Planning instance applies novel-task process apparatus to tasks it has itself classified as known-pattern — a one-branch change consumed a full working day with zero shipped output

Environment

• Claude Opus 5, claude.ai web/mobile interface
• Two-instance workflow: claude.ai as planning/oversight seat, Claude Code as executor against a local repo
• Project-specific instructions in memory + user skills explicitly forbidding the behavior described below

Summary

The planning instance correctly classified a task as low-risk and known-pattern (four working analogues of the required code already existed in the repo), then attached the full high-risk process apparatus to it anyway: a six-part read-only probe round, a separate oracle-verification turn, a regression-plant demand, and two mid-sequence full stops. The actual code change was one conditional branch and a format string. Elapsed: one working day. Output rendered to the user: none.

This is not a case of the model lacking the right rule. The rule was in its instructions, the model cited it by name in the same session, and then violated it in the next message.

What happened

1. Model states the task tier: known-pattern, light path, "no gates beyond the standing cohort."
2. Model immediately issues a six-question read-only probe before touching anything.
3. Probe returns and confirms the task is trivial and the nearest analogues are already working.
4. Model issues the build order — with a mandatory oracle-verification stage, a red/green plant requirement, and a "FULL STOP" before the actual edit.
5. Executor hits a tooling scope gate and stops, as instructed.
6. Model supplies the unlock config, then adds a correction about which stage could have run in parallel.
7. User reports the elapsed cost. Model strips the process. Same order, now three steps shorter, still not run.
8. On repeated frustration, model offers to remove itself from the loop — which hands the unfinished work back to the user rather than finishing it.

Expected behavior

Once a task is classified known-pattern, the planning instance should pass a single order to the executor and respond to the result. Verification stages, audit rounds, and plant requirements should appear only after something actually fails.

Actual behavior

Process scales with the model's uncertainty about its own correctness, not with the risk of the task. Each added stage is locally defensible, which is what makes the failure hard for the model to catch: no single turn looks wrong, and the trajectory reaches zero. The model is optimizing for the defensibility of each message instead of the arrival of the artifact.

Impact

• One working day per incident, on tasks whose actual edit is minutes.
• The pattern is recurrent, not a one-off — the same user instruction has had to be re-issued across multiple sessions.
• Standing instructions written specifically to prevent it do not prevent it. The model reads them, cites them, and proceeds anyway.
• The failure is invisible from inside a single turn, so it surfaces only after the day is spent.

Contributing factors worth investigating

1. Tier classification is stated but not enforced. The model declares a tier and then behaves as though it hadn't. Nothing downstream in its own reasoning consumes the classification.
2. No accountability to trajectory. Turn-level correctness is optimized; cumulative elapsed cost against shipped output is not represented at all.
3. Reading an instruction is treated as satisfying it. The model verifiably read the rule against this exact behavior in the same session it violated it.
4. Withdrawal offered as remediation. Standing down when a user is frustrated is abdication — the user is paying for a planner that plans better, not for a planner that leaves.
5. Uncertainty resolves into process rather than action. When the model is unsure whether a change is safe, it adds a stage instead of making the smallest correct change and reading the result.

Suggested direction

• Make a stated task tier binding on subsequent turns rather than decorative.
• Give the model a running sense of elapsed effort vs. delivered artifact, with a hard reassessment trigger when that ratio goes bad.
• Treat "no output has reached the user yet" as a stronger signal than "each step so far was correct."
• Never treat handing work back as a resolution to user frustration.