fix(memory): anchor staleness to last_verified, not file mtime#150
Open
huytg2610 wants to merge 1 commit into
Open
fix(memory): anchor staleness to last_verified, not file mtime#150huytg2610 wants to merge 1 commit into
huytg2610 wants to merge 1 commit into
Conversation
Retrieval rewrote the memory file (last_used_at), bumping mtime; both the recency score and the stale-memory warning were derived from mtime, so a single read reset a stale memory's recency to ~1.0 and suppressed its verify-against-code warning. Anchor staleness to a last_verified date (fallback created, then mtime for legacy files), refresh it only via the new MemoryVerify tool / mark_verified(), and preserve mtime in touch_last_used. Adds a regression test. Realizes the paper's 'make trust a runtime decision' for memory (§4.2).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
MemorySearchrewrites the memory file to updatelast_used_at, which bumpsthe file's mtime. Both the recency score in
_memory_searchand thestale-memory warning in
memory_freshness_textwere derived from that mtime,so a single read of a stale, never-re-verified memory reset its recency to
~1.0 and suppressed its "verify against current code" warning — the
"stale-but-confident" failure the design (paper §4.2) warns against. The
most-retrieved memories, the ones most likely to be acted on, became immune
to the staleness penalty.
Repro (before this PR)
A memory 60 days old, never re-verified:
Fix
last_verifiedfrontmatter field; defaults tocreatedat save time.verified_epoch(last_verified →created → mtime fallback for legacy files), never from raw mtime.
touch_last_usedpreserves mtime and never toucheslast_verified— a readcan't look like a write.
MemoryVerifytool /mark_verified()is the only thing thatrefreshes the clock, called after the agent re-checks the claim against the
environment. This is integral to the fix, not a separate feature: removing
the broken implicit refresh (read = fresh) requires providing the correct
explicit one, otherwise a still-valid old memory would be stuck stale.
After the fix, the same scenario keeps the warning after a read, and only
MemoryVerifyclears it.Tests
tests/test_memory_staleness.py(7 tests) encodes the bug as a regression(fails on the old design, passes here): retrieval doesn't reset staleness,
mtime is preserved, explicit verification refreshes, verification-anchored
ranking, and legacy-file fallback. Existing
test_memory.pystays green.