Staged offender remediation: escalation ladder (DM -> alert Elazar -> unregister/kill)
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 5 of KPI-45. Elazar policy set 2026-09-03 (supersedes the 08-28 'no auto-stop absent policy' clause): when a KPI collector flags an offender (misconfig/burn/context/turns), escalate in stages. Stage 1 (LIVE, kpi-burn-alert.sh v1.19): DM the offender to pause/reassess scope, model, effort, context; dedupe per agent+kind, cooldown between re-fires. Stage 2 (TODO): after N ignored DMs while still flagged, alert Elazar on every channel from KPI-46 (all CLI sessions, Linux notification on whey/venus/lezama, email). Stage 3 (TODO): still flagged after M more -> unregister from hub (MSG-38 POST /unregister) and/or kill the agent process; DM Elazar the kill record. Proposed N=3 (45min), M=3 more (90min) - Elazar to confirm numbers. Policy owner monitor-context-cc, coder bin-venus-cc.
Sub-tickets — 2/2 done
KPI-55 Canceled high
bvbin-venus-cc
KPI-56 Canceled high
bvbin-venus-cc
Activity
-
parent=#3062
-
bin-venus-cc
-
Elazar GO 2026-08-28: build alongside KPI-46, same detection logic/review pass, don't split. Spec/gatekeeper: nw-venus-cc. Executor: bin-venus-cc. Dedupe+cooldown, no auto-stop absent explicit policy.
-
Shares kpi-burn-alert.sh v1.4 with KPI-46, same timer. Per-pair state keying + TURNS_MIN=5 growth gate + low-confidence marking landed. Live 15min cadence started.
-
Same incident/fix as KPI-46 (shared script/timer): bearer overlay path broke ~17:10 today from a fleet llmmsg-env consolidation, silently 401ing every remediation DM since. Fixed via systemd Environment=LLMMSG_ENV_FILE=/home/rob/.llmmsg-env, verified with --probe-elazar (HTTP 200). This is why remediation DMs required Elazar manually relaying nw-venus-cc's findings instead of firing automatically - the automated leg has been dark since the consolidation landed, not since 08-28. Live again as of 2026-09-01 17:23 ART.
-
Reopened by monitor-context-cc on Elazar order 2026-09-03. Elazar SET the stop policy this item was waiting on: (1) DM offender until it stops, (2) if ignored, alert Elazar on every channel (all CLIs DM + Linux notification whey/venus/lezama + email), (3) still burning -> unregister from hub and/or kill process. Stage 1 (advisory DM, dedupe+cooldown) is built and live (v1.19). Stages 2-3 do not exist; children filed.
-
Staged offender remediation: escalation ladder (DM -> alert Elazar -> unregister/kill)
-
was: Requirement 5 of KPI-45 (Elazar 2026-08-28): when a KPI collector flags an offending agent (misconfig/burn/context/turns), DM that agent to pause/reassess scope, model, effort, or context. Must dedupe (don't re-flag same agent repeatedly in a short window) and cooldown between flags. Explicitly NO automatic stop/kill absent an Elazar-set policy - remediation is advisory DM only until policy says otherwise. Design owner TBD.
-
bin-venus-cc
-
Elazar 2026-09-03 (CLI to monitor-context-cc, nqla 1b/2b/3a/4a): N=2 ignored DMs (30min at 15min cadence) -> stage 2 alert Elazar on all channels; M=2 more (60min total) -> stage 3. Stage 3 = kill tmux pane AND hub-unregister (unregister half waits on MSG-38, kill half ships without it). Same ladder on whey, venus, lezama - no host exemption.
-
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