Before checking principles, identify whether the changes
conflict with existing design invariants. This is the
highest-judgment step in architecture review — models
get this wrong more often than any other call.
Identify existing invariants:
Scan ADRs for recorded decisions still in "accepted"
status
Check module boundaries (are imports crossing layers
that previously didn't?)
Check data flow direction (does data now flow in a
new direction?)
Check API contracts (are public interfaces changing
shape?)
Check structural patterns (is a new pattern being
introduced alongside an existing one?)
Do NOT recommend a resolution. Present the three options
and escalate to human judgment:
Option
When Right
When Wrong
Preserve invariant (reject feature)
Invariant simplifies many things; feature is marginal
Feature is genuinely needed and invariant is stale
Layer on top (add inelegantly)
Feature is needed; invariant still valuable; imperfection is OK
Layering creates a maintenance trap that will compound
Revise invariant (change the design)
Genuine new learning invalidates the original reasoning
You're "cleaning up" a decision you don't fully understand
Output format:
### Invariant Conflicts
[I1] **[Invariant name]** — [what decision it represents]
-**Conflict**: [what change clashes]
-**Options**: Preserve / Layer / Revise
-**Recommendation**: ESCALATE TO HUMAN
-**Risk if wrong**: [what compounds]
Why this matters: Bad invariant decisions compound.
After a few wrong calls the codebase becomes
unsalvageable. This is a judgment problem, not a context
problem — the agent should surface it, not solve it.
