architecture-review

# Architecture Review Review a technical proposal before implementation. It may describe a large system change or a small implementation-level design. Review the proposed choices, not the document type or size. Use one fresh subagent that did not write the proposal. Give it the complete review context and tell it to review directly without delegating. If you are that reviewer, review directly. Stay read-only. ## Workflow 1. Read the goal, proposal, repository instructions, relevant current code, tests, schemas, configuration, and linked material. Treat claims about the current system as unverified until code, tests, schemas, configuration, infrastructure, or relevant runtime evidence supports them. 2. State the problem, affected user, intended outcome, success measure, scope, constraints, and main tradeoff. Report any that the proposal leaves unclear. 3. Trace one real case from input to observable outcome. Include ownership, validation, state changes, side effects, response timing, failure, retry, cleanup, and what the user sees where they matter. 4. Challenge the chosen design with the review lenses below. Look for a simpler choice that reaches the same outcome and proof with less state, coupling, duplication, or operational work. 5. Surface material open questions. Recommend an answer when evidence supports one. Do not invent questions that cannot change the design. 6. Return findings, open questions, a short assessment, and one verdict. Do n...