Ship discipline
Heuristics for shipping. Pick a single gate; let the rest be informational.
One gate, named explicitly
The ship gate is one thing only: Eng Review passing.
CEO / Design / Adversarial / Outside-Voice reviews are shown but never block shipping.
For solo founders: pick one hard gate per workflow and refuse to let optional reviews accumulate veto power.
Six auto-decision principles
When deciding between approaches in a plan review, apply in order:
- Choose completeness — pick the approach that covers more edge cases.
- Boil lakes — fix everything in blast radius; auto-approve expansions <1 day of AI-assisted effort.
- Pragmatic — "5 seconds choosing, not 5 minutes."
- DRY — duplicates existing functionality? Reject.
- Explicit over clever — "10-line obvious fix > 200-line abstraction. Pick what a new contributor reads in 30 seconds."
- Bias toward action — "Merge > review cycles > stale deliberation. Flag concerns but don't block."
Phase tiebreakers
- CEO review → P1+P2 (completeness, boil lakes) dominate
- Eng review → P5+P3 (explicit, pragmatic)
- Design review → P5+P1 (explicit, completeness)
Decision classification
Three categories. Treat each differently:
| Type | Action |
|---|
| Mechanical (one obviously correct answer) | Decide silently, mention in summary |
| Taste (close call, defensible either way) | Auto-decide, surface at the end for user review |
| User Challenge (both AI models disagree with the user) | NEVER auto-decide. Force the models to make the case |
User Challenge framing: "The user's original direction is the default." Models must argue against it.
The Confusion Protocol
STOP and ask only on:
- Architectural / data-model ambiguity
- Destructive scope unclear
- Contradicting patterns in the codebase
Never stop for:
- Routine work
- Uncommitted changes
- Version bumps
- CHANGELOG updates
- Commit messages
"If you catch yourself writing fewer than 3 sentences for any review section, you are likely compressing."
9 prime directives (eng review)
These are non-negotiable in code review:
- Zero silent failures — every error has a name
- Catch-all / is ALWAYS a smell
- Data flows have shadow paths — trace happy + nil + empty + upstream-error, all four
- Diagrams are mandatory for architectural changes
- Everything deferred must be written down — "vague intentions are lies. TODOS.md or it doesn't exist."
- Optimize for the 6-month future, not the 6-day present
- Test coverage is non-optional — see review-and-debug for confidence calibration
- Prefer // over equivalents when a dedicated tool fits
- No string-matching error messages to dodge linters
Land and deploy
Persona: a release engineer who has deployed thousands of times.
"The two worst feelings in software: the merge that breaks prod, and the merge that sits in queue for 45 minutes while you stare."
Two hard gates remain even when automated:
- First-run dry-run validation — you need to see the deploy infra once
- Pre-merge readiness — reviews / tests / docs
Tone rule: narrate, don't go silent.
"Explain why before asking — 'Deploys are irreversible, so I check X.'"
First run = teacher mode. Subsequent runs = efficient.
Single-pass verification (not continuous monitoring — that's canary's job).
Ship's central doctrine
"AI makes completeness near-free… A 'lake' is boilable; an 'ocean' is not. Boil lakes, flag oceans."
"'Ship the shortcut' is legacy thinking from when human engineering time was the bottleneck."
What ship explicitly does NOT block on
- CEO / scope-expansion suggestions (informational)
- Design review findings (informational)
- Adversarial review (informational)
- Outside-voice critique (informational)
- Uncommitted changes from unrelated work
- Version bumps
- CHANGELOG voice / formatting
What ship explicitly DOES block on
- Eng review failures
- Test failures (any tier)
- Plan failures
- TODOS reorg if requested
The asymmetry is the point: the one hard gate is named. Everything else is information.