Describe the bug
remember automatically replaces a valid memory when a new memory describes the same property of a different subject. Shared vocabulary is enough to classify the second fact as an update, even though neither fact supersedes the other.
In a fresh store, a fact about Project Beta soft-deletes a separate fact about Project Alpha. Both use maximum importance (--imp 5).
To reproduce
With mnemon 0.2.8 on PATH:
export MNEMON_DATA_DIR="$(mktemp -d)"
export MNEMON_STORE=distinct-facts-repro
export MNEMON_EMBED_ENDPOINT=http://127.0.0.1:1
mnemon remember 'Project Alpha uses PostgreSQL database for persistent application storage' --cat fact --imp 5
mnemon remember 'Project Beta uses PostgreSQL database for persistent application storage' --cat fact --imp 5
mnemon recall 'Project Alpha storage'
Actual behavior
The first write returns action: "added". The second returns:
{
"action": "updated",
"content": "Project Beta uses PostgreSQL database for persistent application storage",
"diff_suggestion": "UPDATE",
"importance": 5,
"embedded": false
}
It also returns replaced_id equal to the first write's ID. Recall for Project Alpha storage returns only the Beta fact. The implementation soft-deletes the replaced insight; this report does not claim its bytes are permanently erased from disk.
Expected behavior
Both facts should remain active and independently retrievable. The second remember should add a fact unless the caller explicitly identifies the first fact as superseded or there is sufficient evidence that both describe the same subject and property.
Lexical similarity alone does not distinguish a changed value for the same subject from the same value for a different subject. A regression test should cover both cases.
Environment
- mnemon
0.2.8, official darwin_arm64 release; archive SHA-256 verified against the release checksums.
- macOS 26.6.2, Apple Silicon.
- Fresh synthetic store, direct CLI calls, no LLM host integration or embeddings.
- The relevant source files also match master at
9c8e760e0143f5d66b5d57609a60e1c4e620da96.
Additional context
Likely cause
After English stopword filtering, these sentences share 7 of 9 unique tokens across their union (Jaccard similarity approximately 0.778). They differ only in the subject, Alpha versus Beta.
classifySuggestion returns UPDATE. remember permits automatic replacement whenever the top match has TokenSimilarity >= 0.6, then soft-deletes that match.
This survives the fixes in #25 and #84: no embeddings or conflict keywords are required. The remaining token-overlap condition itself permits replacement of a distinct subject's fact.
Workaround
--no-diff bypasses this replacement path. Separate stores can isolate projects, but facts about multiple subjects can legitimately coexist in one store; store isolation does not solve the general problem.
Related: #131 discusses applicability metadata. This report focuses on the concrete loss of an active fact during remember, independently of how future scope metadata is designed.
Validation scope: direct CLI reproduction only; no code changes or full test-suite run.
Describe the bug
rememberautomatically replaces a valid memory when a new memory describes the same property of a different subject. Shared vocabulary is enough to classify the second fact as an update, even though neither fact supersedes the other.In a fresh store, a fact about Project Beta soft-deletes a separate fact about Project Alpha. Both use maximum importance (
--imp 5).To reproduce
With mnemon 0.2.8 on
PATH:Actual behavior
The first write returns
action: "added". The second returns:{ "action": "updated", "content": "Project Beta uses PostgreSQL database for persistent application storage", "diff_suggestion": "UPDATE", "importance": 5, "embedded": false }It also returns
replaced_idequal to the first write's ID. Recall forProject Alpha storagereturns only the Beta fact. The implementation soft-deletes the replaced insight; this report does not claim its bytes are permanently erased from disk.Expected behavior
Both facts should remain active and independently retrievable. The second
remembershould add a fact unless the caller explicitly identifies the first fact as superseded or there is sufficient evidence that both describe the same subject and property.Lexical similarity alone does not distinguish a changed value for the same subject from the same value for a different subject. A regression test should cover both cases.
Environment
0.2.8, officialdarwin_arm64release; archive SHA-256 verified against the release checksums.9c8e760e0143f5d66b5d57609a60e1c4e620da96.Additional context
Likely cause
After English stopword filtering, these sentences share 7 of 9 unique tokens across their union (Jaccard similarity approximately 0.778). They differ only in the subject, Alpha versus Beta.
classifySuggestionreturnsUPDATE.rememberpermits automatic replacement whenever the top match hasTokenSimilarity >= 0.6, then soft-deletes that match.This survives the fixes in #25 and #84: no embeddings or conflict keywords are required. The remaining token-overlap condition itself permits replacement of a distinct subject's fact.
Workaround
--no-diffbypasses this replacement path. Separate stores can isolate projects, but facts about multiple subjects can legitimately coexist in one store; store isolation does not solve the general problem.Related: #131 discusses applicability metadata. This report focuses on the concrete loss of an active fact during
remember, independently of how future scope metadata is designed.Validation scope: direct CLI reproduction only; no code changes or full test-suite run.