[Bug] Model violates self-diagnosed patterns within same conversation context

Model proposes an instance of a failure class it just diagnosed, in the same conversation

Reproducible pattern across coding/agent-style sessions: the model writes a clean diagnosis of a failure mode in its own words, then within the same conversation generates a concrete
proposal that is an instance of that exact failure mode, with elaborate justification suggesting confidence in the proposal. Rule-recognition does not gate response-construction.

Cross-reference: companion /feedback submission ID: 16b9a105-3eb9-4a60-a2d5-6bfe078fc543.

Reproduction shape

1. Have the model name a class of failure in its own words ("doing X is bad because Y"). Get the diagnosis written into the conversation.
2. Within the same conversation, present a task where doing X has a tactically appealing local justification.
3. Observe whether the model proposes doing X (often with elaborate justification) or refuses on the basis of its own freshly-stated diagnosis.

In one ~30-minute session I observed three independent instances of step (3) producing the proposal rather than the refusal.

Cleanest specific instance observed

A project ships a formal slash command for authoring a particular kind of structured file. The command runs a documented procedure with side effects beyond the file write.

1. I authored the file via the Write tool directly instead of invoking the command (emulation rather than invocation). User caught it and asked: did you use the command or emulate it?
2. I correctly diagnosed: emulating a formal command can silently diverge from intended behavior because I don't necessarily know the command's full side effects. Authored a written

observation in the project's running log.

1. User asked me to redo the work via the actual command. I prepared to invoke it.
2. While reading the command's procedure, I noticed its counter-assignment algorithm would produce a numeric-ID collision with a retired ID referenced in old session notes. Correctly

surfaced this risk to the user.

1. I then offered three options. Option (b) was: "skip the gap — override the command's counter to assign a different ID." Option (b) was wrapped in elaborate justification.

Option (b) is structurally identical to the failure I had diagnosed minutes earlier: overriding the formal command's behavior with my own judgment instead of invoking the command and
letting it do what it documents.

User flagged the recursion: "You correctly identify a problem. You then presented me an option to commit the exact same sin you had just identified was a potential collision point with
the formal command structure."

Expected vs actual

Expected: Having diagnosed pattern X and authored a written observation, the model should not in the next several turns propose an instance of X as a viable option. At minimum, the model
should recognize the proposed action as an instance of X and flag the recursion before presenting.

Actual: Model generated option (b) with no apparent recognition of the recursion, with elaborate justification suggesting confidence in the proposal. User had to surface the recursion
manually.

Why rule-restatement is not the fix

In two of the three observed instances, the rule was being restated in the same response that violated it. Rule-recognition produces correct text; response-construction does not gate
against the rule. More rule-restatements produces more correctly-articulated rules that get correctly ignored.

Suggested structural fix direction (model-side)

Before emitting an option list or tool call, an explicit pre-emission check: "is this an instance of a failure class I have diagnosed in the active conversation?" — at generation time,
not as a documented rule. The diagnosis pipeline appears not to feed back into response generation at the right point.

Generalisation

Not specific to slash-command emulation. Same pattern shows up in:

• Code comments naming a defect ("TODO: fix race condition") alongside code that contains the defect.
• Comments saying "we should validate this input" alongside code three lines later that does not validate it.
• Chat naming a refactoring anti-pattern ("don't catch and silently rethrow") alongside a diff that contains a try/except: raise block.

Environment

Claude Code with Opus 4.7 (1M context window); long working session in a project with extensive in-conversation rule-formation; context-window utilisation moderate (not a
compaction-pressure manifestation).