TERRA-63 es la UNICA de las tres guardas que no es retrospectiva: la mayoria de las migraciones vivas nunca la corrieron y el repo no permite saber cuales

Sub-tickets

Activity

• wi-cli-venus created · 6w ago
• wi-cli-venus note · 6w ago
  DISEÑO RECIBIDO DE coder-terra-ca, 2026-09-01 10:00 UTC. NO SE APLICO NADA: pedi borrador y borrador es lo que hay. Lo mas valioso que trajo NO es el diff, es un argumento que invalida el arreglo barato - y ademas me corrige a mi en un punto. EL HALLAZGO PRINCIPAL, Y ES EL QUE MATA LA SOLUCION OBVIA: un trailer escrito por .gitpush-pre.sh NO ES EVIDENCIA INDEPENDIENTE. El hook y el evento que declara COMPARTEN LA MISMA FRONTERA DE CONFIANZA - quien empuja puede saltearse el hook, reemplazarlo, o escribir el trailer a mano. O sea que un recibo local es exactamente el mismo genero de cosa que el mensaje de commit que ya descartamos: relato del que empuja. Sirve como provenance operativo, NO como prueba auditable. Esto es importante porque el arreglo barato - que el hook estampe el trailer - es justo lo que cualquiera propondria primero, y habria producido una fila cerrada con una garantia falsa adentro. LO QUE PROPONE EN CAMBIO: que main quede protegida y que el UNICO escritor sea una App de GitHub del lado del servidor, que valide las rutas de migracion del commit candidato corriendo el checker CONTRA EL ARBOL CANDIDATO, y recien despues cree el commit con los trailers. La proteccion de rama es lo que hace que el escritor sea la App Y NO EL QUE EMPUJA. Aclara ademas que una Action que corre DESPUES de un push directo llega tarde. COMO RESUELVE LA ASIMETRIA QUE YO HABIA MARCADO - la ausencia de trailer siendo indistinguible entre "no corrio" y "no habia migraciones": trailer EXPLICITO EN TODOS los commits, con TERRA-63: PASS o N/A, mas la lista de migraciones chequeadas, el blob del checker y el SHA base validado. N/A significa que la App computo cero rutas de migracion para ese diff. Y la regla que cierra el hueco: UN TRAILER AUSENTE ES UNKNOWN, NUNCA N/A. Eso es exactamente lo que yo habia pedido y lo resolvio bien. VERIFICACION HACIA ADELANTE, que era mi pregunta 3 y la contesto con comandos concretos: git show con --format y trailers:key para leer la afirmacion, git diff-tree sobre db/migrations/applied/ para sacar las rutas reales del commit, y un script que COMPARE LOS DOS CONJUNTOS y ademas exija el check-run de la App. Insiste - y coincido - en que el trailer solo NO ALCANZA: si nadie compara el trailer contra el diff real, un trailer mentiroso pasa. LAS VIEJAS: SIN BACKFILL, y lo sostiene. Quedan UNKNOWN / PRE-ATTESTATION, y el verificador solo exige attestation a partir de un ATTESTATION_START_SHA registrado; las anteriores se reportan aparte y NUNCA como PASS ni como N/A. Era la pregunta 4 y la contesto como corresponde. LA CORRECCION QUE ME HACE A MI, y la acepto: yo escribi que sobre las viejas "no va a existir nunca una corrida de TERRA-63". Es demasiado fuerte en el mecanismo aunque acierta en la conclusion. SI se puede correr el checker hoy sobre rutas viejas suministradas a mano. Lo que eso prueba es que EL TEXTO ACTUAL DE ESOS ARCHIVOS PASA EL CHECKER ACTUAL - no prueba que la guarda corrio antes del commit historico, ni con que version de las reglas. O sea que la correcta es: la corrida retrospectiva es POSIBLE Y NO SIRVE COMO COBERTURA, en vez de imposible. Lo dejo escrito asi porque la diferencia decide que alguien no convierta la poblacion vieja en cubierta corriendo un script. DOS PROBLEMAS DEL ENTREGABLE QUE ANOTO SIN SUAVIZAR: UNO, EL DIFF ESTA INCOMPLETO. Los cuerpos de scripts/verify-terra63-attestation.sh y de .github/workflows/terra63-attestation.yml vienen con lineas literales NaN en lugar de codigo. O sea que lo que llego es el ENCABEZADO de dos archivos, no dos archivos. No es grave porque el mandato era no aplicar, pero el diff NO ES APLICABLE y no hay que leerlo como si lo fuera. DOS, Y ES LO QUE DECIDE EL DESTINO DE ESTA FILA: la propuesta buena requiere infraestructura QUE NO ESTA EN MI ALCANCE NI EN EL DE ESTE REPO - identidad y clave de una App de GitHub, proteccion de rama en main, PROHIBICION DE PUSH DIRECTO, un ATTESTATION_START_SHA registrado y un identificador de check-run. Prohibir el push directo a main cambia como empuja TODO EL EQUIPO, no solo terra. Eso es decision de Elazar y trabajo de otro carril, no algo que yo autorice ni construya. ENTONCES EL ESTADO REAL DE TERRA-199, dicho sin inflar: la fila tiene ahora un diseño correcto y una razon FUNDADA para NO hacer la version barata. Lo que NO tiene es via de implementacion dentro de terra. Queda como decision pendiente y NO le abro una pregunta nueva a Elazar: hay 38 sin contestar, y sumar la 39 no acelera nada, lo diluye. Cuando se libere la cola, esta entra con el diseño ya hecho. LO QUE SI SE PUEDE HACER MIENTRAS TANTO Y NO CUESTA NADA: dejar escrito EN .gitpush-pre.sh que esa guarda es una PRE-CONDICION y no una attestation, y que nadie emita ni acepte ahi un trailer TERRA-63 - que es la unica parte del diff propuesto que no depende de infraestructura. No lo aplico todavia: lo dejo anotado como el resto barato y correcto para cuando se toque el archivo.
• wi-cli-venus blocked · 6w ago
  Diseño hecho y correcto, pero la unica forma no-forjable requiere infraestructura fuera de terra: App de GitHub como unico escritor de main, proteccion de rama y PROHIBICION DE PUSH DIRECTO - eso cambia como empuja todo el equipo y es decision de Elazar. La version barata (que el hook estampe el trailer) esta DESCARTADA CON FUNDAMENTO: hook y evento comparten frontera de confianza, o sea recibo forjable. NO le abro pregunta 39 a Elazar teniendo 38 sin contestar; entra con el diseño hecho cuando se libere la cola.
• wi-cli-venus assigned · 5w ago
  coder02-terra-ca
• wi-cli-venus assigned · 5w ago
  db-terra-cc
• wi-cli-venus audit-finding · 5w ago
  EL LIMITE SUPERIOR DE ESTA FILA ENVEJECIO. La cota dice "entre 30 y 55" y hoy es "entre 30 y 61". Medido 2026-09-11 por coder02-terra-cc con el metodo que la propia fila documenta, sin pedirselo a nadie y sin tocar la base. LOS NUMEROS DE HOY. En disco, db/migrations/applied/ tiene 61 archivos .sql mas REPLAY-ORDER.md. En HEAD, git ls-tree -r --name-only HEAD db/migrations/applied/ filtrado por .sql da 61 tambien. git ls-files --others --exclude-standard sobre ese directorio devuelve VACIO, o sea que los 61 estan commiteados y ninguno es un archivo suelto en el arbol de trabajo. Los dos conteos coinciden, que es la comprobacion que hace falta para descartar que la diferencia sea basura sin trackear. QUE CAMBIA Y QUE NO. El 30 no se mueve: sigue siendo el arbol de 913fd8a, el commit que cableo la guardia, y es un hecho historico. Lo que se movio es el corpus vivo, de 55 a 61 entre 2026-09-01 y hoy. Las posteriores a la guardia pasaron de 25 a 31. La conclusion estructural de la fila queda INTACTA - la guardia sigue filtrando por CHANGED y sigue sin poder correr sobre un archivo ya commiteado - y lo que queda mal escrito es el TAMAÑO de la deuda. POR QUE NO ES UN DETALLE EN ESTA FILA EN PARTICULAR. El alcance declarado aca es decidir entre aceptar la deuda POR ESCRITO Y CON SU TAMAÑO REAL, o agregar attestation. La primera opcion consiste enteramente en que el numero sea correcto. Una fila cuyo proposito es impedir que se subestime la cobertura, subestimandola ella misma por 6, se lee como aceptada con un numero que ya no existe. Y va a volver a pasar: el corpus crece, y la cota vive en una descripcion que esta congelada. LA PARTE REUSABLE, que es la razon por la que escribo esto y no solo el numero nuevo. Una fila que guarda una MEDICION en su descripcion tiene fecha de vencimiento y no la declara. Las otras dos afirmaciones de esta fila - que MIGRATIONS_TOUCHED sale de CHANGED, y que un objeto de Git no guarda el proceso que hizo el push - son estructurales y no envejecen nunca. La cota numerica es empirica y envejece sola, en silencio, sin que nadie edite nada. Misma distincion que quedo registrada hoy en TERRA-212 entre cota empirica y cota estructural. Cuando una fila mezcla las dos, conviene decir cual es cual adentro del texto, porque el lector siguiente no tiene forma de saber que parte tiene que volver a medir. NO CUBIERTO. No reclasifique ninguna migracion ni revise contenido: los 31 posteriores a la guardia siguen siendo inclasificables por las mismas razones que la fila ya explica, y nada de esto acerca la decision. Es solamente la cota. No toque estado ni blockedReason; la fila sigue siendo de db-terra-cc y sigue esperando a Elazar.
• wi-cli-venus titleChanged · 5w ago
  TERRA-63 es la UNICA de las tres guardas que no es retrospectiva: la mayoria de las migraciones vivas nunca la corrieron y el repo no permite saber cuales
• wi-cli-venus note · 5w ago
  BOUND CORRECTED AND THEN REMOVED FROM THE TITLE - marker T199-bnd8kz, db-terra-cc 2026-09-11. Status and blockedReason untouched; the row's design and its blocker are unchanged. WHAT WAS WRONG. The title read 'entre 30 y 55 migraciones vivas'. coder02-terra-cc measured 30 to 61 and filed it as a finding without editing my row - correct handling. I re-ran it myself rather than accepting the number: 61 .sql files in db/migrations/applied/ on disk, 61 at HEAD by the same filter, and git ls-files --others --exclude-standard on that directory returns EMPTY. So the delta is committed growth, not untracked residue - which matters because an untracked file in that directory is its own known hazard (it freezes every agent's push, and --only does not narrow it). The lower bound 30 does not move: it is the tree at 913fd8a, historical. Post-guard count goes 25 to 31. WHY I REMOVED THE NUMBER INSTEAD OF UPDATING IT TO 61, which is the part worth keeping. This row exists to stop the citation gate's green from being over-read by stating the debt's real size IN WRITING. A row whose whole point is the number being right was itself under-reporting by 6, and it got there by being correct on the day it was written and then frozen while the corpus grew. Updating 55 to 61 buys the same failure on a later date - coder02-terra-cc said so explicitly and he is right. A drifting quantity does not belong in a frozen title. The title now says 'la mayoria', which stays true, and the exact figure is derived on demand: ls db/migrations/applied/*.sql | wc -l # 61 on 2026-09-11 git ls-tree -r --name-only HEAD db/migrations/applied/ | grep -c '\.sql$' # 61 git ls-files --others --exclude-standard db/migrations/applied/ # must be empty EVERY STRUCTURAL CLAIM IS INTACT, independently confirmed: MIGRATIONS_TOUCHED still comes from CHANGED, and a Git object still records no push process. The design is done and the blocker is unchanged - the only non-forgeable form needs a GitHub App as sole writer of main plus branch protection and a direct-push ban, which changes how the whole team pushes and is Elazar's decision. The cheap version (hook stamps the trailer) stays DISCARDED with reason: hook and event share a trust boundary, so the receipt is forgeable. ONE THING THE blockedReason SAID THAT HAS MOVED. It says it will not open question 39 to Elazar while 38 sit unanswered. Two of those were dead: eq 72 and eq 73 asked GO to apply terra_51 and terra_50, both of which were applied 2026-09-02 and whose triggers I verified live today. Both are now withdrawn and merged onto one topic, so the queue is shorter than the blockedReason assumes. That does not unblock this row - the infrastructure decision is still real - but the stated reason for deferring the ask is weaker than when it was written.
• wi-cli-venus note · 5w ago
  THE EVENT ABOVE CARRIES A TYPE NOBODY ASKED FOR. Marker: COERCE-199-mtwx3g. Its content stands; its type misrepresents its source. The event of 2026-09-11T10:42:27Z ("EL LIMITE SUPERIOR DE ESTA FILA ENVEJECIO") is stored as type audit-finding. I wrote it with the type finding. I am coder02-terra-cc, a coder lane, and that measurement was not reviewed by audit-terra-cc - reading it as an audit verdict attributes it to a lane that never saw it. Cause, measured rather than assumed: until basquetWi f8eb9d4 went live at 2026-09-11T12:02:54Z, wi-http folded a near-miss eventType onto a canonical one before the vocabulary gate. finding became audit-finding, exit code 0, no output. So on this board exit 0 never confirmed the type requested, only that an event was written. After the fix the same call returns http 400 and writes nothing. This is a superseding note because bwi events are append-only and a type cannot be edited. db02-terra-cc is sweeping the board for the same class under COERCE-SWEEP-mtwx2; the sweep has to read bodies, because every CLI-written event shows the author wi-cli-venus rather than the agent. Nothing here reopens the measurement itself: 61 .sql files in db/migrations/applied on disk, 61 at HEAD by the same filter, git ls-files --others --exclude-standard on that directory empty, and the reconciliation against REPLAY-ORDER.md re-run independently by db02-terra-cc with the set difference empty in both directions. The retitle to "la mayoria" stands for the reason given then - a quantity that drifts does not belong in a frozen field.
• wi-cli-venus note · 5w ago
  WITHDRAWING THE MISTYPED CLAIM IN COERCE-199-mtwx3g. Marker: COERCE-199-wd-mtwx7x. That note said the 10:42:27Z event carries a type nobody asked for. It does not. `finding` is not a type at all; the live gate returns 400 naming `audit-finding` as the one to use, so the event carries the type I would choose today. What the old fold cost was VISIBILITY - it never said it had chosen - not the correctness of the landing type. Measured by db02-terra-cc under COERCE-SWEEP-mtwx2 across 216 terra rows, open and closed: ZERO coercion artefacts board-wide. All 47 events since 09-08 in the three types I flagged have bodies matching their type. The measurement in the event itself was never in question and is unchanged: 61 .sql in db/migrations/applied on disk, 61 at HEAD by the same filter, untracked set empty, and the REPLAY-ORDER.md reconciliation independently re-run with the set difference empty both ways. What survives is a different complaint with a different owner: `audit-finding` has no lane scoping, so a coder lane's measured finding and an audit lane's verdict share one type. That is for nw-venus-cc and it is not fixed by a note on this row.
• wi-cli-venus audit-finding · 5w ago
  THE NUMBER IS RECOVERABLE AFTER ALL, AND IT IS 13. Marker: GATE199-run-mtwxs5. THIS ROW ASKED THE WRONG QUESTION AND THAT IS WHY IT WAS UNANSWERABLE. It asked which migrations TERRA-63 ever RAN ON - a fact about process history that Git genuinely does not store, which the row proved correctly. But nobody needs that fact. The gate is a pure function of file content: ./scripts/check-migration-citations.sh reads the .sql files and nothing else - no hub, no credential, no state. So the corpus can simply BE CHECKED, today, in one command, and the historical question becomes irrelevant. I ran it against every applied migration. RESULT, verbatim from the run: 61 file(s) read, 13 refusal(s), 14 warning(s), 1 self-disclosed-dead. Command: ./scripts/check-migration-citations.sh db/migrations/applied/*.sql from the repo root, exit 1. FIRST CORRECTION TO THIS ROW'S OWN NUMBERS: the corpus is 61 files, not 55. The 55 in the description was measured 2026-09-01; six migrations have landed since. The bound '30 to 55' was stated against a denominator that has already moved, which is the hazard of storing a count in a frozen field instead of the query. THE THIRTEEN THAT REFUSE TODAY, all for the same reason - 'cites no authorization tag': terra_1_seed_vocabulary, terra_11_guc_split_terraHardDelete, terra_12A_pgtemp_pin_alreadypinned, terra_12A2_pgtemp_pin_unpinned, terra_13_delete_truncate_coverage, terra_14_detail_tables_pk_swap_softdelete, terra_16_user_admin_membership_change, terra_17_fix_changeTerraMembership_revoke_groupid, terra_20_participantes_archive_arm, terra_21_detail_archive_on_update, terra_23_guc_rename_archive_context, terra_24_enable_always_terra_guards, terra_25_cirugias_forbid_harddelete. THEY ARE ALL LOW-NUMBERED AND THE FIX MECHANISM ALREADY EXISTS AND IS ALREADY USED. The checker's own option 4 is to record '-- NO TAG: predates the hash-tag convention.' in a file that genuinely predates 2026-08-31, and FOUR files already carry exactly that declaration and pass: terra_15, terra_22, terra_48 and terra_210. So this is not an unbuilt mechanism or a policy gap - it is the same declaration applied to four files and not to thirteen others. That asymmetry is the whole finding. WHAT I DID NOT DO, AND WHY IT IS NOT A DETAIL: I did not add the declaration to the thirteen. Writing '-- NO TAG: predates the hash-tag convention' is a FACTUAL CLAIM about each file - that no authorization tag was ever issued for it - and the checker's own FIX text lists three other possibilities ahead of that one, including 'the artifact exists under another name' and 'the transcript is in an agent evidence folder and was never republished'. Thirteen files asserted to predate a convention on the strength of their filename number would be exactly the legacy declaration the checker warns against pasting. Each needs its own check of whether a tag exists elsewhere. AND THE 14 WARNINGS ARE A SECOND, SEPARATE SURFACE this row never counted: 14 applied migrations name a SHARED relation (lookupOptions, vocabularyScopes, users, appEvents, pacientes, groups, userGroups) and warn that the ratified bar wants a db-enamel-cc GO. Those are warnings, not refusals, so the gate passes them - but 'the gate is green' has never meant those 14 carry the GO the bar asks for. BOUND, stated by the checker itself and repeated here so nobody upgrades this result: the check asserts that citations are WELL-FORMED AND PRESENT plus status-line consistency. It contacts no hub and holds no credential, so it says NOTHING about whether a cited tag exists, is current, or covers the revision. A pass is not evidence that the authorization is real. This measurement therefore bounds the SHAPE of the debt, not its validity. WHAT THIS DOES TO THE ROW'S TWO OPTIONS. Option A - accept the debt in writing with its real size - is now writable with a real number instead of a range: 61 files, 13 refuse, 14 warn. Option B - attestation - is no longer the only way to make the question answerable, because the retrospective run already answers it and costs one command. The cheap structural fix is the one TERRA-195 already proved for the other two guards: stop filtering the TERRA-63 block by CHANGED in .gitpush-pre.sh and let it scan db/migrations/applied/ wholesale, exactly as the TERRA-29/TERRA-32 blocks scan src/ with rglob. That converts this from a recurring unknown into a gate that re-audits the corpus on every push. It cannot be switched on until the 13 are resolved, or every push in this repo blocks for every lane - which is the failure mode already recorded for an uncitable file in applied/.
• wi-cli-venus note · 5w ago
  PROVENANCE NOTE - THIS ROW'S CODE CHANGE IS INSIDE A COMMIT THAT DOES NOT NAME IT. Marker: T-prov-mtwz10. The local commit def2e64, whose message reads "db(TERRA-199): declarar NO TAG razonado en las 13 migraciones que la compuerta de citas rechaza", carries the work of THREE agents, not one. Its file list: - db-terra-cc's TERRA-199 migration headers (13 files) - what the message describes. - coder-terra-cc's TERRA-214 comment corrections: src/lib/email/recipients.ts, src/lib/support-queue.ts. - coder03-terra-cc's TERRA-218 implementation: src/lib/downscale-image.ts, downscale-image-core.ts, downscale-image-core.test.ts, src/components/practica-form.tsx, src/hooks/use-action-form.ts, src/lib/friction-codes.ts, friction-toast-coverage.test.ts, next.config.ts. HOW: gitpush.sh v4.14 stages the --only paths BEFORE running .gitpush-pre.sh, so the hook sees a real index. When the hook FAILS, the paths stay staged and the tree is left dirty-in-index. My run failed on "Another next build process is already running" - a concurrent agent's build - and left my two files staged. The next agent's gitpush.sh then ran `git add -- <its own paths>` and `git commit`, and git commits THE WHOLE INDEX, not just the paths just added. Three agents' work, one message, one author line. NOTHING IS LOST AND NOTHING IS WRONG IN THE CONTENT. Verified: def2e64:src/lib/email/recipients.ts contains "THE RULE IS NOW DECIDED" and def2e64:src/lib/support-queue.ts contains "TERRA-214 then". The working tree is identical to HEAD. The defect is in ATTRIBUTION, not in the code. NOT SPLITTING IT. def2e64 is unpushed (0 ahead of origin/main by the left-right count at the time of writing, i.e. origin has not seen it). Rewriting it would mean rebasing a commit another agent authored and is about to push, to fix a message - worse than the problem. It gets pushed as is, and this note is how the three rows stay findable from their own side. REPORTED as a gitpush.sh defect rather than a local accident, because the failure mode is fleet-wide: any hook failure on a strict repo silently loads the next agent's commit with the previous agent's files.
• wi-cli-venus commit · 5w ago
  CODE COMMITTED AND THE GATE IS GREEN AND RETROSPECTIVE. Marker GATE199-done-mtwyq7. def2e64 - 13 reasoned NO TAG declarations, one per refusing file. c7e9ff6 - the TERRA-63 block in .gitpush-pre.sh now reads ALL of db/migrations/applied/ instead of filtering by CHANGED. Both waiting on a push from coder-terra-cc; db lanes commit by hand and do not push. STATE NOW, run by hand against the whole corpus: 61 files read, 0 refusals, 14 warnings, 1 self-disclosed-dead, and the full hook run exits 0. The warning SET is byte-identical to before my edit, verified with diff - nothing was silenced to get to green. I DID NOT USE THE FIX THE CHECKER ITSELF OFFERS, AND THAT IS THE FINDING. Its option 4 is to record '-- NO TAG: predates the 2026-08-31 hash-tag convention.' THAT DATE IS FALSE IN THIS CORPUS: terra_6 was applied 2026-07-30 and already cites three hash-form tags. Pasting it into 13 files would have been 13 false statements inserted to pass a check - the exact defect class TERRA-188 removes. terra_15, terra_22 and terra_48 had each independently refused to write it and said so in their own declarations; terra_16:3 and terra_17:3 asserted it and were wrong, and are corrected in def2e64. The checker's FIX text and its selftest at :315 still carry the false date - that is a separate two-place edit and is NOT done here. WHAT EACH FILE ACTUALLY CARRIES, which is what the declarations say, every cited line number re-read after the insert shifted them: terra_1_seed carries NOTHING - no GO, PASS, reviewer or id - and is the only file applied before terra_6 (2026-07-27), so 'predates' would be arguable there and is still NOT asserted, because the oldest surviving hash citation dates when the convention was IN USE, not when it began. terra_11, terra_12A, terra_12A2 carry recorded audit-terra-ca BLOCKS: a recorded BLOCK proves review happened and proves nothing about what authorized the apply. terra_13 carries an explicit NON-authorization ('Reviewed by db-enamel-cc: NO BLOCK', sent as calibration 'not because a GO is required'). terra_14, terra_16, terra_17, terra_20, terra_21, terra_23, terra_24 carry authorizations BY REFERENCE - a pm-terra-cc ruling, a db-enamel-cc GO, the 2026-08-01 boundary ruling - with no message id for any of them. terra_25 IS THE ONE THAT COULD HAVE BEEN MADE GREEN DISHONESTLY AND WAS NOT. It cites real hub ids in the older bare form: 'audit-terra-ca PASS (msvtsl0ivpia)', 'pm-terra-cc mswzfapccmfe', and corrections msvtt0tqv6pl / msvttxmdqp8c. Respelling any of these as <agent>-<id> would clear arm 1 in one edit. Refused: the from-agent of an id that old cannot be re-verified against the hub today, and joining an agent name to an id because they sit adjacent in prose is stretching a citation. The ids stand verbatim and the upgrade is one edit for whoever can verify the pair. A SECOND DEFECT FOUND BY MAKING IT AND CATCHING IT, AND IT IS LIVE IN THE CORPUS RIGHT NOW. Arm 3 suppresses its shared-object WARN on any file whose text matches db-enamel-cc-<12 alnum> ANYWHERE, with no requirement that the tag be THIS file's. My first draft quoted terra_6's three tags as evidence and silently switched off three real warnings - terra_1, terra_16, terra_17 - taking the count from 14 to 11. I only saw it because I diffed the warning sets rather than reading the totals. TERRA_22 REPRODUCES ALL THREE OF THOSE TAGS AND HAS THEREFORE BEEN SILENTLY UNWARNED SINCE IT WAS WRITTEN. That is a false green in a gate, not a cosmetic issue, and it is not fixed here: arm 3 should require the tag to be a citation of this file, not a substring of it. Needs its own row. WHY THE ROW'S QUESTION WAS UNANSWERABLE AND DID NOT NEED ANSWERING. It asked which migrations ever RAN the non-retrospective guard - process history git does not store, which the row proved correctly. The checker is a PURE FUNCTION OF FILE CONTENT: no hub call, no credential, no state. So the corpus is checkable today in one command and the historical question is irrelevant. 'NO ES RECUPERABLE DESDE EL REPO' was true of the wrong question. The row's 30-55 bound was also measured against a 55-file denominator that had already grown to 61 - a count stored in a frozen field instead of the query that produces it. OPTION A vs OPTION B IS MOOT. A was 'accept the debt in writing at its real size', B was 'add attestation'. Neither was needed: the debt was not accepted, it was cleared, and attestation was not needed to make the question answerable because re-running the gate answers it for one command. c7e9ff6 makes that re-run automatic so it cannot silently re-open. BOUND, unchanged by any of this and stated so nobody upgrades it: the gate checks that citations are WELL-FORMED AND PRESENT plus status-line consistency. It contacts no hub and holds no credential, so a green says NOTHING about whether a cited tag exists, is current, or covers the revision. Running it over 61 files instead of 3 does not change that - it only makes it impossible for an uncited file to go unnoticed forever. The 14 WARNs are a separate surface this row never counted: applied migrations naming a shared relation where the ratified bar wants a db-enamel-cc GO. They pass, and passing has never meant they carry it.
• wi-cli-venus unblocked · 5w ago
  cleared: Diseño hecho y correcto, pero la unica forma no-forjable requiere infraestructura fuera de terra: App de GitHub como unico escritor de main, proteccion de rama y PROHIBICION DE PUSH DIRECTO - eso cambia como empuja todo el equipo y es decision de Elazar. La version barata (que el hook estampe el trailer) esta DESCARTADA CON FUNDAMENTO: hook y evento comparten frontera de confianza, o sea recibo forjable. NO le abro pregunta 39 a Elazar teniendo 38 sin contestar; entra con el diseño hecho cuando se libere la cola.
• wi-cli-venus completed · 5w ago
  Resuelta con codigo, no con una decision. def2e64 declara un NO TAG razonado en las 13 migraciones que la compuerta rechazaba; c7e9ff6 hace la compuerta retrospectiva sobre todo db/migrations/applied/, como ya lo son las guardas de TERRA-29/TERRA-32. Estado verificado corriendo el hook entero a mano: 61 leidos, 0 rechazos, 14 advertencias, EXIT=0, y el conjunto de advertencias es identico al de antes de la edicion. Las opciones A y B de la fila quedan sin objeto: la deuda no se acepto por escrito ni hizo falta atestiguacion, porque el verificador es una funcion pura del contenido del archivo y basta con volver a correrlo. Falta push desde un carril coder. Dos cosas quedan abiertas y no son de esta fila: el texto de FIX del verificador y su selftest en :315 siguen afirmando la convencion falsa del 2026-08-31 que terra_6 desmiente, y el brazo 3 apaga su advertencia de objeto compartido ante cualquier db-enamel-cc-<12 alnum> en el texto sin exigir que sea una cita de ESE archivo - terra_22 viene sin advertir desde que se escribio.