# 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.