architecture-review
architecture-review
When an agent or user needs to decide the SHAPE of a change before any code is written — which seam to cut at, what to reuse, what the tradeoff costs. Also use when the user says "how should we build this," "what's the right design," "should we extend or rewrite," "where does this belong," "is this the right abstraction," "review this design," or "what will this break." Use this whenever the question is about structure rather than syntax. For reading an existing diff, see diff-review. For executing a shape that is already decided, see code-edit. For a workflow's edge weights, see workflow-optimise.
Architecture Review
You decide the shape of a change and name what it costs. The output is a
decision with a stated tradeoff — never a diff, never a verdict without its
downside.
The loop, in order
Restate the constraint, or refuse. What must be true after this change
that is not true now? One sentence. If the brief is too thin to yield that
sentence, say so and stop — a design evaluated against a guessed goal is
worse than no design, and asking for the missing constraint costs one turn.
Run the reuse verdict. Exactly one of four, with a file:line citation:
| Verdict |
Means |
expose |
The primitive exists and works — it just isn't reachable from here |
extend |
The primitive exists and needs one more case |
build |
Genuinely new. Needs the most evidence, not the least |
drop |
The requirement dissolves once the existing shape is understood |
Find the seam. If the brief names two or more symptoms, look for the one
place beneath them. Two instances of a defect shape is a root cause and a
base rate — designing at the sites leaves the rest of the population open.
State both sides of the tradeoff, and one non-goal. gains and costs,
both populated. A design with an empty costs has not been examined. Name
what it makes harder, who pays that cost, and when they pay it — then name at
least one thing this deliberately does not do. An unstated non-goal is a
vacuum the build wave fills on its own.
Write must_not_break. The invariants this change is forbidden to
violate, each one checkable. This becomes the Interface Contract the build
wave pins and the edit wave dissolves against.
Set the tier. PATCH walks BUILD → VERIFY only. FIX adds SURVEY →
TEST → PROVE. FEATURE and SCHEMA walk the full spine including TEACH.
Anything touching schema/, packages/sdk/, or authority code is never a
PATCH.
Hard rules
- The locked things are locked. Six dimensions, six verbs, eight workflow
step kinds, four role rungs. A design that needs a seventh of any of them is
the design that is wrong, not the substrate.
- One truth per domain. Authority resolves by one walk up the group tree;
the schema is the single source. A design that adds a parallel policy table
has added a second truth that will drift.
- Every signal closes —
mark, warn, or dissolve. A design with a silent
return path is unfinished.
- Prefer boring. Developer legibility is an architectural property, not a
nicety. The team reading this in six cycles is the primary user.
Out of scope
- Writing the diff — that is
code-edit, and it happens after.
- Relitigating locked names or the authority model.
- Approving your own design: a proposal is proposed, a human or the director
accepts.