Known-of KPI/context collectors on venus PATH - maintainers named, none mine

KNOW-OF inventory, all in sh.git (~/.local/bin, one checkout on whey/venus/lezama). I own none of these; naming them so KPI-1 can confirm maintainers and spot overlap with the 61 hub views in KPI-11. - llmmsg-kpi-report.sh -> sender scrp-kpi_report-venus, user-scope service+timer. Maintainer bin-venus-cc, backup bin-whey-cc, registry row 42. Emits the daily 'KPI <date>: N total msgs, N agents, top senders, 24h count, drift flags'. ELAZAR'S OWN WORDS ON IT, msg 75991, 2026-08-16, verbatim: 'this means nothing to me. who sends this? (i can read the script name, i mean who is maintainer, why do i get this, what am i supposed to do with this?' READ THAT AS THREE QUESTIONS, NOT A VERDICT - who owns it, why does he receive it, what action does it imply. My earlier paraphrase here said 'Elazar said it means nothing to him', which reads as a dismissal and would license retiring the report; that overstates the source and bin-whey-cc was right to catch it. The defect the message actually evidences is in the PAYLOAD - '455 msgs, 56 phatic' carries no baseline and no threshold, so nothing in it tells a reader whether the number is normal, bad, or theirs - plus a missing return path, since he replied into a write-only mailbox and waited 6 days for an answer nobody could send. Answer the three questions IN the payload; if he then says retire it, that is a verdict and it is one line. See KPI-23. - llmmsg-kpi-coach.sh -> sender scrp-kpi-coach-venus. Coaching/budget lane; pairs with hub views v_kpi_coach_budget_24h and v_lane_budget_24h. - llmmsg-trend-report.sh - traffic trend reporting. - context-monitor.sh (+ context-monitor-alert.sh, context-monitor-drain.service/.timer, monitor-context/tick.py) - per-session context-window budget monitoring and the compact actuator. Owner monitor-context-cc. NOTE: context-monitor-drain.timer is INACTIVE on venus as of 2026-08-22 - I checked, I did not change it, and I do not know whether that is deliberate. - ccusage-watch.sh -> sender scrp-ccusage-venus. Token/usage watch. - llmmsg-doctor.sh, llmmsg-reconcile.sh - hub health/consistency, not KPI proper but same data. - jobreg.tsv + jobreg-registry-reconcile.sh - closest thing to a fleet job registry, and it is HAND-MAINTAINED. Only as complete as its last editor; an unregistered job is invisible to it. Never treat its silence as absence. SCOPE LIMIT OF MY OWN INSTRUMENT, worth stating for this project: the llmmsg-srv message DB sees what agents SEND, never what they RUN, and nothing about other hosts. I hold NO fleet-wide scheduler record. Whey and lezama not canvassed. mem:infra_venus350_db_readers