launch control

treat the plan as the contract and every merged pr as evidence. the executor codes; a separate independent subagent reviews alignment, truthfulness, and working proof before merge. self-review is not enough.

do not use

• tiny one-step fixes.
• pure q&a, brainstorming, or read-only review.
• work where the user explicitly does not want prs, subagents, or formal gates.

workflow

1. write or load the plan first.

   • extract phases, acceptance criteria, commands, artifacts, stop conditions, and missing inputs.
   • if the plan is vague, write the concrete implementation plan before coding.
   • keep the plan lean enough to execute, not a speculative architecture dump.
   • create or reuse an append-only DECISIONS.md / PLAN_CHANGES.md for plan amendments, scope changes, and discovered constraints.

2. establish execution rules.

   • use the repo's real stack and real integrations.
   • no mocks, demos, fallbacks, or fake validation unless the user explicitly asks.
   • use the smallest working implementation per block.
   • use a log reducer such as context firewall for noisy commands when available; keep raw evidence accessible by span or log.

3. work in logical blocks.

   • one block should map to one plan item or one coherent slice.
   • create a branch, implement, run the block's real checks, commit, push, and open a pr.
   • pr body must name the plan block, what changed, why, and which real validation passed.
   • if a block exposes a plan flaw, new assumption, changed scope, api/data-model change, or acceptance-criteria change, add an entry to DECISIONS.md / PLAN_CHANGES.md before asking for implementation approval.
   • author flags such as plan_changed: no are only hints. they are never proof.

4. send each pr to a separate independent reviewer subagent.

   • this is mandatory for launch-control. do not self-review your own pr.
   • reviewer is a gate, not a co-author.
   • ask for approved or changes_requested.
   • reviewer must check plan freshness first, then implementation correctness.
   • freshness gate:
     • read the actual plan file, decision log, pr diff, and validation output;
     • do not trust the executor's self-report about whether the plan changed;
     • independently diff the pr against the plan/current block;
     • reject before code review if the pr reveals stale plan, new assumptions, scope changes, api/data-model changes, or acceptance-criteria changes without a decision-log entry;
     • reject if the decision-log entry looks like plan laundering: changing the plan only to justify a bad or unproven implementation.
   • implementation gate:
     • check whether the pr itself is correctly implemented;
     • verify no scope drift or hidden behavior changes;
     • verify real validation evidence supports the pr claims;
     • verify tests cover the changed behavior at the right level;
     • verify no fake success, mocks, fallbacks, or unverified claims slipped in.
   • if rejected, fix only the rejected issues, rerun validation, update the pr, and ask for re-review.
   • do not merge until approved.

5. merge and continue.

   • after approval, merge the pr, return to main, pull, and confirm the tree is clean.
   • update progress against the plan.
   • start the next block only after the previous one is merged or intentionally abandoned.

6. finish with a completion audit.

   • re-read the plan and list every explicit requirement, artifact, command, and invariant.
   • verify each item against current files, pr state, tests, runtime behavior, or command evidence.
   • run the final real gate.
   • confirm no open prs and no dirty worktree.
   • report blockers plainly; do not mark complete on partial evidence.

reviewer prompt

review pr #n in <repo path> against <plan path or summary>.
use a minimalist senior-engineer mindset: no invented issues, no over-review.
return approved or changes_requested.

check:
1. plan freshness:
   - read the actual plan file and decision log from the repo.
   - read the pr diff and validation output.
   - ignore the executor's self-report except as a hint.
   - did this pr introduce new assumptions, scope changes, api/data-model changes, or acceptance-criteria changes?
   - if yes, is there a justified decision-log entry?
   - is the decision-log entry legitimate, or is it plan laundering to excuse bad code?
   - if plan freshness fails, return changes_requested before code review.

2. plan alignment:
   - did the executor drift from the plan, user intent, or intended block?
   - is this pr doing the right slice now?
   - is the pr too large to review safely?

3. pr correctness:
   - is the implementation correct for the intended behavior?
   - does the pr claim only what the diff and validation prove?
   - did real tests/builds/integrations run?
   - are there mocks, fallbacks, demos, or hidden shortcuts?
   - is the scope small enough to merge safely?

do not edit files.

stop conditions

stop and escalate when:

• required real credentials, data, services, or user decisions are missing;
• a separate reviewer subagent is unavailable and the user has not explicitly waived the gate;
• the plan is too vague to diff a pr against a specific block;
• a pr reveals stale plan but no justified decision-log entry exists;
• a command proves the local environment is broken outside the project;
• reviewer rejects the same issue repeatedly and the fix would change scope;
• continuing would require destructive, irreversible, or externally visible action.

do not stop for ordinary failures. fix them, rerun the real checks, and keep moving.