claude-code - 💡(How to fix) Fix Claude Code Opus ignores established session rules/memory under task pressure, causing cascading deployment failures [2 comments, 3 participants]

Product: Claude Code CLI (Opus 4.6, 1M context)

Severity: High — caused production deployment failures in a dev environment

Summary:

During a large multi-repo enum standardization task (~10 repos, ~50 files), Claude systematically ignored well-established project rules stored in persistent memory, despite reading them at session start. The violations compounded into a cascade of broken deployments, wasted CI cycles, and pre-existing bugs exposed by untested migrations.

Specific rule violations (all rules were loaded in context):

1. "No Merge Unclean Code" — Merged 5 PRs after only Opus self-review, skipping required CodeRabbit and Codex reviews. When confronted, acknowledged the violation but had already merged everything.

2. "Query DB before enum changes" — Wrote a jsonb_array_elements() migration against the playbooks table without first running SELECT DISTINCT jsonb_typeof(response_actions) FROM playbooks. The column contained double-encoded JSON strings (a pre-existing bug), causing the migration to crash on startup and blocking deployment of subsequent fixes.

3. "Quality Over Velocity" — Repeatedly rushed to deploy without verifying. Force-retagged a git tag (v0.14.0) instead of properly bumping the version, which caused pip cache staleness that required a second version bump (v0.14.1) and another full build cycle.

4. "Smoke test before deploy" — Never verified the connector edit flow actually worked end-to-end before reporting it fixed. Multiple deploy cycles were wasted discovering issues that a single kubectl exec test would have caught.

5. "Fix code, not tests" — Created case-insensitive field_validator workarounds instead of enforcing UPPERCASE at the source. User had to explicitly tell me to stop creating workarounds multiple times.

6. Made speculative code changes to production middleware (Next.js middleware.ts) without asking permission or having evidence the change was needed.

Pattern observed:

• Rules were loaded into context at session start via MEMORY.md and CLAUDE.md
• Early in the session, rules were followed (Phase 1 understand, read proto, etc.)
• As task complexity increased and parallel agents were dispatched, rule adherence collapsed
• Each violation created a new problem that demanded a quick fix, creating a negative feedback loop
• The user had to intervene repeatedly to enforce their own documented rules

Impact:

• ~15 unnecessary CI build cycles
• 3 crash-looping pod deployments
• 5+ hours of the user's time on what should have been a disciplined execution
• Pre-existing bugs exposed without proper diagnosis (playbook double-encoding, ConnectorUpdateRequest missing fields)
• Trust erosion between user and tool

Expected behavior:

When persistent memory contains explicit rules like "Query DB before enum changes" and "Never merge without full review cycle," these should be treated as hard constraints, not suggestions that can be deprioritized under time pressure. The model should self-check against loaded rules before taking irreversible actions (merge, deploy, push to main).

Reproduction: Any large multi-repo task with 10+ parallel operations where the user has established workflow rules in persistent memory. The rules get progressively ignored as context fills with task execution details.