evolutiva-emaildrain@.service exists on one disk: untracked, unsymlinked, no registry row - and it is now the only thing sending enamel's and terra's mail
GO given by pmmaster-evolutiva-cc on Elazar's behalf 2026-09-11, on bin-venus-cc's own finding. It flagged this rather than acting; this is the work order, so act. THE STATE. ~/.config/systemd/user/evolutiva-emaildrain@.service is a plain untracked file. It is not symlinked from any repo, has no maintainers-registry row, and exists on exactly one disk. As of today it carries enamel (enabled today, first timer run 13:00:01 UTC, success) and terra (verified live at 12:55, Result=success). That is production mail for two apps depending on a file nothing backs up and nothing can age. WHY THIS IS p1 AND NOT HOUSEKEEPING. The whole EVO-94 campaign exists because email was draining through something nobody could observe. The replacement has now inherited the same property one level up: the DRAIN is observable, the THING THAT DEFINES THE DRAIN is not. Lose the disk and the rail is not recoverable from any repo; worse, nobody would know what it had contained, because the per-app case arms are the only record of which apps were cut over and by what method. WHAT TO DO: bring the unit under the same tracking as the rest of the venus rail - repo-tracked source with the deployed path symlinked or installed from it, plus a maintainers-registry row naming you as owner with a lastVerified date. NO SECRETS IN THE TRACKED FILE: the enamel credential lives in the venus .llmmsg-env overlay and is referenced by EnvironmentFile, never inlined. gitcommit.sh v1.2+ aborts on a pre-stage scan hit and that abort is the gate working, not a problem to route around. RECORD THE PER-APP METHOD ON THE ROW, because it is the non-obvious part and it currently survives only inside a case arm: method is per-app, default GET, and enamel overrides to POST because its route answers GET with 405. Emitted as request=$method in the same stdin curl config. A future reader adding the fourth app will otherwise assume GET and get a silent 405. ACCEPTANCE is not 'the file is in git'. It is: the deployed unit and the tracked source are the same bytes, verified by reading both, and the registry row exists with the method note. Say what you did NOT cover.
Activity
-
ACCEPTANCE MET, and the row's premise was already half-stale when I reached it. VERIFIED BY READING BOTH, as the acceptance demands. ~/.config/systemd/user/evolutiva-emaildrain@.{service,timer} are SYMLINKS into /home/rob/Documents/terminal/nw-venus/systemd/; deployed sha256 == tracked sha256 for both, and 'git diff HEAD' on those two paths is empty, so the committed bytes are the running bytes. A symlink is stronger than byte-equality: the two cannot silently diverge. That work was not mine - nw-venus-cc did it on 2026-10-05 under EVO-110 (53d247b), 24 days after this row was filed. The row's 'untracked plain file, symlinked from nothing' was true when written and false when I read it. REGISTRY. Row 233 existed but its scriptLocation still ASSERTED the untracked state - a false claim sitting in the field a coverage reader trusts. Corrected, lastVerified -> 2026-10-06, and the method note + verification written into notes (changelog rows under writer bin-venus-cc). THE ROW DID NOT NAME YOU AS OWNER AND SHOULD NOT: the nw/bin lane split puts the UNIT on nw-venus-cc (runtime) and this seat as backup, code-only. That is correct, so I did not reseat it. THE GAP THIS ROW DID NOT NAME. Row 233 covers the unit only. The unit's ExecStart is ~/.local/bin/evolutiva-emaildrain.sh, which had NO registry row and was NOT in index.md - the script holding the entire method table and the exit-status contract was named nowhere. Filed as registry row 235 (primary bin-venus-cc, backup tbd owed by nw-venus-cc, asked not assumed) and indexed in d3c5a4a. PER-APP METHOD, recorded as instructed: default GET; mars/venus/terra accept GET; ENAMEL IS POST because /api/cron/drain-email-outbox answers a GET with 405. Measured 2026-09-11. It no longer survives only in a unit case arm - it is the dispatch table at evolutiva-emaildrain.sh:130-137, in sh.git and pushed, so that knowledge IS off-disk. A fourth app added on the GET assumption still gets a silent 405. A CONTROL I CHECKED RATHER THAN ASSUMED, because it had actually failed. OnFailure is live: 'systemctl show -p OnFailure' returns failnotify@%i, and the journal has failnotify@venus completing with notify-nw.sh DMing nw-venus-cc (04:19:48 and 04:20:00 on 10-05). The same file carried the classic defect hours earlier - two journal warnings at 04:19, 'Unknown key OnFailure in section [Service], ignoring', against line 16. It is now line 7 under [Unit]. Had I read only the current file I would have reported a working alert path without knowing it had ever been a silently-dropped one. SECRETS: four bearers and four URLs, all via the unit's EnvironmentFile from the git-ignored overlay. Nothing inlined, nothing printed on any path, and missing-url vs missing-bearer are separate errors. WHAT I DID NOT COVER, and one of them is the row's actual concern. 1. THE OFF-DISK PROPERTY IS STILL ABSENT. /home/rob/Documents/terminal/nw-venus has NO git remote ('git remote -v' empty). This row was filed because 'lose the disk and the rail is not recoverable from any repo' - a repo on the same disk does not change that sentence, it only adds a local change history. The sole thing naming that tree is backup-to-pendrive.sh, manual, no timer, needs hardware attached. Filed as EVO-112 p1 on nw-venus-cc, same priority this row carried for the same property; theirs to lower. 2. I did not test a drain. The four timers are active and last ran 00:15:25Z; evolutiva-emaildrain@nosuchapp.service is 'failed' since 2026-09-11 12:56 with status=64/USAGE and the log line 'unsupported email-drain app: nosuchapp' - a deliberate negative case from the EVO-110 work, gate-correct, left alone. Its failnotify has no journal entries, consistent with that failure PREDATING the OnFailure wiring, so nothing was swallowed. 3. The timer cadence, the .timer contents and the per-app enable state are nw-venus-cc's lane and were read, not audited.