Silvic 0.1.64 can keep showing an old ADOPTION FAILED / Stopped state after the same Plot has recovered through the packaged CLI.
Reproduction
- Keep the Silvic desktop app open.
- Let adoption fail once for a discovered worktree. In this case the checkout initially had a detached HEAD.
- Attach the checkout to its branch and rerun adoption/provisioning through the packaged CLI.
- Start the development preview through the CLI.
- Compare
silvic status --plot <id> --json with the desktop Plot list.
Observed
The CLI reported:
adoption.status: adopted on attempt 3provisioning.status: complete- Web, Convex, and Agent runtimes running
- the canonical web preview available
The desktop list still showed ADOPTION FAILED / Stopped for fix/sidebar-room-disclosure. Selecting that Plot caused the row to update immediately to ACTIVE, and the detail pane then correctly showed Adoption Adopted and Recipe Complete with the running runtimes.
The stale failure remained visible long enough to make the healthy preview look broken. No desktop restart was involved.
Expected
Desktop state should update when adoption, provisioning, or runtime state changes through the CLI/MCP. A successful later attempt should clear the previous failure without requiring the user to select the Plot or manually refresh the project.
At minimum, the renderer could invalidate its Plot data on Gate state-change events and when the app regains focus. A regression test should cover failed adoption followed by successful external recovery while the desktop list remains mounted.
Silvic 0.1.64 can keep showing an old
ADOPTION FAILED / Stoppedstate after the same Plot has recovered through the packaged CLI.Reproduction
silvic status --plot <id> --jsonwith the desktop Plot list.Observed
The CLI reported:
adoption.status: adoptedon attempt 3provisioning.status: completeThe desktop list still showed
ADOPTION FAILED / Stoppedforfix/sidebar-room-disclosure. Selecting that Plot caused the row to update immediately toACTIVE, and the detail pane then correctly showedAdoption AdoptedandRecipe Completewith the running runtimes.The stale failure remained visible long enough to make the healthy preview look broken. No desktop restart was involved.
Expected
Desktop state should update when adoption, provisioning, or runtime state changes through the CLI/MCP. A successful later attempt should clear the previous failure without requiring the user to select the Plot or manually refresh the project.
At minimum, the renderer could invalidate its Plot data on Gate state-change events and when the app regains focus. A regression test should cover failed adoption followed by successful external recovery while the desktop list remains mounted.