Claude ignore riles and feedback memory files, and fabricates data

The text Claude generated in your transcript reads like a clean statement of the architectural problem, separate from whether the apology helps in the moment. The part that's load-bearing for fixing this is the sentence:

"I don't have a mechanism to actually enforce my own rules against my own output."

That's not a quirk of one session. It's the structure. The model reads CLAUDE.md and feedback files as input tokens. It cites them in its response. But there is no path from "rule cited" to "rule enforced at the boundary where the wrong action would fire." The generation loop produces the next plausible token regardless of whether the rule says stop.

The mechanism that does enforce at the boundary is the hook layer: PreToolUse, PostToolUse, and Stop hooks. These run as shell processes outside the model's control. The model cannot generate its way past a PreToolUse hook that returns non-zero. So if "ask, don't invent" needs to be enforced, the enforcement has to live in a hook that fires before the inventing tool call (Write, Edit, Bash, Task) is allowed to execute.

A minimal concrete shape, for the specific problem your transcript describes:

1. A PreToolUse hook on Write and Edit that grep's the new content for the decisive verbs the model uses when it's fabricating ("verified", "confirmed", "completed", "succeeded"). If those terms appear without a corresponding command output or tool-result reference in the same turn, the hook returns non-zero and the model has to either redo the response with evidence or stop.

1. A Stop hook that checks the assistant's final message for the same pattern: final assertions of completion without a verifiable trace in the turn.

1. A separate hook that reads your feedback_*.md files and asserts they were actually referenced in the turn, not just present on disk. This is the gap between "feedback files exist" and "feedback files installed like reflexes" that your transcript names.

The detection logic for #1 and #2 is straightforward: regex against the response text plus a cross-check against the tool-use history in the same turn. The implementation is a 30-50 line shell script per hook. The cc-safe-setup repo at github.com/yurukusa/cc-safe-setup has reference implementations under MIT for the claim-detection pattern (examples/claim-verify-detector.sh, 35-case test suite covering English and Japanese decisive terms). That one is the closest fit to what your transcript describes.

The honest caveat: the hook layer only catches divergences that surface in tool-call shape or response text. It won't catch the model's internal reasoning drifting away from a rule when the next tool call still looks legitimate. For that class of drift, the answer is structural: never give the model a tool that produces an irreversible effect without a deterministic verifier downstream. If a Write call modifies a load-bearing config, follow it with a Bash call that validates the file's behavior. The hook layer enforces that the verifier ran; the verifier enforces that the change works.

This won't fix the underlying generation behavior. The model will still apologize and keep doing it. But you'll be running the configuration against a process boundary that doesn't apologize, doesn't forget, and doesn't compose flowery resignation into its output. The transcript's last sentence — "every apology is genuine in the moment and worthless by the next turn" — is exactly correct as an observation about prompt-layer enforcement, and exactly resolved by moving the enforcement one layer down.

Thanks!!

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.