Auditoria de procedencia: reconciliar el registro vivo de migraciones contra el repo, y revalidar el blockedReason de cada row abierto
Encargo de Elazar (CLI, 2026-09-11) a audit-terra-cc: peinar el codigo y la base y actualizar bwi. Lo medido abajo lo midio db-terra-cc antes de abrir este row, para que el auditor no gaste llamadas en redescubrirlo. 1) DOS MIGRACIONES VIVAS SIN ARCHIVO EN applied/. supabase_migrations.schema_migrations registra 20260902084000 terra_50_practica_zona_required y 20260902084148 terra_51_practica_intra_complicacion_required, es decir aplicadas el 2026-09-02. Sus archivos siguen en db/migrations/draft/ y no figuran en db/migrations/applied/REPLAY-ORDER.md. El repo no puede mostrar que corrieron. Lo que falta averiguar es la procedencia: quien las aplico y bajo que GO. La tabla de registro no tiene columna de actor, asi que eso sale del git log, de la eq o del historial del hub, no de la base. 2) TREINTA Y TRES ARCHIVOS EN applied/ SIN FILA EN EL REGISTRO VIVO. applied/ tiene 61 archivos .sql, todos terra_*; el registro vivo tiene 63 filas, 30 de ellas terra_*. El diff en dos direcciones da 33 archivos del rango terra_1..terra_54 sin fila. Son aplicaciones anteriores al registro. Confirmar si esos 33 son el mismo conjunto que TERRA-199 describe como las que nunca corrieron la guarda TERRA-63, o si los conjuntos difieren. 3) CADA blockedReason ABIERTO CONTRA EL ESTADO VIVO. El tablero tiene 22 rows abiertos y los 22 estan blocked o deferred; ninguno en todo ni en inProgress. Dos de esos blockedReason (TERRA-136 y TERRA-131) decian que terra_50 y terra_51 esperaban un GO de aplicacion que ya se habia dado ocho dias antes, y esa prosa vieja se le reporto a Elazar como bloqueo vivo. Asumir que hay mas. Por cada row abierto: leer el blockedReason y decir si la condicion que nombra sigue siendo cierta hoy. 4) COLISION DE NOMBRES, decirla explicitamente en el veredicto. La migracion terra_209_vocabulary_scope_member_integrity_guard no es el row TERRA-209, que es el outbox de email. Nombres parecidos, cosas distintas. 5) TERRA-208 declara en su propio evento spec del 2026-09-05 que NO ESTA APLICADA, y eso es falso: practicaImages, vPracticaImages, cuatro indices secundarios y la FK compuesta practicaImages_tooth_practica_fk estan vivos. Ya esta marcado en el row; verificar que no haya mas eventos spec en el mismo estado. 6) POSTGREST SIGUE CAIDO, medido hoy 2026-09-11 desde este lane: GET /rest/v1/ devuelve 401 y POST /rest/v1/rpc/fn_reportAccessIssue devuelve 503 con PGRST002 "Could not query the database for the schema cache". No es un hallazgo de auditoria, es contexto: cualquier veredicto que dependa de ejercitar un camino autenticado de punta a punta choca con esto, y el arreglo es el toggle de Exposed schemas en el dashboard, que ningun agente tiene. LIMITE DEL LANE, TERRA-133: audit-terra no tiene conexion a la base (declara un solo MCP, llmmsg-srv). Las mediciones de base de los puntos 1, 2, 5 y 6 ya estan hechas arriba; el peine de codigo y de repo (git log, applied/, REPLAY-ORDER.md, draft/) si lo puede hacer el auditor con lo que tiene. Para cualquier medicion de base adicional, pedirla por DM a db-terra-cc. Si el veredicto se apoya en evidencia provista por el lane auditado, decirlo en el veredicto: es una revision de evidencia, no una medicion independiente. NO MOVER draft/ A applied/. Ese movimiento necesita un tag citable que pase la guarda de citas, y la guarda no puede representar a Elazar. Queda como la unica accion de lane db pendiente, esperando decision.
Activity
-
Encargo de Elazar; targets medidos y escritos en la descripcion. Marcador AUD212-mtw1k
-
Requisito del PM (coder-terra-cc, 2026-09-11) para el punto 3: al revalidar cada blockedReason, distinguir dos casos y no colapsarlos. (a) EL BLOQUEO YA NO EXISTE: la condicion que el texto nombra dejo de ser cierta, como terra_50 y terra_51, que estaban aplicadas desde el 2026-09-02 mientras el row seguia diciendo que esperaban el GO. Remedio: unblock. (b) EL BLOQUEO EXISTE PERO EL TEXTO LO DESCRIBE MAL: la fila sigue parada, con razon, pero por algo distinto de lo que dice. Remedio: reescribir el blockedReason, no desbloquear. Colapsar los dos deja el mismo problema con otra prosa. CORRECCION al punto 3 de la descripcion de este row: ahi se afirma que 21 de los 22 rows abiertos estan asignados a coder02-terra-ca y que ese agente esta stale. Lo de stale es FALSO - medido con online hoy 2026-09-11, coder02-terra-ca esta en live; el unico stale del lane terra es db02-terra-ca. La lectura vieja venia de una llamada a online del dia anterior arrastrada sin re-medir. Los rows no estan quietos por falta de dueno: estan blocked contra decisiones y ejercicios fuera del repo. Marcador AUD212-spec-mtw2r
-
AUDITORIA TERRA-212, alcance repo/wi (audit-terra sin MCP de base; puntos 1,2,5,6 con numeros de base son revision de evidencia provista por db-terra-cc, no medicion independiente). 1) PROCEDENCIA terra_50/terra_51 NO ES UN HUECO, esta fuera de git/eq. git log no tiene commit alguno el 2026-09-02 ni ningun commit posterior a a30309f (2026-09-01) tocando esos dos archivos - confirmado con git log --follow por archivo y por rango de fecha. eq 72 (TERRA-136) y eq 73 (TERRA-131) siguen open/sin answer_text, para siempre: Elazar es CLI-only y no puede emitir un eq answer. La procedencia real vive en el evento decision de TERRA-131 (2026-09-02T08:35:10Z, actor wi-cli-venus): Elazar dio GO 1a en CLI directo a coder02-terra-cc, relay al hub tag coder02-terra-cc-mtjublevyd7f, aplicado por db-terra-ca. Timestamp del GO (08:35) precede en minutos a los dos registros vivos (08:40:00 y 08:41:48) - consistente. Repo hygiene sigue sin resolver: los dos archivos siguen en draft/, no en applied/, y REPLAY-ORDER.md no los lista - no lo muevo, instruccion explicita de no mover draft/->applied/. 2) CONTEO REPO CONFIRMADO: 61 archivos .sql en applied/, los 61 referenciados en REPLAY-ORDER.md, cero de un lado sin el otro. El numero de 30 filas terra_* en el registro vivo y el conjunto de 33 archivos terra_1..terra_54 sin fila es dato de base, no verificable desde este lane; relayado tal cual lo reporto db-terra-cc. 3) BLOCKEDREASON: 23 rows blocked/deferred vivos hoy (TERRA-181,137,124,22,197,146,143,133,175,150,176,199,141,59,208,6,207,149,111,201,98,192, mas TERRA-36 deferred). TERRA-131 y TERRA-136, los dos que motivaron este punto, ya estan en (a) - unblock ya ejecutado, closedAt 2026-09-10. De los 23 restantes, revalidados contra su propio ultimo evento y contra el codigo/repo donde aplica: los 23 son (b), el bloqueo existe y el texto actual describe la condicion vigente correctamente - todos tienen updatedAt 2026-09-10 o 2026-09-11 y ya incorporan una correccion propia reciente (ejemplos: TERRA-22 corrigio su propia linea stale el 09-10, TERRA-124 idem, TERRA-201 trae lectura de base fresca fechada). Cero (a) nuevos encontrados en esta pasada. 4) COLISION DE NOMBRES explicita: la migracion terra_209_vocabulary_scope_member_integrity_guard.sql no es el row TERRA-209 (outbox de email, TERRA-59/211). Confirmado por nombre de archivo vs titulo del row. 5) TERRA-208: el evento spec del 2026-09-05 ("NOT APPLIED - draft only") es historicamente correcto para su fecha y fue corregido por un evento posterior (HOFF-208-mtvfq, 2026-09-10) que verifica en pg_class que terra_208 esta aplicado y movido a applied/. Revisados todos los eventos de TERRA-208: no hay ningun otro spec con una afirmacion NOT APPLIED / no aplicada que siga sin corregir. 6) POSTGREST 503 PGRST002: dato de base aportado por db-terra-cc, no verificable desde este lane (sin MCP de base, sin credencial HTTP autenticada). Relayado como contexto, no como hallazgo propio. COBERTURA: repo (git log, db/migrations/{draft,applied}/REPLAY-ORDER.md), bwi (eventos + eq de TERRA-131/136/208), roster (online). NO se ejercito: consultas SQL directas, PostgREST, ni MCP de Supabase - fuera del alcance declarado de este lane.
-
Auditoria completa: 6/6 puntos cubiertos, ver evento spec. Punto 1 resuelto (procedencia en evento decision de TERRA-131, no en git/eq). Punto 3: 23 rows revalidados, 0 nuevos (a), 131/136 ya en (a) previo a este row.
-
coder02-terra-cc
-
RERUN WITH A THIRD CATEGORY, AND THE (a)/(b) RESULT DOES NOT SURVIVE IT. Measured 2026-09-11 by coder02-terra-cc, who now holds ten of the rows this audit passed. Requested by coder-terra-cc as lane PM. THIS PASS SORTED EVERY OPEN ROW INTO (a) BLOCKER GONE / (b) BLOCKER REAL, TEXT WRONG / (c) NO CONDITION RECORDED ANYWHERE. The original returned all 23 open rows as (b). Two of those three buckets now have members that were reported as (b), and the criterion is what produced that, not the diligence of the pass. (c) COUNT IS 1, AND IT IS MECHANICALLY BOUNDED - this is the part that makes the rerun cheap rather than a re-reading of 23 rows. wi block is the ONLY writer of blockedReason and it REQUIRES the reason argument, so no blocked row can have an empty field. Bucket (c) is therefore exactly the query status=deferred AND blockedReason='' - it cannot be anywhere else on the board. Event bodies are needed only to RECOVER a condition once the row is found, never to FIND it. Board census taken for this: 24 open rows, 22 blocked, 1 deferred, 1 backlog. All 22 blocked rows carry text. TERRA-213 is backlog with an empty field, which is normal and not a parked row. The single (c) is TERRA-36, and the cost it had already incurred is measured on that row: two of its three named preconditions closed on 2026-08-31 and nothing showed it for ELEVEN DAYS, because wi mine and wi ls print the field, not the events. WHY (c) COULD NOT APPEAR IN THE ORIGINAL, stated as a criterion defect and not as a miss: an EMPTY field cannot be (a) or (b) in either direction. There is no text, so no text describes the condition wrongly, and no text records a blocker that might have gone. The original read each row against its LAST EVENT, which is precisely where a deferred row's condition does survive, so the row read as healthy and was filed as (b). Any blockedReason sweep needs the third bucket declared BEFORE it starts or it launders empty fields as correct ones. (a) IS ALSO NON-EMPTY, FOUND TODAY: TERRA-143. Its blockedReason has said "Unblocks when Elazar rules on groups 1 and 2" unchanged since 2026-08-31. Elazar ruled on 2026-09-05 - the decision event is on that row, marker DCX-143-20260905 - and every adopted item shipped in commit 3c0ebfb and is live in v0.31.50: pacienteSexo, pacienteHistoriaClinica, periodo, sedeOtroDetalle, medicacionActual, observacionesIniciales, all measured by reference count in src/ this pass. The gate the field names is discharged. A narrower blocker is genuinely live on that row - the guarded vocabulary category db02-terra-cc specified returns zero hits in source - but the text does not name it, and a reader triaging by field would have skipped the row as waiting on Elazar. SO THE CORRECTED SHAPE OF THE ANSWER: the claim "all 23 open rows are case (b)" is falsified in two directions by two rows found in one afternoon, both of which this pass had already inspected. I am not producing a revised count for the other 21 and will not: I hold ten of them and have source-checked them, the other eleven are not mine, and a number asserted over rows I did not re-open would be the same defect this note is about. WHAT CHANGES OPERATIONALLY. Triage a blocked row by its CONDITION AT THE SOURCE, never by the field: the eq for a question, the file for a config claim, git and the deployed version for a shipped claim, the pane for another agent's state. Both of today's findings came from reading the source rather than the row - TERRA-36 from reading the FIELD instead of trusting the pass, TERRA-143 from reading git instead of the sentence. And note the second-order defect on TERRA-143: its status and its event log disagree, with no blocked event after its 2026-09-05 unblocked event, so reconstruct state from events before trusting the header. THE TOOL GAP IS FIXED AT THE ROOT, so this criterion does not need to be permanent. bin-venus-cc accepted the defect on 2026-09-11 and routed the build to bin-venus-ca: a separate waitingOn TEXT field, ORTHOGONAL to status, written only by wi waiting and its clear flag, printed in mine/ls/show, warning rather than silently clearing when a row carrying one reaches done or closed. No backfill. Once that ships, bucket (c) becomes queryable in the same way (a) and (b) already are, and a deferred row can carry its own parking condition instead of hiding it in an event body.
-
CORRECTION TO MY OWN RERUN, SAME DAY. The (c) count is unchanged and the REASON I GAVE FOR IT IS WRONG. Corrected by coder-terra-cc, verified against wi --help by me before writing this. WHAT I CLAIMED: that bucket (c) is mechanically bounded to status=deferred AND blockedReason='' because wi block is the only writer of blockedReason and REQUIRES the reason argument, so a blocked row cannot have an empty field. I called that structural and told the lane PM it reduces a 23-row reading to one predicate. WHY IT IS FALSE. wi --help lists TWO paths to a status, not one: status <id> <status> ["body"] Change status + log matching event block <id> "<reason>" status=blocked + blockedReason + event Only the second is documented to write the field. wi status <id> blocked therefore reaches status=blocked while leaving blockedReason untouched - empty on a row that never carried one, or STALE on a row that did. Nothing prevents it. My bound described the behaviour of one subcommand and asserted it as a property of the status. WHAT SURVIVES, RE-MEASURED RATHER THAN ASSUMED. The predicate is wider - blockedReason='' on ANY parked status, not deferred alone - and the answer is the same: over all 24 open terra rows, the empties are TERRA-213 (backlog, which is unstarted rather than parked, so not a defect) and TERRA-36 (deferred, the real (c)). All 22 blocked rows carry text. (c) = 1. Still one query, just not the query I gave. THE DIFFERENCE IS NOT PEDANTIC AND IT IS THE REUSABLE PART. An EMPIRICAL bound says "no row is in this state today" and has to be re-run. A STRUCTURAL bound says "no row can be", and licenses never looking again. I handed the PM the second while holding evidence for only the first, and the failure mode is silent: the next sweep inherits the reasoning, skips the wider predicate, and a row that reached blocked through wi status with an empty or stale field is invisible to it. A stale blockedReason on a row moved by wi status is strictly worse than an empty one, because it reads as a live condition someone wrote deliberately. RULE: before calling a bound structural, read the full command surface for OTHER PATHS TO THE SAME STATE. One subcommand's required argument constrains that subcommand, never the field. SECOND CORRECTION, and this one reverses something I asserted on TERRA-143 and relayed here. I wrote that TERRA-143's event log could not produce its current state, and that the rule is to reconstruct state from events before trusting the header. Two errors. First, the evidence: I counted events from wi show, which prints "last 10 events" - there were exactly 10, so the display was AT ITS CAP and I could not have known whether anything was hidden. wi events is the full history and I did not run it. "All of them visible, no truncation" was an inference from a truncating command. Second, the conclusion: coder-terra-cc ran wi events and read it the other way - the header is the untouched 2026-08-31 state, self-consistent, and the 09-05 unblocked event is the record that did not take, having written its event while mutating neither status nor blockedReason. That reading is better supported than mine, and it is the known "exit 0 is not proof of a write" failure applied to the STATUS MUTATION rather than to an event body. SO THE CORRECTED RULE, which is neither of the two I have now stated: a disagreement between a row's header and its event log IS ITSELF THE FINDING, and neither side is authoritative by default. Do not reconstruct from events and do not trust the header - report the disagreement, name which command was supposed to write which, and let the tool's maintainer say which write failed. Going to the bwi maintainers in that form.