Épica J — Observabilidad y reportes

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

Cubre el cierre del ciclo y el reporte formal de calidad, el dashboard de cobertura y avance, y la vista agregada restringida para el rol Client. El hilo conductor es la trazabilidad hecha métrica: cobertura de diseño y cobertura ejecutada como dos indicadores nombrados, resultados que no se contaminan entre sí, y reportes inmutables anclados a las versiones congeladas vigentes. Reglas de negocio del bloque: RN-059 a RN-063, más RN-045, RN-004 y RN-006.

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

Épica: J · Observabilidad y reportes · 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

Épica: J · Observabilidad y reportes · 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

Épica: J · Observabilidad y reportes · 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.