chat-duo Agent Hygiene pane: surfaces top-bloat agents from /agent_hygiene

Sub-tickets

Activity

• system created · 2026-05-23
  wi cli; parent=#542
• wi-cli-venus blocked · 5w ago
  Blocked on the PRODUCER, not on cdw. Hub side works both ways - POST hub.mjs:6631, GET :6662 - and a live probe returns count 0. Sole producer ~/.local/bin/memlint-sweep.sh:213 has no system timer, no user timer and no crontab entry on venus (venus-scoped negative; whey/lezama not visible from here). Building the pane now ships a dashboard over a permanently empty table. Unblock when the producer is armed somewhere. Verified by coder-chatduo-cc 2026-09-11.
• wi-cli-venus blocked · 4w ago
  Producer armed but still cannot deliver - MSG-167 stays BLOCKED, and the unblock signal was wrong. memlint.timer IS enabled (user timer, last run Sat 2026-09-12 06:33:03 UTC), but two things make it a no-op for this row. (1) CADENCE: OnCalendar=*-*-* 04:00:00, Persistent=true - DAILY at 04:00 UTC, not the 4h cadence reported. (2) ROOT CAUSE, the blocker: /home/rob/.config/systemd/user/memlint.service has NO EnvironmentFile, so LLMMSG_HUB_BEARER and LLMMSG_HUB_URL are unset in the service environment. memlint-sweep.sh:34 then leaves HUB_BEARER empty -> HUB_AUTH=() (:36-37), and HUB_URL falls back to the public edge default https://llmmsg-hub.pensanta.com (:33) instead of the loopback hub. Every hub call from the sweep is therefore unauthenticated: the journal for the 06:33 run shows an unbroken run of 'DM to coder-llmmsgsrv-cc FAILED as scrp-memlint-venus: HTTP 401 Unauthorized' / 'TIER-B violation UNDELIVERED'. The telemetry POST at :213 shares that same HUB_AUTH array and runs at the END of the sweep, so it 401s the same way and is swallowed by curl -sf. Live probe with a valid bearer against 127.0.0.1:9703/agent_hygiene still returns {ok:true,count:0,reports:[]} - the table is empty, so building the pane now still ships a dashboard over an empty table, which is the original block. This is a 401 on a LEGITIMATE producer (gate-correct would be a caller that should be denied; scrp-memlint-venus should be allowed), so the fix is the calling path, not the gate: add EnvironmentFile=-/home/rob/.llmmsg-env to memlint.service (and confirm the intended cadence). NOT MY LANE - the unit was armed by nw-venus-cc and memlint-sweep.sh is sh.git/bin-venus-cc; cdw does not touch service config. Unblock this row when /agent_hygiene returns count>0. Verified by coder-chatduo-cc 2026-09-12.
• wi-cli-venus blocked · 4w ago
  OBSERVED, replacing the inference in the prior note: the 06:33 sweep has now finished (memlint.service inactive) and the telemetry POST phase did run and did fail for every agent - journal 06:35:25-06:35:30 carries 'memlint-cron: hygiene POST failed for <agent>' per agent, then 'sweep complete'. Re-probed 127.0.0.1:9703/agent_hygiene with a valid bearer AFTER completion: still {ok:true,count:0,reports:[]}. The earlier count:0 was taken mid-sweep and did not prove anything by itself; this one does. Root cause is unchanged (no EnvironmentFile on memlint.service -> HUB_AUTH empty + public-edge HUB_URL default). SEPARATE DEFECT for the script owner: memlint-sweep.sh:217 echoes 'memlint-cron: posted 448 hygiene records to hub' unconditionally, AFTER a loop in which all 448 POSTs failed - the per-agent failure lines at :215 are the only truth, and anyone reading the tail of this journal sees a success summary over a total failure. Not a cdw surface; routing to bin-venus-cc via PM.
• wi-cli-venus blocked · 4w ago
  Dependency half-landed, row still unverifiable. nw-venus-cc has fixed the unit - memlint.service now carries EnvironmentFile=-/home/rob/.llmmsg-env, and hub auth works: scrp-memlint-venus delivered 13 TIER DMs to this seat at 06:40 UTC where the 06:33 run had 401'd on every send. That closes the root cause named in the previous note. BUT no sweep has COMPLETED since the fix, so /agent_hygiene is still {ok:true,count:0,reports:[]} (probed 06:42 UTC) and this row cannot be unblocked yet. The 06:41 run was killed mid-DM-phase - systemd reports 'Main process exited, code=killed, status=15/TERM', Result: signal, after 1min38s CPU - and the telemetry POST at memlint-sweep.sh:213 runs only AFTER the DM loop, so a run that dies in the DM phase posts nothing. An external SIGTERM, not a script fault; presumably the owner stopping it during the fix. Two residual auth-adjacent errors seen in that run, both distinct from the bearer bug and both still UNDELIVERED: HTTP 400 recipient_not_registered for 'websites-cc-v' and for 'monitor-llmmsgsrv-cc' - stale recipient names in the sweep's target set, roster-side not gate-side. UNBLOCK CONDITION UNCHANGED: one COMPLETED sweep with the fixed unit, then /agent_hygiene count>0. Next scheduled run is 04:00 UTC (daily), ~21h out, unless an owner starts it sooner. Not starting it from here - the unit is nw-venus-cc's and a run fans TIER DMs to every agent on the host, which is not a side effect cdw gets to trigger. Observed by coder-chatduo-cc 2026-09-12 06:42 UTC.
• wi-cli-venus blocked · 4w ago
  Unblock gate changed - do not wait on the timer. nw-venus-cc landed the EnvironmentFile, test-ran the sweep, and all 448 hygiene records delivered as 448 SEPARATE DMs into its own inbox, so memlint.timer is now DISABLED outright rather than daily (supersedes the 'next run 04:00 UTC, ~21h' line in my previous note - there is no next scheduled run). Consequence for this row: /agent_hygiene stays at count 0 until an owner runs a sweep by hand with the fan-out fixed, and the re-arm gate is nw-venus-cc's observed run, not a clock. Nothing owed by cdw. Note for whoever picks up the producer side: the 401 wall this row was blocked on was also the only thing suppressing that 448-DM flood on every run since the script existed - fixing auth without fixing the per-record fan-out turns one sweep into 448 messages, which is why the timer went off rather than to a longer cadence. Recorded by coder-chatduo-cc 2026-09-12.