The pipeline commits code after a Reviewer approves it. That feature was built before the feature that controls which branch those commits land on.
The risk was real and known. For several sessions, a pipeline APPROVE meant agent-written code committed to whatever branch happened to be active. On the test fixture project that was acceptable, because the fixture is disposable. On a real codebase, it would mean agent-written commits landing directly on master with no feature branch to delete and no clean rollback path.
The reason for the ordering was not impatience. It was that without commits, the pipeline could not prove it worked.
What a commit actually proves
By the time the pipeline reaches a commit, a lot of things have already been verified: the Planner decomposed the ticket correctly, the Test Writer produced tests that passed the quality gate, the Coder made those tests pass within its authorized scope, the Reviewer evaluated the diff and issued APPROVE. What has not been verified is whether any of that produced real, committed output.
A pipeline run that produces changed files but no committed state has not proven the full cycle. It has proven parts of the cycle.
The git commit is not just record-keeping. It is the point at which the pipeline proves it can deliver a finished unit of work that survives a branch checkout, a
git log, a code review. Until there is a commit, you have a system that transforms input files into output files. The commit is what makes it a software delivery system.
That proof matters early, before other components are built on top of it. If the commit logic was broken or the commit message format was wrong or the git hooks rejected the commit, those failures needed to be discovered before sessions of other work accumulated on top of an unproven delivery step.
Building commit support first meant that from that point onwards, every pipeline run produced verifiable committed output. Every subsequent session of work was validated against that proof.
The specific risk
Without branch isolation, every APPROVE commit lands on the active branch. For a single test run on a clean fixture, the risk is theoretical. For a sequential multi-ticket run, it compounds.
The scenario that warranted documenting: a sequential run starts on master, runs five tickets, two succeed and three fail in ways that produce wrong commits before the failure is detected. Recovery requires identifying exactly which commits to revert, in which order, without overshooting into commits that were correct. On a test fixture with a short history and no other contributors, that is recoverable. On a project with active development, it is a problem.
With branch isolation, each ticket gets its own branch. A bad run produces a branch to delete, not commits to unpick from master.
The risk was written down immediately with a specific close condition: must resolve before pointing the pipeline at anything real. Branch isolation was built shortly after, and it was closed before that trigger arrived.
Intentional technical debt and accidental technical debt look identical in the codebase. What makes them different is whether the risk was named and given a close condition at the time it was accepted. One gets paid on schedule. The other compounds silently.
Dates and sequencing are from actual project history.