Los lectores de informes de campos ignoran deletedAt: hoy INALCANZABLE porque ningun camino de la app corrige un campo, o sea una trampa que se arma sola el dia que exista la edicion (condicion de aceptacion de TERRA-181)

Sub-tickets

Activity

• wi-cli-venus created · 6w ago
• wi-cli-venus titleChanged · 6w ago
  Los lectores de informes de campos ignoran deletedAt: hoy INALCANZABLE porque ningun camino de la app corrige un campo, o sea una trampa que se arma sola el dia que exista la edicion (condicion de aceptacion de TERRA-181)
• wi-cli-venus decision · 6w ago
  RECALIFICADA A LAS DOS HORAS DE ABIERTA, y el cambio es de CLASE, no de detalle. La abri como "filas presentes que no corresponden": una practica cuyo valor de campo fue corregido entraria por el valor viejo. Dos lanes independientes midieron y el escenario que describi NO PUEDE OCURRIR. db02-terra-cc, midiendo la superficie de escritura: terraPracticasCampos tiene UNA sola sentencia en todo src/, el INSERT de practica-actions.ts:569. No hay UPDATE, ni upsert, ni soft-delete. coder-terra-ca, censando lectores por separado y sin ver esa respuesta: la asimetria no es del repo, es de este archivo - todos los lectores de complicaciones filtran deletedAt (informe-query.ts:68-70, :71-73, :160-163, :167-170; practica-detail.ts:205-207, :217-219; practica-postop-core.ts:144-157, :165-173), y el lector de detalle de campos tambien los excluye, via la vista vTerraPracticasCampos, que filtra v."deletedAt" IS NULL en terra_31:404-409. Los unicos tres que no filtran son los de informes, que es donde yo la habia visto. O SEA QUE NO FUE UN DESCUIDO: LA CONSULTA ESPEJA LA REALIDAD. Complicaciones post tiene un escritor de correccion de verdad, POSTOP_SOFTDELETE_SQL en practica-postop-core.ts:180, que marca borradas las opciones deseleccionadas al editar. Campos no tiene ninguno. El filtro esta donde hay filas que filtrar y falta donde no las hay. Verifique la poblacion ademas: 3 filas en campos, 0 borradas. POR QUE LA FILA NO SE CIERRA IGUAL. Deja de ser un defecto y pasa a ser una TRAMPA ARMADA: se dispara sola el dia que exista una pantalla para corregir un campo. La primera correccion produce la primera fila borrada y ese mismo dia los informes empiezan a contar el valor viejo y el nuevo, sin que nada avise y sin que nadie relacione el informe raro con la pantalla nueva. Ese es exactamente el modo en que esta clase sobrevive. QUEDA COMO CONDICION DE ACEPTACION DE TERRA-181, no como trabajo independiente. TERRA-181 es la fila que abri con el hallazgo de fondo: una practica no se puede corregir despues de creada, salvo el postoperatorio. Arreglar los tres lectores hoy es correcto y barato, pero desconectado de cualquier sintoma; hacerlo COMO PARTE de la fila que introduce la edicion es lo que garantiza que se haga antes de que importe. LO QUE SIGUE VALIENDO DE LA FILA ORIGINAL, sin cambios: el comentario de informe-query.ts:104-106 justifica leer sin filtrar isActive ni deletedAt, y aplica a historicalLabel_, o sea a como se resuelve la ETIQUETA de un valor, no a que FILAS entran. Sigue siendo el comentario que puede hacer que alguien cierre esto sin arreglarlo, y ahora con mas razon, porque quien lo lea va a tener ademas el argumento correcto de que hoy no hay filas borradas. Y UNA CORRECCION SOBRE COMO ME LO REPORTARON, verificada contra pg_get_triggerdef y el cuerpo de la funcion: es cierto que trg_requireArchiveCtx no exige contexto en un UPDATE liso de value - la funcion ramifica y solo lo pide en la transicion a deletedAt no nulo. Pero de ahi no se sigue que el cambio no quede registrado: trg_archiveOnUpdate es AFTER UPDATE con el WHEN inverso, asi que un cambio de valor SI se archiva. Registrado y no justificado son dos cosas distintas, y la que importa para el diseño de la edicion es la segunda.
• wi-cli-venus note · 6w ago
  TERRA-180 — verificacion de escritor de deletedAt en terraPracticasCampos (SOLO LECTURA, DB viva eprpywqwzsvrjeaforei, 2026-09-01) 1) Filas con deletedAt no nulo, contadas por separado: - terraPracticasCampos: 0 - terraPracticasComplicaciones: 0 Ambas cero hoy. 2) No aplica: no hay filas blandas en terraPracticasCampos que trazar (punto 1 dio cero), asi que no hay practicas ni duplicacion de conteo que medir en este punto. 3) Escritor del lado de la base (busqueda por prosrc, no por nombre, contra pg_proc completo): UNA sola funcion en todo pg_proc menciona terraPracticasCampos en su cuerpo - fn_terraModuloCamposDefinitionGuard. Es un GUARD que corre en UPDATE de terraModuloCampos (definicion del campo, no de la fila de valor): antes de dejar cambiar moduloId/key/inputType/lookupCategory de un campo, hace un SELECT EXISTS contra terraPracticasCampos para bloquear el cambio si el campo ya tiene valores registrados (vivos O archivados - lee ambos estados, no escribe ninguno). No contiene ningun UPDATE ni INSERT sobre terraPracticasCampos, solo un SELECT de lectura. Ninguna otra funcion en pg_catalog toca la tabla. Sumado a lo ya medido en TERRA-180 sobre src/ (unico INSERT en practica-actions.ts:569, cero UPDATE/upsert en toda la app): NO EXISTE NINGUN ESCRITOR DE deletedAt PARA terraPracticasCampos HOY, ni en src/ ni en pg_proc. El trigger trg_terraPracticasCampos_archiveSoftDelete esta armado (registra la transicion cuando OLD.deletedAt IS NULL AND NEW.deletedAt IS NOT NULL) pero nada en el codigo lo dispara - es un receptor sin emisor. CONCLUSION para los tres puntos juntos: no es un defecto vivo, es una trampa armada. El filtro IS NULL faltante en $7/$8 de FILTER_SQL no tiene efecto medible hoy porque no hay ninguna via, ni de app ni de base, para que una fila de campo llegue a deletedAt no nulo. El dia que exista una edicion de campos (via app o via un escritor de base todavia no construido) el filtro faltante empieza a contar filas corregidas como vigentes sin que nadie lo haya notado en este momento.
• wi-cli-venus verified · 6w ago
  VERIFIQUE EL CENSO DE db02-terra-cc CON CONSULTA PROPIA Y COINCIDE, y despues mire una cosa mas que cambia lo que hay que hacer con esta fila. LO QUE COINCIDE. terraPracticasCampos: 3 filas, 0 con deletedAt. terraPracticasComplicaciones: 10 filas, 0 con deletedAt. Buscando en pg_proc por PROSRC y no por nombre, una sola funcion menciona terraPracticasCampos - fn_terraModuloCamposDefinitionGuard - y es lectura pura. Ninguna otra la toca. Sumado a que la app solo INSERTa, NO HAY ESCRITOR DE deletedAt para esa tabla, ni del lado de la app ni de la base. ENTONCES TERRA-180 ES TRAMPA ARMADA, NO DEFECTO VIVO, y lo escribo asi en vez de dejarlo como defecto sin efecto medible. La asimetria de FILTER_SQL :62-87 es real - los predicados de complicaciones ($5, $6) llevan AND k."deletedAt" IS NULL y los de campos ($7, $8) no - pero hoy no puede tener efecto porque no existe fila blanda ni forma de crear una. Se vuelve defecto EL DIA que alguien construya la edicion o el borrado de campos, y ese dia nada va a apuntar aca. UNA CORRECCION AL RESUMEN DE db02, menor pero importa para no dejar escrito algo falso: dijo que trg_terraPracticasCampos_archiveSoftDelete es "receptor sin emisor". Eso es cierto DE ESE TRIGGER, que tiene WHEN (old.deletedAt IS NULL AND new.deletedAt IS NOT NULL) y por lo tanto nunca disparo. Pero la tabla tiene SIETE triggers y el hermano trg_terraPracticasCampos_archiveOnUpdate lleva la condicion COMPLEMENTARIA, o sea que cualquier update que no sea un borrado blando SI archiva. La tabla no esta sin instrumentar: le falta ejercicio en una rama sola. Y ESTO ES LO QUE ENCONTRE MIRANDO LOS SIETE, que no estaba en el encargo y pesa mas que la fila: UN VALOR DE CAMPO, UNA VEZ ESCRITO, NO SE PUEDE CORREGIR NI BORRAR POR NINGUN CAMINO EXISTENTE. El hard delete esta prohibido por trg_terraPracticasCampos_forbidHardDelete, que usa la variante INCONDICIONAL fn_terraDetailForbidHardDelete - sin bypass por GUC, a diferencia de la que tiene terraCirugias. El borrado blando no tiene escritor, que es lo que acabamos de medir. Y el update de value esta ANTICIPADO por el esquema - trg_terraPracticasCampos_valueGuard es BEFORE INSERT OR UPDATE OF value, "campoId" - pero la app no lo ejerce: solo INSERTa. O sea que la base preve la correccion y la app no la ofrece. ESO ATA ESTA FILA A LA eq 74 Y NO AL REVES. La pregunta abierta ahi es la politica de correccion de una practica - quien puede corregir, hasta cuando, si hace falta motivo - y estaba planteada como decision de producto. Ahora tiene un hecho tecnico atras: para campos la correccion no existe a nivel de datos, ni siquiera para el propio autor, y la unica rama que la base dejo preparada (update de value) es la que nadie llama. Cuando se conteste la eq 74, el trabajo de campos no arranca de cero pero tampoco de donde parecia: hay guarda de valor y hay archivado de update esperando, y no hay borrado blando de ningun tipo.
• wi-cli-venus deferred · 6w ago
  Trampa armada, no defecto vivo: medido cero filas blandas en ambas tablas y ningun escritor de deletedAt ni en app ni en base. Queda diferida hasta que se conteste la eq 74 y se construya la correccion de campos, que es el dia en que la asimetria de FILTER_SQL se vuelve efectiva.
• wi-cli-venus note · 6w ago
  MEDIDO Y SIGUE LATENTE, con el numero fresco: SELECT count(*) FROM "terraPracticasCampos" WHERE "deletedAt" IS NOT NULL da CERO. O sea que la asimetria de FILTER_SQL - los predicados de complicaciones llevan AND k."deletedAt" IS NULL y los de campos, $7 tipoInjerto y $8 marcaImplante, no - HOY NO CAMBIA NINGUN NUMERO DE NINGUN INFORME. No hay ninguna practica contada por un valor de campo borrado, porque no hay ningun valor de campo borrado. POR QUE NO LO CIERRO IGUAL, y esta es la decision de la fila: el cero no viene de que el filtro este bien, viene de que NADIE PUEDE BORRAR. Verificado para esta misma fila: un valor de campo escrito no se puede corregir ni borrar por ningun camino existente en la app. O sea que la columna deletedAt de esa tabla existe, esta indexada por el esquema, y no tiene un solo escritor. El predicado que falta esta esperando a que alguien construya el borrado, y el dia que se construya el defecto aparece en el mismo commit que la funcionalidad, escrito por alguien que no va a estar mirando informe-query.ts. ESO ES EXACTAMENTE LA FORMA DE TRAMPA ARMADA por la que la fila quedo diferida y no cerrada, y la medicion de hoy la confirma en vez de desactivarla. Un cero producido por la ausencia de un escritor no es evidencia de que el filtro sea correcto - es evidencia de que todavia no fue ejercido. Absence of exercise no es verificacion. QUE HAY QUE HACER CUANDO SE TOQUE ESTO, escrito ahora que esta medido y no cuando alguien lo descubra: el commit que construya la correccion o el borrado de un valor de campo - que es TERRA-181 / eq 74, la politica de correccion de practicas - tiene que agregar AND "deletedAt" IS NULL a $7 y $8 EN EL MISMO COMMIT. No antes como precaucion suelta, porque un predicado agregado hoy no tiene forma de fallar y nadie sabria si quedo bien; no despues, porque entre uno y otro hay una ventana donde los informes cuentan valores borrados y nada avisa. QUEDA DIFERIDA, no cerrada, y el disparador esta nombrado: TERRA-181.
• wi-cli-venus note · 6w ago
  CENSO INDEPENDIENTE DE SUPERFICIES, por audit-terra-ca, pedido a ciegas - le prohibi leer mis conclusiones y las de db02 antes de escribir la suya. Confirma esta fila EN SU FORMA ESTRECHA y le pone un limite que anoto para que nadie la lea de mas. CONFIRMADO: una practica se crea en UNA transaccion que inserta padre mas piezas, antecedentes, regiones, campos, complicaciones intra y participantes, y ahi no hay ningun camino de update ni de delete para esos hechos. O sea que sobre un valor de campo ya escrito no existe segunda escritura, que es exactamente lo que esta fila afirma y lo que cite en TERRA-196 y en las eq 71 y 79. EL LIMITE, Y ES LA PARTE UTIL: SI existe una superficie de re-guardado genuina, savePostopComplicaciones sobre /practicas/[id]. Actualiza comentario, completitud y alta en terraPracticas, inserta complicaciones nuevas de fase post y borra en blando las deseleccionadas de fase post. No puede tocar fase intra ni terraPracticasCampos. ENTONCES: esta fila es exacta leida como 'no hay correccion de valores de campo ni de los hechos de creacion', y es FALSA leida como 'ningun hecho de una practica puede recibir una segunda escritura'. Las dos frases se parecen y la segunda es la que se cita sola cuando alguien resume. Queda escrito aca para que el proximo lector no tenga que descubrirlo. LIMITE DEL CENSO, declarado por ella sin que se lo pidiera: es sobre codigo, no consulto la base, asi que no afirma nada sobre poblacion viva. La poblacion la medi yo aparte: terraPracticasCampos no tiene ni una fila de terraMarcaImplante, y hay 6 practicas vivas con una sola que tiene valores de campo.
• wi-cli-venus verified · 6w ago
  VERIFICADA EN SUS DOS MITADES, 2026-09-01 11:47 UTC. La fila afirma dos cosas separadas - que los lectores ignoran deletedAt, y que hoy eso es inalcanzable - y hasta ahora ninguna de las dos tenia medicion propia. Se midieron por caminos distintos y a proposito: la de codigo la lei yo, la de datos la corrio db02-terra-cc y la reverifique contra la base antes de escribir esto. MITAD DE CODIGO: CONFIRMADA. campoBreakdown en src/lib/informe-query.ts consulta terraPracticasCampos filtrando por practicaId y por lookupCategory y NO TIENE NINGUN PREDICADO SOBRE deletedAt. Leido, no inferido. O sea que si alguna vez existe una fila borrada logicamente, el informe la cuenta igual. MITAD DE DATOS: la columna deletedAt EXISTE en terraPracticasCampos - timestamptz, nullable, confirmado contra information_schema y no asumido porque otras tablas terra la tengan. Y hay CERO filas con deletedAt no nulo. EL DENOMINADOR, QUE ES LA PARTE QUE CAMBIA COMO SE LEE ESE CERO: la tabla tiene TRES FILAS EN TOTAL. O sea que el cero no es "nadie borro nunca en una poblacion grande", es "la tabla casi no tiene datos todavia". Un cero sobre tres no es evidencia de disciplina ni de imposibilidad - es una tabla joven. Escribirlo sin el denominador habria hecho parecer que hay una practica establecida de no borrar, y no la hay: no hay practica de nada. Y LA DISTINCION QUE DECIDE LA CLASIFICACION: la columna EXISTE. O sea que el cero significa "nadie borro", NO "no se puede borrar". Si la columna no existiera, la trampa seria imposible por esquema y la fila se podria cerrar. Como existe, la trampa esta armada y solo espera datos. Esa diferencia es la unica razon por la que esta fila sigue abierta en vez de cerrarse hoy. QUEDA DIFERIDA, y ahora la condicion es explicita en vez de implicita: se sostiene MIENTRAS el conteo de filas con deletedAt no nulo siga en cero. El dia que aparezca la primera, los informes ya estan contando mal y la fila deja de ser preventiva sin que nadie la toque. NADA VIGILA ESE UMBRAL HOY - lo digo en vez de dejar que la fila implique que alguien mira. LA CAUSA AGUAS ARRIBA NO CAMBIO Y ES DE OTRA FILA: no hay camino en la aplicacion que corrija un campo de una practica ya creada (TERRA-181). El dia que se agregue ese camino es el mismo dia en que este cero deja de valer, y el que lo agregue no tiene por que estar leyendo esta fila. Ese es el acoplamiento real y por eso queda escrito aca y no solo alla. SIN CAMBIO DE CODIGO. Es medicion.
• wi-cli-venus assigned · 6w ago
  coder-terra-ca
• wi-cli-venus assigned · 6w ago
  SALE DE DEFERRED Y SE ASIGNA A coder-terra-ca. La decision es mia y la escribo con su razon, porque revertir un deferred sin decir por que es como ponerlo. POR QUE ESTABA DIFERIDA Y POR QUE ESO YA NO ALCANZA: el deferred se justificaba en que el defecto es LATENTE - terraPracticasCampos tiene 3 filas y 0 con deletedAt, o sea que ningun informe emitido hasta hoy puede estar mal. Eso sigue siendo cierto y lo re-verifique. Lo que cambio es la lectura del costo: el arreglo son CINCO LINEAS y el alcance ya estaba decidido dentro de la propia fila - dos filtros y tres instancias de campoBreakdown, una sola decision y no cuatro parches. Diferir un arreglo de cinco lineas cuya trampa se arma sola, no avisa, y no deja ninguna evidencia observable que lleve a mirarlo, es mas caro que hacerlo. Un deferred es barato cuando el trabajo es grande o la decision no esta tomada; aca no se cumple ninguna de las dos. LA CONDICION QUE LO MANTENIA ATADO A OTRA FILA TAMBIEN PIERDE FUERZA. Estaba escrito como condicion de aceptacion de TERRA-181 - la trampa se dispara el dia que exista la edicion de practicas. Pero TERRA-181 esta BLOQUEADA, y encadenar un arreglo de cinco lineas a una fila bloqueada significa que la trampa queda armada por tiempo indefinido. Si la edicion llega primero, el defecto se activa; si no llega nunca, el arreglo costo cinco lineas igual. Las dos ramas favorecen hacerlo ahora. LO QUE LE PEDI, MAS ALLA DEL ARREGLO, y son dos cosas que la fila pedia y no eran obvias: Primero, dejar INTACTO el comentario de las lineas 104-106 y agregarle una linea que acote su alcance. Ese comentario justifica leer sin filtrar isActive ni deletedAt y ES CORRECTO, pero aplica a historicalLabel_, o sea a como se resuelve LA ETIQUETA - un informe del año pasado no debe imprimir camelCase el dia que se retira una opcion. No dice nada sobre que FILAS entran. Es exactamente la clase de comentario verdadero que un lector rapido toma como cobertura de un defecto adyacente y usa para cerrarlo sin arreglarlo. Acotarlo vale mas que borrarlo. Segundo, un brazo de test que falle si una lectura de campos pierde el predicado - porque sin eso la asimetria vuelve la proxima vez que alguien agregue una lectura, que es como llego esta vez. Y le dije explicitamente que si no encuentra una forma honesta de que ese brazo REALMENTE FALLE, me diga que no en vez de escribir uno que pase siempre. Ese carril ya rehuso bien un atajo hoy - el test que se saltea sin credencial - asi que la instruccion no es desconfianza, es hacer barato repetir la conducta correcta. CARRIL Y VENTANA, medido antes de asignar y no supuesto: coder-terra-ca reseteo su ventana y esta en 258K, es el unico de los tres carriles -ca con margen, y src/ es su lane. audit-terra-ca sigue en 10 por ciento y sigue parado; db-terra-ca en 28 por ciento y ademas sosteniendo terra_55. NO CAMBIA NADA DE LO MEDIDO: sigue latente, sigue sin poder haber afectado ningun informe emitido, y sigue siendo distinta de TERRA-178 - aquella es lo que la pantalla NO puede decir, esta es lo que la pantalla dice MAL.
• wi-cli-venus statusChanged · 6w ago
  Sale de deferred: el arreglo son cinco lineas, el alcance ya estaba decidido dentro de la fila, y la condicion que la ataba a TERRA-181 pierde fuerza porque TERRA-181 esta bloqueada - encadenar cinco lineas a una fila bloqueada deja la trampa armada por tiempo indefinido. Asignada a coder-terra-ca, que es el unico carril -ca con ventana y cuyo lane es src/. La razon completa esta en el evento assigned inmediatamente anterior.
• wi-cli-venus verified · 6w ago
  ARREGLADO Y PUSHEADO: ca8e4ae, fix(informes): exclude archived campo rows, 2026-09-01T12:27:43Z. Dos archivos, +51/-0 - cinco lineas en informe-query.ts y un test nuevo de 46. Verificado por mi por tres caminos distintos y en ninguno acepte el reporte del carril. PRIMERO, EL PARCHE, leido con gh api: k."deletedAt" IS NULL entra en el filtro de $7 (tipoInjerto), en el de $8 (marcaImplante) y en campoBreakdown. Y CAMPOBREAKDOWN ES UN HELPER PARAMETRIZADO, o sea que ese unico agregado cubre los tres desgloses - marca, injerto y zona. Eso es lo que la fila pedia cuando decia UNA decision para las cuatro lecturas y no cuatro parches: no quedaron tres copias que alguien tenga que mantener sincronizadas. SEGUNDO, EL CENSO DE LECTORES, que hice yo y no estaba pedido: hay exactamente TRES lecturas de terraPracticasCampos en el archivo - lineas 89, 95 y 114 - y las tres quedan guardadas. Verifique ademas que campoApplicable NO es una cuarta lectura escondida: lee terraCirugiaCampos, otra tabla, y ya filtraba su propio deletedAt. El conteo de guards en el archivo pasa de 4 a 7, que es consistente con los tres agregados. TERCERO, Y ES EL UNICO QUE VALE COMO EVIDENCIA: FORCE EL BRAZO ROJO, DOS VECES Y POR CAMINOS DISTINTOS. Saque el guard del filtro $7 y el test dio not ok 1, fail 1. Restaure. Saque el guard del helper de breakdown y dio lo mismo. Restaure y confirme los 7 guards. Que falle por LAS DOS razones por las que tiene que fallar importa: un brazo que se cae por un solo camino deja el otro sin cubrir y se ve identico desde afuera. EL COMENTARIO DE 104-106 QUEDO ACOTADO Y NO BORRADO, como se pidio: se le agrego que la excepcion resuelve la ETIQUETA de un valor registrado y nunca admite una fila archivada en un filtro o un desglose. Sigue siendo verdadero lo que decia; ahora no se puede leer como cobertura de esto. DOS COSAS QUE EL CARRIL HIZO SIN QUE SE LE PIDIERAN Y QUE SON LAS QUE HACEN QUE EL TEST SIRVA. Los dos extractores de texto hacen assert.ok(start >= 0 && end > start) antes de devolver el segmento: si el ancla deja de matchear, el test FALLA en vez de comparar contra una cadena vacia y aprobar al vacio - que es el modo de falla propio de un test que lee fuente y el que convierte una guarda en un adorno. Y matcheo los DOS filtros por separado en vez de contar apariciones, con el comentario correcto: un conteo pasaria si una edicion futura protege un filtro dos veces y deja el otro descubierto. Es contar por miembro y no en total. LO QUE TODAVIA NO CUBRE, y por eso la fila NO SE CIERRA EN ESTE EVENTO: el test verifica LOS TRES LECTORES QUE HOY EXISTEN, nombrados - $7, $8 y campoBreakdown. No verifica LA POBLACION de lectores. El dia que alguien agregue un filtro nuevo que lea terraPracticasCampos sin el predicado, el test sigue verde, porque los tres que nombra siguen guardados. Y ESA ES EXACTAMENTE LA FORMA EN QUE LLEGO ESTE DEFECTO: las lecturas de complicaciones tenian el predicado y las de campos no, porque se agregaron despues. Un test que enumera es del mismo tipo que la lista de nombres que ya nos dejo una tabla afuera hoy. PEDIDA LA ASERCION QUE FALTA: contar las apariciones de FROM "terraPracticasCampos" y exigir el guard en cada una, o al menos afirmar que el conteo es 3 con un mensaje que obligue a decidir explicitamente cuando aparezca un cuarto lector. La segunda forma es mas tosca y falla en la direccion correcta - un lector nuevo no puede entrar en silencio. GATES REPORTADOS POR EL CARRIL Y NO RE-CORRIDOS POR MI, y lo digo asi en vez de presentarlo como verificado: 465 tests, lint sin errores con 3 warnings preexistentes, typecheck y build. Yo corri unicamente el test nuevo, tres veces - verde, rojo, rojo - y esa parte si la vi con mis ojos.
• wi-cli-venus completed · 6w ago
  CIERRA. El hueco que quedaba abierto en el evento anterior esta tapado y lo verifique disparandolo, no leyendolo. Follow-up 1b7a270, test(informes): census campo readers, ocho lineas, solo el archivo de test. QUE FALTABA Y POR QUE NO ERA UN DETALLE: el test verificaba LOS TRES LECTORES QUE HOY EXISTEN, nombrados uno por uno - $7, $8 y campoBreakdown. No verificaba LA POBLACION. Un cuarto lector agregado despues entraba sin predicado y el test seguia verde, porque los tres que nombra seguian guardados. Y esa es literalmente la forma en que llego este defecto: las lecturas de complicaciones tenian el predicado y las de campos no, porque se agregaron despues. Un test que enumera repite el error que esta arreglando. LO QUE AGREGA: exige que haya EXACTAMENTE 3 apariciones de FROM "terraPracticasCampos" en el archivo, con el mensaje "a fourth terraPracticasCampos reader requires an explicit archived-row decision and test update". La forma es tosca a proposito - no verifica que el cuarto lector tenga el guard, obliga a que alguien lo mire. Falla en la direccion correcta: un lector nuevo NO PUEDE ENTRAR EN SILENCIO, que es la unica propiedad que importaba. LO VERIFIQUE DISPARANDOLO, que es lo unico que cuenta como evidencia: inserte un cuarto lector sintetico sin predicado dentro de FILTER_SQL, el conteo paso a 4, y el test dio not ok 1 IMPRIMIENDO ESE MENSAJE - o sea que falla por la razon que dice y no por otra cosa que casualmente coincide. Restaure el archivo, el conteo volvio a 3 y el test volvio a verde. Cinco corridas en total sobre esta fila entre el arreglo y el censo: verde, rojo por el filtro $7, rojo por el helper, rojo por el cuarto lector, verde otra vez. ESTADO FINAL DE LA FILA, con lo que efectivamente quedo: - Las TRES lecturas de terraPracticasCampos llevan k."deletedAt" IS NULL. campoBreakdown es un helper parametrizado, asi que el agregado unico cubre marca, injerto y zona sin dejar tres copias que sincronizar. - campoApplicable NO era una cuarta lectura: lee terraCirugiaCampos y ya filtraba su propio deletedAt. Verificado, no supuesto. - El comentario de la etiqueta historica sigue intacto y ahora dice explicitamente que resuelve la ETIQUETA y nunca admite una fila archivada en un filtro o un desglose. Era la trampa de lectura que la fila advertia. - El test cubre las dos direcciones: que los lectores conocidos conserven el guard, y que no aparezca uno nuevo sin que alguien decida. LO QUE NO CAMBIO Y CONVIENE QUE QUEDE ESCRITO EN EL CIERRE: esto NUNCA afecto ningun informe emitido. terraPracticasCampos tiene 3 filas y 0 con deletedAt; terraPracticasComplicaciones 10 y 0. Era una trampa latente que se disparaba la primera vez que alguien corrigiera un campo. Se cierra sin haber causado daño, que es la unica forma barata de cerrar esta clase. Y SIGUE SIENDO DISTINTA DE TERRA-178, que queda abierta: aquella es lo que la pantalla NO PUEDE DECIR - un vacio que no distingue "no hubo" de "no se pregunto". Esta era lo que la pantalla DECIA MAL. Se tocan en el mismo archivo y no son la misma decision. GATES: el carril reporto 465 tests, lint, typecheck y build. Yo corri unicamente el test de esta fila, cinco veces, y esa parte la vi con mis ojos; el resto es reporte suyo y lo digo asi en vez de presentarlo como verificado.