Épica B — Gestión de proyectos

Estado: Borrador · Última actualización: 2026-08-24 · Índice: README

Cubre el ciclo de vida del proyecto de QA: su importación desde Argos Operaciones —única vía de creación—, la sincronización de su metadata y la degradación cuando Argos Operaciones no responde, y el archivado y reactivación. Reglas de negocio del bloque: RN-014 a RN-017 y RN-082.

HU-003 — Importar un proyecto desde Argos Operaciones

Épica: B · Gestión de proyectos · Deriva de: CU-001 · Cubre: RF-009, RF-010, RF-011, RF-012, RF-017 · Reglas: RN-014, RN-015 · Estado: Borrador

Historia

Como Product Manager, quiero crear el espacio de QA de un proyecto importándolo desde Argos Operaciones, para partir de la fuente de verdad y no duplicar proyectos que ya existen.

Objetivo / valor. Un proyecto de QA no nace de cero: es la contraparte de uno que ya existe en Argos Operaciones. La importación garantiza que ambos comparten identificador y que Argos Operaciones sigue siendo la fuente de verdad de proyectos.

Alcance

• Dentro: búsqueda del proyecto en Argos Operaciones, selección, previsualización de los

datos a importar, creación del proyecto local vinculado de forma permanente, asignación automática del rol Product Manager al importador y el enlace directo al proyecto en Argos Operaciones.

• Fuera: cualquier creación manual de proyectos (prohibida), la re-sincronización

posterior (HU-004), y el contrato fino de la API de Argos Operaciones (documentado, no diseñado).

Actores y permisos

Importar es una acción de plataforma: la habilita el rol de plataforma Product Manager o Admin (RN-085), no un rol de proyecto (que aún no existe). Al importar, el usuario queda como Product Manager de proyecto del proyecto creado (RN-005, DEC-060). El rol PM de la tabla describe ese estado resultante, no una precondición.

Precondiciones

• El usuario está autenticado con un JWT válido de Flagare y tiene **rol de plataforma

Product Manager o Admin** (HU-001, RN-085).

• El proyecto existe en Argos Operaciones y el usuario tiene acceso a él allí.
• Argos Operaciones está disponible.

Comportamiento funcional

• Principal. El usuario abre la creación de proyecto y busca por nombre o identificador de

Argos Operaciones; el sistema consulta Argos Operaciones y muestra los proyectos coincidentes a los que el usuario tiene acceso; el usuario selecciona uno; el sistema muestra los datos que se importarán (identificador, nombre, cliente, estado, responsable); el usuario confirma; el sistema crea el proyecto local, lo vincula de forma permanente al identificador de Argos Operaciones, asigna al usuario el rol Product Manager, registra la creación en auditoría y deja visible el enlace al proyecto en Argos Operaciones.

• Alternativo A1 — la búsqueda no arroja resultados. El sistema informa que no encontró el

proyecto y recuerda que debe existir previamente en Argos Operaciones. No ofrece crearlo localmente.

• Error E1 — el proyecto ya fue importado. El sistema lo indica y ofrece navegar al

proyecto existente en Argos QA; no crea un duplicado (RN-015).

• Error E2 — Argos Operaciones no responde. El sistema informa que la importación no está

disponible e invita a reintentar. No ofrece una creación manual como alternativa (RN-014).

Datos y campos (funcional)

• Precargado desde Argos Operaciones (no editable en la importación): identificador en Argos Operaciones, nombre,

cliente asociado, estado y responsable. El identificador de Argos Operaciones es la clave de vinculación permanente. El detalle exacto de campos depende de PA-006.

• Deriva el sistema: proyecto local Activo, vínculo permanente al identificador de

Argos Operaciones, rol Product Manager para el importador, enlace directo al proyecto en Argos Operaciones.

Reglas de negocio aplicables

• RN-014 — no existe un proyecto de QA sin proyecto correspondiente en Argos Operaciones; ninguna

vía de creación manual, ni para pilotos o pruebas internas.

• RN-015 — un proyecto de Argos Operaciones se corresponde con exactamente uno de QA; no se duplica

la importación.

Estados y transiciones. El proyecto nace en Activo (ver máquina de estados del proyecto: [*] → Activo).

Integraciones (documentado, el dev implementa)

• Argos Operaciones — el sistema consulta los proyectos accesibles del usuario, lee los

datos a importar y guarda el identificador de vínculo permanente. El contrato fino (endpoint de búsqueda, campos exactos, verificación de acceso) se cierra con PA-006.

Eventos que emite. Ninguno del catálogo de dominio; la creación queda en auditoría (HU-027).

Criterios de aceptación

• CA-030

> Dado un Product Manager autenticado y un proyecto que existe en Argos Operaciones y aún no está importado > Cuando lo busca, lo selecciona, revisa los datos a importar y confirma > Entonces el sistema crea el proyecto local vinculado de forma permanente al identificador de Argos Operaciones, le asigna el rol Product Manager y registra la creación en auditoría.

• CA-031

> Dado un proyecto de Argos Operaciones que ya fue importado a Argos QA > Cuando el usuario intenta importarlo de nuevo > Entonces el sistema lo impide, lo indica y ofrece navegar al proyecto existente, sin crear un duplicado.

• CA-032

> Dado una búsqueda que no arroja resultados en Argos Operaciones > Cuando el usuario consulta > Entonces el sistema informa que no lo encontró, recuerda que debe existir en Argos Operaciones y no ofrece crearlo localmente.

• CA-033

> Dado que Argos Operaciones no responde > Cuando el usuario intenta importar un proyecto > Entonces el sistema informa que la importación no está disponible e invita a reintentar, sin ofrecer una creación manual.

• CA-034

> Dado un proyecto ya importado > Cuando el usuario abre cualquier vista del proyecto > Entonces el sistema ofrece un enlace directo al proyecto correspondiente en Argos Operaciones.

Dependencias y bloqueos

• PA-019 → resuelta (DEC-060). Quién importa el primer proyecto se autoriza por el **rol

de plataforma** Product Manager/Admin (RN-085), no por un rol de proyecto. Queda solo la dependencia del contrato del claim de rol en el JWT (PA-007).

• PA-006 (API de Argos Operaciones) — condiciona los campos importados y el contrato de

búsqueda y vínculo; la prohibición de creación manual no depende de ella.

• HU-001 (autenticación) es precondición.
• HU-004 (sincronización) refresca la metadata importada aquí.

HU-004 — Sincronizar y degradar con Argos Operaciones

Épica: B · Gestión de proyectos · Deriva de: Transversal · Cubre: RF-013, RF-014 · Reglas: RN-016, RN-017 · Decisiones: DEC-039 · Estado: Borrador

Historia

Como QA o Product Manager, quiero refrescar los datos del proyecto desde Argos Operaciones y seguir trabajando aunque Argos Operaciones esté caído, para tener metadata al día sin que una caída de integración detenga la operación de QA.

Objetivo / valor. La integración con Argos Operaciones actualiza, no gobierna. Refrescar trae la metadata más reciente sin tocar lo que es propio de QA; y si Argos Operaciones no responde, la plataforma degrada de forma controlada en lugar de detenerse.

Alcance

• Dentro: re-sincronización bajo demanda y programada de los datos importados, la

garantía de no sobrescribir datos propios de QA, y el modo degradado cuando Argos Operaciones no responde (indicación visible y bloqueo acotado).

• Fuera: la importación de proyectos nuevos (HU-003) y la creación del ticket espejo de

un bug con Argos Operaciones caído (HU-020, que trata el reintento diferido). El contrato fino de la API es documentado, no diseñado.

Actores y permisos

Precondiciones

• El proyecto ya está importado (HU-003).
• Para la sincronización bajo demanda: el usuario tiene rol Product Manager o QA.

Comportamiento funcional

• Principal — refresco. Un usuario PM o QA fuerza la re-sincronización, o esta ocurre de

forma programada; el sistema trae de Argos Operaciones los datos importados (identificador, nombre, cliente, estado, responsable) y actualiza únicamente esos campos. Los datos propios de QA —roles, ciclos, escenarios, ejecuciones, evidencia, bugs— nunca se sobrescriben (RN-016).

• Alternativo A1 — sincronización programada. El sistema refresca la metadata de forma

periódica sin intervención del usuario, con las mismas garantías de no sobrescritura.

• Error E1 — Argos Operaciones no responde. El sistema sigue operando sobre los proyectos ya

importados e indica de forma visible que la sincronización está desactualizada y desde cuándo. Lo único que queda bloqueado es la importación de proyectos nuevos (DEC-039); la creación de bugs no se bloquea, su ticket espejo queda diferido para reintento (HU-020).

Datos y campos (funcional)

• Refresca desde Argos Operaciones: identificador, nombre, cliente, estado, responsable.
• Nunca se toca: roles, ciclos, escenarios, ejecuciones, evidencia, bugs (datos propios de

QA).

• Deriva el sistema: marca de última sincronización correcta y su timestamp, para mostrar

desde cuándo la metadata está desactualizada.

Reglas de negocio aplicables

• RN-016 — la re-sincronización actualiza solo los datos importados; nunca sobrescribe

información propia de QA.

• RN-017 — la indisponibilidad de Argos Operaciones degrada, no detiene: los proyectos ya

importados siguen operativos; solo se bloquean la importación de proyectos nuevos y, de forma diferida, la creación del ticket espejo de bugs (RN-054, HU-020).

• DEC-039 — con Argos Operaciones caído lo único que se bloquea es la importación de proyectos

nuevos.

Integraciones (documentado, el dev implementa)

• Argos Operaciones — el sistema lee la metadata del proyecto para refrescarla. El

contrato fino (endpoint, frecuencia de la sincronización programada, campos) se cierra con PA-006; el comportamiento degradado local no depende de él.

Criterios de aceptación

• CA-035

> Dado un proyecto importado y Argos Operaciones disponible > Cuando un QA fuerza la re-sincronización > Entonces el sistema actualiza los datos importados y deja intactos roles, ciclos, escenarios, ejecuciones, evidencia y bugs.

• CA-036

> Dado un proyecto importado > Cuando se cumple el ciclo de la sincronización programada > Entonces el sistema refresca la metadata sin intervención del usuario y con las mismas garantías de no sobrescritura.

• CA-037

> Dado que Argos Operaciones no responde > Cuando un usuario trabaja sobre un proyecto ya importado > Entonces el sistema sigue operativo e indica de forma visible que la sincronización está desactualizada y desde cuándo.

• CA-038

> Dado que Argos Operaciones no responde > Cuando un usuario intenta importar un proyecto nuevo > Entonces el sistema lo bloquea, mientras que las demás operaciones sobre proyectos importados siguen disponibles.

Dependencias y bloqueos

• PA-006 (API de Argos Operaciones) — condiciona el contrato de sincronización; el modo

degradado local no depende de ella.

• HU-003 (importación) es lo único que la caída de Argos Operaciones bloquea.
• HU-020 (registrar un bug) — con Argos Operaciones caído, el ticket espejo se difiere; la creación

del bug no se bloquea.

Casos borde / notas. La sincronización es de lectura sobre Argos Operaciones: Argos QA no escribe la metadata del proyecto de vuelta. La única escritura hacia Argos Operaciones en el MVP es la creación del ticket espejo de bugs (HU-020).

HU-005 — Archivar y reactivar un proyecto

Épica: B · Gestión de proyectos · Deriva de: Transversal · Cubre: RF-016, RF-141, RF-138 · Reglas: RN-005, RN-082 · Decisiones: DEC-051 · Estado: Borrador

Historia

Como Product Manager, quiero archivar un proyecto que ya no está activo y poder reactivarlo, para congelar su información sin perderla y reabrirlo si el trabajo se reanuda.

Objetivo / valor. Un proyecto terminado no se borra: se archiva. El archivado lo vuelve de solo lectura conservando toda su información y evidencia, y la reactivación lo devuelve a la operación intacto. Ambas acciones son facultad del PM y quedan auditadas.

Alcance

• Dentro: archivar un proyecto Activo, la validación de que no tenga ciclos abiertos,

el efecto de solo lectura del estado Archivado, la continuidad del reintento de sincronización de bugs tras archivar, y la reactivación a Activo.

• Fuera: el cierre de ciclos que impide archivar (bloque G) y la sincronización de

metadata (HU-004).

Actores y permisos

Precondiciones

• El usuario tiene rol Product Manager en el proyecto.
• Para archivar: el proyecto está Activo y no tiene ningún ciclo Abierto.
• Para reactivar: el proyecto está Archivado.

Comportamiento funcional

• Principal — archivar. El PM archiva un proyecto Activo sin ciclos abiertos; el sistema

lo pasa a Archivado, lo vuelve de solo lectura conservando toda su información y evidencia, y registra el cambio en auditoría. El reintento de sincronización de bugs pendientes hacia Argos Operaciones sigue corriendo tras el archivado (RN-082).

• Principal — reactivar. El PM reactiva un proyecto Archivado; el sistema lo devuelve a

Activo con toda su información intacta y registra la reactivación en auditoría.

• Error E1 — ciclo abierto. El sistema impide archivar mientras exista un ciclo Abierto

e indica cuáles hay que cerrar primero (RN-082).

Datos y campos (funcional)

• Captura el usuario: la acción de archivar o reactivar.
• Deriva el sistema: estado del proyecto (Activo / Archivado), marca de auditoría con

autor y timestamp de cada transición.

Reglas de negocio aplicables

• RN-005 — un proyecto siempre conserva al menos un Product Manager; archivar no altera

esa exigencia.

• RN-082 — no se archiva un proyecto con un ciclo Abierto; archivar y reactivar es

facultad del Product Manager y queda auditado; el archivado no detiene el reintento de sincronización de bugs hacia Argos Operaciones.

• DEC-051 — no se archiva con ciclos abiertos; archivar y reactivar es facultad del PM.

Estados y transiciones. Sigue la máquina de estados del proyecto: Activo → Archivado (sin ciclos abiertos) y Archivado → Activo (reactivación por el PM). Un proyecto Archivado es de solo lectura: no admite ciclos, ejecuciones, bugs ni ediciones nuevas.

Criterios de aceptación

• CA-039

> Dado un proyecto Activo sin ningún ciclo Abierto > Cuando el Product Manager lo archiva > Entonces el proyecto pasa a Archivado, queda de solo lectura conservando su información y evidencia, y el cambio se registra en auditoría.

• CA-040

> Dado un proyecto Activo con al menos un ciclo Abierto > Cuando el Product Manager intenta archivarlo > Entonces el sistema lo impide e indica qué ciclos hay que cerrar antes.

• CA-041

> Dado un proyecto Archivado > Cuando el Product Manager lo reactiva > Entonces el proyecto vuelve a Activo con toda su información intacta y la reactivación queda en auditoría.

• CA-042

> Dado un proyecto Archivado con bugs cuya sincronización con Argos Operaciones quedó pendiente > Cuando el proyecto permanece archivado > Entonces el reintento de creación del ticket espejo hacia Argos Operaciones sigue corriendo.

• CA-043

> Dado un proyecto Archivado > Cuando un usuario intenta abrir un ciclo, ejecutar, registrar un bug o editar > Entonces el sistema lo impide por el modo de solo lectura del proyecto.

Dependencias y bloqueos

• HU-004 (sincronización) — el reintento de tickets espejo de bugs sigue tras el

archivado.

• Bloque G (ciclos) — el cierre de ciclos abiertos es condición para poder archivar.

Casos borde / notas. El archivado es reversible (Archivado → Activo), a diferencia de los estados terminales de otras entidades. La única actividad que un proyecto archivado no detiene es el reintento de sincronización de bugs hacia Argos Operaciones: el ticket espejo debe existir aunque el proyecto de QA esté cerrado.