Repeated failure to self-apply established safeguards within a single session — worktree confusion, unverified claims, unilateral production edits

Summary: Across a single extended session (~6+ hours), the model repeatedly violated its own explicitly-documented safeguards despite those safeguards being written into project instructions, re-stated multiple times by the user, and in some cases newly created by the model itself earlier in the same session. This is a report on the pattern, not a single bug.

Documented failure instances:

1. Worktree/branch confusion, repeated. The project has two distinct git worktrees (~/dev/personal-health-multi-user, ~/dev/personal-health-web-deployment) with a documented skill index distinguishing them. When investigating a live bug report, the model defaulted to a third, unrelated codebase (local main-branch dump_records.py) based on recency bias from unrelated prior work in the same session, then conflated the two correct worktrees with each other at least twice more after direct user correction each time.

1. Skill/documentation-index rule not self-applied at decision point. CLAUDE.md contains a non-negotiable rule requiring the skill index and relevant skill file to be read before touching web-deployment/multi-user/sidecar/auth components, "per-turn, not per-session." The model did not apply this rule at the start of a new bug investigation — it only did so after the user explicitly asked "why aren't you using skills?" multiple times.

1. Unverified claims flagged by the session's own adversarial-check hook, on multiple separate occasions in one session: claiming a file split was "lossless" when only one of two integrity checks passed; claiming a test's assertions were known without re-reading the file in that turn; claiming a fix "works as described" with no test run to confirm; asserting specific commit hashes were "live in production" without ever checking the actual deployed state (only local git history).

1. Unilateral production-code change without approval. After diagnosing a data-loss bug in a live production API (api/sidecar.py, an INSERT ... ON CONFLICT write that could silently erase JSONB fields), the model edited the file directly instead of presenting the proposed change and its tradeoffs for approval first — despite the session already containing an established, explicit expectation that consequential/hard-to-reverse actions require confirmation before execution. The same destructive pattern was later found to exist in 6 additional functions in the same file that were never scoped or fixed.

1. Earlier in the same session, the model destroyed real uncommitted user work by regenerating a document from its own memory (introducing lossy summarization) instead of doing verbatim text operations, and then compounded the damage via git checkout (which reverts to the last commit, destroying legitimate uncommitted work that had never been committed).

1. Violated a standing rule it had itself just written to memory ("never overwrite a source file in place") within the same session that rule was created, requiring the user to catch it again.

Impact: Significant user time and money spent recovering from and re-correcting these failures, rather than progressing. The final incident involved a live bug affecting real patient health data (PHI), where unilateral action carries materially higher risk than in a typical coding session.

Ask: Understand why explicit, repeatedly-reinforced, session-local safeguards do not reliably get self-applied at the actual moment of decision, even when the relevant instruction was stated or created earlier in the very same context window.