[codex] Redesign analytics dashboard

[steipete-oai]

Summary

• replace the dark control-room hero and radial meters with a clean, light analytics dashboard
• add accessible 30-day request and provider-distribution charts with responsive keyboard and touch behavior
• rebuild Usage as a full-width analytics and audit workspace
• add real UTC daily usage buckets to the ledger and preserve mixed-version rollout semantics
• simplify shell metadata, improve empty states, and tighten light/dark theme contrast

Why

The previous dashboard was visually heavy and the Usage screen had aggregate counters and tables but no trustworthy time-series data. Building a 30-day chart from the latest 100 events would undercount busy installations, so this change adds daily aggregation at the ledger boundary and uses it across Home and Usage.

Validation

• node --test admin/test/*.test.mjs — 22 passed
• node --test worker/test/usage-sharding.test.mjs — 3 passed
• admin TypeScript --noEmit check passed
• production Vite bundle passed
• git diff --check passed
• responsive, dark-mode, accessibility, and rollout autoreviews completed with no remaining findings

Notes

The full workspace pnpm check could not run in this environment because the internal package registry returned 403 for @cloudflare/workers-types@4.20260621.1. The focused touched-surface checks above passed.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed July 2, 2026, 8:08 PM ET / 00:08 UTC.

Summary
The branch redesigns the admin Home and Usage analytics surfaces, adds chart helpers/styles/tests, extends UsageSnapshot with optional daily buckets, and computes daily usage buckets in Worker ledger snapshots.

Reproducibility: not applicable. This PR adds a redesigned analytics/dashboard experience and daily usage aggregation rather than reporting a failing current-main behavior.

Review metrics: 3 noteworthy metrics.

• Changed surface: 17 files, +1364/-108. The patch spans admin UI, shared contracts, Worker ledger aggregation, and tests, so review is broader than CSS polish.
• New files: 4 added. New chart, analytics helper, stylesheet, and test files own most of the redesigned dashboard behavior.
• Shared API: 1 response contract extended. UsageSnapshot gains optional daily buckets, so rollout behavior and consumer compatibility need maintainer attention.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🌊 off-meta tidepool
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Confirm whether usage consumers should now see UTC calendar-day totals instead of rolling 30-day totals.
• Attach rendered browser proof or ask Mantis to verify the redesigned Home and Usage charts across themes and narrow widths.

Mantis proof suggestion
The redesigned Home and Usage analytics surfaces are visible browser behavior that would benefit from rendered proof across themes and narrow widths. A maintainer can ask Mantis to capture proof by posting this exact PR comment:

@openclaw-mantis visual task: verify the admin Home and Usage analytics charts render in light/dark desktop and narrow widths with no overlap.

Risk before merge

• [P1] Usage snapshot summary, provider totals, and recent event selection would shift from a rolling 30-day cutoff to UTC calendar-day semantics; existing consumers may see different totals unless maintainers explicitly accept that contract change.
• [P1] The broad visual dashboard rewrite has no rendered browser screenshot or recording in the PR body; the collaborator proof gate does not apply, but maintainers may still want visual proof across themes and narrow widths before landing.

Maintainer options:

1. Confirm Calendar-Day Usage Semantics
   Maintainers can accept the compatibility change if admin and session usage consumers should now treat reported totals as UTC calendar-day windows instead of rolling 30-day windows.
2. Preserve Rolling Totals Separately
   Keep the existing rolling cutoff for summary, providers, and recent events, then compute UTC daily buckets only for the new charts.
3. Split Ledger Change From Visual Rewrite
   Hold or split the PR if maintainers want to review the shared usage API change independently from the dashboard redesign.

Next step before merge

• [P2] Maintainer review should decide whether the shared usage API can switch to UTC calendar-day semantics and whether the dashboard redesign direction is acceptable; there is no narrow automated repair until that choice is made.

Security
Cleared: No concrete security or supply-chain regression was found; the diff does not add dependencies, workflows, secrets handling, broader retained-content access, or raw prompt/completion logging.

Review details

Best possible solution:

Land after maintainers confirm the UTC calendar-day usage semantics and dashboard direction, or preserve the existing rolling summary/providers/events while using daily buckets only for chart rendering.

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

Not applicable; this PR adds a redesigned analytics/dashboard experience and daily usage aggregation rather than reporting a failing current-main behavior.

Is this the best way to solve the issue?

Unclear; the implementation is coherent, but the best final shape depends on maintainer acceptance of replacing the dashboard and changing usage-window semantics. A safer compatibility path would keep rolling summary totals and add daily buckets only for chart series.

AGENTS.md: found and applied where relevant.

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

Label changes

Label justifications:

• P2: This is a normal-priority admin analytics and usage-contract improvement with bounded but real compatibility review surface.
• merge-risk: 🚨 compatibility: The PR changes the shared UsageSnapshot shape and the usage snapshot time-window semantics used by current consumers.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The external-contributor proof gate does not apply to this collaborator-authored PR; the PR body lists validation but does not attach rendered browser media.

Evidence reviewed

What I checked:

• Repository policy read: AGENTS.md was read fully; its Worker/admin validation guidance and data-plane hot-path constraints are relevant because the PR touches admin TypeScript, shared contracts, and Worker ledger aggregation. (AGENTS.md:1, d39ef9cfa07f)
• Protected author signal: GitHub reports the PR is open, draft, and authored by a collaborator, so this cleanup review should not auto-close it even though maintainer judgment is needed. (2931c0345524)
• Current main usage behavior: Current main snapshots use a rolling Date.now() - usageRetentionMs cutoff and return summary/providers/events without daily buckets. (worker/ledgers.ts:135, d39ef9cfa07f)
• PR changes usage-window semantics: The PR changes the snapshot cutoff to the first UTC calendar day in the 30-day chart window, and the same cutoff feeds events, summary, providers, and daily buckets. (worker/ledgers.ts:136, 2931c0345524)
• Shared contract extension: The PR adds UsageDailySummary and makes UsageSnapshot.daily optional, extending the shared admin/session usage response shape. (shared/contracts.ts:157, 2931c0345524)
• Current main lacks the central PR feature: Search found no UsageDailySummary, usageTimeline, TrafficAreaChart, or daily usage snapshot support on current main, so the PR is not already implemented. (d39ef9cfa07f)

Likely related people:

• steipete: Merged PRs 55, 57, and 58 introduced or refactored the current TypeScript Worker usage ledger, usage sharding, shared contracts, and admin dashboard surfaces touched by this PR. (role: recent area contributor; confidence: high; commits: 61cba0807c1e, f50252f718ff, e33fdacbbf80; files: worker/ledgers.ts, worker/usage-sharding.ts, shared/contracts.ts)
• steipete-oai: Authored the merged centralized spend-controls work that originally added the usage and admin analytics foundation this PR extends. (role: feature owner; confidence: medium; commits: 21e11b869116, d6752dbebf3b; files: docs/agent-spend-control.md, admin/src/main.tsx, crates/edge/src/lib.rs)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

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.

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.