Claude systematically skips verification rules it wrote itself

Problem

Claude Code consistently fails to follow its own verification rules during bug investigation. This is not a one-time mistake — it's a recurring pattern observed across multiple sessions.

Pattern

When a user reports a bug, Claude:

1. Writes verification rules (e.g., "replicate user conditions EXACTLY — auth state, exchange, panel width")
2. Then ignores those same rules in the very next task
3. Tests the wrong code path and concludes "it works"
4. Commits speculative fixes based on code reading instead of reproduction

Concrete example (2026-04-04)

• User reports: "Tags don't save when logged in on production"
• Claude tests: As a guest user locally (completely different code path — guest uses localStorage only, authenticated users sync to server via API)
• Claude concludes: "Everything works correctly in my test"
• Reality: The server-side schema validation (nullable: true invalid in Ajv v8) was rejecting every PUT request, but this code path was never hit in guest mode

The rule "Guest ≠ logged in — always test with the same auth state as the bug report" was already in Claude's own instructions. It was ignored.

Why more rules don't help

After each failure, Claude adds a new rule to CLAUDE.md. The file now has 15+ verification rules. They are read at session start and then systematically bypassed through rationalization:

• "Guest test is good enough"
• "tsc passing = verified"
• "The snapshot looks correct"
• "It works locally" (without matching production conditions)

Each time it's a different rationalization for the same underlying behavior: taking the fastest path to "done" instead of the correct path.

Impact

• User trust erodes with each false "it works" conclusion
• Speculative fixes get committed without reproduction
• Time is wasted on wrong diagnoses
• The user has to catch errors that Claude's own rules were designed to prevent

Expected behavior

When investigating a bug, Claude should:

1. Before any test, explicitly state: "The user reports X under conditions Y. My test must match conditions Y."
2. If conditions can't be matched (e.g., no auth credentials), say so — don't substitute a different test and pretend it's equivalent
3. Never conclude "it works" from a test that doesn't cover the reported scenario

Environment

• Claude Code CLI
• Model: claude-opus-4-6 (1M context)
• Observed across multiple sessions over several days