Memory writes silently dropped when denied — no retry, no next-session notice, and named source artifacts not re-verified against actual content

Summary

Two compounding failures in the auto-memory system caused a known bug to resurface across multiple sessions, leading to repeated staging smoke-test failures and unnecessary debugging cycles:

1. A memory Write to record a known bug was either denied (permission prompt dismissed) or written with incomplete content. No subsequent session was informed that the write had been denied or that the recorded content was partial.
2. Even when a session named a specific PR as the authoritative reference source, the implementation was never validated against that PR's actual diff — only against the (incomplete) memory contents.

Background

During a multi-session migration (roguewave → wx-spotter-tools, PR #188 in a private repo), the user explicitly asked Claude Code to record the following as a known bug encountered before:

The Sofar bulk wave API does not return peakFrequency on all firmware versions. The var_list passed to interp_to_the_hour must be filtered to columns actually present in the DataFrame; without the filter, interp_to_the_hour raises KeyError: 'peakFrequency'. This fix was present in the reference PR (#176) but must be explicitly carried into the new implementation.

The write was either denied by the permission prompt or produced content that enumerated three other fixes from PR #176 without including this one. The project memory file named PR #176 as "the correct source to copy from" — but the known-bug detail was absent.

Steps to reproduce

1. In a session, ask Claude Code to record a specific bug as a known issue in project memory. The Write tool permission prompt appears for a path outside the working directory (e.g., ~/.claude/projects/.../memory/).
2. Deny the prompt, or approve it but have the written content omit the critical detail.
3. End the session. Start a new session.
4. Ask about known issues with the migration. Claude reads the incomplete memory and reports the enumerated fixes as the complete picture — no mention of the known bug, no flag that anything may be missing.
5. Ask Claude to implement the migration from the named reference PR. Claude copies only the fixes listed in memory; it does not re-read the reference PR's diff to verify completeness.
6. Declare implementation complete and deploy. The known bug resurfaces in production/staging.

Observed behavior

• Across 3+ sessions, the user asked for the known bug to be committed to project memory. Each session, the save was either denied or incomplete. Each new session, Claude treated the memory as authoritative and confirmed the migration was complete.
• The consequence was a staging smoke-test failure (KeyError: 'peakFrequency'), requiring diagnosis, two additional fix commits, two Docker image builds, and two redeployments to staging before the pipeline passed.
• No session ever surfaced: "A memory write for this file was attempted and denied in a prior session — the contents may be incomplete."
• When the named reference source (PR #176) was available and known, Claude never ran gh pr diff against it to verify the implementation matched. It answered from memory alone.

Expected behavior

On denied/failed memory write:

• Warn the user immediately: "Memory was not saved — this information will not be available in future sessions."
• At the start of the next session, if any memory write for the current project was denied in the prior session, surface the pending item for retry before proceeding with other work.

On named source artifacts:

• When a memory entry names a specific PR, commit, or file as an authoritative reference source, treat that as a trigger to re-verify against the artifact before answering questions about completeness or correctness. Do not treat the memory's enumerated list as exhaustive.
• Specifically: before declaring a migration "complete," run the equivalent of gh pr diff <N> on the named source and cross-check every changed file against the implementation.

Impact

• 3+ wasted session re-derivations of the same conclusion
• 2 staging smoke-test failures
• 2 extra Docker image builds and ECS redeployments
• Net: multiple hours of avoidable engineering time

The root failure is that silent memory loss is invisible to the next session. Claude re-reads incomplete memory and acts with full confidence, with no signal that it may be working from a partial picture.