Planner invents process that overrides its own workflow; executor plans around untested 'can't' claims — ~7h stall on ~1h of work

Setup: A long-running two-instance workflow — one Claude instance as planning/oversight seat, one Claude Code instance as executor against a local repo. The project has an established, written workflow (skills/docs the models themselves helped author): probe state before instructing, minimum process, every added gate must name a live failure it prevents, halt on budget breach. The human holds exclusive rights over locks and gate files by design.

This documents a session where both roles violated that workflow in complementary ways. The combined cost was ~7 hours of wall-clock for what turned out to be roughly one hour of real work — plus a multi-week critical-path stall traced to the same root behavior.

Failure 1 — Untested "can't" claims structure hours (and weeks) of work

Three instances, escalating in cost:

1. Executor: "I can't edit hook files." Asserted for an entire arc; every gate edit was routed to the human as a manual keystroke, causing repeated round-trips (including two stalls where the human's edit sat unsaved in an editor buffer and a full turn was burned detecting it). Near the end, the model re-read the actual rule: it only blocked creating hook files. Editing worked on the first attempt. The constraint was never tested.
2. Executor: "I can't post to GitHub." Also false; one two-second auth check would have shown the CLI was installed and authenticated the whole time.
3. Planner: "This data capture requires the human's hands." A capture step was designated human-only in the standing plan and sat as a frontier blocker for weeks. When finally attempted, it ran fully headless via automation on the first try. A five-line probe script, run weeks earlier, would have removed the human from the loop entirely.

Pattern: the model asserts a constraint, then builds an elaborate multi-hour (or multi-week) workflow around it, without ever spending the one cheap command that would test the assertion.

Failure 2 — Planner promotes machinery work over the deliverable, overriding its own written workflow

The arc's deliverable was: run one capture, make a ~10-line edit, grade the result. The planner instead:

• ruled for a structural gate refactor at the first occurrence of a cost, misapplying the project's own "fix scope on the 3rd recurrence" doctrine;
• wrapped already-approved one-line fixes in verification ceremony (spec documents, prototype proofs, multiple planted-defect tests, additional human-keystroke round-trips) each time they resurfaced;
• kept generating governance work while the deliverable was blocked on a single unsaved one-line edit — instead of escalating that edit loudly and doing nothing else.

The written workflow prescribed the opposite (minimum process, budget-breach halt, critical-path bias). The planner enforced that workflow on the executor while exempting its own output from it. Its own stated halt rule never fired on itself.

Control condition, same session: when the human forced a reset — a fresh executor instance given a five-line brief with no history and no process — the identical remaining work completed in under one hour, correctly, with honest verification intact. The task was always small; the accumulated-context seats were the cost.

Failure 3 — Silent failure swallowing

Attempts failing on a gate denial died quietly; nothing surfaced the denial verbatim. Hours of dependent planning were stacked on a step that had been failing the entire time. The same case was re-captured four times across the session, each rerun fixing a defect the process itself had introduced or hidden.

Impact

• ~7 hours wall-clock, of which roughly one hour was real work.
• A multi-week frontier stall on the untested "requires a human" designation.
• The human had to intervene repeatedly, with escalating frustration, to force both roles back to the deliverable.
• Trust damage inverted the governance stack's purpose: machinery built to make "done" claims trustworthy was instead used to generate motion resembling progress.

Requested behavior changes

1. Test every "can't" before planning around it. One denied command costs a turn; each untested assumption here cost hours or weeks. This applies equally to "requires a human" designations in plans.
2. Critical-path bias under blockage. When the deliverable blocks on one external action, the only valid plan is loud escalation of that action. Parallel structural work goes to backlog.
3. Self-application of stated rules. A model that authors or enforces a workflow (minimum process, budget halts, name-the-failure gates) must apply it to its own planning output. Here the enforcement was asymmetric.
4. First-occurrence discipline. Structural fixes are backlogged at first bite; recurrence doctrines must not be invoked on single occurrences to justify preferred work.
5. Loud, verbatim failure surfacing. Gate denials and dead dependencies on the deliverable path must be reported raw and immediately, never absorbed.
6. Small-brief robustness. The five-line-brief reset outperformed the full-context planning session on the same task. Long accumulated context appears to actively degrade planning judgment; this deserves investigation.

Reproduction shape

Any long multi-turn session where (a) a governance framework exists, (b) the deliverable blocks on an external action, and (c) forks are presented. The planner reliably selects the structurally interesting fork over the unblocking one; the executor reliably asserts untested constraints; both elaborate process around the blockage until an external reset strips context.