feat: BrainBar V1 dashboard — progressive-disclosure signal coverage#520
Conversation
There was a problem hiding this comment.
Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.
📝 WalkthroughWalkthrough
ChangesSignal Coverage Panel Expandable Redesign
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 163c4bb. Configure here.
| HStack(spacing: compact ? 14 : 22) { | ||
| BrainBarSignalDetailMetric(label: "drain", value: "~\(formatted(estimatedDrainRatePerHour))/hr", tint: signal.accentColor) | ||
| BrainBarSignalDetailMetric(label: "ETA", value: "~\(estimatedETAHours)h", tint: signal.accentColor) | ||
| BrainBarSignalDetailMetric(label: "backlog", value: signal.backlogText, tint: Color.brainBarTextPrimary) |
There was a problem hiding this comment.
Vector ETA ignores live backlog
Medium Severity
BrainBarVectorSignalDetail shows live backlog from DashboardStats beside fixed ~3,300/hr drain and ~13h ETA. As stats refresh, backlog can be zero or far from the demo backlog while drain and ETA never change, so the L2 panel contradicts itself.
Reviewed by Cursor Bugbot for commit 163c4bb. Configure here.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 163c4bb50e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| backlogCount: stats.vectorBacklogCount, | ||
| coveragePercent: stats.vectorCoveragePercent, | ||
| accentColor: .brainBarAccent | ||
| accentColor: amber, |
There was a problem hiding this comment.
Derive signal colors from current coverage
When the dashboard is connected to a DB where Vector is fully caught up, this still renders Vector as degraded, while the nearby FTS5/Trigram entries stay green even if their backlog grows. Since the percentages and backlog counts already come from DashboardStats, the accent should be based on each signal’s current coverage/backlog rather than frozen snapshot colors; otherwise refreshed stats can show healthy-looking or degraded-looking retrieval signals incorrectly.
Useful? React with 👍 / 👎.
| // TODO: Replace these rollout estimates with measured vector drain fields | ||
| // once DashboardStats carries vector indexing history. | ||
| private let estimatedDrainRatePerHour = 3_300 | ||
| private let estimatedETAHours = 13 |
There was a problem hiding this comment.
Compute vector drain and ETA from live stats
When vectorBacklogCount differs from the rollout snapshot, including when it reaches zero or stops draining, L2 still displays ~3,300/hr and ~13h, so users see an ETA unrelated to the current database state. The detail should be derived from measured stats/backlog or hidden until those fields exist; otherwise BrainBar can report a caught-up or stalled vector index as actively draining with a fixed ETA.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@brain-bar/Sources/BrainBar/BrainBarWindowRootView.swift`:
- Around line 897-900: The hardcoded values estimatedDrainRatePerHour and
estimatedETAHours in BrainBarWindowRootView are acknowledged as temporary
scaffolding in the TODO comment. Create a formal issue or task in your project
tracker to document the technical debt of replacing these hardcoded estimates
with computed values derived from DashboardStats once it carries vector indexing
history. Alternatively, enhance the TODO comment to include specific acceptance
criteria such as what fields need to be added to DashboardStats and how the
drain rate and ETA should be calculated from actual vector indexing metrics.
🪄 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: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: a3dcc511-d770-4963-ab32-192cd7624490
📒 Files selected for processing (2)
brain-bar/Sources/BrainBar/BrainBarWindowRootView.swiftbrain-bar/Tests/BrainBarTests/DashboardTests.swift
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: test (3.11)
- GitHub Check: test (3.13)
- GitHub Check: test (3.12)
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2026-03-18T00:12:08.774Z
Learnt from: EtanHey
Repo: EtanHey/brainlayer PR: 87
File: brain-bar/Sources/BrainBar/BrainBarServer.swift:118-129
Timestamp: 2026-03-18T00:12:08.774Z
Learning: In Swift files under brain-bar/Sources/BrainBar, enforce that when a critical dependency like the database is nil due to startup ordering (socket before DB), any tool handler that accesses the database must throw an explicit error (e.g., ToolError.noDatabase) instead of returning a default/empty value. Do not allow silent defaults (e.g., guard let db else { return ... }). Flag patterns that silently return defaults when db is nil, as this masks startup timing issues. This guidance applies broadly to similar Swift files in the BrainBar module, not just this one location.
Applied to files:
brain-bar/Sources/BrainBar/BrainBarWindowRootView.swift
📚 Learning: 2026-03-29T18:45:40.988Z
Learnt from: EtanHey
Repo: EtanHey/brainlayer PR: 133
File: brain-bar/Sources/BrainBar/BrainDatabase.swift:0-0
Timestamp: 2026-03-29T18:45:40.988Z
Learning: In the BrainBar module’s Swift database layer (notably BrainDatabase.swift), ensure that the `search()` function’s `unreadOnly=true` path orders results by the delivery frontier cursor so the watermark `maxRowID` stays contiguous. Specifically, when `unreadOnly` is enabled, the query must include `ORDER BY c.rowid ASC` (e.g., via `let orderByClause = unreadOnly ? "c.rowid ASC" : "f.rank"`). Do not replace the unread-only ordering with relevance-based sorting (e.g., `f.rank`) unconditionally or for the unread-only path, as it can introduce gaps in the watermark and incorrectly mark unseen rows as delivered. Flag any future change to the `ORDER BY` clause in this function that makes relevance sorting apply to the unread-only case.
Applied to files:
brain-bar/Sources/BrainBar/BrainBarWindowRootView.swift
🔇 Additional comments (9)
brain-bar/Tests/BrainBarTests/DashboardTests.swift (1)
297-303: LGTM!brain-bar/Sources/BrainBar/BrainBarWindowRootView.swift (8)
325-326: LGTM!
493-503: LGTM!
555-562: LGTM!
706-738: LGTM!
758-820: LGTM!
823-845: LGTM!
847-891: LGTM!
961-980: LGTM!
| // TODO: Replace these rollout estimates with measured vector drain fields | ||
| // once DashboardStats carries vector indexing history. | ||
| private let estimatedDrainRatePerHour = 3_300 | ||
| private let estimatedETAHours = 13 |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Consider tracking the TODO for real drain metrics.
The hardcoded values (estimatedDrainRatePerHour = 3_300, estimatedETAHours = 13) and the static "falling" trend label (line 946) are acknowledged as scaffolding. Once DashboardStats carries vector indexing history, these should be replaced with computed values.
Would you like me to open an issue to track adding vector drain rate and ETA calculation to DashboardStats?
🤖 Prompt for 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.
In `@brain-bar/Sources/BrainBar/BrainBarWindowRootView.swift` around lines 897 -
900, The hardcoded values estimatedDrainRatePerHour and estimatedETAHours in
BrainBarWindowRootView are acknowledged as temporary scaffolding in the TODO
comment. Create a formal issue or task in your project tracker to document the
technical debt of replacing these hardcoded estimates with computed values
derived from DashboardStats once it carries vector indexing history.
Alternatively, enhance the TODO comment to include specific acceptance criteria
such as what fields need to be added to DashboardStats and how the drain rate
and ETA should be calculated from actual vector indexing metrics.


Etan's V1 pick. Replaces the always-on Signal Coverage panel with minimal progressive disclosure under the WRITES throughput graph:
Real numbers from DashboardStats; responsive compact/full preserved. Sandbox-verified on an alt socket; real-app screenshots + Opus design review to follow.
Note
Low Risk
SwiftUI-only dashboard layout and presentation changes; backlog/coverage still come from real stats, but Vector drain/ETA/trend are static estimates and could mislead operators until wired to data.
Overview
Signal coverage moves from a standalone dashboard section into the Pipeline panel, stacked under the Writes card. The old always-visible glass panel with a "Signal Coverage" header and explanatory copy is replaced by a collapsed "see under the hood" control.
Expanding that control shows Vector, FTS5, and Trigram coverage as compact health-colored gradient bars (amber for Vector, green for FTS5/Trigram), driven by existing
DashboardStatscounts and percentages. Vector is tappable for a second level of detail: drain rate, ETA, formatted backlog, and a static "falling" trend badge—drain/ETA/trend are hard-coded placeholders untilDashboardStatsexposes measured vector indexing history.Coverage rows drop indexed/total metrics and
ProgressViewin favor of card styling with optional selection chrome. Source tests were updated to assert the new disclosure strings and state, and to ensure the old section label and helper text are gone.Reviewed by Cursor Bugbot for commit 163c4bb. Bugbot is set up for automated code reviews on this repo. Configure here.
Note
Add progressive-disclosure signal coverage panel to BrainBar V1 dashboard
BrainBarSignalCoveragePanelinto the pipeline section and makes it collapsible via a 'see under the hood' disclosure button, controlled by newsignalCoverageExpandedandvectorSignalDetailExpandedstate properties onBrainBarDashboardView.ProgressView-based signal rows inBrainBarSignalCoverageRowwith custom Capsule gradient bars and button-selectable rows that highlight when active.BrainBarVectorSignalDetail, a new subpanel shown when the Vector signal row is selected, displaying drain rate, ETA, backlog, and trend via reusableBrainBarSignalDetailMetriccomponents.showsDetail=true, FTS is renamed FTS5 with green accent, and Trigram uses green accent.DashboardTestsare updated to assert the new disclosure label, state properties, and FTS5 naming, and to confirm removal of the old section header and description copy.Macroscope summarized 163c4bb.
Summary by CodeRabbit
New Features
Style