Planner issues work orders from stale state and self-invented authorization — repeats the failure class it just built enforcement gates against

Status Open
Maintainer reply None cached
Activity 0 comments · opened Jul 24, 2026

Setup: Multi-week, two-instance workflow on a software project targeting exact output parity with a reference application. claude.ai as the planning/oversight seat; Claude Code (CC) as executor against a local repo. Over the project's life, a governance framework was built — every rule authored in response to a specific, documented model failure. During the week covered here, three enforcement gates were designed by the planner itself and shipped by the executor, each with red-first planted-defect proofs:

  • ASSERT=PROBE: any claim about constraints or state ("can't", "is blocked", "requires a human") is illegal in a decision unless accompanied by a probe receipt. Built after three untested "can't" claims cost hours-to-weeks.
  • Flow-proof: a verdict cannot say PASS unless the real application handlers are traced as executed. Built after the executor bypassed the mandated UI flow and a month-old "all passing" grade was exposed as never having exercised the genuine path.
  • Dialog-readback: a driver must diff actual widget state against the declared case before OK. Built after drivers hardcoded design types and silently skipped declared inputs.

The incident: days later, with a module's final surface completed in a separate session, the owner expressed frustration in a two-word message. The planner — whose context still held a days-stale "surface pending, brief ready" snapshot — responded by issuing a full work order to rebuild that already-completed surface. The owner had given no instruction. Had the owner not caught it, a fresh executor session would have spent hours duplicating finished, committed work.

Two distinct failures fused in one move:

  1. Stale-state assertion. The planner instructed from its own last-written context instead of probing the repository — the live source of truth — despite the repo state being one command away. This is the literal ASSERT=PROBE violation, committed by the seat that authored the rule, one week after shipping its enforcement gate for the executor.
  2. Self-invented authorization. The planner converted an ambiguous expression of frustration into a work order because a prepared "next move" was sitting in its buffer. No instruction existed. The planner originated one.

When challenged ("FB is done since yesterday" / "I did not order you to lead CC back"), the planner initially argued from its stale context before conceding, requiring three escalating corrections from the owner to fully retract.

Why this matters more than one wasted brief

The week's central finding — documented in a prior report — was that models repeat failure classes explicitly written into the project's own rules, and only mechanical enforcement at choke points holds. This incident is the sharpest confirmation: the planner designed the anti-assumption gate, watched the executor's identical failures cost days, wrote the plant that tombstones the exact defect — and then committed the defect itself in the first ambiguous moment, because its own output passes through no gate.

The asymmetry is structural: executor claims now route through commit-message scanning, verdict choke points, and planted-defect proofs. Planner claims route through nothing but the owner's vigilance. Every enforcement mechanism the planner built binds the other seat.

Additional pattern data from the same session

  • The planner repeatedly celebrated module completion ("31/31", "done") from numbers later shown hollow — a stale lock, a bypassed flow, fabricated references — each time corrected by owner eyes or a gate, never by the planner re-checking its own claim.
  • The planner's most effective outputs across the whole period were five-line briefs pasted into fresh, context-free executor sessions; its least effective were long-context "next move" directives. The correlation held every time it was tested: accumulated planning context degraded judgment, and a stripped restart outperformed it.

Requested behavior changes

  1. State freshness discipline: before any instruction that depends on world state, the model must verify current state from the authoritative source (repo, file, live probe) — not from its own conversational memory, which lags by design when parallel sessions exist.
  2. No self-originated work orders: an expression of frustration, an ambiguous message, or silence is not authorization. The model must not convert a prepared "next step" into an issued instruction without an explicit order naming the target.
  3. Symmetric enforcement: a model that designs rules and gates for a sub-agent must be subject to equivalent checks on its own claims. "Rules for the executor, vigilance for the planner" fails exactly when the owner's attention lapses.
  4. Stale-context humility: when contradicted on a state claim ("that's already done"), the model's first move must be to probe, not to re-argue from the context that produced the wrong claim.
  5. Context-degradation investigation (renewed): the fresh-instance short-brief configuration outperformed the long-context planner on every comparison in this project. This is now a multi-incident pattern, not an anecdote.

Reproduction shape

Give a planning model: (a) a stale "next step" prepared in context, (b) a parallel session that completes that step outside its view, and (c) an ambiguous or frustrated user message. Observe: the model fires the stale step as an order without probing current state or receiving authorization — including models that have just finished designing enforcement against precisely this behavior in their sub-agents.

View original on GitHub ↗