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