Say which memories the model can actually see

Retrieval has been path-scoped since SP3: a memory on a branch this story
never travelled is never sent to the AI. The drawer listed every memory
alike, so on a fork you read "Fell down the cellar stairs; badly hurt" and
reasonably concluded the model knew it. It does not. That is worse than
either hiding the row or retrieving it — it is the screen claiming
something the engine contradicts.

Hiding them is not the answer either; that was the original comment's
point, and it stands. A memory nobody can list is a memory nobody can
delete, in a phase whose rule is that nothing is removed automatically.

So the whole bank still lists, and the rows off the current path are set
back, dashed, and labelled "another branch". MemoryOut.on_path carries it,
computed from the predicate retrieval itself uses rather than a second
spelling of the same idea — two spellings drift, and the failure mode here
is a badge that says the opposite of what the model gets. Pinning does not
override it: the path clause runs before pinning is considered.

The relationship is asymmetric and there is now a test that says so. A fork
borrows its ancestors, so a memory written on the parent is on the fork's
path too; the reverse never is. Worth pinning before somebody makes it
symmetric on the grounds that it looks wrong.

399 tests, three new, egress ceilings intact — the flag costs one id-only
query. Verified in a browser on tools/branch_fixture.py.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015H5qiyiR7gtFQaoDphHZ3g
This commit is contained in:
parththakkar106
2026-08-18 19:14:07 +05:30
committed by Parth
co-authored by Claude Opus 5
parent 811368d048
commit 1d1367ce3a
7 changed files with 171 additions and 9 deletions
+10
View File
@@ -166,6 +166,16 @@ That is now four bugs on this frontend found by exercising it rather than by tes
two of them in paths that had just shipped. The pattern is not subtle any more: **this
frontend has no test runner, so anything not driven by hand is unverified.**
**The memory drawer now says what the model can see.** Retrieval has been path-scoped
since SP3, but the drawer listed every memory alike — so on a fork you read "Fell down
the cellar stairs" and reasonably concluded the AI knew it, when that memory is never
retrieved on that branch. Rows off the current path are set back and labelled *another
branch*, still fully editable and deletable. The flag comes from the predicate retrieval
itself uses, so the badge cannot drift from the behaviour. Note the asymmetry before
changing it: a fork borrows its ancestors, so a parent's memory *is* on the fork's path;
the reverse never is. And a hand-written memory has no depth, so it survives the fork cap
by design — see SP7's entry in `plan/14` for the one case where that surprises.
**The scroll path is finally driven.** 602-action fixture, three prepends of ~16,200 px
each: the same DOM node held viewport top 792 → 787, and the view stayed 48,174 px from
the bottom. PR #2's fix holds. Measuring note worth keeping — the fixture's prose repeats,