Rule
A verified result can become the new floor after the caller accepts and lands it. Keep the verdict with the change, then turn the behavior into a test or check that later work must still pass.
Done requires a verdict. A pull request can merge on optimism and still leave the floor where it was. Progress is the change that passed its gate and became the new baseline. One large open-source repository's ten-month public dataset makes the social version of this rule visible: hundreds of agent-authored pull requests, every one held at draft until a human reviewed it, over half needing human follow-up commits before landing. The airlock is what made the throughput safe.
Put It to Work
- Let the caller's repository policy decide whether verified work is committed, pushed, or merged.
- Record the proof that made each change acceptable alongside the change.
- Close or update the issue that tracked the work; file follow-ups for unfinished scope.
- Treat any regression below a ratcheted baseline as a stop-everything event. Do not file it as flaky.
Failure Signal
- A fix exists only in an unpushed local checkout.
- Work merges because it looked finished, and the gate runs afterward, or never.
- A later agent reopens solved ground without knowing it was solved.
- The project cannot tell a failed attempt from accepted progress.
Done Looks Like
The accepted change is landed under repository policy, its verdict remains inspectable, and a later regression fails a named check.