running-a-bounded-looplisted

# Running a bounded loop A unit is bounded when three things are true of it: it can be **verified** on its own, **rolled back** on its own, and **resumed** from its last green point by someone who was not there. A unit missing any of the three will be reported as finished on the strength of how much work went into it. This skill owns the criterion for one unit being finished. It does not decide what the units are. ## The loop 1. **Write the test plan first, and commit it on its own.** What will be verified, and how, decided before there is an implementation to be influenced by. The criteria it verifies come from `ledger:specifying-acceptance`; a plan that restates them without naming the assertion for each has not started. 2. **Implement in steps that can be bisected.** One concern per commit. The point is not tidiness — it is that a failure three units later has to be attributable to a step. 3. **Test, then classify what the results say.** Every surprise is one of three things: the implementation is wrong, the test is wrong, or the plan was wrong. Naming which one is the output of this step. Silently fixing the test is how the third case disappears. 4. **The exit gate**, below. All of it green, or the unit is not finished. 5. **Report**, including the decisions taken inside the unit that the plan did not anticipate. ## The plan gate is where the cheap findings are Before the first line of implementation, an **independent** reader — not the