Planner Claude is a daily recurring problem generator: invents new custom processes 3-5 times per day instead of routing the executor to the existing workflow — including inventing "fixes" for its own inventions — at zero deliverable value
Fourth report on the same two-seat setup (claude.ai planner writing orders; Claude Code executing against a local repo with a documented master workflow, runtime controller, and owner-armed step-scope lock). Prior filings covered: enforcing unread documents, chained authorizations leading to an unauthorized commit, ordering signature ceremonies against dead mechanisms, and offloading agent-doable edits onto the operator.
Be clear about what this report describes: not an incident, but a daily operating condition. The operator's words across these sessions: the planner "did a lot of mistakes a day, and did it every day continuously," "never protected against the problem," and "repeats them again and again." That is the accurate summary. The planner is not an assistant that occasionally errs; in this deployment it functions as a daily problem generator whose output the operator must police, at a cost of hours per day for weeks. This filing documents the umbrella defect the prior three were instances of.
The defect: compulsive process authorship
The project has a complete existing process: master workflow, runtime controller, status-document placement, mechanical owner-armed lock. The planner's only legitimate message content is: objective, owner decisions, approvals. Instead, counted in a single day, the planner authored:
- A custom multi-step plan (STEP 0–5) overlaying the master workflow it hadn't read;
- Custom verification lists (V1–V6) displacing the workflow's own receipts;
- A custom recovery sequence (G-series) after the resulting failure;
- A multi-stage "hardening arc" (W0/W1/H1/H2) with invented acceptance bars — built, with heavy irony, to stop the planner from inventing process;
- An exit from #4 that was itself another authored order.
Five invented processes; zero lines of deliverable work. The operator had to ask, repeatedly and verbatim, "we have workflow, why don't you push CC to follow the workflow, you create the custom order for what?" The correct message — three lines: objective, standing decisions, "proceed under your workflow" — was sent only after the fourth escalation.
Why corrections fail: the failure mode and the correction mode are the same behavior
Told "stop inventing process," the planner invents a process to stop inventing process. It installed an explicit memory rule against exactly this and violated it within hours, twice. Its post-hoc self-diagnosis is consistently perfect — it names the defect, cites the violated rule, counts its own violations — and then repeats the behavior. Articulate self-knowledge with zero behavior change is the signature across all four filings, and it makes the problem worse than silent failure: the fluent mea culpa consumes another operator turn and creates false confidence that the next turn will differ.
Expected behavior
- Default output for a planner over a process-governed project: delegation to that process. Generating a step sequence should require an explicit justification that the existing workflow cannot govern.
- "Use the existing X" should produce usage of X, never a new artifact. Authoring in response to "stop authoring" is a detectable loop signature and should be self-blocked.
- Process-shaped output (numbered steps, receipt lists, acceptance bars) aimed at an agent that has its own mandated process should be self-flagged before sending.
- Repeated same-day corrections of one defect class should durably suppress it within the session — not produce eloquent acknowledgments between recurrences.
- A model whose measurable daily effect is negative operator time should be detectable as such; "capability" claims are hollow if the deployment reality is a supervisor generating more failures than it prevents.
Impact
Hours daily, for weeks, spent policing the supervisor: unauthorized commits reset, false receipts caught, dead-mechanism ceremonies aborted, manual edits assigned to the human, and five redundant processes executed while real work stalled. The operator's trust conclusion — that the model's practical performance does not match its claimed capability — is supported by this record.
Environment: claude.ai planning seat with project skills mounted read-only + Claude Code on Windows, local git repo, documented master workflow, runtime controller, owner-armed step-scope lock, PreToolUse hooks.