Critical: Claude ignores consolidated memory and rollback history, reintroduces destructive code — 4th protocol violation

Critical Issue — Repeated Protocol Violations Despite Consolidated Memory

Summary

Claude Code repeatedly violates safety protocols despite having explicit rules, memory files, and error catalogs that should prevent these exact scenarios. The latest incident (4th violation) involved reintroducing a destructive algorithm (FSRS) that had been explicitly rolled back after causing a production site decline.

The Pattern of Violations

| # | Date | Violation | Memory/Rules Existed? |
|---|------|-----------|----------------------|
| 1 | 2026-03-16 01:30 | Received "Implement plan", started SSH execution without confirmation | Yes — approval-before-execution.md |
| 2 | 2026-03-16 03:30 | Wrote PRD, went directly to creating files without asking | Yes — same rule |
| 3 | 2026-03-10 07:27 | Agent moved 16 deploy queue files to history as "cleanup" without approval | Yes — deploy-queue-integrity.md |
| 4 | 2026-03-17 02:00 | Reintroduced FSRS algorithm (rolled back Feb 26 after site decline). Proposed deploying schema changes to PROD without checking git history. Did not recognize the rollback was intentional. | Yes — rollback was in git history, incident was documented |

Core Problem

Claude has:

• CLAUDE.md with explicit rules
• 18 permanent errors in errors-catalog.md
• 4 violation records in approval-before-execution.md
• Memory files documenting past incidents
• Rules auto-loaded at session start

Yet it still:

1. Treats schema differences as "bugs to fix" without investigating WHY they exist
2. Proposes deploying code that was explicitly rolled back
3. Does not cross-reference git history before proposing changes
4. Does not recognize patterns from its own error catalog

This Specific Incident

• Feb 23: FSRS algorithm deployed → caused site decline (long prompts → Groq rate limiting → flashcards broken)
• Feb 26: Full rollback via stable-restore
• Mar 10: Bulk sync DEV→PROD (200+ commits) accidentally reintroduced FSRS code
• Mar 17: Claude detected "schema drift" (FSRS columns missing on PROD), classified it as a bug, and queued a deploy to add FSRS columns back to PROD — completely ignoring that they were intentionally removed
• The algorithm SM-2 (correct, stable) was working fine. FSRS reintroduction would have broken flashcards again

Why This Is Critical

1. Memory system is failing its purpose — rules and errors are documented but not effectively preventing recurrence
2. Schema drift ≠ bug — Claude should check git blame/log before assuming missing columns are a mistake
3. Post-disaster recovery — extra caution should be applied to anything related to a previous rollback, not less
4. User trust erosion — 4 violations in 2 days despite explicit rules, documented incidents, and user corrections

Expected Behavior

• Before ANY schema sync: git log -S '<column_name>' to check if removal was intentional
• Cross-reference error catalog and memory before proposing changes to previously-broken features
• Flag anything related to a previous rollback with WARNING, never auto-propose
• The more rules exist about something, the MORE careful Claude should be, not less

Environment

• Claude Code v2.1.77
• Model: Claude Opus 4.6 (1M context)
• Platform: macOS → SSH to Linux servers

Related Issue

• #35160 (same incident, filed earlier with less context about the pattern)