Port upstream 0.69.0: mark Kimi windows blocked by an exhausted monthly limit (stacked on #691)

[Finesssee]

Summary

When Kimi's monthly membership pool (kimi-monthly, "Total usage") is exhausted (remaining <= 0, reset in the future or unknown), the shorter windows (primary, secondary, kimi-code-7d; a window without minutes counts as the 5h lane) render as 100% used with "Blocked by monthly limit". Their reset, pace, reserve and session-forecast text is cleared; the pool row keeps the reset. Raw percentages in the snapshot and explicit menu-bar selections are unchanged. Unknown-usage, expired or available monthly pools never block.

Upstream reference

• Release 0.69.0 item fix(providers): clarify Kimi and z.ai quota availability steipete/CodexBar#4091 (RateWindow.bindingQuotaProjection, MenuCardView.blockingQuotaMetrics); audit entry kimi-blocking-monthly (PR 7).

Ported / Deferred

• Ported: core::BlockedWindows::evaluate (provider-declared blocker via ProviderId::blocking_quota_window_id, Kimi only), bridge field blockedByMonthlyLimit (Rust DTO + bridge.ts), MenuCard metric-row presentation, PanelBlockedByMonthlyLimit locale key (en-US).
• Not changed: tray icon, notifications and float bar read raw/explicitly selected metrics, so they intentionally keep the provider data (per spec). No projected-reset computation (blocker's own reset owns the text).

Validation

• cargo +1.98.0 fmt --all: clean
• cargo +1.98.0 clippy --workspace --all-targets -- -D warnings: pass
• cargo +1.98.0 test -p codexbar: 2236 passed, 0 failed, 1 ignored
• cargo +1.98.0 test -p codexbar-desktop-tauri: 488 passed, 0 failed
• vitest (full): 68 files / 409 tests passed; pnpm run build: ok; pnpm run lint: only pre-existing warnings in untouched files

Affected areas

Kimi provider windows, bridge DTO, tray card (MenuCard), locale catalog.

UI proof

Pending: coordinator will capture CUA proof on a fresh build.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Finesssee]

Thermo-nuclear review

Reviewed against upstream v0.69.0 steipete#4091 (RateWindow.bindingQuotaProjection, MenuCardView.blockingQuotaMetrics, KimiProviderDescriptor.blockingQuota) and AGENTS.md. Diff reviewed relative to the stacked base (#691's head).

Verdict: no blockers. Behavior matches the spec.

Spec parity (checked line by line):

• Blocker must be a known-usage kimi-monthly window that is longer than the candidate, has remaining <= 0, and has a reset in the future or unknown. is_blocked_by matches isActivelyExhausted plus the minutes > primaryMinutes filter, including the 5h default for a window with no minutes.
• Blocked rows read 100% used, with reset, pace, reserve and forecast cleared. The pool row keeps its reset. Raw percentages stay untouched in the snapshot, so tray, notifications and explicit menu-bar selections keep the provider data (per spec).
• Provider-declared blocker (ProviderId::blocking_quota_window_id) is the Rust equivalent of the descriptor's blockingQuota. No cross-provider string branching in shared paths. Other providers derive nothing (tested).
• Size: no file crosses 1000 lines (bridge.rs and provider.rs were already over and grew by about 15 and 9 lines; MenuCardDetails.tsx is 836).

Findings (fixed in the follow-up commit):

1. MetricRow gained three separate blocked conditionals (blocked label, !blocked && on the exhausted label, forecast). The two label branches were the same slot with two guards. Collapsed into one statusLabel value so there is a single place that decides what the status line says.
2. BlockedWindows tests never asserted the tertiary and model_specific flags as true, so those two arms of evaluate were untested. Added assertions.

Left as is (non-blocking):

• The DTO field blockedByMonthlyLimit and the PanelBlockedByMonthlyLimit string are Kimi-shaped names on a generic mechanism (blocking_quota_window_id). Upstream carries the message per provider policy. With one provider that is fine; the message should move into provider metadata when a second blocker lands. Renaming now would churn about ten files for no behavior change.
• toBlockedSnapshot also clears reserve fields that are already gated by isExhausted in getMetricPaceView. It is redundant but explicit, and cheap.
• The flag is computed when the snapshot is converted, so a monthly reset passing between refreshes unblocks on the next refresh rather than instantly. The provider's own 100% would be equally stale until then.

Local checks after the fixes: cargo +1.98.0 fmt --all clean, clippy -p codexbar --all-targets -D warnings pass, test -p codexbar blocking_quota 5 passed, vitest MenuCard.test.tsx 33 passed.

[Finesssee]

Follow-up to the thermo-nuclear review: pushed c220563 ("Address thermo review").

Fixed:

• MetricRow now derives one statusLabel (blocked text, else the exhausted label in the full card) instead of two guarded branches. No behavior change.
• Added tertiary and model_specific assertions to the BlockedWindows tests.

Left, with reasons: Kimi-shaped DTO/locale names on the generic mechanism (one provider today, rename would touch about ten files), redundant reserve clearing in toBlockedSnapshot (explicit and harmless), and fetch-time flag evaluation (matches when the provider data itself refreshes).

Checks: fmt clean, clippy -D warnings pass on codexbar, blocking_quota tests 5 passed, MenuCard.test.tsx 33 passed.

[Finesssee]

CUA proof

Build commit: c220563 (PR head) plus one uncommitted proof-only patch, not part of the PR: rust/src/logging.rs config_root() also honors CODEXBAR_PROOF_CONFIG_ROOT (isolated config, user settings untouched).

Data path: seeded via the existing CODEXBAR_SEED_USAGE_JSON proof support (bridge-shaped Kimi snapshot carrying blockedByMonthlyLimit). This proves the React rendering; the Rust derivation is covered by the unit tests (blocking_quota tests + bridge test).

Commands: bash launch.sh popOut blocked and bash launch.sh popOut available (prebuilt debug exe, no rebuild, empty provider homes, only Kimi enabled, theme auto); driven with cua-driver serve / call list_windows|get_window_state|click (select Kimi tab, capture UIA tree + screenshot).

Note: the "All" overview is compact (first two rows only), so the four-row checks were made on the Kimi tab of the pop-out; the tray panel overview showed the same Weekly / Rate limit rows with "Blocked by monthly limit".

Scenario A: monthly pool exhausted

#	Assertion	Result
1	Four rows: Weekly, Rate limit, Total usage, Code 7-day	PASS
2	Weekly, Rate limit, Code 7-day read "100% used", full bar, "Blocked by monthly limit"	PASS
3	Those rows show no reset text, no reserve / pace / "On-pace budget" lines; Weekly not "0% used"	PASS
4	Total usage "100% used", own reset "Resets in 19d 23h", shows "Exhausted", no blocked line	PASS
5	Exactly one reset text; "Blocked by monthly limit" exactly 3 times	PASS
6	No other-provider identity; theme stays dark under auto	PASS

Scenario B: control (monthly 50%)

#	Assertion	Result
1	Weekly 0% used with "Resets in 3d 23h", Rate limit 0% used with reset, Code 7-day 25%, Total usage 50%	PASS
2	"Blocked by monthly limit" absent	PASS

Screenshots (local, not committed), under C:\Users\FSOS\AppData\Local\Win-CodexBar\port-audit\proof\697\shots\:

• A-blocked-popout-kimi.png
• A-blocked-popout.png (overview)
• A-blocked-tray.png (tray panel)
• B-available-popout-kimi.png

No real personal data appears in any screenshot.

[Finesssee]

CUA proof (rerun)

Build commit: c220563 (PR head, "Address thermo review"). Rerun on a rebuilt debug exe with profile isolation: home, config, data and cache dirs all resolve under a proof-only directory, so no real account or settings from the machine are read.

Proof-only patch (uncommitted, reverted after the build, not part of the PR): root Cargo.toml [patch.crates-io] dirs = { path = ".../proof-shim/dirs" } redirecting dirs lookups to CODEXBAR_PROOF_HOME. No source file patched.

Data path: bridge-shaped Kimi snapshot via the existing CODEXBAR_SEED_USAGE_JSON proof support (Kimi monthly pool comes from a hardcoded https web host, so it is not mockable without weakening URL validation). This proves the React rendering of blockedByMonthlyLimit; the Rust derivation is covered by the PR's unit tests. No keyring or network access.

Commands: pnpm --dir apps/desktop-tauri run tauri:build:debug, then CODEXBAR_PROOF_MODE=popOut:provider:kimi launched with dummy keys and empty provider homes (scenario "blocked": Weekly 0%, Rate limit 0%, Code 7-day 25%, Total usage 100%; scenario "available": Total usage 50%). Window captured with cua-driver call get_window_state --screenshot-out-file (background only, window kept on a secondary monitor).

Scenario A: monthly pool exhausted

#	Assertion	Result
0	No real email/account from the machine visible	PASS
1	Four rows: Weekly, Rate limit, Total usage, Code 7-day	PASS
2	Weekly, Rate limit, Code 7-day read "100% used", full bar, "Blocked by monthly limit" (Weekly not "0% used")	PASS
3	Those rows show no reset text, no reserve / "On-pace budget" / forecast line	PASS
4	Total usage "100% used", own reset "Resets in 19d 23h", "Exhausted", no blocked line	PASS
5	Exactly one reset text; "Blocked by monthly limit" exactly 3 times	PASS
6	Dark theme under auto; no other-provider text	PASS

Scenario B: control (monthly 50%)

#	Assertion	Result
1	Weekly 0% used "Resets in 3d 23h", Rate limit 0% used "Resets in 59m", Code 7-day 25%, Total usage 50%	PASS
2	"Blocked by monthly limit" absent	PASS

Screenshots (local, not committed), in C:\Users\FSOS\AppData\Local\Win-CodexBar\port-audit\proof\697\shots\:

• n-A-blocked-kimi.png
• n-B-available-kimi.png

No personal data appears in either screenshot.