Buscar en la base de conocimiento

Hitos, tareas y checklist aplicables a React 19

Este mapa conecta el pilar PtD Stack - React 19 con los hitos reales del proyecto. La intencion es que arquitectura, desarrollo, QA, seguridad y operacion puedan revisar que tareas tocan este frente, que checklist debe completarse y donde conviene levantar una alerta antes de cerrar el hito.

Como usar este mapa

Este articulo cruza el pilar con los 22 hitos contractuales. Cada hito muestra las tareas que deben revisarse desde este enfoque tecnico, con checklist de entregables cuando hay relacion directa. Si un hito no tiene tarea directa para el pilar, queda como punto de control transversal para no perder trazabilidad.

H01 - Este hito debe instalar el gobierno del proyecto, confirmar alcance RMH/RMI, responsables, infraestructura, RACI, RAID, cronograma, QA e interoperabilidad inicial. Su alcance operativo se concentra en Gobierno del Proyecto, Registro de Movilidad Humana, Registro de Movilidad Interna, Infraestructura DTI, QA y Certificacion, Interoperabilidad Interna/Externa, Gestion Documental y requiere coordinacion de Coordinacion, Funcional/Backend, DevOps, QA, Integraciones, Documentacion.

PYD-005 - Solicitar repositorio e infraestructura

Responsable: DevOps | Disciplina: DevOps | Sistema/componente: Infraestructura DTI | Fechas: 2026-06-16 a 2026-06-18.

Descripcion detallada

PYD-005 - Solicitar repositorio e infraestructura

Objetivo PM: habilitar repositorios, ambientes y accesos minimos para construir con trazabilidad y sin depender de archivos sueltos o credenciales compartidas.

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 Infraestructura DTI, queda a cargo de DevOps 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 solicitud debe cubrir ramas, permisos, variables, politicas de PR, ambientes y prueba basica de despliegue o ejecucion. Actividades principales del checklist: Formalizar solicitud de repositorio backend/frontend, ambientes y accesos requeridos; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Especificar ramas, politicas de PR, revisores, proteccion de rama y nomenclatura de versiones; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Solicitar infraestructura minima para desarrollo, QA y pruebas de integracion; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Confirmar mecanismos seguros para variables de entorno y secretos fuera del repositorio; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Registrar usuarios autorizados, permisos y vigencia de accesos; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-005 (Solicitar repositorio e infraestructura): solicitud formal de repositorios, ambientes, accesos, ramas, permisos y evidencias de habilitacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-005 solo si "Solicitar repositorio e infraestructura" produce solicitud formal de repositorios, ambientes, accesos, ramas, permisos y evidencias de habilitacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con evidencia de acceso y ejecucion de un artefacto minimo en el ambiente acordado. 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-DTI-008 - Infraestructura productiva

Riesgos y controles: Riesgo de cerrar Solicitar repositorio e infraestructura sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo; DEP-DTI-008 - Infraestructura productiva. 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-005 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-003 - Infraestructura de desarrollo; DEP-DTI-008 - Infraestructura productiva. 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 Infraestructura DTI, 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-005 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-005 (Solicitar repositorio e infraestructura): solicitud formal de repositorios, ambientes, accesos, ramas, permisos y evidencias de habilitacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-005 solo si "Solicitar repositorio e infraestructura" produce solicitud formal de repositorios, ambientes, accesos, ramas, permisos y evidencias de habilitacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con evidencia de acceso y ejecucion de un artefacto minimo en el ambiente acordado. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Riesgo de cerrar Solicitar repositorio e infraestructura sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo; DEP-DTI-008 - Infraestructura productiva. 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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-04 - RMP - Registro de Medidas de Proteccion, SYS-07 - Acceso Unico Institucional, SYS-09 - Gestion Documental, SYS-11 - Infraestructura DTI, SYS-12 - Repositorio Git Institucional, SYS-RMI - RMI - Registro de Movilidad Interna

Checklist de entregables

  • PYD-005 | Alcance | Formalizar solicitud de repositorio backend/frontend, ambientes y accesos requeridos; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
  • PYD-005 | Analisis | Especificar ramas, politicas de PR, revisores, proteccion de rama y nomenclatura de versiones; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
  • PYD-005 | Construccion | Solicitar infraestructura minima para desarrollo, QA y pruebas de integracion; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
  • PYD-005 | Evidencia | Confirmar mecanismos seguros para variables de entorno y secretos fuera del repositorio; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
  • PYD-005 | Validacion | Registrar usuarios autorizados, permisos y vigencia de accesos; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
  • PYD-005 | Dependencias | Adjuntar acuse o evidencia de habilitacion de repositorio/ambiente; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
  • PYD-005 | Seguridad | Validar que el equipo puede clonar, ejecutar y desplegar un artefacto minimo; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
  • PYD-005 | Cierre | Actualizar dependencia DTI y semaforo del hito segun disponibilidad real; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-007 - Crear matriz RAID inicial

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

Descripcion detallada

PYD-007 - Crear matriz RAID inicial

Objetivo PM: registrar riesgos, supuestos, incidencias y dependencias que pueden cambiar fechas, alcance, calidad o aceptacion contractual.

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: cada elemento debe tener dueno, impacto, severidad, fecha objetivo y respuesta concreta. Actividades principales del checklist: Crear registro inicial de riesgos, supuestos, issues y dependencias del proyecto; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Asignar severidad, probabilidad, impacto, dueno, fecha objetivo y semaforo; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Incluir riesgos de RMH, RMI, INM, COMAR, datos, seguridad, infraestructura y adopcion; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Definir respuesta o plan de contingencia para cada elemento critico; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Relacionar cada dependencia con hitos o tareas afectadas; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-007 (Crear matriz RAID inicial): matriz RAID inicial con riesgos, supuestos, incidencias, dependencias, dueno, severidad y fecha objetivo. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-007 solo si "Crear matriz RAID inicial" produce matriz RAID inicial con riesgos, supuestos, incidencias, dependencias, dueno, severidad y fecha objetivo; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el RAID queda publicado y conectado con las tareas o hitos afectados. 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 RAID inicial 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-007 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-007 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-007 (Crear matriz RAID inicial): matriz RAID inicial con riesgos, supuestos, incidencias, dependencias, dueno, severidad y fecha objetivo. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-007 solo si "Crear matriz RAID inicial" produce matriz RAID inicial con riesgos, supuestos, incidencias, dependencias, dueno, severidad y fecha objetivo; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el RAID queda publicado y conectado con las tareas o hitos afectados. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Riesgo de cerrar Crear matriz RAID inicial 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-01 - INM, SYS-02 - COMAR, SYS-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-04 - RMP - Registro de Medidas de Proteccion, SYS-05 - RNCAS - Registro Nacional de Centros de Asistencia Social, SYS-09 - Gestion Documental, SYS-10 - Plataforma Publica de Indicadores, SYS-11 - Infraestructura DTI, SYS-12 - Repositorio Git Institucional, SYS-RMH - RMH - Registro de Movilidad Humana, SYS-RMI - RMI - Registro de Movilidad Interna

Checklist de entregables

  • PYD-007 | Alcance | Crear registro inicial de riesgos, supuestos, issues y dependencias del proyecto; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
  • PYD-007 | Analisis | Asignar severidad, probabilidad, impacto, dueno, fecha objetivo y semaforo; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
  • PYD-007 | Construccion | Incluir riesgos de RMH, RMI, INM, COMAR, datos, seguridad, infraestructura y adopcion; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
  • PYD-007 | Evidencia | Definir respuesta o plan de contingencia para cada elemento critico; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
  • PYD-007 | Validacion | Relacionar cada dependencia con hitos o tareas afectadas; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
  • PYD-007 | Dependencias | Validar que no existan bloqueos sin dueno o fecha compromiso; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
  • PYD-007 | Seguridad | Publicar RAID en Perfex/PtD y acordar frecuencia de revision; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
  • PYD-007 | Cierre | Actualizar dashboard con semaforo inicial y pendientes de escalamiento; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.

H02 - Este hito debe levantar operacion funcional y normativa del Expediente Unico, RMH, RMI, registros internos y sistemas externos. Su alcance operativo se concentra en Expediente Unico NNA y captura inicial de identidad/datos generales, Registro de Movilidad Humana, Registro de Movilidad Interna, Acceso Unico Institucional, Gobierno de Datos, interoperabilidad con INM, interoperabilidad con COMAR, Registro del Derecho a Vivir en Familia y requiere coordinacion de Coordinacion, Funcional/Backend, Seguridad, Datos, Integraciones.

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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-06 - Expediente Unico NNA, SYS-07 - Acceso Unico Institucional, SYS-09 - Gestion Documental, SYS-10 - Plataforma Publica de Indicadores, SYS-12 - Repositorio Git Institucional

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-021 - Taller de seguimiento migratorio

Responsable: Analista funcional | Disciplina: Funcional/Backend | Sistema/componente: RMH - Registro de Movilidad Humana | Fechas: 2026-07-01 a 2026-07-02.

Descripcion detallada

PYD-021 - Taller de seguimiento migratorio

Objetivo PM: entender como se registra y actualiza la situacion migratoria del NNA, incluyendo historial, eventos, fuente, estatus y seguimiento institucional.

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 RMH - Registro de Movilidad Humana, queda a cargo de Analista funcional y esta planeada del 2026-07-01 al 2026-07-02. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: la actividad debe separar datos capturados localmente, datos esperados de INM/COMAR y reglas para modificar o consultar historial. Actividades principales del checklist: Preparar guion del taller y preguntas especificas para Registro de Movilidad Humana; 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-021 (Taller de seguimiento migratorio): 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-021 solo si "Taller de seguimiento migratorio" 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 seguimiento migratorio queda traducido a estados, eventos, permisos y evidencias. 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: Riesgo de cerrar Taller de seguimiento migratorio sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. 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-021 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-021 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-021 (Taller de seguimiento migratorio): 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-021 solo si "Taller de seguimiento migratorio" 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 seguimiento migratorio queda traducido a estados, eventos, permisos y evidencias. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Riesgo de cerrar Taller de seguimiento migratorio sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. 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-01 - INM, SYS-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-04 - RMP - Registro de Medidas de Proteccion, SYS-05 - RNCAS - Registro Nacional de Centros de Asistencia Social, SYS-09 - Gestion Documental, SYS-12 - Repositorio Git Institucional, SYS-RMH - RMH - Registro de Movilidad Humana, SYS-RMI - RMI - Registro de Movilidad Interna

Checklist de entregables

  • PYD-021 | Alcance | Preparar guion del taller y preguntas especificas para Registro de Movilidad Humana; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
  • PYD-021 | 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-021 | 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-021 | 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-021 | Validacion | Separar reglas obligatorias de preferencias de interfaz o reporteo; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
  • PYD-021 | 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-021 | 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-021 | 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-022 - Taller de ingresos, salidas y repatriaciones

Responsable: Analista funcional | Disciplina: Funcional/Backend | Sistema/componente: RMH - Registro de Movilidad Humana | Fechas: 2026-07-02 a 2026-07-03.

Descripcion detallada

PYD-022 - Taller de ingresos, salidas y repatriaciones

Objetivo PM: levantar el tratamiento operativo de ingresos al pais, salidas, repatriaciones y eventos fronterizos que alimentan RMH.

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 RMH - Registro de Movilidad Humana, queda a cargo de Analista funcional y esta planeada del 2026-07-02 al 2026-07-03. 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 precisar datos, documentos, fechas, autoridad fuente, validaciones, excepciones y conciliacion con INM. Actividades principales del checklist: Preparar guion del taller y preguntas especificas para Registro de Movilidad Humana; 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-022 (Taller de ingresos, salidas y repatriaciones): 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-022 solo si "Taller de ingresos, salidas y repatriaciones" 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 los eventos migratorios pueden mapearse a catalogos, modelo y pruebas. 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: Riesgo de cerrar Taller de ingresos, salidas y repatriaciones sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. 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-022 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-022 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-022 (Taller de ingresos, salidas y repatriaciones): 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-022 solo si "Taller de ingresos, salidas y repatriaciones" 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 los eventos migratorios pueden mapearse a catalogos, modelo y pruebas. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Riesgo de cerrar Taller de ingresos, salidas y repatriaciones sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. 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-01 - INM, SYS-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-04 - RMP - Registro de Medidas de Proteccion, SYS-05 - RNCAS - Registro Nacional de Centros de Asistencia Social, SYS-09 - Gestion Documental, SYS-12 - Repositorio Git Institucional, SYS-RMH - RMH - Registro de Movilidad Humana, SYS-RMI - RMI - Registro de Movilidad Interna

Checklist de entregables

  • PYD-022 | Alcance | Preparar guion del taller y preguntas especificas para Registro de Movilidad Humana; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
  • PYD-022 | 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-022 | 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-022 | 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-022 | Validacion | Separar reglas obligatorias de preferencias de interfaz o reporteo; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
  • PYD-022 | 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-022 | 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-022 | 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-023 - Taller de canalizaciones y traslados

Responsable: Analista funcional | Disciplina: Funcional/Backend | Sistema/componente: RMI - Registro de Movilidad Interna | Fechas: 2026-07-03 a 2026-07-06.

Descripcion detallada

PYD-023 - Taller de canalizaciones y traslados

Objetivo PM: distinguir canalizaciones migratorias de traslados internos, sus responsables, documentos, estados y relacion con RMI.

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 RMI - Registro de Movilidad Interna, queda a cargo de Analista funcional y esta planeada del 2026-07-03 al 2026-07-06. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: la sesion debe dejar claro origen, destino, motivo, autoridad responsable, evidencia y reglas para seguimiento. Actividades principales del checklist: Preparar guion del taller y preguntas especificas para Registro de Movilidad Interna; 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-023 (Taller de canalizaciones y traslados): 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-023 solo si "Taller de canalizaciones y traslados" 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 canalizacion y traslado quedan modelados como flujos separados pero interoperables. 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: Riesgo de cerrar Taller de canalizaciones y traslados sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. 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-023 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 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-023 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-023 (Taller de canalizaciones y traslados): 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-023 solo si "Taller de canalizaciones y traslados" 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 canalizacion y traslado quedan modelados como flujos separados pero interoperables. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Riesgo de cerrar Taller de canalizaciones y traslados sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. 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-01 - INM, SYS-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-04 - RMP - Registro de Medidas de Proteccion, SYS-05 - RNCAS - Registro Nacional de Centros de Asistencia Social, SYS-09 - Gestion Documental, SYS-12 - Repositorio Git Institucional, SYS-RMH - RMH - Registro de Movilidad Humana, SYS-RMI - RMI - Registro de Movilidad Interna

Checklist de entregables

  • PYD-023 | Alcance | Preparar guion del taller y preguntas especificas para Registro de Movilidad Interna; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
  • PYD-023 | 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-023 | 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-023 | 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-023 | Validacion | Separar reglas obligatorias de preferencias de interfaz o reporteo; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
  • PYD-023 | 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-023 | 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-023 | 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, SYS-07 - Acceso Unico Institucional, SYS-09 - Gestion Documental, SYS-11 - Infraestructura DTI, SYS-12 - Repositorio Git Institucional, SYS-RMI - RMI - Registro de Movilidad Interna

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-025 - Recibir y homologar catálogos

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

Descripcion detallada

PYD-025 - Recibir y homologar catálogos

Objetivo PM: homologar catalogos para que captura, interoperabilidad, reportes y migracion compartan significados consistentes.

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 Gobierno de Datos, queda a cargo de Datos y esta planeada del 2026-07-01 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 trabajo debe documentar fuente, dueno, version, equivalencias, vigencia y reglas de cambio. Actividades principales del checklist: Recibir catalogos fuente con version, responsable, fecha y alcance de uso; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Comparar catalogos contra RMH, RMI, RDVF, RMP, RNCAS e integraciones externas; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Homologar nombres, claves, vigencia, equivalencias y valores obsoletos; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Documentar reglas de alta, baja, modificacion y aprobacion de catalogos; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Definir impacto en modelo de datos, formularios, APIs y reportes; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-025 (Recibir y homologar catálogos): catalogos homologados con fuente, dueno, vigencia, equivalencias y reglas de cambio. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-025 solo si "Recibir y homologar catálogos" produce catalogos homologados con fuente, dueno, vigencia, equivalencias y reglas de cambio; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con catalogos versionados y reglas de conciliacion aprobadas. 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-004 - Catálogos y ejemplos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-PF-004 - Catálogos; DEP-RDVF-002 - Modelo de datos

Riesgos y controles: Riesgo de cerrar Recibir y homologar catálogos 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-004 - Catálogos y ejemplos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-PF-004 - Catálogos; DEP-RDVF-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-025 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-007 - Acceso a datos históricos; DEP-INM-004 - Catálogos y ejemplos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-PF-004 - Catálogos; DEP-RDVF-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-025 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-025 (Recibir y homologar catálogos): catalogos homologados con fuente, dueno, vigencia, equivalencias y reglas de cambio. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-025 solo si "Recibir y homologar catálogos" produce catalogos homologados con fuente, dueno, vigencia, equivalencias y reglas de cambio; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con catalogos versionados y reglas de conciliacion aprobadas. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Riesgo de cerrar Recibir y homologar catálogos 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-004 - Catálogos y ejemplos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-PF-004 - Catálogos; DEP-RDVF-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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-04 - RMP - Registro de Medidas de Proteccion, SYS-05 - RNCAS - Registro Nacional de Centros de Asistencia Social, SYS-09 - Gestion Documental, SYS-10 - Plataforma Publica de Indicadores, SYS-12 - Repositorio Git Institucional, SYS-RMH - RMH - Registro de Movilidad Humana, SYS-RMI - RMI - Registro de Movilidad Interna

Checklist de entregables

  • PYD-025 | Alcance | Recibir catalogos fuente con version, responsable, fecha y alcance de uso; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
  • PYD-025 | Analisis | Comparar catalogos contra RMH, RMI, RDVF, RMP, RNCAS e integraciones externas; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
  • PYD-025 | Construccion | Homologar nombres, claves, vigencia, equivalencias y valores obsoletos; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
  • PYD-025 | Evidencia | Documentar reglas de alta, baja, modificacion y aprobacion de catalogos; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
  • PYD-025 | Validacion | Definir impacto en modelo de datos, formularios, APIs y reportes; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
  • PYD-025 | Dependencias | Identificar valores pendientes o ambiguos para resolucion funcional; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
  • PYD-025 | Seguridad | Preparar archivo o script de carga controlada sin datos personales reales; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
  • PYD-025 | Cierre | Publicar catalogo versionado y evidencia de aprobacion; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.

H03 - Este hito debe cerrar requisitos no funcionales medibles de rendimiento, seguridad, auditoria, privacidad, disponibilidad y continuidad. Su alcance operativo se concentra en QA y Certificacion, Acceso Unico Institucional y requiere coordinacion de QA, Seguridad.

Control transversal: no hay tarea directa con este pilar, pero el hito debe conservar evidencia, trazabilidad, control de cambios y validacion de impacto si toca datos, servicios o integraciones relacionadas.

H04 - Este hito debe definir arquitectura C4, modelo de datos, modelo canonico, catalogos, OpenAPI y gobierno de interoperabilidad. Su alcance operativo se concentra en arquitectura C4 de contexto institucional, actores, registros y sistemas externos, contenedores backend, frontend, datos, integraciones y servicios transversales, FastAPI / API Gateway, Frontend React 19, rutas, estado, componentes y UX operativa, modelo relacional PostgreSQL para Expediente, RMH, RMI e interoperabilidad, Gobierno de Datos, Interoperabilidad Interna/Externa, paquete formal de arquitectura, analisis funcional y modelo de datos y requiere coordinacion de Arquitectura, Backend/Arquitectura, Frontend, Datos, Integraciones, Documentacion.

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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-06 - Expediente Unico NNA, SYS-07 - Acceso Unico Institucional, SYS-09 - Gestion Documental, SYS-10 - Plataforma Publica de Indicadores, SYS-11 - Infraestructura DTI, SYS-12 - Repositorio Git Institucional, SYS-RMH - RMH - Registro de Movilidad Humana, SYS-RMI - RMI - Registro de Movilidad Interna

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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-06 - Expediente Unico NNA, SYS-07 - Acceso Unico Institucional, SYS-09 - Gestion Documental, SYS-10 - Plataforma Publica de Indicadores, SYS-11 - Infraestructura DTI, SYS-12 - Repositorio Git Institucional, SYS-RMH - RMH - Registro de Movilidad Humana, SYS-RMI - RMI - Registro de Movilidad Interna

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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-06 - Expediente Unico NNA, SYS-07 - Acceso Unico Institucional, SYS-09 - Gestion Documental, SYS-10 - Plataforma Publica de Indicadores, SYS-11 - Infraestructura DTI, SYS-12 - Repositorio Git Institucional, SYS-RMH - RMH - Registro de Movilidad Humana, SYS-RMI - RMI - Registro de Movilidad Interna

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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-06 - Expediente Unico NNA, SYS-07 - Acceso Unico Institucional, SYS-09 - Gestion Documental, SYS-10 - Plataforma Publica de Indicadores, SYS-11 - Infraestructura DTI, SYS-12 - Repositorio Git Institucional, SYS-RMH - RMH - Registro de Movilidad Humana, SYS-RMI - RMI - Registro de Movilidad Interna

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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-06 - Expediente Unico NNA, SYS-07 - Acceso Unico Institucional, SYS-09 - Gestion Documental, SYS-10 - Plataforma Publica de Indicadores, SYS-11 - Infraestructura DTI, SYS-12 - Repositorio Git Institucional, SYS-RMH - RMH - Registro de Movilidad Humana, SYS-RMI - RMI - Registro de Movilidad Interna

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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-06 - Expediente Unico NNA, SYS-07 - Acceso Unico Institucional, SYS-09 - Gestion Documental, SYS-10 - Plataforma Publica de Indicadores, SYS-11 - Infraestructura DTI, SYS-12 - Repositorio Git Institucional, SYS-RMH - RMH - Registro de Movilidad Humana, SYS-RMI - RMI - Registro de Movilidad Interna

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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-06 - Expediente Unico NNA, SYS-07 - Acceso Unico Institucional, SYS-09 - Gestion Documental, SYS-10 - Plataforma Publica de Indicadores, SYS-11 - Infraestructura DTI, SYS-12 - Repositorio Git Institucional, SYS-RMH - RMH - Registro de Movilidad Humana, SYS-RMI - RMI - Registro de Movilidad Interna

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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-06 - Expediente Unico NNA, SYS-07 - Acceso Unico Institucional, SYS-09 - Gestion Documental, SYS-10 - Plataforma Publica de Indicadores, SYS-11 - Infraestructura DTI, SYS-12 - Repositorio Git Institucional, SYS-RMH - RMH - Registro de Movilidad Humana, SYS-RMI - RMI - Registro de Movilidad Interna

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.

H05 - Este hito debe preparar repositorios, proyectos base, PostgreSQL, pruebas, pipeline, logging y health checks. Su alcance operativo se concentra en Infraestructura DTI, Frontend React / UI Operativa, Interoperabilidad Interna/Externa, Frontend React 19 con Vite, PNPM, estructura de componentes y convenciones, PostgreSQL, migraciones iniciales, esquemas y convenciones de datos, QA y Certificacion, pruebas frontend con Jest, React Testing Library y datos de prueba, pipeline CI/CD, validaciones automaticas y control de calidad y requiere coordinacion de DevOps, Frontend, Integraciones, Datos, QA.

PYD-051 - Configurar repositorio frontend

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

Descripcion detallada

PYD-051 - Configurar repositorio frontend

Objetivo PM: preparar la base tecnica de Frontend React / UI Operativa para que el equipo pueda desarrollar, probar y desplegar de forma repetible.

Alcance operativo: esta tarea pertenece a H05 - H05 - Preparacion tecnica y Sprint 0, se vincula con PYD-E3 - Construccion base del Registro de Movilidad Humana e interoperabilidad mock, impacta Frontend React / UI Operativa, queda a cargo de Frontend 1 y esta planeada del 2026-07-28 al 2026-07-30. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: la configuracion debe incluir comandos, variables no secretas, pruebas iniciales, health check, logging o pipeline segun aplique. Actividades principales del checklist: Crear o ajustar estructura base del componente relacionado con Configurar repositorio frontend; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.; Documentar comandos de instalacion, ejecucion, pruebas y variables no secretas; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.; Configurar dependencias, convenciones, linting/formato o estructura de carpetas segun aplique; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.; Agregar prueba o verificacion minima que confirme que el componente arranca; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.; Configurar manejo de ambiente sin credenciales en repositorio; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-051 (Configurar repositorio frontend): componente base configurado con README, comandos, variables no secretas, pruebas iniciales y pipeline o evidencia local. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-051 solo si "Configurar repositorio frontend" produce componente base configurado con README, comandos, variables no secretas, pruebas iniciales y pipeline o evidencia local; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con ejecucion reproducible y evidencia de ambiente o pipeline. 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 Configurar repositorio frontend 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-051 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 Frontend 1 puede coordinar la revision de Frontend React / UI 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-051 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-051 (Configurar repositorio frontend): componente base configurado con README, comandos, variables no secretas, pruebas iniciales y pipeline o evidencia local. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-051 solo si "Configurar repositorio frontend" produce componente base configurado con README, comandos, variables no secretas, pruebas iniciales y pipeline o evidencia local; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con ejecucion reproducible y evidencia de ambiente o pipeline. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Riesgo de cerrar Configurar repositorio frontend 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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-09 - Gestion Documental, SYS-11 - Infraestructura DTI, SYS-12 - Repositorio Git Institucional

Checklist de entregables

  • PYD-051 | Alcance | Crear o ajustar estructura base del componente relacionado con Configurar repositorio frontend; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.
  • PYD-051 | Analisis | Documentar comandos de instalacion, ejecucion, pruebas y variables no secretas; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.
  • PYD-051 | Construccion | Configurar dependencias, convenciones, linting/formato o estructura de carpetas segun aplique; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.
  • PYD-051 | Evidencia | Agregar prueba o verificacion minima que confirme que el componente arranca; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.
  • PYD-051 | Validacion | Configurar manejo de ambiente sin credenciales en repositorio; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.
  • PYD-051 | Dependencias | Registrar evidencia: captura, log, pipeline, commit o resultado de prueba; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.
  • PYD-051 | Seguridad | Actualizar README o guia tecnica con pasos reproducibles; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.
  • PYD-051 | Cierre | Vincular repositorio/rama/commit o evidencia en Perfex/PtD; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.
PYD-053 - Crear proyecto base React 19/Vite/PNPM

Responsable: Frontend 1 | Disciplina: Frontend | Sistema/componente: Frontend React / UI Operativa | Fechas: 2026-07-29 a 2026-08-04.

Descripcion detallada

PYD-053 - Crear proyecto base React 19/Vite/PNPM

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 H05 - H05 - Preparacion tecnica y Sprint 0, se vincula con PYD-E3 - Construccion base del Registro de Movilidad Humana e interoperabilidad mock, impacta Frontend React / UI Operativa, queda a cargo de Frontend 1 y esta planeada del 2026-07-29 al 2026-08-04. 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: Crear o ajustar estructura base del componente relacionado con Crear proyecto base React 19/Vite/PNPM; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.; Documentar comandos de instalacion, ejecucion, pruebas y variables no secretas; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.; Configurar dependencias, convenciones, linting/formato o estructura de carpetas segun aplique; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.; Agregar prueba o verificacion minima que confirme que el componente arranca; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.; Configurar manejo de ambiente sin credenciales en repositorio; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-053 (Crear proyecto base React 19/Vite/PNPM): componente base configurado con README, comandos, variables no secretas, pruebas iniciales y pipeline o evidencia local. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-053 solo si "Crear proyecto base React 19/Vite/PNPM" produce componente base configurado con README, comandos, variables no secretas, pruebas iniciales y pipeline o evidencia local; 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: 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 proyecto base React 19/Vite/PNPM 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-053 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 Frontend 1 puede coordinar la revision de Frontend React 19 con Vite, PNPM, estructura de componentes y convenciones, 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-053 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-053 (Crear proyecto base React 19/Vite/PNPM): componente base configurado con README, comandos, variables no secretas, pruebas iniciales y pipeline o evidencia local. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-053 solo si "Crear proyecto base React 19/Vite/PNPM" produce componente base configurado con README, comandos, variables no secretas, pruebas iniciales y pipeline o evidencia local; 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 Crear proyecto base React 19/Vite/PNPM 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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-09 - Gestion Documental, SYS-11 - Infraestructura DTI, SYS-12 - Repositorio Git Institucional, SYS-RMI - RMI - Registro de Movilidad Interna

Checklist de entregables

  • PYD-053 | Alcance | Crear o ajustar estructura base del componente relacionado con Crear proyecto base React 19/Vite/PNPM; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.
  • PYD-053 | Analisis | Documentar comandos de instalacion, ejecucion, pruebas y variables no secretas; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.
  • PYD-053 | Construccion | Configurar dependencias, convenciones, linting/formato o estructura de carpetas segun aplique; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.
  • PYD-053 | Evidencia | Agregar prueba o verificacion minima que confirme que el componente arranca; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.
  • PYD-053 | Validacion | Configurar manejo de ambiente sin credenciales en repositorio; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.
  • PYD-053 | Dependencias | Registrar evidencia: captura, log, pipeline, commit o resultado de prueba; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.
  • PYD-053 | Seguridad | Actualizar README o guia tecnica con pasos reproducibles; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.
  • PYD-053 | Cierre | Vincular repositorio/rama/commit o evidencia en Perfex/PtD; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.
PYD-056 - Configurar Jest y React Testing Library

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

Descripcion detallada

PYD-056 - Configurar Jest y React Testing Library

Objetivo PM: preparar la base tecnica de pruebas frontend con Jest, React Testing Library y datos de prueba para que el equipo pueda desarrollar, probar y desplegar de forma repetible.

Alcance operativo: esta tarea pertenece a H05 - H05 - Preparacion tecnica y Sprint 0, se vincula con PYD-E3 - Construccion base del Registro de Movilidad Humana e interoperabilidad mock, impacta QA y Certificacion, queda a cargo de QA y esta planeada del 2026-08-03 al 2026-08-06. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: la configuracion debe incluir comandos, variables no secretas, pruebas iniciales, health check, logging o pipeline segun aplique. Actividades principales del checklist: Crear o ajustar estructura base del componente relacionado con Configurar Jest y React Testing Library; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.; Documentar comandos de instalacion, ejecucion, pruebas y variables no secretas; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.; Configurar dependencias, convenciones, linting/formato o estructura de carpetas segun aplique; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.; Agregar prueba o verificacion minima que confirme que el componente arranca; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.; Configurar manejo de ambiente sin credenciales en repositorio; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-056 (Configurar Jest y React Testing Library): componente base configurado con README, comandos, variables no secretas, pruebas iniciales y pipeline o evidencia local. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-056 solo si "Configurar Jest y React Testing Library" produce componente base configurado con README, comandos, variables no secretas, pruebas iniciales y pipeline o evidencia local; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con ejecucion reproducible y evidencia de ambiente o pipeline. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Dependencias y coordinacion: DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-INM-006 - Ventana de certificación; DEP-INM-007 - Certificación QA; DEP-PF-007 - Usuarios para pruebas; DEP-RDVF-007 - Certificacion

Riesgos y controles: Riesgo de cerrar Configurar Jest y React Testing Library sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-INM-006 - Ventana de certificación; DEP-INM-007 - Certificación QA; DEP-PF-007 - Usuarios para pruebas; DEP-RDVF-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-056 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-INM-006 - Ventana de certificación; DEP-INM-007 - Certificación QA; DEP-PF-007 - Usuarios para pruebas; DEP-RDVF-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 pruebas frontend con Jest, React Testing Library y datos de prueba, 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-056 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-056 (Configurar Jest y React Testing Library): componente base configurado con README, comandos, variables no secretas, pruebas iniciales y pipeline o evidencia local. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-056 solo si "Configurar Jest y React Testing Library" produce componente base configurado con README, comandos, variables no secretas, pruebas iniciales y pipeline o evidencia local; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con ejecucion reproducible y evidencia de ambiente o pipeline. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Riesgo de cerrar Configurar Jest y React Testing Library sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-INM-006 - Ventana de certificación; DEP-INM-007 - Certificación QA; DEP-PF-007 - Usuarios para pruebas; DEP-RDVF-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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-09 - Gestion Documental, SYS-11 - Infraestructura DTI, SYS-12 - Repositorio Git Institucional

Checklist de entregables

  • PYD-056 | Alcance | Crear o ajustar estructura base del componente relacionado con Configurar Jest y React Testing Library; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.
  • PYD-056 | Analisis | Documentar comandos de instalacion, ejecucion, pruebas y variables no secretas; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.
  • PYD-056 | Construccion | Configurar dependencias, convenciones, linting/formato o estructura de carpetas segun aplique; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.
  • PYD-056 | Evidencia | Agregar prueba o verificacion minima que confirme que el componente arranca; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.
  • PYD-056 | Validacion | Configurar manejo de ambiente sin credenciales en repositorio; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.
  • PYD-056 | Dependencias | Registrar evidencia: captura, log, pipeline, commit o resultado de prueba; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.
  • PYD-056 | Seguridad | Actualizar README o guia tecnica con pasos reproducibles; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.
  • PYD-056 | Cierre | Vincular repositorio/rama/commit o evidencia en Perfex/PtD; debe dejar evidencia trazable al hito H05, responsable asignado y fecha de cierre.

H06 - Este hito debe construir Expediente Unico NNA, identidad, datos generales, OAuth2/JWT, RBAC, proteccion de rutas y auditoria inicial. Su alcance operativo se concentra en Expediente Unico NNA, busqueda, filtros, permisos y auditoria, Expediente Unico NNA, Gobierno de Datos, Acceso Unico Institucional con OAuth2/JWT, sesiones y tokens, Acceso Unico Institucional, proteccion de rutas React integrada con RBAC y sesion institucional, QA y Certificacion y requiere coordinacion de Backend, Datos, Seguridad, Frontend/Seguridad, QA.

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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-06 - Expediente Unico NNA, SYS-07 - Acceso Unico Institucional, SYS-09 - Gestion Documental, SYS-12 - Repositorio Git Institucional, SYS-RMI - RMI - Registro de Movilidad Interna

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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-06 - Expediente Unico NNA, SYS-07 - Acceso Unico Institucional, SYS-09 - Gestion Documental, SYS-12 - Repositorio Git Institucional, SYS-RMI - RMI - Registro de Movilidad Interna

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-062 - Crear formularios de datos generales

Responsable: Frontend 1 | Disciplina: Datos | Sistema/componente: Gobierno de Datos | Fechas: 2026-08-10 a 2026-08-18.

Descripcion detallada

PYD-062 - Crear formularios de datos generales

Objetivo PM: implementar Crear formularios de datos generales dentro de Gobierno de Datos 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 Gobierno de Datos, queda a cargo de Frontend 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: 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 Crear formularios de datos generales en Gobierno de Datos; 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-062 (Crear formularios de datos generales): 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-062 solo si "Crear formularios de datos generales" 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-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-PF-001 - Procesos y formularios; DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos

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-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-PF-001 - Procesos y formularios; DEP-RDVF-002 - Modelo de datos; DEP-RMP-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: La funcionalidad no debe cerrarse como completa si faltan contrato, permisos, pruebas, auditoria o evidencia de error controlado. Dependencias a vigilar: DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-PF-001 - Procesos y formularios; DEP-RDVF-002 - Modelo de datos; DEP-RMP-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 Frontend 1 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-062 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-062 (Crear formularios de datos generales): 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-062 solo si "Crear formularios de datos generales" 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-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-PF-001 - Procesos y formularios; DEP-RDVF-002 - Modelo de datos; DEP-RMP-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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-09 - Gestion Documental, SYS-12 - Repositorio Git Institucional, SYS-RMI - RMI - Registro de Movilidad Interna

Checklist de entregables

  • PYD-062 | Alcance | Confirmar historia o flujo operativo que resuelve Crear formularios de datos generales en Gobierno de Datos; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
  • PYD-062 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
  • PYD-062 | 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-062 | 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-062 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
  • PYD-062 | 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-062 | 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-062 | 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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-06 - Expediente Unico NNA, SYS-07 - Acceso Unico Institucional, SYS-09 - Gestion Documental, SYS-12 - Repositorio Git Institucional, SYS-RMI - RMI - Registro de Movilidad Interna

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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-06 - Expediente Unico NNA, SYS-07 - Acceso Unico Institucional, SYS-09 - Gestion Documental, SYS-12 - Repositorio Git Institucional, SYS-RMI - RMI - Registro de Movilidad Interna

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-065 - Implementar protección de rutas React

Responsable: Frontend 1 | Disciplina: Frontend/Seguridad | Sistema/componente: Frontend React / UI Operativa | Fechas: 2026-08-17 a 2026-08-20.

Descripcion detallada

PYD-065 - Implementar protección de rutas React

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 Frontend React / UI Operativa, queda a cargo de Frontend 1 y esta planeada del 2026-08-17 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 protección de rutas React en proteccion de rutas React integrada con RBAC y sesion 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-065 (Implementar protección de rutas React): 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-065 solo si "Implementar protección de rutas React" 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: 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 Frontend 1 puede coordinar la revision de proteccion de rutas React integrada con RBAC y sesion 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-065 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-065 (Implementar protección de rutas React): 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-065 solo si "Implementar protección de rutas React" 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. 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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-04 - RMP - Registro de Medidas de Proteccion, SYS-07 - Acceso Unico Institucional, SYS-09 - Gestion Documental, SYS-12 - Repositorio Git Institucional, SYS-RMI - RMI - Registro de Movilidad Interna

Checklist de entregables

  • PYD-065 | Alcance | Confirmar historia o flujo operativo que resuelve Implementar protección de rutas React en proteccion de rutas React integrada con RBAC y sesion institucional; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
  • PYD-065 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
  • PYD-065 | 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-065 | 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-065 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
  • PYD-065 | 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-065 | 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-065 | 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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-06 - Expediente Unico NNA, SYS-07 - Acceso Unico Institucional, SYS-09 - Gestion Documental, SYS-12 - Repositorio Git Institucional, SYS-RMI - RMI - Registro de Movilidad Interna

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.

H07 - Este hito debe implementar Registro de Movilidad Humana con alta de caso, situacion migratoria, seguimiento y canalizaciones. Su alcance operativo se concentra en Registro de Movilidad Humana, Interoperabilidad Interna/Externa, Frontend React / UI Operativa, Registro de Movilidad Interna, QA y Certificacion y requiere coordinacion de Funcional/Backend, Integraciones, Frontend, QA.

PYD-070 - API de alta de caso RMH

Responsable: Backend 1 | Disciplina: Funcional/Backend | Sistema/componente: RMH - Registro de Movilidad Humana | Fechas: 2026-08-24 a 2026-08-28.

Descripcion detallada

PYD-070 - API de alta de caso RMH

Objetivo PM: implementar el endpoint para crear caso RMH con datos migratorios iniciales, validaciones, permisos y trazabilidad hacia Expediente Unico.

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 RMH - Registro de Movilidad Humana, queda a cargo de Backend 1 y esta planeada del 2026-08-24 al 2026-08-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 validar payload, catalogos, duplicados, errores de negocio, auditoria y respuesta consistente con OpenAPI. Actividades principales del checklist: Confirmar historia o flujo operativo que resuelve API de alta de caso RMH en Registro de Movilidad Humana; 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-070 (API de alta de caso RMH): 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-070 solo si "API de alta de caso RMH" 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 alta exitosa, payload incompleto, permiso insuficiente, duplicado 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; DEP-INM-001 - Enlace técnico y funcional

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-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: 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-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 Backend 1 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-070 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-070 (API de alta de caso RMH): 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-070 solo si "API de alta de caso RMH" 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 alta exitosa, payload incompleto, permiso insuficiente, duplicado 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; 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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-04 - RMP - Registro de Medidas de Proteccion, SYS-05 - RNCAS - Registro Nacional de Centros de Asistencia Social, SYS-09 - Gestion Documental, SYS-12 - Repositorio Git Institucional, SYS-RMH - RMH - Registro de Movilidad Humana, SYS-RMI - RMI - Registro de Movilidad Interna

Checklist de entregables

  • PYD-070 | Alcance | Confirmar historia o flujo operativo que resuelve API de alta de caso RMH en Registro de Movilidad Humana; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.
  • PYD-070 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.
  • PYD-070 | 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-070 | 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-070 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.
  • PYD-070 | 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-070 | 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-070 | Cierre | Actualizar estado, riesgos e integraciones relacionadas en PtD; debe dejar evidencia trazable al hito H07, 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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-06 - Expediente Unico NNA, SYS-09 - Gestion Documental, SYS-12 - Repositorio Git Institucional, SYS-RMI - RMI - Registro de Movilidad Interna

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-072 - API de seguimiento migratorio

Responsable: Backend 2 | Disciplina: Funcional/Backend | Sistema/componente: RMH - Registro de Movilidad Humana | Fechas: 2026-08-28 a 2026-09-02.

Descripcion detallada

PYD-072 - API de seguimiento migratorio

Objetivo PM: entender como se registra y actualiza la situacion migratoria del NNA, incluyendo historial, eventos, fuente, estatus y seguimiento institucional.

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 RMH - Registro de Movilidad Humana, queda a cargo de Backend 2 y esta planeada del 2026-08-28 al 2026-09-02. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: la actividad debe separar datos capturados localmente, datos esperados de INM/COMAR y reglas para modificar o consultar historial. Actividades principales del checklist: Confirmar historia o flujo operativo que resuelve API de seguimiento migratorio en Registro de Movilidad Humana; 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-072 (API de seguimiento migratorio): 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-072 solo si "API de seguimiento migratorio" 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 el seguimiento migratorio queda traducido a estados, eventos, permisos y evidencias. 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: 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-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: 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-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 Backend 2 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-072 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-072 (API de seguimiento migratorio): 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-072 solo si "API de seguimiento migratorio" 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 el seguimiento migratorio queda traducido a estados, eventos, permisos y evidencias. 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-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-01 - INM, SYS-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-04 - RMP - Registro de Medidas de Proteccion, SYS-05 - RNCAS - Registro Nacional de Centros de Asistencia Social, SYS-09 - Gestion Documental, SYS-12 - Repositorio Git Institucional, SYS-RMH - RMH - Registro de Movilidad Humana, SYS-RMI - RMI - Registro de Movilidad Interna

Checklist de entregables

  • PYD-072 | Alcance | Confirmar historia o flujo operativo que resuelve API de seguimiento migratorio en Registro de Movilidad Humana; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.
  • PYD-072 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.
  • PYD-072 | 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-072 | 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-072 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.
  • PYD-072 | 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-072 | 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-072 | Cierre | Actualizar estado, riesgos e integraciones relacionadas en PtD; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.
PYD-073 - Interfaz de alta de caso

Responsable: Frontend 1 | Disciplina: Frontend | Sistema/componente: Frontend React / UI Operativa | Fechas: 2026-08-24 a 2026-09-01.

Descripcion detallada

PYD-073 - Interfaz de alta de caso

Objetivo PM: construir interfaz operativa para capturar y dar seguimiento a casos sin perder validaciones, estados ni evidencia.

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 Frontend React / UI Operativa, queda a cargo de Frontend 1 y esta planeada del 2026-08-24 al 2026-09-01. 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 formularios, mensajes de error, guardado, consulta, permisos, accesibilidad y estados de carga. Actividades principales del checklist: Confirmar historia o flujo operativo que resuelve Interfaz de alta de caso en Frontend React / UI Operativa; 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-073 (Interfaz de alta de caso): 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-073 solo si "Interfaz de alta de caso" 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 flujo completo de usuario, casos negativos, responsive basico y evidencia visual. 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 Frontend 1 puede coordinar la revision de Frontend React / UI 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-073 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-073 (Interfaz de alta de caso): 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-073 solo si "Interfaz de alta de caso" 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 flujo completo de usuario, casos negativos, responsive basico y evidencia visual. 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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-09 - Gestion Documental, SYS-12 - Repositorio Git Institucional, SYS-RMI - RMI - Registro de Movilidad Interna

Checklist de entregables

  • PYD-073 | Alcance | Confirmar historia o flujo operativo que resuelve Interfaz de alta de caso en Frontend React / UI Operativa; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.
  • PYD-073 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.
  • PYD-073 | 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-073 | 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-073 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.
  • PYD-073 | 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-073 | 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-073 | Cierre | Actualizar estado, riesgos e integraciones relacionadas en PtD; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.
PYD-074 - Interfaz de seguimiento

Responsable: Frontend 2 | Disciplina: Funcional/Backend | Sistema/componente: RMI - Registro de Movilidad Interna | Fechas: 2026-08-28 a 2026-09-03.

Descripcion detallada

PYD-074 - Interfaz de seguimiento

Objetivo PM: construir interfaz operativa para capturar y dar seguimiento a casos sin perder validaciones, estados ni evidencia.

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 RMI - Registro de Movilidad Interna, queda a cargo de Frontend 2 y esta planeada del 2026-08-28 al 2026-09-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 formularios, mensajes de error, guardado, consulta, permisos, accesibilidad y estados de carga. Actividades principales del checklist: Confirmar historia o flujo operativo que resuelve Interfaz de seguimiento en Registro de Movilidad Interna; 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-074 (Interfaz de seguimiento): 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-074 solo si "Interfaz de seguimiento" 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 flujo completo de usuario, casos negativos, responsive basico y evidencia visual. 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: 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-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: 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-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 Frontend 2 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-074 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-074 (Interfaz de seguimiento): 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-074 solo si "Interfaz de seguimiento" 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 flujo completo de usuario, casos negativos, responsive basico y evidencia visual. 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-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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-04 - RMP - Registro de Medidas de Proteccion, SYS-05 - RNCAS - Registro Nacional de Centros de Asistencia Social, SYS-09 - Gestion Documental, SYS-12 - Repositorio Git Institucional, SYS-RMH - RMH - Registro de Movilidad Humana, SYS-RMI - RMI - Registro de Movilidad Interna

Checklist de entregables

  • PYD-074 | Alcance | Confirmar historia o flujo operativo que resuelve Interfaz de seguimiento en Registro de Movilidad Interna; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.
  • PYD-074 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.
  • PYD-074 | 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-074 | 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-074 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.
  • PYD-074 | 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-074 | 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-074 | Cierre | Actualizar estado, riesgos e integraciones relacionadas en PtD; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.
PYD-075 - API e interfaz de canalizaciones

Responsable: Backend 1 | Disciplina: Funcional/Backend | Sistema/componente: RMI - Registro de Movilidad Interna | Fechas: 2026-08-31 a 2026-09-04.

Descripcion detallada

PYD-075 - API e interfaz de canalizaciones

Objetivo PM: implementar canalizaciones con API e interfaz para registrar destino, motivo, autoridad, documentos y seguimiento.

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 RMI - Registro de Movilidad Interna, queda a cargo de Backend 1 y esta planeada del 2026-08-31 al 2026-09-04. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: debe mantener consistencia entre RMH, RMI y Expediente, incluyendo estados, permisos, evidencia y auditoria. Actividades principales del checklist: Confirmar historia o flujo operativo que resuelve API e interfaz de canalizaciones en Registro de Movilidad Interna; 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-075 (API e interfaz de canalizaciones): 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-075 solo si "API e interfaz de canalizaciones" 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 canalizacion creada, actualizada, consultada y auditada. 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: 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-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: 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-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 Backend 1 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-075 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-075 (API e interfaz de canalizaciones): 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-075 solo si "API e interfaz de canalizaciones" 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 canalizacion creada, actualizada, consultada y auditada. 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-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-01 - INM, SYS-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-04 - RMP - Registro de Medidas de Proteccion, SYS-05 - RNCAS - Registro Nacional de Centros de Asistencia Social, SYS-09 - Gestion Documental, SYS-12 - Repositorio Git Institucional, SYS-RMH - RMH - Registro de Movilidad Humana, SYS-RMI - RMI - Registro de Movilidad Interna

Checklist de entregables

  • PYD-075 | Alcance | Confirmar historia o flujo operativo que resuelve API e interfaz de canalizaciones en Registro de Movilidad Interna; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.
  • PYD-075 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.
  • PYD-075 | 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-075 | 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-075 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.
  • PYD-075 | 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-075 | 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-075 | Cierre | Actualizar estado, riesgos e integraciones relacionadas en PtD; debe dejar evidencia trazable al hito H07, responsable asignado y fecha de cierre.

H08 - Este hito debe implementar Movilidad Interna, modelo canonico, mocks de interoperabilidad, outbox, reintentos e idempotencia. Su alcance operativo se concentra en Registro de Movilidad Interna, modelo canonico de interoperabilidad para registros internos y externos, interoperabilidad con INM, interoperabilidad con COMAR, Registro del Derecho a Vivir en Familia, Interoperabilidad Interna/Externa, QA y Certificacion y requiere coordinacion de Funcional/Backend, Integraciones, QA.

PYD-080 - API de traslados

Responsable: Backend 1 | Disciplina: Funcional/Backend | Sistema/componente: RMI - Registro de Movilidad Interna | Fechas: 2026-09-07 a 2026-09-11.

Descripcion detallada

PYD-080 - API de traslados

Objetivo PM: implementar traslados de movilidad interna con origen, destino, causa, responsable, evidencia, estado y seguimiento.

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 RMI - Registro de Movilidad Interna, queda a cargo de Backend 1 y esta planeada del 2026-09-07 al 2026-09-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 separar traslado interno de canalizacion, validar catalogos, permisos, documentos y relacion con expediente. Actividades principales del checklist: Confirmar historia o flujo operativo que resuelve API de traslados en Registro de Movilidad Interna; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-080 (API de traslados): 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-080 solo si "API de traslados" 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 alta, consulta, cambio de estado, datos limite y auditoria del traslado. 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: 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-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: 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-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 Backend 1 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-080 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-080 (API de traslados): 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-080 solo si "API de traslados" 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 alta, consulta, cambio de estado, datos limite y auditoria del traslado. 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-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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-04 - RMP - Registro de Medidas de Proteccion, SYS-05 - RNCAS - Registro Nacional de Centros de Asistencia Social, SYS-09 - Gestion Documental, SYS-12 - Repositorio Git Institucional, SYS-RMH - RMH - Registro de Movilidad Humana, SYS-RMI - RMI - Registro de Movilidad Interna

Checklist de entregables

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

Responsable: Frontend 1 | Disciplina: Funcional/Backend | Sistema/componente: RMI - Registro de Movilidad Interna | Fechas: 2026-09-07 a 2026-09-14.

Descripcion detallada

PYD-081 - Interfaz de traslados

Objetivo PM: implementar traslados de movilidad interna con origen, destino, causa, responsable, evidencia, estado y seguimiento.

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 RMI - Registro de Movilidad Interna, queda a cargo de Frontend 1 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 separar traslado interno de canalizacion, validar catalogos, permisos, documentos y relacion con expediente. Actividades principales del checklist: Confirmar historia o flujo operativo que resuelve Interfaz de traslados en Registro de Movilidad Interna; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-081 (Interfaz de traslados): 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-081 solo si "Interfaz de traslados" 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 alta, consulta, cambio de estado, datos limite y auditoria del traslado. 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: 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-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: 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-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 Frontend 1 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-081 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-081 (Interfaz de traslados): 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-081 solo si "Interfaz de traslados" 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 alta, consulta, cambio de estado, datos limite y auditoria del traslado. 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-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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-04 - RMP - Registro de Medidas de Proteccion, SYS-05 - RNCAS - Registro Nacional de Centros de Asistencia Social, SYS-09 - Gestion Documental, SYS-12 - Repositorio Git Institucional, SYS-RMH - RMH - Registro de Movilidad Humana, SYS-RMI - RMI - Registro de Movilidad Interna

Checklist de entregables

  • PYD-081 | Alcance | Confirmar historia o flujo operativo que resuelve Interfaz de traslados en Registro de Movilidad Interna; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
  • PYD-081 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
  • PYD-081 | Construccion | Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
  • PYD-081 | Evidencia | Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
  • PYD-081 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
  • PYD-081 | Dependencias | Verificar que no se registren secretos ni datos personales reales en logs o evidencias; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
  • PYD-081 | Seguridad | Adjuntar evidencia funcional: captura, reporte de prueba, commit, PR o demo; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
  • PYD-081 | Cierre | Actualizar estado, riesgos e integraciones relacionadas en PtD; debe dejar evidencia trazable al hito H08, 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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-06 - Expediente Unico NNA, SYS-07 - Acceso Unico Institucional, SYS-09 - Gestion Documental, SYS-10 - Plataforma Publica de Indicadores, SYS-11 - Infraestructura DTI, SYS-12 - Repositorio Git Institucional, SYS-RMH - RMH - Registro de Movilidad Humana, SYS-RMI - RMI - Registro de Movilidad Interna

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-086 - Implementar outbox y reintentos

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

Descripcion detallada

PYD-086 - Implementar outbox y reintentos

Objetivo PM: implementar patron outbox/reintentos para que eventos de interoperabilidad sean consistentes, idempotentes y auditables.

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 Backend 1 y esta planeada del 2026-09-14 al 2026-09-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 persistencia de evento, estados, reintentos, backoff, errores definitivos, correlation ID y reproceso. Actividades principales del checklist: Confirmar historia o flujo operativo que resuelve Implementar outbox y reintentos en Interoperabilidad Interna/Externa; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-086 (Implementar outbox y reintentos): 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-086 solo si "Implementar outbox y reintentos" 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 simulando exito, falla temporal, falla permanente y reintento sin duplicar efectos. 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 1 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-086 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-086 (Implementar outbox y reintentos): 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-086 solo si "Implementar outbox y reintentos" 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 simulando exito, falla temporal, falla permanente y reintento sin duplicar efectos. 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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-09 - Gestion Documental, SYS-12 - Repositorio Git Institucional, SYS-RMI - RMI - Registro de Movilidad Interna

Checklist de entregables

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

H09 - Este hito debe cerrar bandejas, filtros, gestion documental, motor antiduplicados y estado de integraciones. Su alcance operativo se concentra en Expediente Unico NNA, Frontend React / UI Operativa, referencias documentales, evidencias, metadatos y permisos por expediente, motor antiduplicados, QA y Certificacion y requiere coordinacion de Backend, Frontend, Documentacion, Datos, QA.

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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-06 - Expediente Unico NNA, SYS-07 - Acceso Unico Institucional, SYS-09 - Gestion Documental, SYS-12 - Repositorio Git Institucional, SYS-RMI - RMI - Registro de Movilidad Interna

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-091 - Filtros y paginación

Responsable: Backend 2 | Disciplina: Frontend | Sistema/componente: Frontend React / UI Operativa | Fechas: 2026-09-21 a 2026-09-28.

Descripcion detallada

PYD-091 - Filtros y paginación

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 Frontend React / UI Operativa, queda a cargo de Backend 2 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 Filtros y paginación en Frontend React / UI Operativa; 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-091 (Filtros y paginación): 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-091 solo si "Filtros y paginación" 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: 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 Frontend React / UI 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-091 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-091 (Filtros y paginación): 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-091 solo si "Filtros y paginación" 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. 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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-09 - Gestion Documental, SYS-12 - Repositorio Git Institucional, SYS-RMI - RMI - Registro de Movilidad Interna

Checklist de entregables

  • PYD-091 | Alcance | Confirmar historia o flujo operativo que resuelve Filtros y paginación en Frontend React / UI Operativa; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
  • PYD-091 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
  • PYD-091 | 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-091 | 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-091 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
  • PYD-091 | 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-091 | 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-091 | 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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-06 - Expediente Unico NNA, SYS-09 - Gestion Documental, SYS-12 - Repositorio Git Institucional, SYS-RMI - RMI - Registro de Movilidad Interna

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-093 - Motor antiduplicados inicial

Responsable: Backend 1 | Disciplina: Datos | Sistema/componente: Motor Antiduplicados | Fechas: 2026-09-21 a 2026-10-01.

Descripcion detallada

PYD-093 - Motor antiduplicados inicial

Objetivo PM: detectar posibles expedientes duplicados con criterios explicables y revision humana antes de fusionar o descartar.

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 Motor Antiduplicados, queda a cargo de Backend 1 y esta planeada del 2026-09-21 al 2026-10-01. 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 CURP, nombre, fecha, nacionalidad, folios, puntaje, umbral, cola de revision y auditoria de decision. Actividades principales del checklist: Confirmar historia o flujo operativo que resuelve Motor antiduplicados inicial en motor antiduplicados; 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-093 (Motor antiduplicados 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-093 solo si "Motor antiduplicados 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 coincidencias altas, bajas, falso positivo, confirmacion y descarte auditados. 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: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. 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: La funcionalidad no debe cerrarse como completa si faltan contrato, permisos, pruebas, auditoria o evidencia de error controlado. 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 Backend 1 puede coordinar la revision de motor antiduplicados, 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-093 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-093 (Motor antiduplicados 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-093 solo si "Motor antiduplicados 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 coincidencias altas, bajas, falso positivo, confirmacion y descarte auditados. 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-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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-08 - Motor Antiduplicados, SYS-09 - Gestion Documental, SYS-12 - Repositorio Git Institucional, SYS-RMI - RMI - Registro de Movilidad Interna

Checklist de entregables

  • PYD-093 | Alcance | Confirmar historia o flujo operativo que resuelve Motor antiduplicados inicial en motor antiduplicados; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
  • PYD-093 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
  • PYD-093 | 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-093 | 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-093 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
  • PYD-093 | 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-093 | 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-093 | Cierre | Actualizar estado, riesgos e integraciones relacionadas en PtD; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
PYD-094 - Pantalla de coincidencias

Responsable: Frontend 1 | Disciplina: Datos | Sistema/componente: Motor Antiduplicados | Fechas: 2026-09-28 a 2026-10-02.

Descripcion detallada

PYD-094 - Pantalla de coincidencias

Objetivo PM: detectar posibles expedientes duplicados con criterios explicables y revision humana antes de fusionar o descartar.

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 Motor Antiduplicados, queda a cargo de Frontend 1 y esta planeada del 2026-09-28 al 2026-10-02. 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 CURP, nombre, fecha, nacionalidad, folios, puntaje, umbral, cola de revision y auditoria de decision. Actividades principales del checklist: Confirmar historia o flujo operativo que resuelve Pantalla de coincidencias en motor antiduplicados; 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-094 (Pantalla de coincidencias): 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-094 solo si "Pantalla de coincidencias" 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 coincidencias altas, bajas, falso positivo, confirmacion y descarte auditados. 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: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. 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: La funcionalidad no debe cerrarse como completa si faltan contrato, permisos, pruebas, auditoria o evidencia de error controlado. 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 Frontend 1 puede coordinar la revision de motor antiduplicados, 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-094 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-094 (Pantalla de coincidencias): 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-094 solo si "Pantalla de coincidencias" 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 coincidencias altas, bajas, falso positivo, confirmacion y descarte auditados. 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-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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-08 - Motor Antiduplicados, SYS-09 - Gestion Documental, SYS-12 - Repositorio Git Institucional, SYS-RMI - RMI - Registro de Movilidad Interna

Checklist de entregables

  • PYD-094 | Alcance | Confirmar historia o flujo operativo que resuelve Pantalla de coincidencias en motor antiduplicados; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
  • PYD-094 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
  • PYD-094 | 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-094 | 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-094 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
  • PYD-094 | 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-094 | 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-094 | Cierre | Actualizar estado, riesgos e integraciones relacionadas en PtD; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
PYD-095 - Pantalla de estado de integraciones

Responsable: Frontend 2 | Disciplina: Frontend | Sistema/componente: Frontend React / UI Operativa | Fechas: 2026-09-28 a 2026-10-02.

Descripcion detallada

PYD-095 - Pantalla de estado de integraciones

Objetivo PM: implementar Pantalla de estado de integraciones dentro de Frontend React / UI Operativa con comportamiento claro, validaciones, permisos, auditoria y pruebas.

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 Frontend React / UI Operativa, queda a cargo de Frontend 2 y esta planeada del 2026-09-28 al 2026-10-02. 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 Pantalla de estado de integraciones en Frontend React / UI Operativa; 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-095 (Pantalla de estado de integraciones): 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-095 solo si "Pantalla de estado de integraciones" 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: 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 Frontend 2 puede coordinar la revision de Frontend React / UI 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-095 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-095 (Pantalla de estado de integraciones): 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-095 solo si "Pantalla de estado de integraciones" 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. 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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-09 - Gestion Documental, SYS-12 - Repositorio Git Institucional, SYS-RMI - RMI - Registro de Movilidad Interna

Checklist de entregables

  • PYD-095 | Alcance | Confirmar historia o flujo operativo que resuelve Pantalla de estado de integraciones en Frontend React / UI Operativa; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
  • PYD-095 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
  • PYD-095 | 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-095 | 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-095 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
  • PYD-095 | 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-095 | 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-095 | Cierre | Actualizar estado, riesgos e integraciones relacionadas en PtD; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.

H10 - Este hito debe congelar funcionalidad del entregable 3, corregir defectos criticos, ejecutar regresion y preparar demo/documentacion. Su alcance operativo se concentra en QA y Certificacion, Gestion Documental y requiere coordinacion de Coordinacion, QA, Documentacion.

Control transversal: no hay tarea directa con este pilar, pero el hito debe conservar evidencia, trazabilidad, control de cambios y validacion de impacto si toca datos, servicios o integraciones relacionadas.

H11 - Este hito debe completar funcionalidad restante de RMH, UX, accesibilidad y relaciones con Expediente Unico y RMI. Su alcance operativo se concentra en Registro de Movilidad Humana, Frontend React / UI Operativa y requiere coordinacion de Funcional/Backend, Frontend.

PYD-111 - Completar interfaces RMH

Responsable: Frontend 1 | Disciplina: Funcional/Backend | Sistema/componente: RMH - Registro de Movilidad Humana | Fechas: 2026-10-20 a 2026-10-30.

Descripcion detallada

PYD-111 - Completar interfaces RMH

Objetivo PM: coordinar Completar interfaces RMH para desbloquear decisiones, responsables, fechas y evidencias del hito.

Alcance operativo: esta tarea pertenece a H11 - H11 - Funcionalidad restante del RMH, se vincula con PYD-E4 - Integracion, QA, seguridad y migracion preliminar, impacta RMH - Registro de Movilidad Humana, queda a cargo de Frontend 1 y esta planeada del 2026-10-20 al 2026-10-30. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: la actividad debe producir acuerdos accionables, no solo seguimiento informal. En terminos practicos debe cubrir: Definir objetivo concreto de coordinacion para Completar interfaces RMH; Identificar participantes, decisiones requeridas y evidencia esperada; Registrar acuerdos, responsables, fechas, riesgos y dependencias; Dar seguimiento a compromisos abiertos hasta cierre o escalamiento; Actualizar estado del hito y entregable relacionado. Actividades principales del checklist: Definir objetivo concreto de coordinacion para Completar interfaces RMH; debe dejar evidencia trazable al hito H11, responsable asignado y fecha de cierre.; Identificar participantes, decisiones requeridas y evidencia esperada; debe dejar evidencia trazable al hito H11, responsable asignado y fecha de cierre.; Registrar acuerdos, responsables, fechas, riesgos y dependencias; debe dejar evidencia trazable al hito H11, responsable asignado y fecha de cierre.; Dar seguimiento a compromisos abiertos hasta cierre o escalamiento; debe dejar evidencia trazable al hito H11, responsable asignado y fecha de cierre.; Actualizar estado del hito y entregable relacionado; debe dejar evidencia trazable al hito H11, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-111 (Completar interfaces RMH): evidencia de coordinacion con acuerdos, responsables, fechas, riesgos y actualizacion de plan. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-111 solo si "Completar interfaces RMH" produce evidencia de coordinacion con acuerdos, responsables, fechas, riesgos y actualizacion de plan; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con minuta, responsable y siguiente accion 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; DEP-INM-001 - Enlace técnico y funcional

Riesgos y controles: Riesgo de cerrar Completar interfaces RMH sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. 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-111 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 Frontend 1 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-111 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-111 (Completar interfaces RMH): evidencia de coordinacion con acuerdos, responsables, fechas, riesgos y actualizacion de plan. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-111 solo si "Completar interfaces RMH" produce evidencia de coordinacion con acuerdos, responsables, fechas, riesgos y actualizacion de plan; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con minuta, responsable y siguiente accion registrada. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Riesgo de cerrar Completar interfaces RMH sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. 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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-04 - RMP - Registro de Medidas de Proteccion, SYS-05 - RNCAS - Registro Nacional de Centros de Asistencia Social, SYS-09 - Gestion Documental, SYS-12 - Repositorio Git Institucional, SYS-RMH - RMH - Registro de Movilidad Humana, SYS-RMI - RMI - Registro de Movilidad Interna

Checklist de entregables

  • PYD-111 | Alcance | Definir objetivo concreto de coordinacion para Completar interfaces RMH; debe dejar evidencia trazable al hito H11, responsable asignado y fecha de cierre.
  • PYD-111 | Analisis | Identificar participantes, decisiones requeridas y evidencia esperada; debe dejar evidencia trazable al hito H11, responsable asignado y fecha de cierre.
  • PYD-111 | Construccion | Registrar acuerdos, responsables, fechas, riesgos y dependencias; debe dejar evidencia trazable al hito H11, responsable asignado y fecha de cierre.
  • PYD-111 | Evidencia | Dar seguimiento a compromisos abiertos hasta cierre o escalamiento; debe dejar evidencia trazable al hito H11, responsable asignado y fecha de cierre.
  • PYD-111 | Validacion | Actualizar estado del hito y entregable relacionado; debe dejar evidencia trazable al hito H11, responsable asignado y fecha de cierre.
  • PYD-111 | Dependencias | Adjuntar minuta, reporte o evidencia de avance; debe dejar evidencia trazable al hito H11, responsable asignado y fecha de cierre.
  • PYD-111 | Seguridad | Validar cierre con Frontend 1; debe dejar evidencia trazable al hito H11, responsable asignado y fecha de cierre.
  • PYD-111 | Cierre | Registrar pendientes y proximas acciones en PtD; debe dejar evidencia trazable al hito H11, responsable asignado y fecha de cierre.
PYD-112 - Validación UX y accesibilidad

Responsable: Diseño | Disciplina: Frontend | Sistema/componente: Frontend React / UI Operativa | Fechas: 2026-10-20 a 2026-10-30.

Descripcion detallada

PYD-112 - Validación UX y accesibilidad

Objetivo PM: comprobar que Frontend React / UI Operativa funciona en escenarios reales, negativos, permisos, integraciones y regresion.

Alcance operativo: esta tarea pertenece a H11 - H11 - Funcionalidad restante del RMH, se vincula con PYD-E4 - Integracion, QA, seguridad y migracion preliminar, impacta Frontend React / UI Operativa, queda a cargo de Diseño y esta planeada del 2026-10-20 al 2026-10-30. 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 Validación UX y accesibilidad y version del artefacto a validar; debe dejar evidencia trazable al hito H11, responsable asignado y fecha de cierre.; Preparar casos, datos anonimizados, usuarios y ambiente; debe dejar evidencia trazable al hito H11, responsable asignado y fecha de cierre.; Ejecutar casos positivos, negativos, permisos, datos limite y regresion aplicable; debe dejar evidencia trazable al hito H11, responsable asignado y fecha de cierre.; Registrar defectos con pasos de reproduccion, evidencia, severidad y modulo afectado; debe dejar evidencia trazable al hito H11, responsable asignado y fecha de cierre.; Separar defectos bloqueantes de observaciones no bloqueantes; debe dejar evidencia trazable al hito H11, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-112 (Validación UX y accesibilidad): 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-112 solo si "Validación UX y accesibilidad" 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-PF-006 - Validación de requerimientos

Riesgos y controles: Defectos bloqueantes sin responsable, datos de prueba insuficientes o regresion incompleta. Puede agravarse si no se atiende: DEP-PF-006 - Validación de requerimientos. 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-112 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-PF-006 - Validación de requerimientos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Diseño puede coordinar la revision de Frontend React / UI 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-112 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-112 (Validación UX y accesibilidad): 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-112 solo si "Validación UX y accesibilidad" 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-PF-006 - Validación de requerimientos. 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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-09 - Gestion Documental, SYS-11 - Infraestructura DTI, SYS-12 - Repositorio Git Institucional, SYS-RMI - RMI - Registro de Movilidad Interna

Checklist de entregables

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

H12 - Este hito debe habilitar interoperabilidad interna real o condicion formal con RDVF, RMP y RNCAS. Su alcance operativo se concentra en Registro del Derecho a Vivir en Familia, Registro de Medidas de Proteccion, Registro Nacional de Centros de Asistencia Social, contratos internos RDVF, RMP y RNCAS con certificacion o condicion formal y requiere coordinacion de Integraciones.

Control transversal: no hay tarea directa con este pilar, pero el hito debe conservar evidencia, trazabilidad, control de cambios y validacion de impacto si toca datos, servicios o integraciones relacionadas.

H13 - Este hito debe concretar integracion real con INM y COMAR, incluyendo red, seguridad, adaptadores, pruebas y certificacion. Su alcance operativo se concentra en interoperabilidad con INM, interoperabilidad con COMAR, Interoperabilidad Interna/Externa y requiere coordinacion de Integraciones.

Control transversal: no hay tarea directa con este pilar, pero el hito debe conservar evidencia, trazabilidad, control de cambios y validacion de impacto si toca datos, servicios o integraciones relacionadas.

H14 - Este hito debe preparar migracion preliminar con perfilamiento, ETL, conciliacion, calidad y rollback. Su alcance operativo se concentra en Gobierno de Datos, Acceso Unico Institucional y requiere coordinacion de Datos, Seguridad.

Control transversal: no hay tarea directa con este pilar, pero el hito debe conservar evidencia, trazabilidad, control de cambios y validacion de impacto si toca datos, servicios o integraciones relacionadas.

H15 - Este hito debe ejecutar QA integral sobre funcionalidad, integraciones, rendimiento, seguridad, roles y auditoria. Su alcance operativo se concentra en QA y Certificacion, Acceso Unico Institucional y requiere coordinacion de QA, Seguridad.

Control transversal: no hay tarea directa con este pilar, pero el hito debe conservar evidencia, trazabilidad, control de cambios y validacion de impacto si toca datos, servicios o integraciones relacionadas.

H16 - Este hito debe corregir defectos criticos, ejecutar regresion final y cerrar tecnicamente QA del entregable 4. Su alcance operativo se concentra en QA y Certificacion, Gestion Documental y requiere coordinacion de QA, Coordinacion, Documentacion.

Control transversal: no hay tarea directa con este pilar, pero el hito debe conservar evidencia, trazabilidad, control de cambios y validacion de impacto si toca datos, servicios o integraciones relacionadas.

H17 - Este hito debe atender ajustes derivados de QA, optimizar rendimiento y actualizar documentacion productiva. Su alcance operativo se concentra en QA y Certificacion, Gestion Documental y requiere coordinacion de QA, Documentacion.

Control transversal: no hay tarea directa con este pilar, pero el hito debe conservar evidencia, trazabilidad, control de cambios y validacion de impacto si toca datos, servicios o integraciones relacionadas.

H18 - Este hito debe definir y ejecutar pentesting con alcance autorizado, evidencias y clasificacion de hallazgos. Su alcance operativo se concentra en Acceso Unico Institucional, gestion de hallazgos de seguridad, severidad, remediacion y retest y requiere coordinacion de Seguridad.

Control transversal: no hay tarea directa con este pilar, pero el hito debe conservar evidencia, trazabilidad, control de cambios y validacion de impacto si toca datos, servicios o integraciones relacionadas.

H19 - Este hito debe remediar vulnerabilidades criticas y altas, ejecutar repruebas y cerrar evidencia de seguridad. Su alcance operativo se concentra en Acceso Unico Institucional, QA y Certificacion y requiere coordinacion de Seguridad, QA.

Control transversal: no hay tarea directa con este pilar, pero el hito debe conservar evidencia, trazabilidad, control de cambios y validacion de impacto si toca datos, servicios o integraciones relacionadas.

H20 - Este hito debe ejecutar ensayo y preparacion de migracion definitiva, infraestructura productiva, monitoreo y respaldos. Su alcance operativo se concentra en Gobierno de Datos, Infraestructura DTI y requiere coordinacion de Datos, DevOps.

Control transversal: no hay tarea directa con este pilar, pero el hito debe conservar evidencia, trazabilidad, control de cambios y validacion de impacto si toca datos, servicios o integraciones relacionadas.

H21 - Este hito debe realizar comite Go/No-Go, liberacion productiva y pruebas de humo. Su alcance operativo se concentra en Gobierno del Proyecto, Infraestructura DTI, QA y Certificacion y requiere coordinacion de Coordinacion, DevOps, QA.

Control transversal: no hay tarea directa con este pilar, pero el hito debe conservar evidencia, trazabilidad, control de cambios y validacion de impacto si toca datos, servicios o integraciones relacionadas.

H22 - Este hito debe transferir operacion, capacitar equipos, cerrar manuales/runbooks, estabilizar y formalizar cierre. Su alcance operativo se concentra en transferencia tecnica backend, APIs y operacion de servicios, transferencia frontend, UX operativa y componentes React, operacion, soporte y mesa de ayuda, documentacion operativa y soporte, estabilizacion post-liberacion, soporte, incidentes y seguimiento operativo, Gestion Documental, cierre contractual, anexos, aceptaciones y transferencia final y requiere coordinacion de Documentacion, Frontend, Soporte.

PYD-221 - Capacitación frontend

Responsable: Frontend 1 | Disciplina: Frontend/Capacitacion | Sistema/componente: Frontend React / UI Operativa | Fechas: 2027-03-23 a 2027-03-25.

Descripcion detallada

PYD-221 - Capacitación frontend

Objetivo PM: transferir al equipo tecnico/operativo la estructura frontend, componentes, rutas, permisos, formularios y patrones de UX.

Alcance operativo: esta tarea pertenece a H22 - H22 - Transferencia y estabilizacion, se vincula con PYD-E5 - Remediacion, despliegue productivo, capacitacion y cierre, impacta Frontend React / UI Operativa, queda a cargo de Frontend 1 y esta planeada del 2027-03-23 al 2027-03-25. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.

Actividades de ejecucion: la sesion debe recorrer flujos reales, manejo de errores, componentes reutilizables, pruebas y ajustes comunes. Actividades principales del checklist: Definir publico objetivo, prerequisitos y alcance de la capacitacion para Capacitación frontend; debe dejar evidencia trazable al hito H22, responsable asignado y fecha de cierre.; Preparar temario, material, ambiente de practica y ejercicios guiados; debe dejar evidencia trazable al hito H22, responsable asignado y fecha de cierre.; Ejecutar demostracion con flujos reales del sistema y casos frecuentes; debe dejar evidencia trazable al hito H22, responsable asignado y fecha de cierre.; Resolver dudas y registrar temas que requieran ajuste de manual o soporte; debe dejar evidencia trazable al hito H22, responsable asignado y fecha de cierre.; Levantar asistencia y evidencia de participacion; debe dejar evidencia trazable al hito H22, responsable asignado y fecha de cierre..

Entregable verificable: Evidencia requerida para PYD-221 (Capacitación frontend): temario, material, lista de asistencia, ejercicio practico, dudas y acuerdos de soporte. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-221 solo si "Capacitación frontend" produce sesion de capacitacion con temario, practica guiada, asistentes, dudas, material y evaluacion basica; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con asistencia, ejercicio guiado, material actualizado y dudas resueltas. 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: Transferencia insuficiente para operacion diaria o dudas no incorporadas a manuales y runbooks. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La capacitacion no sustituye la aceptacion funcional ni el soporte post-liberacion; solo acredita transferencia inicial. 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 transferencia frontend, UX operativa y componentes React, 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-221 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-221 (Capacitación frontend): temario, material, lista de asistencia, ejercicio practico, dudas y acuerdos de soporte. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.

Criterio de aceptacion: Aceptar PYD-221 solo si "Capacitación frontend" produce sesion de capacitacion con temario, practica guiada, asistentes, dudas, material y evaluacion basica; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con asistencia, ejercicio guiado, material actualizado y dudas resueltas. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.

Riesgos operativos: Transferencia insuficiente para operacion diaria o dudas no incorporadas a manuales y runbooks. 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-03 - RDVF - Registro del Derecho a Vivir en Familia, SYS-05 - RNCAS - Registro Nacional de Centros de Asistencia Social, SYS-09 - Gestion Documental, SYS-11 - Infraestructura DTI, SYS-12 - Repositorio Git Institucional

Checklist de entregables

  • PYD-221 | Alcance | Definir publico objetivo, prerequisitos y alcance de la capacitacion para Capacitación frontend; debe dejar evidencia trazable al hito H22, responsable asignado y fecha de cierre.
  • PYD-221 | Analisis | Preparar temario, material, ambiente de practica y ejercicios guiados; debe dejar evidencia trazable al hito H22, responsable asignado y fecha de cierre.
  • PYD-221 | Construccion | Ejecutar demostracion con flujos reales del sistema y casos frecuentes; debe dejar evidencia trazable al hito H22, responsable asignado y fecha de cierre.
  • PYD-221 | Evidencia | Resolver dudas y registrar temas que requieran ajuste de manual o soporte; debe dejar evidencia trazable al hito H22, responsable asignado y fecha de cierre.
  • PYD-221 | Validacion | Levantar asistencia y evidencia de participacion; debe dejar evidencia trazable al hito H22, responsable asignado y fecha de cierre.
  • PYD-221 | Dependencias | Aplicar validacion basica de comprension o ejercicio practico; debe dejar evidencia trazable al hito H22, responsable asignado y fecha de cierre.
  • PYD-221 | Seguridad | Actualizar manuales/runbooks con preguntas frecuentes detectadas; debe dejar evidencia trazable al hito H22, responsable asignado y fecha de cierre.
  • PYD-221 | Cierre | Registrar acuerdos de soporte posterior y responsables; debe dejar evidencia trazable al hito H22, responsable asignado y fecha de cierre.

¿Le ha resultado útil este artículo?

Articulos relacionados