feat: factor weeklyProgressWorkDays into pace calculation

[pstanton237]

Summary

The existing weeklyProgressWorkDays setting (added in #1096 / PR #1102) segments the weekly progress bar visually, but does not affect the pace calculation itself. Users who work only on weekdays (e.g. 5 days/week) see misleading pace indicators throughout the week:

Day (5-day user)	7-day linear expected	Actual usage	Pace verdict
Wednesday	42.9%	60%	17% deficit
Friday	71.4%	100%	29% deficit
Saturday	85.7%	100%	14% deficit

A user consuming 100% by Friday is using their quota exactly as planned across 5 work days, yet the current model reports a large deficit all week.

Proposed behavior

When weeklyProgressWorkDays is set (e.g. 5), the pace expected curve should distribute 100% across only the configured work days rather than uniformly across 7 calendar days:

Day (5-day model)	Expected	Actual	Verdict
Wednesday	60%	60%	on pace
Friday	100%	100%	on pace
Saturday	100%	100%	on pace

On non-work days, the expected curve should remain flat (no additional expected usage).

Implementation notes

UsagePace.weekly() currently computes:

let expected = ((elapsed / duration) * 100).clamped(to: 0...100)

This could be replaced with a workday-aware calculation when workDays is provided, distributing expected usage only across work-day hours within the window.

The weeklyProgressWorkDays value is already available in settings — it just needs to be threaded into the pace calculation path.

Context

Follow-up to #1096 which added visual segmentation. This completes the feature by making the pace indicator workday-aware.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 13, 2026, 5:11 PM ET / 21:11 UTC.

Summary
Keep open. Current main still uses linear weekly pace, and the requested work is now owned by an open clean PR with closing syntax, so this issue should remain open until that PR lands or maintainers choose a different semantics path.

Reproducibility: yes. Source inspection shows current main computes weekly expected usage with elapsed wall-clock time and does not pass weeklyProgressWorkDays into fallback pace, while the setting currently reaches marker rendering only.

Next step
No new fix lane is needed because the issue is already paired with a clean open implementation PR that should be reviewed, landed, revised, or closed by maintainers.

Review details

Best possible solution:

Review and land #1451 if maintainers accept the unified setting semantics; otherwise revise that PR to split pace into a separate opt-in setting before closing this issue.

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

Yes. Source inspection shows current main computes weekly expected usage with elapsed wall-clock time and does not pass weeklyProgressWorkDays into fallback pace, while the setting currently reaches marker rendering only.

Is this the best way to solve the issue?

Yes. The open canonical PR is the best current path because it reuses the existing setting, preserves historical Codex pace authority, adds focused regressions, and carries maintainer-visible proof; the issue should close only after that PR merges.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The linked PR intentionally changes fallback pace and ETA for users who already saved 4- or 5-day work-day marker preferences, so the issue should remain paired with that maintainer-reviewed upgrade decision.
• Current main and the latest release still have the linear behavior; closing this issue before the open PR merges would lose the canonical tracker.

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

Label changes

Label changes:

• remove clawsweeper:needs-maintainer-review: Current issue advisory state no longer selects this label.

Label justifications:

• P3: This is a low-urgency product-semantics improvement to weekly quota pacing rather than an outage or urgent provider regression.
• impact:other: The issue affects how CodexBar communicates weekly quota pacing for users with non-seven-day work weeks.

Evidence reviewed

What I checked:

• Current pace calculation is still linear: UsagePace.weekly on current main computes expected usage from elapsed wall-clock duration over the full window, with no work-day parameter. (Sources/CodexBarCore/UsagePace.swift:54, 8e7df44eb002)
• Settings value is not threaded into fallback pace on main: UsageStore.weeklyPace calls UsagePace.weekly for Codex fallback and generic provider pace without reading weeklyProgressWorkDays. (Sources/CodexBar/UsageStore+HistoricalPace.swift:25, 8e7df44eb002)
• Existing work-day setting is marker-only on main: workDayMarkerPercents only returns weekly progress marker percentages for standard weekly windows; it does not alter pace math. (Sources/CodexBar/MenuCardQuotaWarningMarkers.swift:73, 8e7df44eb002)
• Current tests encode seven-day expected pace: UsagePaceTests expects about 42.857% after three elapsed days in a seven-day window, matching the reported linear model. (Tests/CodexBarTests/UsagePaceTests.swift:19, 8e7df44eb002)
• Canonical open PR owns the implementation: GitHub reports feat: use configured work days for weekly pace #1451 is open, mergeable/clean, references this issue with closing syntax, and its body states the intended work-day-aware pace behavior and validation. (1a60cb5ac26e)
• PR head implements the requested pace threading: The PR head adds optional workDays handling to UsagePace.weekly and reads settings.weeklyProgressWorkDays in UsageStore.weeklyPace for fallback weekly pace. (Sources/CodexBarCore/UsagePace.swift:40, 1a60cb5ac26e)

Likely related people:

• Peter Steinberger: Current-main blame points central pace/store code at the latest release commit, and the open owner-hosted PR accepts the unified work-day pace semantics. (role: recent area contributor and product-decision owner; confidence: high; commits: 7717813b9eed, 1a60cb5ac26e; files: Sources/CodexBarCore/UsagePace.swift, Sources/CodexBar/UsageStore+HistoricalPace.swift, Tests/CodexBarTests/MenuCardWorkdayPaceTests.swift)
• Yuxin Qiao: Commit e9b7e25f added weeklyProgressWorkDays, display preferences, marker rendering, and tests that this issue asks to extend into pace behavior. (role: introduced work-day marker setting; confidence: high; commits: e9b7e25f851b; files: Sources/CodexBar/MenuCardQuotaWarningMarkers.swift, Sources/CodexBar/SettingsStore+Defaults.swift, Sources/CodexBar/StatusItemController+MenuCardModel.swift)
• Remedy92: Commit a679311 added UsagePace.weekly and the original weekly pace indicator surface that current main still uses for fallback pace. (role: introduced weekly pace model; confidence: medium; commits: a679311227fc; files: Sources/CodexBarCore/UsagePace.swift, Sources/CodexBar/UsagePaceText.swift)
• pstanton237: The maintainer-hosted PR history preserves this contributor's commits for workday-aware pace semantics and related tests before owner follow-up fixes. (role: proposed implementation contributor; confidence: medium; commits: 6980ceaa58b8, 23b96662c343, dc41a444f3b9; files: Sources/CodexBarCore/UsagePace.swift, Tests/CodexBarTests/UsagePaceTests.swift)

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.

[TheAngryPit]

Thanks for the detailed analysis. I’m going to take a small pass at this and open a narrow PR rather than trying to solve the broader pacing model.

Proposed scope:

• keep the current default behavior unchanged
• apply weeklyProgressWorkDays only to standard weekly linear pace windows
• treat the configured work days as the active part of the weekly reset window, then keep the expected curve flat for the remaining days
• leave Codex historical pace unchanged when historical data is available; this would only affect the generic/fallback weekly pace path
• add focused tests around UsagePace and the menu/historical fallback behavior

If that semantic shape is off, I can adjust the PR once there’s maintainer feedback.

[pstanton237]

Thanks for looking into this! PR #1357 covers the same scope if useful as a starting point.

[TheAngryPit]

Thanks for the pointer — I reviewed PR #1357 and agree that is the right base rather than opening a duplicate PR.

I left a note there with one small consistency edge case I noticed, and offered to send a tiny patch/diff if useful.

I will keep following that PR from there.