Comentarios de migraciones aplicadas que afirman poblacion viva: separar estado-al-aplicar de presente-sin-fecha antes de medir
audit-terra-ca censo db/migrations/applied/ entero - unos 60 comentarios en 35 archivos que afirman poblacion viva, clasificados por tipo (conteo, exhaustividad, estado) y por si son chequeables contra la base de terra. El censo respeto su limite sin que se lo recordara: no tiene conexion a la base y no verifico ninguna, y dijo explicitamente que no emitia sospechas. Es la lista, no el veredicto. LO QUE EL CENSO NO SEPARA Y ES LO QUE DECIDE TODO EL TRABAJO: marca como chequeables contra la base de hoy tanto las afirmaciones sobre el ESTADO AL APLICAR como las afirmaciones en PRESENTE. No son lo mismo y tratarlas igual produce el daño exacto que esta fila quiere evitar. "terraPracticas estaba en 0 filas" dicho de una migracion de agosto es CIERTO PARA SIEMPRE - describe el momento en que corrio. Volver a medirlo hoy da 6 y "corregirlo" destruiria historia correcta. Medir esa clase contra la base viva no es verificar, es romper. LA DISTINCION QUE SI SIRVE NO ES EL TIEMPO VERBAL, ES SI LLEVA FECHA. Y no la invente: ya existe en este repo, bien hecha, en terra_53:45 - "Population measurement, 2026-08-31: all 159 live public.users rows have a live Terra membership". Una medicion fechada NUNCA puede volverse falsa, solo vieja, y el lector sabe cual de las dos cosas esta leyendo. Una afirmacion en presente sin fecha se vence en silencio y sigue leyendose como vigente. Ese es el estandar y esta adentro del repo, o sea que es citable y no una regla de estilo que yo agrego. TRES CONFIRMADAS FALSAS HOY, medidas por mi contra la base viva antes de abrir esta fila: - terra_6:59-60 dice "createTerraPractica CANNOT SUCCEED TODAY ... terraCirugias has ZERO live rows". En presente, sin fecha. terraCirugias tiene 78 filas. La frase completa se lee como una limitacion vigente del sistema y no lo es desde hace meses. - terra_22:193-195 dice "pacientes is still 0 rows database-wide". El "still" refuerza que habla del presente. pacientes tiene 6 filas vivas. Y la mitad que la acompaña - "terra still never inserts into it" - es una afirmacion sobre FUENTE, no sobre poblacion, o sea que las dos mitades de una misma oracion se verifican en lugares distintos y una envejecio y la otra no. - terra_1, terra_5, terra_13, terra_14, terra_15, terra_20, terra_23, terra_27, terra_28 tienen la misma forma "0 rows" sobre tablas que hoy no estan en cero. NO LAS CUENTO COMO DEFECTO SIN LEERLAS UNA POR UNA, justamente por lo de arriba: si estan redactadas como estado al aplicar son correctas y no se tocan. DOS QUE MEDI Y SIGUEN SIENDO CIERTAS, anotadas para que nadie las "arregle": users tiene 159 filas vivas y cero sinteticas vivas, que es lo que afirman terra_29:67-68 y terra_53:46-47. La de terra_53 ademas esta fechada, asi que es honesta pase lo que pase. QUE HAY QUE HACER, y el orden importa: primero clasificar cada entrada del censo en (a) estado al aplicar - no se toca, (b) presente con fecha - no se toca, (c) presente sin fecha - se mide y se corrige. Recien despues medir las de (c). Mandarle a db02 la lista entera para verificar seria pedirle que declare falsa la historia. Y LA CORRECCION DE (c) NO ES ACTUALIZAR EL NUMERO. Un numero nuevo sin fecha se vence igual y vuelve a esta fila en tres meses. Se fecha la medicion, como terra_53, o se saca el numero y se deja la consulta - con la salvedad que aprendi hoy por las malas en terra_183: una consulta tambien es una afirmacion y hay que verificarla, no hereda correccion por ser ejecutable. FUERA DE ALCANCE POR NO SER CHEQUEABLES DESDE ACA, y el censo las marco bien: terra_38:18-19 afirma poblaciones de la base de VENUS, y terra_21 y terra_54:348 afirman cosas sobre call sites en fuente. Las primeras se borran en vez de medirse - ningun carril de terra puede consultarlas, igual que el "venus has it on all ten" que ya saque de terra_41. Las segundas se verifican leyendo src, no la base. PROCEDENCIA: censo de audit-terra-ca (tag audit-terra-ca-mti72ms7goy5), pedido por mi despues de que terra_183 apareciera por casualidad. La lane estaba en 82 por ciento de contexto - media hora antes esta misma lane figuraba como inutilizable por tener 16.
Activity
-
Clasificacion devuelta por audit-terra-ca (tag audit-terra-ca-mti7dpyzpf0l), sin acceso a base y sin editar nada. Las tres clases quedaron pobladas y la (c) - presente sin fecha - tiene once entradas vivas, no las sesenta del censo original. O sea que la separacion saco de la cola de medicion la gran mayoria de las afirmaciones, que era el punto. LO MAS VALIOSO ES QUE SE CORRIGIO A SI MISMO Y LO DIJO. Su primer censo habia marcado como chequeables-hoy varias precondiciones historicas de cero filas; al leer la oracion completa las movio a (a) y lo anoto explicitamente como correccion. Y saco terra_20:56-59 de la cola propia iniciativa porque dice "MEASURED 2026-08-16" y su :133-138 repite "measured live this session", o sea clase (b). Un censo que se corrige nombrando que se corrige es distinto de uno que entrega una lista nueva y deja creer que la primera nunca existio. LA CLASE (a) ES ENORME Y ESO ES EL HALLAZGO, no un detalle de conteo: mas de veinticinco archivos - terra_1, 5, 7, 9, 13, 14, 23, 27, 28, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 48, 52, 53, 54 - llevan sus mediciones redactadas como estado al aplicar o con fecha explicita del tipo "Live-verified post-apply" o "MEASURED LIVE 2026-08-22". Esa es la forma correcta y ya es la MAYORIA del corpus. Si le hubiera mandado a db02 la lista cruda del censo para verificar, habria puesto a un carril a declarar falsa la historia de veinticinco archivos bien escritos. La distincion no era pedanteria de redaccion, era la diferencia entre arreglar once comentarios y romper veinticinco. COLA (c) QUE VA A MEDICION, once entradas: terra_3:51-53 tres sign-ins totales; terra_6:59-60 terraCirugias en cero (ya corregido por mi en cf3c894); terra_7:52-53 catalogo vacio y por eso ninguna practica creable; terra_8:51,94 terraPracticas vacia, max=0; terra_15:6-8 pacientes en cero; terra_22:194 pacientes en cero (ya corregido en cf3c894); terra_38:39-40, :111, :118, :122-123 la unica practica viva, terraPracticasCampos vacia, y los "4 de 7 / 7 de 10"; terra_41:15, :83-85, :299-304 alcance cero y default-open; terra_46:13-15, :33-36 pg_default_acl "currently" y tres sequences "right now"; terra_52:216-223 catalogo sin esa fila y pacienteAntecedentes vacia hoy; terra_54:177 "at three live users". UNA ADVERTENCIA QUE VINO DENTRO DE LA CLASIFICACION Y QUE HAY QUE RESPETAR: en terra_41 la parte semantica - que un campo sin filas de alcance queda abierto a todo - es CONTRATO, no poblacion, y no se reemplaza por un conteo. Se puede medir cuantas filas de alcance hay; no se puede convertir la regla en un numero. Es la misma leccion que ya pague en ese archivo. FUERA DE COLA, cada uno por su motivo: terra_21:17-19 y :93-94 son afirmaciones sobre call sites y se leen en src; terra_38:18-19 es poblacion de la base de VENUS y se borra en vez de medirse porque ningun carril de terra puede consultarla; terra_54:348-364 es alcanzabilidad de control flow, no poblacion; y terra_53 queda intacto porque su 159 y su cero-sinteticos son (b) fechados y ademas los confirme vivos.
-
Cola (c) medida por db02-terra-cc, evidencia en agents/db02-terra/evidence/2026-09-01-terra_188-population-claims-remeasure.result.txt con el .sql al lado. Siete afirmaciones muertas y cuatro vivas. MUERTAS: terra_3 "tres sign-ins en total" contra 32/36 en appEvents; terra_7 "terraCirugias vacia, asi que hoy ninguna practica puede crearse" contra 78 cirugias y 6 practicas; terra_8 "terraPracticas VACIA, 0 filas, max=0" contra 6 filas y max=6; terra_15 "live pacientes is 0 rows" contra 6; terra_38 "LA UNICA PRACTICA VIVA" contra 6; terra_38 "terraPracticasCampos esta vacia" contra 3 filas; terra_54 "at three live users" - y esta es la peor de las siete porque NINGUNA lectura posible da tres: el conjunto admin da 1 y todos los usuarios terra dan 169, o sea que no hay predicado bajo el cual la oracion haya sido cierta recientemente. VIVAS Y NO SE TOCAN: el scope 7/7/4 de terra_41, que es seed y no snapshot que envejece; los 6 campos activos de terra_41:83-85; las tres secuencias y el pg_default_acl ya sin service_role de terra_46; y el requiresDetail=0 con pacienteAntecedentes=0 de terra_52. LO QUE NO SE PODIA DELEGAR A UN CONTEO Y POR ESO SE PIDIO APARTE: le pedi que dijera, en terra_7 y terra_8, si la oracion se salva re-fechandola o si la conclusion tambien murio. Contesto que las dos se salvan: son narracion de COSTO Y TIMING atada al momento del apply - la decision de Elazar del 2026-07-30 en terra_7, y en terra_8 que el seed lee COALESCE(MAX,0) en vez de hardcodear el valor - o sea que ninguna afirma el estado actual y ninguna conclusion cayo. Es la distincion entera de esta fila aplicada a dos casos concretos: el numero vencido y la conclusion que sostiene son dos preguntas separadas, y aca la segunda salio viva las dos veces. Y CORRIGIO UNA CITA MIA LEYENDO, NO MIDIENDO: le pase terra_41:299-304 como afirmacion de poblacion y esa linea cae en la seccion de GRANTS. La afirmacion real esta alrededor de L310-342 y la re-midio ahi. La cita venia de la clasificacion de audit y yo la reenvie sin abrir el archivo. Si hubiera medido lo que le mandaron, habria devuelto un resultado correcto sobre la linea equivocada y las dos puntas habrian quedado conformes. Tambien separo, en terra_38, que la mitad estructural sobrevive aunque el conteo muera: cirugiaId=3 sigue retirado y no huerfano. Misma forma que terra_22 - una oracion con dos mitades que se vencen en direcciones distintas. PENDIENTE: escribir las siete correcciones. Es carril mio, .sql de comentario sobre migraciones aplicadas, que no desincroniza nada porque Supabase strippea los comentarios al registrar. terra_6 y terra_22 ya salieron en cf3c894.