terra_53 is APPLIED and live on terraParticipantes but its only copy sits in draft/ with no file in applied/ at all - the inverse of terra_29's stale twin, and the third disagreeing apply-record registry found today
FOUND BY THE SWEEP TERRA-158 ORDERED, AND IT IS THE EXACT INVERSE OF WHAT THAT SWEEP WAS LOOKING FOR. terra_29 had a stale draft copy claiming NOT APPLIED beside a real applied file. terra_53 has the opposite defect: db/migrations/draft/terra_53_participante_terra_membership_guard.sql declares in its own first line "APPLIED as Supabase migration 20260831131036 on 2026-08-31" with an applied source SHA-256 of 8a6182ab612095d6f4525f069603aad5d24ce506576662787e7d4071678d7aea, and db/migrations/applied/ contains ZERO terra_53 files. Verified here rather than taken from the sweep. IT IS THE ONLY COPY, SO THIS IS NOT A DELETION. Deleting the draft - the fix terra_29 needed - would destroy the sole record of an applied migration. The action is promotion to applied/, and it is not the same action, which is why the sweeping lane correctly declined to take it. THE DEFECT IS THAT THE DIRECTORY IS THE STATE AND THE DIRECTORY IS WRONG. Anyone answering "what has terra applied" by listing applied/ misses terra_53 entirely. Anyone answering "what is still pending" by listing draft/ is told terra_53 is pending, and only reading its first line contradicts that. It ships a guard that is LIVE on terraParticipantes - INSERT and UPDATE OF userId or deletedAt now require the referenced user to hold a live Terra membership - so the write rule in force on a clinical table has no entry in the set of applied migrations. AND IT IS THE THIRD DISTINCT WAY THIS PROJECT'S APPLY RECORD HAS BEEN WRONG IN ONE DAY, which is the argument for an instrument rather than three fixes. TERRA-156: ten applied migrations with no row in supabase_migrations.schema_migrations. TERRA-158: an applied migration with a stale draft twin asserting the opposite. This one: an applied migration with no applied/ file at all. Three registries - the schema_migrations table, the applied/ directory, the file header - and no two of them agree, with nothing comparing any pair. DO NOT PROMOTE IT ON THE HEADER'S WORD. The recorded SHA is of the APPLIED SOURCE, and the file on disk now carries a post-apply header the applied source did not have, so the hash cannot be recomputed from the current bytes without knowing where the hashed region begins. Moving the file records whatever it contains today as the thing that ran. The attestation has to come from the live migration record - supabase_migrations.schema_migrations holds the statements for 20260831131036 - compared against the file body, not from the header describing itself. SCOPE: confirm 20260831131036 exists in the live migration history, compare its recorded statements against the executable body of the draft file, and only then move the file to applied/ with a note stating what the comparison showed. If the two differ, that is a bigger finding than a misplaced file and it stops there. Verify draft/ once more afterwards: terra_50, terra_51, terra_52 and enamel_XXX_seed_antecedentes_catalog were reported as genuinely unapplied with no applied/ twin, and that claim was not independently checked here.
Activity
-
PROMOTION IS DONE AND VERIFIED, AND THE PUSH IS BLOCKED ON SOMETHING BIGGER THAN THE FILE'S LOCATION. terra_53 is now in db/migrations/applied/ with a header stating what was compared and why: supabase_migrations.schema_migrations holds version 20260831131036 under the matching name, and its recorded statements array diffs byte-identical against the file's BEGIN...COMMIT body plus every substantive comment, differing only in the two-line post-apply annotation itself. Not moved on the header's word - the recorded SHA is of the applied source and cannot be recomputed against today's bytes, so the statement-array comparison is the actual attestation. REPLAY-ORDER.md WAS MISSING IT TOO, AND THAT IS THE HALF NOBODY WAS LOOKING FOR. The ordered list jumps terra_49 straight to terra_29. A replay built from that file would have reconstructed the database WITHOUT fn_terraParticipanteRequireTerraMembership, so the membership rule now in force on terraParticipantes would silently not exist in the restore. Entry added. AND THE OMISSION WAS CAMOUFLAGED BY THE FILE NAMING terra_53 ANYWAY. terra_29's annotation on the line immediately below reads "registration 20260831135235 after terra_53". The string is present, in a sentence about ordering, while the entry is absent. Anyone checking whether terra_53 is covered finds the name and stops - the same shape as TERRA-158's stale twin an hour earlier: the artifact that MENTIONS the thing reads as the artifact that CONTAINS it. THE PUSH WAS REFUSED BY THE PRE-HOOK AND THE REFUSAL IS CORRECT. "REFUSE db/migrations/applied/terra_53_...: cites no authorization tag." terra_53 carries no db-enamel-cc GO and no audit-terra-ca PASS, in any form. I searched: no evidence file in either lane's directory records one, and TERRA-130 carries none. Staged files reset rather than left exposed. I DID NOT USE THE ESCAPE THE HOOK ITSELF OFFERS. Its FIX line accepts a recorded "no tag: predates the convention" as a resolution. That sentence would be FALSE for a file applied today, and writing it would convert a live question into a closed one with a plausible-looking explanation - which is the single most repeated failure in this project's history. The hook cannot tell the difference; only the person writing the line can. THE CONCERN IS NOT MERELY CLERICAL. terra_53's predicate reads Terra membership, which is shared state. terra_29 required a db-enamel-cc GO for ONE SELECT against public.users, on the explicit ruling that a READ of a shared object is a touch and touch is the gate's whole test. If that ruling holds, terra_53 needed the same and is live without it on a clinical table. NOT ASSERTED AS AN UNAUTHORISED APPLY. The likelier case is that tags exist in the applying lane's hub history and never reached the file, which is a documentation defect fixable in a minute. Asked db-terra-ca directly for the verbatim tags with "none" as an acceptable answer, because a reconstruction from memory would be worse than the gap. Blocked there. INCIDENTAL, AND IT CORRECTS SOMETHING I WROTE AN HOUR AGO: the deleted terra_29 draft was TRACKED, not untracked - git reports it as a pending deletion. My TERRA-158 note said untracked and reasoned from that; the memory entry is fixed. The untracked file in draft/ was a different one, terra_29_cirugias_archive_arm.sql. STILL PENDING ON THE TREE, none of it pushable until the tag question answers: the terra_53 promotion, the REPLAY-ORDER entry, and db02-terra-cc's deletion of the stale terra_29 draft.
-
Pushed aa69d07. terra_53 promoted to applied/ with its authorization recorded honestly, REPLAY-ORDER.md gained the entry it was missing (a replay would have omitted the live membership guard), and TERRA-158's stale terra_29 draft deleted in the same commit. The promotion was attested against schema_migrations' recorded statements array, not against the header SHA, which cannot be recomputed once a post-apply header exists. WHAT STAYS OPEN AND IS NOT THIS ROW: terra_53 is live DDL with a db-enamel-cc GO and NO audit-terra-ca Class-A PASS - never issued, because the audit lane has been below usable context since before it was applied. That is written into the file header as an open exception so it cannot read as an oversight or become precedent, and it belongs to the audit-lane availability question already with Elazar.