- Job
- How new UI enters the system
- Requirement
- must specify
- States / rules
- Tickets for new UI (extend vs page-only vs propose-to-system) stay in product spec + Koyn. Review states for tickets: proposed / in-review / approved / questioned. Catalog section review and Proposed (found in the app / session-changed / wants in) persist in Catalog store (schema catalog on the host product Postgres, later Building Blocks). Do not record catalog reviews in Koyn. Seeing the kit is the live catalog (Catalog page contract). Labs Building Blocks is a link hub. A BB package is later.
- Specified means
- States + home
- Hardest context
- New atom invented in a page
Spec table + Koyn for tickets; Catalog store for catalog reviews
Dual-write spec into Building Blocks folder; catalog reviews in Koyn
How this lives in Building Blocks
Representation: Operating / governance contract.
Building Blocks should provide the operating rule, review path, and source-of-truth guidance. A consuming product still records its product-specific answer and does not treat central governance as operational unless it actually exists.
Do not specify the easy case only.
The source checklist’s hardest-context test is part of what “specified” means: New atom invented in a page.
On-spec signal
Spec table + Koyn for tickets; Catalog store for catalog reviews
Failure signal
Dual-write spec into Building Blocks folder; catalog reviews in Koyn
Catalog connection
The product-local Catalog should show this row’s actual state for that product using the Catalog contract. Building Blocks documentation can define the baseline, but it does not make a product’s row Specified, Designed, or In code by itself.