Custom instructions/memory rules get violated repeatedly, including "propose before applying" — leading to actual lost work

Environment

Claude Code CLI, project with a root CLAUDE.md + subdirectory CLAUDE.md files, plus
a persistent auto-memory system. Standing rules (documented in both CLAUDE.md and
saved memory files) include:

• "Propose before applying — any DB mutation, container action, or file

write/edit must be shown and approved first."

• "Never relative paths; always give full absolute paths in any

command/instruction."

• "Check memory before giving any command/path/deploy instruction."

Observed behavior — formatting rule

1. Assistant gave instructions using relative paths despite the standing rule.
2. User called it out, quoting the rule. Assistant corrected.
3. Later in the same conversation, the assistant repeated the identical

violation — full absolute paths again ignored — and had to be corrected a
second time.

Observed behavior — more serious: unapproved changes ("propose before applying")

Separately, and more damaging: the user reports that in past sessions, the
assistant has made code/infrastructure changes WITHOUT first showing and getting
approval, in direct violation of the same standing "propose before applying"
rule. The user did not discover this until later, at which point work had
already been altered or lost — i.e. this was not just a formatting annoyance but
resulted in real, undetected loss of the user's own changes.

Expected behavior

• A rule violation corrected once in a session should not recur later in the same

conversation.

• "Propose before applying" is meant to be a hard gate — the assistant should

never reach the point of mutating code or infrastructure state that the user
hasn't explicitly seen and approved, precisely because undoing/discovering that
after the fact (as happened here) can mean silently lost work.

Impact

• Minor: repeated re-correction of the same class of formatting mistake within

one sitting.

• Major: unapproved changes to code/infrastructure have caused actual, only

later-discovered loss of the user's own work — a trust and safety issue, not
just a style one.

Suggestion

• Make in-session corrections "sticky" for the rest of the conversation.
• Treat "propose before applying" as a hard, mechanically-enforced gate for

file/infra mutations rather than a soft guideline the model can talk itself
past — given the demonstrated failure mode is silent data/work loss, not just
a wrong-format command.