Desktop: a failed knowledge-selection read is not an empty answer (/ palette, workflow capture)

[Broccolito]

⚠ Stacked on the proof for knowledge-selection reads (#235). Merge that first. This PR targets main rather than #235's branch because the repo auto-deletes a merged head branch, which would close a PR based on it. Until #235 merges, its three commits show here too. This PR's own change is the last three commits: compare against #235's branch.

What was wrong

Two consumers of GET /knowledge/active read it with throwOnError: false. When the read failed, data was undefined, and both read that as the daemon saying "no base is hidden, none is primary":

• The / palette (MentionPopover.tsx) computed hidden_kbs ?? [] and primary_kb ?? active_kb ?? null. It offered every base as "Knowledge base in this chat", including the ones the chat had hidden, and named no primary.
• The create-workflow modal (CreateWorkflowFromSessionModal.tsx) computed visible as every base and the default as visible[0]. handleCreateWorkflow prefers that state over the generated workflow's own knowledge_bases block whenever it is non-empty, so the workflow saved every base.

Now that the read carries the user's proof (#235), a failure here is a genuine error: a surface that cannot prove the person, a dropped connection, an older daemon. None of those is a statement about the chat. KnowledgeContext.tsx already states the rule for listBases, and it holds here: a failed request is not an empty answer.

The modal's claim is the costly one. apply_knowledge_selection makes a workflow's visible list the set of every chat the workflow starts. So every base, hidden ones included, would have been switched on in each of those chats.

Decisions

The / palette offers every base but makes no claim about the chat

	Read answered	Read failed, before	Read failed, after
Bases offered	the chat's	all	all
Row label	"Primary knowledge base" or "Knowledge base in this chat"	"Knowledge base in this chat" on every row	"Knowledge base"
Primary named	yes	no	no
Read that rejects	n/a	the whole palette empties (commands, skills, extensions too)	same as a failed read

The bases stay on offer because a reference names its base by id, and an explicit id reaches a base whatever the chat's selection. kb_id_or_primary in the knowledge server says so: "An explicit kb_id always wins and is never filtered against the session's set." Offering a base doesn't grant access to it: the privacy tier is enforced at the knowledge server's read choke point either way. Omitting the rows was the other option. It would make a transient failure look like "this chat has no knowledge bases", which is also a claim.

The create-workflow modal captures nothing, falls back to the daemon's block, and says so

• A failed read captures nothing. The picker still lists every base from listBases, so the user can choose.
• The daemon's block takes over. On a successful generation, the daemon builds knowledge_bases itself (knowledge_bases_for_session) whenever any base exists, and the save path already falls back to it. A block that is already in place is no longer overwritten.
• With no block, the generation failed and the user is filling the form in, or the daemon predates the block. The workflow is then saved with no knowledge_bases key, and apply_knowledge_selection leaves the new chat's selection alone.
• The picker says why nothing is selected, so an empty picker doesn't read as "this chat uses no knowledge bases": "Could not load this chat's knowledge bases, so none were selected automatically." It is a Note with role="status", since the settings visual vocabulary (which covers components/workflows/) makes every in-place notice one. It clears when the generation brings the daemon's block, because the selection is known then.

Found along the way

• A rejected read emptied the palette. The selection read shares a Promise.all with commands, skills and extensions, and a rejection took all of them down. The new reader never rejects.
• The modal's overwrite only happens inside a ~500 ms window. It lost in two orders: with no generated block, and when the failed read landed after the generation's block but before the form showed. After that window hasAnalyzed flips, the effect is torn down, and a late answer is dropped. See "Not in this PR".

Changes

• components/knowledge/knowledgeSelection.ts (new):
  • readKnowledgeSelection(sessionId) is the one reader for a surface that shows or saves a chat's selection. It sends userActionHeaders(), resolves to null on any failure, never rejects, and logs one line through briefSelectionFailure.
  • readPrimary and readHidden move here from KnowledgeContext unchanged.
• components/MentionPopover.tsx: rows come from the reader, and knowledgeBaseRole decides what a row may claim.
• components/workflows/CreateWorkflowFromSessionModal.tsx: a failed read captures nothing and sets knowledgeSelectionUnread unless the daemon's block is already there. The block clears it.
• components/workflows/shared/WorkflowResourcePicker.tsx and WorkflowFormFields.tsx: an optional notice / knowledgeBaseNotice, rendered as <Note role="status">.

There are three commits: a refactor with no behavior change, then the palette, then the modal. Each typechecks, lints, and passes the three affected test files on its own.

Tests

All six of the new tests that cover the bug fail with the production change reverted:

Test	Before	After
Palette, read refused (the shared gate model with a bridge that has no proof)	rows say "Knowledge base in this chat"	"Knowledge base · ", no primary
Palette, read fails in transit	same	same as above
Palette, read rejects	empty palette	same as above
Modal, no generated block	saved { default: 'soul', visible: [all three] }	no knowledge_bases key
Modal, the notice	absent	present, role="status"
Modal, failed read lands after the generation's block	"3 KBs selected", every base saved	the daemon's block is kept
Modal, read fails first and the block arrives later (guard)	passes	passes; fails if the notice isn't cleared (mutation-checked)

Verification

• npm run test:run: 443 of 443 files, 4981 passed, 1 skipped.
• npm run lint:check: passes (typecheck, ESLint, themes, 332 contrast assertions, tokens).
• npx prettier --check on the eight changed files: passes.
• Verified by unit tests only. I didn't produce a failed read in the running app.

Not in this PR

• The modal drops any answer that lands after the analysis window, including a successful selection read and the base list. If listBases is slower than the generation plus 500 ms, the picker has no items. This bug predates the change. It's rare, because the generation waits on a model.
• A failed listBases in the modal still gives an empty derivation. Nothing wrong is saved, because the save falls back to the daemon's block, but the picker would say "No knowledge bases found".
• The modal invents a primary. When the chat has none, it writes visible[0] as the workflow's default, on both the read path and the generation path, and apply_knowledge_selection then pins that base as each new chat's primary. The daemon's own rule says the opposite, in the doc on plan_workflow_knowledge_selection (routes/agent.rs): the primary comes only from default, and the merged model forbids inventing the pointer, because it is the target of KB-less writes. This predates the change and isn't on the failure path.

🤖 Generated with Claude Code