feat(capacity): show OpenAI usage from pi's OpenAI login

[codeaholicguy]

Summary

ai-devkit capacity now shows pi · OpenAI rows — beside pi · z.ai — whenever the user has logged in to OpenAI via pi, with zero manual setup and no platform API key. Previously the default report warned openai capacity unavailable: OpenAI API key not found because the provider only understood OPENAI_API_KEY / a pi openai platform-key credential, and could never see pi's OAuth login (the openai-codex entry in ~/.pi/agent/auth.json).

Live report on a machine with only the pi OpenAI login (redacted):

Harness  Provider  Status  Quota             Usage                  Resets
codex    OpenAI    OK      Session           ░░░░░░░░░░ 0%          in 5h
codex    OpenAI    OK      Weekly            ░░░░░░░░░░ 0%          Oct 4
pi       z.ai      OK      Tokens · 5 hours  █████░░░░░ 42%         in 2h 26m
pi       z.ai      OK      MCP · monthly     ░░░░░░░░░░ 0% · 0/100  Oct 25
pi       OpenAI    OK      Session           ░░░░░░░░░░ 0%          in 5h      ← new
pi       OpenAI    OK      Weekly            ░░░░░░░░░░ 0%          Oct 4      ← new

Design rationale (full docs in docs/ai/*/2026-09-27-feature-openai-pi-login-capacity.md)

• Resolution order — OPENAI_API_KEY env → pi openai {type:"api_key"} → pi openai-codex OAuth → sanitized not-found error (message now mentions the pi login path). Platform-key users keep a byte-identical report; OAuth only fills the no-setup gap.
• OAuth usage source — same endpoint the codex harness uses: read-only GET https://chatgpt.com/backend-api/wham/usage with Authorization: Bearer + ChatGPT-Account-Id. Verified live with the real pi token (HTTP 200; window/credits shape confirmed) during design; tests use fixtures only.
• No refresh, no dedupe — stale tokens (epoch-ms expires, or JWT exp fallback; seconds vs ms handled by magnitude) are never refreshed and never fetched: they render authenticated-but-stale (available: "unknown"), matching codex.ts policy. pi · OpenAI and codex · OpenAI rows may coexist — the harness column exists for exactly this.
• Parser extraction — wham/usage parsing moved to a new shared pure module capacity/wham.ts, now that a second real caller exists. codex.ts delegates and keeps its parseUsage/toRateWindow exports; codex.test.ts passes unchanged.
• Token hygiene — fixtures use fake tokens; no-leak assertions on reports/errors; branch audited by script against the real stored token values (clean).

Validation

• Scoped: vitest run src/__tests__/capacity/ (agent-manager) → 70 tests passed (16 pre-existing platform tests untouched and green; codex.test.ts/zai.test.ts untouched).
• Coverage: openai.ts and wham.ts at 100% lines; remaining uncovered branches are only the never-network default-injection arms (?? globalThis.fetch, ?? 5000) — same as codex.ts/zai.ts.
• Root gates (fresh, on final HEAD): npm run lint exit 0 · npm test exit 0 · npm run test:e2e exit 0 (42 tests). Husky pre-commit green on every commit.
• Manual: default + capacity openai --json on this machine; scripted check confirms no access/refresh/accountId values in output.

Risks & follow-ups

• Live creditsRemaining renders null when the account's credits.balance is non-numeric (tolerated by parser).
• Follow-up (both harnesses, out of scope): wham's top-level rate_limit_reached_type could drive available: "no" for API responses.
• Branch name uses feature/… per worktree brief convention instead of the repo's feature-… lint expectation (documented deviation; lint --feature docs checks pass).

🤖 Generated with Claude Code