Requerimientos funcionales — MVP

Estado: Borrador · Última actualización: 2026-08-24 Alcance: MVP / Fase 1 · Deriva de: visión y alcance y el snapshot del documento maestro

Cómo leer este documento

Cada requerimiento tiene un ID estable (RF-###) que no se reutiliza ni se renumera. Las referencias a RN-### apuntan a reglas de negocio; las referencias a PA-### a preguntas abiertas que aún condicionan el detalle.

Prioridad: todos los requerimientos listados son Must para el MVP salvo que se indique Should o [Fase N] explícitamente.

Agregados en la revisión del 2026-08-24, sin renumerar los existentes (RN-076): RF-138 y RF-141 pertenecen al bloque B, RF-139 al bloque E y RF-140 al bloque I.

A. Autenticación, usuarios y roles

RF-001 — Autenticación mediante el JWT de Flagare. El sistema debe autenticar a los usuarios validando el JWT emitido por identity.flagare. No mantiene contraseñas ni un registro de credenciales propio. Depende de PA-007.

RF-002 — Rechazo de tokens inválidos o expirados. Toda petición con token ausente, malformado, expirado o de emisor no reconocido debe rechazarse sin revelar información del recurso solicitado.

RF-003 — Alta implícita del usuario. Al primer acceso válido de un usuario desconocido, el sistema debe crear su registro local a partir de los claims del token. No requiere aprovisionamiento previo.

RF-004 — Asignación de rol por proyecto. El sistema debe permitir asignar a un usuario uno o más roles (Product Manager, QA, Developer, Client) en el contexto de un proyecto específico. No existe el concepto de rol global. RN-001, RN-002, RN-003.

RF-005 — Permisos como unión de roles. Cuando un usuario tiene varios roles en un proyecto, sus permisos efectivos son la unión de los permisos de cada rol. RN-002.

RF-006 — Aislamiento por proyecto. Un usuario sin rol asignado en un proyecto no debe poder verlo, listarlo, ni obtener ninguno de sus recursos por acceso directo a un identificador. RN-004.

RF-007 — Exclusividad del rol Client. El sistema debe impedir asignar el rol Client a un usuario que ya tenga otro rol en ese proyecto, y viceversa. RN-006.

RF-008 — Product Manager obligatorio. Todo proyecto debe tener al menos un Product Manager asignado. El sistema debe impedir revocar el último. RN-005.

B. Gestión de proyectos

RF-009 — Importación desde Argos Operaciones. Un proyecto de QA solo puede crearse importándolo desde argos.flagare. El usuario busca el proyecto en Argos Operaciones, lo selecciona, y el sistema crea su contraparte local. RN-014.

RF-010 — Prohibición de creación manual. El sistema no debe ofrecer ninguna vía para crear un proyecto que no exista en Argos Operaciones. Esto incluye pilotos y pruebas internas: deben crearse primero en Argos Operaciones. RN-014, DEC-025.

RF-011 — Datos importados. De cada proyecto se importa al menos: identificador en Argos Operaciones, nombre, cliente asociado, estado y responsable. El identificador de Argos Operaciones es la clave de vinculación permanente. Depende de PA-006.

RF-012 — Un proyecto de Argos Operaciones, un proyecto de QA. El sistema debe impedir importar dos veces el mismo proyecto de Argos Operaciones. RN-015.

RF-013 — Re-sincronización de metadata. El sistema debe permitir refrescar bajo demanda los datos importados desde Argos Operaciones, y debe hacerlo también de forma programada. Los datos locales de QA (roles, ciclos, escenarios) nunca se sobrescriben en esa operación. RN-016.

RF-014 — Degradación ante Argos Operaciones no disponible. Si Argos Operaciones no responde, el sistema debe seguir operando sobre los proyectos ya importados, indicando 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. La creación de bugs no se bloquea: el bug se registra localmente y su ticket espejo en Argos Operaciones queda diferido, en estado Pendiente de sincronizar, para reintento automático. RN-017, RN-054, DEC-039.

RF-015 — Listado filtrado por permisos. El listado de proyectos debe mostrar únicamente aquellos donde el usuario tiene un rol asignado. RN-004.

RF-016 — Archivado de proyectos. Un proyecto puede archivarse, y solo lo archiva el Product Manager. Un proyecto archivado es de solo lectura: no admite nuevos ciclos, ejecuciones, bugs ni ediciones, y conserva toda su información y evidencia.

El sistema debe impedir el archivado mientras exista un ciclo Abierto en el proyecto, e indicar cuáles hay que cerrar. Los bugs con sincronización Pendiente o Error siguen reintentando después del archivado: el ticket espejo debe existir en Argos Operaciones aunque el proyecto de QA esté cerrado. RN-082, DEC-051.

RF-138 — Reactivación de proyectos. El Product Manager debe poder reactivar un proyecto archivado, devolviéndolo a Activo con toda su información intacta. La reactivación queda registrada en auditoría. RN-082, DEC-051.

RF-141 — Estados del proyecto. Los estados son Activo y Archivado, con las transiciones definidas en máquinas de estado. DEC-054.

RF-017 — Enlace al proyecto en Argos Operaciones. Toda vista de proyecto debe ofrecer un enlace directo al proyecto correspondiente en Argos Operaciones.

RF-018 — Gestión de miembros. El Product Manager debe poder asignar y revocar roles de los miembros del proyecto. Cada cambio queda registrado en auditoría. RN-007.

C. Ingesta de requerimientos

RF-019 — Requerimiento por texto pegado. El sistema debe permitir crear un requerimiento pegando texto directamente en la plataforma. DEC-007.

RF-020 — Requerimiento por archivo de texto o Markdown. El sistema debe aceptar la carga de archivos .md y .txt. DEC-007.

RF-021 — Rechazo explícito de formatos no soportados. Al intentar cargar PDF, DOCX u otro binario, el sistema debe rechazarlo con un mensaje que indique los formatos aceptados. No debe intentar una extracción parcial ni fallar en silencio. RN-018.

RF-022 — Límite de tamaño. El sistema debe imponer un límite de tamaño por documento de origen y comunicarlo antes de la carga. Valor concreto en RNF.

RF-023 — Documento de origen inmutable. El texto cargado se conserva como documento de origen sin modificaciones. Corregirlo implica cargar una versión nueva; la anterior se conserva. RN-019.

RF-024 — Vinculación con tickets de Argos Operaciones. Un requerimiento debe poder vincularse a uno o más tickets del proyecto en Argos Operaciones. Depende de PA-006.

RF-025 — Análisis asistido por IA. Sobre un requerimiento cargado, el sistema debe poder ejecutar un análisis que identifique: actores, objetivos, restricciones, reglas de negocio, supuestos, dependencias, ambigüedades detectadas y riesgos funcionales.

RF-026 — El análisis es una acción explícita. El análisis de IA nunca se dispara automáticamente al cargar un documento. Requiere una acción deliberada del usuario. RN-064.

RF-027 — Resultado del análisis revisable. El resultado del análisis se presenta como propuesta editable, no como hecho consumado. El usuario puede aceptar, editar o descartar cada elemento identificado.

RF-028 — Preguntas abiertas del requerimiento. Las ambigüedades que detecte la IA deben quedar registradas como preguntas abiertas asociadas al requerimiento, con estado propio (Abierta / Resuelta), para que no se pierdan al avanzar a casos de uso.

D. Casos de uso

RF-029 — Generación asistida por IA. El sistema debe poder generar casos de uso a partir de un requerimiento analizado, proponiendo flujos principales, alternativos, de error y casos borde.

RF-030 — Creación manual. El sistema debe permitir crear un caso de uso completamente a mano, sin pasar por la IA. La disponibilidad de IA nunca es condición para avanzar. DEC-027, RN-065.

RF-031 — Estructura obligatoria del caso de uso. Todo caso de uso debe contener, como mínimo: identificador, título, objetivo, actores, precondiciones, flujo principal, flujos alternativos, flujos de error, postcondiciones, reglas de negocio aplicables y supuestos. El sistema debe impedir pasar a En revisión un caso incompleto. RN-020.

RF-032 — Trazabilidad al origen. Todo caso de uso debe declarar de qué requerimiento deriva. Si fue generado por IA, debe registrar además el job que lo produjo. RN-021.

RF-033 — Estados del caso de uso. Los estados son Draft, En revisión, Validado, Congelado y Obsoleto, con las transiciones definidas en máquinas de estado.

RF-034 — Edición según estado. Un caso de uso es editable en Draft, En revisión y Validado. En Congelado y Obsoleto es de solo lectura, sin excepción por rol. Editar el contenido de un caso Validado lo devuelve automáticamente a En revisión, y el sistema debe advertirlo antes de confirmar el cambio. RN-009, RN-077, DEC-040.

RF-035 — Congelamiento exclusivo del Product Manager. Solo un usuario con rol Product Manager en ese proyecto puede pasar un caso de uso a Congelado. RN-022.

RF-036 — Registro del congelamiento. Al congelar, el sistema debe registrar quién congeló, cuándo y sobre qué número de versión. Ese registro es inmutable. RN-022.

RF-037 — Inmutabilidad de la versión congelada. Una versión congelada no puede editarse, descongelarse ni eliminarse. RN-009, DEC-028.

RF-038 — Nueva versión desde una congelada. Para modificar un caso congelado, el sistema debe permitir crear una versión nueva que nace en Draft con el contenido de la anterior. La versión congelada permanece intacta y sigue siendo consultable. RN-023, DEC-028.

RF-039 — Marcado de escenarios desactualizados. Al congelar una versión nueva de un caso de uso, todos los escenarios de prueba derivados de la versión anterior deben marcarse automáticamente como desactualizados, para forzar su revisión. No se eliminan ni se bloquean. RN-024.

RF-040 — Visibilidad del desfase. El sistema debe mostrar, en el escenario y en el plan, qué versión del caso de uso lo originó y si esa versión sigue siendo la vigente.

RF-041 — Obsolescencia. El Product Manager puede marcar un caso de uso como Obsoleto desde cualquier estado: un caso congelado que dejó de aplicar y una propuesta abandonada en Draft se retiran por la misma vía. Los escenarios derivados se marcan como desactualizados y el caso deja de contar para la cobertura. Nada se elimina: el caso obsoleto permanece consultable. RN-079, DEC-047.

RF-042 — Historial de versiones. El sistema debe permitir consultar todas las versiones de un caso de uso, con su estado, fecha, autor y las diferencias respecto de la versión anterior.

E. Plan de pruebas y escenarios

RF-043 — Un plan por proyecto. Cada proyecto tiene un plan de pruebas que agrupa sus escenarios, criterios de aceptación y cobertura.

RF-139 — Estados del plan de pruebas. Los estados son Borrador, Pendiente de aprobación y Aprobado, con las transiciones definidas en máquinas de estado. DEC-054.

RF-044 — Generación asistida de escenarios. El sistema debe poder generar escenarios de prueba a partir de casos de uso, proponiendo también criterios de aceptación y datos de prueba.

RF-045 — Aprobación solo con el caso de uso congelado. Ningún escenario puede aprobarse si su caso de uso de origen no está en estado Congelado, sin importar si lo generó la IA o lo escribió una persona. El sistema debe impedir la transición e indicar qué caso de uso falta congelar. Crear y editar el escenario antes de eso está permitido: queda en Generado o En revisión hasta que su caso se congele. RN-031, DEC-041.

RF-046 — Creación manual de escenarios. Todo escenario debe poder crearse y editarse a mano, en cualquier estado de su caso de uso de origen. La vía manual no exime de RF-045 para aprobarlo. DEC-027, RN-031.

RF-047 — Estructura obligatoria del escenario. Todo escenario debe contener: objetivo, precondiciones, ambiente requerido, datos de prueba, rol o usuario necesario, pasos de ejecución numerados, resultado esperado por paso, criterio de aprobación, evidencia requerida, tipo de ejecución y el caso de uso del que deriva. El sistema debe impedir aprobar un escenario incompleto. RN-032.

RF-048 — Tipo de ejecución. Cada escenario se clasifica como Manual, Automatizable, Semi-automatizada o No automatizable. En el MVP el campo es informativo; habilita la automatización de [Fase 3].

RF-049 — Priorización. Cada escenario debe poder priorizarse por riesgo o impacto, y el plan debe poder ordenarse y filtrarse por esa prioridad.

RF-050 — Estados del escenario. Los estados son Generado, En revisión, Aprobado, Requiere cambios y Retirado.

RF-051 — Aprobación del plan por el Product Manager. El plan de pruebas requiere aprobación del Product Manager antes de poder ejecutarse. La IA propone, el equipo itera, el PM aprueba. RN-033, DEC-029.

RF-052 — Solo se ejecuta lo aprobado. El sistema debe impedir ejecutar un escenario que no esté en estado Aprobado dentro de un plan aprobado. RN-034.

RF-053 — Reapertura del plan. Agregar o modificar escenarios en un plan aprobado devuelve el plan a estado pendiente de aprobación, indicando qué cambió. RN-035.

RF-054 — Matriz de cobertura de diseño. El sistema debe mantener y mostrar la relación entre casos de uso y escenarios que los cubren, en ambos sentidos. La matriz mide cobertura de diseño: si existe prueba diseñada, no si se ejecutó. RN-081, DEC-049.

RF-055 — Detección de huecos de cobertura de diseño. La matriz debe señalar explícitamente los casos de uso congelados sin ningún escenario aprobado que los cubra. RN-036, RN-081.

RF-056 — Iteración asistida sobre el plan. El sistema debe permitir pedir a la IA que revise el plan y sugiera escenarios faltantes, casos borde no cubiertos o criterios de aceptación ambiguos, como propuesta revisable.

F. Ambientes de prueba

RF-057 — Registro de ambientes. Cada proyecto debe poder registrar uno o más ambientes de prueba, tipificados como Local, Desarrollo, QA, Staging, Producción controlada o Servidor externo. El ambiente es un registro editable y no se versiona: el rastro histórico de su configuración son los snapshots inmutables que capturan los ciclos (RF-067) y las ejecuciones fuera de ciclo. RN-029, RN-042, DEC-046.

RF-058 — Datos de acceso del ambiente. El ambiente debe registrar URLs, endpoints y servidores involucrados.

RF-059 — Credenciales solo por referencia. El sistema debe permitir declarar qué credenciales requiere el ambiente únicamente como referencia al vault — identificador del secreto, ubicación y responsable de entregarlo. El sistema nunca almacena el valor. RN-026, RN-012, DEC-026.

RF-060 — Detección de secretos en texto plano. El sistema debe detectar y rechazar valores que aparenten ser credenciales en campos de texto libre del ambiente, explicando por qué se rechaza. RN-027.

RF-061 — Conexiones y dependencias externas. El ambiente debe registrar sus conexiones: base de datos, APIs internas y externas, servicios de autenticación, storage, colas y servicios de terceros.

RF-062 — Configuración de ejecución. El ambiente debe registrar variables de entorno relevantes, feature flags, parámetros por cliente, versiones de servicios y la referencia de código bajo prueba: branch, commit, tag o release candidate.

RF-063 — Datos de prueba. El ambiente debe documentar los datos necesarios: usuarios, roles, permisos, registros base, fixtures y seeds.

RF-064 — Dependencias previas. El ambiente debe documentar qué debe ocurrir antes de probar: migraciones aplicadas, jobs ejecutados, integraciones habilitadas, servicios levantados y accesos validados.

RF-065 — Checklist de readiness. El ambiente debe tener un checklist de preparación verificable antes de abrir un ciclo: login funcional, servicios disponibles, conectividad, datos mínimos presentes, permisos correctos e integraciones sincronizando.

RF-066 — Advertencia por readiness incompleto. Al abrir un ciclo sobre un ambiente con checklist incompleto, el sistema debe advertirlo de forma explícita. No lo impide, pero deja constancia en el ciclo. RN-028.

RF-067 — Snapshot del ambiente al abrir el ciclo. Al abrir un ciclo, el sistema debe capturar una copia inmutable de la configuración del ambiente en ese instante. Los cambios posteriores al ambiente no alteran el snapshot del ciclo ya abierto. Es lo que permite reproducir una ejecución. RN-029.

G. Ciclos y ejecución

RF-068 — Apertura de ciclo. Un ciclo de QA se abre contra un ambiente específico, con nombre, alcance y fecha de inicio.

RF-069 — Alcance del ciclo. Al abrir el ciclo se selecciona el conjunto de escenarios aprobados que lo componen.

RF-070 — Ejecución fuera de ciclo. El sistema debe permitir ejecutar un escenario aprobado sin abrir un ciclo, para verificaciones puntuales. DEC-030.

No exige plan aprobado: basta que el escenario esté Aprobado. Un plan que volvió a Pendiente de aprobación no impide la verificación puntual. RN-034, DEC-055.

Al iniciarla, el ejecutor debe elegir explícitamente el ambiente entre los registrados del proyecto cuyo tipo coincida con el ambiente requerido por el escenario (RF-047). Si no existe ninguno compatible, el sistema impide la ejecución e indica qué tipo de ambiente falta registrar. El snapshot se captura sobre el ambiente elegido. RN-042, RN-080, DEC-048.

RF-071 — Separación en las métricas. Las ejecuciones fuera de ciclo deben quedar registradas con su evidencia y trazabilidad completas, pero no computan en las métricas de cobertura ni de avance del ciclo. El sistema debe distinguirlas visualmente. RN-038.

RF-072 — Ejecución guiada paso a paso. Durante la ejecución, el sistema debe presentar de forma secuencial: precondiciones, datos de prueba, cada paso con su resultado esperado, y el criterio de aprobación.

RF-073 — Resultado por paso. El ejecutor debe poder registrar el resultado de cada paso individualmente, no solo del escenario completo. Los resultados posibles por paso son Pass, Fail y No ejecutado, este último para los pasos que quedaron sin correr cuando la ejecución se detiene antes del final. RN-084, DEC-053.

RF-074 — Estados de ejecución. Los estados son Not run, Pass, Fail, Blocked, Retest required y Passed after fix.

RF-075 — Evidencia obligatoria. El sistema debe impedir registrar cualquier resultado de ejecución sin al menos un elemento de evidencia adjunto. Aplica a todos los resultados, incluido Pass. RN-013, RN-046, DEC-031.

RF-076 — Comentarios de ejecución. El ejecutor debe poder registrar observaciones por paso y por escenario.

RF-077 — Bug desde el punto de fallo. Desde un paso marcado como Fail, el sistema debe permitir crear un bug que herede automáticamente: escenario, caso de uso, paso, ciclo, ambiente, snapshot de configuración, usuario ejecutor, timestamp y la evidencia ya adjunta. RN-051.

RF-078 — Blocked exige un bloqueo. Marcar una ejecución como Blocked requiere asociarla a un bloqueo, nuevo o existente. RN-039, DEC-032.

RF-079 — Reejecución. Un escenario puede ejecutarse varias veces dentro de un ciclo. Cada ejecución se conserva como registro independiente; no se sobrescribe la anterior. RN-040.

Un escenario en Fail sin bug asociado puede marcarse para reejecución sin abrir un defecto —fallo por dato de prueba, error del ejecutor, ambiente mal preparado—, y el sistema debe exigir un motivo escrito que quede en auditoría. RN-078, DEC-044.

RF-080 — Retest tras corrección. Cuando un bug asociado pasa a Listo para retest, las ejecuciones fallidas que lo originaron deben marcarse como Retest required. RN-041.

RF-081 — Cierre de ciclo. Un ciclo puede cerrarse. Al cerrarlo, el sistema debe advertir si quedan escenarios en Not run, Fail, Retest required o Blocked, y exigir confirmación explícita. Un Fail puede quedar abierto al cierre: la advertencia obliga a mirarlo, no a resolverlo.

RF-082 — Reapertura de ciclo. Un ciclo cerrado puede reabrirse, dejando registro de quién lo reabrió y por qué.

H. Evidencia

RF-083 — Adjuntar evidencia. El sistema debe permitir adjuntar screenshots, logs y archivos a un paso o a la ejecución completa. DEC-006 excluye la grabación de pantalla del MVP.

RF-084 — Tipos y tamaños permitidos. El sistema debe validar tipo y tamaño de cada archivo, y rechazar lo que exceda los límites con un mensaje claro.

RF-085 — Metadata automática. Cada elemento de evidencia debe registrar automáticamente: usuario, timestamp, ejecución, paso, escenario, ciclo, ambiente, tipo, tamaño y hash del contenido. RN-047.

RF-086 — Almacenamiento en S3. Los archivos se almacenan en Amazon S3. La base de datos guarda metadata y referencias, nunca el binario. DEC-016, RN-048.

RF-087 — Acceso por URL firmada. La evidencia se sirve mediante URLs firmadas de vigencia limitada. No debe existir acceso público ni URL permanente. RN-049.

RF-088 — Auditoría de acceso. Toda visualización y descarga de evidencia debe quedar registrada en auditoría con usuario, timestamp y elemento accedido. RN-050.

RF-089 — Evidencia no eliminable. Ningún usuario puede eliminar evidencia. Solo desaparece por vencimiento de la política de retención. RN-010.

RF-090 — Política de retención. El sistema debe aplicar la política de retención definida en DEC-020, diferenciada por tipo de evidencia y por resultado de la ejecución asociada.

RF-091 — Aviso previo a la expiración. Antes de que la evidencia expire, el sistema debe permitir consultar qué está por vencer, para poder retenerla si respalda una entrega formal. Should.

I. Bugs y bloqueos

RF-092 — Creación de bugs. El sistema debe permitir registrar un bug, tanto desde una ejecución fallida como de forma independiente dentro del proyecto.

RF-093 — Estructura del bug. Todo bug debe contener: título, descripción, severidad, pasos para reproducir, resultado esperado, resultado obtenido, ambiente, referencia de código bajo prueba y evidencia. RN-052.

RF-094 — Escala de severidad. La severidad se registra en una escala fija: Bloqueante, Crítica, Mayor, Menor, Cosmética.

RF-095 — Creación automática del ticket en Argos Operaciones. Al crear un bug, el sistema debe crear automáticamente el ticket correspondiente en Argos Operaciones y mantener ambos enlazados. RN-053, DEC-033.

RF-096 — Reintento ante fallo de Argos Operaciones. Si la creación del ticket en Argos Operaciones falla, el bug debe persistir localmente en estado Pendiente de sincronizar y reintentarse de forma automática y controlada. El usuario nunca pierde el registro por una caída de Argos Operaciones. RN-054.

RF-097 — Visibilidad del estado de sincronización. El sistema debe mostrar en el bug si está sincronizado con Argos Operaciones, pendiente o en error, y permitir forzar el reintento.

RF-098 — Estados del bug. Los estados son Nuevo, Asignado, En desarrollo, Listo para retest, Reabierto, Resuelto y Cerrado. Salir de Nuevo exige asignar el bug: un bug en curso siempre tiene un responsable identificable. Pueden asignar el Product Manager, el QA y el Developer; el destinatario debe ser miembro del proyecto con uno de esos tres roles. RN-083, DEC-052.

RF-099 — Reapertura de bugs. Un bug Resuelto o Cerrado puede reabrirse. La reapertura debe exigir un motivo y evidencia nueva. RN-055.

RF-100 — Trazabilidad del bug. Todo bug debe mantener el enlace con la ejecución, el escenario, el criterio de aceptación, el caso de uso y el ticket de Argos Operaciones que le corresponden. RN-056.

RF-101 — Creación de bloqueos. El sistema debe permitir registrar un bloqueo como entidad propia, con tipo, descripción, responsable, fecha de detección e impacto. DEC-032.

RF-140 — Estados del bloqueo. Los estados son Abierto, En gestión, Resuelto y Descartado, con las transiciones definidas en máquinas de estado. El efecto de Resuelto y Descartado sobre las ejecuciones dependientes lo fija RN-058. DEC-054.

RF-102 — Tipos de bloqueo. El bloqueo se tipifica al menos como: Ambiente, Datos, Acceso, Dependencia externa, Definición pendiente. La distinción con el bug es que el bloqueo no es un defecto del producto: es un impedimento para poder probarlo. RN-057.

RF-103 — Bloqueo con alcance múltiple. Un mismo bloqueo puede afectar a varias ejecuciones y escenarios simultáneamente.

RF-104 — Cierre de bloqueos y efecto en las ejecuciones. Al resolver un bloqueo, todas las ejecuciones que dependían de él deben pasar a Retest required. Al descartarlo, deben volver a Not run, y el sistema debe advertir que fueron marcadas Blocked sin causa válida. RN-058, DEC-045.

RF-105 — Vista agregada de bloqueos. El sistema debe ofrecer una vista de los bloqueos activos del proyecto, ordenables por impacto, para responder qué está frenando la validación.

J. Observabilidad y reportes

RF-106 — Dashboard del ciclo activo. El sistema debe mostrar el estado del ciclo en curso: escenarios totales, ejecutados, aprobados, fallidos, bloqueados y pendientes.

RF-107 — Cobertura ejecutada. Porcentaje de casos de uso congelados cubiertos por al menos un escenario aprobado y ejecutado con resultado registrado. Es un indicador distinto de la cobertura de diseño de RF-054: el dashboard debe mostrar ambos con su nombre, nunca uno rotulado solo "cobertura". RN-081, DEC-049.

RF-108 — Porcentaje de éxito del ciclo. Aprobadas sobre ejecutadas, distinguiendo fallidas de bloqueadas — un bloqueo no es un fallo del producto y no debe contaminar el indicador. RN-059.

RF-109 — Bugs por severidad y estado. Conteo de bugs abiertos, resueltos y bloqueantes, con su tendencia dentro del ciclo.

RF-110 — Avance por ejecutor. Volumen y resultado de las ejecuciones registradas por cada miembro del proyecto, sobre un ciclo o un rango de fechas. Es una atribución de trabajo realizado, no un reparto de trabajo pendiente: en el MVP no existe asignación de escenarios ni de ejecuciones a personas. Lo pendiente se mide a nivel de ciclo (RF-109, RF-112), no por persona. DEC-042.

La asignación explícita de escenarios a miembros, con su permiso, su evento y su notificación, queda fuera del MVP. [Fase 2]

RF-111 — Navegación de trazabilidad. Desde cualquier artefacto, el sistema debe permitir recorrer la cadena completa: requerimiento → caso de uso → escenario → criterio → ejecución → evidencia → bug → ticket de Argos Operaciones → resolución. RN-060.

RF-112 — Riesgo de liberación. El dashboard debe señalar las condiciones que desaconsejan liberar: bugs bloqueantes abiertos, casos de uso sin cobertura, escenarios sin ejecutar y bloqueos activos.

RF-113 — Reporte formal de calidad. El sistema debe generar un reporte exportable con el estado de calidad del ciclo, su alcance, resultados, evidencia referenciada y bugs pendientes.

RF-114 — Reporte agregado para el Client. El sistema debe generar una vista y una exportación restringidas al rol Client, con cobertura ejecutada (RF-107, no la de diseño), porcentaje de éxito, avance y conteo de bugs por severidad — sin detalle de casos, escenarios, evidencia, comentarios ni descripción de bugs. RN-061, DEC-034.

RF-115 — Métricas de consumo de IA. El sistema debe reportar tokens de entrada y salida, número de invocaciones y costo estimado, desglosado por proyecto, tipo de tarea y usuario. RN-066.

RF-116 — Métricas de storage. El sistema debe reportar el volumen de evidencia almacenada por proyecto y su evolución.

K. Eventos y notificaciones

RF-117 — Catálogo de eventos de dominio. El sistema debe emitir, como mínimo: 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 evento use_case.approved de la fuente se reemplaza por use_case.frozen: el hito con consecuencias externas es el congelamiento, no la validación. El paso a Validado no emite evento — es un trámite interno del equipo (RN-069). use_case.obsoleted se agrega porque la obsolescencia también invalida artefactos derivados (RN-079). DEC-050.

RF-118 — Publicación hacia notifications.flagare. Los eventos se publican mediante la API de notifications.flagare. DEC-012. Depende de PA-009.

RF-119 — Entrega garantizada. La publicación debe pasar por una cola de salida persistente con reintento. Un fallo de notifications.flagare no puede provocar la pérdida de un evento ni el fallo de la operación de negocio que lo originó. RN-069.

RF-120 — Notificación en vivo por SSE. El frontend debe recibir notificaciones en tiempo real mediante SSE. DEC-012.

RF-121 — Reconexión del canal. El canal SSE debe reconectarse automáticamente ante caída y recuperar los eventos perdidos durante la desconexión. RN-070.

RF-122 — Autorización del canal. El canal SSE debe autenticar al usuario y entregar únicamente eventos de proyectos donde tiene rol asignado. El sistema debe rechazar el establecimiento de la suscripción a un usuario cuyo único rol en el proyecto sea Client: ese rol no recibe eventos en vivo, y su vista se refresca por consulta. RN-071, RN-061, RNF-028, DEC-043.

RF-123 — Evento idempotente. Cada evento debe llevar un identificador único que permita al consumidor descartar duplicados generados por reintentos. RN-072.

L. Orquestación de IA

RF-124 — Registro de cada invocación. Toda invocación al proveedor de IA debe registrarse como un job con: tarea, modelo, tokens de entrada y salida, duración, costo estimado, usuario, proyecto y resultado. RN-066.

RF-125 — Model routing por tarea. El sistema debe seleccionar el modelo según la complejidad de la tarea, usando el modelo más económico que la resuelva. La asignación tarea → modelo debe ser configurable sin desplegar código. RN-067.

RF-126 — Salida estructurada. Las respuestas de IA que alimentan artefactos deben solicitarse en formato estructurado y validarse antes de persistirse. Una respuesta que no valida se descarta y se informa; no se guarda parcialmente. RN-068.

RF-127 — Reintento acotado. Los reintentos ante fallo del proveedor deben ser limitados en número y visibles para el usuario. Sin reintentos automáticos ilimitados. RN-068.

RF-128 — Degradación sin IA. Si el proveedor de IA no está disponible, todas las funciones de creación y edición manual deben seguir operando. La plataforma no se detiene. RN-065, DEC-027.

RF-129 — Caché por contenido. El sistema debe cachear resultados de IA indexados por hash del contenido de entrada, prompt y versión, para no reprocesar lo que no cambió. Should.

RF-130 — Aviso de costo antes de operaciones grandes. Antes de procesar un documento extenso, el sistema debe mostrar una estimación del costo y requerir confirmación. Es Must: mientras PA-010 no fije el techo de gasto mensual, avisar antes de gastar es la única contención. El umbral de "documento extenso" se define junto con ese techo. DEC-056.

M. Auditoría y trazabilidad

RF-131 — Registro de cambios críticos. Todo cambio sobre casos de uso, planes, escenarios, ambientes, ciclos, ejecuciones, bugs, bloqueos, roles y aprobaciones debe registrarse en auditoría. RN-073.

RF-132 — Contenido del registro. Cada entrada debe incluir: usuario, fecha y hora, acción, artefacto afectado, valor anterior, valor nuevo y justificación cuando aplique. RN-073.

RF-133 — Origen del cambio. Cada entrada debe declarar su origen: Usuario, IA, Integración o Automatización. Distinguir lo que hizo una persona de lo que hizo el sistema es esencial cuando la IA escribe artefactos. RN-074.

RF-134 — Log inmutable. El registro de auditoría es append-only. No admite edición ni borrado por ningún rol. RN-011, RN-075.

RF-135 — Consulta de auditoría. El sistema debe permitir consultar la auditoría filtrando por artefacto, usuario, rango de fechas, acción y origen.

RF-136 — Identificadores estables. Todo artefacto debe tener un identificador estable y legible dentro del proyecto (CU-007, ESC-042, BUG-013), que no se reutiliza aunque el artefacto se retire. RN-076.

RF-137 — Integridad referencial de la trazabilidad. El sistema debe impedir eliminar un artefacto que tenga otros derivados. El camino es retirarlo o marcarlo obsoleto, nunca romper la cadena. RN-076.