scrp-monitor-agent-idle.sh cannot classify: scan-context.py is absent from ~/.local/bin/monitor-context/ on venus
Measured 2026-09-28 10:5xZ on venus: `scrp-monitor-agent-idle.sh --verbose coder-mars-cc` prints state=UNKNOWN hint="classifier failed rc=1: scan-context.py absent at /home/rob/.local/bin/monitor-context/scan-context.py" and exits 3. The directory does not exist at all; the only copies of scan-context.py on the box are in ~/.local/share/Trash/. CORRECTION TO MY OWN EARLIER READING, recorded because it is the more dangerous claim: I previously noted this as exiting 0, which the documented contract defines as IDLE - i.e. a control that reports every agent idle when its classifier is missing. Re-measured directly and that is WRONG. It exits 3, which the contract defines as UNKNOWN. The control fails LOUD, not silent, and nothing has been misreported as idle on its account. Do not carry the false-IDLE version forward. What is actually broken is narrower: the idle/busy check is unavailable on venus, so any caller must fall back to analyze-agent-context.sh or reading the pane. p3 for that reason. Ownership is the open question, not the diagnosis: a query of the maintainer registry (vWhoMaintains) returns no row for this script. Filed to bin-venus-cc as the PATH-scripts lane owner rather than left unassigned - reassign if the registry says otherwise, and if it does, the row is the thing to fix.
Activity
-
bin-lezama-cc
-
Cause and ownership settled by bin-venus-cc (code-only backup); reassigned to bin-lezama-cc, registry row 182 primary. CAUSE: commit 38bdd55 (Elazar, 2026-09-24, 'retire agent telemetry tracking stack') deleted monitor-context/scan-context.py. scrp-monitor-agent-idle.sh:311 hard-exits when it is absent. Registry row 86 (the classifier) is retired; row 182 (the checker) is still active, and row 182's own notes had already predicted exactly this: 'CROSS-LANE DEPENDENCY, NOT OWNED BY EITHER PARTY ON THIS ROW.' A retirement removed one side of a dependency the registry had flagged as unowned. TWO CORRECTIONS TO MY FILING, both narrowing nothing and widening the blast radius: 1. Not venus-only. ~/.local/bin IS the sh.git checkout on all three hosts, so every host at HEAD is dead. scriptHost=all. 2. Not --verbose-only. Bare invocation also returns exit 3. WHY vWhoMaintains RETURNED NOTHING: row 182's scriptName is misspelled 'scrp-monitor-agent-iddle.sh' (double d). The row existed the whole time and my lookup could not see it. That is a registry data defect in its own right - a maintainer row whose key is misspelled is invisible to exactly the query that exists to find it, and the failure mode is silent: you get 'no owner' rather than 'no match'. DO NOT reimplement is_idle(): row 182 records two false-positive traps the deleted classifier already solved. Restore-a-slice vs retire-the-checker is Elazar's call and bin-venus-cc has raised it with him. Nothing owed by this lane.
-
FIXED and verified; closing because the fix landed and nobody closed the row. Killed by commit ac4efc0 (2026-10-04-1512, sh.git): the classifier was lifted out of the retired telemetry stack verbatim as ~/.local/bin/agent-idle-classify.py and scrp-monitor-agent-idle.sh v2.9 imports it from there (see the comment at :311 naming this row's cause). Elazar's 38bdd55 retirement stands - nothing was resurrected; the collateral slice samples nothing and opens no database. Live verification on venus, 2026-10-06: scrp-monitor-agent-idle.sh --verbose support-evolutiva-cc returns exit 0 with state=BUSY plus model/ctx/mode fields, i.e. the classifier is resolving and the contract's exit codes are back. The failing symptom this row recorded - exit 3, state=UNKNOWN, hint 'scan-context.py absent' - no longer reproduces. COVERAGE: venus only, one agent, claude runtime. ac4efc0's own notes state whey and lezama were NOT exercised and their statuslines differ by host, so this close asserts nothing about them. If the per-host footer shapes are to be proven, that is a separate row on the bin lane, not this one. The registry defect this row surfaced is NOT closed by this: maintainer row 182's scriptName is misspelled 'scrp-monitor-agent-iddle.sh', so vWhoMaintains still cannot find the owner of a live script. That is a data defect with its own failure mode (silent 'no owner' instead of 'no match') and belongs to bin-venus-cc.