Automate the api-images operator-log read (.api-images.log)
The api-images log has NO scheduled reader. It went dark for 24 days (2026-07-30 to 2026-08-23) and nobody noticed, because the only process was ad-hoc: coder-apiimages-cc asking nw-whey-cc for an FTP pull. Why it matters: PURGE_COMPLETED (info plane) is the one observable in this service whose ABSENCE is the signal - a missing line means the daily trash sweep died. An instrument nobody reads is byte-identical to a broken one, which is exactly what happened: LOG_FILE was an unresolved relative path, so every shutdown-plane line (PURGE_COMPLETED, PURGE_FAILED, fatal catcher) resolved against the process CWD at write time and never reached the log. Fixed on branch in 908ed4e; forward coverage only, the lost lines are lost. Also gated on a read cadence: the 14-day CHECKSUM_MISMATCH warn-window criterion (acd8395) counts DAYS OBSERVED, not days elapsed - the clock cannot start until something reads the log daily. Newly feasible: SSH works on this box (port 65002, full account, PHP 8.4.23 CLI present). The 'FTP-only, no SSH, no PHP CLI' constraint in CLAUDE.md was false. A scheduled read is now a normal automation problem, not a hosting limitation. Scope: decide the reader (venus-side cron pulling over SSH vs a host-side script), what it asserts (PURGE_COMPLETED present for yesterday's date; any warn-plane line surfaced), and where it alerts. NOTE: the global self-arm rule bans an agent arming its own recurring poll - the cadence must be assigned by Elazar or a PM, which is why this is a WI and not already running. Blocked until 908ed4e deploys (nw-whey-cc, FTP from whey): before that the shutdown-plane lines still do not reach the log, and a reader asserting against a dark instrument would report healthy silence. mem:box-access-ssh-not-absent, mem:signal-that-cannot-be-false
Activity
-
Done, 94ff364. The row's own blocker was already dead and nobody had checked: it said 'blocked until 908ed4e deploys'. 908ed4e IS deployed - .api-images.log on the box carries an unbroken PURGE_COMPLETED line every calendar day from 2026-08-25 to 2026-09-11, 18 consecutive days. That also closes a separate long-standing 'built and never observed' item: purge_trash_older_than() has now been observed doing real work, not just claiming the watermark - 2026-09-05 files=4 bytes=543692 and 2026-09-08 files=55 bytes=8818250. Before this, only the zero-file case had ever been seen and the function that actually walks and unlinks had never been demonstrated at all. WHAT SHIPPED: agents/api-images-log-reader.sh plus a venus user timer (api-images-log-reader.timer, daily 12:00 UTC, Persistent=true, enabled and verified running under systemd). Read-only on the box - it tails one file and writes nothing there; all state is on venus under ~/.local/state/api-images-log-reader/. ASSERTS: (1) PURGE_COMPLETED present for YESTERDAY, never today - the sweep fires on the first request of a calendar day, so today's line may legitimately not exist yet and asserting on it would produce a daily false alarm. (2) Any warn/error line, de-duped against the last one already reported, so a standing warn does not re-alert forever. (3) A days-observed counter, which is precisely what the 14-day CHECKSUM_MISMATCH warn-window criterion (acd8395) needs - that criterion counts days OBSERVED, not days elapsed, so its clock could not start until something read the log daily. It is now at 1. DESIGN POINTS THAT ARE NOT INCIDENTAL: unreachable is reported as its own condition and never as an all-clear - conflating 'I could not look' with 'I looked and it was fine' is the exact failure this reader exists to remove. The purge alarm is edge-triggered so a multi-day fault sends once rather than daily; new warn lines always send because each is a distinct event rather than a continuing state. It sends as scrp-api_images_log_reader-venus per the fleet sender grammar, not as coder-apiimages-cc - a scheduled script wearing a live agent's name makes an automated alert indistinguishable from something that agent said - registers itself on every run because an unregistered sender's DMs bounce ON THE SENDER, which would lose the alert in exactly the situation it was written for, and names a maintainer plus the stop command in the payload because a scrp-* name drains no inbox. Verified in the systemd shape (env -u LLMMSG_AGENT) on both paths: the healthy run sends nothing, a forced-unreachable run delivered. BACKLOG FOUND ON FIRST READ, triaged and benign: 6 warn lines, all dated 2026-07-30, all from the terra/venus onboarding test session - CHECKSUM_MISMATCH with an all-zero claimed digest on a 160-byte file, and CHECKSUM_UNPARSEABLE with digests of length 5, 8, 16 and 68. Deliberately malformed test input, not customer data. No warn or error line exists anywhere in the log after 2026-07-30. Self-arm: the cadence was assigned by pmmaster-evolutiva-cc holding Elazar's GO, so the ban on an agent arming its own recurring poll does not apply. Box credential stays in the git-ignored ~/.local/bin/.llmmsg-env and reaches the script via EnvironmentFile - no literal value in the unit or the script.