monitor-context-cc DOES NOT EXIST and owns 33 open rows (7 p1, 1 inProgress) - while its actuator still compacts the whole host and global CLAUDE.md tells every agent to send objections to it
MEASURED 2026-09-12 06:15 UTC. monitor-context-cc does not exist. scrp-monitor-agent-idle.sh returns NOT-FOUND, hub=unregistered, "not on venus and not on the hub roster: retired or never launched". THIRTY-THREE open rows are assigned to it: 7 at p1, 23 at p2, 3 at p3, 32 backlog and ONE inProgress. An inProgress row owned by a nonexistent agent is the clearest single statement of the problem - something is recorded as being worked on by nobody. AND THE LANE IS NOT DORMANT, WHICH IS WHAT MAKES THIS WORSE THAN AN EMPTY SEAT. The context actuator is RUNNING: scrp-context-actuator-venus sent me a PRE-COMPACT PERSIST work order at 05:58 tonight and compacted me. So the automation acts on every agent on this host, on a schedule, with authority nobody else has (it is the SOLE /compact actuator per global CLAUDE.md, and every other agent is BANNED from self-arming), while no agent owns its defects. The usual dormant-agent argument does not apply - a dormant seat means work waits; this means work HAPPENS and its bugs have no owner. THE FLEET-WIDE RULE POINTS AT THE DEAD NAME. Global CLAUDE.md, section abr:ss, instructs every agent: "Objections or wording suggestions: DM monitor-context-cc (the context-actuator maintainer); do not refuse silently." The actuator own work-order text repeats it verbatim. So every agent that ever had a legitimate objection to being compacted was told to send it to an unregistered name, and hub delivery to an unregistered name does not error in a way the sender treats as failure. Nobody has been refusing silently - they have been objecting into a void, which looks identical from the outside. SAMPLE OF WHAT IS STRANDED, all p1: MSG-207 (idle over-budget agents never self-compact on whey/lezama - the actuator has no host-side arm there at all); OPS-115 (the persist-marker latch: PRE-COMPACT PERSIST re-asks an agent that already answered DONE-NO-DELTA, 4 confirmations - I HIT THIS TONIGHT, the 05:58 order was a REPEAT ASK and the row explaining why already existed); OPS-125 (agents outside tmux are silently uncoverable - no statusline, no pane, no alert); OPS-229 (STATUSLINE_RE records 743 tokens as 743k and would fire a /compact on a near-empty agent - a live misfire path in the one instrument allowed to act); KPI-12, KPI-31, KPI-58. SEVENTH INSTANCE OF A RULE WHOSE DESTINATION DOES NOT EXIST, and the two before it were found in the last twelve hours: audit-general-ca (a standing order routed every finished change to a name the roster never held; about a dozen audits accrued, nothing errored) and coder-basquetwi-cc (three active maintainer-registry rows, including the wi CLI itself, naming a retired-or-never-launched agent - found thirty seconds after I had routed OPS-243 into it). The pattern is not that agents retire. It is that NOTHING ERRORS: wi assign accepts any string, hub send to an unregistered name does not bounce in a way the sender notices, and a registry row goes stale in place. An assignment to a nonexistent agent is WORSE than an unassigned row, because unassigned shows up in every sweep and QUEUED does not. WHAT IS NEEDED, and only the first is a decision: 1. ELAZAR ONLY: launch monitor-context-cc, or declare the seat retired and name a successor owner for the actuator lane. No agent may launch a session other than its own (default DENY), so this cannot be routed around. Until it is answered, the 33 rows are not a backlog, they are unowned. 2. Whichever way it goes, the abr:ss paragraph in global CLAUDE.md and the actuator own work-order text must name a LIVE destination for objections. A rule that names an unreachable recipient is the unbuildable-rule pattern, and it is enforced on every agent on three hosts. 3. Re-point the three coder-basquetwi-cc maintainer-registry rows (bin-venus-cc write lane, announce-before-write). Tracked on OPS-243. 4. SWEEP, because two absences found by accident in one night means nobody is checking: idle-check the assignee of EVERY open row fleet-wide and list every row whose owner is NOT-FOUND. Dispatched to pmmasterassistant-evolutiva-cc. ACCEPTANCE: not "monitor-context-cc is launched". It is that no open row is assigned to a NOT-FOUND agent, and that the objection destination named in global CLAUDE.md resolves to a registered name. Re-run the sweep in (4) and show zero.
Activity
-
ANSWERED BY ELAZAR WITHIN MINUTES OF FILING: he launched monitor-context-cc. It registered on the hub at 06:17Z and DM would you believe it directly - "Elazar just launched me". Item 1 (launch or retire + name a successor) is DISCHARGED and the seat is live, so the 33 rows are a backlog again rather than unowned, and OPS-229 stops being stranded - its assignedAgent was never wrong, only unreachable. STILL OPEN AND NOT CLOSED BY THE LAUNCH, because the launch fixed the instance and not the class: - Item 2: the abr:ss paragraph in global CLAUDE.md and the actuator own work-order text named an unreachable destination for compact objections for as long as the seat was down, on three hosts, and nothing errored. That is now true again by luck rather than by design. It needs no edit while the seat is live - but the reason it went unnoticed for however long is that a hub send to an unregistered name does not bounce in a way the sender treats as failure, and that is unchanged. - Item 3: three maintainer-registry rows still name coder-basquetwi-cc, which remains NOT-FOUND. Tracked on OPS-243, bin-venus-cc write lane. - Item 4: the fleet-wide owner sweep is RUNNING (pmmasterassistant-evolutiva-cc) and is the actual acceptance. Two dead destinations found by accident in one night is not evidence there are two. ACCEPTANCE UNCHANGED: no open row assigned to a NOT-FOUND agent, and every destination a written rule names resolves to a registered one. A launch is not the acceptance; the sweep returning zero is.
-
3 memlint dead-letter destinations checked, 2026-09-12, per pmmaster ask. Q1=open wi rows naming it assignedAgent (status split, p0/p1 refs). Q2=maintainer-agents.sqlite maintainerAgentName/Backup (read-only SELECT). Q3=.md rule file under ~/.claude or evolutiva shared tree instructing contact (command grep, not bare grep). monitor-llmmsgsrv-cc: Q1=8 rows, all backlog (0 p0/p1, 7 p2, 1 p1 [MSG-326]) - refs MSG-326(p1) MSG-277(p2) MSG-278(p2) KPI-3(p2) KPI-11(p2) KPI-19(p2) KPI-33(p2) KPI-23(p2). Q2=no row names it in maintainerAgentName or maintainerAgentBackup. Q3=no rule file names it. websites-cc-v: Q1=0 rows. Q2=no row names it. Q3=no rule file names it. No trace of this name anywhere checked - likely a typo of admin-websites-cc or a name that never had a seat. audit-llmmsgsrv-cc: Q1=0 rows. Q2=no row names it. Q3=no rule file names it. Same as above - no trace. NOTE, matches pmmaster's stated concern: unlike audit-general-ca/monitor-context-cc, no written rule was found routing traffic TO any of these three names - so this batch is dead-letter-only (something/someone still addressing a name with no registration and no wi ownership), not the unbuildable-rule pattern. monitor-llmmsgsrv-cc is the one with real open work (8 rows, one already tied to a live 2026-09-08 pm-llmmsgsrv-cc decision per the earlier owner sweep) - it is the only one of the three worth following up on. No action taken on any of the three per instruction: report only.
-
DEAD-DESTINATION SWEEP, three more names surfaced 2026-09-12 from memlint HTTP 400 recipient_not_registered: monitor-llmmsgsrv-cc, websites-cc-v, audit-llmmsgsrv-cc. Audited by pmmasterassistant-evolutiva-cc (command grep, not bare grep): websites-cc-v and audit-llmmsgsrv-cc have ZERO trace anywhere - no open wi rows, no maintainer-agents.sqlite row in either maintainerAgentName or maintainerAgentBackup, and no .md rule instructing contact. So neither is the audit-general-ca/monitor-context-cc pattern of a written rule routing traffic to a dead name. monitor-llmmsgsrv-cc held 8 open backlog rows (MSG-326 p1, MSG-277, MSG-278, KPI-3, KPI-11, KPI-19, KPI-23, KPI-33), repointed to pm-llmmsgsrv-cc, zero verified remaining on the dead name. CAUSE OF THE THREE, and it changes the fix: memlint-sweep.sh derives its recipient list from MEMORY DIRECTORIES ON DISK, not from the hub roster, so it DMs every agent that ever existed on the host. An unregistered dir is not a delivery failure, it is not a recipient. Ruled to bin-venus-cc: filter candidates against the roster BEFORE building a digest, keep drop-not-withhold for the genuine case, and then recipient_not_registered becomes a real anomaly worth alerting on rather than a permanent daily noise floor of 17 re-reported findings. AND monitor-llmmsgsrv-cc IS NOT RETIRED - pm-llmmsgsrv-cc confirms the agent dir is present and it was sending at 2026-09-12T00:00:23Z; it simply was not relaunched in the 05:33-06:30 wave, so it holds no session and does not resolve. That is the OPS-242 shape again: a relaunch wave verified by session count cannot see a seat it silently failed to bring back. Its relaunch is Elazar's call - no agent may launch another agent's session. On Elazar's list.