merge: resolve dev conflict in copilot instructions

.github/agents/copilot-instructions.md

@@ -230,10 +230,14 @@ ## Active Technologies
 - PostgreSQL via existing `findings`, `tenants`, `tenant_memberships`, and workspace context session state; no schema changes planned (221-findings-operator-inbox)
 - PHP 8.4.15, Laravel 12, Filament v5, Livewire v4, Blade + Filament admin pages/tables/actions/notifications, `Finding`, `FindingResource`, `FindingWorkflowService`, `FindingPolicy`, `CapabilityResolver`, `CanonicalAdminTenantFilterState`, `CanonicalNavigationContext`, `WorkspaceContext`, and `UiEnforcement` (222-findings-intake-team-queue)
 - PostgreSQL via existing `findings`, `tenants`, `tenant_memberships`, `audit_logs`, and workspace session context; no schema changes planned (222-findings-intake-team-queue)
+- TypeScript 5.9, Astro 6, Node.js 20+ + Astro, astro-icon, Tailwind CSS v4, Playwright 1.59 (223-astrodeck-website-rebuild)
+- File-based route files, Astro content collections under `src/content`, public assets, and planning documents under `specs/223-astrodeck-website-rebuild`; no database (223-astrodeck-website-rebuild)
 - PHP 8.4.15, Laravel 12, Filament v5, Livewire v4, Blade + Laravel notifications (`database` channel), Filament database notifications, `Finding`, `FindingWorkflowService`, `FindingSlaPolicy`, `AlertRule`, `AlertDelivery`, `AlertDispatchService`, `EvaluateAlertsJob`, `CapabilityResolver`, `WorkspaceContext`, `TenantMembership`, `FindingResource` (224-findings-notifications-escalation)
 - PostgreSQL via existing `findings`, `alert_rules`, `alert_deliveries`, `notifications`, `tenant_memberships`, and `audit_logs`; no schema changes planned (224-findings-notifications-escalation)
 - PHP 8.4.15, Laravel 12, Filament v5, Livewire v4, Blade + `Finding`, `FindingResource`, `MyFindingsInbox`, `FindingsIntakeQueue`, `WorkspaceOverviewBuilder`, `EnsureFilamentTenantSelected`, `FindingWorkflowService`, `AuditLog`, `TenantMembership`, Filament page and table primitives (225-assignment-hygiene)
 - PostgreSQL via existing `findings`, `audit_logs`, `tenant_memberships`, and `users`; no schema changes planned (225-assignment-hygiene)
+- Markdown artifacts + Astro 6.0.0 + TypeScript 5.9 context for source discovery + Repository spec workflow (`.specify`), Astro website source tree under `apps/website/src`, existing component taxonomy (`primitives`, `content`, `sections`, `layout`) (226-astrodeck-inventory-planning)
+- Filesystem only (`specs/226-astrodeck-inventory-planning/*`) (226-astrodeck-inventory-planning)
 
 - PHP 8.4.15 (feat/005-bulk-operations)
 
@@ -268,6 +272,7 @@ ## Code Style
 PHP 8.4.15: Follow standard conventions
 
 ## Recent Changes
+- 226-astrodeck-inventory-planning: Added Markdown artifacts + Astro 6.0.0 + TypeScript 5.9 context for source discovery + Repository spec workflow (`.specify`), Astro website source tree under `apps/website/src`, existing component taxonomy (`primitives`, `content`, `sections`, `layout`)
 - 225-assignment-hygiene: Added PHP 8.4.15, Laravel 12, Filament v5, Livewire v4, Blade + `Finding`, `FindingResource`, `MyFindingsInbox`, `FindingsIntakeQueue`, `WorkspaceOverviewBuilder`, `EnsureFilamentTenantSelected`, `FindingWorkflowService`, `AuditLog`, `TenantMembership`, Filament page and table primitives
 - 224-findings-notifications-escalation: Added PHP 8.4.15, Laravel 12, Filament v5, Livewire v4, Blade + Laravel notifications (`database` channel), Filament database notifications, `Finding`, `FindingWorkflowService`, `FindingSlaPolicy`, `AlertRule`, `AlertDelivery`, `AlertDispatchService`, `EvaluateAlertsJob`, `CapabilityResolver`, `WorkspaceContext`, `TenantMembership`, `FindingResource`
 - 222-findings-intake-team-queue: Added PHP 8.4.15, Laravel 12, Filament v5, Livewire v4, Blade + Filament admin pages/tables/actions/notifications, `Finding`, `FindingResource`, `FindingWorkflowService`, `FindingPolicy`, `CapabilityResolver`, `CanonicalAdminTenantFilterState`, `CanonicalNavigationContext`, `WorkspaceContext`, and `UiEnforcement`

specs/213-website-foundation-v0/spec.md

@@ -159,3 +159,10 @@ ### Measurable Outcomes
 - **SC-004**: Every core page includes a visible next-step CTA and at least one deeper path into the product, trust, or contact story.
 - **SC-005**: No released page contains placeholder copy, unsubstantiated trust or compliance claims, or speculative integration promises.
 - **SC-006**: Core pages remain readable and navigable on both desktop and mobile widths without horizontal scrolling or hidden primary navigation.
+
+## Spec 223 Rebuild Status
+
+- **Classification**: partially valid
+- **Forward owner**: `../223-astrodeck-website-rebuild/mappings/spec-213-website-foundation-v0.md`
+- **Material drift now recorded**: canonical trust routing now lives on `/trust`, `/security-trust` is redirect-only, `/changelog` and `/imprint` are canonical public surfaces, and `/legal`, `/terms`, `/solutions`, and `/integrations` are retained secondary routes under the smaller IA.
+- **Forward-work rule**: new implementation work must start from the AstroDeck intake aliases and the Spec 223 mapping sheet instead of from the current `apps/website` implementation.

specs/213-website-foundation-v0/tasks.md

@@ -5,6 +5,12 @@ # Tasks: Initial Website Foundation & v0 Product Site
 
 **Tests**: Browser smoke coverage is required for this runtime-changing website feature, together with the root website build proof.
 
+## Historical Status
+
+This implementation record is retained for traceability and is superseded by AstroDeck rebuild.
+
+Forward planning now lives in `../223-astrodeck-website-rebuild/mappings/spec-213-website-foundation-v0.md`. Do not reset or reopen the checkbox state below; new work belongs to the Spec 223 mapping and follow-up slices.
+
 ## Test Governance Checklist
 
 - [X] Lane assignment is named and is the narrowest sufficient proof for the changed behavior.

specs/214-website-visual-foundation/spec.md

@@ -173,4 +173,11 @@ ### Measurable Outcomes
 - **SC-002**: Reviewers can assess the same three representative page families without raising unresolved foundational questions about typography hierarchy, spacing rhythm, surface usage, or CTA weighting.
 - **SC-003**: 100% of library-derived website components proposed for the initial implementation phase can be justified as adaptations of the defined token and primitive model rather than uncontrolled default styles.
 - **SC-004**: The specification contains zero requirements that obligate visual changes to `apps/platform`, Filament, or a shared cross-surface design system.
-- **SC-005**: At least one primary CTA hierarchy and one low-emphasis CTA pattern are defined clearly enough that reviewers can classify CTA weight consistently across representative website pages.
+- **SC-005**: At least one primary CTA hierarchy and one low-emphasis CTA pattern are defined clearly enough that reviewers can classify CTA weight consistently across representative website pages.
+
+## Spec 223 Rebuild Status
+
+- **Classification**: continuing
+- **Forward owner**: `../223-astrodeck-website-rebuild/mappings/spec-214-website-visual-foundation.md`
+- **Material drift**: none logged. AstroDeck changes the implementation substrate only; this website-local visual contract remains authoritative.
+- **Forward-work rule**: all AstroDeck primitives must be adapted to the Spec 214 foundation before they are allowed into `apps/website`.

specs/214-website-visual-foundation/tasks.md

@@ -5,6 +5,12 @@ # Tasks: Website Visual Foundation
 
 **Tests**: Browser smoke coverage and the root website build proof are required for this runtime-changing website feature.
 
+## Historical Status
+
+This implementation record is retained for traceability and is superseded by AstroDeck rebuild.
+
+Forward planning now lives in `../223-astrodeck-website-rebuild/mappings/spec-214-website-visual-foundation.md`. Do not reset or reopen the checkbox state below; new work belongs to the Spec 223 mapping and follow-up slices.
+
 ## Test Governance Checklist
 
 - [X] Lane assignment is named and is the narrowest sufficient proof for the changed behavior.

specs/215-website-core-pages/spec.md

@@ -201,4 +201,11 @@ ## Planned Follow-on Specs
 - Spec 222 - Changelog Surface
 - Spec 223 - Blog / Resources Surface, if activated
 - Spec 224 - Solutions / Use-Case Surfaces, if activated later
-- Spec 225 - Pricing Surface, if activated later
+- Spec 225 - Pricing Surface, if activated later
+
+## Spec 223 Rebuild Status
+
+- **Classification**: continuing
+- **Forward owner**: `../223-astrodeck-website-rebuild/mappings/spec-215-website-core-pages.md`
+- **Material drift**: none logged. This spec remains the canonical IA source of truth that constrains AstroDeck adoption.
+- **Forward-work rule**: no AstroDeck route or navigation item may become public unless it matches the required, retained-secondary, or approved-optional surfaces defined here.

specs/215-website-core-pages/tasks.md

@@ -5,6 +5,12 @@ # Tasks: Website Information Architecture / Core Pages
 
 **Tests**: Browser smoke coverage and the root website build proof are required for this runtime-changing website feature.
 
+## Historical Status
+
+This implementation record is retained for traceability and is superseded by AstroDeck rebuild.
+
+Forward planning now lives in `../223-astrodeck-website-rebuild/mappings/spec-215-website-core-pages.md`. Do not reset or reopen the checkbox state below; new work belongs to the Spec 223 mapping and follow-up slices.
+
 ## Test Governance Checklist
 
 - [X] Lane assignment is named and is the narrowest sufficient proof for the changed behavior.

specs/217-homepage-structure/spec.md

@@ -212,4 +212,11 @@ ### Measurable Outcomes
 - **SC-008**: The hero visual communicates at least one TenantAtlas-specific governance concept such as drift, review, restore, evidence, or bounded access rather than generic dashboard activity.
 - **SC-009**: Reviewers can identify at least one typographic or compositional cue and one product-truth cue that distinguish the hero from a generic shadcn or Tailwind marketing layout.
 - **SC-010**: On desktop and mobile, the hero retains clear contrast between the dominant element, supporting copy, product visual, and CTA instead of flattening into visually equal neutral surfaces.
-- **SC-011**: The released homepage hero avoids the anti-patterns of neutral mush and correct-but-forgettable minimalism while remaining calm and trust-oriented.
+- **SC-011**: The released homepage hero avoids the anti-patterns of neutral mush and correct-but-forgettable minimalism while remaining calm and trust-oriented.
+
+## Spec 223 Rebuild Status
+
+- **Classification**: continuing
+- **Forward owner**: `../223-astrodeck-website-rebuild/mappings/spec-217-homepage-structure.md`
+- **Material drift**: none logged. Optional AstroDeck proof sections are handled as remove/adapt decisions inside the mapping sheet, not as structural homepage truth changes.
+- **Forward-work rule**: AstroDeck homepage work must preserve the required block order of hero, outcome, product model, trust, progress, CTA, and footer.

specs/217-homepage-structure/tasks.md

@@ -5,6 +5,12 @@ # Tasks: Website Homepage Structure & Section Model
 
 **Tests**: Browser smoke coverage and the root website build proof are required for this runtime-changing website feature.
 
+## Historical Status
+
+This implementation record is retained for traceability and is superseded by AstroDeck rebuild.
+
+Forward planning now lives in `../223-astrodeck-website-rebuild/mappings/spec-217-homepage-structure.md`. Do not reset or reopen the checkbox state below; new work belongs to the Spec 223 mapping and follow-up slices.
+
 ## Test Governance Checklist
 
 - [X] Lane assignment stays `Browser` in `fast-feedback`, which is the narrowest sufficient proof for this homepage-only change.
@@ -216,4 +222,4 @@ ### Suggested MVP Scope
 
 - Deliver through **User Story 1** for the smallest independently valuable slice.
 - Add **User Story 2** next for stronger product-model and trust proof.
-- Finish with **User Story 3** for fully deliberate onward routing from the homepage.
+- Finish with **User Story 3** for fully deliberate onward routing from the homepage.

specs/218-homepage-hero/spec.md

@@ -186,4 +186,11 @@ ## Planned Follow-on Work
 - Product-visual and screenshot strategy
 - Final hero copy exploration
 - Stitch-based hero design exploration
-- Downstream homepage-section detail work that assumes this hero contract rather than redefining it
+- Downstream homepage-section detail work that assumes this hero contract rather than redefining it
+
+## Spec 223 Rebuild Status
+
+- **Classification**: continuing
+- **Forward owner**: `../223-astrodeck-website-rebuild/mappings/spec-218-homepage-hero.md`
+- **Material drift**: none logged. AstroDeck can provide the hero shell, but it does not change the allowed semantic structure or anti-pattern rules.
+- **Forward-work rule**: mapped AstroDeck hero primitives must keep one clear anchor, one CTA pair, product-near visual truth, and bounded trust cues on desktop and mobile.

specs/218-homepage-hero/tasks.md

@@ -5,6 +5,12 @@ # Tasks: Website Homepage Hero
 
 **Tests**: Browser smoke coverage and the root website build proof are required for this runtime-changing website feature.
 
+## Historical Status
+
+This implementation record is retained for traceability and is superseded by AstroDeck rebuild.
+
+Forward planning now lives in `../223-astrodeck-website-rebuild/mappings/spec-218-homepage-hero.md`. Do not reset or reopen the checkbox state below; new work belongs to the Spec 223 mapping and follow-up slices.
+
 ## Test Governance Checklist
 
 - [X] Lane assignment stays `Browser` in `fast-feedback`, which is the narrowest sufficient proof for this homepage-hero-only change.
@@ -199,4 +205,4 @@ ### Suggested MVP Scope
 
 - Deliver through **User Story 1** for the smallest independently valuable slice.
 - Add **User Story 2** next for stronger visual truth and bounded credibility cues.
-- Finish with **User Story 3** for deliberate narrow-screen behavior and route integrity.
+- Finish with **User Story 3** for deliberate narrow-screen behavior and route integrity.

specs/223-astrodeck-website-rebuild/astrodeck-primitive-inventory.md

@@ -0,0 +1,69 @@
+# AstroDeck Primitive Inventory
+
+The IDs below are stable intake aliases for the AstroDeck snapshot described in `astrodeck-source-intake.md`. They are the only allowed primitive vocabulary for follow-up rebuild planning until the real snapshot is mounted and bound to these aliases.
+
+## Inventory Columns
+
+| Column | Meaning |
+| --- | --- |
+| `primitiveId` | Stable intake alias used by the mapping sheets |
+| `primitiveType` | `page`, `section`, or `component` |
+| `sourceReference` | Expected AstroDeck source family or later binding target |
+| `candidateSurfaces` | Current routes or spec slices the primitive can support |
+| `demoContentFlags` | Demo artifacts that must be removed, adapted, or explicitly approved |
+| `notes` | Review guidance before the primitive is kept or adapted |
+
+## Page Candidates
+
+| primitiveId | primitiveType | sourceReference | candidateSurfaces | demoContentFlags | notes |
+| --- | --- | --- | --- | --- | --- |
+| `adk-page-home-marketing` | page | `snapshot/page/home` | `/`, Specs 213, 215, 217, 218 | demo stats, generic customer proof, newsletter CTA | Primary landing substrate for the rebuild. |
+| `adk-page-product-overview` | page | `snapshot/page/product-or-features` | `/product`, Specs 213, 215 | feature-silo copy, pricing teaser | Use for the product-model page, not a feature-wall clone. |
+| `adk-page-trust-proof` | page | `snapshot/page/security-or-proof` | `/trust`, Specs 213, 215, 217, 218 | compliance theater, absolute claims, badge walls | Preferred starting point for the canonical trust route. |
+| `adk-page-contact-conversion` | page | `snapshot/page/contact` | `/contact`, Specs 213, 215 | generic sales language, oversized lead form | Must be adapted to the working-session framing. |
+| `adk-page-content-index` | page | `snapshot/page/blog-or-news-index` | `/changelog`, optional `/resources` | blog taxonomy chrome, author bios, editorial promos | Repurpose for dated changelog proof; keep resources unpublished unless substantive. |
+| `adk-page-legal-utility` | page | `snapshot/page/legal-or-company-utility` | `/privacy`, `/imprint`, `/terms`, `/legal` | placeholder legal copy, company boilerplate | Use as the base for legal surfaces; do not ship template legal text. |
+| `adk-page-supporting-showcase` | page | `snapshot/page/about-solutions-or-integrations` | `/solutions`, `/integrations` | fake logos, partner walls, over-broad ecosystem claims | Secondary-only surface for audience-fit and integration-fit pages. |
+
+## Section Candidates
+
+| primitiveId | primitiveType | sourceReference | candidateSurfaces | demoContentFlags | notes |
+| --- | --- | --- | --- | --- | --- |
+| `adk-section-hero-split-media` | section | `snapshot/section/hero-split-media` | homepage, product, trust, contact | startup buzzwords, fake metrics, decorative dashboard wallpaper | Preferred hero family for Specs 217 and 218. |
+| `adk-section-outcome-band` | section | `snapshot/section/outcomes-or-value-band` | homepage, product | vague benefit copy, investor-style slogans | Use to translate product capability into buyer outcomes. |
+| `adk-section-feature-cluster-grid` | section | `snapshot/section/feature-grid-or-capability-clusters` | homepage, product, solutions, integrations | equal-weight feature cards, pricing hooks | Must be grouped by product model, not by generic marketing categories. |
+| `adk-section-trust-principles` | section | `snapshot/section/trust-or-proof-grid` | trust page, homepage | compliance badges, guarantee claims | Use only with bounded, supportable trust language. |
+| `adk-section-proof-stats` | section | `snapshot/section/stats-or-proof-strip` | homepage, product, trust | invented KPIs, vanity counters | Remove unless real approved proof exists. |
+| `adk-section-logo-strip` | section | `snapshot/section/logo-cloud` | homepage, solutions | fake customers, unapproved brands | Remove by default. |
+| `adk-section-testimonial-stack` | section | `snapshot/section/testimonials` | homepage, solutions | fabricated quotes, polished social proof | Remove by default. |
+| `adk-section-changelog-teaser` | section | `snapshot/section/news-or-update-teaser` | homepage, changelog | editorial filler, blog cards without dated product value | Keep only if it points to real dated changelog entries. |
+| `adk-section-contact-form` | section | `snapshot/section/contact-form` | contact, footer CTA follow-through | unnecessary intake fields, aggressive SDR language | Adapt to minimal useful working-session context. |
+| `adk-section-cta-band` | section | `snapshot/section/final-cta` | homepage, product, trust, changelog, legal | duplicated loud CTAs, demo pressure | Keep exactly one dominant action. |
+| `adk-section-footer-utility` | section | `snapshot/section/footer-utility` | all public routes | docs/pricing overload, empty content links | Must match the canonical 215 IA. |
+
+## Component Candidates
+
+| primitiveId | primitiveType | sourceReference | candidateSurfaces | demoContentFlags | notes |
+| --- | --- | --- | --- | --- | --- |
+| `adk-component-header-nav` | component | `snapshot/component/header-nav` | all public routes | pricing/docs/blog clutter | Must shrink to Product, Trust, Changelog, Contact, plus one CTA. |
+| `adk-component-footer-nav` | component | `snapshot/component/footer-nav` | all public routes | template link dumps | Must preserve trust/legal/contact grouping. |
+| `adk-component-primary-button` | component | `snapshot/component/button-primary` | homepage, product, trust, contact | multi-primary CTA styling | Dominant CTA only. |
+| `adk-component-secondary-button` | component | `snapshot/component/button-secondary` | homepage, product, trust, contact, changelog | outline fallback styling with no hierarchy | Use only as a lower-emphasis deepening action. |
+| `adk-component-badge-chip` | component | `snapshot/component/badge-chip` | hero trust cues, callouts | badge walls, pseudo-certification labels | Use sparingly and only with factual claims. |
+| `adk-component-card-surface` | component | `snapshot/component/card` | product clusters, legal summaries, changelog cards | over-elevated surfaces | Keep border-first clarity and restrained shadows. |
+| `adk-component-section-shell` | component | `snapshot/component/section-shell` | all page families | inconsistent width/spacing defaults | Main adaptation point for Spec 214 spacing and surface rules. |
+| `adk-component-input-field` | component | `snapshot/component/input` | contact | marketing-form defaults | Must align to the website foundation and minimal intake scope. |
+| `adk-component-textarea-field` | component | `snapshot/component/textarea` | contact | marketing-form defaults | Same constraint as the input field. |
+| `adk-component-callout-panel` | component | `snapshot/component/callout-or-alert-panel` | product, trust, legal, changelog | alarmist styling, decorative status colors | Use for bounded explanation, not urgency theater. |
+
+## Demo-Content Flag Vocabulary
+
+- `demo stats`: invented counters, fake KPIs, or unsourced numerical proof.
+- `generic customer proof`: logo clouds, testimonials, and case-study language without approved source material.
+- `newsletter CTA`: sign-up or nurture patterns that are not part of the current IA.
+- `pricing teaser`: navigation or CTA pressure toward pricing or packaging pages that are not live.
+- `compliance theater`: seals, badges, or guarantee language that overstates trust posture.
+
+## Inventory Conclusion
+
+The alias set above is sufficient to drive the per-spec mapping sheets without creating net-new primitive families up front. Where the imported snapshot later disproves one of these families, the mismatch must reopen the intake review and the exception workflow before implementation continues.

specs/223-astrodeck-website-rebuild/astrodeck-source-intake.md

@@ -0,0 +1,48 @@
+# AstroDeck Source Intake
+
+Spec 223 assumes AstroDeck is an external template source, not an already-imported repository subtree. This intake record fixes the review assumptions that must hold before primitive mapping starts.
+
+## Intake Record
+
+| Field | Value |
+| --- | --- |
+| sourceSnapshotReference | Pending external AstroDeck distribution archive to be mounted into the local implementation workspace before the first rebuild slice starts |
+| planningAliasPrefix | `adk-` |
+| reviewStatus | planning assumptions only; no committed AstroDeck source is present in this repository as of 2026-04-22 |
+| notes | All primitive IDs in this feature are stable intake aliases. Once the snapshot is mounted, the implementation owner must bind each alias to the real AstroDeck file or component name before copying code. |
+
+## Intake Constraints
+
+- Treat AstroDeck as the only forward substrate for `apps/website`; the current custom Astro site remains historical comparison material only.
+- Do not let AstroDeck demo routes, placeholder sections, generic testimonials, pricing promos, or newsletter capture define the public IA by default.
+- Do not copy vendor demo copy, customer logos, invented metrics, or compliance theater into TenantAtlas surfaces.
+- Keep the repo-level website working contract intact: `@tenantatlas/website`, `WEBSITE_PORT`, `corepack pnpm dev:website`, and `corepack pnpm build:website` remain unchanged.
+- Keep all rebuild governance local to `apps/website`; no platform, Filament, or cross-app obligations may leak out of the template intake.
+- If the imported snapshot lacks an adequate page, section, or component family, route the gap through `exception-register.md` before inventing a custom primitive.
+
+## Review Assumptions
+
+- The chosen AstroDeck distribution will provide at least one marketing home page, one product/features page, one contact/conversion page, one blog/news/content index, one generic legal/company utility page, and shared header/footer shells.
+- The distribution will also provide hero, feature-grid, CTA, proof, and form sections plus button, badge, card, input, textarea, and navigation primitives.
+- Trust, changelog, and imprint will likely require adaptation of generic proof, blog/news, and legal/company primitives instead of direct one-to-one template pages.
+- Any AstroDeck page family that tries to push pricing, docs, resources, or social proof into primary navigation remains non-authoritative until an active website spec explicitly promotes it.
+- The mapping sheets may use intake aliases even before the real snapshot is committed, but the first implementation slice must resolve each alias against the mounted source before code transfer starts.
+- No compatibility shim is needed for the retired custom site. LEAN-001 applies: replace the old substrate rather than hybridizing it.
+
+## Review Boundaries
+
+- Current-site route truth comes from `current-website-inventory.md`, not from the AstroDeck template.
+- Governing spec truth comes from Specs 213, 214, 215, 217, and 218 plus their Spec 223 rebuild notes, not from template defaults.
+- Material route, navigation, CTA, or trust drift introduced by AstroDeck must be recorded in `material-drift-follow-up.md`.
+- The exception path remains closed unless the adequacy rubric in `exception-register.md` explicitly says the available AstroDeck primitives cannot satisfy the active requirement through bounded adaptation.
+
+## Forward Substrate Decision
+
+The forward substrate for new website work is therefore:
+
+1. Mounted AstroDeck snapshot
+2. Spec 223 intake aliases and primitive inventory
+3. Per-spec mapping sheets
+4. Exception review only if mapping fails
+
+The current `apps/website` codebase is still required for comparison, smoke-baseline review, and copy extraction, but it is not a valid starting point for new implementation work.

specs/223-astrodeck-website-rebuild/checklists/requirements.md

@@ -0,0 +1,36 @@
+# Specification Quality Checklist: Website Reset and AstroDeck Rebuild
+
+**Purpose**: Validate specification completeness and quality before proceeding to planning  
+**Created**: 2026-04-22  
+**Feature**: [spec.md](../spec.md)
+
+## Content Quality
+
+- [x] No implementation details (languages, frameworks, APIs)
+- [x] Focused on user value and business needs
+- [x] Written for non-technical stakeholders
+- [x] All mandatory sections completed
+
+## Requirement Completeness
+
+- [x] No [NEEDS CLARIFICATION] markers remain
+- [x] Requirements are testable and unambiguous
+- [x] Success criteria are measurable
+- [x] Success criteria are technology-agnostic (no implementation details)
+- [x] All acceptance scenarios are defined
+- [x] Edge cases are identified
+- [x] Scope is clearly bounded
+- [x] Dependencies and assumptions identified
+
+## Feature Readiness
+
+- [x] All functional requirements have clear acceptance criteria
+- [x] User scenarios cover primary flows
+- [x] Feature meets measurable outcomes defined in Success Criteria
+- [x] No implementation details leak into specification
+
+## Notes
+
+- Validation round 1 passed.
+- The spec stays local to `apps/website` and defines no runtime or platform obligations.
+- Existing website spec references were aligned to the current repository set: Specs 213, 214, 215, 217, and 218.

specs/223-astrodeck-website-rebuild/contracts/rebuild-planning-artifacts.yaml

@@ -0,0 +1,345 @@
+version: 1
+feature: 223-astrodeck-website-rebuild
+description: File-based contract for the planning artifacts required by the AstroDeck rebuild workflow.
+
+artifacts:
+  astroDeckSourceIntake:
+    description: Reviewable source-intake record for the AstroDeck snapshot being evaluated before primitive mapping begins.
+    type: object
+    required:
+      - sourceSnapshotReference
+      - intakeConstraints
+      - reviewAssumptions
+    properties:
+      sourceSnapshotReference:
+        type: string
+      intakeConstraints:
+        type: array
+        items:
+          type: string
+      reviewAssumptions:
+        type: array
+        items:
+          type: string
+
+  currentWebsiteInventory:
+    description: Current `apps/website` surface inventory captured before any AstroDeck replacement work starts.
+    type: object
+    required:
+      - surfaces
+    properties:
+      surfaces:
+        type: array
+        items:
+          type: object
+          required:
+            - route
+            - sourceFile
+            - surfaceRole
+            - governingSpecs
+            - plannedDisposition
+          properties:
+            route:
+              type: string
+            sourceFile:
+              type: string
+            surfaceRole:
+              type: string
+            governingSpecs:
+              type: array
+              items:
+                type: integer
+            currentDependencies:
+              type: array
+              items:
+                type: string
+            plannedDisposition:
+              type: string
+              enum: [keep, adapt, remove, redirect]
+
+  astroDeckPrimitiveInventory:
+    description: Inventory of candidate AstroDeck pages, sections, and components.
+    type: object
+    required:
+      - primitives
+    properties:
+      primitives:
+        type: array
+        items:
+          type: object
+          required:
+            - primitiveId
+            - primitiveType
+            - sourceReference
+          properties:
+            primitiveId:
+              type: string
+            primitiveType:
+              type: string
+              enum: [page, section, component]
+            sourceReference:
+              type: string
+            candidateSurfaces:
+              type: array
+              items:
+                type: string
+            demoContentFlags:
+              type: array
+              items:
+                type: string
+            notes:
+              type: string
+
+  governingSpecClassification:
+    description: Classification of the active website spec set before rebuild implementation starts.
+    type: object
+    required:
+      - specs
+    properties:
+      specs:
+        type: array
+        items:
+          type: object
+          required:
+            - specId
+            - title
+            - classification
+            - scopeSummary
+            - rationale
+            - followUpPlan
+          properties:
+            specId:
+              type: integer
+            title:
+              type: string
+            classification:
+              type: string
+              enum: [continuing, "partially valid", superseded]
+            scopeSummary:
+              type: string
+            rationale:
+              type: string
+            followUpPlan:
+              description: Path to the per-spec mapping artifact or explicit supersession-closure artifact that owns current-slice delivery for this spec.
+              type: string
+
+  primitiveMapping:
+    description: Mapping of one governing website spec requirement to one AstroDeck primitive, including the replacement task ownership embedded in the same per-spec artifact.
+    type: object
+    required:
+      - mappings
+    properties:
+      mappings:
+        type: array
+        items:
+          type: object
+          required:
+            - specId
+            - requirementReference
+            - disposition
+            - acceptanceMapping
+            - replacementTasks
+          properties:
+            specId:
+              type: integer
+            requirementReference:
+              type: string
+            primitiveId:
+              description: Required when disposition is keep, adapt, or remove; omitted when disposition is exception.
+              type: string
+            disposition:
+              type: string
+              enum: [keep, adapt, remove, exception]
+            adaptationSummary:
+              type: string
+            acceptanceMapping:
+              type: string
+            replacementTasks:
+              description: Ordered replacement task list owned by the same per-spec mapping or disposition artifact.
+              type: array
+              items:
+                type: string
+            taskPrimitiveReferences:
+              description: Named AstroDeck pages, sections, components, or explicit mapping activities referenced by the replacement task list.
+              type: array
+              items:
+                type: string
+            materialDriftReferences:
+              type: array
+              items:
+                type: string
+            exceptionReference:
+              type: string
+          oneOf:
+            - properties:
+                disposition:
+                  enum: [keep, adapt, remove]
+              required:
+                - primitiveId
+            - properties:
+                disposition:
+                  enum: [exception]
+              required:
+                - exceptionReference
+
+  supersessionClosure:
+    description: Explicit closure artifact for an in-scope website spec that ends the rebuild review as superseded instead of continuing into a mapping-based plan.
+    type: object
+    required:
+      - specId
+      - classification
+      - closureRationale
+      - legacyTaskDispositionReference
+      - replacementReference
+    properties:
+      specId:
+        type: integer
+      classification:
+        type: string
+        enum: [superseded]
+      closureRationale:
+        type: string
+      legacyTaskDispositionReference:
+        type: string
+      replacementReference:
+        description: Replacement plan reference or an explicit `no replacement work required` statement.
+        type: string
+      notes:
+        type: string
+
+  legacyTaskDisposition:
+    description: Historical task record preserved while being superseded by the rebuild.
+    type: object
+    required:
+      - dispositions
+    properties:
+      dispositions:
+        type: array
+        items:
+          type: object
+          required:
+            - originalSpecId
+            - originalTaskReference
+            - disposition
+            - replacementReference
+          properties:
+            originalSpecId:
+              type: integer
+            originalTaskReference:
+              type: string
+            disposition:
+              type: string
+              enum: ["superseded by AstroDeck rebuild"]
+            replacementReference:
+              description: New plan, task set, or an explicit `no replacement work required` statement.
+              type: string
+            notes:
+              type: string
+
+  materialDriftFollowUp:
+    description: Explicit spec-update follow-up record for material page inventory, CTA logic, navigation, or trust messaging drift discovered during mapping.
+    type: object
+    required:
+      - driftRecords
+    properties:
+      driftRecords:
+        type: array
+        items:
+          type: object
+          required:
+            - affectedSpecId
+            - driftClass
+            - driftSummary
+            - requiredSpecAction
+            - targetSpecReference
+          properties:
+            affectedSpecId:
+              type: integer
+            driftClass:
+              type: string
+              enum: ["page inventory", "CTA logic", navigation, "trust messaging"]
+            driftSummary:
+              type: string
+            requiredSpecAction:
+              type: string
+              enum: ["update existing spec", "create follow-up spec"]
+            targetSpecReference:
+              type: string
+            notes:
+              type: string
+
+  exceptionRegister:
+    description: Standing review register for missing-candidate checks, including approved exceptions and explicit no-exception outcomes.
+    type: object
+    required:
+      - entries
+    properties:
+      entries:
+        type: array
+        items:
+          type: object
+          required:
+            - specId
+            - scope
+            - reviewOutcome
+            - reviewRationale
+          properties:
+            specId:
+              type: integer
+            scope:
+              type: string
+            reviewOutcome:
+              type: string
+              enum: ["approved exception", "no exception required"]
+            reviewRationale:
+              type: string
+            exceptionReference:
+              type: string
+            notes:
+              type: string
+          oneOf:
+            - properties:
+                reviewOutcome:
+                  enum: ["approved exception"]
+              required:
+                - exceptionReference
+            - properties:
+                reviewOutcome:
+                  enum: ["no exception required"]
+
+  documentedException:
+    description: Approved exception record for custom work when no adequate AstroDeck primitive exists, stored inside the exception register when reviewOutcome is `approved exception`.
+    type: object
+    required:
+      - exceptions
+    properties:
+      exceptions:
+        type: array
+        items:
+          type: object
+          required:
+            - scope
+            - missingCandidate
+            - unmetRequirement
+            - adequacyFailureReason
+            - boundedDeviation
+            - approvedBy
+            - approvalReference
+            - spreadControl
+          properties:
+            scope:
+              type: string
+            missingCandidate:
+              type: string
+            unmetRequirement:
+              type: string
+            adequacyFailureReason:
+              type: string
+            boundedDeviation:
+              type: string
+            approvedBy:
+              type: string
+            approvalReference:
+              type: string
+            spreadControl:
+              type: string

specs/223-astrodeck-website-rebuild/current-website-inventory.md

@@ -0,0 +1,59 @@
+# Current Website Inventory
+
+This document captures the current `apps/website` implementation as retired implementation history. It remains reviewable context for Spec 223, but it is not the forward substrate for new website work.
+
+## Legacy Substrate Record
+
+| Field | Value |
+| --- | --- |
+| scopePath | `apps/website` |
+| status | discarded implementation history |
+| replacedBySpec | `223-astrodeck-website-rebuild` |
+| notes | The current Astro 6 site remains useful for route, copy, and smoke-test baseline review, but future delivery must start from the AstroDeck intake aliases documented in this feature. |
+
+## Current Route Baseline
+
+| Route | Source file | Surface role | Governing specs | Current dependencies | Planned disposition | Notes |
+| --- | --- | --- | --- | --- | --- | --- |
+| `/` | `apps/website/src/pages/index.astro` | entry and homepage routing hub | 213, 214, 215, 217, 218 | `src/content/pages/home.ts`; `PageHero`; `OutcomeSection`; `CapabilityGrid`; `TrustGrid`; `ProgressTeaser`; `home-product.spec.ts`; `visual-foundation-guardrails.spec.ts` | adapt | Keep the route, but replace the custom section assembly with an AstroDeck home page shell plus mapped sections. |
+| `/product` | `apps/website/src/pages/product.astro` | core product model surface | 213, 214, 215 | `src/content/pages/product.ts`; `PageHero`; `FeatureGrid`; `Callout`; `home-product.spec.ts` | adapt | Product explanation remains required, but the current page composition is historical. |
+| `/trust` | `apps/website/src/pages/trust.astro` | canonical trust surface | 214, 215 | `src/content/pages/trust.ts`; `PageHero`; `TrustGrid`; `Callout`; `solutions-trust-integrations.spec.ts`; `visual-foundation-guardrails.spec.ts` | adapt | Retain the canonical route and re-map it onto AstroDeck proof/trust primitives. |
+| `/changelog` | `apps/website/src/pages/changelog.astro` | dated public progress surface | 215 | `src/content/pages/changelog.ts`; `src/content/changelog`; `PageHero`; `Card`; `changelog-core-ia.spec.ts` | adapt | Preserve the route and dated update behavior by adapting an AstroDeck content/news index. |
+| `/contact` | `apps/website/src/pages/contact.astro` | primary conversion route | 213, 215 | `src/content/pages/contact.ts`; `ContactPanel`; `DemoPrompt`; `Input`; `Textarea`; `contact-legal.spec.ts` | adapt | Keep the route and working-session framing, but move the shell to AstroDeck contact primitives. |
+| `/privacy` | `apps/website/src/pages/privacy.astro` | required legal surface | 213, 215 | `src/content/pages/privacy.ts`; `RichText`; `PageHero`; `contact-legal.spec.ts` | adapt | Preserve the route and legal intent; repurpose a generic AstroDeck legal shell. |
+| `/imprint` | `apps/website/src/pages/imprint.astro` | canonical legal notice surface | 215 | `src/content/pages/imprint.ts`; `RichText`; `PageHero`; `contact-legal.spec.ts` | adapt | Keep the canonical route even if the AstroDeck snapshot only ships a generic legal/company page. |
+| `/legal` | `apps/website/src/pages/legal.astro` | retained secondary legal hub | 213, 215 | `src/content/pages/legal.ts`; `RichText`; `Card`; `contact-legal.spec.ts` | adapt | Remains published as a secondary surface, not a primary-nav destination. |
+| `/terms` | `apps/website/src/pages/terms.astro` | retained secondary legal surface | 213, 215 | `src/content/pages/terms.ts`; `RichText`; `PageHero`; `contact-legal.spec.ts` | adapt | Keep the route, but align it with the AstroDeck legal utility shell. |
+| `/solutions` | `apps/website/src/pages/solutions.astro` | retained secondary audience-fit surface | 213, 215 | `src/content/pages/solutions.ts`; `AudienceRow`; `FeatureGrid`; `solutions-trust-integrations.spec.ts` | adapt | Keep available as a secondary surface if the mapped AstroDeck page remains substantive. |
+| `/integrations` | `apps/website/src/pages/integrations.astro` | retained secondary ecosystem-fit surface | 213, 215 | `src/content/pages/integrations.ts`; `IntegrationBadge`; `FeatureGrid`; `solutions-trust-integrations.spec.ts` | adapt | Keep available as a secondary surface if the mapped AstroDeck content stays grounded in real integrations. |
+| `/security-trust` | `apps/website/src/pages/security-trust.astro` | compatibility alias | 213, 215 | redirect only; `solutions-trust-integrations.spec.ts` | redirect | Preserve only as a compatibility redirect to `/trust`; do not rebuild as an independent AstroDeck page. |
+
+## Component-Family Baseline
+
+| Family | Current files | Current role | Forward candidate |
+| --- | --- | --- | --- |
+| layout | `Navbar`, `Footer`, `PageShell` | current shell, navigation, footer grouping | adapt via AstroDeck header/footer/page-shell primitives |
+| primitives | `Badge`, `Button`, `Card`, `Cluster`, `Container`, `Grid`, `Input`, `Section`, `SectionHeader`, `Stack`, `Textarea` | local semantic building blocks | adapt or replace with AstroDeck component families re-skinned to Spec 214 |
+| sections | `PageHero`, `CTASection`, `CapabilityGrid`, `FeatureGrid`, `OutcomeSection`, `ProgressTeaser`, `TrustGrid` | primary public-page assembly surfaces | adapt from AstroDeck hero, feature-grid, trust, changelog-teaser, and CTA-band sections |
+| optional sections | `LogoStrip`, `HeroDashboard` | proof and product-near visual helpers in the current site | remove generic proof/demo variants unless the imported AstroDeck assets carry real, approved proof material |
+| content primitives | `AudienceRow`, `Callout`, `ContactPanel`, `DemoPrompt`, `Eyebrow`, `FeatureItem`, `Headline`, `IntegrationBadge`, `Lead`, `Metric`, `PrimaryCTA`, `RichText`, `SecondaryCTA`, `TrustPrincipleCard` | current page-level copy and CTA helpers | selectively adapt only where the AstroDeck intake does not already provide the same semantic role |
+
+## Content and Support Baseline
+
+- Route-local content modules live under `apps/website/src/content/pages` and currently define the published copy contract for all 12 public routes.
+- Astro content collections currently expose one published `changelog` entry, keep `resources` unpublished by gating, and keep `articles` unpublished entirely.
+- `apps/website/src/pages/sitemap.xml.ts` is a support artifact for discoverability proof, not a public planning surface to rebuild directly.
+
+## Smoke-Suite Baseline
+
+| Smoke file | Current proof focus |
+| --- | --- |
+| `apps/website/tests/smoke/home-product.spec.ts` | homepage clarity, hero semantics, grouped capability model, trust/progress ordering, route reachability, and product-page narrative integrity |
+| `apps/website/tests/smoke/solutions-trust-integrations.spec.ts` | secondary audience-fit surface, canonical trust posture, legacy trust redirect, and integrations-page credibility |
+| `apps/website/tests/smoke/changelog-core-ia.spec.ts` | dated changelog proof plus optional/deferred-surface suppression |
+| `apps/website/tests/smoke/contact-legal.spec.ts` | contact-path qualification, legal discoverability, footer links, and mobile navigation |
+| `apps/website/tests/smoke/visual-foundation-guardrails.spec.ts` | shared CTA, badge, surface, and input semantics across representative pages |
+
+## Baseline Conclusion
+
+The current site already encodes the canonical route family that Specs 214, 215, 217, and 218 expect. Spec 223 keeps that truth visible, but treats the underlying page assembly, component family, and section composition as retired implementation that must be reintroduced through AstroDeck mapping instead of copied forward.

specs/223-astrodeck-website-rebuild/data-model.md

@@ -0,0 +1,178 @@
+# Data Model: Website Reset and AstroDeck Rebuild
+
+This feature does not introduce runtime persistence. The entities below define the planning artifacts that must exist for the rebuild workflow to remain reviewable and deterministic.
+
+## Entity: LegacyWebsiteImplementation
+
+- **Purpose**: Represents the current `apps/website` codebase as the retired implementation substrate.
+- **Fields**:
+  - `scopePath`: repository path being retired, currently `apps/website`
+  - `status`: discarded implementation history
+  - `replacedBySpec`: spec reference that formally retires it, `223-astrodeck-website-rebuild`
+  - `notes`: short rationale for why it is no longer the active base
+- **Relationships**:
+  - One `LegacyWebsiteImplementation` has many `LegacyTaskDisposition` records.
+
+## Entity: CurrentWebsiteSurface
+
+- **Purpose**: Captures the existing public routes and current website surfaces that must be reconciled during rebuild planning.
+- **Fields**:
+  - `route`: public route, such as `/`, `/product`, `/trust`, `/contact`, `/legal`
+  - `sourceFile`: current Astro page file
+  - `surfaceRole`: current role in the website IA, such as core, secondary, legal, redirect, or optional
+  - `governingSpecs`: list of active website specs that currently constrain the surface
+  - `currentDependencies`: content collections, layout primitives, tests, or redirects tied to the surface
+  - `plannedDisposition`: keep, adapt, remove, or redirect
+- **Relationships**:
+  - A `CurrentWebsiteSurface` may map to one or more `AstroDeckPrimitive` candidates through `PrimitiveMapping`.
+
+## Entity: AstroDeckSourceIntake
+
+- **Purpose**: Captures the reviewable AstroDeck source snapshot, intake constraints, and working assumptions before primitive mapping begins.
+- **Fields**:
+  - `sourceSnapshotReference`: path, tag, archive name, or other stable reference for the imported AstroDeck source
+  - `intakeConstraints`: list of intake limitations, licensing boundaries, or review constraints
+  - `reviewAssumptions`: explicit assumptions used while building the primitive inventory and mappings
+  - `notes`: traceability details for reviewers
+- **Relationships**:
+  - One `AstroDeckSourceIntake` may inform many `AstroDeckPrimitive` records.
+
+## Entity: GoverningWebsiteSpec
+
+- **Purpose**: Tracks each existing website spec that must be classified before rebuild work continues.
+- **Fields**:
+  - `specId`: current spec number, initially one of 213, 214, 215, 217, 218
+  - `title`: short spec title
+  - `classification`: continuing, partially valid, or superseded
+  - `scopeSummary`: what part of the website the spec governs
+  - `followUpPlan`: reference to the per-spec mapping artifact or explicit supersession-closure artifact that owns current-slice delivery for this spec
+  - `rationale`: why the classification was chosen
+- **Relationships**:
+  - One `GoverningWebsiteSpec` has many `PrimitiveMapping` records.
+  - One `GoverningWebsiteSpec` has many `LegacyTaskDisposition` records.
+  - One `GoverningWebsiteSpec` may have one `SupersessionClosure` when rebuild planning ends with an explicit closure instead of a mapping plan.
+
+## Entity: SupersessionClosure
+
+- **Purpose**: Captures the explicit closure artifact used when an in-scope website spec is classified as superseded and therefore does not continue into a mapping-based rebuild plan.
+- **Fields**:
+  - `specId`: governing website spec being closed out
+  - `classification`: superseded
+  - `closureRationale`: why the spec no longer needs a rebuild mapping artifact
+  - `legacyTaskDispositionReference`: where the superseded legacy tasks were recorded
+  - `replacementReference`: replacement plan reference or explicit `no replacement work required` statement
+  - `notes`: traceability details for reviewers
+- **Relationships**:
+  - One `SupersessionClosure` belongs to one `GoverningWebsiteSpec`.
+
+## Entity: AstroDeckPrimitive
+
+- **Purpose**: Represents a candidate AstroDeck page, section, or component available for rebuild mapping.
+- **Fields**:
+  - `primitiveId`: stable identifier inside the imported AstroDeck inventory
+  - `primitiveType`: page, section, or component
+  - `sourceReference`: where the primitive came from inside the AstroDeck source snapshot
+  - `candidateSurfaces`: current routes or spec requirements it may satisfy
+  - `demoContentFlags`: whether it carries demo copy, demo media, or demo CTA behavior that may require removal
+  - `notes`: freeform adaptation concerns
+- **Relationships**:
+  - One `AstroDeckPrimitive` may be referenced by many `PrimitiveMapping` records.
+
+## Entity: PrimitiveMapping
+
+- **Purpose**: Records how a governing website spec requirement maps to one AstroDeck primitive or falls through to a documented missing-candidate exception path, including the replacement task ownership captured inside the same per-spec artifact.
+- **Fields**:
+  - `specId`: owning website spec
+  - `requirementReference`: spec requirement, acceptance point, or surface requirement being mapped
+  - `primitiveId`: referenced AstroDeck primitive when a concrete candidate exists; omitted when the disposition is `exception`
+  - `disposition`: keep, adapt, remove, or exception
+  - `adaptationSummary`: required changes to route, structure, styling, copy slots, or CTA behavior
+  - `acceptanceMapping`: how the mapped primitive satisfies the spec once adapted
+  - `replacementTasks`: ordered replacement task list owned by the same per-spec mapping or disposition artifact
+  - `taskPrimitiveReferences`: named AstroDeck pages, sections, components, or explicit mapping activities referenced by the replacement task list
+  - `materialDriftReferences`: references to updated or follow-up website specs required when AstroDeck adoption changes page inventory, CTA logic, navigation, or trust messaging
+  - `exceptionReference`: linked `DocumentedException` record when the disposition is `exception`
+- **Relationships**:
+  - Many `PrimitiveMapping` records belong to one `GoverningWebsiteSpec`.
+  - Many `PrimitiveMapping` records may target one `AstroDeckPrimitive`.
+  - One `PrimitiveMapping` may have zero or one `DocumentedException`.
+
+## Entity: ExceptionRegisterEntry
+
+- **Purpose**: Captures the review outcome for each missing-candidate check so the rebuild keeps a standing register of approved exceptions and explicit no-exception outcomes.
+- **Fields**:
+  - `specId`: governing website spec under review
+  - `scope`: page, section, component, or route slice being checked
+  - `reviewOutcome`: approved exception or no exception required
+  - `reviewRationale`: why the review produced that outcome
+  - `exceptionReference`: linked `DocumentedException` when the outcome is approved exception
+  - `notes`: traceability details for reviewers
+- **Relationships**:
+  - Many `ExceptionRegisterEntry` records belong to one `GoverningWebsiteSpec`.
+  - One `ExceptionRegisterEntry` may reference zero or one `DocumentedException`.
+
+## Entity: MaterialDriftFollowUp
+
+- **Purpose**: Captures any material page inventory, CTA logic, navigation, or trust messaging change discovered during mapping so it becomes an explicit spec update instead of silent template drift.
+- **Fields**:
+  - `affectedSpecId`: governing website spec whose truth must be updated or followed up
+  - `driftClass`: page inventory, CTA logic, navigation, or trust messaging
+  - `driftSummary`: concise description of what changed materially
+  - `requiredSpecAction`: update existing spec or create follow-up spec
+  - `targetSpecReference`: path to the existing spec or named follow-up spec that owns the change
+  - `notes`: rationale and traceability details
+- **Relationships**:
+  - Many `MaterialDriftFollowUp` records may belong to one `GoverningWebsiteSpec`.
+
+## Entity: LegacyTaskDisposition
+
+- **Purpose**: Preserves old website implementation task history while marking it as no longer authoritative.
+- **Fields**:
+  - `originalSpecId`: spec that owned the original task
+  - `originalTaskReference`: stable task identifier or short description
+  - `disposition`: `superseded by AstroDeck rebuild`
+  - `replacementReference`: new plan, spec, or task set that replaces the old task
+  - `notes`: why the original task cannot simply be reopened
+- **Relationships**:
+  - Many `LegacyTaskDisposition` records belong to one `LegacyWebsiteImplementation`.
+  - Many `LegacyTaskDisposition` records may be associated with one `GoverningWebsiteSpec`.
+
+## Entity: DocumentedException
+
+- **Purpose**: Captures the narrow approved cases where no adequate AstroDeck primitive exists and custom work is justified, stored as the approved-exception detail inside the exception register.
+- **Fields**:
+  - `scope`: page, section, component, or route slice that needs an exception
+  - `missingCandidate`: statement of which AstroDeck search failed
+  - `unmetRequirement`: the active website-spec requirement that could not be satisfied
+  - `adequacyFailureReason`: why keep or bounded adaptation could not satisfy the requirement
+  - `boundedDeviation`: precise custom work being allowed
+  - `approvedBy`: named website reviewer, owner, or equivalent feature approver
+  - `approvalReference`: spec, review note, or task entry that owns the exception
+  - `spreadControl`: explicit statement of why the exception stays local
+- **Relationships**:
+  - One `DocumentedException` belongs to one `PrimitiveMapping`.
+  - One `DocumentedException` is represented by one approved `ExceptionRegisterEntry`.
+
+## Validation Rules
+
+- Every continuing or partially valid `GoverningWebsiteSpec` must have at least one `PrimitiveMapping` before implementation starts.
+- Every `CurrentWebsiteSurface` must end the planning phase with an explicit disposition.
+- Every `LegacyTaskDisposition` must point to a replacement reference or explicitly state that no replacement work is required.
+- Every `DocumentedException` must name the failed AstroDeck candidate search, the unmet requirement, the adequacy failure reason, the bounded deviation, and the named approver.
+- Every material page inventory, CTA logic, navigation, or trust messaging change discovered during mapping must create a `MaterialDriftFollowUp` record that points to an updated or follow-up website spec.
+- Every missing-candidate review must create an `ExceptionRegisterEntry` with outcome `approved exception` or `no exception required`.
+- Every replacement task list must name the relevant AstroDeck page, section, component, or mapping activity instead of using generic build wording.
+- No `PrimitiveMapping` may use `exception` as its disposition without a linked `ExceptionRegisterEntry` and `DocumentedException`.
+
+## State Transitions
+
+- `GoverningWebsiteSpec.classification`: `unreviewed -> continuing | partially valid | superseded`
+- `CurrentWebsiteSurface.plannedDisposition`: `discovered -> keep | adapt | remove | redirect`
+- `PrimitiveMapping.disposition`: `candidate -> keep | adapt | remove | exception`
+- `ExceptionRegisterEntry.reviewOutcome`: `reviewed -> approved exception | no exception required`
+- `DocumentedException`: `gap identified -> approved exception record`
+- `LegacyTaskDisposition.disposition`: `historical -> superseded by AstroDeck rebuild`
+
+## Notes
+
+- These entities are planning artifacts only. They do not imply new database tables, application models, or runtime services.

specs/223-astrodeck-website-rebuild/exception-register.md

@@ -0,0 +1,56 @@
+# Exception Register
+
+This register defines the only allowed path for non-AstroDeck primitives. Until an entry is approved here, custom rebuild work is out of bounds.
+
+## Workflow
+
+1. Search the AstroDeck alias inventory before proposing any custom page, section, or component.
+2. Record the candidate aliases reviewed and explain why keep or bounded adaptation is or is not sufficient.
+3. If one or more aliases can satisfy the need without inventing a new IA contract or unsupported interaction model, record `no exception required`.
+4. If all viable aliases fail, record the unmet requirement, the failed candidate search, the bounded deviation, the named approver, and the owning follow-up task.
+5. Keep every approved exception local to one page, section, or component slice. Do not generalize it into a new default primitive family.
+
+## Adequacy Rubric
+
+Use `no exception required` when the AstroDeck candidate family can satisfy the active requirement through bounded adaptation across all of the checks below:
+
+- It preserves the active route and IA contract from Specs 213, 215, 217, or 218.
+- It preserves CTA hierarchy, trust-boundary rules, and mobile meaning order without adding a new interaction model.
+- It avoids shipping demo-only proof, fake logos, invented metrics, or placeholder legal/trust content.
+- It can be re-skinned to the Spec 214 foundation without introducing a second visual system.
+
+Use `approved exception` only when every candidate fails one or more of those checks and the failure cannot be resolved by bounded adaptation.
+
+## Required Evidence for Approved Exceptions
+
+- failed AstroDeck candidate search
+- unmet active-spec requirement
+- adequacy failure reason for each reviewed candidate
+- bounded deviation being approved
+- named website reviewer, owner, or equivalent feature approver
+- replacement task or mapping entry that owns the deviation
+- spread-control note explaining why the deviation does not create a new default
+
+## Approval Boundary
+
+- Minimum approver: named website reviewer or feature owner
+- Preferred approver for IA or trust changes: spec author or feature owner responsible for Specs 215, 217, or 218
+- Re-review trigger: if the mounted AstroDeck snapshot disproves the intake aliases currently recorded in `astrodeck-primitive-inventory.md`
+
+## Register Entries
+
+| specId | scope | reviewOutcome | reviewRationale | exceptionReference | notes |
+| --- | --- | --- | --- | --- | --- |
+| 213 | site-foundation shell, core routes, contact/legal baseline | no exception required | The alias set already covers landing, product, trust, contact, legal utility, header/footer, and CTA primitives. The main drift is route emphasis, not missing primitive families. | none | Spread control: route drift is handled by the Spec 213 mapping sheet and the drift ledger, not by inventing new primitives. |
+| 214 | visual foundation tokens, surfaces, CTA/input semantics | no exception required | AstroDeck page, section, and component families can be re-skinned to the website-local foundation without inventing a second design system. | none | Acceptance trace: all work must route through `mappings/spec-214-website-visual-foundation.md`. |
+| 215 | core IA, trust/changelog/contact/legal surfaces, retained secondary routes | no exception required | Generic home, product, proof, content-index, contact, and legal utility aliases are sufficient when demo routes are suppressed. | none | Spread control: any later missing route family must re-open this register before a custom page is approved. |
+| 217 | homepage section order, trust/progress placement, CTA transition | no exception required | Hero, outcome, feature-cluster, trust, changelog-teaser, and CTA-band aliases cover the homepage contract. | none | Acceptance trace: remove optional proof sections instead of replacing the homepage with a custom greenfield assembly. |
+| 218 | hero CTA pair, product-near media, bounded trust cues, mobile order | no exception required | The split hero family plus button and badge primitives are adequate once demo media and fake proof are stripped. | none | Spread control: a later hero exception would need to show why the split-media family cannot preserve the existing hero contract. |
+
+## Approved Exception Records
+
+None as of 2026-04-22.
+
+## Standing Rule
+
+No follow-up implementation slice may introduce a net-new page, section, or component by default. If the mounted AstroDeck snapshot later proves one of the alias families wrong, that mismatch must reopen this register before implementation continues.

specs/223-astrodeck-website-rebuild/governing-website-spec-classification.md

@@ -0,0 +1,41 @@
+# Governing Website Spec Classification
+
+This crosswalk classifies the in-scope website specs before AstroDeck implementation begins and records the follow-up owner for each one.
+
+## Classification Summary
+
+| specId | Title | Classification | scopeSummary | rationale | followUpPlan |
+| --- | --- | --- | --- | --- | --- |
+| 213 | Initial Website Foundation & v0 Product Site | partially valid | broad v0 public-site truth, shared shell expectations, contact/legal baseline, trust-first positioning | The broad public-site intent remains useful, but the original route inventory and trust-route naming no longer match the canonical IA recorded in later specs. | `specs/223-astrodeck-website-rebuild/mappings/spec-213-website-foundation-v0.md` |
+| 214 | Website Visual Foundation | continuing | website-only visual direction, tokens, typography, surfaces, CTA/input semantics | AstroDeck changes the implementation substrate, not the website-local visual contract. | `specs/223-astrodeck-website-rebuild/mappings/spec-214-website-visual-foundation.md` |
+| 215 | Website Information Architecture / Core Pages | continuing | canonical public IA, route priorities, trust/changelog/contact/legal reachability | The current route truth already reflects this spec and must constrain AstroDeck adoption. | `specs/223-astrodeck-website-rebuild/mappings/spec-215-website-core-pages.md` |
+| 217 | Website Homepage Structure & Section Model | continuing | homepage block order, trust/progress placement, CTA sequencing, onward routing | AstroDeck must adapt to the homepage contract instead of redefining it. | `specs/223-astrodeck-website-rebuild/mappings/spec-217-homepage-structure.md` |
+| 218 | Website Homepage Hero | continuing | homepage hero semantics, CTA pair, product-near visual truth, bounded trust cues | AstroDeck hero primitives are acceptable only when they preserve the existing hero contract. | `specs/223-astrodeck-website-rebuild/mappings/spec-218-homepage-hero.md` |
+
+## Current-Surface Crosswalk
+
+| Surface or concern | 213 | 214 | 215 | 217 | 218 | Forward owner |
+| --- | --- | --- | --- | --- | --- | --- |
+| `/` homepage route | X | X | X | X | X | `mappings/spec-217-homepage-structure.md` and `mappings/spec-218-homepage-hero.md`, with 214 and 215 as constraints |
+| `/product` | X | X | X |  |  | `mappings/spec-213-website-foundation-v0.md` and `mappings/spec-215-website-core-pages.md` |
+| `/trust` plus `/security-trust` compatibility | X | X | X | X | X | `mappings/spec-215-website-core-pages.md` and `mappings/spec-213-website-foundation-v0.md` |
+| `/changelog` |  |  | X | X |  | `mappings/spec-215-website-core-pages.md` |
+| `/contact` | X | X | X | X | X | `mappings/spec-213-website-foundation-v0.md` and `mappings/spec-215-website-core-pages.md` |
+| `/privacy`, `/imprint`, `/terms`, `/legal` | X | X | X |  |  | `mappings/spec-213-website-foundation-v0.md` and `mappings/spec-215-website-core-pages.md` |
+| `/solutions` and `/integrations` as retained secondary surfaces | X | X | X |  |  | `mappings/spec-215-website-core-pages.md` |
+| shared visual system, shells, CTA/input semantics | X | X | X | X | X | `mappings/spec-214-website-visual-foundation.md` |
+
+## Final Follow-up Execution Order
+
+1. AstroDeck intake binding and primitive verification using `astrodeck-source-intake.md` and `astrodeck-primitive-inventory.md`.
+2. Conditional foundation slice owned by `mappings/spec-213-website-foundation-v0.md`, because Spec 213 remains partially valid and still governs broad public-site truth.
+3. Shared visual-adaptation slice owned by `mappings/spec-214-website-visual-foundation.md`.
+4. Canonical IA and route-mapping slice owned by `mappings/spec-215-website-core-pages.md`.
+5. Homepage section-composition slice owned by `mappings/spec-217-homepage-structure.md`.
+6. Homepage hero-refinement slice owned by `mappings/spec-218-homepage-hero.md`.
+
+## Execution Notes
+
+- Steps 3 and 4 can overlap once the AstroDeck aliases are bound, but route ownership from Spec 215 must settle before any homepage-only AstroDeck assembly lands.
+- Steps 5 and 6 share homepage files and therefore stay sequential after the IA slice has fixed the canonical route shell.
+- Any imported AstroDeck demo page that tries to introduce new top-level IA must be handled as removal or suppression work in the owning mapping sheet, not as silent scope growth.

specs/223-astrodeck-website-rebuild/legacy-task-disposition.md

@@ -0,0 +1,27 @@
+# Legacy Task Disposition
+
+The task files below remain visible as historical execution records, but they are no longer the forward implementation source for `apps/website`.
+
+## Historical Marker
+
+Every affected legacy task file now carries the canonical marker:
+
+`superseded by AstroDeck rebuild`
+
+That marker preserves the completed checkbox history while making it clear that new delivery belongs to the Spec 223 mapping artifacts instead of the old implementation plans.
+
+## Replacement References
+
+| originalSpecId | originalTaskReference | disposition | replacementReference | notes |
+| --- | --- | --- | --- | --- |
+| 213 | `specs/213-website-foundation-v0/tasks.md` (`T001-T033`) | superseded by AstroDeck rebuild | `specs/223-astrodeck-website-rebuild/mappings/spec-213-website-foundation-v0.md` | The original v0-site build shipped on the custom Astro substrate. Future work must restart from AstroDeck while preserving the public-site truth. |
+| 214 | `specs/214-website-visual-foundation/tasks.md` (`T001-T021`) | superseded by AstroDeck rebuild | `specs/223-astrodeck-website-rebuild/mappings/spec-214-website-visual-foundation.md` | The current website foundation remains valid as a design rule set, but its implementation record is historical. |
+| 215 | `specs/215-website-core-pages/tasks.md` (`T001-T022`) | superseded by AstroDeck rebuild | `specs/223-astrodeck-website-rebuild/mappings/spec-215-website-core-pages.md` | Route truth remains authoritative; the old implementation task list does not. |
+| 217 | `specs/217-homepage-structure/tasks.md` (`T001-T023`) | superseded by AstroDeck rebuild | `specs/223-astrodeck-website-rebuild/mappings/spec-217-homepage-structure.md` | Homepage structure truth stays active, but the existing section assembly is not the forward substrate. |
+| 218 | `specs/218-homepage-hero/tasks.md` (`T001-T016`) | superseded by AstroDeck rebuild | `specs/223-astrodeck-website-rebuild/mappings/spec-218-homepage-hero.md` | Hero semantics remain active; the existing hero implementation record is historical only. |
+
+## Interpretation Rule
+
+- Do not reset or reopen checkbox state in the legacy task files.
+- Do not continue delivery from the custom `apps/website` implementation plan.
+- Use the replacement mapping sheet for all forward task planning, acceptance tracing, and exception review.

specs/223-astrodeck-website-rebuild/mappings/spec-213-website-foundation-v0.md

@@ -0,0 +1,37 @@
+# Mapping: Spec 213 - Initial Website Foundation & v0 Product Site
+
+## Status
+
+| Field | Value |
+| --- | --- |
+| classification | partially valid |
+| follow-up owner | `specs/223-astrodeck-website-rebuild/mappings/spec-213-website-foundation-v0.md` |
+| legacy task file | `specs/213-website-foundation-v0/tasks.md` |
+| exception outcome | no exception required |
+| material drift references | `223-DRIFT-213-ia`, `223-DRIFT-213-nav`, `223-DRIFT-213-trust` |
+
+Spec 213 remains useful as the broad v0 public-site contract, but its original route emphasis predates the later canonical IA. This mapping sheet keeps the surviving truth while moving all implementation ownership onto AstroDeck.
+
+## Mapping Records
+
+| Requirement reference | Candidate primitive(s) | Disposition | Adaptation summary | Acceptance mapping | materialDriftReferences | exceptionReference |
+| --- | --- | --- | --- | --- | --- | --- |
+| Core public-site shell, header/footer reachability, and one coherent page family | `adk-component-header-nav`, `adk-component-footer-nav`, `adk-component-section-shell` | adapt | Collapse AstroDeck navigation to Product, Trust, Changelog, and Contact plus one primary CTA; preserve footer legal grouping; keep repo-level website contracts intact. | 213 FR-002, FR-003, FR-010, FR-011, FR-017 | `223-DRIFT-213-nav` | none |
+| First-pass product explanation across Home and Product | `adk-page-home-marketing`, `adk-page-product-overview`, `adk-section-outcome-band`, `adk-section-feature-cluster-grid` | adapt | Keep the trust-first governance story, but replace the current custom page assembly with AstroDeck landing and product shells. | 213 FR-001, FR-004, FR-005, FR-012, FR-016 | none | none |
+| Trust, contact, and legal baseline | `adk-page-trust-proof`, `adk-page-contact-conversion`, `adk-page-legal-utility`, `adk-section-trust-principles`, `adk-section-contact-form` | adapt | Route trust to `/trust`, preserve `/contact` as the primary next step, and repurpose legal/company utility pages for privacy, imprint, terms, and the retained legal hub. | 213 FR-007, FR-008, FR-009, FR-010 | `223-DRIFT-213-trust` | none |
+| Secondary pages and compatibility behavior | `adk-page-supporting-showcase`, `adk-page-content-index`, `adk-page-trust-proof` | adapt | Keep `/solutions`, `/integrations`, `/legal`, and `/terms` published as secondary surfaces; preserve `/security-trust` as a redirect only; add `/changelog` and `/imprint` through adapted content/legal shells. | 213 SC-002, SC-004, plus the Spec 223 rebuild rule for preserved history | `223-DRIFT-213-ia` | none |
+
+## Replacement Tasks
+
+1. Bind the AstroDeck aliases for the landing shell, product shell, trust proof page, contact page, and legal utility page before any code is copied out of the current `apps/website` implementation.
+2. Adapt `adk-component-header-nav` and `adk-component-footer-nav` to the canonical Product/Trust/Changelog/Contact navigation model with retained legal footer grouping.
+3. Map `adk-page-home-marketing` and `adk-page-product-overview` to the v0 product-story surfaces without carrying over AstroDeck demo proof, pricing, or newsletter behavior.
+4. Repurpose `adk-page-trust-proof`, `adk-page-contact-conversion`, and `adk-page-legal-utility` for `/trust`, `/contact`, `/privacy`, `/imprint`, `/terms`, and `/legal`.
+5. Add a route-suppression pass that removes AstroDeck demo pages from top-level discoverability and keeps `/security-trust` as a compatibility redirect only.
+6. Re-run the Spec 213 acceptance trace against the later canonical IA so the broad v0 truth remains visible without overriding Specs 214, 215, 217, and 218.
+
+## Spread Control and Acceptance Trace
+
+- Spread control: this mapping sheet does not authorize any new public IA beyond the canonical route family already documented in the current-site inventory and Spec 215.
+- Acceptance trace: broad v0-site requirements remain owned here, but route inventory, navigation, and trust-route naming defer to the later specs and the drift ledger.
+- Exception note: no exception is approved. If the mounted AstroDeck snapshot lacks a usable legal utility page or trust-proof page, the missing family must reopen `exception-register.md`.

specs/223-astrodeck-website-rebuild/mappings/spec-214-website-visual-foundation.md

@@ -0,0 +1,37 @@
+# Mapping: Spec 214 - Website Visual Foundation
+
+## Status
+
+| Field | Value |
+| --- | --- |
+| classification | continuing |
+| follow-up owner | `specs/223-astrodeck-website-rebuild/mappings/spec-214-website-visual-foundation.md` |
+| legacy task file | `specs/214-website-visual-foundation/tasks.md` |
+| exception outcome | no exception required |
+| material drift references | none |
+
+Spec 214 remains the controlling visual contract. AstroDeck may accelerate the rebuild, but it may not impose a second visual system or a generic startup aesthetic.
+
+## Mapping Records
+
+| Requirement reference | Candidate primitive(s) | Disposition | Adaptation summary | Acceptance mapping | materialDriftReferences | exceptionReference |
+| --- | --- | --- | --- | --- | --- | --- |
+| Color roles, surfaces, border-first clarity, and restrained elevation | `adk-component-section-shell`, `adk-component-card-surface`, `adk-component-badge-chip` | adapt | Map AstroDeck colors, borders, and surface layers to the website-local token model; strip decorative gradients, glass, and vanity shadows. | 214 FR-003, FR-004, FR-008, FR-009, FR-015 | none | none |
+| Typography hierarchy, page rhythm, and progressive disclosure | `adk-section-hero-split-media`, `adk-section-outcome-band`, `adk-section-feature-cluster-grid` | adapt | Rebuild heading scale, section spacing, and copy rhythm around the Spec 214 hierarchy instead of vendor defaults. | 214 FR-005, FR-006, FR-007, FR-013, FR-016 | none | none |
+| CTA, link, and form semantics | `adk-component-primary-button`, `adk-component-secondary-button`, `adk-component-input-field`, `adk-component-textarea-field` | adapt | Preserve one dominant CTA, lower-emphasis secondary actions, shared focus logic, and calm form styling. | 214 FR-010, FR-012, FR-015, FR-017 | none | none |
+| Shared shell and page-family consistency across landing, trust, and content routes | `adk-component-header-nav`, `adk-component-footer-nav`, `adk-section-footer-utility`, `adk-page-home-marketing`, `adk-page-trust-proof`, `adk-page-legal-utility` | adapt | Keep one website-only visual language across landing, trust/legal, and content-heavy surfaces; no platform coupling and no raw library styling. | 214 FR-001, FR-002, FR-011, FR-018, FR-019, FR-020 | none | none |
+
+## Replacement Tasks
+
+1. Inventory AstroDeck design tokens, utility classes, and section-shell defaults, then bind them to the Spec 214 role model before any page-level restyling starts.
+2. Adapt `adk-component-section-shell`, `adk-component-card-surface`, and `adk-component-badge-chip` to the website-local surface, border, radius, and contrast rules.
+3. Re-skin `adk-component-primary-button`, `adk-component-secondary-button`, `adk-component-input-field`, and `adk-component-textarea-field` to match the CTA and form semantics already defined by Spec 214.
+4. Rebuild AstroDeck header/footer typography, spacing, and nav emphasis so landing, trust, and content page families read as one website.
+5. Remove or neutralize AstroDeck visual defaults that drift into glass, loud gradients, decorative shadows, or badge-heavy proof theater.
+6. Re-verify the mapped primitives against representative landing, trust/legal, and content-heavy surfaces before homepage-specific work lands.
+
+## Spread Control and Acceptance Trace
+
+- Spread control: all styling work must route through the website-local token and primitive model; no raw AstroDeck styling is allowed to remain as a second standard.
+- Acceptance trace: the mapped primitives cover the required design token set, typography hierarchy, surface model, interaction semantics, and page-family review rules from Spec 214.
+- Exception note: no exception is approved. A later exception would need to prove that the mounted AstroDeck snapshot lacks a usable button, form, card, or shell family entirely.

specs/223-astrodeck-website-rebuild/mappings/spec-215-website-core-pages.md

@@ -0,0 +1,38 @@
+# Mapping: Spec 215 - Website Information Architecture / Core Pages
+
+## Status
+
+| Field | Value |
+| --- | --- |
+| classification | continuing |
+| follow-up owner | `specs/223-astrodeck-website-rebuild/mappings/spec-215-website-core-pages.md` |
+| legacy task file | `specs/215-website-core-pages/tasks.md` |
+| exception outcome | no exception required |
+| material drift references | none |
+
+Spec 215 is the canonical IA source of truth. AstroDeck may only be adopted in ways that preserve this route model, page priority, and navigation discipline.
+
+## Mapping Records
+
+| Requirement reference | Candidate primitive(s) | Disposition | Adaptation summary | Acceptance mapping | materialDriftReferences | exceptionReference |
+| --- | --- | --- | --- | --- | --- | --- |
+| Required core routes: `/`, `/product`, `/trust`, `/changelog`, `/contact`, `/privacy`, `/imprint` | `adk-page-home-marketing`, `adk-page-product-overview`, `adk-page-trust-proof`, `adk-page-content-index`, `adk-page-contact-conversion`, `adk-page-legal-utility` | adapt | Bind each canonical route to an AstroDeck page family without inheriting template route names or page priorities. | 215 FR-002, FR-003, FR-006, FR-008, FR-010, FR-012, FR-013 | none | none |
+| Small primary navigation plus trust/legal footer discoverability | `adk-component-header-nav`, `adk-component-footer-nav`, `adk-section-footer-utility` | adapt | Keep top-level navigation intentionally small and group footer trust/legal/contact links according to Spec 215. | 215 FR-014, FR-015, FR-017, FR-018, FR-019, FR-025 | none | none |
+| Optional and deferred surfaces | `adk-page-content-index`, `adk-page-supporting-showcase`, `adk-section-logo-strip`, `adk-section-testimonial-stack` | remove | Suppress template pricing, docs, case-study, resource-hub, logo-cloud, and testimonial promotion until an active spec turns them on. | 215 FR-004, FR-005, FR-016, FR-021, FR-022, FR-024 | none | none |
+| Retained secondary routes and compatibility behavior | `adk-page-supporting-showcase`, `adk-page-legal-utility`, `adk-page-trust-proof` | adapt | Keep `/legal`, `/terms`, `/solutions`, and `/integrations` published as secondary surfaces; preserve `/security-trust` as a redirect to `/trust`. | 215 FR-011, FR-020, FR-023, FR-027 | none | none |
+
+## Replacement Tasks
+
+1. Bind AstroDeck page aliases for home, product, trust/proof, content index, contact, and legal utility before route-level implementation starts.
+2. Adapt `adk-component-header-nav` so primary discoverability remains Product, Trust, Changelog, and Contact with one CTA only.
+3. Repurpose `adk-page-content-index` into `/changelog` and keep optional `Resources` or editorial surfaces unpublished unless substantive content exists.
+4. Adapt `adk-page-legal-utility` for `/privacy`, `/imprint`, `/terms`, and the retained `/legal` hub without shipping template legal copy.
+5. Keep `adk-page-supporting-showcase` available only for `/solutions` and `/integrations`, and do not let those routes displace the required core IA.
+6. Add an AstroDeck route-suppression pass for pricing, docs, case-study, resource, team, and newsletter surfaces that are not yet active.
+7. Preserve `/security-trust` as redirect-only behavior once `/trust` is mapped to the canonical proof page.
+
+## Spread Control and Acceptance Trace
+
+- Spread control: no AstroDeck route becomes publicly discoverable unless Spec 215 already classifies it as required, retained secondary, or approved optional.
+- Acceptance trace: the mapping above preserves the required core routes, the small top-level navigation, trust visibility, changelog visibility, and contact primacy.
+- Exception note: no exception is approved. A future exception would need to show that the mounted snapshot lacks a usable content-index or legal-utility family entirely.

specs/223-astrodeck-website-rebuild/mappings/spec-217-homepage-structure.md

@@ -0,0 +1,38 @@
+# Mapping: Spec 217 - Website Homepage Structure & Section Model
+
+## Status
+
+| Field | Value |
+| --- | --- |
+| classification | continuing |
+| follow-up owner | `specs/223-astrodeck-website-rebuild/mappings/spec-217-homepage-structure.md` |
+| legacy task file | `specs/217-homepage-structure/tasks.md` |
+| exception outcome | no exception required |
+| material drift references | none |
+
+Spec 217 remains the homepage structure contract. AstroDeck can supply section families, but it may not reorder the homepage into a generic feature wall or proof-heavy template.
+
+## Mapping Records
+
+| Requirement reference | Candidate primitive(s) | Disposition | Adaptation summary | Acceptance mapping | materialDriftReferences | exceptionReference |
+| --- | --- | --- | --- | --- | --- | --- |
+| Hero to outcome flow | `adk-section-hero-split-media`, `adk-section-outcome-band` | adapt | Keep the homepage order of hero first, outcome framing second, and route visitors into a product-near reading path immediately. | 217 FR-001, FR-002, FR-003, FR-004, FR-008 | none | none |
+| Grouped capability model instead of route-job cards | `adk-section-feature-cluster-grid` | adapt | Use grouped capability clusters that route deeper explanation to `/product` instead of equal-weight marketing cards. | 217 FR-009, FR-010 | none | none |
+| Trust and progress before the final CTA | `adk-section-trust-principles`, `adk-section-changelog-teaser`, `adk-section-cta-band` | adapt | Keep trust and visible product movement ahead of the closing CTA and route them to `/trust` and `/changelog`. | 217 FR-011, FR-012, FR-013, FR-014, FR-018 | none | none |
+| Optional proof sections that risk fake maturity | `adk-section-proof-stats`, `adk-section-logo-strip`, `adk-section-testimonial-stack` | remove | Remove by default unless the team has approved, real, public-safe proof material. | 217 FR-017, FR-020 | none | none |
+| Header/footer discoverability and mobile continuity | `adk-component-header-nav`, `adk-component-footer-nav`, `adk-section-footer-utility` | adapt | Preserve the published route set and keep the same meaning order on narrow screens. | 217 FR-005, FR-006, FR-015, FR-016, FR-019, FR-021 | none | none |
+
+## Replacement Tasks
+
+1. Adapt `adk-section-hero-split-media` into the homepage entry point without letting AstroDeck proof strips or testimonial blocks appear above the product explanation.
+2. Adapt `adk-section-outcome-band` so buyer-oriented outcomes appear before any capability cluster or proof section.
+3. Rebuild `adk-section-feature-cluster-grid` into grouped capability coverage that routes to `/product` instead of acting like a route list.
+4. Place `adk-section-trust-principles` and `adk-section-changelog-teaser` ahead of the closing `adk-section-cta-band`.
+5. Remove `adk-section-proof-stats`, `adk-section-logo-strip`, and `adk-section-testimonial-stack` unless real proof assets are explicitly approved later.
+6. Re-check the homepage route transitions, footer legal reachability, and mobile section order after the mapped sections are in place.
+
+## Spread Control and Acceptance Trace
+
+- Spread control: homepage-only structure work may not pull in extra AstroDeck sections simply because they are visually available.
+- Acceptance trace: the mapping preserves the required homepage block set, section order, trust/progress placement, and onward routing from Spec 217.
+- Exception note: no exception is approved. If the mounted snapshot lacks a usable outcome or changelog-teaser family, reopen the exception workflow before composing a net-new homepage section.

specs/223-astrodeck-website-rebuild/mappings/spec-218-homepage-hero.md

@@ -0,0 +1,38 @@
+# Mapping: Spec 218 - Website Homepage Hero
+
+## Status
+
+| Field | Value |
+| --- | --- |
+| classification | continuing |
+| follow-up owner | `specs/223-astrodeck-website-rebuild/mappings/spec-218-homepage-hero.md` |
+| legacy task file | `specs/218-homepage-hero/tasks.md` |
+| exception outcome | no exception required |
+| material drift references | none |
+
+Spec 218 keeps the hero contract narrow and semantic. AstroDeck may only be used as a hero substrate when it preserves one clear anchor, one CTA pair, product-near truth, and bounded trust cues.
+
+## Mapping Records
+
+| Requirement reference | Candidate primitive(s) | Disposition | Adaptation summary | Acceptance mapping | materialDriftReferences | exceptionReference |
+| --- | --- | --- | --- | --- | --- | --- |
+| Hero text core: category context, headline, supporting copy | `adk-section-hero-split-media` | adapt | Keep one clear product category cue, one headline, and one supporting-copy block; remove stacked marketing slogans and filler text. | 218 FR-001, FR-002, FR-005, FR-006, FR-007, FR-013, FR-014 | none | none |
+| One dominant primary CTA plus one lower-emphasis secondary CTA | `adk-component-primary-button`, `adk-component-secondary-button` | adapt | Preserve the Contact-first action with one deepening CTA and remove any additional equal-weight buttons. | 218 FR-008, FR-009, FR-016 | none | none |
+| Product-near visual truth | `adk-section-hero-split-media`, `adk-component-card-surface` | adapt | Replace generic analytics wallpaper with a governance-specific product visual or truthful placeholder tied to change history, review, restore, or drift. | 218 FR-010, FR-011, FR-015, FR-020 | none | none |
+| Optional bounded trust chips | `adk-component-badge-chip` | adapt | Reduce AstroDeck hero chips to a small set of factual, supportable trust cues. | 218 FR-012, FR-013 | none | none |
+| Anti-pattern removal and mobile meaning order | `adk-section-proof-stats`, `adk-section-logo-strip`, `adk-section-testimonial-stack`, `adk-section-hero-split-media` | remove | Remove badge walls, fake proof, and extra CTA pressure; preserve headline, copy, CTA, visual, and optional trust chips on mobile. | 218 FR-017, FR-018, FR-019, FR-022 | none | none |
+
+## Replacement Tasks
+
+1. Bind `adk-section-hero-split-media` to the homepage hero and reduce it to the allowed semantic structure before any art-direction pass starts.
+2. Adapt `adk-component-primary-button` and `adk-component-secondary-button` into the Contact-first CTA pair with no competing primary actions.
+3. Replace AstroDeck demo hero imagery with a governance-specific product visual or a truthful approximation derived from real product structure.
+4. Reduce `adk-component-badge-chip` usage to a small bounded trust-subclaim set that routes deeper context to `/trust`.
+5. Remove hero-adjacent proof stats, logo strips, testimonials, and extra CTA blocks that dilute the primary anchor.
+6. Verify the mapped hero preserves headline-first reading order, CTA visibility, and product-near proof on narrow screens before the homepage section pass is considered complete.
+
+## Spread Control and Acceptance Trace
+
+- Spread control: this sheet does not authorize a bespoke hero framework or a custom visual language separate from the Spec 214 foundation.
+- Acceptance trace: the mapping covers the required hero text core, CTA pair, product-near visual, bounded trust cues, mobile meaning order, and anti-pattern rejection from Spec 218.
+- Exception note: no exception is approved. A future exception would need to prove that the mounted AstroDeck hero family cannot preserve the current hero contract even after bounded adaptation.

specs/223-astrodeck-website-rebuild/material-drift-follow-up.md

@@ -0,0 +1,22 @@
+# Material Drift Follow-up
+
+Only material drift that changes page inventory, CTA logic, navigation, or trust messaging belongs here. As of 2026-04-22, drift is concentrated in Spec 213.
+
+## Drift Records
+
+| driftId | affectedSpecId | driftClass | driftSummary | requiredSpecAction | targetSpecReference | notes |
+| --- | --- | --- | --- | --- | --- | --- |
+| `223-DRIFT-213-ia` | 213 | page inventory | The canonical public IA now treats `/trust`, `/changelog`, and `/imprint` as required surfaces and demotes `/legal`, `/terms`, `/solutions`, and `/integrations` to retained secondary status. | update existing spec | `specs/213-website-foundation-v0/spec.md` | Spec 215 already carries the newer route truth; Spec 213 needs an explicit rebuild note so the mismatch is visible. |
+| `223-DRIFT-213-nav` | 213 | navigation | Top-level discoverability now centers on Product, Trust, Changelog, and Contact with one primary CTA instead of the broader route emphasis implied by the original v0 foundation. | update existing spec | `specs/213-website-foundation-v0/spec.md` | This keeps the public journey aligned with Spec 215 and the current website baseline. |
+| `223-DRIFT-213-trust` | 213 | trust messaging | The canonical trust surface is `/trust`, while `/security-trust` is now only a compatibility redirect and must not be rebuilt as a first-class page. | update existing spec | `specs/213-website-foundation-v0/spec.md` | The rebuild note in Spec 213 points future work to the canonical Trust route and the Spec 223 mapping sheet. |
+
+## No Additional Drift Logged
+
+- Spec 214: no material drift logged. AstroDeck changes the substrate, but the website-only visual contract stays authoritative.
+- Spec 215: no material drift logged. The current IA is already the source of truth that constrains AstroDeck adoption.
+- Spec 217: no material drift logged. Optional AstroDeck proof sections are handled as remove/adapt mapping decisions, not as homepage-structure truth changes.
+- Spec 218: no material drift logged. Hero anti-pattern control and CTA semantics remain authoritative without new spec changes.
+
+## Action Summary
+
+The drift set above requires one direct spec update: Spec 213 must now carry an explicit Spec 223 rebuild note so reviewers can see that its broad truth survives while its older route and navigation assumptions do not.

specs/223-astrodeck-website-rebuild/plan.md

@@ -0,0 +1,191 @@
+# Implementation Plan: Website Reset and AstroDeck Rebuild
+
+**Branch**: `223-astrodeck-website-rebuild` | **Date**: 2026-04-22 | **Spec**: [spec.md](spec.md)
+**Input**: Feature specification from `/specs/223-astrodeck-website-rebuild/spec.md`
+
+**Note**: This template is filled in by the `/speckit.plan` command. See `.specify/scripts/` for helper scripts.
+
+## Summary
+
+This plan turns Spec 223 into a documentation-first rebuild workflow for `apps/website`. The primary requirement is to discard the current website implementation as the forward substrate while preserving the validity of continuing website specs and the history of legacy implementation tasks.
+
+The technical approach is:
+1. Confirm the current website is a standalone Astro 6 static app with file-based routes, content collections, and Playwright smoke coverage.
+2. Treat AstroDeck as an external template source that must be inventoried before any rebuild mapping or custom work starts.
+3. Model the rebuild with file-based planning artifacts only: current-site inventory, AstroDeck source intake, AstroDeck primitive inventory, website-spec classification, per-spec mapping or supersession-closure records, superseded legacy-task treatment, material-drift follow-up, and an exception register with review outcomes plus embedded approved exception records.
+4. Hand off follow-up task planning as an inventory-first slice, a conditional Spec 213 disposition-or-mapping slice, and per-spec mapping slices for the continuing website specs, with each per-spec mapping artifact owning its embedded replacement task list and explicit spec-update follow-up when mapping reveals material page inventory, CTA logic, navigation, or trust messaging drift.
+
+## Phases & Checkpoints
+
+### Phase 0 - Research & Scope Lock
+
+- Done when the current `apps/website` substrate, AstroDeck availability, route drift, and planning-artifact contract are documented in [research.md](research.md).
+- Done when no Technical Context field remains unresolved.
+
+### Phase 1 - Design Artifacts
+
+- Done when [data-model.md](data-model.md), [contracts/rebuild-planning-artifacts.yaml](contracts/rebuild-planning-artifacts.yaml), and [quickstart.md](quickstart.md) define the inventory, classification, mapping, superseded-task, and exception workflow.
+- Done when the Constitution Check is re-run post-design and still passes without introducing runtime or platform obligations.
+
+### Phase 2 - Task Planning Handoff
+
+- Done when `/speckit.tasks` can generate a task set that starts with AstroDeck inventory, keeps a conditional dedicated path for Spec 213, and then splits into per-spec mapping slices for Specs 214, 215, 217, and 218.
+- Done when legacy-task superseded handling and exception boundaries are explicit enough that task generation cannot silently fall back to greenfield rebuild work.
+
+## Final Follow-up Execution Order
+
+1. Bind the mounted AstroDeck snapshot to the aliases in `astrodeck-source-intake.md` and `astrodeck-primitive-inventory.md`.
+2. Execute the conditional foundation slice in `mappings/spec-213-website-foundation-v0.md`.
+3. Execute the shared visual-adaptation slice in `mappings/spec-214-website-visual-foundation.md`.
+4. Execute the canonical IA and route-mapping slice in `mappings/spec-215-website-core-pages.md`.
+5. Execute the homepage section-composition slice in `mappings/spec-217-homepage-structure.md`.
+6. Execute the homepage hero-refinement slice in `mappings/spec-218-homepage-hero.md`.
+
+## Technical Context
+
+**Language/Version**: TypeScript 5.9, Astro 6, Node.js 20+  
+**Primary Dependencies**: Astro, astro-icon, Tailwind CSS v4, Playwright 1.59  
+**Storage**: File-based route files, Astro content collections under `src/content`, public assets, and planning documents under `specs/223-astrodeck-website-rebuild`; no database  
+**Testing**: Static build plus Playwright smoke tests in `apps/website/tests/smoke` for follow-up implementation slices; this planning slice itself is documentation-only  
+**Validation Lanes**: N/A for this planning slice; fast-feedback for follow-up website implementation (`corepack pnpm build:website`, `cd apps/website && corepack pnpm exec playwright test`)
+**Target Platform**: Static public website served from the Astro app in `apps/website`
+**Project Type**: Monorepo web application with a standalone Astro website app  
+**Performance Goals**: No new runtime goal in this planning-only slice; follow-up rebuild work must preserve static-site buildability and smoke-testable route rendering across the current public route family  
+**Constraints**: Strictly local to `apps/website`; AstroDeck-first inventory and mapping; legacy tasks remain visible as superseded history; no default greenfield work; no platform or Filament coupling  
+**Scale/Scope**: Current website scope covers 12 public route files, 5 governing website specs (213, 214, 215, 217, 218), component families under `src/components/{primitives,sections,content,layout}`, and file-based content collections for articles, changelog, and resources
+
+## UI / Surface Guardrail Plan
+
+- **Guardrail scope**: no operator-facing surface change
+- **Native vs custom classification summary**: N/A
+- **Shared-family relevance**: none
+- **State layers in scope**: none
+- **Handling modes by drift class or surface**: report-only
+- **Repository-signal treatment**: review-mandatory for follow-up inventory and mapping artifacts; no runtime hard-stop in this slice
+- **Special surface test profiles**: N/A
+- **Required tests or manual smoke**: N/A for this planning slice; follow-up implementation slices must use browser smoke plus static build proof
+- **Exception path and spread control**: one named exception boundary only, for non-AstroDeck primitives that fail the mapping search and meet the documented exception rule
+- **Active feature PR close-out entry**: N/A
+
+## Constitution Check
+
+*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
+
+- [X] **Inventory-first / snapshots / Graph contract / deterministic capabilities / run observability / automation**: N/A. This slice introduces no runtime inventory model, no Graph calls, no queued work, and no `OperationRun`.
+- [X] **Scope / ownership / workspace and tenant isolation / RBAC / operator-surface rules**: N/A. The work is repository-local to `apps/website` and does not touch `/admin`, `/system`, tenant scope, or platform permissions.
+- [X] **Proportionality / no premature abstraction / few layers**: Pass. All outputs remain file-based design artifacts; no runtime registries, DTO layers, or persisted models are introduced.
+- [X] **LEAN-001**: Pass. The discarded website implementation is replaced rather than preserved through compatibility shims or legacy aliases.
+- [X] **TEST-GOV-001**: Pass. This slice is explicitly docs-only, states `N/A` for runtime proof, and pushes build/browser proof to follow-up implementation specs.
+- [X] **UI-FIL / BADGE / UX-001 / action-surface / naming / opsurface rules**: N/A. No Filament or operator-facing UI changes are planned in this slice.
+
+## Test Governance Check
+
+- **Test purpose / classification by changed surface**: N/A
+- **Affected validation lanes**: N/A
+- **Why this lane mix is the narrowest sufficient proof**: This slice only produces planning artifacts and does not change runtime behavior.
+- **Narrowest proving command(s)**: N/A
+- **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**: N/A
+- **Closing validation and reviewer handoff**: Reviewers should inspect the generated planning artifacts for completeness, continuity with Spec 223, and explicit follow-up validation ownership.
+- **Budget / baseline / trend follow-up**: none
+- **Review-stop questions**: lane fit, hidden runtime claims, accidental platform coupling
+- **Escalation path**: none
+- **Active feature PR close-out entry**: N/A
+- **Why no dedicated follow-up spec is needed**: This slice already exists to define the reset and planning contract; follow-up implementation proof belongs in the subsequent mapping specs and task plans.
+
+## Project Structure
+
+### Documentation & Planning Artifacts (this feature)
+
+```text
+specs/223-astrodeck-website-rebuild/
+├── current-website-inventory.md
+├── astrodeck-source-intake.md
+├── astrodeck-primitive-inventory.md
+├── governing-website-spec-classification.md
+├── legacy-task-disposition.md
+├── exception-register.md
+├── material-drift-follow-up.md
+├── mappings/
+│   ├── spec-213-website-foundation-v0.md
+│   ├── spec-214-website-visual-foundation.md
+│   ├── spec-215-website-core-pages.md
+│   ├── spec-217-homepage-structure.md
+│   └── spec-218-homepage-hero.md
+├── plan.md
+├── research.md
+├── data-model.md
+├── quickstart.md
+├── contracts/
+│   └── rebuild-planning-artifacts.yaml
+└── tasks.md
+```
+
+### Source Code (repository root)
+
+```text
+apps/website/
+├── astro.config.mjs
+├── package.json
+├── playwright.config.ts
+├── src/
+│   ├── content.config.ts
+│   ├── components/
+│   │   ├── content/
+│   │   ├── layout/
+│   │   ├── primitives/
+│   │   └── sections/
+│   ├── content/
+│   │   ├── articles/
+│   │   ├── changelog/
+│   │   ├── pages/
+│   │   └── resources/
+│   ├── layouts/
+│   ├── lib/
+│   ├── pages/
+│   │   ├── index.astro
+│   │   ├── product.astro
+│   │   ├── trust.astro
+│   │   ├── changelog.astro
+│   │   ├── contact.astro
+│   │   ├── privacy.astro
+│   │   ├── imprint.astro
+│   │   ├── terms.astro
+│   │   ├── solutions.astro
+│   │   ├── integrations.astro
+│   │   ├── legal.astro
+│   │   └── security-trust.astro
+│   └── styles/
+└── tests/
+    └── smoke/
+        ├── home-product.spec.ts
+        ├── solutions-trust-integrations.spec.ts
+        ├── changelog-core-ia.spec.ts
+        ├── contact-legal.spec.ts
+        └── visual-foundation-guardrails.spec.ts
+```
+
+**Structure Decision**: Use the existing monorepo structure as-is. This plan is centered on `apps/website` and the planning artifacts under `specs/223-astrodeck-website-rebuild`, with only bounded traceability updates to the referenced 213/214/215/217/218 spec or task files when legacy-task supersession or material-drift follow-up requires them. No new runtime packages, shared libraries, or platform directories are introduced. The per-spec mapping or disposition files are also the forward-looking rebuild-plan artifacts: they embed the replacement task list or explicit supersession closure instead of spawning separate per-spec `tasks.md` files in this slice.
+
+## Complexity Tracking
+
+| Violation | Why Needed | Simpler Alternative Rejected Because |
+|-----------|------------|-------------------------------------|
+| none | N/A | N/A |
+
+## Proportionality Review
+
+- **Current operator problem**: Website contributors and reviewers need one explicit rebuild contract so they can discard the current implementation without losing continuing website truth or legacy task history.
+- **Existing structure is insufficient because**: The current website specs define public-surface intent, but they do not specify how a full substrate change should preserve those decisions, reconcile current routes, and prevent silent greenfield rebuilding.
+- **Narrowest correct implementation**: File-based artifacts only: research, data model, contracts, quickstart, inventories, classifications, mapping sheets, superseded-task handling, material-drift follow-up, and exception boundaries.
+- **Ownership cost created**: Ongoing maintenance of a planning vocabulary for current-site inventory, AstroDeck primitive inventory, spec classification, mapping records, legacy-task disposition, and bounded exceptions.
+- **Alternative intentionally rejected**: A code-first template import or a single monolithic rebuild task list was rejected because both would hide the strategy shift and collapse inventory, classification, and mapping into one opaque step.
+- **Release truth**: Current-release truth for the public website rebuild; not future platform preparation.
+
+## Post-Design Constitution Check
+
+- [X] Post-design gate still passes: artifacts remain file-based and local to `apps/website`.
+- [X] No runtime, platform, RBAC, Filament, or operator-surface obligations were introduced during design.
+- [X] Follow-up implementation responsibility is explicit: inventory first, mapping second, tasks third, build/browser proof in later slices.

specs/223-astrodeck-website-rebuild/quickstart.md

@@ -0,0 +1,118 @@
+# Quickstart: Website Reset and AstroDeck Rebuild
+
+This quickstart describes how to execute Spec 223 after planning is approved.
+
+## Prerequisites
+
+- Work on branch `223-astrodeck-website-rebuild` or a follow-up branch derived from it.
+- Keep the existing `apps/website` codebase available for comparison until legacy-task disposition and current-site inventory are complete.
+- Obtain the AstroDeck source snapshot that will act as the new substrate. It does not need to be committed yet, but it must be available for inventory and mapping.
+
+## Step 1: Capture the current website inventory
+
+Inspect the current website surface before replacing anything.
+
+- Record every current route under `apps/website/src/pages`.
+- Record current component families under `apps/website/src/components`.
+- Record content-backed sources from `apps/website/src/content` and `apps/website/src/content.config.ts`.
+- Record current smoke coverage under `apps/website/tests/smoke` so follow-up rebuild work preserves intentional route and guardrail coverage.
+
+## Step 2: Capture the AstroDeck inventory
+
+Create a reviewable inventory of the imported AstroDeck source.
+
+- List AstroDeck pages.
+- List AstroDeck sections.
+- List AstroDeck components.
+- Flag demo-only copy, media, and CTA behavior that will require adaptation or removal.
+
+## Step 3: Classify the governing website specs
+
+Classify the current website spec set before touching implementation tasks.
+
+- Evaluate Specs 213, 214, 215, 217, and 218.
+- Mark each as continuing, partially valid, or superseded.
+- Record why the classification was chosen.
+- Record the `scopeSummary` for each classified spec.
+- Record the `followUpPlan` path for each classified spec so the owning per-spec mapping artifact or explicit supersession-closure artifact is visible immediately.
+- If Spec 213 remains continuing or partially valid, assign it its own dedicated rebuild-plan artifact instead of folding it into the 214-218 slices.
+
+## Step 4: Mark legacy implementation tasks as superseded
+
+Do not reopen or reset legacy tasks.
+
+- Preserve the old task history.
+- Mark implementation tasks tied to the discarded website with the canonical historical marker `superseded by AstroDeck rebuild`.
+- Point each superseded task to the new follow-up plan or task list, or record the explicit statement `no replacement work required`.
+
+## Step 5: Build per-spec AstroDeck mappings
+
+For each continuing or partially valid website spec:
+
+- Identify candidate AstroDeck pages, sections, and components.
+- Decide keep, adapt, remove, or exception for each relevant primitive.
+- Capture required adaptation to routes, content slots, styling, CTA logic, and trust/legal behavior.
+- Record acceptance mapping back to the governing spec.
+- Author the replacement task list inside the same per-spec mapping or disposition artifact so forward delivery ownership is explicit before implementation begins.
+- Name each replacement task by the relevant AstroDeck page, section, component, or mapping activity rather than using generic build verbs.
+- Give Spec 213 its own mapping or explicit supersession-closure artifact depending on the classification outcome.
+
+## Step 6: Record exceptions only when the primitive search fails
+
+Custom work is the exception path.
+
+- Search AstroDeck first.
+- Treat a primitive as adequate only when keep or bounded adaptation can satisfy the requirement without introducing a net-new IA contract or unsupported interaction model.
+- Record every missing-candidate review in the exception register as either `approved exception` or `no exception required`.
+- If no adequate primitive exists, capture the documented exception record in `exception-register.md` with the failed adequacy rationale and named approver.
+- Bound the exception to one page, section, or component slice.
+
+## Step 7: Record material drift as explicit spec work
+
+AstroDeck adoption must not silently change website truth.
+
+- Log any material page inventory, CTA logic, navigation, or trust messaging drift.
+- Update the affected existing website spec or create a named follow-up website spec.
+- Link the drift record to the mapping artifact that exposed it.
+
+## Step 8: Record cross-spec execution order for the follow-up tasks
+
+After the per-spec artifacts already contain their embedded replacement task lists or supersession closures, record the cross-spec execution order in this sequence:
+
+1. AstroDeck intake binding and primitive verification using `astrodeck-source-intake.md` and `astrodeck-primitive-inventory.md`
+2. Conditional Spec 213 disposition-or-mapping slice in `mappings/spec-213-website-foundation-v0.md`
+3. Spec 214 visual-adaptation slice in `mappings/spec-214-website-visual-foundation.md`
+4. Spec 215 IA and route-mapping slice in `mappings/spec-215-website-core-pages.md`
+5. Spec 217 homepage section-composition slice in `mappings/spec-217-homepage-structure.md`
+6. Spec 218 homepage hero-refinement slice in `mappings/spec-218-homepage-hero.md`
+
+Each per-spec mapping or disposition artifact should already contain its replacement task list or explicit supersession closure before this cross-spec execution order is recorded.
+
+## Step 9: Begin implementation only after the planning artifacts are complete
+
+Implementation should start only when:
+
+- every current website surface has a disposition
+- every continuing or partially valid website spec has a mapping artifact
+- legacy tasks are marked superseded
+- every material drift item points to an updated or follow-up website spec
+- any custom primitive has an approved exception record
+
+## Validation
+
+This planning slice does not require runtime validation. Follow-up implementation slices should use:
+
+- `corepack pnpm build:website`
+- `cd apps/website && corepack pnpm exec playwright test`
+
+## Expected Outputs
+
+- A current-site inventory for `apps/website`
+- An AstroDeck source-intake record
+- An AstroDeck primitive inventory
+- A classification of Specs 213, 214, 215, 217, and 218
+- Superseded legacy-task records
+- Per-spec AstroDeck mappings and embedded replacement task lists or explicit supersession closures, including the conditional Spec 213 artifact
+- Material-drift follow-up records tied to updated or follow-up website specs
+- An exception register with approved-exception and no-exception outcomes
+- Exception records only where AstroDeck cannot satisfy an active requirement

specs/223-astrodeck-website-rebuild/research.md

@@ -0,0 +1,49 @@
+# Research: Website Reset and AstroDeck Rebuild
+
+## Decision 1: Treat the current website as a custom Astro substrate that is being retired, not as a hybrid AstroDeck base
+
+- **Decision**: The existing `apps/website` codebase is a custom Astro 6 static site and must be treated as the legacy implementation being replaced.
+- **Rationale**: The app uses hand-authored route files under `src/pages`, custom component families under `src/components/{primitives,sections,content,layout}`, Astro content collections in `src/content.config.ts`, and a focused Playwright smoke suite. No AstroDeck runtime artifacts or imports exist in the current app.
+- **Alternatives considered**:
+  - Assume the current site is already close enough to AstroDeck and continue incrementally. Rejected because the repository shows a custom build, not a template-derived primitive inventory.
+  - Rebuild directly from the current component families. Rejected because Spec 223 makes AstroDeck the required substrate for forward work.
+
+## Decision 2: Treat AstroDeck as an external source intake that must be imported and inventoried before mapping begins
+
+- **Decision**: Planning must assume AstroDeck is not yet materialized in the repository and therefore must first be brought into a reviewable workspace before mapping decisions can start.
+- **Rationale**: Repository-wide search found AstroDeck references only in the spec text, not in `apps/website` source code or supporting docs. That makes AstroDeck an external input to the rebuild, not an already-present code surface.
+- **Alternatives considered**:
+  - Start mapping directly against the current website files. Rejected because that would bypass the mandatory AstroDeck-first workflow.
+  - Begin greenfield implementation and retrofit AstroDeck naming later. Rejected because Spec 223 forbids making AstroDeck invisible in planning and tasks.
+
+## Decision 3: Use file-based planning artifacts, not runtime models or APIs
+
+- **Decision**: The rebuild workflow will be modeled through documentation artifacts only: inventory, classification, mapping, legacy-task disposition, and exception records.
+- **Rationale**: Spec 223 is planning-only, introduces no runtime behavior, and explicitly avoids platform or application changes. File-based artifacts satisfy the need without importing new persistence, runtime contracts, or code abstractions.
+- **Alternatives considered**:
+  - Add database tables or a runtime registry for website planning state. Rejected as disproportionate and unnecessary for a docs-only slice.
+  - Encode the workflow only in freeform notes. Rejected because the rebuild needs consistent, reviewable structures for later task generation.
+
+## Decision 4: The current website source of truth spans routes, content collections, and smoke tests
+
+- **Decision**: The current-site inventory phase must inspect `src/pages`, `src/content`, `src/content.config.ts`, and `tests/smoke`, not route files alone.
+- **Rationale**: Routes define the surface area, content collections define editorial sources that survive page swaps, and smoke tests encode which public paths and guardrails the current website already treats as important.
+- **Alternatives considered**:
+  - Inventory route files only. Rejected because it would miss content-backed and test-backed obligations already present in the app.
+  - Inventory components only. Rejected because route and content drift is central to the rebuild scope.
+
+## Decision 5: The current route family is mostly aligned with the active website specs, but two classification edge cases must be handled explicitly
+
+- **Decision**: The rebuild plan should treat the current route family as mostly aligned with the active website specs while explicitly classifying `/legal` and `/security-trust` during the inventory and mapping phases.
+- **Rationale**: Current route files cover the core and secondary IA surfaces from Specs 213, 214, 215, 217, and 218. The comparison found one trust alias (`/security-trust` redirecting to `/trust`) and one legal hub/question (`/legal`) that require an explicit keep/adapt/remove decision.
+- **Alternatives considered**:
+  - Assume all current routes are canonical and carry them forward untouched. Rejected because Spec 223 requires visible mapping and removal decisions for non-conforming or extra surfaces.
+  - Assume any extra route is legacy and delete it immediately. Rejected because redirect and legal-hub behavior may still be valid and must be classified first.
+
+## Decision 6: Follow-up planning should split into one inventory slice, one conditional Spec 213 slice, and multiple mapping slices
+
+- **Decision**: After this plan, task generation should split into one AstroDeck inventory slice, one conditional Spec 213 disposition-or-mapping slice, and then separate mapping-and-replanning slices for Specs 214, 215, 217, and 218, with explicit spec updates or follow-up specs when material page inventory, CTA logic, navigation, or trust messaging drift is discovered.
+- **Rationale**: Spec 223 requires inventory before mapping, Spec 213 cannot disappear implicitly if it remains active after classification, and the continuing website specs each own different acceptance logic. Separating them keeps the rebuild reviewable and prevents one opaque website mega-task from hiding route, section, component, and spec-update decisions.
+- **Alternatives considered**:
+  - One monolithic rebuild task list for the entire website. Rejected because it would blur spec ownership and make superseded legacy-task treatment hard to audit.
+  - One tiny task per route or component. Rejected because it would over-fragment the work and obscure the governing spec boundaries.

specs/223-astrodeck-website-rebuild/spec.md

@@ -0,0 +1,187 @@
+# Feature Specification: Website Reset and AstroDeck Rebuild
+
+**Feature Branch**: `223-astrodeck-website-rebuild`  
+**Created**: 2026-04-22  
+**Status**: Approved  
+**Input**: User description: "Reset and rebuild `apps/website` on AstroDeck with strict AstroDeck primitive mapping, preserved website spec truth, superseded legacy implementation tasks, and documented exceptions for any non-AstroDeck rebuild work."
+
+## Spec Candidate Check *(mandatory — SPEC-GATE-001)*
+
+- **Problem**: `apps/website` has an existing implementation and task history that no longer match the desired implementation substrate, so future work can drift between legacy code, template import, and undocumented greenfield rebuilding.
+- **Today's failure**: Contributors could delete the old website, import AstroDeck, and reopen legacy tasks as if nothing materially changed, which would erase the strategy shift and make planning history misleading.
+- **User-visible improvement**: Website contributors and reviewers can rebuild on a clearly defined base, preserve existing public-surface spec truth, and distinguish legacy work from the new forward plan without guesswork.
+- **Smallest enterprise-capable version**: One `apps/website`-local reset-and-rebuild governance spec that declares the prior implementation superseded, makes AstroDeck the required substrate, classifies existing website specs, preserves legacy task history, and requires fresh AstroDeck-specific replanning.
+- **Explicit non-goals**: No final page visuals, no final copy, no file-by-file migration guide, no platform or Filament changes, no automatic reapproval of every website spec, and no unrestricted greenfield redesign.
+- **Permanent complexity imported**: A website-local rebuild contract, AstroDeck primitive inventory and mapping vocabulary, a superseded-task policy, and a narrow exception workflow for cases where the chosen base primitives are insufficient.
+- **Why now**: More website work is already blocked by uncertainty about whether the old implementation still matters and whether new work should inherit template defaults or existing website specs.
+- **Why not local**: A one-off migration note or template import would not preserve task history, would not classify which website specs still govern the site, and would not force future work onto one visible substrate.
+- **Approval class**: Cleanup
+- **Red flags triggered**: #1 introduces a new planning classification layer; #4 uses foundation/substrate language; #6 naturally leads to follow-up planning specs. The scope remains justified because it replaces ambiguity with one local contract and prevents silent drift during a full implementation reset.
+- **Score**: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 2 | Produktnaehe: 1 | Wiederverwendung: 2 | **Gesamt: 11/12**
+- **Decision**: approve
+
+## Spec Scope Fields *(mandatory)*
+
+- **Scope**: workspace
+- **Primary Routes**: All public routes in `apps/website`, starting with the current website route family governed by Specs 213, 214, 215, 217, and 218, including `/`, `/product`, `/trust`, `/changelog`, `/contact`, `/privacy`, and `/imprint`.
+- **Data Ownership**: Website-owned planning truth only: implementation-basis selection, AstroDeck primitive inventory and mapping, continuing-spec classification, superseded legacy task treatment, and documented exception records. No tenant-owned records, platform runtime data, or shared persistence are introduced.
+- **RBAC**: None. This feature governs repository planning and public-website implementation rules only.
+
+## UI / Surface Guardrail Impact *(mandatory when operator-facing surfaces are changed; otherwise write `N/A`)*
+
+N/A - no operator-facing surface change. This feature governs website implementation basis, planning artifacts, and legacy task treatment inside `apps/website`.
+
+## Proportionality Review *(mandatory when structural complexity is introduced)*
+
+- **New source of truth?**: yes
+- **New persisted entity/table/artifact?**: no
+- **New abstraction?**: yes
+- **New enum/state/reason family?**: no
+- **New cross-domain UI framework/taxonomy?**: yes, but only within `apps/website` planning and implementation governance
+- **Current operator problem**: Website contributors and reviewers cannot currently tell which website specs survive the reset, which tasks are obsolete, and whether new work must start from AstroDeck or from custom rebuilding.
+- **Existing structure is insufficient because**: The current website specs describe public-surface truth, but they do not define how a full implementation reset should preserve that truth, retire legacy tasks, or make AstroDeck mandatory for forward work.
+- **Narrowest correct implementation**: One website-local reset spec that fixes the implementation basis, legacy-task treatment, replanning workflow, and bounded exception policy without redefining page design or expanding into platform governance.
+- **Ownership cost**: Future website planning must keep continuing specs classified, legacy tasks visibly superseded, AstroDeck mappings explicit, and exceptions tightly bounded instead of allowing ad hoc drift.
+- **Alternative intentionally rejected**: Deleting the old website, importing AstroDeck, and reopening old tasks was rejected because it would erase the strategy shift, hide replanning work, and make implementation history unreliable.
+- **Release truth**: Current-release truth for the public website only; this is not a platform-wide workflow contract.
+
+### Compatibility posture
+
+This feature assumes a pre-production environment.
+
+Backward compatibility for the discarded website implementation, migration shims for legacy pages, and preservation of obsolete implementation structure are out of scope unless a later spec explicitly requires them.
+
+Canonical replacement through the new substrate is preferred over preservation.
+
+## Testing / Lane / Runtime Impact *(mandatory for runtime behavior changes)*
+
+- **Test purpose / classification**: N/A
+- **Validation lane(s)**: N/A
+- **Why this classification and these lanes are sufficient**: This feature changes specification and planning truth only. It does not by itself change runtime behavior, browser surfaces, or automated test obligations.
+- **New or expanded test families**: none
+- **Fixture / helper cost impact**: none
+- **Heavy-family visibility / justification**: none
+- **Special surface test profile**: N/A
+- **Standard-native relief or required special coverage**: none; follow-up implementation specs must define their own build and browser proof.
+- **Reviewer handoff**: Reviewers must confirm that the spec clearly separates discarded implementation from continuing spec truth, preserves task history, makes the implementation substrate explicit, and bounds exceptions instead of allowing greenfield bypass.
+- **Budget / baseline / trend impact**: none
+- **Escalation needed**: none
+- **Active feature PR close-out entry**: N/A
+- **Planned validation commands**: N/A - specification quality review only
+
+## User Scenarios & Testing *(mandatory)*
+
+### User Story 1 - Start rebuild work from one visible substrate (Priority: P1)
+
+A website contributor begins a new `apps/website` implementation slice and can tell immediately that the old website implementation no longer governs forward work and that the rebuild must start from AstroDeck primitives.
+
+**Why this priority**: If the implementation basis remains ambiguous, every follow-up website task risks mixing discarded code, template defaults, and unreviewed custom work.
+
+**Independent Test**: Review the reset spec and one follow-up planning artifact and confirm that the implementation starts from identified base pages, sections, and components rather than from the discarded website or a generic "build" task.
+
+**Acceptance Scenarios**:
+
+1. **Given** the previous website implementation still exists in repository history, **When** a contributor starts new website planning, **Then** they treat that implementation as superseded history rather than as the active build base.
+2. **Given** a contributor needs to plan a new website slice, **When** they begin the work, **Then** they first identify base pages, sections, or components from the chosen substrate before proposing custom construction.
+
+---
+
+### User Story 2 - Preserve old task history while creating a new forward plan (Priority: P1)
+
+A reviewer can see which older website implementation tasks no longer govern current work and which new task list now owns delivery for each continuing website spec.
+
+**Why this priority**: The reset is only trustworthy if it preserves why previous work no longer applies instead of pretending the same tasks can simply be started again.
+
+**Independent Test**: Review a continuing website spec and confirm that legacy implementation tasks are visibly superseded and that a separate forward-looking task list exists for the rebuild.
+
+**Acceptance Scenarios**:
+
+1. **Given** a website spec remains valid after the reset, **When** forward planning is created, **Then** its legacy implementation tasks stay visible as superseded history rather than being reset to unchecked.
+2. **Given** a reviewer inspects a continuing website spec, **When** they compare old and new planning, **Then** they can distinguish the legacy task record from the rebuild task list without relying on tribal knowledge.
+
+---
+
+### User Story 3 - Allow bounded exceptions only when the base primitives are insufficient (Priority: P2)
+
+A website planner can introduce a non-standard page, section, or component only after documenting why the existing base primitives cannot satisfy a continuing website spec.
+
+**Why this priority**: The rebuild only stays disciplined if custom work is a bounded exception rather than the silent default.
+
+**Independent Test**: Inspect any proposed custom primitive during replanning and confirm that it points to a missing candidate, a specific unmet requirement, and a dedicated exception record.
+
+**Acceptance Scenarios**:
+
+1. **Given** no adequate base primitive satisfies a continuing website spec, **When** a planner proposes custom work, **Then** they create a documented exception tied to that unmet requirement.
+2. **Given** an adequate base primitive exists, **When** a planner proposes custom rebuilding anyway, **Then** the proposal is rejected as a default path and must return to mapping or adaptation.
+
+### Edge Cases
+
+- What happens when an existing website spec contains both enduring public-surface truth and outdated implementation assumptions? It must be classified as partially valid, updated or supplemented as needed, and then replanned on the new base rather than treated as fully current or fully discarded.
+- What happens when Spec 213 remains continuing or partially valid after classification? It must receive its own dedicated rebuild-plan artifact instead of being absorbed implicitly into Specs 214, 215, 217, or 218.
+- What happens when multiple base primitives could satisfy the same spec requirement? The mapping must state the chosen candidate and rationale before task creation so later work stays traceable.
+- How does the rebuild handle imported demo pages, demo sections, or demo copy that do not conform to active website specs? They must generate explicit removal or adaptation tasks instead of surviving by default.
+- How does the rebuild handle a missing base primitive for a required capability? The gap must become a documented exception with a bounded replacement task rather than a silent greenfield detour.
+
+## Requirements *(mandatory)*
+
+**Constitution alignment (required):** This feature introduces no Microsoft Graph calls, no queueing, no long-running operations, no authorization changes, and no Filament operator surfaces. Its contract is strictly local to `apps/website` and the planning artifacts that govern website implementation.
+
+**Constitution alignment (PROP-001 / ABSTR-001 / PERSIST-001 / STATE-001 / BLOAT-001):** This feature adds a narrow website-local rebuild contract and exception workflow, not new runtime persistence or a shared platform abstraction. The rule set is justified only because a full implementation reset would otherwise blur continuing website truth, legacy task history, and forward planning.
+
+**Constitution alignment (TEST-GOV-001):** This feature changes no runtime behavior and adds no automated runtime tests. Follow-up implementation specs remain responsible for build and browser validation. This spec is validated through repository review and the specification quality checklist only.
+
+### Functional Requirements
+
+- **FR-001**: The existing `apps/website` implementation MUST be treated as discarded implementation history and MUST NOT remain the primary starting point for forward website work.
+- **FR-002**: AstroDeck MUST become the required technical and structural substrate for new `apps/website` implementation work.
+- **FR-003**: This reset-and-rebuild contract MUST remain strictly local to `apps/website` and MUST NOT impose platform, Filament, or cross-app obligations.
+- **FR-004**: Existing website specs that still define valid public-surface truth MUST remain authoritative unless a later spec explicitly replaces or narrows them.
+- **FR-005**: Each existing website spec in scope MUST be classified as continuing, partially valid, or superseded before new implementation planning begins.
+- **FR-006**: Legacy implementation tasks tied to the discarded website MUST remain visible as historical context and MUST NOT be reset to unchecked or reopened as if the underlying implementation basis were unchanged.
+- **FR-007**: Legacy implementation tasks affected by the rebuild MUST use the canonical historical marker `superseded by AstroDeck rebuild` so their non-authoritative status stays consistent across all affected website specs.
+- **FR-008**: Each continuing or partially valid website spec MUST receive a separate new implementation plan for the rebuild; if Spec 213 remains continuing or partially valid after classification, it MUST receive its own dedicated rebuild-plan artifact rather than being folded implicitly into Specs 214, 215, 217, or 218.
+- **FR-009**: Each new implementation plan MUST identify candidate AstroDeck pages, sections, and components that act as the starting point for that spec's rebuild work.
+- **FR-010**: Each identified AstroDeck candidate in a new plan MUST be classified as keep, adapt, remove, or exception.
+- **FR-011**: New implementation tasks MUST explicitly name the relevant AstroDeck page, section, component, or mapping activity rather than describing custom rebuilding in generic terms.
+- **FR-012**: New implementation tasks MUST cover removal of demo pages, demo sections, demo components, and demo copy that do not conform to active website specs.
+- **FR-013**: New implementation tasks MUST cover any required adaptation to structure, routing, content slots, styling, or composition needed to satisfy active website specs.
+- **FR-014**: New implementation work MUST begin with AstroDeck primitive identification and mapping before any freeform new page, section, or component is proposed.
+- **FR-015**: A freeform new page, section, or component MUST NOT be created when an adequate AstroDeck-derived candidate already exists; a candidate counts as adequate only when keep or bounded adaptation can satisfy the active requirement without inventing a net-new IA contract or unsupported interaction model.
+- **FR-016**: A non-AstroDeck page, section, or component MAY be introduced only through a documented exception approved in the mapping review by a named website reviewer, owner, or equivalent feature approver and tied to a specific unmet requirement in an active website spec.
+- **FR-017**: Each documented exception MUST record the missing AstroDeck candidate, the unmet requirement, why the available AstroDeck candidates failed the adequacy test, the bounded deviation, the named approver, and the dedicated task or planning entry that owns the exception.
+- **FR-018**: The rebuild workflow MUST occur in this order: discard prior implementation basis, establish AstroDeck as base, inventory AstroDeck primitives, classify existing website specs, mark legacy tasks superseded, create mappings, create new tasks, document exceptions, then begin implementation.
+- **FR-019**: The planning output for each continuing or partially valid website spec MUST include AstroDeck primitive mapping, keep/adapt/remove/exception decisions, a new task list embedded in the same per-spec mapping or disposition artifact or linked from it explicitly, and explicit acceptance mapping back to the active spec.
+- **FR-020**: Any material change to page inventory, CTA logic, navigation, or trust messaging introduced through AstroDeck adoption MUST appear in updated existing website specs or explicitly created follow-up website specs referenced from the rebuild planning artifacts rather than entering silently through template import.
+- **FR-021**: The rebuild deliverables MUST include an AstroDeck inventory for `apps/website`, a classification of in-scope website specs, preserved historical task treatment using the canonical superseded marker, a new task list or explicit supersession closure for each in-scope website spec, a material-drift follow-up record for any required spec updates, and an exception register that records approved exceptions and explicit no-exception outcomes.
+- **FR-022**: Follow-up classification MUST explicitly evaluate the current known website spec set that already governs `apps/website`, including Specs 213, 214, 215, 217, and 218.
+- **FR-023**: Task wording and planning artifacts MUST keep AstroDeck visible as the implementation substrate and MUST NOT hide it behind generic build verbs that make the mapping step invisible.
+
+### Assumptions
+
+- This reset occurs in a pre-production website track, so preserving the discarded implementation for backward compatibility is not required.
+- Existing website specs remain the current normative baseline until they are explicitly classified or superseded through follow-up planning.
+- The chosen AstroDeck distribution provides reusable pages, sections, and components sufficient to support an inventory and mapping pass.
+
+### Dependencies
+
+- AstroDeck assets and primitives must be available to the repository or local implementation workspace so that inventory and mapping can be performed.
+- Follow-up planning work must create separate task lists or replanning artifacts for the continuing website specs after this reset spec is accepted.
+- The planning workflow must support a visible superseded marker or equivalent notation for legacy implementation tasks.
+
+### Key Entities
+
+- **Legacy Website Implementation**: The previous `apps/website` codebase and assembly approach that remains part of repository history but no longer serves as the forward-looking implementation base.
+- **Continuing Website Spec**: An existing website spec whose public-surface truth remains active after classification, even though its prior implementation tasks may no longer govern delivery.
+- **AstroDeck Primitive Mapping**: The per-spec record of which AstroDeck pages, sections, and components serve as the rebuild starting point and whether each is kept, adapted, removed, or treated as an exception.
+- **Superseded Legacy Task**: A historical implementation task preserved for traceability but no longer authoritative for current website delivery.
+- **Documented Exception**: A bounded approval record for introducing a non-AstroDeck page, section, or component when no adequate AstroDeck candidate satisfies an active website requirement.
+
+## Success Criteria *(mandatory)*
+
+### Measurable Outcomes
+
+- **SC-001**: A reviewer can inspect the reset artifacts and determine in one pass that the previous `apps/website` implementation no longer governs forward work.
+- **SC-002**: 100% of continuing or partially valid website specs in scope, including Spec 213 whenever it remains active after classification, have a forward-looking rebuild task list that is clearly separated from legacy implementation tasks.
+- **SC-003**: 100% of forward-looking website plans identify starting pages, sections, and components and assign keep, adapt, remove, or exception outcomes before implementation begins.
+- **SC-004**: 100% of freeform non-AstroDeck primitives introduced during follow-up planning carry an explicit exception record tied to an unmet active-spec requirement.
+- **SC-005**: 100% of the currently known website spec set in scope is classified as continuing, partially valid, or superseded before rebuild implementation starts.

specs/223-astrodeck-website-rebuild/tasks.md

@@ -0,0 +1,187 @@
+# Tasks: Website Reset and AstroDeck Rebuild
+
+**Input**: Design documents from `/specs/223-astrodeck-website-rebuild/`  
+**Prerequisites**: `plan.md`, `spec.md`, `research.md`, `data-model.md`, `quickstart.md`, `contracts/rebuild-planning-artifacts.yaml`
+
+**Tests**: N/A - docs-only planning feature. This slice adds no runtime behavior, so no automated test tasks are required here. Follow-up implementation slices own `corepack pnpm build:website` and `cd apps/website && corepack pnpm exec playwright test`.
+
+## Test Governance Checklist
+
+- [X] Lane assignment is `N/A` because this feature changes planning artifacts only.
+- [X] No runtime or browser test family is added in this slice.
+- [X] No new helpers, fixtures, seeds, or shared defaults are introduced.
+- [X] Runtime proof remains explicitly deferred to follow-up website implementation slices.
+- [X] The governance outcome stays documented in-feature rather than becoming a separate cleanup item.
+
+## Phase 1: Setup (Shared Infrastructure)
+
+**Purpose**: Create the planning workspace files that the inventory, classification, mapping, and exception workflow will use.
+
+- [X] T001 Create the current-site and AstroDeck inventory stubs in `specs/223-astrodeck-website-rebuild/current-website-inventory.md`, `specs/223-astrodeck-website-rebuild/astrodeck-source-intake.md`, and `specs/223-astrodeck-website-rebuild/astrodeck-primitive-inventory.md`
+- [X] T002 [P] Create the governing-spec, legacy-task disposition, and material-drift follow-up stubs in `specs/223-astrodeck-website-rebuild/governing-website-spec-classification.md`, `specs/223-astrodeck-website-rebuild/legacy-task-disposition.md`, and `specs/223-astrodeck-website-rebuild/material-drift-follow-up.md`
+- [X] T003 [P] Create the per-spec mapping workspace and exception stub in `specs/223-astrodeck-website-rebuild/exception-register.md`, `specs/223-astrodeck-website-rebuild/mappings/spec-213-website-foundation-v0.md`, `specs/223-astrodeck-website-rebuild/mappings/spec-214-website-visual-foundation.md`, `specs/223-astrodeck-website-rebuild/mappings/spec-215-website-core-pages.md`, `specs/223-astrodeck-website-rebuild/mappings/spec-217-homepage-structure.md`, and `specs/223-astrodeck-website-rebuild/mappings/spec-218-homepage-hero.md`
+
+---
+
+## Phase 2: Foundational (Blocking Prerequisites)
+
+**Purpose**: Establish the shared baseline, intake rules, and crosswalk logic that every user story depends on.
+
+**⚠️ CRITICAL**: No user story work should begin until this phase is complete.
+
+- [X] T004 Capture the current route, content, component-family, and smoke-suite baseline in `specs/223-astrodeck-website-rebuild/current-website-inventory.md`
+- [X] T005 [P] Record AstroDeck source provenance, intake constraints, and review assumptions in `specs/223-astrodeck-website-rebuild/astrodeck-source-intake.md`
+- [X] T006 [P] Define the page, section, and component inventory columns plus demo-content flags in `specs/223-astrodeck-website-rebuild/astrodeck-primitive-inventory.md`
+- [X] T007 Build the shared crosswalk from current website surfaces to Specs 213, 214, 215, 217, and 218 in `specs/223-astrodeck-website-rebuild/governing-website-spec-classification.md`
+
+**Checkpoint**: The planning workspace, current-site baseline, AstroDeck intake rules, and governing-spec crosswalk are in place. Story work can now proceed.
+
+---
+
+## Phase 3: User Story 1 - Start Rebuild Work From One Visible Substrate (Priority: P1) 🎯 MVP
+
+**Goal**: Make the retired current website and the new AstroDeck substrate visible side by side so future work starts from the right base.
+
+**Independent Test**: A reviewer can open the current-site inventory and AstroDeck inventory documents and see that the old `apps/website` implementation is historical context while forward work starts from identified AstroDeck pages, sections, and components.
+
+### Implementation for User Story 1
+
+- [X] T008 [P] [US1] Complete the current website surface inventory with route roles, source files, dependencies, and initial keep/adapt/remove/redirect candidates in `specs/223-astrodeck-website-rebuild/current-website-inventory.md`
+- [X] T009 [P] [US1] Complete the AstroDeck primitive inventory with page, section, and component candidates plus demo-content flags in `specs/223-astrodeck-website-rebuild/astrodeck-primitive-inventory.md`
+- [X] T010 [US1] Reconcile the current-site baseline with the AstroDeck intake summary so the forward substrate is explicit in `specs/223-astrodeck-website-rebuild/astrodeck-source-intake.md`, `specs/223-astrodeck-website-rebuild/current-website-inventory.md`, and `specs/223-astrodeck-website-rebuild/astrodeck-primitive-inventory.md`
+
+**Checkpoint**: The rebuild now has one visible implementation substrate and a clear retired baseline.
+
+---
+
+## Phase 4: User Story 2 - Preserve Old Task History While Creating a New Forward Plan (Priority: P1)
+
+**Goal**: Keep legacy website task history readable while producing AstroDeck-specific replacement planning for the continuing website specs.
+
+**Independent Test**: A reviewer can inspect the classification and legacy-task artifacts and then open the per-spec mapping sheets to see which old tasks were superseded and which new AstroDeck-specific task lists now own delivery.
+
+### Implementation for User Story 2
+
+- [X] T011 [US2] Classify Specs 213, 214, 215, 217, and 218 as continuing, partially valid, or superseded and record the classification `rationale`, `scopeSummary`, and `followUpPlan` reference for each spec in `specs/223-astrodeck-website-rebuild/governing-website-spec-classification.md`, including whether Spec 213 points to a dedicated rebuild plan in `specs/223-astrodeck-website-rebuild/mappings/spec-213-website-foundation-v0.md`
+- [X] T012 [US2] Mark legacy implementation tasks as `superseded by AstroDeck rebuild` in `specs/213-website-foundation-v0/tasks.md`, `specs/214-website-visual-foundation/tasks.md`, `specs/215-website-core-pages/tasks.md`, `specs/217-homepage-structure/tasks.md`, and `specs/218-homepage-hero/tasks.md`, and summarize the replacement references in `specs/223-astrodeck-website-rebuild/legacy-task-disposition.md`
+- [X] T013 [P] [US2] Create the Spec 213 disposition-or-rebuild mapping sheet, recording either a full AstroDeck plan with its embedded replacement task list naming the relevant AstroDeck page, section, component, or mapping activity or an explicit supersession closure, in `specs/223-astrodeck-website-rebuild/mappings/spec-213-website-foundation-v0.md`
+- [X] T014 [P] [US2] Create the Spec 214 and Spec 215 disposition-or-rebuild mapping sheets, recording either full AstroDeck plans with embedded replacement task lists naming the relevant AstroDeck pages, sections, components, or mapping activities or explicit supersession closures, in `specs/223-astrodeck-website-rebuild/mappings/spec-214-website-visual-foundation.md` and `specs/223-astrodeck-website-rebuild/mappings/spec-215-website-core-pages.md`
+- [X] T015 [P] [US2] Create the Spec 217 and Spec 218 disposition-or-rebuild mapping sheets, recording either full AstroDeck plans with embedded replacement task lists naming the relevant AstroDeck pages, sections, components, or mapping activities or explicit supersession closures, in `specs/223-astrodeck-website-rebuild/mappings/spec-217-homepage-structure.md` and `specs/223-astrodeck-website-rebuild/mappings/spec-218-homepage-hero.md`
+- [X] T016 [US2] Cross-check the per-spec mapping sheets against the spec classifications, `followUpPlan` references, legacy-task replacements, and material-drift follow-up ledger in `specs/223-astrodeck-website-rebuild/governing-website-spec-classification.md`, `specs/223-astrodeck-website-rebuild/legacy-task-disposition.md`, `specs/223-astrodeck-website-rebuild/material-drift-follow-up.md`, `specs/223-astrodeck-website-rebuild/mappings/spec-213-website-foundation-v0.md`, `specs/223-astrodeck-website-rebuild/mappings/spec-214-website-visual-foundation.md`, `specs/223-astrodeck-website-rebuild/mappings/spec-215-website-core-pages.md`, `specs/223-astrodeck-website-rebuild/mappings/spec-217-homepage-structure.md`, and `specs/223-astrodeck-website-rebuild/mappings/spec-218-homepage-hero.md`
+
+**Checkpoint**: Legacy work remains readable, and the forward-looking AstroDeck task ownership exists for every continuing website spec.
+
+---
+
+## Phase 5: User Story 3 - Allow Bounded Exceptions Only When the Base Primitives Are Insufficient (Priority: P2)
+
+**Goal**: Make custom non-AstroDeck work possible only through an explicit, scoped exception path.
+
+**Independent Test**: A reviewer can inspect any custom-primitive proposal and see the failed AstroDeck search, the unmet spec requirement, the bounded deviation, and the approval reference without ambiguity.
+
+### Implementation for User Story 3
+
+- [X] T017 [US3] Define the exception workflow, adequacy rubric, required evidence, approval boundary, and embedded documented-exception record shape for non-AstroDeck primitives in `specs/223-astrodeck-website-rebuild/exception-register.md`
+- [X] T018 [P] [US3] Review the Spec 213, Spec 214, and Spec 215 mapping sheets for unmet requirements and record either approved exceptions or explicit no-exception outcomes in `specs/223-astrodeck-website-rebuild/exception-register.md`, `specs/223-astrodeck-website-rebuild/mappings/spec-213-website-foundation-v0.md`, `specs/223-astrodeck-website-rebuild/mappings/spec-214-website-visual-foundation.md`, and `specs/223-astrodeck-website-rebuild/mappings/spec-215-website-core-pages.md`
+- [X] T019 [P] [US3] Review the Spec 217 and Spec 218 mapping sheets for unmet requirements and record either approved exceptions or explicit no-exception outcomes in `specs/223-astrodeck-website-rebuild/exception-register.md`, `specs/223-astrodeck-website-rebuild/mappings/spec-217-homepage-structure.md`, and `specs/223-astrodeck-website-rebuild/mappings/spec-218-homepage-hero.md`
+- [X] T020 [US3] Add spread-control and acceptance-trace notes for every exception-backed or no-exception mapping in `specs/223-astrodeck-website-rebuild/exception-register.md`, `specs/223-astrodeck-website-rebuild/mappings/spec-213-website-foundation-v0.md`, `specs/223-astrodeck-website-rebuild/mappings/spec-214-website-visual-foundation.md`, `specs/223-astrodeck-website-rebuild/mappings/spec-215-website-core-pages.md`, `specs/223-astrodeck-website-rebuild/mappings/spec-217-homepage-structure.md`, and `specs/223-astrodeck-website-rebuild/mappings/spec-218-homepage-hero.md`
+
+**Checkpoint**: The rebuild has a controlled exception path instead of a silent greenfield bypass.
+
+---
+
+## Phase 6: Polish & Cross-Cutting Concerns
+
+**Purpose**: Reconcile the finished planning artifacts with the contract, force explicit spec-update follow-up for material drift, and lock the handoff order for implementation slices.
+
+- [X] T021 [P] Reconcile the completed inventory, classification, mapping, exception, and material-drift artifacts against `specs/223-astrodeck-website-rebuild/contracts/rebuild-planning-artifacts.yaml` and `specs/223-astrodeck-website-rebuild/quickstart.md`
+- [X] T022 [P] Update the affected continuing website specs or create named follow-up website specs when material page inventory, CTA logic, navigation, or trust messaging drift is logged in `specs/213-website-foundation-v0/spec.md`, `specs/214-website-visual-foundation/spec.md`, `specs/215-website-core-pages/spec.md`, `specs/217-homepage-structure/spec.md`, `specs/218-homepage-hero/spec.md`, and `specs/223-astrodeck-website-rebuild/material-drift-follow-up.md`
+- [X] T023 [P] Verify that superseded legacy-task markers and replacement references are visible from `specs/213-website-foundation-v0/tasks.md`, `specs/214-website-visual-foundation/tasks.md`, `specs/215-website-core-pages/tasks.md`, `specs/217-homepage-structure/tasks.md`, `specs/218-homepage-hero/tasks.md`, and `specs/223-astrodeck-website-rebuild/legacy-task-disposition.md`
+- [X] T024 Record the final follow-up execution order for the AstroDeck inventory slice, the conditional Spec 213 slice, and the Spec 214/215/217/218 mapping slices, each already carrying its embedded replacement task list or supersession closure, in `specs/223-astrodeck-website-rebuild/plan.md`, `specs/223-astrodeck-website-rebuild/quickstart.md`, and `specs/223-astrodeck-website-rebuild/governing-website-spec-classification.md`
+
+---
+
+## Dependencies & Execution Order
+
+### Phase Dependencies
+
+- **Setup (Phase 1)**: Starts immediately.
+- **Foundational (Phase 2)**: Depends on Setup and blocks all user stories.
+- **User Story 1 (Phase 3)**: Depends on Foundational only.
+- **User Story 2 (Phase 4)**: Depends on User Story 1 because the completed inventories from US1 are required before classification and mapping can start.
+- **User Story 3 (Phase 5)**: Depends on the mapping sheets from US2.
+- **Polish (Phase 6)**: Depends on all targeted user stories being complete.
+
+### User Story Dependencies
+
+- **US1**: MVP slice. No dependency on US2 or US3.
+- **US2**: Depends on US1 because the current-site and AstroDeck inventories must be complete before classification and mapping.
+- **US3**: Depends on the per-spec mapping sheets, including the conditional Spec 213 artifact, so exceptions can be evaluated against real candidate searches.
+
+### Within Each User Story
+
+- Establish or complete the relevant artifact first.
+- Record explicit dispositions before writing replacement task lists.
+- Link exceptions only after the mapping decision shows a real gap.
+- Finish each story’s cross-check task before moving to the next story.
+
+---
+
+## Parallel Opportunities
+
+- `T002` and `T003` can run in parallel after `T001`.
+- `T005` and `T006` can run in parallel after `T004` starts.
+- In US1, `T008` and `T009` can run in parallel before `T010`.
+- In US2, `T013`, `T014`, and `T015` can run in parallel after `T012`.
+- In US3, `T018` and `T019` can run in parallel after `T017`.
+- In Phase 6, `T021`, `T022`, and `T023` can run in parallel before `T024`.
+
+---
+
+## Parallel Example: User Story 2
+
+```bash
+# First record legacy-task supersession after classification:
+Task: "T012 [US2] Mark legacy implementation tasks as superseded"
+
+# After legacy-task supersession is recorded, launch the per-spec planning artifacts in parallel:
+Task: "T013 [US2] Create the Spec 213 disposition-or-rebuild mapping sheet"
+Task: "T014 [US2] Create the Spec 214 and Spec 215 disposition-or-rebuild mapping sheets"
+Task: "T015 [US2] Create the Spec 217 and Spec 218 disposition-or-rebuild mapping sheets"
+
+# Then run the consistency pass:
+Task: "T016 [US2] Cross-check the mapping sheets against the classification, legacy-task, and material-drift records"
+```
+
+---
+
+## Implementation Strategy
+
+### MVP First (User Story 1 Only)
+
+1. Complete Phase 1: Setup.
+2. Complete Phase 2: Foundational.
+3. Complete Phase 3: User Story 1.
+4. **STOP and VALIDATE**: Review the current-site and AstroDeck inventories together.
+5. Use that MVP substrate view as the basis for the follow-up mapping work.
+
+### Incremental Delivery
+
+1. Complete Setup + Foundational to establish the planning workspace.
+2. Add US1 to make the rebuild substrate explicit.
+3. Add US2 to preserve legacy history and produce forward AstroDeck task ownership.
+4. Add US3 to harden the exception path.
+5. Finish with Phase 6 to reconcile the artifacts and publish the handoff order.
+
+### Suggested MVP Scope
+
+- Deliver through **User Story 1** if the smallest first slice is needed.
+- Add **User Story 2** next to preserve task history and create per-spec forward plans.
+- Finish with **User Story 3** to ensure custom work remains exception-bound.
+
+## Notes
+
+- `[P]` tasks touch different files or independent artifacts and can run in parallel once dependencies are satisfied.
+- `[US1]`, `[US2]`, and `[US3]` map directly to the user stories in `spec.md`.
+- This is a docs-only planning feature, so no runtime test tasks are included here.
+- The intended follow-up split after this feature is one AstroDeck inventory slice, a conditional Spec 213 slice, and per-spec mapping slices for Specs 214, 215, 217, and 218, with each per-spec artifact carrying its replacement task list or explicit supersession closure and with spec updates or follow-up specs when material drift is discovered.

specs/226-astrodeck-inventory-planning/checklists/requirements.md

@@ -0,0 +1,35 @@
+# Specification Quality Checklist: AstroDeck Inventory Planning for Website Rebuild
+
+**Purpose**: Validate specification completeness and quality before proceeding to planning
+**Created**: 2026-04-22
+**Feature**: [spec.md](../spec.md)
+
+## Content Quality
+
+- [x] No implementation details (languages, frameworks, APIs)
+- [x] Focused on user value and business needs
+- [x] Written for non-technical stakeholders
+- [x] All mandatory sections completed
+
+## Requirement Completeness
+
+- [x] No [NEEDS CLARIFICATION] markers remain
+- [x] Requirements are testable and unambiguous
+- [x] Success criteria are measurable
+- [x] Success criteria are technology-agnostic (no implementation details)
+- [x] All acceptance scenarios are defined
+- [x] Edge cases are identified
+- [x] Scope is clearly bounded
+- [x] Dependencies and assumptions identified
+
+## Feature Readiness
+
+- [x] All functional requirements have clear acceptance criteria
+- [x] User scenarios cover primary flows
+- [x] Feature meets measurable outcomes defined in Success Criteria
+- [x] No implementation details leak into specification
+
+## Notes
+
+- Validation passed in first iteration; no unresolved issues.
+- Ready for `/speckit.plan`.

specs/226-astrodeck-inventory-planning/contracts/astrodeck-inventory.logical.openapi.yaml

@@ -0,0 +1,287 @@
+openapi: 3.1.0
+info:
+  title: AstroDeck Inventory Logical Contract
+  version: 0.1.0
+  description: >-
+    Logical planning contract for publishing and querying AstroDeck primitive inventory
+    used by website rebuild mapping specs. This contract defines artifact shapes only
+    for planning governance and does not imply runtime implementation in this feature.
+servers:
+  - url: https://planning.local
+paths:
+  /inventory/catalogs:
+    post:
+      summary: Publish a new inventory catalog snapshot
+      operationId: publishInventoryCatalog
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              $ref: '#/components/schemas/InventoryCatalogCreateRequest'
+      responses:
+        '201':
+          description: Catalog created
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/InventoryCatalog'
+  /inventory/catalogs/{catalogId}:
+    get:
+      summary: Retrieve one inventory catalog with entries
+      operationId: getInventoryCatalog
+      parameters:
+        - name: catalogId
+          in: path
+          required: true
+          schema:
+            type: string
+      responses:
+        '200':
+          description: Catalog found
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/InventoryCatalog'
+  /inventory/catalogs/{catalogId}/summary:
+    get:
+      summary: Retrieve suitability and risk summary
+      operationId: getInventorySuitabilitySummary
+      parameters:
+        - name: catalogId
+          in: path
+          required: true
+          schema:
+            type: string
+      responses:
+        '200':
+          description: Summary found
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/SuitabilitySummary'
+  /inventory/catalogs/{catalogId}/entries:
+    get:
+      summary: List inventory entries with optional filters
+      operationId: listInventoryEntries
+      parameters:
+        - name: catalogId
+          in: path
+          required: true
+          schema:
+            type: string
+        - name: primitiveClass
+          in: query
+          required: false
+          schema:
+            $ref: '#/components/schemas/PrimitiveClass'
+        - name: suitabilityClass
+          in: query
+          required: false
+          schema:
+            $ref: '#/components/schemas/SuitabilityClass'
+        - name: marker
+          in: query
+          required: false
+          schema:
+            $ref: '#/components/schemas/Marker'
+      responses:
+        '200':
+          description: Entries returned
+          content:
+            application/json:
+              schema:
+                type: object
+                properties:
+                  data:
+                    type: array
+                    items:
+                      $ref: '#/components/schemas/InventoryEntry'
+                required: [data]
+components:
+  schemas:
+    PrimitiveClass:
+      type: string
+      enum: [Page, Section, Component]
+    SuitabilityClass:
+      type: string
+      enum: [A, B, C, D]
+    TenantAtlasRelevance:
+      type: string
+      enum: [high, medium, low, none]
+    Marker:
+      type: string
+      enum:
+        - tenantatlas-likely
+        - needs-heavy-adaptation
+        - visual-risk
+        - semantic-risk
+        - demo-only
+        - remove-likely
+        - hero-candidate
+        - trust-candidate
+        - navigation-candidate
+        - footer-candidate
+        - contact-candidate
+        - product-explainer-candidate
+        - changelog-candidate
+    InventoryEntry:
+      type: object
+      required:
+        - entryId
+        - identifier
+        - primitiveClass
+        - fileRef
+        - functionalRole
+        - defaultSemantics
+        - defaultVisualCharacter
+        - tenantatlasRelevance
+        - suitabilityClass
+      properties:
+        entryId:
+          type: string
+        identifier:
+          type: string
+        primitiveClass:
+          $ref: '#/components/schemas/PrimitiveClass'
+        fileRef:
+          type: string
+        functionalRole:
+          type: string
+        defaultSemantics:
+          type: string
+        defaultVisualCharacter:
+          type: string
+        tenantatlasRelevance:
+          $ref: '#/components/schemas/TenantAtlasRelevance'
+        suitabilityClass:
+          $ref: '#/components/schemas/SuitabilityClass'
+        markers:
+          type: array
+          items:
+            $ref: '#/components/schemas/Marker'
+        notes:
+          type: string
+    SuitabilitySummary:
+      type: object
+      required:
+        - countA
+        - countB
+        - countC
+        - countD
+        - riskVisualCount
+        - riskSemanticCount
+        - demoOnlyCount
+        - surfaceCandidates
+      properties:
+        countA:
+          type: integer
+          minimum: 0
+        countB:
+          type: integer
+          minimum: 0
+        countC:
+          type: integer
+          minimum: 0
+        countD:
+          type: integer
+          minimum: 0
+        riskVisualCount:
+          type: integer
+          minimum: 0
+        riskSemanticCount:
+          type: integer
+          minimum: 0
+        demoOnlyCount:
+          type: integer
+          minimum: 0
+        surfaceCandidates:
+          type: object
+          required:
+            - homepage
+            - hero
+            - product
+            - trust
+            - changelog
+            - contactDemo
+            - navigation
+            - footer
+          properties:
+            homepage:
+              type: array
+              items:
+                type: string
+            hero:
+              type: array
+              items:
+                type: string
+            product:
+              type: array
+              items:
+                type: string
+            trust:
+              type: array
+              items:
+                type: string
+            changelog:
+              type: array
+              items:
+                type: string
+            contactDemo:
+              type: array
+              items:
+                type: string
+            navigation:
+              type: array
+              items:
+                type: string
+            footer:
+              type: array
+              items:
+                type: string
+    InventoryCatalog:
+      type: object
+      required:
+        - catalogId
+        - scope
+        - createdAt
+        - sourceCommit
+        - status
+        - entries
+        - summary
+      properties:
+        catalogId:
+          type: string
+        scope:
+          type: string
+          const: apps/website
+        createdAt:
+          type: string
+          format: date-time
+        sourceCommit:
+          type: string
+        status:
+          type: string
+          enum: [draft, reviewed, baselined]
+        entries:
+          type: array
+          items:
+            $ref: '#/components/schemas/InventoryEntry'
+        summary:
+          $ref: '#/components/schemas/SuitabilitySummary'
+    InventoryCatalogCreateRequest:
+      type: object
+      required:
+        - catalogId
+        - sourceCommit
+        - entries
+      properties:
+        catalogId:
+          type: string
+        sourceCommit:
+          type: string
+        entries:
+          type: array
+          minItems: 1
+          items:
+            $ref: '#/components/schemas/InventoryEntry'

specs/226-astrodeck-inventory-planning/data-model.md

@@ -0,0 +1,103 @@
+# Data Model: AstroDeck Inventory Planning (Website)
+
+## Overview
+
+This feature introduces no database schema. The model defines planning artifacts that describe AstroDeck primitive availability in `apps/website`.
+
+## Entities
+
+### InventoryCatalog
+
+- **Purpose**: Canonical inventory container for one website planning baseline.
+- **Fields**:
+  - `catalog_id` (string, format: `astrodeck-v<YYYY-MM-DD>`, e.g. `astrodeck-v2026-04-22`; use `astrodeck-226-baseline` for the first Spec 226 catalog)
+  - `scope` (fixed: `apps/website`)
+  - `created_at` (ISO datetime)
+  - `source_commit` (git SHA or reference)
+  - `status` (`draft`, `reviewed`, `baselined`)
+- **Relationships**:
+  - Has many `InventoryEntry`
+  - Has one `SuitabilitySummary`
+- **Validation rules**:
+  - Must include entries for all three primitive classes.
+  - Cannot reach `baselined` unless every entry has required attributes and suitability.
+
+### InventoryEntry
+
+- **Purpose**: One documented AstroDeck primitive candidate.
+- **Fields**:
+  - `entry_id` (string, unique within catalog)
+  - `identifier` (human-readable or technical name)
+  - `primitive_class` (`Page`, `Section`, `Component`)
+  - `file_ref` (workspace-relative path)
+  - `functional_role` (string)
+  - `default_semantics` (string)
+  - `default_visual_character` (closed enum: `minimal` | `enterprise-neutral` | `content-heavy` | `bold-visual` | `utility-dense` | `decorative`; add `notes` for anything outside this set)
+  - `tenantatlas_relevance` (`high`, `medium`, `low`, `none`)
+  - `suitability_class` (`A`, `B`, `C`, `D`)
+  - `markers` (string array)
+  - `notes` (optional string)
+- **Relationships**:
+  - Belongs to `InventoryCatalog`
+- **Validation rules**:
+  - Required core fields must be non-empty.
+  - `primitive_class` and `suitability_class` values are constrained.
+  - `markers` must come from allowed marker vocabulary.
+
+### SuitabilitySummary
+
+- **Purpose**: Aggregated view of candidate distribution and risk visibility.
+- **Fields**:
+  - `count_a`, `count_b`, `count_c`, `count_d` (integers)
+  - `risk_visual_count` (integer)
+  - `risk_semantic_count` (integer)
+  - `demo_only_count` (integer)
+  - `surface_candidates` (object keyed by surface: homepage, hero, product, trust, changelog, contact-demo, navigation, footer)
+- **Relationships**:
+  - Belongs to `InventoryCatalog`
+- **Validation rules**:
+  - Aggregate counts must reconcile with `InventoryEntry` rows.
+  - Every required surface key must be present.
+
+### MarkerVocabulary
+
+- **Purpose**: Allowed marker set for consistent tagging.
+- **Allowed values**:
+  - `tenantatlas-likely`
+  - `needs-heavy-adaptation`
+  - `visual-risk`
+  - `semantic-risk`
+  - `demo-only`
+  - `remove-likely`
+  - `hero-candidate`
+  - `trust-candidate`
+  - `navigation-candidate`
+  - `footer-candidate`
+  - `contact-candidate`
+  - `product-explainer-candidate`
+  - `changelog-candidate`
+
+## Primitive Class Mapping
+
+- `Page` — route entrypoints in `apps/website/src/pages/`
+- `Section` — composite sections in `apps/website/src/components/sections/`
+- `Component` — all reusable units across three sub-families:
+  - `primitives/` (structural atoms)
+  - `content/` (semantic content blocks)
+  - `layout/` (shell, navigation, footer) — **layout/ maps to `primitive_class: Component`; there is no fourth primitive class**
+
+## Lifecycle
+
+### Catalog Status Transitions
+
+- `draft` -> `reviewed`
+  - Condition: required fields complete and class coverage verified.
+- `reviewed` -> `baselined`
+  - Condition: suitability summary reconciled and candidate/risk visibility confirmed.
+- `baselined` -> `draft`
+  - Condition: source primitive set changes and inventory requires refresh.
+
+## Derived Rules
+
+- No mapping spec may claim candidate selection without referencing `entry_id` from the active baselined catalog.
+- Non-candidates (`D`) remain first-class records and cannot be hidden from summary outputs.

specs/226-astrodeck-inventory-planning/inventory/catalog.md

@@ -0,0 +1,87 @@
+# AstroDeck Inventory Catalog
+
+- catalog_id: astrodeck-226-baseline
+- scope: apps/website
+- created_at: 2026-04-22T07:52:32Z
+- source_commit: 71f94c3afa897c00f6a8d35b63f40882ae86e348
+- status: reviewed
+- source_file_count: 50
+- inventory_entry_target: 51
+
+## Source Discovery
+
+- discovery_command: `cd apps/website && rg --files src/pages src/components/sections src/components/primitives src/components/content src/components/layout`
+- discovery_commit: `71f94c3afa897c00f6a8d35b63f40882ae86e348`
+- discovery_classification_rule: Each discovered file maps to exactly one primitive class from `Page`, `Section`, or `Component`.
+
+### Pages
+
+- `apps/website/src/pages/changelog.astro`
+- `apps/website/src/pages/contact.astro`
+- `apps/website/src/pages/imprint.astro`
+- `apps/website/src/pages/index.astro`
+- `apps/website/src/pages/integrations.astro`
+- `apps/website/src/pages/legal.astro`
+- `apps/website/src/pages/privacy.astro`
+- `apps/website/src/pages/product.astro`
+- `apps/website/src/pages/security-trust.astro`
+- `apps/website/src/pages/sitemap.xml.ts`
+- `apps/website/src/pages/solutions.astro`
+- `apps/website/src/pages/terms.astro`
+- `apps/website/src/pages/trust.astro`
+
+### Sections
+
+- `apps/website/src/components/sections/CTASection.astro`
+- `apps/website/src/components/sections/CapabilityGrid.astro`
+- `apps/website/src/components/sections/FeatureGrid.astro`
+- `apps/website/src/components/sections/LogoStrip.astro`
+- `apps/website/src/components/sections/OutcomeSection.astro`
+- `apps/website/src/components/sections/PageHero.astro`
+- `apps/website/src/components/sections/ProgressTeaser.astro`
+- `apps/website/src/components/sections/TrustGrid.astro`
+
+### Components
+
+- `apps/website/src/components/primitives/Badge.astro`
+- `apps/website/src/components/primitives/Button.astro`
+- `apps/website/src/components/primitives/Card.astro`
+- `apps/website/src/components/primitives/Cluster.astro`
+- `apps/website/src/components/primitives/Container.astro`
+- `apps/website/src/components/primitives/Grid.astro`
+- `apps/website/src/components/primitives/Input.astro`
+- `apps/website/src/components/primitives/Section.astro`
+- `apps/website/src/components/primitives/SectionHeader.astro`
+- `apps/website/src/components/primitives/Stack.astro`
+- `apps/website/src/components/primitives/Textarea.astro`
+- `apps/website/src/components/content/AudienceRow.astro`
+- `apps/website/src/components/content/Callout.astro`
+- `apps/website/src/components/content/ContactPanel.astro`
+- `apps/website/src/components/content/DemoPrompt.astro`
+- `apps/website/src/components/content/Eyebrow.astro`
+- `apps/website/src/components/content/FeatureItem.astro`
+- `apps/website/src/components/content/Headline.astro`
+- `apps/website/src/components/content/HeroDashboard.astro`
+- `apps/website/src/components/content/IntegrationBadge.astro`
+- `apps/website/src/components/content/Lead.astro`
+- `apps/website/src/components/content/Metric.astro`
+- `apps/website/src/components/content/PrimaryCTA.astro`
+- `apps/website/src/components/content/RichText.astro`
+- `apps/website/src/components/content/SecondaryCTA.astro`
+- `apps/website/src/components/content/TrustPrincipleCard.astro`
+- `apps/website/src/components/layout/Footer.astro`
+- `apps/website/src/components/layout/Navbar.astro`
+- `apps/website/src/components/layout/PageShell.astro`
+
+## Related Layout Dependencies Outside T002 Discovery
+
+- `apps/website/src/layouts/BaseLayout.astro`
+
+BaseLayout is intentionally inventoried because T005 names it explicitly and `PageShell.astro` cannot render without it, even though the quickstart discovery command is limited to `src/pages` and `src/components/*`.
+
+## Reviewer Sign-off
+
+- reviewed_at: 2026-04-22
+- reviewer: Codex
+- summary_reconciled: yes
+- notes: Validated 51 entries across pages, sections, and components; suitability totals and risk counts reconcile with `summary.md`.

specs/226-astrodeck-inventory-planning/inventory/components.md

@@ -0,0 +1,431 @@
+# Component Inventory
+
+- catalog_id: astrodeck-226-baseline
+- primitive_class: Component
+- entry_count: 30
+
+### Primitives
+
+#### component.button
+
+- entry_id: component.button
+- identifier: Button
+- primitive_class: Component
+- file_ref: apps/website/src/components/primitives/Button.astro
+- functional_role: Shared interaction primitive for links and buttons across CTA surfaces.
+- default_semantics: Reusable primary, secondary, or ghost action control with shared size variants.
+- default_visual_character: enterprise-neutral
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely]
+- notes: Foundational CTA primitive used throughout the site shell and surface sections.
+
+#### component.card
+
+- entry_id: component.card
+- identifier: Card
+- primitive_class: Component
+- file_ref: apps/website/src/components/primitives/Card.astro
+- functional_role: Wraps grouped content inside consistent rounded surface treatments.
+- default_semantics: Generic surface container with default, accent, and subtle variants plus optional hover behavior.
+- default_visual_character: enterprise-neutral
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely]
+- notes: Central structural primitive for nearly every section family.
+
+#### component.container
+
+- entry_id: component.container
+- identifier: Container
+- primitive_class: Component
+- file_ref: apps/website/src/components/primitives/Container.astro
+- functional_role: Constrains horizontal width and page gutters.
+- default_semantics: Layout wrapper for content, measure, and wide-width surfaces.
+- default_visual_character: minimal
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely]
+- notes: Core layout primitive that stays valid regardless of final surface composition.
+
+#### component.grid
+
+- entry_id: component.grid
+- identifier: Grid
+- primitive_class: Component
+- file_ref: apps/website/src/components/primitives/Grid.astro
+- functional_role: Provides the standard responsive card and content grid behavior.
+- default_semantics: Responsive grid helper with fixed column presets and shared gap sizing.
+- default_visual_character: minimal
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely]
+- notes: Generic layout utility already proven across product, trust, and contact surfaces.
+
+#### component.stack
+
+- entry_id: component.stack
+- identifier: Stack
+- primitive_class: Component
+- file_ref: apps/website/src/components/primitives/Stack.astro
+- functional_role: Offers vertical spacing control for simple stacked layouts.
+- default_semantics: Flex-column spacing helper with small through extra-large gap presets.
+- default_visual_character: minimal
+- tenantatlas_relevance: medium
+- suitability_class: B
+- markers: []
+- notes: Useful as a narrow layout helper, but it is not currently exercised by the shipped route set.
+
+#### component.section
+
+- entry_id: component.section
+- identifier: Section
+- primitive_class: Component
+- file_ref: apps/website/src/components/primitives/Section.astro
+- functional_role: Normalizes vertical rhythm, tone, and disclosure layering for page sections.
+- default_semantics: Section shell primitive with density, tone, and disclosure-layer options.
+- default_visual_character: minimal
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely]
+- notes: Required base primitive for keeping section spacing and surface shells consistent.
+
+#### component.section-header
+
+- entry_id: component.section-header
+- identifier: SectionHeader
+- primitive_class: Component
+- file_ref: apps/website/src/components/primitives/SectionHeader.astro
+- functional_role: Standardizes eyebrow, headline, and supporting copy for section intros.
+- default_semantics: Content header primitive with alignment and width controls.
+- default_visual_character: enterprise-neutral
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely]
+- notes: Direct fit for any rebuild surface that needs consistent section framing.
+
+#### component.cluster
+
+- entry_id: component.cluster
+- identifier: Cluster
+- primitive_class: Component
+- file_ref: apps/website/src/components/primitives/Cluster.astro
+- functional_role: Groups inline items such as CTA pairs and small metadata sets.
+- default_semantics: Flexible inline cluster helper with gap and justification presets.
+- default_visual_character: minimal
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely]
+- notes: Reusable utility for CTAs, badges, and compact link groups.
+
+#### component.badge
+
+- entry_id: component.badge
+- identifier: Badge
+- primitive_class: Component
+- file_ref: apps/website/src/components/primitives/Badge.astro
+- functional_role: Applies small signal labels for eyebrows, dates, and metadata accents.
+- default_semantics: Pill-style label primitive with accent, neutral, signal, and warm tones.
+- default_visual_character: minimal
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely]
+- notes: Lightweight signaling primitive used in hero, progress, and ecosystem contexts.
+
+#### component.input
+
+- entry_id: component.input
+- identifier: Input
+- primitive_class: Component
+- file_ref: apps/website/src/components/primitives/Input.astro
+- functional_role: Provides a text-input shell for the static contact preview.
+- default_semantics: Single-line form-control primitive with readonly support but no labels, validation, or submission wiring.
+- default_visual_character: utility-dense
+- tenantatlas_relevance: medium
+- suitability_class: B
+- markers: []
+- notes: Structurally reusable, but interactive contact flows would need labels, errors, and submission states layered around it.
+
+#### component.textarea
+
+- entry_id: component.textarea
+- identifier: Textarea
+- primitive_class: Component
+- file_ref: apps/website/src/components/primitives/Textarea.astro
+- functional_role: Provides a multiline text shell for the static contact preview.
+- default_semantics: Multiline form-control primitive with readonly support but no validation or helper-state system.
+- default_visual_character: utility-dense
+- tenantatlas_relevance: medium
+- suitability_class: B
+- markers: []
+- notes: Reusable if the rebuild keeps a preview-only contact pattern; richer interaction would need additional semantics.
+
+### Content
+
+#### component.headline
+
+- entry_id: component.headline
+- identifier: Headline
+- primitive_class: Component
+- file_ref: apps/website/src/components/content/Headline.astro
+- functional_role: Provides the shared heading scale across hero, section, and card contexts.
+- default_semantics: Typography primitive for display, page, section, and card-level headings.
+- default_visual_character: minimal
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely]
+- notes: Core type primitive for the current visual system and likely any close rebuild variant.
+
+#### component.lead
+
+- entry_id: component.lead
+- identifier: Lead
+- primitive_class: Component
+- file_ref: apps/website/src/components/content/Lead.astro
+- functional_role: Renders supporting descriptive copy with a shared size scale.
+- default_semantics: Body-copy primitive for hero, card, and legal-prose support text.
+- default_visual_character: minimal
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely]
+- notes: Generic copy primitive used across every page family.
+
+#### component.eyebrow
+
+- entry_id: component.eyebrow
+- identifier: Eyebrow
+- primitive_class: Component
+- file_ref: apps/website/src/components/content/Eyebrow.astro
+- functional_role: Introduces sections and cards with compact uppercase framing labels.
+- default_semantics: Small-type label primitive with accent, neutral, and signal tones.
+- default_visual_character: minimal
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely]
+- notes: Shared content primitive that anchors information hierarchy without adding structural complexity.
+
+#### component.metric
+
+- entry_id: component.metric
+- identifier: Metric
+- primitive_class: Component
+- file_ref: apps/website/src/components/content/Metric.astro
+- functional_role: Packages hero-supporting metrics into small card surfaces.
+- default_semantics: Metric card with a numeric or label-like headline, eyebrow label, and support copy.
+- default_visual_character: enterprise-neutral
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely, hero-candidate]
+- notes: Directly useful for hero-adjacent proof or product framing when the rebuild keeps quantified support signals.
+
+#### component.primary-cta
+
+- entry_id: component.primary-cta
+- identifier: PrimaryCTA
+- primitive_class: Component
+- file_ref: apps/website/src/components/content/PrimaryCTA.astro
+- functional_role: Wraps the primary button treatment used across hero and closing CTA surfaces.
+- default_semantics: Primary action wrapper with optional helper copy and size variants.
+- default_visual_character: enterprise-neutral
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely]
+- notes: Stable CTA wrapper used across hero, progress, footer, and closing conversion surfaces.
+
+#### component.secondary-cta
+
+- entry_id: component.secondary-cta
+- identifier: SecondaryCTA
+- primitive_class: Component
+- file_ref: apps/website/src/components/content/SecondaryCTA.astro
+- functional_role: Provides the supporting secondary action pattern for route handoffs.
+- default_semantics: Secondary action wrapper with optional helper text and size variants.
+- default_visual_character: enterprise-neutral
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely]
+- notes: Pairs cleanly with the primary CTA pattern and is already part of the approved route handoff model.
+
+#### component.feature-item
+
+- entry_id: component.feature-item
+- identifier: FeatureItem
+- primitive_class: Component
+- file_ref: apps/website/src/components/content/FeatureItem.astro
+- functional_role: Renders feature or rule cards with optional iconography, metadata, and link treatment.
+- default_semantics: Card-based feature explanation primitive for product, solutions, and integration rule surfaces.
+- default_visual_character: enterprise-neutral
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely, product-explainer-candidate]
+- notes: Strong product-explainer building block for any rebuild surface that needs repeatable explanatory cards.
+
+#### component.callout
+
+- entry_id: component.callout
+- identifier: Callout
+- primitive_class: Component
+- file_ref: apps/website/src/components/content/Callout.astro
+- functional_role: Shows compact narrative or trust-supporting callouts in card form.
+- default_semantics: Callout card with optional eyebrow, headline, supporting copy, and tone selection.
+- default_visual_character: enterprise-neutral
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely, trust-candidate]
+- notes: Works well for trust or product-support narratives without demanding a new section pattern.
+
+#### component.rich-text
+
+- entry_id: component.rich-text
+- identifier: RichText
+- primitive_class: Component
+- file_ref: apps/website/src/components/content/RichText.astro
+- functional_role: Renders structured legal or policy prose as a stack of readable cards.
+- default_semantics: Rich text wrapper for titled legal sections with paragraphs and optional bullet lists.
+- default_visual_character: content-heavy
+- tenantatlas_relevance: medium
+- suitability_class: A
+- markers: [tenantatlas-likely]
+- notes: Strong direct-fit primitive for the retained legal and policy routes.
+
+#### component.trust-principle-card
+
+- entry_id: component.trust-principle-card
+- identifier: TrustPrincipleCard
+- primitive_class: Component
+- file_ref: apps/website/src/components/content/TrustPrincipleCard.astro
+- functional_role: Packages trust claims into a consistent proof-card treatment.
+- default_semantics: Trust card with title, supporting copy, and optional note.
+- default_visual_character: enterprise-neutral
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely, trust-candidate]
+- notes: Canonical trust-content primitive already aligned with the explicit trust posture route.
+
+#### component.demo-prompt
+
+- entry_id: component.demo-prompt
+- identifier: DemoPrompt
+- primitive_class: Component
+- file_ref: apps/website/src/components/content/DemoPrompt.astro
+- functional_role: Highlights suggested conversation prompts for the first contact exchange.
+- default_semantics: Simple supporting card for contact/demo preparation prompts.
+- default_visual_character: enterprise-neutral
+- tenantatlas_relevance: medium
+- suitability_class: B
+- markers: [contact-candidate]
+- notes: Useful for the contact path, but it is tied to a specific conversation-prep pattern rather than a universal route need.
+
+#### component.hero-dashboard
+
+- entry_id: component.hero-dashboard
+- identifier: HeroDashboard
+- primitive_class: Component
+- file_ref: apps/website/src/components/content/HeroDashboard.astro
+- functional_role: Supplies the product-near illustrative UI mock used in hero compositions.
+- default_semantics: Decorative but content-bearing product mock that implies change history, restore preview, and review queue behavior.
+- default_visual_character: bold-visual
+- tenantatlas_relevance: high
+- suitability_class: C
+- markers: [needs-heavy-adaptation, visual-risk, hero-candidate]
+- notes: The mock is strongly tied to the current TenantAtlas governance narrative and would require coordinated visual and narrative updates before reuse.
+
+#### component.integration-badge
+
+- entry_id: component.integration-badge
+- identifier: IntegrationBadge
+- primitive_class: Component
+- file_ref: apps/website/src/components/content/IntegrationBadge.astro
+- functional_role: Compresses ecosystem, partner, or integration signals into compact badge cards.
+- default_semantics: Small proof card for ecosystem-fit lists and supporting strips.
+- default_visual_character: enterprise-neutral
+- tenantatlas_relevance: medium
+- suitability_class: C
+- markers: [needs-heavy-adaptation, semantic-risk]
+- notes: Reusable only when the rebuild can substantiate the ecosystem claim; otherwise the component risks overstating platform breadth.
+
+#### component.audience-row
+
+- entry_id: component.audience-row
+- identifier: AudienceRow
+- primitive_class: Component
+- file_ref: apps/website/src/components/content/AudienceRow.astro
+- functional_role: Shows audience-specific fit through bullets and an optional secondary CTA.
+- default_semantics: Audience-fit card primitive used on the solutions route.
+- default_visual_character: enterprise-neutral
+- tenantatlas_relevance: medium
+- suitability_class: B
+- markers: [tenantatlas-likely]
+- notes: Structurally useful, but the audience framing is supporting rather than core to the first-pass route model.
+
+#### component.contact-panel
+
+- entry_id: component.contact-panel
+- identifier: ContactPanel
+- primitive_class: Component
+- file_ref: apps/website/src/components/content/ContactPanel.astro
+- functional_role: Frames qualified outreach with a short list of who should contact the team and one primary CTA.
+- default_semantics: Accent card for the contact route that packages qualification points and a primary action.
+- default_visual_character: enterprise-neutral
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely, contact-candidate]
+- notes: Directly useful for the contact and demo surface because it keeps outreach intent explicit without building a form workflow.
+
+### Layout
+
+#### component.page-shell
+
+- entry_id: component.page-shell
+- identifier: PageShell
+- primitive_class: Component
+- file_ref: apps/website/src/components/layout/PageShell.astro
+- functional_role: Wraps every page with SEO metadata, shell attributes, navigation, and footer.
+- default_semantics: Canonical page-shell orchestrator that binds route metadata to the shared layout and shell components.
+- default_visual_character: enterprise-neutral
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely]
+- notes: Central shell component for any rebuild that preserves the current route architecture.
+
+#### component.navbar
+
+- entry_id: component.navbar
+- identifier: Navbar
+- primitive_class: Component
+- file_ref: apps/website/src/components/layout/Navbar.astro
+- functional_role: Provides the sticky primary navigation with desktop and mobile variants.
+- default_semantics: Top-level navigation shell with brand lockup, route links, and a secondary CTA.
+- default_visual_character: enterprise-neutral
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely, navigation-candidate]
+- notes: Canonical navigation surface for the current website route set.
+
+#### component.footer
+
+- entry_id: component.footer
+- identifier: Footer
+- primitive_class: Component
+- file_ref: apps/website/src/components/layout/Footer.astro
+- functional_role: Provides the closing navigation, trustful footer copy, and final CTA.
+- default_semantics: Footer surface with route-group navigation, lead copy, and a small CTA.
+- default_visual_character: enterprise-neutral
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely, footer-candidate]
+- notes: Canonical footer surface and an explicit part of the rebuild inventory.
+
+#### component.base-layout
+
+- entry_id: component.base-layout
+- identifier: BaseLayout
+- primitive_class: Component
+- file_ref: apps/website/src/layouts/BaseLayout.astro
+- functional_role: Owns the document shell, metadata tags, font includes, and global CSS import.
+- default_semantics: Top-level HTML layout wrapper for the static Astro site.
+- default_visual_character: minimal
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely]
+- notes: Included even though it sits outside the T002 discovery command because PageShell depends on it to render any route.

specs/226-astrodeck-inventory-planning/inventory/mapping-anchors.md

@@ -0,0 +1,39 @@
+# Mapping Anchors
+
+## Mandatory Reference Rule
+
+- No downstream mapping spec may claim a keep, adapt, remove, or replace decision without citing at least one `entry_id` from the active baselined catalog.
+- The active catalog for Spec 226 is `astrodeck-226-baseline` until a later refresh supersedes it.
+- If a downstream spec references a section or component, it should also cite the owning page or surface context when that context changes the decision.
+
+## Recommended Reference Block
+
+Use a concrete inventory block in downstream mapping specs such as `specs/214-website-visual-foundation/`, `specs/215-website-core-pages/`, or `specs/217-homepage-structure/`:
+
+```md
+### Inventory References
+
+- catalog_id: astrodeck-226-baseline
+- selected_entries:
+  - page.product
+  - section.feature-grid
+  - component.feature-item
+- suitability_basis:
+  - page.product: A / high
+  - section.feature-grid: A / high
+  - component.feature-item: A / high
+- decision: adapt
+- rationale: Keep the product-explainer structure but adjust copy hierarchy and visual density for the approved rebuild route.
+```
+
+## Exception Path For Non-Candidate Decisions
+
+- If a downstream surface has no direct candidate, write `no direct candidate` explicitly in the mapping spec and cite the closest rejected `entry_id` values plus the reason they were rejected.
+- If an inventory entry is intentionally excluded, cite the `entry_id`, current `suitability_class`, and the concrete reason for exclusion instead of silently omitting it.
+- If a downstream spec decides a current `A` or `B` entry should still be removed, that spec must document the higher-priority constraint that overrides the inventory suitability.
+
+## Refresh Rule Before The Next Mapping Cycle
+
+- Refresh the inventory whenever the source primitive set changes under `apps/website/src/pages`, `apps/website/src/components`, or `apps/website/src/layouts`.
+- Re-run the T002 discovery command from repo root and compare the resulting file list with `inventory/catalog.md`.
+- If the primitive set changes, update the row-level inventory files, reconcile `summary.md`, and set `catalog.md` back to `draft` until review completes again.

specs/226-astrodeck-inventory-planning/inventory/pages.md

@@ -0,0 +1,187 @@
+# Page Inventory
+
+- catalog_id: astrodeck-226-baseline
+- primitive_class: Page
+- entry_count: 13
+
+### page.index
+
+- entry_id: page.index
+- identifier: index
+- primitive_class: Page
+- file_ref: apps/website/src/pages/index.astro
+- functional_role: Homepage entrypoint that sequences the launch hero, product framing, trust, progress, and contact handoff.
+- default_semantics: Primary marketing route for first-visit orientation and route handoff into product, trust, changelog, and contact.
+- default_visual_character: bold-visual
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely]
+- notes: The current homepage already reflects the canonical TenantAtlas launch journey and is the main reference page for downstream mapping.
+
+### page.product
+
+- entry_id: page.product
+- identifier: product
+- primitive_class: Page
+- file_ref: apps/website/src/pages/product.astro
+- functional_role: Explains the connected product model before the visitor is asked to trust or contact the team.
+- default_semantics: Product explainer route that combines hero framing, feature clusters, narrative callouts, and downstream CTAs.
+- default_visual_character: enterprise-neutral
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely, product-explainer-candidate]
+- notes: Strong direct-fit route for rebuild planning because it already anchors the product explanation in current release truth.
+
+### page.trust
+
+- entry_id: page.trust
+- identifier: trust
+- primitive_class: Page
+- file_ref: apps/website/src/pages/trust.astro
+- functional_role: Dedicated trust posture route for operator safeguards, isolation boundaries, and credibility framing.
+- default_semantics: Trust-first supporting page with one explicit proof surface and a clear contact handoff.
+- default_visual_character: enterprise-neutral
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely, trust-candidate]
+- notes: This is the canonical trust route and should remain explicit in any AstroDeck rebuild plan.
+
+### page.changelog
+
+- entry_id: page.changelog
+- identifier: changelog
+- primitive_class: Page
+- file_ref: apps/website/src/pages/changelog.astro
+- functional_role: Publishes dated product progress so visitors can verify motion without relying on vague marketing claims.
+- default_semantics: Content-led route with a hero, chronologically ordered update cards, and a closing CTA back into evaluation.
+- default_visual_character: content-heavy
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely, changelog-candidate]
+- notes: The route is already aligned with the visible-progress requirement in the active website strategy.
+
+### page.contact
+
+- entry_id: page.contact
+- identifier: contact
+- primitive_class: Page
+- file_ref: apps/website/src/pages/contact.astro
+- functional_role: Qualifies outreach and shows what a serious first conversation should contain before anyone shares sensitive detail.
+- default_semantics: Contact and demo-prep route with guidance cards, a static message preview, legal reassurance, and a CTA handoff.
+- default_visual_character: utility-dense
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely, contact-candidate]
+- notes: Strong fit for rebuild planning because it already combines contact intent, legal reassurance, and route continuity.
+
+### page.solutions
+
+- entry_id: page.solutions
+- identifier: solutions
+- primitive_class: Page
+- file_ref: apps/website/src/pages/solutions.astro
+- functional_role: Shows audience fit and operating-model resonance for deeper evaluators without owning the primary journey.
+- default_semantics: Supporting audience-fit route with hero framing, audience cards, supporting signals, and a closing CTA.
+- default_visual_character: enterprise-neutral
+- tenantatlas_relevance: medium
+- suitability_class: B
+- markers: [tenantatlas-likely]
+- notes: Reusable with limited copy and information-architecture changes, but it should stay subordinate to the primary route set.
+
+### page.integrations
+
+- entry_id: page.integrations
+- identifier: integrations
+- primitive_class: Page
+- file_ref: apps/website/src/pages/integrations.astro
+- functional_role: Documents ecosystem fit and integration direction without pretending broad platform coverage is already launch truth.
+- default_semantics: Supporting ecosystem route with badges, rule cards, and a handoff back into product or contact.
+- default_visual_character: enterprise-neutral
+- tenantatlas_relevance: medium
+- suitability_class: B
+- markers: [tenantatlas-likely]
+- notes: Structurally reusable, but its value depends on keeping ecosystem claims concrete and bounded.
+
+### page.privacy
+
+- entry_id: page.privacy
+- identifier: privacy
+- primitive_class: Page
+- file_ref: apps/website/src/pages/privacy.astro
+- functional_role: Explains the narrow public-site privacy posture and the bounds of inquiry handling.
+- default_semantics: Legal text route with an opening hero, reading-width rich text, and a simple next-step CTA.
+- default_visual_character: content-heavy
+- tenantatlas_relevance: medium
+- suitability_class: B
+- markers: [tenantatlas-likely]
+- notes: Good structural fit for the rebuild, but the content remains jurisdiction- and policy-dependent.
+
+### page.terms
+
+- entry_id: page.terms
+- identifier: terms
+- primitive_class: Page
+- file_ref: apps/website/src/pages/terms.astro
+- functional_role: States the website terms and clarifies that public marketing pages do not replace commercial agreements.
+- default_semantics: Legal text route built from hero, reading-width prose cards, and a closing CTA.
+- default_visual_character: content-heavy
+- tenantatlas_relevance: medium
+- suitability_class: B
+- markers: [tenantatlas-likely]
+- notes: Directly reusable for the legal baseline, with expected copy and jurisdiction updates only.
+
+### page.imprint
+
+- entry_id: page.imprint
+- identifier: imprint
+- primitive_class: Page
+- file_ref: apps/website/src/pages/imprint.astro
+- functional_role: Publishes the public legal-notice baseline for publisher identity and jurisdiction-specific disclosure.
+- default_semantics: Legal notice route with a hero, reading-width legal content, and a return CTA into trust or contact.
+- default_visual_character: content-heavy
+- tenantatlas_relevance: low
+- suitability_class: B
+- markers: [tenantatlas-likely]
+- notes: Useful for the retained legal baseline, but the content remains highly dependent on jurisdiction and publication details.
+
+### page.legal
+
+- entry_id: page.legal
+- identifier: legal
+- primitive_class: Page
+- file_ref: apps/website/src/pages/legal.astro
+- functional_role: Aggregates trust, privacy, terms, and imprint into one retained legal hub route.
+- default_semantics: Secondary legal index page that duplicates links to leaf legal routes and adds a short notice section.
+- default_visual_character: content-heavy
+- tenantatlas_relevance: low
+- suitability_class: C
+- markers: [needs-heavy-adaptation, semantic-risk]
+- notes: The hub risks adding route ambiguity because the leaf legal pages already exist; keep only if the rebuild still needs a legal index.
+
+### page.security-trust
+
+- entry_id: page.security-trust
+- identifier: security-trust
+- primitive_class: Page
+- file_ref: apps/website/src/pages/security-trust.astro
+- functional_role: Preserves a legacy alias by redirecting `/security-trust` to `/trust`.
+- default_semantics: Redirect-only route with no user-facing content surface.
+- default_visual_character: minimal
+- tenantatlas_relevance: low
+- suitability_class: D
+- markers: []
+- notes: Inventory it for route completeness, but exclude it from visual surface selection because it contributes no reusable layout or content pattern.
+
+### page.sitemap-xml
+
+- entry_id: page.sitemap-xml
+- identifier: sitemap.xml
+- primitive_class: Page
+- file_ref: apps/website/src/pages/sitemap.xml.ts
+- functional_role: Exposes a machine-readable sitemap for search crawlers.
+- default_semantics: API-style XML endpoint rather than a human-facing content route.
+- default_visual_character: utility-dense
+- tenantatlas_relevance: none
+- suitability_class: D
+- markers: []
+- notes: Keep visible in the inventory for route governance, but it is not a rebuild candidate for visual or narrative surfaces.

specs/226-astrodeck-inventory-planning/inventory/sections.md

@@ -0,0 +1,117 @@
+# Section Inventory
+
+- catalog_id: astrodeck-226-baseline
+- primitive_class: Section
+- entry_count: 8
+
+### section.page-hero
+
+- entry_id: section.page-hero
+- identifier: PageHero
+- primitive_class: Section
+- file_ref: apps/website/src/components/sections/PageHero.astro
+- functional_role: Renders the primary hero composition for the homepage and all secondary pages.
+- default_semantics: Hero section with badge, headline, supporting copy, CTA cluster, and optional product visual or trust proof.
+- default_visual_character: bold-visual
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely, hero-candidate]
+- notes: This is the most important rebuild primitive because it already defines homepage and subpage hero behavior in one place.
+
+### section.feature-grid
+
+- entry_id: section.feature-grid
+- identifier: FeatureGrid
+- primitive_class: Section
+- file_ref: apps/website/src/components/sections/FeatureGrid.astro
+- functional_role: Presents feature or rule clusters in a repeatable grid with a section header.
+- default_semantics: Product-explainer or rule-list section that relies on structured cards rather than freeform prose.
+- default_visual_character: enterprise-neutral
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely, product-explainer-candidate]
+- notes: Strong direct-fit section for product, solutions, and integrations surfaces.
+
+### section.cta-section
+
+- entry_id: section.cta-section
+- identifier: CTASection
+- primitive_class: Section
+- file_ref: apps/website/src/components/sections/CTASection.astro
+- functional_role: Delivers the final conversion handoff from any route back into contact or the next core page.
+- default_semantics: Closing CTA band with one required primary action and one optional secondary action.
+- default_visual_character: enterprise-neutral
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely, contact-candidate]
+- notes: It appears across the route set and already encodes the preferred evaluation handoff pattern.
+
+### section.capability-grid
+
+- entry_id: section.capability-grid
+- identifier: CapabilityGrid
+- primitive_class: Section
+- file_ref: apps/website/src/components/sections/CapabilityGrid.astro
+- functional_role: Explains the grouped product model through clustered capability cards.
+- default_semantics: Product-explainer section with structured clusters, optional metadata badges, and linked supporting detail.
+- default_visual_character: enterprise-neutral
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely, product-explainer-candidate]
+- notes: Strong fit for any rebuild surface that needs to explain how TenantAtlas capabilities connect.
+
+### section.outcome-section
+
+- entry_id: section.outcome-section
+- identifier: OutcomeSection
+- primitive_class: Section
+- file_ref: apps/website/src/components/sections/OutcomeSection.astro
+- functional_role: Frames product value through outcome cards rather than a feature checklist.
+- default_semantics: Mid-page section with a header plus three outcome cards.
+- default_visual_character: enterprise-neutral
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely]
+- notes: Useful for the homepage because it translates product truth into buyer outcomes without inflating surface complexity.
+
+### section.trust-grid
+
+- entry_id: section.trust-grid
+- identifier: TrustGrid
+- primitive_class: Section
+- file_ref: apps/website/src/components/sections/TrustGrid.astro
+- functional_role: Shows the public trust posture through structured trust-principle cards.
+- default_semantics: Trust-proof section with a header and a fixed card grid.
+- default_visual_character: enterprise-neutral
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely, trust-candidate]
+- notes: Canonical trust section for both the homepage trust block and the dedicated trust route.
+
+### section.logo-strip
+
+- entry_id: section.logo-strip
+- identifier: LogoStrip
+- primitive_class: Section
+- file_ref: apps/website/src/components/sections/LogoStrip.astro
+- functional_role: Displays ecosystem-fit badges or logo-like entries in a compact supporting strip.
+- default_semantics: Supporting proof section that compresses partner, ecosystem, or integration signals into a narrow banner treatment.
+- default_visual_character: decorative
+- tenantatlas_relevance: medium
+- suitability_class: C
+- markers: [needs-heavy-adaptation, semantic-risk]
+- notes: The pattern is reusable only when ecosystem proof is concrete; otherwise it risks overstating breadth and slipping into decorative social proof.
+
+### section.progress-teaser
+
+- entry_id: section.progress-teaser
+- identifier: ProgressTeaser
+- primitive_class: Section
+- file_ref: apps/website/src/components/sections/ProgressTeaser.astro
+- functional_role: Surfaces recent dated progress entries and links back to the full changelog.
+- default_semantics: Changelog teaser section with compact dated cards and one follow-up CTA.
+- default_visual_character: utility-dense
+- tenantatlas_relevance: high
+- suitability_class: A
+- markers: [tenantatlas-likely, changelog-candidate]
+- notes: Directly aligned with the visible-progress requirement for the current website strategy.

specs/226-astrodeck-inventory-planning/inventory/summary.md

@@ -0,0 +1,41 @@
+# Suitability Summary
+
+- catalog_id: astrodeck-226-baseline
+- reconciled_entry_count: 51
+
+## Suitability Distribution
+
+| Class | Count |
+|-------|-------|
+| A | 35 |
+| B | 10 |
+| C | 4 |
+| D | 2 |
+
+## Risk Visibility
+
+| Marker | Count | Entry IDs |
+|--------|-------|-----------|
+| `visual-risk` | 1 | `component.hero-dashboard` |
+| `semantic-risk` | 3 | `page.legal`, `section.logo-strip`, `component.integration-badge` |
+| `demo-only` | 0 | `none` |
+
+## Surface Candidate Visibility
+
+| Surface | Candidate entry_ids | Notes |
+|---------|---------------------|-------|
+| homepage | `page.index`, `section.page-hero`, `section.outcome-section`, `section.capability-grid`, `section.trust-grid`, `section.progress-teaser`, `section.cta-section` | Current MarkerVocabulary has no dedicated `homepage-candidate` tag, so homepage visibility is tracked in this summary only. |
+| hero | `section.page-hero`, `component.hero-dashboard`, `component.metric` | All non-homepage entries in this row carry `hero-candidate`. |
+| product | `page.product`, `section.capability-grid`, `section.feature-grid`, `component.feature-item` | All non-page entries in this row carry `product-explainer-candidate`. |
+| trust | `page.trust`, `section.trust-grid`, `component.trust-principle-card`, `component.callout` | All supporting entries in this row carry `trust-candidate`. |
+| changelog | `page.changelog`, `section.progress-teaser` | Supporting section carries `changelog-candidate`. |
+| contact-demo | `page.contact`, `section.cta-section`, `component.contact-panel`, `component.demo-prompt` | Supporting entries in this row carry `contact-candidate`. |
+| navigation | `component.navbar` | Canonical navigation surface. |
+| footer | `component.footer` | Canonical footer surface. |
+
+## Reconciliation Notes
+
+- Pages: 13 entries (`A=5`, `B=5`, `C=1`, `D=2`)
+- Sections: 8 entries (`A=7`, `B=0`, `C=1`, `D=0`)
+- Components: 30 entries (`A=23`, `B=5`, `C=2`, `D=0`)
+- Non-candidates remain visible in the row-level inventory instead of being omitted from the summary.

specs/226-astrodeck-inventory-planning/plan.md

@@ -0,0 +1,187 @@
+# Implementation Plan: AstroDeck Inventory Planning for Website Rebuild
+
+**Branch**: `226-astrodeck-inventory-planning` | **Date**: 2026-04-22 | **Spec**: `specs/226-astrodeck-inventory-planning/spec.md`
+**Input**: Feature specification from `specs/226-astrodeck-inventory-planning/spec.md`
+
+**Note**: This template is filled in by the `/speckit.plan` command. See `.specify/scripts/` for helper scripts.
+
+## Summary
+
+- Establish a mandatory, repository-referenceable AstroDeck inventory for `apps/website` before any new AstroDeck-based rebuild mapping or task planning.
+- Cover all three primitive classes (`Page`, `Section`, `Component`) with unified required attributes, suitability grading, relevance scoring, and risk/candidate markers.
+- Keep this feature documentation-only and workspace-local: no runtime route changes, no platform coupling, no new persistence.
+- Produce design artifacts (`research.md`, `data-model.md`, `contracts/`, `quickstart.md`) that make follow-up mapping specs (214/215/217 alignment work) deterministic and auditable.
+
+## Technical Context
+
+**Language/Version**: Markdown artifacts + Astro 6.0.0 + TypeScript 5.9 context for source discovery  
+**Primary Dependencies**: Repository spec workflow (`.specify`), Astro website source tree under `apps/website/src`, existing component taxonomy (`primitives`, `content`, `sections`, `layout`)  
+**Storage**: Filesystem only (`specs/226-astrodeck-inventory-planning/*`)  
+**Testing**: Documentation quality checks + structural completeness review (no runtime test suite changes)  
+**Validation Lanes**: N/A (docs-only planning artifact)  
+**Target Platform**: Monorepo planning workflow with website scope limited to `apps/website`  
+**Project Type**: Web documentation and planning spec (no executable feature code)  
+**Performance Goals**: Inventory must be complete enough to avoid ad-hoc primitive selection and support deterministic mapping decisions  
+**Constraints**: Must remain strictly local to `apps/website`; must capture demo-only and non-candidate primitives; must not pre-commit final mapping choices; must not introduce backend/runtime changes  
+**Scale/Scope**: Current website primitive landscape spans page entry routes in `apps/website/src/pages`, section composites in `apps/website/src/components/sections`, and component primitives/content/layout in `apps/website/src/components/*`
+
+## UI / Surface Guardrail Plan
+
+- **Guardrail scope**: no operator-facing surface change
+- **Native vs custom classification summary**: N/A
+- **Shared-family relevance**: none
+- **State layers in scope**: none
+- **Handling modes by drift class or surface**: N/A
+- **Repository-signal treatment**: report-only (spec artifacts)
+- **Special surface test profiles**: N/A
+- **Required tests or manual smoke**: N/A
+- **Exception path and spread control**: none
+- **Active feature PR close-out entry**: Guardrail
+
+## Constitution Check
+
+*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
+
+- Inventory-first: Pass. This feature explicitly enforces inventory-before-mapping as the primary rule.
+- Read/write separation: Pass. No write flow, no queue/scheduler, no operational mutation path.
+- Graph contract path: N/A. No Microsoft Graph calls.
+- Deterministic capabilities: N/A. No capability resolver or runtime authorization semantics added.
+- RBAC-UX and workspace/tenant isolation rules: N/A for runtime; this is repository planning documentation only.
+- Run observability / Ops-UX: N/A. No `OperationRun` introduced.
+- Data minimization: Pass. Only planning metadata; no secrets, no tenant records.
+- Test governance (TEST-GOV-001): Pass with docs-only classification and explicit N/A lane decision.
+- Proportionality and no premature abstraction: Pass. Adds only a narrow inventory taxonomy needed for immediate follow-up specs.
+- Persisted truth and behavioral state: Pass. No DB entity/state machine added.
+- UI semantics and layer control: Pass. No new runtime UI semantic framework; taxonomy remains spec-local.
+- Filament/operator surface rules: N/A.
+- Spec discipline/bloat check: Pass. Taxonomy is scoped to this feature and documented with explicit non-goals.
+
+Status: ✅ Constitution gate passed for Phase 0.
+
+## Test Governance Check
+
+- **Test purpose / classification by changed surface**: N/A (docs-only)
+- **Affected validation lanes**: N/A
+- **Why this lane mix is the narrowest sufficient proof**: No runtime behavior changes; quality is proven via artifact completeness and reviewable structure.
+- **Narrowest proving command(s)**: N/A
+- **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**: N/A
+- **Closing validation and reviewer handoff**: Reviewers verify required sections, no unresolved clarification markers, and contract/data-model consistency.
+- **Budget / baseline / trend follow-up**: none
+- **Review-stop questions**: Are all primitive classes covered? Are risks and non-candidates visible? Are follow-up specs able to reference concrete inventory IDs?
+- **Escalation path**: document-in-feature
+- **Active feature PR close-out entry**: Guardrail
+- **Why no dedicated follow-up spec is needed**: This planning unit is itself the prerequisite contract; runtime work comes in later mapping/implementation specs.
+
+## Project Structure
+
+### Documentation (this feature)
+
+```text
+specs/226-astrodeck-inventory-planning/
+├── plan.md
+├── research.md
+├── data-model.md
+├── quickstart.md
+├── contracts/
+│   └── astrodeck-inventory.logical.openapi.yaml
+└── tasks.md
+```
+
+### Source Code (repository root)
+
+```text
+apps/website/
+├── src/
+│   ├── pages/                    # Astro page entrypoints (inventory class: Page)
+│   ├── components/
+│   │   ├── sections/             # Composite sections (inventory class: Section)
+│   │   ├── primitives/           # Structural primitives (inventory class: Component)
+│   │   ├── content/              # Semantic content components (inventory class: Component)
+│   │   └── layout/               # Shell/navigation/footer components (inventory class: Component)
+│   ├── content/                  # Route content definitions used for semantic context
+│   ├── styles/
+│   └── types/
+└── tests/
+    └── smoke/
+```
+
+**Structure Decision**: Keep all implementation planning local to `apps/website` and derive inventory artifacts directly from current page/component directories without introducing a new shared package or backend service.
+
+## Complexity Tracking
+
+None.
+
+## Proportionality Review
+
+- **Current operator problem**: Rebuild decisions cannot be audited or reproduced when AstroDeck primitive availability is undocumented.
+- **Existing structure is insufficient because**: Existing website specs define desired outcomes but not a complete primitive candidate universe.
+- **Narrowest correct implementation**: A mandatory inventory contract with required attributes, suitability classes, and candidate/risk markers.
+- **Ownership cost created**: Ongoing updates when primitives change; review overhead to keep mappings anchored to inventory references.
+- **Alternative intentionally rejected**: Ad-hoc mapping without inventory, because it hides omissions and increases rework risk.
+- **Release truth**: Current-release truth.
+
+*Full BLOAT-001 proportionality review (6 questions) is answered in `specs/226-astrodeck-inventory-planning/spec.md` under "Proportionality Review". The new cross-domain taxonomy (Suitability Class, MarkerVocabulary, Primitive Class, TenantAtlas Relevance) is flagged as "New cross-domain UI framework/taxonomy: yes" with all six BLOAT-001 questions answered there.*
+
+## Phase 0 — Outline & Research (complete)
+
+- Output: `specs/226-astrodeck-inventory-planning/research.md`
+- Unknowns resolved:
+  - Concrete primitive discovery boundaries in `apps/website` (`pages`, `sections`, `components` families).
+  - Practical inventory schema pattern that supports future mapping specs.
+  - Risk/candidate marker strategy that keeps non-candidates visible.
+- Key decisions captured:
+  - Use repository-derived component taxonomy as inventory source of truth.
+  - Keep inventory neutral (candidate visibility without premature selection).
+  - Standardize suitability classes A/B/C/D and relevance levels high/medium/low/none.
+  - Include demo-only/template-only artifacts explicitly.
+
+## Phase 1 — Design & Contracts (complete)
+
+### Data model
+
+- Output: `specs/226-astrodeck-inventory-planning/data-model.md`
+- Defines inventory entities, required attributes, marker vocabulary, and lifecycle/status rules for planning governance.
+
+### Design contract
+
+- Output: `specs/226-astrodeck-inventory-planning/contracts/astrodeck-inventory.logical.openapi.yaml`
+- Logical contract for inventory ingestion/query/reporting workflows that follow-up mapping specs can consume.
+
+### Quickstart
+
+- Output: `specs/226-astrodeck-inventory-planning/quickstart.md`
+- Documents the concrete process to generate and validate the inventory from `apps/website` source paths.
+
+### Agent context update
+
+- Completed via `.specify/scripts/bash/update-agent-context.sh copilot`.
+
+### Constitution re-check (post-design)
+
+- ✅ Still docs-only and workspace-scoped.
+- ✅ No runtime mutation, no Graph, no new persistence.
+- ✅ Proportionality remains narrow and directly tied to current follow-up mapping needs.
+- ✅ No guardrail regressions introduced.
+
+## Phase 2 — Implementation Plan (next)
+
+### Story 1 (P1): Build complete primitive inventory
+
+- Enumerate all relevant Astro page entrypoints, section composites, and component families from `apps/website/src`.
+- Capture mandatory fields per entry (identifier, class, role, semantics, visual character, relevance, suitability).
+- Ensure demo/template-only entries are included and marked.
+
+### Story 2 (P1): Add suitability and risk classification
+
+- Apply A/B/C/D suitability classes and relevance grading to every entry.
+- Add marker tags (`tenantatlas-likely`, `visual-risk`, `semantic-risk`, `demo-only`, etc.) where applicable.
+- Publish suitability overview and candidate visibility slices for homepage/hero/product/trust/changelog/contact/navigation/footer.
+
+### Story 3 (P2): Anchor follow-up mappings to inventory
+
+- Require mapping specs (214/215/217 follow-ups) to reference concrete inventory entry identifiers.
+- Document exception path for remove/non-candidate decisions.
+- Keep inventory updated as primitives evolve to preserve planning determinism.

specs/226-astrodeck-inventory-planning/quickstart.md

@@ -0,0 +1,114 @@
+# Quickstart: AstroDeck Inventory Planning (Spec 226)
+
+## Purpose
+
+Create a complete, mapping-ready AstroDeck inventory for `apps/website` before any rebuild mapping or task re-planning.
+
+## Preconditions
+
+- Work from branch `226-astrodeck-inventory-planning`.
+- Keep scope strictly inside `apps/website`.
+- Do not make final keep/adapt/remove decisions in this step.
+
+## Step 1: Discover primitive candidates from source paths
+
+From repository root:
+
+```bash
+cd apps/website
+rg --files src/pages src/components/sections src/components/primitives src/components/content src/components/layout
+```
+
+Classify files into:
+
+- `Page`: route entrypoints in `src/pages`
+- `Section`: composites in `src/components/sections`
+- `Component`: reusable units in `src/components/primitives`, `src/components/content`, `src/components/layout`
+
+## Step 2: Build inventory entries
+
+For each candidate, capture required attributes (satisfies FR-002 and FR-008):
+
+- `identifier`
+- `primitive_class`
+- `file_ref`
+- `functional_role`
+- `default_semantics`
+- `default_visual_character`
+- `tenantatlas_relevance` (`high|medium|low|none`)
+- `suitability_class` (`A|B|C|D`)
+
+### Suitability Decision Rubric (FR-008: Bewertungslogik)
+
+Apply the following criteria consistently across all entries. Consider structure, semantics, rework effort, risk, and reuse potential:
+
+| Class | Meaning | Typical signals |
+|-------|---------|-----------------|
+| **A** | Directly reusable as-is for TenantAtlas | Matches enterprise-neutral semantics, no rework needed, no visual/semantic risk |
+| **B** | Reusable with minor TenantAtlas adaptation | Needs copy/color/layout tweaks but structural fit is good; low risk |
+| **C** | Reusable only with significant rework | Semantic mismatch, heavy visual risk, or complex structural changes required |
+| **D** | Not suitable for TenantAtlas use | Wrong domain semantics, demo-only purpose, or fundamentally incompatible design |
+
+### Marker Application Rules
+
+Markers are applied per-entry from the allowed `MarkerVocabulary`. Minimum required marker rules:
+
+- `demo-only` — **required** if the entry has `suitability_class: D` and its purpose is demo/template-only
+- `visual-risk` — **required** if `suitability_class` is C and the notes mention visual incompatibility
+- `semantic-risk` — **required** if `suitability_class` is C and the notes mention semantic mismatch
+- Surface candidate markers (`hero-candidate`, `trust-candidate`, etc.) — **required** if the entry appears in a surface's candidate list in summary.md
+
+All other markers are optional and additive.
+
+Add markers where applicable:
+
+- `tenantatlas-likely`
+- `needs-heavy-adaptation`
+- `visual-risk`
+- `semantic-risk`
+- `demo-only`
+- `remove-likely`
+- `hero-candidate`
+- `trust-candidate`
+- `navigation-candidate`
+- `footer-candidate`
+- `contact-candidate`
+- `product-explainer-candidate`
+- `changelog-candidate`
+
+## Step 3: Produce summary visibility
+
+Compute and document:
+
+- Suitability distribution (`A/B/C/D`)
+- Risk visibility counts (`visual-risk`, `semantic-risk`, `demo-only`)
+- Candidate visibility for:
+  - homepage
+  - hero
+  - product
+  - trust
+  - changelog
+  - contact/demo
+  - navigation
+  - footer
+
+## Step 4: Validate spec acceptance alignment
+
+Confirm:
+
+- All three classes (`Page`, `Section`, `Component`) are present.
+- No entry misses required fields.
+- Non-candidates are visible, not omitted.
+- Inventory remains neutral and does not pre-empt mapping decisions.
+
+## Step 5: Prepare downstream mapping handoff
+
+Use stable `entry_id` references for follow-up specs and tasks so mapping choices and exceptions can be traced back to this inventory baseline.
+
+## Done Criteria
+
+The quickstart execution is complete when:
+
+- Inventory artifacts satisfy Spec 226 AC1-AC7.
+- Suitability and candidate/risk summaries are present and coherent.
+- Follow-up mapping specs can consume inventory IDs without ambiguity.

specs/226-astrodeck-inventory-planning/research.md

@@ -0,0 +1,56 @@
+# Research: AstroDeck Inventory Planning for Website Rebuild
+
+## Decision 1: Inventory source boundaries are directory-driven and explicit
+
+- **Decision**: Use current `apps/website/src` structure as the mandatory discovery boundary:
+  - `src/pages` -> `Page` primitives
+  - `src/components/sections` -> `Section` primitives
+  - `src/components/primitives`, `src/components/content`, `src/components/layout` -> `Component` primitives
+- **Rationale**: This matches how the website is already authored and prevents hidden omissions.
+- **Alternatives considered**:
+  - Inventory only referenced components in current routes: rejected because it misses available but currently unused candidates.
+  - Inventory from screenshots/manual browsing only: rejected because it is incomplete and non-deterministic.
+
+## Decision 2: Include demo/template artifacts as first-class inventory entries
+
+- **Decision**: Mark template/demo artifacts explicitly (e.g., `demo-only`) instead of excluding them.
+- **Rationale**: Excluding them early hides available options and weakens auditability of later keep/adapt/remove decisions.
+- **Alternatives considered**:
+  - Exclude demo components from inventory: rejected because it creates selective inventory bias.
+
+## Decision 3: Suitability classes must be mandatory and exhaustive
+
+- **Decision**: Every inventory entry receives exactly one suitability class:
+  - `A` strong candidate
+  - `B` adaptable candidate
+  - `C` weak candidate
+  - `D` non-candidate
+- **Rationale**: Follow-up mapping specs require deterministic triage and cannot rely on narrative-only judgments.
+- **Alternatives considered**:
+  - Optional suitability scoring: rejected because it creates inconsistent coverage across entries.
+
+## Decision 4: Risk and candidate markers are additive, not substitutive
+
+- **Decision**: Marker tags (e.g., `visual-risk`, `semantic-risk`, `hero-candidate`, `trust-candidate`) augment but do not replace required fields.
+- **Rationale**: Tags improve queryability for later mapping while preserving normalized core attributes.
+- **Alternatives considered**:
+  - Use markers only, skip required fields: rejected because it is too ambiguous for cross-spec traceability.
+
+## Decision 5: Inventory output must be mapping-consumable by contract
+
+- **Decision**: Define a logical OpenAPI contract for inventory publication and summary retrieval so downstream specs can reference stable structures.
+- **Rationale**: A contractized shape increases consistency for future tasks and automation without introducing runtime implementation in this feature.
+- **Alternatives considered**:
+  - Freeform markdown only: rejected because downstream mapping extraction becomes error-prone.
+
+## Decision 6: Existing repo patterns favor normalized inventories with explicit classes
+
+- **Decision**: Mirror existing repository planning patterns by using normalized entity fields, explicit classifications, and deterministic summaries.
+- **Rationale**: Prior specs (`040`, `042`, `045`) consistently model inventory-like domains with strict fields and taxonomy semantics.
+- **Alternatives considered**:
+  - Introduce a novel inventory schema unrelated to existing specs: rejected because it adds unnecessary cognitive overhead.
+
+## Resolved Clarifications
+
+- No unresolved `NEEDS CLARIFICATION` items remain.
+- The technical stack and boundaries are sufficient for Phase 1 artifact design.

specs/226-astrodeck-inventory-planning/spec.md

@@ -0,0 +1,214 @@
+# Feature Specification: AstroDeck Inventory Planning for Website Rebuild
+
+**Feature Branch**: `226-astrodeck-inventory-planning`  
+**Created**: 2026-04-22  
+**Status**: Draft  
+**Input**: User description: "Spec 226 - apps/website AstroDeck Inventory for Strict Rebuild Planning"
+
+## Spec Candidate Check *(mandatory — SPEC-GATE-001)*
+
+- **Problem**: Das Team kann AstroDeck-Konformitat bei der Website-Re-Planung nicht belastbar nachweisen, weil ein systematisches Primitive-Inventar fehlt.
+- **Today's failure**: AstroDeck wird unscharf referenziert, Kandidaten werden opportunistisch gewahlt, und wichtige oder unpassende Primitives bleiben unsichtbar.
+- **User-visible improvement**: Folge-Specs und Rebuild-Tasks werden konsistent, nachvollziehbar und auditierbar, weil jede Auswahl auf dokumentierten Kandidaten basiert.
+- **Smallest enterprise-capable version**: Ein vollstandiges, referenzierbares Inventory fur Pages, Sections und Components mit einheitlicher Klassifikation, Eignung und Risiko-Sichtbarkeit.
+- **Explicit non-goals**: Keine finale Primitive-Auswahl je TenantAtlas-Seite, keine Umsetzung von UI-Seiten, keine Copy-Arbeit, keine Plattform- oder Backend-Themen.
+- **Permanent complexity imported**: Neue Inventar-Taxonomie (Primitive Class, Suitability Class, Relevance, Markierungen) und Pflegeaufwand fur die Inventardokumentation.
+- **Why now**: Nach dem AstroDeck-Bindungsentscheid muss vor jedem weiteren Mapping die verfugbare Primitive-Landschaft explizit gemacht werden, sonst droht Greenfield-Drift.
+- **Why not local**: Eine schmale lokale Notiz lost weder die Vollstandigkeitsanforderung noch die Wiederverwendbarkeit fur Folge-Specs und Task-Planung.
+- **Approval class**: Core Enterprise
+- **Red flags triggered**: Scope creep in Mapping-Phase; verdeckte Ausnahmen ohne Inventarspur.
+- **Score**: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitat: 1 | Produktnahe: 2 | Wiederverwendung: 2 | **Gesamt: 11/12**
+- **Decision**: approve
+
+## Spec Scope Fields *(mandatory)*
+
+- **Scope**: workspace
+- **Primary Routes**: Keine runtime-Route-Anderung; betroffen sind Website-Rebuild-Planungsartefakte fur `apps/website`.
+- **Data Ownership**: Repository-Dokumentation auf Workspace-Ebene; keine tenant-owned Records.
+- **RBAC**: N/A - keine Laufzeit- oder Berechtigungsanderung.
+
+For canonical-view specs, the spec MUST define:
+
+- **Default filter behavior when tenant-context is active**: N/A
+- **Explicit entitlement checks preventing cross-tenant leakage**: N/A
+
+## UI / Surface Guardrail Impact *(mandatory when operator-facing surfaces are changed; otherwise write `N/A`)*
+
+N/A - no operator-facing surface change
+
+| Surface / Change | Operator-facing surface change? | Native vs Custom | Shared-Family Relevance | State Layers Touched | Exception Needed? | Low-Impact / `N/A` Note |
+|---|---|---|---|---|---|---|
+| AstroDeck inventory documentation for `apps/website` | no | N/A | none | none | no | `N/A - planning artifact only` |
+
+## Decision-First Surface Role *(mandatory when operator-facing surfaces are changed)*
+
+N/A - no operator-facing surface change
+
+## UI/UX Surface Classification *(mandatory when operator-facing surfaces are changed)*
+
+N/A - no operator-facing surface change
+
+## Operator Surface Contract *(mandatory when operator-facing surfaces are changed)*
+
+N/A - no operator-facing surface change
+
+## Proportionality Review *(mandatory when structural complexity is introduced)*
+
+- **New source of truth?**: no
+- **New persisted entity/table/artifact?**: no
+- **New abstraction?**: no
+- **New enum/state/reason family?**: no
+- **New cross-domain UI framework/taxonomy?**: yes (Dokumentations-Taxonomie fur Inventarbewertung)
+- **Current operator problem**: Teams konnen Rebuild-Entscheidungen nicht konsistent begrunden, weil AstroDeck-Kandidaten nicht vollstandig sichtbar sind.
+- **Existing structure is insufficient because**: Bestehende Spezifikationen beschreiben Ziele und Seiten, aber nicht die vollstandige Primitive-Ausgangslage.
+- **Narrowest correct implementation**: Ein verpflichtendes Inventar mit klaren Pflichtattributen, Eignungsklassen und Markierungen ohne Implementierungsentscheidungen.
+- **Ownership cost**: Laufender Aufwand fur Pflege und Aktualisierung des Inventars vor Folge-Mappings.
+- **Alternative intentionally rejected**: Ad-hoc Mapping ohne Inventar, weil es zu intransparenter Auswahl und hoher Rework-Wahrscheinlichkeit fuhrt.
+- **Release truth**: Current-release truth
+
+### Compatibility posture
+
+This feature assumes a pre-production environment.
+
+Backward compatibility, legacy aliases, migration shims, historical fixtures, and compatibility-specific tests are out of scope unless explicitly required by this spec.
+
+Canonical replacement is preferred over preservation.
+
+## Testing / Lane / Runtime Impact *(mandatory for runtime behavior changes)*
+
+- **Test purpose / classification**: N/A (Spezifikations- und Planungsarbeit ohne Runtime-Anderung)
+- **Validation lane(s)**: N/A
+- **Why this classification and these lanes are sufficient**: Die Anderung erzeugt keine ausfuhrbare Laufzeitlogik; Qualitat wird uber Spezifikationsvollstandigkeit und Checkliste validiert.
+- **New or expanded test families**: none
+- **Fixture / helper cost impact**: none
+- **Heavy-family visibility / justification**: none
+- **Special surface test profile**: N/A
+- **Standard-native relief or required special coverage**: ordinary feature coverage only
+- **Reviewer handoff**: Reviewer bestatigen Vollstandigkeit des Inventarrahmens, fehlende Implementierungsdetails und messbare Erfolgskriterien.
+- **Budget / baseline / trend impact**: none
+- **Escalation needed**: none
+- **Active feature PR close-out entry**: Guardrail
+- **Planned validation commands**: none (Dokumentenreview)
+
+## User Scenarios & Testing *(mandatory)*
+
+### User Story 1 - Vollstandiges Primitive-Inventar erstellen (Priority: P1)
+
+Als Planungsverantwortliche Person fur den Website-Rebuild will ich eine vollstandige Liste der verfugbaren AstroDeck Pages, Sections und Components haben, damit ich jede nachgelagerte Mapping-Entscheidung auf nachweisbarer Verfugbarkeit basieren kann.
+
+**Why this priority**: Ohne Vollstandigkeit ist jede weitere Re-Planung fachlich unsicher und nicht AstroDeck-konform.
+
+**Independent Test**: Kann eigenstandig gepruft werden, indem die drei Inventarlisten vorliegen und jeder Eintrag die Pflichtattribute enthalt.
+
+**Acceptance Scenarios**:
+
+1. **Given** eine AstroDeck-basierte Re-Planung startet, **When** das Inventar erstellt wird, **Then** existieren getrennte und dokumentierte Listen fur Pages, Sections und Components.
+2. **Given** ein Inventareintrag wird gepruft, **When** Pflichtattribute kontrolliert werden, **Then** sind Identifier, Primitive Class, Functional Role, Default Semantics, Default Visual Character, TenantAtlas Relevance und Suitability Class vorhanden.
+
+---
+
+### User Story 2 - Kandidaten und Risiken sichtbar machen (Priority: P1)
+
+Als Spezifikationsverantwortliche Person will ich starke, anpassbare, schwache und ungeeignete Kandidaten inklusive Risiko-Markierungen sehen, damit die Folge-Specs transparent begrundete Auswahlentscheidungen treffen konnen.
+
+**Why this priority**: Sichtbarkeit von Risiken und Nicht-Kandidaten verhindert verzerrte Auswahl und verdeckte Auslassungen.
+
+**Independent Test**: Kann eigenstandig gepruft werden, indem die Suitability-Distribution und Risiko-Markierungen im Inventar nachvollziehbar ausgewiesen sind.
+
+**Acceptance Scenarios**:
+
+1. **Given** das Inventar liegt vor, **When** die Eignung gepruft wird, **Then** jeder Eintrag ist einer Klasse A bis D zugeordnet.
+2. **Given** semantisch oder visuell riskante Primitives existieren, **When** das Inventar gelesen wird, **Then** diese sind explizit markiert statt stillschweigend entfernt.
+
+---
+
+### User Story 3 - Folge-Specs belastbar vorbereiten (Priority: P3)
+
+Als Autorin oder Autor nachgelagerter Mapping-Specs will ich auf das Inventory referenzieren konnen, damit neue Tasks und Ausnahmen konsistent, wiederholbar und auditierbar geplant werden.
+
+**Why this priority**: Der Nutzen des Inventars entsteht erst, wenn Folge-Specs es als verpflichtende Grundlage verwenden.
+
+**Independent Test**: Kann eigenstandig gepruft werden, indem Folge-Specs eindeutige Inventarreferenzen fur Auswahl- und Ausnahmeentscheidungen nutzen.
+
+**Acceptance Scenarios**:
+
+1. **Given** eine Folge-Spec wird erstellt, **When** Primitive-Mapping dokumentiert wird, **Then** die Entscheidung verweist auf konkrete Inventareintrage und deren Eignung.
+
+### Edge Cases
+
+- Was passiert, wenn ein AstroDeck-Primitive mehrdeutig zwischen Section und Component einzuordnen ist? Es MUSS eine klare Primarklasse dokumentiert und die Mehrdeutigkeit im Eintrag vermerkt werden.
+- Was passiert, wenn eine vermeintlich irrelevante Demo-Seite spater als Vorlage nutzbar ist? Sie MUSS trotzdem inventarisiert werden und darf nicht durch vorzeitiges Filtering verloren gehen.
+- Was passiert, wenn in kurzer Zeit neue AstroDeck-Primitives hinzugefugt werden? Das Inventar MUSS vor nachsten Mapping-Entscheidungen aktualisiert werden.
+
+### Assumptions & Dependencies
+
+- Die AstroDeck-Bindung fur den Website-Rebuild gilt bereits als gesetzt (Referenz: vorangehender Bindungsentscheid).
+- Folge-Specs fur Mapping und Task-Planung konsumieren das Inventory als verpflichtende Eingabe.
+- Inventarisierung bezieht sich strikt auf den Scope `apps/website` und schlieBt Plattform-Surfaces aus.
+
+## Requirements *(mandatory)*
+
+**Constitution alignment (required):** Nicht anwendbar, da keine Microsoft-Graph-Aufrufe, keine Runtime-Mutation und keine long-running Operations eingefuhrt werden.
+
+**Constitution alignment (PROP-001 / ABSTR-001 / PERSIST-001 / STATE-001 / BLOAT-001):** Nur Dokumentations-Taxonomie; keine neue Laufzeitpersistenz, keine Runtime-Abstraktionsschicht, keine neuen produktiven Zustandsmaschinen.
+
+**Constitution alignment (TEST-GOV-001):** Runtime-Tests nicht erforderlich; der Nachweis erfolgt uber Vollstandigkeit, Eindeutigkeit und Messbarkeit der Spezifikationsartefakte.
+
+**Constitution alignment (OPS-UX):** N/A
+
+**Constitution alignment (RBAC-UX):** N/A
+
+**Constitution alignment (OPS-EX-AUTH-001):** N/A
+
+**Constitution alignment (BADGE-001):** N/A
+
+**Constitution alignment (UI-FIL-001):** N/A
+
+**Constitution alignment (UI-NAMING-001):** N/A
+
+**Constitution alignment (DECIDE-001):** N/A
+
+**Constitution alignment (UI-CONST-001 / UI-SURF-001 / ACTSURF-001 / UI-HARD-001 / UI-EX-001 / UI-REVIEW-001 / HDR-001):** N/A
+
+**Constitution alignment (ACTSURF-001 - action hierarchy):** N/A
+
+**Constitution alignment (OPSURF-001):** N/A
+
+**Constitution alignment (UI-SEM-001 / LAYER-001 / TEST-TRUTH-001):** N/A
+
+**Constitution alignment (Filament Action Surfaces):** N/A
+
+**Constitution alignment (UX-001 — Layout & Information Architecture):** N/A
+
+### Functional Requirements
+
+- **FR-001**: Das System der Rebuild-Planung MUSS vor jeder AstroDeck-basierten Re-Planung von `apps/website` ein dokumentiertes Inventory fur Pages, Sections und Components verlangen. Das Inventory MUSS als strukturierte, repository-referenzierbare Dokumentation vorliegen; rein implizites Wissen oder unstrukturierte Screenshots sind ausgeschlossen.
+- **FR-002**: Das Inventory MUSS fur jeden Eintrag mindestens Identifier, Primitive Class, Functional Role, Default Semantics, Default Visual Character, TenantAtlas Relevance und Suitability Class enthalten.
+- **FR-003**: Das Inventory MUSS Pages, Sections und Components als getrennte Klassen dokumentieren und als eigenstandige Listen auswertbar machen.
+- **FR-004**: Das Inventory MUSS pro Eintrag eine vorlaufige Eignung in Klasse A, B, C oder D enthalten.
+- **FR-005**: Das Inventory MUSS auch ungeeignete, risikoreiche oder demo-only Primitives sichtbar halten und darf diese nicht stillschweigend auslassen.
+- **FR-006**: Das Inventory MUSS TenantAtlas-Relevanz pro Eintrag als hohe, mittlere, geringe oder keine Relevanz erfassen.
+- **FR-007**: Das Inventory MUSS die Candidate Visibility fur Homepage, Hero, Product, Trust, Changelog, Contact/Demo, Navigation und Footer explizit ausweisbar machen.
+- **FR-008**: Das Inventory MUSS eine dokumentierte Bewertungslogik enthalten, die Struktur, Semantik, Rework-Aufwand, Risiko und Reuse-Potenzial je Primitive berucksichtigt.
+- **FR-009**: Folge-Specs fur Mapping und Task-Planung MUSSEN auf das Inventory als verpflichtende Referenz verweisen.
+
+## UI Action Matrix *(mandatory when Filament is changed)*
+
+N/A - no Filament surface change.
+
+### Key Entities *(include if feature involves data)*
+
+- **Inventory Entry**: Ein dokumentierter AstroDeck-Primitive-Eintrag mit Pflichtattributen, Eignungsklasse, Relevanz und optionalen Markierungen.
+- **Primitive Class**: Kategorie eines Inventareintrags (`Page`, `Section`, `Component`) zur strukturierten Trennung und Auswertung.
+- **Suitability Class**: Vorlaufige Eignungsstufe (`A`, `B`, `C`, `D`) fur TenantAtlas-Nutzbarkeit.
+- **Marker Set**: Optionales Tag-Set pro Eintrag (z. B. `tenantatlas-likely`, `visual-risk`, `demo-only`) zur besseren Mapping-Qualitat.
+
+## Success Criteria *(mandatory)*
+
+### Measurable Outcomes
+
+- **SC-001**: 100% der im Scope identifizierten AstroDeck-Primitives sind in genau einer der drei Inventarklassen (`Page`, `Section`, `Component`) dokumentiert.
+- **SC-002**: 100% der Inventareintrage enthalten alle Pflichtattribute gemaB FR-002 ohne fehlende Felder.
+- **SC-003**: 100% der Inventareintrage enthalten eine Suitability Class (`A` bis `D`) und eine TenantAtlas-Relevanzstufe.
+- **SC-004**: Fur alle definierten Kernsurfaces (Homepage, Hero, Product, Trust, Changelog, Contact/Demo, Navigation, Footer) existiert sichtbare Kandidatenzuordnung oder explizite Nichtverfugbarkeitsnotiz.
+- **SC-005**: Jede nachgelagerte Mapping-Spec referenziert mindestens einen konkreten Inventareintrag als Entscheidungsgrundlage. *(Forward-governance rule: verified in downstream mapping specs, not a done-criterion for Spec 226 itself.)*

specs/226-astrodeck-inventory-planning/tasks.md

@@ -0,0 +1,123 @@
+# Tasks: AstroDeck Inventory Planning for Website Rebuild
+
+**Input**: Design documents from `specs/226-astrodeck-inventory-planning/`
+**Prerequisites**: plan.md ✅ | spec.md ✅ | research.md ✅ | data-model.md ✅ | contracts/ ✅ | quickstart.md ✅
+
+**Tests**: N/A — docs-only planning artifact; no runtime behavior changes; quality proven by artifact completeness and structural review.
+**Operations**: N/A — no long-running, remote, queued, or scheduled work.
+**RBAC**: N/A — no authorization changes.
+
+---
+
+## Phase 1 — Setup
+
+**Goal**: Initialize inventory folder and catalog metadata header.
+
+**Independent Test**: `specs/226-astrodeck-inventory-planning/inventory/` directory exists and `catalog.md` is present with all catalog-level fields.
+
+- [X] T001 Create `specs/226-astrodeck-inventory-planning/inventory/catalog.md` with catalog metadata (`catalog_id`, `scope`, `created_at`, `source_commit`, `status: draft`) per data-model.md InventoryCatalog definition
+
+---
+
+## Phase 2 — Foundational
+
+**Goal**: Execute primitive discovery to establish the complete source-of-truth file list before any entries are authored.
+
+**Independent Test**: Discovery command executes cleanly from repo root and every file returned maps to exactly one of the three primitive classes (Page, Section, Component).
+
+- [X] T002 Run the quickstart discovery command (`rg --files src/pages src/components/sections src/components/primitives src/components/content src/components/layout` from `apps/website`) and record the complete file list in `specs/226-astrodeck-inventory-planning/inventory/catalog.md` under a `## Source Discovery` section with source commit SHA
+
+---
+
+## Phase 3 — User Story 1 (P1): Build Complete Primitive Inventory
+
+**Story goal**: Complete, class-separated inventory lists for Pages, Sections, and Components — each entry carrying all mandatory fields (FR-001, FR-002, FR-003).
+
+**Independent Test**: Three inventory files exist; every entry contains `identifier`, `primitive_class`, `file_ref`, `functional_role`, `default_semantics`, `default_visual_character`, `tenantatlas_relevance`, and `suitability_class` without missing fields (SC-001, SC-002). Demo/template-only entries are included (FR-005).
+
+- [X] T003 [P] [US1] Create `specs/226-astrodeck-inventory-planning/inventory/pages.md` with one entry per Astro page entrypoint (`index`, `product`, `trust`, `changelog`, `contact`, `solutions`, `integrations`, `privacy`, `terms`, `imprint`, `legal`, `security-trust`) using the InventoryEntry schema from `data-model.md`; include `file_ref` pointing to the relevant `apps/website/src/pages/` path; include any additional page files discovered in T002 that are not in the list above
+
+- [X] T004 [P] [US1] Create `specs/226-astrodeck-inventory-planning/inventory/sections.md` with one entry per section composite (`PageHero`, `FeatureGrid`, `CTASection`, `CapabilityGrid`, `OutcomeSection`, `TrustGrid`, `LogoStrip`, `ProgressTeaser`) and any additional sections discovered in T002; use InventoryEntry schema; include `file_ref` pointing to `apps/website/src/components/sections/`
+
+- [X] T005 [P] [US1] Create `specs/226-astrodeck-inventory-planning/inventory/components.md` with one entry per component in all three sub-families — primitives (`Button`, `Card`, `Container`, `Grid`, `Stack`, `Section`, `SectionHeader`, `Cluster`, `Badge`, `Input`, `Textarea`), content (`Headline`, `Lead`, `Eyebrow`, `Metric`, `PrimaryCTA`, `SecondaryCTA`, `FeatureItem`, `Callout`, `RichText`, `TrustPrincipleCard`, `DemoPrompt`, `HeroDashboard`, `IntegrationBadge`, `AudienceRow`, `ContactPanel`), and layout (`PageShell`, `Navbar`, `Footer`, `BaseLayout`); group by sub-family under headings `### Primitives`, `### Content`, `### Layout`; use InventoryEntry schema; include `file_ref` pointing to respective `apps/website/src/components/` path
+
+---
+
+## Phase 4 — User Story 2 (P1): Add Suitability and Risk Classification
+
+**Story goal**: Every inventory entry carries a validated A/B/C/D suitability class, a TenantAtlas relevance level, and all applicable markers from the allowed MarkerVocabulary. Suitability distribution and surface candidate visibility are published in a summary document (FR-004, FR-005, FR-006, FR-007, FR-008).
+
+**Independent Test**: Every entry in pages, sections, and components files has a non-empty `suitability_class` (A–D) and `tenantatlas_relevance` (high/medium/low/none); no entry is missing markers where applicable; `summary.md` reconciles aggregate counts with row-level entries and covers all 8 required surfaces (SC-003, SC-004).
+
+- [X] T006 [US2] Apply A/B/C/D suitability classification, TenantAtlas relevance grading, and applicable MarkerVocabulary tags to every entry in `specs/226-astrodeck-inventory-planning/inventory/pages.md`; apply minimum marker rules per quickstart.md (D entries with demo purpose → `demo-only` required; C entries with visual/semantic notes → `visual-risk`/`semantic-risk` required); do not pre-empt mapping decisions
+
+- [X] T007 [US2] Apply A/B/C/D suitability classification, TenantAtlas relevance grading, and applicable MarkerVocabulary tags to every entry in `specs/226-astrodeck-inventory-planning/inventory/sections.md`; apply minimum marker rules per quickstart.md (C entries with visual/semantic notes → corresponding risk marker required; surface candidate sections → required surface marker); flag risky sections explicitly rather than silently downgrading suitability
+
+- [X] T008 [US2] Apply A/B/C/D suitability classification, TenantAtlas relevance grading, and applicable MarkerVocabulary tags to every entry in `specs/226-astrodeck-inventory-planning/inventory/components.md`; apply minimum marker rules per quickstart.md (C entries with visual/semantic notes → required risk marker; components appearing in surface candidate list → required surface marker); ensure layout/ sub-family entries use `primitive_class: Component`
+
+- [X] T009 [US2] Create `specs/226-astrodeck-inventory-planning/inventory/summary.md` containing: suitability distribution table (`count_a`, `count_b`, `count_c`, `count_d`), risk visibility counts (`visual-risk`, `semantic-risk`, `demo-only`), and a surface candidate table covering homepage, hero, product, trust, changelog, contact-demo, navigation, and footer — each surface lists candidate `entry_id` references or an explicit "no direct candidate" note
+
+---
+
+## Phase 5 — User Story 3 (P2): Anchor Follow-up Mapping Specs
+
+**Story goal**: Downstream mapping specs (214/215/217 alignment work) have a clear reference contract requiring concrete `entry_id` citations. Non-candidate decisions are documented rather than silently omitted (FR-009, FR-010).
+
+**Independent Test**: `mapping-anchors.md` exists; it includes the mandatory reference rule (no selection without `entry_id`), an example reference block, and an exception path for non-candidate decisions.
+
+- [X] T010 [US3] Create `specs/226-astrodeck-inventory-planning/inventory/mapping-anchors.md` defining: (1) the mandatory rule that no mapping spec may claim primitive selection without referencing `entry_id` from the active baselined catalog; (2) an example reference block for downstream specs; (3) the exception path for remove/non-candidate decisions that require explicit rationale rather than omission; (4) instructions to refresh the inventory when source primitives change before the next mapping cycle
+
+---
+
+## Final Phase — Polish & Cross-Cutting
+
+**Goal**: Structural completeness validation, catalog status transition, and agent context update.
+
+- [X] T011 Cross-validate that all entries in pages, sections, and components files have no missing required fields (SC-002); confirm all entries have `suitability_class` and `tenantatlas_relevance` set (SC-003); confirm all 8 surfaces have a candidate entry or an explicit "no direct candidate" note in `summary.md` (SC-004); record any gaps as inline TODO notes rather than omitting entries; note SC-005 (downstream specs reference inventory) is a forward-governance rule verified in downstream mapping specs, not a done-criterion for Spec 226
+
+- [X] T012 Update `specs/226-astrodeck-inventory-planning/inventory/catalog.md` status from `draft` to `reviewed` once T011 passes; add reviewer sign-off section with date and confirmation that suitability summary is reconciled with row-level entries
+
+- [X] T013 Run `.specify/scripts/bash/update-agent-context.sh copilot` from repo root to record Spec 226 inventory completion in `.github/agents/copilot-instructions.md`
+
+---
+
+## Dependencies
+
+```
+T001
+ └── T002
+      ├── T003 (US1, parallel with T004, T005)
+      ├── T004 (US1, parallel with T003, T005)
+      └── T005 (US1, parallel with T003, T004)
+           ├── T006 (US2, depends on T003)
+           ├── T007 (US2, depends on T004)
+           └── T008 (US2, depends on T005)
+                └── T009 (US2, depends on T006+T007+T008)
+                     └── T010 (US3, depends on T009)
+                          └── T011 (Polish, depends on T006+T007+T008+T009+T010)
+                               └── T012
+                                    └── T013
+```
+
+**User story completion order**: US1 before US2 (suitability requires populated entries); US2 before US3 (anchoring requires suitability to be visible).
+
+## Parallel Execution
+
+Within Phase 3 (US1), T003 + T004 + T005 can be authored simultaneously (different files, no cross-dependency).
+
+Within Phase 4 (US2), T006 + T007 + T008 can be applied simultaneously (different files) once their respective entry file from US1 is complete. T009 requires all three to be finished.
+
+## Implementation Strategy
+
+**MVP scope**: Complete Phase 3 (US1) first — a fully populated entry set with required fields but without suitability is already more useful than no inventory. This allows review and feedback before the classification pass (US2).
+
+**Incremental delivery**:
+1. T001–T002: discovery and catalog header (minutes)
+2. T003–T005: three entry files without suitability markers yet (main authoring effort)
+3. T006–T009: classification + summary pass
+4. T010: mapping anchor contract
+5. T011–T013: validation + status transition + context update
+
+**Total task count**: 13  
+**Task count per user story**: US1 → 3 tasks | US2 → 4 tasks | US3 → 1 task | Setup/Foundational → 2 tasks | Polish → 3 tasks  
+**Parallel opportunities**: Phase 3 (3-way) + Phase 4 initial pass (3-way)