architecture-elevationlisted

# Architecture Elevation Skill ## Trigger `/architecture-elevation <path-to-analysis-or-design-doc>` Also invoked automatically as a gate from: - `/rootcause-all` at end of Phase 4 (after solution documented) - `/design-v5` between Phase 3 (synthesis) and Phase 4 (finalize) - `/rootcause-review` at Phase 1 (intake) ## Purpose Peer review asks "are the claims INSIDE the frame true?" This skill asks two questions in order: 1. **Does this concern exist because of an abstraction we introduced?** If the abstraction were removed, would the concern disappear? (Phase 0.) 2. **If the concern is real, is there a single boundary that would DELETE the duplication instead of add to it?** (Phases 1-3.) The single failure mode this skill defends against: a surface-level fix is accepted because every downstream gate (peer review, six-sigma, impact-analysis) validates claims WITHIN the current frame, and none interrogates the frame. The most common form of that failure: an ADR or prior decomposition encoded the surface-level remedy, and "ADR-compliance" is then mistaken for architectural correctness. ## Bias: subtraction over addition A proposal that adds a new layer, interface, or abstraction is almost never the answer. The answer is almost always either (a) a boundary that already exists being given the invariant it should have carried all along, such that other layers can be DELETED, or (b) an abstraction that shouldn't have been introduced being removed, such that the concern dis