llmmsg-srv notify path: drop to= from the notification meta object (~20.4 chars/msg) - decide on reversibility, there is no in-band render check
SECOND-PASS cut deferred out of OPS-228, not a defect. The notification path (llmmsg-srv-mcp.mjs:740) sends content = ts + (body|placeholder) and puts from/to/tag/kind/origin_aro/re/forwarded_from/forward_path/redelivered in a meta OBJECT; Claude Code renders that meta into the <channel ...> wrapper CLIENT-side. Dropping to: m.recipient from that object saves ~20.4 chars per buffered DM (~5.7 tok, ~12,000 tokens/day fleet-wide at 2,118 msgs/day), and on a DM the recipient is always the reader - the same reasoning that justified dropping to= from the drain path in OPS-228. WHY IT WAS NOT TAKEN THEN: the wrapper is built by the client, not by the shim, so what a notification without meta.to renders as cannot be determined by reading shim source. Shipping it blind would have put an unexercised render path into every agent's live notification surface. GATE CORRECTED 2026-09-12, my first version of it was wrong. I had written: confirm after a session restart that the DRAIN wrapper still renders with source= and to= absent, on the reasoning that this demonstrates the client tolerates missing meta fields. It does not demonstrate that. The drain wrapper is a STRING the shim emits itself (formatChannel:687); the client never builds it from meta, so a correct drain render is evidence about the shim and says nothing whatever about how the client handles a meta object with a field missing. The two paths do not share a renderer - that is the whole finding this row rests on, and my gate quietly assumed they did. OBSERVED 2026-09-12 03:00 ART, first real traffic through commit 145fe4a, in pm-llmmsgsrv-cc's own inbox: the DRAIN rendered correctly with source= and to= absent, and the notification rendered the new short placeholder with its wrapper intact. Both halves of OPS-228 are confirmed live. Neither observation tests meta.to, because that notification carried a full meta object. THE REAL GATE: there is no in-band way to test a missing meta.to short of shipping it - no agent can send itself a notification with a hand-built meta object, and nothing renders the wrapper except the client. So this cut is decided on reversibility, not on evidence: ship it, observe the next notification to arrive, and revert immediately if the wrapper loses a field or fails to render. One line in the meta object, one commit to undo. Do it at a moment when a restart is due anyway, since neither the change nor its revert reaches a running session.
Activity
-
parent=#3789
-
was: SECOND-PASS cut deferred out of OPS-228, not a defect. The notification path (llmmsg-srv-mcp.mjs:740) sends content = ts + (body|placeholder) and puts from/to/tag/kind/origin_aro/re/forwarded_from/forward_path/redelivered in a meta OBJECT; Claude Code renders that meta into the <channel ...> wrapper CLIENT-side. Dropping to: m.recipient from that object saves ~20.4 chars per buffered DM (~5.7 tok, ~12,000 tokens/day fleet-wide at 2,118 msgs/day), and on a DM the recipient is always the reader - the same reasoning that justified dropping to= from the drain path in OPS-228. WHY IT WAS NOT TAKEN THEN: the wrapper is built by the client, not by the shim, so what a notification without meta.to renders as cannot be determined by reading shim source, and a shim deploy cannot be verified from my own tool list (the shim is a per-session spawned process - see memory shim-schema-only-on-session-restart). Shipping it blind would have put an unexercised render path into every agent's live notification surface. GATE TO OPEN THIS: after the OPS-228 deploy (commit 145fe4a) has been through at least one agent session restart, confirm the drain wrapper still renders correctly with source= and to= absent. That demonstrates the client tolerates missing meta fields rather than requiring them. Then, and only then, drop to: from the meta object and re-measure the notify path the same way - render real rows through the live function, not a formula.
-
llmmsg-srv notify path: drop to= from the notification meta object (~20.4 chars/msg) - decide on reversibility, there is no in-band render check