The Planning Loop
A plan is a set of claims about a codebase, and most of them are wrong until someone checks. The Planning Loop is how a claimed card becomes a plan that has been checked — by reading the code, asking a person once, and then attacking the draft.
What the attack finds
On this site’s own plans, the adversarial pass found wrong claims in every one: at least three, and eight in the middle plan.
Counted from the first adversarial pass of 27 of the 28 card plans in this site’s onMain project — Plans 1 to 29, written 2026-09-29 to 2026-10-01; the one left out is still a draft. A claim counts when the pass found a stated fact untrue, not when it found something missing. Each plan is counted at the low end of its range; the most was nineteen.
A plan that reads as finished is not evidence
A plan is written once and built by a session that cannot ask its author what was meant. A plan can carry no open questions and still misdescribe the code it is about to change. So every plan is held to three rules: assert nothing about code you have not read, never defer a question the repository can answer, and never hand over a plan you have not tried to destroy.
Six steps, from a claimed card to a buildable plan
Before the first step, the agent confirms the project is set up and records anything a previous session landed, so it never plans on a stale board.
- ReconnaissanceRead the spec, the invariants, recent plans, the decisions and the architecture, then the code. Every claim carries a file and line, or a command and its output.
read_plan · read_record · read_architecture - DecisionsSort every fork: answer it from the repository, answer it by running something, or bring it to a person — once, batched, with a recommendation.
- DraftWrite the plan as phases a session can build one at a time, each opening with what is true today, each check naming the input that makes it fail. It is born a draft, and nobody builds a draft.
create_plan - Triage the residueEvery hedge and “TBD” in the draft goes back through the same sorting. What survives is a question for a person or a command someone must run — never a guess.
- Adversarial reviewA fresh session, without the conversation that wrote the plan, hunts for what it gets wrong. Only once that pass is written down may the plan be set to executing.
record_review · update_plan - ConsolidationPut adjacent debt to the owner instead of folding it in. Decisions the plan made are proposed as records, and accepted only when the owner approves the plan.
revise_record
Two question gates, and one rule the server enforces
Questions come to a person twice: once after reading, and once after drafting — never in the first five minutes, and never put off to the last. And the server refuses to move a plan from draft to executing until it has a written section of adversarial findings, so readiness is a status the process owns, not a box someone ticks.
What a plan carries when it leaves
Every phase opens with what is true today, with citations. Every check names the input that makes it fail, and every new guard is proven by planting the defect it exists to catch. And every plan says what it will not do.
Questions
Does a person still decide anything?
Yes. Intent, design and product questions come to a person, batched once, with the evidence and a recommendation. The loop exists so that a person is asked only what the code cannot answer.
Why attack a plan nobody has built yet?
Because a wrong premise caught in a plan costs a sentence, and caught in a build it costs commits. On 2026-09-29, on onMain’s own project, a session built four phases of a plan whose adversarial pass was still running; three of the pass’s four corrections then landed as fixes on top. The Standard now records it as the reason a draft is never built.
Is this the documentation?
No. This page shows the loop’s shape. The Standard itself is longer, and the agent reads it before every plan; the documentation is still being written.