feat(dashboard): align agent-row chips with the hardened inbox semantic layer#172
Conversation
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>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reached
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 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 configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (9)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
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:
2587975):computeDashboardSessionsbuilt per-session thread stats from the rawlistThreadSummaries(), which includes notification records (threads taggednotification). A needs-input notice was counted in bothN unread(notification store) andthread X/Y/Z/pending(thread store) — same record, shown twice. Excluded notification-tagged threads from the stats source, mirroring the Coordination de-dupe.233c198): sharedisNotificationStale(exported fromcoordination-model); the dashboardN unreadchip renders muted when a needs-input notice lingers but the live agent label has moved on — gated onsemantic.runtime.isAliveto match Coordination's live-only stale.b21e912): regression test thatcleanupInboxrefreshes consumers (refreshNotificationEntries+metadataServer.notifyChange) on archival, so the dashboard's automatic unread-count shrink can't silently regress.351388a): the live state label already announces a needs-input request, so the unread chip subtracts that portion when the label conveys it (per-sessionneedsInputUnreadCount). 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
unreadmeans other unread or a muted stale remnant.Test plan
yarn typecheck,yarn lint, fullyarn vitest(1461 passing),yarn build— all clean.🤖 Generated with Claude Code