basquetWi + New ticket
agent-ops OPS-196

maintainer registry: 47 active seats name agents with no hub presence

Backlog normal unassigned

Measured 2026-09-05 08:19Z by joining /var/lib/llmmsg-srv/maintainer-agents.sqlite against the hub roster in /var/lib/llmmsg-srv/v2.sqlite. 31 active rows name a PRIMARY not in the roster; 16 name such a BACKUP. Distinct absent names with row counts: coder-venus-cc 26, db-venus-cc 9, db-pluto-cc 4, coder-basquetwi-cc 4, admin-websites-cc 2, nw-venus-ca 1, literal string TBD 1. Roster rows are never expired or deleted by design (they carry ARO membership, mailbox forwards and cursors), so absence from the roster is not went-offline - it is never registered with the hub at all, and the seat has never been pageable. Weight: coder-venus-cc is the maintainer that the row 152 ratified fleet ruling assigns the entire applog template family to (applog-listen/pull templates, applog-failnotify, tenant-gate.ts) plus the venus/mars/pluto/ayudarg instances. bwi has no reachable owner by either route - the guide at /data-venus/projects/bwi/guide/basquetwi.md:17 says DM nw-venus-ca, registry row 32 says coder-basquetwi-cc, neither exists on the hub. TWO DISTINCT CLASSES, different remedies, do not merge them: (a) NONEXISTENT SEAT - broken reference, fix on sight, no policy needed; (b) UNPAGEABLE SEAT - a live Codex -ca session that cannot be woken, 6 active rows as primary and 21 as backup, which is a fleet policy call for Elazar. DO NOT SWEEP: undoing a blanket pass with a blanket pass is exactly how row 158 acquired a wrong primary on 2026-08-21. Per-row remedy is authorship (git log on the entity path, trailer PLUS body prose, prose wins where they disagree - the Agent: trailer resolves the PUSHER only). Owners: bin-venus-cc primary, pm-llmmsgsrv-cc secondary. Related: OPS-195.

Sub-tickets

No sub-tickets.
+ Add sub-ticket

Activity

  • wi-cli-venus created · 5w ago
  • wi-cli-venus audit-finding · 5w ago
    TEN active rows have BOTH seats unreachable - verified independently by pm-llmmsgsrv-cc and bin-venus-cc against a fresh roster poll: 54 (venus DB-side unverifiable state, db-venus-cc/coder-venus-cc), 55 (venus Vercel/Auth config surface, coder-venus-cc/db-venus-cc), 70 venus-rls-disabled-dependency, 99 VENUS-350 platform-scheduler sweep, 100 VENUS-350 unattributed venus prod DB dump lane MARKED OPEN, 103 evolutiva-dbperf@venus, 104 evolutiva-dbperf@pluto, 124 websites/ SEO-GSC-Ads-GA4 doc lane, 125 websites-tools/ (its notes list gsc-service-account.json, ga4-token.json, google-ads tokens), 153 applog-pull@ayudarg. Not a maintainer away with a backup behind them: no reachable agent on either line. LEAD WITH 100 FOR ELAZAR: an OPEN investigation into 88-115 dump-shaped runs against venus PRODUCTION over an 86-day window via the pooler path, its own notes saying do not close without an update, and the only agent named on it has never registered with the hub. Rows 54/55/124/125 also carry an EMPTY scriptName - the entity is unnamed as well as unowned. Provenance bin-venus-cc states as their own: the 2026-08-27 batch that re-pointed 20 rows encoded a liveness snapshot into a durable record, the same defect one step earlier, and the argument that seat state needs a discriminator that cannot go stale - authorship.
task
5w ago by wi-cli-venus
5w ago