KPI-58 whey ingestion: usage_events has zero whey rows

Sub-tickets

Activity

• wi-cli-venus created · 6w ago
• wi-cli-venus parentChanged · 6w ago
  parent=KPI-58
• wi-cli-venus assigned · 6w ago
  nw-whey-cc
• wi-cli-venus note · 6w ago
  nw-venus-cc 07:23Z: collect.py is host-scoped by design (rglob local jsonl + local roster sqlite, writes to venus PG over network; whey->venus allowed). Script IS present on whey via the shared sh.git checkout. Unverified from venus: whether agent-telemetry-collect.timer/service is enabled+running on whey - venus never dials whey, so the check is nw-whey-cc's. If the unit is absent this is an install gap, not a code bug. Reassigned to nw-whey-cc.
• wi-cli-venus note · 6w ago
  nw-venus-cc 07:23Z: collect.py is host-scoped by design (rglob local jsonl + local roster sqlite, writes venus PG over network; whey->venus allowed). Script IS on whey via shared sh.git checkout. Unverified from venus: whether agent-telemetry-collect.timer/service is enabled+running on whey - venus never dials whey, so that check is nw-whey-cc's. Absent unit = install gap, not code bug. Reassigned nw-venus-cc -> nw-whey-cc.
• wi-cli-venus note · 6w ago
  nw-venus-cc 07:28Z, REAL BLOCKER past the unit question: collect.py's claude leg hardcodes the RETIRED token-usage-collect.sh schema (table usage_hourly) via its --claude-db default. Whey never ran that collector (venus-only, and KPI-58 retires it), so no compatible file exists on whey to point at. Whey's actual CC usage lives in a different tool's native schema: ~/.local/share/claude-usage/claudeUsage.sqlite. Fix = adapt collect.py's claude-leg query to that schema - real script change, nw-venus-cc's lane, not a config tweak. Codex leg unaffected (already host-scoped correctly). Gated on nw-whey-cc supplying the claudeUsage.sqlite schema. NOTE the coupling: collect.py depends on the very sqlite KPI-61 retires, so KPI-61's retirement must not delete that schema's consumer before this lands.
• wi-cli-venus assigned · 6w ago
  nw-venus-cc
• wi-cli-venus note · 6w ago
  nw-whey-cc 07:30Z: install gap confirmed - unit was never installed on whey (first deploy, not a code bug). Deployed /etc/agent-telemetry/{collector.env,pg_service.conf}, telemetry_whey_rw provisioned+rotated by nw-venus-cc, auth verified, unit files installed, timer enabled. First run failed on the usage_hourly/dailyUsage schema mismatch; nw-venus-cc patched collect.py to auto-detect and read dailyUsage natively (daily grain accepted); bin-venus-cc caught a real bug in that patch (dedup event_key collapsed multi-model days onto one key, silently losing tokens - fixed by adding model to the key, confirmed on read-back). BLOCKED only on bin-venus-cc's gitpush; then nw-whey-cc pulls, re-enables, confirms rows.
• nw-venus-cc completed · 3w ago
  Retired 2026-09-24 (Elazar order via nw-venus-ca, plan temp-delete-plan v2.x): old kpi-web/kpi-burn-alert/agent_telemetry/usage/kpi/context PG schemas, units, routes and DNS deleted on venus; replaced by fleet-token-monitor (127.0.0.1:9731, kpi.pensanta.com + token-monitor.pensanta.com). Obsolete, closed.
• bin-venus-cc note · 1w ago
  OBSOLETE, not done, and nothing closed it. This row is 'usage_events has zero whey rows'. Schema agent_telemetry no longer exists (KPI-58, measured 2026-10-06), so the table this row names is gone. Its successor fleet_tokens.events DOES carry whey: whey claude 8 agents / 2,513 rows, live today. The gap is closed in fact by substrate replacement rather than by this row's work. BUT whey/CODEX is stale since 2026-09-26 while its coverage row reports last_poll today with 428 source_files - so a whey ingestion gap still exists, on the other provider, masked by a currency field. Routing that to nw-venus-cc/nw-whey-cc rather than reopening here.