Repository navigation
GH-50: Warn when an edited file is named in unread memories - #54
Merged
Merged
Conversation
bguidolim
force-pushed
the
bruno/GH-50-edit-linked-memories
branch
from
October 29, 2026 00:23
6905cc0 to
b89462c
Compare
- kb-gate scans memories for the edited file's project-relative path and names unread ones as context; it never blocks the edit - get/multi_get are recorded synchronously so a memory read just before an edit counts - Tests, contract fixture and docs cover the new warning
- A memory counts only when it names the full path, so a root file no longer matches nested paths ending in its name - The note gives the count and asks for a KB search on the path instead of listing titles
… KB search - A memory naming the file's path, or its name when that has two or more words, triggers a note asking for a lex+vec KB search - Only a search for the path or name since session start or the last compaction silences it; reading a memory does not - At most three notes per turn; a SessionStart "compact" registration marks where earlier searches stop counting
bguidolim
force-pushed
the
bruno/GH-50-edit-linked-memories
branch
from
October 30, 2026 00:06
bae9229 to
501b38b
Compare
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
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.
Why
A session can edit a file against a rule the KB already holds, because a search for the task doesn't surface rules about each file it touches along the way. Now, when a memory names the edited file — by its path, or by its file name when that has two or more words (
HermesManager,user_service) — Claude is asked to search the KB for it, with a line saying what the edit changes and why, and to check the edit against the results. The note never blocks the edit;observeonly logs it.A KB search that includes the path or name silences the note for the rest of the session, until the conversation is compacted; reading a memory doesn't count, because one broad memory can name many files. At most three notes per turn.
Replayed on 300 recent commits of a large app repo, about 17% of changed files would trigger a note, usually from one memory. Running the requested search for 14 sampled triggers surfaced a memory about the file in the top 6 every time.
Closes #50.
Test plan
mcs sync, then edit a file whose type name appears in a memory → expect a note asking for a KB search on that nameindex.ts→ expect no note unless a memory names its full path