Add Grok weekly usage projections

[Zihao-Qi]

Summary

• Enable the existing reset-window pace projection for Grok weekly quota windows.
• Classify reset-based Grok windows using the menu model deterministic timestamp.
• Cover CLI and web weekly windows, plus monthly and unclassified negative cases.

Why

Grok was excluded from the generic reset-window pace support used by other providers. Web-derived Grok windows also relied on the wall clock during label classification instead of the model input timestamp, which prevented deterministic weekly classification in the menu model.

The shared UsagePace.weekly helper remains responsible for validating reset timing and window duration.

User impact

Weekly Grok usage rows with a valid weekly reset now show the existing deficit/reserve text, projected run-out estimate, and pace marker. Monthly and unclassified windows remain unchanged.

Validation

• swift test --filter GrokMenuCardModelTests — 4 tests passed
• swift test --skip-build --filter Grok — 48 tests passed
• make check — SwiftFormat and SwiftLint passed
• git diff --check — passed
• Full sharded suite — discovered 643 selections; stopped after an unrelated CLIOpenAIDashboardCacheTests group reported 3 cache-restoration failures
• swift test --skip-build --filter CLIOpenAIDashboardCacheTests — all 10 tests passed in isolation

Screenshots

Not included. The behavior is covered through the stable menu model seam without running a live Grok provider probe.

Fixes #2165

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1bd3dbe404

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

[chatgpt-codex-connector]

Handle >7-day Grok web resets before enabling pace

When a Grok web window has no windowMinutes and its reset is 8–12 days away, this predicate returns true because GrokProviderDescriptor.primaryLabel classifies that reset distance as Weekly. But resetWindowPaceDetail then calls UsagePace.weekly with defaultWindowMinutes: 10080, and that helper returns nil whenever timeUntilReset exceeds the 7-day duration, so these newly supported weekly rows still show no deficit/run-out text or pace marker. Either infer a duration that covers the reset distance or avoid marking those windows as pace-supported.

Useful? React with 👍 / 👎.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed July 16, 2026, 4:32 PM ET / 20:32 UTC.

Summary
The PR enables deterministic weekly pace projections for Grok reset windows and adds four menu-model tests covering CLI, web, excessive-duration, and non-weekly cases.

Reproducibility: not applicable. as a bug reproduction: the linked issue requests a new Grok display capability, and the focused tests deterministically describe the desired output.

Review metrics: 2 noteworthy metrics.

• Patch surface: 2 files changed. The implementation is confined to one existing menu-model helper and one focused test file.
• Behavior coverage: 4 cases added. The tests cover both supported Grok input shapes and the two main exclusion paths.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #2165
Summary: This PR is the candidate implementation for the linked request to show Grok projection text and a pace marker.

Members:

• canonical: Add Projections to Grok Tracker #2165 - The issue requests the same Grok deficit or reserve text and progress-bar pace marker implemented by this PR.
• adjacent_distinct: Stabilize shell cleanup timeout test #2178 - That merged PR addressed an unrelated flaky cleanup test observed during this PR's validation and does not overlap the Grok behavior.

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

Merge readiness
Overall: 🦪 silver shellfish
Proof: 🦪 silver shellfish
Patch quality: 🐚 platinum hermit
Result: blocked until real behavior proof from a real setup is added.

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

Rank-up moves:

• [P1] Add a redacted screenshot or recording from a freshly built bundle showing the Grok weekly deficit or reserve text, projected run-out, and pace marker; redact account details or other private information.

Proof guidance:

• [P1] Needs real behavior proof before merge: Only deterministic model tests and checks are provided; add a redacted screenshot or short recording from a freshly built bundle showing the after-fix Grok weekly pace display, then update the PR body to trigger review or ask a maintainer to comment @clawsweeper re-review.

Risk before merge

• [P1] No after-fix evidence yet confirms that a real Grok weekly row renders the deficit or reserve text, projected run-out, and pace marker correctly in the packaged app.

Maintainer options:

1. Decide the mitigation before merge
   Land the narrow shared-helper implementation after a freshly built CodexBar bundle visibly demonstrates the intended Grok weekly projection while monthly and unclassified rows remain unchanged.
2. Pause or close
   Do not merge this PR until maintainers decide whether the risk is worth taking.

Next step before merge

• [P1] Real-app proof is a contributor-specific human merge gate, and no remaining mechanical code defect supports an automated repair PR.

Security
Cleared: The focused Swift model-and-test diff adds no dependency, secret, workflow, downloaded-code, or supply-chain surface.

Review details

Best possible solution:

Land the narrow shared-helper implementation after a freshly built CodexBar bundle visibly demonstrates the intended Grok weekly projection while monthly and unclassified rows remain unchanged.

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

Not applicable as a bug reproduction: the linked issue requests a new Grok display capability, and the focused tests deterministically describe the desired output.

Is this the best way to solve the issue?

Yes, subject to runtime proof: reusing the existing weekly pace helper through the stable menu-model seam is narrower and more maintainable than adding Grok-specific projection logic.

AGENTS.md: found and applied where relevant.

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

Label changes

Label changes:

• add rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🐚 platinum hermit.
• remove rating: 🧂 unranked krab: Current PR rating is rating: 🦪 silver shellfish, so this older rating label is no longer current.

Label justifications:

• P3: This is low-risk provider UI parity that improves projection ergonomics without affecting core availability or stored state.
• rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🐚 platinum hermit.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: Only deterministic model tests and checks are provided; add a redacted screenshot or short recording from a freshly built bundle showing the after-fix Grok weekly pace display, then update the PR body to trigger review or ask a maintainer to comment @clawsweeper re-review.

Evidence reviewed

What I checked:

• Current-main behavior: The base implementation limits reset-window pace support to Copilot and Cursor, so the linked Grok projection request remains necessary on current main. (Sources/CodexBar/MenuCardView+ModelHelpers.swift:528, 65e2ae6a6363)
• Proposed implementation: The PR passes the model timestamp into Grok window classification and admits only valid weekly Grok windows to the existing shared pace calculation. (Sources/CodexBar/MenuCardView+ModelHelpers.swift:286, 1f1455e6b5f2)
• Focused coverage: Four deterministic model tests cover weekly CLI and web projections plus excessive-duration and monthly negative cases. (Tests/CodexBarTests/GrokMenuCardModelTests.swift:7, 1f1455e6b5f2)
• Prior finding resolved: Commit bd7bf69 added the duration guard requested by the earlier review; the latest commit also preserves the pre-existing Copilot predicate. (Sources/CodexBar/MenuCardView+ModelHelpers.swift:536, 1f1455e6b5f2)
• Proof gap: The PR body explicitly provides no screenshot, recording, or live Grok-provider run; tests, lint, and CI are supplemental rather than real behavior proof. (1f1455e6b5f2)
• Repository validation policy: AGENTS.md prefers stable model seams for menu tests but requires UI/runtime behavior to be checked against a freshly built bundle. (AGENTS.md:25, 65e2ae6a6363)

Likely related people:

• steipete: Recently merged current main into the branch and authored the latest predicate-preservation fix in the central menu-model helper. (role: recent area contributor and merger; confidence: high; commits: 698a0768b623, 1f1455e6b5f2; files: Sources/CodexBar/MenuCardView+ModelHelpers.swift)
• taibaran: Introduced the repository's Grok provider support, making them relevant to the provider's usage-window semantics and expected presentation. (role: feature introducer; confidence: medium; commits: 03480281251a; files: Sources/CodexBarCore/Providers/Grok, Sources/CodexBar)

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.

Review history (7 earlier review cycles)

• reviewed 2026-07-15T05:23:14.026Z sha 548a1be :: needs real behavior proof before merge. :: none
• reviewed 2026-07-15T06:38:26.560Z sha 548a1be :: needs real behavior proof before merge. :: none
• reviewed 2026-07-15T07:50:07.802Z sha 548a1be :: needs real behavior proof before merge. :: none
• reviewed 2026-07-15T09:02:26.278Z sha 548a1be :: needs real behavior proof before merge. :: none
• reviewed 2026-07-15T10:18:24.735Z sha 548a1be :: needs real behavior proof before merge. :: none
• reviewed 2026-07-16T02:14:12.365Z sha 548a1be :: needs real behavior proof before merge. :: [P2] Align Grok pace eligibility with the seven-day calculation
• reviewed 2026-07-16T14:08:30.924Z sha bd7bf69 :: needs real behavior proof before merge. :: none

[steipete]

Verified, repaired after main integration, and merged.

• Reviewed the complete two-file contributor diff for scope, correctness, and suspicious content; no unexpected network, credential, dependency, or unrelated changes.
• Integrated current main with merge commit 698a076. The automatic helper merge preserved both Copilot and Grok cases plus the input.now classification path, but omitted an explicit Copilot return. Autoreview caught the compile regression; commit 1f1455e restored it before push.
• swift test --filter GrokMenuCardModelTests: 5/5 passed on the contributor head and 5/5 after integration/fix.
• swift test --filter CopilotMenuCardModelTests: 4/4 passed after integration/fix, proving the adjacent Copilot path survived.
• make check: passed; SwiftFormat reported 0 files, SwiftLint reported 0 violations in 1466 files, and repository/script/docs/localization checks passed.
• git diff --check: passed.
• Final full-branch autoreview: clean, no accepted/actionable findings; overall correctness 0.91.
• Exact-head CI on 1f1455e: all 8 checks passed, including macOS shards (26m4s and 39m6s), Linux arm64/x64, lint, GitGuardian, changes, and lint-build-test.
• GitHub reported MERGEABLE/CLEAN immediately before merge.

Merge commit: e63b188