| name | review-interfaces |
| description | Are the boundaries between components clean, minimal, and well-defined? |
Interface & Boundary Review
Evaluate the seams between components. Clean interfaces make systems replaceable, testable, and understandable. Messy interfaces make everything fragile.
ultrathink
Rules
- Every finding must identify a specific interface, contract, or boundary
- "Tightly coupled" is not a finding. "The MUD command dispatch (§7.C) directly calls VizConfigContext setters, meaning command logic can't be tested without the React context — an interface boundary is missing" is a finding
- Look for implicit contracts (assumptions that aren't documented) as hard as you look for explicit ones
- If the design references existing code (reuse, refactor, replace), read that code before assessing interfaces. The existing code's contracts may answer questions the design doc leaves open. A finding that the code already resolves is not a finding.
- Distinguish "not yet specified" (future phase placeholder) from "underspecified" (current phase gap). Phase 2+ placeholders in a phased design doc are expected, not findings.
Questions
- Read referenced code first. If the design doc says "reuse X" or "replace Y," read those components' actual interfaces before reviewing. The code is ground truth for existing contracts.
- Identify all interfaces/contracts in the design: APIs, context shapes, event protocols, file formats, command grammars
- For each interface: is it minimal? Does either side depend on internal details of the other?
- Could you swap one side of an interface without the other knowing? If not, why?
- Where would a change ripple? If you modify component X, what else has to change?
- Are there implicit contracts — things that must be true for the system to work but aren't documented as interfaces?
- Are there missing interfaces — places where components interact without a defined contract?
- Do interfaces have clear error contracts? What happens when one side sends unexpected input?
Output Format
| Interface | Between | Issue | Severity | Recommendation |
|---|
| [name/description] | [Component A ↔ B] | [specific issue] | Critical / Important / Minor | [specific action] |