Separate the scalable usage dashboard from the social share artifact

[Chipagosfinest]

Summary

Separate the scalable Usage & Spend dashboard from the social share artifact
instead of compressing the entire dashboard into one image.

This is a design follow-up to #2112 and #2116. It should not block the production
bug fixes.

Dashboard contract

• Every enabled provider remains discoverable through a searchable/sortable,
  capability-aware roster.
• Provider and model details use progressive disclosure.
• Partial coverage remains visible and explicitly labeled.
• Time-series usage supports provider/model filtering without forcing every
  source into the same normalized metric.

Share-card contract

• One hero statement, one supporting visualization, and compact provenance.
• The visual should explain volume, time, and source mix without listing an
  unbounded provider table.
• Dominant sources may be named while the long tail is represented as Other or
  +N more.
• Spend is labeled estimated where applicable.
• The artifact remains legible at 1200×630 social/OG thumbnail scale.
• Generated-image tools may inform art direction, but runtime layout and text
  must be deterministic.

Design evidence required before implementation

• Standalone 1200×630 card at actual size.
• Settings viewport at desktop and narrow widths.
• Examples with 1, 4, 8, and 20 enabled sources.
• Complete, partial, empty, unavailable, and multi-currency states.
• Dark/light appearance and reduced-motion/accessibility behavior where
  applicable.
• No fabricated productivity scores, public percentiles, or leaderboards.

Non-goals

• Hosted public profiles.
• Provider-logo walls.
• A literal copy of GitHub, Visa, or another product's visual system.
• Treating spend as the only measure of meaningful usage.

[Chipagosfinest]

Tracked in #2291. Follow-up PRs should link both this issue and #2291.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 18, 2026, 2:45 AM ET / 06:45 UTC.

Summary
Keep open. This is a fresh, scoped product-design follow-up: the merged dashboard and share-card work establishes the baseline split, but the open tracker still lists this specific scalable-information-architecture work as remaining and no maintainer decision adopts or rejects the requested next surface.

Reproducibility: not applicable. this is a requested product/UI capability, not a report of broken existing behavior. The current baseline is documented by the merged dashboard and share-card work.

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
A maintainer must choose the permanent dashboard/share-artifact product boundary before a repair or implementation lane can safely begin.

Maintainer decision needed

• Question: Should CodexBar sponsor the proposed scalable Usage & Spend exploration surface beyond the already merged dashboard and fixed-size local share artifact?
• Rationale: The request defines a new information architecture and UI-proof matrix, so source inspection cannot determine the intended permanent product boundary or acceptable scope.
• Likely owner: steipete — Repository-level product direction is required to choose the permanent UI boundary.
• Options:
  • Sponsor a scoped dashboard follow-up (recommended): Approve a focused design/implementation plan that preserves the existing local, provider-specific usage and share-card contracts.
  • Defer the expanded dashboard: Keep the shipped dashboard and share card as the supported surface until a later product cycle prioritizes scalable exploration.
  • Limit work to correctness fixes: Retain the tracker only for the linked production hardening items and decline new dashboard information-architecture scope for now.

Review details

Best possible solution:

Have a product owner approve a narrow dashboard information architecture that reuses the existing provider-specific data model, keeps partial coverage and currencies explicit, and validates the required source-count, state, appearance, and accessibility matrix before implementation.

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

Not applicable: this is a requested product/UI capability, not a report of broken existing behavior. The current baseline is documented by the merged dashboard and share-card work.

Is this the best way to solve the issue?

Unclear: the desired split is reasonable, but the exact scalable dashboard surface requires maintainer product approval before it can be judged as the narrowest maintainable solution.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A broad dashboard redesign without explicit product scope could duplicate or conflict with the existing local share-card and provider-specific coverage/currency contracts.

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

Label changes

Label changes:

• add P3: This is a non-blocking, explicitly deferred design enhancement rather than a production correctness regression.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P3: This is a non-blocking, explicitly deferred design enhancement rather than a production correctness regression.

Evidence reviewed

What I checked:

• Active canonical tracker: The reporter explicitly linked the open production-follow-up tracker, whose sharing/design checklist includes this exact dashboard-versus-share-card separation; it is an umbrella tracker rather than evidence that this child request is already completed.
• Merged baseline implementations: Merged PRs Add shareable subscription usage cards #2112 and Settings: add unified usage and spend dashboard #2116 established the local share-card and persisted Usage & Spend dashboard, respectively, but their stated scopes intentionally separate export from persistent exploration rather than implementing the requested scalable roster/filter design. (Sources/CodexBar, 7b11885ba51f)
• Repository review policy: The checked-out repository policy requires focused UI evidence and favors preserving provider-specific data boundaries; this proposal needs an approved, scoped product direction before a broad UI implementation can be evaluated. (AGENTS.md:1, 9e9f739b6a96)

Likely related people:

• Chipagosfinest: Authored the merged share-card and Usage & Spend dashboard PRs that define the existing separation and data-contract baseline for this follow-up. (role: introduced merged feature work; confidence: high; commits: 7b11885ba51f, 0397529ae6e5; files: Sources/CodexBar)
• steipete: The requested work adds a substantial product/UI direction beyond the already merged feature baseline and therefore needs repository-owner product sponsorship. (role: repository vision decision owner; confidence: medium; files: VISION.md, AGENTS.md)

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]

Release-gate audit (2026-07-18): draft #2307 is the current share-card prototype, but it is not ready for product review yet. It depends on renderer fix #2292 and partial-model fix #2308, and its committed image is a design target rather than a runtime SwiftUI export. The dashboard bullet requiring every enabled provider also conflicts with the maintainer decision on #2288, which kept Usage & Spend scoped to cost-history-capable sources. Before #2307 is promoted, this issue should either narrow that provider-scope sentence or record an explicit maintainer decision to expand it. Model/source identity and cross-provider aggregation are also tracked in #2257.