architecture-baseline

Architecture Baseline

Turn what the product promises its users into what the system guarantees, and write it down so every feature built afterwards is built the same way.

Read ../../CONVENTIONS.md first. It carries the shared rules — stages, where work is saved, the tree, markers, interview rules, precedence, gates, decision records and the baseline status footer. This skill does not repeat them.

This is stage 5 of 5, and the last before building starts — though the revision beat described in ../../CONVENTIONS.md may bring any of these documents back.

What this prevents

The constitution stops eleven specs using eleven vocabularies. This stops eleven implementations inventing eleven patterns — eleven models of the same entity, eleven error conventions, eleven answers to what happens when the network dies.

That is the test for every section: name the divergence it prevents. A section that cannot is decoration and should be cut.

What your job is

Not to design features. To make every decision that eleven parallel implementations would otherwise each make separately — once, here, in a form that can be checked.

Stage 3 deliberately deferred all design to you. Sections 1–3 below are unambiguously design work and are yours to do.

Before starting

Establish the project root as ../../CONVENTIONS.md describes. Read, in this order:

1. .specify/memory/architecture.md — the constraints from stage 3, and the Deferred to the baseline list, which is your agenda
2. .specify/memory/experience.md — the conditions of use and accessibility floor (which drive more of the architecture than anything else in it), the surface classes, status dimensions, every [NEEDS DESIGN] marker — each is a system-side question you either answer here or record as an open risk — state inventory, composite state, interaction budgets, and any Open questions addressed to the architect
3. .specify/memory/decisions.md — so you do not re-decide something settled, and so you can check the class of anything described to you as agreed. Also compare the experience baseline's version against **Against experience baseline** in this document's footer: if it has moved, the budgets and fitness functions below may be derived from a guarantee that has since been superseded — say so before starting
4. .specify/memory/constitution.md — and compare its version to the **Against constitution** field in the constraints. If it has moved, say so; something recorded as fixed may no longer be
5. every specs/NNN-*/spec.md
6. any existing technical material elsewhere in the project — see "Look for what already exists" in ../../CONVENTIONS.md. If one exists, settle explicitly whether this baseline supersedes it or defers to it, and record that. Leaving two architecture documents at two paths with no supersession rule is worse than either alone.