10. Review Gates & Anti-Patterns
Chapter 10
Executive Summary
What this chapter establishes
Review gates and named anti-patterns keep the portfolio from mistaking activity for autonomy.
Operator ExperienceThe gates force every slice to prove the human step disappeared or to admit it did not.
10.1 The four review gates
Section titled “10.1 The four review gates”Work passes through gates, in order. Each is a checklist, not a vibe.
| Gate | When | Must hold |
|---|---|---|
| Planning Gate | Before implementation | Role identified · burden stated · capability proposed · reusable boundary clear · Zach’s day-change clear · risks known · verification plan clear |
| Implementation Gate | Before merge | Tests pass · typecheck passes · no authority widening · no auth weakening · evidence produced · receipt path exists · independent review where needed |
| Burden Gate | Before claiming success | Human burden removed · operator-visible outcome exists · Zach no longer performs the step · receipts prove it · role scorecard updated |
| Operational Gate | Before calling something operational | Runs without human trigger · works on live input · produces receipts · health monitoring exists · failure modes known · rollback exists |
Anti-self-grading (the discipline behind the gates). “Proven” requires independent audit of a random evidence sample by a separate adversarial agent — threshold math on self-produced evidence is not enough. Never self-merge governance code (authority, receipts, promotion/readiness, evidence schema, the Capability API): it goes through review by a separate agent even when no human is available.
10.2 Anti-patterns — the named failure modes
Section titled “10.2 Anti-patterns — the named failure modes”Each is a way to look like progress while the real goal stalls. Name them out loud when you see them.
| Anti-pattern | What it looks like |
|---|---|
| Artifact Worship | Mistaking PRs, docs, comments, or JSON for outcomes |
| Advisory Dead End | Producing a BLOCKED comment with no follow-up execution initiated |
| Local Optimization | Improving one feature while ignoring role replacement |
| Strategy Churn | Writing more doctrine when the runtime is missing |
| Human as Event Bus | Depending on a person to wake the system |
| Human as Dispatcher | Depending on a person to route work between repos |
| Surface Without Use | Building UI no one uses and claiming burden reduction |
| Capability Without Consumption | Building a reusable capability no organization consumes |
| Replacing Judgment | Automating decisions that should remain executive judgment |
| Project-Manager Steward | Shepherding every implementation instead of managing throughput |
Part IV — The Product
Section titled “Part IV — The Product”Chapter closeout
Decision ledger
Key Decisions
- Proven requires independent audit.
- Governance code is never self-merged.
Open Questions
- Which anti-pattern should be instrumented first in the product?
Related Chapters
- Ch. 8 - Execution Doctrine
- Capability Cards
- Concept Map - Receipts