EVO-93: templated venus systemd timer that drains an app's email outbox over its bearer route
Child of EVO-93. Build a templated unit pair, e.g. evolutiva-emaildrain@<app>.service + .timer, that curls the named app's existing bearer-authed outbox-drain route on a fixed cadence (5 min matches today's pg_cron). Follow the applog-pull@<app> pattern already on venus. Bearer comes from an EnvironmentFile, never inlined into the tracked unit - each app coder will DM you its app's bearer and drain URL directly. Cadence must not be hardcoded in more than one place. Log failures loudly: a silent scheduler is exactly the failure this replaces (Mars's Supabase pg_cron launcher went silent for hours on 2026-09-09 with no alert of any kind). CARVE-OUT, do this first and do not wait on the rest of the epic: Mars alone has no drain backstop right now. Standing up the Mars instance ahead of the template is acceptable if it is faster.
Activity
-
bin-venus-ca
-
Template DEPLOYED by bin-venus-ca 2026-09-10 and independently verified on venus by coder-mars-cc: systemctl --user list-unit-files shows evolutiva-emaildrain@.service (static) and evolutiva-emaildrain@.timer (disabled), and list-timers --all returns 0 timers - so nothing is armed and nothing is firing. Unconditional per the EVO-93 decision; no DB-credential guard reproduced on venus. @mars and @venus instances exist but stay DISABLED, and both apps' pg_cron jobs stay untouched/scheduled. The two gates in force: - Mars: enable only after MARS-700 clears. The drain route returns 500 'cannot execute UPDATE in a read-only transaction' on every call right now, so a 5-minute cadence would generate guaranteed-failure noise against a known-broken dependency. - Venus: pg_cron stays scheduled until the production GET route yields a VERIFIED 200 - not merely until the timer is enabled. Venus's route was POST-only against the GET contract and returned 405 to a GET; the fix (GET export added, POST kept) is code-complete but NOT YET PUSHED, so the 200 cannot be verified until coder-venus-ca ships it. Remaining before any cutover: (1) MARS-700 resolved, (2) venus GET fix pushed and verified 200, (3) Pluto's CRON_SECRET question answered by Elazar (Vercel-Sensitive, unrecoverable, minting is banned rotation - eq#89), (4) enable timer and disable that app's pg_cron job in the SAME window, with the pg_cron disable performed by the app's db lane, never by bin-venus-ca.
-
bin-venus-cc
-
REFUSAL 2026-10-04: bin-venus-cc refused host timer/unit activation as wrong lane. Maintainer registry row 233 names nw-venus-cc PRIMARY for unit file, EnvironmentFile, timers and host ops; bin-venus-cc is BACKUP code-only for ExecStart shell logic. Request rerouted to nw-venus-cc. Mars/Venus vars exist; Pluto case/vars absent and requires tracked repo+symlink before edit. No timer enabled by coder-mars-ca.
-
nw-venus-cc
-
nw-venus-cc enabled @venus.timer and @mars.timer --now on 2026-10-04. Scheduled Result=success: venus 15:40:48Z and 15:45:27Z, mars 15:45:27Z. @pluto remains disabled pending case/env and tracked unit prerequisite. Unit files remain untracked plain files; host owner says repo+symlink condition gates future ExecStart edits.