[Bug]: Project add can silently succeed, then the second add fails with duplicate workspace root

[justelson]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

1. Install the desktop app fresh on Windows.
2. Open DP Code.
3. Add a local project/folder.
4. The UI shows the add flow, but no project/thread appears.
5. Try adding the same folder again.
6. The second attempt fails with a duplicate workspace-root error.

Expected behavior

The first add should surface the project and let me start/use threads immediately. If the project already exists, the app should recover or focus that existing project instead of throwing an invariant error.

Actual behavior

The first project.create appears to succeed, but the client never surfaces the project/thread. The second add then fails with:

Orchestration command invariant failed (project.create): Project '<id>' already uses workspace root '<path>'

Impact

Blocks work completely

Version or commit

Desktop app build on Apr 21, 2026

Environment

Windows desktop app, first install / fresh local state

Logs or stack traces

`Error: Orchestration command invariant failed (project.create): Project 'de518ba1-43c2-46ae-80af-2cbb219ad231' already uses workspace root 'C:\Users\elson\my_coding_play\play projects\pi'.`

Screenshots, recordings, or supporting files

image.png

Workaround

No reliable user-facing workaround found. Restarting/reloading may resync state sometimes, but the add flow itself is broken.

[justelson]

Fixed in #44.

Root cause: project.create could succeed, but the client only polled getSnapshot() and could accept broken local/read-model state where the created project row was still missing. That left the UI empty after the first add, and retrying the same folder then hit the duplicate workspace-root invariant.

Fix: add-project and duplicate-create flows now share the same recovery helper, which first retries the read model and then falls back to repairState() if the project still cannot be surfaced. If the project is recovered, the client syncs the repaired snapshot and reopens the existing project instead of failing on the second add.

PR: #44