Reviewed 2026-09-19. These decisions implement the user's approved option 2 plan. They do not change A7 syntax or compiler behavior.
Use a persistent documentation rail, a readable article column, and an optional page outline. Collapse navigation into native disclosures on smaller screens so it works without JavaScript. Separate the guided tour from exhaustive language reference. This applies the distinction between learning and information retrieval in Diátaxis.
The 2026-11 landing + responsive pass keeps that IA. The home route adds a brand-first hero (large A7, one sentence, two CTAs, full-bleed code visual) before the shared shell. Responsive hardening covers safe-area insets, short-height orientations, local overflow for tables and code, and progressive fold / viewport-segment dual-pane rules. Fold hardware coverage is only as strong as the CSS APIs the browser exposes; record simulations separately from device claims.
No option 2 concept image was located by the initial repository filename search. The written approved plan is the design authority for the docs shell. The Project store brief site-responsive-redesign.md (approach 3) is the authority for the landing and fold/responsive additions. Existing screenshots under docs/audits/2026-09-19/browser/ record the previous site, not acceptance of this rebuild. Do not claim a pixel comparison against an unavailable reference.
Use Inter Variable for prose and navigation, with JetBrains Mono for literal source and terminal commands. Inter documents optical sizing and tabular figures. JetBrains documents its code-oriented character design. These properties suit this layout; they do not prove Inter is the fastest font for every reader. Research found substantial individual variation in reading speed across fonts.
- Inter documentation and license links
- JetBrains Mono documentation
- Individual reading differences, Adobe Research
Self-host pinned WOFF2 files and retain license notices. Use swap display, preload only the primary prose font, and test blocked fonts. A preload can improve discovery but also competes for bandwidth; excessive preloading is not a substitute for measuring the page. See web.dev font delivery guidance.
Set body text to 1.0625rem with a 1.65 line height and prose width near 65ch. Use 0.9375rem code with a 1.6 line height. Disable code ligatures to retain literal operators. These dimensions are project choices from the approved plan.
Use the plan's neutral light and dark backgrounds and restrained red links. Underline article links and provide a visible focus outline. Status text must state supported, limited, unavailable, planned, or unverified rather than relying on color. Validate actual rendered pairings, including secondary surfaces, against WCAG contrast guidance and use of color guidance.
Review reflow at a 320 CSS pixel width and enlarged text. Keep code and wide tables in local overflow containers. Test spacing overrides without hidden or overlapping content. These checks follow reflow guidance and text spacing guidance. Passing a viewport sweep alone is not complete accessibility acceptance.
Simple compiler and memory explanations use semantic HTML with explicit labels and equivalent text. Labels remain visible without hovering. Complex diagrams need a caption and an explanation that preserves the relationships, following W3C complex-image guidance. Do not invent performance charts or completion percentages.
Keep llms.txt a concise grouped Markdown index. Recommend selective retrieval, with llms-full.txt available for consumers that need the complete corpus. Each document has a Markdown twin; structured metadata describes features, qualifications, evidence, and source revision. A revision identifies a source snapshot and is not proof of correctness.
The llms.txt proposal describes a discovery convention. The fetched page labels its current text v2. Adoption by a particular agent is not guaranteed. Preserve the project's established URLs and ordinary Markdown links independently of proposal revisions.
Compiler tests establish only the behaviors they exercise. Parser acceptance cannot establish native execution support. Browser captures establish only the states and viewports inspected. Record unsupported features and unresolved specification conflicts explicitly. The final verification report must distinguish automated checks, manual inspection, and skipped checks.