Sprint S3 — Plan de pruebas y ambientes

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

Demo al cierre: sobre casos congelados, la IA genera el plan de pruebas y sus escenarios con criterios; el PM lo aprueba; registro y preparo el ambiente; los eventos de dominio disparan notificaciones. · Bloques funcionales: E, F, K.

HU-012 — Generar el plan de pruebas y sus escenarios

Sprint/Épica: S3 · Plan de pruebas y ambientes · Bloque: E · Deriva de: CU-009 · Cubre: RF-043–RF-050, RF-054–RF-056, RF-139 · Reglas: RN-031, RN-032, RN-036 · Estado: Borrador

Historia

Como QA, quiero convertir los casos de uso congelados en escenarios ejecutables, con su criterio de aprobación y su matriz de cobertura, para que cualquiera pueda probar contra una definición estable y se vea qué quedó sin cubrir.

Objetivo / valor. Que la prueba se ancle a una línea base inmutable: solo se generan escenarios desde casos Congelado, cada escenario nace estructurado y con criterio de aprobación, y la matriz muestra los huecos de cobertura de diseño antes de que alguien los descubra ejecutando.

Alcance

• Dentro: generación asistida de escenarios desde casos congelados, edición y creación

manual, criterios de aceptación, priorización por riesgo o impacto, matriz de cobertura de diseño y detección de huecos, y el avance de escenarios por sus estados.

• Fuera: la aprobación del plan (HU-013), la ejecución (HU-016) y el diseño del prompt de

generación de escenarios (documentado en HU-026, no diseñado aquí).

Actores y permisos

Precondiciones

• Existe al menos un caso de uso en estado Congelado en el proyecto.
• El proyecto tiene un plan de pruebas (uno por proyecto, RF-043).

Comportamiento funcional

• Principal. El QA abre el plan del proyecto y selecciona los casos de uso Congelado a

cubrir; solicita la generación. El sistema propone escenarios —cada uno con objetivo, precondiciones, ambiente requerido, datos de prueba, rol necesario, pasos numerados con resultado esperado, criterio de aprobación, evidencia requerida y tipo de ejecución— en estado Generado y marcados como generados por IA. El usuario revisa, edita, agrega escenarios a mano y descarta los que no aplican; define criterios de aceptación y prioriza por riesgo o impacto. El sistema actualiza la matriz de cobertura y señala los casos congelados sin escenario que los cubra. El usuario envía los escenarios a En revisión. El sistema emite test_plan.generated.

• Alternativo A1 — revisión asistida del plan. El usuario pide a la IA que señale casos

borde no cubiertos o criterios de aceptación ambiguos, como propuesta revisable; evalúa y acepta o descarta las sugerencias.

• Alternativo A2 — escenario íntegramente manual. El usuario crea un escenario sin pasar por

la IA, con las mismas obligaciones estructurales (RF-046, RF-047).

• Error E1 — caso de uso no congelado. El sistema impide generar escenarios desde un caso

que no esté en Congelado y explica por qué (RN-031).

• Error E2 — escenario incompleto. El sistema impide aprobar un escenario al que le falte

cualquier campo obligatorio, y señala cuáles (RN-032).

Datos y campos (funcional, no esquema)

• Del escenario: objetivo, precondiciones, ambiente requerido, datos de prueba, rol o

usuario necesario, pasos numerados con resultado esperado por paso, criterio de aprobación, evidencia requerida, tipo de ejecución (Manual, Automatizable, Semi-automatizada, No automatizable — informativo en el MVP), prioridad por riesgo o impacto, y el caso de uso de origen con su número de versión.

• De la matriz de cobertura de diseño: relación caso de uso ↔ escenarios que lo cubren, en

ambos sentidos; lista de casos congelados sin escenario aprobado que los cubra.

• Precarga la IA: la propuesta inicial de escenarios y de criterios de aceptación; todo es

editable y descartable.

Reglas de negocio aplicables

• RN-031 — un escenario solo pasa a Aprobado si su caso de uso de origen está

Congelado; la exigencia es del escenario, no del método. Crear y editar antes de eso está permitido: el escenario espera en Generado o En revisión.

• RN-032 — un escenario incompleto no puede aprobarse; se señalan los campos faltantes.
• RN-036 — un caso congelado sin ningún escenario aprobado que lo cubra es un hueco de

cobertura de diseño y se reporta como tal.

Estados y transiciones. Sigue la máquina de estados del escenario: Generado → En revisión → Aprobado, con Requiere cambios y Retirado. Desactualizado no es un estado sino un indicador que acompaña a cualquier estado (RN-037). El plan sigue su propia máquina: Borrador → Pendiente de aprobación → Aprobado.

Integraciones (documentado, el dev implementa)

• IA (orquestación, HU-026) — genera la propuesta de escenarios y de criterios de

aceptación de forma asíncrona; el comportamiento del plan no depende de que la IA responda, porque todo escenario admite creación manual.

Eventos que emite. test_plan.generated.

Criterios de aceptación

• CA-140

> Dado un caso de uso en estado Congelado seleccionado en el plan > Cuando el QA solicita la generación de escenarios > Entonces el sistema propone escenarios en estado Generado, marcados como generados por IA, cada uno con objetivo, precondiciones, ambiente requerido, datos de prueba, rol necesario, pasos con resultado esperado, criterio de aprobación, evidencia requerida y tipo de ejecución.

• CA-141

> Dado un caso de uso que no está en estado Congelado > Cuando se intenta generar escenarios a partir de él > Entonces el sistema lo impide y explica que solo se generan escenarios desde casos de uso congelados.

• CA-142

> Dado un escenario al que le falta al menos un campo obligatorio > Cuando se intenta pasarlo a Aprobado > Entonces el sistema lo impide y señala qué campos faltan.

• CA-143

> Dado un escenario completo cuyo caso de uso de origen no está en Congelado > Cuando se intenta pasarlo a Aprobado > Entonces el sistema lo impide e indica qué caso de uso falta congelar, aunque el escenario se haya creado a mano.

• CA-144

> Dado un caso de uso congelado sin ningún escenario aprobado que lo cubra > Cuando se consulta la matriz de cobertura > Entonces la matriz muestra la relación caso de uso ↔ escenarios en ambos sentidos y señala explícitamente ese caso como hueco de cobertura de diseño.

• CA-145

> Dado un conjunto de escenarios revisados sobre casos congelados > Cuando el usuario los envía a revisión tras la generación > Entonces el sistema emite test_plan.generated.

Dependencias y bloqueos

• HU-010 (revisar y congelar un caso de uso) provee los casos Congelado que esta HU

exige.

• HU-011 (versión nueva de un caso congelado) marca escenarios como desactualizados

(RN-024, RN-037); el indicador se gestiona aquí.

• HU-013 (aprobar el plan) consume los escenarios en Aprobado.
• HU-026 (orquestación de IA) provee la generación asistida.

Casos borde / notas. El tipo de ejecución es informativo en el MVP: no habilita automatización, que es [Fase 3]. La matriz mide cobertura de diseño —si existe prueba diseñada—, no si se ejecutó (RF-054, DEC-049).

HU-013 — Aprobar el plan de pruebas

Sprint/Épica: S3 · Plan de pruebas y ambientes · Bloque: E · Deriva de: CU-010 · Cubre: RF-051–RF-053 · Reglas: RN-033, RN-034, RN-035 · Estado: Borrador

Historia

Como Product Manager, quiero aprobar el plan de pruebas antes de que se ejecute, para dar por bueno que lo que se va a probar responde al requerimiento y habilitar la apertura de ciclos.

Objetivo / valor. La IA propone y el equipo itera, pero la ejecución solo arranca cuando el PM aprueba. Modificar un plan aprobado lo devuelve a aprobación sin frenar lo que ya está en curso.

Alcance

• Dentro: la revisión y aprobación del plan por el PM, la aprobación con huecos conocidos,

la devolución con observaciones y la reapertura automática al modificar un plan aprobado.

• Fuera: la generación y edición de escenarios (HU-012), la apertura de ciclos (HU-015) y

la ejecución (HU-016).

Actores y permisos

Precondiciones

• El plan está en Pendiente de aprobación con al menos un escenario en Aprobado.
• El usuario tiene rol Product Manager en el proyecto.

Comportamiento funcional

• Principal. El PM revisa escenarios, criterios de aceptación, prioridades y matriz de

cobertura; el sistema destaca los casos congelados sin cobertura. El PM aprueba; el plan pasa a Aprobado, habilitando la apertura de ciclos. El sistema emite test_plan.approved.

• Alternativo A1 — devolver con observaciones. El PM devuelve el plan a Borrador

indicando qué falta; los escenarios conservan sus estados individuales.

• Alternativo A2 — aprobar con huecos conocidos. El PM aprueba aunque haya casos sin

cobertura; el sistema lo permite y deja constancia de qué quedó descubierto al momento de aprobar.

• Error E1 — el usuario no es Product Manager. El sistema rechaza la aprobación (RN-033).
• Error E2 — se modifica un plan aprobado. Agregar o cambiar un escenario devuelve el plan

a Pendiente de aprobación, indicando qué cambió; los ciclos ya abiertos continúan (RN-035).

Datos y campos (funcional)

• Captura el PM: la decisión de aprobar o devolver, y —en la devolución— las observaciones.
• Deriva el sistema: el estado del plan, la constancia de los huecos conocidos al momento de

aprobar y el registro de qué cambió al reabrirse.

Reglas de negocio aplicables

• RN-033 — solo el Product Manager aprueba el plan; habilita la ejecución.
• RN-034 — solo se ejecutan escenarios en Aprobado dentro de un plan aprobado; la

apertura de un ciclo exige plan aprobado.

• RN-035 — agregar o modificar escenarios en un plan aprobado lo devuelve a

Pendiente de aprobación; los ciclos ya abiertos siguen con los escenarios que estaban aprobados al abrirse.

Estados y transiciones. Sigue la máquina de estados del plan de pruebas: Pendiente de aprobación → Aprobado (aprueba el PM) y Aprobado → Pendiente de aprobación (se agrega o modifica un escenario). La devolución con observaciones lleva a Borrador.

Eventos que emite. test_plan.approved.

Criterios de aceptación

• CA-146

> Dado un plan en Pendiente de aprobación con al menos un escenario Aprobado > Cuando el Product Manager lo aprueba > Entonces el plan pasa a Aprobado, queda habilitada la apertura de ciclos y se emite test_plan.approved.

• CA-147

> Dado un usuario que no es Product Manager > Cuando intenta aprobar el plan > Entonces el sistema rechaza la aprobación.

• CA-148

> Dado un plan en estado Aprobado con uno o más ciclos abiertos > Cuando se agrega o modifica un escenario > Entonces el plan vuelve a Pendiente de aprobación indicando qué cambió, y los ciclos ya abiertos continúan.

• CA-149

> Dado un plan con casos de uso congelados sin cobertura de diseño > Cuando el Product Manager aprueba a pesar de los huecos > Entonces el sistema lo permite y deja constancia de qué quedó descubierto al momento de aprobar.

Dependencias y bloqueos

• HU-012 (generar el plan) provee los escenarios Aprobado que la aprobación exige.
• HU-015 (abrir un ciclo) depende de que el plan esté Aprobado (RN-034).

Casos borde / notas. Un plan aprobado que vuelve a Pendiente de aprobación no interrumpe los ciclos en curso ni impide la ejecución fuera de ciclo de un escenario que siga Aprobado (RN-034, DEC-055); lo único que se bloquea es abrir un ciclo nuevo.

HU-014 — Registrar y preparar un ambiente de prueba

Sprint/Épica: S3 · Plan de pruebas y ambientes · Bloque: F · Deriva de: CU-011 · Cubre: RF-057–RF-067 · Reglas: RN-012, RN-026, RN-027, RN-028, RN-029, RN-030 · Decisiones: DEC-026, DEC-046 · Estado: Borrador

Historia

Como QA, quiero registrar un ambiente con todo lo necesario para ejecutar el plan y reproducir la ejecución después, para que cualquiera pueda probar sobre una configuración conocida y ningún fallo quede sin poder atribuirse a cómo estaba el ambiente.

Objetivo / valor. Dejar por escrito accesos, conexiones, configuración, datos y dependencias, sin guardar jamás el valor de un secreto, y con un checklist de readiness que advierte pero no frena. El registro no se versiona: su rastro histórico son los snapshots que toman los ciclos.

Alcance

• Dentro: registro y edición del ambiente, tipificación, datos de acceso, credenciales

como referencia al vault, detección de secretos en texto plano, conexiones y dependencias externas, configuración de ejecución, datos de prueba, dependencias previas, checklist de readiness, clonado, actualización de la versión bajo prueba, y la advertencia de readiness y la captura del snapshot al abrir un ciclo.

• Fuera: la apertura del ciclo en sí (HU-015), la ejecución (HU-016) y el diseño del

contrato con el vault (documentado, no diseñado — depende de PA-008).

Actores y permisos

La resolución del valor de un secreto la hace el usuario contra el vault con sus propias credenciales (▲³ de roles y permisos, RN-026); la plataforma solo muestra la referencia.

Precondiciones

• El usuario tiene rol en el proyecto.
• Existe un vault de secretos donde viven los valores de las credenciales (PA-008).

Comportamiento funcional

• Principal. El usuario registra un ambiente y elige su tipo —Local, Desarrollo, QA,

Staging, Producción controlada o Servidor externo—; registra URLs, endpoints y servidores; declara las credenciales necesarias como referencias al vault (identificador del secreto, ubicación y responsable de entregarlo); registra conexiones (base de datos, APIs internas y externas, autenticación, storage, colas y terceros); la configuración de ejecución (variables, feature flags, parámetros por cliente, versiones de servicios y la referencia de código bajo prueba: branch, commit, tag o release candidate); documenta los datos de prueba (usuarios, roles, permisos, registros base, fixtures y seeds) y las dependencias previas (migraciones, jobs, integraciones, servicios levantados y accesos validados); recorre el checklist de readiness y marca cada verificación.

• Alternativo A1 — clonar un ambiente. El usuario duplica un ambiente existente del mismo

proyecto y ajusta lo que cambia.

• Alternativo A2 — actualizar la versión bajo prueba. Entre un ciclo y otro se actualiza el

commit o release candidate; los ciclos ya abiertos conservan su snapshot (RN-029).

• Error E1 — secreto en texto plano. El sistema detecta un valor que aparenta ser una

credencial en un campo de texto libre y rechaza el guardado, explicando que solo se admiten referencias (RN-027).

• Error E2 — checklist incompleto al abrir un ciclo. El sistema advierte, no bloquea, y deja

constancia del estado del checklist en el ciclo (RN-028).

Datos y campos (funcional, no esquema)

• Identificación: nombre y tipo (Local, Desarrollo, QA, Staging,

Producción controlada, Servidor externo).

• Acceso: URLs, endpoints y servidores.
• Credenciales (solo referencia): identificador del secreto en el vault, ubicación y

responsable de entregarlo. Nunca el valor.

• Conexiones: base de datos, APIs internas y externas, autenticación, storage, colas,

terceros.

• Configuración de ejecución: variables, feature flags, parámetros por cliente, versiones de

servicios y referencia de código bajo prueba (branch, commit, tag o release candidate).

• Datos de prueba: usuarios, roles, permisos, registros base, fixtures y seeds.
• Dependencias previas: migraciones aplicadas, jobs ejecutados, integraciones habilitadas,

servicios levantados y accesos validados.

• Checklist de readiness: login funcional, servicios disponibles, conectividad, datos

mínimos presentes, permisos correctos e integraciones sincronizando.

Reglas de negocio aplicables

• RN-012 / RN-026 — Argos QA no almacena el valor de ningún secreto; las credenciales se

registran exclusivamente como referencia al vault (identificador, ubicación, responsable).

• RN-027 — el sistema rechaza los valores que aparenten ser credenciales en campos de

texto libre; ante la duda, rechaza.

• RN-028 — un checklist de readiness incompleto no impide abrir un ciclo, pero la

advertencia y el estado del checklist quedan registrados en el ciclo.

• RN-029 / DEC-046 — el ambiente no se versiona; al abrir un ciclo se captura un snapshot

inmutable de su configuración, y los cambios posteriores no alteran el snapshot de un ciclo ya abierto. El historial del ambiente son esos snapshots.

• RN-030 — un ambiente pertenece a un único proyecto; no se comparten entre proyectos

aunque apunten a la misma infraestructura.

Estados y transiciones. El ambiente no tiene máquina de estados: es un registro editable y no versionado (RF-057, DEC-046). Lo que se congela es el snapshot que toma cada ciclo, no el ambiente.

Integraciones (documentado, el dev implementa)

• Vault de secretos — el ambiente guarda solo la referencia (identificador, ubicación,

responsable); el valor se resuelve fuera de Argos QA, contra el vault, con las credenciales del propio usuario. El contrato fino (qué vault, cómo se referencia y se resuelve) se cierra con PA-008; el comportamiento local —guardar referencias y rechazar valores en claro— no depende de esa respuesta.

Eventos que emite. Ninguno en el MVP para el registro del ambiente. El snapshot se emite como parte de la apertura del ciclo (HU-015, RF-067).

Criterios de aceptación

• CA-170

> Dado un usuario con rol en el proyecto > Cuando registra un ambiente con su tipo, URLs y endpoints, conexiones, configuración de ejecución, datos de prueba y dependencias previas > Entonces el ambiente queda guardado y editable, asociado a un único proyecto.

• CA-171

> Dado que el ambiente requiere una credencial > Cuando el usuario la declara como identificador del secreto, ubicación y responsable de entregarlo > Entonces el sistema guarda solo la referencia al vault y en ningún momento almacena el valor del secreto.

• CA-172

> Dado un campo de texto libre del ambiente con un valor que aparenta ser una credencial > Cuando el usuario intenta guardar > Entonces el sistema rechaza el guardado y explica que solo se admiten referencias al vault.

• CA-173

> Dado un ambiente con el checklist de readiness incompleto > Cuando se abre un ciclo sobre él > Entonces el sistema advierte de forma explícita, no lo impide, y deja constancia del estado del checklist en el ciclo.

• CA-174

> Dado un ciclo abierto que capturó el snapshot de un ambiente > Cuando el ambiente se edita después > Entonces el snapshot del ciclo ya abierto no cambia, porque el ambiente no se versiona y su historial son los snapshots de los ciclos.

• CA-175

> Dado un ambiente existente del mismo proyecto > Cuando el usuario lo clona > Entonces el sistema crea un ambiente nuevo con la misma configuración, que el usuario ajusta en lo que cambia.

• CA-176

> Dado un ambiente cuya referencia de código bajo prueba se actualiza entre un ciclo y otro > Cuando se cambia el commit o release candidate > Entonces los ciclos ya abiertos conservan su snapshot y solo los ciclos nuevos toman la versión actualizada.

Dependencias y bloqueos

• PA-008 (vault de secretos) — condiciona el contrato de referencia y resolución de

secretos; el comportamiento local no depende de él.

• HU-015 (abrir un ciclo) captura el snapshot del ambiente (RF-067) y dispara la

advertencia de readiness.

Casos borde / notas. El tipo de ejecución del ambiente no restringe el tipo de escenario; son ejes independientes. Un checklist incompleto nunca bloquea: la decisión de arrancar igual, y su costo, quedan visibles en el ciclo para poder atribuir un fallo posterior a un ambiente mal preparado (RN-028).

HU-025 — Emitir eventos de dominio y notificar

Sprint/Épica: S3 · Plan de pruebas y ambientes · Bloque: K · Deriva de: Transversal · Cubre: RF-117–RF-123 · Reglas: RN-069, RN-070, RN-071, RN-072 · Decisiones: DEC-012, DEC-043, DEC-050 · Estado: Borrador

Historia

Como plataforma, quiero emitir cada hito del proceso como un evento de dominio, publicarlo sin pérdida y reflejarlo en vivo en el frontend, para que el equipo se entere de lo que pasa en el momento en que pasa, sin que la notificación ponga en riesgo la operación que la originó.

Objetivo / valor. Que los cambios relevantes —un caso congelado, un escenario fallido, un bug abierto— se propaguen de forma confiable a notifications.flagare y a la vista del usuario, con entrega garantizada e idempotente, y sin que el Client vea en vivo lo que no le corresponde.

Alcance

• Dentro: el catálogo de eventos de dominio, la emisión como efecto de otras HU, la cola

de salida persistente con reintento, la publicación por API hacia notifications.flagare, la entrega en vivo por SSE con reconexión y recuperación, la autorización del canal y la idempotencia por identificador único.

• Fuera: qué dispara cada evento en particular (eso vive en la HU que lo emite), el

contrato fino del payload y del transporte SSE (documentado, no diseñado; PA-009), y la lógica interna de notifications.flagare.

Actores y permisos (comportamiento del sistema)

• Los eventos los emite el sistema, no un rol; ninguna acción de usuario publica un

evento directamente.

• La suscripción al canal en vivo se autoriza por rol de proyecto: un usuario recibe

solo eventos de proyectos donde tiene rol asignado.

• El rol Client nunca se suscribe al canal de eventos, en ninguna circunstancia; su

vista se refresca por consulta (RN-071, DEC-043).

Precondiciones

• Ocurre una operación de negocio que, según su HU, emite un evento del catálogo.
• Para la entrega en vivo: el usuario tiene una sesión autenticada con el JWT de Flagare y

rol asignado en el proyecto del evento.

Comportamiento funcional

• Principal. La operación de negocio que origina el hito **persiste su evento antes de

publicarlo**: el evento entra en una cola de salida persistente con un identificador único. Un despachador lo publica mediante la API de notifications.flagare y, en paralelo, lo entrega por SSE a los suscriptores autorizados del proyecto. El commit de la operación de negocio no depende de que la publicación tenga éxito.

• Alternativo A1 — entrega en vivo. Un usuario con rol en el proyecto abre el canal SSE y

recibe los eventos del proyecto en tiempo real, sin recargar la vista.

• Alternativo A2 — reconexión. Si el canal SSE se cae, el cliente reconecta de forma

automática y el sistema le reentrega los eventos ocurridos durante la desconexión, sin huecos (RN-070).

• Error E1 — notifications.flagare no responde. El evento permanece en la cola y se

reintenta; la operación de negocio no falla ni se revierte, y ningún evento se pierde (RN-069).

• Error E2 — reintento y duplicados. Un reintento puede reentregar un evento ya recibido;

el identificador único permite al consumidor descartar el duplicado (RN-072). La emisión es idempotente por diseño.

• Error E3 — suscripción de un Client. El sistema **rechaza el establecimiento de la

suscripción** de un usuario cuyo único rol en el proyecto es Client. La exclusión se aplica al abrir el canal, no filtrando el payload (RN-071, DEC-043).

Datos y campos (funcional, no esquema)

• Del evento: identificador único, tipo de evento (del catálogo de RF-117), proyecto,

artefacto afectado, autor u origen de la operación, timestamp.

• De la cola de salida: estado de publicación (pendiente, publicado, en reintento),

número de reintentos.

• Del canal: usuario suscriptor, proyectos autorizados, punto de recuperación tras

desconexión.

Catálogo de eventos (RF-117, DEC-050)

requirement.ingested, use_case.generated, use_case.frozen, use_case.obsoleted, test_plan.generated, test_plan.approved, test_case.failed, test_case.blocked, bug.created, bug.assigned, bug.ready_for_retest, bug.reopened, blocker.created, blocker.resolved, cycle.completed, quality_report.generated.

El congelamiento —no la validación— es el hito con consecuencias externas: el catálogo usa use_case.frozen en lugar de use_case.approved, y el paso a Validado no emite evento (RN-069, DEC-050). use_case.obsoleted se incluye porque la obsolescencia invalida artefactos derivados.

Reglas de negocio aplicables

• RN-069 — el evento se persiste antes de publicarse; su emisión nunca hace fallar la

operación de negocio ni se pierde por indisponibilidad del consumidor.

• RN-070 — el canal en vivo reconecta solo y recupera los eventos perdidos durante la

desconexión.

• RN-071 / RN-061 / DEC-043 — la suscripción al canal se autoriza por rol de proyecto y

se rechaza para el Client, que se refresca por consulta.

• RN-072 — cada evento lleva un identificador único para descartar duplicados de

reintento.

Estados y transiciones. No aplica una máquina de estados de dominio; el único ciclo relevante es el interno del elemento en la cola de salida: Pendiente → Publicado, con En reintento ante fallo del consumidor.

Integraciones (documentado, el dev implementa)

• notifications.flagare — recibe los eventos publicados por su API. Qué se toca:

publicación de cada evento del catálogo. El contrato fino (forma del payload, quién expone el SSE, autenticación del canal, comportamiento ante desconexión) se cierra con PA-009; el comportamiento local —cola persistente, reintento, no pérdida— no depende de ella.

• SSE (canal en vivo del frontend) — entrega los eventos en tiempo real a los

suscriptores autorizados, con reconexión y recuperación. Documentado a nivel funcional; el dev lo implementa.

Eventos que emite. Los del catálogo de RF-117; cada uno lo dispara la HU dueña del hito (por ejemplo, bug.created en HU-020, use_case.frozen en HU-010, cycle.completed en HU-022). Esta HU no origina eventos propios: define cómo se emiten, publican y entregan.

Criterios de aceptación

• CA-340

> Dado una operación de negocio que emite un evento de dominio > Cuando la operación se confirma > Entonces el evento se persiste con un identificador único en la cola de salida antes de publicarse, y el commit de la operación no depende de la publicación.

• CA-341

> Dado un evento persistido en la cola y notifications.flagare disponible > Cuando el despachador lo publica > Entonces el evento se entrega por la API de notifications.flagare y queda marcado como publicado.

• CA-342

> Dado un evento persistido y notifications.flagare sin responder > Cuando falla la publicación > Entonces el evento permanece en la cola con reintento, la operación de negocio no se revierte y ningún evento se pierde.

• CA-343

> Dado un reintento que reentrega un evento ya recibido > Cuando el consumidor lo procesa > Entonces el identificador único le permite descartarlo como duplicado.

• CA-344

> Dado un usuario con rol asignado en un proyecto > Cuando abre el canal SSE > Entonces recibe en vivo únicamente los eventos de los proyectos donde tiene rol.

• CA-345

> Dado un canal SSE que se cae durante una sesión activa > Cuando el cliente reconecta > Entonces el sistema reentrega los eventos ocurridos durante la desconexión, sin huecos.

• CA-346

> Dado un usuario cuyo único rol en el proyecto es Client > Cuando intenta establecer la suscripción al canal de eventos en vivo > Entonces el sistema rechaza el establecimiento de la suscripción y su vista se refresca por consulta.

Dependencias y bloqueos

• PA-009 (contrato de notifications.flagare y del SSE) — condiciona el payload, el

transporte y la autenticación del canal; el comportamiento local —catálogo, cola persistente, reintento, idempotencia, no pérdida— no depende de ella.

• Cada HU emisora del catálogo (HU-006 a HU-022) es dependiente: esta HU es la mecánica

común que todas invocan.

Casos borde / notas. La exclusión del Client se aplica al abrir la suscripción, no filtrando el payload de un canal ya abierto: el canal en vivo revelaría por sí mismo que un escenario falló o que se abrió un bug, así que el Client nunca lo abre (RN-071). El paso de un caso de uso a Validado es un trámite interno del equipo y no emite evento; el hito que se propaga es el congelamiento.