La integracion SYS-02 - COMAR debe tratarse como contrato operativo entre sistemas. Este articulo describe el estado actual, la forma esperada de integracion, las dependencias necesarias y las tareas que deben cerrar evidencia antes de avanzar a certificacion o produccion.
Introduccion
Esta integracion debe entenderse como un contrato operativo entre sistemas. Su implementacion debe avanzar por etapas: definicion funcional, contrato tecnico, mock, adaptador, prueba de permisos, conexion real, certificacion, despliegue y monitoreo.
Detalle
- Sistema: SYS-02 - COMAR
- Owner funcional: COMAR - enlace funcional por confirmar | Owner tecnico: COMAR/DTI - enlace tecnico por confirmar
- Autenticacion: OAuth2/JWT, certificado o mecanismo COMAR por confirmar
- VPN: Si | Allowlist: Si | Certificados: No
- Estado: mock Mock COMAR requerido y trazable, adaptador Adaptador COMAR pendiente de contrato oficial, conexion real Pendiente de VPN/allowlist/credenciales COMAR, certificacion Certificacion COMAR pendiente, produccion Produccion condicionada a autorizacion COMAR.
Como se espera integrar
Integracion REST/JSON para solicitudes, estatus, resoluciones y medidas especiales, con mapeo semantico, minimizacion de datos personales y conciliacion con expediente unico.
Dependencias necesarias
No hay dependencia especifica enlazada por texto. Antes de avanzar debe confirmarse documentacion, credenciales, datos de prueba, ambiente, responsable tecnico y evidencia de seguridad.
Tareas vinculadas
RMH-027 - Solicitar documentación técnica de COMAR
Responsable: Integraciones | Disciplina: Integraciones | Sistema/componente: COMAR | Fechas: 2026-07-03 a 2026-07-15.
Descripcion detallada
RMH-027 - Solicitar documentación técnica de COMAR
Propósito
obtener documentacion, contratos, credenciales controladas, ambientes y responsables necesarios para integrar interoperabilidad con COMAR.
Alcance de ejecución
la solicitud debe distinguir informacion tecnica, datos de prueba, ventanas de prueba, seguridad, certificacion y vigencia. La tarea se ejecuta del 2026-07-03 al 2026-07-15, dentro de H02 - Levantamiento funcional y normativo, y contribuye a RMH-E2 - Analisis, arquitectura y diseno funcional/API First.
Resultado verificable
Para RMH-027 - Solicitar documentación técnica de COMAR, la evidencia debe incluir solicitud y acuse de documentacion tecnica, contratos, credenciales, ambientes, datos de prueba y responsables.
Criterio de aceptación
RMH-027 - Solicitar documentación técnica de COMAR se acepta cuando el resultado contiene solicitud y acuse de documentacion tecnica, contratos, credenciales, ambientes, datos de prueba y responsables y con acuse, fecha compromiso o condicion formal registrada como dependencia.
Dependencias y coordinación
- DEP-DTI-004: Documentación de autenticación - condicion operacional para DTI. [estado: No solicitada; requerida 2026-08-24]
- DEP-INM-002: Documentación de servicios - condicion operacional para INM. [estado: No solicitada; requerida 2026-07-22]
Responsabilidad
Integraciones. La persona responsable coordina la ejecución, reúne evidencia y obtiene la validación indicada; no transfiere el cierre a participantes consultados.
Límites y supuestos
Una prueba contra mock valida el contrato acordado, pero no sustituye conectividad, credenciales, certificación ni autorización productiva de la contraparte. Existe contrato versionado o mock validado, datos de prueba y un responsable técnico capaz de resolver diferencias de integración.
Riesgos y control
Cambios de contrato, catálogos o autenticación pueden romper compatibilidad y desplazar pruebas o certificaciones posteriores. Además, el cierre depende del seguimiento oportuno de DEP-DTI-004, DEP-INM-002. Registrar versión de contrato, solicitud, respuesta, errores y correlación sin exponer credenciales ni datos personales.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git. Se considera atendida cuando se recibe y valida: URLs de repositorios, grupos/permisos, ramas protegidas, politica de pull request, responsables tecnicos y evidencia de acceso. Impacto si no está disponible: Sin repositorios y reglas Git no se puede cerrar implementacion, revisiones tecnicas, trazabilidad de cambios ni evidencia de versionado., DEP-DTI-002 - Arquitectura institucional. Se considera atendida cuando se recibe y valida: Lineamientos institucionales de arquitectura, red, seguridad, despliegue, dominios, certificados, observabilidad y restricciones de plataforma. Impacto si no está disponible: Puede obligar a redisenar contenedores, despliegues, seguridad, integraciones y criterios de operacion., DEP-DTI-003 - Infraestructura de desarrollo. Se considera atendida cuando se recibe y valida: Ambientes de desarrollo, accesos, variables no secretas, conectividad, base de datos, almacenamiento documental y responsables de soporte. Impacto si no está disponible: Bloquea ejecucion reproducible, pruebas iniciales, health checks y evidencia de ambiente., DEP-DTI-004 - Documentación de autenticación. Se considera atendida cuando se recibe y valida: Especificacion de autenticacion institucional: OAuth2/JWT/MFA/RBAC, claims, expiracion, roles, endpoints, ambientes y datos de prueba. Impacto si no está disponible: Condiciona Acceso Unico, proteccion de rutas, RBAC, auditoria, capacitacion backend y pruebas de seguridad., DEP-DTI-005 - Ambiente QA. Se considera atendida cuando se recibe y valida: Ambiente QA, URLs, despliegue, base de datos, usuarios de prueba, datos sinteticos, logs y procedimiento de reinicio. Impacto si no está disponible: Sin QA no se pueden cerrar pruebas integrales, certificacion interna, pentesting previo ni evidencia de aceptacion., DEP-DTI-006 - Certificados y DNS QA. Se considera atendida cuando se recibe y valida: Ambiente QA, URLs, despliegue, base de datos, usuarios de prueba, datos sinteticos, logs y procedimiento de reinicio. Impacto si no está disponible: Sin QA no se pueden cerrar pruebas integrales, certificacion interna, pentesting previo ni evidencia de aceptacion., DEP-DTI-007 - Acceso a datos historicos. Se considera atendida cuando se recibe y valida: Inventario de fuentes historicas autorizadas, diccionario de campos, volumen estimado, formato de extraccion, reglas de anonimizado, ventana de acceso, responsable de validacion y criterio de conciliacion. Impacto si no está disponible: Sin esta informacion no se puede perfilar calidad, disenar ETL, estimar tiempos de migracion, ejecutar migracion preliminar ni cerrar conciliacion de datos historicos para H12, H15 y H20., DEP-DTI-008 - Infraestructura productiva. Se considera atendida cuando se recibe y valida: Ambiente productivo aprobado, recursos, dominios, certificados, almacenamiento, monitoreo, respaldos, usuarios operativos, ventanas de despliegue, procedimiento de rollback y responsable de soporte. Impacto si no está disponible: Condiciona Go/No-Go, despliegue productivo, pruebas de humo, monitoreo, respaldo, estabilizacion y cierre contractual; sin ambiente aprobado no debe declararse operacion productiva.
Integraciones relacionadas: SYS-02 - COMAR
Entregables para cerrar la tarea
- Solicitud técnica de COMAR incluye contratos, endpoints, autenticación y ambientes.
- Catálogos, datos de prueba, límites, SLA y manejo de errores solicitados.
- Responsable funcional, responsable técnico y fecha compromiso confirmados o escalados.
- Acuse, documentación recibida y brechas pendientes registrados.
RMH-084 - Construir mock COMAR
Responsable: Backend 2 | Disciplina: Integraciones | Sistema/componente: COMAR | Fechas: 2026-09-25 a 2026-10-01.
Descripcion detallada
RMH-084 - Construir mock COMAR
Propósito
construir mock contractual para interoperabilidad con COMAR, permitiendo probar flujos sin depender de disponibilidad institucional real.
Alcance de ejecución
el mock debe exponer payloads representativos, errores, latencia controlada, versionado y datos de prueba documentados. La tarea se ejecuta del 2026-09-25 al 2026-10-01, dentro de H08 - Traslados e interoperabilidad base, y contribuye a RMH-E3 - Construccion base del Registro de Movilidad Humana e interoperabilidad mock.
Resultado verificable
Para RMH-084 - Construir mock COMAR, la evidencia debe incluir contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion.
Criterio de aceptación
RMH-084 - Construir mock COMAR se acepta cuando el resultado contiene integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia y cuando el adaptador consume el mock y reproduce casos exitosos y fallidos.
Dependencias y coordinación
- DEP-RDVF-005: Mock validado - condicion operacional para RDVF. [estado: No solicitada; requerida 2026-08-31]
- DEP-RMP-005: Mock validado - condicion operacional para RMP. [estado: No solicitada; requerida 2026-08-31]
- DEP-RNCAS-005: Mock validado - condicion operacional para RNCAS. [estado: No solicitada; requerida 2026-08-31]
Responsabilidad
Backend 2; colaboración: Integraciones. La persona responsable coordina la ejecución, reúne evidencia y obtiene la validación indicada; no transfiere el cierre a participantes consultados.
Límites y supuestos
Una prueba contra mock valida el contrato acordado, pero no sustituye conectividad, credenciales, certificación ni autorización productiva de la contraparte. Existe contrato versionado o mock validado, datos de prueba y un responsable técnico capaz de resolver diferencias de integración.
Riesgos y control
Cambios de contrato, catálogos o autenticación pueden romper compatibilidad y desplazar pruebas o certificaciones posteriores. Además, el cierre depende del seguimiento oportuno de DEP-RDVF-005, DEP-RMP-005, DEP-RNCAS-005. Registrar versión de contrato, solicitud, respuesta, errores y correlación sin exponer credenciales ni datos personales.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git. Se considera atendida cuando se recibe y valida: URLs de repositorios, grupos/permisos, ramas protegidas, politica de pull request, responsables tecnicos y evidencia de acceso. Impacto si no está disponible: Sin repositorios y reglas Git no se puede cerrar implementacion, revisiones tecnicas, trazabilidad de cambios ni evidencia de versionado., DEP-DTI-002 - Arquitectura institucional. Se considera atendida cuando se recibe y valida: Lineamientos institucionales de arquitectura, red, seguridad, despliegue, dominios, certificados, observabilidad y restricciones de plataforma. Impacto si no está disponible: Puede obligar a redisenar contenedores, despliegues, seguridad, integraciones y criterios de operacion., DEP-DTI-003 - Infraestructura de desarrollo. Se considera atendida cuando se recibe y valida: Ambientes de desarrollo, accesos, variables no secretas, conectividad, base de datos, almacenamiento documental y responsables de soporte. Impacto si no está disponible: Bloquea ejecucion reproducible, pruebas iniciales, health checks y evidencia de ambiente., DEP-DTI-004 - Documentación de autenticación. Se considera atendida cuando se recibe y valida: Especificacion de autenticacion institucional: OAuth2/JWT/MFA/RBAC, claims, expiracion, roles, endpoints, ambientes y datos de prueba. Impacto si no está disponible: Condiciona Acceso Unico, proteccion de rutas, RBAC, auditoria, capacitacion backend y pruebas de seguridad., DEP-DTI-005 - Ambiente QA. Se considera atendida cuando se recibe y valida: Ambiente QA, URLs, despliegue, base de datos, usuarios de prueba, datos sinteticos, logs y procedimiento de reinicio. Impacto si no está disponible: Sin QA no se pueden cerrar pruebas integrales, certificacion interna, pentesting previo ni evidencia de aceptacion., DEP-DTI-006 - Certificados y DNS QA. Se considera atendida cuando se recibe y valida: Ambiente QA, URLs, despliegue, base de datos, usuarios de prueba, datos sinteticos, logs y procedimiento de reinicio. Impacto si no está disponible: Sin QA no se pueden cerrar pruebas integrales, certificacion interna, pentesting previo ni evidencia de aceptacion., DEP-DTI-007 - Acceso a datos historicos. Se considera atendida cuando se recibe y valida: Inventario de fuentes historicas autorizadas, diccionario de campos, volumen estimado, formato de extraccion, reglas de anonimizado, ventana de acceso, responsable de validacion y criterio de conciliacion. Impacto si no está disponible: Sin esta informacion no se puede perfilar calidad, disenar ETL, estimar tiempos de migracion, ejecutar migracion preliminar ni cerrar conciliacion de datos historicos para H12, H15 y H20., DEP-DTI-008 - Infraestructura productiva. Se considera atendida cuando se recibe y valida: Ambiente productivo aprobado, recursos, dominios, certificados, almacenamiento, monitoreo, respaldos, usuarios operativos, ventanas de despliegue, procedimiento de rollback y responsable de soporte. Impacto si no está disponible: Condiciona Go/No-Go, despliegue productivo, pruebas de humo, monitoreo, respaldo, estabilizacion y cierre contractual; sin ambiente aprobado no debe declararse operacion productiva.
Integraciones relacionadas: SYS-02 - COMAR
Entregables para cerrar la tarea
- Contrato y escenarios del mock de COMAR versionados.
- Respuestas exitosas, no encontradas y errores controlados implementadas.
- Latencia, timeout y datos sintéticos configurables.
- Pruebas automáticas del mock ejecutadas con evidencia.
- Limitación explícita: el mock no acredita conexión ni certificación real.
RMH-131 - Probar adaptador INM
Responsable: Integraciones | Disciplina: Integraciones | Sistema/componente: INM | Fechas: 2026-12-03 a 2026-12-10.
Descripcion detallada
RMH-131 - Probar adaptador INM
Propósito
habilitar interoperabilidad externa con INM, cuidando red, autenticacion, contrato, errores, evidencias y condicion institucional.
Alcance de ejecución
debe probar conectividad, payload, autenticacion, timeout, reintento, catalogos, datos de prueba y bitacora de solicitud/respuesta. La tarea se ejecuta del 2026-12-03 al 2026-12-10, dentro de H13 - Integracion real INM y COMAR, y contribuye a RMH-E4 - Integracion, QA, seguridad y migracion preliminar.
Resultado verificable
Para RMH-131 - Probar adaptador INM, la evidencia debe incluir contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion.
Criterio de aceptación
RMH-131 - Probar adaptador INM se acepta cuando el resultado contiene integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia y cuando el adaptador demuestra caso exitoso, error controlado y estado formal de certificacion o bloqueo.
Dependencias y coordinación
No tiene una dependencia directa registrada. El responsable debe confirmar que los insumos propios de la tarea están disponibles antes de iniciar.
Responsabilidad
Integraciones; colaboración: QA. La persona responsable coordina la ejecución, reúne evidencia y obtiene la validación indicada; no transfiere el cierre a participantes consultados.
Límites y supuestos
Una prueba contra mock valida el contrato acordado, pero no sustituye conectividad, credenciales, certificación ni autorización productiva de la contraparte. Existe contrato versionado o mock validado, datos de prueba y un responsable técnico capaz de resolver diferencias de integración.
Riesgos y control
Cambios de contrato, catálogos o autenticación pueden romper compatibilidad y desplazar pruebas o certificaciones posteriores. Registrar versión de contrato, solicitud, respuesta, errores y correlación sin exponer credenciales ni datos personales.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git. Se considera atendida cuando se recibe y valida: URLs de repositorios, grupos/permisos, ramas protegidas, politica de pull request, responsables tecnicos y evidencia de acceso. Impacto si no está disponible: Sin repositorios y reglas Git no se puede cerrar implementacion, revisiones tecnicas, trazabilidad de cambios ni evidencia de versionado., DEP-DTI-002 - Arquitectura institucional. Se considera atendida cuando se recibe y valida: Lineamientos institucionales de arquitectura, red, seguridad, despliegue, dominios, certificados, observabilidad y restricciones de plataforma. Impacto si no está disponible: Puede obligar a redisenar contenedores, despliegues, seguridad, integraciones y criterios de operacion., DEP-DTI-003 - Infraestructura de desarrollo. Se considera atendida cuando se recibe y valida: Ambientes de desarrollo, accesos, variables no secretas, conectividad, base de datos, almacenamiento documental y responsables de soporte. Impacto si no está disponible: Bloquea ejecucion reproducible, pruebas iniciales, health checks y evidencia de ambiente., DEP-DTI-004 - Documentación de autenticación. Se considera atendida cuando se recibe y valida: Especificacion de autenticacion institucional: OAuth2/JWT/MFA/RBAC, claims, expiracion, roles, endpoints, ambientes y datos de prueba. Impacto si no está disponible: Condiciona Acceso Unico, proteccion de rutas, RBAC, auditoria, capacitacion backend y pruebas de seguridad., DEP-DTI-005 - Ambiente QA. Se considera atendida cuando se recibe y valida: Ambiente QA, URLs, despliegue, base de datos, usuarios de prueba, datos sinteticos, logs y procedimiento de reinicio. Impacto si no está disponible: Sin QA no se pueden cerrar pruebas integrales, certificacion interna, pentesting previo ni evidencia de aceptacion., DEP-DTI-006 - Certificados y DNS QA. Se considera atendida cuando se recibe y valida: Ambiente QA, URLs, despliegue, base de datos, usuarios de prueba, datos sinteticos, logs y procedimiento de reinicio. Impacto si no está disponible: Sin QA no se pueden cerrar pruebas integrales, certificacion interna, pentesting previo ni evidencia de aceptacion., DEP-DTI-007 - Acceso a datos historicos. Se considera atendida cuando se recibe y valida: Inventario de fuentes historicas autorizadas, diccionario de campos, volumen estimado, formato de extraccion, reglas de anonimizado, ventana de acceso, responsable de validacion y criterio de conciliacion. Impacto si no está disponible: Sin esta informacion no se puede perfilar calidad, disenar ETL, estimar tiempos de migracion, ejecutar migracion preliminar ni cerrar conciliacion de datos historicos para H12, H15 y H20., DEP-DTI-008 - Infraestructura productiva. Se considera atendida cuando se recibe y valida: Ambiente productivo aprobado, recursos, dominios, certificados, almacenamiento, monitoreo, respaldos, usuarios operativos, ventanas de despliegue, procedimiento de rollback y responsable de soporte. Impacto si no está disponible: Condiciona Go/No-Go, despliegue productivo, pruebas de humo, monitoreo, respaldo, estabilizacion y cierre contractual; sin ambiente aprobado no debe declararse operacion productiva.
Integraciones relacionadas: SYS-02 - COMAR
Entregables para cerrar la tarea
- Versión del adaptador y contrato de INM identificados.
- Mapeo de campos y catálogos obligatorios validado.
- Casos exitoso, no encontrado, error, timeout y reintento ejecutados.
- Autenticación, auditoría, correlation ID e idempotencia verificadas.
- Defectos y evidencia de solicitudes/respuestas sanitizadas documentados.
- Resultado técnico aprobado, condicionado o rechazado registrado.
RMH-132 - Configurar conectividad COMAR
Responsable: DevOps | Disciplina: Integraciones | Sistema/componente: COMAR | Fechas: 2026-12-02 a 2026-12-07.
Descripcion detallada
RMH-132 - Configurar conectividad COMAR
Propósito
habilitar interoperabilidad externa con COMAR, cuidando red, autenticacion, contrato, errores, evidencias y condicion institucional.
Alcance de ejecución
debe probar conectividad, payload, autenticacion, timeout, reintento, catalogos, datos de prueba y bitacora de solicitud/respuesta. La tarea se ejecuta del 2026-12-02 al 2026-12-07, dentro de H13 - Integracion real INM y COMAR, y contribuye a RMH-E4 - Integracion, QA, seguridad y migracion preliminar.
Resultado verificable
Para RMH-132 - Configurar conectividad COMAR, la evidencia debe incluir contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion.
Criterio de aceptación
RMH-132 - Configurar conectividad COMAR se acepta cuando el resultado contiene integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia y cuando el adaptador demuestra caso exitoso, error controlado y estado formal de certificacion o bloqueo.
Dependencias y coordinación
No tiene una dependencia directa registrada. El responsable debe confirmar que los insumos propios de la tarea están disponibles antes de iniciar.
Responsabilidad
DevOps; colaboración: Integraciones. La persona responsable coordina la ejecución, reúne evidencia y obtiene la validación indicada; no transfiere el cierre a participantes consultados.
Límites y supuestos
Una prueba contra mock valida el contrato acordado, pero no sustituye conectividad, credenciales, certificación ni autorización productiva de la contraparte. Existe contrato versionado o mock validado, datos de prueba y un responsable técnico capaz de resolver diferencias de integración.
Riesgos y control
Cambios de contrato, catálogos o autenticación pueden romper compatibilidad y desplazar pruebas o certificaciones posteriores. Registrar versión de contrato, solicitud, respuesta, errores y correlación sin exponer credenciales ni datos personales.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git. Se considera atendida cuando se recibe y valida: URLs de repositorios, grupos/permisos, ramas protegidas, politica de pull request, responsables tecnicos y evidencia de acceso. Impacto si no está disponible: Sin repositorios y reglas Git no se puede cerrar implementacion, revisiones tecnicas, trazabilidad de cambios ni evidencia de versionado., DEP-DTI-002 - Arquitectura institucional. Se considera atendida cuando se recibe y valida: Lineamientos institucionales de arquitectura, red, seguridad, despliegue, dominios, certificados, observabilidad y restricciones de plataforma. Impacto si no está disponible: Puede obligar a redisenar contenedores, despliegues, seguridad, integraciones y criterios de operacion., DEP-DTI-003 - Infraestructura de desarrollo. Se considera atendida cuando se recibe y valida: Ambientes de desarrollo, accesos, variables no secretas, conectividad, base de datos, almacenamiento documental y responsables de soporte. Impacto si no está disponible: Bloquea ejecucion reproducible, pruebas iniciales, health checks y evidencia de ambiente., DEP-DTI-004 - Documentación de autenticación. Se considera atendida cuando se recibe y valida: Especificacion de autenticacion institucional: OAuth2/JWT/MFA/RBAC, claims, expiracion, roles, endpoints, ambientes y datos de prueba. Impacto si no está disponible: Condiciona Acceso Unico, proteccion de rutas, RBAC, auditoria, capacitacion backend y pruebas de seguridad., DEP-DTI-005 - Ambiente QA. Se considera atendida cuando se recibe y valida: Ambiente QA, URLs, despliegue, base de datos, usuarios de prueba, datos sinteticos, logs y procedimiento de reinicio. Impacto si no está disponible: Sin QA no se pueden cerrar pruebas integrales, certificacion interna, pentesting previo ni evidencia de aceptacion., DEP-DTI-006 - Certificados y DNS QA. Se considera atendida cuando se recibe y valida: Ambiente QA, URLs, despliegue, base de datos, usuarios de prueba, datos sinteticos, logs y procedimiento de reinicio. Impacto si no está disponible: Sin QA no se pueden cerrar pruebas integrales, certificacion interna, pentesting previo ni evidencia de aceptacion., DEP-DTI-007 - Acceso a datos historicos. Se considera atendida cuando se recibe y valida: Inventario de fuentes historicas autorizadas, diccionario de campos, volumen estimado, formato de extraccion, reglas de anonimizado, ventana de acceso, responsable de validacion y criterio de conciliacion. Impacto si no está disponible: Sin esta informacion no se puede perfilar calidad, disenar ETL, estimar tiempos de migracion, ejecutar migracion preliminar ni cerrar conciliacion de datos historicos para H12, H15 y H20., DEP-DTI-008 - Infraestructura productiva. Se considera atendida cuando se recibe y valida: Ambiente productivo aprobado, recursos, dominios, certificados, almacenamiento, monitoreo, respaldos, usuarios operativos, ventanas de despliegue, procedimiento de rollback y responsable de soporte. Impacto si no está disponible: Condiciona Go/No-Go, despliegue productivo, pruebas de humo, monitoreo, respaldo, estabilizacion y cierre contractual; sin ambiente aprobado no debe declararse operacion productiva.
Integraciones relacionadas: SYS-02 - COMAR
Entregables para cerrar la tarea
- Requisitos de red para COMAR: URL, puertos, VPN, allowlist y certificados confirmados.
- Credenciales gestionadas fuera del código y del sistema de gestión.
- Resolución DNS, TLS y conexión al ambiente autorizado comprobadas.
- Evidencia de conectividad sin datos sensibles adjunta.
- Incidencias y responsables externos registrados con fecha compromiso.
RMH-133 - Probar adaptador COMAR
Responsable: Integraciones | Disciplina: Integraciones | Sistema/componente: COMAR | Fechas: 2026-12-03 a 2026-12-10.
Descripcion detallada
RMH-133 - Probar adaptador COMAR
Propósito
habilitar interoperabilidad externa con COMAR, cuidando red, autenticacion, contrato, errores, evidencias y condicion institucional.
Alcance de ejecución
debe probar conectividad, payload, autenticacion, timeout, reintento, catalogos, datos de prueba y bitacora de solicitud/respuesta. La tarea se ejecuta del 2026-12-03 al 2026-12-10, dentro de H13 - Integracion real INM y COMAR, y contribuye a RMH-E4 - Integracion, QA, seguridad y migracion preliminar.
Resultado verificable
Para RMH-133 - Probar adaptador COMAR, la evidencia debe incluir contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion.
Criterio de aceptación
RMH-133 - Probar adaptador COMAR se acepta cuando el resultado contiene integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia y cuando el adaptador demuestra caso exitoso, error controlado y estado formal de certificacion o bloqueo.
Dependencias y coordinación
No tiene una dependencia directa registrada. El responsable debe confirmar que los insumos propios de la tarea están disponibles antes de iniciar.
Responsabilidad
Integraciones; colaboración: QA. La persona responsable coordina la ejecución, reúne evidencia y obtiene la validación indicada; no transfiere el cierre a participantes consultados.
Límites y supuestos
Una prueba contra mock valida el contrato acordado, pero no sustituye conectividad, credenciales, certificación ni autorización productiva de la contraparte. Existe contrato versionado o mock validado, datos de prueba y un responsable técnico capaz de resolver diferencias de integración.
Riesgos y control
Cambios de contrato, catálogos o autenticación pueden romper compatibilidad y desplazar pruebas o certificaciones posteriores. Registrar versión de contrato, solicitud, respuesta, errores y correlación sin exponer credenciales ni datos personales.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git. Se considera atendida cuando se recibe y valida: URLs de repositorios, grupos/permisos, ramas protegidas, politica de pull request, responsables tecnicos y evidencia de acceso. Impacto si no está disponible: Sin repositorios y reglas Git no se puede cerrar implementacion, revisiones tecnicas, trazabilidad de cambios ni evidencia de versionado., DEP-DTI-002 - Arquitectura institucional. Se considera atendida cuando se recibe y valida: Lineamientos institucionales de arquitectura, red, seguridad, despliegue, dominios, certificados, observabilidad y restricciones de plataforma. Impacto si no está disponible: Puede obligar a redisenar contenedores, despliegues, seguridad, integraciones y criterios de operacion., DEP-DTI-003 - Infraestructura de desarrollo. Se considera atendida cuando se recibe y valida: Ambientes de desarrollo, accesos, variables no secretas, conectividad, base de datos, almacenamiento documental y responsables de soporte. Impacto si no está disponible: Bloquea ejecucion reproducible, pruebas iniciales, health checks y evidencia de ambiente., DEP-DTI-004 - Documentación de autenticación. Se considera atendida cuando se recibe y valida: Especificacion de autenticacion institucional: OAuth2/JWT/MFA/RBAC, claims, expiracion, roles, endpoints, ambientes y datos de prueba. Impacto si no está disponible: Condiciona Acceso Unico, proteccion de rutas, RBAC, auditoria, capacitacion backend y pruebas de seguridad., DEP-DTI-005 - Ambiente QA. Se considera atendida cuando se recibe y valida: Ambiente QA, URLs, despliegue, base de datos, usuarios de prueba, datos sinteticos, logs y procedimiento de reinicio. Impacto si no está disponible: Sin QA no se pueden cerrar pruebas integrales, certificacion interna, pentesting previo ni evidencia de aceptacion., DEP-DTI-006 - Certificados y DNS QA. Se considera atendida cuando se recibe y valida: Ambiente QA, URLs, despliegue, base de datos, usuarios de prueba, datos sinteticos, logs y procedimiento de reinicio. Impacto si no está disponible: Sin QA no se pueden cerrar pruebas integrales, certificacion interna, pentesting previo ni evidencia de aceptacion., DEP-DTI-007 - Acceso a datos historicos. Se considera atendida cuando se recibe y valida: Inventario de fuentes historicas autorizadas, diccionario de campos, volumen estimado, formato de extraccion, reglas de anonimizado, ventana de acceso, responsable de validacion y criterio de conciliacion. Impacto si no está disponible: Sin esta informacion no se puede perfilar calidad, disenar ETL, estimar tiempos de migracion, ejecutar migracion preliminar ni cerrar conciliacion de datos historicos para H12, H15 y H20., DEP-DTI-008 - Infraestructura productiva. Se considera atendida cuando se recibe y valida: Ambiente productivo aprobado, recursos, dominios, certificados, almacenamiento, monitoreo, respaldos, usuarios operativos, ventanas de despliegue, procedimiento de rollback y responsable de soporte. Impacto si no está disponible: Condiciona Go/No-Go, despliegue productivo, pruebas de humo, monitoreo, respaldo, estabilizacion y cierre contractual; sin ambiente aprobado no debe declararse operacion productiva.
Integraciones relacionadas: SYS-02 - COMAR
Entregables para cerrar la tarea
- Versión del adaptador y contrato de COMAR identificados.
- Mapeo de campos y catálogos obligatorios validado.
- Casos exitoso, no encontrado, error, timeout y reintento ejecutados.
- Autenticación, auditoría, correlation ID e idempotencia verificadas.
- Defectos y evidencia de solicitudes/respuestas sanitizadas documentados.
- Resultado técnico aprobado, condicionado o rechazado registrado.
RMH-224 - Periodo de estabilización
Responsable: Soporte | Disciplina: Soporte | Sistema/componente: Operacion y soporte | Fechas: 2027-01-06 a 2027-01-19.
Descripcion detallada
RMH-224 - Periodo de estabilización
Propósito
vigilar comportamiento posterior a liberacion o entrega, atendiendo incidentes con tiempos, responsable y causa raiz.
Alcance de ejecución
la bitacora debe registrar incidentes, prioridad, respuesta, fix, retest y pendientes. La tarea se ejecuta del 2027-01-06 al 2027-01-19, dentro de H22 - Transferencia y estabilizacion, y contribuye a RMH-E5 - Remediacion, despliegue productivo, capacitacion y cierre.
Resultado verificable
Para RMH-224 - Periodo de estabilización, la evidencia debe incluir bitacora de estabilizacion con incidentes, seguimiento, tiempos de respuesta, fixes y pendientes.
Criterio de aceptación
RMH-224 - Periodo de estabilización se acepta cuando el resultado contiene bitacora de estabilizacion con incidentes, seguimiento, tiempos de respuesta, fixes y pendientes y cuando los incidentes quedan cerrados o aceptados con plan.
Dependencias y coordinación
No tiene una dependencia directa registrada. El responsable debe confirmar que los insumos propios de la tarea están disponibles antes de iniciar.
Responsabilidad
Soporte; colaboración: todo el equipo técnico. La persona responsable coordina la ejecución, reúne evidencia y obtiene la validación indicada; no transfiere el cierre a participantes consultados.
Límites y supuestos
La coordinación no se considera cerrada con una reunión o envío; deben quedar decisiones, responsables y fechas aplicables al trabajo posterior. Las áreas convocadas cuentan con autoridad o ruta de escalamiento para tomar las decisiones requeridas.
Riesgos y control
Acuerdos ambiguos o sin responsable pueden trasladar bloqueos a los hitos y entregables siguientes. Registrar decisiones, responsables, fecha compromiso y condición de escalamiento en una evidencia versionada.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git. Se considera atendida cuando se recibe y valida: URLs de repositorios, grupos/permisos, ramas protegidas, politica de pull request, responsables tecnicos y evidencia de acceso. Impacto si no está disponible: Sin repositorios y reglas Git no se puede cerrar implementacion, revisiones tecnicas, trazabilidad de cambios ni evidencia de versionado., DEP-DTI-002 - Arquitectura institucional. Se considera atendida cuando se recibe y valida: Lineamientos institucionales de arquitectura, red, seguridad, despliegue, dominios, certificados, observabilidad y restricciones de plataforma. Impacto si no está disponible: Puede obligar a redisenar contenedores, despliegues, seguridad, integraciones y criterios de operacion., DEP-DTI-003 - Infraestructura de desarrollo. Se considera atendida cuando se recibe y valida: Ambientes de desarrollo, accesos, variables no secretas, conectividad, base de datos, almacenamiento documental y responsables de soporte. Impacto si no está disponible: Bloquea ejecucion reproducible, pruebas iniciales, health checks y evidencia de ambiente., DEP-DTI-004 - Documentación de autenticación. Se considera atendida cuando se recibe y valida: Especificacion de autenticacion institucional: OAuth2/JWT/MFA/RBAC, claims, expiracion, roles, endpoints, ambientes y datos de prueba. Impacto si no está disponible: Condiciona Acceso Unico, proteccion de rutas, RBAC, auditoria, capacitacion backend y pruebas de seguridad., DEP-DTI-005 - Ambiente QA. Se considera atendida cuando se recibe y valida: Ambiente QA, URLs, despliegue, base de datos, usuarios de prueba, datos sinteticos, logs y procedimiento de reinicio. Impacto si no está disponible: Sin QA no se pueden cerrar pruebas integrales, certificacion interna, pentesting previo ni evidencia de aceptacion., DEP-DTI-006 - Certificados y DNS QA. Se considera atendida cuando se recibe y valida: Ambiente QA, URLs, despliegue, base de datos, usuarios de prueba, datos sinteticos, logs y procedimiento de reinicio. Impacto si no está disponible: Sin QA no se pueden cerrar pruebas integrales, certificacion interna, pentesting previo ni evidencia de aceptacion., DEP-DTI-007 - Acceso a datos historicos. Se considera atendida cuando se recibe y valida: Inventario de fuentes historicas autorizadas, diccionario de campos, volumen estimado, formato de extraccion, reglas de anonimizado, ventana de acceso, responsable de validacion y criterio de conciliacion. Impacto si no está disponible: Sin esta informacion no se puede perfilar calidad, disenar ETL, estimar tiempos de migracion, ejecutar migracion preliminar ni cerrar conciliacion de datos historicos para H12, H15 y H20., DEP-DTI-008 - Infraestructura productiva. Se considera atendida cuando se recibe y valida: Ambiente productivo aprobado, recursos, dominios, certificados, almacenamiento, monitoreo, respaldos, usuarios operativos, ventanas de despliegue, procedimiento de rollback y responsable de soporte. Impacto si no está disponible: Condiciona Go/No-Go, despliegue productivo, pruebas de humo, monitoreo, respaldo, estabilizacion y cierre contractual; sin ambiente aprobado no debe declararse operacion productiva.
Integraciones relacionadas: SYS-02 - COMAR
Entregables para cerrar la tarea
- Bitácora de incidentes y solicitudes post-liberación actualizada.
- Severidad, responsable y tiempo de respuesta registrados.
- Correcciones desplegadas y verificadas con evidencia.
- Métricas operativas y comportamiento de integraciones revisados.
- Pendientes aceptados con plan o periodo cerrado formalmente.