Tres campos con alcance CERO: la fila decia que por eso ningun formulario los pide y es al reves - alcance cero es ABIERTO POR DEFECTO, se piden en todas las cirugias del modulo. Queda vivo solo si ese alcance cero es deliberado en dos de los tres

Sub-tickets

Activity

• wi-cli-venus created · 6w ago
• wi-cli-venus note · 6w ago
  CORRECCION DE ALCANCE, no de contenido: lo que este row describe es real, y es UNA DE SEIS instancias de la misma clase. Abri TERRA-178 con el censo completo. El remedio que este row propone - sacar el desglose por marca de implante de la pantalla de informes - arregla exactamente un sexto. Verificado por mi en la fuente: marca, tipo de injerto y zona dadora salen de UNA SOLA funcion, campoBreakdown en src/lib/informe-query.ts:93-100, instanciada en :171, :172 y :173. Esa funcion junta terraPracticasCampos con terraModuloCampos y nada mas; grepee el archivo entero por terraCirugiaCampos y hay CERO ocurrencias, o sea que ningun panel de campos sabe si el campo correspondia preguntarse. Marca no tiene un defecto propio - tiene el defecto de la funcion, y sus dos hermanas tambien. Y hay dos mas que ni siquiera son casos de campo sin alcance: intra (informe-query.ts:157-163) y post (:164-170) vienen de otras consultas y colapsan igual. El vacio de intra ademas lo GARANTIZA hacia atras el diseño que ya aprobamos en TERRA-136, porque terra_51 preserva a proposito las practicas viejas con cero respuestas. O sea que sacar el panel de marca dejaria cinco paneles con el mismo problema y con la clase ya identificada por escrito - que es la forma habitual en que estas cosas sobreviven a su propio descubrimiento. QUE CAMBIA PARA ESTE ROW: nada de lo que le pregunto al cliente. La eq 71 sigue igual y sigue siendo la que desbloquea - si los tres campos se preguntan o no, y en que cirugias. Lo que cambia es que la remediacion no se ejecuta desde aca: cuando llegue la respuesta, el arreglo pasa por campoBreakdown y por el Panel generico de informes/page.tsx:309-317, y se coordina en TERRA-178.
• wi-cli-venus verified · 6w ago
  CORRECCION: LA PREMISA CENTRAL DE ESTA FILA ESTA DADA VUELTA, Y LA ESCRIBI YO. Dice que tres campos "estan scopeados a CERO cirugias y por lo tanto no aparecen en ningun formulario de practica". Eso implementa la regla CONTRARIA a la que rige. Alcance cero significa ABIERTO POR DEFECTO: el campo aplica a toda cirugia de su modulo. No es que no aparezcan en ningun formulario - aparecen en TODOS los de su modulo. Y NO ES UNA DISCREPANCIA ENTRE LO ESCRITO Y LO CONSTRUIDO: lei el resolvedor. src/lib/campo-scope-core.ts:70 hace campos.filter(c => !scoped.has(c.id) || allowedHere.has(c.id)) - un campo que ninguna fila de alcance menciona pasa el filtro siempre. El formulario implementa default-open correctamente. Los tres campos que llame inalcanzables son los UNICOS tres que se piden en todas las cirugias de su modulo. DE DONDE SALIO EL ERROR, que es lo unico que vale registrar: mire terraCirugiaCampos, vi cero filas para esos tres campos, y lei el cero como exclusion. Es exactamente el error contra el que terra_41 advierte en su encabezado y contra el que campo-scope-core.ts:17-19 advierte en el suyo - "absence means nobody has scoped this campo yet, NEVER this campo applies to nothing". Los dos comentarios estaban ahi cuando escribi la fila. Leer el dato sin leer la regla que lo interpreta produce una lectura fluida y al reves. QUE PASA CON LA SEGUNDA MITAD, la que declare defecto "independientemente de eso": decia que informes promete un desglose por marca de implante que solo puede salir vacio porque el dato no se puede cargar. TAMBIEN CAE. El dato SI se puede cargar: marcaImplante se renderiza en las diez cirugias activas del modulo 1. El panel esta vacio por otro motivo, medido: hay 6 practicas vivas y UNA SOLA tiene filas de campos, tres valores, y es de modulo 2. No hay marcas cargadas porque casi no hay practicas cargadas, no porque la pregunta no se haga. LO QUE QUEDA EN PIE, y es poco pero es real: un panel vacio no distinguia "nadie contesto" de "no se pregunto". Eso YA SE ARREGLO en TERRA-178, cerrada en 13fedc28 - los paneles de campos ahora dicen sobre cuantas practicas el campo era aplicable. Para marca va a decir "Aplicable en 3 de 6 practicas" y ninguna fila, que es la lectura verdadera. LO QUE NO ESTA CONTESTADO Y ES LA UNICA PREGUNTA VIVA DE ESTA FILA: si el alcance cero de esos tres campos es DELIBERADO. Para marcaImplante hay respuesta y esta escrita en campo-scope-core.ts:20-22 - venus lleva marcaPicker en las diez cirugias del modulo, o sea que esta correctamente sin scope y debe seguir resolviendo en todas. Para los otros dos - tipoBarrera y tipoInjerto del modulo 2 - no hay nota equivalente, y la pregunta sigue siendo si la catedra quiso que se pregunten en toda cirugia de Reconstruccion o si nadie los scopeo todavia. Esa es la fila reducida a su tamaño real. UN NUMERO QUE CORREGI DE PASO Y AFECTA A TERRA-183: el modulo 1 tiene DIECISEIS filas en terraCirugias pero DIEZ activas. Los comentarios que dicen "las diez cirugias del modulo" cuentan activas y estan bien. Lo verifique despues de haber abierto TERRA-183 diciendo que las tres cifras del ejemplo de terra_41 estaban mal; solo estaba mal una. Corregido alla.
• wi-cli-venus titleChanged · 6w ago
  Tres campos con alcance CERO: la fila decia que por eso ningun formulario los pide y es al reves - alcance cero es ABIERTO POR DEFECTO, se piden en todas las cirugias del modulo. Queda vivo solo si ese alcance cero es deliberado en dos de los tres
• wi-cli-venus verified · 6w ago
  LA PREGUNTA QUE QUEDABA VIVA AHORA TIENE FORMA, Y LA RESPUESTA PROBABLE ES QUE LA PASADA DE TERRA-97 QUEDO INCOMPLETA. No lo afirmo: dejo el hecho medido y lo que habria que mirar para cerrarlo. QUE MEDI. Las filas de alcance vivas, cruzadas contra las cirugias ACTIVAS de cada modulo: modulo 1, tipoBarrera: 7 cirugias alcanzadas de 10 activas. modulo 1, tipoInjerto: 7 de 10. modulo 2, zonaDadora: 4 de 7. Y nada mas. Los otros tres campos - marcaImplante de modulo 1, tipoBarrera de modulo 2, tipoInjerto de modulo 2 - no tienen ninguna fila. ESO REPRODUCE EXACTAMENTE EL MODELO QUE DESCRIBE campo-scope-core.ts:9-11, y por eso el numero importa: el archivo dice que terra sobre-ofrecia injerto y barrera en 3 de las 10 cirugias del modulo 1 (172, 179, 180) y zonaDadora en 3 de las 7 del modulo 2 (181, 182, 183). 10 menos 3 da 7, y 7 menos 3 da 4. Las tres cifras cierran. O sea que las filas de alcance que existen hoy son precisamente las que dejo la correccion de TERRA-97, y no otra cosa. Y AHI ESTA LA ASIMETRIA: esa pasada toco TRES campos, no seis. Corrigio injerto y barrera EN EL MODULO 1, y zonaDadora EN EL MODULO 2. No toco injerto ni barrera EN EL MODULO 2. Los mismos dos campos, con la misma clave, quedaron con lista blanca en un modulo y abiertos por defecto en el otro. POR QUE ESO NO SE EXPLICA SOLO. El documento de la catedra, segun campo-scope-core.ts:5-8, marca cada cirugia con una taquigrafia de asteriscos donde * significa injerto mas barrera. O sea que injerto y barrera se scopean JUNTOS y POR CIRUGIA, en cualquier modulo. Si las 7 cirugias activas del modulo 2 estuvieran todas marcadas, alcance cero seria correcto y equivalente a alcance completo. Si alguna no lo esta, estan sobre-ofrecidas hoy - que es literalmente el defecto de TERRA-97, sin corregir, en el modulo que la pasada dejo a medias. MARCA IMPLANTE ES DISTINTO Y NO ENTRA EN ESTA DUDA: campo-scope-core.ts:20-22 dice que venus lleva marcaPicker en las diez cirugias del modulo, o sea que su alcance cero es deliberado y verificado, no un olvido. Queda fuera de la pregunta. LO QUE NO PUEDO VERIFICAR Y QUIEN PUEDE. La taquigrafia vive en cirugias.subcascadeShape en venus, que es base de otro proyecto y no la consulto desde este carril. La pregunta concreta y contestable es UNA: de las 7 cirugias activas del modulo 2, cuantas llevan asterisco. Si son 7, no hay nada que hacer y hay que escribir el motivo al lado del campo como esta escrito para marcaImplante. Si son menos, faltan filas de alcance y es TERRA-97 sin terminar. CONSECUENCIA SI ESTA SOBRE-OFRECIDO, para dimensionar: el propio archivo dice que un campo sobre-ofrecido invita a registrar un injerto en una cirugia que no lo lleva, y nada aguas abajo distingue ese valor de uno real. Con 6 practicas vivas el daño acumulado es nulo hoy. El costo es que cada practica nueva que se cargue en esas cirugias puede incorporar el error, y no hay forma de corregirlo despues - lo verifique para TERRA-180: un valor de campo escrito no se puede corregir ni borrar por ningun camino existente.
• wi-cli-venus descriptionChanged · 6w ago
  was: MEDIDO 2026-09-01 contra eprpywqwzsvrjeaforei. De los SEIS campos configurados en terraModuloCampos, TRES estan scopeados a CERO cirugias en terraCirugiaCampos y por lo tanto no aparecen en ningun formulario de practica: Marca de implante (terraMarcaImplante, modulo Implantologia), Tipo de barrera (terraTipoBarreraReconstruccion) y Tipo de injerto (terraTipoInjerto, fila 800629bd) ambos del modulo Reconstruccion del reborde alveolar. Ese modulo tiene UNO SOLO de sus tres campos alcanzable, Zona dadora con 4 cirugias. Implantologia tiene dos de tres, Tipo de barrera y Tipo de injerto con 7 cada uno. CONSECUENCIA MEDIDA: terraPracticasCampos tiene 3 filas vivas en total y ninguna pertenece a un campo sin scope, que es lo esperable porque son inalcanzables. POR QUE NO SE VE: cada uno de los tres tiene vocabulario sembrado en lookupOptions y camino de lectura renderizado - marcaImplante tiene 19 marcas vivas mas filtro y Panel de desglose en informes/page.tsx. Vocabulario sembrado mas lectura renderizada se lee como funcionalidad construida, y la unica fila que falta para que aparezca en un formulario es la de scope, que no se ve desde ninguna pantalla. NO ES CLARO QUE SEA UN DEFECTO Y ESA ES LA PREGUNTA: puede ser configuracion pendiente de la catedra (nadie dijo todavia en que cirugias corresponde preguntar cada campo) o puede ser un scope que se perdio. Hay que distinguirlo antes de arreglar nada. LO QUE SI ES DEFECTO INDEPENDIENTEMENTE DE ESO: informes promete un desglose por marca de implante que solo puede salir vacio, porque el dato no se puede cargar. Un panel siempre vacio se lee como que no hubo casos, no como que la pregunta nunca se hizo. BOUND: contado sobre terraCirugiaCampos sin filtro de deletedAt en el count por campo; terraModuloCampos no tiene columna deletedAt.
• wi-cli-venus blocked · 6w ago
  MEDIDO 2026-09-01 06:45 UTC. La fila estaba en backlog y eso decia lo que no es: backlog dice que nadie la tomo todavia, y lo que pasa es que no queda nada que un agente pueda tomar. La unica pregunta viva de esta fila se contesta contra cirugias.subcascadeShape, que vive en la base de OTRO proyecto, y este carril no consulta bases de otros proyectos - no por falta de credencial sino por regla de alcance. Ningun agente de terra puede desbloquearla trabajando mas. LA PREGUNTA, reducida a una sola cifra para que quien la conteste no tenga que leer la fila entera: de las 7 cirugias ACTIVAS del modulo 2 (Reconstruccion del reborde alveolar), cuantas llevan asterisco en cirugias.subcascadeShape. El asterisco significa injerto mas barrera. Si son 7, el alcance cero de tipoInjerto y tipoBarrera en ese modulo es correcto y equivale a alcance completo, y lo unico que hay que hacer es escribir el motivo al lado del campo como ya esta escrito para marcaImplante en campo-scope-core.ts:20-22. Si son menos, esos dos campos estan sobre-ofrecidos hoy y es TERRA-97 sin terminar. QUE YA ESTA MEDIDO Y NO HAY QUE VOLVER A MEDIR, para que nadie lo rehaga: las filas de alcance vivas cruzadas contra cirugias activas dan modulo 1 tipoBarrera 7 de 10, modulo 1 tipoInjerto 7 de 10, modulo 2 zonaDadora 4 de 7, y los otros tres campos sin ninguna fila. Las tres cifras cierran exacto con los 3 sobre-ofrecidos que campo-scope-core.ts:9-11 dice que corrigio TERRA-97, o sea que el alcance que existe hoy es precisamente lo que dejo esa pasada y no otra cosa. marcaImplante queda FUERA de la duda: su cero es deliberado y verificado. POR QUE NO LA CIERRO POR SILENCIO. Alcance cero es ABIERTO POR DEFECTO, asi que la fila no describe una funcionalidad ausente sino dos campos que hoy se preguntan en TODAS las cirugias del modulo 2. La hipotesis de que eso es correcto y la de que es un olvido producen el mismo estado observable, fila sin scope, y ninguna evidencia dentro de terra las separa. Cerrarla como no-defecto seria elegir una de las dos sin medir. DESBLOQUEA CON: la respuesta a la eq que acabo de abrir. Nada mas espera a ningun agente de este carril.
• wi-cli-venus verified · 6w ago
  CORREGI LA eq 71, QUE SEGUIA AFIRMANDO LA PREMISA QUE ESTA FILA YA HABIA DADO VUELTA HACE TRES HORAS. A las 03:44 corregi el row: cero filas de alcance no significa excluido, significa ABIERTO POR DEFECTO. Corregi el titulo, la descripcion y los eventos. NO CORREGI LA PREGUNTA, que estaba filada sobre la premisa vieja y quedo abierta en la cola de Elazar pidiendole a la catedra que decida sobre una app que no existe - y ademas pidiendo sacar de informes un panel que no esta roto. O SEA QUE DURANTE TRES HORAS EL TABLERO Y LA COLA DECIAN LO CONTRARIO, y la que un humano lee es la cola. Esa es la parte que importa: la version vieja no solo sobrevivio, sino que sobrevivio en el unico lugar donde alguien iba a actuar sobre ella. COMO APARECIO: liste la cola entera por otro motivo. No la encontre acordandome de lo que habia filado, que es exactamente el metodo que fallo. QUE DICE AHORA LA eq 71: que la premisa estaba dada vuelta y por que, que se retira el pedido de sacar el panel de marca, y queda una sola pregunta viva - si injerto y barrera del modulo 2 corresponden en las 7 cirugias activas o si a alguien se le paso acotarlos. Mismo topico que la eq 79, terra-campo-scope-modulo2, asi que una sola respuesta cierra las dos y no hay que contestar dos veces lo mismo. LA REGLA QUE ME LLEVO, porque esto es la segunda instancia del mismo defecto en un dia: corregir la fila no corrige la cola. Una afirmacion vive en mas lugares que el repo - la cola de preguntas, un entregable al cliente, un DM ya mandado, un comentario en el archivo de otro carril - y el grep que probo que src/ estaba limpio no llega a ninguno de esos. Despues de dar vuelta una premisa hay que enumerar donde mas la afirme, y verificar la cola LISTANDOLA, no recordandola.
• wi-cli-venus note · 6w ago
  MEDIDO POR db02-terra-cc, SELECT solamente, 2026-09-01 08:24, contra la pregunta que dejaba viva esta fila. LA RESPUESTA ES QUE NO SE PUEDE CONTESTAR DESDE LA BASE, y eso cierra la via, no la fila. LOS TRES CAMPOS CON ALCANCE CERO, confirmados por conteo y no dados por buenos porque el numero lo escribi yo: marcaImplante (modulo 1), tipoInjerto (modulo 2) y tipoBarrera (modulo 2). Son exactamente tres. LO QUE ARRASTRAN POR LA REGLA DE ABIERTO POR DEFECTO, y aca corrijo el rotulo del reporte: db02 dio 16 para modulo 1 y 14 para modulo 2 describiendolos como cirugias ACTIVAS. Son los TOTALES. Las activas son 10 en modulo 1 y 7 en modulo 2 - medido por mi agrupando por moduloId. El numero estaba bien contado y mal nombrado, que es la variante que nadie revisa porque la cifra es verdadera de algo. Filas realmente cargadas: marcaImplante 0, tipoInjerto 1, tipoBarrera 1. LA PREGUNTA QUE DECIDIA LA FILA ERA SI EL CERO ES DELIBERADO EN AL MENOS DOS DE LOS TRES. No hay forma de saberlo desde la base, y db02 lo escribio asi en vez de rellenarlo. La comparacion de createdAt contra hermanos con alcance no-cero apunta para los dos lados: en modulo 1 marcaImplante (08:34:03.048452) tiene marca distinta de tipoInjerto/tipoBarrera de ese modulo, que tienen alcance 7 y createdAt 14:48:45.903403 - eso separaria. Pero en modulo 2 zonaDadora, con alcance 4, comparte el createdAt EXACTO 08:34:03.048452 con tipoInjerto y tipoBarrera, que tienen cero. La misma marca de tiempo cubre un campo con alcance real y dos sin el, asi que el patron de modulo 1 no generaliza. isRequired, isActive e inputType son identicos en los seis campos (false/true/lookup): ningun diferenciador ahi tampoco. CONSECUENCIA PARA ESTA FILA: no sobrevive por señal de la base. Si sobrevive, es por un argumento de diseño o por preguntarle a la catedra, no por medicion. Lo anoto asi en vez de dejar la pregunta abierta como si faltara medir mas. ENLACE QUE NO HABIA VISTO: marcaImplante es UNO de los tres campos de alcance cero, y es el mismo campo de TERRA-196 y TERRA-141. O sea que el campo que arrastra la fila de escape 'otra' es tambien el que se pide en las diez cirugias activas del modulo por no tener alcance cargado. Las tres filas miran el mismo campo desde tres lados.
• wi-cli-venus note · 6w ago
  RE-MEDIDA CONTRA LA BASE VIVA, SIN DRIFT, 2026-09-01 09:52 UTC. Medido por db02-terra-cc, y las cifras las corri yo tambien contra la base en vez de tomarle la palabra. CONFIRMADO: siguen siendo TRES campos con alcance CERO, sobre SEIS terraModuloCampos en total. Y los tres son los mismos. Los nombro con su modulo porque el nombre solo no alcanza - tipoBarrera y tipoInjerto EXISTEN EN LOS DOS MODULOS y solo la copia de uno de ellos esta en cero: marcaImplante en modulo 1: 0 filas en terraCirugiaCampos. tipoBarrera en modulo 2: 0 filas. tipoInjerto en modulo 2: 0 filas. Y LAS OTRAS TRES NO ESTAN EN CERO, que es lo que hace que el hallazgo sea un hallazgo y no una tabla vacia: tipoBarrera en modulo 1 tiene 7, tipoInjerto en modulo 1 tiene 7, zonaDadora en modulo 2 tiene 4. Conte tambien filtrando deletedAt IS NULL y da lo mismo - 0, 7, 7, 0, 0, 4 - o sea que los ceros no son filas borradas logicamente, es alcance que nunca se cargo. QUE LA COPIA DE UN MODULO ESTE EN CERO MIENTRAS LA DEL OTRO TIENE 7 ES EL DATO, y refuerza la lectura de la fila en vez de debilitarla: si el alcance cero fuera deliberado como "este campo no se usa", costaria explicar por que el MISMO campo si tiene alcance cargado en el otro modulo. Deja como principal sospecha el olvido de carga, no la decision. UNA CORRECCION MENOR AL REPORTE QUE RECIBI, que no cambia nada del fondo: db02 escribio "0/6 fields con scope cero" en la misma linea donde dice "los mismos 3 campos, scope 0 en los 3". Son TRES sobre seis, no cero sobre seis. La identificacion de CUALES eran los tres es exacta - la verifique campo por campo - asi que es un desliz de fraccion en la redaccion, no un error de medicion. Lo dejo escrito porque la fraccion es justamente el numero que esta fila usa. LOS OTROS CAMPOS DE LA DEFINICION, medidos de paso: los seis tienen isRequired=false e isActive=true. O sea que ninguno de los tres en cero esta desactivado, que seria la otra explicacion inocente. Estan activos y sin alcance. LO QUE ESTO NO TOCA: la fila dice que alcance cero es ABIERTO POR DEFECTO, o sea que se piden en TODAS las cirugias del modulo. Eso es una lectura del CODIGO de la app y no la verifique en esta pasada - lo que verifique es la mitad de base, o sea que el alcance efectivamente esta vacio. La pregunta viva de la fila sigue siendo si ese cero es deliberado en dos de los tres.
• wi-cli-venus note · 6w ago
  MEDIDO CONTRA LA BASE VIVA Y CONTRA EL CODIGO, 2026-09-01 10:41 UTC. La fila queda VIVA y ademas aparece algo que no estaba: el riesgo real de esta mecanica NO es el alcance cero, es el alcance NO CERO. PRIMERO, LO QUE CONFIRMA LA FILA. campo-scope-core.ts:15-22 escribe la regla explicita: un campo con CERO filas vivas en terraCirugiaCampos aplica a TODAS las cirugias de su modulo, y un campo con una o mas filas es una LISTA BLANCA ESTRICTA. O sea que alcance cero es ABIERTO, tal como esta fila lo corrigio, y no cerrado. La fuente ademas dice por que ese default y no el otro: el default inverso borraria una pregunta del formulario el dia que alguien agrega un campo, y el formulario se veria correcto preguntando nada. Y RESUELVE UNO DE LOS TRES CASOS SIN AMBIGUEDAD: marcaImplante en modulo 1 esta documentado ahi mismo como deliberado - "venus carries marcaPicker on ALL TEN cirugias of the modulo, so it is correctly unscoped and must keep resolving everywhere". O sea que ese cero no es un olvido y no hay que tocarlo. Quedan los otros dos, tipoBarrera y tipoInjerto de modulo 2, que es exactamente lo que esta fila dice que hay que decidir. SEGUNDO, Y ES NUEVO. Cheque los denominadores del comentario contra la base porque no coincidian a primera vista: el comentario habla de "modulo 1's 10 cirugias" y "modulo 2's 7", y la base tiene 16 y 14 vivas. NO ES UN COMENTARIO DESACTUALIZADO - conte confirmadas y son exactamente 10 y 7. El comentario midio contra las CONFIRMADAS y acerto: dice que terra sobre-ofrece en 3 de 10, y hay 7 cirugias con alcance de tipoBarrera y 7 de tipoInjerto; dice 3 de 7 en modulo 2, y hay 4 con alcance de zonaDadora. Las cuatro cifras cierran. PERO ESO ES JUSTO LO QUE DESTAPA EL PROBLEMA: la lista blanca se poblo contra el conjunto CONFIRMADO, y desde entonces el modulo 1 paso de 10 a 16 cirugias vivas y el modulo 2 de 7 a 14. Las 6 nuevas de modulo 1 y las 7 de modulo 2 NO ESTAN en ninguna fila de terraCirugiaCampos. Como la regla para un campo con alcance es LISTA BLANCA ESTRICTA, esas cirugias nuevas NO reciben tipoInjerto, tipoBarrera ni zonaDadora - y no porque alguien lo haya decidido, sino porque nadie agrego la fila. O SEA QUE EL MODO DE FALLA QUE LA FUENTE TEME ESTA EN EL OTRO CAMPO. El comentario se cuida del default cerrado, que borraria preguntas al agregar un CAMPO. Lo que pasa hoy es que agregar una CIRUGIA a un modulo donde el campo YA tiene alcance la deja silenciosamente afuera. Los dos terminan en un formulario que no pregunta lo que deberia, y del segundo no avisa nada. NO AFIRMO QUE ESAS 13 CIRUGIAS DEBAN RECIBIR LOS CAMPOS. Puede que clinicamente no corresponda - el atajo del asterisco del espe dice que sin asterisco no van ni injerto ni barrera. Lo que afirmo es que HOY NO SE PUEDE DISTINGUIR "quedo afuera porque corresponde" de "quedo afuera porque nadie la agrego", y las dos se ven identicas: ausencia de fila. DATO AL MARGEN CON DENOMINADOR, para que no se lea como que el problema es general: los modulos 3, 4, 5 y 6 suman 48 cirugias vivas, CERO confirmadas, y terraModuloCampos no tiene ni un campo para ellos. O sea que esta mecanica hoy solo aplica a los modulos 1 y 2; los otros cuatro no tienen campos que alcanzar. SIN CAMBIO DE CODIGO NI DE DATOS. Es medicion.
• wi-cli-venus verified · 6w ago
  CIERRA EL UNKNOWN DEL PREDICADO, 2026-09-01 12:22 UTC. Yo habia escrito textual que no medi el predicado que aplica el selector de cirugias y que por eso no podia decir si "todas las cirugias del modulo" son 16 o 10. Medido por audit-terra-ca sobre fuente, y la mitad de base la verifique yo contra la vista viva, que es justo la parte que ese carril declaro no poder ver - no tiene conexion a la base, que es TERRA-133. EL SELECTOR OFRECE LAS ACTIVAS, NO EL TOTAL. La lista sale de getCirugias() en src/lib/lookups.ts, que la carga /practicas/nueva. La consulta NO TIENE WHERE PROPIO: es un SELECT plano sobre vTerraCirugias ordenado por nombre. El filtro no esta en la consulta, esta en la VISTA. Y LA VISTA LA LEI YO CONTRA LA BASE, no en el comentario que la describe: vTerraCirugias es SELECT ... FROM terraCirugias WHERE deletedAt IS NULL AND isActive. O sea que el predicado existe y es el que el comentario dice. Esto importa porque la afirmacion del carril venia de una lectura de fuente, y una vista es un objeto de base: el comentario podria haber quedado viejo y la unica forma de saberlo es mirar la definicion viva. Coincide. ENTONCES, PARA TERRA-176: "todas las cirugias del modulo" son DIEZ, no dieciseis. Un campo con alcance cero es abierto por defecto sobre las cirugias que el formulario ofrece, y el formulario ofrece las activas. Las seis inactivas del modulo 1 no son alcanzables desde ahi. EL GUARDADO LEE LA MISMA VISTA, y esa es la respuesta a la tercera pregunta, la que podia sorprender: practica-actions.ts consulta vTerraCirugias por id para resolver requierePieza y requiereRegion, o sea que hereda el mismo predicado. Selector y guarda coinciden. PERO LA CONSECUENCIA NO ES TRANQUILIZADORA Y EL CARRIL NO LA SACO, ASI QUE LA SACO YO. Heredar el predicado de la vista es exactamente lo que hace que una cirugia RETIRADA se lea como AUSENTE en vez de leerse con sus flags. El codigo devuelve rows[0] ?? null y lo justifica con este comentario: "The parent INSERT's FK remains responsible for an unknown or retired cirugia". LA FK NO ES RESPONSABLE DE UNA RETIRADA. La lei: es FOREIGN KEY (cirugiaId, moduloId) REFERENCES terraCirugias(id, moduloId), o sea contra LA TABLA BASE, que contiene las retiradas. La FK admite todas las filas que la vista esconde. El comentario es verdadero para "desconocida" y FALSO para "retirada", y las presenta como una sola cosa. QUE PASA ENTONCES CON UNA RETIRADA: el requisito vuelve null, resolveZonaAxes cae en la rama unconfirmed y aplica la regla plana de al-menos-uno en vez de la regla estricta por flag. Es una DEGRADACION, no una ausencia de validacion, y lo digo asi en vez de decir "no valida". Y HOY NO PRODUCE NINGUN DEFECTO, medido en vez de supuesto: las 48 cirugias activas tienen requierePieza y requiereRegion en NULL, TODAS. O sea que la rama estricta NO SE EJECUTA NUNCA para nada, y degradar de estricta a plana es un no-op. Ademas hay 30 inactivas y NINGUNA lleva ninguno de los dos flags. ESE NULL ES DELIBERADO Y CASI ABRO UNA FILA CONTRA EL. TERRA-91 dice en su condicion de aceptacion SEED NOTHING, todas las filas en NULL, porque la lista de cirugias era una semilla provisoria que el cliente ya habia reportado como equivocada - TERRA-75 - y llenar los flags entonces era adivinar reglas clinicas de filas a punto de ser reemplazadas. Fui a leer la fila que lo cerro ANTES de escribir el hallazgo, y por eso no se abrio una fila contra un estado diseñado. REGLA: ausencia diseñada y ausencia por decaimiento se ven identicas en los datos; se distinguen leyendo la fila que cerro el asunto. LO QUE SI QUEDA ANOTADO Y NO TIENE FILA HOY: TERRA-91 y TERRA-75 estan las DOS cerradas, y la siembra de los flags dependia de la lista corregida de Puia. La poblacion crecio de las 35 filas que TERRA-91 midio a 78 - 48 activas - con los flags todavia sin sembrar. No lo abro como defecto porque el diseño es ese; lo dejo escrito porque nadie lo esta mirando. LIMITE DEL CARRIL, mantenido tal cual: leyo dos archivos de fuente mas la pagina que llama, y NO releyo la definicion viva de la vista, no consulto la base y no inspecciono caminos de SQL externos o directos. Esa ultima parte sigue sin medirse: un escritor que no pase por practica-actions.ts no tiene ninguno de estos predicados.
• wi-cli-venus assigned · 5w ago
  coder02-terra-ca
• wi-cli-venus assigned · 5w ago
  db-terra-cc
• wi-cli-venus verified · 5w ago
  BLOCKER REVALIDATED, STILL VALID - db-terra-cc 2026-09-11, marker SCOPE176-mtwrta. Unlike TERRA-98 and TERRA-201, this row's numbers survive re-measurement EXACTLY as written: modulo 1 tipoBarrera 7 of 10 active, modulo 1 tipoInjerto 7 of 10, modulo 2 zonaDadora 4 of 7, and the other three fields carry zero scope rows. marcaImplante modulo 1 scope 0 (deliberate, documented). tipoInjerto and tipoBarrera in modulo 2 are both scope 0, i.e. open to all 7 active cirugias - which is precisely the asymmetry this row exists to question. Also confirmed: modulo 2 has exactly 7 ACTIVE cirugias (14 vivas, 7 of them inactive), so the 'de las 7 cirugias activas del modulo 2' framing in the blockedReason is still the right denominator ten days on. THE BLOCKER IS GENUINE AND NO AGENT OF THIS LANE CAN CLEAR IT. The one open question is how many of those 7 carry the asterisk in cirugias.subcascadeShape, which lives in the venus project's database. That is out of scope by rule, not by missing credential, so working harder does not move it. Recorded here so this row is not re-swept: it was checked on 2026-09-11 and it is correctly blocked, which is a different finding from the two rows whose blockers turned out to be stale.
• wi-cli-venus verified · 5w ago
  ANSWERED: 7 OF 7. The zero scope is CORRECT, and the blocker was wrong about why it was a blocker. Marker: SCOPE176-answer-mtwxr8. THE NUMBER THIS ROW WAS REDUCED TO: of the 7 ACTIVE cirugias of modulo 2, SEVEN carry injerto+barrera. Source is /data-venus/evolutiva/terra/venus-import/2026-08-22-venus-subcascade-modulos-4-16.md, coder-venus-cc's own SELECT against venus PROD, transcribed per-cirugia. Venus modulo 16 is terra's modulo 2 and its seven rows are ids 158-164: 158/159/160 carry barrera+injerto, and 161/162/163/164 carry barrera+injerto+zonaDadora. There is no eighth row and no row without them. By this row's own stated criterion - 'Si son 7, el alcance cero de tipoInjerto y tipoBarrera en ese modulo es correcto y equivale a alcance completo' - the question is answered YES and this is not TERRA-97 left unfinished. THE 1:1 MAP TO LIVE ROWS, so the file is not trusted on its label alone. Live modulo 2 today: 7 active, all isConfirmedByClient. EPS (183), ROG horizontal (182) and ROG vertical (181) carry ZERO terraCirugiaCampos rows; Injertos en bloque por aposicion (184), por interposicion (185), perforado (186) and dividido (187) carry exactly ONE each. That is venus 158-160 (asterisk = injerto+barrera, no zonaDadora) and venus 161-164 (triple asterisk = the three fields) reproduced exactly. The four bloque rows ARE the four zonaDadora scope rows, which is the same 4-of-7 this row already measured twice, arrived at independently. WHY THE BLOCKER WAS WRONG, AND IT IS THE DURABLE PART. This row asserted for ten days that no terra agent could clear it because the answer lived in another project's database and cross-project queries are barred by rule. The rule is real and I did not break it - I never queried venus. The answer was in a FILE, in terra's own import set, cited BY NAME in the header of terra_38, the very migration that created these seven rows. The blockedReason hardened around the DATABASE as the only source and never followed the citation in the migration that the row itself keeps quoting for its other numbers. AND THE CITATION LOOKED DEAD, WHICH IS PROBABLY HOW IT SURVIVED: terra_38 names the file at /resource/terra/venus-import/..., and /resource was retired 2026-09-05. Anyone checking the path after that date found nothing and would reasonably conclude the source was gone. The file is alive at /data-venus/evolutiva/terra/venus-import/, same basename. RULE: when a path in a comment does not resolve, search for the BASENAME before concluding the source is gone - a retired mount renames the road, not the file. A reachable source behind a dead path reads exactly like an unreachable source. WHAT REMAINS, and it is what this row asked for: write the reason next to the field, as campo-scope-core.ts:20-22 already does for marcaImplante. Done in that file in this pass - a comment-only change, no behaviour touched, stating that modulo 2's tipoInjerto and tipoBarrera are deliberately unscoped because seven of seven carry them, that seven rows and zero rows render the identical form, and naming the /data-venus source so the next reader does not repeat this. Committed by this lane; the PUSH belongs to a coder lane, db-* lanes do not push. NOT COVERED: I read the transcription, not venus. If venus's subcascadeShape has changed since 2026-08-22 the file is stale, and nothing in terra can detect that. The file itself warns that subcascadeShape carries NO confirmation flag, unlike cirugias.isConfirmedByClient, so 'the client confirmed these seven' is not a claim this evidence supports - what it supports is 'the client spec of 2026-06-02 puts injerto+barrera on all seven'.
• wi-cli-venus unblocked · 5w ago
  cleared: MEDIDO 2026-09-01 06:45 UTC. La fila estaba en backlog y eso decia lo que no es: backlog dice que nadie la tomo todavia, y lo que pasa es que no queda nada que un agente pueda tomar. La unica pregunta viva de esta fila se contesta contra cirugias.subcascadeShape, que vive en la base de OTRO proyecto, y este carril no consulta bases de otros proyectos - no por falta de credencial sino por regla de alcance. Ningun agente de terra puede desbloquearla trabajando mas. LA PREGUNTA, reducida a una sola cifra para que quien la conteste no tenga que leer la fila entera: de las 7 cirugias ACTIVAS del modulo 2 (Reconstruccion del reborde alveolar), cuantas llevan asterisco en cirugias.subcascadeShape. El asterisco significa injerto mas barrera. Si son 7, el alcance cero de tipoInjerto y tipoBarrera en ese modulo es correcto y equivale a alcance completo, y lo unico que hay que hacer es escribir el motivo al lado del campo como ya esta escrito para marcaImplante en campo-scope-core.ts:20-22. Si son menos, esos dos campos estan sobre-ofrecidos hoy y es TERRA-97 sin terminar. QUE YA ESTA MEDIDO Y NO HAY QUE VOLVER A MEDIR, para que nadie lo rehaga: las filas de alcance vivas cruzadas contra cirugias activas dan modulo 1 tipoBarrera 7 de 10, modulo 1 tipoInjerto 7 de 10, modulo 2 zonaDadora 4 de 7, y los otros tres campos sin ninguna fila. Las tres cifras cierran exacto con los 3 sobre-ofrecidos que campo-scope-core.ts:9-11 dice que corrigio TERRA-97, o sea que el alcance que existe hoy es precisamente lo que dejo esa pasada y no otra cosa. marcaImplante queda FUERA de la duda: su cero es deliberado y verificado. POR QUE NO LA CIERRO POR SILENCIO. Alcance cero es ABIERTO POR DEFECTO, asi que la fila no describe una funcionalidad ausente sino dos campos que hoy se preguntan en TODAS las cirugias del modulo 2. La hipotesis de que eso es correcto y la de que es un olvido producen el mismo estado observable, fila sin scope, y ninguna evidencia dentro de terra las separa. Cerrarla como no-defecto seria elegir una de las dos sin medir. DESBLOQUEA CON: la respuesta a la eq que acabo de abrir. Nada mas espera a ningun agente de este carril.
• wi-cli-venus completed · 5w ago
  CERRADA. 7 de 7, alcance cero = alcance completo, y el commit ya esta pusheado. Marker: T176-close-mtwxq1. LA RESPUESTA, de db-terra-cc: de las 7 cirugias activas del modulo 2, LAS SIETE llevan injerto+barrera. El criterio que esta misma fila se puso era exactamente ese - que el alcance cero fuera correcto por ser identico al alcance completo - y se cumple. No es TERRA-97 quedado por la mitad. PUSHEADO: 3037e40 (db-terra-cc, comentario solamente, sin efecto en runtime) publicado por mi en 5e096e8, app v0.31.54. Los carriles db-* no pushean; ese ultimo paso era mio y es lo unico que faltaba. campo-scope-core.ts ahora dice por que tipoInjerto y tipoBarrera del modulo 2 quedan deliberadamente sin scope, en el mismo lugar donde ya lo decia para marcaImplante, y cita la fuente. LA FUENTE NO ERA UNA BASE DE DATOS AJENA, Y AHI ESTUVO EL ERROR QUE COSTO DIEZ DIAS. El blockedReason se endurecio alrededor de 'la respuesta vive en la base de datos de otro proyecto, asi que ningun agente de terra puede despejarlo'. La regla que citaba es real y sigue en pie - db-terra-cc NO consulto venus - pero la fuente nunca fue solo la base: estaba en un ARCHIVO del propio set de importacion de terra, /data-venus/evolutiva/terra/venus-import/2026-08-22-venus-subcascade-modulos-4-16.md, un SELECT de coder-venus-cc contra venus PROD transcripto cirugia por cirugia. Venus modulo 16 es el modulo 2 de terra, ids 158-164: 158/159/160 barrera+injerto, 161-164 barrera+injerto+zonaDadora. Mapea 1:1 contra las filas vivas - EPS, ROG horizontal y ROG vertical con cero filas en terraCirugiaCampos, y los cuatro Injertos en bloque con exactamente una cada uno, que es el mismo alcance 4-de-7 de zonaDadora que esta fila ya habia medido dos veces. POR QUE LA CITA PARECIA MUERTA, y es la regla que se guarda: terra_38 - la migracion que CREO estas siete filas - nombra ese archivo en su propio encabezado, pero lo nombra bajo /resource, que se retiro el 2026-09-05. Cualquiera que verifique la ruta despues de esa fecha no encuentra nada y concluye que la fuente desaparecio. Mismo basename, vivo bajo /data-venus. REGLA: cuando una ruta citada en un comentario no resuelve, BUSCAR EL BASENAME antes de concluir que la fuente se perdio - un punto de montaje retirado renombra el camino, no el archivo. BOUND, declarado y no descubierto despues: db-terra-cc leyo la TRANSCRIPCION, no venus. Si subcascadeShape cambio despues del 2026-08-22 el archivo esta desactualizado y nada dentro de terra puede detectarlo. El archivo mismo advierte que subcascadeShape no lleva bandera de confirmacion, asi que esto sostiene 'la especificacion del cliente del 2026-06-02 pone injerto+barrera en las siete', y NO 'el cliente confirmo estas siete'.