Count all enabled providers in Overview spend

[Chipagosfinest]

Summary

• keep Overview provider cards capped at the configured six-provider display limit
• compute Overview spend and its coverage denominator from every enabled provider in the display roster
• stable-deduplicate the accounting roster before building spend inputs
• add an integration regression proving a hidden seventh provider contributes without adding a seventh card

Root cause

The Overview menu reused its six-provider card selection as the spend input list. Any enabled provider outside that compact selection was silently excluded from both the subtotal and the x of y coverage denominator.

User impact

Users can keep a compact six-card Overview while the spend summary accounts for every enabled provider. Providers without a valid current-config cost snapshot remain in the denominator but do not enter the known subtotal.

Fresh app proof

This redacted capture comes from the freshly packaged branch app. It shows all seven enabled provider tabs, the six-card Overview selection, and 1 of 7 subscriptions have spend. Exact spend, token volume, and account identity are redacted. The app binary was built from eff754f2e6a7; current head 0d75f17d0e76 adds only this proof image.

Hosted behavior proof

The hosted macOS runner built the branch and executed the actual AppKit menu integration on commit 94399ec56d32. The only later production change is the three-line gatekeeper-anchor realignment in eff754f2e6a7; 0d75f17d0e76 adds only the proof image above.

macOS shard transcript

Test "overview keeps six visible providers while accounting for all seven connected providers" started.
Provider enablement: antigravity, claude, codex, gemini, grok, openai, openrouter
Test "overview keeps six visible providers while accounting for all seven connected providers" passed after 0.303 seconds.

That integration renders the real menu and asserts exactly six overviewRow-* items, while the hidden seventh provider contributes to the exact $85.00 subtotal and the summary reports 3 of 7 coverage. It also proves a disabled provider is excluded and duplicate accounting inputs are stable-deduplicated.

Validation

• fresh interactive branch-app capture above: seven enabled provider tabs and 1 of 7 spend coverage
• hosted AppKit integration above passed on macOS
• swift build --target CodexBarCore
• SwiftFormat 0.61.1 lint on changed files
• Swift parser checks on changed files
• exact gatekeeper anchors verified after the source insertion
• git diff --check
• independent adversarial review: ready, no actionable findings
• local focused execution is blocked before the target by the Command Line Tools environment missing PreviewsMacros in the KeyboardShortcuts dependency; hosted Xcode/macOS CI is authoritative

Follow-up to #3054 and the provider-coverage behavior discussed in #2695.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed August 18, 2026, 11:51 PM ET / August 19, 2026, 03:51 UTC.

ClawSweeper review

What this changes

The PR keeps Overview limited to six provider cards while calculating spend totals and coverage from every enabled, inline-eligible provider.

Regression provenance

Possible regression — suspected (reviewed change). No predecessor PR is attributed.

Merge readiness

✅ Ready for maintainer review

Keep open: the focused fix correctly separates compact Overview cards from spend accounting, with a regression test and direct redacted app proof. No actionable patch defect was found.

Priority: P2
Reviewed head: 0d75f17d0e769dc274541d373e7cc93afd30974d

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	Focused implementation, direct redacted app proof, and an AppKit regression provide normal good merge-ready evidence.
Proof confidence	🐚 platinum hermit (4/6) ✨ media proof bonus	Sufficient (screenshot): A prepared, redacted capture from a freshly packaged branch app directly shows seven enabled providers and 1 of 7 spend coverage.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (screenshot): A prepared, redacted capture from a freshly packaged branch app directly shows seven enabled providers and 1 of 7 spend coverage.
Evidence reviewed	4 items	Current-main defect: Current main derives spendProviders from the capped Overview selection, so enabled providers outside the six-card selection cannot enter the subtotal or coverage denominator. Focused implementation and regression: The branch retains the reconciled visible selection, builds a stable-deduplicated eligible spend roster from enabled providers, and covers seven enabled providers, six rows, a hidden provider’s $10.12 contribution, and 3 of 7 coverage. Merged feature provenance: The related merged change established Overview provider accounting on current main; this PR addresses the remaining visible-selection truncation in that path.
Findings	None	None.
Security	None	None.

Live Verification

Command: swift test --filter 'overview keeps six visible providers while accounting for all seven connected providers'

Result: FAIL (failed) — execution before step 1 run: sh -lc pnpm install --ignore-scripts --frozen-lockfile failed: ! Corepack is about to download https://registry.npmjs.org/pnpm/-/pnpm-11.22.0.tgz

sh -lc pnpm install --ignore-scripts --frozen-lockfile failed: ! Corepack is about to download https://registry.npmjs.org/pnpm/-/pnpm-11.22.0.tgz

Assertions:

• FAIL expect_output: overview keeps six visible providers while accounting for all seven connected providers

How this fits together

CodexBar builds the merged Overview menu from enabled provider status data and user display preferences. It renders a compact card set while aggregating eligible provider cost snapshots into a spend summary.

flowchart LR
A[Enabled providers] --> B[Overview scope selection]
C[Card display preferences] --> B
B --> D[Six visible cards]
B --> E[Spend accounting roster]
F[Provider cost snapshots] --> G[Spend summary]
E --> G
G --> H[Overview menu]

Loading

Before merge

None.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Production versus test delta	production +19/-6; tests +110/-3; 1 proof image	The small menu-accounting change is backed by a larger focused AppKit regression covering the hidden-provider case.

Technical review

Best possible solution:

Land the narrow roster separation once required checks complete, preserving six visible cards while reporting spend coverage across all enabled eligible providers.

Do we have a high-confidence way to reproduce the issue?

Yes—current-main source passes the capped six-card selection into spend accounting, and the branch regression constructs a seventh enabled provider excluded by that path.

Is this the best way to solve the issue?

Yes—the patch preserves the established compact-card behavior while using the full enabled roster only for spend accounting.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against a32989c750e6.

Labels

Label changes:

• add proof: sufficient: Contributor real behavior proof is sufficient. A prepared, redacted capture from a freshly packaged branch app directly shows seven enabled providers and 1 of 7 spend coverage.
• add proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. A prepared, redacted capture from a freshly packaged branch app directly shows seven enabled providers and 1 of 7 spend coverage.
• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🐚 platinum hermit.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (screenshot): A prepared, redacted capture from a freshly packaged branch app directly shows seven enabled providers and 1 of 7 spend coverage.
• remove status: 📣 needs proof: Current PR status label is status: 👀 ready for maintainer look.
• remove rating: 🦪 silver shellfish: Current PR rating is rating: 🐚 platinum hermit, so this older rating label is no longer current.

Label justifications:

• P2: This corrects misleading spend totals and coverage for multi-provider users without evidence of availability, security, or data-loss impact.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (screenshot): A prepared, redacted capture from a freshly packaged branch app directly shows seven enabled providers and 1 of 7 spend coverage.
• proof: sufficient: Contributor real behavior proof is sufficient. A prepared, redacted capture from a freshly packaged branch app directly shows seven enabled providers and 1 of 7 spend coverage.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. A prepared, redacted capture from a freshly packaged branch app directly shows seven enabled providers and 1 of 7 spend coverage.

Evidence

What I checked:

• Current-main defect: Current main derives spendProviders from the capped Overview selection, so enabled providers outside the six-card selection cannot enter the subtotal or coverage denominator. (Sources/CodexBar/StatusItemController+Menu.swift:581, a32989c750e6)
• Focused implementation and regression: The branch retains the reconciled visible selection, builds a stable-deduplicated eligible spend roster from enabled providers, and covers seven enabled providers, six rows, a hidden provider’s $10.12 contribution, and 3 of 7 coverage. (Sources/CodexBar/StatusItemController+Menu.swift:640, 0d75f17d0e76)
• Merged feature provenance: The related merged change established Overview provider accounting on current main; this PR addresses the remaining visible-selection truncation in that path. (Sources/CodexBar/StatusItemController+Menu.swift:581, d353ace608ce)
• Real app proof inspected: The prepared redacted image visibly shows seven enabled provider tabs and the Overview summary reading 1 of 7 subscriptions have spend. (.github/pr-proof/overview-all-connected-spend-redacted.png, 0d75f17d0e76)

Likely related people:

• Chipagosfinest: Authored this PR and co-authored the merged current-main Overview accounting work in the same subsystem. (role: recent merged spend-path contributor; confidence: high; commits: d353ace608ce; files: Sources/CodexBar/StatusItemController+Menu.swift, Tests/CodexBarTests/StatusMenuOverviewSpendTests.swift)
• Peter Steinberger: Feature history and shortlog show extensive, recent work in the central Overview menu path. (role: long-term Overview-menu contributor; confidence: medium; commits: 61c7e1ce821a, 7deae2acc44e; files: Sources/CodexBar/StatusItemController+Menu.swift)

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

History

Review history (3 earlier review cycles)

• reviewed 2026-08-19T02:18:00.384Z sha 5284444 :: needs real behavior proof before merge. :: none
• reviewed 2026-08-19T02:48:09.941Z sha 94399ec :: needs real behavior proof before merge. :: none
• reviewed 2026-08-19T03:20:36.179Z sha eff754f :: needs real behavior proof before merge. :: none

[Chipagosfinest]

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event exact_review_queue).
Result: when the review finishes, ClawSweeper will create the durable review comment if needed or update the existing comment in place.

[Chipagosfinest]

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event exact_review_queue).
Result: when the review finishes, ClawSweeper will create the durable review comment if needed or update the existing comment in place.

[Chipagosfinest]

Exact-head CI is terminal green on 0d75f17d0e769dc274541d373e7cc93afd30974d, including both macOS Swift-test shards and all Linux builds: https://github.com/steipete/CodexBar/actions/runs/32213488499