[DreamyTalesPAN]

For VibeTV-shop/vibetv#285 (step 1, "check whether the synthetic 0 % fallback shows invented values today"). Answer: yes, in many providers. This PR fixes the first batch; the rest is tracked in VibeTV-shop/vibetv#289.

Problem

When a provider response carries no usable quota (missing total or counter), these providers returned a successful 0 % window instead of an error: Windsurf, Chutes, Claude web, Codex, Cursor, Gemini, Copilot. Downstream (VibeTV) shows that as "0 % used". A real 0 / N reading is indistinguishable from the invented one, so there is no single central place to fix it; every parser had its own fallback.

Change (7 provider files, no new abstraction)

• Windsurf: no daily and no weekly quota -> ProviderError::Parse. Only weekly present -> daily is RateWindow::informational (unavailable), weekly kept.
• Chutes: no quota window in the payload -> ProviderError::Parse.
• Claude web: a usage window without utilization is treated as absent (same as a missing five_hour, which already became the informational "No active 5h session").
• Codex: a window needs used_percent; a body with no usage fields -> ProviderError::Parse.
• Cursor: no total percent and no positive limit -> ProviderError::Parse (removed the test that pinned the invented 0 %).
• Gemini: buckets without a usable remainingFraction -> ProviderError::Parse.
• Copilot: no usable quota -> ProviderError::Parse.

Every provider has a test that the missing-data case is an error / informational and a test that a real 0 % stays a success.

Evidence

• Red first: 8 missing-data tests failed on 7614e4d2 (6 real-zero controls passed).
• After: cargo test --lib 1829 passed, 4 failed. The same 4 fail on the untouched base 7614e4d2 (Windows path tests on macOS: pi_family_tests::config_dir_must_stay_within_home, pi_family_tests::windows_shims_and_paths_are_normalized_for_dialect, codex_sessions::tests::normalizes_codex_root_to_sessions_dir, core::hooks::tests::config_matching_respects_enabled_flag).
• cargo fmt --all --check clean. cargo clippy has no finding in the changed files (pre-existing cast_possible_truncation errors in tty_runner.rs, untouched).
• Windows binary built from this commit on macOS: DLL imports identical to v0.60.3-vibetv.13, no VCRUNTIME / api-ms-win-crt imports.
• VibeTV side: the new sentences classify as the generic "could not read usage" state in the Companion (test in the VibeTV PR).

Build recipe (as for .13)

brew install llvm lld; cargo install cargo-xwin --locked
rustup target add x86_64-pc-windows-msvc        # use the rustup toolchain's cargo first on PATH
cargo xwin build --manifest-path rust/Cargo.toml --release --bin codexbar --target x86_64-pc-windows-msvc
cp target/x86_64-pc-windows-msvc/release/codexbar.exe codexbar-cli.exe
zip CodexBarCLI-v0.60.3-vibetv.14-windows-x64.zip codexbar-cli.exe && shasum -a 256 <zip> > <zip>.sha256

.cargo/config.toml already sets +crt-static.

Request to @marcus7989

Please merge with a merge commit (as #9/#11/#12) and tag/release v0.60.3-vibetv.14 (pre-release) from the merge commit, as for .13. Release notes draft: "Windsurf, Chutes, Claude web, Codex, Cursor, Gemini and Copilot no longer report an invented successful 0 % when the response carries no usable quota (VibeTV nesszer#285). Not included yet: remaining providers (VibeTV nesszer#289)." VibeTV pins the release's zip SHA-256 afterwards (scripts/fetch-win-codexbar.ps1); the VibeTV pull request is a draft until the tag exists.

[marcus7989]

Review of head d28bf762:

1. P1 – Cursor: plan usage and overall/pooled usage default missing used to zero. For example, {"individualUsage":{"plan":{"limit":2000}}} succeeds with an invented 0%. Require an actual counter and usable denominator unless a percentage is supplied. Test missing used with limit/remaining, explicit zero, and nonzero usage.
2. P2 – Copilot: A response with only {"quota_snapshots":{"custom":{"percent_remaining":75,"quota_id":"custom"}}} contains a valid 25% extra quota, but the new primary check returns an error and loses it. Preserve the quota without inventing a primary zero; test extra-only, mixed quotas and token billing.
3. P2 – Dashboard output: The dashboard serializes an informational primary as 0% used and 100% remaining, without the informational flag. This pre-existing issue is now also reachable with Windsurf weekly-only responses. Test unavailable vs. genuine zero in the dashboard output and assess its consumers alongside VibeTV-shop/vibetv#289; the Companion handles raw windows separately.

Local macOS tests: 1829 passed, 4 failed, 1 ignored; the same four fail on the unchanged base. Three targeted probes reproduced the findings. The Windows x64 cross-build passed. A real Windows/Companion run remains outstanding on the final candidate.

[DreamyTalesPAN]

Wir übernehmen P1 (Cursor) und P2 (Copilot) auf diesem Branch, bitte nicht pushen. P3 (Dashboard-Ausgabe) behandeln wir im Paket VibeTV-shop/vibetv#289 und melden uns dort.

[DreamyTalesPAN]

fertig (53941bc), zurück an dich.

• P1 Cursor: erledigt. Ein Limit oder Rest ohne used-Zähler ergibt keine 0 % mehr (Plan, Overall, Pooled). used wird nur aus Limit minus Rest abgeleitet, und die Plan-Kostenzeile braucht echte Zähler. Rot zuerst (3 Tests), dann grün; explizite 0 und 0/N bleiben Erfolg.
• P2 Copilot: erledigt. Nur eine Zusatzquote bleibt erhalten (25 % im Beispiel) neben einer informational Hauptquote, keine erfundene 0 %; Mischfall und Token-Billing (bestehende Tests) bleiben grün. Ohne jede Quote weiter Fehler.
• P3 Dashboard: gehört in VibeTV-shop/vibetv#289; dort bewerten wir Dashboard-Ausgabe und Verbraucher, nicht in diesem PR.

Lokal: 1834 grün, die 4 bekannten Windows-Pfad-Tests fehlen wie auf der Basis.

[DreamyTalesPAN]

Joint Windows probe of #15–#17: PASS (details below; same text on all three PRs).

Build: local merge branch claude/probe-15-17 @ 8b8134d3 (#15 53941bcc + #16 cacb7c8d + #17 0c5def4d; clean merge, branch only, no PR). Built on a Windows runner like the release build (cargo build --release --bin codexbar, Rust 1.98.0, static CRT): codexbar 0.60.3, codexbar-cli.exe sha256 a7b3f8e95bee92f3e831159838365becb8366696e32987ba6c48350b25fe6ed8.
Windows unit tests (cargo test -p codexbar --lib, windows-latest): 2035 passed, 1 failed. The 4 path tests that fail on macOS pass on Windows. The one failure is codex_accounts::codex_desktop::tests::restart_uses_manifest_gui_and_leaves_standalone_cli_alone (it runs a PowerShell restart script on the runner); codex_accounts/ is identical to vibetv, so none of #15–#17 touches it. I did not re-run it on plain vibetv.
VibeTV app on real Windows (bench laptop, real VibeTV on the cable): CI installer 9999.0.357 (merge commit of VibeTV main 5c97812c), its codexbar-cli.exe replaced by the probe CLI after each install (sha verified).

• Cold (from delivery firmware 1.0.41): paired, firmware 1.0.50, Mini Classic active, renderOk: true, stream healthy.
• Warm (public 1.0.66 + 1.0.50, candidate installed over it): app 9999.0.357, still paired, theme kept, stream healthy, Updates tab "Up to date".
  Direct CLI comparison, .13 vs probe (real Claude Max login, settings copied, nothing written to the app's config):
• usage --provider claude without a session key: identical windows and numbers (probe adds usageKnown: true on the window); real values, no invented 0 %.
• Claude Auto: the Claude window's session key reads only claude.ai, a signed-in Claude Code does not win (VibeTV-shop/vibetv#273) #17: with an invented CLAUDE_AI_SESSION_KEY, .13 still answers from Claude Code (source: oauth, real numbers); the probe answers only {"error":"Authentication required","provider":"claude"}.
  Not covered: live provider answers that arrive without a usable quota (Report missing provider usage as unavailable instead of an invented 0% (VibeTV #285) #15/Remove the remaining invented 0 % / window values (VibeTV #289) #16) need accounts we do not have; that part rests on the fork's red-to-green unit tests (all pass on Windows). The same applies to the Kimi K2 and Doubao cases of the Remove the remaining invented 0 % / window values (VibeTV #289) #16 fix. The real claude.ai sign-in in the VibeTV window was not exercised, only the environment variable path. Fork CI (CircleCI) reported no status on the new Remove the remaining invented 0 % / window values (VibeTV #289) #16 head.

Ready for your merge, then tag .14 for #15 and .15 for #16 + #17?

[marcus7989]

W211 · Beelink Windows validation, 2026-10-29 · STOP (environment blocker)

The exact native Rust 1.98.0 baseline/probe comparison could not start: HOMESTATION-WIN has no cargo/rustc/rustup on PATH, no user .cargo/.rustup directory, and no matching Rust/MSVC/Git executables in the checked tools/program directories. No compiler/toolchain was installed during this slot. This is an unfulfilled test environment, not an observed product regression; no cargo test exit codes exist and the known restart-test result remains unresolved.

Task results: (1) baseline 7614e4d vs probe 8b8134d BLOCKED before execution; (2) isolated #15 / .14 build and VibeTV smoke NOT RUN; (3) automatic Windows Usage/Refresh NOT RUN after the explicit stop condition; (4) NO MERGES, NO TAGS, no release workflow triggered.

Final baseline check passed: app 9999.0.2266, runtime a9e985be9d1500de8455edc26d62c9a66b52bd4f, VibeTV 5804558, Clippy, brightness 20, automatic codex/claude/cursor. All app files and 13/13 configs match the pre-slot backup byte-for-byte; Firefox process IDs and existing Codex CLI auth-file hash are unchanged. No login, reboot or OS switch performed. Current PR heads remain #15 53941bc, #16 cacb7c8, #17 0c5def4.

Local evidence: .local/reports/wincb16/BEELINK-W211.md; w211/tools-result.json and w211/final-result.json. The next native run needs a prepared Rust 1.98.0/MSVC build environment, or a separately approved cross-build/native-execution plan; it must not be reported as already tested.