Repository navigation
aggregator: finish quota throughput data + record the design contract (#851) #3933
Description
Context
Follow-up from #851 and tracker hygiene task #1183. Slice 1 shipped the quota panel in PR #892, but its implementation issue #890 explicitly deferred throughput burn segments and token-rate history to slice 2. On current main, QuotaView has historical BurnSegment and QuotaPool has active-session/model/token and burnTokensPerMin fields, but scripts/collect-fleet-feed.ts emits burn: [] and does not populate live burnTokensPerMin; those fields are only present in fixtures. The root project-management design record also does not yet record the quota data contract, per-source refresh cadence, and wall-detection rule required by #851.
Existing related work remains distinct: #1172 tracks uninstrumented-provider coverage, #1174 tracks quota actions on /today and /attention, and #1184 is the coherence epic. This issue carries the remaining #851 throughput/design-record gap; it does not replace those follow-ups.
Acceptance criteria
- Update the project-management stack design record with the joined quota/throughput model, refresh cadence by source, and per-pool wall/near-limit rules; link this issue from the record.
- Live quota data attributes active sessions and cumulative tokens by provider/pool/model, and reports measured recent token rate where its source supports it (no fabricated estimates).
- Historical burn segments are populated from observed usage across reset windows when the source data supports them; empty/missing history is represented honestly.
/api/quota.jsonand/quotaexpose the same live data, including model-choice/headroom guidance; the OpenChamber quota picker remains the source for values it already exposes.- Targeted tests cover live mapping, reset-boundary history, and honest missing-data behavior.
Activity
developing-today commentedon Nov 3, 2026
agent-note:v1
state: triaged (coverage pass)
Coverage pass 2026-11-03: reviewed in the fleet-wide per-issue pass (drift / overlap / already-handled / stale / blockers / ordering). Verdict: still live; queued in repo-health-code-pilot as triage at priority 40 (priority/normal). If this is already handled at current main, the triage closes it with evidence; if it needs splitting, the triage files the split.
Found via: coverage pass 2026-11-03
dezren39 commentedon Nov 3, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 3, 2026
agent-note:v1
state: picked-up
queue: repo-health-code-pilot
task: 8320 (triage, worker repo-worker-code, lane 262eb403-3347-4a7c-ba6b-e7bc263ca853)
by: openchamber-scheduled-lane
at: 2026-11-03T21:54:47Z
Claimed for current-main triage. Fresh issue view confirms #3933 is OPEN and assigned to Drew; no open PR was returned by the exact #3933 search. I will verify the current-main gap and existing ownership before routing; this triage will not modify implementation files or any Drew-owned PR.
dezren39 commentedon Nov 3, 2026
agent-note:v1
state: triaged
queue: repo-health-code-pilot
task: 8320 (triage, worker repo-worker-code, lane 262eb403-3347-4a7c-ba6b-e7bc263ca853)
by: openchamber-scheduled-lane
at: 2026-11-03T22:00:09Z
Triage verdict: still live on current main
e41dabde5pm-stack/aggregator/scripts/collect-fleet-feed.ts:642populates active-session/token attribution for pools, but does not setburnTokensPerMin; line 911 emitsburn: []unconditionally.src/model.ts:252,313-345already defines measured pool burn rate and historicalBurnSegment/QuotaViewfields.README.md:730-735still describes per-source live readers as slice 2, confirming this is an unfinished implementation slice rather than a stale request.The existing #3933 acceptance already scopes the implementation (data/refresh and wall rules, measured live rate/history where supported, same API/UI data, tests). No split or duplicate follow-up is needed; keep this issue as the implementation vehicle and preserve its current assignee. No technical blocker was found, and no implementation files or PRs were touched.