Fix usage pace risk label consistency

[kiranmagic7]

Summary

• avoid rendering Lasts until reset together with a nonzero rounded run out risk
• keep the risk label visible when historical pace marks the quota as lasting but still reports material risk
• add regression coverage for the reported 45% risk state

Refs #1544

Tests

• swift test --filter UsagePaceTextTests
• make check

Notes

This intentionally does not change Codex historical pace authority or work day fallback behavior. It only removes the contradictory text state while maintainers decide the larger pacing semantics.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed June 15, 2026, 4:00 PM ET / 20:00 UTC.

Summary
The PR makes UsagePaceText show only the run-out risk when a pace also says it will last to reset with a nonzero rounded risk, and adds a regression test for the 45% state.

Reproducibility: yes. at source level. On current main, UsagePaceText.detailRightLabel builds Lasts until reset from willLastToReset and then appends a risk label whenever runOutProbability exists, so a pace with willLastToReset == true and runOutProbability == 0.45 reproduces the contradiction.

Review metrics: 1 noteworthy metric.

• Changed surface: 1 production file, 1 test file; 21 additions, 0 deletions. The branch is a narrow formatter/test change, so maintainers can focus review on text semantics and regression coverage.

Merge readiness
Overall: 🦪 silver shellfish
Proof: 🧂 unranked krab
Patch quality: 🐚 platinum hermit
Result: blocked until real behavior proof 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 redacted real behavior proof, such as terminal output from exercising UsagePaceText.weeklyDetail or a screenshot/recording showing the after-fix weekly label for the 45% risk state.

Proof guidance:

• [P1] Needs real behavior proof before merge: The PR body lists test commands but does not include after-fix app output, terminal output, screenshot, recording, or logs showing the changed label, so external real behavior proof is still needed before merge. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Risk before merge

• [P1] The PR body lists test commands but does not include after-fix app output, terminal output, screenshot, or other real behavior proof for the changed label path.
• [P1] The broader weekly pacing issue at Weekly reserve / run-out risk inverted in v0.35.0 with work-days OFF — a clear deficit is shown as surplus (Codex Pro 20x) #1544 remains open; merging this PR should only be considered a label-consistency fix, not a decision on historical pace authority or work-days-off semantics.

Maintainer options:

1. Decide the mitigation before merge
   Land the narrow label-consistency fix after proof and CI are satisfactory, while keeping the broader weekly historical-versus-linear pacing decision tracked in Weekly reserve / run-out risk inverted in v0.35.0 with work-days OFF — a clear deficit is shown as surplus (Codex Pro 20x) #1544.
2. Pause or close
   Do not merge this PR until maintainers decide whether the risk is worth taking.

Next step before merge

• [P1] No automated repair is needed; the remaining gate is contributor real-behavior proof plus normal maintainer and CI review.

Security
Cleared: The diff only changes Swift formatter logic and an XCTest; no dependency, CI, secrets, auth, or supply-chain surface changes were found.

Review details

Best possible solution:

Land the narrow label-consistency fix after proof and CI are satisfactory, while keeping the broader weekly historical-versus-linear pacing decision tracked in #1544.

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

Yes, at source level. On current main, UsagePaceText.detailRightLabel builds Lasts until reset from willLastToReset and then appends a risk label whenever runOutProbability exists, so a pace with willLastToReset == true and runOutProbability == 0.45 reproduces the contradiction.

Is this the best way to solve the issue?

Yes for the narrow PR. It avoids changing historical pace authority or work-day fallback behavior, adds focused coverage, and leaves the larger pacing semantics to the linked issue.

AGENTS.md: found and applied where relevant.

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

Label changes

Label changes:

• add P2: This is a user-visible quota pace text bug with limited blast radius to CodexBar weekly pace presentation.
• add rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🧂 unranked krab and patch quality is 🐚 platinum hermit.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body lists test commands but does not include after-fix app output, terminal output, screenshot, recording, or logs showing the changed label, so external real behavior proof is still needed before merge. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Label justifications:

• P2: This is a user-visible quota pace text bug with limited blast radius to CodexBar weekly pace presentation.
• rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🧂 unranked krab 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: The PR body lists test commands but does not include after-fix app output, terminal output, screenshot, recording, or logs showing the changed label, so external real behavior proof is still needed before merge. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Evidence reviewed

What I checked:

• Repository policy read: AGENTS.md was present and fully read; its focused SwiftPM test guidance applies to this formatter/test PR. (AGENTS.md:18, 3286934b8be3)
• Current main can render the contradictory label: Current main builds Lasts until reset from willLastToReset, then appends ≈ %d%% run-out risk whenever runOutProbability exists, which permits the reported mixed state. (Sources/CodexBar/UsagePaceText.swift:60, 3286934b8be3)
• PR diff targets only the text contradiction: The branch adds a guard returning the risk label alone when willLastToReset is true and the rounded risk is nonzero, plus a focused XCTest for runOutProbability: 0.45. (Sources/CodexBar/UsagePaceText.swift:60, 99752f704e8a)
• Historical pace can supply both fields: The historical evaluator keeps a nonnil run-out probability after enough samples and sets willLastToReset when the smoothed probability is below 0.5, so a 45% risk can reach the text layer with willLastToReset == true. (Sources/CodexBar/HistoricalUsagePace.swift:858, 9490a8d5590d)
• Menu model uses this formatter: The weekly menu card model calls UsagePaceText.weeklyDetail, so this formatter change affects the user-visible menu-card text from the linked report. (Sources/CodexBar/MenuCardView+ModelHelpers.swift:277, 3286934b8be3)
• Linked broader issue remains open: The related weekly pacing issue is still open and already notes that historical pace authority versus work-days-off linear semantics needs maintainer follow-up; this PR intentionally handles only label consistency.

Likely related people:

• steipete: Peter Steinberger authored the current-main formatter and historical-risk lines in commit 9490a8d..., and also authored recent work-day pace commits touching the same weekly pace path. (role: recent area contributor; confidence: high; commits: 9490a8d5590d, 2f92ee97e46e, 1a60cb5ac26e; files: Sources/CodexBar/UsagePaceText.swift, Sources/CodexBar/HistoricalUsagePace.swift, Sources/CodexBarCore/UsagePace.swift)
• Remedy92: Remedy92 authored the original weekly pace indicator commit that introduced UsagePaceText, UsagePace, and the first related tests. (role: introduced weekly pace model; confidence: medium; commits: a679311227fc; files: Sources/CodexBar/UsagePaceText.swift, Sources/CodexBarCore/UsagePace.swift, Tests/CodexBarTests/UsagePaceTextTests.swift)
• Tristan Manchester: Tristan Manchester authored historical pace and backfill hardening in the evaluator/store area that can provide the mixed willLastToReset and risk fields. (role: adjacent historical pace contributor; confidence: medium; commits: a2973265477e; files: Sources/CodexBar/HistoricalUsagePace.swift, Sources/CodexBar/UsageStore+HistoricalPace.swift, Tests/CodexBarTests/HistoricalUsagePaceTests.swift)
• pstanton237: pstanton237 authored workday-aware pace calculation commits that are adjacent to the linked issue’s suspected weekly pacing semantics, though this PR only changes label formatting. (role: adjacent work-day pace contributor; confidence: medium; commits: 6980ceaa58b8, 23b96662c343, dc41a444f3b9; files: Sources/CodexBarCore/UsagePace.swift, Tests/CodexBarTests/UsagePaceTests.swift)

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.