Track Usage & Spend production hardening and sharing follow-ups

[Chipagosfinest]

Goal

Track the production hardening and product follow-ups for the Usage & Spend dashboard and aggregate share-card work introduced by #2112 and #2116.

Each item is intentionally isolated so correctness fixes can land without waiting on broader product design.

Production correctness

• Fix black PNG exports from usage share cards #2286 — Copy Image exports an all-black PNG
  • Fix candidate: Fix black PNG exports from usage share cards #2292
  • Gate: renderer proof sufficient; exact-head Linux x64/arm64 and musl green; both macOS shards green on the tree-identical prior head; current empty-retry-head macOS jobs queued
• Keep complete model rows visible when another source is incomplete #2287 — incomplete sources suppress complete model rows
  • Fix candidate: Fix partial model history aggregation #2308
  • Gate: resolve aggregate-overflow completeness review, then require final CI
• Represent every enabled provider in Usage & Spend #2288 — enabled providers without token-cost capability are omitted
  • Closed as not planned under the current cost-history dashboard contract

Sharing and design

• Add native macOS sharing for aggregate usage cards #2289 — native macOS sharing for the same local aggregate artifact
  • Keep separate until renderer and card contract are stable
• Separate the scalable usage dashboard from the social share artifact #2290 — separate scalable dashboard information architecture from the standalone social artifact
  • Draft implementation: Redesign usage share card around model activity #2307
  • Related model-identity discussion: Feature discussion: model-centric token / cost view across providers #2257
  • Dependencies: Fix black PNG exports from usage share cards #2292 and Fix partial model history aggregation #2308

Related provider work

• Add daily cost and plan usage history for OpenCode Go #2296 adds OpenCode Go plan and daily cost history. It is adjacent provider capability work, not an implementation of an all-enabled-provider Usage & Spend roster.
  • Current blockers: web/local plan percentages still share an identityless unscoped history bucket, packaged Auto/Web source-boundary proof is missing, and replacement CI for the source-contract test fix at ee5d6d1b is pending.

CI reliability

• Prevent concurrent PlatformGatingTests flake on Linux #2309 — concurrent Claude CLI platform-gating cases can flake on Linux x64
  • Fix candidate: Serialize flaky Claude CLI platform-gating cases #2311
  • Gate: exact-head Linux x64 and arm64 passed; full local make check and 716-selection make test passed; ready for maintainer review while macOS jobs settle

Current release order

1. Land renderer correctness in Fix black PNG exports from usage share cards #2292 after its queued tree-identical-head checks settle.
2. Land partial model-history correctness in Fix partial model history aggregation #2308 after its aggregate-overflow finding is resolved and CI is green.
3. Land test-only CI isolation in Serialize flaky Claude CLI platform-gating cases #2311 independently; it fixes Prevent concurrent PlatformGatingTests flake on Linux #2309 and is not a dependency of the renderer implementation.
4. Rebase and harden draft Redesign usage share card around model activity #2307 against the approved data/product contract.
5. Implement native sharing under Add native macOS sharing for aggregate usage cards #2289 as its own concern.

Shipping rules

• One concern per PR.
• Link the child issue and this tracker.
• Use current-main source reproduction and focused tests.
• Run make check and make test before handoff.
• UI changes include actual-size screenshot evidence from the real runtime path.
• No account identity, keys, prompts, projects, paths, or raw events in evidence.
• No provider-wide normalization when the underlying capability does not exist.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 18, 2026, 5:22 PM ET / 21:22 UTC.

Summary
Keep this coordination tracker open: active, separately scoped correctness PRs still need to land or be reviewed, while the dashboard/share follow-ups require an explicit product-sequencing decision.

Reproducibility: not applicable. this is an umbrella coordination tracker, while its individual correctness reports and pull requests own the concrete reproduction paths.

Root-cause cluster
Relationship: canonical
Canonical: #2291
Summary: This is the umbrella tracker for distinct Usage & Spend follow-ups; the linked items share a release sequence but retain separate technical and product boundaries.

Members:

• partial_overlap: Fix black PNG exports from usage share cards #2286 - This is one concrete renderer-correctness child tracked by the umbrella.
• partial_overlap: Fix black PNG exports from usage share cards #2292 - This active PR is the proposed implementation path for one child correctness issue, not a replacement for the whole tracker.
• partial_overlap: Add native macOS sharing for aggregate usage cards #2289 - Native sharing is a distinct future product concern explicitly retained as a separate item.
• partial_overlap: Separate the scalable usage dashboard from the social share artifact #2290 - Dashboard versus social-artifact information architecture is a separate design decision under the same release sequence.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Include the exact command, prompt, or workflow that triggered it.
• Add expected vs actual behavior.

Next step
The concrete repairs already have active implementation paths; the remaining blocker is maintainer sponsorship and sequencing for the broader product surface.

Maintainer decision needed

• Question: Should the repository sponsor the proposed sequence of correctness fixes first, followed by a separately approved dashboard/share contract for the remaining design work?
• Rationale: The open work includes new sharing and information-architecture scope whose accepted product boundary cannot be inferred from the existing tracker or implementation PRs alone.
• Likely owner: steipete — As repository owner, they are the best available decision point for whether these new product surfaces should be sponsored and in what order.
• Options:
  • Adopt the staged sequence (recommended): Review the focused correctness PRs independently, then require an approved dashboard/share contract before accepting redesign or native-sharing work.
  • Pause the broader product work: Keep correctness fixes moving but defer dashboard redesign and native sharing until the repository has a clearer Usage & Spend roadmap.

Review details

Best possible solution:

Land or resolve the focused correctness PRs independently, then have the repository owner approve a narrow dashboard/share contract before advancing the remaining product work.

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

Not applicable: this is an umbrella coordination tracker, while its individual correctness reports and pull requests own the concrete reproduction paths.

Is this the best way to solve the issue?

Unclear until product direction is confirmed; keeping renderer/model correctness separate from the broader sharing and dashboard design is the maintainable boundary supported by the discussion.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Without an explicit sequence, broader dashboard/share redesign work could advance before the renderer and partial-model-history correctness paths are settled.

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

Label changes

Label changes:

• remove impact:other: Current review selected no impact labels.

Label justifications:

• P2: This tracker coordinates active production-correctness follow-ups and bounded product decisions, but no emergency or presently confirmed broad user outage is established.

Evidence reviewed

What I checked:

• Active implementation paths: The tracker identifies active candidate PRs for the black-PNG renderer defect and the dashboard redesign, so the central work is not yet completed or superseded. (d2a3da910477)
• Merged feature baseline: The tracker follows the already-merged share-card and Usage & Spend dashboard work, with production hardening and product-boundary follow-ups still explicitly separated. (Sources/CodexBar/ShareStatsRenderer.swift, 7b11885ba51f)
• Merged dashboard provenance: The related dashboard implementation merged in commit 0397529; the open tracker concerns follow-up correctness and design work rather than a duplicate request. (Sources/CodexBar/SpendDashboardModel.swift, 0397529ae6e5)
• Contributor discussion: The contributor explicitly states that the renderer fix is being handled in a tightly scoped PR and that the dashboard/share redesign should wait for approved visual direction.
• Repository policy: The repository’s generic personal-repository review profile requires conservative handling and does not enable automatic closure for this tracker. (AGENTS.md:1, d2a3da910477)

Likely related people:

• Chipagosfinest: Their earlier merged work established both the local share-card and Usage & Spend dashboard surfaces that this tracker coordinates. (role: merged feature contributor; confidence: high; commits: 7b11885ba51f, 0397529ae6e5; files: Sources/CodexBar/ShareStatsRenderer.swift, Sources/CodexBar/SpendDashboardModel.swift)
• steipete: The remaining dashboard/share scope needs a repository-level product and sequencing decision rather than another independent implementation branch. (role: repository owner and likely product decision owner; confidence: medium)

How this review workflow works

• 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.

[Chipagosfinest]

First tightly scoped draft PR is up: #2292 fixes the production black-PNG export bug tracked in #2286. The dashboard/share redesign remains separate and will not be PR'd until its visual direction is approved.