workflow(efforts): map the two state-honesty gaps in dashboard-control-plane #413
No reviewers
Labels
No labels
bug
contract
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
iterative-works/iw-cli!413
Loading…
Reference in a new issue
No description provided.
Delete branch "wip/dashboard-control-plane-map"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Adds two Layer 1 items to the dashboard-control-plane map, found while diagnosing why the dashboard shows months-old data.
always-warm-cache(#336) covers the refresh half. It does not cover either of these, and a refresh loop alone would not fix them — a server that is down still loses every registration, and nothing reconciles afterwards.server-autostart(dx)iw-run:814-817resolves the dashboard jar only when the command isdashboardorserver:Autostart is reached from
ServerClient.ensureServerRunningviaregisterWorktree/updateLastSeen— called byStart,Open,Rm,Issue,Register. For those commandsIW_DASHBOARD_JARis unset, sospawnServerProcessfails on its own guard and returnsLeft; the worktree command carries on without a visible error.So
iw starthas never been able to bring the server up, in any repo. It appears to work in iw-cli only because that is where./iw dashboard/./iw serverget run explicitly — the one path that resolves the jar. While the server is up,isHealthy()short-circuits before the spawn, hiding the bug.worktree-reconcile(wf)Registration is a single fire-and-forget push with no retry and no reconciliation against disk. Every
iw start/iw rmissued while the server is down is lost permanently, with no way back to current.Reconciling registered worktrees against
git worktree listmakes disk the ground truth and gives downtime a recovery path.Evidence
Measured against the live state file (TTLs are 30 min for issues, 15 min for PRs):
The mechanism itself is fine. Requesting one card endpoint refreshed
SNOL-173fromBacklog(fetched 2026-03-19) toDonein 0.58s — it had displayed a four-and-a-half-month-old status because refresh only ever fires for a card you open, and the list view is cached-only.Both items sit under the intent's "dashboard state is honest" invariant, which counts a stale signal as a defect rather than a cosmetic issue. Neither carries a tracker issue yet; the map's convention is an issue reference once active.
🤖 Generated with Claude Code