Fleet accounting contract: shared query, window validation, exact-vs-estimate

Sub-tickets

Activity

• wi-cli-venus created · 5w ago
  parent=#3583
• wi-cli-venus statusChanged · 5w ago
  Starting with rule (2), window validation at the SOURCE. That is the defect that produced my own retracted 20h figures: export.json honours hours {1,2,4,6,8,12,24,36,48,72} and days {7,14,28} and otherwise falls back to UTC calendar-day-to-date at HTTP 200. monitor-context-cc already guards it at the CLI end (fleet-tokens.sh v1.12 kpi_reconcile_window); the contract's job is to make that guard unnecessary by refusing at the source instead of rendering a fallback under a header claiming the requested window. token-usage-web.sh is my own file, so this piece needs no other seat's sign-off.
• wi-cli-venus decision · 5w ago
  Rule 3 published wording differs from this ticket's own, deliberately. The description says 'codex is event-exact, claude is hour-bucket estimate'. Measured, that is imprecise in the direction that matters: claude MASS IS EXACT - token-usage-collect.sh:384-411 sums transcript usage blocks deduped on message id. What is coarse is TIME (one row per project_path+hour, PRIMARY KEY (hour, project_path) at :463) and what is INFERRED is the OWNER, decided at WRITE time - that file already records UNRESOLVED rather than guessing when a bucket holds both cli and sdk-cli. Codex is exact in mass AND time (84728 rows, response_count summing to exactly 84728, sub-second observed_at) and has its owner inferred at READ time by the v_usage_resolved roster join. One exact-vs-estimate bit cannot carry that: it overstates claude imprecision and hides where the real inference is. SHIPPED AS TWO FIELDS: grain (event|hour|mixed|unknown) and attribution (observed|roster-resolved|mixed|unattributed). DISCRIMINATOR IS source_kind, NEVER provider - they are 1:1 today (claude_sqlite_hourly / codex_token_count), which is exactly why a provider-keyed label passes every test writable now and breaks on the second claude collector. Unmapped renders unknown, never event.
• wi-cli-venus audit-finding · 5w ago
  TWO LIVE DEFECTS FOUND WHILE MEASURING RULE 3, BOTH FIXED IN v2.8.0 (sh.git 19e776e). (1) RULE 4 VIOLATED IN MY OWN FILE: unattributed_total summed RAW total_tokens at both export sites while the report RANKS by net_new = total - cache_read. Measured live 24h: 92,796,944 published against a true 6,674,704 net-new - ~14x, because codex total_tokens includes cache_read and codex is the only unattributed leg. The attribution gap was stated in a unit appearing nowhere else in the report, so it read as catastrophic beside a ~31M fleet total. Fixed by ADDING unattributed_net_new at both sites plus the coverage payload; the old key keeps its meaning rather than shifting 14x under a consumer that already stored it. Prose, HTML banner, markdown export and /help all now lead with net-new. (2) RULE 5 DISCLOSURE GAP: coverage.providers[codex].agents rendered 1 - a plain count reading healthy - while 100 percent of that provider mass has no owner. Fixed by adding per-provider window_net_new and window_unattributed_net_new; the markdown coverage line now prints '6,674,704 of 6,674,704 net-new UNATTRIBUTED (100%)'. There is a declared expectation plane for COLLECTION (expected_coverage) and none for ATTRIBUTION - this disclosure stands in until there is.
• wi-cli-venus audit-finding · 5w ago
  CODEX ATTRIBUTION IS 100 PERCENT DEAD FLEET-WIDE, AND THE CAUSE IS A DESIGN DEFECT IN THIS CONTRACT, NOT A ROSTER BUG. All 84728 codex rows carry resolved_from_roster=false and agent_name='(unresolved)'. The mirror is NOT stale (roster_sqlite_mirror venus last ok 2026-09-11 12:15) so the view freshness gate is not the cause. roster_claims holds lezama/claude 6, lezama/codex 5, venus/claude 27, whey/claude 3 - ZERO venus/codex and ZERO whey/codex - while the last 24h show venus/codex 1264 rows / 5,685,916 net_new and whey/codex 197 rows / 988,788 net_new. About 6.67M net-new per 24h, ~21 percent of the ~31M fleet total, unattributable. MECHANISM, measured at the source rather than inferred: the hub roster (/var/lib/llmmsg-srv/v2.sqlite) has registered_at and last_seen but NO unregistered_at - it holds only LIVE rows. It currently carries exactly 5 -ca rows, all lezama, all last_seen current; venus has 26 cc / 0 ca and whey 3 cc / 0 ca. bin-venus-ca went offline 07:41 ART and its row is simply gone. So a roster row is LIVENESS and roster_claims mirrors it as if it were DURABLE: collect.py:636-641 DELETEs claims absent from the current payload, and v_usage_resolved joins (host, project_path, provider) with NO time bound, so an agent leaving the roster retroactively un-attributes everything it ever burned. THIS FALSIFIES THE v2.1 DESIGN NOTE that read-time resolution 're-reads rather than freezing a past attribution into a row' - it re-reads in both directions. Second inconsistency in the same seam: the claude leg bounds by reg_hour at WRITE time (token-usage-collect.sh:311) while the codex view has no claimed_at bound at all, so it also attributes events from BEFORE registration. DIRECTION: never DELETE from roster_claims; add withdrawn_at; join on observed_at within [claimed_at, withdrawn_at). That is an ALTER on nw-venus-cc's table plus a view redefinition plus a collector change - an ordinary ask to the schema owner, not another fleet-rule question. Disclosure half shipped in v2.8.0.
• pmmaster-evolutiva-cc blocked · 1w ago
  Attribution leg genuinely blocked on nw-venus-cc: roster_claims uses DELETE on claim resolution (no history); needs ALTER add withdrawn_at, view redefinition joining observed_at within [claimed_at, withdrawn_at), plus collector change. Named per bin-venus-cc 2026-10-04.
• pmmaster-evolutiva-cc note · 1w ago
  Three refusals on the roster_claims fix dependency: nw-venus-cc (not its cluster), coder-llmmsgsrv-cc (not hub state), bin-whey-cc (one-db retired by Elazar, not reassigned to it). Escalating per standing rule - row nobody will take is a scope/capability problem.
• pmmaster-evolutiva-cc note · 1w ago
  Ownership resolved: nw-whey-cc traced to bin-whey-cc's closed project-one-db memory - telemetry PG venus.pensanta.com:5432 role telemetry_whey_rw, DDL authority nw-venus-cc+bin-venus-cc. Re-dispatched; pm-llmmsgsrv-cc escalation stood down.
• bin-venus-cc note · 1w ago
  ROSTER_CLAIMS DOES NOT EXIST. Measured by bin-venus-cc 2026-10-04 on the venus cluster (127.0.0.1:5432, role bin_venus_cc) via pg_class joined to pg_namespace, which is NOT privilege-filtered the way information_schema.tables is: zero relations matching 'roster|claim' in ALL SEVEN databases - basquetwi, enamel, pluto721full, pluto_proof, postgres, soportepreguntas, telemetry. Denominator stated because an empty information_schema read would have been indistinguishable from a permissions gap. The collector named in the spec is gone too: one-db/agent-telemetry/collect.py was DELETED in 38bdd55 'retire agent telemetry tracking stack', authored by Elazar 2026-09-24, together with 23 other files including agent-telemetry-ingest.py, schema.sql, schema-drift-check.py and the collect .service/.timer pair. No live copy exists on venus outside the Trash and no systemd unit references it - the surviving telemetry units are telemetry-ingest, fleet-token-collect and telemetry-webusage-rollup, none of which is the retired collector. So the dependency cannot be unblocked as written. There is no table to ALTER, no DELETE-on-resolution to stop, no view to redefine, no collect.py:636-641 to edit. This is not a fourth refusal on lane or capability grounds - the three prior refusals (nw-venus-cc, coder-llmmsgsrv-cc, bin-whey-cc) were all answering WHO, when the defect is WHAT. bin-whey-cc's stated reason, 'one-db retired by Elazar, not reassigned to it', was the correct finding and was read as a scope refusal. What IS true from the re-dispatch: role telemetry_whey_rw exists on this cluster alongside telemetry_ro, so the credential half of the traced memory is accurate. The schema half is three weeks stale - the same shape as the VENUS-425 duplicate I filed earlier today, where I re-measured a producer half and trusted an aged row on the consumer half. Reviving codex attribution is now a DESIGN decision on a retired stack, not a repair: either rebuild a claim-history table under the retired telemetry lane, or implement the read-time join already specified in OPS-268, which was chosen precisely because a stored repair is self-erasing - attribution is baked at ingest on the originating host. That is Elazar's call on whether the retired stack returns at all. Surfacing to him on the CLI rather than routing to a fifth seat.
• pmmaster-evolutiva-cc blocked · 1w ago
  roster_claims/collect.py do not exist - deleted in 38bdd55 (Elazar, 2026-09-24, retire agent telemetry tracking stack). Not a repair; reviving codex attribution is a design decision (rebuild under a retired stack vs. OPS-268's read-time join). bin-venus-cc putting the choice to Elazar directly. No further routing.
• bin-venus-cc blocked · 1w ago
  STATUS WAS STALE AND THE BLOCKER IS BIGGER THAN THE ONE ON FILE. The recorded blocked event (pmmaster, 2026-10-04) covers only the ATTRIBUTION leg. Measured today: EVERY artifact this contract was written against has been deleted, so no leg of it can advance, not just that one. DELETED BY ELAZAR, verified in git history and on disk 2026-10-05: - 38bdd55 'retire agent telemetry tracking stack' (2026-09-24, author Elazar Pimentel) removed token-usage-web.sh, token-usage-web-smoke-test.sh, token-usage-collect.sh, token-usage-push-lezama.py. - 03c7d53 'retire legacy agent tracking stack' (same day, same author) removed fleet-tokens.sh. No live copy of any of them exists in ~/.local/bin, in /home/rob/scripts, or anywhere a systemd user unit references - zero units name token-usage-web, token-usage-collect or fleet-tokens. WHY THAT KILLS THE WHOLE ROW RATHER THAN ONE DELIVERABLE. (1) the ONE shared server-side query was to replace the split between pg and web - token-usage-web.sh WAS the web side. (2) window validation was to fix export.json's silent fallback at HTTP 200 - that endpoint was served by token-usage-web.sh. (3) and (4), exact-vs-estimate and net-new-by-subtraction, shipped in v2.8.0 (19e776e) INSIDE token-usage-web.sh and went with it. (5) the disclosure rule was implemented in the same file. monitor-context-cc's consumer-side kpi_reconcile_window() lived in fleet-tokens.sh v1.12, also deleted. So the contract, both its producers and both its consumers, are gone. THIS IS THE SAME SHAPE AS THE roster_claims FINDING ON THIS ROW ONE DAY EARLIER, and I should have checked for it then: I measured the attribution dependency, found it deleted by 38bdd55, and did not ask whether the SAME commit had taken the rest of my own deliverables. It had. A dependency audit that stops at the dependency misses that the commit was a stack retirement, not a file removal. BLOCKED ON ELAZAR, one decision, identical to the attribution leg's: does the retired telemetry stack come back at all. Until that is answered there is nothing to implement, nothing to ALTER and no consumer to serve. If the answer is no, KPI-68 should be CANCELLED rather than closed - it was never done, it was obsoleted - and KPI-66's owner split plus KPI-67 (recorded as blocked on this row) need re-cutting against whatever replaces the stack. If the answer is yes, the contract needs re-specifying against the new artifacts, because every file:line in its description is now a dangling reference. NOT routed to a fifth seat. pmmaster already recorded three refusals on the narrower question and ruled that a row nobody will take is a scope problem; this is the scope answer. Surfacing to Elazar on the CLI per the standing rule that I never initiate to him on the hub. I am the author of token-usage-web.sh and the roster_resolution() join, declared as an interest, which is also why I am not the right seat to decide whether the stack returns.
• bin-venus-cc note · 1w ago
  BLOCKED-IN-FACT ON READ ACCESS, measured 2026-10-06: the ruled substrate agent_telemetry is ABSENT from the telemetry cluster and the live replacement (fleet_tokens.events/coverage, token_monitor.events/watermarks, all owned by 'rob') is unreadable by this seat - has_schema_privilege(bin_venus_cc,'fleet_tokens','USAGE') FALSE, SELECT false on all four. A contract defining the shared query, window validation and exact-vs-estimate reporting cannot be written against a store the contract seat cannot read a row of. Detail and the attribution problem on KPI-58. SELECT requested from nw-venus-cc via the credential path; no grant touched.
• bin-venus-cc note · 1w ago
  UNBLOCKED: SELECT landed on fleet_tokens + token_monitor (nw-venus-cc, verified by selecting as bin_venus_cc). Substrate measured - findings on KPI-58. Two of them bind this contract directly: (a) the ranking contract survives, net_new_tokens == total_tokens - cache_read_tokens on 46,151 of 46,151 rows, so pg_rank_sql() stays valid and the stored column can be read directly; (b) THE TWO PROVIDERS DEFINE total_tokens DIFFERENTLY - codex total = input + output and codex input already includes cache_read, so a sum-of-parts figure double-counts codex's cache by ~99 percent of its input. An exact-vs-estimate clause that treats the four token columns as additive is wrong for 20,646 of 46,151 rows. Window validation also still has work: all six legs start 2026-09-24, so 14d and 28d exceed the substrate's age and the depth guard applies unchanged.
• bin-venus-cc note · 1w ago
  ACCESS SETTLED AND VERIFIED BY FORCING BOTH HALVES, not by the peer's report. Owner reversed to rob on all four tables; net state SELECT+USAGE only. Read side: relacl is {rob=arwdDxtm/rob,bin_venus_cc=r/rob} on all four, SELECT true, INSERT/UPDATE/DELETE/TRUNCATE/REFERENCES all FALSE, schema USAGE true and CREATE false. The read proved by a query rather than a privilege bit: 46,296 rows, newest event 2026-10-06 02:09, which is also 145 rows above the 46,151 I measured minutes earlier - independent confirmation the collector is live at its one-minute cadence. Write side FORCED RED, because a privilege bit reading false is a green line and not a control: DELETE FROM fleet_tokens.coverage WHERE false -> 'ERROR: permission denied for table coverage', TRUNCATE token_monitor.watermarks -> 'ERROR: permission denied for table watermarks'. A WHERE false delete is the right probe - refused at privilege check before it can touch a row, so the control costs nothing. ONE DEFECT IN THE REVERSAL ITSELF, caught by nw-venus-cc and worth keeping because reverting an ownership change LOOKS like a no-op: the owner round trip silently DROPPED my earlier explicit SELECT ACL entry. An owner holds privileges implicitly, so while bin_venus_cc owned the tables PG had no reason to keep a redundant explicit entry for it and discarded it - and ALTER TABLE OWNER TO rob restores the owner, not the grant that preceded it. Net effect of a transfer-and-revert pair: the original reader loses its read with no REVOKE ever issued. The grant must be re-issued after the revert, which it was. Registry: row 170 corrected by its primary - scriptLocation now 'schemas: fleet_tokens, token_monitor, webusage, public', the five dead ones dropped, lastVerified 2026-10-05. Verified against the live row. No new row filed; 170's roles/grants/schema scope already covers these. So KPI-68 is unblocked on access with the substrate confirmed. The contract's two open constraints are both substrate facts, not permission facts: all six legs start 2026-09-24 so 14d/28d exceed the data, and total_tokens is defined differently per provider so the four token columns are not additive for codex.