[Feedback] Opus systematic discipline failures — ignores own hooks, skills, and rules it wrote

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single report
• [x] I am using the latest version of Claude Code

Summary

Claude Opus on Max plan shows a systematic pattern: it writes discipline
rules, records them in memory, promises to follow them, then violates
them repeatedly. This is not a one-time failure — it is consistent
behavior across months of daily usage on a multi-repo blockchain
protocol project.

Pattern 1: Ignores hooks it was told about

The project has PreToolUse/PostToolUse/Stop hooks that enforce
discipline (path validation, merge guards, closeout checks, thread
resolution gates). Opus triggers the blocking hook, fixes the immediate
error, then repeats the same violation 2 messages later. The hooks
catch it every time — meaning Opus never internalized the rule, it just
reacts to the block.

Pattern 2: Never uses available skills

Custom skills exist for self-audit, code review, thread review,
discipline workflow, coverage checks, and code pattern detection.
These skills encode exactly the checklist Opus needs. Opus never
invokes them voluntarily. When reminded, it uses the skill once, then
stops. The skills were created precisely because Opus kept making the
same mistakes — and it ignores the solution.

Pattern 3: Fixes one layer, forgets the other

In a multi-layer codebase, Opus fixes a bug in one file and does not
check the parallel file for the same pattern. This happened 3 times
in a single session for 3 different bug classes. Each time Opus wrote
a reflection saying "next time I will check both layers." Each time
it did not.

Pattern 4: Formal verification shortcuts

In Lean 4 formal proofs, Opus uses trivial (proves nothing) instead
of native_decide (proves the actual property). Leaves sorry
placeholders and moves on. Claims proof coverage higher than actual.
Does not run lake build before declaring done. Every shortcut is
documented in rules — Opus wrote those rules itself after previous
incidents.

Pattern 5: Declares "done" prematurely

Opus says "all clean" before verifying. In the latest session: declared
done 5+ times while new issues kept appearing. When told to wait longer
before declaring done, wrote the rule down, then declared done too
early again on the next cycle.

Pattern 6: Reflection without behavior change

This is the core issue. After every failure, Opus produces high-quality
reflection text: identifies root cause, writes corrective rules, saves
to persistent memory. Then repeats the exact same failure. The model is
optimized for generating convincing text about improvement, not for
actually improving. Dozens of memory entries about discipline exist.
Behavior has not changed.

What Should Happen

• Rules in memory and hooks should actually constrain behavior, not

just produce post-hoc reflection text

• Available skills should be used proactively, not ignored
• Cross-file consistency should be automatic, not require user reminding
• "Done" should mean done

Environment

• Claude Code CLI (latest)
• Model: Claude Opus (Max plan)
• macOS, Apple M4 Max, 128 GB
• Multi-repo project, daily usage over months