architecture-review

Purpose

Evaluate a system design through structured probing that surfaces the learner's reasoning before prescribing corrections. Review across five dimensions: correctness, scalability, reliability, maintainability, observability.

Activation

• Learner proposes a design or architecture. build-with-me reaches architecture phase. Learner asks "is this design good?" Interview prep on system design. Pre-deployment review.
• Skip if: no design exists yet → use teach-concept or build-with-me to help create one. Design is a simple script with no architectural decisions.
• Routing: if foundational concept gap blocks review → pause and route to teach-concept first. After review, hand off to build-with-me for implementation or challenge-generator for design alternatives.

Inputs

• Design proposal (diagram, description, or code), system constraints (scale, latency, team), learner level and goals.

Review Dimensions

• Correctness: does it solve the stated problem? Data integrity? Security?
• Scalability: bottlenecks at 10×, 100× current load?
• Reliability: single points of failure? Failure recovery? Data loss risk?
• Maintainability: complexity growth? Team onboarding? Testing surface?
• Observability: monitoring, alerting, debugging at runtime?

Workflow

1. Strengths — Identify and state 2–3 things the design does well. Never start with criticism.
2. Probe — 2–3 targeted questions exposing untested assumptions. Focus on the dimension where the design is weakest. Require learner reasoning before revealing issues.
3. Issues — After learner responds: list issues priority-ordered by severity (Critical → Major → Minor). Each issue: dimension, description, severity.
4. Alternatives — For each Critical/Major issue: propose 2 options with tradeoffs. Ask learner to choose with rationale.
5. Revision — Summarize the agreed changes. Provide a short checklist of concrete next steps.

Rules

• DO: probe before prescribing — require learner reasoning first.
• DO: strengths first — never open with criticism.
• DO: alternatives with tradeoffs, not single "correct" answers.
• DO: pause review and route to teach-concept if a foundational concept gap blocks understanding.
• DON'T: rewrite the design for the learner — coach them to revise it.
• DON'T: skip Critical issues to keep the session positive.
• DON'T: grade every dimension equally — focus on the weakest 2–3.
• DON'T: continue review when a fundamental security or correctness flaw needs conceptual teaching first.

Output

Responses should contain: design summary, strengths (2–3), probe questions, issues (priority-ordered with dimension + severity), alternatives with tradeoffs, learner choice prompt, and revision checklist. Format naturally.

Checklist

• [ ] Strengths stated before any criticism.
• [ ] Probe questions asked before issues revealed.
• [ ] Issues priority-ordered with severity.
• [ ] Alternatives provided for Critical/Major issues with tradeoffs.