Prevent lost updates in workspace storage operations

[tonythethompson]

The Raycast workspace store uses a load-modify-save pattern for add/update/delete/pin/reorder/touch operations. If two commands overlap, the last save can overwrite the first and lose data.

Acceptance criteria:

• Concurrent storage mutations do not silently clobber each other.
• Storage writes are serialized or otherwise protected against lost updates.
• If concurrent modification cannot be prevented, the extension detects it and surfaces a clear error or retry path.

[tonythethompson]

Audit against current code (QuickShell.Raycast, lib/storage.ts): PARTIAL progress.

Done: the store keeps an in-memory cache (all reads/writes route through it), markWorkspaceUsed is debounced (RECENT_WRITE_DEBOUNCE_MS = 500) and flushed before each mutation (flushRecentWrites), and save() records undo snapshots (pushUndoSnapshot, MAX_HISTORY_ENTRIES = 25) so accidental overwrites are recoverable.

Gap vs spec: there is no explicit serialization/mutex/queue around the load-modify-save critical section. Each op does flushRecentWrites() -> load() (a clone of the shared cache) -> mutate -> save(). Because two overlapping async commands can both read the cache before either writes, the last save() can still overwrite the first (classic lost-update). The debounce only protects the recent-write path, not general mutations, and there is no conflict detection or retry path if concurrent modification is detected.

Acceptance not yet met: writes are not serialized against each other, and no clear error/retry is surfaced on detected concurrency. Recommend a single in-flight write lock (or a mutation queue) around save() plus optional optimistic-concurrency detection.

[tonythethompson]

Audit correction (re-checked against the .NET main project, the actual QuickShell):

.NET HAS this: QuickShell.Core/Services/ShortcutRepository.cs (Mutex + SemaphoreSlim) and ShortcutDraftStore.cs serialize storage writes against lost updates. Raycast port: in-memory cache + debounced recent writes + undo snapshots, but no explicit write lock / conflict detection around the load-modify-save critical section. Stays open (Raycast gap).

[tonythethompson]

Re-audit (2026-07-22)

Verdict: NOT DONE. Remains open.

Prior analysis still accurate. storage.ts is still load-clone-mutate-save through a shared cache with no write mutex/queue. Debounce only covers markWorkspaceUsed. Concurrent async commands can still lose updates. Core has Mutex + SemaphoreSlim; Raycast does not.