Antecedentes del paciente: el formulario promete paridad con maxilo y no existe - tabla y triggers listos desde terra_2, catalogo con 0 filas y cero codigo en la app
El formulario PROMETE los antecedentes y no los tiene. practica-form.tsx:507-509 renderiza el texto "Antecedentes del paciente: igual al formulario de maxilo (se incorpora con el catalogo de antecedentes)" dentro del fieldset del paciente. Es una frase, no un control: grep -rni antecedent sobre src/ devuelve EXACTAMENTE esas dos lineas y nada mas. Cero campos, cero lectura, cero escritura. MISMA FORMA QUE TERRA-82 y por eso es app-lane, no db: el lado de datos ya esta completo. terra_2_antecedentes_correction_details.sql (2026-07-30) creo terraPracticasAntecedentes + vTerraPracticasAntecedentes, con FK antecedenteId -> antecedentesCatalog(id), FK practicaId -> terraPracticas(id), unique parcial uq_terraPracticasAntecedentes_live (practicaId, antecedenteId) WHERE deletedAt IS NULL, CHECK de detailText no-blanco, y los cinco triggers de archivo/no-hard-delete. La regla de negocio tambien esta escrita: db/schema.md:153 dice que un antecedente con antecedentesCatalog.requiresDetail = true exige detailText no vacio. PERO EL CATALOGO ESTA VACIO, y esto es lo que separa este ticket de TERRA-82. Medido en vivo 2026-08-23: SELECT count(*) FROM "antecedentesCatalog" WHERE "deletedAt" IS NULL devuelve 0, con 0 filas requiresDetail. Asi que no alcanza con construir la UI - sin contenido el fieldset se renderiza vacio, que para el usuario es el mismo defecto con otra cara. SON DOS BLOQUEOS DISTINTOS y conviene no confundirlos: la superficie es mia, el contenido no existe en ningun lado que esta lane pueda leer. DE DONDE SALE EL CONTENIDO: el pedido del cliente es paridad con maxilo, y maxilo = la app VENUS (Postgrado Cirugia Buco-Maxilofacial), resuelto por brainstorm bs-mrzoxn10qpj y registrado en pm/05-client-info.md:27-28. La lista de antecedentes, su orden y cuales llevan requiresDetail son propiedad de ese repo, que esta lane no lee. Hace falta que coder-venus-cc entregue el catalogo, o que Puia lo confirme. antecedentesCatalog ademas es una tabla COMPARTIDA de enamel: sembrarla es DDL/DML de otro dueno, no de terra. POR QUE IMPORTA AHORA: Puia entra a la app en horas y el cliente pidio explicitamente (CR-004) mismos antecedentes que maxilo con el mismo comportamiento al hacer clic. Hoy encuentra una promesa en gris. Una frase que anuncia una funcion ausente es peor que la ausencia: se lee como algo roto, no como algo pendiente. ACEPTACION: (1) catalogo sembrado con la lista de venus, con requiresDetail por fila y su procedencia registrada; (2) el fieldset renderiza los antecedentes como controles seleccionables con el mismo comportamiento de clic que maxilo; (3) los seleccionados se escriben en terraPracticasAntecedentes dentro de la MISMA transaccion que createPractica, despues de setArchiveContext, como ya hacen las otras tres tablas hijas; (4) requiresDetail validado SERVER-SIDE contra el catalogo releido, nunca contra lo que manda el cliente - mismo criterio que TERRA-91 usa con requierePieza/requiereRegion; (5) el detalle los muestra en /practicas/[id] resolviendo etiquetas historicas sin picker activo-solamente, la leccion de TERRA-105/107; (6) la frase de practica-form.tsx:507 se borra en el mismo commit - si queda, anuncia por segunda vez algo que ya esta en pantalla. MIENTRAS TANTO, y es una decision de producto que no tomo solo: si el catalogo tarda, la frase debe decir la verdad (que los antecedentes todavia no se registran en terra) o desaparecer. Lo que no puede seguir es prometiendo paridad con maxilo.
Activity
-
Media medida hecha y en vivo: v0.24.55 dpl_8Nw9TGghCvpVuYzugv7PEt15es9K. La frase que prometia paridad con maxilo se reemplazo por 'Los antecedentes del paciente todavia no se registran en esta aplicacion'. Eso es todo lo que esta lane puede entregar hoy: el fieldset sin catalogo renderiza una seccion vacia, que es el mismo defecto con otra cara. SIGUE BLOQUEADO en el contenido, no en la UI - antecedentesCatalog tiene 0 filas y es tabla COMPARTIDA de enamel, y la lista es propiedad de la app venus. Se necesita que coder-venus-cc entregue lista + orden + requiresDetail por fila, y despues db-enamel-cc para sembrarla.
-
Catalogo vacio: antecedentesCatalog = 0 filas. La lista, su orden y los flags requiresDetail son de la app venus (maxilo) y la tabla es compartida de enamel. Hacen falta coder-venus-cc (contenido) y db-enamel-cc (siembra) antes de que el fieldset tenga sentido. La superficie es app-lane y no esta bloqueada tecnicamente, pero construirla primero entrega una seccion vacia.
-
DECISION DE PRODUCTO PENDIENTE, para pm-terra-cc. terra_1_initial_schema.sql:41-42 escribe el flujo previsto: el formulario de terra PRE-CARGA desde pacienteAntecedentes, el clinico confirma o enmienda, y el submit escribe la atestacion Y empuja la enmienda de vuelta a pacienteAntecedentes. Mi plan v1 deja fuera esa mitad y audit-terra-ca bloqueo el encuadre con razon: descartar un contrato escrito es una decision de producto que se registra, no una simplificacion que se hace en silencio.\n\nDATO PARA DECIDIR, medido hoy: pacienteAntecedentes tiene 0 filas y hay 1 paciente. La PRE-CARGA es entonces un no-op el dia uno y no cambia nada para nadie. La mitad que si importa es la ESCRITURA DE VUELTA: es lo unico que puede hacer que la lista compartida del paciente deje de estar vacia, y cada practica que se registre sin ella es un dato clinico que existio y no quedo en el estado del paciente.\n\nNO EJECUTO NI DESCARTO hasta que pm-terra-cc lo decida. Si la respuesta es v1 sin write-back, hay que actualizar el contrato en terra_1/schema.md en el mismo commit - un contrato que sigue diciendo lo contrario de lo que hace el codigo es peor que no tenerlo.
-
BORRADOR DE SIEMBRA EN REVISION DE DB, no aplicado. /resource/terra/db-review/2026-08-23-enamel-seed-antecedentes-catalog-DRAFT.sql md5 5de269438c1ff1f5a3cc12d73336563b. Tambien en db/migrations/draft/enamel_XXX_seed_antecedentes_catalog.sql.\n\n33 filas de venus/db/seed-antecedentesCatalog.sql (prod venus 2026-05-19, isConfirmedByClient en las 33). pluto corrobora con 12 planas, no agrega ninguna. mars NO tiene catalogo: antecedentesDelPaciente es text libre - verificado antes de citarlo como fuente.\n\nFORMA: 33 filas INDEPENDIENTES, planas, con etiquetas auto-descriptivas del tipo 'Diabetes - Tipo 2'. El primer plan era 16 raices con el hijo en detailText via requiresDetail y audit-terra-ca lo BLOQUEO con razon (mt5qplgof6b8): eso pierde CUAL hijo se eligio. requiresDetail queda false en las 33. grupo='general' en las 33 mas una fila nueva en lookupOptions/antecedenteGrupo, decision de presentacion y no clinica, porque los 5 grupos de enamel_002 no clasifican limpio a Tabaquismo, Embarazo ni HIV/Hepatitis.\n\nSIN RESOLVER a proposito: venus escribe 'antiresorivos' (falta la t), pluto 'antiresortiva', la correcta es 'antirresortivos'. El archivo copia venus literal y marca la decision. El label se cambia barato despues, el value no.\n\nVERIFICADO EN VIVO antes de escribir el archivo: existe ux_antecedentesCatalog_value_live UNIQUE (value) WHERE deletedAt IS NULL, asi que el ON CONFLICT nombra ese predicado parcial; grupo no tiene FK, solo CHECK de no-vacio. NO ejecutado ni en dry-run: esta lane es SELECT-only. Enviado a db-enamel-cc (mt5qu5m27m1h) para revision, no para aplicacion.\n\nSIGUE BLOQUEADO en dos cosas distintas: GO de db-enamel-cc sobre la siembra, y la decision PM sobre el write-back a pacienteAntecedentes. Nada de app se escribe hasta las dos.
-
GO de db-enamel-cc (mt5qv9ay6ywc). Verificaron en vivo columnas, los dos unique index parciales, constraints, defaults y 0 filas en las 3 tablas, y coincide con lo que declara el archivo. Aceptaron la forma: 33 filas planas, grupo='general', requiresDetail=false, guarda + ON CONFLICT muerto a proposito.\n\nORTOGRAFIA RESUELTA por ellos: label corregido a 'Medicacion antirresortivos', value dejado como 'medicacionAntiresorivos...' sin tocar. El value es un identificador opaco al que van a apuntar filas de terraPracticasAntecedentes, asi que corregirlo despues es caro y corregirlo ahora no compra nada; el label es lo unico que ve un clinico. COSTO ACEPTADO Y ESCRITO EN EL ARCHIVO: value y label no coinciden en 4 filas, y quien lea el value y deduzca de ahi la ortografia del label se equivoca.\n\nArchivo actualizado, md5 NUEVO bc7739bdcf67b3ef52c7ac60711d8fe8 (antes 5de269438c1ff1f5a3cc12d73336563b). Recontado despues de editar: 33 filas, 17 con separador de hijo, 0 apariciones de la errata en labels.\n\nLA APLICACION ES DE db-enamel-cc: tabla compartida, esta lane es SELECT-only. Nada aplicado todavia.\n\nSIGUE ABIERTA, y es independiente del GO: la decision PM sobre el write-back a pacienteAntecedentes (terra_1:41-42). La app no se escribe hasta que se aplique la siembra Y se decida eso.
-
APP SHIPPED, v0.24.56 dpl_FiJmzGJNeSRDVSQFLRpyJzg5LJiK. La seccion Antecedentes del paciente existe: 33 opciones desde antecedentesCatalog, escritura en terraPracticasAntecedentes dentro de la misma transaccion de createPractica despues de setArchiveContext, y lectura en /practicas/[id] con el catalogo joineado SIN FILTRAR (ni isActive ni deletedAt) porque la fila afirma lo que se atestiguo ese dia - regla de historicalLabel, defecto de TERRA-105.\n\nEl input de detalle se construyo aunque hoy no lo ve nadie: las 33 filas tienen requiresDetail=false, pero fn_terraAntecedenteRequireDetail RAISE si falta el detalle, asi que un formulario sin manera de darlo empezaria a FALLAR AL GUARDAR el dia que la catedra encienda un flag. Es la forma de TERRA-107. El writer NO pre-chequea requiresDetail en Node: el trigger relee el catalogo en la misma transaccion y una segunda copia de esa regla es lo que terra_2 rechazo explicitamente. Detalle vacio va como NULL y no como '', porque el CHECK rechaza el string en blanco.\n\nLa seccion del detalle se renderiza SOLO si hay algo atestiguado: un 'Antecedentes: -' permanente se lee como una afirmacion sobre el PACIENTE (ninguno) cuando es una afirmacion sobre el FORMULARIO (no se registro nada), y 'Sin antecedentes' es una fila real del catalogo justamente para que la primera se pueda decir a proposito.\n\n270/270 unit, tsc limpio.\n\nSIGUE ABIERTO y es lo unico que queda de esta WI: la decision PM sobre el write-back a pacienteAntecedentes (terra_1:41-42). NO PROBADO CONTRA UNA PRACTICA REAL - no hay sesion autenticada en esta lane y no se registro ninguna practica con antecedentes; lo verificado es tipos, unit y el estado del catalogo en vivo.
-
cleared: Catalogo vacio: antecedentesCatalog = 0 filas. La lista, su orden y los flags requiresDetail son de la app venus (maxilo) y la tabla es compartida de enamel. Hacen falta coder-venus-cc (contenido) y db-enamel-cc (siembra) antes de que el fieldset tenga sentido. La superficie es app-lane y no esta bloqueada tecnicamente, pero construirla primero entrega una seccion vacia.
-
La mitad de pre-carga + escritura de vuelta a pacienteAntecedentes se separo a TERRA-113. Esta WI queda solo con la atestacion por practica, que es lo que su titulo nombra.
-
CERRADA. Lo que nombra el titulo esta entregado y en vivo desde v0.24.56 (a879594): 33 opciones desde antecedentesCatalog, escritura en terraPracticasAntecedentes dentro de la misma transaccion de createPractica, lectura en /practicas/[id] con el catalogo joineado SIN FILTRAR. TERRA-117 agrego despues los dos niveles (enamel_036, parentId) y el arbol en el formulario.\n\nLO QUE QUEDABA ABIERTO NO ERA DE ESTA WI: la pre-carga desde pacienteAntecedentes y la escritura de vuelta se separaron a TERRA-113 el 2026-08-23, y esta WI quedo explicitamente solo con la atestacion por practica. Se cierra contra su propio alcance, no contra el de TERRA-113.\n\nSIN PROBAR PUNTA A PUNTA y dicho en vez de implicado: esta lane no tiene sesion autenticada, asi que no se registro ninguna practica real con antecedentes. Lo verificado es tipos, unit y el estado del catalogo en vivo.