feat: use configured work days for weekly pace - #1451
Conversation
|
Codex review: needs maintainer review before merge. Reviewed June 13, 2026, 3:26 PM ET / 19:26 UTC. Summary Reproducibility: not applicable. as a feature/product-semantics PR. The current-main source clearly uses linear weekly fallback pace, and the PR proof/tests exercise the new workday-aware behavior. Review metrics: 2 noteworthy metrics.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Land the unified work-day pace behavior with the accepted compatibility tradeoff; if maintainers reconsider upgrade semantics later, split pace calculation behind a distinct opt-in setting with migration coverage. Do we have a high-confidence way to reproduce the issue? Not applicable as a feature/product-semantics PR. The current-main source clearly uses linear weekly fallback pace, and the PR proof/tests exercise the new workday-aware behavior. Is this the best way to solve the issue? Yes for the accepted product direction: the patch reuses the existing setting consistently, preserves historical Codex pace authority, and adds focused math/menu/localization coverage. The safer alternative would be a separate opt-in pace setting if maintainers no longer want persisted marker preferences to affect ETA on upgrade. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against ca948292c164. Label changesLabel justifications:
Evidence reviewedWhat I checked:
Likely related people:
What the crustacean ranks mean
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
Bot
added
the
rating: 🌊 off-meta tidepool
795bfac to
22903e3
Compare
|
Rebased onto current Autoreview caught and this head fixes one edge case: a fully depleted quota after the final configured workday now remains exhausted instead of reporting that it lasts through the weekend. Proof:
Fresh CI is running. Keeping this draft/unmerged for product review of the workday pacing semantics. |
22903e3 to
c994ca7
Compare
|
Rebased onto current Exact head: Proof:
Fresh CI is running. Keeping this draft and unmerged for the existing product decision on changing the semantics of the persisted work-day setting. |
b695eb5 to
999b083
Compare
clawsweeper
Bot
added
rating: 🦐 gold shrimp
|
Prepared on exact head Proof:
Not merging autonomously: interpreting configured work days as quota-consumption pace changes user-facing product semantics. |
999b083 to
19a120a
Compare
|
Prepared on exact head Proof:
Keeping this draft and unmerged. The remaining question is product/upgrade semantics: whether the existing persisted work-day display preference should also control quota pace and ETA. |
19a120a to
3e83eb4
Compare
|
Rebased onto current Exact head: Proof:
Fresh CI is running. Keeping this draft and unmerged for the existing product/upgrade decision: whether the persisted work-day display preference should also control quota pace and ETA. |
|
Exact candidate: Maintainer decision: accept unified semantics. Existing persisted work-day values intentionally control both weekly markers and fallback pace/ETA. The PR body, localized UI copy, changelog, focused regressions, and built-app proof now state and cover that behavior. @codex review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
The existing weeklyProgressWorkDays setting only affected visual markers on the progress bar. This change threads the work-days value into UsagePace.weekly() so that the expected usage curve distributes 100% across configured work days only. Non-work days contribute zero expected usage, producing a flat curve on weekends. Users who work Mon-Fri and consume 100% by Friday now see "on pace" instead of a misleading ~29% deficit from the 7-day linear model. Fixes #1356
Address Codex bot review feedback: when the weekly reset time is not at midnight, the previous 24-hour-slice approach could misclassify hours near day boundaries. Now uses calendar.startOfDay to split intervals at local midnight, ensuring each slice is classified by its actual calendar weekday regardless of reset time offset.
Align the valid workDays range (>= 2) with the UI picker (Off/4/5/7) and marker path (2...7) to prevent inconsistent behavior from stale or manual values.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 166dc07327
ℹ️ 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".
clawsweeper
Bot
added
rating: 🐚 platinum hermit
166dc07 to
1527044
Compare
|
Exact candidate: Maintainer decision: accept unified semantics. Existing persisted work-day values intentionally control both weekly markers and fallback pace/ETA. The PR body, localized UI copy, changelog, focused regressions, and built-app proof now state and cover that behavior. @codex review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
Codex Review: Didn't find any major issues. Bravo. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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". |
clawsweeper
Bot
added
rating: 🦐 gold shrimp
|
Exact candidate: The depleted pre-first-workday menu finding is fixed and covered by a focused visible menu-model regression. Exact-head focused/full tests, lint, build, package/signature, built-app settings persistence, autoreview, and the Public Model Identifier Gate all pass. @codex review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
Codex Review: Didn't find any major issues. Nice work! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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". |
clawsweeper
Bot
added
proof: sufficient
|
Decision-ready on exact head
Recommendation: land. Tradeoff: existing persisted 4-day or 5-day marker values now intentionally control fallback weekly pace and ETA, as documented. |
|
Landed as Verification on the exact merged head:
Verification images were not applicable beyond the built-app settings proof already attached in the PR discussion. |
2 participants
Summary
weeklyProgressWorkDaysvalue for both weekly markers and fallback pace/ETA; this unified behavior is intentionalSupersedes #1357 because repository CI would not start for the fork head. Preserves @pstanton237's commits and authorship.
Fixes #1356.
Validation
1a60cb5ac26e81153ad00eb12487fc7ac0b13041Pacific/Auckland: 65 tests across 3 suites passed3,753 + 76 + 132test executions)make check: SwiftFormat clean; SwiftLint 0 violations across 1,077 Swift filesswift build6628e502ada679532bb18a14626f138e035d0732198bfc1234225faca882f1e5Runs out now