ahmido
ccd4a17209
Some checks failed
Main Confidence / confidence (push) Failing after 1m36s
## Summary - finalize Spec 226 artifacts for AstroDeck inventory planning - include completed planning set: spec, plan, research, data model, quickstart, tasks, checklist, contracts, and inventory outputs - apply consistency fixes from the project analysis review ## Included changes - updated `.github/agents/copilot-instructions.md` from agent-context sync - added/updated all files under `specs/226-astrodeck-inventory-planning/` ## Notes - docs/spec workflow changes only - no runtime code paths changed Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #263
115 lines
3.8 KiB
Markdown
115 lines
3.8 KiB
Markdown
# 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.
|