57 lines
4.5 KiB
Markdown
57 lines
4.5 KiB
Markdown
# Exception Register
|
|
|
|
This register defines the only allowed path for non-AstroDeck primitives. Until an entry is approved here, custom rebuild work is out of bounds.
|
|
|
|
## Workflow
|
|
|
|
1. Search the AstroDeck alias inventory before proposing any custom page, section, or component.
|
|
2. Record the candidate aliases reviewed and explain why keep or bounded adaptation is or is not sufficient.
|
|
3. If one or more aliases can satisfy the need without inventing a new IA contract or unsupported interaction model, record `no exception required`.
|
|
4. If all viable aliases fail, record the unmet requirement, the failed candidate search, the bounded deviation, the named approver, and the owning follow-up task.
|
|
5. Keep every approved exception local to one page, section, or component slice. Do not generalize it into a new default primitive family.
|
|
|
|
## Adequacy Rubric
|
|
|
|
Use `no exception required` when the AstroDeck candidate family can satisfy the active requirement through bounded adaptation across all of the checks below:
|
|
|
|
- It preserves the active route and IA contract from Specs 213, 215, 217, or 218.
|
|
- It preserves CTA hierarchy, trust-boundary rules, and mobile meaning order without adding a new interaction model.
|
|
- It avoids shipping demo-only proof, fake logos, invented metrics, or placeholder legal/trust content.
|
|
- It can be re-skinned to the Spec 214 foundation without introducing a second visual system.
|
|
|
|
Use `approved exception` only when every candidate fails one or more of those checks and the failure cannot be resolved by bounded adaptation.
|
|
|
|
## Required Evidence for Approved Exceptions
|
|
|
|
- failed AstroDeck candidate search
|
|
- unmet active-spec requirement
|
|
- adequacy failure reason for each reviewed candidate
|
|
- bounded deviation being approved
|
|
- named website reviewer, owner, or equivalent feature approver
|
|
- replacement task or mapping entry that owns the deviation
|
|
- spread-control note explaining why the deviation does not create a new default
|
|
|
|
## Approval Boundary
|
|
|
|
- Minimum approver: named website reviewer or feature owner
|
|
- Preferred approver for IA or trust changes: spec author or feature owner responsible for Specs 215, 217, or 218
|
|
- Re-review trigger: if the mounted AstroDeck snapshot disproves the intake aliases currently recorded in `astrodeck-primitive-inventory.md`
|
|
|
|
## Register Entries
|
|
|
|
| specId | scope | reviewOutcome | reviewRationale | exceptionReference | notes |
|
|
| --- | --- | --- | --- | --- | --- |
|
|
| 213 | site-foundation shell, core routes, contact/legal baseline | no exception required | The alias set already covers landing, product, trust, contact, legal utility, header/footer, and CTA primitives. The main drift is route emphasis, not missing primitive families. | none | Spread control: route drift is handled by the Spec 213 mapping sheet and the drift ledger, not by inventing new primitives. |
|
|
| 214 | visual foundation tokens, surfaces, CTA/input semantics | no exception required | AstroDeck page, section, and component families can be re-skinned to the website-local foundation without inventing a second design system. | none | Acceptance trace: all work must route through `mappings/spec-214-website-visual-foundation.md`. |
|
|
| 215 | core IA, trust/changelog/contact/legal surfaces, retained secondary routes | no exception required | Generic home, product, proof, content-index, contact, and legal utility aliases are sufficient when demo routes are suppressed. | none | Spread control: any later missing route family must re-open this register before a custom page is approved. |
|
|
| 217 | homepage section order, trust/progress placement, CTA transition | no exception required | Hero, outcome, feature-cluster, trust, changelog-teaser, and CTA-band aliases cover the homepage contract. | none | Acceptance trace: remove optional proof sections instead of replacing the homepage with a custom greenfield assembly. |
|
|
| 218 | hero CTA pair, product-near media, bounded trust cues, mobile order | no exception required | The split hero family plus button and badge primitives are adequate once demo media and fake proof are stripped. | none | Spread control: a later hero exception would need to show why the split-media family cannot preserve the existing hero contract. |
|
|
|
|
## Approved Exception Records
|
|
|
|
None as of 2026-04-22.
|
|
|
|
## Standing Rule
|
|
|
|
No follow-up implementation slice may introduce a net-new page, section, or component by default. If the mounted AstroDeck snapshot later proves one of the alias families wrong, that mismatch must reopen this register before implementation continues.
|