Add optional upcoming reset schedule display

[gmkbenjamin]

Summary

• Adds an off-by-default Show upcoming resets Menu preference that projects the next few rolling-quota reset times from resetsAt + windowMinutes.
• Reset times (Countdown vs Date & time) applies to both the immediate next reset and estimated follow-ups; absolute estimated resets use weekday + date + time stamps.
• Projects only fixed rolling cadences (1h / 4h / 5h / daily / weekly). Billing-cycle windows are not projected.
• CLI usage honors the same preference and Reset times style when reading UserDefaults.
• New strings localized in all supported catalogs.
• Rebuilt cleanly on current main; unrelated Spend Dashboard test-isolation commits were removed from the branch.

Real behavior proof

Fresh packaged release bundle (CodexBar.app → /Applications/CodexBar.app), Claude account.

Menu (countdown, preference on)

Shows Session Then 9h 59m · 14h 59m · 19h 59m and Weekly Then 8d 18h · 15d 18h · 22d 18h.

CLI (same settings, redacted runtime)

On + Countdown

Session: 100% left
Resets in 4h 36m
Then 9h 36m · 14h 36m · 19h 36m
Weekly: 0% left
Resets in 1d 18h
Then 8d 18h · 15d 18h · 22d 18h

On + Date & time

Session: 100% left
Resets tomorrow, 3:00 AM
Then Tue, Jul 28 at 8:00 AM · Tue, Jul 28 at 1:00 PM · Tue, Jul 28 at 6:00 PM
Weekly: 0% left
Resets Jul 29 at 5:00 PM
Then Wed, Aug 5 at 5:00 PM · Wed, Aug 12 at 5:00 PM · Wed, Aug 19 at 5:00 PM

Off

Session: 100% left
Resets tomorrow, 3:00 AM
Weekly: 0% left
Resets Jul 29 at 5:00 PM

(no Then … lines)

Raw artifacts: docs/screenshots/upcoming-resets-cli-*.txt

Test plan

• Preference defaults off
• Fixed rolling cadences project; billing/non-projectable windows do not
• Past reset anchors retain the first future boundary while the primary line says “Resets now”
• Countdown and Date & time styles update primary + projected reset lines
• Menu and CLI live proof
• make check
• swift test --filter 'MenuCardUpcomingResetsTests|UsageFormatterTests' — 53 tests
• CI green

Maintainer decision still needed

Confirm this opt-in persistent Menu/CLI preference is desired product-wise.

@clawsweeper re-review

Made with Cursor

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 02e119dca4

ℹ️ 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".

[gmkbenjamin]

Addressed the P2 review note: upcoming reset projection is now gated to fixed rolling cadences only (1h / 4h / 5h / daily / weekly). Billing-cycle windows that populate windowMinutes (Cursor, Grok, Abacus, monthly plans) are skipped so the menu no longer fabricates Then … dates for those providers.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed July 28, 2026, 11:04 AM ET / 15:04 UTC.

ClawSweeper review

What this changes

Adds an off-by-default preference that displays estimated future reset times for supported rolling quotas in the menu and codexbar usage output.

Merge readiness

⚠️ Ready for maintainer review - 3 items remain

The implementation and submitted proof are credible, and the prior dashboard-test overlap appears removed from the rebuilt head. This remains open because it deliberately adds a persistent Menu/CLI feature and the repository owner explicitly requested product sign-off before selecting it for merge.

Priority: P2
Reviewed head: 518da0a08af62d7e6f7b3576b95502a90e3deeb2
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	The patch is focused, tested, localized, and supported by live menu and CLI evidence; the remaining blocker is product selection rather than implementation quality.
Proof confidence	🦞 diamond lobster (5/6) ✨ media proof bonus	Sufficient (screenshot): The PR body provides a packaged-app menu screenshot plus redacted CLI output showing the preference enabled in countdown and date/time modes and disabled with projected lines absent.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (screenshot): The PR body provides a packaged-app menu screenshot plus redacted CLI output showing the preference enabled in countdown and date/time modes and disabled with projected lines absent.
Evidence reviewed	6 items	Rolling-window projection is deliberately bounded: The formatter projects future dates only when a reset anchor and window duration are present and the duration is recognized as a fixed rolling cadence; the implementation excludes billing-cycle extrapolation and advances a past anchor to the first future boundary. Preference is opt-in and propagated to both surfaces: The new setting defaults to false when absent, is observed by the menu settings store, and is passed into menu-card rendering; the CLI separately reads the same persisted preference before appending projected reset lines. Regression coverage includes the owner-raised edge case: The branch adds focused coverage for default persistence, fixed and non-projectable cadences, display styles, and the past-anchor case where the primary line says “Resets now” while the first future boundary remains visible.
Findings	None	None.
Security	None	None.

How this fits together

CodexBar collects provider quota windows and formats their next-reset information for the menu-bar card and CLI usage view. This change derives additional future boundaries only for known fixed rolling windows, then renders them according to the user’s reset-time display preference.

flowchart LR
    A[Provider quota window] --> B[Reset formatter]
    B --> C{Fixed rolling cadence?}
    C -->|Yes| D[Projected reset boundaries]
    C -->|No| E[Current reset only]
    F[Menu preference] --> G[Menu and CLI renderers]
    D --> G
    E --> G
    G --> H[Menu card and usage output]

Loading

Decision needed

Question	Recommendation
Should CodexBar expose an off-by-default persistent setting that projects future reset times for fixed rolling quotas in both the menu and CLI?	Defer this feature for now: Keep the PR open without merging until a future product round selects projected reset schedules as a supported preference.

Why: The patch is mechanically bounded and tested, but whether projected quota timing is a desirable persistent product capability is a user-experience and scope decision that code review cannot determine.

Before merge

• Resolve merge risk (P1) - Merging introduces a persistent opt-in that presents estimated—not provider-authoritative—future reset schedules in both the menu and CLI; only the product owner can decide whether that expectation belongs in the default product surface.
• Complete next step (P2) - Await the owner’s product-direction choice; there is no narrow mechanical repair for automation to perform.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Review surface	45 files affected; 635 added, 37 removed	A small user preference crosses core formatting, menu rendering, CLI rendering, tests, screenshots, and localized catalogs, so owner scope approval matters before merge.
Validation matrix	9 reported successful check runs	The current head has successful lint, build, test, and security checks across supported CI targets.

Merge-risk options

Maintainer options:

1. Get explicit product approval before merge (recommended)
   Confirm that estimated future quota boundaries are an intended persistent Menu/CLI feature, then merge the existing opt-in implementation.
2. Defer the feature
   Leave this PR unmerged until projected reset schedules are selected for a future product round.

Technical review

Best possible solution:

Obtain explicit owner approval for the opt-in schedule concept, then merge the bounded fixed-cadence implementation while retaining the existing off-by-default behavior.

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

Not applicable: this PR proposes a new opt-in capability rather than reporting broken existing behavior. The supplied menu screenshot and CLI on/off outputs do provide credible after-change behavior evidence.

Is this the best way to solve the issue?

Unclear pending product direction: the fixed-cadence gate and off-by-default preference are a narrow implementation, but the owner must decide whether projected schedules should be a supported Menu/CLI feature at all.

AGENTS.md: found and applied where relevant.

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

Labels

Label justifications:

• P2: This is a bounded optional product enhancement with no demonstrated urgent regression, but it needs an owner decision before landing.
• merge-risk: 🚨 other: The feature persists an opt-in that adds estimated reset information to established menu and CLI output, so product acceptance—not ordinary CI—settles the remaining merge risk.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (screenshot): The PR body provides a packaged-app menu screenshot plus redacted CLI output showing the preference enabled in countdown and date/time modes and disabled with projected lines absent.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body provides a packaged-app menu screenshot plus redacted CLI output showing the preference enabled in countdown and date/time modes and disabled with projected lines absent.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. The PR body provides a packaged-app menu screenshot plus redacted CLI output showing the preference enabled in countdown and date/time modes and disabled with projected lines absent.

Evidence

What I checked:

• Rolling-window projection is deliberately bounded: The formatter projects future dates only when a reset anchor and window duration are present and the duration is recognized as a fixed rolling cadence; the implementation excludes billing-cycle extrapolation and advances a past anchor to the first future boundary. (Sources/CodexBarCore/UsageFormatter.swift:183, 518da0a08af6)
• Preference is opt-in and propagated to both surfaces: The new setting defaults to false when absent, is observed by the menu settings store, and is passed into menu-card rendering; the CLI separately reads the same persisted preference before appending projected reset lines. (Sources/CodexBar/SettingsStore.swift:442, 518da0a08af6)
• Regression coverage includes the owner-raised edge case: The branch adds focused coverage for default persistence, fixed and non-projectable cadences, display styles, and the past-anchor case where the primary line says “Resets now” while the first future boundary remains visible. (Tests/CodexBarTests/UsageFormatterTests.swift:281, 518da0a08af6)
• Prior overlap was addressed on the current review head: The prior review requested removal of duplicate dashboard test-isolation work. The current-head response states that the branch was rebuilt on main and dropped those edits; the owner’s earlier note identifies the now-landed replacement as the intended source for that separate repair. (518da0a08af6)
• Owner requested a product decision rather than a mechanical repair: The repository owner described the PR as well-built with green CI and live proof, but stated that a new persistent Menu/CLI feature needs Peter’s product sign-off and was not selected in that triage round.
• Current automated validation is green: The provided check set reports successful lint, Linux CLI builds, macOS test shards, and security scanning for the current pull-request head. (518da0a08af6)

Likely related people:

• steipete: The repository owner explicitly reviewed this feature, confirmed its implementation quality, and reserved merge selection for product sign-off. (role: product decision owner; confidence: high; files: Sources/CodexBar/PreferencesMenuPane.swift, Sources/CodexBarCore/UsageFormatter.swift)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Obtain explicit owner sign-off on the persistent projected-reset preference.

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 (7 earlier review cycles)

• reviewed 2026-07-27T11:29:26.759Z sha daa2745 :: needs real behavior proof before merge. :: none
• reviewed 2026-07-27T12:30:16.749Z sha 9b7ea47 :: found issues before merge. :: [P2] Localize the newly visible preference strings
• reviewed 2026-07-27T12:36:52.594Z sha 9b7ea47 :: found issues before merge. :: [P2] Translate the new labels in every supported catalog
• reviewed 2026-07-27T13:09:32.128Z sha b3dc6e8 :: found issues before merge. :: [P2] Translate the new labels in every supported catalog
• reviewed 2026-07-27T21:36:13.903Z sha 34691ce :: found issues before merge. :: [P2] Translate the new labels in every supported catalog
• reviewed 2026-07-27T23:08:02.622Z sha 76a54d6 :: needs maintainer review before merge. :: none
• reviewed 2026-07-28T10:56:11.090Z sha 512164b :: found issues before merge. :: [P2] Remove the duplicate dashboard test-isolation edits

[gmkbenjamin]

Addressed follow-ups on 9b7ea47f:

1. CI (Italian): translated show_upcoming_resets_*, Then %@, and related reset-times copy in it.lproj (was failing LocalizationLanguageCatalogTests).
2. P2 cadence gate: already landed earlier — only 1h / 4h / 5h / daily / weekly project.
3. Real behavior proof: menu screenshot + CLI off/on for both Reset times styles:
   • Menu (countdown on): https://raw.githubusercontent.com/gmkbenjamin/CodexBar/feature/upcoming-resets-schedule/docs/screenshots/upcoming-resets-claude-menu-2026-07-27.png
   • CLI countdown / absolute / off: docs/screenshots/upcoming-resets-cli-*.txt
4. CLI: showUpcomingResets + Reset times style now apply to codexbar usage text/cards.

linux-arm64 CLICardsClaudeSwapTests process-launch failure looks unrelated (NSCocoaErrorDomain 256 on fake executable); x64 Linux passed.

@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 repository_dispatch).
Result: when the review finishes, ClawSweeper will create the durable review comment if needed or update the existing comment in place.

Re-review progress:

• State: Review in progress
• Detail: The exact-review queue leased this run; Codex is reviewing the item.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/30266450412
• Updated: 2026-07-27T12:34:45.290Z

[gmkbenjamin]

Pushed an empty commit to retrigger CI. The macOS failure on the previous run was unrelated SpendDashboardTokenProvenanceTests (cost stayed nil after refresh wait) — not touched by this PR, and the suite passes locally. Italian localization already passed on 9b7ea47f.

[gmkbenjamin]

Root-caused the recurring macOS CI failure in SpendDashboardTokenProvenanceTests:

SpendDashboardClockRolloverTests called selectDays(7) on a controller backed by UserDefaults.standard, which persisted settingsSpendDashboardDays=7. Later provenance tests then built a 7-day window that excluded the fixed 2026-07-16 fixtures, so groups.first?.totalCost stayed nil.

Fix: isolate UserDefaults for clock-rollover and provenance controller construction (force 30-day window). Reproduced locally with a polluted global default; suite now passes with that pollution present.

[gmkbenjamin]

Addressed the remaining ClawSweeper before-merge localization blocker:

• Translated reset_times_subtitle, reset_times_clock (Date & time), show_upcoming_resets_title, show_upcoming_resets_subtitle, and Then %@ in all previously English-leftover catalogs (20 locales).
• Verified no English leftovers remain for those keys; LocalizationLanguageCatalogTests + make check pass locally.

Still needs maintainer product confirmation for the new opt-in Menu preference (ClawSweeper decision item). CI should be green on this head.

@clawsweeper re-review

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Command router queued. I will update this comment with the next step.

[steipete]

Triage note: this is well-built (green CI, live proof appreciated), but as a new persistent Menu/CLI feature it needs Peter's product sign-off, and it wasn't selected in this triage round. Two things to address while it waits: (1) when resetsAt is in the past, upcomingResetsLine drops the first future boundary while the primary line still says "Resets now" — the actual next reset disappears; a past-anchor regression test would pin this. (2) The test-isolation changes duplicating #2386 should drop out after a rebase (that PR just landed area repairs). Leaving open for owner review.