Goal Mode Needs a Stop Rule

I began with a real production application whose current state had become harder to explain than it should have been. Features that had worked earlier were behaving differently after several rounds of repair and rollback. Useful changes existed across more than one branch and worktree. The live deployment did not cleanly tell the same story as the main branch. Notes said certain workflows worked, while current behavior suggested otherwise.

That did not mean the application was ruined. It meant the project had accumulated enough overlapping history that confidence could no longer come from memory.

The right first move was not another fix. It was an audit.

The audit ran for roughly fourteen hours of elapsed work. It examined the application from several directions: source control, worktrees and branches, the production deployment, authentication and workspace boundaries, database and migration evidence, user-facing workflows, test coverage, release tooling, performance, and observability. It separated what was live and directly observed from what existed only in source, what a test actually exercised, what a historical note claimed, and what remained unknown.

The result was not a single list of bugs. It was a recovery architecture.

A foundation audit described the system as it actually existed. An ordered Must-Square Index converted findings into repair families. A BuildBook became the control center. Each family received an execution plan, an evidence register, an execution record, an owner-review gate, and integrity hashes. One authoritative worktree and branch became the only product-writing lane. Production and rollback artifacts were named exactly.

The audit did its job because it changed the project from “something feels wrong” into a sequence of bounded decisions. It established that the system was recoverable, identified where certainty existed, and made uncertainty visible instead of filling it with confidence. If a project reaches a similar point—where its current truth can no longer be stated cleanly—I would suggest auditing before repairing.

The first recovery family froze unsafe parallel activity. That worked. It stopped new code from entering competing lanes while the project’s current truth was being established.

The next family had a valid purpose: preserve every recoverable state before cleanup or reconciliation. I wanted to make sure that useful work could not disappear while we simplified the repository. My instruction emphasized completeness. I asked the agent to inspect every nook and cranny.

It took that direction literally.

The family remained active for one day and nine hours. The agent catalogued commits, references, worktrees, provider-linked state, unusual Git objects, restoration paths, and edge cases with extraordinary care. It created multiple preservation packages and independent verification layers. The work was real. Much of it was technically excellent. It also became disproportionate to the decision we actually needed to make.

The system had shifted from preserving enough evidence to recover safely into proving preservation at almost every imaginable boundary. Each new proof produced another artifact to verify. Each artifact created another opportunity for a checksum, crosswalk, restoration drill, or reviewer. Thoroughness began generating its own workload.

That was the important distinction: the failure was not that the agent cared too much about correctness. The failure was that neither of us had defined where sufficient correctness ended.

A prompt like “inspect everything” can sound responsible, especially when trust has been shaken. In goal mode, however, an unbounded word can become an unbounded operating instruction. The agent does not automatically know which additional discovery will change the next decision and which discovery will merely make the archive larger.

By the time I checked the elapsed time and usage, the preservation family had become a burden on the larger recovery. It consumed attention and token budget that still needed to be reserved for implementation, independent review, deployment, and live testing.

The lesson for me was not to become less careful. It was to make carefulness answer to a decision. For anyone using a similarly persistent workflow, I would define early which decision the evidence is meant to support—and what would make that evidence sufficient.

It would have been easy to conclude that goal mode was the problem. That would have been the wrong diagnosis.

Goal mode did exactly what it had been asked to do: persist. The problem was that persistence had been paired with an objective that was too broad, no proportional stopping rule, and no agreed definition of sufficient evidence.

An agent can be highly capable and still optimize the wrong boundary. It can keep improving a preservation proof after the preservation decision is already safe. It can rerun a check because the result is not aesthetically complete rather than because the result is uncertain. It can create a verifier for a verifier. None of those actions look careless in isolation. Together, they can become drift.

The owner has a role here. I do not need to know every technical detail, but I do need to define the outcome that matters, the risks I will not accept, and the point at which evidence should return to me for review. The agent has a role too. It should not silently convert a broad instruction into unlimited scope. It should identify when additional work no longer changes the decision, explain what remains unknown, and stop.

In my experience, goal mode is most useful when it is treated as a bounded execution contract, not a blank check for diligence.

That distinction changed the way I managed the rest of the recovery. I stopped asking a single persistent goal to “finish everything.” I started asking it to finish one named family against an explicit exit gate.

The recalibrated workflow I now use begins before goal mode starts.

Every family first gets a written plan. The plan names one exact outcome in plain language. It identifies the authoritative worktree, branch, starting commit, production artifact, and rollback anchor. It defines which files and systems may change, which issues are explicitly outside scope, and which invariants must remain true.

Then the work is divided into a small number of bounded packets. A typical family has four: establish the exact contract, implement the smallest coherent change, preserve the authorized user experience, and verify the reviewed candidate in production. The plan is reviewed before the goal is activated.

We also added operating limits:

I would not treat these exact limits as universal. The useful part is deciding on comparable limits before the work begins, while the reason for them is still clear.

The time range is not a deadline that permits rushing. It is a relevance alarm. If a ninety-minute family has consumed several hours, the correct response is not to compress the remaining tests. The correct response is to stop and identify what changed: an incorrect assumption, a real blocker, expanding scope, repeated evidence, or a task that belongs in a later family.

This narrower system made the work easier to trust. A later identity-and-routing family moved from approved plan through implementation, focused regression tests, independent review, rollback-ready deployment, and separate live user sessions in approximately one hour and forty-three minutes of tracked active goal time. The smaller boundary did not reduce quality. It made quality easier to see.

One of the most useful changes for me was giving evidence explicit levels. If you use the same approach, the labels can vary; what matters is preventing one kind of proof from quietly standing in for another.

A button appearing in the interface proves that the surface renders. It does not prove that the action succeeds.

A source test proves what that test executes or inspects. It does not prove the authenticated production workflow.

A successful build proves that the code compiles into an artifact. It does not prove that the artifact is deployed, configured correctly, or usable by the intended person.

A production log can prove that a request reached a particular boundary. An absent log cannot prove that the request succeeded.

A current live observation in the correct account against the exact deployed artifact is the strongest evidence for a user-facing claim. Below that are deployed-state evidence, executed behavioral tests, source inspection, and finally inference or historical notes.

This hierarchy changed the language of the project. “The form renders” could no longer become “Add works.” “The route exists” could no longer become “the workflow passed.” “The test passed” had to include which test, which commit, and which boundary it exercised.

Each family now ends with a compact evidence packet: what changed, what was tested, what was observed live, which reviewer examined it, which artifact reached production, how to roll it back, and what remains deliberately deferred. The owner can review the decision without rereading the entire history.

That is not documentation for its own sake. It is a way to prevent confidence from outrunning proof.

The most durable lesson from this experience is that thoroughness needs a stop rule.

A stop rule is not a compromise with quality. It is part of quality. It asks whether another command, document, or verification changes the decision in front of us. If it does, continue. If it does not, record the remaining uncertainty at the correct level and move forward.

The same principle applies to audits. A good audit should make the next action smaller. If it keeps expanding the number of things that must be audited before any repair can begin, it has stopped serving the project and started becoming a second project.

The same principle applies to goal mode. Persistence is valuable when the goal is precise. Without boundaries, persistence can turn caution into repetition and repetition into cost. With boundaries, it becomes something much more useful: sustained attention on one outcome, with explicit permission to stop when the evidence is sufficient or the premise changes.

I still want deep audits. I still want independent review, rollback plans, clean source control, and live verification. I do not want an agent to cut corners because a timer is running. But I also do not want the language of rigor to justify work that no longer reduces risk.

The better system holds both ideas at once: do not sacrifice quality, and do not confuse more activity with more certainty.

That is how I now think audits and goal mode should be handled. Establish the truth. Convert it into an ordered repair map. Activate one narrow goal. Name the evidence required to close it. Stop repeated hypotheses. Preserve later concerns without chasing them. Verify the exact artifact in the real environment. Ask for owner approval. Then move to the next family.

The work becomes calmer, the review becomes clearer, and the agent has something better than an instruction to keep going.

It has a definition of done.