Deleted workspaces may reappear after reload

[ProfSynapse]

Deleting a workspace appears to succeed, but the workspace can come back on reload.

Backend delete logic looked correct when this was last examined; a UI-side cache was the suspicion, never confirmed. Given the storage model (JSONL event store as source of truth, SQLite as rebuildable cache), the other candidate is a delete event that lands in the cache but not durably in the event store, so a rebuild resurrects the row.

Needs re-confirmation before spending time on it — this is long-standing and may already have been fixed incidentally by later storage work.

Filed from a CLAUDE.md cleanup — it was tracked only in that file's status section, which no longer holds status.

[ProfSynapse]

Reproduced live, and the mechanism is not the UI cache this issue hypothesises. Recording it before the detail is lost — not fixed, as this fell outside the current scope.

deleteWorkspace routes through withDualBackend, which checks isReady() and silently falls back to the legacy <id>.json path when storage is not ready. Reads, however, go through withReadableBackend, which waits.

So during startup hydration — isReady() false for tens of seconds, and unbounded if hydration stalls — a delete:

• writes no workspace_deleted event
• removes no SQLite row
• returns no error
• still fires notifyWorkspaceChange({action: 'deleted'}), so the UI drops the row

The workspace is back on the next read. Captured in a live vault: the shard contained only workspace_created, and the workspace reappeared after plugin:reload.

Note this is a narrower window than before — the hydration-gate fix on main means isReady() now becomes true on fresh vaults instead of never — but the asymmetry itself remains: a write path that silently degrades while the matching read path waits.

---

Generated by Claude Code