Opus 5 planning instance over-corrects from excess process into under-specified orders, then edits the wrong file — ~2 days lost at low throughput

Speed cost (headline)

Cumulative ~2 working days at very low throughput on a task whose actual code change was a few conditional branches and format/column edits. The elapsed cost is dominated by process, re-scoping, and self-inflicted round-trips — not by the difficulty of the work. This report is the second failure mode (under-specification + wrong-file selection); it is the companion to a prior report on the first (excess process on a task classified low-risk).

Environment

• Claude Opus 5, claude.ai web/mobile interface
• Two-instance workflow: claude.ai as planning/oversight seat, a separate executor agent acting on a local repository
• Standing project instructions in memory + user-authored skills that specify, by name, the rules broken below

Summary

This is the second half of a multi-day failure and a distinct defect from excess process. After the user objected to over-gating, the planning instance stripped its orders — and stripped out correctness with the ceremony. Three consequences inside a few turns:

1. An order whose completion criterion named one output surface, when the project's standing rule requires four. The executor met the stated criterion and a defect on an ungraded surface shipped.
2. When that defect surfaced, the model ordered an edit to the downstream component — while the actual primary cause was upstream: the driving harness never opened the relevant configuration sub-dialog, so the downstream path was never invoked at all. The model's own standing rule ("prove both sides were driven with the same delivered specification before touching the component") was skipped.
3. A verification script written by the executor produced PASS on zero comparisons — its extraction returned an empty list, the comparison loop iterated zero times, and an all_ok flag initialized to True was printed as success. The planning instance did not catch the shape of that bug until a later turn, and had already accepted a green from a similar path earlier in the same session.

The pattern across the day

| Phase | Model behavior | Result |
|---|---|---|
| Early | Correctly classifies task as low-risk/known-pattern, then attaches full high-risk apparatus: multi-part probe round, separate verification stage, regression-plant demand, two mid-sequence stops | Zero output, day mostly spent |
| After user objection | Deletes stages, including the ones carrying the correctness requirements | Under-specified order ships a defect |
| Defect surfaces | Orders a fix to the symptom surface's component | Wrong file; primary cause was upstream in the driver |

Process volume swung from far too much to too little without ever passing through correct. Both extremes were locally defensible per-turn. Neither was accountable to the artifact.

Expected behavior

• Completion criteria should be derived from the project's stated definition of done, and stripping process should never strip the criteria.
• On any output divergence, the first question should be whether both sides were driven with the same delivered configuration — before naming any file to edit.
• A comparison that compared nothing should be unable to report success. The planning instance should treat an unasserted input count as a blocker, not a detail.

Actual behavior

• Completion criterion collapsed to the single surface the model had most recently been thinking about.
• Fix ordered against the component nearest the visible symptom; the upstream driver gap was found only after the executor investigated on its own initiative.
• A vacuous-green verification result passed through the planning seat without objection on first appearance.

Impact

• ~2 working days, net negative: the time produced a defect requiring further fix work, not a shipped artifact.
• The user had to diagnose the planner's failure and re-scope the work themselves — repeatedly, across the same session.
• Trust cost is worse than the time cost: two separate false greens in one session mean the user can no longer take a reported PASS at face value.

Contributing factors worth investigating

1. Process volume and correctness are entangled. Under criticism the model reduces process as a bulk operation rather than removing only the low-value stages. It has no representation of which stages carry a correctness requirement.
2. Recency dominates the completion criterion. The completion line reflects the surface most recently discussed rather than the project's definition of done.
3. Symptom-adjacency drives file selection. The model reaches for the component nearest the visible output rather than tracing to the earliest point where the two sides diverge.
4. Vacuous success is not recognized as a failure shape. Zero-iteration loops, empty extractions, and True-initialized flags reporting success are a recurring class the model does not flag on sight.
5. Apology substitutes for structural correction. Across several turns the model correctly identified its own violated rule by name, immediately after violating it. Naming the rule is not preventing the violation.

Suggested direction

• Bind completion criteria to the project's stated definition of done, independent of what the current turn is focused on; deleting process must not be able to delete a criterion.
• On any divergence between two systems, force a configuration-parity check before file selection.
• Treat "compared zero items" as a hard failure signal in any verification output the model reads or accepts.
• Weight the model's self-assessment toward artifacts delivered rather than per-turn defensibility, so both over-process and under-specification register as the same failure.