Sprint S1 — Plataforma y proyectos

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

Demo al cierre: entro con mi cuenta Flagare (roles resueltos por /me), importo un proyecto desde Argos Operaciones, administro su equipo y su ciclo de vida, y toda acción queda auditada. · Bloques funcionales: A, B, M.

HU-001 — Autenticarse con el JWT de Flagare

Sprint/Épica: S1 · Plataforma y proyectos · Bloque: A · Deriva de: Transversal · Cubre: RF-001, RF-002, RF-003 · Reglas: RN-008, RN-085 · Estado: Borrador

Historia

Como usuario de Flagare, quiero acceder a Argos QA con el mismo token que ya me identifica en el ecosistema, para no gestionar una credencial más y que mi identidad sea la única fuente de verdad.

Objetivo / valor. Argos QA no administra identidades propias: delega el quién es en identity.flagare y se reserva solo el qué puede hacer en cada proyecto. Un token válido basta para entrar; nada de contraseñas locales.

Alcance

• Dentro: validación del JWT en cada petición, la consulta al servicio /me de

identity.flagare al iniciar sesión para obtener los permisos del usuario, el alta implícita en el primer acceso, y el rechazo de tokens inválidos.

• Fuera: la autorización por rol de proyecto (la resuelve HU-002 y la matriz) y el

diseño del contrato del token y de /me (documentado, no diseñado).

Actores y permisos

Precondiciones

• El emisor identity.flagare está disponible para que su token pueda validarse.
• La petición transporta un token en la forma esperada por el contrato (pendiente PA-007).

Comportamiento funcional

• Principal. La petición llega con un JWT que solo valida la identidad; el sistema lo

valida (firma, vigencia, emisor). Al iniciar sesión en Argos QA, el sistema llama al servicio /me de identity.flagare, que devuelve los permisos del usuario —incluido su rol de plataforma (Admin, Product Manager o ninguno)—. Si el usuario no existe localmente, se crea su registro a partir de la identidad, sin aprovisionamiento previo; la sesión continúa con la identidad y los permisos establecidos.

• Alternativo A1 — usuario ya conocido. El registro local ya existe; el sistema no lo

recrea, solo lo asocia a la sesión (sus permisos igual se refrescan desde /me).

• Error E1 — token ausente o malformado. El sistema rechaza la petición sin revelar

información del recurso solicitado.

• Error E2 — token expirado o de emisor no reconocido. Mismo rechazo, sin filtrar

detalle del recurso.

• Error E3 — /me no responde. Sin la respuesta de /me, el sistema no puede resolver los

permisos de plataforma; lo informa y no autoriza acciones de plataforma hasta poder consultarlo.

Datos y campos (funcional, no esquema)

• Del token (JWT): solo validación de identidad —firma, vigencia, emisor e identificador

del usuario—. El token no transporta roles ni permisos.

• De /me de identity.flagare: los permisos del usuario, incluido su **rol de

plataforma** (Admin / Product Manager / ninguno, RN-085). Su forma exacta depende de PA-007.

• Deriva el sistema: registro local del usuario en su primer acceso.

Reglas de negocio aplicables

• RN-008 / RN-085 — el JWT valida la identidad; los permisos de plataforma los

entrega el servicio /me de identity.flagare, que Argos QA consulta y no administra. Los roles de proyecto los administra Argos QA. El contrato de /me queda pendiente en PA-007.

Integraciones (documentado, el dev implementa)

• identity.flagare — Argos QA valida el JWT (llave de identidad) y consulta /me

para obtener los permisos del usuario (rol de plataforma). El contrato fino (forma del token y respuesta de /me) se cierra con PA-007; ninguna credencial propia se almacena.

Criterios de aceptación

• CA-001

> Dado un JWT válido emitido por identity.flagare de un usuario desconocido para Argos QA > Cuando el usuario hace su primera petición autenticada > Entonces el sistema crea su registro local a partir de los claims del token y la petición procede con esa identidad.

• CA-002

> Dado un usuario que ya tiene registro local en Argos QA > Cuando vuelve a autenticarse con un token válido > Entonces el sistema reutiliza su registro y no crea un duplicado.

• CA-003

> Dado una petición sin token o con un token malformado > Cuando llega al sistema > Entonces se rechaza sin revelar información del recurso solicitado.

• CA-004

> Dado una petición con un token expirado o de un emisor no reconocido > Cuando llega al sistema > Entonces se rechaza igual que un token ausente, sin filtrar detalle del recurso.

• CA-012

> Dado un usuario con JWT válido que inicia sesión en Argos QA > Cuando el sistema consulta /me de identity.flagare > Entonces obtiene los permisos del usuario —incluido su rol de plataforma— y los usa para autorizar; el JWT por sí solo no otorga permisos.

Dependencias y bloqueos

• PA-007 — condiciona el contrato del JWT (validación) y del servicio /me de

identity.flagare (forma de los permisos, nombres de rol de plataforma). La HU se especifica asumiendo: token = identidad; /me = permisos.

• HU-002 (miembros y roles) consume la identidad establecida aquí para resolver los

permisos por proyecto.

Casos borde / notas. El alta implícita no requiere que un administrador provisione al usuario de antemano: existir en identity.flagare y acceder por primera vez basta para tener registro local. Ese registro no otorga ningún rol de proyecto por sí solo (RN-004, HU-002).

HU-002 — Gestionar miembros y roles del proyecto

Sprint/Épica: S1 · Plataforma y proyectos · Bloque: A · Deriva de: CU-002 · Cubre: RF-004, RF-005, RF-006, RF-007, RF-008, RF-018 · Reglas: RN-001, RN-002, RN-003, RN-004, RN-005, RN-006, RN-007 · Estado: Borrador

Historia

Como Product Manager, quiero definir quién participa en el proyecto y con qué roles, para que cada persona vea y haga exactamente lo que le corresponde, y nada más.

Objetivo / valor. El acceso a un proyecto se gobierna por la dupla usuario + proyecto. Sin rol asignado no hay visibilidad; con varios roles, los permisos se suman. El PM es quien reparte esas responsabilidades y cada cambio queda auditado.

Alcance

• Dentro: listar miembros y sus roles, agregar un miembro con uno o más roles, revocar

roles, y la validación de las restricciones de asignación (Client excluyente, último PM).

• Fuera: la autenticación en sí (HU-001), la definición de qué permite cada rol (la fija

la matriz de roles y permisos), las asignaciones de trabajo a personas —escenarios o ejecuciones—, que no existen en el MVP, y la administración de roles de plataforma (Admin, Product Manager de plataforma), que provienen del servicio /me de identity.flagare y no se gestionan aquí (RN-085).

Actores y permisos

Precondiciones

• El usuario que gestiona tiene rol Product Manager en el proyecto, o es Admin de

plataforma (RN-085).

• El proyecto existe y está Activo.

Comportamiento funcional

• Principal. El PM abre la administración de miembros; el sistema muestra los miembros

actuales con sus roles; el PM agrega una persona y le asigna uno o más roles entre Product Manager, QA, Developer y Client; el sistema valida las restricciones, guarda la asignación, la registra en auditoría y notifica al usuario agregado.

• Alternativo A1 — varios roles a la misma persona. El PM asigna, por ejemplo, Developer

y QA a una misma persona; el sistema lo acepta y los permisos efectivos son la unión de ambos (RN-002).

• Alternativo A2 — revocar un rol. El PM retira un rol; el sistema lo aplica de inmediato;

las sesiones activas del afectado pierden el permiso en su siguiente petición.

• Error E1 — Client junto a otro rol. El sistema rechaza asignar Client a quien ya tiene

otro rol en el proyecto, y rechaza asignar otro rol a quien es Client, explicando la exclusividad (RN-006).

• Error E2 — último Product Manager. El sistema impide revocar el rol Product Manager si

es el único del proyecto (RN-005).

Datos y campos (funcional)

• Captura el usuario: miembro a agregar (identidad del usuario), rol o roles a asignar.
• Deriva el sistema: permisos efectivos como unión de roles, marca de auditoría con autor

y timestamp de cada cambio.

Reglas de negocio aplicables

• RN-001 / RN-003 — el rol se asigna por usuario + proyecto; no hay rol global y una

misma persona puede tener roles distintos en proyectos distintos.

• RN-002 — con varios roles, los permisos son la unión, nunca la intersección.
• RN-004 — un usuario sin rol en el proyecto no puede verlo ni saber que existe.
• RN-005 — todo proyecto conserva al menos un Product Manager; no se revoca el último.
• RN-006 — el rol Client es excluyente respecto de cualquier otro rol en el proyecto.
• RN-007 — asignar y revocar roles es facultad del Product Manager y queda auditado.

Estados y transiciones. No cambia el estado de ninguna entidad de producto; sí exige que el proyecto esté Activo (un proyecto Archivado es de solo lectura, HU-005).

Eventos que emite. Ninguno del catálogo de dominio; la notificación al usuario agregado se cursa por el canal de notificaciones (HU-025). El cambio de rol se refleja en auditoría (HU-027).

Criterios de aceptación

• CA-005

> Dado un Product Manager en la administración de miembros de su proyecto > Cuando agrega a una persona y le asigna el rol QA > Entonces el miembro queda con rol QA, el cambio se registra en auditoría y se le notifica.

• CA-006

> Dado una persona ya miembro del proyecto > Cuando el PM le asigna además el rol Developer teniendo ya QA > Entonces el sistema lo acepta y sus permisos efectivos son la unión de QA y Developer.

• CA-007

> Dado un usuario que ya tiene rol Developer en el proyecto > Cuando el PM intenta asignarle además el rol Client > Entonces el sistema lo impide y explica que Client es excluyente.

• CA-008

> Dado un usuario con rol Client en el proyecto > Cuando el PM intenta asignarle cualquier otro rol > Entonces el sistema lo impide por la misma exclusividad.

• CA-009

> Dado un proyecto con un único Product Manager > Cuando el PM intenta revocarle ese rol > Entonces el sistema lo impide e indica que debe existir al menos un Product Manager.

• CA-010

> Dado un miembro con un rol asignado y una sesión activa > Cuando el PM le revoca ese rol > Entonces el permiso se pierde en la siguiente petición del afectado.

• CA-011

> Dado un usuario sin ningún rol en un proyecto > Cuando intenta listarlo o acceder a él por su identificador > Entonces el sistema no se lo muestra ni le revela que existe.

• CA-013

> Dado un usuario con rol de plataforma Admin y un proyecto donde no tiene rol de proyecto asignado > Cuando accede a ese proyecto > Entonces el sistema se lo permite —excepción a RN-004 por su permiso de plataforma (RN-085)—, a diferencia de un usuario sin rol, al que se le niega.

Dependencias y bloqueos

• HU-001 (autenticación) provee la identidad sobre la que se asignan los roles.
• HU-005 (archivar y reactivar) — sobre un proyecto Archivado no se gestionan roles.
• HU-025 (eventos y notificaciones) cursa el aviso al usuario agregado.

Casos borde / notas. La revocación no cierra sesiones activas de forma inmediata: el permiso se pierde en la siguiente petición, no a mitad de una en curso. Un usuario puede ser QA en un proyecto y Developer en otro sin conflicto (RN-003).

HU-003 — Importar un proyecto desde Argos Operaciones

Sprint/Épica: S1 · Plataforma y proyectos · Bloque: B · 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

Sprint/Épica: S1 · Plataforma y proyectos · Bloque: B · 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

Sprint/Épica: S1 · Plataforma y proyectos · Bloque: B · 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.

HU-027 — Registrar auditoría e integridad referencial

Sprint/Épica: S1 · Plataforma y proyectos · Bloque: M · Deriva de: Transversal · Cubre: RF-131–RF-137 · Reglas: RN-011, RN-073, RN-074, RN-075, RN-076 · Estado: Borrador

Historia

Como plataforma, quiero registrar toda operación relevante en un log inmutable con autor, origen y timestamp, y mantener intacta la cadena de trazabilidad, para que quede evidencia auditable de quién cambió qué y cuándo, y que nunca se rompa el vínculo entre un requerimiento y todo lo que deriva de él.

Objetivo / valor. Que la trazabilidad —tesis del producto— sea verificable: cada cambio crítico deja rastro inmutable con su origen (persona, IA, integración o automatización), y ningún artefacto con derivados puede eliminarse rompiendo la cadena.

Alcance

• Dentro: el registro de cambios críticos con su contenido, la declaración de origen del

cambio, el carácter append-only del log, la consulta filtrable de auditoría, los identificadores estables por artefacto y la integridad referencial que impide eliminar un artefacto con derivados.

• Fuera: qué produce cada operación auditada (vive en su HU), la máquina de estados de

cada entidad y la navegación visual de trazabilidad como reporte (HU-023, RF-111); aquí se garantiza la integridad de la cadena, no su visualización.

Actores y permisos (comportamiento del sistema)

• El registro de auditoría lo escribe el sistema como efecto de cada operación crítica;

ningún rol lo edita ni lo borra —ninguno, incluidos PM y administradores (RN-011, RN-075).

• La consulta de auditoría está disponible para los roles con acceso al proyecto según

la matriz de roles; el Client queda fuera del detalle de auditoría por RN-061.

• La integridad referencial es una garantía del sistema: no depende de la disciplina de

un rol.

Precondiciones

• Ocurre una operación sobre un artefacto crítico: caso de uso, plan, escenario, ambiente,

ciclo, ejecución, bug, bloqueo, rol o aprobación (RF-131).

Comportamiento funcional

• Principal. Toda operación sobre un artefacto crítico genera una entrada de auditoría

con usuario, fecha y hora, acción, artefacto afectado, valor anterior, valor nuevo y justificación cuando aplique, más la declaración de origen del cambio: Usuario, IA, Integración o Automatización. La entrada se agrega al log; el log no admite edición ni borrado por ningún rol.

• Alternativo A1 — consulta. Un usuario con acceso consulta la auditoría filtrando por

artefacto, usuario, rango de fechas, acción y origen (RF-135).

• Alternativo A2 — cambio originado por IA o integración. Cuando el autor material no es

una persona —la IA que escribe un artefacto, Argos Operaciones que crea un ticket espejo—, la entrada declara ese origen, de modo que se distingue lo que hizo una persona de lo que hizo el sistema (RN-074).

• Error E1 — intento de eliminar un artefacto con derivados. El sistema lo impide: el

camino es retirar el artefacto o marcarlo obsoleto, nunca romper la cadena. El identificador del artefacto no se reutiliza aunque se retire (RF-136, RF-137, RN-076).

• Error E2 — intento de editar o borrar auditoría. Rechazado para cualquier rol; el log es

append-only (RN-011, RN-075).

Datos y campos (funcional, no esquema)

• De cada entrada: usuario, fecha y hora, acción, artefacto afectado, valor anterior, valor

nuevo, justificación (cuando aplique), origen (Usuario / IA / Integración / Automatización).

• Del artefacto: identificador estable y legible dentro del proyecto (CU-007, ESC-042,

BUG-013), que no se reutiliza aunque el artefacto se retire.

• De la consulta: filtros por artefacto, usuario, rango de fechas, acción y origen.

Reglas de negocio aplicables

• RN-073 — todo cambio sobre un artefacto crítico registra usuario, fecha y hora, acción,

artefacto, valor anterior, valor nuevo y justificación cuando aplique.

• RN-074 — toda entrada declara su origen: Usuario, IA, Integración o

Automatización.

• RN-011 / RN-075 — el registro de auditoría es append-only: no se edita ni se borra por

ningún rol.

• RN-076 — los identificadores son estables y no se reutilizan; un artefacto con derivados

no se elimina, se retira o se marca obsoleto, y la cadena de trazabilidad no se rompe nunca.

• RN-060 (relacionada) — la cadena requerimiento → caso de uso → escenario → criterio →

ejecución → evidencia → bug → ticket → resolución debe poder recorrerse completa y en ambos sentidos; la integridad referencial de esta HU es lo que garantiza que ese recorrido no tenga eslabones rotos.

Estados y transiciones. No aplica una máquina de estados propia; la auditoría acompaña las transiciones de las máquinas de estado de las demás entidades, registrando cada cambio de estado como una entrada más.

Integraciones (documentado, el dev implementa)

• No introduce integraciones externas propias. Registra, con origen Integración, los

cambios que provienen de sistemas externos ya integrados en otras HU (por ejemplo, el ticket espejo creado en Argos Operaciones desde HU-020, o la importación de proyecto desde HU-003).

Eventos que emite. Ninguno propio. La auditoría es un efecto lateral de las operaciones de negocio; los eventos de dominio los emiten las HU dueñas de cada hito (Épica K).

Criterios de aceptación

• CA-380

> Dado una operación sobre un artefacto crítico (caso, plan, escenario, ambiente, ciclo, ejecución, bug, bloqueo, rol o aprobación) > Cuando la operación se confirma > Entonces se agrega una entrada de auditoría con usuario, fecha y hora, acción, artefacto, valor anterior, valor nuevo y justificación cuando aplique.

• CA-381

> Dado un cambio realizado por la IA o por una integración > Cuando se registra en auditoría > Entonces la entrada declara su origen (Usuario, IA, Integración o Automatización), distinguible del cambio hecho por una persona.

• CA-382

> Dado una entrada de auditoría existente > Cuando cualquier rol intenta editarla o borrarla > Entonces el sistema lo rechaza; el log es append-only.

• CA-383

> Dado un usuario con acceso a la auditoría del proyecto > Cuando consulta filtrando por artefacto, usuario, rango de fechas, acción u origen > Entonces el sistema devuelve las entradas que cumplen el filtro.

• CA-384

> Dado un artefacto que tiene otros artefactos derivados > Cuando se intenta eliminarlo > Entonces el sistema lo impide y ofrece retirarlo o marcarlo obsoleto, sin romper la cadena de trazabilidad.

• CA-385

> Dado un artefacto retirado u obsoleto > Cuando se crea un artefacto nuevo del mismo tipo > Entonces el identificador del artefacto retirado no se reutiliza.

• CA-386

> Dado la cadena de trazabilidad de un proyecto > Cuando se recorre desde un requerimiento hacia sus derivados o desde una resolución hacia su requerimiento de origen > Entonces el recorrido es completo en ambos sentidos, sin eslabones rotos.

Dependencias y bloqueos

• Sin PA que bloquee: la auditoría y la integridad referencial no dependen de insumos

externos pendientes.

• Toda HU que opere sobre artefactos críticos (HU-002 a HU-024) alimenta esta auditoría; esta

HU es la garantía transversal que todas invocan.

Casos borde / notas. "Retirar u obsoletar, nunca eliminar" es la regla que hace que la cadena de RN-060 sea siempre recorrible: un artefacto sin derivados puede desaparecer, pero en cuanto algo deriva de él, su identificador y su rastro quedan. El origen IA en la auditoría es la contraparte de que la IA escriba artefactos (Épica L): sin él no se podría distinguir un caso de uso redactado por una persona de uno propuesto por el modelo.