modules/ceremony-audit.md (~600 tokens): Manual lenses for mapping layers that never diverge. Passthrough mappers, twin types, speculative DTOs, single-implementation interfaces. Includes the IO boundary counter-signal.
Load all modules for full reviews. For focused reviews, load only relevant modules.
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]
-**Location**: file.py:42
-**Anchor**: `verbatim source text at line 42`-**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 rather than a
context problem: the agent should surface it, not solve it.
Coupling analysis (Step 3) finds boundaries that leak. This step finds the
opposite failure: boundaries that cost something and separate nothing.
Passthrough mappers whose fields are all 1:1 copies.
Twin types that are structurally identical across layers.
Speculative DTOs with no external contract pinning their shape.
Interfaces with exactly one implementation and no test double.
Each finding must name the need the ceremony serves today. If no current
need can be named, the ceremony is the finding.
Do not flag mappers at an IO boundary. They are load-bearing even when
they look like passthroughs, because they stop future internal fields from
escaping. See the counter-signal in the module.
Step 5: Risks and Actions (arch-review:risks-actions)
Summarize using imbue:diff-analysis/modules/risk-assessment-framework:
Current vs proposed architecture.
Business impact.
Technical debt implications.
List follow-ups with owners and dates.
Provide recommendation:
Approve: Architecture sound.
Approve with actions: Minor issues to address.
Block: Fundamental problems requiring redesign.
Architecture Principles Checklist
Coupling
Dependencies follow defined boundaries.
No circular dependencies.
Extension points used properly.
Abstractions don't leak.
Cohesion
Related functionality grouped.
Single responsibility per module.
Clear module purposes.
Layering
Layers have clear responsibilities.
Dependencies flow downward.
No layer bypassing.
Invariants
Existing design invariants identified.
Conflicts between changes and invariants surfaced.
Drop or label UNVERIFIED any finding the verifier fails (exit 1); only
verified findings enter the report. See Skill(imbue:review-core) Step 5
and Skill(imbue:structured-output) for the schema.
Every reported finding carries a Location + verbatim Anchor
confirmed by citation_verifier.py (exit 0), or unverified findings
were dropped or labeled UNVERIFIED.