Scheduled GoTrue config-drift check (cron/applog rail, alerts not blocks)

Sub-tickets

Activity

• wi-cli-venus created · 2026-07-30
• wi-cli-venus assigned · 2026-07-30
  coder-pluto-cc
• wi-cli-venus note · 2026-08-01
  Built: --alert mode on scripts/assert-authconfig.mjs (+138/-8, unpushed) + systemd user units pluto-authconfig-drift.{service,timer} on venus, daily 08:10 UTC, enabled, one manual run green (7/7 fields match). Host timer not Vercel cron: the Management-API PAT is account-wide/unscopeable, keeping it off prod runtime env. Drift emails the field diff; a SKIP escalates only after 72h with no successful read. Blocked on INTERNAL_EMAIL_KEY (Vercel Sensitive, unpullable) - asked pm-pluto-cc. Class-A pre-push diff review with audit-pluto-ca (coder-pluto-cc-msaalp47mei6).
• wi-cli-venus statusChanged · 2026-08-01
  Implemented + timer live; holding push on audit PASS + INTERNAL_EMAIL_KEY
• wi-cli-venus note · 2026-08-01
  PUSHED 7fbbff2 v2.22.52, live version-match confirmed (api/app-version 2.22.52, dpl_5AS4Xz2wFp8CYVnPt3CpgRafoKAs). audit-pluto-ca PASS x2 (msaaouv25g7o main diff, msaas1f5ra73 --test-alert delta). Registry rows 93/94 filed by bin-venus-cc, maintainer coder-pluto-cc, backup db-pluto-cc; unit-file/timer/EnvironmentFile plumbing routes to nw-venus-cc per row-38 lane split. REMAINING (WI stays open): the alert leg is UNTESTED, not merely undeliverable - no run has ever entered the email path since none has found drift. Needs (a) INTERNAL_EMAIL_KEY provisioned by Elazar via pm-pluto-cc, (b) one [TEST]-labelled send via --alert --test-alert, (c) a forced throwaway-field drift to exercise detection->mail end to end. Note for future journal readers: the 2026-08-01 11:34:56Z exit-1 run ('AUTHCONFIG_SPEC_PATH set in the runner env - refusing') was me deliberately injecting a drop-in to prove the ExecStartPre guard fails the unit; drop-in removed, clean rerun 1s later. Not a defect.
• wi-cli-venus note · 7w ago
  ALERT LEG PARTIALLY EXERCISED, 2026-08-22 — two of the three remaining items are now demonstrated, not assumed. The key is still missing, so this stays open, but the untested surface is much smaller than the 08-01 note describes. WHAT THE 08-01 NOTE SAID WAS UNPROVEN: 'the alert leg is UNTESTED, not merely undeliverable — no run has ever entered the email path since none has found drift.' That is no longer true of the detection half. (1) FORCED DRIFT — DETECTION PROVEN, against LIVE Supabase, not a fixture. Copied db/state/authconfig.json to a throwaway outside the repo, mutated site_url to https://THROWAWAY-DRIFT-PROBE.invalid, ran WITHOUT --alert via AUTHCONFIG_SPEC_PATH. Result: exit 1, and a correct field-level diff naming site_url, printing expected vs live (live read back as the real https://evolutiva.pensanta.com), plus the why-it-matters line and the resolve-before-pushing guidance. So detection fires on real drift, reads live config, and reports the specific field — the path from 'config differs' up to 'call the mailer' works. Throwaway deleted; the tracked spec was never touched and no Supabase write of any kind was made (read-only). (2) MISSING-KEY BEHAVIOUR — LOUD, PROVEN. Ran --alert --test-alert with the real runner env: 'ALERT NOT SENT — INTERNAL_EMAIL_KEY or OPERATOR_EMAIL unset in the runner env' then 'TEST FAILED — the alert was not accepted by the mailer', exit 1. The no-key case fails visibly and non-zero rather than silently reporting success, which was a design claim and is now measured. Worth recording that the two could not be combined into one run BY DESIGN and that this is correct: --alert refuses outright (exit 2) when AUTHCONFIG_SPEC_PATH is set, per the audit-pluto-ca BLOCK (audit-pluto-ca-msaamorfsj70) — a poisoned unit env must not be able to point the unwatched checker at an attacker-chosen expectation. So forced drift can never be routed into a real alert send, and the detection proof and the mail proof are necessarily separate runs. Not a gap; do not 'fix' it by relaxing the guard. STILL UNPROVEN, and it is now exactly one link: the SMTP hop itself — that a real drift-triggered mail is accepted by POST /api/internal/send-email and arrives at OPERATOR_EMAIL. That needs INTERNAL_EMAIL_KEY in ~/.config/pluto-authconfig/env (Vercel Sensitive, unpullable, must be pasted by hand from a DM). Blocked on Elazar via eq#51/#53, unchanged. DETECTION RAIL HEALTH, same read: timer active, daily 08:10 UTC, seven consecutive clean runs Aug 16-22, every one 'OK — 7 live auth-config fields match'. No drift has occurred, no run has been skipped, so the 72h SKIP escalation has never armed either.
• wi-cli-venus statusChanged · 5w ago
  Board hygiene per pmmaster 10:01: eight rows sat in inProgress at once, which reports nothing. Not actively worked this turn; PLUTO-718 is the single active row. Order: 718, then 688, then the rest.
• wi-cli-venus assigned · 4w ago
  unassigned
• wi-cli-venus statusChanged · 4w ago
  Unassigned and moved to backlog by pmmaster-evolutiva-cc 2026-09-12. The assigned agent did not exist: coder-venus-cc, db-venus-cc, coder-pluto-cc and db-pluto-cc are all absent from the hub roster and have no tmux pane, and venus and pluto currently have no staffed coder or db lane at all. A todo or inProgress row against an absent assignee reads as staffed-and-underway and is neither, so the status was a lie about this row rather than a claim about the work. The work itself is untouched and the priority is unchanged. Cause of the cluster, and it is a fleet-wide pattern rather than a bookkeeping slip: five auto-succession call sites plus resolvePm can leave a row pointing at an agent that has been deregistered, and nothing reconciles an assignee against the roster afterwards. Filed context: 178 rows across these four names, of which 23 carried a non-backlog status. Restaffing venus and pluto is Elazars decision, not a reassignment I can make.