# Implementation Plan: Public Docs & Knowledge Base IA **Branch**: `410-public-docs-ia` | **Date**: 2026-05-31 | **Spec**: [spec.md](spec.md) **Input**: Feature specification from `/specs/410-public-docs-ia/spec.md` ## Summary Rework the current root-mounted Starlight starter docs into a dedicated bilingual `/docs` route family backed by the existing MDX docs collection, then replace the lightweight starter pages with the twelve required public knowledge-base topics for Microsoft 365 governance, trust review, evidence, drift, recovery context, review packs, limitations, and FAQ. The implementation stays inside `apps/website`, reuses the existing Astro + Starlight + MDX docs stack for the documentation pages, keeps navigation and footer links inside the current `siteCopy` plus locale helper pattern, and preserves public continuity by mapping the current starter docs routes and the legacy evidence-review docs page to the new docs IA instead of leaving broken public URLs behind. ## Technical Context **Language/Version**: TypeScript 6.0.3, Astro 6.3.3, MDX content files rendered through Starlight 0.39.2 **Primary Dependencies**: Astro, `@astrojs/starlight`, `@astrojs/mdx`, Tailwind CSS v4 via `@tailwindcss/vite`, Playwright 1.59.1 **Storage**: N/A (static public website content only) **Testing**: Playwright smoke tests in `apps/website/tests/smoke` plus `astro check` within the website `build` script **Validation Lanes**: browser, confidence **Target Platform**: Static bilingual website build rendered in desktop and mobile browsers **Project Type**: Web application with Astro page routes plus a Starlight-backed docs surface **Performance Goals**: Preserve static prerendered docs pages, readable desktop/mobile docs layouts, valid metadata, intentional links, no horizontal overflow, and no broken locale-aware routes **Constraints**: `apps/website` only, preserve root workspace contracts (`package.json` scripts, `WEBSITE_PORT`, `apps/*` workspace layout), keep `apps/platform` untouched, keep DE as default locale with EN prefixed routes, avoid unsupported trust/provider/automation claims, and keep all docs links real **Scale/Scope**: One new localized docs landing route family, twelve localized child pages, explicit sidebar ordering, nav/footer retargeting, selected public crosslinks, smoke inventory updates, and legacy docs-route continuity handling ## UI / Surface Guardrail Plan - **Guardrail scope**: no operator-facing surface change - **Native vs custom classification summary**: mixed public-site surface; Starlight for docs pages, existing Astro marketing pages for discovery teasers - **Shared-family relevance**: public navigation, footer, metadata, Starlight docs sidebar, related-link cards, and smoke route inventory - **State layers in scope**: shell and page - **Audience modes in scope**: customer/read-only - **Decision/diagnostic/raw hierarchy plan**: docs stay decision-first and buyer-readable; no operator diagnostics or raw evidence surfaces are introduced - **Raw/support gating plan**: N/A - **One-primary-action / duplicate-truth control**: the docs landing page keeps one clear start path into the IA, while each child page uses related links and at most one conversion-oriented handoff to avoid repeating the same CTA block on every section - **Handling modes by drift class or surface**: report-only - **Repository-signal treatment**: review-mandatory for route moves, claim language, and legacy URL continuity - **Special surface test profiles**: N/A - **Required tests or manual smoke**: manual-smoke and browser smoke - **Exception path and spread control**: none - **Active feature PR close-out entry**: Smoke Coverage ## Shared Pattern & System Fit - **Cross-cutting feature marker**: yes - **Systems touched**: `apps/website/astro.config.mjs`, `apps/website/src/content.config.ts`, `apps/website/src/content/docs/**`, `apps/website/src/data_files/site-copy.ts`, `apps/website/src/i18n.ts`, navbar/footer components, and smoke route helpers - **Shared abstractions reused**: Starlight docs collection, Starlight sidebar configuration, custom Starlight shell overrides in `src/components/ui/starlight`, locale helpers in `src/i18n.ts`, and public route smoke helpers in `apps/website/tests/smoke/smoke-helpers.ts` - **New abstraction introduced? why?**: none; the feature should stay inside the existing docs collection plus shared site copy and smoke helpers - **Why the existing abstraction was sufficient or insufficient**: the repo already ships a bilingual Starlight docs surface and smoke coverage for docs routes, but the current IA is starter-like (`/welcome-to-docs/`, `/guides/*`) and does not match the required public knowledge-base structure - **Bounded deviation / spread control**: no second docs system; the plan keeps docs pages in Starlight/MDX and marketing discovery links in existing Astro pages instead of introducing parallel content pipelines ## OperationRun UX Impact - **Touches OperationRun start/completion/link UX?**: no - **Central contract reused**: N/A - **Delegated UX behaviors**: N/A - **Surface-owned behavior kept local**: none - **Queued DB-notification policy**: N/A - **Terminal notification path**: N/A - **Exception path**: none ## Provider Boundary & Portability Fit - **Shared provider/platform boundary touched?**: yes - **Provider-owned seams**: Microsoft 365 provider framing, permissions and data-access wording, consent/admin-role language, and trust references - **Platform-core seams**: docs IA, policy evidence, drift detection, review-pack framing, limitations language, FAQ structure, and evaluation-readiness vocabulary - **Neutral platform terms / contracts preserved**: provider connection, permissions and data access, policy evidence, drift detection, recovery context, findings, accepted risk, review packs, evaluation, known limitations, and FAQ - **Retained provider-specific semantics and why**: Microsoft 365 stays explicit because it is the current public product focus and the docs must remain concrete for evaluators - **Bounded extraction or follow-up path**: document-in-feature only; detailed permission matrices, multi-provider docs, localized slug alias systems, and search/versioning expansion remain follow-up work ## Constitution Check GATE status before Phase 0 research: Pass for website-only scope. - Inventory-first: N/A (no inventory/runtime change) - Read/write separation: Pass (no write behavior) - Graph contract path: N/A (no Graph/API runtime) - Deterministic capabilities: N/A - RBAC-UX and tenant/workspace isolation: N/A (public unauthenticated docs surface) - Run observability / OperationRun UX: N/A - TEST-GOV-001: Pass (browser lane explicit, existing smoke family reused, no fixture/helper cost expansion planned) - PROP-001 / ABSTR-001 / PERSIST-001 / STATE-001 / BLOAT-001: Pass (no new persistence, runtime abstraction, enum, or semantic framework) - XCUT-001: Pass (reuse Starlight docs infrastructure, shared nav/footer copy, and smoke helpers) - PROV-001: Pass (provider-specific language remains bounded to current public Microsoft 365 scope) - DECIDE-AUD-001: N/A for operator/status surfaces; this remains public docs copy only Post-design re-check after Phase 1: Pass. The research, docs content model, route contract, and quickstart stay static public-site artifacts only, keep all runtime product behavior out of scope, and do not require any `apps/platform` touch. ## Test Governance Check - **Test purpose / classification by changed surface**: Browser - **Affected validation lanes**: browser, confidence - **Why this lane mix is the narrowest sufficient proof**: the feature changes public routes, sidebar/nav/footer links, metadata, localized URLs, and claim-safe copy; those are best proven by the existing public route and interaction smoke suites plus the website build - **Narrowest proving command(s)**: - `corepack pnpm --filter @tenantatlas/website build` - `corepack pnpm --filter @tenantatlas/website test tests/smoke/public-routes.spec.ts` - `corepack pnpm --filter @tenantatlas/website test tests/smoke/interaction.spec.ts` - **Fixture / helper / factory / seed / context cost risks**: none - **Expensive defaults or shared helper growth introduced?**: no - **Heavy-family additions, promotions, or visibility changes**: none - **Surface-class relief / special coverage rule**: public website browser smoke only - **Closing validation and reviewer handoff**: reviewers verify docs routes render in both locales, legacy docs URLs do not break silently, nav/footer and contextual links point at the new docs family, and no banned claims appear in source or build output - **Budget / baseline / trend follow-up**: none expected - **Review-stop questions**: lane fit, hidden route-migration cost, legacy-link continuity, and claim-boundary completeness - **Escalation path**: document-in-feature - **Active feature PR close-out entry**: Smoke Coverage - **Why no dedicated follow-up spec is needed**: the work remains inside existing website docs infrastructure; future search/versioning/provider-expansion concerns are separate slices only if product truth changes ## Project Structure ### Documentation (this feature) ```text specs/410-public-docs-ia/ ├── plan.md ├── research.md ├── data-model.md ├── quickstart.md ├── contracts/ │ └── public-docs-routes.openapi.yaml └── spec.md ``` ### Source Code (repository root) ```text apps/website/ ├── astro.config.mjs ├── src/ │ ├── content.config.ts │ ├── content/ │ │ └── docs/ │ │ ├── index.mdx │ │ ├── getting-started.mdx │ │ ├── microsoft-365-provider.mdx │ │ ├── permissions-data-access.mdx │ │ ├── data-processing-trust.mdx │ │ ├── policy-evidence.mdx │ │ ├── drift-detection.mdx │ │ ├── backups-versioning-recovery.mdx │ │ ├── findings-exceptions-accepted-risk.mdx │ │ ├── review-packs-decisions.mdx │ │ ├── evaluation-pilot.mdx │ │ ├── known-limitations.mdx │ │ ├── faq.mdx │ │ └── en/ │ │ ├── index.mdx │ │ ├── getting-started.mdx │ │ ├── microsoft-365-provider.mdx │ │ ├── permissions-data-access.mdx │ │ ├── data-processing-trust.mdx │ │ ├── policy-evidence.mdx │ │ ├── drift-detection.mdx │ │ ├── backups-versioning-recovery.mdx │ │ ├── findings-exceptions-accepted-risk.mdx │ │ ├── review-packs-decisions.mdx │ │ ├── evaluation-pilot.mdx │ │ ├── known-limitations.mdx │ │ └── faq.mdx │ ├── components/ │ │ ├── sections/ │ │ │ └── navbar&footer/ │ │ │ ├── FooterSection.astro │ │ │ └── Navbar.astro │ │ └── ui/ │ │ └── starlight/ │ ├── data_files/ │ │ └── site-copy.ts │ └── i18n.ts └── tests/smoke/ ├── interaction.spec.ts ├── public-routes.spec.ts └── smoke-helpers.ts ``` **Structure Decision**: Keep marketing pages as Astro routes and move the public docs IA deeper into the existing Starlight + MDX docs collection. Navigation/footer stay copy-driven in `site-copy.ts`; docs pages and sidebar stay content-driven in `src/content/docs/**` and `astro.config.mjs`. ## Documentation IA Decision Selected IA shape: - dedicated docs base route at `/docs/` and `/en/docs/` - twelve required child pages below the docs base route - stable English slugs for both locales - localized visible labels in the Starlight sidebar and on page content - explicit sidebar ordering instead of the current starter `guides` autogeneration Reasoning: - The repository already ships Starlight and a docs content collection, so nested docs routes are supported without inventing a new content stack. - The spec explicitly prefers a `/docs` family, and the current root-mounted starter docs do not yet provide that public IA. - The broader website already uses many English technical slugs (`/platform`, `/trust`, `/pricing`, `/contact`, `/use-cases/...`), so stable English docs slugs are the narrowest path and avoid expanding locale alias logic from one special case (`/evaluierung` <-> `/evaluation`) to twelve more route families. - Explicit sidebar entries are safer than `guides/` autogeneration because the required docs order is fixed by the spec and mixes concept, trust, and readiness topics. Rejected alternatives: - Keep `/welcome-to-docs/` and `/guides/*` as the primary IA: misaligned with the spec and too starter-like for the required public knowledge base. - Use `/dokumentation` and `/en/documentation`: adds another localized slug family when the existing public site already tolerates English route slugs. - Landing-page-only fallback: unnecessary because Starlight nested docs infrastructure already exists in the repo. ## Docs Content System Decision Selected content system: - Starlight-backed MDX pages in `apps/website/src/content/docs/**` - localized DE root files and EN mirror files under `apps/website/src/content/docs/en/**` - current Starlight custom shell components retained - page metadata and page body content authored in MDX frontmatter/content, not in `siteCopy.ts` Reasoning: - The current repo already validates docs content through `src/content.config.ts`, Starlight docs loader/schema, and the website build. - The docs surface already ships Pagefind search assets in the generated build, so using the existing docs system keeps future expansion options open without adding work now. - `siteCopy.ts` is the right place for nav/footer labels and marketing page copy, but not for twelve concept-heavy docs pages in two locales. Rejected alternatives: - Build the docs IA as custom Astro marketing pages under `src/pages/docs/**`: would duplicate a docs rendering system the repo already has. - Keep the starter Starlight pages and only change sidebar labels: too weak for the required route and content restructuring. - Create a second content collection just for docs IA: unnecessary while `src/content/docs/**` already exists. ## Legacy Route Continuity Decision Selected continuity approach: preserve public continuity through redirects or equivalent route aliases from the current starter docs URLs to the new docs family. Minimum legacy mapping to preserve: - `/welcome-to-docs/` -> `/docs/` - `/guides/intro/` -> `/docs/getting-started/` - `/guides/getting-started/` -> `/docs/getting-started/` - `/guides/first-project-checklist/` -> `/docs/evaluation-pilot/` - `/platform/evidence-review/` -> `/docs/policy-evidence/` - `/en/welcome-to-docs/` -> `/en/docs/` - `/en/guides/intro/` -> `/en/docs/getting-started/` - `/en/guides/getting-started/` -> `/en/docs/getting-started/` - `/en/guides/first-project-checklist/` -> `/en/docs/evaluation-pilot/` - `/en/platform/evidence-review/` -> `/en/docs/policy-evidence/` Reasoning: - The current public nav, footer, and smoke inventory already expose the starter docs URLs, so silently removing them would create regressions. - The old evidence-review docs page is conceptually closest to the new `policy-evidence` topic and can hand off there without inventing a second evidence docs tree. - Redirecting or aliasing the old docs URLs is narrower than permanently supporting two public docs IAs. Rejected alternatives: - Keep both the new `/docs` family and the old starter docs pages permanently: duplicate truth and split discoverability. - Drop the old URLs without continuity handling: would break existing public links and smoke expectations. ## Discovery Strategy Decision Selected minimum discovery surfaces: - main navigation `Docs` link - footer `Docs` link - homepage teaser - platform page teaser - trust page crosslink - evaluation page crosslink Selected secondary surfaces when both checks pass: - the destination route already exists in the local public IA - the page can reuse an existing teaser or card slot without adding a new section or displacing its primary CTA - review-packs page crosslink - MSP use-case crosslink - Mittelstand use-case crosslink Reasoning: - Navigation and footer already carry a docs entry today, so the simplest change is to retarget them from `/welcome-to-docs/` to `/docs/`. - Homepage, platform, trust, and evaluation are the most direct adjacent public surfaces named in the spec. - Review packs and use-case pages already sit in the public route inventory and can support docs discovery when the destination route exists and a docs handoff fits into an existing teaser or card slot without creating a second CTA hierarchy. Rejected alternatives: - Footer-only discoverability: too weak for a major public IA shift. - Main-nav-only discoverability: insufficient without contextual handoff from trust, evaluation, and product-story pages. - Add a second large navigation family just for docs topics: too broad for the current public site IA. ## Research-Driven Implementation Notes - `apps/website/astro.config.mjs` currently mounts Starlight at the site root and uses a starter sidebar built from `guides/` plus one hardcoded `platform/evidence-review/` entry; implementation must replace that setup with the dedicated docs IA. - `apps/website/src/i18n.ts` currently holds only one slug alias group for `/evaluierung` <-> `/evaluation`; the docs route family should avoid multiplying alias groups by keeping shared English docs slugs across locales. - `apps/website/src/data_files/site-copy.ts` already owns nav and footer docs links; retarget those links rather than inventing a new nav config. - current public metadata handling, including canonical tags where present, must be inspected and reused for the docs landing and child pages instead of introducing docs-only metadata rules. - `apps/website/tests/smoke/smoke-helpers.ts` already keeps `renderedRoutes` and `docsRoutes`; treat those arrays as the source of truth for smoke-route inventory. - `apps/website/tests/smoke/interaction.spec.ts` already asserts desktop keyboard reachability and mobile navigation visibility for the docs link; updating the docs href there is part of the route migration. ## Static Claim Scan Commands - `grep -RIn -e 'href="#"' -e 'lorem ipsum' -e 'repo-real foundation' -e 'productization gap' -e 'capability registry' -e 'provider-neutral artifact taxonomy' -e 'source family' -e 'detector key' -e 'workspace-first cutover' -e 'route-owned context' -e 'implementation truth' -e 'DSGVO-konform' -e 'ISO-zertifiziert' -e 'NIS2-konform' -e 'in Deutschland gehostet' -e 'no customer data stored' -e 'keine Kundendaten' -e 'keine personenbezogenen Daten' -e 'Google supported' -e 'AWS supported' -e 'multi-cloud supported' -e 'real-time drift' -e 'automatic remediation' -e 'automatic restore' -e 'one-click restore' -e 'immutable backups' -e 'lueckenlose Evidence' -e 'lueckenlose Evidenz' -e 'gerichtsfeste Nachweise' -e 'guarantees audit success' -e 'makes you compliant' apps/website/src apps/website/public 2>/dev/null || true` - `grep -RIn -e 'href="#"' -e 'lorem ipsum' -e 'repo-real foundation' -e 'productization gap' -e 'capability registry' -e 'provider-neutral artifact taxonomy' -e 'source family' -e 'detector key' -e 'workspace-first cutover' -e 'route-owned context' -e 'implementation truth' -e 'DSGVO-konform' -e 'ISO-zertifiziert' -e 'NIS2-konform' -e 'in Deutschland gehostet' -e 'no customer data stored' -e 'keine Kundendaten' -e 'keine personenbezogenen Daten' -e 'Google supported' -e 'AWS supported' -e 'multi-cloud supported' -e 'real-time drift' -e 'automatic remediation' -e 'automatic restore' -e 'one-click restore' -e 'immutable backups' -e 'lueckenlose Evidence' -e 'lueckenlose Evidenz' -e 'gerichtsfeste Nachweise' -e 'guarantees audit success' -e 'makes you compliant' apps/website/dist 2>/dev/null || true` ## Planned Validation Results Capture Implementation must record: - exact website commands run from the existing root and website package manifests - the final docs route matrix for DE and EN - whether the final implementation shipped the twelve child pages or a section-only fallback - any legacy redirect or alias mapping shipped for the old docs URLs - whether canonical metadata support exists and was reused for docs pages, or why FR-034 resolved as N/A - nav/footer/docs crosslink changes and any intentionally omitted discovery surfaces - static claim scan outcomes in source and generated output - browser smoke pass/fail notes for docs landing, child pages, nav/footer links, and related public-page crosslinks on desktop and mobile - confirmation that `apps/platform/**` remained untouched ### Validation Results - Commands run: - `corepack pnpm --filter @tenantatlas/website build` - `WEBSITE_PORT=4325 corepack pnpm --filter @tenantatlas/website test tests/smoke/public-routes.spec.ts --reporter=dot` - `corepack pnpm --filter @tenantatlas/website build && WEBSITE_PORT=4326 corepack pnpm --filter @tenantatlas/website test tests/smoke/public-routes.spec.ts -g 'sitemap exposes canonical routes and excludes redirect aliases'` - `WEBSITE_PORT=4328 corepack pnpm --filter @tenantatlas/website test tests/smoke/interaction.spec.ts -g '(answers reviewer-facing questions conservatively|explains technical governance concepts in public language)' --reporter=dot` - `WEBSITE_PORT=4329 corepack pnpm --filter @tenantatlas/website test tests/smoke/interaction.spec.ts --reporter=dot` - `grep -RIn -e 'href="#"' -e 'lorem ipsum' -e 'repo-real foundation' -e 'productization gap' -e 'capability registry' -e 'provider-neutral artifact taxonomy' -e 'source family' -e 'detector key' -e 'workspace-first cutover' -e 'route-owned context' -e 'implementation truth' -e 'DSGVO-konform' -e 'ISO-zertifiziert' -e 'NIS2-konform' -e 'in Deutschland gehostet' -e 'no customer data stored' -e 'keine Kundendaten' -e 'keine personenbezogenen Daten' -e 'Google supported' -e 'AWS supported' -e 'multi-cloud supported' -e 'real-time drift' -e 'automatic remediation' -e 'automatic restore' -e 'one-click restore' -e 'immutable backups' -e 'lueckenlose Evidence' -e 'lueckenlose Evidenz' -e 'gerichtsfeste Nachweise' -e 'guarantees audit success' -e 'makes you compliant' apps/website/src apps/website/public 2>/dev/null || true` - `grep -RIn -e 'href="#"' -e 'lorem ipsum' -e 'repo-real foundation' -e 'productization gap' -e 'capability registry' -e 'provider-neutral artifact taxonomy' -e 'source family' -e 'detector key' -e 'workspace-first cutover' -e 'route-owned context' -e 'implementation truth' -e 'DSGVO-konform' -e 'ISO-zertifiziert' -e 'NIS2-konform' -e 'in Deutschland gehostet' -e 'no customer data stored' -e 'keine Kundendaten' -e 'keine personenbezogenen Daten' -e 'Google supported' -e 'AWS supported' -e 'multi-cloud supported' -e 'real-time drift' -e 'automatic remediation' -e 'automatic restore' -e 'one-click restore' -e 'immutable backups' -e 'lueckenlose Evidence' -e 'lueckenlose Evidenz' -e 'gerichtsfeste Nachweise' -e 'guarantees audit success' -e 'makes you compliant' apps/website/dist 2>/dev/null || true` - Final docs route matrix: - DE: `/docs/`, `/docs/getting-started/`, `/docs/microsoft-365-provider/`, `/docs/permissions-data-access/`, `/docs/data-processing-trust/`, `/docs/policy-evidence/`, `/docs/drift-detection/`, `/docs/backups-versioning-recovery/`, `/docs/findings-exceptions-accepted-risk/`, `/docs/review-packs-decisions/`, `/docs/evaluation-pilot/`, `/docs/known-limitations/`, `/docs/faq/` - EN: `/en/docs/` plus the same twelve child slugs under `/en/docs/` - Shipped docs shape: full bilingual docs landing plus all twelve child pages shipped; no section-only fallback was used. - Legacy alias behavior: - `/welcome-to-docs/` -> `/docs/` - `/guides/intro/` -> `/docs/getting-started/` - `/guides/getting-started/` -> `/docs/getting-started/` - `/guides/first-project-checklist/` -> `/docs/evaluation-pilot/` - `/platform/evidence-review/` -> `/docs/policy-evidence/` - `/en/welcome-to-docs/` -> `/en/docs/` - `/en/guides/intro/` -> `/en/docs/getting-started/` - `/en/guides/getting-started/` -> `/en/docs/getting-started/` - `/en/guides/first-project-checklist/` -> `/en/docs/evaluation-pilot/` - `/en/platform/evidence-review/` -> `/en/docs/policy-evidence/` - Canonical metadata reuse: Starlight page metadata and canonicals are reused for all docs pages; the generated Astro redirect pages emit canonical links to their target docs routes and are excluded from the sitemap. - Shipped discovery surfaces: - nav `Docs` - footer `Docs` - homepage docs CTA - platform docs CTA - trust docs CTA - evaluation docs CTA - review-packs docs CTA - DE and EN use-case docs CTAs - contact-page docs handoff - Starlight site-title docs link - Intentionally omitted discovery changes: no second docs navigation system, no new standalone marketing sections, and no `apps/platform/**` changes. - Static claim scan outcomes: - `apps/website/src` and `apps/website/public`: no matches - `apps/website/dist`: no matches - Smoke Coverage close-out: - `public-routes.spec.ts`: initial full run reached `540 passed / 2 failed`, then the sitemap exclusion rerun passed `2/2`; the remaining targeted EN claim-route rerun passed `24/24` after copy fixes. - `interaction.spec.ts`: initial full run reached `106 passed / 28 failed / 6 skipped`; the targeted docs content rerun passed `44/44` after narrowing heading assertions to the `main` H1, and the final full rerun passed `134/140` with `6` intentional skips. - `apps/platform/**` scope confirmation: `git diff --name-only -- apps/platform` returned no changed files. ### Success Criteria Proof Notes - **SC-001**: `/docs/` and `/en/docs/` now open with a dedicated docs hero and one-click entry points to every required topic; interaction smoke asserts the landing-page topic links and public handoffs are visible. - **SC-002**: each required category is reachable from the docs landing page in one click through the explicit topic card grid and sidebar order. - **SC-003**: reviewer-oriented pages, technical-concept pages, nav/footer links, and contextual discovery CTAs are covered by route and interaction smoke without placeholder links or fake download artifacts. - **SC-004**: source, public assets, rendered output, and browser smoke all passed the forbidden-claim and placeholder-link checks after copy hardening on recovery/drift phrasing. - **SC-005**: desktop and mobile browser smoke passed for public routes and interactions, including docs landing, localized child pages, discovery CTAs, and legacy starter-route continuity. - **SC-006**: implementation stayed inside `apps/website/**` plus feature-spec artifacts; `apps/platform/**` remained untouched. ### Quickstart Validation - `quickstart.md` remained aligned with the implemented route family, validation commands, legacy alias expectations, and static scan command set. - Local `WEBSITE_PORT=432x` overrides were used only to avoid preview port collisions during Playwright runs; no documentation drift or script-contract drift was introduced. ## Complexity Tracking No constitutional violations and no bloat-triggering additions are planned for this feature. ## Proportionality Review N/A for this implementation plan. The feature introduces no new enum/status family, DTO/presenter/envelope layer, persisted entity/table/artifact, interface/contract/registry/resolver, taxonomy system, or cross-domain UI framework. It only rehomes and expands the existing public docs surface inside the current website docs infrastructure.