SYS-06 - Expediente Unico NNA

PYD-002 - Confirmación formal del alcance del RMH

Responsable: Analista funcional | Disciplina: Funcional/Backend | Sistema/componente: RMH - Registro de Movilidad Humana | Fechas: 2026-06-16 a 2026-06-18.

Descripcion detallada

PYD-002 - Confirmación formal del alcance del RMH

Objetivo PM: cerrar que cubre y que no cubre el Registro de Movilidad Humana: alta de caso, situacion migratoria, seguimiento, canalizaciones, entradas/salidas, repatriaciones e interoperabilidad INM/COMAR.

Alcance operativo: esta tarea pertenece a H01 - H01 - Arranque, gobierno y plan de trabajo, se vincula con PYD-E1 - Plan de trabajo, estrategia y gobierno del proyecto, impacta RMH - Registro de Movilidad Humana, queda a cargo de Analista funcional y esta planeada del 2026-06-16 al 2026-06-18. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: el alcance debe separar funciones obligatorias, integraciones condicionadas, datos afectados, reglas de negocio, reportes y criterios de aceptacion. Actividades principales del checklist: Revisar objetivo del componente Registro de Movilidad Humana y su relacion con Expediente Unico NNA e interoperabilidad; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Definir que procesos, datos, reportes e integraciones quedan incluidos en el alcance; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Documentar exclusiones, supuestos, restricciones institucionales y criterios para cambios futuros; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Identificar dependencias externas, responsables de aprobacion y riesgos que condicionan el cierre; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Aterrizar criterios de aceptacion verificables para analisis, construccion, pruebas y entrega; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-002 (Confirmación formal del alcance del RMH): documento de alcance, lista de incluidos/excluidos, supuestos, criterios de aceptacion y aprobacion funcional/tecnica. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-002 solo si "Confirmación formal del alcance del RMH" produce documento de alcance con incluidos, excluidos, supuestos, dependencias, criterios de aceptacion y responsables; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando RMH queda aprobado como alcance operativo y las excepciones quedan registradas como condicion o cambio futuro. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-003 - Infraestructura de desarrollo; DEP-INM-001 - Enlace técnico y funcional

Riesgos y controles: Alcance ambiguo que provoque retrabajo, expectativas no aprobadas o cierre condicionado del entregable. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo; DEP-INM-001 - Enlace técnico y funcional. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-002 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-003 - Infraestructura de desarrollo; DEP-INM-001 - Enlace técnico y funcional. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Analista funcional puede coordinar la revision de Registro de Movilidad Humana, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-002 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-002 (Confirmación formal del alcance del RMH): documento de alcance, lista de incluidos/excluidos, supuestos, criterios de aceptacion y aprobacion funcional/tecnica. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-002 solo si "Confirmación formal del alcance del RMH" produce documento de alcance con incluidos, excluidos, supuestos, dependencias, criterios de aceptacion y responsables; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando RMH queda aprobado como alcance operativo y las excepciones quedan registradas como condicion o cambio futuro. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Alcance ambiguo que provoque retrabajo, expectativas no aprobadas o cierre condicionado del entregable. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo; DEP-INM-001 - Enlace técnico y funcional. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-002 | Alcance | Revisar objetivo del componente Registro de Movilidad Humana y su relacion con Expediente Unico NNA e interoperabilidad; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-002 | Analisis | Definir que procesos, datos, reportes e integraciones quedan incluidos en el alcance; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-002 | Construccion | Documentar exclusiones, supuestos, restricciones institucionales y criterios para cambios futuros; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-002 | Evidencia | Identificar dependencias externas, responsables de aprobacion y riesgos que condicionan el cierre; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-002 | Validacion | Aterrizar criterios de aceptacion verificables para analisis, construccion, pruebas y entrega; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-002 | Dependencias | Validar que el alcance no prometa conexion real cuando solo exista mock o documentacion pendiente; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-002 | Seguridad | Obtener revision funcional y tecnica sobre el alcance acordado; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-002 | Cierre | Actualizar Perfex/PtD con decisiones, condiciones y pendientes del alcance; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.

PYD-003 - Confirmar alcance de Movilidad Interna

Responsable: Coordinadora técnica | Disciplina: Funcional/Backend | Sistema/componente: RMI - Registro de Movilidad Interna | Fechas: 2026-06-16 a 2026-06-18.

Descripcion detallada

PYD-003 - Confirmar alcance de Movilidad Interna

Objetivo PM: cerrar el alcance del Registro de Movilidad Interna: traslados, origen/destino, causas, responsables, seguimiento, relacion con medidas y centros.

Alcance operativo: esta tarea pertenece a H01 - H01 - Arranque, gobierno y plan de trabajo, se vincula con PYD-E1 - Plan de trabajo, estrategia y gobierno del proyecto, impacta RMI - Registro de Movilidad Interna, queda a cargo de Coordinadora técnica y esta planeada del 2026-06-16 al 2026-06-18. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: el alcance debe precisar datos, estados, validaciones, permisos, evidencias y cruces con Expediente Unico y RMH. Actividades principales del checklist: Revisar objetivo del componente Registro de Movilidad Interna y su relacion con Expediente Unico NNA e interoperabilidad; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Definir que procesos, datos, reportes e integraciones quedan incluidos en el alcance; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Documentar exclusiones, supuestos, restricciones institucionales y criterios para cambios futuros; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Identificar dependencias externas, responsables de aprobacion y riesgos que condicionan el cierre; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Aterrizar criterios de aceptacion verificables para analisis, construccion, pruebas y entrega; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-003 (Confirmar alcance de Movilidad Interna): documento de alcance, lista de incluidos/excluidos, supuestos, criterios de aceptacion y aprobacion funcional/tecnica. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-003 solo si "Confirmar alcance de Movilidad Interna" produce documento de alcance con incluidos, excluidos, supuestos, dependencias, criterios de aceptacion y responsables; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando RMI queda delimitado y no se confunde con canalizaciones migratorias o movimientos externos. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-003 - Infraestructura de desarrollo; DEP-INM-001 - Enlace técnico y funcional

Riesgos y controles: Alcance ambiguo que provoque retrabajo, expectativas no aprobadas o cierre condicionado del entregable. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo; DEP-INM-001 - Enlace técnico y funcional. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-003 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-003 - Infraestructura de desarrollo; DEP-INM-001 - Enlace técnico y funcional. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Coordinadora técnica puede coordinar la revision de Registro de Movilidad Interna, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-003 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-003 (Confirmar alcance de Movilidad Interna): documento de alcance, lista de incluidos/excluidos, supuestos, criterios de aceptacion y aprobacion funcional/tecnica. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-003 solo si "Confirmar alcance de Movilidad Interna" produce documento de alcance con incluidos, excluidos, supuestos, dependencias, criterios de aceptacion y responsables; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando RMI queda delimitado y no se confunde con canalizaciones migratorias o movimientos externos. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Alcance ambiguo que provoque retrabajo, expectativas no aprobadas o cierre condicionado del entregable. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo; DEP-INM-001 - Enlace técnico y funcional. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-003 | Alcance | Revisar objetivo del componente Registro de Movilidad Interna y su relacion con Expediente Unico NNA e interoperabilidad; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-003 | Analisis | Definir que procesos, datos, reportes e integraciones quedan incluidos en el alcance; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-003 | Construccion | Documentar exclusiones, supuestos, restricciones institucionales y criterios para cambios futuros; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-003 | Evidencia | Identificar dependencias externas, responsables de aprobacion y riesgos que condicionan el cierre; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-003 | Validacion | Aterrizar criterios de aceptacion verificables para analisis, construccion, pruebas y entrega; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-003 | Dependencias | Validar que el alcance no prometa conexion real cuando solo exista mock o documentacion pendiente; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-003 | Seguridad | Obtener revision funcional y tecnica sobre el alcance acordado; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-003 | Cierre | Actualizar Perfex/PtD con decisiones, condiciones y pendientes del alcance; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.

PYD-004 - Identificar responsables institucionales

Responsable: Coordinadora técnica | Disciplina: Coordinacion | Sistema/componente: Gobierno del Proyecto | Fechas: 2026-06-16 a 2026-06-18.

Descripcion detallada

PYD-004 - Identificar responsables institucionales

Objetivo PM: identificar quien decide, quien opera, quien valida, quien autoriza accesos y quien escala bloqueos durante el proyecto.

Alcance operativo: esta tarea pertenece a H01 - H01 - Arranque, gobierno y plan de trabajo, se vincula con PYD-E1 - Plan de trabajo, estrategia y gobierno del proyecto, impacta Gobierno del Proyecto, queda a cargo de Coordinadora técnica y esta planeada del 2026-06-16 al 2026-06-18. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: la matriz debe distinguir responsables funcionales, tecnicos, suplentes y aprobadores, con relacion directa a entregables e integraciones. Actividades principales del checklist: Listar instituciones, areas y responsables que participan en decisiones, validaciones o entregas; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Separar responsable funcional, responsable tecnico, suplente, aprobador y ruta de escalamiento; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Registrar datos de contacto operativos sin incluir secretos ni credenciales; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Identificar quien autoriza cambios de alcance, accesos, datos, integraciones y evidencia contractual; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Relacionar cada responsable con hitos, entregables o dependencias concretas; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-004 (Identificar responsables institucionales): matriz de responsables institucionales con contacto funcional, tecnico, suplente y ruta de escalamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-004 solo si "Identificar responsables institucionales" produce matriz de responsables institucionales con contacto funcional, tecnico, suplente y ruta de escalamiento; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando no quedan actividades criticas sin responsable unico de cierre. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-RDVF-001 - Responsable tecnico; DEP-RMP-001 - Responsable tecnico; DEP-RNCAS-001 - Responsable tecnico

Riesgos y controles: Riesgo de cerrar Identificar responsables institucionales sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-RDVF-001 - Responsable tecnico; DEP-RMP-001 - Responsable tecnico; DEP-RNCAS-001 - Responsable tecnico. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-004 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-RDVF-001 - Responsable tecnico; DEP-RMP-001 - Responsable tecnico; DEP-RNCAS-001 - Responsable tecnico. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Coordinadora técnica puede coordinar la revision de Gobierno del Proyecto, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-004 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-004 (Identificar responsables institucionales): matriz de responsables institucionales con contacto funcional, tecnico, suplente y ruta de escalamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-004 solo si "Identificar responsables institucionales" produce matriz de responsables institucionales con contacto funcional, tecnico, suplente y ruta de escalamiento; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando no quedan actividades criticas sin responsable unico de cierre. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Riesgo de cerrar Identificar responsables institucionales sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-RDVF-001 - Responsable tecnico; DEP-RMP-001 - Responsable tecnico; DEP-RNCAS-001 - Responsable tecnico. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-004 | Alcance | Listar instituciones, areas y responsables que participan en decisiones, validaciones o entregas; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-004 | Analisis | Separar responsable funcional, responsable tecnico, suplente, aprobador y ruta de escalamiento; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-004 | Construccion | Registrar datos de contacto operativos sin incluir secretos ni credenciales; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-004 | Evidencia | Identificar quien autoriza cambios de alcance, accesos, datos, integraciones y evidencia contractual; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-004 | Validacion | Relacionar cada responsable con hitos, entregables o dependencias concretas; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-004 | Dependencias | Validar la matriz con coordinacion y corregir vacios de responsabilidad; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-004 | Seguridad | Publicar la version controlada en Perfex/PtD o repositorio documental autorizado; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-004 | Cierre | Registrar fecha de revision y siguiente actualizacion programada; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.

PYD-006 - Crear matriz RACI

Responsable: Coordinadora técnica | Disciplina: Coordinacion | Sistema/componente: Gobierno del Proyecto | Fechas: 2026-06-17 a 2026-06-19.

Descripcion detallada

PYD-006 - Crear matriz RACI

Objetivo PM: definir responsabilidad real por actividad y aprobacion, evitando que los cierres queden repartidos entre varias areas sin accountable.

Alcance operativo: esta tarea pertenece a H01 - H01 - Arranque, gobierno y plan de trabajo, se vincula con PYD-E1 - Plan de trabajo, estrategia y gobierno del proyecto, impacta Gobierno del Proyecto, queda a cargo de Coordinadora técnica y esta planeada del 2026-06-17 al 2026-06-19. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: la matriz debe cubrir entregables, hitos, integraciones, QA, seguridad, datos, aprobaciones y escalamiento. Actividades principales del checklist: Listar actividades principales por entregable, hito, integracion, QA, seguridad y datos; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Asignar Responsible, Accountable, Consulted e Informed sin duplicar aprobadores finales; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Resolver vacios donde no exista responsable unico de decision; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Validar segregacion de funciones en aprobaciones tecnicas, funcionales y de seguridad; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Alinear RACI con responsables registrados en Perfex/PtD; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-006 (Crear matriz RACI): matriz RACI aprobada para entregables, hitos, integraciones, QA, seguridad y aprobaciones. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-006 solo si "Crear matriz RACI" produce matriz RACI aprobada para entregables, hitos, integraciones, QA, seguridad y aprobaciones; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando coordinacion acepta la RACI y se resuelven vacios de responsabilidad. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: No hay una dependencia directa enlazada por texto; aun asi debe verificarse que ambientes, accesos, datos de prueba y responsables esten disponibles antes del cierre.

Riesgos y controles: Riesgo de cerrar Crear matriz RACI sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-006 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Coordinadora técnica puede coordinar la revision de Gobierno del Proyecto, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-006 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-006 (Crear matriz RACI): matriz RACI aprobada para entregables, hitos, integraciones, QA, seguridad y aprobaciones. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-006 solo si "Crear matriz RACI" produce matriz RACI aprobada para entregables, hitos, integraciones, QA, seguridad y aprobaciones; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando coordinacion acepta la RACI y se resuelven vacios de responsabilidad. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Riesgo de cerrar Crear matriz RACI sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-006 | Alcance | Listar actividades principales por entregable, hito, integracion, QA, seguridad y datos; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-006 | Analisis | Asignar Responsible, Accountable, Consulted e Informed sin duplicar aprobadores finales; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-006 | Construccion | Resolver vacios donde no exista responsable unico de decision; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-006 | Evidencia | Validar segregacion de funciones en aprobaciones tecnicas, funcionales y de seguridad; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-006 | Validacion | Alinear RACI con responsables registrados en Perfex/PtD; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-006 | Dependencias | Documentar excepciones y acuerdos de escalamiento; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-006 | Seguridad | Obtener revision de coordinacion tecnica y aprobador funcional; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-006 | Cierre | Publicar matriz versionada y vincularla al Entregable 1; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.

PYD-009 - Elaborar estrategia de QA

Responsable: QA | Disciplina: QA | Sistema/componente: QA y Certificacion | Fechas: 2026-06-18 a 2026-06-22.

Descripcion detallada

PYD-009 - Elaborar estrategia de QA

Objetivo PM: establecer como se comprobara calidad funcional, integracion, permisos, datos, seguridad, rendimiento y regresion.

Alcance operativo: esta tarea pertenece a H01 - H01 - Arranque, gobierno y plan de trabajo, se vincula con PYD-E1 - Plan de trabajo, estrategia y gobierno del proyecto, impacta QA y Certificacion, queda a cargo de QA y esta planeada del 2026-06-18 al 2026-06-22. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: la estrategia debe definir casos, ambientes, datos, severidades, criterios de entrada/salida y evidencia obligatoria. Actividades principales del checklist: Definir alcance QA por modulo: Expediente, RMH, RMI, integraciones, seguridad, reportes y documentos; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Establecer tipos de prueba: funcional, integracion, regresion, permisos, datos limite, carga y humo; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Definir ambientes, datos de prueba anonimizados y criterios de entrada/salida; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Crear matriz de trazabilidad entre historias, tareas, casos y evidencias; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Establecer severidades, SLA de defectos y criterio para bloquear liberacion; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-009 (Elaborar estrategia de QA): estrategia QA con alcance, tipos de prueba, ambientes, datos, criterios de entrada/salida y evidencia. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-009 solo si "Elaborar estrategia de QA" produce estrategia QA con alcance, tipos de prueba, ambientes, datos, criterios de entrada/salida y evidencia; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando QA puede ejecutar sin reinterpretar alcance ni inventar datos de prueba. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-INM-006 - Ventana de certificación; DEP-INM-007 - Certificación QA; DEP-RDVF-007 - Certificacion; DEP-RMP-007 - Certificacion; DEP-RNCAS-007 - Certificacion

Riesgos y controles: Riesgo de cerrar Elaborar estrategia de QA sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-INM-006 - Ventana de certificación; DEP-INM-007 - Certificación QA; DEP-RDVF-007 - Certificacion; DEP-RMP-007 - Certificacion; DEP-RNCAS-007 - Certificacion. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-009 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-INM-006 - Ventana de certificación; DEP-INM-007 - Certificación QA; DEP-RDVF-007 - Certificacion; DEP-RMP-007 - Certificacion; DEP-RNCAS-007 - Certificacion. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que QA puede coordinar la revision de QA y Certificacion, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-009 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-009 (Elaborar estrategia de QA): estrategia QA con alcance, tipos de prueba, ambientes, datos, criterios de entrada/salida y evidencia. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-009 solo si "Elaborar estrategia de QA" produce estrategia QA con alcance, tipos de prueba, ambientes, datos, criterios de entrada/salida y evidencia; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando QA puede ejecutar sin reinterpretar alcance ni inventar datos de prueba. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Riesgo de cerrar Elaborar estrategia de QA sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-INM-006 - Ventana de certificación; DEP-INM-007 - Certificación QA; DEP-RDVF-007 - Certificacion; DEP-RMP-007 - Certificacion; DEP-RNCAS-007 - Certificacion. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-009 | Alcance | Definir alcance QA por modulo: Expediente, RMH, RMI, integraciones, seguridad, reportes y documentos; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-009 | Analisis | Establecer tipos de prueba: funcional, integracion, regresion, permisos, datos limite, carga y humo; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-009 | Construccion | Definir ambientes, datos de prueba anonimizados y criterios de entrada/salida; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-009 | Evidencia | Crear matriz de trazabilidad entre historias, tareas, casos y evidencias; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-009 | Validacion | Establecer severidades, SLA de defectos y criterio para bloquear liberacion; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-009 | Dependencias | Definir formato de reporte QA y evidencias obligatorias; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-009 | Seguridad | Acordar responsables de ejecucion, validacion y aprobacion; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-009 | Cierre | Registrar estrategia en Perfex/PtD y vincularla al Entregable 1; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.

PYD-010 - Elaborar estrategia de interoperabilidad con mocks

Responsable: Integraciones | Disciplina: Integraciones | Sistema/componente: Interoperabilidad Interna/Externa | Fechas: 2026-06-18 a 2026-06-22.

Descripcion detallada

PYD-010 - Elaborar estrategia de interoperabilidad con mocks

Objetivo PM: ordenar la interoperabilidad por estados verificables: contrato, mock, adaptador, conexion real, certificacion y produccion.

Alcance operativo: esta tarea pertenece a H01 - H01 - Arranque, gobierno y plan de trabajo, se vincula con PYD-E1 - Plan de trabajo, estrategia y gobierno del proyecto, impacta Interoperabilidad Interna/Externa, queda a cargo de Integraciones y esta planeada del 2026-06-18 al 2026-06-22. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: la estrategia debe indicar versionado OpenAPI/JSON, errores, reintentos, idempotencia, seguridad, auditoria y responsables externos. Actividades principales del checklist: Listar sistemas internos y externos: INM, COMAR, RDVF, RMP, RNCAS, RMH, RMI y Expediente Unico; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Definir que integraciones avanzan con mock, cuales requieren contrato y cuales requieren conexion real; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Establecer versionado de contratos OpenAPI/JSON, errores, reintentos y trazabilidad; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Definir seguridad: OAuth2/JWT, VPN, allowlist, certificados o condicion pendiente; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Crear criterio para no marcar certificacion si solo existe mock; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-010 (Elaborar estrategia de interoperabilidad con mocks): estrategia de interoperabilidad con mocks, contratos, adaptadores, seguridad, estados y certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-010 solo si "Elaborar estrategia de interoperabilidad con mocks" produce estrategia de interoperabilidad con mocks, contratos, adaptadores, seguridad, estados y certificacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando cada sistema tiene camino de avance y condicion formal si la contraparte no entrega accesos o contratos. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-RDVF-005 - Mock validado; DEP-RMP-005 - Mock validado; DEP-RNCAS-005 - Mock validado

Riesgos y controles: Riesgo de cerrar Elaborar estrategia de interoperabilidad con mocks sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-RDVF-005 - Mock validado; DEP-RMP-005 - Mock validado; DEP-RNCAS-005 - Mock validado. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-010 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-RDVF-005 - Mock validado; DEP-RMP-005 - Mock validado; DEP-RNCAS-005 - Mock validado. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Integraciones puede coordinar la revision de Interoperabilidad Interna/Externa, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-010 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-010 (Elaborar estrategia de interoperabilidad con mocks): estrategia de interoperabilidad con mocks, contratos, adaptadores, seguridad, estados y certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-010 solo si "Elaborar estrategia de interoperabilidad con mocks" produce estrategia de interoperabilidad con mocks, contratos, adaptadores, seguridad, estados y certificacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando cada sistema tiene camino de avance y condicion formal si la contraparte no entrega accesos o contratos. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Riesgo de cerrar Elaborar estrategia de interoperabilidad con mocks sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-RDVF-005 - Mock validado; DEP-RMP-005 - Mock validado; DEP-RNCAS-005 - Mock validado. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-010 | Alcance | Listar sistemas internos y externos: INM, COMAR, RDVF, RMP, RNCAS, RMH, RMI y Expediente Unico; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-010 | Analisis | Definir que integraciones avanzan con mock, cuales requieren contrato y cuales requieren conexion real; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-010 | Construccion | Establecer versionado de contratos OpenAPI/JSON, errores, reintentos y trazabilidad; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-010 | Evidencia | Definir seguridad: OAuth2/JWT, VPN, allowlist, certificados o condicion pendiente; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-010 | Validacion | Crear criterio para no marcar certificacion si solo existe mock; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-010 | Dependencias | Definir bitacora de intercambio, correlation ID y evidencia de prueba; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-010 | Seguridad | Relacionar dependencias externas con tareas y fechas del plan; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-010 | Cierre | Publicar estrategia y actualizar estados de integracion en PtD; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.

PYD-020 - Taller de captura inicial del NNA

Responsable: Analista funcional | Disciplina: Coordinacion | Sistema/componente: PortusDerechos 2.0 | Fechas: 2026-06-30 a 2026-07-01.

Descripcion detallada

PYD-020 - Taller de captura inicial del NNA

Objetivo PM: levantar como se registra por primera vez un NNA: identidad, datos generales, documentos, fuente institucional, validaciones, duplicados y permisos de captura.

Alcance operativo: esta tarea pertenece a H02 - H02 - Levantamiento funcional y normativo, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta PortusDerechos 2.0, queda a cargo de Analista funcional y esta planeada del 2026-06-30 al 2026-07-01. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: el taller debe producir flujo de captura, campos obligatorios/opcionales, excepciones, evidencias y preguntas que impactan modelo de datos o UX. Actividades principales del checklist: Preparar guion del taller y preguntas especificas para Expediente Unico NNA y captura inicial de identidad/datos generales; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Confirmar usuarios expertos, responsables funcionales y perfiles que operan el flujo; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Levantar flujo actual paso a paso, incluyendo excepciones, documentos usados y decisiones manuales; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Identificar datos capturados, validaciones reales, puntos de dolor y riesgos operativos; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Separar reglas obligatorias de preferencias de interfaz o reporteo; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-020 (Taller de captura inicial del NNA): minuta de taller, flujo levantado, reglas operativas, preguntas abiertas, evidencias funcionales y acuerdos. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-020 solo si "Taller de captura inicial del NNA" produce minuta de taller con flujo actual, reglas operativas, pain points, decisiones y dudas por resolver; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el flujo puede transformarse en formulario, API, validaciones y casos de prueba. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: No hay una dependencia directa enlazada por texto; aun asi debe verificarse que ambientes, accesos, datos de prueba y responsables esten disponibles antes del cierre.

Riesgos y controles: Riesgo de cerrar Taller de captura inicial del NNA sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-020 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Analista funcional puede coordinar la revision de Expediente Unico NNA y captura inicial de identidad/datos generales, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-020 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-020 (Taller de captura inicial del NNA): minuta de taller, flujo levantado, reglas operativas, preguntas abiertas, evidencias funcionales y acuerdos. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-020 solo si "Taller de captura inicial del NNA" produce minuta de taller con flujo actual, reglas operativas, pain points, decisiones y dudas por resolver; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el flujo puede transformarse en formulario, API, validaciones y casos de prueba. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Riesgo de cerrar Taller de captura inicial del NNA sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-020 | Alcance | Preparar guion del taller y preguntas especificas para Expediente Unico NNA y captura inicial de identidad/datos generales; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
PYD-020 | Analisis | Confirmar usuarios expertos, responsables funcionales y perfiles que operan el flujo; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
PYD-020 | Construccion | Levantar flujo actual paso a paso, incluyendo excepciones, documentos usados y decisiones manuales; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
PYD-020 | Evidencia | Identificar datos capturados, validaciones reales, puntos de dolor y riesgos operativos; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
PYD-020 | Validacion | Separar reglas obligatorias de preferencias de interfaz o reporteo; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
PYD-020 | Dependencias | Registrar acuerdos, dudas abiertas, supuestos y evidencias entregadas durante el taller; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
PYD-020 | Seguridad | Traducir hallazgos a historias, reglas, catalogos o tareas tecnicas trazables; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
PYD-020 | Cierre | Validar minuta del taller con el responsable funcional antes de cerrar la tarea; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.

PYD-024 - Definir roles y jerarquías

Responsable: Analista funcional | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2026-07-06 a 2026-07-08.

Descripcion detallada

PYD-024 - Definir roles y jerarquías

Objetivo PM: asegurar que cada perfil acceda solo a funciones, rutas, datos y acciones autorizadas.

Alcance operativo: esta tarea pertenece a H02 - H02 - Levantamiento funcional y normativo, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta Acceso Unico Institucional, queda a cargo de Analista funcional y esta planeada del 2026-07-06 al 2026-07-08. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: debe mapear roles, permisos, rutas protegidas, acciones criticas, denegaciones y evidencia de auditoria. Actividades principales del checklist: Identificar perfiles de usuario reales y acciones que ejecutan en cada modulo; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Definir jerarquia, permisos de consulta, captura, modificacion, autorizacion, exportacion y administracion; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Marcar acciones criticas que requieren MFA, aprobacion adicional o auditoria reforzada; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Validar segregacion de funciones y conflictos de permisos; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Alinear roles con RBAC tecnico y pantallas React; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-024 (Definir roles y jerarquías): matriz de roles, jerarquias, permisos, segregacion de funciones y acciones criticas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-024 solo si "Definir roles y jerarquías" produce matriz de roles, jerarquias, permisos, segregacion de funciones y acciones criticas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con matriz de permisos y pruebas de acceso permitido/denegado. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-PF-003 - Roles y jerarquías

Riesgos y controles: Riesgo de cerrar Definir roles y jerarquías sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-PF-003 - Roles y jerarquías. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-024 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-PF-003 - Roles y jerarquías. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Analista funcional puede coordinar la revision de Acceso Unico Institucional, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-024 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-024 (Definir roles y jerarquías): matriz de roles, jerarquias, permisos, segregacion de funciones y acciones criticas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-024 solo si "Definir roles y jerarquías" produce matriz de roles, jerarquias, permisos, segregacion de funciones y acciones criticas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con matriz de permisos y pruebas de acceso permitido/denegado. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Riesgo de cerrar Definir roles y jerarquías sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-PF-003 - Roles y jerarquías. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-024 | Alcance | Identificar perfiles de usuario reales y acciones que ejecutan en cada modulo; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
PYD-024 | Analisis | Definir jerarquia, permisos de consulta, captura, modificacion, autorizacion, exportacion y administracion; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
PYD-024 | Construccion | Marcar acciones criticas que requieren MFA, aprobacion adicional o auditoria reforzada; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
PYD-024 | Evidencia | Validar segregacion de funciones y conflictos de permisos; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
PYD-024 | Validacion | Alinear roles con RBAC tecnico y pantallas React; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
PYD-024 | Dependencias | Definir datos sensibles que no deben mostrarse por perfil; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
PYD-024 | Seguridad | Revisar matriz con seguridad, DTI y responsable funcional; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
PYD-024 | Cierre | Registrar matriz aprobada y pendientes de implementacion; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.

PYD-030 - Definir requisitos de seguridad

Responsable: Seguridad | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2026-07-06 a 2026-07-10.

Descripcion detallada

PYD-030 - Definir requisitos de seguridad

Objetivo PM: definir requisitos medibles para Acceso Unico Institucional, con umbrales, metodo de verificacion y responsable de aceptacion.

Alcance operativo: esta tarea pertenece a H03 - H03 - Requerimientos no funcionales, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta Acceso Unico Institucional, queda a cargo de Seguridad y esta planeada del 2026-07-06 al 2026-07-10. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: cada requisito debe poder probarse; se deben evitar frases aspiracionales sin metrica, ambiente o evidencia. Actividades principales del checklist: Definir requisito medible y ambito exacto para Definir requisitos de seguridad; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.; Establecer metrica, umbral, metodo de medicion y ambiente de prueba; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.; Identificar impacto en arquitectura, infraestructura, datos, seguridad y experiencia de usuario; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.; Definir casos de prueba y evidencia requerida para aceptar el requisito; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.; Registrar supuestos, restricciones y dependencias tecnicas; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-030 (Definir requisitos de seguridad): documento de requisitos no funcionales medibles, umbrales, metodos de prueba y responsables. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-030 solo si "Definir requisitos de seguridad" produce documento de requisitos no funcionales medibles, umbrales, metodos de prueba y responsables; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando QA y arquitectura pueden convertir los requisitos en pruebas o controles. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos

Riesgos y controles: Riesgo de cerrar Definir requisitos de seguridad sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-030 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Seguridad puede coordinar la revision de Acceso Unico Institucional, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-030 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-030 (Definir requisitos de seguridad): documento de requisitos no funcionales medibles, umbrales, metodos de prueba y responsables. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-030 solo si "Definir requisitos de seguridad" produce documento de requisitos no funcionales medibles, umbrales, metodos de prueba y responsables; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando QA y arquitectura pueden convertir los requisitos en pruebas o controles. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Riesgo de cerrar Definir requisitos de seguridad sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-030 | Alcance | Definir requisito medible y ambito exacto para Definir requisitos de seguridad; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
PYD-030 | Analisis | Establecer metrica, umbral, metodo de medicion y ambiente de prueba; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
PYD-030 | Construccion | Identificar impacto en arquitectura, infraestructura, datos, seguridad y experiencia de usuario; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
PYD-030 | Evidencia | Definir casos de prueba y evidencia requerida para aceptar el requisito; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
PYD-030 | Validacion | Registrar supuestos, restricciones y dependencias tecnicas; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
PYD-030 | Dependencias | Validar viabilidad con desarrollo, QA, seguridad y DTI; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
PYD-030 | Seguridad | Aprobar requisito con responsable tecnico y funcional; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
PYD-030 | Cierre | Actualizar trazabilidad con hitos y entregables del proyecto; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.

PYD-031 - Definir auditoría y trazabilidad

Responsable: Seguridad | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2026-07-08 a 2026-07-13.

Descripcion detallada

PYD-031 - Definir auditoría y trazabilidad

Objetivo PM: evaluar seguridad con alcance autorizado, evidencia controlada y plan de remediacion accionable.

Alcance operativo: esta tarea pertenece a H03 - H03 - Requerimientos no funcionales, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta Acceso Unico Institucional, queda a cargo de Seguridad y esta planeada del 2026-07-08 al 2026-07-13. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: la prueba debe cubrir roles, sesion, APIs, configuracion, datos sensibles y hallazgos clasificados por severidad. Actividades principales del checklist: Definir alcance exacto de seguridad para Definir auditoría y trazabilidad: modulos, endpoints, roles y datos sensibles; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.; Preparar ambiente, usuarios de prueba, ventanas de ejecucion y autorizacion formal; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.; Ejecutar pruebas o revision segun alcance: permisos, sesion, API, datos, configuracion o pentest; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.; Clasificar hallazgos por severidad, impacto, explotabilidad y evidencia; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.; Registrar plan de remediacion con responsable y fecha objetivo; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-031 (Definir auditoría y trazabilidad): reporte de seguridad, hallazgos, severidad, evidencia controlada, remediacion y retest. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-031 solo si "Definir auditoría y trazabilidad" produce reporte de seguridad con alcance, evidencia, hallazgos, severidad, plan de remediacion y retest; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con reporte, plan de remediacion, retest o excepcion formal aprobada. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos

Riesgos y controles: Hallazgos criticos sin ventana de remediacion, evidencia sensible mal resguardada o retest incompleto. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: Las pruebas de seguridad solo pueden ejecutarse sobre alcance autorizado, ambientes permitidos y usuarios de prueba. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Seguridad puede coordinar la revision de Acceso Unico Institucional, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-031 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-031 (Definir auditoría y trazabilidad): reporte de seguridad, hallazgos, severidad, evidencia controlada, remediacion y retest. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-031 solo si "Definir auditoría y trazabilidad" produce reporte de seguridad con alcance, evidencia, hallazgos, severidad, plan de remediacion y retest; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con reporte, plan de remediacion, retest o excepcion formal aprobada. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Hallazgos criticos sin ventana de remediacion, evidencia sensible mal resguardada o retest incompleto. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-031 | Alcance | Definir alcance exacto de seguridad para Definir auditoría y trazabilidad: modulos, endpoints, roles y datos sensibles; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
PYD-031 | Analisis | Preparar ambiente, usuarios de prueba, ventanas de ejecucion y autorizacion formal; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
PYD-031 | Construccion | Ejecutar pruebas o revision segun alcance: permisos, sesion, API, datos, configuracion o pentest; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
PYD-031 | Evidencia | Clasificar hallazgos por severidad, impacto, explotabilidad y evidencia; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
PYD-031 | Validacion | Registrar plan de remediacion con responsable y fecha objetivo; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
PYD-031 | Dependencias | Validar que evidencias no incluyan secretos ni datos personales reales; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
PYD-031 | Seguridad | Ejecutar retest o definir condicion formal cuando aplique; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
PYD-031 | Cierre | Actualizar riesgos, RAID y criterio de liberacion; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.

PYD-032 - Diseñar C4 Contexto

Responsable: Integraciones | Disciplina: Arquitectura | Sistema/componente: Arquitectura Institucional | Fechas: 2026-07-08 a 2026-07-10.

Descripcion detallada

PYD-032 - Diseñar C4 Contexto

Objetivo PM: representar el ecosistema institucional de PortusDerechos 2.0: usuarios, registros, servicios transversales, INM, COMAR y limites del sistema.

Alcance operativo: esta tarea pertenece a H04 - H04 - Arquitectura C4 y modelo de datos preliminar, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta Arquitectura Institucional, queda a cargo de Integraciones y esta planeada del 2026-07-08 al 2026-07-10. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: el diagrama debe mostrar actores, sistemas externos, fronteras, responsabilidades de datos y relaciones de confianza. Actividades principales del checklist: Definir alcance del artefacto de diseno para Diseñar C4 Contexto; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-032 (Diseñar C4 Contexto): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-032 solo si "Diseñar C4 Contexto" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el contexto explica quien usa, quien provee datos y que queda fuera del sistema. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional

Riesgos y controles: Riesgo de cerrar Diseñar C4 Contexto sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-032 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Integraciones puede coordinar la revision de arquitectura C4 de contexto institucional, actores, registros y sistemas externos, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-032 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-032 (Diseñar C4 Contexto): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-032 solo si "Diseñar C4 Contexto" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el contexto explica quien usa, quien provee datos y que queda fuera del sistema. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Riesgo de cerrar Diseñar C4 Contexto sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-032 | Alcance | Definir alcance del artefacto de diseno para Diseñar C4 Contexto; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-032 | Analisis | Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-032 | Construccion | Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-032 | Evidencia | Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-032 | Validacion | Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-032 | Dependencias | Registrar riesgos tecnicos y decisiones ADR cuando aplique; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-032 | Seguridad | Revisar el artefacto con arquitectura, desarrollo y QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-032 | Cierre | Publicar version aprobada y vincularla al entregable correspondiente; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.

PYD-033 - Diseñar C4 Contenedores

Responsable: Integraciones | Disciplina: Arquitectura | Sistema/componente: Arquitectura Tecnica | Fechas: 2026-07-10 a 2026-07-14.

Descripcion detallada

PYD-033 - Diseñar C4 Contenedores

Objetivo PM: definir contenedores logicos y tecnologicos: frontend React, API Gateway/FastAPI, servicios, PostgreSQL, mensajeria, documentos, seguridad y observabilidad.

Alcance operativo: esta tarea pertenece a H04 - H04 - Arquitectura C4 y modelo de datos preliminar, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta Arquitectura Tecnica, queda a cargo de Integraciones y esta planeada del 2026-07-10 al 2026-07-14. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: el diseno debe aterrizar responsabilidades, protocolos, despliegue, dependencias y puntos de fallo por contenedor. Actividades principales del checklist: Definir alcance del artefacto de diseno para Diseñar C4 Contenedores; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-033 (Diseñar C4 Contenedores): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-033 solo si "Diseñar C4 Contenedores" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando cada contenedor tiene proposito, contrato y relacion clara con el modelo operativo. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional

Riesgos y controles: Riesgo de cerrar Diseñar C4 Contenedores sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-033 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Integraciones puede coordinar la revision de contenedores backend, frontend, datos, integraciones y servicios transversales, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-033 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-033 (Diseñar C4 Contenedores): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-033 solo si "Diseñar C4 Contenedores" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando cada contenedor tiene proposito, contrato y relacion clara con el modelo operativo. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Riesgo de cerrar Diseñar C4 Contenedores sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-033 | Alcance | Definir alcance del artefacto de diseno para Diseñar C4 Contenedores; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-033 | Analisis | Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-033 | Construccion | Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-033 | Evidencia | Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-033 | Validacion | Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-033 | Dependencias | Registrar riesgos tecnicos y decisiones ADR cuando aplique; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-033 | Seguridad | Revisar el artefacto con arquitectura, desarrollo y QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-033 | Cierre | Publicar version aprobada y vincularla al entregable correspondiente; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.

PYD-034 - Diseñar componentes FastAPI

Responsable: Backend 1 | Disciplina: Backend/Arquitectura | Sistema/componente: FastAPI / API Gateway | Fechas: 2026-07-10 a 2026-07-15.

Descripcion detallada

PYD-034 - Diseñar componentes FastAPI

Objetivo PM: definir o preparar la base FastAPI para servicios de Expediente, RMH, RMI, interoperabilidad, seguridad y observabilidad.

Alcance operativo: esta tarea pertenece a H04 - H04 - Arquitectura C4 y modelo de datos preliminar, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta FastAPI / API Gateway, queda a cargo de Backend 1 y esta planeada del 2026-07-10 al 2026-07-15. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: debe quedar estructura de routers, dependencias, validaciones Pydantic, errores, OpenAPI, configuracion y pruebas base. Actividades principales del checklist: Definir alcance del artefacto de diseno para Diseñar componentes FastAPI; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-034 (Diseñar componentes FastAPI): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-034 solo si "Diseñar componentes FastAPI" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el servicio arranca, publica contrato y soporta pruebas automatizadas iniciales. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional

Riesgos y controles: Riesgo de cerrar Diseñar componentes FastAPI sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-034 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Backend 1 puede coordinar la revision de FastAPI / API Gateway, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-034 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-034 (Diseñar componentes FastAPI): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-034 solo si "Diseñar componentes FastAPI" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el servicio arranca, publica contrato y soporta pruebas automatizadas iniciales. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Riesgo de cerrar Diseñar componentes FastAPI sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-034 | Alcance | Definir alcance del artefacto de diseno para Diseñar componentes FastAPI; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-034 | Analisis | Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-034 | Construccion | Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-034 | Evidencia | Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-034 | Validacion | Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-034 | Dependencias | Registrar riesgos tecnicos y decisiones ADR cuando aplique; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-034 | Seguridad | Revisar el artefacto con arquitectura, desarrollo y QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-034 | Cierre | Publicar version aprobada y vincularla al entregable correspondiente; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.

PYD-035 - Diseñar arquitectura React

Responsable: Frontend 1 | Disciplina: Frontend | Sistema/componente: Frontend React / UI Operativa | Fechas: 2026-07-10 a 2026-07-15.

Descripcion detallada

PYD-035 - Diseñar arquitectura React

Objetivo PM: definir o preparar la base React 19 para una operacion institucional: rutas, layout, formularios, bandejas, permisos y componentes reutilizables.

Alcance operativo: esta tarea pertenece a H04 - H04 - Arquitectura C4 y modelo de datos preliminar, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta Frontend React / UI Operativa, queda a cargo de Frontend 1 y esta planeada del 2026-07-10 al 2026-07-15. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: debe quedar estructura Vite/PNPM, convenciones de componentes, manejo de estado, servicios API, errores y pruebas frontend. Actividades principales del checklist: Definir alcance del artefacto de diseno para Diseñar arquitectura React; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-035 (Diseñar arquitectura React): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-035 solo si "Diseñar arquitectura React" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el frontend corre, consume configuracion y permite extender flujos sin rehacer arquitectura. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional

Riesgos y controles: Riesgo de cerrar Diseñar arquitectura React sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-035 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Frontend 1 puede coordinar la revision de Frontend React 19, rutas, estado, componentes y UX operativa, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-035 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-035 (Diseñar arquitectura React): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-035 solo si "Diseñar arquitectura React" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el frontend corre, consume configuracion y permite extender flujos sin rehacer arquitectura. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Riesgo de cerrar Diseñar arquitectura React sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-035 | Alcance | Definir alcance del artefacto de diseno para Diseñar arquitectura React; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-035 | Analisis | Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-035 | Construccion | Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-035 | Evidencia | Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-035 | Validacion | Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-035 | Dependencias | Registrar riesgos tecnicos y decisiones ADR cuando aplique; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-035 | Seguridad | Revisar el artefacto con arquitectura, desarrollo y QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-035 | Cierre | Publicar version aprobada y vincularla al entregable correspondiente; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.

PYD-036 - Diseñar ERD PostgreSQL

Responsable: Datos | Disciplina: Datos | Sistema/componente: PostgreSQL / Gobierno de Datos | Fechas: 2026-07-08 a 2026-07-15.

Descripcion detallada

PYD-036 - Diseñar ERD PostgreSQL

Objetivo PM: aterrizar entidades, relaciones, catalogos, constraints y linaje de datos para Expediente, RMH, RMI e interoperabilidad.

Alcance operativo: esta tarea pertenece a H04 - H04 - Arquitectura C4 y modelo de datos preliminar, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta PostgreSQL / Gobierno de Datos, queda a cargo de Datos y esta planeada del 2026-07-08 al 2026-07-15. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: el artefacto debe cubrir llaves, cardinalidades, historiales, auditoria, campos sensibles, indices y reglas de calidad. Actividades principales del checklist: Definir alcance del artefacto de diseno para Diseñar ERD PostgreSQL; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-036 (Diseñar ERD PostgreSQL): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-036 solo si "Diseñar ERD PostgreSQL" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando desarrollo, migracion y reportes pueden usar el modelo sin reinterpretar campos. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos

Riesgos y controles: Riesgo de cerrar Diseñar ERD PostgreSQL sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-036 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Datos puede coordinar la revision de modelo relacional PostgreSQL para Expediente, RMH, RMI e interoperabilidad, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-036 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-036 (Diseñar ERD PostgreSQL): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-036 solo si "Diseñar ERD PostgreSQL" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando desarrollo, migracion y reportes pueden usar el modelo sin reinterpretar campos. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Riesgo de cerrar Diseñar ERD PostgreSQL sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-036 | Alcance | Definir alcance del artefacto de diseno para Diseñar ERD PostgreSQL; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-036 | Analisis | Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-036 | Construccion | Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-036 | Evidencia | Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-036 | Validacion | Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-036 | Dependencias | Registrar riesgos tecnicos y decisiones ADR cuando aplique; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-036 | Seguridad | Revisar el artefacto con arquitectura, desarrollo y QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-036 | Cierre | Publicar version aprobada y vincularla al entregable correspondiente; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.

PYD-037 - Elaborar diccionario de datos

Responsable: Datos | Disciplina: Datos | Sistema/componente: Gobierno de Datos | Fechas: 2026-07-10 a 2026-07-17.

Descripcion detallada

PYD-037 - Elaborar diccionario de datos

Objetivo PM: aterrizar entidades, relaciones, catalogos, constraints y linaje de datos para Expediente, RMH, RMI e interoperabilidad.

Alcance operativo: esta tarea pertenece a H04 - H04 - Arquitectura C4 y modelo de datos preliminar, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta Gobierno de Datos, queda a cargo de Datos y esta planeada del 2026-07-10 al 2026-07-17. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: el artefacto debe cubrir llaves, cardinalidades, historiales, auditoria, campos sensibles, indices y reglas de calidad. Actividades principales del checklist: Definir alcance del artefacto de diseno para Elaborar diccionario de datos; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-037 (Elaborar diccionario de datos): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-037 solo si "Elaborar diccionario de datos" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando desarrollo, migracion y reportes pueden usar el modelo sin reinterpretar campos. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos

Riesgos y controles: Riesgo de cerrar Elaborar diccionario de datos sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-037 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Datos puede coordinar la revision de Gobierno de Datos, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-037 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-037 (Elaborar diccionario de datos): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-037 solo si "Elaborar diccionario de datos" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando desarrollo, migracion y reportes pueden usar el modelo sin reinterpretar campos. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Riesgo de cerrar Elaborar diccionario de datos sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-037 | Alcance | Definir alcance del artefacto de diseno para Elaborar diccionario de datos; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-037 | Analisis | Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-037 | Construccion | Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-037 | Evidencia | Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-037 | Validacion | Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-037 | Dependencias | Registrar riesgos tecnicos y decisiones ADR cuando aplique; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-037 | Seguridad | Revisar el artefacto con arquitectura, desarrollo y QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-037 | Cierre | Publicar version aprobada y vincularla al entregable correspondiente; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.

PYD-038 - Diseñar modelo canónico de interoperabilidad

Responsable: Integraciones | Disciplina: Integraciones | Sistema/componente: Interoperabilidad Interna/Externa | Fechas: 2026-07-10 a 2026-07-17.

Descripcion detallada

PYD-038 - Diseñar modelo canónico de interoperabilidad

Objetivo PM: definir el formato comun de intercambio entre Expediente, RMH, RMI, RDVF, RMP, RNCAS, INM y COMAR.

Alcance operativo: esta tarea pertenece a H04 - H04 - Arquitectura C4 y modelo de datos preliminar, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta Interoperabilidad Interna/Externa, queda a cargo de Integraciones y esta planeada del 2026-07-10 al 2026-07-17. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: debe precisar identificadores, eventos, catalogos, payloads, versiones, errores, idempotencia y trazabilidad. Actividades principales del checklist: Definir alcance del artefacto de diseno para Diseñar modelo canónico de interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-038 (Diseñar modelo canónico de interoperabilidad): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-038 solo si "Diseñar modelo canónico de interoperabilidad" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los mocks/adaptadores pueden mapear sus datos al contrato comun. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos

Riesgos y controles: Riesgo de cerrar Diseñar modelo canónico de interoperabilidad sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-038 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Integraciones puede coordinar la revision de Interoperabilidad Interna/Externa, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-038 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-038 (Diseñar modelo canónico de interoperabilidad): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-038 solo si "Diseñar modelo canónico de interoperabilidad" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los mocks/adaptadores pueden mapear sus datos al contrato comun. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Riesgo de cerrar Diseñar modelo canónico de interoperabilidad sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-038 | Alcance | Definir alcance del artefacto de diseno para Diseñar modelo canónico de interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-038 | Analisis | Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-038 | Construccion | Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-038 | Evidencia | Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-038 | Validacion | Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-038 | Dependencias | Registrar riesgos tecnicos y decisiones ADR cuando aplique; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-038 | Seguridad | Revisar el artefacto con arquitectura, desarrollo y QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-038 | Cierre | Publicar version aprobada y vincularla al entregable correspondiente; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.

PYD-039 - Diseñar estrategia de migración

Responsable: Datos | Disciplina: Datos | Sistema/componente: Gobierno de Datos | Fechas: 2026-07-13 a 2026-07-17.

Descripcion detallada

PYD-039 - Diseñar estrategia de migración

Objetivo PM: preparar migracion con reglas de extraccion, limpieza, transformacion, conciliacion, rechazo y rollback.

Alcance operativo: esta tarea pertenece a H04 - H04 - Arquitectura C4 y modelo de datos preliminar, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta Gobierno de Datos, queda a cargo de Datos y esta planeada del 2026-07-13 al 2026-07-17. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: el trabajo debe producir totales, reglas de calidad, bitacora, muestras, diferencias explicadas y dependencias de datos fuente. Actividades principales del checklist: Definir alcance del artefacto de diseno para Diseñar estrategia de migración; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-039 (Diseñar estrategia de migración): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-039 solo si "Diseñar estrategia de migración" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los datos pueden ensayarse y conciliase sin poner en riesgo informacion real. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos

Riesgos y controles: Riesgo de cerrar Diseñar estrategia de migración sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-039 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Datos puede coordinar la revision de Gobierno de Datos, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-039 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-039 (Diseñar estrategia de migración): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-039 solo si "Diseñar estrategia de migración" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los datos pueden ensayarse y conciliase sin poner en riesgo informacion real. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Riesgo de cerrar Diseñar estrategia de migración sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-039 | Alcance | Definir alcance del artefacto de diseno para Diseñar estrategia de migración; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-039 | Analisis | Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-039 | Construccion | Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-039 | Evidencia | Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-039 | Validacion | Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-039 | Dependencias | Registrar riesgos tecnicos y decisiones ADR cuando aplique; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-039 | Seguridad | Revisar el artefacto con arquitectura, desarrollo y QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-039 | Cierre | Publicar version aprobada y vincularla al entregable correspondiente; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.

PYD-060 - Implementar búsqueda de NNA

Responsable: Backend 1 | Disciplina: Backend | Sistema/componente: Expediente Unico NNA | Fechas: 2026-08-10 a 2026-08-14.

Descripcion detallada

PYD-060 - Implementar búsqueda de NNA

Objetivo PM: implementar busqueda de expedientes NNA con criterios permitidos, filtros, permisos, auditoria y prevencion de duplicados.

Alcance operativo: esta tarea pertenece a H06 - H06 - Expediente unico, autenticacion y seguridad base, se vincula con PYD-E3 - Construccion base del Registro de Movilidad Humana e interoperabilidad mock, impacta Expediente Unico NNA, queda a cargo de Backend 1 y esta planeada del 2026-08-10 al 2026-08-14. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: debe considerar nombre, CURP o identificadores permitidos, paginacion, resultados parciales, seguridad y bitacora de consulta. Actividades principales del checklist: Confirmar historia o flujo operativo que resuelve Implementar búsqueda de NNA en Expediente Unico NNA, busqueda, filtros, permisos y auditoria; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-060 (Implementar búsqueda de NNA): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-060 solo si "Implementar búsqueda de NNA" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con casos de busqueda exacta, parcial, sin resultados, permisos insuficientes y auditoria registrada. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-003 - Infraestructura de desarrollo

Riesgos y controles: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La funcionalidad no debe cerrarse como completa si faltan contrato, permisos, pruebas, auditoria o evidencia de error controlado. Dependencias a vigilar: DEP-DTI-003 - Infraestructura de desarrollo. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Backend 1 puede coordinar la revision de Expediente Unico NNA, busqueda, filtros, permisos y auditoria, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-060 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-060 (Implementar búsqueda de NNA): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-060 solo si "Implementar búsqueda de NNA" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con casos de busqueda exacta, parcial, sin resultados, permisos insuficientes y auditoria registrada. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-060 | Alcance | Confirmar historia o flujo operativo que resuelve Implementar búsqueda de NNA en Expediente Unico NNA, busqueda, filtros, permisos y auditoria; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-060 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-060 | Construccion | Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-060 | Evidencia | Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-060 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-060 | Dependencias | Verificar que no se registren secretos ni datos personales reales en logs o evidencias; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-060 | Seguridad | Adjuntar evidencia funcional: captura, reporte de prueba, commit, PR o demo; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-060 | Cierre | Actualizar estado, riesgos e integraciones relacionadas en PtD; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.

PYD-061 - Implementar alta de expediente

Responsable: Backend 2 | Disciplina: Backend | Sistema/componente: Expediente Unico NNA | Fechas: 2026-08-10 a 2026-08-17.

Descripcion detallada

PYD-061 - Implementar alta de expediente

Objetivo PM: implementar Implementar alta de expediente dentro de Expediente Unico NNA con comportamiento claro, validaciones, permisos, auditoria y pruebas.

Alcance operativo: esta tarea pertenece a H06 - H06 - Expediente unico, autenticacion y seguridad base, se vincula con PYD-E3 - Construccion base del Registro de Movilidad Humana e interoperabilidad mock, impacta Expediente Unico NNA, queda a cargo de Backend 2 y esta planeada del 2026-08-10 al 2026-08-17. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: el desarrollo debe cubrir backend, frontend, modelo, contrato o servicio impactado, con manejo de errores y datos limite. Actividades principales del checklist: Confirmar historia o flujo operativo que resuelve Implementar alta de expediente en Expediente Unico NNA; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-061 (Implementar alta de expediente): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-061 solo si "Implementar alta de expediente" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con evidencia funcional, pruebas, trazabilidad de cambio y actualizacion de contrato o documentacion si aplica. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-003 - Infraestructura de desarrollo

Riesgos y controles: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La funcionalidad no debe cerrarse como completa si faltan contrato, permisos, pruebas, auditoria o evidencia de error controlado. Dependencias a vigilar: DEP-DTI-003 - Infraestructura de desarrollo. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Backend 2 puede coordinar la revision de Expediente Unico NNA, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-061 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-061 (Implementar alta de expediente): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-061 solo si "Implementar alta de expediente" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con evidencia funcional, pruebas, trazabilidad de cambio y actualizacion de contrato o documentacion si aplica. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-061 | Alcance | Confirmar historia o flujo operativo que resuelve Implementar alta de expediente en Expediente Unico NNA; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-061 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-061 | Construccion | Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-061 | Evidencia | Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-061 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-061 | Dependencias | Verificar que no se registren secretos ni datos personales reales en logs o evidencias; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-061 | Seguridad | Adjuntar evidencia funcional: captura, reporte de prueba, commit, PR o demo; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-061 | Cierre | Actualizar estado, riesgos e integraciones relacionadas en PtD; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.

PYD-063 - Implementar JWT/OAuth2 simulado o real

Responsable: Backend 1 | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2026-08-10 a 2026-08-18.

Descripcion detallada

PYD-063 - Implementar JWT/OAuth2 simulado o real

Objetivo PM: habilitar autenticacion institucional mediante OAuth2/JWT real o simulado de forma controlada para desarrollo y QA.

Alcance operativo: esta tarea pertenece a H06 - H06 - Expediente unico, autenticacion y seguridad base, se vincula con PYD-E3 - Construccion base del Registro de Movilidad Humana e interoperabilidad mock, impacta Acceso Unico Institucional, queda a cargo de Backend 1 y esta planeada del 2026-08-10 al 2026-08-18. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: debe cubrir emision/validacion de token, expiracion, refresh si aplica, claims, errores y configuracion segura. Actividades principales del checklist: Confirmar historia o flujo operativo que resuelve Implementar JWT/OAuth2 simulado o real en Acceso Unico Institucional con OAuth2/JWT, sesiones y tokens; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-063 (Implementar JWT/OAuth2 simulado o real): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-063 solo si "Implementar JWT/OAuth2 simulado o real" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con acceso permitido, token invalido, expirado, rol insuficiente y auditoria de sesion. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-004 - Documentación de autenticación; DEP-DTI-007 - Acceso a datos históricos; DEP-RDVF-004 - Fecha real de disponibilidad; DEP-RMP-004 - Fecha real de disponibilidad

Riesgos y controles: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-004 - Documentación de autenticación; DEP-DTI-007 - Acceso a datos históricos; DEP-RDVF-004 - Fecha real de disponibilidad; DEP-RMP-004 - Fecha real de disponibilidad. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La funcionalidad no debe cerrarse como completa si faltan contrato, permisos, pruebas, auditoria o evidencia de error controlado. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-004 - Documentación de autenticación; DEP-DTI-007 - Acceso a datos históricos; DEP-RDVF-004 - Fecha real de disponibilidad; DEP-RMP-004 - Fecha real de disponibilidad. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Backend 1 puede coordinar la revision de Acceso Unico Institucional con OAuth2/JWT, sesiones y tokens, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-063 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-063 (Implementar JWT/OAuth2 simulado o real): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-063 solo si "Implementar JWT/OAuth2 simulado o real" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con acceso permitido, token invalido, expirado, rol insuficiente y auditoria de sesion. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-004 - Documentación de autenticación; DEP-DTI-007 - Acceso a datos históricos; DEP-RDVF-004 - Fecha real de disponibilidad; DEP-RMP-004 - Fecha real de disponibilidad. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-063 | Alcance | Confirmar historia o flujo operativo que resuelve Implementar JWT/OAuth2 simulado o real en Acceso Unico Institucional con OAuth2/JWT, sesiones y tokens; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-063 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-063 | Construccion | Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-063 | Evidencia | Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-063 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-063 | Dependencias | Verificar que no se registren secretos ni datos personales reales en logs o evidencias; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-063 | Seguridad | Adjuntar evidencia funcional: captura, reporte de prueba, commit, PR o demo; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-063 | Cierre | Actualizar estado, riesgos e integraciones relacionadas en PtD; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.

PYD-064 - Implementar RBAC base

Responsable: Backend 1 | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2026-08-14 a 2026-08-20.

Descripcion detallada

PYD-064 - Implementar RBAC base

Objetivo PM: asegurar que cada perfil acceda solo a funciones, rutas, datos y acciones autorizadas.

Alcance operativo: esta tarea pertenece a H06 - H06 - Expediente unico, autenticacion y seguridad base, se vincula con PYD-E3 - Construccion base del Registro de Movilidad Humana e interoperabilidad mock, impacta Acceso Unico Institucional, queda a cargo de Backend 1 y esta planeada del 2026-08-14 al 2026-08-20. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: debe mapear roles, permisos, rutas protegidas, acciones criticas, denegaciones y evidencia de auditoria. Actividades principales del checklist: Confirmar historia o flujo operativo que resuelve Implementar RBAC base en Acceso Unico Institucional; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-064 (Implementar RBAC base): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-064 solo si "Implementar RBAC base" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con matriz de permisos y pruebas de acceso permitido/denegado. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos

Riesgos y controles: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La funcionalidad no debe cerrarse como completa si faltan contrato, permisos, pruebas, auditoria o evidencia de error controlado. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Backend 1 puede coordinar la revision de Acceso Unico Institucional, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-064 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-064 (Implementar RBAC base): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-064 solo si "Implementar RBAC base" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con matriz de permisos y pruebas de acceso permitido/denegado. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-064 | Alcance | Confirmar historia o flujo operativo que resuelve Implementar RBAC base en Acceso Unico Institucional; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-064 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-064 | Construccion | Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-064 | Evidencia | Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-064 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-064 | Dependencias | Verificar que no se registren secretos ni datos personales reales en logs o evidencias; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-064 | Seguridad | Adjuntar evidencia funcional: captura, reporte de prueba, commit, PR o demo; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-064 | Cierre | Actualizar estado, riesgos e integraciones relacionadas en PtD; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.

PYD-066 - Implementar auditoría inicial

Responsable: Backend 2 | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2026-08-17 a 2026-08-21.

Descripcion detallada

PYD-066 - Implementar auditoría inicial

Objetivo PM: implementar Implementar auditoría inicial dentro de Acceso Unico Institucional con comportamiento claro, validaciones, permisos, auditoria y pruebas.

Alcance operativo: esta tarea pertenece a H06 - H06 - Expediente unico, autenticacion y seguridad base, se vincula con PYD-E3 - Construccion base del Registro de Movilidad Humana e interoperabilidad mock, impacta Acceso Unico Institucional, queda a cargo de Backend 2 y esta planeada del 2026-08-17 al 2026-08-21. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: el desarrollo debe cubrir backend, frontend, modelo, contrato o servicio impactado, con manejo de errores y datos limite. Actividades principales del checklist: Confirmar historia o flujo operativo que resuelve Implementar auditoría inicial en Acceso Unico Institucional; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-066 (Implementar auditoría inicial): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-066 solo si "Implementar auditoría inicial" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con evidencia funcional, pruebas, trazabilidad de cambio y actualizacion de contrato o documentacion si aplica. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos

Riesgos y controles: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La funcionalidad no debe cerrarse como completa si faltan contrato, permisos, pruebas, auditoria o evidencia de error controlado. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Backend 2 puede coordinar la revision de Acceso Unico Institucional, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-066 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-066 (Implementar auditoría inicial): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-066 solo si "Implementar auditoría inicial" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con evidencia funcional, pruebas, trazabilidad de cambio y actualizacion de contrato o documentacion si aplica. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-066 | Alcance | Confirmar historia o flujo operativo que resuelve Implementar auditoría inicial en Acceso Unico Institucional; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-066 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-066 | Construccion | Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-066 | Evidencia | Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-066 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-066 | Dependencias | Verificar que no se registren secretos ni datos personales reales en logs o evidencias; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-066 | Seguridad | Adjuntar evidencia funcional: captura, reporte de prueba, commit, PR o demo; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-066 | Cierre | Actualizar estado, riesgos e integraciones relacionadas en PtD; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.

PYD-071 - API de situación migratoria

Responsable: Backend 2 | Disciplina: Integraciones | Sistema/componente: Interoperabilidad Interna/Externa | Fechas: 2026-08-24 a 2026-08-31.

Descripcion detallada

PYD-071 - API de situación migratoria

Objetivo PM: implementar servicios RMH para consultar y actualizar situacion/seguimiento migratorio con historial y fuente trazable.

Alcance operativo: esta tarea pertenece a H07 - H07 - Caso de Movilidad Humana, se vincula con PYD-E3 - Construccion base del Registro de Movilidad Humana e interoperabilidad mock, impacta Interoperabilidad Interna/Externa, queda a cargo de Backend 2 y esta planeada del 2026-08-24 al 2026-08-31. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: debe cubrir estados, eventos, validaciones, usuario responsable, fecha, evidencia y compatibilidad con INM/COMAR si aplica. Actividades principales del checklist: Confirmar historia o flujo operativo que resuelve API de situación migratoria en Interoperabilidad Interna/Externa; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.; Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.; Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.; Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.; Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-071 (API de situación migratoria): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-071 solo si "API de situación migratoria" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con cambios de estado, consulta de historial, error controlado y bitacora completa. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: No hay una dependencia directa enlazada por texto; aun asi debe verificarse que ambientes, accesos, datos de prueba y responsables esten disponibles antes del cierre.

Riesgos y controles: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La funcionalidad no debe cerrarse como completa si faltan contrato, permisos, pruebas, auditoria o evidencia de error controlado. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Backend 2 puede coordinar la revision de Interoperabilidad Interna/Externa, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-071 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-071 (API de situación migratoria): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-071 solo si "API de situación migratoria" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con cambios de estado, consulta de historial, error controlado y bitacora completa. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-071 | Alcance | Confirmar historia o flujo operativo que resuelve API de situación migratoria en Interoperabilidad Interna/Externa; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.
PYD-071 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.
PYD-071 | Construccion | Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.
PYD-071 | Evidencia | Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.
PYD-071 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.
PYD-071 | Dependencias | Verificar que no se registren secretos ni datos personales reales en logs o evidencias; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.
PYD-071 | Seguridad | Adjuntar evidencia funcional: captura, reporte de prueba, commit, PR o demo; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.
PYD-071 | Cierre | Actualizar estado, riesgos e integraciones relacionadas en PtD; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.

PYD-082 - Implementar modelo canónico

Responsable: Integraciones | Disciplina: Integraciones | Sistema/componente: Interoperabilidad Interna/Externa | Fechas: 2026-09-07 a 2026-09-14.

Descripcion detallada

PYD-082 - Implementar modelo canónico

Objetivo PM: definir el formato comun de intercambio entre Expediente, RMH, RMI, RDVF, RMP, RNCAS, INM y COMAR.

Alcance operativo: esta tarea pertenece a H08 - H08 - Traslados e interoperabilidad base, se vincula con PYD-E3 - Construccion base del Registro de Movilidad Humana e interoperabilidad mock, impacta Interoperabilidad Interna/Externa, queda a cargo de Integraciones y esta planeada del 2026-09-07 al 2026-09-14. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: debe precisar identificadores, eventos, catalogos, payloads, versiones, errores, idempotencia y trazabilidad. Actividades principales del checklist: Definir alcance del artefacto de diseno para Implementar modelo canónico; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-082 (Implementar modelo canónico): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-082 solo si "Implementar modelo canónico" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los mocks/adaptadores pueden mapear sus datos al contrato comun. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos

Riesgos y controles: Riesgo de cerrar Implementar modelo canónico sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-082 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Integraciones puede coordinar la revision de modelo canonico de interoperabilidad para registros internos y externos, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-082 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-082 (Implementar modelo canónico): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-082 solo si "Implementar modelo canónico" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los mocks/adaptadores pueden mapear sus datos al contrato comun. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Riesgo de cerrar Implementar modelo canónico sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-082 | Alcance | Definir alcance del artefacto de diseno para Implementar modelo canónico; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
PYD-082 | Analisis | Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
PYD-082 | Construccion | Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
PYD-082 | Evidencia | Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
PYD-082 | Validacion | Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
PYD-082 | Dependencias | Registrar riesgos tecnicos y decisiones ADR cuando aplique; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
PYD-082 | Seguridad | Revisar el artefacto con arquitectura, desarrollo y QA; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
PYD-082 | Cierre | Publicar version aprobada y vincularla al entregable correspondiente; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.

PYD-090 - Bandeja principal de casos

Responsable: Frontend 1 | Disciplina: Backend | Sistema/componente: Expediente Unico NNA | Fechas: 2026-09-21 a 2026-09-28.

Descripcion detallada

PYD-090 - Bandeja principal de casos

Objetivo PM: habilitar bandejas operativas para localizar, priorizar y abrir casos con filtros utiles y rendimiento aceptable.

Alcance operativo: esta tarea pertenece a H09 - H09 - Bandejas, documentos y antiduplicados, se vincula con PYD-E3 - Construccion base del Registro de Movilidad Humana e interoperabilidad mock, impacta Expediente Unico NNA, queda a cargo de Frontend 1 y esta planeada del 2026-09-21 al 2026-09-28. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: debe cubrir columnas, filtros, paginacion, ordenamiento, permisos, estados vacios y tiempos de respuesta. Actividades principales del checklist: Confirmar historia o flujo operativo que resuelve Bandeja principal de casos en Expediente Unico NNA; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.; Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.; Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.; Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.; Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-090 (Bandeja principal de casos): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-090 solo si "Bandeja principal de casos" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con datos de prueba suficientes, filtros combinados, permisos y evidencia UX. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-003 - Infraestructura de desarrollo; DEP-PF-005 - Casos de aceptación

Riesgos y controles: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo; DEP-PF-005 - Casos de aceptación. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La funcionalidad no debe cerrarse como completa si faltan contrato, permisos, pruebas, auditoria o evidencia de error controlado. Dependencias a vigilar: DEP-DTI-003 - Infraestructura de desarrollo; DEP-PF-005 - Casos de aceptación. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Frontend 1 puede coordinar la revision de Expediente Unico NNA, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-090 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-090 (Bandeja principal de casos): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-090 solo si "Bandeja principal de casos" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con datos de prueba suficientes, filtros combinados, permisos y evidencia UX. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo; DEP-PF-005 - Casos de aceptación. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-090 | Alcance | Confirmar historia o flujo operativo que resuelve Bandeja principal de casos en Expediente Unico NNA; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
PYD-090 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
PYD-090 | Construccion | Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
PYD-090 | Evidencia | Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
PYD-090 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
PYD-090 | Dependencias | Verificar que no se registren secretos ni datos personales reales en logs o evidencias; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
PYD-090 | Seguridad | Adjuntar evidencia funcional: captura, reporte de prueba, commit, PR o demo; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
PYD-090 | Cierre | Actualizar estado, riesgos e integraciones relacionadas en PtD; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.

PYD-092 - Gestión de referencias documentales

Responsable: Backend 1 | Disciplina: Documentacion | Sistema/componente: Almacenamiento Documental | Fechas: 2026-09-23 a 2026-09-30.

Descripcion detallada

PYD-092 - Gestión de referencias documentales

Objetivo PM: organizar evidencia documental con metadatos, permisos, versionado y utilidad operativa para soporte y auditoria.

Alcance operativo: esta tarea pertenece a H09 - H09 - Bandejas, documentos y antiduplicados, se vincula con PYD-E3 - Construccion base del Registro de Movilidad Humana e interoperabilidad mock, impacta Almacenamiento Documental, queda a cargo de Backend 1 y esta planeada del 2026-09-23 al 2026-09-30. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: debe definir tipos de documento, vinculo con expediente/tarea, reglas de acceso, control de cambios y responsables. Actividades principales del checklist: Confirmar historia o flujo operativo que resuelve Gestión de referencias documentales en referencias documentales, evidencias, metadatos y permisos por expediente; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.; Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.; Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.; Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.; Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-092 (Gestión de referencias documentales): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-092 solo si "Gestión de referencias documentales" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando la evidencia puede encontrarse, abrirse y auditarse sin exponer informacion sensible. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-004 - Documentación de autenticación; DEP-INM-002 - Documentación de servicios

Riesgos y controles: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. Puede agravarse si no se atiende: DEP-DTI-004 - Documentación de autenticación; DEP-INM-002 - Documentación de servicios. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La funcionalidad no debe cerrarse como completa si faltan contrato, permisos, pruebas, auditoria o evidencia de error controlado. Dependencias a vigilar: DEP-DTI-004 - Documentación de autenticación; DEP-INM-002 - Documentación de servicios. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Backend 1 puede coordinar la revision de referencias documentales, evidencias, metadatos y permisos por expediente, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-092 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-092 (Gestión de referencias documentales): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-092 solo si "Gestión de referencias documentales" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando la evidencia puede encontrarse, abrirse y auditarse sin exponer informacion sensible. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. Puede agravarse si no se atiende: DEP-DTI-004 - Documentación de autenticación; DEP-INM-002 - Documentación de servicios. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-092 | Alcance | Confirmar historia o flujo operativo que resuelve Gestión de referencias documentales en referencias documentales, evidencias, metadatos y permisos por expediente; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
PYD-092 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
PYD-092 | Construccion | Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
PYD-092 | Evidencia | Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
PYD-092 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
PYD-092 | Dependencias | Verificar que no se registren secretos ni datos personales reales en logs o evidencias; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
PYD-092 | Seguridad | Adjuntar evidencia funcional: captura, reporte de prueba, commit, PR o demo; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
PYD-092 | Cierre | Actualizar estado, riesgos e integraciones relacionadas en PtD; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.

PYD-143 - Validar rollback

Responsable: DevOps | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2026-12-04 a 2026-12-04.

Descripcion detallada

PYD-143 - Validar rollback

Objetivo PM: mover o preparar datos con calidad verificable, conciliacion y capacidad de rollback.

Alcance operativo: esta tarea pertenece a H14 - H14 - Migracion preliminar, se vincula con PYD-E4 - Integracion, QA, seguridad y migracion preliminar, impacta Acceso Unico Institucional, queda a cargo de DevOps y esta planeada del 2026-12-04 al 2026-12-04. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: el paquete debe cubrir fuente, reglas de limpieza, rechazados, bitacora, muestras, conciliacion y rollback. Actividades principales del checklist: Confirmar fuentes, estructura, volumen, periodo y responsable de datos para Validar rollback; debe dejar evidencia trazable al hito H14, responsable asignado y fecha de cierre.; Definir reglas de limpieza, transformacion, catalogos, deduplicacion y rechazo; debe dejar evidencia trazable al hito H14, responsable asignado y fecha de cierre.; Ejecutar proceso en ambiente controlado con datos anonimizados o autorizados; debe dejar evidencia trazable al hito H14, responsable asignado y fecha de cierre.; Registrar bitacora de registros leidos, aceptados, rechazados y corregidos; debe dejar evidencia trazable al hito H14, responsable asignado y fecha de cierre.; Conciliar totales, muestras y campos criticos con responsable funcional; debe dejar evidencia trazable al hito H14, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-143 (Validar rollback): scripts, bitacora de carga, reporte de rechazados, conciliacion, muestras y rollback. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-143 solo si "Validar rollback" produce paquete de migracion con fuente, reglas, validaciones, bitacora, conciliacion y rollback; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con reporte de totales, diferencias explicadas y evidencia de recuperacion. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos

Riesgos y controles: Datos fuente incompletos, duplicados, reglas de limpieza no aprobadas o conciliacion insuficiente. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La migracion queda limitada por calidad de fuente, reglas de limpieza, disponibilidad de respaldos y autorizacion de datos. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que DevOps puede coordinar la revision de Acceso Unico Institucional, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-143 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-143 (Validar rollback): scripts, bitacora de carga, reporte de rechazados, conciliacion, muestras y rollback. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-143 solo si "Validar rollback" produce paquete de migracion con fuente, reglas, validaciones, bitacora, conciliacion y rollback; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con reporte de totales, diferencias explicadas y evidencia de recuperacion. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Datos fuente incompletos, duplicados, reglas de limpieza no aprobadas o conciliacion insuficiente. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-143 | Alcance | Confirmar fuentes, estructura, volumen, periodo y responsable de datos para Validar rollback; debe dejar evidencia trazable al hito H14, responsable asignado y fecha de cierre.
PYD-143 | Analisis | Definir reglas de limpieza, transformacion, catalogos, deduplicacion y rechazo; debe dejar evidencia trazable al hito H14, responsable asignado y fecha de cierre.
PYD-143 | Construccion | Ejecutar proceso en ambiente controlado con datos anonimizados o autorizados; debe dejar evidencia trazable al hito H14, responsable asignado y fecha de cierre.
PYD-143 | Evidencia | Registrar bitacora de registros leidos, aceptados, rechazados y corregidos; debe dejar evidencia trazable al hito H14, responsable asignado y fecha de cierre.
PYD-143 | Validacion | Conciliar totales, muestras y campos criticos con responsable funcional; debe dejar evidencia trazable al hito H14, responsable asignado y fecha de cierre.
PYD-143 | Dependencias | Documentar errores, excepciones, ajustes y plan de rollback; debe dejar evidencia trazable al hito H14, responsable asignado y fecha de cierre.
PYD-143 | Seguridad | Adjuntar scripts, reporte de ejecucion y evidencia de conciliacion; debe dejar evidencia trazable al hito H14, responsable asignado y fecha de cierre.
PYD-143 | Cierre | Actualizar semaforo de migracion y tareas afectadas; debe dejar evidencia trazable al hito H14, responsable asignado y fecha de cierre.

PYD-153 - Ejecutar pruebas de seguridad

Responsable: Seguridad | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2026-12-09 a 2026-12-11.

Descripcion detallada

PYD-153 - Ejecutar pruebas de seguridad

Objetivo PM: comprobar que Acceso Unico Institucional funciona en escenarios reales, negativos, permisos, integraciones y regresion.

Alcance operativo: esta tarea pertenece a H15 - H15 - Pruebas integrales de QA, se vincula con PYD-E4 - Integracion, QA, seguridad y migracion preliminar, impacta Acceso Unico Institucional, queda a cargo de Seguridad y esta planeada del 2026-12-09 al 2026-12-11. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: la ejecucion debe registrar casos, datos usados, evidencia, defectos, severidad y decision de avance. Actividades principales del checklist: Confirmar alcance de prueba para Ejecutar pruebas de seguridad y version del artefacto a validar; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.; Preparar casos, datos anonimizados, usuarios y ambiente; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.; Ejecutar casos positivos, negativos, permisos, datos limite y regresion aplicable; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.; Registrar defectos con pasos de reproduccion, evidencia, severidad y modulo afectado; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.; Separar defectos bloqueantes de observaciones no bloqueantes; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-153 (Ejecutar pruebas de seguridad): reporte QA, casos ejecutados, defectos, evidencia, decision QA y matriz de regresion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-153 solo si "Ejecutar pruebas de seguridad" produce reporte de pruebas con casos ejecutados, defectos, evidencias, severidad y decision de avance; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando no quedan defectos bloqueantes sin plan ni aceptacion condicionada. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-PF-007 - Usuarios para pruebas

Riesgos y controles: Defectos bloqueantes sin responsable, datos de prueba insuficientes o regresion incompleta. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-PF-007 - Usuarios para pruebas. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-153 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-PF-007 - Usuarios para pruebas. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Seguridad puede coordinar la revision de Acceso Unico Institucional, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-153 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-153 (Ejecutar pruebas de seguridad): reporte QA, casos ejecutados, defectos, evidencia, decision QA y matriz de regresion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-153 solo si "Ejecutar pruebas de seguridad" produce reporte de pruebas con casos ejecutados, defectos, evidencias, severidad y decision de avance; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando no quedan defectos bloqueantes sin plan ni aceptacion condicionada. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Defectos bloqueantes sin responsable, datos de prueba insuficientes o regresion incompleta. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-PF-007 - Usuarios para pruebas. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-153 | Alcance | Confirmar alcance de prueba para Ejecutar pruebas de seguridad y version del artefacto a validar; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
PYD-153 | Analisis | Preparar casos, datos anonimizados, usuarios y ambiente; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
PYD-153 | Construccion | Ejecutar casos positivos, negativos, permisos, datos limite y regresion aplicable; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
PYD-153 | Evidencia | Registrar defectos con pasos de reproduccion, evidencia, severidad y modulo afectado; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
PYD-153 | Validacion | Separar defectos bloqueantes de observaciones no bloqueantes; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
PYD-153 | Dependencias | Reejecutar casos corregidos y documentar resultado; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
PYD-153 | Seguridad | Emitir decision QA: aprobado, aprobado condicionado o rechazado; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
PYD-153 | Cierre | Actualizar Perfex/PtD con reporte, evidencias y riesgos; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.

PYD-154 - Ejecutar pruebas de roles y auditoría

Responsable: Seguridad | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2026-12-09 a 2026-12-11.

Descripcion detallada

PYD-154 - Ejecutar pruebas de roles y auditoría

Objetivo PM: asegurar que cada perfil acceda solo a funciones, rutas, datos y acciones autorizadas.

Alcance operativo: esta tarea pertenece a H15 - H15 - Pruebas integrales de QA, se vincula con PYD-E4 - Integracion, QA, seguridad y migracion preliminar, impacta Acceso Unico Institucional, queda a cargo de Seguridad y esta planeada del 2026-12-09 al 2026-12-11. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: debe mapear roles, permisos, rutas protegidas, acciones criticas, denegaciones y evidencia de auditoria. Actividades principales del checklist: Confirmar alcance de prueba para Ejecutar pruebas de roles y auditoría y version del artefacto a validar; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.; Preparar casos, datos anonimizados, usuarios y ambiente; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.; Ejecutar casos positivos, negativos, permisos, datos limite y regresion aplicable; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.; Registrar defectos con pasos de reproduccion, evidencia, severidad y modulo afectado; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.; Separar defectos bloqueantes de observaciones no bloqueantes; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-154 (Ejecutar pruebas de roles y auditoría): reporte QA, casos ejecutados, defectos, evidencia, decision QA y matriz de regresion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-154 solo si "Ejecutar pruebas de roles y auditoría" produce reporte de pruebas con casos ejecutados, defectos, evidencias, severidad y decision de avance; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con matriz de permisos y pruebas de acceso permitido/denegado. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-PF-003 - Roles y jerarquías; DEP-PF-007 - Usuarios para pruebas

Riesgos y controles: Defectos bloqueantes sin responsable, datos de prueba insuficientes o regresion incompleta. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-PF-003 - Roles y jerarquías; DEP-PF-007 - Usuarios para pruebas. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-154 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-PF-003 - Roles y jerarquías; DEP-PF-007 - Usuarios para pruebas. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Seguridad puede coordinar la revision de Acceso Unico Institucional, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-154 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-154 (Ejecutar pruebas de roles y auditoría): reporte QA, casos ejecutados, defectos, evidencia, decision QA y matriz de regresion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-154 solo si "Ejecutar pruebas de roles y auditoría" produce reporte de pruebas con casos ejecutados, defectos, evidencias, severidad y decision de avance; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con matriz de permisos y pruebas de acceso permitido/denegado. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Defectos bloqueantes sin responsable, datos de prueba insuficientes o regresion incompleta. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-PF-003 - Roles y jerarquías; DEP-PF-007 - Usuarios para pruebas. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-154 | Alcance | Confirmar alcance de prueba para Ejecutar pruebas de roles y auditoría y version del artefacto a validar; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
PYD-154 | Analisis | Preparar casos, datos anonimizados, usuarios y ambiente; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
PYD-154 | Construccion | Ejecutar casos positivos, negativos, permisos, datos limite y regresion aplicable; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
PYD-154 | Evidencia | Registrar defectos con pasos de reproduccion, evidencia, severidad y modulo afectado; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
PYD-154 | Validacion | Separar defectos bloqueantes de observaciones no bloqueantes; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
PYD-154 | Dependencias | Reejecutar casos corregidos y documentar resultado; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
PYD-154 | Seguridad | Emitir decision QA: aprobado, aprobado condicionado o rechazado; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
PYD-154 | Cierre | Actualizar Perfex/PtD con reporte, evidencias y riesgos; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.

PYD-180 - Preparar alcance de pentesting

Responsable: Seguridad | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2027-02-01 a 2027-02-03.

Descripcion detallada

PYD-180 - Preparar alcance de pentesting

Objetivo PM: gestionar seguridad desde alcance autorizado hasta remediacion comprobada, sin exponer evidencia sensible.

Alcance operativo: esta tarea pertenece a H18 - H18 - Pentesting y evaluacion de seguridad, se vincula con PYD-E5 - Remediacion, despliegue productivo, capacitacion y cierre, impacta Acceso Unico Institucional, queda a cargo de Seguridad y esta planeada del 2027-02-01 al 2027-02-03. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: debe cubrir hallazgos, severidad, impacto, responsable, fix, retest, excepcion y decision de liberacion. Actividades principales del checklist: Definir alcance exacto de seguridad para Preparar alcance de pentesting: modulos, endpoints, roles y datos sensibles; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.; Preparar ambiente, usuarios de prueba, ventanas de ejecucion y autorizacion formal; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.; Ejecutar pruebas o revision segun alcance: permisos, sesion, API, datos, configuracion o pentest; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.; Clasificar hallazgos por severidad, impacto, explotabilidad y evidencia; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.; Registrar plan de remediacion con responsable y fecha objetivo; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-180 (Preparar alcance de pentesting): reporte de seguridad, hallazgos, severidad, evidencia controlada, remediacion y retest. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-180 solo si "Preparar alcance de pentesting" produce reporte de seguridad con alcance, evidencia, hallazgos, severidad, plan de remediacion y retest; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los hallazgos criticos/altos quedan cerrados o formalmente exceptuados. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-PF-007 - Usuarios para pruebas

Riesgos y controles: Hallazgos criticos sin ventana de remediacion, evidencia sensible mal resguardada o retest incompleto. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-PF-007 - Usuarios para pruebas. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: Las pruebas de seguridad solo pueden ejecutarse sobre alcance autorizado, ambientes permitidos y usuarios de prueba. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-PF-007 - Usuarios para pruebas. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Seguridad puede coordinar la revision de Acceso Unico Institucional, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-180 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-180 (Preparar alcance de pentesting): reporte de seguridad, hallazgos, severidad, evidencia controlada, remediacion y retest. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-180 solo si "Preparar alcance de pentesting" produce reporte de seguridad con alcance, evidencia, hallazgos, severidad, plan de remediacion y retest; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los hallazgos criticos/altos quedan cerrados o formalmente exceptuados. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Hallazgos criticos sin ventana de remediacion, evidencia sensible mal resguardada o retest incompleto. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-PF-007 - Usuarios para pruebas. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-180 | Alcance | Definir alcance exacto de seguridad para Preparar alcance de pentesting: modulos, endpoints, roles y datos sensibles; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
PYD-180 | Analisis | Preparar ambiente, usuarios de prueba, ventanas de ejecucion y autorizacion formal; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
PYD-180 | Construccion | Ejecutar pruebas o revision segun alcance: permisos, sesion, API, datos, configuracion o pentest; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
PYD-180 | Evidencia | Clasificar hallazgos por severidad, impacto, explotabilidad y evidencia; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
PYD-180 | Validacion | Registrar plan de remediacion con responsable y fecha objetivo; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
PYD-180 | Dependencias | Validar que evidencias no incluyan secretos ni datos personales reales; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
PYD-180 | Seguridad | Ejecutar retest o definir condicion formal cuando aplique; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
PYD-180 | Cierre | Actualizar riesgos, RAID y criterio de liberacion; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.

PYD-181 - Ejecutar pentesting

Responsable: Seguridad | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2027-02-03 a 2027-02-10.

Descripcion detallada

PYD-181 - Ejecutar pentesting

Objetivo PM: gestionar seguridad desde alcance autorizado hasta remediacion comprobada, sin exponer evidencia sensible.

Alcance operativo: esta tarea pertenece a H18 - H18 - Pentesting y evaluacion de seguridad, se vincula con PYD-E5 - Remediacion, despliegue productivo, capacitacion y cierre, impacta Acceso Unico Institucional, queda a cargo de Seguridad y esta planeada del 2027-02-03 al 2027-02-10. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: debe cubrir hallazgos, severidad, impacto, responsable, fix, retest, excepcion y decision de liberacion. Actividades principales del checklist: Definir alcance exacto de seguridad para Ejecutar pentesting: modulos, endpoints, roles y datos sensibles; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.; Preparar ambiente, usuarios de prueba, ventanas de ejecucion y autorizacion formal; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.; Ejecutar pruebas o revision segun alcance: permisos, sesion, API, datos, configuracion o pentest; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.; Clasificar hallazgos por severidad, impacto, explotabilidad y evidencia; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.; Registrar plan de remediacion con responsable y fecha objetivo; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-181 (Ejecutar pentesting): reporte de seguridad, hallazgos, severidad, evidencia controlada, remediacion y retest. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-181 solo si "Ejecutar pentesting" produce reporte de seguridad con alcance, evidencia, hallazgos, severidad, plan de remediacion y retest; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los hallazgos criticos/altos quedan cerrados o formalmente exceptuados. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos

Riesgos y controles: Hallazgos criticos sin ventana de remediacion, evidencia sensible mal resguardada o retest incompleto. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: Las pruebas de seguridad solo pueden ejecutarse sobre alcance autorizado, ambientes permitidos y usuarios de prueba. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Seguridad puede coordinar la revision de Acceso Unico Institucional, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-181 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-181 (Ejecutar pentesting): reporte de seguridad, hallazgos, severidad, evidencia controlada, remediacion y retest. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-181 solo si "Ejecutar pentesting" produce reporte de seguridad con alcance, evidencia, hallazgos, severidad, plan de remediacion y retest; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los hallazgos criticos/altos quedan cerrados o formalmente exceptuados. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Hallazgos criticos sin ventana de remediacion, evidencia sensible mal resguardada o retest incompleto. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-181 | Alcance | Definir alcance exacto de seguridad para Ejecutar pentesting: modulos, endpoints, roles y datos sensibles; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
PYD-181 | Analisis | Preparar ambiente, usuarios de prueba, ventanas de ejecucion y autorizacion formal; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
PYD-181 | Construccion | Ejecutar pruebas o revision segun alcance: permisos, sesion, API, datos, configuracion o pentest; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
PYD-181 | Evidencia | Clasificar hallazgos por severidad, impacto, explotabilidad y evidencia; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
PYD-181 | Validacion | Registrar plan de remediacion con responsable y fecha objetivo; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
PYD-181 | Dependencias | Validar que evidencias no incluyan secretos ni datos personales reales; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
PYD-181 | Seguridad | Ejecutar retest o definir condicion formal cuando aplique; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
PYD-181 | Cierre | Actualizar riesgos, RAID y criterio de liberacion; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.

PYD-182 - Clasificar hallazgos

Responsable: Seguridad | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2027-02-10 a 2027-02-12.

Descripcion detallada

PYD-182 - Clasificar hallazgos

Objetivo PM: evaluar seguridad con alcance autorizado, evidencia controlada y plan de remediacion accionable.

Alcance operativo: esta tarea pertenece a H18 - H18 - Pentesting y evaluacion de seguridad, se vincula con PYD-E5 - Remediacion, despliegue productivo, capacitacion y cierre, impacta Acceso Unico Institucional, queda a cargo de Seguridad y esta planeada del 2027-02-10 al 2027-02-12. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: la prueba debe cubrir roles, sesion, APIs, configuracion, datos sensibles y hallazgos clasificados por severidad. Actividades principales del checklist: Definir alcance exacto de seguridad para Clasificar hallazgos: modulos, endpoints, roles y datos sensibles; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.; Preparar ambiente, usuarios de prueba, ventanas de ejecucion y autorizacion formal; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.; Ejecutar pruebas o revision segun alcance: permisos, sesion, API, datos, configuracion o pentest; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.; Clasificar hallazgos por severidad, impacto, explotabilidad y evidencia; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.; Registrar plan de remediacion con responsable y fecha objetivo; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-182 (Clasificar hallazgos): reporte de seguridad, hallazgos, severidad, evidencia controlada, remediacion y retest. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-182 solo si "Clasificar hallazgos" produce reporte de seguridad con alcance, evidencia, hallazgos, severidad, plan de remediacion y retest; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con reporte, plan de remediacion, retest o excepcion formal aprobada. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos

Riesgos y controles: Hallazgos criticos sin ventana de remediacion, evidencia sensible mal resguardada o retest incompleto. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: Las pruebas de seguridad solo pueden ejecutarse sobre alcance autorizado, ambientes permitidos y usuarios de prueba. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Seguridad puede coordinar la revision de gestion de hallazgos de seguridad, severidad, remediacion y retest, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-182 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-182 (Clasificar hallazgos): reporte de seguridad, hallazgos, severidad, evidencia controlada, remediacion y retest. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-182 solo si "Clasificar hallazgos" produce reporte de seguridad con alcance, evidencia, hallazgos, severidad, plan de remediacion y retest; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con reporte, plan de remediacion, retest o excepcion formal aprobada. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Hallazgos criticos sin ventana de remediacion, evidencia sensible mal resguardada o retest incompleto. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-182 | Alcance | Definir alcance exacto de seguridad para Clasificar hallazgos: modulos, endpoints, roles y datos sensibles; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
PYD-182 | Analisis | Preparar ambiente, usuarios de prueba, ventanas de ejecucion y autorizacion formal; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
PYD-182 | Construccion | Ejecutar pruebas o revision segun alcance: permisos, sesion, API, datos, configuracion o pentest; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
PYD-182 | Evidencia | Clasificar hallazgos por severidad, impacto, explotabilidad y evidencia; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
PYD-182 | Validacion | Registrar plan de remediacion con responsable y fecha objetivo; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
PYD-182 | Dependencias | Validar que evidencias no incluyan secretos ni datos personales reales; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
PYD-182 | Seguridad | Ejecutar retest o definir condicion formal cuando aplique; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
PYD-182 | Cierre | Actualizar riesgos, RAID y criterio de liberacion; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.

PYD-190 - Remediar vulnerabilidades críticas

Responsable: Backend 1 | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2027-02-15 a 2027-02-19.

Descripcion detallada

PYD-190 - Remediar vulnerabilidades críticas

Objetivo PM: gestionar seguridad desde alcance autorizado hasta remediacion comprobada, sin exponer evidencia sensible.

Alcance operativo: esta tarea pertenece a H19 - H19 - Remediacion y repruebas, se vincula con PYD-E5 - Remediacion, despliegue productivo, capacitacion y cierre, impacta Acceso Unico Institucional, queda a cargo de Backend 1 y esta planeada del 2027-02-15 al 2027-02-19. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: debe cubrir hallazgos, severidad, impacto, responsable, fix, retest, excepcion y decision de liberacion. Actividades principales del checklist: Definir alcance exacto de seguridad para Remediar vulnerabilidades críticas: modulos, endpoints, roles y datos sensibles; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.; Preparar ambiente, usuarios de prueba, ventanas de ejecucion y autorizacion formal; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.; Ejecutar pruebas o revision segun alcance: permisos, sesion, API, datos, configuracion o pentest; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.; Clasificar hallazgos por severidad, impacto, explotabilidad y evidencia; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.; Registrar plan de remediacion con responsable y fecha objetivo; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-190 (Remediar vulnerabilidades críticas): reporte de seguridad, hallazgos, severidad, evidencia controlada, remediacion y retest. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-190 solo si "Remediar vulnerabilidades críticas" produce reporte de seguridad con alcance, evidencia, hallazgos, severidad, plan de remediacion y retest; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los hallazgos criticos/altos quedan cerrados o formalmente exceptuados. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos

Riesgos y controles: Hallazgos criticos sin ventana de remediacion, evidencia sensible mal resguardada o retest incompleto. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: Las pruebas de seguridad solo pueden ejecutarse sobre alcance autorizado, ambientes permitidos y usuarios de prueba. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Backend 1 puede coordinar la revision de Acceso Unico Institucional, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-190 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-190 (Remediar vulnerabilidades críticas): reporte de seguridad, hallazgos, severidad, evidencia controlada, remediacion y retest. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-190 solo si "Remediar vulnerabilidades críticas" produce reporte de seguridad con alcance, evidencia, hallazgos, severidad, plan de remediacion y retest; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los hallazgos criticos/altos quedan cerrados o formalmente exceptuados. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Hallazgos criticos sin ventana de remediacion, evidencia sensible mal resguardada o retest incompleto. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-190 | Alcance | Definir alcance exacto de seguridad para Remediar vulnerabilidades críticas: modulos, endpoints, roles y datos sensibles; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
PYD-190 | Analisis | Preparar ambiente, usuarios de prueba, ventanas de ejecucion y autorizacion formal; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
PYD-190 | Construccion | Ejecutar pruebas o revision segun alcance: permisos, sesion, API, datos, configuracion o pentest; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
PYD-190 | Evidencia | Clasificar hallazgos por severidad, impacto, explotabilidad y evidencia; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
PYD-190 | Validacion | Registrar plan de remediacion con responsable y fecha objetivo; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
PYD-190 | Dependencias | Validar que evidencias no incluyan secretos ni datos personales reales; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
PYD-190 | Seguridad | Ejecutar retest o definir condicion formal cuando aplique; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
PYD-190 | Cierre | Actualizar riesgos, RAID y criterio de liberacion; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.

PYD-191 - Remediar vulnerabilidades altas

Responsable: Backend 1 | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2027-02-18 a 2027-02-24.

Descripcion detallada

PYD-191 - Remediar vulnerabilidades altas

Objetivo PM: gestionar seguridad desde alcance autorizado hasta remediacion comprobada, sin exponer evidencia sensible.

Alcance operativo: esta tarea pertenece a H19 - H19 - Remediacion y repruebas, se vincula con PYD-E5 - Remediacion, despliegue productivo, capacitacion y cierre, impacta Acceso Unico Institucional, queda a cargo de Backend 1 y esta planeada del 2027-02-18 al 2027-02-24. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: debe cubrir hallazgos, severidad, impacto, responsable, fix, retest, excepcion y decision de liberacion. Actividades principales del checklist: Definir alcance exacto de seguridad para Remediar vulnerabilidades altas: modulos, endpoints, roles y datos sensibles; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.; Preparar ambiente, usuarios de prueba, ventanas de ejecucion y autorizacion formal; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.; Ejecutar pruebas o revision segun alcance: permisos, sesion, API, datos, configuracion o pentest; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.; Clasificar hallazgos por severidad, impacto, explotabilidad y evidencia; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.; Registrar plan de remediacion con responsable y fecha objetivo; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-191 (Remediar vulnerabilidades altas): reporte de seguridad, hallazgos, severidad, evidencia controlada, remediacion y retest. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-191 solo si "Remediar vulnerabilidades altas" produce reporte de seguridad con alcance, evidencia, hallazgos, severidad, plan de remediacion y retest; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los hallazgos criticos/altos quedan cerrados o formalmente exceptuados. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos

Riesgos y controles: Hallazgos criticos sin ventana de remediacion, evidencia sensible mal resguardada o retest incompleto. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: Las pruebas de seguridad solo pueden ejecutarse sobre alcance autorizado, ambientes permitidos y usuarios de prueba. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Backend 1 puede coordinar la revision de Acceso Unico Institucional, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.

Regla de cierre: PYD-191 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.

Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.

Evidencia esperada: Evidencia requerida para PYD-191 (Remediar vulnerabilidades altas): reporte de seguridad, hallazgos, severidad, evidencia controlada, remediacion y retest. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-191 solo si "Remediar vulnerabilidades altas" produce reporte de seguridad con alcance, evidencia, hallazgos, severidad, plan de remediacion y retest; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los hallazgos criticos/altos quedan cerrados o formalmente exceptuados. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Hallazgos criticos sin ventana de remediacion, evidencia sensible mal resguardada o retest incompleto. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.

Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.

Integraciones relacionadas: SYS-06 - Expediente Unico NNA

Checklist de entregables

PYD-191 | Alcance | Definir alcance exacto de seguridad para Remediar vulnerabilidades altas: modulos, endpoints, roles y datos sensibles; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
PYD-191 | Analisis | Preparar ambiente, usuarios de prueba, ventanas de ejecucion y autorizacion formal; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
PYD-191 | Construccion | Ejecutar pruebas o revision segun alcance: permisos, sesion, API, datos, configuracion o pentest; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
PYD-191 | Evidencia | Clasificar hallazgos por severidad, impacto, explotabilidad y evidencia; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
PYD-191 | Validacion | Registrar plan de remediacion con responsable y fecha objetivo; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
PYD-191 | Dependencias | Validar que evidencias no incluyan secretos ni datos personales reales; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
PYD-191 | Seguridad | Ejecutar retest o definir condicion formal cuando aplique; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
PYD-191 | Cierre | Actualizar riesgos, RAID y criterio de liberacion; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.

Buscar en la base de conocimiento

SYS-06 - Expediente Unico NNA

Introduccion

Detalle

Como se espera integrar

Dependencias necesarias

Tareas vinculadas

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

Descripcion detallada

Checklist de entregables

¿Le ha resultado útil este artículo?

Articulos relacionados

Mapa maestro de integraciones del proyecto