Harden dashboard async lifecycle paths

[TraderSamwise]

Summary

• route the remaining dashboard interaction statusline mutation through the TUI API adapter
• lifecycle-gate pending-action model reconcile renders
• add explicit rejection handling for create-settlement refresh callbacks
• add regressions for API adapter routing and stale lifecycle renders

Verification

• yarn vitest run src/multiplexer/dashboard-interaction.test.ts src/multiplexer/dashboard-model.test.ts src/multiplexer/dashboard-view-methods.test.ts src/multiplexer/dashboard-lifecycle.test.ts
• yarn typecheck && yarn lint && yarn vitest run && yarn build
• independent sub-agent audit: clean

Summary by CodeRabbit

• Bug Fixes

  • Fixed an issue where the dashboard could incorrectly render after transitioning to session mode.
  • Improved dashboard state handling during worktree row reordering operations.
  • Enhanced error handling for dashboard refresh requests.

• Tests

  • Added tests verifying dashboard worktree reordering routes correctly through the dashboard API.
  • Added tests ensuring proper behavior during mode transitions.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
app	Ready	Preview, Comment	Jun 23, 2026 6:32am

[coderabbitai]

Warning

Review limit reached

@TraderSamwise, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 1 minute and 1 second. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate.

For paid Pro and Pro+ PR reviews, CodeRabbit uses rolling per-developer review limits. Reviews become available again as older review attempts age out of the rolling limit window.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 50bebfed-656e-4c2f-a78b-07545df9c1b5

📥 Commits

Reviewing files that changed from the base of the PR and between f2436a6 and b615e2e.

📒 Files selected for processing (2)

• src/multiplexer/dashboard-interaction.test.ts
• src/multiplexer/dashboard-model.test.ts

📝 Walkthrough

Walkthrough

Lifecycle token capture is added to scheduleDashboardModelReconcile so that renderDashboard is skipped if the dashboard mode has changed since the refresh started. settleDashboardCreatePending gains a .catch to suppress refresh errors. The post-move statusline refresh in moveSelectedDashboardWorktreeEntry is rerouted from host.postToProjectService to mutateDashboardApi. Tests cover these three behavioral changes.

Changes

Dashboard lifecycle gating and API routing

Layer / File(s)	Summary
Lifecycle-gated render in scheduleDashboardModelReconcile src/multiplexer/dashboard-model.ts	Imports captureDashboardLifecycle and DashboardLifecycleToken; scheduleDashboardModelReconcile captures a token, passes it to refreshDashboardModelFromService, and only calls host.renderDashboard() when the token is still current after the refresh resolves.
settleDashboardCreatePending error handling and mutateDashboardApi routing src/multiplexer/dashboard-view-methods.ts, src/multiplexer/dashboard-interaction.ts	settleDashboardCreatePending adds .catch(() => undefined) to suppress refreshDashboardModelThroughApi rejections. Post-move statusline refresh is switched from host.postToProjectService?.(...) to mutateDashboardApi(host, ...).
Tests for lifecycle gating and reorder routing src/multiplexer/dashboard-model.test.ts, src/multiplexer/dashboard-interaction.test.ts	Updated reconcile test waits for a lifecycle-aware refreshDashboardModelFromService call before asserting renderDashboard. New test asserts renderDashboard is suppressed after mode transitions to "session". New test asserts the shifted-down key routes through moveEntryWithinWorktree and posts a forced statusline refresh.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• TraderSamwise/aimux#222: Introduces lifecycle-token gating in dashboard-view-methods.ts to prevent stale async callbacks from mutating UI, directly overlapping with this PR's lifecycle guard additions.
• TraderSamwise/aimux#230: Routes dashboard statusline and mutation flows through mutateDashboardApi instead of host.postToProjectService, which is the same refactor applied to moveSelectedDashboardWorktreeEntry here.
• TraderSamwise/aimux#229: Threads lifecycle tokens through dashboard refresh and settlement logic, matching the lifecycle capture and render-guard pattern added to scheduleDashboardModelReconcile in this PR.

Poem

🐇 A token I grabbed before the refresh began,
To check if the dashboard still followed the plan.
If mode flipped to session while awaiting the call,
No render shall trigger — no stale paint at all!
The API routes cleanly through mutateDashboardApi,
And errors are silenced with a gentle catch sigh.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Harden dashboard async lifecycle paths' accurately captures the main objective of the PR—improving robustness of asynchronous lifecycle management in the dashboard module, which is the core theme across all file changes.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch chore/next-20260623-tui-connection-adapter-7

---

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/multiplexer/dashboard-interaction.test.ts`:
- Around line 396-410: The test assertion on `postToProjectService` does not
uniquely verify that the adapter routing through `mutateDashboardApi` is being
used, as both the old and new code paths could satisfy this expectation. Add a
spy or mock for the `mutateDashboardApi` function in the test setup for the host
object, and then add a separate expectation to verify that `mutateDashboardApi`
was actually called during the `handleDashboardKey` invocation to ensure the
adapter routing is properly tested.

In `@src/multiplexer/dashboard-model.test.ts`:
- Around line 1067-1075: The assertions for host.renderDashboard at lines 1075
and 1107 are being checked outside the vi.waitFor block, which creates a race
condition where the render check may execute before the refresh promise chain
completes, causing flaky tests. Move both renderDashboard assertions inside
their respective vi.waitFor blocks so they are evaluated together with the
refreshDashboardModelFromService assertion, ensuring the test waits for the
complete reconciliation flow to settle before verifying render state.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 42110a66-d81a-462e-8e14-5aba67247410

📥 Commits

Reviewing files that changed from the base of the PR and between 44b7fcf and f2436a6.

📒 Files selected for processing (5)

• src/multiplexer/dashboard-interaction.test.ts
• src/multiplexer/dashboard-interaction.ts
• src/multiplexer/dashboard-model.test.ts
• src/multiplexer/dashboard-model.ts
• src/multiplexer/dashboard-view-methods.ts