Skip to content

feat(quota-plane): adapter — Command Code via CLI/app credential #1165

Closed

Description

@dezren39

Priority P1 — order 5d. Horizon: Month. Design: quota-plane-design-2026-10-26.md (usage-billing-hub goal files), Stage 2. Parent context: epic #1047. (§2) — on the framework + gatherer from this epic.

Command Code adapter: CLI/app credential -> usage state ($ used of 0 credits, window %) without a dashboard visit. The CLI route is verified working on the sandbox (resident ACP); check whether its status surface carries quota before reaching for the dashboard API.
Acceptance: Command Code current on the tick from a machine route.

Acceptance criteria

Activity

  1. developing-today commented on Oct 27, 2026

    @developing-today
    Contributor
  2. dezren39 commented on Oct 27, 2026

    @dezren39
    MemberAuthor

    RE-SCOPE (2026-10-26, per Drew + git archaeology): the Command Code quota provider existed and was dropped upstream (openchamber 1b1a95ff6) because the OFFICIAL API has no usage endpoints — its source was the unofficial studio API. Our fleet's route is documented in the quota module's own DOCUMENTATION.md: resolve account scope via GET /alpha/whoami, then GET /alpha/billing/credits?orgId=... (personal accounts: org null, no orgId) for credit balances + 5h/weekly limits, authed by the command-code OpenCode auth entry (OAuth access) or COMMAND_CODE_API_KEY.
    Work: (1) recover the dropped provider from openchamber history (279f248a0, providers/command-code.js + tests) into our fork as a restoration — do not redesign from scratch; (2) verify the /alpha endpoints against our live credential; (3) if the studio API has drifted, adapt parsing fail-closed; (4) wire into the gatherer path like the other providers. Drew used Command Code this week; its $10-credit state is currently read by hand.

  3. dezren39 commented on Oct 27, 2026

    @dezren39
    MemberAuthor

    Restoration status (2026-10-26):

    • The dropped provider is recovered verbatim from openchamber history (279f248a0 / pre-drop state at 1b1a95ff6^) on branch feat/restore-command-code-quota, then adapted to the current quota module: injected readOpenCodeCredentials (the old readAuthFile no longer exists), registry aliases, and per-credential fetching via the registry's fetchWithCredentialRead, matching ClinePass/DeepInfra. Parse logic and the /alpha/whoami → /alpha/billing/credits flow are the recovered code unchanged. PR: feat(quota): restore the Command Code usage provider openchamber#528 (not merged — merge stays with Drew).
    • Live verification (2026-10-26, repeated 2026-10-27 from the laptop per the laptop-only execution rule): GET /alpha/whoami → 200, org: null (personal account). GET /alpha/billing/credits → 200 with exactly the documented shape — credits{monthlyCredits, purchasedCredits, freeCredits}, windowLimits{fiveHour, weekly}{used, cap, resetAt} — no drift the parser can't handle; extra fields are ignored. Current reading: monthly credits 3.15, purchased 0, free 0; 5h window 0.0134 / 3 used (reset 2026-10-27 ~02:45 CDT); weekly 0.808 / 6 used (reset ~2026-10-31).
    • Full wired path proven on the laptop: the laptop's OpenCode server store holds an active commandcode key (30 rows), and openchamber quota command-code --json from the restored branch returns ok: true, configured: true with the live windows.
    • Tests (all on the laptop): provider + registry 25 passed; full quota suite 498 passed (37 files); bun run check:changed passed with no new anti-slop findings. (A sandbox gate attempt failed only on that worktree's incomplete dependency install; the laptop run supersedes it.)
    • One precise remaining gap, environment rather than code: the SANDBOX server's credential store (23 rows) has no command-code credential — its key lives only in legacy auth.json there. So the sandbox CLI reports "Not configured" until that credential is seeded into the sandbox server store. The laptop, the fleet's real server, already has it and works end to end.
  4. dezren39 commented on Oct 27, 2026

    @dezren39
    MemberAuthor

    MERGED 2026-10-27: openchamber PR #528 (Command Code quota provider restoration) merged after full CI green (build/tests/gate/lint/type-check) + laptop live verification. The restored provider is on openchamber main; fleet rollout follows the normal build/deploy path. Remaining from this issue: gatherer wiring of the command-code provider (rides #1151's provider coverage).

  5. added
    kind/featureNew feature or capability request
    priority/highImportant and time-sensitive
    effort/mMedium: expected under 1 day of work
    source/humanFiled directly by a human
    meta/enrichedIntake review done: acceptance criteria, links, and normalized labels added
    on Oct 28, 2026
  6. dezren39 commented on Oct 28, 2026

    @dezren39
    MemberAuthor

    Intake review

    • Related: epic epic(usage-hub): SaaS/cloud services completion — v2 live collectors, daily console reads, v3 reconciliation #1047 (quota plane; this is Stage 2, order 5d in its sequence); design quota-plane-design-2026-10-26.md in the usage-billing-hub goal files (§2); sibling adapters in the same epic are the pattern to match.
    • Still live: a merged-PR search for a Command Code quota adapter found no resolving PR; the issue carried only meta/follow-up before this pass.
    • Notes: the body states "Priority P1" in prose — normalized here to priority/high. Its Acceptance line has been expanded into the appended ## Acceptance criteria section (original body preserved verbatim above it).
    • Risks: credential route is the unknown — the body notes the CLI route is verified working on the sandbox (resident ACP), but whether its status surface carries quota is exactly what must be checked before designing around a dashboard API.
    • Suggested approach: probe the CLI status surface first (one tick), then build the adapter on the epic(usage-hub): SaaS/cloud services completion — v2 live collectors, daily console reads, v3 reconciliation #1047 framework + gatherer like the sibling Stage 2 adapters.
    • Labels normalized by fleet monitor: kind/feature, priority/high (P1 in body), effort/m, source/human, status/needs-triage, meta/enriched.
  7. added
    mode/onlineFully doable remotely: design, config, code, cloud
    work/assignedQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    and removed on Nov 1, 2026
  8. dezren39 commented on Nov 2, 2026

    @dezren39
    MemberAuthor

    agent-note:v1
    state: picked_up
    task_id: 2449
    worker: repo-worker-code
    lane: aea12c82-c5af-4e5a-9b66-f8e360f87177
    at: 2026-11-02T22:44:12Z
    summary: Claimed triage; validating Command Code adapter and quota-gatherer completion on current main.

  9. dezren39 commented on Nov 2, 2026

    @dezren39
    MemberAuthor

    agent-note:v1
    state: done
    task_id: 2449
    worker: repo-worker-code
    lane: aea12c82-c5af-4e5a-9b66-f8e360f87177
    at: 2026-11-02T22:46:00Z
    outcome: already_done
    summary: Closing as satisfied; the Command Code quota adapter and its gatherer-to-/quota path are implemented and merged, so no follow-up task remains.
    evidence: OpenChamber main contains packages/web/server/lib/quota/providers/command-code.js (merged PR #528); code main scripts/gather-quota.ts enumerates configured providers and fetches each provider via the OpenChamber module (PR #1309); src/sources/live.ts overlays quota-current into /quota (PR #1329); Command Code latest-read parsing fix #3413 is merged. Current main commits: code f2c6259; OpenChamber 3194bcffc13dc1f965d6e296243757401ce3af4a.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

effort/mMedium: expected under 1 day of workkind/featureNew feature or capability requestmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedmeta/follow-upFollow-up spun out of earlier workmode/onlineFully doable remotely: design, config, code, cloudpriority/highImportant and time-sensitivesource/humanFiled directly by a humanstatus:done

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions