tipoBarrera fuera de /informes y la justificacion de agrupamiento que solo cubre la mitad de los casos; y que la base no tiene marcador de vocabulario provisorio, asi que una direccion del chequeo es indetectable

Sub-tickets

Activity

• wi-cli-venus created · 6w ago
• wi-cli-venus commit · 6w ago
  Item 1 written-justification correction only: 6ca746c677b9a9f8bcbe35114a44717bb0344c18. Verified CAMPO_CATEGORIES remains exactly tipoInjerto, marcaImplante, zonaDadora; source migration shows tipoBarrera has distinct terraTipoBarreraImplante and terraTipoBarreraReconstruccion categories. Updated the rationale bound only: no query-spec or behavior change; if barrera enters informes, grouping needs a deliberate decision. Verification: pnpm test (458 pass), pnpm typecheck, git diff --check.
• wi-cli-venus verified · 6w ago
  ITEM 1 CERRADO EN SU MITAD ESCRIBIBLE, con verificacion independiente. El item 1 tenia dos partes y solo una era contestable sin la catedra: si tipoBarrera entra al informe es pregunta de producto y sigue abierta; que la JUSTIFICACION escrita estuviera mal era un defecto de hoy, independiente de esa respuesta, y eso es lo que se arreglo. QUE CAMBIO: 6ca746c, src/lib/informe-query.ts, +9/-5, comentario unicamente. El parrafo justificaba agrupar por lookupCategory citando tipoInjerto - misma categoria bajo dos modulos - y estaba redactado como si la regla cubriera a todo campo repetido. Ahora acota la regla al caso de categoria compartida, nombra a tipoBarrera como el caso que NO cubre con la razon correcta (sus dos filas de campo llevan terraTipoBarreraImplante y terraTipoBarreraReconstruccion, categorias distintas, asi que agrupar por categoria lo partiria en dos filas, que es el inverso del caso tipoInjerto y exactamente el defecto que el parrafo dice evitar), y dice que si barrera alguna vez entra a /informes la decision de agrupamiento se toma a proposito y no se hereda de esta regla. LO QUE DELIBERADAMENTE NO SE HIZO: no se agrego tipoBarrera a CAMPO_CATEGORIES. Eso contestaria en silencio la pregunta de producto que esta fila deja abierta. La constante sigue teniendo exactamente tipoInjerto, marcaImplante y zonaDadora. VERIFICADO POR audit-terra-ca A CIEGAS DEL REPORTE DE QUIEN LO ESCRIBIO, que es la unica forma en que la segunda lectura vale algo: le pedi explicitamente que no leyera el informe de coder-terra-ca ni le preguntara que habia cambiado, y no le cite el texto nuevo. Cuatro veredictos separados, los cuatro PASS - regla acotada, tipoBarrera nombrado con razon correcta, decision deliberada exigida, y comportamiento sin cambios. El punto 4 no me lo reporto nadie: lo pedi yo justamente porque el riesgo de esta tarea era que alguien "mejorara" el comentario agregando el campo. Y no verifico la razon contra el comentario sino contra terra_38 aplicado, el INSERT de modulo 1 y el repoint de modulo 2, que es donde esa afirmacion se puede desmentir. Yo ademas lei el patch en origin antes de todo esto en vez de aceptar el SHA de palabra. QUE QUEDA VIVO EN ESTA FILA, sin cambios: si tipoBarrera entra al informe, que necesita respuesta de la catedra; y el item 2 entero, el limite estructural - ni lookupOptions ni terraModuloCampos tienen marcador de vocabulario provisorio, asi que una direccion del chequeo sigue siendo indetectable. La fila se queda en backlog por eso, no por falta de trabajo hecho.
• wi-cli-venus note · 6w ago
  MITAD DE ITEM 1 CERRADA 2026-09-01: la justificacion escrita ya no afirma de mas. Commit 6ca746c en src/lib/informe-query.ts, +9/-5, solo comentario, cero cambio de comportamiento. Lei el parche en origin yo mismo, no el reporte. QUE DICE AHORA: nombra la regla como el caso de CATEGORIA COMPARTIDA y da tipoInjerto como su ejemplo, y despues excluye tipoBarrera EXPLICITAMENTE por la razon medida - sus dos filas de campo usan categorias distintas, terraTipoBarreraImplante y terraTipoBarreraReconstruccion - y dice que si barrera entra a /informes su agrupamiento hay que decidirlo deliberadamente y no heredarlo de esta regla. Cierra con la medicion viva fechada: 6 campos, 5 categorias distintas. LO QUE NO CAMBIO Y ES DELIBERADO: CAMPO_CATEGORIES sigue teniendo exactamente tres claves. Agregar tipoBarrera habria contestado en silencio la pregunta de catedra que esta fila abre, o sea que la omision se mantiene como omision hasta que la catedra conteste. VERIFICACION INDEPENDIENTE: audit-terra-ca corrio cuatro chequeos de fuente y dio 4/4 PASS, contrastando la afirmacion de dos categorias contra terra_38 aplicada - INSERT de modulo 1 en :458-460 y repunte de modulo 2 en :462-464. Se le pidio a ciegas del reporte de coder-terra-ca, no despues de leerlo, porque dos carriles que coinciden despues de que uno vio la respuesta del otro son una sola medicion con dos nombres. QUE QUEDA ABIERTO EN ESTA FILA, sin cambio: la PREGUNTA DE PRODUCTO de item 1 - si tipoBarrera entra al informe - que es de la catedra y no de este carril; y ITEM 2 entero, el marcador de provisoriedad en base, que sigue siendo un hueco declarado y no tapado.
• wi-cli-venus descriptionChanged · 6w ago
  was: Salen las dos de TERRA-191 y comparten causa, por eso van juntas: la nocion de "vocabulario provisorio" no existe en la base y solo vive en una constante del front. ITEM 1, DECISION DE PRODUCTO, no defecto: src/lib/informe-query.ts define CAMPO_CATEGORIES con tres claves - tipoInjerto, marcaImplante, zonaDadora - y NO incluye tipoBarrera, asi que /informes no lo desglosa. El comentario dice que son "los vocabularios que Puia nombro", asi que la omision puede ser exactamente lo pedido, y coder-terra-ca hizo bien en no tocar una spec de query sin autorizacion cuando lo encontro. Hay que preguntarle a la catedra si tipoBarrera entra al informe. LO QUE SI ESTA MAL HOY ES LA JUSTIFICACION ESCRITA, no la omision. El parrafo dice que agrupa por lookupCategory porque la MISMA categoria aparece bajo dos modulos, y da tipoInjerto de ejemplo: cierto, terraTipoInjerto esta en modulo 1 y en modulo 2, y agrupar por campoId partiria una pregunta clinica en dos filas. Pero tipoBarrera es el caso INVERSO - mismo campo bajo dos modulos con DOS categorias distintas, terraTipoBarreraImplante y terraTipoBarreraReconstruccion - asi que agrupar por categoria lo partiria en dos filas, que es exactamente el defecto que el parrafo dice estar evitando. La regla enunciada vale para la mitad de los campos que aparecen en dos modulos, y esta escrita como si valiera para todos. Si tipoBarrera entra al informe, la decision de agrupamiento hay que tomarla explicitamente, no heredarla de una regla que no lo cubre. ITEM 2, LIMITE ESTRUCTURAL MEDIDO, y esta anotado para que no se descubra de nuevo dentro de seis meses: ni lookupOptions ni terraModuloCampos tienen columna alguna de confirmacion o provisoriedad - medido contra el esquema vivo por db02-terra-cc, no asumido, evidencia en agents/db02-terra/evidence/2026-09-01-terra-campo-provenance-set-instrument.result.txt. LA BASE NO SABE QUE ES PROVISORIO. CONSECUENCIA EXACTA: PROVISIONAL_CAMPO_CATEGORIES en src/lib/campo-provenance.ts es HOY EL UNICO LUGAR donde existe esa nocion. Se puede chequear una direccion - que ninguna entrada del Set apunte a una categoria muerta, que es el defecto de TERRA-191 y hoy da PASS 5/5 - pero NO la otra: una categoria activa nueva que deberia ser provisoria y no esta en el Set es indetectable, porque sin marcador una categoria nueva provisoria y una nueva ya confirmada se ven identicas, fila activa y sin flag. db02 dijo que no se podia armar como gate en vez de forzar una enumeracion que pareciera un chequeo. O sea que agregar un campo provisorio nuevo y olvidarse del Set no lo detecta nadie, ni el front ni la base. Es un hueco declarado, no tapado, que es la unica forma en que alguna vez se llena. ARREGLO SI SE QUIERE CERRAR: un marcador de provenance en lookupOptions o en terraModuloCampos. Ojo con lookupOptions: es tabla COMPARTIDA con enamel, asi que agregarle una columna no es decision de terra sola y necesita GO de db-enamel-cc - es justamente por eso que el Set existe, segun el propio comentario de campo-provenance.ts desde TERRA-90. terraModuloCampos si es terra-owned y seria el lugar barato. terraCirugias ya tiene la nocion equivalente via isConfirmedByClient y el sufijo " (a conf.)", asi que hay precedente de forma dentro del mismo proyecto. NO ESTA ASIGNADO Y NO PIDO QUE SE HAGA AHORA. Item 1 necesita respuesta de la catedra; item 2 necesita decidir si vale una migracion para una clase que hasta hoy fallo una sola vez.
• wi-cli-venus note · 6w ago
  CONFIRMADA LA MITAD QUE YO HABIA AFIRMADO SIN MEDIR. db02-terra-cc, SELECT solamente, 2026-09-01 08:35. YO HABIA ESCRITO que la base no tiene marcador de vocabulario provisorio y que por eso una direccion del chequeo es indetectable. Lo escribi sin abrir la tabla. Ahora esta medido y es cierto, con la lista completa a la vista para que se vea que no es una lectura parcial: lookupOptions tiene diez columnas - id, category, ownerAppKey, value, label, sortOrder, isActive, createdAt, updatedAt, deletedAt - y NINGUNA puede marcar provisorio contra confirmado. No hay booleano, ni estado, ni texto de origen. LA PARTE QUE NO ESPERABA Y QUE ES PEOR DE LO QUE LA FILA DECIA. terra_33 dice en su cabecera que la marca de procedencia se puso en TRES lugares, justamente porque lookupOptions es compartida y terra no puede agregarle una columna. Los tres lugares son: (a) la cabecera de la migracion, (b) PROVISIONAL_CAMPO_CATEGORIES en src/lib/campo-provenance.ts, (c) pm/05-client-info.md. LOS TRES ESTAN FUERA DE LA BASE. Consultables por una query: CERO de tres. Y (a) ES PEOR QUE "fuera de la base": ya esta medido que Supabase STRIPEA los comentarios de dos guiones del statement que registra, asi que ese texto ni siquiera vive en pg_catalog - existe unicamente en el archivo del repo. O sea que la unica marca que se escribio pensando en ser "el registro de registro" es la que menos sobrevive. RESPUESTA A LA PREGUNTA QUE PLANTEE: hoy, alguien que mira SOLO la base NO puede saber que estas cuatro listas son provisorias. La fila queda confirmada, y ahora ademas explica POR QUE, que es lo que le faltaba. POBLACION HOY contra lo sembrado, con ownerAppKey terra: terraTipoInjerto 9 hoy contra 5 sembradas; terraZonaDadora 15 contra 9; terraTipoBarrera 7 contra 7; terraMarcaImplante 19 contra 15. Tres de las cuatro crecieron. LO QUE NO SE PUEDE SABER, y db02 lo separo como inferido en vez de explicarlo: updatedAt distinto de createdAt da 5/9, 9/15, 7/7 y 1/19, pero updatedAt no dice CUAL cambio hubo. El crecimiento post-siembra es COMPATIBLE con "la catedra ya confirmo algunas" y tambien con cualquier otra edicion. No hay confirmedAt. Asi que ni siquiera se puede distinguir una lista que la catedra ya reviso de una que nadie miro. CONSECUENCIA CONCRETA que la fila no tenia escrita: terraMarcaImplante crecio de 15 a 19 filas. Cuatro marcas nuevas entraron despues de la siembra. Si esas cuatro son confirmaciones de la catedra, entonces el camino que TERRA-141 dice que no existe SI se uso alguna vez por fuera de la app - y no hay forma de saberlo desde la base. Lo dejo como pregunta, no como conclusion.
• wi-cli-venus note · 6w ago
  ITEM 2 VERIFICADO POR SEGUNDA MANO, 2026-09-01 10:22 UTC. La afirmacion "la base no sabe que es provisorio" la habia medido db02-terra-cc, o sea el mismo carril que despues la uso para justificar no armar el gate. La re-corri yo contra information_schema y SE SOSTIENE. CON DENOMINADOR, que es lo que le faltaba a la fila: lookupOptions tiene 10 columnas - id, category, ownerAppKey, value, label, sortOrder, isActive, createdAt, updatedAt, deletedAt. terraModuloCampos tiene 10 - id, moduloId, key, label, inputType, lookupCategory, orden, isRequired, isActive, createdAt. Veinte columnas en total y NINGUNA de confirmacion, provisoriedad o provenance. isActive es vigencia, no confianza: una categoria provisoria y una confirmada son las dos isActive true y ahi se terminan las diferencias. O SEA QUE LA DIRECCION INDETECTABLE SIGUE INDETECTABLE, y ahora esta medido dos veces por separado en vez de una: una categoria activa nueva que deberia ser provisoria y no esta en PROVISIONAL_CAMPO_CATEGORIES no la encuentra nadie, porque no hay columna que distinguiera el caso. SIN CAMBIO DE ESTADO Y A PROPOSITO. La fila dice explicitamente que no pide que se haga ahora: el item 1 espera respuesta de la catedra sobre si tipoBarrera entra al informe, y el item 2 espera decidir si vale una migracion para una clase que fallo una sola vez. La dejo SIN ASIGNAR, que es lo honesto - asignarla hoy seria fabricar trabajo sobre dos decisiones que no estan tomadas. Lo unico que agrego es que el limite estructural quedo confirmado y con las veinte columnas enumeradas, para que el dia que se decida no haya que volver a medirlo.
• wi-cli-venus verified · 6w ago
  LAS DOS AFIRMACIONES DE ESTA FILA SIGUEN VIVAS. Auditado por coder-terra-ca sobre 6ca746c, RE-VERIFICADO POR MI leyendo informe-query.ts, 2026-09-01 11:36 UTC. El resultado util es que NO HAY QUE CORREGIR NADA - hoy eso no se podia dar por sentado, porque las dos filas anteriores que revise en el dia, TERRA-131 y TERRA-127, resultaron vencidas. (1) tipoBarrera FUERA DE /informes: VIVA. CAMPO_CATEGORIES enumera tipoInjerto, marcaImplante y zonaDadora, y nada mas. Los seis sitios de llamada de las lineas 215-220 usan esas tres. tipoBarrera aparece UNA SOLA VEZ en todo el archivo, en la linea 29, y es dentro de un comentario - no hay filtro, ni selector de vocabulario, ni campo de resultado, ni desglose. Lo conte yo, no lo acepte del reporte. (2) LA JUSTIFICACION DE AGRUPAMIENTO CUBRE SOLO LA MITAD: VIVA, y 6ca746c la mejoro sin invalidarla - la hizo EXPLICITA en vez de dejarla implicita. El comentario dice ahora con todas las letras que la regla de categoria compartida vale para tipoInjerto, que es campo de Implantologia y de Reconstruccion con la MISMA categoria terraTipoInjerto, y que NO CUBRE tipoBarrera, cuyas dos filas usan categorias DISTINTAS - terraTipoBarreraImplante y terraTipoBarreraReconstruccion. O sea que la fila describe correctamente el estado: la justificacion existe, es correcta, y alcanza a la mitad de los casos por una razon escrita. Y ESE COMENTARIO LLEVA SU MEDICION FECHADA - "Measured live 2026-09-01: 6 campos, 5 distinct categories". Es lo que le pedi hoy a este mismo carril en otro archivo y aca ya estaba hecho. TERCERA COSA, QUE NO ES DE ESTA FILA Y LA ABRO APARTE PARA NO ESCONDERLA ACA: el mismo archivo justifica una INTERPOLACION DE STRING dentro de SQL con un comentario que afirma en presente que los sitios de llamada son solo tres. Va a fila propia. LIMITE DECLARADO, tal como lo escribio el carril y lo mantengo: se leyo el commit y el estado actual de informe-query.ts, y se verifico que ningun commit posterior toca ese archivo. NO se consulto la base, NO se ejercito /informes, NO se inspecciono un build desplegado. Si la medicion fechada del comentario sigue valiendo hoy es UNKNOWN - la fecha dice cuando se midio, no que se haya vuelto a medir. SIN CAMBIO DE CODIGO. Es verificacion de frescura, y el resultado es que la fila esta bien como esta.
• wi-cli-venus verified · 6w ago
  CERRADA LA PREGUNTA DE LAS CUATRO MARCAS, y la respuesta es NO: el camino de aprobacion NUNCA se uso. Estaba escrita explicitamente como pregunta y no como conclusion - "si esas cuatro son confirmaciones de la catedra, entonces el camino que TERRA-141 dice que no existe SI se uso alguna vez por fuera de la app, y no hay forma de saberlo desde la base". Habia forma. Es esta. EL HECHO, medido contra lookupOptions con los timestamps completos y no solo el conteo: las 19 filas de terraMarcaImplante con ownerAppKey terra se reparten en DOS instantes y nada mas. QUINCE llevan createdAt 2026-08-22 09:18:58.62108 - al microsegundo, las quince identicas, o sea UNA transaccion. CUATRO llevan 2026-08-22 13:36:01.638913, tambien identicas entre si: fia, implantsim, inspiral y nuvo. POR QUE ESO YA DESCARTA LA HIPOTESIS ANTES DE MIRAR EL REPO: cuatro confirmaciones de la catedra llegando por un camino de aprobacion serian cuatro decisiones separadas, dispersas en el tiempo. Cuatro filas con el MISMO microsegundo son una sola escritura. La forma de la evidencia contesta la pregunta sin necesidad de saber quien escribio. Y EL ESCRITOR TAMBIEN ESTA IDENTIFICADO, para no dejarlo en inferencia: db/migrations/applied/terra_35_marca_implante_espe_brands.sql inserta las cuatro por nombre. Es una migracion, aplicada, con las marcas escritas en el archivo. EL DETALLE QUE CONFIRMA QUE FUE LA MISMA TRANSACCION Y NO DOS COSAS QUE COINCIDEN: la fila 'otra' tiene createdAt 09:18:58.62108 - o sea que venia de la siembra - pero updatedAt 2026-08-22 13:36:01.638913, EXACTAMENTE el createdAt de las cuatro nuevas. terra_35 la reubico al final del orden al meter las marcas nuevas. Un updatedAt que coincide al microsegundo con el createdAt de otras filas es la firma de una sola transaccion, y es lo que descarta que las cuatro hayan llegado por un camino distinto que casualmente corrio ese dia. QUE LE HACE ESTO A CADA FILA: A TERRA-192: cierra el unico punto que quedaba abierto como pregunta. El crecimiento post-siembra de terraMarcaImplante NO es evidencia de un camino de confirmacion no documentado; es una migracion. Las otras dos categorias que crecieron - terraTipoInjerto de 5 a 9 y terraZonaDadora de 9 a 15 - no las medi con este metodo y NO extiendo la conclusion a ellas: lo digo en vez de dejar que se lea como que las tres quedaron explicadas. A TERRA-141: REFUERZA su premisa en vez de contradecirla, que era el riesgo. La fila afirma que el camino para que la catedra agregue una marca NUNCA SE CONSTRUYO. Si las cuatro hubieran sido confirmaciones, la premisa era falsa y la fila habria que reescribirla entera. Son una migracion escrita a mano, o sea que la unica forma en que una marca entro al catalogo despues de la siembra es que alguien escribiera SQL. Eso es exactamente lo que la fila pide reemplazar. Y AGREGA UN DATO QUE LA eq 83 NO TENIA: agregar una marca hoy no es solo "no hay superficie", es que la operacion REAL que se hizo la ultima vez fue una migracion aplicada por un carril de base. Sea cual sea la respuesta sobre quien aprueba, el paso final aterriza en una migracion - que es lo que el diseño ya proponia - y ahora eso tiene un precedente medido en vez de ser una suposicion de arquitectura. RECORDATORIO QUE NO CAMBIA: agregar una marca son DOS escrituras, lookupOptions mas vocabularyScopeMembers, porque terraMarcaImplante SI tiene scope en modo include con 19 miembros. La cabecera de terra_35 dice lo contrario y era cierta cuando se escribio.
• wi-cli-venus note · 6w ago
  CORRIJO UNA CIFRA MIA DE ESTA MISMA FILA, Y EL ERROR ES DE LA CLASE QUE ACABO DE CERRAR EN TERRA-180 HACE VEINTE MINUTOS. Medido 2026-09-01 12:42 UTC, hora leida del reloj. LO QUE ESTA ESCRITO MAS ARRIBA EN ESTA FILA: "POBLACION HOY contra lo sembrado, con ownerAppKey terra: terraTipoInjerto 9 hoy contra 5 sembradas; terraZonaDadora 15 contra 9; terraTipoBarrera 7 contra 7; terraMarcaImplante 19 contra 15. TRES DE LAS CUATRO CRECIERON." ESO ES FALSO. Los conteos son correctos como TOTALES y la conclusion que se saco de ellos no lo es, porque NINGUNO FILTRA deletedAt. Con el desglose: - terraTipoInjerto: 9 totales, 4 ACTIVAS, 5 BORRADAS. No crecio de 5 a 9: fue REEMPLAZADA. Cinco viejas borradas, cuatro nuevas. Neto MENOS UNO. - terraZonaDadora: 15 totales, 6 ACTIVAS, 9 BORRADAS. Tampoco crecio: nueve viejas borradas, seis nuevas. Neto MENOS TRES. - terraTipoBarrera: 7 totales, CERO ACTIVAS, 7 BORRADAS. La categoria entera esta retirada - terra_38 la partio en terraTipoBarreraImplante (4) y terraTipoBarreraReconstruccion (7). Leerla como "7 contra 7, no crecio" la presenta como estable cuando en realidad ya no existe. - terraMarcaImplante: 19 totales, 19 ACTIVAS, 0 BORRADAS. ESTA SI CRECIO, y es la UNICA. O SEA QUE LA FRASE CORRECTA ES "UNA DE LAS CUATRO CRECIO", no tres. Dos fueron reemplazadas y ENCOGIERON, y una esta retirada por completo. POR QUE LO ESCRIBO COMO CORRECCION Y NO SOLO CAMBIO EL NUMERO: es EXACTAMENTE el defecto de TERRA-180. Ahi el problema era que las lecturas de campos de informe-query.ts contaban filas archivadas junto con las vigentes, y lo cerre hace veinte minutos habiendo forzado el brazo rojo cinco veces. La misma omision - contar sin filtrar el borrado logico - estaba en una medicion mia, en bwi, hecha antes ese mismo dia, y sobrevivio a que yo pasara la tarde entera arreglando la version de codigo del mismo error. Y NO ES INOCUA, porque de ese numero salio una hipotesis: "tres de las cuatro crecieron" alimentaba la pregunta de si la catedra habia confirmado vocabulario por fuera de la app. Con el desglose, dos de esas tres no son confirmaciones de nada - son reemplazos de terra_38 - y la unica que de verdad crecio ya quedo atribuida a terra_35 en el evento anterior. La hipotesis se apoyaba en dos casos que no existian. LO QUE SI QUEDA CONFIRMADO Y AHORA SIN EL AGUJERO: TODO el vocabulario propio de terra se escribio en CUATRO INSTANTES, y ninguno tiene forma de goteo. 2026-07-27 14:11:27.948224 la siembra original - regiones, anestesia, complicaciones intra y post. 2026-08-22 09:18:58.62108, 13:36:01.638913 y 14:48:45.903403 las tres operaciones de agosto. Dentro de cada instante los timestamps son identicos al microsegundo, o sea una transaccion cada uno. No hay una sola fila escrita fuera de esos cuatro momentos. ENTONCES LA CONCLUSION DEL EVENTO ANTERIOR SE EXTIENDE A TODAS LAS CATEGORIAS Y NO SOLO A MARCA, que era el limite que yo mismo habia declarado: NINGUNA opcion de vocabulario de terra entro nunca por fuera de una migracion. Lo habia dejado como no medido para no extender de mas; una consulta lo cerraba y por eso la corri en vez de dejarlo anotado. REGLA QUE ME LLEVO: un conteo de una tabla con borrado logico no es una poblacion hasta que declara isActive y deletedAt. Un total sin ese desglose no distingue crecimiento de reemplazo, y reemplazo con encogimiento se lee como crecimiento - que es la direccion mas engañosa de las dos.
• wi-cli-venus note · 6w ago
  CORRIJO UNA AFIRMACION MIA DE HOY SOBRE terra_35, Y ES LA SEGUNDA CORRECCION QUE ME HAGO EN ESTA MISMA FILA. Hora leida del reloj en la corrida que escribe esto. LO QUE ESCRIBI ANTES, cerrando el evento de las cuatro marcas: "La cabecera de terra_35 dice lo contrario y ERA CIERTA CUANDO SE ESCRIBIO". Me refería al comentario de terra_35 linea 41, que dice que terraMarcaImplante no tiene scope. NO ERA CIERTA CUANDO SE ESCRIBIO. Medido en vocabularyScopes: el scope de terraMarcaImplante se creo 2026-08-22 08:34:03.048452+00, en modo include. terra_35 escribio sus filas 2026-08-22 13:36:01.638913+00. Cinco horas y dos minutos DESPUES. La categoria ya tenia scope cuando el autor escribio que no lo tenia. POR QUE ME EQUIVOQUE, y es una forma de error que vale nombrar porque es comoda: asumi la explicacion BENIGNA - un comentario que fue verdadero y despues envejecio - porque es la que uno espera encontrar en un repositorio que funciona, y porque el comentario esta bien redactado y suena a alguien que verifico. No mire el timestamp del scope. Estaba a una consulta. Y NO ES UNA CORRECCION COSMETICA, porque las dos versiones piden ARREGLOS DISTINTOS. Si el comentario hubiera envejecido, el problema era de documentacion que se pudre y el arreglo es refrescarla. Siendo falso desde el principio, el problema es que ALGUIEN VERIFICO MAL Y ESCRIBIO EL RESULTADO COMO SI FUERA UN HECHO, y ninguna regla de proceso que pida documentar la decision lo agarra - el autor la documento. Eso ya quedo escrito en TERRA-198, que es donde vive el arreglo. LO QUE NO CAMBIA, y conviene decirlo para que la correccion no se lea como un derrumbe: la conclusion del evento de las marcas SIGUE EN PIE ENTERA. Las 19 filas de terraMarcaImplante siguen repartidas en dos instantes identicos al microsegundo, las cuatro marcas nuevas siguen viniendo de terra_35, y el camino de aprobacion de la catedra sigue sin haberse usado nunca. La correccion es sobre POR QUE el autor omitio los members, no sobre quien escribio las filas. TERCERA VEZ HOY QUE UN SUPUESTO PLAUSIBLE Y NO MEDIDO ME DEVUELVE UNA AFIRMACION FALSA EN ESTA FILA: los conteos sin filtrar deletedAt, las horas derivadas del contexto en vez del reloj, y ahora un comentario que di por vigente sin mirar la fecha de lo que describe. Las tres son la misma clase - algo verdadero DE OTRA COSA, o verdadero EN OTRO MOMENTO, aceptado porque encajaba.
• wi-cli-venus blocked · 5w ago
  Bloqueado en dos decisiones: la catedra debe decir si tipoBarrera entra a /informes y como agrupar sus dos categorias; producto debe autorizar el marcador persistente de vocabulario provisorio y su semantica antes de una migracion. El defecto escribible de justificacion ya fue corregido en 6ca746c.
• wi-cli-venus verified · 5w ago
  Independent audit PASS 2026-09-10: blocker states the actual pending product decisions and makes no unproven implementation claim.
• wi-cli-venus assigned · 5w ago
  coder02-terra-ca
• wi-cli-venus assigned · 5w ago
  db-terra-cc
• wi-cli-venus verified · 5w ago
  ITEM 2 REVALIDATED, STILL TRUE - db-terra-cc 2026-09-11, marker VOCAB192-mtwrtc. Re-read the live schema rather than trusting the 09-01 measurement. lookupOptions columns: id, category, ownerAppKey, value, label, sortOrder, isActive, createdAt, updatedAt, deletedAt. terraModuloCampos columns: id, moduloId, key, label, inputType, lookupCategory, orden, isRequired, isActive, createdAt. NEITHER TABLE HAS ANY PROVENANCE OR CONFIRMATION COLUMN, so the structural limit this row records is unchanged: the database still cannot distinguish a provisional vocabulary from a confirmed one, PROVISIONAL_CAMPO_CATEGORIES in src/lib/campo-provenance.ts remains the only place that notion exists, and the undetectable direction (a new active category that should be provisional but was never added to the Set) remains undetectable. Item 1 (whether tipoBarrera enters /informes, and how to group its two categories) is a catedra question and is untouched by anything measurable here. One adjacent fact from today's TERRA-201 pass, relevant to item 1's grouping problem: tipoBarrera does carry two distinct lookupCategory values across the two modules - terraTipoBarreraImplante in modulo 1 and terraTipoBarreraReconstruccion in modulo 2 - confirmed live. So the row's claim that grouping by category would split it in two is correct as written, not an inference.
• wi-cli-venus verified · 5w ago
  ITEM 1 REENCUADRADO CONTRA LA FUENTE, E ITEM 2 CERRADO CON CODIGO. Commit f8b667c, marcador BARRERA192-mtwzq4. Esto CORRIGE una afirmacion mia de hoy en esta misma fila: el evento de las 09:46 dice que el item 1 esta "untouched by anything measurable here". Era falso - habia una fuente que medir y no la habia leido. ITEM 1, LA PREMISA ESCRITA EN EL CODIGO ERA FALSA. src/lib/informe-query.ts justificaba las tres claves de CAMPO_CATEGORIES con "the campo vocabularies Puia named". La unica frase del cliente sobre vocabularios de campo es pm/05-client-info.md:273 y nombra CUATRO, no tres: "tipo de injerto, zona dadora, tipo de barrera, marca de implantes, etc." (corroborado en :128). Y los nombra como cosas que ABREN LOS MODULOS - campos del formulario - no como dimensiones de un informe. Ninguna fuente del cliente enumera un desglose para /informes: su unico pedido sobre esa pantalla, :285, es ver "las mezclas de info de los alumnos", sin dimensiones. Verificado ademas contra el origen: 3d56671, el commit que creo /informes, dice "built with all seven filters he named" - filtros, no desgloses. O SEA QUE LA FRASE ERA FALSA EN LAS DOS MITADES: ni son las que Puia nombro, ni Puia nombro dimensiones de informe. Corregida en f8b667c donde vive, con las dos citas y sus lineas. NO TOQUE CAMPO_CATEGORIES: que tipoBarrera entre al informe sigue siendo decision de producto. Lo que cambia es que ya no se puede cerrar citando una frase que dice lo contrario, que es exactamente la clase de defecto que esta fila viene arrastrando (el comentario de terra_35 que se verifico mal y se escribio como hecho). ITEM 2 NO NECESITA MIGRACION, Y ESO CONTRADICE LA CONCLUSION QUE LA FILA TENIA ESCRITA. La fila decia que la direccion faltante - una categoria activa nueva que deberia ser provisoria y nadie agrego al Set - es indetectable sin una columna de provenance, y db02 lo cerro con "catching that needs a DB-side is-this-provisional signal that does not exist". Eso es cierto de CLASIFICAR y no de ENUMERAR, y la fila las trato como la misma cosa. LO QUE SI SE PUEDE: una lookupCategory solo entra a terraModuloCampos por una migracion aplicada. No es un supuesto de arquitectura, esta medido en esta misma fila - todo el vocabulario propio de terra se escribio en cuatro transacciones de migracion y no hay una sola fila fuera de ellas. Entonces el corpus de migraciones ES la lista completa de categorias que existieron alguna vez, y el chequeo que cierra la direccion es de TOTALIDAD sobre esa enumeracion, no un flag: cada categoria que el corpus escribe en terraModuloCampos tiene que estar en exactamente uno de tres conjuntos declarados en codigo. Una categoria nueva no esta en ninguno, el test se pone rojo, y una persona tiene que decir cual es. El juicio sigue siendo humano; el gate solo se niega a que quede sin hacer. NO ES LA TAUTOLOGIA QUE campo-provenance.test.ts SE NIEGA A ESCRIBIR, y esa objecion es correcta y la respeto: comparar la constante contra una segunda constante escrita a mano no puede fallar por la causa real. La entrada de este gate es db/migrations/{applied,draft}/*.sql - un directorio que nadie edita para que un test pase, y el mismo origen que ya lee el guard de TERRA-198. CONJUNTOS, en src/lib/campo-provenance.ts: PROVISIONAL_CAMPO_CATEGORIES sin cambios (5). CONFIRMED_CAMPO_CATEGORIES nace VACIO y es el estado honesto, no un olvido - la catedra no confirmo ningun vocabulario todavia, que es justamente lo que esta fila espera. RETIRED_CAMPO_CATEGORIES lleva terraTipoBarrera, el literal de TERRA-191: terra_31 lo sembro, terra_38 lo partio en las dos por modulo, y dejarlo sin clasificar dejaba el gate rojo para siempre. Los tres disjuntos, y classifyCampoCategory LEVANTA si una categoria cae en dos - una categoria provisoria y confirmada a la vez muestra "a confirmar por la catedra" bajo un campo ya firmado, o esconde el aviso bajo uno que no. MEDIDO VIVO HOY, no heredado: las cinco lookupCategory activas de terraModuloCampos son exactamente las cinco del Set provisorio; el corpus aplicado escribe seis, esas cinco mas la retirada. El test fija las dos listas, asi que una categoria que DESAPARECE se ve igual de rapido que una que llega. BRAZOS ROJOS FORZADOS, uno de ellos sobre un directorio real y no solo sobre un string: campo nuevo sin clasificar, repunte de un campo existente a una categoria nueva (lo que hizo terra_38), escritura a lookupOptions que NO debe escanearse - terraAnestesia, terraRegionAnatomica y las complicaciones no son campos y marcarlas haria llorar al lobo hasta que alguien borrara el gate -, comentario que no es escritura, y doble clasificacion. El brazo de directorio se arma su propio temp dir en vez de dejar un archivo en db/migrations/draft: ese arbol lo escriben cinco carriles a la vez y un test no muta un arbol compartido. npm test 547/547, tsc limpio. QUE QUEDA DE LOS DOS BLOQUEOS. El de producto sobre el marcador persistente YA NO BLOQUEA NADA: la deteccion existe sin migracion, asi que la columna de provenance pasa de ser el arreglo necesario a ser una mejora opcional que nadie tiene que decidir hoy. El de la catedra se reduce a UNA sola pregunta, y la mitad que parecia pregunta no lo era: si tipoBarrera entra a /informes y, si entra, si sus dos categorias - terraTipoBarreraImplante y terraTipoBarreraReconstruccion - van como UNA fila o como DOS.
• wi-cli-venus blocked · 5w ago
  UNA SOLA DECISION, marcador BARRERA192-mtwzq4 y commit f8b667c. La catedra tiene que decir si tipoBarrera entra a /informes y, si entra, si sus dos categorias - terraTipoBarreraImplante y terraTipoBarreraReconstruccion - van como UNA fila o como DOS. LOS OTROS DOS BLOQUEOS SE CAYERON: el item 1 no era pregunta para la catedra en su mitad de premisa - la justificacion escrita citaba a Puia diciendo tres vocabularios y la unica frase suya, pm/05-client-info.md:273, nombra cuatro incluido tipo de barrera, y los nombra como campos de formulario y no como dimensiones de informe; corregido en f8b667c. El item 2 ya no espera autorizacion de producto: la direccion indetectable quedo detectable SIN migracion, con un gate de totalidad sobre el corpus de migraciones, asi que la columna de provenance es opcional y no el arreglo necesario.
• wi-cli-venus unblocked · 5w ago
  RULED by pmmaster-evolutiva-cc on Elazar behalf 2026-09-11, on db-terra-cc reduction of this row to one question (marker BARRERA192-mtwzq4, code at f8b667c, 547/547, not pushed - db lanes do not push). ANSWER: tipoBarrera does NOT enter /informes. And IF it ever does, it renders as TWO rows, never one. ON WHETHER IT ENTERS. The premise that made this a catedra question was false in both halves and db-terra-cc disproved it rather than escalating it: informe-query.ts justified its three breakdown vocabularies as "the campo vocabularies Puia named", but the only client sentence on campo vocabularies (pm/05-client-info.md:273) names FOUR, including tipo de barrera, and names them as things the MODULOS open - form campos, not report dimensions. No client source names /informes dimensions at all. So there was never a client mandate to include tipoBarrera, and there is none to exclude it either. With no requirement on either side, adding a report dimension nobody has asked for is speculative, and the row has spent weeks blocked on a question the client never posed. It stays out until someone names a use for it. ON ONE ROW VERSUS TWO, and this is the half worth keeping even though the answer above makes it moot today. terraTipoBarreraImplante and terraTipoBarreraReconstruccion are scoped to DIFFERENT modulos. No cirugia is in both, so the two vocabularies are never simultaneously applicable to one practica. Rendering them as a single row would sum across a boundary that carries meaning - one structure answering two questions - and the resulting figure would be a number no clinician could act on, since it would silently blend two populations that were never comparable. If this is ever revisited: TWO rows, and that is not a presentation preference, it is a correctness constraint. FLAGGED, NOT ACTIONED, because expanding this row is how it got stuck: the false justification covered all THREE existing breakdown vocabularies, not only the absent fourth. Those three are now known to rest on a citation that does not say what it was read as saying. That does not make them wrong - it makes them unexamined. If anyone later asks why /informes breaks down by exactly those three, the honest answer today is that nobody knows, and that belongs in its own row rather than here. WHAT db-terra-cc DELIVERED THAT CLOSED THE OTHER HALF: item 2 needed no migration and no product decision. Classifying a vocabulary needs provenance; ENUMERATING one does not, because a lookupCategory only reaches terraModuloCampos through an applied migration - measured, all terra vocabulary written in four migration transactions, zero rows outside. So the corpus IS the complete list, and a totality gate over it (every category written must be in exactly one of provisional/confirmed/retired, all declared in code) turns "somebody forgot the Set" into a red npm test, with forced-red arms including one over a real directory. The provenance column is now optional rather than necessary. Note the relationship to TERRA-224, which is still worth building: that row marks a vocabulary as provisional so the STATE is observable; this gate makes an OMISSION observable. Different halves, do not merge them.
• wi-cli-venus verified · 5w ago
  FALLADO Y ESCRITO EN EL CODIGO. Marcador BARRERA192-ruled-mtwzi. Fallo de pmmaster-evolutiva-cc relayado 2026-09-11 10:18 ART, commit 694255c. EL FALLO: tipoBarrera NO entra a /informes. Sin ninguna fuente del cliente que nombre dimensiones de informe en un sentido ni en el otro, agregar una dimension que nadie pidio es especular. SI ALGUNA VEZ SE REVISA: DOS filas, nunca una - las dos categorias estan scopeadas a modulos distintos, asi que ninguna cirugia esta en las dos y una fila fusionada sumaria cruzando un limite que significa algo. ESO CIERRA LAS DOS MITADES DEL ITEM 1, y la segunda mitad es la que el parrafo de informe-query.ts venia pidiendo explicitamente desde 6ca746c: "si tipoBarrera entra al informe, la decision de agrupamiento hay que tomarla explicitamente, no heredarla de una regla que no lo cubre". Se tomo. Y quedo escrita DONDE VIVE LA DECISION, no solo en la fila: el comentario de f8b667c todavia decia "OPEN PRODUCT QUESTION" en presente y ahora dice el fallo, con la razon de las dos filas. LO QUE EL FALLO AGREGA Y YO NO HABIA VISTO, anotado aca porque es lo que queda vivo de esta fila: la cita falsa cubria TAMBIEN a los tres desgloses que SI estan. Era la unica razon escrita para que el conjunto sea tipoInjerto, marcaImplante y zonaDadora, asi que esos tres quedan NO EXAMINADOS, no equivocados - ninguna fuente del cliente los eligio tampoco. No se propone sacar ninguno y no hay defecto que arreglar. Esta fila se queda con la pregunta si alguien pregunta por que esos tres. ITEM 2 CONFIRMADO POR EL MISMO FALLO: enumerar no necesita provenance porque una lookupCategory solo llega a terraModuloCampos por una migracion aplicada, asi que el corpus ES la lista. El gate de totalidad de f8b667c es la forma que toma. ESTADO: pasa a todo. No corri test ni build para 694255c - son solo comentarios y coder-terra-cc serializa el unico push del rango y pidio que nadie arranque un build en terra hasta que aterrice. ADVERTENCIA QUE NO ES DE ESTA FILA PERO LA TOCA: db03-terra-cc me paso para aplicar db/migrations/draft/terra_224_vocabulary_provisional_ratification.sql, que es exactamente el marcador persistente de vocabulario provisorio que el bloqueo de esta fila decia que producto tenia que autorizar antes de una migracion. NO LA APLICO sin que eso se decida, y ahora ademas hay que decidirla contra una deteccion que ya existe sin migracion. Va como aviso a pmmaster, no como accion.
• wi-cli-venus unblocked · 5w ago
  Fallado por pmmaster-evolutiva-cc 2026-09-11: tipoBarrera NO entra a /informes, y si se revisa van DOS filas y nunca una. Escrito en el codigo en 694255c, no solo en la fila. Item 2 cerrado sin migracion en f8b667c. Queda vivo un solo punto, y es nuevo: la cita falsa cubria tambien a los tres desgloses que si estan, asi que tipoInjerto, marcaImplante y zonaDadora quedan NO EXAMINADOS - ninguna fuente del cliente los eligio tampoco. No hay defecto que arreglar ni se propone sacar ninguno; esta fila se queda con la pregunta.
• wi-cli-venus blocked · 5w ago
  T192-BLOCK-mtx6j17xrucd. Bloqueada por una DECISION DE PRODUCTO, no por trabajo de base. Preguntado a pmmaster-evolutiva-cc 2026-09-11: si tipoBarrera entra a /informes y, en ese caso, si agrupa por campo o por categoria. Item 1 no es un defecto - la omision puede ser exactamente lo pedido - pero la regla de agrupamiento escrita cubre la mitad de los casos: tipoInjerto es UNA categoria bajo dos modulos (agrupar por campoId partiria una pregunta clinica en dos), mientras que tipoBarrera es el caso inverso, UN campo bajo dos modulos con DOS categorias (terraTipoBarreraImplante y terraTipoBarreraReconstruccion), asi que agrupar por categoria lo parte en dos, que es justo el defecto que la regla dice evitar. La justificacion escrita ya se corrigio en 6ca746c; lo que sigue abierto es la decision, y no la puede tomar este lane. Item 2 no necesita nada: registra un limite estructural ya medido contra el esquema vivo - ni lookupOptions ni terraModuloCampos tienen columna de confirmacion o provisoriedad, asi que 'vocabulario provisorio' solo existe en una constante del front y una direccion del chequeo es indetectable en la base. Desbloquea con la respuesta de la catedra, no con codigo.
• wi-cli-venus unblocked · 5w ago
  T192-SPLIT-mtx6nw3avmjb. Se desbloquea para cerrarse partida, por decision de pmmaster-evolutiva-cc: bloquearla estaba mal porque la mitad tecnica no necesitaba a nadie.
• wi-cli-venus completed · 5w ago
  T192-CLOSE-mtx6nw3avmjb. CERRADA PARTIDA, no resuelta de un lado solo. Por decision de pmmaster-evolutiva-cc 2026-09-11, que corrige mi bloqueo: la fila mezclaba una decision tecnica que mi propia evidencia ya resolvia con una pregunta de producto que nadie de este lado puede contestar, y bloquear las dos juntas dejaba la primera sin registrar y la segunda inbuscable. 1. LA MITAD DE AGRUPAMIENTO QUEDA DECIDIDA AQUI, POR CAMPO. Si tipoBarrera entra a /informes, agrupa por campoId, no por lookupCategory. LA REGLA, escrita en la forma general porque esa es la parte que se pierde: la clave de agrupamiento es la que mantenga UNA PREGUNTA CLINICA EN UN SOLO GRUPO, y ninguna de las dos claves es correcta globalmente. tipoInjerto es UNA categoria bajo dos modulos, asi que agrupar por campoId lo partiria - de ahi el agrupamiento por categoria que existe hoy en src/lib/informe-query.ts. tipoBarrera es el caso exactamente inverso, UN campo bajo dos modulos con DOS categorias (terraTipoBarreraImplante y terraTipoBarreraReconstruccion), asi que agrupar por categoria lo parte en dos - que es el defecto que la regla dice evitar. Misma regla, mecanismo opuesto, resultado opuesto. La justificacion escrita en el codigo ya se habia corregido en 6ca746c y nombra el caso de categoria compartida excluyendo tipoBarrera explicitamente; lo que faltaba era decir cual es la clave correcta para el caso inverso, y ahora esta dicho. 2. LA PREGUNTA DE PRODUCTO SE VA A TERRA-237: entra tipoBarrera al desglose de /informes. Es de la catedra y no la contesta ningun agente. Se le da fila propia por la razon que dio pmmaster y que vale mas que este caso: una pregunta guardada dentro del historial de otra fila no quedo sin registrar, quedo INBUSCABLE. Mismo movimiento que TERRA-59 -> TERRA-214. 3. EL ITEM 2 SE VA A TERRA-238: ni lookupOptions ni terraModuloCampos tienen columna de confirmacion o provisoriedad, medido contra el esquema vivo por db02-terra-cc, asi que 'vocabulario provisorio' vive solo en una constante del front y una direccion del chequeo es indetectable en la base. Se traslada como HUECO DE ESQUEMA accionable y no como nota: la fila nueva dice explicitamente que agregar la columna toca una tabla compartida con enamel y necesita GO de db-enamel-cc, y que declarar el limite tambien es un cierre valido - lo que no vale es que el limite siga sin estar en ningun lado consultable. No queda contenido en esta fila que no este en TERRA-237 o TERRA-238.