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

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