Alert Elazar: misconfig / high-burn / context / needless-turns
Blocked high
bvbin-venus-cc
⛔ KEPT OPEN AS A CAPABILITY, BLOCKED ON ONE ELAZAR DECISION - deliberately NOT cancelled, unlike its five implementation legs (KPI-52/53/54/55/56, cancelled today). The distinction is the point: kpi-burn-alert.sh, which implemented this, was deleted by Elazar in 38bdd55 'retire agent telemetry tracking stack' (2026-09-24, verified on disk and in git history 2026-10-05; registry row 188 retired). The LEGS were internals of that file and have nowhere to land. The CAPABILITY - alert Elazar on misconfig, high burn, context and needless turns, and a staged offender ladder behind it - is plausibly still wanted and nothing has said otherwise, so cancelling it would delete the intent along with the dead code.
BLOCKER: the same single open question recorded on KPI-68 - does the retired telemetry stack come back at all, and in what form. Every input this alerter consumed came from that stack. Until that is answered there is no data source to alert from, so the row cannot advance by effort.
Surfacing to Elazar on the CLI, per the standing rule that I never initiate to him on the hub. Not routed to another seat: pmmaster already ruled on the narrower version of this question that a row nobody will take is a scope problem, and this is the scope answer.
ALSO RECORDED, because the status was the misleading part: this row read as 'todo' in my queue, which is indistinguishable from not-yet-started ordinary work. A stack retirement silently obsoletes every ticket written against it and the tickets keep presenting as actionable backlog - that is why today's drumbeat counted these as untouched work.
Requirement 4 of KPI-45 (Elazar 2026-08-28, reaffirmed 2026-09-03): alert Elazar when fleet KPI data shows misconfiguration, high token burn, high context, or needless turns. Required channels: (a) hub DM - LIVE since 08-28 (kpi-burn-alert.sh, single DM to elazar); (b) DM fan-out to EVERY elazar CLI session, not one - TODO; (c) Linux notification (inotify/notify-send breadcrumb) on whey, venus, lezama - TODO; (d) email - TODO. Also the delivery surface for KPI-47 stage 2. Closed prematurely 08-28 with only (a). Policy owner monitor-context-cc, coder bin-venus-cc.
Sub-tickets — 3/3 done
KPI-53 Canceled high
bvbin-venus-cc
Activity
-
parent=#3062
-
bin-venus-cc
-
Elazar GO 2026-08-28: build now, priority ahead of dashboard/migration. Spec/gatekeeper: nw-venus-cc. Executor: bin-venus-cc (opus 5). Report-only, no auto-stop.
-
kpi-burn-alert.{service,timer} installed+enabled on venus, User=rob, *:0/15, --send. First fire 13:45 UTC.
-
Alert delivery was silently 401'ing since ~17:10 today, not chronic: fleet llmmsg-env secrets consolidation replaced /home/rob/.local/bin/.llmmsg-env's inline LLMMSG_HUB_BEARER with a pointer comment ('sourced from the single home overlay'), but kpi-burn-alert.sh's default bearer-file path is that same bin-dir file, and the systemd unit had no EnvironmentFile/LLMMSG_ENV_FILE override - so every 15min tick since ~17:15 posted unauthenticated (401, alert silently lost, journal-only breadcrumb). Root-caused via journalctl (399 clean runs since 08-28, first bearer failure was today's 17:15 tick) + maintainer-agents row read. Fix: added Environment=LLMMSG_ENV_FILE=/home/rob/.llmmsg-env to /etc/systemd/system/kpi-burn-alert.service (verified overlay, grep-extracted per script's existing design - not sourced, not duplicated). daemon-reload + manual run confirmed no bearer error. Canary: --probe-elazar returned HTTP 200 (hub accepted, authenticated). Filed by monitor-context-cc under the new KPI-46/47 policy seat (maintainer row 188). collect.py/token-usage-collect.sh unaffected, different overlay consumers.
-
Correction to prior commit event: root cause was pm-llmmsgsrv-cc's llmmsg-env consolidation, not a missing wiring on this unit's side - their indirection (source guard) silently failed under both bare systemd env and systemd's native EnvironmentFile= parser (neither executes shell). They reverted to a literal KEY=VALUE bearer in the canonical bin-dir file and verified it against both consumption paths. My earlier fix (Environment=LLMMSG_ENV_FILE=/home/rob/.llmmsg-env override) is REMOVED now that the canonical source is fixed - one bearer source, not two. Re-verified via --probe-elazar against the default (stock) unit config: HTTP 200.
-
Reopened by monitor-context-cc (KPI-46/47 policy seat) on Elazar order 2026-09-03: closed 08-28 with only the hub-DM leg built. Spec required email + Linux notification too; neither exists in kpi-burn-alert.sh (grep: zero mail/msmtp/notify-send lines). Also needs DM fan-out to every elazar CLI session, not one hub DM. Children filed for each missing leg.
-
was: Requirement 4 of KPI-45 (Elazar 2026-08-28): alert Elazar by email/DM/Linux-notification when the fleet KPI data shows misconfiguration, high token burn, high context, or needless turns. Builds on existing collectors (KPI-26 llmmsg-kpi-report.sh, KPI-27 llmmsg-kpi-coach.sh, KPI-29 ccusage-watch.sh burst detection) - this item is the alerting/notification layer on top, not a new collector. Design owner TBD.
-
bin-venus-cc
-
KEPT OPEN AS A CAPABILITY, BLOCKED ON ONE ELAZAR DECISION - deliberately NOT cancelled, unlike its five implementation legs (KPI-52/53/54/55/56, cancelled today). The distinction is the point: kpi-burn-alert.sh, which implemented this, was deleted by Elazar in 38bdd55 'retire agent telemetry tracking stack' (2026-09-24, verified on disk and in git history 2026-10-05; registry row 188 retired). The LEGS were internals of that file and have nowhere to land. The CAPABILITY - alert Elazar on misconfig, high burn, context and needless turns, and a staged offender ladder behind it - is plausibly still wanted and nothing has said otherwise, so cancelling it would delete the intent along with the dead code. BLOCKER: the same single open question recorded on KPI-68 - does the retired telemetry stack come back at all, and in what form. Every input this alerter consumed came from that stack. Until that is answered there is no data source to alert from, so the row cannot advance by effort. Surfacing to Elazar on the CLI, per the standing rule that I never initiate to him on the hub. Not routed to another seat: pmmaster already ruled on the narrower version of this question that a row nobody will take is a scope problem, and this is the scope answer. ALSO RECORDED, because the status was the misleading part: this row read as 'todo' in my queue, which is indistinguishable from not-yet-started ordinary work. A stack retirement silently obsoletes every ticket written against it and the tickets keep presenting as actionable backlog - that is why today's drumbeat counted these as untouched work.
feature
7w ago by wi-cli-venus
1w ago