Phase 3 — Review

Explicit human approval before spending tokens on execution.

🎯 Goal

Validate that the BLUEPRINT meets the DESIGN, before triggering the Execute phase (where tokens are actually spent). Every architectural bug not caught here costs 10x more later.

This is the most important phase of the method for the quality of the final output, and ironically the most underrated.

📋 What to do

1. Read the entire BLUEPRINT.md

Yes, the entire thing. No skimming. If you just glanced over it, you didn't do a Review — you did a facade audit.

2. Cross-check against the DESIGN.md

Ask of each part of the Blueprint: "Which success criterion of the Design does this meet?". If any non-goal from the Design shows up being implemented, flag it as a bug.

3. Check assumptions

Every explicit assumption in the Blueprint must be true or acceptable as a risk. If it's false, send it back to Architect.

4. Analyze trade-offs

For each important decision: did the AI propose alternatives? Does the rationale make sense for your context (not for a generic one)?

5. Identify gaps

What's missing? Validation? Error handling? Logs? Auth? Consider stack-specific items:

• Auth: is the auth flow clear? Tokens, refresh, logout?
• Validation: schemas for inputs? Sanitization?
• Errors: logging strategy? Telemetry? Rate limiting?
• Migrations / data: rollback plan?
• Tests: which types of test? Minimum coverage?

6. Decide

Approve: mark the BLUEPRINT.md as ready (e.g., add <!-- ✓ APPROVED on YYYY-MM-DD by <name> --> at the top).

Reject: comment inline on what needs to change. Return to Architect with clear feedback.

🧪 Concrete checklist

Use this as a guide:

- [ ] Every success criterion in the DESIGN has a counterpart in the BLUEPRINT
- [ ] Non-goals from the DESIGN are not implemented
- [ ] The chosen stack has a valid rationale for the current context
- [ ] The folder structure is navigable (no 5 empty / artificial folders)
- [ ] Data models cover all required fields
- [ ] API contracts include: input, output, possible errors, status codes
- [ ] Auth and authorization explicitly modeled (if applicable)
- [ ] Input validation planned
- [ ] Error-handling strategy defined
- [ ] Logs / observability planned
- [ ] Tests planned (type + minimum coverage)
- [ ] Migrations / initial setup documented
- [ ] Risks have concrete mitigation (not just listed)
- [ ] Task list is granular enough (each task < 1h of execute)

🚫 Common anti-patterns

"Approval theater"

You read for 30s, say "looks good", and approve. You're guaranteed to hit an architectural bug in the Execute phase. If you don't have 5-10 min to review for real, don't start the feature yet.

"I'll refine it during execution"

The thought: "let me approve now, I'll fix the details later".
The reality: uncorrected details become code that has to be redone. It's cheaper to fix the markdown now.

"I'm not the one who validates"

You are the sole owner of the project. Even if you ask someone else to review, you are still the final validator.

"I'll approve and go grab a coffee"

After approving, stay available during the Execute phase for the first 10-15 min. That's when Blueprint bugs surface earliest. If something goes wrong, you intervene quickly.

🔁 What happens if you reject

Review (rejects) → Architect (refines) → Review (rejects) → ...

There's no formal limit on iterations between Architect ↔ Review. But if you're on the third round and still disagreeing with the architecture, the DESIGN probably has a hole in it. Go back to Design.

🎯 Principle in a nutshell

Tokens spent in Execute after a bad approval are waste.
Minutes spent in Review are an investment.

In direct monetary value: 1h of your attention in Review can prevent 50h of AI producing wrong code.

🔗 Next

Phase 4: Execute →