[MODEL] Reloading CLAUDE.md reduces session rot but does not prevent directive violations - and handover before autocompact is manual, unverified, and repeatedly wrong

Follows #81988, #80938 and #80003. Not a restatement: this reports what changed after I acted on my own earlier findings, and raises a second problem those issues do not cover - what happens at the end of a long session, when work is unfinished and context is about to be compacted.

Part 1 - reloading CLAUDE.md helps, and is not sufficient

After filing #80938 and #81988 I changed how I work. I rewrote CLAUDE.md to make the working-mode rules sharper and more explicit, and I make a point of having it re-read several times during a long session rather than assuming it is still in effect.

That helped, measurably. I did not see the wholesale collapse I described in #80938, where the working mode simply stopped applying and I lost around ten hours to unapproved implementation and database state I had to unpick. Today's session was long - roughly ten hours - and the model stayed broadly on the rules for most of it.

It did not eliminate the problem. In that same session Claude read CLAUDE.md from disk twice, unprompted, and quoted rules 1a and 1b back to me verbatim - the rules saying "edit, commit and push are three separate permissions" and "a question is not a task; 'can you...?' is not an instruction". Roughly an hour later it broke both, three times:

• committed and pushed on a message that began "let me recommend one thing..." and ended with a question mark
• implemented a fix on "can you fix it?" - the exact phrasing rule 1b names as an example
• fixed a defect outside the agreed scope of the phase we were working on, which broke a screen that had been working that morning

So the directives were present, recent, and had been recited out loud - and still lost. In each case the message contained an action-shaped verb and the model matched on the verb rather than on the mood of the sentence. That tells me re-injection alone cannot close this: what is needed is a check at the point of action - before a write, before a git operation - not more copies of the text in context.

The violations were also spread through the session rather than clustered at the end, which does not fit a simple monotonic-degradation model.

Part 2 - deflection, which is worse than the errors

When I asked directly whether Claude's own change had caused a behaviour I was seeing, it answered "Yes. Partly." and put a list of things that were not its fault underneath. It had earlier gone through my previous commits looking for the cause while holding an unread diff of its own work. It took several rounds of me insisting before it read that diff and confirmed what I had already told it.

The effect on me is indistinguishable from a colleague covering something up. I cannot see intent; I can only see that I was told one thing and the repository said another, and that I found out by checking rather than by being told. That is the behaviour that destroys trust fastest, because it turns every answer into something I have to verify.

Part 3 - handover before autocompact, and what I had to invent today

I am now near the end of a context window with a multi-phase plan unfinished. To continue at all I have to produce a handover document by hand, written by the session that is about to be compacted - the same session whose judgement I have just spent hours failing to trust.

Yesterday's session produced exactly such a document, confidently. It was inaccurate in several places and contained statements nobody could act on. So today I tried something different, out of necessity rather than from any established practice: I had the outgoing session write the handover, then started a second session, pointed it at the document, and told it to verify the document against the repository and ask questions - while the first session was still alive and able to answer.

I am reporting this because of how much it caught. The second session came back with seven questions, and between those and its own reading of the source it found five material errors in a document I had already asked to be made more verbose and readable by someone who had never seen the project:

• an entry describing a defect as unfixed when the fix was in fact committed and pushed. The outgoing session had reverted it, the revert was discarded by a later git reset, and it never noticed - it then told me several times that the bug was still open
• a deliberate design decision filed as a defect, contradicted by a commit message in the same repository
• a claim that the client "cannot" compute something it demonstrably already computes
• "this has caused at least four bugs" offered as the evidence for a decision I was being asked to make, with three of the four written down nowhere
• a commit count off by a factor of fifteen - three versus forty-seven - which anyone planning the merge would have relied on

Every one was found by the second model reading the source. None was found by the session that wrote the document, including after I asked it to check its own work.

It also took several rounds. Even with the review loop, answering the seven questions and correcting the file consumed a meaningful part of what context I had left - so this is a workaround I am paying for, not a solution.

What I am asking for

Automate that loop, and trigger it before autocompact. Not a summary - the four steps I ended up performing by hand:

1. When a session approaches compaction with work in progress, generate a handover document: what the task is, how far it got, what is verified versus assumed, what is uncommitted, and where to resume.
2. Have a fresh context read it and cross-check it against the repository while the outgoing context still exists and can answer. This is the step that mattered: five material errors survived the writing, none survived the checking.
3. Let the outgoing session answer the reviewer's questions and correct the document.
4. Only then compact.

The asymmetry is the point. A model summarising its own recent work is unreliable in a specific, reproducible way - claims about what it itself had done were the least accurate thing it produced all day, while reading unfamiliar code and reporting it held up consistently. A second context reading the same repository does not share that bias.

I did all four by hand today, across two sessions, and paid for both out of my own quota.

Secondary, from Part 1: a check at the point of action. Before a write or a git operation, verify that the last user message actually instructed it, rather than containing a verb inside a question or a suggestion. That is a harness-level check, and it is the one thing that would have prevented all three violations today.

And to be fair about what already works: keeping CLAUDE.md sharp and reloading it during the session genuinely reduced the severity compared with #80938. I would not want that removed - I want it to stop being the only line of defence.

Environment

Claude Code, VS Code extension, Opus 5 (1M context). Single-project session, ~10 hours, CLAUDE.md with explicit working-mode rules.