Envío al registro

El envío es un proceso separado de la aprobación. No se dispara al aprobar y permanece deshabilitado salvo configuración explícita.

Condiciones antes de encolar

POST /api/biobadamex/drafts/:id/submit exige sesión, acceso de investigación, propiedad, estado approved, faltantes resueltos, BIOBADAMEX_REGISTRY_SUBMIT_ENABLED=1, confirmación de comorbilidades cuando aplica y payload válido con versión del mapa.

Un administrador puede leer borradores de otro médico con auditoría, pero no enviarlos. Un borrador sin propietario tampoco es enviable.

Trabajo en cola

La API crea un trabajo con id del borrador, registro aprobado y versión del mapa. La cola usa lote de uno por trabajador, pero no configura reintentos específicos. Varias instancias necesitan coordinación adicional para garantizar una sola sesión externa global.

Sandbox

Por cada trabajo, el servicio valida configuración, carga el bundle, crea una microVM Tenki, inyecta payload y credenciales mediante variables de proceso, ejecuta Playwright, analiza el resultado JSON y destruye la microVM al salir.

Recorrido externo

Login.
Llenar y guardar crdA.
Leer el idpac asignado.
Visitar y guardar crdB, crdC, crdD y crdE.
Abrir resumen.
Exigir el texto del mismo idpac.

idpac y resumen son fatales. Muchos campos individuales son best-effort: un control ausente o una opción no reconocida se registra y se omite. succeeded confirma paciente y resumen, no paridad campo por campo.

Mapa externo

El mapa está versionado. Cambiar selectores exige subir REGISTRY_MAP_VERSION y revalidar. Existen huecos conocidos: controles no modelados, radios no confirmados con valores distintos, ambigüedad BASDAI, marcas biológicas pendientes y campos de detalle/fecha no cubiertos.

No se debe describir como cobertura total del formulario.

Tratamientos biológicos

crdE acepta episodios con rol. Solo previous entra al bloque previo. El trabajador rechaza rol desconocido con fármaco, conflicto marca-sustancia, episodios duplicados que sobreescribirían fechas y fármacos sin mapeo confirmado.

Resultado y errores

Éxito: persiste idpac, submittedAt, estado submitted y auditoría.
Rechazo del formulario: persiste submitError, audita y no repite el mismo envío.
Fallo de infraestructura: lanza error; la cola actual no tiene política específica de reintento.
La lectura posterior verifica resumen, no cada campo.
Hay contratos de lectura acotada, pero no están montados en el flujo de submit de este commit.

Riesgos de idempotencia y estado

El endpoint descarta el id del trabajo y no usa singleton por borrador. Dos solicitudes antes del primer resultado pueden encolar dos mutaciones.
Si crdA asigna idpac y falla una página posterior, el resultado fallido puede contenerlo en memoria, pero la persistencia guarda solo submitError. Un reintento puede volver a crear identidad.
summaryUrl no se persiste.
Un fallo de infraestructura antes de un resultado estructurado deja el borrador approved sin submitError; la UI no tiene un estado durable queued/running.