venus has no live schema-drift watcher, so every schema-contract test reads a snapshot that can lag prod
VENUS-458 was possible because db/schema.md is a committed SNAPSHOT: VENUS-343 dropped appEvents.path in prod at 07:53:45Z and nothing compared prod's catalog to the repo until a human grep after the outage. Every schema-contract test on venus reads that snapshot, so all of them stay green through exactly the window that matters. Measured 2026-10-06 while implementing VENUS-460: db-schema-watch.service / .timer DO exist on this host at a 15-minute cadence, but they are TERRA-35 and scoped to Supabase project eprpywqwzsvrjeaforei (terra/enamel) - venus is not watched by them. The VENUS-460 live-catalog test arm covers the comparison but is describe.skipIf(!HARNESS_ON), so it does not run on push and reads as a pass when skipped. Options to weigh, not a pre-committed design: (a) extend the TERRA-35 watcher to the venus project id, which is the cheapest if its per-project config is a list; (b) a venus-side unit that diffs the live catalog against db/schema.md on a cadence and pages on a difference; (c) regenerate db/schema.md inside the migration apply path so the snapshot cannot lag an applied DDL - this is the only option that removes the lag rather than detecting it, and it belongs to the db lane. Note (c) and (b) are not exclusive.
Activity
-
The gate this row has to wire now EXISTS and is pushed: scripts/appevents-column-census.ts at b4d03db. Pre-apply form is 'npx tsx scripts/appevents-column-census.ts --migration=<file>' with DATABASE_URL_DIRECT set - it subtracts that migration's literal appEvents DROP COLUMN targets from the live pg_attribute set and exits 1 if any writer still names one; bare form is the post-apply read and exits 2 on an unreadable catalog or a drifted parser. So this row is no longer 'build a drift watcher', it is the narrower and cheaper 'make the pre-apply run unskippable in the db lane's apply path' plus, separately, regenerating db/schema.md inside that same path - which is the only option that removes the snapshot lag rather than detecting it. Until that wiring lands the control is a DOCUMENTED step: VENUS-460's close says so and no instrument should be quoted as enforcement in the meantime.