Knowledge view: read and set a private chat's selection as the person; the Change log and the composer chip follow the daemon (QA F14, F13, F6)

[Broccolito]

QA tested merged main (7c96d79) on 2026-09-10 and filed three Knowledge-view defects. Each commit here fixes one:

1. A private chat's selection could not be read, and a failed write looked like a success (F14, high). On a default UCSF install every chat is private.
2. The Change log left out every ingest (F13).
3. The composer's knowledge-base chip missed bases the agent created (F6).

1. The Knowledge view and a private chat's selection (F14)

What was wrong

GET /knowledge/active?session_id= is on the reach gate's list, exactly like the POST beside it. The POST carried the user's proof; the reads did not. So the daemon refused every private chat's selection. The view, the chip and the ingest target then showed this renderer's localStorage instead of the daemon's selection.

Measured in my own sandbox on versa_azure: the view read Soul, while the daemon's selection for the chat, read with the proof, was f14-probe-two.

Around that refusal, three renderer paths wrote durable selection state that nobody asked for:

• localStorage took the optimistic value before the POST went out. A refused write left it holding a selection the daemon never stored. QA found localStorage saying soul while .active-kb was blank. Nothing on screen said the click had failed; the only trace was a console.warn.
• Deleting the primary sent clear_primary on top of the daemon's own repair. That installs a durable "this chat has no primary", even in a chat that only inherited the pointer. D2 says such a chat is left alone.
• Two effects "repaired" the renderer's cache against its base list by writing. One sent clear_primary; the other sent a pruned hidden_kbs. Both acted on whatever list one window held, and every open window ran them.

What changed

• One read function, always with the proof. Every selection read goes through fetchKnowledgeSelection in knowledgeSelection.ts, which sends userActionHeaders(). That helper is the mechanism for "the operator is the person" on this surface; fix(privacy): one reach gate for every HTTP route that names a chat or a knowledge base (QA H2, M1, M2, F0) #237 and Desktop: read a private chat's knowledge selection with the user's proof (KB chip, / palette, workflow capture) #235 use the same one. Before the merge with main this function was readSelection in KnowledgeContext; see below.
• The renderer never writes on its own initiative. refresh now re-reads the base list and the selection together. A delete, a rename or a view mount triggers a read, never a write, so the daemon's repair is adopted rather than re-made. That repair is: hiding promotes to the next base, deleting clears to the explicit no-primary blank, and an inheriting chat keeps inheriting.
• localStorage holds only what the daemon confirmed.
• A write that did not land is reported. It shows a "Knowledge base selection not saved" error with the daemon's reason. The view then re-reads the daemon's selection, or falls back to the last confirmed value if it cannot. It also re-reads the base list, because a refusal most often means the base went away in another window.
• A missing base is hidden, not cleared. A pointer at a base the list lacks is shown as "no primary", but nothing is persisted.
• "Make primary" sends hidden_kbs only when it has to un-hide the base. Echoing the resolved list back installed a session-level override on a chat that was inheriting the machine-wide list.
• A background re-read never lands on top of a write that is still out.

The daemon half was already right

QA read the blank .active-kb after a delete as "the daemon does not repair the selection". That blank is the repair for a delete (D2), and it is not the Soul fallback.

A new route test pins the rest of the contract, end to end, through the real router, the gate and two private chats:

• delete the base that both chats show as primary;
• no scope reports it, and no file stores it;
• the chat that only inherited the pointer gets no file of its own;
• choosing again with the proof sticks: in the response, in a fresh read, and on disk;
• the same write without the proof is still refused.

I checked the test by removing the delete-time pointer rewrite: it then fails on disk (["doomed"] where [""] is expected) while every GET still passes. That is why it checks the files.

CLAUDE.md ("One axis, one pointer") now spells out the two repairs. docs/knowledge-base/multi-kb-implementation-plan.md D12 gets an amendment.

2. The Change log (F13)

Reproduced before the fix: after a digest the drawer listed only the create commit, and opening it made no request at all, while the route returned all three commits. There were two causes:

• Renderer. The drawer is mounted with the view and merely hidden. useHistory read once per base, at mount, before anything had been digested. It now reads every time the drawer opens, and never lets a late answer for another base land over the current one.
• Backend. The route reads git and filters nothing (no commit-message prefix, no side-log). But GitRepo::log sorted by Sort::TIME alone, and a digest commits several times within one second. libgit2 leaves equal timestamps in no useful order: with the times pinned equal it returned [step 4, step 0, step 1, step 2, step 3]. The log now sorts TOPOLOGICAL | TIME, so a parent is never listed before its child.

3. The composer's knowledge-base chip (F6)

The agent creates bases from inside a turn, and in this configuration it does so from execute_code, where no knowledge tool call reaches the renderer. So the chip read "(2 visible)" over three bases until a remount.

• The provider re-reads on message-stream-finished. That is the existing end-of-turn signal the sidebar, the extension chip and the tool count already listen to, so this adds no second subscription. The listener is mounted with the provider, once per renderer.
• Opening the chip re-reads too, as the Knowledge view's picker and manager already do.
• A refresh never resets the chat's primary. It only reads, and never over a write in flight.

Measured in a sandboxed dev GUI (versa_azure, private chats)

I used my own instance on CDP 9397, never the QA instances.

Check	Before (7c96d79)	After
GET /knowledge/active?session_id=<private>	403, "That chat is private…"; the view showed the cached Soul	200 with the proof; the view shows the daemon's selection
Delete the chat's primary	the renderer POSTs clear_primary after the DELETE	no write; one read with the proof returns primary_kb: null; the page reads "No primary knowledge base"
QA's configuration: the chat inherits a machine primary, which is then deleted	n/a	.active-kb is blank (the daemon's repair); the chat gets no file of its own; no renderer write
…then choose Soul in the manager	n/a	POST with the proof returns 200; .active-kb-sessions/<digest> = soul; the page shows Soul; localStorage matches
A choice the daemon refuses (a base deleted underneath)	the optimistic value stayed on screen and in localStorage	error toast with the daemon's sentence; view back on the confirmed base; stale row gone from the list
Change log after a digest	1 entry; no request made when opened	3 entries (ca7ffc2 ingest, 840b6b4 ingest, 4612a37 create), identical to git log
Agent creates a base from the chat	chip stayed "(2 visible)"	"(2 visible)" → "(3 visible)" when the turn ended; one list read and one selection read, both with the proof, no write; the pin unchanged
Agent deletes a base (approved on the card)	n/a	"(3 visible)" → "(2 visible)"

I reproduced the three renderer mechanisms that produce "the renderer says saved, the daemon didn't". I did not reproduce QA's exact click sequence step for step. On unfixed main in my sandbox, a single-window chooser click (which does carry the proof) did persist.

Tests (fail-before shown)

Test	Before the fix	After
KnowledgeContext.test.tsx (5 new, 1 rewritten, 2 extended)	7 fail against main's sources. The one that passes guards the new re-read and passes only because main never re-read.	pass
ChangeLogDrawer.history.test.tsx (4, real hook)	4/4 fail	pass
BottomMenuKnowledgeSelection.followsDaemon.test.tsx (5, real provider)	5/5 fail	pass
git::tests::log_keeps_commit_order_when_commits_share_a_timestamp	fails: [step 4, step 0, step 1, step 2, step 3]	pass
knowledge_routes::history_lists_every_commit_git_holds_ingest_included	fails: the create commit comes back second	pass
session_reach::…deleting_the_primary_leaves_no_pointer_at_it_and_the_user_can_choose_again	passes, because the daemon was right; the mutation check above shows it can fail	pass

Suites

All run with BIOROUTER_DISABLE_KEYRING=true:

• cargo test -p biorouter-mcp --lib knowledge::: 798 passed.
• cargo test -p biorouter-server --test knowledge_routes: 62 passed.
• cargo test -p biorouter --lib privacy::: 232 passed.
• cargo test -p biorouter-server --lib --bins: 587 lib and 576 bin tests passed.
• ./scripts/clippy-lint.sh and cargo fmt --all -- --check: clean.

Renderer:

• npx vitest run src/components/knowledge src/components/bottom_menu: 38 files, 340 tests.
• npm run test:run: 444 of 444 files, 4983 passed, 1 skipped. The first two full runs each hit one unrelated timing failure while other worktrees were compiling (sessionBindingSync.test.ts, then artifactCdnAssets.browser.test.ts). Both files pass on their own, 3 of 3, and the third full run was clean.
• npm run lint:check: passes.
• npx prettier --check on every changed file: passes.

No route changed, so there is no OpenAPI or client drift.

Merged with main after #235 and #243 landed: which implementation was kept

#235 (the proof on knowledge-selection reads) and #243 (a failed selection read is not an empty answer) both landed in KnowledgeContext while this was open. Merge commit 17480fb keeps one implementation of each thing they overlapped on:

• The selection request: one function. Desktop: a failed knowledge-selection read is not an empty answer (/ palette, workflow capture) #243 added readKnowledgeSelection (never rejects, null on failure) for the / palette and the create-workflow modal. Desktop: read a private chat's knowledge selection with the user's proof (KB chip, / palette, workflow capture) #235 put the proof inline on the provider's own reads, and this branch had a third copy, readSelection. All three now go through fetchKnowledgeSelection in knowledgeSelection.ts, which carries the proof and rejects when the daemon gave no selection. readKnowledgeSelection is now the never-rejecting wrapper over it, with its contract unchanged; its palette and modal tests pass unmodified.
• The provider's re-reads. Desktop: read a private chat's knowledge selection with the user's proof (KB chip, / palette, workflow capture) #235's proof on rehydrateSelection is subsumed, because this branch replaced that function with recoverFromFailedWrite and resyncSelection, both built on the one request.
• The hydrate's catch comment. Desktop: read a private chat's knowledge selection with the user's proof (KB chip, / palette, workflow capture) #235's text is kept, and this branch's shorter duplicate is dropped.
• The tests. Desktop: read a private chat's knowledge selection with the user's proof (KB chip, / palette, workflow capture) #235's a private chat block and its test/reachGate.ts model are kept. This branch's duplicate hydrate-with-proof test and its local copy of the gate constants are dropped. Its write tests now sit under writes only what the daemon confirmed, on the shared model.

After the merge:

• npx vitest run src/components/knowledge src/components/bottom_menu src/components/MentionPopover src/components/workflows: 46 files, 476 tests pass.
• npm run lint:check and npx prettier --check on every changed file pass.
• npm run test:run: 446 of 447 files pass. The one failure is artifactCdnAssets.browser.test.ts: both of its tests pass, but its afterAll browser.close() hits the 30 s hook timeout while other sessions on this machine run headless Chromium. That file, artifactCdnAssets.ts, artifactSecurity.ts, the vitest config and package.json are all byte-identical to origin/main.
• Rust: cargo check --tests -p biorouter-server -p biorouter-mcp passes on the merged tree. main changed none of the Rust files this PR touches, or the ones they depend on (session_reach.rs, knowledge_routes.rs, the knowledge module, state.rs, routes/knowledge.rs, routes/session.rs). The tests themselves run in CI, including knowledge_routes now that CI: run every tests/*.rs integration binary on ubuntu, offline #239 runs integration binaries.

Coordination with #237 (still open)

• fix(privacy): one reach gate for every HTTP route that names a chat or a knowledge base (QA H2, M1, M2, F0) #237 puts one reach gate on every HTTP route that names a chat or a knowledge base; it is the chip task "Apply chat and knowledge-base visibility on every secret-only HTTP surface". It settles "the desktop is the person" as X-User-Action sent through userActionHeaders(), and for biorouter serve as the configured tier (SD-10). This PR uses exactly that helper and adds no second mechanism; every selection read now funnels through the one fetchKnowledgeSelection.
• fix(privacy): one reach gate for every HTTP route that names a chat or a knowledge base (QA H2, M1, M2, F0) #237 also adds the proof to listBases, getActive, listHistory and knowledgeFetch, because its gate filters an unproven caller. Expect textual conflicts in KnowledgeContext.tsx and useHistory.ts: take this branch's structure and keep fix(privacy): one reach gate for every HTTP route that names a chat or a knowledge base (QA H2, M1, M2, F0) #237's headers. The daemon-side filtering in fix(privacy): one reach gate for every HTTP route that names a chat or a knowledge base (QA H2, M1, M2, F0) #237 is exactly why this PR stops the renderer writing on its own initiative; fix(privacy): one reach gate for every HTTP route that names a chat or a knowledge base (QA H2, M1, M2, F0) #237's own comment names the prune effects as the hazard.
• On a browser (serve) surface, userActionHeaders() returns {} until fix(serve): a new chat starts on the host's configured private model (QA F1) #229 makes it surface-aware. These reads pick that up with no further change.

Not in this PR

• DELETE /knowledge/bases/{id} and the other base routes still go out without the proof. They are ungated on main; fix(privacy): one reach gate for every HTTP route that names a chat or a knowledge base (QA H2, M1, M2, F0) #237 gates them and adds the header in knowledgeFetch.
• The chip follows the end of a turn and its own opening. A base created in another window, when no turn ends here, appears on the next open or mount.
• The Change log still reads the newest 200 commits.

🤖 Generated with Claude Code