Feature request: configurable workday tick appearance for weekly quota bars

[grango0]

Problem

The weekly progress bar can show workday boundaries (Automatic / 4 / 5 / 7 days), but their visual style is fixed in the app. On macOS dark mode the current markers are very subtle: they are one physical pixel wide, half the bar height, and rendered at low opacity.

That makes the useful daily pacing reference difficult to see at a glance, especially when the bar is filled with a bright provider color.

Requested improvement

Please add a Menu settings control for Workday tick appearance, ideally with:

• Visibility toggle
• Contrast: subtle / normal / high
• Optional color: automatic / neutral / white
• Optional thickness or full-height marker mode

The existing day-count picker should continue to control the number of boundaries; this request is only about visibility and visual accessibility.

Why it matters

For weekly Codex limits, these markers are an effective way to compare current consumption with the daily-average budget. A high-contrast option would make that pacing signal usable without requiring custom builds.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 13, 2026, 6:44 AM ET / 10:44 UTC.

Summary
Keep open for product sign-off: current main intentionally renders workday boundaries as subtle ticks, and the request adds new persisted UI/configuration surface rather than repairing broken behavior.

Reproducibility: not applicable. this is a request for additional appearance controls, and current source confirms the existing subtle-tick design.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Maintainer decision needed

Question	Recommendation
Should CodexBar add a persisted workday-tick appearance preference, and if so should it be limited to a small contrast/visibility choice rather than separate color, thickness, and height controls?	Add a narrow contrast choice: Keep the current default and offer one high-contrast alternative, avoiding a multi-control styling subsystem.

Why: The reported rendering matches the current intentional design, while the requested solution creates new preference surface whose scope is not determined by an existing contract.

Next step
A maintainer must choose whether the accessibility benefit warrants a new persisted preference and its supported control scope.

Review details

Best possible solution:

Preserve the subtle default and, if sponsored, add one narrow persisted appearance choice such as Subtle or High contrast, with focused rendering and settings-persistence coverage.

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

Not applicable: this is a request for additional appearance controls, and current source confirms the existing subtle-tick design.

Is this the best way to solve the issue?

Unclear pending product direction; a single high-contrast alternative is the narrowest maintainable path if the preference is accepted.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Multiple independent color, thickness, height, and visibility controls would expand persistent settings and visual compatibility beyond the demonstrated accessibility need.

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

Label changes

Label changes:

• add P3: This is a low-risk visual-accessibility enhancement, not a broken quota calculation or blocking flow.
• add impact:ux-friction: The fixed low-contrast ticks make a useful pacing cue harder to see without preventing quota tracking.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P3: This is a low-risk visual-accessibility enhancement, not a broken quota calculation or blocking flow.
• impact:ux-friction: The fixed low-contrast ticks make a useful pacing cue harder to see without preventing quota tracking.

Evidence reviewed

What I checked:

• Current rendering is intentionally subtle: Current main draws each workday boundary at one physical pixel, half bar height, and 30% primary-color opacity (55% while highlighted), matching the visibility concern but offering no appearance setting. (Sources/CodexBar/UsageProgressBar.swift:291, d14c3242d88e)
• Existing preference only controls day count: The Menu preferences pane exposes the Work days picker alongside a separate quota-warning-marker toggle; neither controls workday-tick appearance. (Sources/CodexBar/PreferencesMenuPane.swift:20, d14c3242d88e)
• Feature history: History identifies the workday-segmentation introduction as “Display: add workday segmentation for weekly progress bars” and the current source blame attributes the rendering block to the current history boundary. (Sources/CodexBar/UsageProgressBar.swift:291, e9b7e25f851b)
• Vision fit requires sign-off: VISION.md welcomes small UI/UX tweaks but explicitly lists new features and meaningful maintenance complexity under “Needs Sign-Off”; a new persisted appearance preference needs that choice. (VISION.md:8, d14c3242d88e)

Likely related people:

• Yuxin-Qiao: The feature-history commit for weekly progress-bar workday segmentation is attributed to Yuxin Qiao. (role: introduced workday segmentation; confidence: high; commits: e9b7e25f851b; files: Sources/CodexBar/UsageProgressBar.swift, Sources/CodexBar/MenuCardQuotaWarningMarkers.swift)
• steipete: Current-history blame for the workday tick geometry and color block attributes the source boundary to Peter Steinberger, and repository policy identifies this as the target owner. (role: recent area contributor; confidence: medium; commits: fc57a317cee4; files: Sources/CodexBar/UsageProgressBar.swift, Sources/CodexBar/PreferencesMenuPane.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.