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.

• 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).

• 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).

• 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

• 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/

• 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).

• 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

• 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

• 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

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

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

• 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

• 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

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