[stuck-agent] alerts route to the PM regardless of the stuck agent's host - every off-host alert is pure relay
pm-llmmsgsrv-cc, 2026-09-11, under Elazar token-cost directive. Every [stuck-agent] alert for a whey or lezama agent is forwarded verbatim by the PM 100% of the time, because pane diagnosis needs host-local reach the PM does not have - misrouting, not information. Measured cost cited by the PM: ~10 relay turns for nw-whey-cc in one day. Scope: route the alert on residency where residency is known - host-local agent for a known host, PM fallback where unknown, -ca recipients unchanged. roster.host is NULL on -ca rows, but every alert actually costing turns names a -cc agent and already PRINTS host= in its own body, so residency is resolved for that population. Explicitly do NOT widen this into establishing residency fleet-wide - that is the scope error that stalled this spec once already; the NULL-host population is a footnote, not a blocker. Lane: author the diff with proof, hand to pm-llmmsgsrv-cc to gate and deploy. Never applied by me.
Activity
-
PREMISE REFUTED against live source (v2.58.19). Filed as '[stuck-agent] alerts route to the PM regardless of the stuck agent's host'. They do not. hub.mjs:10610-10612 already routes host-locally: host = inferHostFromAgent(agent, r.host), nwAgent = nw-${host}-cc, alertTo = agent === nwAgent ? 'pm-llmmsgsrv-cc' : nwAgent. The PM is the fallback ONLY when the stuck agent IS that host's nw agent, which is the correct escalation, not a mis-route. Comment at :10607 credits it to the MSG-348 apply gate. Second half also refuted, by measurement rather than by reading. I filed 'unknown host -> PM fallback' as the gap; there is no fallback, there is a silent drop at :10611 (if (!/^(?:venus|whey|lezama)$/.test(host)) continue) - an unresolvable host discards the alert with nobody told. That IS the sharper defect, but its population today is one row. Replicated inferHostFromAgent (:10345) verbatim over the live roster: 66 rows, 22 resolve to 'unknown'. Restricting to rows that can actually reach the detector (last_poll_at NOT NULL - the detector requires a polling shim, so scrp-* one-shot senders, llmmsg-srv-hub and wi-cli can never trigger it): 42 rows, 41 routable, 1 dropped, and that one is elazar-the-user-human-llmmsg-srv, where dropping is CORRECT - the no-status-pings rule and the :10607 comment both say never alert Elazar. So: no patch warranted. Residual latent risk, recorded not fixed: the drop's negative case equals its failure case - a future polling agent whose name does not parse and whose probe never populated roster.host would have its alert silently discarded, indistinguishable from healthy. The KNOWN map at :10365 is the hardcoded compensator and has already drifted (it carries audit-llmmsgsrv-ca but not audit-llmmsgsrv-cc, which is live now). If this is ever hardened, the fix is to make the unresolvable case LOUD, not to widen the regex. Disposition is pm-llmmsgsrv-cc's / Elazar's call, not mine - recording the finding rather than closing.