Sprint S5 — Cierre: bugs, bloqueos, reportes y portal cliente

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

Demo al cierre: un fallo genera un bug hacia Operaciones; registro y resuelvo bloqueos; reejecuto tras la corrección; cierro el ciclo con su reporte de calidad; consulto el dashboard y el Client ve su reporte agregado. · Bloques funcionales: G (parcial), I, J.

HU-020 — Registrar un bug desde un fallo

Sprint/Épica: S5 · Cierre: bugs, bloqueos, reportes y portal cliente · Bloque: I · Deriva de: CU-014 · Cubre: RF-077, RF-092–RF-100 · Reglas: RN-051, RN-052, RN-053, RN-054, RN-056, RN-083 · Decisiones: DEC-033, DEC-052 · Estado: Borrador

Historia

Como Developer, quiero registrar un bug desde un paso fallido de una ejecución, para dejar un defecto reproducible y trazado hasta el requerimiento que lo originó, y ponerlo en el flujo de trabajo del equipo.

Objetivo / valor. Que ningún hallazgo se pierda ni quede sin contexto: el bug nace con toda la cadena de trazabilidad ya adjunta y con su ticket espejo en Argos Operaciones.

Alcance

• Dentro: creación desde un paso Fail, precarga de contexto inmutable, captura de los

datos del defecto, creación del ticket espejo, asignación y emisión del evento.

• Fuera: resolución y reejecución (HU-018), edición de la ejecución origen (es

inmutable), y el diseño del mapeo de campos bug→ticket (documentado, no diseñado).

Actores y permisos

Precondiciones

• Existe una ejecución con al menos un paso en Fail (para el flujo principal).
• El usuario tiene rol PM, QA o Developer en el proyecto.

Comportamiento funcional

• Principal. Desde el paso fallido, el sistema precarga el contexto no editable

(escenario, caso de uso y versión, paso, ciclo, ambiente, snapshot, referencia de código bajo prueba, ejecutor, timestamp, evidencia adjunta); el usuario completa los datos del defecto; el bug se guarda en Nuevo con sincronización Pendiente; el sistema crea el ticket espejo en Argos Operaciones, enlaza ambos de forma permanente y pasa la sincronización a Sincronizado; emite bug.created.

• Alternativo A1 — bug independiente. Sin partir de una ejecución; el usuario aporta

manualmente el contexto no heredable; sigue rigiendo la evidencia obligatoria.

• Alternativo A2 — asignación. A un miembro PM/QA/Developer; el bug pasa a Asignado;

emite bug.assigned y notifica.

• Error E1 — Argos Operaciones no responde. El bug queda local con sincronización

Pendiente y reintento automático acotado; el ejecutor no se bloquea ni pierde el hallazgo.

• Error E2 — reintentos agotados. La sincronización pasa a Error, visible, con opción de

reintento manual.

• Error E3 — sin evidencia. El sistema rechaza el registro.

Datos y campos (funcional, no esquema)

• Precargado inmutable: escenario, CU + versión, paso, ciclo, ambiente, snapshot,

referencia de código, ejecutor, timestamp, evidencia previa.

• Captura el usuario: título, descripción, severidad, pasos para reproducir, resultado

esperado, resultado obtenido, evidencia adicional (opcional).

Reglas de negocio aplicables

• RN-052 — sin evidencia no se registra el bug (incluido el independiente).
• RN-053 / RN-054 — ticket espejo automático y enlace permanente; con Argos Operaciones

caído, sincronización diferida con reintento.

• RN-051 / RN-056 — el bug hereda la cadena de trazabilidad hasta el requerimiento.
• RN-083 — un Client nunca es destinatario de asignación.

Estados y transiciones. Sigue la máquina de estados del bug: Nuevo → Asignado → …. La asignación es condición para salir de Nuevo (DEC-052).

Integraciones (documentado, el dev implementa)

• Argos Operaciones — crea el ticket espejo y mantiene el enlace permanente. El contrato

fino (endpoint, mapeo de campos) se cierra con PA-006 y PA-016; el comportamiento local no depende de ellas.

Eventos que emite. bug.created; bug.assigned al asignar.

Criterios de aceptación

• CA-270

> Dado un paso de ejecución en estado Fail > Cuando el Developer crea un bug desde ese paso y aporta título, severidad, pasos, esperado y obtenido con al menos un elemento de evidencia > Entonces el bug queda en Nuevo con sincronización Pendiente, con el contexto de la ejecución precargado y no editable.

• CA-271

> Dado un bug recién guardado y Argos Operaciones disponible > Cuando el sistema crea el ticket espejo > Entonces ambos quedan enlazados de forma permanente, la sincronización pasa a Sincronizado y se emite bug.created.

• CA-272

> Dado un intento de registrar un bug sin ningún elemento de evidencia > Cuando el usuario confirma el registro > Entonces el sistema lo rechaza e indica que la evidencia es obligatoria.

• CA-273

> Dado un bug guardado y Argos Operaciones sin responder > Cuando se agotan los reintentos automáticos > Entonces la sincronización queda en Error, visible, con opción de reintento manual, sin que el hallazgo se pierda.

• CA-274

> Dado un bug en Nuevo > Cuando se intenta asignarlo a un usuario con rol Client > Entonces el sistema lo impide.

Dependencias y bloqueos

• PA-006 (API de Argos Operaciones) y PA-016 (mapeo bug→ticket) — condicionan el

contrato del ticket espejo; el comportamiento local no depende de ellas.

• HU-018 (reejecutar tras corrección) consume el estado del bug.

HU-021 — Registrar y resolver un bloqueo

Sprint/Épica: S5 · Cierre: bugs, bloqueos, reportes y portal cliente · Bloque: I · Deriva de: CU-015 · Cubre: RF-078, RF-101–RF-105, RF-140 · Reglas: RN-039, RN-057, RN-058 · Decisiones: DEC-032, DEC-045 · Estado: Borrador

Historia

Como QA, quiero registrar un impedimento como un bloqueo con dueño y ciclo de vida propio, para distinguir lo que impide probar de lo que está defectuoso, y que ninguna de las dos cosas contamine la lectura de la otra.

Objetivo / valor. El bloqueo no se diluye en un comentario: es una entidad con tipo, responsable e impacto, y al resolverse libera automáticamente lo que dependía de él.

Alcance

• Dentro: creación del bloqueo al marcar una ejecución Blocked, su gestión y

resolución, y la liberación de las ejecuciones afectadas.

• Fuera: la ejecución en sí (HU-016) y el registro de bugs (HU-020); un bloqueo no es un

defecto.

Actores y permisos

Precondiciones

• Existe un impedimento que impide ejecutar uno o más escenarios.

Comportamiento funcional

• Principal. Al marcar una ejecución como Blocked, el sistema exige asociar un bloqueo;

el usuario crea uno nuevo o selecciona uno existente. Al crearlo indica tipo —Ambiente, Datos, Acceso, Dependencia externa, Definición pendiente—, descripción, responsable e impacto. El bloqueo queda Abierto y vinculado a la ejecución; se emiten blocker.created y test_case.blocked. Cuando alguien se hace cargo pasa a En gestión; al desaparecer el impedimento se marca Resuelto y el sistema pasa a Retest required todas las ejecuciones que dependían de él, emitiendo blocker.resolved.

• Alternativo A1 — alcance múltiple. Un mismo bloqueo se asocia a varias ejecuciones; al

resolverse, todas se liberan a la vez.

• Alternativo A2 — bloqueo descartado. Si no era un bloqueo real, las ejecuciones vuelven a

Not run (no a Retest required); el sistema advierte que se marcaron Blocked sin causa válida y el Blocked descartado permanece en el historial (RN-058, DEC-045).

• Error E1 — Blocked sin bloqueo. El sistema impide registrar el resultado Blocked si

no se asocia un bloqueo (RN-039).

Datos y campos (funcional)

• Captura el usuario: tipo, descripción, responsable, impacto.
• Deriva el sistema: ejecuciones y escenarios vinculados, estado del bloqueo, marcas de

tiempo de cada transición.

Reglas de negocio aplicables

• RN-039 — un resultado Blocked exige un bloqueo asociado.
• RN-057 — el bloqueo es una entidad con dueño y ciclo de vida propio.
• RN-058 / DEC-045 — al descartar un bloqueo las ejecuciones vuelven a Not run, y el

Blocked inválido queda registrado como señal de mal uso.

Estados y transiciones. Sigue la máquina de estados del bloqueo: Abierto → En gestión → Resuelto, con salida lateral Descartado.

Eventos que emite. blocker.created, test_case.blocked, blocker.resolved.

Criterios de aceptación

• CA-275

> Dado una ejecución que el usuario marca como Blocked > Cuando confirma el resultado sin asociar ningún bloqueo > Entonces el sistema lo impide y exige crear o seleccionar un bloqueo.

• CA-276

> Dado un impedimento real > Cuando el QA crea un bloqueo con tipo, descripción, responsable e impacto > Entonces el bloqueo queda Abierto, vinculado a la ejecución, y se emiten blocker.created y test_case.blocked.

• CA-277

> Dado un bloqueo Abierto o En gestión asociado a varias ejecuciones > Cuando se marca Resuelto > Entonces todas las ejecuciones dependientes pasan a Retest required y se emite blocker.resolved.

• CA-278

> Dado un bloqueo que se determina que no era real > Cuando se descarta > Entonces las ejecuciones asociadas vuelven a Not run, el sistema advierte el uso indebido de Blocked y el estado descartado queda en el historial.

Dependencias y bloqueos

• HU-016 (ejecución guiada) origina el Blocked que dispara esta HU.
• HU-018 (reejecución) consume las ejecuciones liberadas a Retest required.

Casos borde / notas. Un bloqueo resuelto no reabre por sí solo; si el impedimento reaparece se registra un bloqueo nuevo. La diferencia entre descartar (nunca fue bloqueo) y resolver (dejó de serlo) es la que decide si las ejecuciones van a Not run o a Retest required.

HU-018 — Reejecutar tras una corrección

Sprint/Épica: S5 · Cierre: bugs, bloqueos, reportes y portal cliente · Bloque: G · Deriva de: CU-016 · Cubre: RF-079, RF-080, RF-098, RF-099 · Reglas: RN-040, RN-041, RN-044, RN-055 · Estado: Borrador

Historia

Como Developer, quiero reejecutar un escenario que falló, una vez corregido el defecto, creando un registro nuevo sin borrar el anterior, para confirmar con evidencia que la corrección funciona sin perder la constancia de que antes falló.

Objetivo / valor. La corrección no borra la historia. Reejecutar crea un registro nuevo; el fallo original queda intacto. Passed after fix distingue una aprobación tras corregir de una que pasó a la primera: no son la misma señal de calidad.

Alcance

• Dentro: disparo del retest cuando un bug pasa a Listo para retest, paso de las

ejecuciones fallidas a Retest required, reejecución que crea un registro nuevo, y desenlace según el resultado (Passed after fix, Fail con reapertura del bug, o Blocked), incluida la reapertura tardía de un bug ya cerrado.

• Fuera: la ejecución guiada en sí (HU-016, que esta HU invoca), el registro del bug

(HU-020) y la resolución del bloqueo (HU-021, que también libera ejecuciones a Retest required).

Actores y permisos

Precondiciones

• Existe un bug en estado Listo para retest, o un bloqueo recién resuelto (HU-021).
• Existe al menos una ejecución fallida asociada al bug.

Comportamiento funcional

• Principal. El desarrollador marca el bug como Listo para retest. El sistema emite

bug.ready_for_retest y pasa a Retest required las ejecuciones fallidas que lo originaron. El ejecutor abre el escenario y lo ejecuta nuevamente siguiendo el flujo guiado (HU-016). El sistema crea un registro de ejecución nuevo; el anterior se conserva intacto e inmutable. Si el resultado es conforme, el escenario queda en Passed after fix y el bug puede pasar a Resuelto.

• Alternativo A1 — el retest vuelve a fallar. El escenario queda en Fail y el bug pasa a

Reabierto. El sistema emite bug.reopened.

• Alternativo A2 — aparece un impedimento nuevo. El escenario pasa a Blocked con su

bloqueo asociado (HU-021, RN-039).

• Alternativo A3 — reapertura tardía. Un bug ya Cerrado reaparece. La reapertura exige

motivo y evidencia nueva; sin ambos, el sistema la impide (RN-055). El sistema emite bug.reopened.

• Error E1 — intento de editar la ejecución fallida original. El sistema lo rechaza: las

ejecuciones son inmutables. La corrección se refleja reejecutando, con ambos registros visibles (RN-040, RN-044).

Datos y campos (funcional, no esquema)

• Captura el usuario: marca de Listo para retest; en la reapertura tardía, motivo y

evidencia nueva; luego el flujo de resultado por paso y evidencia de HU-016.

• Deriva el sistema: transición de las ejecuciones fallidas a Retest required, registro

de ejecución nuevo enlazado al escenario, estado resultante del escenario (Passed after fix, Fail o Blocked), transición del bug (Resuelto o Reabierto).

Reglas de negocio aplicables

• RN-040 / RN-044 — la reejecución crea un registro nuevo; nunca sobrescribe ni edita el

anterior. El error de un registro se corrige reejecutando, dejando ambos visibles.

• RN-041 — cuando el bug pasa a Listo para retest, las ejecuciones fallidas que lo

originaron pasan a Retest required.

• RN-055 — la reapertura de un bug exige motivo y evidencia nueva.

Estados y transiciones. El escenario sigue la máquina de ejecución: Fail → Retest required (por bug listo para retest, RN-041), y desde Retest required a Passed after fix (conforme), Fail (no conforme) o Blocked (nuevo impedimento). El bug sigue su máquina: Listo para retest → Resuelto o → Reabierto, y Cerrado → Reabierto con motivo y evidencia (RN-055).

Integraciones (documentado, el dev implementa)

• S3 — evidencia de la reejecución y de la reapertura, igual que HU-016/HU-019.
• Argos Operaciones — la transición del bug se refleja en su ticket espejo enlazado; el

contrato fino se cierra con PA-006 (ver HU-020). El comportamiento local no depende de él.

Eventos que emite. bug.ready_for_retest al marcar el bug listo para retest; bug.reopened cuando el retest vuelve a fallar o cuando un bug cerrado se reabre.

Criterios de aceptación

• CA-213

> Dado un bug con ejecuciones fallidas asociadas > Cuando el desarrollador lo marca como Listo para retest > Entonces el sistema emite bug.ready_for_retest y pasa a Retest required las ejecuciones fallidas que lo originaron.

• CA-214

> Dado un escenario en Retest required > Cuando el ejecutor lo reejecuta con evidencia > Entonces el sistema crea un registro de ejecución nuevo y conserva intacto e inmutable el registro de la ejecución fallida anterior.

• CA-215

> Dado una reejecución con resultado conforme > Cuando el sistema la registra > Entonces el escenario queda en Passed after fix y el bug puede pasar a Resuelto.

• CA-216

> Dado una reejecución que vuelve a fallar > Cuando el sistema la registra > Entonces el escenario queda en Fail, el bug pasa a Reabierto y se emite bug.reopened.

• CA-217

> Dado un bug en estado Cerrado que reaparece > Cuando el usuario intenta reabrirlo sin aportar motivo y evidencia nueva > Entonces el sistema impide la reapertura hasta que ambos se aporten.

• CA-218

> Dado un bug Cerrado que reaparece > Cuando el usuario lo reabre con motivo y evidencia nueva > Entonces el sistema lo reabre y emite bug.reopened.

• CA-219

> Dado la ejecución fallida original de un escenario > Cuando un usuario intenta editarla para reflejar la corrección > Entonces el sistema lo rechaza: la ejecución es inmutable y la corrección se refleja reejecutando, con ambos registros visibles.

Dependencias y bloqueos

• HU-016 (ejecución guiada) provee el flujo de la reejecución.
• HU-020 (bug desde un fallo) aporta el bug cuyo cambio de estado dispara el retest.
• HU-021 (bloqueo) libera ejecuciones a Retest required por la vía del bloqueo resuelto

(RN-058), alternativa al bug listo para retest.

Casos borde / notas. Un Fail sin bug asociado puede pasar a Retest required por decisión de quien ejecuta, con un motivo escrito que queda en auditoría (RN-078, RF-079); esa vía es distinta de la de RN-041, que aplica a un Fail con bug. La reejecución puede ocurrir dentro del mismo ciclo (RF-079) o tras reabrir uno cerrado (HU-022); en ambos casos cada registro se conserva por separado.

HU-022 — Cerrar el ciclo y emitir el reporte de calidad

Sprint/Épica: S5 · Cierre: bugs, bloqueos, reportes y portal cliente · Bloque: J · Deriva de: CU-017 · Cubre: RF-081, RF-082, RF-106–RF-113 · Reglas: RN-045, RN-059, RN-060, RN-062, RN-063 · Estado: Borrador

Historia

Como QA, quiero cerrar el ciclo de pruebas y emitir un reporte formal de calidad, para dar por terminada la iteración y dejar una foto defendible e inmutable del estado de calidad.

Objetivo / valor. El cierre no es un botón silencioso: obliga a mirar lo que queda sin resolver antes de confirmarlo, y el reporte que produce queda anclado a las versiones congeladas vigentes, de modo que una versión posterior de un caso de uso no cambia lo que el reporte ya dijo.

Alcance

• Dentro: solicitud de cierre, resumen de estado, advertencia y confirmación explícita

ante escenarios sin cerrar, cierre del ciclo, generación del reporte formal anclado a versiones congeladas, reapertura auditada y reporte intermedio parcial.

• Fuera: la ejecución de escenarios (HU-016) y la gestión de bugs y bloqueos (HU-020,

HU-021); el formato y los medios de exportación del reporte, pendientes (PA-017).

Actores y permisos

Precondiciones

• Existe un ciclo en estado Abierto.

Comportamiento funcional

• Principal. El usuario solicita cerrar el ciclo. El sistema muestra el resumen: escenarios

aprobados, fallidos, bloqueados y sin ejecutar; bugs abiertos por severidad; bloqueos activos; huecos de cobertura de diseño. Si quedan escenarios en Not run, Retest required o Blocked, el sistema lo advierte y exige confirmación explícita. Un Fail puede quedar abierto al cierre: la advertencia obliga a mirarlo, no a resolverlo. El usuario confirma; el sistema cierra el ciclo y emite cycle.completed. El usuario genera el reporte formal, que el sistema produce con alcance, resultados, cobertura de diseño y ejecutada, evidencia referenciada, bugs pendientes y señales de riesgo de liberación, anclado a las versiones congeladas de los casos de uso vigentes en ese momento; emite quality_report.generated.

• Alternativo A1 — reabrir el ciclo. El usuario reabre un ciclo cerrado; el sistema registra

quién lo reabrió y por qué (RN-045). El reporte ya emitido no se altera.

• Alternativo A2 — reporte intermedio. El usuario genera un reporte sin cerrar el ciclo,

marcado como parcial.

• Error E1 — fallo al generar el reporte. El sistema informa y conserva el ciclo cerrado; el

reporte puede regenerarse.

Datos y campos (funcional, no esquema)

• Muestra el sistema al cerrar: conteo de escenarios por resultado, bugs abiertos por

severidad, bloqueos activos, huecos de cobertura de diseño.

• Captura el usuario: confirmación explícita del cierre con escenarios pendientes; motivo de

la reapertura.

• Contiene el reporte: alcance del ciclo, resultados, cobertura de diseño y ejecutada,

evidencia referenciada, bugs pendientes, señales de riesgo de liberación, y la referencia a las versiones congeladas de los casos de uso vigentes al generarse.

Reglas de negocio aplicables

• RN-045 — un ciclo cerrado no admite ejecuciones nuevas; para continuar hay que

reabrirlo, y la reapertura queda auditada.

• RN-059 — las ejecuciones Blocked no computan como fallo del producto en el porcentaje

de éxito; se reportan en su propia categoría.

• RN-060 — la cadena de trazabilidad del reporte se recorre completa: requerimiento → caso

de uso → escenario → criterio → ejecución → evidencia → bug → ticket → resolución.

• RN-062 — las métricas del ciclo se calculan solo sobre las ejecuciones pertenecientes a

ese ciclo; las de fuera de ciclo no computan.

• RN-063 — el reporte referencia siempre las versiones congeladas vigentes al generarse;

su contenido no cambia porque después se cree una versión nueva de un caso de uso.

Estados y transiciones. Sigue la máquina de estados del ciclo: Abierto → Cerrado, con reapertura Cerrado → Abierto auditada (RN-045). El reporte, una vez generado, es inmutable en contenido (RN-063).

Integraciones (documentado, el dev implementa)

• Ninguna integración externa propia. El reporte se emite dentro de Argos QA; el formato y los

destinos de exportación (por ejemplo alimentar a Flagare CAB Manager) quedan pendientes de PA-017.

Eventos que emite. cycle.completed al cerrar el ciclo; quality_report.generated al generar el reporte formal.

Criterios de aceptación

• CA-300

> Dado un ciclo Abierto con escenarios en Not run, Retest required o Blocked > Cuando el QA solicita cerrarlo > Entonces el sistema muestra el resumen de estado, advierte de los escenarios sin cerrar y exige confirmación explícita antes de cerrar.

• CA-301

> Dado un cierre confirmado > Cuando el sistema cierra el ciclo > Entonces el ciclo queda Cerrado, no admite ejecuciones nuevas y se emite cycle.completed.

• CA-302

> Dado un ciclo cerrado > Cuando el usuario genera el reporte formal de calidad > Entonces el sistema lo produce con alcance, resultados, cobertura de diseño y ejecutada, evidencia referenciada, bugs pendientes y señales de riesgo, anclado a las versiones congeladas vigentes, y emite quality_report.generated.

• CA-303

> Dado un reporte ya emitido > Cuando después se crea una versión nueva de un caso de uso que el reporte referenciaba > Entonces el contenido del reporte no cambia: sigue mostrando las versiones congeladas vigentes al momento de generarse.

• CA-304

> Dado un ciclo Cerrado > Cuando un usuario con permiso lo reabre > Entonces el sistema registra en auditoría quién lo reabrió y por qué, y el reporte ya emitido no se altera.

• CA-305

> Dado un ciclo aún Abierto > Cuando el usuario genera un reporte sin cerrarlo > Entonces el sistema lo produce marcado como parcial.

• CA-306

> Dado un fallo al generar el reporte > Cuando el sistema no logra producirlo > Entonces informa el error, conserva el ciclo cerrado y permite regenerar el reporte.

Dependencias y bloqueos

• PA-017 (formato exigido del reporte) — condiciona la plantilla y los formatos de

exportación; el contenido funcional del reporte no depende de él.

• HU-016 (ejecución) aporta las ejecuciones que el resumen y el reporte consolidan;

HU-023 consume las mismas métricas en vivo.

Casos borde / notas. Un Fail sin resolver no impide cerrar el ciclo: la advertencia obliga a mirarlo, no a resolverlo (RF-081). La diferencia entre reporte parcial (ciclo abierto) y reporte formal (ciclo cerrado) es visible en el propio reporte.

HU-023 — Consultar el dashboard de cobertura y avance

Sprint/Épica: S5 · Cierre: bugs, bloqueos, reportes y portal cliente · Bloque: J · Deriva de: Transversal · Cubre: RF-106–RF-112, RF-115, RF-116 · Reglas: RN-059, RN-060, RN-062 · Decisiones: DEC-049 · Estado: Borrador

Historia

Como miembro interno del proyecto (PM, QA o Developer), quiero un dashboard que muestre cobertura, avance, riesgo de liberación y consumo, para saber en todo momento en qué estado de calidad está el proyecto y qué desaconseja liberar.

Objetivo / valor. Concentra en una vista la lectura del estado de calidad: dos coberturas nombradas sin ambigüedad, un porcentaje de éxito que no confunde bloqueo con fallo, la navegación por la cadena de trazabilidad, y el costo de IA y storage que el proceso consume.

Alcance

• Dentro: dashboard del ciclo activo (totales, ejecutados, aprobados, fallidos,

bloqueados, pendientes); cobertura de diseño y cobertura ejecutada como dos indicadores nombrados; porcentaje de éxito; bugs por severidad y estado; avance por ejecutor; navegación de trazabilidad; riesgo de liberación; métricas de consumo de IA y de storage.

• Fuera: el reporte formal exportable (HU-022) y la vista agregada del Client (HU-024); la

asignación de escenarios a personas, fuera del MVP [Fase 2].

Actores y permisos

Precondiciones

• El usuario tiene rol PM, QA o Developer en el proyecto.

Comportamiento funcional

• Principal. El sistema muestra el estado del ciclo en curso: escenarios totales,

ejecutados, aprobados, fallidos, bloqueados y pendientes. Presenta cobertura de diseño y cobertura ejecutada como dos indicadores distintos, cada uno con su nombre —nunca uno rotulado solo "cobertura" (RN-081, DEC-049)—; el porcentaje de éxito (aprobadas sobre ejecutadas), distinguiendo fallidas de bloqueadas; los bugs por severidad y estado con su tendencia; y el avance por ejecutor como atribución del trabajo registrado. Señala el riesgo de liberación: bugs bloqueantes abiertos, casos de uso sin cobertura, escenarios sin ejecutar y bloqueos activos.

• Alternativo A1 — navegación de trazabilidad. Desde cualquier artefacto el usuario recorre

la cadena completa: requerimiento → caso de uso → escenario → criterio → ejecución → evidencia → bug → ticket → resolución (RN-060).

• Alternativo A2 — métricas de consumo. PM y QA consultan el consumo de IA (tokens de

entrada y salida, invocaciones, costo estimado, desglosado por proyecto, tipo de tarea y usuario) y el volumen de storage por proyecto con su evolución. El Developer no accede a estas métricas.

Datos y campos (funcional, no esquema)

• Métricas del ciclo: totales por resultado, cobertura de diseño, cobertura ejecutada,

porcentaje de éxito, bugs por severidad/estado y tendencia, avance por ejecutor.

• Riesgo de liberación: bugs bloqueantes abiertos, casos sin cobertura, escenarios sin

ejecutar, bloqueos activos.

• Consumo: tokens de entrada/salida, invocaciones y costo estimado de IA (por proyecto, tipo

de tarea y usuario); volumen de evidencia por proyecto y su evolución.

Reglas de negocio aplicables

• RN-059 — el porcentaje de éxito no cuenta los Blocked como fallo; se reportan aparte.
• RN-060 — la trazabilidad se recorre completa y en ambos sentidos.
• RN-062 — cobertura y avance del ciclo se calculan solo sobre las ejecuciones de ese

ciclo; las de fuera de ciclo no computan.

• RN-081 / DEC-049 — "cobertura" nunca se usa sin calificar: cobertura de diseño y

cobertura ejecutada se muestran cada una con su nombre.

Estados y transiciones. No aplica: el dashboard es una vista de lectura sobre el estado vigente de las entidades; no tiene ciclo de vida propio.

Integraciones (documentado, el dev implementa)

• Ninguna integración externa propia. Las métricas de consumo de IA se alimentan del registro

que produce la orquestación de IA (HU-026); las de storage, del inventario de evidencia (HU-019). Se documenta la dependencia funcional, no el contrato.

Eventos que emite. Ninguno. El dashboard consume el estado y los eventos que otras HU emiten; no dispara eventos de dominio.

Criterios de aceptación

• CA-310

> Dado un ciclo en curso > Cuando el usuario abre el dashboard > Entonces el sistema muestra escenarios totales, ejecutados, aprobados, fallidos, bloqueados y pendientes del ciclo.

• CA-311

> Dado el dashboard del proyecto > Cuando el sistema presenta la cobertura > Entonces muestra la cobertura de diseño y la cobertura ejecutada como dos indicadores nombrados por separado, nunca uno rotulado solo "cobertura".

• CA-312

> Dado un ciclo con ejecuciones aprobadas, fallidas y bloqueadas > Cuando el sistema calcula el porcentaje de éxito > Entonces cuenta aprobadas sobre ejecutadas y reporta las bloqueadas en su propia categoría, sin contarlas como fallo del producto.

• CA-313

> Dado un proyecto con bugs bloqueantes abiertos, casos sin cobertura, escenarios sin ejecutar o bloqueos activos > Cuando el usuario consulta el riesgo de liberación > Entonces el dashboard señala esas condiciones como razones que desaconsejan liberar.

• CA-314

> Dado cualquier artefacto del dashboard > Cuando el usuario navega su trazabilidad > Entonces el sistema permite recorrer la cadena completa desde el requerimiento hasta la resolución del bug, en ambos sentidos.

• CA-315

> Dado un ciclo con ejecuciones dentro y fuera de ciclo > Cuando el sistema calcula cobertura y avance > Entonces solo computa las ejecuciones pertenecientes al ciclo y excluye las de fuera de ciclo.

• CA-316

> Dado un usuario con rol PM o QA > Cuando consulta las métricas de consumo > Entonces el sistema muestra el consumo de IA (tokens de entrada y salida, invocaciones y costo estimado por proyecto, tipo de tarea y usuario) y el volumen de storage por proyecto con su evolución.

• CA-317

> Dado un usuario con rol Developer > Cuando intenta ver las métricas de consumo de IA o de storage > Entonces el sistema no se las muestra.

Dependencias y bloqueos

• HU-016 (ejecución) y HU-020/HU-021 (bugs y bloqueos) alimentan los conteos y el

riesgo de liberación; HU-026 (orquestación de IA) y HU-019 (evidencia) alimentan las métricas de consumo.

Casos borde / notas. El avance por ejecutor es una atribución del trabajo registrado, no un reparto de trabajo pendiente: en el MVP no hay asignación de escenarios a personas, y lo pendiente se mide a nivel de ciclo, no por persona (DEC-042). Las ejecuciones fuera de ciclo, que sí quedan registradas con trazabilidad y evidencia, no aparecen en cobertura ni avance.

HU-024 — Consultar el reporte agregado como Client

Sprint/Épica: S5 · Cierre: bugs, bloqueos, reportes y portal cliente · Bloque: J · Deriva de: CU-018 · Cubre: RF-006, RF-015, RF-114 · Reglas: RN-004, RN-006, RN-061 · Decisiones: DEC-034, DEC-043 · Estado: Borrador

Historia

Como Client, quiero ver el estado de calidad agregado de mi propio proyecto, para conocer el avance y el resultado de las pruebas sin acceder a ningún material interno.

Objetivo / valor. Dar visibilidad a la contraparte externa sin exponer casos, escenarios, evidencia, comentarios ni descripciones de bugs. El Client ve indicadores, no interioridades, y la restricción se hace cumplir en el backend, no ocultando cosas en la interfaz.

Alcance

• Dentro: listado de solo los proyectos donde el usuario es Client; vista y exportación

del reporte agregado (cobertura ejecutada, porcentaje de éxito, avance del ciclo, bugs por severidad); rechazo en backend de todo acceso a recursos internos; refresco por consulta.

• Fuera: el dashboard interno completo (HU-023), el reporte formal (HU-022) y la

suscripción a eventos en vivo (DEC-043); todo detalle de casos, escenarios, evidencia, comentarios y descripción de bugs.

Actores y permisos

Precondiciones

• El usuario tiene rol Client en el proyecto. El rol Client es excluyente: quien lo tiene

en un proyecto no tiene otro rol en ese proyecto (RN-006).

Comportamiento funcional

• Principal. El Client ingresa y ve únicamente los proyectos donde tiene rol Client. Abre

el proyecto y accede al reporte agregado: cobertura ejecutada (RF-107, no la de diseño), porcentaje de éxito, avance del ciclo y conteo de bugs por severidad. Puede exportar exactamente ese mismo nivel de detalle. La vista se refresca por consulta; el Client no se suscribe al canal de eventos en vivo (DEC-043).

• Alternativo A1 — sin ciclos ejecutados. El sistema indica que aún no hay resultados, sin

exponer la estructura interna del proyecto.

• Error E1 — acceso directo a un recurso interno. Un intento de acceder por identificador a

un caso de uso, escenario, evidencia, comentario o detalle de bug se rechaza en el backend, no ocultándolo en la interfaz (RN-061, RNF-028).

• Error E2 — proyecto sin rol asignado. El sistema responde como si el proyecto no existiera

(RN-004).

Datos y campos (funcional, no esquema)

• Muestra el sistema: cobertura ejecutada, porcentaje de éxito, avance del ciclo, conteo de

bugs por severidad — nada más.

• Nunca muestra: detalle de casos, escenarios, evidencia, comentarios internos ni

descripción de bugs.

Reglas de negocio aplicables

• RN-004 — un usuario sin rol en un proyecto no puede verlo, listarlo ni acceder a sus

recursos, ni siquiera conociendo su identificador.

• RN-006 — el rol Client es excluyente dentro de un proyecto.
• RN-061 — el Client accede exclusivamente a indicadores agregados de su propio proyecto;

nunca a casos, escenarios, evidencia, comentarios ni descripción de bugs; el rechazo se hace en el backend.

Estados y transiciones. No aplica: es una vista de solo lectura sobre indicadores agregados; no crea ni transiciona entidades.

Integraciones (documentado, el dev implementa)

• Ninguna integración externa propia. La exportación produce el agregado al mismo nivel que la

pantalla; su formato queda ligado a lo que resuelva PA-017 para la salida de reportes.

Eventos que emite. Ninguno. El Client consume una vista de lectura y no se suscribe a eventos en vivo (DEC-043).

Criterios de aceptación

• CA-320

> Dado un usuario con rol Client en uno o más proyectos > Cuando ingresa y lista proyectos > Entonces el sistema muestra únicamente los proyectos donde tiene rol Client.

• CA-321

> Dado un Client que abre su proyecto > Cuando accede al reporte agregado > Entonces el sistema muestra cobertura ejecutada, porcentaje de éxito, avance del ciclo y conteo de bugs por severidad, sin detalle de casos, escenarios, evidencia, comentarios ni descripción de bugs.

• CA-322

> Dado un Client viendo el reporte agregado > Cuando exporta el reporte > Entonces el sistema exporta exactamente el mismo nivel de detalle que ve en pantalla, nunca el reporte interno.

• CA-323

> Dado un Client que intenta acceder por identificador a un caso de uso, escenario, evidencia, comentario o detalle de bug > Cuando envía la petición > Entonces el backend la rechaza, no se limita a ocultarla en la interfaz.

• CA-324

> Dado un Client cuyo proyecto aún no tiene ciclos ejecutados > Cuando abre el reporte agregado > Entonces el sistema indica que aún no hay resultados, sin exponer la estructura interna del proyecto.

• CA-325

> Dado un Client que intenta acceder a un proyecto donde no tiene rol asignado > Cuando envía la petición conociendo su identificador > Entonces el sistema responde como si el proyecto no existiera.

• CA-326

> Dado un ciclo cuyo estado cambia mientras el Client tiene abierta su vista > Cuando el Client quiere ver el dato actualizado > Entonces la vista se refresca por consulta y no por suscripción a eventos en vivo.

Dependencias y bloqueos

• HU-022 (reporte de calidad) y HU-023 (dashboard) producen los indicadores que aquí

se recortan al nivel agregado; ninguno expone al Client más que la cobertura ejecutada, el porcentaje de éxito, el avance y los bugs por severidad.

• PA-017 (formato del reporte) — condiciona el formato de la exportación agregada.

Casos borde / notas. La cobertura que ve el Client es la ejecutada, nunca la de diseño (RF-114, DEC-049). El rechazo de recursos internos es en backend por diseño (RN-061): ocultar en la interfaz no es suficiente, porque el Client podría conocer un identificador.