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

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:

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.