@ybbmm/dsh-session-delete

LIMITATIONS

Known limitations

- **No toast.** The workspace toast slot's key domain is closed to third-party plugins; the dialog's in-place acknowledgement is the confirmation instead. - **UI copy is English and Chinese only.** - Deleting a conversation does not delete files the conversation *produced* in your workspace — only the conversation itself. - A conversation created but never written to disk has no artifact; deleting it releases the row and reports `removed: false`, but the empty slot can linger in the Host's in-memory pending list until the next restart. - The search index (`dsh-session-query-sqlite`) reconciles against the persistence listing on every query, so it drops the deleted conversation on the next search rather than eagerly. - The trash is a plain directory next to the session store. It is not shared between machines and does not sync. - **Restore is only as exact as the host API allows.** The workspace registry has `attachSession` (which prepends) and `insertSessionBefore`, not an "insert after"; the recorded slot is restored when the session that followed the deleted one still exists, otherwise the conversation is accounted at the front. Pinning always prepends, so a restored pin is in the pinned set but may not hold its old position among the pinned sessions. The workspace projection itself is followed by the browser's own workspace stream, so no extra client RPC is needed for it. - A restore that could not reattach the workspace accounting leaves the files and the row metadata in place and reports `needsRestart: true`; the next launch re-adopts the session through the host's history bootstrap.