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

```bash
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.