Los dos campos tipoBarrera se muestran SIN el aviso de lista provisoria: el Set del front nombra terraTipoBarrera, que quedo con cero filas vivas cuando la categoria se partio en Implante y Reconstruccion
DEFECTO VISIBLE PARA EL USUARIO, no un comentario vencido. src/lib/campo-provenance.ts:20-25 declara PROVISIONAL_CAMPO_CATEGORIES con cuatro categorias - terraTipoInjerto, terraZonaDadora, terraTipoBarrera, terraMarcaImplante - y practica-form.tsx:1279 usa isProvisionalCampoCategory(campo.lookupCategory) para decidir si muestra "Lista provisoria, a confirmar por la catedra" debajo del campo. La comparacion es pertenencia exacta a un Set, sin prefijos ni normalizacion. terraTipoBarrera YA NO EXISTE COMO CATEGORIA VIVA. Medido contra la base hoy, 2026-09-01: lookupOptions tiene 7 filas bajo terraTipoBarrera y las 7 estan borradas - cero vivas. Las categorias vivas son terraTipoBarreraImplante con 4 filas y terraTipoBarreraReconstruccion con 7. Y terraModuloCampos apunta los campos a esas dos: el campo tipoBarrera del modulo 1 usa terraTipoBarreraImplante y el del modulo 2 usa terraTipoBarreraReconstruccion, los dos isActive. CONSECUENCIA EXACTA: los dos campos tipoBarrera se renderizan CON opciones - 4 y 7 respectivamente, o sea que no caen en la rama de "este campo no tiene opciones" - y SIN el aviso de lista provisoria. Se le presentan a la catedra como si fueran listas que la catedra ya confirmo. Las otras tres categorias si matchean y si muestran el aviso, asi que la pantalla se ve coherente y solo falta en un campo de cada uno de los dos modulos. POR QUE NADIE LO VIO Y POR QUE NO FALLO NADA: el unico miembro muerto del Set es el unico que no puede matchear con nada, asi que su presencia no rompe ninguna comparacion - simplemente nunca da true. Un Set con una entrada de mas no tiene sintoma. La ausencia del aviso tampoco tiene sintoma tecnico: no hay error, no hay lista vacia, no hay log. El unico lector que puede notarlo es el que sabe que tipoBarrera deberia decir provisorio, y ese es el mismo que escribio el Set. Y ES CONTRARIO A LA REGLA QUE EL PROPIO ARCHIVO CITA. El comentario dice que Elazar decidio (CLI 2026-08-22, "3b") que los CUATRO campos salieran vivos con la advertencia, porque las listas son un punto de partida que la catedra EDITA y no un hecho que terra afirma, y agrega que sacar una categoria del Set solo se hace cuando Sebastian Puia confirmo esa lista, y que la remocion ES el registro de que lo hizo, asi que tiene que citar donde. Aca la categoria no se saco: se quedo escrita mientras la categoria real se partia en dos abajo, y el efecto es el mismo que sacarla - sin la cita, sin la decision, y para dos campos en vez de uno. EL ORIGEN ES LA PARTICION: terra_33 sembro las 7 opciones bajo terraTipoBarrera. Despues alguien partio la categoria en Implante y Reconstruccion y retiro la vieja. El Set del front quedo apuntando al nombre viejo. O sea que este defecto se creo en una migracion de base que no tenia por que saber que existia un Set en TypeScript con nombres de categoria escritos a mano. Una constante en el front que enumera nombres de categorias de la base es una copia del vocabulario que nada mantiene sincronizada, exactamente la clase que ya me mordio en la lista de roles de terra_6. ARREGLO: reemplazar terraTipoBarrera por terraTipoBarreraImplante y terraTipoBarreraReconstruccion en el Set. NO alcanza con agregarlas y dejar la vieja - la vieja no matchea nada y su unica funcion hoy es hacer creer que tipoBarrera esta cubierto, que es lo que hizo hasta ahora. Y el archivo tiene que decir POR QUE son dos entradas donde antes habia una, o el proximo que lea va a "limpiar" el duplicado. SEGUNDO ITEM, ABIERTO COMO PREGUNTA Y NO COMO DEFECTO, porque no se si es deliberado: src/lib/informe-query.ts:30-34 define CAMPO_CATEGORIES con tres claves - tipoInjerto, marcaImplante, zonaDadora - y NO incluye tipoBarrera, asi que /informes no tiene desglose de tipoBarrera. El comentario dice que son "las vocabularios que Puia nombro", asi que la omision puede ser lo pedido. Lo que si esta mal es la JUSTIFICACION que da arriba: dice que agrupa por lookupCategory porque la MISMA categoria aparece bajo dos modulos - y da tipoInjerto como ejemplo, que es cierto, terraTipoInjerto esta en modulo 1 y 2. Pero tipoBarrera es el caso INVERSO: es el mismo campo bajo dos modulos con DOS categorias distintas, asi que agrupar por categoria lo partiria en dos filas, que es exactamente el defecto que el parrafo dice estar evitando. La regla enunciada solo vale para la mitad de los campos que aparecen en dos modulos. Hay que decidir si tipoBarrera entra al informe y, entre, como se agrupa. COMO APARECIO, que vale la pena porque no lo estaba buscando: informe-query.ts:30 lleva "Measured live 2026-09-01: 6 campos, 5 distinct categories". Lo medi y es CIERTO - terraModuloCampos tiene 6 campos, los 6 activos, y 5 lookupCategory distintas. La afirmacion fechada estaba bien; leer alrededor de por que 6 campos dan 5 categorias es lo que expuso la particion de tipoBarrera y de ahi salio el Set muerto. Un numero correcto no cierra la pregunta que lo rodea.
Activity
-
Arreglado por coder-terra-ca en 4d0d833 y corregido en 25f2a96 (v0.31.20). El Set queda con terraTipoBarreraImplante y terraTipoBarreraReconstruccion y sin la muerta, con el motivo de la particion escrito al lado y la condicion de Puia intacta. Verifique la cita ademas del arreglo: terra_38 es efectivamente la que parte el campo - mide pre y post de las dos categorias nuevas y su linea de rollback devuelve modulo 2 a terraTipoBarrera - y terra_39 despues borra las filas de vocabularyScopes y vocabularyScopeMembers de la vieja. EL PRIMER TEST LO BLOQUEE Y ESA ES LA PARTE QUE VALE LA PENA GUARDAR. Construia un SEGUNDO Set escrito a mano con las mismas cinco cadenas, en el mismo repo, y lo comparaba con deepEqual contra el primero. NO PODIA FALLAR POR LA CAUSA QUE LO ORIGINO: el defecto no fue que dos listas se desincronizaran entre si, fue que la BASE retiro una categoria y el front no se entero. Cuando eso vuelva a pasar las dos listas van a seguir identicas y el test verde. Medía "alguien no edito un archivo sin editar el otro", que es una propiedad mas debil, y ademas dejaba el archivo PARECIENDO cubierto, que es peor que no tener test porque nadie va a buscar cobertura donde ya hay verde. El comentario decia "Contract measured from active terraModuloCampos and live lookupOptions on 2026-09-01" y eso era cierto sobre como se ESCRIBIO la lista, no sobre lo que el test mide. EL SEGUNDO ESTA BIEN Y POR TRES MOTIVOS, uno de los cuales no lo habia pedido: el deepEqual no esta; el limite entre suite unitaria y base viva quedo escrito y NOMBRA al carril que si tiene base, o sea hueco declarado y direccionado en vez de tapado; y extrajo el guard a assertNoRetiredBarrierCategory, asi que el control must-fail ejercita LA MISMA funcion que la assertion real. Eso ultimo es lo que hace que el control valga - un must-fail que re-implementa la comparacion prueba la re-implementacion. LA DIRECCION QUE FALTA NO SE PUEDE INSTRUMENTAR Y ESO ES UN HALLAZGO, NO UNA TAREA PENDIENTE. Le pedi a db02-terra-cc las dos direcciones. La 1 - entrada del Set que no matchea nada vivo - da PASS 5/5 con opciones vivas en las cinco. La 2 - categoria activa que deberia estar en el Set y no esta - NO se puede armar como gate, y db02 lo dijo en vez de forzarlo. El motivo lo midio contra el esquema en lugar de asumirlo: ni lookupOptions ni terraModuloCampos tienen columna alguna de confirmacion o provisoriedad. LA BASE NO SABE QUE ES PROVISORIO. Se pueden enumerar las 6 filas activas con lookupCategory y ver que las 6 estan en el Set, pero eso no dice nada sobre mañana: sin marcador, una categoria nueva provisoria y una nueva ya confirmada se ven identicas. CONSECUENCIA: el Set del front es HOY EL UNICO LUGAR DONDE EXISTE LA NOCION DE PROVISORIO. Es literalmente lo que el comentario del archivo viene diciendo desde TERRA-90 - lookupOptions es compartida con enamel y no tiene isConfirmedByClient - solo que ahora esta medido contra el esquema y no citado. Agregar un campo provisorio nuevo y olvidarse del Set no lo puede detectar nadie. Si alguna vez se quiere cerrar, es un marcador de provenance en lookupOptions o terraModuloCampos; terraCirugias si tiene esa nocion via isConfirmedByClient y el sufijo " (a conf.)", estas tablas no. Queda como limite conocido, no como trabajo asignado. QUEDA ABIERTA LA PREGUNTA DE /informes, y coder hizo bien en no tocarla: CAMPO_CATEGORIES en informe-query.ts omite tipoBarrera, y no cambiar una spec de query sin autorizacion es correcto. Lo que SI esta mal hoy es la justificacion escrita arriba, no la omision: dice que agrupa por lookupCategory porque la MISMA categoria aparece bajo dos modulos, con tipoInjerto de ejemplo, que es cierto. tipoBarrera es el caso inverso - mismo campo, dos categorias - asi que agrupar por categoria lo PARTE en dos filas, justo el defecto que el parrafo dice evitar. La regla enunciada vale para la mitad de los campos que aparecen en dos modulos. Evidencia: agents/db02-terra/evidence/2026-09-01-terra-campo-provenance-set-instrument.result.txt con su .sql.