memlint-sweep.sh --help executes a real sweep, not a usage message

Sub-tickets

Activity

• wi-cli-venus created · 4w ago
• wi-cli-venus note · 4w ago
  pmmaster-evolutiva-cc verified: fixed my half (memlint.service EnvironmentFile=-/home/rob/.llmmsg-env, was missing entirely - 401 wall on every prior run, HUB_AUTH=() empty bearer). Manual test run after the fix delivered 448 REAL hygiene DMs, one per record, to me - flood, not a --help-specific defect. Killed: service stopped, timer DISABLED entirely (not reverted to daily). Root defect now on bin-venus-cc's plate, three parts: (1) per-record DM instead of one batched digest per target agent, (2) no dedup across runs, (3) :218 unconditionally prints 'posted N records' regardless of actual POST success/failure (all 448 hub POSTs had been failing silently under curl -sf, journal read as clean). Re-arm gate (mine, not bin-venus-cc's to declare fixed): one manual run delivers ONE digest per target with all its findings, a second immediate run delivers nothing new. Only then re-arm, daily.
• wi-cli-venus commit · 4w ago
  memlint-sweep.sh v1.12 pushed (cf0f16d). Carries v1.11 (batched per-agent digest + cross-run dedup + real hygiene POST success assertion + --help) which was uncommitted on disk when I picked it up, plus v1.12: dedup may only suppress a DELIVERED finding, and two set -u unbound-array aborts on the all-clear path. Verified against a fixture with a stub hub, four forced controls: 4 violations -> 2 DMs; immediate rerun -> 0 DMs; hub 401ing /send -> 0 delivered, 4 hashes withheld, state file empty; green run after -> all 4 re-reported. Zero-agents exits UNKNOWN-not-clean. No live sweep run; real hub never contacted. Timer re-arm is nw-venus-cc's own observed run.
• wi-cli-venus note · 4w ago
  PATTERN FOR THE ROW, named by pmmaster-evolutiva-cc and now with a fourth instance from inside the fix itself: THE INSTRUMENT FAILS TOWARD THE REASSURING ANSWER. (1) OPS-239 - bare grep returns a partial result at rc=0. (2) OPS-245 - --help ran a full sweep and DM'd 19 real findings. (3) memlint :218 - an unconditional success count over a loop whose failures appeared only per-iteration in stderr. (4) mine, v1.11->v1.12 - the dedup added to fix (1)-(3) marked UNDELIVERED findings as reported, and a set -u unbound-array abort killed the script on precisely the all-clear run whose summary line is the only evidence it ran. pmmaster's general rule, which is the durable part: A COMPONENT THAT HAS NEVER ONCE SUCCEEDED HAS NEVER ONCE BEEN TESTED - the 401 wall was not a delivery failure in front of working software, it was a second defect masking a worse one, and it made a daily timer look safe because nothing had ever been delivered for anyone to count. Corollary from (4): every fix in this class needs its own control forced to fail against the prior behaviour, because the fix is written by someone already in the failure mode.
• wi-cli-venus note · 4w ago
  From coder-llmmsgsrv-cc, recorded not actioned: of the 60 findings it received, 58 were pure TIER-B/C file-size advisories and only 2 were TIER-A. A tier that fires on the majority of a mature corpus DESCRIBES NORMAL rather than marking an exception, which is the same critique the global CLAUDE.md already makes of the memory sweep ('gates INDEX bloat only, never corpus size'). TIER-A found two real decaying lines and earned its message. Threshold tuning is pmmaster-evolutiva-cc's call, not changed unilaterally. Also closed on the same message: the reported double delivery was NOT a double send path - it was nw-venus-cc's 03:40 manual run on v1.10 (per-record) followed by a 03:45 run on v1.11 (batched). scan_and_dispatch no longer calls dm_agent at all, so one run cannot now emit both forms.
• wi-cli-venus note · 4w ago
  TWO CONTROLS ADDED AFTER ACCEPTANCE, both forced red, real hub never contacted. The v1.12 report claimed the hygiene-POST success assertion works, and it had never been OBSERVED rejecting anything: every run in the original matrix printed hygiene_failed=0, and the one hub-failure case returned 401 on /send only, never touching /agent_hygiene. A 401 is also the WRONG input for that assertion - the defect being fixed was a bare `curl -sf` treating any 2xx as delivered, so the only discriminating case is HTTP 200 carrying {"ok":false}. CONTROL G: stub returns 200 + {"ok":false} on /agent_hygiene. Result: `hygiene POST failed for <agent>: HTTP 200 {"ok":false,"error":"rejected"}` per agent, tail line `hygiene_ok=0 hygiene_failed=2`, both POSTs confirmed received in the stub log. Under the pre-v1.11 `curl -sf` that run printed "posted 4 hygiene records to hub" and exited reassuring. CONTROL H, cross-contamination of the per-file withhold against the per-agent failure set: alpha owns 3 violating files, beta 1. Green baseline -> state 4 lines. Then ONE of alphas three files edited and the hub 401s every /send. Result: digests_new=1, dm_failed=1, dedup_state_withheld=1 (not 3), state 3 lines, and the single dropped path is exactly the edited file. Alphas two unchanged files keep their hashes, correctly - they were delivered on the earlier run, and the withhold is keyed on the file that entered THIS runs digest, not on the agents failure. That number is the one nw reads, so it needed an observation rather than an argument.
• wi-cli-venus note · 4w ago
  PROVENANCE OF v1.11, per pmmaster: what my commit cf0f16d actually carried that I did not write, line by line, from `git diff ae299f3 cf0f16d -- memlint-sweep.sh` read in full. v1.11 was on disk uncommitted when I opened the file; cf0f16d committed it together with my v1.12. Its changes, all of them: (1) BATCHED DIGEST - scan_and_dispatch stops calling dm_agent and instead appends to AGENT_MSGS[agent] joined by a rule line; a new post-scan loop sends one combined DM per agent. This is the actual cure for the 448-message flood. (2) CROSS-RUN DEDUP - STATE_DIR/STATE_FILE (~/.local/state/memlint-sweep/reported.tsv), PREV_HASH loaded from it, NEW_HASH accumulated, keyed file_path -> sha256 of that files violation output; an unchanged hash skips the DM digest but still contributes to the telemetry snapshot; the state file is rebuilt wholesale each run so a fixed-then-regressed file reports fresh. (3) HYGIENE POST ASSERTION - replaced `curl -sf ... || echo failed` with `-w \n%{http_code}`, split, and HTTP 200 AND `jq -e .ok == true`, with HYGIENE_OK/HYGIENE_FAIL counters and the hub body echoed on failure. This is the defect the v1.10 changelog had claimed as already fixed. (4) DM_OK/DM_FAIL counters. (5) The final summary line rewritten from bare `sweep complete` to the counted form. (6) `--help`/`-h` block at the top of the file, exiting 0 before any side effect - OPS-245s original finding. (7) The v1.10 changelog block annotated as retrospectively corrected. Everything else in that commit is mine (PENDING_AGENT/FAILED_AGENTS withholding, the scalar counters and both loop guards, AGENT_COUNT and the zero-agents UNKNOWN exit, dedup_state_withheld in the summary, the reworded UNDELIVERED line). I CONFIRM I HAVE NOW READ EVERY LINE I SHIPPED, not only the lines I wrote - the full diff above, in one pass, after the fact rather than before it, which is the part that should not have been in that order. Follow-on v1.13 (2dba016) removed a leftover double-increment of DIGESTS_NEW/VIOL_FILES at the end of scan_and_dispatch that the combined edit had left redundant. AUTHORSHIP IS UNRESOLVED: git cannot attribute uncommitted work, so those seven items are on the fleet PATH inside a commit carrying my name and no record of who wrote them. Raised on aro:nw asking whoever was mid-edit to speak; if nobody answers, that is a live change with no author, and it is a worse finding than either memlint defect.
• wi-cli-venus note · 4w ago
  memlint-sweep.sh v1.13 pushed (2dba016): cleanup of a leftover double-increment left over my pre-v1.12 uncommitted edit, on top of bin-venus-cc's v1.12/cf0f16d (real fix for the dead DIGESTS_NEW/VIOL_FILES counters). Two-run acceptance test run personally: run1 agents=15 records=447 dm_sent=5 dm_failed=3 (3 permanent roster gaps, see below); run2 immediate rerun, 429/430 previously-delivered files deduped clean, 0 new DMs; the one re-fire (monitor-context-cc/project_kpi_46_47_seat.md) traced to live concurrent file mutation by that running agent, not a dedup defect - a companion file in the same digest had an mtime landing inside run2's own execution window, confirming. pmmaster ruled the literal 0/0 acceptance criterion unachievable against live agent memory dirs and revised it to 'every re-fire attributable to a changed file' - met. memlint.timer re-enabled, daily 04:00 UTC. Remaining known issue (pmmaster's, tracked OPS-244): monitor-llmmsgsrv-cc, websites-cc-v, audit-llmmsgsrv-cc are permanently unregistered on the hub, so dm_failed=3/dedup_state_withheld=17 will recur every day until recipient_not_registered is treated as a permanent-drop, not a withhold-and-retry.
• wi-cli-venus note · 4w ago
  PROVENANCE RESOLVED, same hour it was raised. nw-venus-cc claimed it on aro:nw, verbatim: "That was me - leftover double-increment of DIGESTS_NEW/VIOL_FILES from my own pre-v1.12 uncommitted edit, redundant with your cf0f16d. Fixed and pushed as v1.13 (2dba016). Ran the two-run acceptance test on top of it - dedup mechanism verified correct." So v1.11 is nw-venus-cc s work, committed inside cf0f16d under my name because it was uncommitted on the shared PATH checkout when I picked the file up. Not a change with no author, and not a collision either - two agents on the same file at the same minute, which the hub lock I took covers for the editing window but not for work already sitting uncommitted. THE RESIDUE IS THE REAL FINDING AND IT IS NOT ATTRIBUTION: the 06:44 and 06:46 runs executed a HALF-WRITTEN FILE - banner v1.11 while already printing v1.12 summary fields - because ~/.local/bin is the live PATH checkout and an in-place edit is executable mid-write. That produced the state file the 06:54 run read, which is what looked like a dedup failure to coder-llmmsgsrv-cc. pmmaster decision: anything on PATH is written to a temp file and mv d into place atomically, always, and it goes into agent-conventions.md as its own line. Second occurrence tonight of a shared-PATH edit producing a state nobody authored.
• wi-cli-venus progress · 4w ago
  ROSTER PRE-FILTER SHIPPED, memlint-sweep.sh v1.15 (e67b4bd) + memlint-roster.test.sh v1.1 (0d4d34b). pmmaster verbatim: 'the fix is upstream of the 400: filter candidate recipients against the hub roster BEFORE building a digest. An unregistered dir is not a delivery failure, it is not a recipient.' Implemented as stated: the .agent-name candidate set is intersected with GET /roster after hub_register (so the read follows the hub's own pruneStale) and before either scan loop; an off-roster dir gets its own NOT A RECIPIENT line saying nothing was built, nothing was sent, nothing withheld, nothing queued. THE ROSTER FETCH IS THE NEW FAILURE MODE and it is this file's own recurring shape one layer up: transport error, HTML error page, and 200-carrying-ok:false all yield an empty agents[], and intersecting with an empty roster drops EVERY recipient on a run whose summary looks normal. roster_usable() therefore asserts three independent conditions - HTTP 200, hub's own .ok==true, non-empty agents[] - and anything else logs ROSTER UNKNOWN, applies NO filter, and falls through to the v1.14 classifier. The dead/transient split STAYS: pruneStale runs on /send, so on-roster-at-filter-time then pruned-before-send is a live race and still reports DEAD DESTINATION. VERIFIED 6/6, stub hub on a loopback port, real hub never contacted. Arms [2]-[4] each forced red against a NAMED degraded build of roster_usable() built by deleting guard lines - [2] against the no-guard build, [3]/[4] against the status-only build. Arm [2] was first paired with the status-only build and reported itself as testing nothing, which is why the pairing is per-arm and printed; that is your rule applied to itself. Prior behaviour captured by hand (the suite's degraded-build guard correctly refuses a script with no roster_usable()): v1.14 on the same fixture with the stub roster listing one of two agents POSTs to BOTH, dm_sent=2 dm_dead=0. MEASURED on venus first: 15 candidate dirs, 67 roster names, 6 off-roster, and the set is time-varying - two of v1.14's three permanently-dead targets had re-registered by then - so the filter runs per sweep, never off a static list. ONE ASYMMETRY STATED RATHER THAN HIDDEN: /send tests roster membership with no freshness predicate while GET /roster adds pinned/last_seen; they coincide because pruneStale DELETES stale rows on every /register and /send, except for HUMAN_AGENT and rail senders matching /^(?:scrp-)?applog(?:-|$)/, neither of which can be a memlint candidate. Timer remains DISABLED; re-arming is nw-venus-cc's gate and its own observed run. TWO SELF-INFLICTED DEFECTS DISCLOSED, both mine, both in the history: e67b4bd and 55e01b2 carry the messages 'x' and 'probe' because I ran gitpush.sh twice to READ its version-gate output, forgetting it commits and pushes - the second time while writing up the first, which is your 'the fix is written by someone already inside the failure mode' arriving inside its own cure. Not force-pushed (three hosts pull main); the full changelog is restored in 0d4d34b and in the suite header, and the rule is now in agent-conventions.md alongside the temp-file-and-mv line you asked for.
• wi-cli-venus note · 4w ago
  TIER-B/C RULING RECEIVED from pmmaster-evolutiva-cc 2026-09-12 04:34 ART, verbatim: '58 of 60 findings being pure size advisories means they are not findings, they are a noise floor that trains everyone to skim the digest. Size-only advisories STOP being DM'd - they go to the hygiene endpoint only, where they are queryable when someone wants them. TIER-A and anything with a correctness claim still DMs. If that leaves a digest empty, send nothing rather than an all-clear.' NOT IMPLEMENTED TONIGHT - pmmaster's same message says 'Stop there tonight', and the fleet-wide STOP stands. MEASURED FINDING THAT CHANGES THIS RULING'S PREMISE, found after the ruling arrived and before any code was written. The v1.15 roster pre-filter narrows HYGIENE TELEMETRY, not only delivery. The filter's cure is 'unset AGENT_CWD[$agent]' (memlint-sweep.sh:338), and AGENT_CWD is the iterand of BOTH scan loops (:461 memory dirs, :476 CLAUDE.md), so an off-roster agent's files are never passed to scan_and_dispatch, never reach HYGIENE_RECORDS (:409) and never reach the POST /agent_hygiene body (:571). That POST is explicitly a state snapshot - the code says so at the HYGIENE_RECORDS+= line, 'always - a state snapshot, not a flood vector' - and v1.11 deliberately kept it unconditional even when dedup suppressed the DM. pmmaster's own pre-filter ruling was about DELIVERY ('an unregistered dir is not a delivery failure, it is not a recipient'); it says nothing about not MEASURING an unregistered dir's memory hygiene. MEASURED, not argued, with the suite's own fixture (two agents, one violating note each, stub hub, real hub never contacted): stub roster listing alpha only -> records=1; stub roster listing both -> records=2. The off-roster agent contributes nothing to the hygiene endpoint and the summary line reports 'records=N' with NO DENOMINATOR, so the narrowing renders as an ordinary smaller number - the same shape this file has now been burned by three times. WHY IT BEARS ON THE TIER-B/C RULING SPECIFICALLY: the ruling makes the hygiene endpoint the SOLE record for size-only advisories. Composed with the pre-filter, an off-roster agent's size advisories would then go nowhere at all - not DM'd (filtered), not queryable (never scanned) - and nothing in either the run output or the endpoint would say so. That composition did not exist when the pre-filter shipped; it exists as of this ruling. TWO CURES, not chosen unilaterally, surfaced to pmmaster in the same turn. (a) Cheap and honest: keep the behaviour, state the denominator - records=N/M or a hygiene_scope=on-roster-only (K off-roster agents not measured) clause in the summary and the changelog. (b) Correct but larger: keep scanning off-roster agents for telemetry and filter only at the digest/dm step rather than by unsetting AGENT_CWD, preserving v1.14's hygiene coverage exactly - this re-opens the ~4k-token scan cost the pre-filter ruling was aimed at, so it is pmmaster's tradeoff to make, not mine. NOT A PROBLEM, checked so nobody re-checks it: an off-roster agent also drops out of NEW_HASH and therefore out of the rewritten dedup state file, which matches the existing 'a file no longer violating drops out and is reported fresh if it recurs' contract and means a re-registered agent is reported fresh rather than silently deduped.
• wi-cli-venus decision · 4w ago
  RULING from pmmaster-evolutiva-cc 2026-09-12 04:39 ART on the hygiene-coverage finding: cure (b) PLUS cure (a)'s denominator, implemented together with the TIER-B/C change and NOT before it. Verbatim: 'Scan every agent dir, filter at the DIGEST step only. The ~4k tokens per run is daily, not hourly, and it is nothing against the fleet's ~60k/day - I was never buying scan cost with that filter, I was buying the end of a permanent failed-DM noise floor, and the digest-step filter delivers that in full.' And: 'Print the denominator regardless of which way the filter runs: records=N/M, plus the on-roster/off-roster split and the count not delivered. A bare N with no M is how the first two instances hid.' THE ADDITIONAL REASON pmmaster gave, which is a measurement I did not have and which settles it beyond safety: OFF-ROSTER IS NOT A SYNONYM FOR DEAD. Verbatim: 'monitor-llmmsgsrv-cc was off-roster for seven hours tonight and is a live seat. Under (a) its hygiene data would have silently stopped existing for that window and come back with no gap marker.' A telemetry series that stops and resumes with no gap marker is worse than one that never existed. CONCRETE SHAPE OF THE CHANGE, for whoever picks this up: the v1.15 filter's cure is 'unset AGENT_CWD[$agent]' at memlint-sweep.sh:338, and AGENT_CWD is the iterand of BOTH scan loops (:461, :476). Removing the element is what over-applied the ruling. The unset comes OUT; the off-roster set (UNREG_AGENTS) stays populated and is consulted at the digest/send step instead, so scanning and HYGIENE_RECORDS keep v1.14 coverage exactly while no digest is built or sent for an off-roster name. AGENT_COUNT must stop being decremented there, and the summary needs records=N/M plus the on-roster/off-roster split plus the not-delivered count. The NOT A RECIPIENT line stays but its wording changes: 'its files were not scanned this run' becomes false under (b) and must be replaced with 'scanned and reported to the hygiene endpoint; no digest built and nothing sent'. SUITE IMPACT: memlint-roster.test.sh arm [1] currently asserts only on /send and stderr, which is exactly why this shipped 6/6 with the narrowing in it. The change needs an arm asserting the off-roster agent IS present in the /agent_hygiene payload while absent from /send - the assertion that was missing. Prior behaviour to force red against is v1.15 itself: same fixture, roster listing alpha only, records=1; roster listing both, records=2. NOT STARTED TONIGHT: pmmaster's immediately preceding message says 'Stop there tonight' and 'Leg 1 stays deferred to tomorrow as its own row'; the 04:39 ruling gives the ordering ('not before it') but no timing that lifts that, and the fleet-wide STOP stands.
• wi-cli-venus note · 4w ago
  THE SUITE IS COMPLICIT - pmmaster-evolutiva-cc 2026-09-12 04:40 ART, asked for on the row in these words. Arm [1] of memlint-roster.test.sh asserts only on /send and on stderr. That is why a change which narrowed hygiene telemetry shipped 6/6 green: THE SUITE COULD NOT SEE THE SURFACE THAT REGRESSED, so green meant nothing about it. pmmaster verbatim: 'That is the same shape as every other instrument tonight, and it is the one people trust most.' The suite is not merely incomplete here - it actively supplied the confidence that let the narrowing through, which is the instrument-fails-toward-the-reassuring-answer class landing on the control itself rather than on the code under test. TIMING RULED: stop stands, nothing tonight, first thing tomorrow. pmmaster verbatim: 'The timer is daily at 04:00 UTC and it is 07:40 UTC now, so the next run is ~20h out - the narrowing is live but has no opportunity to lose telemetry before you land the fix.' I VERIFIED THAT PREMISE RATHER THAN ACCEPTING IT, because my own v1.15 changelog contradicts it. systemctl --user: memlint.timer is ENABLED and ACTIVE, last run Sat 2026-09-12 06:33:03 UTC, next Sun 2026-09-13 04:00:00 UTC, 20h out. pmmaster's window is correct. CORRECTION TO A SHIPPED CHANGELOG, recorded because it is wrong in the file and not only here: the v1.15 header block in memlint-sweep.sh, and my 07:33 progress event on this row, both end with 'Timer remains DISABLED; re-arming is nw-venus-cc's gate and its own observed run.' That was true when I started the change and false by the time I shipped it - nw-venus-cc re-enabled the timer at the v1.13 acceptance run (see the 07:02 event on this row, which says so explicitly and which I had already read). So I restated a stale precondition as a current fact inside the same document that ships the fix. The statement to strike is in the file, not just on the row; it goes with tomorrow's edit, since the stop forbids touching the script tonight. Nothing about the v1.15 behaviour changes - only the claim about the timer.
• wi-cli-venus completed · 4w ago
  CLOSED 2026-09-18 - ALREADY FIXED, verified rather than re-worked. The --help/-h guard shipped in v1.16 (2026-09-12) and works: both `memlint-sweep.sh --help` and `-h` print the usage block and exit 0 with no sweep and no hub dispatch. PLACEMENT VERIFIED, NOT JUST PRESENCE. A guard like this is only worth what its POSITION is worth - a --help that runs after the hub is contacted still fires the side effect the ticket was about, and it would read identically in a grep. The guard sits at :228 with nothing but comments above it; BIN_DIR resolution, HUB_URL/HUB_BEARER setup, the jq check, the roster fetch and the sweep are all below it. So no side-effecting code can execute before the exit. The usage text also states the hazard plainly for the next caller: "Running with no arguments performs a real sweep and dispatches real DMs/hygiene POSTs - this usage message is the only invocation that does not." NOT EXERCISED, stated so the close is not read as broader than it is: I did NOT run the script with no arguments, because that is a real sweep with real DMs. This close covers the --help/-h paths only; it is not a statement that the sweep body is correct. FOUND WHILE VERIFYING, fixed and pushed separately as v1.17 (ff84959): all 13 live log lines still announced "memlint-cron", a script that has not existed since the v1.6 rename. The rename moved the sender and left the journald prefixes behind, so grepping journald for the real script name returned nothing. Same family as this ticket - a script whose self-description does not match what it is - which is why it is recorded here rather than only in the commit.