Add a Show pace setting to hide the usage pace stripe and forecast text

[urda]

Summary

CodexBar draws a green or red stripe inside every usage progress bar,
and a line of forecast text below it. The stripe marks expected usage
against actual usage. Both were unconditional, with no preference
anywhere to turn them off.

This adds one setting, Show pace, on by default. Turning it off
hides the stripe and the forecast text together.

Settings > Menu > Usage, directly below "Show quota warning markers".

What changed

• One gate. paceGatedMetrics runs inside
  UsageMenuCardView.Model.make, the single factory both
  UsageProgressBar call sites resolve through. It nulls pacePercent,
  detailLeftText, detailRightText, and sessionEquivalentDetail.
  It copies all 16 Metric fields, so quota and workday tick marks
  survive.
• The plain menu. MenuDescriptor renders pace from UsagePaceText
  directly rather than from the gated model, so its three pace entries
  are guarded separately.
• Sync. SyncedPreferences.paceVisible is an optional Bool with a
  nil default, matching the workdayTickAppearance precedent. A
  payload from an older build still decodes, and an absent key leaves
  the local value untouched. CodexBarSyncSchema.currentVersion is
  deliberately not bumped, since a bump trips needsAppUpdate and halts
  sync on older builds.
• Observation. The setting is registered in menuObservationToken,
  without which the stored value changes but an open menu does not
  redraw.
• Localization. Two new keys in all 23 catalogs.

Provider details are preserved (review fix)

Review flagged that detailLeftText and detailRightText are shared slots:
Kiro bonus credits and the Copilot/ZenMux reset description ride the same
fields as the pace forecast. An earlier revision of this PR cleared them
unconditionally, which hid provider data that is not pace output. That is
fixed.

PaceDetail, PrimaryMetricPresentation, and Metric now carry an
isPaceDerived marker. It defaults to false, and only the pace producer
functions opt in, so anything unrecognised is preserved rather than hidden.
The gate clears the detail slots only when they hold a pace forecast:

detailLeftText:  metric.detailIsPaceDerived ? nil : metric.detailLeftText,
detailRightText: metric.detailIsPaceDerived ? nil : metric.detailRightText,
pacePercent:     nil,   // always: unambiguously pace

The marker rides three types rather than two because the primary lane builds
its Metric from PrimaryMetricPresentation with no PaceDetail in scope; a
two-type version silently fails on the primary bar of every non-Codex provider.

Provider call sites are untouched, so this adds no provider-specific code.
Two regression tests cover it: Kiro bonus credits survive, and ZenMux with no
reset date keeps its reset description, which was the worst case raised.

Synthetic regen labels are treated as pace-derived and still hide, by choice.
Synthetic's "Regenerates in 2h 15m" countdown is unaffected either way, since it
lives in resetText, which the gate never touches.

Out of scope

These pace surfaces are each separately opt-in, so this setting does not
reach them: predictive pace notifications, which have their own
preference; the .pace menu bar layout token and the menu bar Pace
display mode, both configured by hand in their own editor; codexbar usage CLI output; and the Burn Down widget, which has an unrelated pace
concept.

Commands run

• make check - clean, 0 violations across 1945 files
• make test - full suite green, 0 timed-out groups
• swift test --filter PaceVisibility
• swift test --filter ProviderArchitectureGatekeeperTests

Tests

Ten tests in PaceVisibilityTests.swift and CloudSyncSettingsTests.swift,
covering the default-on path, the cleared path, the primary metric specifically
(it builds from PrimaryMetricPresentation rather than a PaceDetail, so it
takes a different code path), the interaction with Hide personal information,
survival of quota warning markers, decoding a sync payload that predates the
key, and the two provider-preservation regressions described above.

PaceVisibilityScreenshotRenderTests.swift renders the before/after images
below. It is env-gated and skipped by default, matching the existing screenshot
render tests.

Screenshots

OFF:

ON:

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: da9e427e84

ℹ️ About Codex in GitHub

Codex has been enabled to automatically 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 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed August 18, 2026, 7:33 PM ET / 23:33 UTC.

ClawSweeper review

What this changes

The PR adds a default-on Show pace setting that hides pace stripes and forecast text in usage cards and plain menus while preserving unrelated provider details.

Merge readiness

⚠️ Ready for maintainer review - 2 items remain

The patch appears correct and resolves the earlier provider-detail regression; it remains open only for maintainer product sign-off because it adds a new synchronized preference.

Priority: P3
Reviewed head: 47f182be0a736540136d553b98d337199c6179c1
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	Direct UI proof and focused regression coverage support a clean patch; only maintainer product approval remains.
Proof confidence	🐚 platinum hermit (4/6) ✨ media proof bonus	Sufficient (screenshot): Before/after screenshots in the PR body directly demonstrate the setting hiding the visual pace stripe and forecast text.
Patch quality	🦞 diamond lobster (5/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (screenshot): Before/after screenshots in the PR body directly demonstrate the setting hiding the visual pace stripe and forecast text.
Evidence reviewed	7 items	Pace rendering gate: The card-model factory removes only pace-derived detail labels, pace stripes, and the session-equivalent forecast when the preference is disabled; quota and workday markers are preserved. Provider-detail regression coverage: Focused tests verify that hiding pace retains Kiro bonus-credit text and ZenMux reset descriptions, addressing the earlier P1 review finding. Sync compatibility: The optional synced field is applied only when present, and the compatibility test keeps a local value unchanged for legacy payloads without the key.
Findings	None	None.
Security	None	None.

Live Verification

Command: swift test --filter PaceVisibilityTests

Result: FAIL (failed) — execution before step 1 run: sh -lc pnpm install --ignore-scripts --frozen-lockfile failed: ! Corepack is about to download https://registry.npmjs.org/pnpm/-/pnpm-11.22.0.tgz

sh -lc pnpm install --ignore-scripts --frozen-lockfile failed: ! Corepack is about to download https://registry.npmjs.org/pnpm/-/pnpm-11.22.0.tgz

Assertions:

• FAIL expect_output: Test run with

How this fits together

CodexBar converts provider usage snapshots into menu-card metrics and plain-menu entries. The new preference is persisted, observed for menu refreshes, synchronized between devices, and applied before those renderers produce their output.

flowchart LR
A[Provider usage snapshots] --> B[Usage metric builder]
C[Show pace preference] --> B
C --> D[Plain menu renderer]
B --> E[Usage cards]
D --> F[Menu entries]
C --> G[Cloud preference sync]

Loading

Decision needed

Question	Recommendation
Should Show pace ship as a global preference that synchronizes its display choice across updated CodexBar devices?	Approve synchronized Show pace: Accept the default-on setting and its existing preference-sync behavior as the product contract.

Why: The implementation follows existing settings and sync patterns, but VISION.md requires sign-off for new features and only maintainers can choose the product scope of a synchronized display setting.

Before merge

• Resolve merge risk (P1) - This preference intentionally synchronizes between updated devices, so maintainers should explicitly accept that a choice made on one device changes the presentation on another.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Localized setting	2 strings added in 23 catalogs	The new settings row is available across the repository's complete localization set.
Focused coverage	3 test files expanded, 389 test lines added	The change covers visibility, legacy sync decoding, and the provider-detail regression path.

Merge-risk options

Maintainer options:

1. Decide the mitigation before merge
   If approved, keep the default-on, backward-compatible synced preference and its narrow pace-only rendering gate.
2. Pause or close
   Do not merge this PR until maintainers decide whether the risk is worth taking.

Technical review

Best possible solution:

If approved, keep the default-on, backward-compatible synced preference and its narrow pace-only rendering gate.

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

Not applicable: this PR adds a display preference rather than fixing a reported failing behavior; direct before/after screenshots show the intended result.

Is this the best way to solve the issue?

Unclear pending product sign-off: the technical approach is narrow and preserves provider-owned details, but maintainers must choose whether the setting should synchronize across devices.

AGENTS.md: found and applied where relevant.

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

Labels

Label changes:

• remove merge-risk: 🚨 compatibility: Current PR review selected no merge-risk labels.

Label justifications:

• P3: This is an optional presentation preference with limited blast radius and no demonstrated current-user regression.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🦞 diamond lobster.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (screenshot): Before/after screenshots in the PR body directly demonstrate the setting hiding the visual pace stripe and forecast text.
• proof: sufficient: Contributor real behavior proof is sufficient. Before/after screenshots in the PR body directly demonstrate the setting hiding the visual pace stripe and forecast text.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. Before/after screenshots in the PR body directly demonstrate the setting hiding the visual pace stripe and forecast text.

Evidence

What I checked:

• Pace rendering gate: The card-model factory removes only pace-derived detail labels, pace stripes, and the session-equivalent forecast when the preference is disabled; quota and workday markers are preserved. (Sources/CodexBar/MenuCardView+ModelHelpers.swift:240, 47f182be0a73)
• Provider-detail regression coverage: Focused tests verify that hiding pace retains Kiro bonus-credit text and ZenMux reset descriptions, addressing the earlier P1 review finding. (Tests/CodexBarTests/PaceVisibilityTests.swift:117, 47f182be0a73)
• Sync compatibility: The optional synced field is applied only when present, and the compatibility test keeps a local value unchanged for legacy payloads without the key. (Sources/CodexBar/SettingsStore+Sync.swift:93, 47f182be0a73)
• Open-menu refresh: The preference participates in the settings observation token, whose observer rebuilds menus after settings changes. (Sources/CodexBar/SettingsStore+MenuObservation.swift:25, 47f182be0a73)
• Revision provenance: Blame attributes the current pace-gating implementation to the reviewed head commit. (Sources/CodexBar/MenuCardView+ModelHelpers.swift:240, 47f182be0a73)
• Product-signoff policy: VISION.md places new features in the Needs Sign-Off category. (VISION.md:15, 47f182be0a73)

Likely related people:

• steipete: The target repository is steipete/codexbar, and this new-feature decision is explicitly reserved for sign-off by VISION.md. (role: repository owner and likely product decision owner; confidence: medium; files: VISION.md, Sources/CodexBar/PreferencesMenuPane.swift, Sources/CodexBar/SettingsStore+Sync.swift)

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
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.

Workflow

• 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.

History

Review history (4 earlier review cycles)

• reviewed 2026-08-18T20:18:27.438Z sha 51cdb8a :: found issues before merge. :: [P1] Preserve non-pace details when hiding pace
• reviewed 2026-08-18T22:05:26.734Z sha c9a6dbc :: needs maintainer review before merge. :: none
• reviewed 2026-08-18T22:36:10.142Z sha ad6df3a :: needs maintainer review before merge. :: none
• reviewed 2026-08-18T23:18:12.545Z sha 4bbe066 :: needs maintainer review before merge. :: none

[urda]

The P1 finding is fixed in 665d967e.

PaceDetail, PrimaryMetricPresentation, and Metric now carry an
isPaceDerived marker. It defaults to false and only the pace producer
functions opt in, so unrecognised text is preserved rather than hidden. The gate
clears detailLeftText and detailRightText only when they hold a pace
forecast; pacePercent is still cleared unconditionally because it is
unambiguously pace.

Three types rather than two: the primary lane builds its Metric from
PrimaryMetricPresentation with no PaceDetail in scope, so a two-type version
silently fails on the primary bar of every non-Codex provider.

Provider call sites are untouched, so no provider-specific code was added. Two
regression tests cover the preservation: Kiro bonus credits survive, and ZenMux
with resetsAt == nil keeps its reset description, which was the worst case in
your finding.

One correction: Copilot is not actually affected. Its detail slot is overwritten
by resetWindowPaceDetail downstream, so it carries pace text regardless of this
setting. ZenMux without a reset date is the real case.

Your live verification failed on an unrelated sandbox issue (a corepack/pnpm
download error), so the screenshot render test never ran. It is env-gated and
skipped by default:
CODEXBAR_PACE_SCREENSHOT_DIR=/tmp/proof swift test --filter PaceVisibilityScreenshotRenderTests

The PR description has been updated to describe the new behavior.

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event exact_review_queue).
Result: when the review finishes, ClawSweeper will create the durable review comment if needed or update the existing comment in place.