Skip to content

feat(dashboard): align agent-row chips with the hardened inbox semantic layer#172

Merged
TraderSamwise merged 4 commits into
masterfrom
chore/tui-next-27
Jun 19, 2026
Merged

feat(dashboard): align agent-row chips with the hardened inbox semantic layer#172
TraderSamwise merged 4 commits into
masterfrom
chore/tui-next-27

Conversation

@TraderSamwise

Copy link
Copy Markdown
Owner

Summary

Now that the Coordination inbox is reconciled (PR #171), the dashboard agent-row chips read the same notification/thread stores on a separate, unreconciled path — so they double-counted and contradicted Coordination. This aligns them (information layer only; existing chip primitives, no color/box restyle). Four focused changes:

  • Stop counting notification threads as session threads (2587975): computeDashboardSessions built per-session thread stats from the raw listThreadSummaries(), which includes notification records (threads tagged notification). A needs-input notice was counted in both N unread (notification store) and thread X/Y/Z/pending (thread store) — same record, shown twice. Excluded notification-tagged threads from the stats source, mirroring the Coordination de-dupe.
  • De-emphasize stale unread (233c198): shared isNotificationStale (exported from coordination-model); the dashboard N unread chip renders muted when a needs-input notice lingers but the live agent label has moved on — gated on semantic.runtime.isAlive to match Coordination's live-only stale.
  • Lock the free win (b21e912): regression test that cleanupInbox refreshes consumers (refreshNotificationEntries + metadataServer.notifyChange) on archival, so the dashboard's automatic unread-count shrink can't silently regress.
  • Don't double-show needs-input (351388a): the live state label already announces a needs-input request, so the unread chip subtracts that portion when the label conveys it (per-session needsInputUnreadCount). Other unread kinds still surface; a stale lingering notice still shows muted. The signal appears once.

Net: the 6-chip agent row collapses to what's actually distinct — needs-input shows once (state label), thread/pending reflect only genuine threads, and unread means other unread or a muted stale remnant.

Test plan

  • yarn typecheck, yarn lint, full yarn vitest (1461 passing), yarn build — all clean.
  • Each phase passed an independent plan-audit + implementation-audit (Explore agents) before commit.

🤖 Generated with Claude Code

test and others added 4 commits June 19, 2026 10:08
computeDashboardSessions built per-session thread stats from the raw
listThreadSummaries(), which includes notification records (exchange threads
tagged `notification`). A needs-input notification was therefore counted in both
the `N unread` chip (notification store) and the `thread X/Y/Z` + `pending` chips
(thread store) — the same record shown twice on the agent row. Exclude
notification-tagged threads from the thread-stats source, mirroring the
Coordination thread de-dupe. The notification signal is unchanged (it flows via
the separate notificationUnreadCount path).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Mirror Coordination's stale reconciliation on the dashboard. A shared
isNotificationStale(liveLabel, hasUnreadNeedsInput) helper (exported from
coordination-model, reused by buildItem) flags when an unread needs-input notice
lingers but the live agent label has moved past a waiting state.

summarizeUnreadNotificationsBySession now reports hasNeedsInputUnread per
session; computeDashboardSessions sets DashboardSession.notificationStale, gated
on the live agent (semantic.runtime.isAlive) to match Coordination's live-only
stale. The unread chip renders muted (not bright) when stale, so the dashboard
stops contradicting a WORKING agent with a loud unread badge.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Regression test that persistenceMethods.cleanupInbox refreshes consumers
(refreshNotificationEntries + metadataServer.notifyChange) when it archives a
read/aged notification, and does neither when nothing is eligible — so the
dashboard's automatic unread-count shrink (the shared-store free win) can't
silently regress.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ad chip

The agent row already announces a needs-input request via its live state label,
so also rendering it as an `N unread` chip is redundant. Track per-session
needsInputUnreadCount (replacing the hasNeedsInputUnread boolean) and, when the
live label conveys needs-input, subtract that portion from the unread chip —
other unread kinds still surface, and a stale lingering notice (label moved on)
still shows muted. Net: the needs-input signal appears once, where it belongs.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@vercel

vercel Bot commented Jun 19, 2026

Copy link
Copy Markdown

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

Project Deployment Actions Updated (UTC)
app Ready Ready Preview, Comment Jun 19, 2026 2:39am

@coderabbitai

coderabbitai Bot commented Jun 19, 2026

Copy link
Copy Markdown

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 57 minutes and 34 seconds. 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 adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: ae7f288e-e0e0-45f2-8fad-c66db6f4e20e

📥 Commits

Reviewing files that changed from the base of the PR and between 52b7929 and 351388a.

📒 Files selected for processing (9)
  • src/coordination-model.test.ts
  • src/coordination-model.ts
  • src/dashboard/index.ts
  • src/multiplexer/dashboard-model.test.ts
  • src/multiplexer/dashboard-model.ts
  • src/multiplexer/inbox-cleanup-runtime.test.ts
  • src/notifications.ts
  • src/tui/screens/dashboard-renderers.test.ts
  • src/tui/screens/dashboard-renderers.ts
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch chore/tui-next-27

Comment @coderabbitai help to get the list of available commands and usage tips.

@TraderSamwise
TraderSamwise merged commit 9ab4147 into master Jun 19, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant