feat(desktop): remove threads through the protocol, not around it

[oratis]

Stacked on #254 → #252.

Closes the 仍未做 item in docs/THREE_WAY_REVIEW.md §7: "桌面侧栏的 archive / delete 仍走 Tauri … 这是'消除第二个读取者'的后半截。"

It was worse than "a second reader"

The app-server is the single owner and writer of thread storage. A renderer deleting session files behind it can pull the ground out from under an open writer, or leave the index pointing at something that is gone. So this is a correctness problem, not only a tidiness one.

And it was three call sites, not two. window.deepcode.sessions.list() has preferred the protocol since #231 — but Sidebar.tsx bypassed the shim entirely and called listSessions() from tauri-api.ts directly, with its own row shape and its own sort. The list was a second reader the whole time.

thread/delete is new

The protocol served thread/list, thread/fork and thread/archive — but not delete, which is why delete had nowhere to go. It mirrors archive:

• 404s on a thread that does not exist rather than silently succeeding;
• a store that cannot delete says so rather than quietly archiving instead. Being helpful about a destructive verb by performing a different one is the worst available answer.

Served under the existing threadManagement capability. The Tauri commands stay as the fallback for a sidecar too old to know the method — the same pattern #231 documented for list.

Delete removes both representations

The protocol snapshot and the canonical session projection share an id and are two views of one thing, and the composite list reads both. Removing one left the row reappearing on the next refresh as an empty session that could not be opened. Tested directly.

SessionManager.delete takes the v1 stream, the legacy stream, the meta sidecar, the writer lock and the per-session directory (snapshots, background-task logs, todos). The listing reads the sidecar, so leaving that behind is not a tidy half-delete — it is a row you cannot get rid of.

Verification

typecheck, lint, format, docs clean; full suite green through the pre-commit hook. 9 new tests:

• protocol runtime: delete drops from the listing, 404s on a missing thread, a store without the method is rejected;
• archive keeps the thread readable, delete does not — both drop out of the listing, so the listing alone cannot tell them apart;
• store: both representations go, and other threads are untouched;
• desktop agent: archive/delete reach the protocol, and report false rather than throwing when the server cannot manage threads, so the fallback is a fallback and not a swallowed error.

The preview fixture answers thread/delete, so the Playwright journey exercises the new path in CI.

🤖 Generated with Claude Code

[oratis]

Review — approve, with one hardening pushed

Finding that the list was also bypassing the shim, and saying so rather than quietly fixing three things under a two-thing title, is the right instinct. The thread/delete design choices are all defensible:

• 404 rather than silently succeeding on a missing thread;
• a store that cannot delete rejects rather than archiving instead — being helpful about a destructive verb by performing a different one is the worst available answer, and the test pins it;
• delete? optional on ThreadStore, so no implementation breaks;
• both representations go, with a test proving the row does not come back. That is the failure that would actually have shipped.

archive keeps the thread readable, delete does not is a good test — the listing alone cannot distinguish them, so reading is the only thing that can.

Pushed: validate the id before the recursive delete

deleteSession ends in rm -rf <root>/<id>, and .. passes the ^[a-zA-Z0-9._-]+$ check that both this path and validThreadId rely on — it is spelled entirely in characters an id may legitimately contain. join(root, '..') is the directory above the sessions root.

Not reachable today: ProtocolRuntime.deleteThread 404s first, and CanonicalThreadStore.delete runs FileThreadStore.delete (which validates) before the session projection. But SessionManager.delete is newly public API on @deepcode/core, this is a recursive delete resolved from an untrusted string, and it is one refactor away from being the only check. AGENTS.md asks for adversarial tests exactly here.

deleteSession now refuses a malformed id before removing anything, and validThreadId stops admitting ./.. — harmless while every path built from an id had a suffix appended, not harmless now that one reaches a directory removal.

Worth noting how it was confirmed: deleting the guard and running the test walked rm -rf up out of the fixture and into $TMPDIR before hitting EPERM. The committed fixture nests its sessions root deep enough that every hostile id still resolves inside the temp directory, so a future contributor who comments out the guard gets a failing test rather than that.

One thing I did not change

In window-shim.ts, delete falls back to the Tauri writer on any thrown error:

try {
  if (await deleteProtocolThread(id)) return;
} catch {
  /* fall through to the local writer */
}
await sessionDelete(id);

The capability check already returns false for a sidecar too old to know the method, and that is the version-skew case the fallback exists for. So the catch only fires when the owner genuinely failed — possibly partway through — and the response is for the renderer to delete files behind it, which is the thing this PR is removing. For archive that is a cheap retry; for delete it is the ground being pulled out from under a writer that was already in trouble.

Left alone because narrowing it is a judgement call about desktop fallback behaviour that I would rather you make than have me make silently. Worth a follow-up.