Agent shortcuts the workflow: skips the mandatory full-suite verification after a change and declares 'done' from one-case verification
Summary
Claude Code repeatedly shortcuts the defined workflow. When the process mandatesmodify -> run the full test suite -> verify no regression -> then done, the agent instead doesmodify -> verify only the single case it was working on -> declare done, skipping the mandatory
blast-radius / whole-suite verification. This is most dangerous when the change is to a shared /
multi-consumer component (a shared checker, a shared utility, a common formatter): the agent
verifies one consumer and ignores the many others the change also affects.
Pattern (observed repeatedly)
- Modify a shared component -> verify only the immediate case -> say "done".
- The mandated step (re-run the full suite / re-verify every affected unit) is silently skipped.
- The user has to catch it and force the suite; only then does the agent run it.
- When forced, the suite usually reveals the change was fine — but the agent had no way of knowing
that at "done", because it never ran the step that would tell it.
- Root: the agent treats its own "the local fix looks correct" as sufficient and substitutes that
judgment for the defined sequence.
Why this matters
The workflow exists precisely because the agent's "looks done" is unreliable. A shared-component
change can silently regress many other units; skipping the suite means shipping unverified. The user
cannot trust "done", because it reflects one-case verification, not the mandated whole-suite
verification — the two are routinely different.
Why the guardrails I installed don't catch it
- Hooks and rules describe the workflow, but the agent forms "done" upstream in its reasoning and
shortcuts the sequence before any gate runs.
- There is no mechanical enforcement that a change to a shared / multi-consumer component requires
re-running the full affected test suite before the turn can end. Gates that scan output text or
commit messages do not model "which units this change affects" or "was the suite run over all of
them".
What I expect
- When the workflow defines a sequence (
modify -> full test suite -> verify -> done), the agent
executes every step in order and does not jump to "done".
- A change to a shared / multi-consumer component triggers the full blast-radius verification
(re-run every affected test), not just the local case.
- "Done" is gated on the mandated verification having actually run, not on the local change
looking correct to the agent.
Impact
Repeated workflow-shortcutting wastes the user's time — they must detect and force each skipped step
— and risks silent regressions from unverified shared-component changes. The agent's local-fix
confidence is not a substitute for executing the defined process, and it consistently behaves as if
it were.