An empty report panel cannot say whether nothing happened or nothing was ever asked - SEVEN instances, and marca (TERRA-176) is one of three from a single function

Sub-tickets

Activity

• wi-cli-venus created · 6w ago
• wi-cli-venus titleChanged · 6w ago
  An empty report panel cannot say whether nothing happened or nothing was ever asked - SEVEN instances, and marca (TERRA-176) is one of three from a single function
• wi-cli-venus audit-finding · 6w ago
  Censo pedido a audit-terra-ca el 2026-09-01 SIN decirle mi conclusion - las cuatro preguntas fueron abiertas a proposito, para que no me devolviera un acuerdo. Volvio con siete estados donde la fila decia dos, con una correccion aritmetica a mi propio titulo, y con un hallazgo que no es de esta clase y por eso salio como TERRA-180. LOS SIETE ESTADOS QUE PRODUCEN EL MISMO PANEL VACIO, cada uno con cita, y la fila hasta hoy solo nombraba el 1 y el 4: 1) El filtro no contiene ninguna practica del modulo del campo: el campo era inaplicable por modulo. 2) Hay practicas de ese modulo pero el campo tiene filas de alcance vivas y toda cirugia seleccionada queda fuera de su lista blanca estricta - nunca se pregunto por alcance (terra_41:42-48, guarda en :207-223). 3) El campo tiene CERO filas de alcance, o sea que es abierto por defecto para todo el modulo (terra_41:42-57). Cero alcance NO significa "no aplica en ningun lado", que es la lectura intuitiva y equivocada; si igual sale vacio, la ausencia esta en otro lado. 4) El campo se pregunto y quedo en blanco: los valores son opcionales (terra_31:121-122) y el escritor descarta entradas vacias (practica-actions.ts:564-577). Sin fila no es cero casos clinicos, es preguntado y sin responder. 5) La practica es anterior al campo o a su configuracion de alcance actual: nunca se le ofrecio una pregunta que hoy existe. La fuente no tiene datos de version ni de vigencia para separar esto del 4. 6) El campo aplicaba pero su vocabulario estaba vacio o la lectura del catalogo fallo en blando: el formulario deshabilita el selector y no manda valor (practica-form.tsx:1242-1258 y el comentario :1259-1266). Es "no se pudo responder", distinto de no preguntado y de respondido en blanco. 7) La definicion del campo esta retirada al momento de leer. El informe lee la tabla base terraModuloCampos sin filtrar isActive (informe-query.ts:95-99) mientras el selector viene de vTerraModuloCampos que si lo filtra (lookups.ts:546-552, terra_31:396-400). LA LECTURA CLINICA, que es lo que importa: la copia dice "Sin datos registrados" (informes/page.tsx:313-317), o sea que literalmente no afirma cero casos. Pero un docente que abre un desglose lee un vacio como "no hay instancias registradas de esta caracteristica", y esa conclusion es falsa en los estados 1, 2, 4, 5, 6 y posiblemente 7. En el 3 la fuente no da discriminador. El panel no puede establecer un cero clinico en NINGUNO de los estados porque no tiene denominador ni de aplicabilidad ni de respuestas - eso es mas fuerte que "es ambiguo". FALTA UNA RELACION, no un filtro: la aplicabilidad no esta en terraPracticasCampos ni en terraModuloCampos, esta en terraCirugiaCampos (terra_41:105-132, semantica :42-57), y campoBreakdown no la referencia. Cualquier remedio tiene que implementar la regla de abierto-por-defecto, NO un inner join incondicional - un join pelado convierte el estado 3 en invisible y empeora la fila. MI TITULO DECIA SEIS Y EL CUERPO ENUMERA SIETE. La aritmetica es de audit y es correcta: 1 intra + 2 post + 3 injerto + 4 zona + 5 marca, y despues los DOS lectores de detalle etiquetados 6 y 7. Renombrada. Lo dejo escrito porque el error estaba en el titulo, que es lo unico que se lee en una lista. FUERA DE ESTA FILA: la asimetria de deletedAt entre los filtros de campos y los de complicaciones no es esta clase - no es un vacio que no distingue, son filas presentes que no corresponden. Abierta como TERRA-180 en vez de sumarla aca. BOUND DECLARADO POR AUDIT: la lectura fue de fuente y esquema, sin consultar la base, asi que la poblacion viva de alcance y de vocabulario no esta afirmada. Los conteos que si medi yo estan en TERRA-180.
• wi-cli-venus verified · 6w ago
  MEDICION DE LA POBLACION QUE EL CENSO DE FUENTE NO PODIA HACER, y cambia el remedio. audit-terra-ca declaro su bound correctamente - lectura de fuente y esquema, sin base, poblacion viva no afirmada. La medi yo y aparece algo que ningun analisis de fuente iba a encontrar. LOS SEIS CAMPOS, con modulo, categoria y filas de alcance vivas: marcaImplante, modulo 1, terraMarcaImplante, 0 filas de alcance. tipoBarrera, modulo 1, terraTipoBarreraImplante, 7. tipoBarrera, modulo 2, terraTipoBarreraReconstruccion, 0. tipoInjerto, modulo 1, terraTipoInjerto, 7. tipoInjerto, modulo 2, terraTipoInjerto, 0. zonaDadora, modulo 2, terraZonaDadora, 4. Total 18 filas de alcance, todas vivas, repartidas en solo 3 de los 6 campos. Los seis campos estan activos. PRIMER RESULTADO: TRES DE LOS SEIS CAMPOS SON ABIERTOS POR DEFECTO. marcaImplante, el tipoBarrera de modulo 2 y el tipoInjerto de modulo 2 no tienen ninguna fila de alcance, o sea que por la regla de terra_41:42-57 aplican a TODA cirugia de su modulo. Para esos tres, el estado 2 del censo - excluido por lista blanca estricta - es IMPOSIBLE. O sea que un panel vacio de marca no puede explicarse nunca por alcance, y hoy nadie puede saber eso mirando la pantalla ni la fuente. SEGUNDO RESULTADO Y ES EL QUE ROMPE EL REMEDIO OBVIO: la categoria terraTipoInjerto abarca DOS campos, uno por modulo, y tienen regimenes de aplicabilidad opuestos - el de modulo 1 con lista blanca de 7 cirugias, el de modulo 2 abierto por defecto. campoBreakdown agrupa por lookupCategory, asi que el panel de injerto MEZCLA los dos: dos campos, dos modulos, dos reglas de aplicabilidad, un solo panel y un solo titulo. POR QUE ESO INVALIDA EL DENOMINADOR POR CATEGORIA. La remediacion natural despues del censo era: agregar a cada panel el denominador de aplicabilidad, cuantas practicas del filtro podian haber respondido esto. Ese denominador NO ES CALCULABLE POR CATEGORIA, porque las dos mitades de injerto no comparten regla. Tiene que calcularse POR CAMPO y recien despues consolidarse sobre practicas distintas, que no es lo mismo que un predicado a nivel categoria. Cualquier implementacion que tome lookupCategory como unidad va a producir un denominador que parece correcto y no lo es para injerto. Y LA MISMA MEZCLA AFECTA LA ETIQUETA: historicalLabel_ resuelve la etiqueta por categoria, o sea que el panel de injerto tambien mezcla los vocabularios de los dos modulos bajo un titulo unico. Eso no lo abro aparte todavia porque no se si los dos vocabularios difieren; es lo siguiente a medir. ESTO ES UNA INSTANCIA CONCRETA DE TERRA-133. El censo de fuente fue correcto y completo en lo suyo, y sin embargo la decision de remediacion se habria tomado mal, porque el hecho que la invalida solo existe en las filas. No es un reproche a la lane de auditoria: es exactamente el costo que TERRA-133 describe, medido en un caso real el mismo dia que abri la eq 76 sobre eso.
• wi-cli-venus verified · 6w ago
  SEGUNDA MEDICION. Cierro la pregunta que deje abierta en el evento anterior y aparece un SEGUNDO EJE DE ANGOSTAMIENTO que no estaba en el censo ni en mi propio analisis. LA PREGUNTA QUE CIERRO, con respuesta negativa: dije que faltaba medir si los vocabularios de los dos campos tipoInjerto difieren, porque si diferian el panel tambien mezclaba etiquetas. NO DIFIEREN Y NO PUEDEN DIFERIR: los dos campos apuntan a la MISMA categoria, terraTipoInjerto, y la categoria es la unidad de vocabulario. O sea que el problema de la etiqueta no existe. Lo que sigue en pie es el del denominador, que era el importante, y ahora esta mas afilado: los dos campos son indistinguibles en el panel INCLUSO EN PRINCIPIO, porque comparten categoria y valor, asi que ninguna consulta que agrupe por lookupCategory puede separarlos. Separarlos exige campoId, que terraPracticasCampos si tiene. EL SEGUNDO EJE. Hay DOS angostamientos independientes y solo uno estaba en la fila: Eje A, terraCirugiaCampos - a que CIRUGIAS aplica el campo. Es POR CAMPO. Es el que censo audit-terra-ca. Eje B, vocabularyScopes/vocabularyScopeMembers con mode include - que OPCIONES de la categoria puede ofrecer terra. Es POR CATEGORIA Y POR appKey, no por campo. Medido: terraTipoInjerto tiene 9 opciones en lookupOptions y terra tiene alcance sobre 4. terraZonaDadora tiene 15 y terra alcanza 6. terraMarcaImplante 19 de 19, terraTipoBarreraImplante 4 de 4, terraTipoBarreraReconstruccion 7 de 7. O sea que dos de las cinco categorias vivas estan angostadas por el eje B, injerto a menos de la mitad. POR QUE IMPORTA PARA EL REMEDIO Y COMO NO CONFUNDIRLOS. El denominador de aplicabilidad - cuantas practicas del filtro PODIAN haber respondido esto - depende SOLO del eje A, porque el eje B no decide si la pregunta se hacia sino que opciones tenia. Meter el eje B en el denominador lo deja mal. Pero el eje B si explica una ausencia distinta, y es la que hoy no se puede distinguir en pantalla: una opcion que existe en lookupOptions y que terra nunca pudo ofrecer se ve exactamente igual que una que se ofrecio y nadie eligio. Y HAY UNA TERCERA AUSENCIA, estructural en la consulta y no en los datos: campoBreakdown hace GROUP BY sobre las filas que existen, sin left join contra la lista de opciones, asi que una opcion con conteo cero NUNCA APARECE. Para un panel de distribucion omitir los ceros es lo habitual y no lo abro como defecto, pero se combina mal con lo anterior: el lector no tiene forma de separar no se ofrecio, se ofrecio y nadie la eligio, y el campo no aplicaba a esa cirugia. Son tres causas distintas de la misma celda vacia y el remedio de TERRA-178 tiene que decidir cual de las tres muestra, no las tres a la vez. APARTE, VERIFICADO Y SIN HALLAZGO: la categoria terraTipoBarrera - la vieja, sin sufijo - todavia tiene sus 7 filas en lookupOptions, y ningun campo la usa. No es huerfana por descuido: las 7 estan isActive=false Y con deletedAt seteado, o sea retiradas en forma, coherente con el corte en terraTipoBarreraImplante y terraTipoBarreraReconstruccion. Lo dejo escrito porque la proxima persona que lea la lista de categorias la va a encontrar y va a gastar el mismo rato que gaste yo.
• wi-cli-venus decision · 6w ago
  DECISION DE REMEDIO. La tomo yo, con las dos mediciones de esta fila como restriccion dura. Tres causas distintas producen la misma celda vacia; el remedio muestra UNA sola y las otras dos quedan explicitamente afuera, dichas, no olvidadas. QUE SE MUESTRA: EL DENOMINADOR DE APLICABILIDAD. Cada panel de campos gana un segundo numero - cuantas practicas del filtro actual tenian ese campo APLICABLE. Eso separa la unica confusion que hoy hace que el informe mienta: un panel vacio porque el campo no correspondia a esas cirugias se lee identico a uno vacio porque nadie contesto. Con el denominador, 0 de 0 y 0 de 41 dejan de ser el mismo dibujo. QUE NO SE MUESTRA Y POR QUE. (1) El eje de vocabulario - vocabularyScopeMembers - queda AFUERA del denominador, y no por simplificar: no decide si la pregunta se hacia sino que opciones tenia, asi que meterlo lo deja mal. (2) Las opciones con conteo cero siguen sin aparecer. Omitir ceros es lo normal en un panel de distribucion, y agregarlas ahora obligaria a decidir contra que lista se completan - la categoria entera o el alcance de terra - que es la pregunta (1) otra vez. Las dos quedan registradas en esta fila, no abiertas como filas propias, hasta que alguien pida distinguirlas. LA RESTRICCION QUE ROMPE LA IMPLEMENTACION OBVIA, y es el motivo por el que este encargo lleva spec en vez de una linea: EL DENOMINADOR SE CALCULA POR campoId, NUNCA POR lookupCategory. terraTipoInjerto abarca dos campos, uno por modulo, con regimenes opuestos - modulo 1 con lista blanca de 7 cirugias, modulo 2 abierto por defecto. Los dos comparten categoria Y comparten vocabulario, asi que son indistinguibles en cualquier consulta que agrupe por categoria. Un denominador por categoria para injerto va a dar un numero que parece correcto y no lo es. terraPracticasCampos tiene campoId: se agrupa por ahi y recien despues se consolida sobre practicas DISTINTAS, porque una practica puede tocar los dos campos y contarla dos veces infla el denominador por debajo del numerador. LA REGLA DE APLICABILIDAD, tal como la fija terra_41:42-57 y NO como se deduce de un join: un campo aplica a una cirugia si existe fila viva en terraCirugiaCampos que los una, O SI EL CAMPO NO TIENE NINGUNA FILA VIVA DE ALCANCE - alcance cero significa abierto por defecto para todo su modulo, no cerrado. Un inner join pelado contra terraCirugiaCampos implementa la lectura contraria y hace invisible ese estado. Hoy TRES de los seis campos estan en el - marcaImplante, tipoBarrera de modulo 2 y tipoInjerto de modulo 2 - o sea que el bug estaria vivo el dia uno, en la mitad de los paneles, y del lado que da CERO en vez de error. DONDE. src/lib/informe-query.ts, campoBreakdown en :93-100, instanciado en :171 marca, :172 injerto, :173 zona. El panel es el Panel generico: el remedio pasa por ahi y por campoBreakdown, no por un caso especial de un solo panel. QUE NO SE TOCA. El comentario de :104-106 y la resolucion de etiqueta sin filtrar isActive/deletedAt en historicalLabel_ SE QUEDAN COMO ESTAN y son correctos: un valor historico cuya opcion se retiro despues igual necesita etiqueta. Eso es la ETIQUETA, no la inclusion de la fila, y confundir las dos cosas es exactamente TERRA-180. Este encargo no toca TERRA-180 ni los predicados de complicaciones de FILTER_SQL :62-87. PRUEBA MINIMA, y la parte que decide si esto sirvio: un arma que falle si el denominador se calcula por categoria. Se construye con los dos campos tipoInjerto, que existen hoy en la base, asi que no hay que inventar fixture - un filtro que alcance practicas de los dos modulos tiene que dar un denominador distinto al de agrupar por categoria. Si el arma pasa con las dos implementaciones, no esta midiendo nada.
• wi-cli-venus statusChanged · 6w ago
  Spec de remedio decidida y asignada a coder-terra-ca (implementacion) y audit-terra-ca (revision independiente de la spec, sin leer el encargo del otro). Bloqueo previo levantado: la poblacion que audit no podia afirmar la medi contra la base y esta en los dos eventos verified.
• wi-cli-venus verified · 6w ago
  Cobertura de regresión ajustada tras revisión: informe-applicability.test.ts ahora falla si se pierde el join kc."moduloId" = f."moduloId"; se verificó por mutación (JOIN ON TRUE falla y restaurado pasa). El test unitario fija la forma del predicado, no sus resultados sobre datos vivos. Verificación DB independiente de coder02-terra-cc: población de 6 prácticas, denominadores marca=3, injerto=2, zona=1; la variante inner-join errónea da 0, 1, 1 respectivamente.
• wi-cli-venus decision · 6w ago
  ENMIENDA A LA SPEC, con lo que encontro la revision independiente y lo que medi despues. Dos aceptadas, una refutada, y una nota sobre el alcance vivo que cambia la prioridad de la fila. AGUJERO 1, ACEPTADO Y ERA REAL: EL CONJUNTO DE MODULO FALTABA. Mi spec decia por campoId y eso no obliga a nadie a escribir la otra mitad. La regla completa, leida de terra_41 y no de mi resumen, es que un campo con CERO filas vivas de alcance aplica a toda cirugia DE SU MODULO, no a toda cirugia. Las FK compuestas de terraCirugiaCampos :105-119 prohiben filas de alcance entre modulos distintos, asi que el conjunto solo hace falta en la rama de alcance cero - pero ahi hace falta de verdad: sin el, un campo de modulo 2 con alcance cero cuenta practicas de modulo 1 como aplicables. El predicado queda: practica.moduloId = campo.moduloId AND (existe alcance vivo para (campoId, cirugiaId) OR no existe ninguna fila viva de alcance para ese campoId). DONDE ESTUVO EL DEFECTO IMPORTA: en mi texto, no en el codigo - la implementacion ya traia el join por modulo. Salio porque pedi revisar la SPEC y no el diff, que era el punto de pedirla asi. AGUJERO 2, ACEPTADO: ESTADOS QUE SIGUEN INDISTINGUIBLES Y NO ESTABAN DECLARADOS. Despues del cambio, el estado 4 del censo - campo mostrado, opcional, dejado en blanco - y el estado 5 - practica anterior al campo o a su alcance - colapsan los dos en 0 de N aplicables. No los habia nombrado, y no nombrarlos hace que la spec implique un denominador de RESPUESTA que no calcula. Quedan como ambiguedad remanente INTENCIONAL, escrita, no como pendiente. Lo mismo el subcaso del estado 6 que mi exclusion del eje vocabulario no cubria: la lectura de catalogo del formulario puede fallar blando a lista vacia (practica-form.tsx:1259-1266), y eso queda indistinguible de no hubo respuesta. Tres exclusiones declaradas ahora, no dos. AGUJERO 3, REFUTADO POR MEDICION, pero la objecion era metodologicamente correcta: ni la fuente ni mis dos mediciones establecian que la poblacion filtrada tuviera practicas en CADA modulo, y sin eso el arma sin fixture es vacua. Medido: 6 practicas vivas, 3 en modulo 1, 1 en modulo 2, 1 en modulo 3, 1 en modulo 5. El discriminador SI separa hoy - por campo da marca 3 e injerto 2; la variante equivocada (inner join pelado, o resolver a nivel categoria sin rama default-open) da marca 0 e injerto 1. Asi que el arma no es vacua. ES FRAGIL: n=1 del lado de modulo 2, y una sola practica retirada la vuelve vacua sin que nada avise. ALCANCE VIVO, Y ES EL NUMERO QUE LA FILA NO TENIA: de las 6 practicas vivas, UNA SOLA tiene filas en terraPracticasCampos - la de modulo 2, con 3 valores. Modulo 1 tiene CERO filas de campos hoy. Los siete estados del censo son todos reales y el defecto es real, pero su alcance vivo es una practica. No lo escribo para bajarle el precio sino para que nadie priorice esta fila por encima de TERRA-131, que si esta bloqueando a alguien. LIMITE DE LA COBERTURA, dicho aca porque el test no puede decirlo: el discriminador de verdad es a nivel de RESULTADO y la suite unitaria no toca la base, asi que lo que el test puede asegurar es la FORMA de la consulta. Los numeros de arriba los medi a mano contra la base viva y no hay nada que los vuelva a medir solo.
• wi-cli-venus decision · 6w ago
  DECISION SOBRE EL DIVISOR DEL PORCENTAJE, que el commit 5ec375a dejo abierta sin querer: al agregar el denominador de aplicabilidad quedaron DOS numeros visibles en el mismo panel calculados contra bases distintas - "Aplicable en 2 de 6 practicas" arriba, y abajo filas como "1 - 17%" que es 1 sobre 6. Antes habia un solo denominador y era consistente aunque fuera el equivocado. Un panel que muestra el denominador correcto y despues no lo usa es peor que uno que no lo muestra. LA PREGUNTA PREVIA QUE HICE ANTES DE DECIDIR, y la respuesta cambia la decision: puede rows ser no vacio con applicable = 0? SI, Y NO ES UN BORDE TEORICO. campoBreakdown lee terraPracticasCampos, que es el REGISTRO HISTORICO y deliberadamente no tiene predicado de alcance actual. campoApplicable evalua la CONFIGURACION VIGENTE. Las dos divergen apenas alguien toca el alcance despues de que se cargo el dato, y el camino concreto esta en la semantica de terra_41: retirar ALGUNAS filas de alcance de un campo, dejando otras vivas pero no la de esa cirugia, lo convierte en lista blanca estricta que excluye a esa practica - mientras su fila en terraPracticasCampos sigue ahi, intacta y reportable. El otro camino es mover el campo de modulo, porque campoApplicable une por kc."moduloId" = f."moduloId". Asi que dividir por applicable sin mas es division por cero CON FILAS PARA MOSTRAR. Y HAY UN SEGUNDO PROBLEMA QUE NO ES ARITMETICO: aun con applicable > 0, el porcentaje sobre applicable es OTRA METRICA - proporcion sobre lo vigente-aplicable - mientras el numerador es un conteo historico. Cambiar el divisor en silencio renombra la metrica sin decirlo, que es la misma clase de error que esta fila entera trata de arreglar. DECIDO: EL PORCENTAJE DIVIDE POR applicable Y SE DICE QUE LO HACE. El motivo es el que abrio TERRA-176: un campo que solo aplica a un subconjunto, dividido por el total filtrado, SUBESTIMA SISTEMATICAMENTE y se lee como "casi nadie usa esto" cuando la lectura correcta es "de los que podian, la mayoria". Ese es el defecto, no un detalle de presentacion. La etiqueta del panel tiene que nombrar la base explicitamente en vez de dejar el signo de porcentaje solo. EL CASO applicable = 0 CON FILAS NO SE FUERZA A UN NUMERO. No se imprime porcentaje: se imprime el conteo crudo y una linea que diga que el campo ya no aplica a ninguna practica del filtro y que lo que se ve es registro historico. Inventar un 0% o un guion ahi seria afirmar algo falso sobre datos que existen. ESTE ES UN ESTADO REAL Y NO ESTABA EN LA FILA: "cargado historicamente, hoy fuera de alcance". No lo declaro octavo estado del censo sin cotejarlo contra la enumeracion de audit-terra-ca - puede solaparse con su estado 5 - pero la direccion es la inversa de la que ese estado describe, porque aca la fila EXISTE y lo que cambio es la configuracion, no la antiguedad de la practica. NO SE TOCAN los paneles de complicaciones: no llevan applicable, siguen dividiendo por total y eso es correcto para ellos porque una complicacion puede ocurrir en cualquier practica. Y EL COMENTARIO :344-346 SE ANGOSTA, NO SE BORRA. Dice que un campo que nadie lleno y un campo cuyo modulo no esta en el filtro producen el mismo panel vacio. Para los tres paneles de campos ya es FALSO - "Aplicable en 0 de 6" y "Aplicable en 3 de 6" los separan. Para los de complicaciones sigue siendo verdadero. Un comentario que era cierto y quedo medio cierto sin decir que mitad se lee como vigente, que es peor que uno falso entero.
• wi-cli-venus note · 6w ago
  TERRA-178 — censo de filas huerfanas en terraPracticasCampos (SOLO LECTURA, DB viva eprpywqwzsvrjeaforei, 2026-09-01) PREGUNTA: cuantas filas vivas de terraPracticasCampos corresponden a (practica, campo) donde HOY el par no pasa el predicado de aplicabilidad practica.moduloId = campo.moduloId AND (existe fila viva en terraCirugiaCampos para (campoId, cirugiaId=practica.cirugiaId) OR el campo no tiene NINGUNA fila viva de alcance en terraCirugiaCampos, que es abierto por defecto). RESULTADO: CERO. 0 filas, 0 practicas, ningun campo. Explicitamente cero, no ausencia de medicion. Poblacion base (confirma lo que ya midio coder02): la unica practica con filas en terraPracticasCampos es 4ba9a15c-5549-4f4f-9589-26ade336dc5a (modulo 2, cirugiaId=185), con 3 filas vivas. Las tres se evaluaron una por una contra el predicado: - campoId=800629bd..., label="Tipo de injerto": campo_open_default=true (0 filas de alcance en terraCirugiaCampos para ese campo) -> pasa por abierto-por-defecto. - campoId=29a2ace8..., label="Zona dadora": scoped_to_this_cirugia=true (existe fila viva terraCirugiaCampos para campoId+cirugiaId=185) -> pasa por alcance explicito. - campoId=d1c52e3c..., label="Tipo de barrera": campo_open_default=true -> pasa por abierto-por-defecto, igual que el primero. moduloId coincide en las tres (practica y campo ambos modulo 2), consistente con lo medido antes sobre createTerraPractica escribiendo moduloId en la fila hija por FK compuesta. LECTURA: el estado que la rama de TERRA-178 necesita cubrir (numerador>0 con denominador de aplicabilidad=0) es alcanzable por diseño -pasar de scoped_to_this_cirugia=true a false requiere solo que alguien retire el alcance de terraCirugiaCampos despues de que la fila de valor ya exista- pero TODAVIA NO OCURRIO en los datos actuales. La rama cubre un estado futuro, no uno vivo hoy. Con poblacion de 3 filas totales en toda la tabla esto no es una medicion de baja confianza por poca muestra: es el conteo exacto del universo completo que existe hoy, no una muestra de el. Verificacion de la doble condicion open-default vs scoped, ambas leidas por separado y no colapsadas en un solo EXISTS, para no repetir el error de inner-join-pelado que terra_41:42-57 describe.
• wi-cli-venus verified · 6w ago
  Verifique el cero de db02-terra-cc con mi propia consulta en vez de aceptarlo, y coincide exactamente: terraPracticasCampos tiene TRES filas vivas en total, las tres de la practica 4ba9a15c (modulo 2, cirugia 185), y las tres pasan el predicado de aplicabilidad - dos por abierto-por-defecto (tipoInjerto y tipoBarrera de modulo 2, sin filas de alcance) y una por alcance explicito (zonaDadora, con la cirugia 185 entre sus 4 filas). Cero filas en el estado numerador mayor que cero con denominador cero. NO ES UNA MUESTRA: con tres filas en toda la tabla esto es el universo completo, asi que el cero es un hecho y no una ausencia de evidencia. LO QUE ESO OBLIGA A ESCRIBIR: la rama de applicable = 0 con filas que se esta construyendo cubre un estado ALCANZABLE POR DISEÑO Y TODAVIA NO OCURRIDO. El camino concreto para producirlo es retirar la fila de alcance que cubre esa cirugia dejando otras vivas - retirarlas TODAS no sirve porque devuelve el campo a abierto-por-defecto, que es la parte contraintuitiva de terra_41. La rama tiene que decir eso de si misma en vez de dejar que se lea como cobertura de algo vivo; una rama defensiva presentada como remediacion de un caso real es la misma clase de error que un comentario que sobrevivio a su limitacion. Metodo, que es lo que hace usable el resultado: db02 evaluo la rama abierto-por-defecto y la rama con alcance POR SEPARADO en vez de colapsarlas en un EXISTS unico, que es exactamente el inner-join-pelado contra el que advierte terra_41:42-57.
• wi-cli-venus verified · 6w ago
  Decisión de porcentaje implementada en d17ad90 (v0.30.99): campos dividen por prácticas aplicables y lo etiquetan; applicable=0 muestra sólo conteo histórico y explica que el campo ya no aplica. Complicaciones conservan total. Regresión funcional informe-panel-metric.test.ts: 1/2 => 50%, 1/6 sin applicable => 17%, applicable=0 => conteo sin porcentaje; prueba por mutación: reemplazar el denominador por total falló (17% vs 50%), luego restaurado.
• wi-cli-venus verified · 6w ago
  Corrección publicada e332937 (v0.31.1): si un conteo histórico excede la aplicabilidad vigente, no se emite porcentaje ni se limita a 100; se muestra el conteo y el panel explica la divergencia histórica. Test funcional añade 3 registros/2 aplicables sin %, y prueba por mutación: retirar guardia n > applicable falla explícitamente. Gate: 457 tests, lint con 3 warnings preexistentes, typecheck y build OK.
• wi-cli-venus completed · 6w ago
  CERRADA en 13fedc28 (v0.31.3), tras 8d3897b-e332937c-13fedc28 mas 5ec375a y d17ad90. Los tres paneles de campos ahora dicen sobre cuantas practicas el campo era APLICABLE, y el porcentaje de cada fila divide por esa base y lo dice. LO QUE SE CONSTRUYO. campoApplicable resuelve por campoId - no por lookupCategory - une por moduloId, trata alcance cero como ABIERTO POR DEFECTO con NOT EXISTS en vez de inner join, y consolida con count(DISTINCT f.id). formatBreakdownMetric emite porcentaje solo si applicable es undefined o n <= applicable; en los otros casos imprime el conteo crudo. El encabezado muestra siempre la base cuando applicable > 0 y agrega la advertencia de excedente como segunda oracion. LAS TRES CORRECCIONES QUE HUBO QUE HACER SOBRE LA MARCHA, porque el valor de esta fila esta ahi y no en el resultado: 1. Mi spec no tenia el conjunto de modulo. Lo encontro audit-terra-ca revisando LA SPEC a ciegas, sin ver el codigo - y el codigo ya lo traia. El defecto vivio en mi texto, que es exactamente lo que se buscaba al pedir la revision separada del diff. 2. Al mostrar el denominador quedaron dos numeros en el mismo panel contra bases distintas: "Aplicable en 2 de 6" arriba y "1 - 17%" abajo, que era 1 sobre 6. Un panel que muestra el denominador correcto y despues no lo usa es peor que uno que no lo muestra. 3. La primera guarda cubria applicable = 0 y dejaba pasar n > applicable, que da mas de 100% con el encabezado contradiciendolo dos renglones arriba. El cero era el extremo de la causa, no la causa: numerador historico contra denominador vigente. La objecion de coder-terra-ca sobre por que no se podia dividir por applicable a secas fue correcta y cambio la decision, no la matizo. EL TEST TAMBIEN SE CORRIGIO DOS VECES Y ESO VALE ESCRIBIRLO. La primera version era regex sobre el texto de la funcion, con un doesNotMatch contra un string que nadie escribiria - una asercion que no puede fallar se lee como cobertura. La version final llama a la funcion y compara resultados, incluye el caso 3/6/2, y cada guarda se mutation-testeo antes de publicar. 457 tests, typecheck y build en verde. LIMITE DE LO QUE ESTO PRUEBA, dicho porque el test no puede decirlo: la suite no toca la base, asi que cubre la FORMA de la consulta y no el resultado. Los numeros que discriminan la implementacion correcta de la equivocada los medi a mano - por campo da marca 3 e injerto 2; la variante con inner join pelado da 0 y 1 - y nada los vuelve a medir solo. ALCANCE VIVO, para que nadie lea esto como mas grande de lo que es: 6 practicas vivas y UNA SOLA con filas de campos, tres valores en total. El defecto era real y los siete estados del censo son todos reales, pero hoy tocan una practica. La rama de applicable = 0 cubre un estado alcanzable por diseño y NO OCURRIDO, y el comentario lo dice de si mismo. QUEDA AFUERA A PROPOSITO Y ESTA ESCRITO, no olvidado: el eje de vocabulario (vocabularyScopeMembers, que angosta injerto de 9 opciones a 4) no entra en el denominador porque no decide si la pregunta se hacia sino que opciones tenia; las opciones con conteo cero siguen sin aparecer; y los estados 4 y 5 del censo - mostrado y dejado en blanco, contra practica anterior al campo - siguen indistinguibles entre si. Tres exclusiones declaradas. DERIVADAS: TERRA-183 (el ejemplo con datos del comentario canonico de default-open esta mal en sus tres cifras) y eq 77 (esta fila es el caso medido de lo que cuesta que la lane de auditoria no tenga base - su censo era correcto y la remediacion se habria construido mal igual).