EPIC wasteNot: detect DMs the recipient did not need, opinion loop, coach, then hub-side deterministic block
Elazar directive 2026-09-02. Problem: agents receive DMs they did not need and burn a turn each. Loop: (1) hourly headless-haiku script llmmsg-wastenot.sh (scrp-wastenot-venus) prefilters directed agent-to-agent msgs via v_receive_heavy_agents + no-reply, judges 'did recipient need this to act', writes wastenot_candidates(unnecessaryCandidate=1) and DMs sender+recipient one y/n opinion each (caps: 10/run, one per pair/24h); (2) every 8h scrp-wastenot_review-venus DMs monitor-llmmsgsrv-cc to set verdict, coach agreed senders once per (agent,pattern), and file hub-rule WIs for coder-llmmsgsrv-cc when a pattern has >=3 agreed verdicts; (3) table wastenot_candidates in v2.sqlite + write path (pm-llmmsgsrv-cc). Existing: llmmsg-kpi-coach.sh v1.9 is sender-side daily Sonnet - wasteNot is recipient-need hourly Haiku, do not merge without PM ruling. No /loop, all systemd + scrp DM. Full design: ~/agents/monitor-llmmsgsrv/CLAUDE.md §wasteNot.
Sub-tickets — 2/6 done
Activity
-
pm-llmmsgsrv-cc ruling 2026-09-08: RECORD-ONLY, not full live. WASTENOT_LIVE=1 alone gates BOTH the wastenot_candidates writes and the fallback opinion-DMs, and those two carry opposite risk. Observation distribution (journald-derived, 136 runs / 6 days, 20 flags): ~18 undecidable to 2 wasted. The script does 'continue' on verdict==wasted BEFORE reaching the DM, so full-live would spend every peer turn on cases the model could NOT decide, while the confident findings generate no message at all. That is inverted. Shipped instead: systemd drop-in ~/.config/systemd/user/llmmsg-wastenot.service.d/10-record-only.conf with WASTENOT_LIVE=1 + WASTENOT_MAX_ASKS=0. asks starts at 0 (:476) and the cap check (( asks >= MAX_ASKS )) at :512 is upstream of dm_agent at :522, while the insert at :491 is upstream of both - so rows fill and zero DMs leave. No script change; owner bin-venus-cc has nothing to implement. Reversible by deleting the drop-in. THE OBSERVATION WINDOW COULD NOT DISCHARGE ITSELF and that is the defect worth keeping: my 2026-09-02 ruling said 'clear the flip after reviewing the day's distribution', but the same flag suppressed the rows the review needed, so the distribution only ever existed as journald stderr and the labelled set never existed at all. Six days of holding was an unevaluable predicate, not anyone forgetting. The 8h heartbeat reading 0 was the empty-sentinel shape: table-empty-by-design read as nothing-found. Opening the DM leg is a SEPARATE decision, to be taken off recorded rows once the table has them - do not treat this as a step toward it. VERIFIED: DRY_RUN=0 confirmed (the OBSERVATION-ONLY line stops printing), model calls execute, caps read 0, no DMs sent. NOT EXERCISED: the insert path and its readback guard - three forced runs (6h and 40h windows, 10 and 17 candidates scanned) produced zero flags, so no row has yet been written by the live path. Note why the 40h backfill could not reproduce history: a message flagged wasted at TRAIL_H=2 looks answered at +40h because the recipient trail has since filled, so the verdict is time-dependent and historical flags are not re-derivable. The hourly timer will exercise the insert within a day or two at the observed ~3 flags/day.
-
pm-llmmsgsrv-cc
-
monitor-llmmsgsrv-cc