**Gutiérrez Soto, Jhosepmyr Orlando – 202317638**
Trabajé comunicando oralmente los aspectos generales del proyecto relacionados con el Capítulo I y parte del Capítulo IV. Expliqué la descripción de la startup, la propuesta de solución y los fundamentos estratégicos del producto, procurando presentar las ideas de manera clara, ordenada y comprensible para una audiencia académica.
**Hernández Tuiro, Eric Ernesto – 20221C857**
Trabajé comunicando oralmente los contenidos vinculados al Capítulo I y Capítulo IV. Presenté ideas relacionadas con el perfil de la solución, el enfoque estratégico del producto y las decisiones generales de diseño, utilizando un lenguaje objetivo y adecuado para explicar la relación entre la problemática identificada y la solución propuesta.
**Ramirez Mestanza, Salim Ignacio – 20201E843**
Trabajé comunicando oralmente los avances desarrollados en el Capítulo II, principalmente los resultados del análisis de requerimientos, entrevistas, competidores y hallazgos del proceso de need finding. Mi participación permitió explicar cómo se identificaron necesidades relevantes para orientar el desarrollo del producto.
**Varela Bustinza, Marcelo Alessandro – 202319668**
Trabajé comunicando oralmente los resultados correspondientes al Capítulo II, especialmente el análisis competitivo, las estrategias frente a competidores, el diseño y análisis de entrevistas, así como los principales hallazgos obtenidos sobre los usuarios. Busqué explicar la información de manera objetiva, conectando los resultados con la definición de requerimientos del proyecto.
**Sulca Gonzales, Paul Fernando – 20221C486**
Trabajé comunicando oralmente los contenidos del Capítulo III, relacionados con la especificación de requerimientos, user stories, product backlog e impact mapping. Expliqué cómo los hallazgos obtenidos en etapas anteriores se transformaron en requisitos y elementos priorizados para el desarrollo de la solución. | Como equipo, se logró comunicar oralmente los avances del proyecto de manera clara, organizada y objetiva. Cada integrante explicó los resultados correspondientes a su participación, conectando los capítulos desarrollados con el propósito general de la solución. Asimismo, la exposición permitió adaptar el lenguaje técnico a una audiencia académica, integrando aspectos de negocio, usuarios, requerimientos y diseño de ingeniería. | -| **Comunica en forma escrita ideas y/o resultados con objetividad a público de diferentes especialidades y niveles jerárquicos, en el marco del desarrollo de un proyecto en ingeniería.** | **TB1**
**Gutiérrez Soto, Jhosepmyr Orlando – 202317638**
Trabajé comunicando de forma escrita los contenidos relacionados con el Capítulo I y parte del Capítulo IV. Redacté información sobre el perfil de la startup, la propuesta de solución y los elementos estratégicos del diseño del producto, procurando mantener una estructura clara y una redacción adecuada para el contexto académico y de ingeniería.
**Hernández Tuiro, Eric Ernesto – 20221C857**
Trabajé comunicando de forma escrita los apartados vinculados al Capítulo I y Capítulo IV. Mi aporte se centró en organizar y redactar ideas sobre la solución propuesta, su relación con la problemática y los criterios estratégicos del producto, asegurando coherencia entre el enfoque del proyecto y las decisiones de diseño.
**Ramirez Mestanza, Salim Ignacio – 20201E843**
Trabajé comunicando de forma escrita los contenidos del Capítulo II, principalmente en los apartados de análisis de requerimientos, entrevistas, competidores, identificación de necesidades y lenguaje ubicuo. Mi aporte permitió documentar los hallazgos de manera ordenada y orientada a sustentar la definición de requerimientos.
**Varela Bustinza, Marcelo Alessandro – 202319668**
Trabajé comunicando de forma escrita los resultados del Capítulo II, incluyendo el análisis competitivo, estrategias frente a competidores, diseño y análisis de entrevistas, user personas, mapas de empatía y escenarios actuales. Mi trabajo contribuyó a presentar evidencia relevante sobre las necesidades del usuario y su relación con los requerimientos del producto.
**Sulca Gonzales, Paul Fernando – 20221C486**
Trabajé comunicando de forma escrita los contenidos del Capítulo III, enfocados en to-be scenario mapping, user stories, product backlog e impact mapping. Mi aporte permitió transformar los hallazgos del análisis en requisitos claros, priorizados y alineados con los objetivos del producto. | Como equipo, se logró comunicar por escrito las ideas, resultados y decisiones del proyecto de manera estructurada y objetiva. El documento integra información sobre negocio, usuarios, requerimientos y diseño estratégico, manteniendo una secuencia lógica entre los capítulos. Además, la redacción permitió presentar el proyecto de forma comprensible para audiencias con distintos niveles de conocimiento técnico. | +| **Criterio específico** | **Acciones realizadas** | **Conclusiones** | +|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| **Comunica oralmente sus ideas y/o resultados con objetividad a público de diferentes especialidades y niveles jerárquicos, en el marco del desarrollo de un proyecto en ingeniería.** | **TB1**
**Gutiérrez Soto, Jhosepmyr Orlando – 202317638**
Trabajé comunicando oralmente los aspectos generales del proyecto relacionados con el Capítulo I y parte del Capítulo IV. Expliqué la descripción de la startup, la propuesta de solución y los fundamentos estratégicos del producto, procurando presentar las ideas de manera clara, ordenada y comprensible para una audiencia académica.
**Hernández Tuiro, Eric Ernesto – 20221C857**
Trabajé comunicando oralmente los contenidos vinculados al Capítulo I y Capítulo IV. Presenté ideas relacionadas con el perfil de la solución, el enfoque estratégico del producto y las decisiones generales de diseño, utilizando un lenguaje objetivo y adecuado para explicar la relación entre la problemática identificada y la solución propuesta.
**Ramirez Mestanza, Salim Ignacio – 20201E843**
Trabajé comunicando oralmente los avances desarrollados en el Capítulo II, principalmente los resultados del análisis de requerimientos, entrevistas, competidores y hallazgos del proceso de need finding. Mi participación permitió explicar cómo se identificaron necesidades relevantes para orientar el desarrollo del producto.
**Varela Bustinza, Marcelo Alessandro – 202319668**
Trabajé comunicando oralmente los resultados correspondientes al Capítulo II, especialmente el análisis competitivo, las estrategias frente a competidores, el diseño y análisis de entrevistas, así como los principales hallazgos obtenidos sobre los usuarios. Busqué explicar la información de manera objetiva, conectando los resultados con la definición de requerimientos del proyecto.
**Sulca Gonzales, Paul Fernando – 20221C486**
Trabajé comunicando oralmente los contenidos del Capítulo III, relacionados con la especificación de requerimientos, user stories, product backlog e impact mapping. Expliqué cómo los hallazgos obtenidos en etapas anteriores se transformaron en requisitos y elementos priorizados para el desarrollo de la solución.
**TP**
**Gutiérrez Soto, Jhosepmyr Orlando – 202317638**
Trabajé comunicando oralmente mis ideas con objetividad al presentar la arquitectura y diseño de cada bounded context en el Capítulo V. Adapté mi lenguaje para que perfiles tanto técnicos (desarrolladores) como de negocio (stakeholders) comprendieran cómo los componentes tácticos resuelven los problemas del proyecto de ingeniería.
**Hernández Tuiro, Eric Ernesto – 20221C857**
Trabajé comunicando oralmente los resultados de la refactorización aplicada al Event Storming y sustenté los diagramas del Capítulo V. Expuse estas ideas con objetividad, asegurándome de que las decisiones de diseño arquitectónico fueran claras para una audiencia de diferentes niveles jerárquicos y especialidades.
**Ramirez Mestanza, Salim Ignacio – 20201E843**
Trabajé comunicando oralmente las especificaciones de la landing page y el diseño y estilos de la versión mobile, correspondientes al Capítulo VI. Presenté mis ideas de forma objetiva, demostrando cómo las decisiones de interfaz de usuario se alinean con los requerimientos técnicos y de ingeniería.
**Varela Bustinza, Marcelo Alessandro – 202319668**
Comuniqué oralmente los resultados del diseño UX/UI de la aplicación web de Reqs-AI, explicando el flujo completo desde la autenticación y creación del workspace hasta la gestión de proyectos, sesiones de descubrimiento, revisión de historias de usuario, integración con Jira, facturación y configuración del equipo. Además, sustenté la relación entre wireframes, wireflows y mock-ups, destacando cómo cada pantalla mantiene coherencia visual, navegación consistente y alineación con las funcionalidades principales del producto.
**Sulca Gonzales, Paul Fernando – 20221C486**
Trabajé comunicando oralmente la refactorización de las User Stories y del Product Backlog, además de sustentar partes del Capítulo V. Mantuve objetividad al explicar cómo las historias guían el desarrollo de la ingeniería, asegurando que el público de diferentes especialidades entendiera su impacto en la arquitectura. | **TB1**
Como equipo, se logró comunicar oralmente los avances del proyecto de manera clara, organizada y objetiva. Cada integrante explicó los resultados correspondientes a su participación, conectando los capítulos desarrollados con el propósito general de la solución. Asimismo, la exposición permitió adaptar el lenguaje técnico a una audiencia académica, integrando aspectos de negocio, usuarios, requerimientos y diseño de ingeniería.
**TP**
Como equipo en esta etapa (TP), logramos sustentar oralmente decisiones arquitectónicas complejas y diseños de interfaz. Comunicamos con objetividad cómo el diseño táctico de los Bounded Contexts y las mejoras en UX/UI resuelven las necesidades del negocio. Adaptamos nuestra exposición para que tanto perfiles gerenciales (enfocados en el valor del producto) como técnicos (enfocados en patrones de ingeniería) comprendieran claramente la evolución y escalabilidad del sistema. | +| **Comunica en forma escrita ideas y/o resultados con objetividad a público de diferentes especialidades y niveles jerárquicos, en el marco del desarrollo de un proyecto en ingeniería.** | **TB1**
**Gutiérrez Soto, Jhosepmyr Orlando – 202317638**
Trabajé comunicando de forma escrita los contenidos relacionados con el Capítulo I y parte del Capítulo IV. Redacté información sobre el perfil de la startup, la propuesta de solución y los elementos estratégicos del diseño del producto, procurando mantener una estructura clara y una redacción adecuada para el contexto académico y de ingeniería.
**Hernández Tuiro, Eric Ernesto – 20221C857**
Trabajé comunicando de forma escrita los apartados vinculados al Capítulo I y Capítulo IV. Mi aporte se centró en organizar y redactar ideas sobre la solución propuesta, su relación con la problemática y los criterios estratégicos del producto, asegurando coherencia entre el enfoque del proyecto y las decisiones de diseño.
**Ramirez Mestanza, Salim Ignacio – 20201E843**
Trabajé comunicando de forma escrita los contenidos del Capítulo II, principalmente en los apartados de análisis de requerimientos, entrevistas, competidores, identificación de necesidades y lenguaje ubicuo. Mi aporte permitió documentar los hallazgos de manera ordenada y orientada a sustentar la definición de requerimientos.
**Varela Bustinza, Marcelo Alessandro – 202319668**
Trabajé comunicando de forma escrita los resultados del Capítulo II, incluyendo el análisis competitivo, estrategias frente a competidores, diseño y análisis de entrevistas, user personas, mapas de empatía y escenarios actuales. Mi trabajo contribuyó a presentar evidencia relevante sobre las necesidades del usuario y su relación con los requerimientos del producto.
**Sulca Gonzales, Paul Fernando – 20221C486**
Trabajé comunicando de forma escrita los contenidos del Capítulo III, enfocados en to-be scenario mapping, user stories, product backlog e impact mapping. Mi aporte permitió transformar los hallazgos del análisis en requisitos claros, priorizados y alineados con los objetivos del producto.
**TP**
**Gutiérrez Soto, Jhosepmyr Orlando – 202317638**
Trabajé comunicando en forma escrita los resultados del diseño táctico de cada bounded context en el Capítulo V. Redacté la estructura de las capas de dominio, aplicación e infraestructura manteniendo objetividad técnica, utilizando diagramas estándar para que equipos de diferentes especialidades puedan comprender la arquitectura.
**Hernández Tuiro, Eric Ernesto – 20221C857**
Trabajé comunicando en forma escrita las mejoras y la refactorización aplicadas al Event Storming, documentando objetivamente las decisiones tomadas. Apoyé en la redacción técnica del Capítulo V, asegurando que la documentación sea comprensible y útil tanto para desarrolladores como para evaluadores del proyecto.
**Ramirez Mestanza, Salim Ignacio – 20201E843**
Trabajé comunicando en forma escrita los elementos del Capítulo VI, especificando la landing page y el diseño y estilos de la versión mobile del app. Documenté estas decisiones de UX/UI con objetividad, estructurando la información de manera que sea fácilmente interpretable por equipos de distintas disciplinas.
**Varela Bustinza, Marcelo Alessandro – 202319668**
Comuniqué de forma escrita la documentación del Capítulo VI: Solution UX Design, desarrollando secciones relacionadas con style guidelines, information architecture, wireframes, wireflows y mock-ups de la web application. Redacté subtítulos y descripciones para cada imagen, organicé los recursos visuales con nombres consistentes y expliqué cómo cada pantalla representa una acción o estado funcional dentro del flujo de Reqs-AI. Este trabajo permitió evidenciar la evolución desde la estructura de baja fidelidad hasta la propuesta visual final de la plataforma.
**Sulca Gonzales, Paul Fernando – 20221C486**
Trabajé comunicando en forma escrita la refactorización de las User Stories y la actualización del Product Backlog. Redacté estos artefactos con objetividad técnica para que sirvan de puente claro entre las necesidades del negocio y la implementación en ingeniería, apoyando también en la documentación del Capítulo V. | **TB1**
Como equipo, se logró comunicar por escrito las ideas, resultados y decisiones del proyecto de manera estructurada y objetiva. El documento integra información sobre negocio, usuarios, requerimientos y diseño estratégico, manteniendo una secuencia lógica entre los capítulos. Además, la redacción permitió presentar el proyecto de forma comprensible para audiencias con distintos niveles de conocimiento técnico.
**TP**
Para el entregable TP, el equipo demostró la capacidad de documentar formalmente la arquitectura de software (Capítulo V) y el diseño de la experiencia de usuario (Capítulo VI). Se estructuraron los modelos de dominio, diagramas tácticos y wireflows con estricta objetividad técnica. Esta documentación escrita permite que profesionales de diferentes especialidades, desde desarrolladores hasta líderes de proyecto, puedan entender las soluciones de ingeniería propuestas sin ambigüedades. | @@ -282,7 +321,6 @@ Nuestro enfoque inicial serán las Startups tecnológicas y empresas de desarrol Sabremos que hemos tenido éxito cuando observemos una reducción del 40% en las reuniones de seguimiento para aclaración de requisitos, una disminución significativa en el tiempo que el analista dedica al postprocesamiento de la información y una tasa de aceptación de historias de usuario superior al 80% en la primera iteración de revisión con el equipo de desarrollo. - #### 1.2.2.2. Lean UX Assumptions Esta sección presenta las suposiciones fundamentales del proyecto Reqs-AI, estructuradas bajo el marco de Lean UX. Aquí definimos los resultados de negocio esperados, los perfiles de usuario que enfrentan el problema y los beneficios tangibles que estos obtendrán al utilizar nuestra solución. @@ -757,7 +795,6 @@ Los user personas sintetizan patrones de comportamiento, objetivos, frustracione
-
### 2.3.2. User Task Matrix
En este User Task Matrix se detallan las tareas que realizan los dos segmentos objetivos considerados en Reqs-AI: el Líder Técnico de Startup y el Analista de Sistemas Enterprise. Las tareas descritas corresponden al trabajo real de levantamiento, validación y transferencia de requisitos, y se ejecutan independientemente de la existencia de una herramienta de software.
@@ -776,7 +813,6 @@ En este User Task Matrix se detallan las tareas que realizan los dos segmentos o
| Revisar grabaciones/minutas y depurar documentación para cerrar vacíos de información | sometimes | medium | always | high |
| Coordinar reuniones de seguimiento por dudas o contradicciones detectadas después del levantamiento | sometimes | medium | sometimes | high |
-
La principal diferencia está en el enfoque operativo: el Líder Técnico de Startup prioriza velocidad de ejecución y alineación práctica para codificar cuanto antes, mientras que el Analista de Sistemas Enterprise prioriza estandarización, trazabilidad y control de riesgo. Por ello, en el segmento enterprise aumentan la frecuencia e importancia de actividades formales como redacción estructurada, revisión exhaustiva de evidencias y gestión de cambios bajo criterios de gobernanza.
### 2.3.3. User Journey Mapping
@@ -864,87 +900,116 @@ El escenario To-Be propone sesiones de levantamiento con mayor validación en ti
El siguiente inventario detalla las funcionalidades del sistema. Nótese la diferenciación entre **US** (User Stories - Funcionalidades de interfaz/usuario) y **TS** (Technical Stories - API y Arquitectura backend).
-| ID | Título de la Historia | Descripción (Como... quiero... para...) | Criterios de Aceptación (BDD) | Épica Asociada |
-|:---------|:------------------------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:---------------|
-| **EP00** | **Landing Page y Captación de Leads** | Landing page pública orientada a convertir visitantes en usuarios mediante la exposición de la propuesta de valor y beneficios por segmentos B2B. | -- | -- |
-| US01 | Visualizar Propuesta de Valor (Hero) | Como visitante, quiero entender inmediatamente qué es Reqs-AI y su propuesta de valor principal en la cabecera (Hero), para decidir en los primeros segundos si me interesa continuar explorando la herramienta. | Feature: Landing Page - Hero SectionScenario: Carga inicial y visibilidad de conversión
Given un visitante que accede a la URL principal de Reqs-AI
When la página carga completamente
Then visualiza un título claro sobre la automatización de requisitos con IA
And un llamado a la acción (CTA) principal visible sin hacer scroll para iniciar el registro. | EP00 | -| US02 | Explorar Casos de Uso por Segmento | Como visitante, quiero alternar entre diferentes perfiles (ej. Consultoras vs Startups) en una sección interactiva, para ver beneficios y ejemplos específicos que se adapten a la realidad de mi equipo. | Feature: Landing Page - Segmentación Interactiva
Scenario Outline: Alternar entre perfiles de usuario
Given un visitante en la sección de 'Construido para tu equipo'
When hace clic en la pestaña del perfil <Perfil>
Then el contenido dinámico se actualiza sin recargar la página
And muestra el beneficio principal <Beneficio> asociado a ese perfil
Examples:
| Perfil | Beneficio |
|---|---|
| Consultoras de Software | Reducción de horas facturables en análisis y toma de requerimientos. |
| Product Managers / Startups | Integración directa con Jira y adopción de metodologías ágiles. |
Scenario: Visualización de respaldo social
Given un visitante explorando los beneficios de la herramienta
When llega a la sección de confianza (Social Proof)
Then el sistema le presenta un carrusel de testimonios o métricas de horas ahorradas
And no permite avanzar hacia el final sin antes exponer estas validaciones de mercado. | EP00 | -| US04 | Visualizar Planes y Precios | Como visitante evaluando la viabilidad financiera, quiero comparar los planes de suscripción (Gratuito, Pro, Equipo) de forma transparente, para determinar cuál se ajusta a mi presupuesto antes de crearme una cuenta. | Feature: Landing Page - Pricing
Scenario: Comparativa de planes (Toggle Mensual/Anual)
Given un visitante en la sección de Precios
When alterna el interruptor entre facturación 'Mensual' y 'Anual'
Then los precios de los planes de pago se actualizan dinámicamente mostrando el descuento aplicado
And cada tarjeta de plan contiene un CTA que redirige al formulario de registro correspondiente. | EP00 | -| **EP01** | **Autenticación y Seguridad** | Gestión de acceso y protección de identidad para los usuarios de Reqs-AI, garantizando que solo personal autorizado acceda a la plataforma y su historial. | -- | -- | -| US03 | Registro de cuenta | Como visitante que llega por primera vez a la plataforma, quiero crear una cuenta con mi correo y una contraseña, para poder acceder a mis proyectos y sesiones de captura de requisitos. | Feature: Registro de cuenta
Scenario: Registro exitoso (Happy Path)
Given un visitante en la página de registro
When ingresa un correo válido y una contraseña segura
Then el sistema crea la cuenta en estado 'pendiente de verificación'
And envía un correo con el enlace de activación
Scenario Outline: Validaciones de registro (Unhappy Paths)
Given un visitante en la página de registro
When ingresa datos con el problema <Problema>
Then el sistema rechaza el registro indicando <Mensaje>
Examples:
| Problema | Mensaje |
|---|---|
| El correo ya está registrado en otra cuenta | El correo ingresado ya se encuentra en uso. |
| La contraseña tiene menos de 8 caracteres | La contraseña debe tener al menos 8 caracteres. |
| El formato del correo es inválido | Ingresa un correo electrónico válido. |
Scenario: Verificación exitosa (Happy Path)
Given un usuario con cuenta pendiente de activación
When hace clic en el enlace de verificación recibido por correo
Then el sistema activa la cuenta
And redirige al usuario al inicio de sesión
Scenario: Enlace expirado o inválido (Unhappy Path)
Given un usuario con un enlace de verificación
When el enlace fue usado previamente o ya expiró su vigencia
Then el sistema muestra un error de enlace inválido
And ofrece la opción de reenviar un nuevo correo de verificación | EP01 | -| US05 | Inicio de sesión | Como usuario con cuenta activa, quiero iniciar sesión con mi correo y contraseña, para acceder a mis proyectos y al historial de sesiones de mi organización. | Feature: Inicio de sesión
Scenario: Autenticación exitosa (Happy Path)
Given un usuario con cuenta activa
When ingresa sus credenciales correctas
Then el sistema le concede acceso
And lo redirige al panel principal de su última organización activa
Scenario Outline: Fallos de autenticación (Unhappy Paths)
Given un usuario intentando iniciar sesión
When ocurre la situación <Situacion>
Then el sistema deniega el acceso con el mensaje <Error>
Examples:
| Situacion | Error |
|---|---|
| Contraseña incorrecta | Credenciales inválidas. |
| La cuenta aún no ha sido verificada | Debes verificar tu correo antes de iniciar sesión. |
| Demasiados intentos fallidos consecutivos | Cuenta bloqueada temporalmente por seguridad. |
Scenario: Solicitar recuperación (Happy Path)
Given un usuario que olvidó su contraseña
When ingresa su correo en el formulario de recuperación
Then el sistema envía un enlace de restablecimiento
And muestra un mensaje genérico de confirmación por seguridad
Scenario: Prevenir enumeración de usuarios (Edge Case - Seguridad)
Given un visitante malintencionado
When ingresa un correo que no existe en el sistema
Then el sistema no revela que el correo es inexistente
And muestra el mismo mensaje genérico de confirmación | EP01 | -| **EP02** | **Organizaciones** | Gestión de espacios de trabajo independientes para separar la información de diferentes empresas o equipos, garantizando que cada organización acceda únicamente a sus propios datos. | -- | -- | -| US07 | Crear organización | Como usuario autenticado que aún no pertenece a ninguna organización, quiero crear un espacio de trabajo con el nombre de mi empresa, para centralizar mis proyectos y gestionar mi equipo en un entorno separado. | Feature: Crear organización
Scenario: Creación exitosa (Happy Path)
Given un usuario autenticado sin organización
When crea una organización con un nombre válido
Then el sistema genera el espacio de trabajo
And asigna al usuario el rol inamovible de 'Propietario'
Scenario: Nombre de organización vacío (Unhappy Path)
Given un usuario creando una organización
When deja el nombre en blanco
Then el sistema bloquea la creación exigiendo un nombre obligatorio | EP02 | -| US32 | Editar organización | Como Propietario de la organización, quiero actualizar el nombre o los datos generales de mi organización, para mantener la información correcta cuando el equipo o el negocio cambia. | Feature: Editar organización
Scenario: Actualizar datos (Happy Path)
Given el Propietario de una organización
When modifica el nombre y guarda los cambios
Then la organización actualiza sus datos en toda la plataforma
Scenario: Intento de edición sin permisos (Unhappy Path)
Given un miembro regular de la organización
When intenta acceder a la configuración de la organización
Then el sistema oculta o bloquea la opción por falta de privilegios | EP02 | -| US33 | Cambiar de organización | Como usuario que pertenece a más de una organización, quiero seleccionar con cuál quiero trabajar desde el menú principal, para asegurarme de estar operando en el contexto correcto según el cliente que estoy atendiendo. | Feature: Cambiar de organización
Scenario: Cambio exitoso de contexto (Happy Path)
Given un usuario que pertenece a múltiples organizaciones
When selecciona una organización distinta desde el menú
Then el sistema recarga el contexto de trabajo
And muestra únicamente los proyectos de la organización seleccionada
Scenario: Eliminación concurrente (Edge Case)
Given un usuario intentando cambiar a la Organización B
When el propietario de la Organización B lo elimina en ese mismo instante
Then el sistema deniega el acceso y lo devuelve a su organización actual | EP02 | -| US41 | Política de retención de audios | Como Propietario de la organización, quiero configurar la eliminación automática de los archivos de audio originales X días después de procesarse, para cumplir con las políticas de privacidad y confidencialidad corporativas. | Feature: Política de retención de audios
Scenario: Eliminación automática al cumplir plazo (Happy Path)
Given una organización con la retención configurada en 7 días
When se cumple el plazo desde que un audio fue procesado
Then el sistema elimina permanentemente el archivo de audio físico
And conserva únicamente las historias generadas en texto
Scenario: Intentar acceder a un audio eliminado (Unhappy Path)
Given un audio que ya superó su periodo de retención y fue purgado
When un usuario intenta reproducirlo o descargarlo desde el historial
Then el sistema muestra un aviso de que el archivo fue eliminado por políticas de privacidad corporativa | EP02 | -| **EP03** | **Suscripción y Facturación** | Gestión de planes y límites de uso del sistema basados en un modelo de suscripción SaaS. Épica de baja prioridad — no entra en los primeros sprints. | -- | -- | -| US42 | Plan gratuito automático | Como usuario que acaba de crear su organización, quiero empezar a usar la plataforma sin ingresar datos de pago, para evaluar si se ajusta a mis necesidades antes de decidir suscribirme. | Feature: Plan gratuito automático
Scenario: Asignación por defecto (Happy Path)
Given un usuario que acaba de crear una nueva organización
When ingresa a su panel por primera vez
Then el sistema le asigna el 'Plan Gratuito'
And habilita las cuotas iniciales sin solicitar método de pago | EP03 | -| US43 | Suscripción al plan Pro | Como Propietario de una organización en plan gratuito, quiero contratar el plan Pro, para acceder a sesiones ilimitadas, captura en tiempo real e integración con Jira. | Feature: Suscripción al plan Pro
Scenario: Upgrade de plan exitoso (Happy Path)
Given el Propietario de una organización en plan gratuito
When ingresa un método de pago válido y contrata el Plan Pro
Then los límites de la organización se expanden inmediatamente
And se emite la factura correspondiente
Scenario: Tarjeta rechazada (Unhappy Path)
Given un Propietario intentando hacer upgrade
When la pasarela de pagos rechaza la tarjeta por fondos insuficientes
Then el sistema mantiene el plan gratuito
And notifica el error de pago al usuario | EP03 | -| US44 | Suscripción al plan Equipo | Como Propietario de una organización en plan Pro, quiero contratar el plan Equipo, para poder agregar a todos los miembros de mi equipo y definir mediante roles personalizados qué puede hacer cada uno. | Feature: Suscripción al plan Equipo
Scenario: Upgrade a Equipo (Happy Path)
Given el Propietario de una organización en Plan Pro
When contrata el Plan Equipo
Then se habilitan las funciones de gestión avanzada de roles y miembros múltiples | EP03 | -| US45 | Cancelación de suscripción | Como Propietario de una suscripción activa, quiero cancelar mi plan antes de que inicie el siguiente período de facturación, para no recibir cargos adicionales después de dejar de usar el servicio. | Feature: Cancelación de suscripción
Scenario: Cancelar antes de renovación (Happy Path)
Given el Propietario de una suscripción paga activa
When cancela la suscripción desde el panel
Then el sistema desactiva la auto-renovación
And mantiene los beneficios premium hasta el final del ciclo de facturación actual | EP03 | -| US46 | Ver estado del plan y consumo | Como Propietario de la organización, quiero ver el plan activo, la fecha de renovación y cuántas sesiones o proyectos he usado, para saber cuándo necesito actualizar mi plan antes de quedarme sin cupo. | Feature: Ver estado del plan y consumo
Scenario: Visualización de cuotas (Happy Path)
Given el Propietario de la organización
When ingresa a la sección de facturación
Then visualiza una barra de progreso con el consumo actual de sesiones frente al límite de su plan
Scenario: Límite alcanzado (Edge Case)
Given una organización que alcanzó exactamente el 100% de su límite
When el usuario visualiza el estado
Then el sistema muestra una alerta destacada invitando al upgrade | EP03 | -| US47 | Dashboard de valor y ahorro de tiempo | Como Propietario de la organización, quiero ver un panel que traduzca las historias generadas en 'horas de trabajo manual ahorradas', para justificar el pago de la suscripción y entender el retorno de inversión mensual de la herramienta. | Feature: Dashboard de ROI
Scenario: Calcular ROI exitosamente (Happy Path)
Given una organización con proyectos y sesiones generadas
When el administrador ingresa al dashboard principal
Then el sistema calcula el tiempo humano ahorrado en base a las horas de audio procesadas vs redacción manual
And muestra gráficas de productividad y métricas clave de retorno de inversión
Scenario: Organización sin historial (Unhappy Path)
Given una organización recién creada sin sesiones activas
When el administrador visita el dashboard
Then el sistema muestra un estado vacío con un mensaje orientativo sobre cómo comenzar a capturar valor | EP03 | -| **EP04** | **Gestión de Proyectos** | Creación, configuración y ciclo de vida de los proyectos por cliente, incluyendo la carga de conocimiento previo que permite a la IA generar historias más precisas. | -- | -- | -| US08 | Crear proyecto | Como miembro con permiso para crear proyectos, quiero registrar un proyecto asociado a un cliente específico, para organizar y separar todas las sesiones de levantamiento de requisitos de ese cliente. | Feature: Crear proyecto
Scenario: Creación de proyecto válida (Happy Path)
Given un usuario con permisos de creación
When crea un proyecto indicando el nombre del cliente
Then el proyecto aparece en el listado activo de la organización
Scenario: Proyecto duplicado (Unhappy Path)
Given un usuario creando un proyecto
When ingresa un nombre que ya existe activo en la misma organización
Then el sistema sugiere usar un nombre distinto para evitar confusiones | EP04 | -| US10 | Cargar documentos del cliente | Como miembro con permiso para configurar proyectos, quiero subir documentos y glosarios del cliente al proyecto, para que las historias generadas reflejen el vocabulario y las reglas del negocio de ese cliente de forma observable en cada historia producida. | Feature: Cargar documentos del cliente
Scenario: Carga de contexto exitosa (Happy Path)
Given un usuario configurando un proyecto
When sube un glosario en PDF válido
Then el sistema procesa el documento y lo incorpora a la base de conocimiento de la IA para futuras sesiones
Scenario Outline: Restricciones de carga documental (Unhappy Paths)
Given un usuario intentando subir documentos de contexto
When ocurre el escenario <Fallo>
Then el sistema rechaza el archivo indicando <Error>
Examples:
| Fallo | Error |
|---|---|
| El archivo es un ejecutable (.exe) | Solo se permiten documentos de texto o PDF. |
| El archivo excede los 50MB | El documento es demasiado pesado. |
Scenario: Guardar perfil técnico (Happy Path)
Given un usuario con permisos en el proyecto
When define que el stack es 'React + Node' y guarda
Then el sistema utiliza esta instrucción como prompt base para la generación de criterios técnicos en las historias de usuario | EP04 | -| US30 | Editar proyecto | Como miembro con permiso para administrar proyectos, quiero modificar el nombre o la descripción de un proyecto existente, para corregir o actualizar la información cuando cambian los acuerdos con el cliente. | Feature: Editar proyecto
Scenario: Modificar datos del proyecto (Happy Path)
Given un usuario administrador del proyecto
When cambia la descripción del proyecto
Then los cambios se reflejan inmediatamente en el panel del equipo | EP04 | -| US31 | Archivar proyecto | Como miembro con permiso para administrar proyectos, quiero archivar un proyecto cuando termina el trabajo con ese cliente, para mantener el panel principal ordenado sin eliminar el historial de sesiones e historias generadas. | Feature: Archivar proyecto
Scenario: Archivar proyecto finalizado (Happy Path)
Given un proyecto activo
When el administrador lo archiva
Then el proyecto se oculta de las vistas principales pero mantiene su historial intacto
Scenario: Operaciones en proyecto archivado (Edge Case)
Given un proyecto en estado archivado
When un usuario intenta iniciar una nueva sesión de captura
Then el sistema bloquea la acción hasta que el proyecto sea desarchivado | EP04 | -| US09 | Proyecto de demostración automático | Como nuevo usuario que acaba de registrarse, quiero encontrar un proyecto de demostración pre-cargado con audios e historias ya generadas, para entender inmediatamente el valor de la plataforma sin tener que grabar mi propia reunión primero. | Feature: Proyecto Sandbox de Demo
Scenario: Cargar datos de demostración en nueva cuenta (Happy Path)
Given un usuario que acaba de registrarse exitosamente en la plataforma
When accede a su organización por primera vez
Then el sistema genera e inserta un proyecto de demostración pre-poblado (con audios, historias y transcripciones de ejemplo)
And lo marca visualmente como 'Sandbox / Demo' para que el usuario experimente de inmediato
Scenario: Restaurar proyecto de demostración (Flujo Alternativo)
Given un usuario que eliminó su proyecto de demostración
When hace clic en 'Restaurar datos de prueba' desde la configuración
Then el sistema vuelve a clonar el proyecto de ejemplo en su espacio de trabajo | EP04 | -| **EP05** | **Colaboración y Roles** | Gestión de roles personalizados con permisos configurables y administración de los miembros del equipo dentro de la organización y sus proyectos. El Propietario es el único rol fijo del sistema — es quien creó la organización, tiene todos los permisos y es el responsable del contrato. Todos los demás roles son creados y configurados por el Propietario. | -- | -- | -| US34 | Invitar miembro a la organización | Como miembro con permiso para gestionar el equipo, quiero invitar a un colega mediante su correo electrónico, para que pueda acceder a los proyectos que le correspondan dentro de la organización. | Feature: Invitar miembro
Scenario: Enviar invitación (Happy Path)
Given un usuario con permisos de gestión de equipo
When envía una invitación a un correo válido
Then el invitado recibe el correo con el enlace de acceso
And aparece en estado 'Pendiente' en el panel
Scenario Outline: Fallos de invitación (Unhappy Paths)
Given un administrador invitando a un usuario
When comete el error <Error_Inv>
Then la invitación falla indicando <Aviso>
Examples:
| Error_Inv | Aviso |
|---|---|
| El correo ya pertenece a la organización | El usuario ya es miembro del equipo. |
| El correo ya tiene una invitación pendiente | Ya existe una invitación enviada a este correo. |
Scenario: Rol creado exitosamente (Happy Path)
Given el Propietario de la organización
When crea el rol 'QA Lead'
Then el nuevo rol queda disponible para ser asignado a cualquier miembro | EP05 | -| US36 | Asignar permisos a un rol | Como Propietario de la organización, quiero seleccionar qué acciones puede realizar cada rol dentro de los proyectos y la organización, para que el nivel de acceso de cada miembro refleje exactamente sus responsabilidades reales. | Feature: Asignar permisos a un rol
Scenario: Configurar permisos (Happy Path)
Given el Propietario configurando un rol
When activa los permisos de 'Crear Sesiones' y 'Aprobar Historias'
Then todos los usuarios con ese rol adquieren dichas capacidades inmediatamente | EP05 | -| US37 | Asignar rol a un miembro | Como miembro con permiso para gestionar el equipo, quiero asignar uno de los roles disponibles a un miembro de la organización, para que sus permisos queden definidos en el momento en que acepta la invitación. Depende de: US19 y US20. | Feature: Asignar rol a un miembro
Scenario: Cambio de rol (Happy Path)
Given un administrador de equipo
When cambia el rol del Usuario A de 'Lector' a 'Editor'
Then el Usuario A obtiene acceso a las herramientas de edición en su próxima navegación | EP05 | -| US38 | Editar permisos de un rol existente | Como Propietario de la organización, quiero modificar los permisos de un rol ya creado, para ajustar el nivel de acceso de todos los miembros que lo tienen asignado cuando cambian sus responsabilidades. | Feature: Editar permisos de un rol existente
Scenario: Propagación de permisos (Happy Path)
Given un rol asignado a 5 usuarios
When el Propietario revoca el permiso de 'Exportar'
Then los 5 usuarios pierden la capacidad de exportar instantáneamente sin necesidad de re-login | EP05 | -| US39 | Eliminar un rol | Como Propietario de la organización, quiero eliminar un rol que ya no corresponde a ninguna función activa del equipo, para mantener la lista de roles ordenada y evitar asignaciones incorrectas. | Feature: Eliminar un rol
Scenario: Eliminar rol sin uso (Happy Path)
Given un rol personalizado que no tiene usuarios asignados
When el Propietario lo elimina
Then el rol desaparece definitivamente de la organización
Scenario: Intento de eliminar rol en uso (Unhappy Path)
Given un rol que está asignado a al menos un miembro
When el Propietario intenta eliminarlo
Then el sistema bloquea la eliminación
And exige reasignar a esos miembros a otro rol antes de proceder | EP05 | -| US40 | Remover miembro de la organización | Como miembro con permiso para gestionar el equipo, quiero remover a un miembro de la organización, para revocar su acceso a todos los proyectos de forma inmediata cuando ya no forma parte del equipo. | Feature: Remover miembro de la organización
Scenario: Remoción exitosa (Happy Path)
Given un administrador de equipo
When remueve al Usuario B de la organización
Then el Usuario B pierde acceso inmediatamente a todos los proyectos de esa organización
Scenario: Intento de remover al Propietario (Edge Case - Seguridad)
Given un administrador de equipo
When intenta remover al Propietario original de la cuenta
Then el sistema bloquea la acción indicando que el rol de Propietario es intransferible e irremovible | EP05 | -| **EP06** | **Captura en Tiempo Real** | Funcionalidad principal del producto que procesa audio en vivo para generar historias de usuario de forma automática mientras la reunión con el cliente ocurre. Las sesiones requieren un proyecto existente. | -- | -- | -| US32 | Iniciar sesión de captura en vivo | Como miembro con permiso para crear sesiones, quiero activar la captura de audio durante la reunión dentro de un proyecto existente, para que el sistema identifique quién habla en cada momento y genere las historias a partir de lo que dice el cliente sin que yo tenga que tomar notas. Depende de: US13. | Feature: Captura en vivo
Scenario: Iniciar captura exitosamente (Happy Path)
Given que el usuario tiene permisos y el proyecto es válido
When inicia la captura de audio en vivo
Then la sesión cambia a estado 'activa' y comienza a registrar el habla
Scenario Outline: Validaciones al intentar iniciar captura (Unhappy Paths)
Given que el usuario intenta iniciar una sesión de captura en vivo
When ocurre la situación <Condicion>
Then el sistema impide el inicio de la sesión
And muestra el mensaje <Mensaje_Error>
Examples:
| Condicion | Mensaje_Error |
|---|---|
| El navegador no tiene permisos de micrófono | Debes otorgar permisos de micrófono para continuar. |
| El usuario tiene un rol sin permisos de creación | No tienes permisos para crear sesiones en este proyecto. |
| El proyecto seleccionado se encuentra archivado | El proyecto está archivado y no admite nuevas sesiones. |
Scenario: Pérdida de conexión al iniciar (Unhappy Path - Flujo Alternativo)
Given que el usuario inicia la captura
When se pierde la conexión a internet antes de confirmar con el servidor
Then el sistema cancela la creación de la sesión
And notifica al usuario que verifique su conexión | EP06 | -| US33 | Generación automática de historias | Como analista en sesión activa, quiero que el sistema convierta automáticamente lo que dice el cliente en historias de usuario con criterios de aceptación, para obtener un backlog estructurado al finalizar la reunión sin necesidad de documentar después. | Feature: Generación automática de historias
Scenario: Extraer historia desde un requisito claro (Happy Path)
Given una sesión activa
When el sistema detecta un requisito válido en la intervención del cliente
Then genera una historia de usuario con criterios de aceptación
And la agrega al backlog de la sesión en tiempo real
Scenario: Manejo de audio incomprensible o ruido (Unhappy Path)
Given una sesión activa
When el cliente habla de temas irrelevantes o hay ruido de fondo
Then el sistema ignora la intervención
And no genera historias vacías ni interrumpe la captura
Scenario: Intervención larga con múltiples requisitos (Edge Case)
Given una sesión activa
When el cliente menciona varios requerimientos distintos en una sola intervención continua
Then el sistema separa lógicamente los temas
And crea una historia individual por cada requerimiento detectado | EP06 | -| US19 | Descartar historia (Componente Unificado) | Como analista, quiero descartar una historia generada indicando un motivo, tanto durante la sesión en vivo como en la etapa de revisión posterior, utilizando una misma interfaz para mantener el backlog limpio. | Feature: Descarte de historias en vivo
Scenario: Descartar historia correctamente (Happy Path)
Given una historia recién generada en el backlog de la sesión
When el analista la descarta ingresando un motivo válido
Then la historia se oculta del backlog activo
And queda registrada en el historial con su motivo
Scenario Outline: Validaciones al descartar (Unhappy Paths)
Given que el analista intenta descartar una historia
When el formulario presenta el problema <Problema>
Then el sistema bloquea el descarte
And solicita la corrección con el mensaje <Mensaje>
Examples:
| Problema | Mensaje |
|---|---|
| El campo de motivo está completamente vacío | Debes ingresar un motivo para descartar la historia. |
| El motivo excede el límite de caracteres (ej. 500) | El motivo es demasiado largo. |
Scenario: Descarte concurrente (Unhappy Path - Flujo Alternativo)
Given una historia visible en pantalla
When el analista intenta descartarla pero otro usuario ya lo hizo segundos antes
Then el sistema alerta que el estado de la historia ha cambiado
And refresca la vista del backlog | EP06 | -| US15 | Pausar y reanudar captura | Como analista durante una sesión activa, quiero pausar la captura cuando la conversación se desvía del tema o hay un receso, para evitar que se generen historias a partir de conversaciones que no son requisitos del cliente. | Feature: Pausa y reanudación
Scenario: Pausar y reanudar la captura (Happy Path)
Given una sesión en estado activa
When el analista pausa la sesión
Then el sistema detiene temporalmente la generación de historias
And al reanudarla, continúa el procesamiento normalmente
Scenario: Intentar pausar una sesión ya pausada (Unhappy Path de concurrencia)
Given una sesión que fue pausada por el analista A
When el analista B intenta pausarla desde otro dispositivo sin haber refrescado
Then el sistema ignora la acción
And sincroniza el estado de la UI para el analista B informando la pausa | EP06 | -| US16 | Cerrar y guardar sesión | Como analista al terminar una reunión, quiero finalizar la sesión de captura, para asegurar que todas las historias generadas queden guardadas en el historial del proyecto. | Feature: Cierre de sesión
Scenario: Cerrar sesión con historias guardadas (Happy Path)
Given una sesión activa con al menos una historia generada
When el analista cierra la sesión de captura
Then la sesión pasa a estado 'cerrada'
And todas las historias se persisten en el proyecto principal
Scenario: Prevenir pérdida de datos al cerrar (Unhappy Path - Flujo de Red)
Given una sesión activa con historias sin sincronizar al backend
When el usuario intenta cerrar la sesión pero no hay conexión a internet
Then el sistema bloquea el cierre temporalmente
And muestra una advertencia de sincronización pendiente para evitar pérdida de datos
Scenario: Cerrar sesión vacía (Edge Case)
Given una sesión activa en la que no se generó ninguna historia
When el analista cierra la sesión
Then el sistema permite el cierre
And muestra el resumen final con contadores en cero | EP06 | -| US18 | Abortar sesión sin guardar | Como analista en una sesión de captura, quiero poder abortar y descartar la reunión por completo si hubo un error (ej. reunión cancelada), para no ensuciar el historial del proyecto con datos basura. | Feature: Abortar sesión en vivo
Scenario: Cancelar y purgar sesión (Happy Path)
Given una sesión activa que no debe ser guardada
When el analista selecciona la opción 'Abortar y salir'
And confirma la advertencia destructiva
Then el sistema purga todas las historias generadas temporalmente
And cierra la sesión sin dejar rastro en el historial del proyecto
Scenario: Abortar por error sin confirmación (Unhappy Path)
Given una sesión activa
When el analista hace clic en 'Abortar'
Then el sistema muestra un modal de confirmación estricto pidiendo tipear 'ELIMINAR'
And no ejecuta el borrado hasta validar el input | EP06 | -| US13 | Etiquetar voz del cliente (Diarización) | Como analista revisando una sesión, quiero poder identificar y etiquetar qué voz corresponde al 'Cliente' y cuáles al 'Equipo', para que la IA priorice las necesidades del cliente y no genere historias basadas en nuestras propias preguntas. | Feature: Diarización (Etiquetado de locutor)
Scenario: Distinguir locutores automáticamente (Happy Path)
Given una sesión de grabación con múltiples participantes (ej. 2 clientes y 1 analista)
When el motor procesa el audio de entrada
Then el sistema segmenta el audio y asigna la transcripción a etiquetas como 'Speaker 1', 'Speaker 2'
And el analista puede renombrar esas etiquetas con los nombres reales de los participantes
Scenario: Audio con superposición de voces (Unhappy Path - Modelo)
Given una sesión activa donde dos personas hablan exactamente al mismo tiempo y fuerte
When el sistema intenta diarizar ese segmento superpuesto
Then el sistema agrupa ambas voces como 'Speaker X'
And advierte sutilmente en la transcripción sobre 'Superposición de voces detectada' | EP06 | -| **EP07** | **Procesamiento de Audio Grabado** | Funcionalidad para procesar grabaciones de reuniones anteriores cuando no fue posible usar la captura en tiempo real. | -- | -- | -| US39 | Subir grabación de reunión | Como miembro con permiso para crear sesiones, quiero subir el archivo de audio de una reunión pasada dentro de un proyecto específico, para que el sistema extraiga los requisitos aplicando el glosario y contexto técnico de ese proyecto. | Feature: Carga de grabaciones
Scenario: Procesar exitosamente una grabación válida (Happy Path)
Given que el usuario tiene permisos para crear sesiones
And la organización tiene minutos de procesamiento disponibles
When el usuario sube un archivo de audio válido
Then el sistema acepta el archivo
And inicia la extracción de requisitos automáticamente sin intervención manual
Scenario Outline: Rechazar carga de grabaciones inválidas o no permitidas (Unhappy Paths)
Given que el usuario intenta subir una grabación
When ocurre la situación descrita en <Condicion_Invalida>
Then el sistema rechaza la carga
And muestra el mensaje explicativo <Mensaje_Esperado>
And no descuenta minutos del plan de suscripción de la organización
Examples:
| Condicion_Invalida | Mensaje_Esperado |
|---|---|
| El archivo tiene un formato no soportado (ej. .pdf, .docx) | El formato del archivo no está soportado. |
| El archivo de audio está corrupto o dañado | El archivo de audio no se puede leer o está dañado. |
| El archivo supera el límite de tamaño máximo permitido | El archivo supera el límite de tamaño permitido. |
| La organización agotó su límite de minutos mensuales | Has alcanzado el límite de procesamiento de tu plan actual. |
Scenario: Procesar audio extremadamente largo (Happy Path)
Given un archivo de audio que excede la ventana de contexto del LLM (ej. reunión de 2 horas)
When el sistema inicia el proceso de transcripción y análisis
Then divide internamente el audio en bloques lógicos (chunks) sin cortar oraciones por la mitad
And los procesa en lote para consolidar los requisitos sin error de límite de tokens
Scenario: Error al ensamblar chunks (Unhappy Path - Backend)
Given un audio dividido en 5 fragmentos
When el motor de IA procesa exitosamente 4 pero falla en 1 por intermitencia de red
Then el sistema reintenta exclusivamente el fragmento fallido en lugar de reiniciar todo el procesamiento
And garantiza que no se pierda la información ensamblando el resultado final de forma consistente | EP07 | -| US14 | Ver estado del procesamiento | Como miembro que subió un archivo de audio, quiero ver el avance del procesamiento de forma visible en la pantalla, para saber cuándo las historias están listas sin tener que revisar la sección manualmente cada cierto tiempo. Depende de: US30. | Feature: Estado del procesamiento
Scenario: Consultar el avance del procesamiento (Happy Path)
Given que un archivo de audio se subió exitosamente
When el usuario consulta la vista de procesamiento
Then el sistema muestra el estado actualizado (ej. 'En cola', 'Procesando', 'Completado')
And muestra un progreso estimado de ser posible
Scenario: Manejo de procesamiento fallido (Unhappy Path - Asíncrono)
Given que un archivo está en estado 'Procesando'
When el motor de IA falla o agota el tiempo de espera por un error interno
Then el estado de la tarea cambia a 'Fallido'
And la interfaz permite al usuario reintentar el procesamiento sin volver a subir el archivo | EP07 | -| **EP08** | **Asistencia Proactiva de la IA** | Capacidad del sistema para sugerir acciones al analista durante o después de la sesión con el fin de mejorar la calidad y completitud de los requisitos capturados. | -- | -- | -| US22 | Sugerencias de preguntas al cliente | Como analista durante o después de una sesión, quiero recibir una lista de preguntas concretas cuando el sistema detecta partes ambiguas en lo que dijo el cliente, para hacer esas preguntas antes de cerrar la reunión y evitar contactar al cliente después. Depende de: US26. | Feature: Sugerencias de preguntas al cliente
Scenario: Sugerir preguntas ante un requisito ambiguo (Happy Path)
Given que el sistema generó una historia a partir de la sesión
When la IA detecta partes ambiguas o contradictorias en lo dicho por el cliente
Then muestra una lista de preguntas concretas sugeridas
And vincula las preguntas al punto de ambigüedad específico
Scenario: Omitir sugerencias ante requisitos claros (Unhappy Path)
Given que el sistema generó una historia
When el requisito expresado por el cliente es completamente claro y detallado
Then el sistema no muestra sugerencias de preguntas irrelevantes | EP08 | -| US23 | Detección de casos no mencionados | Como analista revisando las historias generadas, quiero ver una lista de situaciones concretas que no se mencionaron en la reunión pero que suelen presentarse en ese tipo de módulo, para que el equipo las evalúe antes de empezar a construir y no las descubra durante el desarrollo. Depende de: US26. | Feature: Detección de casos no mencionados
Scenario: Proponer escenarios omitidos (Happy Path)
Given una historia de usuario estructurada sobre un módulo específico (ej. 'Login')
When el sistema analiza el contexto general de la historia
Then sugiere casos de uso típicos no mencionados por el cliente (ej. 'Bloqueo de cuenta tras N intentos fallidos')
Scenario Outline: Restricciones de sugerencia (Unhappy Paths)
Given una historia de usuario estructurada
When ocurre el escenario <Escenario>
Then el comportamiento del sistema será <Comportamiento>
Examples:
| Escenario | Comportamiento |
|---|---|
| El contexto del proyecto y el requisito son excesivamente genéricos | No inventa casos de uso sin fundamento ni genera ruido visual. |
| Existen docenas de posibles casos borde asociados al módulo | Filtra la lista y muestra únicamente los N casos más críticos y probables. |
Scenario: Sugerir funcionalidades típicas del dominio (Happy Path)
Given un proyecto con un dominio de negocio bien definido (ej. E-commerce)
When el sistema procesa los requerimientos actuales
Then sugiere funcionalidades complementarias comunes en el mercado (ej. 'Recuperación de carrito')
Scenario: Omitir repeticiones durante la sesión (Edge Case)
Given una sesión larga en curso
When el sistema genera un nuevo lote de sugerencias relacionadas
Then filtra cualquier funcionalidad que ya haya sido sugerida o descartada previamente en la misma sesión | EP08 | -| **EP09** | **Calidad y Detección de Duplicados** | Búsqueda semántica sobre el historial de historias aprobadas del proyecto para mantener la integridad y unicidad del backlog. | -- | -- | -| US20 | Detección de historias similares | Como analista en una sesión activa, quiero que el sistema me avise con el porcentaje de similitud cuando una historia nueva se parece a una que ya existe en el proyecto, para evitar que el backlog tenga requisitos redundantes o contradictorios entre sí. | Feature: Detección de historias similares
Scenario: Alertar duplicidad evidente (Happy Path)
Given una nueva historia recién generada
When su significado excede el porcentaje de similitud configurado respecto a una historia previamente aprobada
Then el sistema muestra una alerta de posible duplicado
And enlaza a la historia original para comparación
Scenario: Ignorar historias relacionadas pero distintas (Unhappy Path)
Given una nueva historia recién generada
When comparte palabras clave con historias anteriores pero el objetivo funcional es diferente (no supera el umbral de similitud semántica)
Then el sistema no levanta ninguna alerta de duplicidad | EP09 | -| US21 | Resolver historia duplicada | Como analista que recibió una alerta de similitud, quiero decidir si fusiono la nueva historia con la existente o la mantengo separada dejando registrada mi justificación, para que el backlog quede limpio con una decisión explícita visible en el historial. Depende de: US35. | Feature: Resolver historia duplicada
Scenario: Resolver manteniendo la historia separada (Happy Path)
Given una alerta activa de historia similar
When el analista elige la opción 'Mantener separada'
And escribe una justificación válida de negocio
Then la alerta se da por resuelta
And la justificación queda documentada en el historial de la historia
Scenario Outline: Validaciones al intentar resolver (Unhappy Paths)
Given una alerta activa de historia similar
When el analista intenta resolverla con la falla <Falla>
Then el sistema bloquea la resolución
And exige corregir la entrada indicando <Requisito>
Examples:
| Falla | Requisito |
|---|---|
| No seleccionó ni 'Fusionar' ni 'Mantener separada' | Debe elegir explícitamente una acción. |
| Eligió 'Mantener separada' pero dejó la justificación en blanco | La justificación es obligatoria para excepciones. |
Scenario: Intento de resolución concurrente (Unhappy Path - Concurrencia)
Given una alerta de similitud visible para dos analistas simultáneamente
When el analista A resuelve la alerta y segundos después el analista B intenta hacer lo mismo
Then el sistema rechaza la acción del analista B
And notifica que la alerta ya fue resuelta, actualizando la vista | EP09 | -| **EP10** | **Revisión, Edición y Aprobación** | Fase final del flujo donde el analista valida y ajusta el trabajo de la IA antes de que las historias queden listas para el equipo de desarrollo. | -- | -- | -| US47 | Editar historia generada | Como miembro con permiso para editar historias, quiero modificar el texto de una historia generada por la IA, para ajustar el lenguaje al estándar que usa mi equipo antes de aprobarla. | Feature: Editar historia generada
Scenario: Guardar cambios en el contenido (Happy Path)
Given que un usuario con permisos se encuentra editando una historia generada por la IA
When modifica el texto y presiona guardar
Then la historia actualiza su contenido
And preserva la etiqueta o trazabilidad de que su origen inicial fue generado por IA
Scenario Outline: Validaciones del formulario de edición (Unhappy Paths)
Given que el usuario intenta guardar las modificaciones de una historia
When el formulario presenta <Error_Formulario>
Then el sistema bloquea el guardado
And muestra el mensaje <Mensaje_Error>
Examples:
| Error_Formulario | Mensaje_Error |
|---|---|
| El título de la historia se ha borrado por completo | El título de la historia es obligatorio. |
| La descripción quedó completamente vacía | La descripción no puede estar vacía. |
Scenario: Conflicto de edición concurrente (Unhappy Path - Flujo Alternativo)
Given que dos usuarios abren la misma historia para editarla al mismo tiempo
When el usuario A guarda sus cambios y luego el usuario B intenta guardar los suyos
Then el sistema bloquea la acción del usuario B
And le advierte que la historia fue modificada externamente para evitar sobreescritura accidental | EP10 | -| US48 | Aprobar historia | Como miembro con permiso para aprobar historias, quiero marcar una historia como aprobada después de revisarla, para que quede disponible para el equipo de desarrollo y pueda exportarse al gestor de tareas. | Feature: Aprobar historia
Scenario: Aprobar historia revisada (Happy Path)
Given una historia completa en estado de revisión
When un usuario con permisos la marca como 'Aprobada'
Then el estado de la historia cambia a 'Aprobada'
And queda disponible en la cola para ser exportada a sistemas externos (ej. Jira)
Scenario Outline: Impedir aprobación de historias incompletas (Unhappy Paths)
Given que el usuario intenta aprobar una historia
When la historia tiene <Falla_Integridad>
Then la aprobación es rechazada
And el sistema indica <Razon_Rechazo>
Examples:
| Falla_Integridad | Razon_Rechazo |
|---|---|
| Faltan definir los criterios de aceptación | La historia debe tener criterios de aceptación antes de ser aprobada. |
| La historia tiene alertas de similitud sin resolver | Debes resolver los conflictos de duplicidad pendientes. |
Scenario: Presentar totales precisos (Happy Path)
Given que una sesión de captura acaba de ser cerrada
When el sistema calcula el resumen final de la reunión
Then presenta una vista consolidada mostrando el total exacto de historias creadas, descartadas y pendientes de revisión
Scenario: Inconsistencia crítica durante cálculo (Unhappy Path - Sistema)
Given que una sesión está en proceso de cierre
When el backend detecta una discrepancia en el conteo de registros (inconsistencia de datos transaccional)
Then interrumpe el cierre de la sesión
And alerta al usuario sobre el problema solicitando actualizar la página antes de reintentar el cierre seguro | EP10 | -| US26 | Compartir historias con el cliente | Como analista, quiero generar un enlace público y seguro de solo lectura con las historias generadas, para enviarlo al cliente y que pueda validarlas o comentarlas sin necesidad de crearse una cuenta en la plataforma. | Feature: Aprobación externa del cliente
Scenario: Generar y visitar enlace público (Happy Path)
Given un proyecto con historias en revisión
When el analista genera un enlace público y el cliente accede a él
Then el cliente puede visualizar las historias en modo de solo lectura
And puede marcarlas como 'Aprobadas' o dejar comentarios
Scenario: Expiración o revocación del enlace (Unhappy Path)
Given un enlace público generado anteriormente
When el analista revoca el acceso o expira el tiempo de validez configurado
Then cualquier intento de ingresar mostrará un error de enlace no disponible | EP10 | -| US25 | Calificar calidad de historia (Feedback Loop) | Como analista revisando las historias generadas, quiero calificar la precisión de la IA (ej. Pulgar arriba/abajo) e indicar si hubo alucinaciones, para generar un registro de retroalimentación que mejore los prompts y el modelo en el futuro. | Feature: Retroalimentación de la IA (Feedback Loop)
Scenario: Calificar positivamente una historia (Happy Path)
Given una historia generada correctamente por la IA
When el analista la califica positivamente (ej. Pulgar arriba)
Then el sistema registra la métrica de éxito de forma silenciosa para el dataset de calidad
Scenario: Reportar alucinación o error de contexto (Unhappy Path - Mejora continua)
Given una historia que contiene datos inventados o malinterpretados por la IA
When el analista la califica negativamente (ej. Pulgar abajo)
Then el sistema despliega un menú opcional para categorizar el fallo (ej. 'Alucinación', 'Falta contexto')
And vincula el texto original generado con la versión final editada por el analista para afinar los modelos futuros | EP10 | -| **EP11** | **Integraciones Externas** | Conectividad con herramientas del ecosistema de desarrollo para transferir las historias aprobadas al backlog del equipo sin trabajo manual. | -- | -- | -| US27 | Conectar cuenta de Jira | Como miembro con permiso para configurar integraciones, quiero autorizar la conexión con Jira a través de un proceso seguro, para que la exportación de historias no requiera compartir credenciales con nadie del equipo. | Feature: Conectar cuenta de Jira
Scenario: Autorización segura y exitosa (Happy Path)
Given un usuario administrador en la sección de integraciones
When completa satisfactoriamente el flujo de autorización (OAuth) en la plataforma de Jira
Then el sistema de Reqs-AI vincula el proyecto a Jira
And muestra un indicador visual de conexión activa y saludable
Scenario Outline: Rechazo de autorización (Unhappy Paths)
Given que el usuario inicia el flujo de autorización
When ocurre el evento <Evento_Fallo>
Then el sistema aborta la integración
And muestra el estado <Estado_Final> sin guardar datos espurios
Examples:
| Evento_Fallo | Estado_Final |
|---|---|
| El usuario deniega los permisos desde la ventana de Jira | Operación cancelada por el usuario, integración inactiva. |
| Fallo de red o timeout durante la comunicación con Jira | Error de comunicación, inténtalo nuevamente. |
Scenario: Token de conexión expirado (Unhappy Path - Flujo Alternativo)
Given una integración previamente configurada que estaba operativa
When el token de seguridad subyacente caduca (vencimiento de credencial)
Then el sistema deshabilita las opciones de exportación
And notifica explícitamente al administrador que se requiere una 'Re-autenticación' para reactivar la conexión | EP11 | -| US28 | Configurar mapeo de proyecto en Jira | Como administrador, quiero vincular un proyecto local de Reqs-AI con un Board/Proyecto específico de Jira, para que el sistema sepa exactamente a qué destino enviar las historias durante la exportación. | Feature: Mapeo de proyectos externos
Scenario: Vincular board destino (Happy Path)
Given una integración con Jira activa
When el usuario accede a la configuración del proyecto
Then puede seleccionar de una lista desplegable el 'Proyecto de Jira' y 'Tipo de Issue' destino
And el sistema guarda este mapeo para las futuras exportaciones
Scenario: Intentar exportar sin mapeo previo (Unhappy Path)
Given un proyecto sin board de destino configurado
When el analista intenta exportar historias a Jira
Then la exportación se bloquea
And el sistema redirige al usuario a la pantalla de mapeo de configuración | EP11 | -| US29 | Exportar historias a Jira | Como miembro con permiso para exportar historias, quiero enviar las historias aprobadas directamente al backlog de Jira, para que el equipo de desarrollo pueda planificar el sprint sin copiar ni pegar nada manualmente. Depende de: US38 y US41. | Feature: Exportar historias a Jira
Scenario: Exportación exitosa de historias aprobadas (Happy Path)
Given un proyecto con una conexión activa a Jira y varias historias en estado 'Aprobada'
When el usuario ejecuta la acción de exportación masiva
Then el sistema transmite únicamente las historias aprobadas a Jira
And marca exitosamente dichas historias como 'Exportadas' dentro de Reqs-AI
Scenario Outline: Validaciones de prerrequisitos de exportación (Unhappy Paths)
Given que el usuario intenta ejecutar la exportación masiva
When se incumple la condición <Incumplimiento>
Then el botón o acción es bloqueado o rechazado indicando <Mensaje_Error>
Examples:
| Incumplimiento | Mensaje_Error |
|---|---|
| La integración con Jira no está configurada o el token expiró | Debes conectar y autorizar tu cuenta de Jira primero. |
| No existe ninguna historia que se encuentre en estado 'Aprobada' | No hay historias válidas listas para exportar. |
Scenario: Fallo parcial durante la transmisión de lotes (Unhappy Path - Fallo de red)
Given un lote de 10 historias aprobadas listas para envío a la API de Jira
When la red experimenta intermitencia y 2 de las peticiones fallan
Then el sistema marca las 8 historias exitosas como 'Exportadas'
And retiene las 2 restantes, marcándolas con error de exportación y habilitando un botón para reintentar el lote fallido | EP11 | -| **EP12** | **Arquitectura y Servicios RESTful API** | Endpoints y servicios backend sin interfaz gráfica directa (Technical Stories), necesarios para soportar el procesamiento de IA, integraciones y lógica de negocio del frontend. | -- | -- | -| TS55 | API: Registro de Usuario (POST /auth/register) | Como Developer, quiero un endpoint para registrar usuarios hasheando su contraseña, para asegurar sus accesos. | Scenario: Registro exitoso
Given payload con email y password
When POST a /auth/register
Then 201 Created | EP12 | -| TS56 | API: Login de Usuario (POST /auth/login) | Como Developer, quiero un endpoint que valide credenciales y retorne un JWT. | Scenario: Login válido
Given credenciales correctas
When POST a /auth/login
Then 200 OK con token JWT | EP12 | -| TS57 | API: Perfil de Usuario (GET /auth/me) | Como Developer, quiero un endpoint que retorne los datos del usuario logueado según su JWT. | Scenario: Token válido
Given header Authorization: Bearer <token>
When GET a /auth/me
Then 200 OK | EP12 | -| TS58 | API: Crear Proyecto (POST /projects) | Como Developer, quiero un endpoint para crear un nuevo espacio de trabajo. | Scenario: Creación de proyecto
Given payload con nombre
When POST a /projects
Then 201 Created | EP12 | -| TS59 | API: Listar Proyectos (GET /projects) | Como Developer, quiero un endpoint para listar los proyectos del usuario autenticado. | Scenario: Listar proyectos
Given usuario con token válido
When GET a /projects
Then 200 OK con array de proyectos | EP12 | -| TS60 | API: Actualizar Proyecto (PUT /projects/{id}) | Como Developer, quiero un endpoint para modificar metadatos de un proyecto. | Scenario: Actualización válida
Given ID de proyecto existente
When PUT a /projects/{id}
Then 200 OK | EP12 | -| TS61 | API: Eliminar Proyecto (DELETE /projects/{id}) | Como Developer, quiero un endpoint de soft-delete para archivar proyectos. | Scenario: Eliminación lógica
Given ID válido
When DELETE a /projects/{id}
Then 204 No Content | EP12 | -| TS62 | API: Subir Audio (POST /sessions/upload) | Como Developer, quiero un endpoint que reciba un multipart/form-data y lo suba a Cloud Storage. | Scenario: Subida exitosa
Given archivo MP3
When POST a /sessions/upload
Then 200 OK con URL del storage | EP12 | -| TS63 | API: Transcribir Audio (POST /sessions/transcribe) | Como Developer, quiero un endpoint que envíe la URL del audio a Whisper/AWS y retorne texto. | Scenario: Transcripción exitosa
Given URL de audio válida
When POST a /sessions/transcribe
Then 200 OK con transcripción | EP12 | -| TS64 | API: Extraer Historias (POST /sessions/extract) | Como Developer, quiero un endpoint que procese la transcripción con el LLM y retorne el JSON de historias. | Scenario: Extracción LLM
Given texto transcrito
When POST a /sessions/extract
Then 200 OK con array JSON | EP12 | -| TS65 | API: Auth Jira (GET /integrations/jira/auth) | Como Developer, quiero un endpoint para iniciar el flujo OAuth2 con Atlassian. | Scenario: Redirección OAuth
Given petición de integración
When GET a /integrations/jira/auth
Then 302 Redirect a Jira | EP12 | -| TS66 | API: Exportar a Jira (POST /integrations/jira/export) | Como Developer, quiero un endpoint que mapee y envíe las historias al Webhook de Jira. | Scenario: Exportación a Webhook
Given array de IDs de historias
When POST a /integrations/jira/export
Then 200 OK confirmando creación | EP12 | +| ID | Título de la Historia | Descripción (Como... quiero... para...) | Criterios de Aceptación (BDD) | Épica Asociada | +|:---------|:-------------------------------------------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:---------------| +| **EP00** | **Landing Page y Captación de Leads** | Landing page pública orientada a convertir visitantes en usuarios mediante la exposición de la propuesta de valor y beneficios por segmentos B2B. | -- | -- | +| US01 | Visualizar Propuesta de Valor (Hero) | Como visitante, quiero entender inmediatamente qué es Reqs-AI y su propuesta de valor principal en la cabecera (Hero), para decidir en los primeros segundos si me interesa continuar explorando la herramienta. | Feature: Landing Page - Hero Section
Scenario: Carga inicial y visibilidad de conversión (Happy Path)
Given un visitante que accede a la URL principal de Reqs-AI
When la página carga completamente
Then visualiza un título claro sobre la automatización de requisitos con IA
And un llamado a la acción (CTA) principal visible sin hacer scroll para iniciar el registro
Scenario: Acceso desde dispositivo móvil (Edge Case - Responsive)
Given un visitante que accede desde un dispositivo móvil (viewport inferior a 768px)
When la página carga completamente
Then el Hero adapta su diseño al ancho de pantalla sin perder legibilidad
And el CTA principal sigue visible y pulsable sin necesidad de hacer scroll
Scenario: Visitante ya autenticado (Edge Case)
Given un usuario que ya tiene sesión activa en la plataforma
When accede a la URL de la landing page
Then el sistema lo redirige directamente al panel principal de su organización
And no muestra la landing para evitar confusión innecesaria | EP00 | +| US02 | Explorar Casos de Uso por Segmento | Como visitante, quiero alternar entre diferentes perfiles (ej. Consultoras vs Startups) en una sección interactiva, para ver beneficios y ejemplos específicos que se adapten a la realidad de mi equipo. | Feature: Landing Page - Segmentación Interactiva
Scenario Outline: Alternar entre perfiles de usuario
Given un visitante en la sección de 'Construido para tu equipo'
When hace clic en la pestaña del perfil <Perfil>
Then el contenido dinámico se actualiza sin recargar la página
And muestra el beneficio principal <Beneficio> asociado a ese perfil
Examples:
| Perfil | Beneficio |
|---|---|
| Consultoras de Software | Reducción de horas facturables en análisis y toma de requerimientos. |
| Product Managers / Startups | Integración directa con Jira y adopción de metodologías ágiles. |
Scenario: Comparativa de planes con toggle (Happy Path)
Given un visitante en la sección de Precios
When alterna el interruptor entre facturación 'Mensual' y 'Anual'
Then los precios de los planes de pago se actualizan dinámicamente mostrando el descuento aplicado
And cada tarjeta de plan contiene un CTA que redirige al formulario de registro correspondiente
Scenario: CTA de plan gratuito no solicita datos de pago (Edge Case)
Given un visitante interesado en el Plan Gratuito
When hace clic en el CTA correspondiente
Then es redirigido al formulario de registro sin que se le solicite ningún dato de tarjeta ni método de pago
Scenario: Visualización sin interacción con el toggle (Edge Case)
Given un visitante que no interactúa con el toggle de facturación
When llega a la sección de precios
Then los planes se muestran en modo mensual por defecto
And cada tarjeta expone precio, límites principales y características clave de forma legible | EP00 | +| **EP01** | **Autenticación y Seguridad** | Gestión de acceso y protección de identidad para los usuarios de Reqs-AI, garantizando que solo personal autorizado acceda a la plataforma y su historial. | -- | -- | +| US04 | Registro de cuenta | Como visitante que llega por primera vez a la plataforma, quiero crear una cuenta con mi correo y una contraseña, para poder acceder a mis proyectos y sesiones de captura de requisitos. | Feature: Registro de cuenta
Scenario: Registro exitoso (Happy Path)
Given un visitante en la página de registro
When ingresa un correo válido y una contraseña segura
Then el sistema crea la cuenta en estado 'pendiente de verificación'
And envía un correo con el enlace de activación
Scenario Outline: Validaciones de registro (Unhappy Paths)
Given un visitante en la página de registro
When ingresa datos con el problema <Problema>
Then el sistema rechaza el registro indicando <Mensaje>
Examples:
| Problema | Mensaje |
|---|---|
| El correo ya está registrado en otra cuenta | El correo ingresado ya se encuentra en uso. |
| La contraseña tiene menos de 8 caracteres | La contraseña debe tener al menos 8 caracteres. |
| El formato del correo es inválido | Ingresa un correo electrónico válido. |
Scenario: Verificación exitosa (Happy Path)
Given un usuario con cuenta pendiente de activación
When hace clic en el enlace de verificación recibido por correo
Then el sistema activa la cuenta
And redirige al usuario al inicio de sesión
Scenario: Enlace expirado o inválido (Unhappy Path)
Given un usuario con un enlace de verificación
When el enlace fue usado previamente o ya expiró su vigencia
Then el sistema muestra un error de enlace inválido
And ofrece la opción de reenviar un nuevo correo de verificación
Scenario: Reenvío de enlace de verificación (Flujo Alternativo)
Given un usuario cuyo enlace de verificación ha expirado
When solicita el reenvío del enlace desde la notificación de error
Then el sistema invalida el enlace anterior
And envía un nuevo enlace válido con un tiempo de expiración renovado | EP01 | +| US06 | Inicio de sesión | Como usuario con cuenta activa, quiero iniciar sesión con mi correo y contraseña, para acceder a mis proyectos y al historial de sesiones de mi organización. | Feature: Inicio de sesión
Scenario: Autenticación exitosa (Happy Path)
Given un usuario con cuenta activa
When ingresa sus credenciales correctas
Then el sistema le concede acceso
And lo redirige al panel principal de su última organización activa
Scenario Outline: Fallos de autenticación (Unhappy Paths)
Given un usuario intentando iniciar sesión
When ocurre la situación <Situacion>
Then el sistema deniega el acceso con el mensaje <Error>
Examples:
| Situacion | Error |
|---|---|
| Contraseña incorrecta | Credenciales inválidas. |
| La cuenta aún no ha sido verificada | Debes verificar tu correo antes de iniciar sesión. |
| Demasiados intentos fallidos consecutivos | Cuenta bloqueada temporalmente por seguridad. |
Scenario: Solicitar recuperación (Happy Path)
Given un usuario que olvidó su contraseña
When ingresa su correo en el formulario de recuperación
Then el sistema envía un enlace de restablecimiento
And muestra un mensaje genérico de confirmación por seguridad
Scenario: Prevenir enumeración de usuarios (Edge Case - Seguridad)
Given un visitante malintencionado
When ingresa un correo que no existe en el sistema
Then el sistema no revela que el correo es inexistente
And muestra el mismo mensaje genérico de confirmación
Scenario: Enlace de restablecimiento expirado al usarlo (Unhappy Path)
Given un usuario que recibió el enlace de restablecimiento en su correo
When intenta acceder a él después de su período de validez (ej. pasadas 24 horas)
Then el sistema rechaza el token indicando que expiró
And ofrece la opción de solicitar un nuevo enlace de restablecimiento | EP01 | +| US08 | Cerrar sesión | Como usuario autenticado, quiero cerrar mi sesión de forma explícita, para asegurarme de que nadie más pueda acceder a mi cuenta desde el mismo dispositivo. | Feature: Cerrar sesión
Scenario: Logout exitoso (Happy Path)
Given un usuario autenticado
When selecciona la opción 'Cerrar sesión'
Then el sistema invalida el token de sesión
And redirige al usuario a la pantalla de inicio de sesión
Scenario: Cierre de sesión con captura activa (Edge Case)
Given un usuario con una sesión de captura en curso
When intenta cerrar sesión
Then el sistema muestra una advertencia de que hay una sesión activa
And requiere confirmar antes de proceder | EP01 | +| US09 | Aceptar términos y política de privacidad | Como nuevo usuario completando el registro, quiero leer y aceptar los términos de uso y la política de privacidad antes de activar mi cuenta, para entender cómo se usan mis datos y las grabaciones de audio antes de comenzar a usar el servicio. | Feature: Consentimiento de privacidad
Scenario: Aceptar términos durante el registro (Happy Path)
Given un visitante completando el formulario de registro
When marca la casilla de aceptación y envía el formulario
Then el sistema registra la fecha y versión del consentimiento otorgado
And procede con la creación de la cuenta
Scenario: Intentar registrarse sin aceptar términos (Unhappy Path)
Given un visitante en el formulario de registro
When intenta crear la cuenta sin marcar la casilla de aceptación
Then el sistema bloquea el envío
And resalta la casilla indicando que es obligatoria | EP01 | +| US10 | Editar perfil de usuario | Como usuario autenticado, quiero actualizar mi nombre y foto de perfil, para que mis compañeros de equipo me identifiquen correctamente en los registros de actividad de las sesiones. | Feature: Editar perfil
Scenario: Actualizar nombre y foto (Happy Path)
Given un usuario autenticado en su perfil
When modifica su nombre y sube una imagen válida
Then el sistema actualiza los datos
And refleja los cambios en todos los proyectos donde el usuario aparece
Scenario: Formato de imagen no soportado (Unhappy Path)
Given un usuario editando su perfil
When sube un archivo que no es imagen (ej. PDF)
Then el sistema rechaza el archivo
And muestra un mensaje indicando los formatos aceptados
Scenario: Imagen supera el tamaño máximo permitido (Unhappy Path)
Given un usuario editando su perfil
When intenta subir una imagen que excede el límite de tamaño (ej. mayor de 5 MB)
Then el sistema rechaza el archivo antes de procesarlo
And muestra el tamaño máximo permitido y los formatos válidos | EP01 | +| **EP02** | **Organizaciones** | Gestión de espacios de trabajo independientes para separar la información de diferentes empresas o equipos, garantizando que cada organización acceda únicamente a sus propios datos. | -- | -- | +| US11 | Crear organización | Como usuario autenticado que aún no pertenece a ninguna organización, quiero crear un espacio de trabajo con el nombre de mi empresa, para centralizar mis proyectos y gestionar mi equipo en un entorno separado. | Feature: Crear organización
Scenario: Creación exitosa (Happy Path)
Given un usuario autenticado sin organización
When crea una organización con un nombre válido
Then el sistema genera el espacio de trabajo
And asigna al usuario el rol inamovible de 'Propietario'
Scenario: Nombre de organización vacío (Unhappy Path)
Given un usuario creando una organización
When deja el nombre en blanco
Then el sistema bloquea la creación exigiendo un nombre obligatorio | EP02 | +| US12 | Editar organización | Como Propietario de la organización, quiero actualizar el nombre o los datos generales de mi organización, para mantener la información correcta cuando el equipo o el negocio cambia. | Feature: Editar organización
Scenario: Actualizar datos (Happy Path)
Given el Propietario de una organización
When modifica el nombre y guarda los cambios
Then la organización actualiza sus datos en toda la plataforma
Scenario: Intento de edición sin permisos (Unhappy Path)
Given un miembro regular de la organización
When intenta acceder a la configuración de la organización
Then el sistema oculta o bloquea la opción por falta de privilegios | EP02 | +| US13 | Cambiar de organización | Como usuario que pertenece a más de una organización, quiero seleccionar con cuál quiero trabajar desde el menú principal, para asegurarme de estar operando en el contexto correcto según el cliente que estoy atendiendo. | Feature: Cambiar de organización
Scenario: Cambio exitoso de contexto (Happy Path)
Given un usuario que pertenece a múltiples organizaciones
When selecciona una organización distinta desde el menú
Then el sistema recarga el contexto de trabajo
And muestra únicamente los proyectos de la organización seleccionada
Scenario: Eliminación concurrente (Edge Case)
Given un usuario intentando cambiar a la Organización B
When el propietario de la Organización B lo elimina en ese mismo instante
Then el sistema deniega el acceso y lo devuelve a su organización actual | EP02 | +| US14 | Política de retención de audios | Como Propietario de la organización, quiero configurar la eliminación automática de los archivos de audio originales X días después de procesarse, para cumplir con las políticas de privacidad y confidencialidad corporativas. | Feature: Política de retención de audios
Scenario: Eliminación automática al cumplir plazo (Happy Path)
Given una organización con la retención configurada en 7 días
When se cumple el plazo desde que un audio fue procesado
Then el sistema elimina permanentemente el archivo de audio físico
And conserva únicamente las historias generadas en texto
Scenario: Intentar acceder a un audio eliminado (Unhappy Path)
Given un audio que ya superó su periodo de retención y fue purgado
When un usuario intenta reproducirlo o descargarlo desde el historial
Then el sistema muestra un aviso de que el archivo fue eliminado por políticas de privacidad corporativa | EP02 | +| **EP03** | **Suscripción y Facturación** | Gestión de planes y límites de uso del sistema basados en un modelo de suscripción SaaS. Épica de baja prioridad — no entra en los primeros sprints. | -- | -- | +| US15 | Plan gratuito automático | Como usuario que acaba de crear su organización, quiero empezar a usar la plataforma sin ingresar datos de pago, para evaluar si se ajusta a mis necesidades antes de decidir suscribirme. | Feature: Plan gratuito automático
Scenario: Asignación por defecto (Happy Path)
Given un usuario que acaba de crear una nueva organización
When ingresa a su panel por primera vez
Then el sistema le asigna el 'Plan Gratuito'
And habilita las cuotas iniciales sin solicitar método de pago
Scenario: Cuota de sesiones del plan gratuito agotada (Edge Case)
Given una organización en Plan Gratuito que ya consumió su límite mensual de sesiones
When un analista intenta iniciar una nueva sesión de captura
Then el sistema bloquea la acción
And muestra un aviso invitando a actualizar al Plan Pro para continuar
Scenario: Intento de crear segunda organización en plan gratuito (Edge Case)
Given un usuario en Plan Gratuito con una organización activa
When intenta crear una segunda organización
Then el sistema bloquea la creación
And informa que el Plan Gratuito está limitado a un único espacio de trabajo | EP03 | +| US16 | Suscripción al plan Pro | Como Propietario de una organización en plan gratuito, quiero contratar el plan Pro, para acceder a sesiones ilimitadas, captura en tiempo real e integración con Jira. | Feature: Suscripción al plan Pro
Scenario: Upgrade de plan exitoso (Happy Path)
Given el Propietario de una organización en plan gratuito
When ingresa un método de pago válido y contrata el Plan Pro
Then los límites de la organización se expanden inmediatamente
And se emite la factura correspondiente
Scenario: Tarjeta rechazada (Unhappy Path)
Given un Propietario intentando hacer upgrade
When la pasarela de pagos rechaza la tarjeta por fondos insuficientes
Then el sistema mantiene el plan gratuito
And notifica el error de pago al usuario | EP03 | +| US17 | Suscripción al plan Equipo | Como Propietario de una organización en plan Pro, quiero contratar el plan Equipo, para poder agregar a todos los miembros de mi equipo y definir mediante roles personalizados qué puede hacer cada uno. | Feature: Suscripción al plan Equipo
Scenario: Upgrade a Equipo exitoso (Happy Path)
Given el Propietario de una organización en Plan Pro
When ingresa un método de pago válido y contrata el Plan Equipo
Then el plan se actualiza de inmediato
And se habilitan la gestión avanzada de roles y los asientos ilimitados de miembros
And se emite la factura correspondiente al nuevo plan
Scenario: Intento de upgrade sin plan Pro previo (Unhappy Path)
Given el Propietario de una organización en Plan Gratuito
When intenta contratar el Plan Equipo directamente
Then el sistema bloquea la operación
And lo redirige al flujo de upgrade al Plan Pro como paso previo requerido
Scenario: Pago rechazado durante upgrade (Unhappy Path)
Given el Propietario intentando contratar el Plan Equipo
When la pasarela de pagos rechaza el método de pago
Then el sistema mantiene el Plan Pro activo sin cambios
And notifica el error de pago solicitando actualizar el método de facturación | EP03 | +| US18 | Cancelación de suscripción | Como Propietario de una suscripción activa, quiero cancelar mi plan antes de que inicie el siguiente período de facturación, para no recibir cargos adicionales después de dejar de usar el servicio. | Feature: Cancelación de suscripción
Scenario: Cancelar antes de renovación (Happy Path)
Given el Propietario de una suscripción paga activa
When cancela la suscripción desde el panel
Then el sistema desactiva la auto-renovación
And mantiene los beneficios premium hasta el final del ciclo de facturación actual
Scenario: Reactivar suscripción antes del vencimiento (Flujo Alternativo)
Given una suscripción en estado CANCELING con días de acceso premium restantes
When el Propietario decide mantener el servicio
Then el sistema restaura la auto-renovación
And la suscripción vuelve al estado ACTIVE sin interrupciones ni cobros adicionales
Scenario: Intentar cancelar un plan gratuito (Edge Case)
Given el Propietario de una organización en Plan Gratuito
When accede al panel de cancelación
Then el sistema informa que el Plan Gratuito no genera cargos
And oculta la opción de cancelación para ese plan | EP03 | +| US19 | Ver estado del plan y consumo | Como Propietario de la organización, quiero ver el plan activo, la fecha de renovación y cuántas sesiones o proyectos he usado, para saber cuándo necesito actualizar mi plan antes de quedarme sin cupo. | Feature: Ver estado del plan y consumo
Scenario: Visualización de cuotas (Happy Path)
Given el Propietario de la organización
When ingresa a la sección de facturación
Then visualiza una barra de progreso con el consumo actual de sesiones frente al límite de su plan
Scenario: Límite alcanzado (Edge Case)
Given una organización que alcanzó exactamente el 100% de su límite
When el usuario visualiza el estado
Then el sistema muestra una alerta destacada invitando al upgrade
Scenario: Servicio de facturación no disponible (Unhappy Path - Sistema)
Given el Propietario accediendo a la sección de facturación
When el servicio de datos de suscripción falla temporalmente
Then el sistema muestra un mensaje de error con opción de reintento
And no expone datos parciales o incorrectos del plan al usuario | EP03 | +| **EP04** | **Gestión de Proyectos** | Creación, configuración y ciclo de vida de los proyectos por cliente, incluyendo la carga de conocimiento previo que permite a la IA generar historias más precisas. | -- | -- | +| US20 | Crear proyecto | Como analista, quiero registrar un proyecto asociado a un cliente específico, para organizar y separar todas las sesiones de levantamiento de requisitos de ese cliente. | Feature: Crear proyecto
Scenario: Creación de proyecto válida (Happy Path)
Given un analista con permisos para crear proyectos en la organización
When registra un nuevo proyecto indicando el nombre del cliente
Then el proyecto aparece en el listado activo de la organización
Scenario: Proyecto duplicado (Unhappy Path)
Given un usuario creando un proyecto
When ingresa un nombre que ya existe activo en la misma organización
Then el sistema sugiere usar un nombre distinto para evitar confusiones | EP04 | +| US21 | Cargar documentos del cliente | Como analista, quiero subir documentos del cliente (PDF, Word) al proyecto, para que el sistema extraiga y clasifique automáticamente su contenido en glosario, restricciones y contexto general, enriqueciendo así las historias que se generen en sesiones futuras. | Feature: Cargar documentos del cliente
Scenario: Carga y clasificación exitosa (Happy Path)
Given un usuario configurando un proyecto
When sube un documento PDF o Word válido
Then el sistema extrae el texto del documento
And clasifica el contenido en glosario, restricciones y contexto general
And lo incorpora a la base de conocimiento del proyecto para futuras sesiones
Scenario Outline: Restricciones de carga documental (Unhappy Paths)
Given un usuario intentando subir documentos de contexto
When ocurre el escenario <Fallo>
Then el sistema rechaza el archivo indicando <Error>
Examples:
| Fallo | Error |
|---|---|
| El archivo es un ejecutable (.exe) | Solo se permiten documentos de texto o PDF. |
| El archivo excede los 50MB | El documento es demasiado pesado. |
Scenario: Guardar perfil técnico (Happy Path)
Given un analista configurando el proyecto
When define que el stack es 'React + Node' y guarda
Then el sistema utiliza esta instrucción como prompt base para la generación de criterios técnicos en las historias de usuario
Scenario: Campo de stack vacío al guardar (Unhappy Path)
Given un analista en el formulario del perfil técnico
When intenta guardar sin haber definido ningún stack tecnológico
Then el sistema bloquea el guardado
And señala que el campo es obligatorio para la generación contextualizada de criterios
Scenario: Actualizar stack con historias ya generadas (Edge Case)
Given un proyecto que ya tiene historias generadas con un stack previo
When el analista actualiza el stack tecnológico
Then el sistema guarda la nueva configuración para futuras sesiones
And advierte que las historias existentes reflejan el stack anterior y no se actualizarán automáticamente | EP04 | +| US23 | Agregar término al glosario manualmente | Como analista, quiero agregar términos del negocio del cliente directamente al glosario del proyecto sin necesidad de subir un documento, para enriquecer el vocabulario de la IA cuando el cliente solo transmite su conocimiento de forma oral. | Feature: Glosario manual del proyecto
Scenario: Agregar término exitosamente (Happy Path)
Given un miembro configurando el glosario de un proyecto
When ingresa un término y su definición y los guarda
Then el término queda disponible para ser utilizado como contexto en futuras sesiones de captura
Scenario: Intentar guardar término sin definición (Unhappy Path)
Given un miembro en el formulario del glosario
When ingresa solo el término sin su definición
Then el sistema bloquea el guardado
And exige completar la definición antes de continuar
Scenario: Término duplicado en el glosario (Unhappy Path)
Given un miembro agregando términos al glosario del proyecto
When ingresa un término idéntico (ignorando mayúsculas) a uno ya registrado
Then el sistema detecta la duplicidad
And ofrece la opción de editar la definición del término existente en lugar de crear uno nuevo | EP04 | +| US24 | Registrar restricción técnica manualmente | Como analista, quiero registrar restricciones técnicas del cliente (ej. 'sin uso de cookies de terceros', 'máximo 3 segundos de latencia') directamente en el proyecto, para que la IA las considere al generar los criterios de aceptación sin necesidad de incluirlas en cada sesión. | Feature: Restricciones técnicas del proyecto
Scenario: Registrar restricción exitosamente (Happy Path)
Given un miembro configurando las restricciones del proyecto
When ingresa una restricción técnica y la guarda
Then la restricción queda registrada
And se incorpora al contexto de generación de historias en futuras sesiones
Scenario: Restricción duplicada (Unhappy Path)
Given un miembro agregando restricciones
When ingresa una restricción idéntica a una ya existente en el proyecto
Then el sistema alerta sobre la duplicidad
And ofrece la opción de editar la existente en lugar de crear una nueva | EP04 | +| US25 | Editar proyecto | Como analista, quiero modificar el nombre o la descripción de un proyecto existente, para corregir o actualizar la información cuando cambian los acuerdos con el cliente. | Feature: Editar proyecto
Scenario: Modificar datos del proyecto (Happy Path)
Given un analista con permisos de administración del proyecto
When cambia el nombre o la descripción del proyecto
Then los cambios se reflejan inmediatamente en el panel del equipo
Scenario: Nombre vacío al guardar (Unhappy Path)
Given un analista editando el nombre del proyecto
When borra el nombre por completo e intenta guardar
Then el sistema bloquea el guardado
And exige que el nombre del proyecto sea obligatorio
Scenario: Nombre duplicado en la organización (Unhappy Path)
Given un analista renombrando un proyecto
When ingresa un nombre igual al de otro proyecto activo en la misma organización
Then el sistema alerta sobre la colisión de nombres
And sugiere usar un sufijo o nombre alternativo para diferenciarlos | EP04 | +| US26 | Archivar proyecto | Como analista, quiero archivar un proyecto cuando termina el trabajo con ese cliente, para mantener el panel principal ordenado sin eliminar el historial de sesiones e historias generadas. | Feature: Archivar proyecto
Scenario: Archivar proyecto finalizado (Happy Path)
Given un proyecto activo
When el administrador lo archiva
Then el proyecto se oculta de las vistas principales pero mantiene su historial intacto
Scenario: Operaciones en proyecto archivado (Edge Case)
Given un proyecto en estado archivado
When un usuario intenta iniciar una nueva sesión de captura
Then el sistema bloquea la acción hasta que el proyecto sea desarchivado | EP04 | +| US27 | Proyecto de demostración automático | Como nuevo usuario que acaba de registrarse, quiero encontrar un proyecto de demostración pre-cargado con audios e historias ya generadas, para entender inmediatamente el valor de la plataforma sin tener que grabar mi propia reunión primero. | Feature: Proyecto Sandbox de Demo
Scenario: Cargar datos de demostración en nueva cuenta (Happy Path)
Given un usuario que acaba de registrarse exitosamente en la plataforma
When accede a su organización por primera vez
Then el sistema genera e inserta un proyecto de demostración pre-poblado (con audios, historias y transcripciones de ejemplo)
And lo marca visualmente como 'Sandbox / Demo' para que el usuario experimente de inmediato
Scenario: Restaurar proyecto de demostración (Flujo Alternativo)
Given un usuario que eliminó su proyecto de demostración
When hace clic en 'Restaurar datos de prueba' desde la configuración
Then el sistema vuelve a clonar el proyecto de ejemplo en su espacio de trabajo | EP04 | +| **EP05** | **Colaboración y Roles** | Gestión de roles personalizados con permisos configurables y administración de los miembros del equipo dentro de la organización y sus proyectos. El Propietario es el único rol fijo del sistema — es quien creó la organización, tiene todos los permisos y es el responsable del contrato. Todos los demás roles son creados y configurados por el Propietario. | -- | -- | +| US28 | Invitar miembro a la organización | Como Administrador de la organización, quiero invitar a un colega mediante su correo electrónico, para que pueda acceder a los proyectos que le correspondan dentro de la organización. | Feature: Invitar miembro
Scenario: Enviar invitación (Happy Path)
Given un usuario con permisos de gestión de equipo
When envía una invitación a un correo válido
Then el invitado recibe el correo con el enlace de acceso
And aparece en estado 'Pendiente' en el panel
Scenario Outline: Fallos de invitación (Unhappy Paths)
Given un administrador invitando a un usuario
When comete el error <Error_Inv>
Then la invitación falla indicando <Aviso>
Examples:
| Error_Inv | Aviso |
|---|---|
| El correo ya pertenece a la organización | El usuario ya es miembro del equipo. |
| El correo ya tiene una invitación pendiente | Ya existe una invitación enviada a este correo. |
Scenario: Rol creado exitosamente (Happy Path)
Given el Propietario de la organización
When crea el rol 'QA Lead' con un nombre único
Then el nuevo rol queda disponible para ser asignado a cualquier miembro
Scenario: Nombre de rol duplicado (Unhappy Path)
Given el Propietario creando un nuevo rol
When ingresa un nombre que ya existe entre los roles de la organización
Then el sistema bloquea la creación
And muestra que el nombre ya está en uso
Scenario: Nombre de rol vacío (Unhappy Path)
Given el Propietario en el formulario de creación de rol
When deja el campo de nombre vacío e intenta guardar
Then el sistema bloquea la acción
And señala que el nombre del rol es obligatorio | EP05 | +| US30 | Asignar permisos a un rol | Como Propietario de la organización, quiero seleccionar qué acciones puede realizar cada rol dentro de los proyectos y la organización, para que el nivel de acceso de cada miembro refleje exactamente sus responsabilidades reales. | Feature: Asignar permisos a un rol
Scenario: Configurar permisos (Happy Path)
Given el Propietario configurando un rol
When activa los permisos de 'Crear Sesiones' y 'Aprobar Historias'
Then todos los usuarios con ese rol adquieren dichas capacidades inmediatamente
Scenario: Revocar todos los permisos de un rol (Edge Case)
Given el Propietario editando los permisos de un rol existente
When intenta desactivar absolutamente todos los permisos disponibles
Then el sistema bloquea la acción
And advierte que un rol debe conservar al menos un permiso para ser funcional
Scenario: Cambio de permisos con miembros en sesión activa (Edge Case)
Given el Propietario revocando el permiso 'Crear Sesiones' de un rol que tienen analistas con sesiones abiertas
When confirma el cambio
Then el sistema aplica la restricción de inmediato
And notifica en tiempo real a los afectados que ya no pueden iniciar nuevas sesiones | EP05 | +| US31 | Asignar rol a un miembro | Como Administrador de la organización, quiero asignar uno de los roles disponibles a un miembro de la organización, para que sus permisos queden definidos en el momento en que acepta la invitación. | Feature: Asignar rol a un miembro
Scenario: Cambio de rol exitoso (Happy Path)
Given un Administrador de la organización
When cambia el rol del Usuario A de 'Lector' a 'Editor'
Then el Usuario A obtiene acceso a las herramientas de edición en su próxima navegación
Scenario: Intentar cambiar el rol del Propietario (Edge Case - Seguridad)
Given un Administrador de la organización
When intenta asignar un rol diferente al usuario Propietario de la cuenta
Then el sistema bloquea la acción
And recuerda que el rol de Propietario es fijo e intransferible
Scenario: Reasignar a rol con permisos reducidos (Unhappy Path - Confirmación)
Given un Administrador que va a reducir los permisos de un miembro activo
When cambia su rol a uno con menos privilegios
Then el sistema solicita confirmación antes de aplicar el cambio
And notifica al miembro afectado que sus permisos han sido actualizados | EP05 | +| US32 | Editar permisos de un rol existente | Como Propietario de la organización, quiero modificar los permisos de un rol ya creado, para ajustar el nivel de acceso de todos los miembros que lo tienen asignado cuando cambian sus responsabilidades. | Feature: Editar permisos de un rol existente
Scenario: Propagación de permisos (Happy Path)
Given un rol asignado a 5 usuarios
When el Propietario revoca el permiso de 'Exportar'
Then los 5 usuarios pierden la capacidad de exportar instantáneamente sin necesidad de re-login
Scenario: Editar rol sin miembros asignados (Edge Case)
Given un rol personalizado sin ningún miembro asignado actualmente
When el Propietario agrega permisos de 'Crear Sesiones' al rol
Then el sistema guarda los nuevos permisos sin ningún efecto inmediato
And los permisos se aplicarán cuando el rol sea asignado a un miembro
Scenario: Intentar dejar rol sin permisos (Unhappy Path)
Given el Propietario editando permisos de un rol
When revoca el último permiso activo del rol
Then el sistema bloquea la acción
And exige conservar al menos un permiso por integridad del rol | EP05 | +| US33 | Eliminar un rol | Como Propietario de la organización, quiero eliminar un rol que ya no corresponde a ninguna función activa del equipo, para mantener la lista de roles ordenada y evitar asignaciones incorrectas. | Feature: Eliminar un rol
Scenario: Eliminar rol sin uso (Happy Path)
Given un rol personalizado que no tiene usuarios asignados
When el Propietario lo elimina
Then el rol desaparece definitivamente de la organización
Scenario: Intento de eliminar rol en uso (Unhappy Path)
Given un rol que está asignado a al menos un miembro
When el Propietario intenta eliminarlo
Then el sistema bloquea la eliminación
And exige reasignar a esos miembros a otro rol antes de proceder | EP05 | +| US34 | Remover miembro de la organización | Como Administrador de la organización, quiero remover a un miembro de la organización, para revocar su acceso a todos los proyectos de forma inmediata cuando ya no forma parte del equipo. | Feature: Remover miembro de la organización
Scenario: Remoción exitosa (Happy Path)
Given un administrador de equipo
When remueve al Usuario B de la organización
Then el Usuario B pierde acceso inmediatamente a todos los proyectos de esa organización
Scenario: Intento de remover al Propietario (Edge Case - Seguridad)
Given un administrador de equipo
When intenta remover al Propietario original de la cuenta
Then el sistema bloquea la acción indicando que el rol de Propietario es intransferible e irremovible | EP05 | +| US35 | Transferir propiedad de la organización | Como Propietario de la organización, quiero transferir la propiedad a otro miembro activo, para poder desvincularme del equipo sin dejar la cuenta sin responsable cuando abandono el proyecto. | Feature: Transferencia de propiedad
Scenario: Transferir propiedad exitosamente (Happy Path)
Given el Propietario actual de la organización
When selecciona a un miembro activo y confirma la transferencia
Then el miembro seleccionado asume el rol de Propietario
And el Propietario anterior pasa a tener un rol regular configurable
Scenario: Intentar transferir a un miembro pendiente de invitación (Unhappy Path)
Given el Propietario intentando transferir la propiedad
When selecciona un usuario que aún no aceptó su invitación
Then el sistema bloquea la transferencia
And exige que el destinatario sea un miembro activo de la organización | EP05 | +| **EP06** | **Captura en Tiempo Real** | Funcionalidad principal del producto que procesa audio en vivo para generar historias de usuario de forma automática mientras la reunión con el cliente ocurre. Las sesiones requieren un proyecto existente. | -- | -- | +| US36 | Iniciar sesión de captura en vivo | Como analista, quiero activar la captura de audio durante la reunión dentro de un proyecto existente, para que el sistema identifique quién habla en cada momento y genere las historias a partir de lo que dice el cliente sin que yo tenga que tomar notas. Depende de: US20. | Feature: Captura en vivo
Scenario: Iniciar captura exitosamente (Happy Path)
Given que el analista tiene permisos y el proyecto está activo
When inicia la captura de audio en vivo
Then la sesión cambia a estado 'activa' y comienza a registrar el habla
Scenario Outline: Validaciones al intentar iniciar captura (Unhappy Paths)
Given que el analista intenta iniciar una sesión de captura en vivo
When ocurre la situación <Condicion>
Then el sistema impide el inicio de la sesión
And muestra el mensaje <Mensaje_Error>
Examples:
| Condicion | Mensaje_Error |
|---|---|
| El navegador no tiene permisos de micrófono | Debes otorgar permisos de micrófono para continuar. |
| El usuario tiene un rol sin permisos de creación | No tienes permisos para crear sesiones en este proyecto. |
| El proyecto seleccionado se encuentra archivado | El proyecto está archivado y no admite nuevas sesiones. |
Scenario: Pérdida de conexión al iniciar (Unhappy Path - Flujo Alternativo)
Given que el analista inicia la captura
When se pierde la conexión a internet antes de confirmar con el servidor
Then el sistema cancela la creación de la sesión
And notifica al analista que verifique su conexión | EP06 | +| US37 | Generación automática de historias | Como analista en sesión activa, quiero que el sistema convierta automáticamente lo que dice el cliente en historias de usuario con criterios de aceptación, para obtener un backlog estructurado al finalizar la reunión sin necesidad de documentar después. | Feature: Generación automática de historias
Scenario: Extraer historia desde un requisito claro (Happy Path)
Given una sesión activa
When el sistema detecta un requisito válido en la intervención del cliente
Then genera una historia de usuario con criterios de aceptación
And la agrega al backlog de la sesión en tiempo real
Scenario: Manejo de audio incomprensible o ruido (Unhappy Path)
Given una sesión activa
When el cliente habla de temas irrelevantes o hay ruido de fondo
Then el sistema ignora la intervención
And no genera historias vacías ni interrumpe la captura
Scenario: Intervención larga con múltiples requisitos (Edge Case)
Given una sesión activa
When el cliente menciona varios requerimientos distintos en una sola intervención continua
Then el sistema separa lógicamente los temas
And crea una historia individual por cada requerimiento detectado | EP06 | +| US38 | Descartar historia durante sesión en vivo | Como analista con una sesión activa, quiero descartar una historia recién generada indicando un motivo, para mantener el backlog de la sesión limpio en tiempo real sin interrumpir la reunión. | Feature: Descarte de historia en vivo
Scenario: Descartar historia en sesión activa (Happy Path)
Given una historia recién generada en el backlog de la sesión activa
When el analista la descarta ingresando un motivo válido
Then la historia se oculta del backlog activo inmediatamente
And queda registrada en el historial de la sesión con su motivo
Scenario Outline: Validaciones al descartar (Unhappy Paths)
Given que el analista intenta descartar una historia
When el formulario presenta el problema <Problema>
Then el sistema bloquea el descarte
And solicita la corrección con el mensaje <Mensaje>
Examples:
| Problema | Mensaje |
|---|---|
| El campo de motivo está completamente vacío | Debes ingresar un motivo para descartar la historia. |
| El motivo excede el límite de caracteres (ej. 500) | El motivo es demasiado largo. |
Scenario: Descartar historia ya descartada simultáneamente (Edge Case - Concurrencia)
Given dos analistas con la misma sesión activa abierta en paralelo
When el analista A descarta una historia y el analista B intenta descartar la misma instantes después
Then el sistema rechaza el intento del analista B
And refresca su vista indicando que la historia ya fue descartada | EP06 | +| US39 | Descartar historia en revisión post-sesión | Como analista revisando el backlog después de cerrar la sesión, quiero descartar una historia indicando un motivo, para depurar el resultado final antes de que el equipo de desarrollo lo utilice. | Feature: Descarte de historia en revisión
Scenario: Descartar historia en etapa de revisión (Happy Path)
Given una sesión cerrada con historias pendientes de revisión
When el analista descarta una historia ingresando un motivo válido
Then la historia pasa al estado 'Descartada'
And el motivo queda visible en el historial del proyecto
Scenario: Descarte concurrente (Edge Case)
Given una historia en revisión visible para dos analistas al mismo tiempo
When el analista A la descarta y segundos después el analista B intenta hacer lo mismo
Then el sistema informa al analista B que la historia ya fue descartada
And refresca su vista del backlog con el estado actualizado | EP10 | +| US40 | Consentimiento de grabación al iniciar sesión | Como analista que va a iniciar una sesión de captura, quiero que el sistema muestre un aviso claro indicando que se grabará audio antes de comenzar, para que todos los participantes sean informados y puedan dar su consentimiento. | Feature: Consentimiento de grabación
Scenario: Mostrar aviso y confirmar inicio (Happy Path)
Given un analista a punto de iniciar una sesión de captura
When hace clic en 'Iniciar sesión'
Then el sistema muestra un modal con el aviso de grabación de audio
And solo activa el micrófono después de que el analista confirma que los participantes fueron informados
Scenario: Cancelar inicio por falta de consentimiento (Unhappy Path)
Given el modal de consentimiento visible
When el analista cancela la acción
Then la sesión no se inicia
And el estado del proyecto permanece sin cambios | EP06 | +| US41 | Pausar y reanudar captura | Como analista durante una sesión activa, quiero pausar la captura cuando la conversación se desvía del tema o hay un receso, para evitar que se generen historias a partir de conversaciones que no son requisitos del cliente. | Feature: Pausa y reanudación
Scenario: Pausar y reanudar la captura (Happy Path)
Given una sesión en estado activa
When el analista pausa la sesión
Then el sistema detiene temporalmente la generación de historias
And al reanudarla, continúa el procesamiento normalmente
Scenario: Intentar pausar una sesión ya pausada (Unhappy Path de concurrencia)
Given una sesión que fue pausada por el analista A
When el analista B intenta pausarla desde otro dispositivo sin haber refrescado
Then el sistema ignora la acción
And sincroniza el estado de la UI para el analista B informando la pausa | EP06 | +| US42 | Cerrar y guardar sesión | Como analista al terminar una reunión, quiero finalizar la sesión de captura, para asegurar que todas las historias generadas queden guardadas en el historial del proyecto. | Feature: Cierre de sesión
Scenario: Cerrar sesión con historias guardadas (Happy Path)
Given una sesión activa con al menos una historia generada
When el analista cierra la sesión de captura
Then la sesión pasa a estado 'cerrada'
And todas las historias se persisten en el proyecto principal
Scenario: Prevenir pérdida de datos al cerrar (Unhappy Path - Flujo de Red)
Given una sesión activa con historias sin sincronizar al backend
When el usuario intenta cerrar la sesión pero no hay conexión a internet
Then el sistema bloquea el cierre temporalmente
And muestra una advertencia de sincronización pendiente para evitar pérdida de datos
Scenario: Cerrar sesión vacía (Edge Case)
Given una sesión activa en la que no se generó ninguna historia
When el analista cierra la sesión
Then el sistema permite el cierre
And muestra el resumen final con contadores en cero | EP06 | +| US43 | Abortar sesión sin guardar | Como analista en una sesión de captura, quiero poder abortar y descartar la reunión por completo si hubo un error (ej. reunión cancelada), para no ensuciar el historial del proyecto con datos basura. | Feature: Abortar sesión en vivo
Scenario: Cancelar y purgar sesión (Happy Path)
Given una sesión activa que no debe ser guardada
When el analista selecciona la opción 'Abortar y salir'
And confirma la advertencia destructiva
Then el sistema purga todas las historias generadas temporalmente
And cierra la sesión sin dejar rastro en el historial del proyecto
Scenario: Abortar por error sin confirmación (Unhappy Path)
Given una sesión activa
When el analista hace clic en 'Abortar'
Then el sistema muestra un modal de confirmación estricto pidiendo tipear 'ELIMINAR'
And no ejecuta el borrado hasta validar el input | EP06 | +| US44 | Etiquetar voz del cliente (Diarización) | Como analista revisando una sesión, quiero poder identificar y etiquetar qué voz corresponde al 'Cliente' y cuáles al 'Equipo', para que la IA priorice las necesidades del cliente y no genere historias basadas en nuestras propias preguntas. | Feature: Diarización (Etiquetado de locutor)
Scenario: Distinguir locutores automáticamente (Happy Path)
Given una sesión de grabación con múltiples participantes (ej. 2 clientes y 1 analista)
When el motor procesa el audio de entrada
Then el sistema segmenta el audio y asigna la transcripción a etiquetas como 'Speaker 1', 'Speaker 2'
And el analista puede renombrar esas etiquetas con los nombres reales de los participantes
Scenario: Audio con superposición de voces (Unhappy Path - Modelo)
Given una sesión activa donde dos personas hablan exactamente al mismo tiempo y fuerte
When el sistema intenta diarizar ese segmento superpuesto
Then el sistema agrupa ambas voces como 'Speaker X'
And advierte sutilmente en la transcripción sobre 'Superposición de voces detectada' | EP06 | +| **EP07** | **Procesamiento de Audio Grabado** | Funcionalidad para procesar grabaciones de reuniones anteriores cuando no fue posible usar la captura en tiempo real. | -- | -- | +| US45 | Subir grabación de reunión | Como analista, quiero subir el archivo de audio de una reunión pasada dentro de un proyecto específico, para que el sistema extraiga los requisitos aplicando el glosario y contexto técnico de ese proyecto. | Feature: Carga de grabaciones
Scenario: Procesar exitosamente una grabación válida (Happy Path)
Given que el analista tiene permisos para crear sesiones
And la organización tiene minutos de procesamiento disponibles
When el analista sube un archivo de audio válido
Then el sistema acepta el archivo
And inicia la extracción de requisitos automáticamente sin intervención manual
Scenario Outline: Rechazar carga de grabaciones inválidas o no permitidas (Unhappy Paths)
Given que el analista intenta subir una grabación
When ocurre la situación descrita en <Condicion_Invalida>
Then el sistema rechaza la carga
And muestra el mensaje explicativo <Mensaje_Esperado>
And no descuenta minutos del plan de suscripción de la organización
Examples:
| Condicion_Invalida | Mensaje_Esperado |
|---|---|
| El archivo tiene un formato no soportado (ej. .pdf, .docx) | El formato del archivo no está soportado. |
| El archivo de audio está corrupto o dañado | El archivo de audio no se puede leer o está dañado. |
| El archivo supera el límite de tamaño máximo permitido | El archivo supera el límite de tamaño permitido. |
| La organización agotó su límite de minutos mensuales | Has alcanzado el límite de procesamiento de tu plan actual. |
Scenario: Consultar el avance del procesamiento (Happy Path)
Given que el analista subió un archivo de audio exitosamente
When consulta la vista de procesamiento
Then el sistema muestra el estado actualizado (ej. 'En cola', 'Procesando', 'Completado')
And muestra un progreso estimado de ser posible
Scenario: Manejo de procesamiento fallido (Unhappy Path - Asíncrono)
Given que un archivo está en estado 'Procesando'
When el motor de IA falla o agota el tiempo de espera por un error interno
Then el estado de la tarea cambia a 'Fallido'
And la interfaz permite al analista reintentar el procesamiento sin volver a subir el archivo | EP07 | +| US47 | Ver historial de sesiones del proyecto | Como miembro del equipo, quiero ver el listado de todas las sesiones (en vivo y grabaciones) asociadas a un proyecto, para acceder rápidamente al resultado de reuniones anteriores sin tener que recordar fechas exactas. | Feature: Historial de sesiones
Scenario: Listar sesiones activas e históricas (Happy Path)
Given un miembro accediendo a la vista de un proyecto
When navega a la sección de historial de sesiones
Then el sistema muestra el listado de sesiones ordenadas por fecha descendente
And cada sesión indica su tipo (en vivo / grabación), fecha y número de historias generadas
Scenario: Proyecto sin sesiones previas (Edge Case)
Given un proyecto recién creado sin sesiones
When el miembro accede al historial
Then el sistema muestra un estado vacío con un mensaje orientativo
Scenario: Sesión con procesamiento de audio en curso (Edge Case)
Given un analista consultando el historial de sesiones del proyecto
When una grabación subida está todavía en proceso de transcripción y extracción
Then el sistema la muestra en el listado con el indicador de estado 'Procesando'
And desactiva las acciones de revisión hasta que el procesamiento finalice | EP07 | +| **EP08** | **Asistencia Proactiva de la IA** | Capacidad del sistema para sugerir acciones al analista durante o después de la sesión con el fin de mejorar la calidad y completitud de los requisitos capturados. | -- | -- | +| US48 | Sugerencias de preguntas al cliente | Como analista durante o después de una sesión, quiero recibir una lista de preguntas concretas cuando el sistema detecta partes ambiguas en lo que dijo el cliente, para hacer esas preguntas antes de cerrar la reunión y evitar contactar al cliente después. Depende de: US37. | Feature: Sugerencias de preguntas al cliente
Scenario: Sugerir preguntas ante un requisito ambiguo (Happy Path)
Given que el sistema generó una historia a partir de la sesión
When la IA detecta partes ambiguas o contradictorias en lo dicho por el cliente
Then muestra una lista de preguntas concretas sugeridas
And vincula las preguntas al punto de ambigüedad específico
Scenario: Omitir sugerencias ante requisitos claros (Unhappy Path)
Given que el sistema generó una historia
When el requisito expresado por el cliente es completamente claro y detallado
Then el sistema no muestra sugerencias de preguntas irrelevantes | EP08 | +| US49 | Detección de casos no mencionados | Como analista revisando las historias generadas, quiero ver una lista de situaciones concretas que no se mencionaron en la reunión pero que suelen presentarse en ese tipo de módulo, para que el equipo las evalúe antes de empezar a construir y no las descubra durante el desarrollo. Depende de: US37. | Feature: Detección de casos no mencionados
Scenario: Proponer escenarios omitidos (Happy Path)
Given una historia de usuario estructurada sobre un módulo específico (ej. 'Login')
When el sistema analiza el contexto general de la historia
Then sugiere casos de uso típicos no mencionados por el cliente (ej. 'Bloqueo de cuenta tras N intentos fallidos')
Scenario Outline: Restricciones de sugerencia (Unhappy Paths)
Given una historia de usuario estructurada
When ocurre el escenario <Escenario>
Then el comportamiento del sistema será <Comportamiento>
Examples:
| Escenario | Comportamiento |
|---|---|
| El contexto del proyecto y el requisito son excesivamente genéricos | No inventa casos de uso sin fundamento ni genera ruido visual. |
| Existen docenas de posibles casos borde asociados al módulo | Filtra la lista y muestra únicamente los N casos más críticos y probables. |
Scenario: Alertar duplicidad evidente (Happy Path)
Given una nueva historia recién generada
When su significado excede el porcentaje de similitud configurado respecto a una historia previamente aprobada
Then el sistema muestra una alerta de posible duplicado
And enlaza a la historia original para comparación
Scenario: Ignorar historias relacionadas pero distintas (Unhappy Path)
Given una nueva historia recién generada
When comparte palabras clave con historias anteriores pero el objetivo funcional es diferente (no supera el umbral de similitud semántica)
Then el sistema no levanta ninguna alerta de duplicidad | EP09 | +| US51 | Resolver historia duplicada | Como analista que recibió una alerta de similitud, quiero decidir si fusiono la nueva historia con la existente o la mantengo separada dejando registrada mi justificación, para que el backlog quede limpio con una decisión explícita visible en el historial. Depende de: US50. | Feature: Resolver historia duplicada
Scenario: Resolver manteniendo la historia separada (Happy Path)
Given una alerta activa de historia similar
When el analista elige la opción 'Mantener separada'
And escribe una justificación válida de negocio
Then la alerta se da por resuelta
And la justificación queda documentada en el historial de la historia
Scenario Outline: Validaciones al intentar resolver (Unhappy Paths)
Given una alerta activa de historia similar
When el analista intenta resolverla con la falla <Falla>
Then el sistema bloquea la resolución
And exige corregir la entrada indicando <Requisito>
Examples:
| Falla | Requisito |
|---|---|
| No seleccionó ni 'Fusionar' ni 'Mantener separada' | Debe elegir explícitamente una acción. |
| Eligió 'Mantener separada' pero dejó la justificación en blanco | La justificación es obligatoria para excepciones. |
Scenario: Intento de resolución concurrente (Unhappy Path - Concurrencia)
Given una alerta de similitud visible para dos analistas simultáneamente
When el analista A resuelve la alerta y segundos después el analista B intenta hacer lo mismo
Then el sistema rechaza la acción del analista B
And notifica que la alerta ya fue resuelta, actualizando la vista | EP09 | +| **EP10** | **Revisión, Edición y Aprobación** | Fase final del flujo donde el analista valida y ajusta el trabajo de la IA antes de que las historias queden listas para el equipo de desarrollo. | -- | -- | +| US52 | Editar historia generada | Como analista, quiero modificar el texto de una historia generada por la IA, para ajustar el lenguaje al estándar que usa mi equipo antes de aprobarla. | Feature: Editar historia generada
Scenario: Guardar cambios en el contenido (Happy Path)
Given que un analista se encuentra editando una historia generada por la IA
When modifica el texto y presiona guardar
Then la historia actualiza su contenido
And preserva la etiqueta o trazabilidad de que su origen inicial fue generado por IA
Scenario Outline: Validaciones del formulario de edición (Unhappy Paths)
Given que el analista intenta guardar las modificaciones de una historia
When el formulario presenta <Error_Formulario>
Then el sistema bloquea el guardado
And muestra el mensaje <Mensaje_Error>
Examples:
| Error_Formulario | Mensaje_Error |
|---|---|
| El título de la historia se ha borrado por completo | El título de la historia es obligatorio. |
| La descripción quedó completamente vacía | La descripción no puede estar vacía. |
Scenario: Conflicto de edición concurrente (Unhappy Path - Flujo Alternativo)
Given que dos usuarios abren la misma historia para editarla al mismo tiempo
When el usuario A guarda sus cambios y luego el usuario B intenta guardar los suyos
Then el sistema bloquea la acción del usuario B
And le advierte que la historia fue modificada externamente para evitar sobreescritura accidental | EP10 | +| US53 | Aprobar historia | Como analista, quiero marcar una historia como aprobada después de revisarla, para que quede disponible para el equipo de desarrollo y pueda exportarse al gestor de tareas. | Feature: Aprobar historia
Scenario: Aprobar historia revisada (Happy Path)
Given una historia completa en estado de revisión
When un usuario con permisos la marca como 'Aprobada'
Then el estado de la historia cambia a 'Aprobada'
And queda disponible en la cola para ser exportada a sistemas externos (ej. Jira)
Scenario Outline: Impedir aprobación de historias incompletas (Unhappy Paths)
Given que el analista intenta aprobar una historia
When la historia tiene <Falla_Integridad>
Then la aprobación es rechazada
And el sistema indica <Razon_Rechazo>
Examples:
| Falla_Integridad | Razon_Rechazo |
|---|---|
| Faltan definir los criterios de aceptación | La historia debe tener criterios de aceptación antes de ser aprobada. |
| La historia tiene alertas de similitud sin resolver | Debes resolver los conflictos de duplicidad pendientes. |
Scenario: Presentar totales precisos (Happy Path)
Given que una sesión de captura acaba de ser cerrada
When el sistema calcula el resumen final de la reunión
Then presenta una vista consolidada mostrando el total exacto de historias creadas, descartadas y pendientes de revisión
Scenario: Inconsistencia crítica durante cálculo (Unhappy Path - Sistema)
Given que una sesión está en proceso de cierre
When el backend detecta una discrepancia en el conteo de registros (inconsistencia de datos transaccional)
Then interrumpe el cierre de la sesión
And alerta al usuario sobre el problema solicitando actualizar la página antes de reintentar el cierre seguro | EP10 | +| US55 | Compartir historias con el cliente | Como analista, quiero generar un enlace público y seguro de solo lectura con las historias generadas, para enviarlo al cliente y que pueda validarlas o comentarlas sin necesidad de crearse una cuenta en la plataforma. | Feature: Aprobación externa del cliente
Scenario: Generar y visitar enlace público (Happy Path)
Given un proyecto con historias en revisión
When el analista genera un enlace público y el cliente accede a él
Then el cliente puede visualizar las historias en modo de solo lectura
And puede marcarlas como 'Aprobadas' o dejar comentarios
Scenario: Expiración o revocación del enlace (Unhappy Path)
Given un enlace público generado anteriormente
When el analista revoca el acceso o expira el tiempo de validez configurado
Then cualquier intento de ingresar mostrará un error de enlace no disponible
Scenario: Cliente externo sin cuenta accede al enlace (Edge Case - Usuario anónimo)
Given un cliente que no tiene cuenta en Reqs-AI y recibió el enlace público por correo
When accede a la URL del enlace desde su navegador
Then puede visualizar las historias en modo solo lectura sin necesidad de autenticarse
And no puede navegar a ninguna otra sección privada de la plataforma desde ese enlace | EP10 | +| US56 | Calificar calidad de historia (Feedback Loop) | Como analista revisando las historias generadas, quiero calificar la precisión de la IA (ej. Pulgar arriba/abajo) e indicar si hubo alucinaciones, para generar un registro de retroalimentación que mejore los prompts y el modelo en el futuro. | Feature: Retroalimentación de la IA (Feedback Loop)
Scenario: Calificar positivamente una historia (Happy Path)
Given una historia generada correctamente por la IA
When el analista la califica positivamente (ej. Pulgar arriba)
Then el sistema registra la métrica de éxito de forma silenciosa para el dataset de calidad
Scenario: Reportar alucinación o error de contexto (Unhappy Path - Mejora continua)
Given una historia que contiene datos inventados o malinterpretados por la IA
When el analista la califica negativamente (ej. Pulgar abajo)
Then el sistema despliega un menú opcional para categorizar el fallo (ej. 'Alucinación', 'Falta contexto')
And vincula el texto original generado con la versión final editada por el analista para afinar los modelos futuros | EP10 | +| US57 | Buscar y filtrar historias del backlog | Como analista revisando el backlog de un proyecto, quiero buscar historias por texto libre y filtrarlas por estado (generada, aprobada, descartada) o épica, para localizar rápidamente las historias que necesito revisar sin tener que desplazarme por todo el backlog. | Feature: Búsqueda y filtrado de historias
Scenario: Búsqueda por texto (Happy Path)
Given un analista en la vista del backlog de un proyecto con múltiples historias
When ingresa un término en el buscador
Then el sistema filtra y muestra únicamente las historias que contienen el término en título o descripción
Scenario: Filtrar por estado (Happy Path)
Given un analista en la vista del backlog
When selecciona el filtro 'Aprobadas'
Then el sistema muestra únicamente las historias en ese estado
Scenario: Sin resultados (Edge Case)
Given un analista aplicando un filtro muy específico
When ninguna historia coincide con los criterios
Then el sistema muestra un estado vacío con un mensaje claro | EP10 | +| **EP11** | **Integraciones Externas** | Conectividad con herramientas del ecosistema de desarrollo para transferir las historias aprobadas al backlog del equipo sin trabajo manual. | -- | -- | +| US58 | Conectar cuenta de Jira | Como Administrador de la organización, quiero autorizar la conexión con Jira a través de un proceso seguro, para que la exportación de historias no requiera compartir credenciales con nadie del equipo. | Feature: Conectar cuenta de Jira
Scenario: Autorización segura y exitosa (Happy Path)
Given un Administrador de la organización en la sección de integraciones
When completa satisfactoriamente el flujo de autorización (OAuth) en la plataforma de Jira
Then el sistema de Reqs-AI vincula el proyecto a Jira
And muestra un indicador visual de conexión activa y saludable
Scenario Outline: Rechazo de autorización (Unhappy Paths)
Given que el Administrador inicia el flujo de autorización
When ocurre el evento <Evento_Fallo>
Then el sistema aborta la integración
And muestra el estado <Estado_Final> sin guardar datos espurios
Examples:
| Evento_Fallo | Estado_Final |
|---|---|
| El usuario deniega los permisos desde la ventana de Jira | Operación cancelada por el usuario, integración inactiva. |
| Fallo de red o timeout durante la comunicación con Jira | Error de comunicación, inténtalo nuevamente. |
Scenario: Token de conexión expirado (Unhappy Path - Flujo Alternativo)
Given una integración previamente configurada que estaba operativa
When el token de seguridad subyacente caduca (vencimiento de credencial)
Then el sistema deshabilita las opciones de exportación
And notifica explícitamente al administrador que se requiere una 'Re-autenticación' para reactivar la conexión | EP11 | +| US59 | Configurar mapeo de proyecto en Jira | Como Administrador de la organización, quiero vincular un proyecto local de Reqs-AI con un Board/Proyecto específico de Jira, para que el sistema sepa exactamente a qué destino enviar las historias durante la exportación. | Feature: Mapeo de proyectos externos
Scenario: Vincular board destino (Happy Path)
Given una integración con Jira activa
When el Administrador accede a la configuración de integración del proyecto
Then puede seleccionar de una lista desplegable el 'Proyecto de Jira' y 'Tipo de Issue' destino
And el sistema guarda este mapeo para las futuras exportaciones
Scenario: Intentar exportar sin mapeo previo (Unhappy Path)
Given un proyecto sin board de destino configurado
When el analista intenta exportar historias a Jira
Then la exportación se bloquea
And el sistema redirige al Administrador a la pantalla de configuración del mapeo
Scenario: Board de Jira eliminado externamente (Edge Case - Servicio externo)
Given un mapeo configurado a un board de Jira que fue eliminado desde Atlassian posteriormente
When el analista intenta ejecutar una exportación de historias
Then el sistema detecta que el destino ya no es accesible
And notifica al Administrador que el mapeo está roto y debe reconfigurarse antes de exportar | EP11 | +| US60 | Exportar historias a Jira | Como analista, quiero enviar las historias aprobadas directamente al backlog de Jira, para que el equipo de desarrollo pueda planificar el sprint sin copiar ni pegar nada manualmente. Depende de: US53 y US58. | Feature: Exportar historias a Jira
Scenario: Exportación exitosa de historias aprobadas (Happy Path)
Given un proyecto con una conexión activa a Jira y varias historias en estado 'Aprobada'
When el analista ejecuta la acción de exportación masiva
Then el sistema transmite únicamente las historias aprobadas a Jira
And marca exitosamente dichas historias como 'Exportadas' dentro de Reqs-AI
Scenario Outline: Validaciones de prerrequisitos de exportación (Unhappy Paths)
Given que el analista intenta ejecutar la exportación masiva
When se incumple la condición <Incumplimiento>
Then el botón o acción es bloqueado o rechazado indicando <Mensaje_Error>
Examples:
| Incumplimiento | Mensaje_Error |
|---|---|
| La integración con Jira no está configurada o el token expiró | Debes conectar y autorizar tu cuenta de Jira primero. |
| No existe ninguna historia que se encuentre en estado 'Aprobada' | No hay historias válidas listas para exportar. |
Scenario: Fallo parcial durante la transmisión de lotes (Unhappy Path - Fallo de red)
Given un lote de 10 historias aprobadas listas para envío a la API de Jira
When la red experimenta intermitencia y 2 de las peticiones fallan
Then el sistema marca las 8 historias exitosas como 'Exportadas'
And retiene las 2 restantes, marcándolas con error de exportación y habilitando un botón para reintentar el lote fallido | EP11 | +| **EP12** | **Arquitectura y Servicios RESTful API** | Endpoints y servicios backend sin interfaz gráfica directa (Technical Stories), necesarios para soportar el procesamiento de IA, integraciones y lógica de negocio del frontend. | -- | -- | +| TS01 | API: Registro de Usuario (POST /auth/register) | Como Developer, quiero un endpoint para registrar usuarios hasheando su contraseña, para asegurar sus accesos. | Scenario: Registro exitoso
Given payload con email y password
When POST a /auth/register
Then 201 Created | EP12 | +| TS02 | API: Login de Usuario (POST /auth/login) | Como Developer, quiero un endpoint que valide credenciales y retorne un JWT. | Scenario: Login válido
Given credenciales correctas
When POST a /auth/login
Then 200 OK con token JWT | EP12 | +| TS03 | API: Perfil de Usuario (GET /auth/me) | Como Developer, quiero un endpoint que retorne los datos del usuario logueado según su JWT. | Scenario: Token válido
Given header Authorization: Bearer <token>
When GET a /auth/me
Then 200 OK | EP12 | +| TS04 | API: Crear Proyecto (POST /projects) | Como Developer, quiero un endpoint para crear un nuevo espacio de trabajo. | Scenario: Creación de proyecto
Given payload con nombre
When POST a /projects
Then 201 Created | EP12 | +| TS05 | API: Listar Proyectos (GET /projects) | Como Developer, quiero un endpoint para listar los proyectos del usuario autenticado. | Scenario: Listar proyectos
Given usuario con token válido
When GET a /projects
Then 200 OK con array de proyectos | EP12 | +| TS06 | API: Actualizar Proyecto (PUT /projects/{id}) | Como Developer, quiero un endpoint para modificar metadatos de un proyecto. | Scenario: Actualización válida
Given ID de proyecto existente
When PUT a /projects/{id}
Then 200 OK | EP12 | +| TS07 | API: Eliminar Proyecto (DELETE /projects/{id}) | Como Developer, quiero un endpoint de soft-delete para archivar proyectos. | Scenario: Eliminación lógica
Given ID válido
When DELETE a /projects/{id}
Then 204 No Content | EP12 | +| TS08 | API: Subir Audio (POST /sessions/upload) | Como Developer, quiero un endpoint que reciba un multipart/form-data y lo suba a Cloud Storage. | Scenario: Subida exitosa
Given archivo MP3
When POST a /sessions/upload
Then 200 OK con URL del storage | EP12 | +| TS09 | API: Transcribir Audio (POST /sessions/transcribe) | Como Developer, quiero un endpoint que envíe la URL del audio a Whisper/AWS y retorne texto. | Scenario: Transcripción exitosa
Given URL de audio válida
When POST a /sessions/transcribe
Then 200 OK con transcripción | EP12 | +| TS10 | API: Extraer Historias (POST /sessions/extract) | Como Developer, quiero un endpoint que procese la transcripción con el LLM y retorne el JSON de historias. | Scenario: Extracción LLM
Given texto transcrito
When POST a /sessions/extract
Then 200 OK con array JSON | EP12 | +| TS11 | API: Auth Jira (GET /integrations/jira/auth) | Como Developer, quiero un endpoint para iniciar el flujo OAuth2 con Atlassian. | Scenario: Redirección OAuth
Given petición de integración
When GET a /integrations/jira/auth
Then 302 Redirect a Jira | EP12 | +| TS12 | API: Exportar a Jira (POST /integrations/jira/export) | Como Developer, quiero un endpoint que mapee y envíe las historias al Webhook de Jira. | Scenario: Exportación a Webhook
Given array de IDs de historias
When POST a /integrations/jira/export
Then 200 OK confirmando creación | EP12 | +| TS13 | Servicio interno: Chunking de audio para ventana de tokens del LLM | Como Developer, quiero que el pipeline de procesamiento divida automáticamente los audios largos en fragmentos semánticos manejables antes de enviarlos al LLM, para evitar errores de límite de tokens y garantizar coherencia en reuniones extensas. | Scenario: Chunking de audio largo
Given audio que supera la ventana de contexto del LLM
When el pipeline de procesamiento lo recibe
Then lo divide en bloques lógicos sin cortar oraciones
And los consolida al finalizar sin pérdida de información
Scenario: Reintento de fragmento fallido
Given un audio dividido en N chunks
When un chunk falla por intermitencia de red
Then el sistema reintenta únicamente ese fragmento sin relanzar todo el proceso | EP12 | +| TS14 | API: Cerrar Sesión de Usuario (POST /auth/logout) | Como Developer, quiero un endpoint que invalide el token JWT activo del usuario. | Scenario: Logout exitoso
Given token JWT válido en header
When POST a /auth/logout
Then 200 OK y token invalidado en blacklist | EP12 | +| TS15 | API: Verificar Email (POST /auth/verify-email) | Como Developer, quiero un endpoint que valide el token de verificación enviado por correo. | Scenario: Verificación válida
Given token de verificación vigente
When POST a /auth/verify-email
Then 200 OK y cuenta marcada como verificada | EP12 | +| TS16 | API: Recuperar Contraseña (POST /auth/forgot-password) | Como Developer, quiero un endpoint que genere y envíe un enlace de reset de contraseña al email. | Scenario: Solicitud de reset
Given email registrado en el sistema
When POST a /auth/forgot-password
Then 200 OK y email de reset enviado | EP12 | +| TS17 | API: Actualizar Perfil de Usuario (PUT /auth/profile) | Como Developer, quiero un endpoint que permita al usuario autenticado editar nombre, avatar y preferencias. | Scenario: Actualización válida
Given usuario autenticado con token JWT
When PUT a /auth/profile con body válido
Then 200 OK con perfil actualizado | EP12 | +| TS18 | API: Crear Organización (POST /organizations) | Como Developer, quiero un endpoint que cree una nueva organización y asigne al creador como Owner. | Scenario: Creación exitosa
Given usuario autenticado sin organización activa
When POST a /organizations con nombre válido
Then 201 Created con ID de organización y rol Owner asignado | EP12 | +| TS19 | API: Actualizar Organización (PUT /organizations/{id}) | Como Developer, quiero un endpoint para modificar nombre, logo y configuraciones de la organización. | Scenario: Actualización válida
Given usuario con permiso de Owner en la organización
When PUT a /organizations/{id} con datos válidos
Then 200 OK con organización actualizada | EP12 | +| TS20 | API: Cambiar Contexto de Organización (POST /organizations/switch) | Como Developer, quiero un endpoint que cambie la organización activa en la sesión del usuario. | Scenario: Cambio exitoso
Given usuario miembro de múltiples organizaciones
When POST a /organizations/switch con el ID destino
Then 200 OK con nuevo JWT que refleja el contexto actualizado | EP12 | +| TS21 | API: Invitar Miembro (POST /organizations/{id}/invitations) | Como Developer, quiero un endpoint que genere y envíe una invitación por email para unirse a la organización. | Scenario: Invitación enviada
Given usuario Owner o Admin con permisos de invitación
When POST a /organizations/{id}/invitations con email y rol
Then 201 Created y email de invitación enviado | EP12 | +| TS22 | API: Crear Rol Personalizado (POST /organizations/{id}/roles) | Como Developer, quiero un endpoint que registre un nuevo rol con nombre y conjunto de permisos. | Scenario: Creación de rol
Given usuario Owner de la organización
When POST a /organizations/{id}/roles con nombre y permisos
Then 201 Created con ID del nuevo rol | EP12 | +| TS23 | API: Configurar Permisos de Rol (PUT /organizations/{id}/roles/{roleId}) | Como Developer, quiero un endpoint que actualice los permisos asociados a un rol existente. | Scenario: Actualización de permisos
Given rol existente en la organización
When PUT a /organizations/{id}/roles/{roleId} con nuevos permisos
Then 200 OK con rol actualizado | EP12 | +| TS24 | API: Eliminar Rol (DELETE /organizations/{id}/roles/{roleId}) | Como Developer, quiero un endpoint que elimine un rol personalizado si no tiene miembros asignados. | Scenario: Eliminación válida
Given rol sin miembros asignados
When DELETE a /organizations/{id}/roles/{roleId}
Then 204 No Content
Scenario: Rol en uso (Unhappy Path)
Given rol con miembros activos
When DELETE a /organizations/{id}/roles/{roleId}
Then 409 Conflict con mensaje indicando miembros activos | EP12 | +| TS25 | API: Crear Sesión en Vivo (POST /sessions) | Como Developer, quiero un endpoint que inicialice una sesión de captura en vivo asociada a un proyecto. | Scenario: Creación exitosa
Given proyecto activo y usuario con permiso de edición
When POST a /sessions con ID de proyecto
Then 201 Created con ID de sesión y estado OPEN | EP12 | +| TS26 | API: Cambiar Estado de Sesión (PATCH /sessions/{id}/status) | Como Developer, quiero un endpoint que cambie el estado de una sesión entre OPEN, PAUSED y CLOSED. | Scenario: Cierre de sesión
Given sesión en estado OPEN
When PATCH a /sessions/{id}/status con estado CLOSED
Then 200 OK y sesión marcada como CLOSED | EP12 | +| TS27 | API: Listar Sesiones de Proyecto (GET /projects/{id}/sessions) | Como Developer, quiero un endpoint paginado que retorne todas las sesiones de un proyecto ordenadas por fecha. | Scenario: Listado exitoso
Given proyecto con sesiones registradas
When GET a /projects/{id}/sessions
Then 200 OK con array paginado de sesiones | EP12 | +| TS28 | API: Listar y Buscar Historias (GET /projects/{id}/stories) | Como Developer, quiero un endpoint con filtros por estado, épica y texto para recuperar historias de un proyecto. | Scenario: Búsqueda con filtro
Given proyecto con historias generadas
When GET a /projects/{id}/stories?status=DRAFT&epic=EP03
Then 200 OK con array filtrado y metadata de paginación | EP12 | +| TS29 | API: Editar Historia (PUT /stories/{id}) | Como Developer, quiero un endpoint que permita actualizar título, descripción y criterios de aceptación de una historia. | Scenario: Edición válida
Given historia existente y usuario con permiso de edición
When PUT a /stories/{id} con body actualizado
Then 200 OK con historia actualizada y timestamp de modificación | EP12 | +| TS30 | API: Cambiar Estado de Historia (PATCH /stories/{id}/status) | Como Developer, quiero un endpoint que cambie el estado de una historia entre DRAFT, APPROVED y REJECTED. | Scenario: Aprobación de historia
Given historia en estado DRAFT
When PATCH a /stories/{id}/status con estado APPROVED
Then 200 OK y historia marcada como APPROVED | EP12 | +| TS31 | API: Cargar Documento (POST /projects/{id}/documents) | Como Developer, quiero un endpoint multipart que acepte PDF/Word, extraiga el texto con Apache Tika y genere embeddings con el LLM. | Scenario: Carga y procesamiento
Given archivo PDF válido
When POST a /projects/{id}/documents
Then 202 Accepted y procesamiento asíncrono iniciado; webhook notifica al completar | EP12 | +| TS32 | API: Agregar Término al Glosario (POST /projects/{id}/glossary) | Como Developer, quiero un endpoint que persista un término con su definición en el contexto de un proyecto. | Scenario: Término agregado
Given proyecto activo y usuario autenticado
When POST a /projects/{id}/glossary con término y definición
Then 201 Created con ID del término | EP12 | +| TS33 | API: Agregar Restricción Técnica (POST /projects/{id}/constraints) | Como Developer, quiero un endpoint que registre una restricción técnica asociada al proyecto para enriquecer el contexto del RAG. | Scenario: Restricción registrada
Given proyecto activo y usuario autenticado
When POST a /projects/{id}/constraints con descripción
Then 201 Created con ID de la restricción | EP12 | +| TS34 | API: Upgrade de Plan (POST /subscriptions/upgrade) | Como Developer, quiero un endpoint que inicie el flujo de pago con Stripe y actualice el plan al confirmar el webhook. | Scenario: Upgrade exitoso
Given organización en plan FREE
When POST a /subscriptions/upgrade con plan destino
Then 200 OK con URL de checkout de Stripe | EP12 | +| TS35 | API: Cancelar Suscripción (DELETE /subscriptions) | Como Developer, quiero un endpoint que marque la suscripción como cancelada al final del período de facturación. | Scenario: Cancelación programada
Given organización con suscripción activa
When DELETE a /subscriptions
Then 200 OK con fecha de expiración y estado CANCELING | EP12 | ## 3.3. Product Backlog @@ -954,68 +1019,103 @@ Esta priorización se rige por el **Valor de Negocio**: las funcionalidades que **Tabla de Estimación y Priorización** -| # Orden | User Story Id | Título | Descripción | Story Points (1/2/3/5/8) | -|:-------:|:--------------|:------------------------------------------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:------------------------:| -| **1** | **US01** | Visualizar Propuesta de Valor (Hero) | Como visitante, quiero entender inmediatamente qué es Reqs-AI y su propuesta de valor principal en la cabecera (Hero), para decidir en los primeros segundos si me interesa continuar explorando la herramienta. | **3** | -| **2** | **US02** | Explorar Casos de Uso por Segmento | Como visitante, quiero alternar entre diferentes perfiles (ej. Consultoras vs Startups) en una sección interactiva, para ver beneficios y ejemplos específicos que se adapten a la realidad de mi equipo. | **3** | -| **3** | **US03** | Validar Credibilidad (Social Proof) | Como visitante escéptico, quiero ver testimonios, métricas de éxito o logos de empresas que ya usan la herramienta, para sentir confianza antes de invertir mi tiempo o dinero en la plataforma. | **2** | -| **4** | **US04** | Visualizar Planes y Precios | Como visitante evaluando la viabilidad financiera, quiero comparar los planes de suscripción (Gratuito, Pro, Equipo) de forma transparente, para determinar cuál se ajusta a mi presupuesto antes de crearme una cuenta. | **3** | -| **5** | **US35** | Pausar y reanudar captura | Como analista durante una sesión activa, quiero pausar la captura cuando la conversación se desvía del tema o hay un receso, para evitar que se generen historias a partir de conversaciones que no son requisitos del cliente. | **2** | -| **6** | **US36** | Cerrar y guardar sesión | Como analista al terminar una reunión, quiero finalizar la sesión de captura, para asegurar que todas las historias generadas queden guardadas en el historial del proyecto. | **2** | -| **7** | **US34** | Descartar historia (Componente Unificado) | Como analista, quiero descartar una historia generada indicando un motivo, tanto durante la sesión en vivo como en la etapa de revisión posterior, utilizando una misma interfaz para mantener el backlog limpio. | **3** | -| **8** | **US37** | Abortar sesión sin guardar | Como analista en una sesión de captura, quiero poder abortar y descartar la reunión por completo si hubo un error (ej. reunión cancelada), para no ensuciar el historial del proyecto con datos basura. | **2** | -| **9** | **TS62** | API: Subir Audio (POST /sessions/upload) | Como Developer, quiero un endpoint que reciba un multipart/form-data y lo suba a Cloud Storage. | **3** | -| **10** | **TS63** | API: Transcribir Audio (POST /sessions/transcribe) | Como Developer, quiero un endpoint que envíe la URL del audio a Whisper/AWS y retorne texto. | **5** | -| **11** | **TS64** | API: Extraer Historias (POST /sessions/extract) | Como Developer, quiero un endpoint que procese la transcripción con el LLM y retorne el JSON de historias. | **5** | -| **12** | **US38** | Etiquetar voz del cliente (Diarización) | Como analista revisando una sesión, quiero poder identificar y etiquetar qué voz corresponde al 'Cliente' y cuáles al 'Equipo', para que la IA priorice las necesidades del cliente y no genere historias basadas en nuestras propias preguntas. | **5** | -| **13** | **US40** | Manejo de límite de tokens (Chunking) en IA | Como sistema de procesamiento, quiero dividir los audios grandes en fragmentos manejables (Chunking) antes de enviarlos al LLM, para evitar errores de 'límite de tokens excedido' cuando las reuniones son muy largas. | **8** | -| **14** | **US41** | Ver estado del procesamiento | Como miembro que subió un archivo de audio, quiero ver el avance del procesamiento de forma visible en la pantalla, para saber cuándo las historias están listas sin tener que revisar la sección manualmente cada cierto tiempo. Depende de: US30. | **2** | -| **15** | **US45** | Detección de historias similares | Como analista en una sesión activa, quiero que el sistema me avise con el porcentaje de similitud cuando una historia nueva se parece a una que ya existe en el proyecto, para evitar que el backlog tenga requisitos redundantes o contradictorios entre sí. | **5** | -| **16** | **US46** | Resolver historia duplicada | Como analista que recibió una alerta de similitud, quiero decidir si fusiono la nueva historia con la existente o la mantengo separada dejando registrada mi justificación, para que el backlog quede limpio con una decisión explícita visible en el historial. Depende de: US35. | **3** | -| **17** | **US42** | Sugerencias de preguntas al cliente | Como analista durante o después de una sesión, quiero recibir una lista de preguntas concretas cuando el sistema detecta partes ambiguas en lo que dijo el cliente, para hacer esas preguntas antes de cerrar la reunión y evitar contactar al cliente después. Depende de: US26. | **5** | -| **18** | **US43** | Detección de casos no mencionados | Como analista revisando las historias generadas, quiero ver una lista de situaciones concretas que no se mencionaron en la reunión pero que suelen presentarse en ese tipo de módulo, para que el equipo las evalúe antes de empezar a construir y no las descubra durante el desarrollo. Depende de: US26. | **3** | -| **19** | **US44** | Sugerencias de funcionalidades relacionadas | Como analista en una sesión activa, quiero recibir una lista de funcionalidades que otros sistemas del mismo sector suelen incluir y que el cliente no mencionó, para presentarlas como opciones concretas durante la reunión y que el cliente decida si las quiere o no. | **3** | -| **20** | **US21** | Configurar perfil técnico del proyecto | Como miembro con permiso para configurar proyectos, quiero registrar las tecnologías que usa el equipo del cliente y los tipos de usuarios del sistema, para que los criterios de aceptación generados sean aplicables al contexto real del proyecto. | **3** | -| **21** | **US20** | Cargar documentos del cliente | Como miembro con permiso para configurar proyectos, quiero subir documentos y glosarios del cliente al proyecto, para que las historias generadas reflejen el vocabulario y las reglas del negocio de ese cliente de forma observable en cada historia producida. | **5** | -| **22** | **US24** | Proyecto de demostración automático | Como nuevo usuario que acaba de registrarse, quiero encontrar un proyecto de demostración pre-cargado con audios e historias ya generadas, para entender inmediatamente el valor de la plataforma sin tener que grabar mi propia reunión primero. | **3** | -| **23** | **US22** | Editar proyecto | Como miembro con permiso para administrar proyectos, quiero modificar el nombre o la descripción de un proyecto existente, para corregir o actualizar la información cuando cambian los acuerdos con el cliente. | **1** | -| **24** | **US23** | Archivar proyecto | Como miembro con permiso para administrar proyectos, quiero archivar un proyecto cuando termina el trabajo con ese cliente, para mantener el panel principal ordenado sin eliminar el historial de sesiones e historias generadas. | **2** | -| **25** | **US49** | Resumen de cierre de sesión | Como analista al cerrar una sesión, quiero ver un resumen con el total de historias creadas, descartadas y pendientes de revisión, para confirmar con el cliente que los acuerdos quedaron correctamente registrados antes de dar la reunión por concluida. | **2** | -| **26** | **US50** | Compartir historias con el cliente | Como analista, quiero generar un enlace público y seguro de solo lectura con las historias generadas, para enviarlo al cliente y que pueda validarlas o comentarlas sin necesidad de crearse una cuenta en la plataforma. | **3** | -| **27** | **US51** | Calificar calidad de historia (Feedback Loop) | Como analista revisando las historias generadas, quiero calificar la precisión de la IA (ej. Pulgar arriba/abajo) e indicar si hubo alucinaciones, para generar un registro de retroalimentación que mejore los prompts y el modelo en el futuro. | **2** | -| **28** | **TS65** | API: Auth Jira (GET /integrations/jira/auth) | Como Developer, quiero un endpoint para iniciar el flujo OAuth2 con Atlassian. | **3** | -| **29** | **TS66** | API: Exportar a Jira (POST /integrations/jira/export) | Como Developer, quiero un endpoint que mapee y envíe las historias al Webhook de Jira. | **5** | -| **30** | **US52** | Conectar cuenta de Jira | Como miembro con permiso para configurar integraciones, quiero autorizar la conexión con Jira a través de un proceso seguro, para que la exportación de historias no requiera compartir credenciales con nadie del equipo. | **5** | -| **31** | **US53** | Configurar mapeo de proyecto en Jira | Como administrador, quiero vincular un proyecto local de Reqs-AI con un Board/Proyecto específico de Jira, para que el sistema sepa exactamente a qué destino enviar las historias durante la exportación. | **2** | -| **32** | **US54** | Exportar historias a Jira | Como miembro con permiso para exportar historias, quiero enviar las historias aprobadas directamente al backlog de Jira, para que el equipo de desarrollo pueda planificar el sprint sin copiar ni pegar nada manualmente. Depende de: US38 y US41. | **5** | -| **33** | **US25** | Invitar miembro a la organización | Como miembro con permiso para gestionar el equipo, quiero invitar a un colega mediante su correo electrónico, para que pueda acceder a los proyectos que le correspondan dentro de la organización. | **3** | -| **34** | **US26** | Crear rol personalizado | Como Propietario de la organización, quiero crear un rol con un nombre definido por mi equipo, para representar una función real dentro de la organización en lugar de usar etiquetas genéricas del sistema. | **2** | -| **35** | **US27** | Asignar permisos a un rol | Como Propietario de la organización, quiero seleccionar qué acciones puede realizar cada rol dentro de los proyectos y la organización, para que el nivel de acceso de cada miembro refleje exactamente sus responsabilidades reales. | **3** | -| **36** | **US28** | Asignar rol a un miembro | Como miembro con permiso para gestionar el equipo, quiero asignar uno de los roles disponibles a un miembro de la organización, para que sus permisos queden definidos en el momento en que acepta la invitación. Depende de: US19 y US20. | **1** | -| **37** | **US29** | Editar permisos de un rol existente | Como Propietario de la organización, quiero modificar los permisos de un rol ya creado, para ajustar el nivel de acceso de todos los miembros que lo tienen asignado cuando cambian sus responsabilidades. | **2** | -| **38** | **US30** | Eliminar un rol | Como Propietario de la organización, quiero eliminar un rol que ya no corresponde a ninguna función activa del equipo, para mantener la lista de roles ordenada y evitar asignaciones incorrectas. | **1** | -| **39** | **US31** | Remover miembro de la organización | Como miembro con permiso para gestionar el equipo, quiero remover a un miembro de la organización, para revocar su acceso a todos los proyectos de forma inmediata cuando ya no forma parte del equipo. | **2** | -| **40** | **TS55** | API: Registro de Usuario (POST /auth/register) | Como Developer, quiero un endpoint para registrar usuarios hasheando su contraseña, para asegurar sus accesos. | **2** | -| **41** | **TS56** | API: Login de Usuario (POST /auth/login) | Como Developer, quiero un endpoint que valide credenciales y retorne un JWT. | **2** | -| **42** | **TS57** | API: Perfil de Usuario (GET /auth/me) | Como Developer, quiero un endpoint que retorne los datos del usuario logueado según su JWT. | **1** | -| **43** | **US05** | Registro de cuenta | Como visitante que llega por primera vez a la plataforma, quiero crear una cuenta con mi correo y una contraseña, para poder acceder a mis proyectos y sesiones de captura de requisitos. | **3** | -| **44** | **US06** | Verificación de correo | Como usuario con cuenta pendiente de activación, quiero verificar mi correo haciendo clic en el enlace que recibí, para activar mi cuenta y empezar a trabajar en la plataforma. | **2** | -| **45** | **US07** | Inicio de sesión | Como usuario con cuenta activa, quiero iniciar sesión con mi correo y contraseña, para acceder a mis proyectos y al historial de sesiones de mi organización. | **3** | -| **46** | **US08** | Recuperación de contraseña | Como usuario registrado que no recuerda su contraseña, quiero recibir un enlace de restablecimiento en mi correo, para recuperar el acceso a mi cuenta sin perder mi historial de trabajo. | **2** | -| **47** | **US09** | Crear organización | Como usuario autenticado que aún no pertenece a ninguna organización, quiero crear un espacio de trabajo con el nombre de mi empresa, para centralizar mis proyectos y gestionar mi equipo en un entorno separado. | **2** | -| **48** | **US10** | Editar organización | Como Propietario de la organización, quiero actualizar el nombre o los datos generales de mi organización, para mantener la información correcta cuando el equipo o el negocio cambia. | **1** | -| **49** | **US11** | Cambiar de organización | Como usuario que pertenece a más de una organización, quiero seleccionar con cuál quiero trabajar desde el menú principal, para asegurarme de estar operando en el contexto correcto según el cliente que estoy atendiendo. | **2** | -| **50** | **TS58** | API: Crear Proyecto (POST /projects) | Como Developer, quiero un endpoint para crear un nuevo espacio de trabajo. | **2** | -| **51** | **TS59** | API: Listar Proyectos (GET /projects) | Como Developer, quiero un endpoint para listar los proyectos del usuario autenticado. | **1** | -| **52** | **TS60** | API: Actualizar Proyecto (PUT /projects/{id}) | Como Developer, quiero un endpoint para modificar metadatos de un proyecto. | **1** | -| **53** | **TS61** | API: Eliminar Proyecto (DELETE /projects/{id}) | Como Developer, quiero un endpoint de soft-delete para archivar proyectos. | **1** | -| **54** | **US12** | Política de retención de audios | Como Propietario de la organización, quiero configurar la eliminación automática de los archivos de audio originales X días después de procesarse, para cumplir con las políticas de privacidad y confidencialidad corporativas. | **3** | -| **55** | **US13** | Plan gratuito automático | Como usuario que acaba de crear su organización, quiero empezar a usar la plataforma sin ingresar datos de pago, para evaluar si se ajusta a mis necesidades antes de decidir suscribirme. | **2** | -| **56** | **US14** | Suscripción al plan Pro | Como Propietario de una organización en plan gratuito, quiero contratar el plan Pro, para acceder a sesiones ilimitadas, captura en tiempo real e integración con Jira. | **5** | -| **57** | **US15** | Suscripción al plan Equipo | Como Propietario de una organización en plan Pro, quiero contratar el plan Equipo, para poder agregar a todos los miembros de mi equipo y definir mediante roles personalizados qué puede hacer cada uno. | **3** | -| **58** | **US16** | Cancelación de suscripción | Como Propietario de una suscripción activa, quiero cancelar mi plan antes de que inicie el siguiente período de facturación, para no recibir cargos adicionales después de dejar de usar el servicio. | **2** | -| **59** | **US17** | Ver estado del plan y consumo | Como Propietario de la organización, quiero ver el plan activo, la fecha de renovación y cuántas sesiones o proyectos he usado, para saber cuándo necesito actualizar mi plan antes de quedarme sin cupo. | **3** | -| **60** | **US18** | Dashboard de valor y ahorro de tiempo | Como Propietario de la organización, quiero ver un panel que traduzca las historias generadas en 'horas de trabajo manual ahorradas', para justificar el pago de la suscripción y entender el retorno de inversión mensual de la herramienta. | **5** | +| # Orden | User Story Id | Título | Descripción | Story Points (1/2/3/5/8) | +|:-------:|:--------------|:-------------------------------------------------------------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:------------------------:| +| **1** | **US01** | Visualizar Propuesta de Valor (Hero) | Como visitante, quiero entender inmediatamente qué es Reqs-AI y su propuesta de valor principal en la cabecera (Hero), para decidir en los primeros segundos si me interesa continuar explorando la herramienta. | **3** | +| **2** | **US02** | Explorar Casos de Uso por Segmento | Como visitante, quiero alternar entre diferentes perfiles (ej. Consultoras vs Startups) en una sección interactiva, para ver beneficios y ejemplos específicos que se adapten a la realidad de mi equipo. | **3** | +| **3** | **US03** | Visualizar Planes y Precios | Como visitante evaluando la viabilidad financiera, quiero comparar los planes de suscripción (Gratuito, Pro, Equipo) de forma transparente, para determinar cuál se ajusta a mi presupuesto antes de crearme una cuenta. | **2** | +| **4** | **TS01** | API: Registro de Usuario (POST /auth/register) | Como Developer, quiero un endpoint para registrar usuarios hasheando su contraseña, para asegurar sus accesos. | **2** | +| **5** | **TS02** | API: Login de Usuario (POST /auth/login) | Como Developer, quiero un endpoint que valide credenciales y retorne un JWT. | **2** | +| **6** | **TS03** | API: Perfil de Usuario (GET /auth/me) | Como Developer, quiero un endpoint que retorne los datos del usuario logueado según su JWT. | **1** | +| **7** | **TS15** | API: Verificar Email (POST /auth/verify-email) | Como Developer, quiero un endpoint que valide el token de verificación enviado por correo. | **3** | +| **8** | **TS16** | API: Recuperar Contraseña (POST /auth/forgot-password) | Como Developer, quiero un endpoint que genere y envíe un enlace de reset de contraseña al email. | **3** | +| **9** | **TS17** | API: Actualizar Perfil de Usuario (PUT /auth/profile) | Como Developer, quiero un endpoint que permita al usuario autenticado editar nombre, avatar y preferencias. | **3** | +| **10** | **TS14** | API: Cerrar Sesión de Usuario (POST /auth/logout) | Como Developer, quiero un endpoint que invalide el token JWT activo del usuario. | **3** | +| **11** | **US04** | Registro de cuenta | Como visitante que llega por primera vez a la plataforma, quiero crear una cuenta con mi correo y una contraseña, para poder acceder a mis proyectos y sesiones de captura de requisitos. | **3** | +| **12** | **US05** | Verificación de correo | Como usuario con cuenta pendiente de activación, quiero verificar mi correo haciendo clic en el enlace que recibí, para activar mi cuenta y empezar a trabajar en la plataforma. | **2** | +| **13** | **US06** | Inicio de sesión | Como usuario con cuenta activa, quiero iniciar sesión con mi correo y contraseña, para acceder a mis proyectos y al historial de sesiones de mi organización. | **3** | +| **14** | **US07** | Recuperación de contraseña | Como usuario registrado que no recuerda su contraseña, quiero recibir un enlace de restablecimiento en mi correo, para recuperar el acceso a mi cuenta sin perder mi historial de trabajo. | **2** | +| **15** | **US08** | Cerrar sesión | Como usuario autenticado, quiero cerrar mi sesión de forma explícita, para asegurarme de que nadie más pueda acceder a mi cuenta desde el mismo dispositivo. | **1** | +| **16** | **US09** | Aceptar términos y política de privacidad | Como nuevo usuario completando el registro, quiero leer y aceptar los términos de uso y la política de privacidad antes de activar mi cuenta, para entender cómo se usan mis datos y las grabaciones de audio antes de comenzar a usar el servicio. | **1** | +| **17** | **US10** | Editar perfil de usuario | Como usuario autenticado, quiero actualizar mi nombre y foto de perfil, para que mis compañeros de equipo me identifiquen correctamente en los registros de actividad de las sesiones. | **2** | +| **18** | **TS18** | API: Crear Organización (POST /organizations) | Como Developer, quiero un endpoint que cree una nueva organización y asigne al creador como Owner. | **3** | +| **19** | **TS19** | API: Actualizar Organización (PUT /organizations/{id}) | Como Developer, quiero un endpoint para modificar nombre, logo y configuraciones de la organización. | **3** | +| **20** | **TS20** | API: Cambiar Contexto de Organización (POST /organizations/switch) | Como Developer, quiero un endpoint que cambie la organización activa en la sesión del usuario. | **3** | +| **21** | **US11** | Crear organización | Como usuario autenticado que aún no pertenece a ninguna organización, quiero crear un espacio de trabajo con el nombre de mi empresa, para centralizar mis proyectos y gestionar mi equipo en un entorno separado. | **2** | +| **22** | **US12** | Editar organización | Como Propietario de la organización, quiero actualizar el nombre o los datos generales de mi organización, para mantener la información correcta cuando el equipo o el negocio cambia. | **1** | +| **23** | **US13** | Cambiar de organización | Como usuario que pertenece a más de una organización, quiero seleccionar con cuál quiero trabajar desde el menú principal, para asegurarme de estar operando en el contexto correcto según el cliente que estoy atendiendo. | **2** | +| **24** | **US14** | Política de retención de audios | Como Propietario de la organización, quiero configurar la eliminación automática de los archivos de audio originales X días después de procesarse, para cumplir con las políticas de privacidad y confidencialidad corporativas. | **3** | +| **25** | **TS34** | API: Upgrade de Plan (POST /subscriptions/upgrade) | Como Developer, quiero un endpoint que inicie el flujo de pago con Stripe y actualice el plan al confirmar el webhook. | **3** | +| **26** | **TS35** | API: Cancelar Suscripción (DELETE /subscriptions) | Como Developer, quiero un endpoint que marque la suscripción como cancelada al final del período de facturación. | **3** | +| **27** | **US15** | Plan gratuito automático | Como usuario que acaba de crear su organización, quiero empezar a usar la plataforma sin ingresar datos de pago, para evaluar si se ajusta a mis necesidades antes de decidir suscribirme. | **2** | +| **28** | **US16** | Suscripción al plan Pro | Como Propietario de una organización en plan gratuito, quiero contratar el plan Pro, para acceder a sesiones ilimitadas, captura en tiempo real e integración con Jira. | **5** | +| **29** | **US17** | Suscripción al plan Equipo | Como Propietario de una organización en plan Pro, quiero contratar el plan Equipo, para poder agregar a todos los miembros de mi equipo y definir mediante roles personalizados qué puede hacer cada uno. | **3** | +| **30** | **US18** | Cancelación de suscripción | Como Propietario de una suscripción activa, quiero cancelar mi plan antes de que inicie el siguiente período de facturación, para no recibir cargos adicionales después de dejar de usar el servicio. | **2** | +| **31** | **US19** | Ver estado del plan y consumo | Como Propietario de la organización, quiero ver el plan activo, la fecha de renovación y cuántas sesiones o proyectos he usado, para saber cuándo necesito actualizar mi plan antes de quedarme sin cupo. | **3** | +| **32** | **TS04** | API: Crear Proyecto (POST /projects) | Como Developer, quiero un endpoint para crear un nuevo espacio de trabajo. | **2** | +| **33** | **TS05** | API: Listar Proyectos (GET /projects) | Como Developer, quiero un endpoint para listar los proyectos del usuario autenticado. | **1** | +| **34** | **TS06** | API: Actualizar Proyecto (PUT /projects/{id}) | Como Developer, quiero un endpoint para modificar metadatos de un proyecto. | **1** | +| **35** | **TS07** | API: Eliminar Proyecto (DELETE /projects/{id}) | Como Developer, quiero un endpoint de soft-delete para archivar proyectos. | **1** | +| **36** | **TS31** | API: Cargar Documento (POST /projects/{id}/documents) | Como Developer, quiero un endpoint multipart que acepte PDF/Word, extraiga el texto con Apache Tika y genere embeddings con el LLM. | **3** | +| **37** | **TS32** | API: Agregar Término al Glosario (POST /projects/{id}/glossary) | Como Developer, quiero un endpoint que persista un término con su definición en el contexto de un proyecto. | **3** | +| **38** | **TS33** | API: Agregar Restricción Técnica (POST /projects/{id}/constraints) | Como Developer, quiero un endpoint que registre una restricción técnica asociada al proyecto para enriquecer el contexto del RAG. | **3** | +| **39** | **US20** | Crear proyecto | Como analista, quiero registrar un proyecto asociado a un cliente específico, para organizar y separar todas las sesiones de levantamiento de requisitos de ese cliente. | **2** | +| **40** | **US21** | Cargar documentos del cliente | Como analista, quiero subir documentos del cliente (PDF, Word) al proyecto, para que el sistema extraiga y clasifique automáticamente su contenido en glosario, restricciones y contexto general, enriqueciendo así las historias que se generen en sesiones futuras. | **5** | +| **41** | **US22** | Configurar perfil técnico del proyecto | Como analista, quiero registrar las tecnologías que usa el equipo del cliente y los tipos de usuarios del sistema, para que los criterios de aceptación generados sean aplicables al contexto real del proyecto. | **3** | +| **42** | **US23** | Agregar término al glosario manualmente | Como analista, quiero agregar términos del negocio del cliente directamente al glosario del proyecto sin necesidad de subir un documento, para enriquecer el vocabulario de la IA cuando el cliente solo transmite su conocimiento de forma oral. | **2** | +| **43** | **US24** | Registrar restricción técnica manualmente | Como analista, quiero registrar restricciones técnicas del cliente (ej. 'sin uso de cookies de terceros', 'máximo 3 segundos de latencia') directamente en el proyecto, para que la IA las considere al generar los criterios de aceptación sin necesidad de incluirlas en cada sesión. | **2** | +| **44** | **US25** | Editar proyecto | Como analista, quiero modificar el nombre o la descripción de un proyecto existente, para corregir o actualizar la información cuando cambian los acuerdos con el cliente. | **1** | +| **45** | **US26** | Archivar proyecto | Como analista, quiero archivar un proyecto cuando termina el trabajo con ese cliente, para mantener el panel principal ordenado sin eliminar el historial de sesiones e historias generadas. | **2** | +| **46** | **US27** | Proyecto de demostración automático | Como nuevo usuario que acaba de registrarse, quiero encontrar un proyecto de demostración pre-cargado con audios e historias ya generadas, para entender inmediatamente el valor de la plataforma sin tener que grabar mi propia reunión primero. | **3** | +| **47** | **TS21** | API: Invitar Miembro (POST /organizations/{id}/invitations) | Como Developer, quiero un endpoint que genere y envíe una invitación por email para unirse a la organización. | **3** | +| **48** | **TS22** | API: Crear Rol Personalizado (POST /organizations/{id}/roles) | Como Developer, quiero un endpoint que registre un nuevo rol con nombre y conjunto de permisos. | **3** | +| **49** | **TS23** | API: Configurar Permisos de Rol (PUT /organizations/{id}/roles/{roleId}) | Como Developer, quiero un endpoint que actualice los permisos asociados a un rol existente. | **3** | +| **50** | **TS24** | API: Eliminar Rol (DELETE /organizations/{id}/roles/{roleId}) | Como Developer, quiero un endpoint que elimine un rol personalizado si no tiene miembros asignados. | **3** | +| **51** | **US28** | Invitar miembro a la organización | Como Administrador de la organización, quiero invitar a un colega mediante su correo electrónico, para que pueda acceder a los proyectos que le correspondan dentro de la organización. | **3** | +| **52** | **US29** | Crear rol personalizado | Como Propietario de la organización, quiero crear un rol con un nombre definido por mi equipo, para representar una función real dentro de la organización en lugar de usar etiquetas genéricas del sistema. | **2** | +| **53** | **US30** | Asignar permisos a un rol | Como Propietario de la organización, quiero seleccionar qué acciones puede realizar cada rol dentro de los proyectos y la organización, para que el nivel de acceso de cada miembro refleje exactamente sus responsabilidades reales. | **3** | +| **54** | **US31** | Asignar rol a un miembro | Como Administrador de la organización, quiero asignar uno de los roles disponibles a un miembro de la organización, para que sus permisos queden definidos en el momento en que acepta la invitación. | **1** | +| **55** | **US32** | Editar permisos de un rol existente | Como Propietario de la organización, quiero modificar los permisos de un rol ya creado, para ajustar el nivel de acceso de todos los miembros que lo tienen asignado cuando cambian sus responsabilidades. | **2** | +| **56** | **US33** | Eliminar un rol | Como Propietario de la organización, quiero eliminar un rol que ya no corresponde a ninguna función activa del equipo, para mantener la lista de roles ordenada y evitar asignaciones incorrectas. | **1** | +| **57** | **US34** | Remover miembro de la organización | Como Administrador de la organización, quiero remover a un miembro de la organización, para revocar su acceso a todos los proyectos de forma inmediata cuando ya no forma parte del equipo. | **2** | +| **58** | **US35** | Transferir propiedad de la organización | Como Propietario de la organización, quiero transferir la propiedad a otro miembro activo, para poder desvincularme del equipo sin dejar la cuenta sin responsable cuando abandono el proyecto. | **3** | +| **59** | **TS13** | Servicio interno: Chunking de audio para ventana de tokens del LLM | Como Developer, quiero que el pipeline de procesamiento divida automáticamente los audios largos en fragmentos semánticos manejables antes de enviarlos al LLM, para evitar errores de límite de tokens y garantizar coherencia en reuniones extensas. | **3** | +| **60** | **TS25** | API: Crear Sesión en Vivo (POST /sessions) | Como Developer, quiero un endpoint que inicialice una sesión de captura en vivo asociada a un proyecto. | **3** | +| **61** | **TS26** | API: Cambiar Estado de Sesión (PATCH /sessions/{id}/status) | Como Developer, quiero un endpoint que cambie el estado de una sesión entre OPEN, PAUSED y CLOSED. | **3** | +| **62** | **US36** | Iniciar sesión de captura en vivo | Como analista, quiero activar la captura de audio durante la reunión dentro de un proyecto existente, para que el sistema identifique quién habla en cada momento y genere las historias a partir de lo que dice el cliente sin que yo tenga que tomar notas. Depende de: US20. | **3** | +| **63** | **US37** | Generación automática de historias | Como analista en sesión activa, quiero que el sistema convierta automáticamente lo que dice el cliente en historias de usuario con criterios de aceptación, para obtener un backlog estructurado al finalizar la reunión sin necesidad de documentar después. | **8** | +| **64** | **US38** | Descartar historia durante sesión en vivo | Como analista con una sesión activa, quiero descartar una historia recién generada indicando un motivo, para mantener el backlog de la sesión limpio en tiempo real sin interrumpir la reunión. | **2** | +| **65** | **US39** | Descartar historia en revisión post-sesión | Como analista revisando el backlog después de cerrar la sesión, quiero descartar una historia indicando un motivo, para depurar el resultado final antes de que el equipo de desarrollo lo utilice. | **2** | +| **66** | **US40** | Consentimiento de grabación al iniciar sesión | Como analista que va a iniciar una sesión de captura, quiero que el sistema muestre un aviso claro indicando que se grabará audio antes de comenzar, para que todos los participantes sean informados y puedan dar su consentimiento. | **2** | +| **67** | **US41** | Pausar y reanudar captura | Como analista durante una sesión activa, quiero pausar la captura cuando la conversación se desvía del tema o hay un receso, para evitar que se generen historias a partir de conversaciones que no son requisitos del cliente. | **2** | +| **68** | **US42** | Cerrar y guardar sesión | Como analista al terminar una reunión, quiero finalizar la sesión de captura, para asegurar que todas las historias generadas queden guardadas en el historial del proyecto. | **2** | +| **69** | **US43** | Abortar sesión sin guardar | Como analista en una sesión de captura, quiero poder abortar y descartar la reunión por completo si hubo un error (ej. reunión cancelada), para no ensuciar el historial del proyecto con datos basura. | **2** | +| **70** | **US44** | Etiquetar voz del cliente (Diarización) | Como analista revisando una sesión, quiero poder identificar y etiquetar qué voz corresponde al 'Cliente' y cuáles al 'Equipo', para que la IA priorice las necesidades del cliente y no genere historias basadas en nuestras propias preguntas. | **5** | +| **71** | **TS08** | API: Subir Audio (POST /sessions/upload) | Como Developer, quiero un endpoint que reciba un multipart/form-data y lo suba a Cloud Storage. | **3** | +| **72** | **TS09** | API: Transcribir Audio (POST /sessions/transcribe) | Como Developer, quiero un endpoint que envíe la URL del audio a Whisper/AWS y retorne texto. | **5** | +| **73** | **TS10** | API: Extraer Historias (POST /sessions/extract) | Como Developer, quiero un endpoint que procese la transcripción con el LLM y retorne el JSON de historias. | **5** | +| **74** | **US45** | Subir grabación de reunión | Como analista, quiero subir el archivo de audio de una reunión pasada dentro de un proyecto específico, para que el sistema extraiga los requisitos aplicando el glosario y contexto técnico de ese proyecto. | **3** | +| **75** | **US46** | Ver estado del procesamiento | Como analista que subió una grabación de reunión, quiero ver el avance del procesamiento de forma visible en la pantalla, para saber cuándo las historias están listas sin tener que revisar la sección manualmente cada cierto tiempo. Depende de: US45. | **2** | +| **76** | **US47** | Ver historial de sesiones del proyecto | Como miembro del equipo, quiero ver el listado de todas las sesiones (en vivo y grabaciones) asociadas a un proyecto, para acceder rápidamente al resultado de reuniones anteriores sin tener que recordar fechas exactas. | **2** | +| **77** | **US48** | Sugerencias de preguntas al cliente | Como analista durante o después de una sesión, quiero recibir una lista de preguntas concretas cuando el sistema detecta partes ambiguas en lo que dijo el cliente, para hacer esas preguntas antes de cerrar la reunión y evitar contactar al cliente después. Depende de: US37. | **5** | +| **78** | **US49** | Detección de casos no mencionados | Como analista revisando las historias generadas, quiero ver una lista de situaciones concretas que no se mencionaron en la reunión pero que suelen presentarse en ese tipo de módulo, para que el equipo las evalúe antes de empezar a construir y no las descubra durante el desarrollo. Depende de: US37. | **3** | +| **79** | **US50** | Detección de historias similares | Como analista en una sesión activa, quiero que el sistema me avise con el porcentaje de similitud cuando una historia nueva se parece a una que ya existe en el proyecto, para evitar que el backlog tenga requisitos redundantes o contradictorios entre sí. | **5** | +| **80** | **US51** | Resolver historia duplicada | Como analista que recibió una alerta de similitud, quiero decidir si fusiono la nueva historia con la existente o la mantengo separada dejando registrada mi justificación, para que el backlog quede limpio con una decisión explícita visible en el historial. Depende de: US50. | **3** | +| **81** | **TS28** | API: Listar y Buscar Historias (GET /projects/{id}/stories) | Como Developer, quiero un endpoint con filtros por estado, épica y texto para recuperar historias de un proyecto. | **3** | +| **82** | **TS29** | API: Editar Historia (PUT /stories/{id}) | Como Developer, quiero un endpoint que permita actualizar título, descripción y criterios de aceptación de una historia. | **3** | +| **83** | **TS30** | API: Cambiar Estado de Historia (PATCH /stories/{id}/status) | Como Developer, quiero un endpoint que cambie el estado de una historia entre DRAFT, APPROVED y REJECTED. | **3** | +| **84** | **TS27** | API: Listar Sesiones de Proyecto (GET /projects/{id}/sessions) | Como Developer, quiero un endpoint paginado que retorne todas las sesiones de un proyecto ordenadas por fecha. | **3** | +| **85** | **US52** | Editar historia generada | Como analista, quiero modificar el texto de una historia generada por la IA, para ajustar el lenguaje al estándar que usa mi equipo antes de aprobarla. | **3** | +| **86** | **US53** | Aprobar historia | Como analista, quiero marcar una historia como aprobada después de revisarla, para que quede disponible para el equipo de desarrollo y pueda exportarse al gestor de tareas. | **2** | +| **87** | **US54** | Resumen de cierre de sesión | Como analista al cerrar una sesión, quiero ver un resumen con el total de historias creadas, descartadas y pendientes de revisión, para confirmar con el cliente que los acuerdos quedaron correctamente registrados antes de dar la reunión por concluida. | **2** | +| **88** | **US55** | Compartir historias con el cliente | Como analista, quiero generar un enlace público y seguro de solo lectura con las historias generadas, para enviarlo al cliente y que pueda validarlas o comentarlas sin necesidad de crearse una cuenta en la plataforma. | **3** | +| **89** | **US56** | Calificar calidad de historia (Feedback Loop) | Como analista revisando las historias generadas, quiero calificar la precisión de la IA (ej. Pulgar arriba/abajo) e indicar si hubo alucinaciones, para generar un registro de retroalimentación que mejore los prompts y el modelo en el futuro. | **2** | +| **90** | **US57** | Buscar y filtrar historias del backlog | Como analista revisando el backlog de un proyecto, quiero buscar historias por texto libre y filtrarlas por estado (generada, aprobada, descartada) o épica, para localizar rápidamente las historias que necesito revisar sin tener que desplazarme por todo el backlog. | **2** | +| **91** | **TS11** | API: Auth Jira (GET /integrations/jira/auth) | Como Developer, quiero un endpoint para iniciar el flujo OAuth2 con Atlassian. | **3** | +| **92** | **TS12** | API: Exportar a Jira (POST /integrations/jira/export) | Como Developer, quiero un endpoint que mapee y envíe las historias al Webhook de Jira. | **5** | +| **93** | **US58** | Conectar cuenta de Jira | Como Administrador de la organización, quiero autorizar la conexión con Jira a través de un proceso seguro, para que la exportación de historias no requiera compartir credenciales con nadie del equipo. | **5** | +| **94** | **US59** | Configurar mapeo de proyecto en Jira | Como Administrador de la organización, quiero vincular un proyecto local de Reqs-AI con un Board/Proyecto específico de Jira, para que el sistema sepa exactamente a qué destino enviar las historias durante la exportación. | **2** | +| **95** | **US60** | Exportar historias a Jira | Como analista, quiero enviar las historias aprobadas directamente al backlog de Jira, para que el equipo de desarrollo pueda planificar el sprint sin copiar ni pegar nada manualmente. Depende de: US53 y US58. | **5** | **Referencia en Herramienta de Gestión (Jira Software)** @@ -1049,7 +1149,7 @@ La trazabilidad final se mantiene en formato **Goal -> Persona -> Impact -> Deli ## 4.1. Strategic-Level Attribute-Driven Design -### 4.1.1. Design Purpose +### 4.1.1. Design Purpose El propósito del proceso de diseño de Reqs-AI es establecer una arquitectura de software capaz de resolver tecnológicamente la desconexión y pérdida de información que ocurre durante el levantamiento de requisitos. El diseño está concebido como un sistema creado desde cero orientado a construir una solución robusta, escalable y en tiempo real que traduzca la voz del cliente directamente en especificaciones técnicas de alto valor. @@ -1059,21 +1159,27 @@ Este diseño está directamente orientado a satisfacer las necesidades críticas A nivel de negocio para la startup Kntro-Soft, el diseño tiene el propósito de habilitar el modelo de distribución SaaS (Software as a Service). La arquitectura debe soportar el sistema de suscripciones y facturación, gestionar los límites de consumo de los motores de IA (LLM) para mantener la rentabilidad, y asegurar que la plataforma pueda escalar el procesamiento de múltiples organizaciones concurrentes sin degradar la experiencia de usuario. -### 4.1.2. Attribute-Driven Design Inputs +### 4.1.2. Attribute-Driven Design Inputs En esta sección se presentan las entradas fundamentales requeridas para ejecutar el proceso de diseño arquitectónico basado en el método Attribute-Driven Design (ADD). Estos inputs proporcionan el contexto, las metas y los límites que guiarán la toma de decisiones técnicas para la plataforma Reqs-AI. A continuación, el contenido se divide en tres categorías principales dictadas por la metodología: la funcionalidad primaria, los escenarios de atributos de calidad y las restricciones. -#### 4.1.2.1. Primary Functionality (Primary User Stories) +#### 4.1.2.1. Primary Functionality (Primary User Stories) A continuación, se detallan las Historias de Usuario primarias que tienen el mayor impacto arquitectónico en el diseño de Reqs-AI. Estas funcionalidades han sido seleccionadas porque introducen requerimientos complejos de procesamiento asíncrono (análisis de audio en tiempo real), integración con servicios de Inteligencia Artificial (LLM) y aislamiento estricto de datos (Multitenancy), elementos que dictarán la topología base del sistema. | Epic / User Story ID | Título | Descripción | Criterios de Aceptación | Relacionado con (Epic ID) | |:---------------------|:-----------------------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:--------------------------| -| **US05** | Crear organización | Como usuario autenticado sin organización, quiero crear un espacio de trabajo con el nombre de mi empresa, para centralizar proyectos en un entorno separado. | **Given** un usuario autenticado sin organización
**When** crea una organización con un nombre válido
**Then** el sistema genera el espacio de trabajo
**And** asigna al usuario el rol inamovible de 'Propietario' | EP02 | -| **US16** | Cargar documentos del cliente | Como miembro, quiero subir documentos del cliente al proyecto, para que las historias generadas reflejen el vocabulario del negocio (RAG). | **Given** un usuario configurando un proyecto
**When** sube un glosario en PDF válido
**Then** el sistema debe fragmentar (chunking), vectorizar y persistir el documento en una base de datos vectorial en menos de 10 segundos | EP04 | -| **US29** | Generación automática de historias | Como analista, quiero que el sistema procese el audio en vivo y redacte automáticamente historias de usuario estructuradas con criterios de aceptación, para ahorrar horas de redacción manual. | **Given** una sesión de captura de audio activa
**When** el sistema recibe y transcribe el flujo de voz
**Then** el motor de IA procesa el texto generado
**And** redacta una historia de usuario en formato Gherkin
**And** la añade al backlog de la sesión actual | EP06 | +| **US11** | Crear organización | Como usuario autenticado sin organización, quiero crear un espacio de trabajo con el nombre de mi empresa, para centralizar proyectos en un entorno separado. | **Given** un usuario autenticado sin organización
**When** crea una organización con un nombre válido
**Then** el sistema genera el espacio de trabajo
**And** asigna al usuario el rol inamovible de 'Propietario' | EP02 | +| **US21** | Cargar documentos del cliente | Como miembro, quiero subir documentos del cliente al proyecto, para que las historias generadas reflejen el vocabulario del negocio (RAG). | **Given** un usuario configurando un proyecto
**When** sube un glosario en PDF válido
**Then** el sistema debe fragmentar (chunking), vectorizar y persistir el documento en una base de datos vectorial en menos de 10 segundos | EP04 | +| **US37** | Generación automática de historias | Como analista, quiero que el sistema procese el audio en vivo y redacte automáticamente historias de usuario estructuradas con criterios de aceptación, para ahorrar horas de redacción manual. | **Given** una sesión de captura de audio activa
**When** el sistema recibe y transcribe el flujo de voz
**Then** el motor de IA procesa el texto generado
**And** redacta una historia de usuario en formato Gherkin
**And** la añade al backlog de la sesión actual | EP06 | -#### 4.1.2.2. Quality attribute Scenarios +**Justificación del Impacto Arquitectónico:** + +* **US11 (Crear organización):** Define el modelo base de multi-tenant y la asignación de ownership; requiere aislamiento de datos, provisión de recursos por organización y reglas consistentes para separar el acceso entre organizaciones. +* **US21 (Cargar documentos del cliente):** Obliga a definir un pipeline de ingesta asíncrona con chunking, embeddings y almacenamiento vectorial, controlando tiempos de procesamiento, costos y límites por organización. +* **US37 (Generación automática de historias):** Exige procesamiento en tiempo real con baja latencia, orquestación de STT y LLM, y manejo de estados de sesión y reintentos sin perder datos durante la captura en vivo. + +#### 4.1.2.2. Quality attribute Scenarios En esta sección se definen los escenarios de atributos de calidad más críticos que guiarán las decisiones arquitectónicas de Reqs-AI. Se ha priorizado el Rendimiento (necesario para el procesamiento de audio en tiempo real), la Seguridad (aislamiento de datos), la Disponibilidad (para tolerar fallas externas) y la Modificabilidad (cambio de proveedores de IA). @@ -1085,17 +1191,23 @@ En esta sección se definen los escenarios de atributos de calidad más crítico | **Availability (Disponibilidad)** | Proveedor externo de IA (API) | El servicio del LLM no responde (Timeout) o devuelve un error 500 durante una sesión en vivo. | Motor de Integración de IA | Entorno degradado (Falla de dependencia externa). | El sistema persiste la transcripción con estado Pendiente y encola la solicitud en memoria mediante Eventos de Spring asíncronos para reintentar la conexión. | Se recupera la operación con **0 bytes perdidos**. | | **Modifiability (Modificabilidad)** | Arquitecto de Software | El negocio decide cambiar de proveedor de LLM (ej. de OpenAI a Anthropic) por un incremento de precios. | Módulo de Integración de IA | Tiempo de diseño/desarrollo. | El desarrollador implementa un nuevo adaptador (Adapter) para la nueva API sin alterar la lógica de negocio core. | El cambio se completa e integra en **menos de 16 horas de desarrollo**. | -##### 4.1.2.3. Constraints +#### 4.1.2.3. Constraints + +Esta sección describe las restricciones innegociables impuestas por el modelo de negocio, las capacidades técnicas del equipo y la viabilidad del proyecto. Las principales restricciones incluyen la dependencia de API de LLM externos y el uso del stack tecnológico (Java/Spring Boot y Angular/Vue.js). A continuación, se detallan: + +| Constraint ID | Título | Descripción | Criterios de Aceptación | Relacionado con (Epic ID) | +|:--------------|:-------------------------------------|:--------------------------------------------------------------------------------------------------------------------------------------------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:--------------------------| +| **CON-01** | Stack Tecnológico Backend y Frontend | Como equipo de desarrollo, debemos utilizar Java (Spring Boot) para el backend y Angular o Vue.js para el frontend. | **Given** un nuevo componente a desarrollar
**When** el equipo inicie su construcción
**Then** el código debe estar escrito en Java 17+ usando Spring Boot o TypeScript usando Angular/Vue.js. | EP01, EP02 | +| **CON-02** | Uso de APIs de LLM externas | Como Arquitecto de Software, debo integrar el sistema con APIs de modelos de terceros (ej. OpenAI, Anthropic), ya que no alojaremos modelos propios. | **Given** la necesidad de generar Gherkin
**When** el sistema realice una inferencia
**Then** la petición debe enrutarse hacia la API REST del proveedor seleccionado. | EP04 | +| **CON-03** | Despliegue en Cloud Pública | Como responsable de infraestructura, debo asegurar que los componentes sean desplegados en la nube (AWS, Azure o GCP), para evitar costos *on-premise*. | **Given** la liberación de una nueva versión
**When** se ejecute el pipeline de despliegue
**Then** los artefactos deben aprovisionarse en la nube pública seleccionada. | Todas | -Esta sección describe las restricciones innegociables impuestas por el modelo de negocio, las capacidades técnicas del equipo y la viabilidad del proyecto. Las principales restricciones incluyen la dependencia de API de LLM externos y el uso del stack tecnológico (Java/Spring Boot y Angular/Vue.js). A continuación, se detallan como Technical Stories: +**Justificación de Restricciones:** -| Technical Story ID | Título | Descripción | Criterios de Aceptación | Relacionado con (Epic ID) | -|:-------------------|:-------------------------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:--------------------------| -| **TS01** | Stack Tecnológico Backend y Frontend | Como equipo de desarrollo, debemos utilizar Java (Spring Boot) para el backend y Angular o Vue.js para el frontend, debido a la experiencia técnica previa del equipo. | **Given** un nuevo componente a desarrollar
**When** el equipo inicie su construcción
**Then** el código debe estar escrito en Java 17+ usando Spring Boot o TypeScript usando Angular/Vue.js. | EP01, EP02 | -| **TS02** | Uso de APIs de LLM externas | Como Arquitecto de Software, debo integrar el sistema con APIs de modelos de terceros (ej. OpenAI, Anthropic), ya que no alojaremos modelos propios. | **Given** la necesidad de generar Gherkin
**When** el sistema realice una inferencia
**Then** la petición debe enrutarse hacia la API REST del proveedor seleccionado. | EP04 | -| **TS03** | Despliegue en Cloud Pública | Como responsable de infraestructura, debo asegurar que los componentes sean desplegados en la nube (AWS, Azure o GCP), para evitar costos *on-premise*. | **Given** la liberación de una nueva versión
**When** se ejecute el pipeline de despliegue
**Then** los artefactos deben aprovisionarse en la nube pública seleccionada. | Todas | +* **CON-01 (Stack Tecnológico Backend y Frontend):** El equipo tiene experiencia consolidada en Java/Spring y frameworks web, lo que reduce curva de aprendizaje y riesgo de entrega. +* **CON-02 (Uso de API de LLM externas):** Los modelos propios no son viables por costos de infraestructura, mantenimiento y talento especializado para entrenamiento y hosting. +* **CON-03 (Despliegue en Cloud Pública):** La startup necesita reducir costos de inversión inicial y operar con elasticidad sin invertir en infraestructura propia. -### 4.1.3. Architectural Drivers Backlog +### 4.1.3. Architectural Drivers Backlog En esta sección se establece el conjunto de Architectural Drivers acordados por el equipo, resultado del proceso iterativo en nuestro Quality Attribute Workshop (QAW). El Architectural Drivers Backlog consolida los Functional Drivers seleccionados (provenientes de las historias de usuario críticas), los Quality Attribute Drivers seleccionados (Performance, Security, Availability, Modifiability) y todos los Constraints del negocio y la tecnología. Todos los Drivers se presentan a continuación, habiendo sido priorizados de forma descendente colocando primero aquellos que representan una Alta importancia para los Stakeholders y un Alto impacto en la Complejidad Técnica de la Arquitectura. @@ -1110,7 +1222,7 @@ En esta sección se establece el conjunto de Architectural Drivers acordados por | **AD-07** | Despliegue en Cloud Pública | Todos los componentes deben ser contenerizados y desplegados en una nube pública como AWS o Azure para minimizar costos *on-premise* y permitir la escalabilidad. | Medium | Medium | | **AD-08** | Stack Tecnológico Base de Desarrollo | El backend debe desarrollarse en Java (Spring Boot) y el frontend en Angular/Vue.js debido al conocimiento técnico previo del equipo, limitando la adopción de otros lenguajes core. | Medium | Low | -### 4.1.4. Architectural Design Decisions +### 4.1.4. Architectural Design Decisions En esta sección se detalla el proceso seguido durante las iteraciones (Stages) del *Quality Attribute Workshop* para definir la arquitectura de Reqs-AI. En cada etapa, el equipo enfrentó un conjunto específico de *Architectural Drivers* y evaluó distintos patrones o tácticas de diseño, sopesando sus pros y contras (Trade-offs) para asegurar que la solución cumpla con los atributos de calidad exigidos sin incurrir en *over-engineering* para la etapa actual de la startup. @@ -1134,8 +1246,7 @@ La siguiente matriz resume la evaluación de los patrones candidatos considerado | **AD-03** | Tolerancia a Fallos en Servicios Externos | **Cola en Memoria RAM local (Patrón Observer con @Async)** *(Elegido)*
**Pro:** Muy rápido (latencia mínima), simplicidad de código y no requiere aprovisionar infraestructura extra (RabbitMQ/Kafka).
**Con:** Si el servidor se reinicia abruptamente, los eventos en memoria se pierden, por lo que el estado debe respaldarse en Base de Datos. | **Message Broker Persistente (ej. RabbitMQ / Kafka)** *(Descartado)*
**Pro:** Garantiza la durabilidad total de los mensajes y retries automáticos si el pod falla.
**Con:** Exceso de ingeniería (Overengineering) para la etapa actual del proyecto. Requiere aprovisionar, configurar y pagar por otro componente pesado en el cloud. | *(No se evaluó un 3er patrón)* | | **AD-06** | Modificabilidad de Proveedores IA | **Arquitectura Monolítica en Capas**
**Pro:** Modelo mental simple para el equipo (Controllers, Services, Repositories).
**Con:** Lógica de negocio altamente acoplada al SDK del proveedor de IA. Tomaría semanas migrar. *(Descartado)* | **Arquitectura Hexagonal (Ports & Adapters)** *(Elegido)*
**Pro:** El dominio ignora qué IA se usa. Cambiar a Anthropic solo exige escribir un nuevo Adapter para el Port correspondiente en <16h.
**Con:** Exige escribir más código *boilerplate* y dominar Inyección de Dependencias. | *(No se evaluó un 3er patrón)* | -### 4.1.5. Quality Attribute Scenario Refinements - +### 4.1.5. Quality Attribute Scenario Refinements Tras finalizar las iteraciones del *Quality Attribute Workshop* y definir los patrones arquitectónicos base (WebSockets para el streaming, Shared DB con Row Level Security para el multitenancy, y Arquitectura Orientada Eventos en Memoria para la tolerancia a fallos), procedemos a refinar los escenarios de atributos de calidad priorizados. Estos refinamientos incorporan los artefactos tecnológicos que ahora conocemos y mapean directamente los escenarios con los objetivos de negocio (Business Goals) de la plataforma SaaS, identificando además las preguntas abiertas y riesgos remanentes (Issues). @@ -1306,9 +1417,9 @@ A continuación, se presenta la versión final de los escenarios refinados en or -## 4.2. Strategic-Level Domain-Driven Design +## 4.2. Strategic-Level Domain-Driven Design -### 4.2.1. EventStorming +### 4.2.1. EventStorming Para establecer una base sólida en el diseño guiado por el dominio (DDD) y facilitar el descubrimiento de nuestros Bounded Contexts, el equipo de Kntro-Soft llevó a cabo una sesión de **Design-Level Event Storming** utilizando la herramienta colaborativa Miro. La sesión tuvo una duración aproximada de 2 horas. El objetivo principal fue transicionar del espacio del problema (entendido en los capítulos anteriores) al espacio de la solución, mapeando la línea de tiempo completa del negocio de Reqs-AI. Al utilizar un enfoque de nivel de diseño, pudimos no solo explorar los eventos que ocurren en el sistema (como la captura de audio o la generación de Gherkin), sino también agrupar lógicamente las reglas de negocio para descubrir los Agregados (Aggregates) estructurales del código antes de definir las fronteras de los subdominios. @@ -1354,7 +1465,7 @@ El resultado de la sesión de Design-Level Event Storming fue un mapa exhaustivo El paso final metodológico del Event Storming, que consiste en agrupar estos Agregados dentro de las fronteras lógicas de los Bounded Contexts correspondientes, se abordará en detalle en la siguiente sección, donde evaluaremos las relaciones semánticas y cohesivas para definir la arquitectura final del dominio. -### 4.2.2. Candidate Context Discovery +### 4.2.2. Candidate Context Discovery A partir del dominio modelado en nuestra sesión de EventStorming, el equipo llevó a cabo un taller colaborativo de descubrimiento de contextos (Candidate Context Discovery) de aproximadamente 2 horas. El objetivo de esta fase fue trazar fronteras lógicas alrededor de los Agregados identificados previamente, con el fin de descomponer el sistema en módulos altamente cohesivos y con bajo acoplamiento (Bounded Contexts). @@ -1373,7 +1484,6 @@ Buscamos los Eventos Pivote que marcan hitos críticos en la vida del cliente. Evaluamos las integraciones postprocesamiento. * Después de que las historias son generadas, deben enviarse a plataformas externas (ej. Jira). Para proteger nuestro Core Domain de los constantes cambios en las API de terceros, aplicamos el patrón Anti-Corruption Layer (ACL) aislando el agregado ExternalConnection en el **Integration Gateway**. - **Resumen de Bounded Contexts Descubiertos** A través de este proceso analítico y evolutivo, el sistema quedó dividido arquitectónicamente en los siguientes 5 Candidate Bounded Contexts: @@ -1387,7 +1497,7 @@ A través de este proceso analítico y evolutivo, el sistema quedó dividido arq  -### 4.2.3. Domain Message Flows Modeling +### 4.2.3. Domain Message Flows Modeling En esta sección, aplicamos una variante técnica de Domain Storytelling enfocado en el flujo de mensajes para evidenciar cómo colaboran los 5 Bounded Contexts consolidados (**Requirement Discovery**, **Workspace Management**, **IAM**, **Billing & Subscription**, e **Integration Gateway**) y así resolver los casos principales del negocio. @@ -1434,7 +1544,7 @@ Este es un flujo netamente operativo y postprocesamiento. Ocurre después de que  -### 4.2.4. Bounded Context Canvases +### 4.2.4. Bounded Context Canvases En esta sección el equipo diseña sus candidate bounded contexts, detallando los criterios de diseño. El equipo seleccionó cada bounded context, por orden de importancia, para elaborar su Bounded Context Canvas. @@ -1468,7 +1578,7 @@ Capa Anticorrupción (ACL) que protege el Core Domain de los cambios en API de t  -### 4.2.5. Context Mapping +### 4.2.5. Context Mapping En esta sección evidenciamos el proceso de elaboración de nuestro Context Map. Para llegar al diseño estructural definitivo de nuestros 5 Bounded Contexts, el equipo evaluó el modelo sometiéndolo a un análisis crítico, respondiendo a las preguntas estratégicas de diseño sugeridas. Además, aplicamos rigurosamente los patrones de integración definidos por el repositorio oficial de Context Mapping de DDD Crew. @@ -1541,36 +1651,39 @@ A continuación presentamos la visualización de las relaciones estructurales co  -## 4.3. Software Architecture +## 4.3. Software Architecture En este capítulo, el equipo detalla la arquitectura de software de Reqs-AI aplicando el modelo C4. Este modelo jerárquico permite documentar el sistema desde su ecosistema más amplio hasta sus componentes desplegables y su entorno de infraestructura final. Todas las decisiones reflejadas en estos diagramas están alineadas con los Atributos de Calidad y Restricciones analizados previamente, como el uso del Monolito Modular, la tolerancia a fallos en memoria y el multitenancy seguro. -### 4.3.1. Software Architecture System Landscape Diagram +### 4.3.1. Software Architecture System Landscape Diagram El *System Landscape Diagram* proporciona una vista panorámica del ecosistema tecnológico en el que habita Reqs-AI. A diferencia de un simple diagrama de contexto que solo mira hacia adentro, este diagrama ilustra cómo nuestro sistema principal (agrupado dentro de los límites de la empresa *Kntro-Soft Enterprise*) interactúa no solo con los usuarios, sino también con el entorno de herramientas de terceros que el usuario final ya utiliza en su día a día corporativo. A continuación, se presenta la topología del paisaje del sistema: - + **Análisis de Interacciones en el Ecosistema:** -1. **Límite Empresarial Kntro-Soft Enterprise:** Agrupa a nuestros actores principales (Technical Lead y Enterprise Analyst) interactuando centralmente con el **ReqsAI System**. Este es el núcleo de valor donde se graban las reuniones, se analizan los requerimientos y se estructuran en historias de usuario. -2. **Proveedores de Inteligencia y Procesamiento (Core Dependencies):** En la parte inferior, observamos las dependencias críticas (SaaS) que Reqs-AI delega para cumplir sus objetivos complejos: - * **STT API (Speech-to-Text):** Recibe los fragmentos de audio en tiempo real y devuelve el texto. - * **LLM API (Large Language Model):** Recibe el contexto del RAG y la transcripción para inferir historias en formato Gherkin. +1. **Límite Empresarial Kntro-Soft Enterprise:** Agrupa a nuestros actores principales (Technical Lead y Enterprise Analyst) interactuando centralmente con el **ReqsAI System**. Este es el núcleo de valor donde se procesan las transcripciones, se analizan los requerimientos y se estructuran en historias de usuario. +2. **Proveedores de Inteligencia y Procesamiento (Core Dependencies):** Las dependencias tecnológicas críticas que Reqs-AI delega para cumplir sus objetivos: + * **STT API (Speech-to-Text):** Recibe los fragmentos de audio en tiempo real y devuelve el texto transcrito. + * **Embedding API:** Convierte texto en vectores numéricos para el índice RAG. Es utilizada por **Workspace Management** (vectorización de documentos y glosario) y por **Requirement Discovery** (vectorización de historias de usuario generadas para búsqueda semántica). + * **LLM API (Large Language Model generativo):** Procesa y genera texto de alto nivel. **Workspace Management** la invoca para extraer y estructurar el contenido de documentos subidos por el cliente, produciendo fragmentos de calidad para el RAG. **Requirement Discovery** la invoca para inferir historias de usuario en formato Gherkin a partir de la transcripción y el contexto recuperado del RAG. * **Payment Gateway:** Procesa las transacciones de las suscripciones B2B corporativas. -3. **Herramientas de Ecosistema del Cliente (The Landscape Effect):** La verdadera amplitud del ecosistema se observa en los bordes laterales: - * **Project Management Tool Jira:** El diagrama evidencia que el *Technical Lead* gestiona sus Sprints directamente en Jira. ReqsAI actúa como un puente inteligente que exporta las historias de usuario aprobadas hacia esta herramienta, cerrando la brecha entre el levantamiento de requerimientos y la ejecución ágil. - * **Email Service Provider:** El *Enterprise Analyst* recibe notificaciones de su organización a través de su proveedor de correo, alimentadas por los eventos disparados desde nuestro sistema. +3. **Herramientas de Ecosistema del Cliente (The Landscape Effect):** La verdadera amplitud del ecosistema se evidencia en las relaciones laterales entre los usuarios y las herramientas que ya usan **independientemente** de ReqsAI: + * **Video Conferencing Tool (Google Meet, Zoom, MS Teams):** El *Technical Lead* y el *Enterprise Analyst* realizan sus reuniones de levantamiento de requisitos en estas plataformas. Exportan las grabaciones de audio y las suben manualmente a ReqsAI para su procesamiento. Esta es la fuente upstream del audio que alimenta el pipeline de IA. + * **Project Management Tool (Jira, Trello, Linear):** El *Technical Lead* gestiona sus Sprints directamente en la herramienta de su equipo. ReqsAI exporta las historias aprobadas hacia ella, cerrando la brecha entre el levantamiento de requerimientos y la ejecución ágil. + * **Email Service Provider:** El *Enterprise Analyst* recibe notificaciones e invitaciones de su organización a través de su proveedor de correo corporativo. + * **Customer Support Channel:** El *Technical Lead* y el *Enterprise Analyst* tienen disponible este canal de atención via correo electrónico para resolver dudas, y reportar problemas. -### 4.3.2. Software Architecture Context Level Diagrams +### 4.3.2. Software Architecture Context Level Diagrams Mientras que el Diagrama Landscape nos mostró el panorama del negocio, el **Diagrama de Contexto (Context Level Diagram)** del modelo C4 cambia el foco hacia el interior, centrando toda la atención arquitectónica exclusivamente en el **Reqs-AI System**. Este diagrama responde a la pregunta de "¿Cuáles son las fronteras inmediatas de nuestra solución?". A nivel de contexto, eliminamos las interacciones directas entre los usuarios y los sistemas de terceros (ej. el Technical Lead consultando Jira por su cuenta) y nos limitamos a mapear cómo nuestro sistema es el único orquestador responsable de comunicarse con el mundo exterior para cumplir sus objetivos. - + **Análisis de Entradas y Salidas del Sistema Central:** @@ -1582,14 +1695,15 @@ A nivel de contexto, eliminamos las interacciones directas entre los usuarios y * **Email Service Provider:** Recibe peticiones vía REST API para enviar los correos transaccionales de recuperación de contraseña y validación de cuentas. * **Sistemas Core (Outbound Tecnológico):** * **STT API (Speech-to-Text):** Recibe el streaming continuo de audio de las reuniones y retorna texto fragmentado con latencia inferior a 2 segundos. - * **LLM API (Inteligencia Generativa):** Recibe un *Prompt* complejo inyectado con el texto de la reunión y el glosario del proyecto, devolviendo un bloque JSON estructurado en Gherkin. + * **Embedding API:** Transforma texto en vectores numéricos para el motor RAG. **Workspace Management** la invoca al ingerir documentos y el glosario técnico del cliente, almacenando los vectores en pgvector. **Requirement Discovery** la invoca para vectorizar las historias de usuario generadas, habilitando búsquedas semánticas sobre el historial del proyecto. + * **LLM API (Inteligencia Generativa):** Genera y procesa lenguaje de alto nivel. **Workspace Management** la invoca para extraer y estructurar el contenido significativo de los documentos subidos por el cliente antes de vectorizarlos, mejorando la calidad de recuperación del RAG. **Requirement Discovery** la invoca para la inferencia generativa: envía un *prompt* que combina la transcripción de la reunión con el contexto recuperado del RAG y recibe como respuesta un bloque JSON estructurado en formato Gherkin. * **Project Management Tool:** Recibe las historias de usuario aprobadas y formateadas para crear automáticamente *Issues* en el backlog del equipo (por ejemplo en Jira). -### 4.3.3. Software Architecture Container Level Diagrams +### 4.3.3. Software Architecture Container Level Diagrams En esta sección presentamos el diagrama de contenedores para el sistema Reqs-AI. Este nivel hace un enfoque al sistema principal para revelar los contenedores de software que lo componen (aplicaciones móviles, web, API, bases de datos), mostrando cómo se distribuyen las responsabilidades, las decisiones tecnológicas de alto nivel y cómo estos componentes se comunican entre sí y con los sistemas externos. - + El sistema Reqs-AI está compuesto por los siguientes contenedores principales: @@ -1598,11 +1712,11 @@ El sistema Reqs-AI está compuesto por los siguientes contenedores principales: * **Mobile App:** Proporciona accesibilidad móvil a los usuarios, permitiéndoles interactuar con el sistema, grabar reuniones o revisar el estado de los requerimientos desde cualquier lugar. Se optó por **Flutter** para asegurar un desarrollo multiplataforma eficiente (iOS y Android) con una base de código unificada. 2. **Distribución y Enrutamiento Perimetral (Edge):** - * **CDN & Reverse Proxy:** Se posiciona como el intermediario absoluto entre las interfaces de usuario (Internet) y la infraestructura interna. Actúa como proxy inverso interceptando todas las peticiones web y móviles. Su función es servir los archivos estáticos de la Web App a alta velocidad desde ubicaciones globales, almacenar respuestas en caché, mitigar ataques (DDoS) y enrutar las peticiones dinámicas (API) hacia el Gateway. En el entorno AWS, la tecnología elegida es **Amazon CloudFront**. - * **API Gateway:** Actúa como la puerta de entrada para todas las peticiones dinámicas (Requests) enrutadas desde el Reverse Proxy. Su responsabilidad es dirigir estas solicitudes hacia los servicios de backend correspondientes, gestionando el *throttling*, métricas de consumo y terminación SSL. + * **CDN & Reverse Proxy (Amazon CloudFront):** Sirve exclusivamente los activos estáticos del SPA Angular desde Edge Locations globales (HTML, CSS, JS), cachea respuestas, mitiga ataques DDoS y enruta el tráfico dinámico de API hacia el API Gateway. **La app móvil no pasa por CloudFront** — es una aplicación nativa instalada desde el App Store/Google Play que llama directamente la API Gateway. + * **API Gateway (AWS API Gateway):** Punto de entrada unificado para todas las peticiones REST y WebSocket, tanto de la app web (enrutadas desde CloudFront) como de la app móvil (conexión directa). Gestiona throttling, métricas de consumo y terminación SSL. 3. **Lógica Core (Backend — Monolito Modular):** - * **Reqs-AI Backend Application:** Desarrollado en **Java 25 con Spring Boot 3**, se despliega como una única unidad de ejecución que concentra toda la inteligencia de negocio del producto. Está estructurado internamente como un **Monolito Modular**: los 5 Bounded Contexts operan como módulos independientes con fronteras de acceso estrictas, comunicándose entre sí mediante interfaces públicas y eventos en memoria —sin tráfico de red interno—, lo que elimina la latencia distribuida y garantiza la coherencia transaccional durante las sesiones de elicitación en tiempo real. Esta decisión prioriza la simplicidad operativa y el *Time-to-Market* en la etapa actual, manteniendo la arquitectura preparada para una migración selectiva a servicios independientes si el volumen futuro lo justifica. + * **Reqs-AI Backend Application:** Desarrollado en **Java 25 con Spring Boot 4**, se despliega como un único contenedor Docker que concentra toda la inteligencia de negocio del producto. Está estructurado internamente como un **Monolito Modular** con Spring Modulith: los 5 Bounded Contexts operan como módulos independientes con fronteras de acceso estrictas, comunicándose entre sí mediante interfaces públicas y eventos en memoria —sin tráfico de red interno—, lo que elimina la latencia distribuida y garantiza la coherencia transaccional. Esta decisión prioriza la simplicidad operativa y el *Time-to-Market* en la etapa actual, manteniendo la arquitectura preparada para una migración selectiva si el volumen futuro lo justifica. | # | Bounded Context | Responsabilidad principal | |---|------------------------|-------------------------------------------------------------------------------------------------------------| @@ -1612,26 +1726,28 @@ El sistema Reqs-AI está compuesto por los siguientes contenedores principales: | 4 | Billing & Subscription | Planes de suscripción, control de cuotas e integración con la pasarela de pagos. | | 5 | Integration Gateway | Exportación de historias aprobadas hacia las herramientas de gestión que el cliente ya utiliza. | -4. **Almacenamiento de Datos:** - * **Database:** Es la base de datos principal de Reqs-AI. Almacena toda la información del dominio. La elección de **PostgreSQL** con la extensión **pgvector** es una decisión estratégica crítica, ya que permite almacenar y consultar *embeddings* vectoriales, facilitando el procesamiento avanzado de IA (RAG) y las búsquedas semánticas. +4. **Almacenamiento de Datos (AWS RDS):** + * **Database:** Base de datos relacional administrada en **AWS RDS** con **PostgreSQL** y la extensión **pgvector**. La elección de pgvector es una decisión estratégica crítica que permite almacenar y consultar *embeddings* vectoriales directamente en la base de datos relacional, habilitando el motor RAG y las búsquedas semánticas sin necesidad de una base de datos vectorial separada. **Comunicación e Integración de Contenedores** -La arquitectura define un flujo de comunicación moderno y orientado a servicios: +La arquitectura define un flujo de comunicación diferenciado según el canal: -* **Comunicación Cliente-Servidor (Internet):** Tanto la aplicación móvil como la web interactúan inicialmente con el **CDN & Reverse Proxy (CloudFront)** a través de **HTTPS**. El proxy inverso sirve la Web App (Angular) y enruta las llamadas de datos hacia el **API Gateway**. Todo el tráfico utiliza conexiones seguras (REST y WebSockets para el streaming de audio). -* **Comunicación Interna:** La API Gateway enruta las llamadas procesadas hacia el *Reqs-AI Backend Application*. Internamente, los Bounded Contexts se comunican mediante eventos en memoria (Domain Events) y persisten su estado de manera síncrona en la base de datos compartida (PostgreSQL). -* **Integración con Sistemas Externos:** En lugar de centralizar todas las salidas, las integraciones están descentralizadas y asignadas al Bounded Context correspondiente que las necesita: - * **IAM** envía credenciales y alertas a través del **Email Service Provider**. - * **Billing & Subscription** procesa transacciones a través del **Payment Gateway**. - * **Requirement Discovery** envía los audios de las reuniones al **STT API** para convertirlos a texto, y delega la inferencia de inteligencia artificial al **LLM API** para la generación de Gherkin. - * **Integration Gateway** exporta finalmente las historias de usuario hacia la herramienta de gestión mediante la **Project Management API** (Jira). +* **Canal Web:** El navegador carga el SPA Angular desde **CloudFront** (activos estáticos cacheados en el Edge). Las llamadas de API del SPA viajan por CloudFront → API Gateway → Backend. +* **Canal Móvil:** La app Flutter (instalada desde App Store/Google Play) realiza llamadas HTTPS directamente la **API Gateway**, sin pasar por CloudFront, ya que no es una aplicación web servida desde un servidor. +* **Comunicación Interna:** La API Gateway enruta todas las peticiones hacia el contenedor del backend. Internamente, los Bounded Contexts se comunican mediante Domain Events en memoria y persisten en la base de datos compartida (AWS RDS PostgreSQL). +* **Integración con Sistemas Externos:** Las integraciones están descentralizadas, asignadas al Bounded Context que las necesita: + * **IAM** envía correos transaccionales vía **Email Service Provider**. + * **Billing & Subscription** procesa pagos vía **Payment Gateway**. + * **Workspace Management** vectoriza documentos y glosario vía **Embedding API**, y procesa el contenido de documentos para el RAG vía **LLM API**. + * **Requirement Discovery** transcribe audio vía **STT API**, vectoriza historias generadas vía **Embedding API** e infiere historias en Gherkin vía **LLM API**. + * **Integration Gateway** exporta historias aprobadas vía **Project Management API** (Jira, Trello, Linear). -### 4.3.4. Software Architecture Deployment Diagrams +### 4.3.4. Software Architecture Deployment Diagrams En esta sección se presenta el diagrama de despliegue, el cual ilustra cómo los contenedores de software de Reqs-AI se mapean a la infraestructura de la nube. Este diagrama detalla los nodos de ejecución, los entornos operativos y la topología de red, priorizando una arquitectura viable, escalable y optimizada en costos. - + **Nodos de Despliegue y Distribución de Componentes** @@ -1645,139 +1761,3922 @@ La infraestructura de despliegue se divide en los entornos de cliente, la red de Para garantizar baja latencia y alta seguridad antes de que el tráfico llegue a los servidores principales, se utilizan los nodos Edge de AWS distribuidos globalmente. * **Amazon CloudFront (CDN & Reverse Proxy):** Actúa como el primer punto de contacto (Proxy Inverso). Almacena en caché los archivos estáticos de la Web App en ubicaciones cercanas al usuario para cargas instantáneas, y enruta de forma segura y eficiente el tráfico dinámico hacia la región principal de AWS. -3. **Entorno de Nube - Procesamiento (Server-Side - AWS North America):** - La lógica de negocio se aloja en AWS North America (us-east-1, Virginia), elegida por su alta disponibilidad y ecosistema completo de servicios. - * **AWS API Gateway:** Recibe el tráfico dinámico enrutado desde CloudFront y funciona como el orquestador de las peticiones REST y WebSockets hacia el backend. - * **AWS Elastic Beanstalk:** Es el entorno PaaS (Platform as a Service) encargado de alojar el **Reqs-AI Backend Application**. Elastic Beanstalk abstrae la complejidad de la infraestructura, aprovisionando servidores EC2 subyacentes, autoescalado y monitoreo, permitiendo al equipo enfocarse únicamente en el código del runtime de Java. +3. **Entorno de Nube - Procesamiento (AWS North America — us-east-1, Virginia):** + La lógica de negocio se aloja en la región de AWS North America, elegida por su alta disponibilidad y ecosistema completo de servicios administrados. + * **AWS API Gateway:** Recibe el tráfico dinámico desde CloudFront (web) y directamente desde la app móvil, funcionando como orquestador de peticiones REST y WebSocket hacia el backend. + * **ECS Cluster (AWS ECS + Fargate):** El backend se despliega como un contenedor Docker en **AWS ECS con Fargate** (serverless containers). Fargate abstrae completamente la gestión de servidores EC2 subyacentes, provisionando cómputo bajo demanda con autoescalado automático. La task definition del ECS define dos contenedores en la misma unidad de ejecución: el **ReqsAI Backend Service** (Java 25 + Spring Boot 4) y el **Grafana Alloy** como sidecar de observabilidad. + * **Observability Server (AWS EC2 + Docker Compose):** Una instancia EC2 dedicada ejecuta el stack de observabilidad completo mediante Docker Compose: **Prometheus** (almacén de métricas, consultado con PromQL), **Loki** (agregación de logs, consultado con LogQL), **Tempo** (trazas distribuidas, consultado con TraceQL) y **Grafana** (dashboard unificado que visualiza las tres fuentes). Grafana Alloy, corriendo como sidecar en el ECS Cluster, colecta las métricas del endpoint `/actuator/prometheus`, logs del stdout del contenedor y trazas OTLP, enviándolos al servidor de observabilidad mediante push. -4. **Entorno de Nube - Persistencia (Database as a Service):** - * **Supabase Cloud (PostgreSQL):** Se delegó el almacenamiento a Supabase, una plataforma BaaS (Backend as a Service). Esta decisión permite aprovechar una base de datos PostgreSQL robusta, gestionada y con la extensión **pgvector** nativa (esencial para los *embeddings* y RAG de los requerimientos), reduciendo drásticamente la carga operativa y los costos. +4. **Entorno de Nube - Persistencia (AWS RDS):** + * **AWS RDS (PostgreSQL + pgvector):** La base de datos principal se gestiona completamente en **Amazon RDS**, el servicio de base de datos relacional administrado de AWS. Se utiliza **PostgreSQL** con la extensión **pgvector** habilitada, esencial para el almacenamiento de embeddings vectoriales que alimentan el motor RAG. RDS provee backups automáticos, failover multi-AZ y actualizaciones de parches sin downtime. **Comunicación e Interacción de Nodos** -* Las aplicaciones (Mobile y Web) se comunican vía internet mediante **HTTPS** con el **Amazon CloudFront** ubicado en el *Edge Location* más cercano. -* CloudFront sirve los recursos estáticos web directamente y enruta las solicitudes API hacia el **AWS API Gateway** en la región de AWS North America. -* La API Gateway enruta el tráfico internamente hacia el entorno de **AWS Elastic Beanstalk**, donde reside la lógica del Monolito Modular. -* El backend de Spring Boot se conecta de manera externa y segura hacia el clúster gestionado en **Supabase Cloud** para realizar operaciones transaccionales (*Reads and writes*) sobre la base de datos compartida. +* **App Web:** El navegador carga el SPA Angular desde **CloudFront** (Edge Location más cercano). Las llamadas de API del SPA viajan CloudFront → API Gateway → ECS Backend. +* **App Móvil:** La app Flutter instalada en el dispositivo del usuario realiza llamadas HTTPS **directamente la API Gateway**, sin pasar por CloudFront, ya que no es una aplicación web servida desde CDN. +* **Observabilidad:** Grafana Alloy (sidecar en ECS) colecta continuamente métricas, logs y trazas del backend y los envía al Observability Server en EC2. Grafana consulta Prometheus, Loki y Tempo para mostrar el estado del sistema en tiempo real. +* **Persistencia:** El backend se conecta a **AWS RDS** via JDBC/JPA para todas las operaciones transaccionales de los 5 Bounded Contexts. # Capítulo V: Tactical-Level Software Design -## 5.X. Bounded Context:
+
+### 6.1.1. General Style Guidelines
+
+Los lineamientos generales de estilo de Reqs-AI se enfocan en transmitir precisión, confianza y productividad. Al tratarse de una plataforma SaaS orientada a requisitos de software, la interfaz debe comunicar orden, seguridad y facilidad de uso. Por ello, se utiliza una composición minimalista, con tarjetas limpias, bordes suaves, sombras ligeras y una estructura modular que permite reconocer rápidamente cada sección del sistema.
+
+La paleta visual se apoya principalmente en tonos neutros, fondos claros y un azul principal para acciones relevantes. El azul se utiliza en botones primarios, enlaces, estados activos y elementos de navegación seleccionados. Los tonos grises se reservan para contenedores, bordes, textos secundarios y fondos de separación. Además, se incorporan colores semánticos para comunicar estados específicos: verde para acciones completadas, amarillo para advertencias, rojo para errores y un acento violeta o azul intenso para elementos relacionados con inteligencia artificial.
+
+
+
+A nivel tipográfico, se propone el uso de una familia sans serif moderna y legible para interfaces digitales. Los títulos deben tener mayor peso visual para diferenciar secciones principales, mientras que los textos descriptivos deben mantener un tamaño cómodo para lectura en pantallas. La jerarquía recomendada distingue entre títulos de página, subtítulos, nombres de módulos, cuerpo de texto, etiquetas, metadatos y mensajes de ayuda.
+
+
+
+Los componentes siguen criterios de consistencia. Los botones principales se reservan para acciones críticas como crear workspace, iniciar sesión en vivo, aprobar historia o conectar Jira. Los botones secundarios se utilizan para editar, cancelar, visualizar detalles o navegar entre estados. Los formularios deben mostrar etiquetas claras, placeholders descriptivos y mensajes de validación visibles cuando exista un error. Las tarjetas se utilizan para agrupar información de proyectos, sesiones, historias y métricas de uso.
+
+En cuanto a accesibilidad, se prioriza el contraste entre texto y fondo, el uso de etiquetas comprensibles, la persistencia de navegación global y la diferenciación visual de estados. Los elementos interactivos deben mantener tamaños adecuados para facilitar su uso en escritorio y pantallas reducidas. Asimismo, los mensajes de error deben ser específicos para que el usuario pueda corregir su acción sin depender de interpretación técnica.
+
+### 6.1.2. Web, Mobile & Devices Style Guidelines
+
+Para la web application, Reqs-AI utiliza una estructura de aplicación empresarial basada en tres zonas principales: sidebar lateral, topbar superior y área central de contenido. La sidebar permite acceder a módulos como Dashboard, Projects, Sessions, User Stories, Integrations, Billing y Settings. La topbar concentra el selector de workspace, la búsqueda global, acciones rápidas y el menú de perfil. El área central se adapta al módulo activo mediante tablas, tarjetas, modales y paneles laterales.
+
+
+
+En escritorio, la aplicación debe aprovechar el ancho disponible para mostrar información densa, como listados de sesiones, tableros de historias, métricas de consumo, configuración de integraciones y paneles de revisión. En estos casos, se recomienda usar layouts de dos columnas o paneles laterales para evitar abrir demasiadas pantallas nuevas. Por ejemplo, una historia de usuario puede listarse en el tablero y abrirse en un drawer lateral para revisar criterios Gherkin, confianza de IA y acciones de aprobación.
+
+En dispositivos móviles, la experiencia debe simplificarse priorizando consultas rápidas, revisión de estados y acciones puntuales. La navegación lateral puede transformarse en menú colapsable, la topbar debe reducirse a búsqueda, perfil y acción principal, y las tablas deben convertirse en tarjetas verticales. Esto permite mantener la coherencia visual sin sobrecargar pantallas pequeñas.
+
+Para dispositivos externos o escenarios de grabación, la interfaz debe reforzar estados claros: sesión activa, sesión pausada, procesamiento en curso, historia generada, historia pendiente de revisión y exportación completada. Estos estados son importantes porque Reqs-AI trabaja con procesos en vivo y procesamiento asistido por IA, por lo que el usuario necesita retroalimentación inmediata para confiar en el sistema.
+
+## 6.2. Information Architecture
+
+La arquitectura de información de Reqs-AI organiza los contenidos de la plataforma en función del flujo real del usuario: acceder a la cuenta, crear o seleccionar un workspace, configurar proyectos, iniciar sesiones de descubrimiento, revisar historias generadas por IA, exportarlas hacia herramientas externas y administrar la organización. Esta organización permite que la experiencia sea coherente con el proceso de levantamiento de requisitos y no solo con una agrupación técnica de funcionalidades.
+
+La estructura principal se divide en módulos globales: Authentication, Workspace, Dashboard, Projects, Discovery Sessions, User Stories, Integrations, Billing y Settings. Cada módulo agrupa acciones relacionadas y mantiene una nomenclatura consistente para reducir ambigüedad. De esta forma, el usuario puede comprender dónde iniciar una tarea, dónde revisar resultados y dónde configurar aspectos administrativos.
+
+
+
+### 6.2.2. Labeling Systems
+
+El sistema de etiquetado de Reqs-AI utiliza términos breves, consistentes y orientados al lenguaje del dominio. Las etiquetas principales se mantienen en inglés porque el producto trabaja con conceptos habituales del entorno SaaS y de gestión ágil, como Workspace, Projects, Sessions, User Stories, Integrations y Billing. Sin embargo, las descripciones internas pueden adaptarse al idioma del usuario cuando se requiera internacionalización.
+
+Las etiquetas de navegación deben indicar claramente el contenido del módulo. “Projects” agrupa iniciativas por cliente o producto; “Sessions” representa reuniones procesadas o en vivo; “User Stories” contiene historias generadas por IA; “Integrations” centraliza conexiones con Jira u otras herramientas; “Billing” administra plan y consumo; y “Settings” concentra la configuración organizacional y de equipo.
+
+
+
+Para las acciones, se recomienda utilizar verbos directos que indiquen intención: Create Workspace, Start Live Session, Create Project, Approve Story, Export to Jira, Invite Member y Connect Integration. Para los estados, se deben usar etiquetas que permitan comprender el avance del flujo: Draft, Active, Processing, Pending Review, Approved, Exported, Failed y Archived.
+
+Este sistema de etiquetado ayuda a reducir la carga cognitiva porque el usuario puede asociar rápidamente cada término con una tarea concreta del proceso de levantamiento, revisión y transferencia de requisitos.
+
+### 6.2.3. Searching Systems
+
+El sistema de búsqueda de Reqs-AI debe facilitar la localización rápida de proyectos, sesiones, historias de usuario, miembros e integraciones. La búsqueda principal se ubica en la topbar para estar disponible desde cualquier módulo de la aplicación. Esto permite que el usuario no dependa únicamente de la navegación lateral cuando necesita encontrar información específica.
+
+
+
+La búsqueda global debe aceptar palabras clave relacionadas con nombres de proyectos, títulos de sesiones, identificadores de historias, estados de revisión, miembros del equipo y referencias externas como tickets de Jira. Además, cada módulo debe contar con filtros contextuales. En Projects, los filtros pueden ser estados, cliente o fecha de actualización. En Sessions, los filtros pueden ser proyecto, estado de procesamiento o fecha. En User Stories, los filtros pueden ser estados, prioridad, confianza de IA, similitud detectada o exportación.
+
+Para mejorar la experiencia, los resultados deben mostrar información resumida: nombre del elemento, tipo, estado, fecha de actualización y acción rápida. Esto permite que el usuario decida si desea abrir el detalle, editar, aprobar o exportar sin ingresar a múltiples pantallas.
+
+### 6.2.4. SEO Tags and Meta Tags
+
+Los SEO Tags y Meta Tags se aplican principalmente a la landing page pública de Reqs-AI, ya que la aplicación interna se encuentra protegida por autenticación y no debe indexarse en buscadores. La landing page debe estar optimizada para comunicar la propuesta de valor del producto, captar leads y explicar cómo la plataforma convierte reuniones de discovery en historias de usuario estructuradas con apoyo de IA.
+
+
+
+Se propone utilizar un título claro y orientado al beneficio, una descripción breve con palabras clave relacionadas con el dominio y etiquetas Open Graph para mejorar la presentación cuando el enlace sea compartido en redes sociales o canales profesionales. También se recomienda definir una imagen de previsualización, metadatos de idioma, autor, viewport responsive y robots index/follow para las páginas públicas.
+
+Ejemplo de metadatos recomendados:
+
+```html
+
+
+**Login Screen Wireframe**
+
+**Descripción:** Muestra la estructura base del inicio de sesión. Define la jerarquía de campos, acciones principales y acceso alternativo para que el usuario registrado ingrese a su workspace.
+
+
+
+**Signup Screen Wireframe**
+
+**Descripción:** Presenta la composición inicial del formulario de registro. Permite validar la disposición de campos, botones y enlaces necesarios para crear una cuenta en la plataforma.
+
+
+
+**Onboarding y creación de workspace**
+
+**Dashboard Empty State Before Workspace Wireframe**
+
+**Descripción:** Expone el estado vacío del dashboard cuando el usuario aún no tiene un workspace. Este wireframe válida el mensaje guía y el llamado a la acción para iniciar el onboarding.
+
+
+
+**Workspace Creation Modal Empty Fields Wireframe**
+
+**Descripción:** Muestra el modal de creación de workspace sin datos ingresados. Sirve para validar la estructura del formulario y los campos mínimos requeridos para crear una organización.
+
+
+
+**Workspace Creation Validation Errors Wireframe**
+
+**Descripción:** Representa los mensajes de validación del formulario. Permite comprobar cómo se informan errores cuando faltan datos obligatorios o cuando la información no cumple las reglas.
+
+
+
+**Workspace Company Type Dropdown Open Wireframe**
+
+**Descripción:** Muestra el selector de tipo de compañía abierto. Este estado permite validar cómo el usuario escoge el perfil de organización para contextualizar el uso inicial de Reqs-AI.
+
+
+
+**Workspace Team Size Dropdown Open Wireframe**
+
+**Descripción:** Presenta el selector de tamaño de equipo. Este wireframe ayuda a validar la captura de información necesaria para adaptar la experiencia del workspace.
+
+
+
+**Workspace Creation Form Filled Wireframe**
+
+**Descripción:** Muestra el formulario de workspace completado. Permite revisar cómo se presentan los datos antes de confirmar la creación del espacio de trabajo.
+
+
+
+**Workspace Use Case Selection State Wireframe**
+
+**Descripción:** Representa la selección del caso de uso principal del workspace. Permite validar la organización visual de opciones vinculadas a discovery, requisitos, documentación e integración.
+
+
+
+**Workspace Creation Loading State Wireframe**
+
+**Descripción:** Muestra el estado de carga durante la creación del workspace. Su objetivo es validar la retroalimentación visual mientras el sistema configura el entorno.
+
+
+
+**Workspace Created Success Modal Wireframe**
+
+**Descripción:** Presenta la confirmación de creación exitosa del workspace. Este wireframe válida el cierre del onboarding y la transición hacia el dashboard principal.
+
+
+
+**Dashboard y navegación principal**
+
+**Workspace Dashboard Home Wireframe**
+
+**Descripción:** Muestra la estructura general del dashboard con navegación lateral, barra superior, métricas y accesos rápidos. Permite validar la organización inicial de la aplicación interna.
+
+
+
+**Workspace Switcher Menu Open Wireframe**
+
+**Descripción:** Representa el selector de workspace abierto. Permite validar el cambio de contexto entre organizaciones o espacios de trabajo sin perder consistencia en la navegación.
+
+
+
+**User Profile Menu Open Wireframe**
+
+**Descripción:** Muestra el menú de perfil del usuario. Válida la ubicación de opciones personales, configuración de cuenta y cierre de sesión dentro de la interfaz global.
+
+
+
+**Gestión de proyectos**
+
+**Projects Page Overview Wireframe**
+
+**Descripción:** Presenta la vista general de proyectos. Permite validar la organización de listados, estados, acciones y acceso a la creación de nuevos proyectos dentro del workspace.
+
+
+
+**Create New Project Modal Wireframe**
+
+**Descripción:** Muestra el modal para crear un proyecto. Permite validar la captura de información inicial del proyecto y la selección de plantilla o configuración base.
+
+
+
+**Sesiones de descubrimiento**
+
+**Discovery Sessions Page Wireframe**
+
+**Descripción:** Representa la vista de sesiones de descubrimiento. Sirve para validar la tabla de sesiones, filtros, estados y acciones asociadas al procesamiento de reuniones.
+
+
+
+**Live Session Configuration Modal Wireframe**
+
+**Descripción:** Muestra la configuración previa para iniciar una sesión en vivo. Permite validar campos, permisos y opciones necesarias para activar la captura asistida por IA.
+
+
+
+**Historias de usuario generadas por IA**
+
+**User Stories Review Board Wireframe**
+
+**Descripción:** Presenta el tablero de historias generadas por IA. Permite validar la disposición de tarjetas, métricas, estados de revisión y acciones de aprobación.
+
+
+
+**User Story Detail Review Drawer Wireframe**
+
+**Descripción:** Muestra el detalle de una historia de usuario, incluyendo criterios de aceptación y revisión. Sirve para validar el panel lateral de edición, confianza y aprobación.
+
+
+
+**Integraciones externas**
+
+**Integrations Page Jira Connection Wireframe**
+
+**Descripción:** Representa la página de integraciones externas. Válida la ubicación de la conexión con Jira, el estado de integración y las acciones de configuración.
+
+
+
+**Jira Connection Modal Wireframe**
+
+**Descripción:** Muestra el asistente de conexión con Jira. Permite validar el flujo de autenticación, mapeo de proyectos y configuración de sincronización con Atlassian.
+
+
+
+**Billing y configuración**
+
+**Billing Subscription Page Wireframe**
+
+**Descripción:** Presenta la página de suscripción y facturación. Sirve para validar la visualización del plan activo, consumo, límites y opciones de actualización.
+
+
+
+**Settings Workspace Configuration Wireframe**
+
+**Descripción:** Muestra la configuración general del workspace. Permite validar la organización de secciones relacionadas con datos, preferencias, plan y controles administrativos.
+
+
+
+**Settings Team Members Management Wireframe**
+
+**Descripción:** Representa la subsección de miembros o perfil dentro de settings. Permite validar la gestión de usuarios, roles, invitaciones y control de acceso al workspace.
+
+
+
+**Navigation Consistency Check Frame Wireframe**
+
+**Descripción:** Evidencia la consistencia de navegación entre pantallas. Permite comprobar que sidebar, barra superior, perfil y acciones principales se mantienen uniformes.
+
+
+
+**Variantes complementarias del onboarding**
+
+**Workspace Creation Form Filled Alternative Wireframe**
+
+**Descripción:** Presenta una variante del formulario de workspace completado. Se usa para contrastar distribución de campos y confirmar que el flujo mantiene claridad antes de guardar.
+
+
+
+**Workspace Settings Company Type Dropdown Wireframe**
+
+**Descripción:** Muestra una variante del selector de tipo de empresa dentro del flujo de configuración. Permite validar la selección del contexto organizacional.
+
+
+
+**Workspace Use Case Selection Modal Wireframe**
+
+**Descripción:** Representa una versión alternativa del modal de selección de caso de uso. Ayuda a validar la lectura de opciones y la continuidad del onboarding.
+
+
+
+**Workspace Initialization Loading Modal Wireframe**
+
+**Descripción:** Muestra una variante del estado de inicialización del workspace. Permite validar la comunicación de progreso mientras se preparan recursos internos.
+
+
+
+**Workspace Created Success Details Wireframe**
+
+**Descripción:** Presenta una variante del mensaje de éxito con mayor detalle. Sirve para validar el cierre del flujo y la confirmación de elementos creados dentro del workspace.
+
+
+
+**Mobile Application Wireframes**
+
+Los wireframes de la aplicación móvil representan la versión de baja fidelidad de Reqs-AI en formato adaptado para dispositivos móviles. Su objetivo es validar la estructura, navegación y flujos principales dentro de una interfaz táctil y de menor tamaño, manteniendo la consistencia funcional con la versión web.
+
+**Login Screen**
+
+**Descripción:** Esta pantalla gestiona el acceso seguro a la aplicación móvil aplicando el principio de simplicidad y reducción de la carga cognitiva mediante un diseño de una sola columna centralizada. El flujo prioriza la accesibilidad táctil ubicando los campos de entrada de texto (Email y Password) y el botón principal de acción (CTA) con dimensiones óptimas para evitar errores de pulsación, mientras que la arquitectura de información organiza los elementos de forma secuencial de arriba hacia abajo, garantizando una navegación intuitiva y directa desde el primer punto de contacto.
+
+
+
+**Dashboard Screen**
+
+**Descripción:** Esta pantalla actúa como el centro de control principal de la aplicación, estructurando la arquitectura de información mediante un flujo completamente vertical y modular para pantallas compactas. En la parte superior se integran tarjetas de métricas numéricas con barras de progreso que aplican el principio de consistencia visual para una asimilación inmediata del estado del proyecto, seguidas de una lista secuencial de elementos (Lorem Ipsum List) con contenedores amplios que mitigan el esfuerzo cognitivo. Para asegurar el diseño inclusivo y la accesibilidad táctil en movilidad, la pantalla incorpora un menú de navegación inferior (Bottom Navigation Bar) con etiquetas claras y un botón de acción flotante (FAB) estratégicamente posicionado en la esquina inferior derecha para facilitar el alcance con el pulgar.
+
+
+
+**Settings & Profile Screen**
+
+**Descripción:** Esta vista gestiona la configuración de usuario agrupando la información en contenedores independientes que respetan el principio de proximidad y consistencia. La arquitectura de información distribuye verticalmente el perfil del usuario, el resumen de cuenta, las preferencias de apariencia, la seguridad, las notificaciones y las herramientas conectadas (como Jira o Trello); garantizando un diseño inclusivo mediante botones de acción grandes, etiquetas explícitas y un menú de navegación inferior consistente que facilita el control ergonómico con una sola mano.
+
+
+
+**Live Assistant Screen**
+
+**Descripción:** Esta pantalla representa el núcleo interactivo en tiempo real de la solución móvil, estructurando un flujo de conversación dinámico optimizado para la escucha activa en juntas de trabajo. La arquitectura de información utiliza un diseño cronológico asimétrico de burbujas de diálogo que diferencia claramente las intervenciones de los participantes (Stakeholder) del procesamiento del sistema (Assistant), reduciendo drásticamente la sobrecarga cognitiva.
+
+Cumpliendo con los principios de diseño inclusivo y accesibilidad táctil en movilidad, la sección inferior integra un carrusel horizontal interactivo de sugerencias estratégicas inteligentes (AI Suggestions) con botones de acción rápida de gran tamaño (Use Suggestion), acompañados por una barra de herramientas de control ergonómico inferior de alta accesibilidad para operaciones inmediatas como silenciar, tomar notas o revisar artefactos generados.
+
+
+
+**Review & Export Screen**
+
+**Descripción:** Esta pantalla gestiona la revisión exhaustiva y exportación de artefactos mediante una arquitectura de información jerárquica y modular adaptada para entornos móviles. La interfaz implementa un sistema de pestañas superiores (Tabs) para alternar rápidamente entre categorías, seguido de tarjetas con listas de verificación individuales (Checkboxes) que permiten al usuario seleccionar historias de usuario específicas que despliegan su estructura sintáctica detallada. Para mitigar la fricción y asegurar un diseño inclusivo en movilidad, la pantalla superpone un panel emergente inferior (Bottom Sheet) de alta accesibilidad táctil que organiza las opciones de integración (como Jira, Azure, GitHub y Markdown) en una cuadrícula simétrica de botones amplios y fáciles de pulsar con una sola mano, agilizando el flujo de sincronización hacia repositorios externos de gestión.
+
+
+
+**Projects Archive Screen**
+
+**Descripción:** Esta pantalla gestiona el catálogo de proyectos activos e históricos estructurando la arquitectura de información mediante un patrón jerárquico que facilita la búsqueda y el filtrado rápido en dispositivos móviles. En la parte superior se integra una barra de búsqueda (Search Input) seguida de píldoras de filtrado por estado (All, In Progress, Completed) que respetan el principio de consistencia técnica y proximidad, permitiendo refinar los resultados con un solo toque. El cuerpo principal organiza los proyectos en tarjetas modulares individuales que optimizan la legibilidad tipográfica; cada tarjeta agrupa de forma clara el estado del proyecto, el título, el cliente, la cantidad de historias de usuario y una barra de progreso porcentual. Finalmente, para garantizar el diseño inclusivo y la ergonomía táctil en movilidad, se incluye un botón de acción flotante (FAB) para añadir nuevos proyectos y una barra de navegación inferior (Bottom Navigation Bar) que asegura un control cómodo y libre de fricciones con una sola mano.
+
+
+
+**Project Settings Screen**
+
+**Descripción:** Esta vista gestiona los parámetros específicos de un proyecto individual organizando la arquitectura de información mediante una estructura puramente vertical que agrupa las configuraciones generales, el backend de sincronización, la gestión de miembros del equipo y los tokens de acceso. El diseño prioriza la accesibilidad y el control inclusivo en movilidad al implementar controles deslizantes (Switches) y menús desplegables con amplias áreas de activación táctil, optimizando la interacción con una sola mano y reduciendo la fatiga cognitiva del usuario.
+
+
+
+**Session History Screen**
+
+**Descripción:** Esta pantalla organiza el historial cronológico de las sesiones de elicitación mediante una línea de tiempo vertical dividida por bloques temporales (Today, Yesterday) que reduce la carga cognitiva del usuario. La interfaz aplica los principios de jerarquía visual y diseño inclusivo al estructurar cada sesión en tarjetas independientes con identificadores únicos (#ID), etiquetas de estado y botones de acción de gran tamaño (View Transcript o Resume Session), permitiendo un acceso y control táctil inmediato en movilidad.
+
+
+
+**Integrations Directory Screen**
+
+**Descripción:** Esta pantalla centraliza las herramientas externas conectadas organizando la arquitectura de información mediante categorías temáticas horizontales (Project Management, Communication) que simplifican el descubrimiento y la navegación en la interfaz móvil. El diseño fomenta el diseño inclusivo al implementar tarjetas independientes con botones de gran tamaño para conectar (Connect) o gestionar (Manage), complementado con un buscador superior accesible para mitigar el esfuerzo cognitivo y agilizar las tareas táctiles en movilidad.
+
+
+
+**Billing & Subscription Screen**
+
+**Descripción:** Esta pantalla gestiona los detalles de facturación de la aplicación organizando la arquitectura de información de manera lineal y segregada mediante bloques de historial de transacciones, métodos de pago vinculados y tarjetas de suscripción activa. El diseño refuerza los principios de diseño inclusivo al incorporar botones de acción prominentes para la cancelación o actualización de planes, reduciendo la fricción en transacciones críticas y garantizando una interacción táctil transparente, ergonómica y libre de errores en movilidad.
+
+
+
+### 6.4.2. Applications Wireflow Diagrams
+
+**Web Application Wireflow Diagrams**
+
+Los wireflows de la aplicación web de Reqs-AI representan la conexión entre pantallas y estados interactivos del sistema. A diferencia de los wireframes, estos diagramas no solo muestran la estructura visual, sino también cómo el usuario avanza de una acción a otra dentro del flujo: autenticación, creación de workspace, navegación principal, gestión de proyectos, sesiones de descubrimiento, revisión de historias generadas por IA, integraciones, facturación y configuración del equipo.
+
+Cada wireflow incluye una flecha que indica la transición principal entre pantallas, permitiendo validar la continuidad de la experiencia, la coherencia de navegación y la relación entre módulos de la web application.
+
+**Flujo de autenticación y acceso**
+
+**Registro hacia inicio de sesión**
+
+**Descripción:** El flujo muestra cómo un visitante que se encuentra en la pantalla de registro puede volver al inicio de sesión mediante el enlace de acceso. Esta transición valida la navegación bidireccional entre autenticación y creación de cuenta.
+
+
+
+**Inicio de sesión hacia autenticación con Google**
+
+**Descripción:** El flujo evidencia que el usuario puede seleccionar la opción de continuar con Google desde el login. Luego es redirigido al selector de cuenta externo, reduciendo fricción en el acceso.
+
+
+
+**Registro hacia autenticación con Google**
+
+**Descripción:** El flujo representa la alternativa de crear una cuenta usando Google desde la pantalla de registro. Permite validar que el onboarding también soporta autenticación federada.
+
+
+
+**Inicio de sesión hacia confirmación de workspace creado**
+
+**Descripción:** El flujo muestra que, luego de autenticarse correctamente, el usuario puede ser llevado al estado de confirmación del workspace. Este paso cierra el acceso inicial y conecta con las acciones posteriores del entorno de trabajo.
+
+
+
+**Flujo de onboarding y creación de workspace**
+
+**Confirmación de workspace hacia carga de configuración**
+
+**Descripción:** El flujo inicia en el modal de workspace creado y continúa hacia un estado de construcción del entorno. Válida que el sistema comunica el progreso mientras prepara módulos, contexto de IA y configuración inicial.
+
+
+
+**Workspace creado hacia configuración de tipo de empresa**
+
+**Descripción:** El flujo permite pasar desde el modal de éxito a la configuración del workspace. Se evidencia la selección del tipo de compañía para adaptar la experiencia al contexto de la organización.
+
+
+
+**Tipo de empresa hacia selección de caso de uso**
+
+**Descripción:** El flujo muestra cómo, después de seleccionar el tipo de organización, el usuario continúa hacia la definición del caso de uso principal. Esta transición ayuda a personalizar el workspace según el objetivo de trabajo.
+
+
+
+**Selección de caso de uso hacia formulario de workspace**
+
+**Descripción:** El flujo representa el paso desde la selección de usos del workspace hacia el formulario de creación. Permite validar que el usuario puede completar la configuración general luego de definir su enfoque de trabajo.
+
+
+
+**Formulario completo hacia validación de nuevo workspace**
+
+**Descripción:** El flujo muestra la acción de crear workspace desde un formulario completado y su transición a una variante de validación. Evidencia cómo la interfaz comunica errores o campos requeridos antes de guardar.
+
+
+
+**Estado vacío hacia creación de workspace**
+
+**Descripción:** El flujo parte del dashboard sin workspace y lleva al modal de creación. Esta transición valida el onboarding principal cuando el usuario aún no tiene un espacio activo.
+
+
+
+**Crear workspace hacia desplegable de tipo de compañía**
+
+**Descripción:** El flujo muestra la apertura del selector de tipo de compañía dentro del formulario. Permite comprobar que el usuario puede clasificar su organización antes de finalizar la creación.
+
+
+
+**Tipo de compañía hacía caso de uso principal**
+
+**Descripción:** El flujo evidencia que, al completar la información organizacional, el usuario puede definir el propósito principal del workspace. Esta selección orienta el uso de Reqs-AI hacia requisitos, discovery o planificación.
+
+
+
+**Tamaño de equipo hacia selección de usos principales**
+
+**Descripción:** El flujo muestra la selección del tamaño del equipo y su avance hacia la pantalla de casos de uso. Permite validar que el onboarding recopila datos de escala y preferencias funcionales.
+
+
+
+**Progreso de creación hacia workspace creado**
+
+**Descripción:** El flujo representa la transición desde el estado de creación en progreso hasta la confirmación exitosa. Válida que el usuario recibe retroalimentación clara cuando el espacio termina de configurarse.
+
+
+
+**Workspace creado hacia página principal**
+
+**Descripción:** El flujo muestra cómo el usuario pasa desde el modal de éxito hacia el home del workspace. Esta transición permite iniciar la gestión de proyectos, sesiones e insights desde el dashboard.
+
+
+
+**Flujo de navegación principal e historias de usuario**
+
+**Home del workspace hacia historias de usuario**
+
+**Descripción:** El flujo evidencia la navegación desde el dashboard principal hacia el módulo de User Stories. Permite validar el acceso al backlog generado por IA desde el menú lateral.
+
+
+
+**Listado de historias hacia panel de revisión**
+
+**Descripción:** El flujo muestra cómo una historia del listado se abre en un drawer de revisión. Allí se visualizan estado, prioridad, confianza de IA, descripción y criterios Gherkin para su aprobación.
+
+
+
+**Selector de workspace hacia menú de perfil**
+
+**Descripción:** El flujo evidencia dos componentes globales de navegación: el selector de workspace y el menú de perfil. Válida que el usuario puede cambiar contexto y acceder a opciones personales desde la cabecera.
+
+
+
+**Flujo de proyectos y sesiones de descubrimiento**
+
+**Selector de workspace hacía proyectos**
+
+**Descripción:** El flujo muestra la transición desde la navegación global hacia la página de proyectos. Permite comprobar que el usuario puede ubicarse en un workspace y administrar sus iniciativas.
+
+
+
+**Proyectos hacia creación de nuevo proyecto**
+
+**Descripción:** El flujo parte del listado de proyectos y abre el modal de creación. Permite validar la captura del nombre, descripción, plantilla y visibilidad del proyecto.
+
+
+
+**Menú de perfil hacia sesiones**
+
+**Descripción:** El flujo muestra la navegación hacia el módulo de Sessions desde la estructura interna de la aplicación. Permite validar la consulta de reuniones procesadas, métricas y acciones disponibles.
+
+
+
+**Sesiones hacia vista de discovery sessions**
+
+**Descripción:** El flujo representa el cambio desde la vista completa de sesiones hacia una vista resumida de discovery sessions. Permite revisar métricas, sesiones recientes y estado de procesamiento.
+
+
+
+**Discovery sessions hacia inicio de sesión en vivo**
+
+**Descripción:** El flujo muestra cómo el usuario abre el modal para iniciar una sesión de descubrimiento en vivo. Se configuran título, proyecto asociado, modo de facilitación y opciones de captura antes de lanzar la sesión.
+
+
+
+**Sesiones hacia integraciones**
+
+**Descripción:** El flujo evidencia la navegación desde sesiones hacia el módulo de integraciones. Permite conectar los resultados del levantamiento con herramientas externas como Jira, Confluence, GitHub, Slack o Miro.
+
+
+
+**Flujo de integraciones, billing y configuración**
+
+**Integraciones hacia conexión con Jira**
+
+**Descripción:** El flujo muestra cómo el usuario inicia la configuración de Jira desde la página de integraciones. El modal guía la autenticación, la conexión del sitio Atlassian y la preparación del mapeo.
+
+
+
+**Billing hacia configuración del workspace**
+
+**Descripción:** El flujo conecta la página de facturación con settings. Permite validar que el usuario puede revisar su plan, consumo y método de pago, y luego administrar configuración organizacional.
+
+
+
+**Settings hacia gestión de equipo**
+
+**Descripción:** El flujo muestra la navegación desde la configuración general hacia Team Management. Permite administrar miembros, invitaciones, roles, permisos y alertas del equipo.
+
+
+
+**Gestión de equipo hacia home con notificaciones**
+
+**Descripción:** El flujo evidencia el retorno desde Team Management hacia el dashboard principal, donde se despliega el panel de notificaciones. Permite validar la continuidad de navegación y comunicación de eventos del sistema.
+
+
+
+**Mobile Application Wireflow Diagrams**
+
+**Autenticación de usuario y gestión de perfil**
+
+**Descripción:** Este Wireflow detalla el flujo secuencial orientado al objetivo del usuario de iniciar sesión de forma segura y navegar de inmediato hacia la gestión de su cuenta. El diagrama mapea la transición interactiva desde la pantalla de Login centralizada hasta la vista de Settings & Profile, evidenciando la persistencia de la arquitectura de información y la consistencia del menú de navegación inferior durante el desplazamiento ergonómico en la aplicación móvil.
+
+
+
+**Navegación del Dashboard a Live Assistant**
+
+**Descripción:** Este Wireflow ilustra el flujo interactivo diseñado para cumplir con el objetivo del usuario de iniciar o acceder rápidamente a una sesión de elicitación de requerimientos en tiempo real. El diagrama define la transición directa desde el Dashboard principal mediante la barra de navegación inferior hacia la pantalla del Live Assistant, asegurando que el analista pueda monitorear la transcripción y recibir sugerencias inteligentes de la IA de manera inmediata y sin fricciones de navegación.
+
+
+
+**Navegación del Dashboard a Review & Export**
+
+**Descripción:** Este Wireflow traza el camino interactivo enfocado en el objetivo del usuario de examinar, validar y exportar los requerimientos generados hacia repositorios externos. El diagrama mapea la navegación desde la vista principal del Dashboard hacia la pantalla de Review & Export, ilustrando cómo la interfaz despliega de forma adaptativa el menú emergente inferior (Bottom Sheet) para facilitar la sincronización táctil con herramientas de gestión de proyectos sin perder el contexto de la aplicación móvil.
+
+
+
+**Gestión Integral de Proyectos y Requerimientos**
+
+**Descripción:** Este Wireflow mapea el flujo interactivo de extremo a extremo diseñado para que el analista administre la configuración y los artefactos de un proyecto. El diagrama detalla la ruta secuencial que inicia en el Dashboard, transiciona por el catálogo de Projects Archive mediante la barra de navegación, ingresa a las configuraciones detalladas en Project Settings y culmina en la vista de Project User Stories, demostrando cómo se mantiene la jerarquía visual y la consistencia en el control de estados críticos a través de la aplicación móvil.
+
+
+
+**Navegación de Historias de Usuario a Historial, Integraciones y Facturación**
+
+**Descripción:** Este Wireflow traza el flujo transversal que permite al analista navegar fluidamente entre el control operativo y administrativo del sistema. El diagrama detalla la transición secuencial iniciada en la vista de Project User Stories, pasando secuencialmente a través del menú de navegación inferior hacia Session History para auditar transcripciones previas, luego hacia el Integrations Directory para conectar servicios de comunicación externos, y culminando directamente en Billing & Subscription para la gestión financiera de la cuenta móvil.
+
+
+
+### 6.4.2. Applications Mock-ups
+
+**Web Application Mock-ups**
+
+Los siguientes mock-ups presentan la versión de alta fidelidad de la aplicación web de Reqs-AI. La secuencia evidencia el recorrido principal del usuario dentro de la plataforma: autenticación, creación del workspace, navegación inicial, gestión de proyectos, sesiones de descubrimiento, revisión de historias generadas por IA, integraciones, facturación y configuración del equipo.
+
+**Autenticación y acceso**
+
+**Google Auth External Authorization**
+
+**Descripción:** Esta pantalla representa el flujo de autorización externa mediante Google. Permite evidenciar que Reqs-AI contempla un acceso rápido y seguro usando una cuenta existente, reduciendo la fricción del registro manual.
+
+
+
+**Login Screen**
+
+**Descripción:** Este mock-up muestra la pantalla de inicio de sesión de Reqs-AI. Aquí el usuario ingresa sus credenciales para acceder a sus proyectos, sesiones e historial dentro de la organización activa.
+
+
+
+**Signup Screen**
+
+**Descripción:** Esta pantalla representa el registro de una nueva cuenta. El formulario permite que un visitante se convierta en usuario de la plataforma para posteriormente crear o asociarse a un workspace.
+
+
+
+**Onboarding y creación de workspace**
+
+**Dashboard Empty State Before Workspace**
+
+**Descripción:** Este mock-up muestra el estado inicial del dashboard cuando el usuario aún no ha creado ningún workspace. Funciona como punto de onboarding y guía al usuario hacia la creación de su primer espacio de trabajo.
+
+
+
+**Workspace Creation Modal Empty Fields**
+
+**Descripción:** Esta pantalla presenta la modal inicial de creación de workspace con los campos vacíos. Su propósito es capturar los datos básicos de la organización o equipo que usará Reqs-AI.
+
+
+
+**Workspace Creation Validation Errors**
+
+**Descripción:** Este mock-up evidencia las validaciones del formulario de creación de workspace. La interfaz informa al usuario cuando faltan campos obligatorios o cuando la información ingresada no cumple las reglas esperadas.
+
+
+
+**Workspace Creation Company Type Dropdown Open**
+
+**Descripción:** Esta pantalla muestra el selector desplegable para elegir el tipo de empresa u organización. Este dato ayuda a contextualizar el uso de Reqs-AI según el perfil del equipo.
+
+
+
+**Workspace Creation Form Filled Private Visibility**
+
+**Descripción:** Este mock-up representa el formulario de workspace completado, incluyendo la configuración de visibilidad privada. Permite revisar la información antes de confirmar la creación del entorno.
+
+
+
+**Workspace Creation Team Size Dropdown Open**
+
+**Descripción:** Esta pantalla muestra el selector de tamaño del equipo. La selección permite adaptar la experiencia inicial y las recomendaciones del sistema según la cantidad de miembros del workspace.
+
+
+
+**Workspace Settings Company Type Dropdown Open**
+
+**Descripción:** Este mock-up representa un estado de configuración donde se puede revisar o ajustar el tipo de organización. Refuerza que los datos del workspace pueden actualizarse según la realidad del equipo.
+
+
+
+**Workspace Onboarding Use Case Selection State**
+
+**Descripción:** Esta pantalla muestra la selección del caso de uso principal del workspace. Permite orientar la plataforma hacia discovery, levantamiento de requisitos, generación de historias o integración con herramientas ágiles.
+
+
+
+**Workspace Use Case Selection Modal**
+
+**Descripción:** Este mock-up presenta el modal donde el usuario define el enfoque inicial de uso de Reqs-AI. Esta decisión ayuda a personalizar el onboarding y las siguientes acciones dentro de la plataforma.
+
+
+
+**Workspace Setup Summary Form Filled**
+
+**Descripción:** Esta pantalla funciona como resumen previo a la creación definitiva del workspace. El usuario puede validar los datos ingresados antes de confirmar el espacio de trabajo.
+
+
+
+**Workspace Creation Loading State**
+
+**Descripción:** Este mock-up muestra el estado de carga después de confirmar la creación del workspace. Comunica que el sistema está procesando la solicitud y evita acciones repetidas.
+
+
+
+**Workspace Creation Progress Loading State**
+
+**Descripción:** Esta pantalla representa un estado de progreso durante la creación del workspace. Muestra que el sistema está configurando el entorno, preparando datos iniciales y habilitando el acceso.
+
+
+
+**Workspace Created Success Modal**
+
+**Descripción:** Este mock-up evidencia la confirmación de creación exitosa del workspace. La interfaz informa que el espacio ya está listo y permite continuar hacia el dashboard principal.
+
+
+
+**Workspace Created Success Details Modal**
+
+**Descripción:** Esta pantalla complementa el mensaje de éxito con detalles del workspace creado. Refuerza el cierre del flujo de onboarding y da claridad sobre el nuevo entorno de trabajo.
+
+
+
+**Dashboard y navegación principal**
+
+**Workspace Dashboard Home**
+
+**Descripción:** Este mock-up muestra el dashboard principal luego de crear el workspace. Presenta una vista general de actividad, accesos rápidos y métricas iniciales.
+
+
+
+**Workspace Switcher Menu Open**
+
+**Descripción:** Esta pantalla evidencia el selector de workspace abierto. Permite cambiar entre organizaciones o espacios de trabajo, asegurando que el usuario opere en el contexto correcto.
+
+
+
+**User Profile Menu Open**
+
+**Descripción:** Este mock-up muestra el menú de perfil del usuario. Desde esta sección se accede a opciones personales, configuración de cuenta o cierre de sesión.
+
+
+
+**Gestión de proyectos**
+
+**Projects Page Overview**
+
+**Descripción:** Este mock-up presenta la vista principal de proyectos dentro del workspace. Permite visualizar proyectos activos, su estado y accesos para crear o administrar iniciativas.
+
+
+
+**Projects Board Overview**
+
+**Descripción:** Esta pantalla muestra una vista tipo tablero de proyectos. Facilita comparar proyectos, revisar su avance y acceder a sesiones o historias relacionadas.
+
+
+
+**Live Discovery Session Modal Configuration**
+
+**Descripción:** Esta pantalla representa la configuración de una sesión de descubrimiento en vivo. El usuario puede preparar la captura de audio y activar el soporte de IA para convertir la conversación en historias de usuario.
+
+
+
+**Historias de usuario generadas por IA**
+
+**User Stories Page Review Board**
+
+**Descripción:** Este mock-up muestra el tablero de revisión de historias de usuario generadas por IA. Las historias pueden organizarse por estado, revisarse, editarse y aprobarse antes de pasar al backlog.
+
+
+
+**Integraciones, billing y configuración**
+
+**Integrations Page Jira Connection**
+
+**Descripción:** Este mock-up muestra la página de integraciones externas, destacando la conexión con Jira. Permite evidenciar cómo Reqs-AI facilita llevar historias aprobadas hacia herramientas ágiles.
+
+
+
+**Jira Connection Modal OAuth Flow**
+
+**Descripción:** Esta pantalla representa el modal de conexión con Jira mediante autorización OAuth. El objetivo es vincular Reqs-AI con Atlassian de forma segura, sin exponer credenciales directamente.
+
+
+
+**Billing Subscription Page**
+
+**Descripción:** Este mock-up presenta la página de suscripción y facturación. Permite visualizar el plan activo, consumo, límites y opciones de actualización del modelo SaaS.
+
+
+
+**Settings Workspace Configuration Page**
+
+**Descripción:** Esta pantalla muestra la configuración general del workspace. Desde aquí se gestionan datos de la organización, preferencias del entorno y ajustes principales.
+
+
+
+**Navigation Consistency Check Frame**
+
+**Descripción:** Esta pantalla evidencia la consistencia visual de la navegación en la aplicación. Mantiene sidebar, barra superior, acciones principales y perfil de usuario de forma uniforme.
+
+
+
+**Settings Team Members Management Page**
+
+**Descripción:** Este mock-up representa la administración de miembros del equipo. Permite invitar usuarios, revisar integrantes, gestionar roles y controlar accesos al workspace.
+
+
+
+**Sesiones de descubrimiento**
+
+**Discovery Sessions Page Simple Overview**
+
+**Descripción:** Esta pantalla muestra una vista general de las sesiones de descubrimiento. Permite revisar reuniones registradas, su estado y el acceso a sesiones anteriores.
+
+
+
+**Discovery Sessions Page Metrics And Export**
+
+**Descripción:** Este mock-up amplía la vista de sesiones con métricas y acciones de exportación. Permite evidenciar el valor generado por Reqs-AI mediante sesiones procesadas y resultados obtenidos.
+
+
+
+**User Story Review Drawer With Gherkin**
+
+**Descripción:** Esta pantalla presenta el panel lateral de detalle de una historia de usuario. Incluye descripción, criterios de aceptación en formato Gherkin, nivel de confianza y acciones de edición o aprobación.
+
+
+
+**Create New Project Modal Template Selection**
+
+**Descripción:** Este mock-up representa el modal de creación de un nuevo proyecto. Incluye la selección de plantilla o tipo de proyecto para configurar rápidamente un espacio de levantamiento de requisitos.
+
+
+
+**Mobile Application Mock-ups**
+
+Los siguientes mock-ups presentan la versión de alta fidelidad de la aplicación móvil de Reqs-AI. La secuencia evidencia el recorrido principal del usuario dentro de la plataforma: autenticación, navegación principal, gestión de proyectos, sesiones de descubrimiento, revisión de historias generadas por IA, integraciones, facturación y configuración del equipo.
+
+**Login Screen**
+
+**Descripción:** El Mock-up de la pantalla de inicio de sesión consolida la identidad de marca del producto aplicando el Design System mediante una paleta de colores sobria, donde destaca el verde esmeralda corporativo en el botón principal de acción (CTA) y los acentos interactivos (Sign In, Forgot Password?). La arquitectura de información distribuye verticalmente los elementos clave (campos de texto legibles, opciones de autenticación federada con Google y Okta, y enlaces de asistencia) sobre una tarjeta contenedora blanca con bordes redondeados y sombras sutiles que generan una clara separación de capas visuales, garantizando un alto contraste tipográfico y un diseño inclusivo que minimiza el error táctil en dispositivos móviles.
+
+
+
+**Dashboard Screen**
+
+**Descripción:** El Mock-up del Dashboard implementa el Design System estructurando métricas clave (como los 12 proyectos activos o las 450 historias generadas) en tarjetas modulares blancas de alta visibilidad que optimizan la carga cognitiva. Su arquitectura de información destaca una sección interactiva de "Recent Sessions" y un contenedor asimétrico azul noche para recomendaciones de la IA, complementado con un menú de navegación inferior consistente y un botón flotante de micrófono esmeralda que garantiza una accesibilidad táctil inmediata en movilidad.
+
+
+
+**Settings & Profile Screen**
+
+**Descripción:** El Mock-up de esta vista consolida las configuraciones de la cuenta organizando la arquitectura de información mediante contenedores modulares con esquinas suavizadas sobre un fondo gris claro neutro. La interfaz integra con precisión los elementos de diseño del Design System, destacando el uso de etiquetas de estado en verde esmeralda para suscripciones activas (Enterprise), selectores de apariencia con alto contraste y un botón de cierre de sesión (Log Out) codificado en rojo para mitigar errores de navegación táctil.
+
+
+
+**Live Assistant Screen**
+
+**Descripción:** El Mock-up de esta pantalla operativa plasma la interacción de la IA en tiempo real utilizando el Design System mediante un contenedor blanco de bordes suavizados y un sutil degradado verde esmeralda para el módulo "AI Smart Suggestions". La arquitectura de información prioriza la accesibilidad y ergonomía táctil en movilidad al ubicar los controles de sesión en la parte inferior, destacando el botón principal asimétrico (Finish & Generate Stories) para cerrar el flujo libre de errores.
+
+
+
+**Review & Export Screen**
+
+**Descripción:** El Mock-up de esta pantalla aplica el Design System superponiendo un panel emergente inferior (Bottom Sheet) estilizado con sombras suaves para confirmar la sincronización hacia plataformas de gestión de proyectos. La arquitectura de información destaca una cuadrícula de botones para seleccionar servicios externos (como Azure DevOps en verde corporativo) y un botón de acción principal de alto contraste (Sync Backlog), garantizando un diseño inclusivo y un control táctil óptimo sin perder la visibilidad de las historias de usuario de fondo.
+
+
+
+**Projects Archive Screen**
+
+**Descripción:** El Mock-up de esta pantalla consolida el catálogo de proyectos empleando tarjetas modulares individuales con bordes suavizados que facilitan la lectura en movilidad. Su arquitectura de información integra un buscador superior intuitivo y píldoras de filtrado por estado, aplicando las pautas de diseño inclusivo del Design System mediante barras de progreso en verde esmeralda y un botón flotante de adición táctil de alta accesibilidad para el pulgar.
+
+
+
+**Project Settings Screen**
+
+**Descripción:** El Mock-up de esta pantalla configura los parámetros del proyecto aplicando el Design System mediante un diseño puramente vertical segmentado en bloques funcionales con tipografía de alto contraste. La arquitectura de información destaca controles interactivos táctiles como el switch esmeralda de "AI Auto-Analysis Settings", tarjetas de integración directa (Jira y Azure) y un componente cronológico de "Team Activity", garantizando un diseño inclusivo y un control ergonómico sin errores en movilidad.
+
+
+
+**Project User Stories Screen**
+
+**Descripción:** El Mock-up de esta pantalla presenta el catálogo detallado de historias de usuario bajo una arquitectura de información estructurada en bloques de sintaxis Gherkin (Given-When-Then) de alta legibilidad para el analista. La interfaz consolida el Design System mediante un buscador superior interactivo, píldoras de filtrado por estado (Draft, Review, Approved) codificadas por colores de alto contraste y un botón flotante de adición táctil que optimiza el diseño inclusivo en movilidad.
+
+
+
+**Session History Screen**
+
+**Descripción:** El Mock-up de esta pantalla organiza las grabaciones pasadas aplicando el Design System sobre una línea de tiempo vertical segmentada de manera limpia con indicadores de estado circulares. La arquitectura de información destaca en cada tarjeta métricas críticas como el porcentaje de precisión de la IA (AI Score), la duración y el moderador, integrando un diseño inclusivo mediante botones de reproducción rápida en verde esmeralda y accesos prominentes (View Transcript) para mitigar errores en movilidad.
+
+
+
+**Integrations Directory Screen**
+
+**Descripción:** El Mock-up de esta pantalla consolida el catálogo de extensiones externas aplicando el Design System mediante tarjetas modulares ordenadas bajo íconos de categoría con alto contraste cromático. La arquitectura de información distribuye de forma jerárquica los servicios vinculados (como Jira en estado activo) de los disponibles para conectar (Connect), integrando un diseño inclusivo mediante botones amplios de fácil alcance y un banner asimétrico azul noche para promocionar integraciones destacadas de la IA.
+
+
+
+**Billing & Subscription Screen**
+
+**Descripción:** El Mock-up de esta pantalla gestiona los datos financieros del usuario aplicando el Design System a través de bloques de información con bordes suavizados sobre un fondo blanco limpio. La arquitectura de información prioriza los datos críticos mediante una barra de progreso esmeralda para el consumo de tokens, una tarjeta asimétrica azul noche para el próximo cobro de $499.00 y una lista vertical de facturas descargables con botones táctiles amplios, logrando un diseño inclusivo que simplifica la administración de la cuenta en movilidad.
+
+
+
+**Web Application User Flow Diagrams**
+
+Los user flow diagrams de la aplicación web de Reqs-AI representan el recorrido funcional que sigue el usuario dentro de la plataforma. A diferencia de los wireframes y wireflows, estos diagramas permiten observar de forma más directa cómo se conectan las acciones principales del usuario con los módulos del sistema: autenticación, onboarding, creación de workspace, navegación principal, gestión de proyectos, sesiones de descubrimiento, revisión de historias generadas por IA, integraciones, facturación y configuración del equipo.
+
+Cada user flow evidencia una ruta de uso concreta, mostrando cómo el usuario avanza desde una necesidad inicial hasta una acción final dentro de la web application. Esto permite validar la continuidad de la experiencia, la coherencia entre módulos y la relación entre las pantallas diseñadas.
+
+#### Flujo de autenticación y acceso
+
+##### Registro hacia inicio de sesión
+
+**Descripción:** Este user flow muestra la transición entre la pantalla de registro y la pantalla de inicio de sesión. El flujo permite validar que un visitante puede crear una cuenta o volver al login si ya cuenta con credenciales, manteniendo una navegación clara en el acceso inicial a Reqs-AI.
+
+
+
+#### Flujo de onboarding y creación de workspace
+
+##### Dashboard vacío hacia configuración del workspace
+
+**Descripción:** Este user flow representa el recorrido inicial del usuario cuando aún no tiene un workspace creado. Desde el dashboard vacío, el usuario puede iniciar la creación del espacio de trabajo, seleccionar el caso de uso principal y completar la configuración base para adaptar Reqs-AI a su organización.
+
+
+
+##### Creación del workspace hacia confirmación exitosa
+
+**Descripción:** Este flujo evidencia el proceso de carga y creación del workspace. La pantalla muestra cómo el sistema comunica el avance de configuración y luego confirma que el workspace fue creado correctamente, permitiendo al usuario continuar hacia el entorno principal de trabajo.
+
+
+
+#### Flujo de navegación principal y proyectos
+
+##### Home del workspace hacia proyectos
+
+**Descripción:** Este user flow muestra la navegación desde el dashboard principal del workspace hacia el módulo de proyectos. Permite validar que el usuario puede revisar proyectos activos, acceder a métricas generales y administrar iniciativas asociadas a clientes o productos específicos.
+
+
+
+#### Flujo de sesiones de descubrimiento
+
+##### Sesiones hacia discovery sessions
+
+**Descripción:** Este flujo representa la navegación desde la página general de sesiones hacia la vista de discovery sessions. Permite revisar reuniones procesadas, métricas de sesiones, estados de avance y accesos a sesiones asistidas por IA.
+
+
+
+##### Discovery sessions hacia inicio de sesión en vivo
+
+**Descripción:** Este user flow muestra cómo el usuario inicia una sesión de descubrimiento en vivo desde el módulo de sesiones. El flujo valida la configuración previa de la sesión, incluyendo título, proyecto asociado, modo de facilitación y opciones de captura antes de lanzar la reunión asistida por IA.
+
+
+
+#### Flujo de historias de usuario generadas por IA
+
+##### Historias de usuario hacia revisión detallada
+
+**Descripción:** Este flujo evidencia cómo el usuario accede al detalle de una historia generada por IA desde el listado principal. El panel de revisión permite validar la descripción, prioridad, nivel de confianza, criterios de aceptación en formato Gherkin y acciones de edición o aprobación antes de utilizar la historia en el backlog.
+
+
+
+#### Flujo de integraciones externas
+
+##### Integraciones hacia conexión con Jira
+
+**Descripción:** Este user flow muestra el proceso para conectar Reqs-AI con Jira desde la página de integraciones. El flujo permite validar la autorización, configuración y vinculación con Atlassian para exportar historias aprobadas hacia herramientas ágiles sin copiar información manualmente.
+
+
+
+#### Flujo de facturación y suscripción
+
+##### Gestión de billing y suscripción
+
+**Descripción:** Este flujo representa la vista de facturación y suscripción del workspace. Permite revisar el plan activo, el consumo de tokens de IA, los colaboradores activos, el método de pago, el historial de facturas y las acciones de upgrade o administración del plan.
+
+
+
+#### Flujo de configuración y equipo
+
+##### Settings hacia gestión de equipo
+
+**Descripción:** Este user flow muestra la navegación desde la configuración general del workspace hacia la administración del equipo. Permite validar la gestión de miembros, roles, permisos, invitaciones y alertas internas, asegurando control sobre el acceso y las responsabilidades dentro de la organización.
+
+
+
+#### Flujo general de la web application
+
+##### Vista general del user flow completo
+
+**Descripción:** Este diagrama resume el recorrido global de la web application de Reqs-AI. Integra las rutas principales entre dashboard, proyectos, sesiones, historias de usuario, integraciones, billing y settings, mostrando cómo los módulos se conectan dentro de una experiencia continua y coherente para el usuario.
+
+
+
+**Mobile Application User Flow Diagrams**
+
+**Autenticación de Usuario y Configuración de Cuenta**
+
+**Descripción:** Este User Flow mapea el happy path de alta fidelidad para el inicio de sesión exitoso y la navegación inmediata hacia la configuración del perfil mediante el menú inferior. El diagrama integra los Mock-ups finales del producto digital para validar las condiciones visuales del Design System, sirviendo como contraparte directa y consistente del Wireflow funcional previamente establecido.
+
+
+
+**Activación de Sesión de Elicitación en Live Assistant**
+
+**Descripción:** Este User Flow ilustra la ruta óptima (happy path) de alta fidelidad que recorre el analista al iniciar una sesión de captura de requerimientos desde el Dashboard principal. El diagrama emplea los Mock-ups terminados para validar visualmente la activación inmediata del motor de IA (Analysis engine active) y el despliegue dinámico de sugerencias en tiempo real al cambiar de pantalla.
+
+
+
+**Sincronización y Exportación de Requerimientos Refinados**
+
+**Descripción:** Este User Flow representa la ruta esperada (happy path) de alta fidelidad para la validación y exportación de artefactos de software directamente a herramientas de gestión desde el Dashboard. El diagrama incorpora los Mock-ups finales para ilustrar la interacción táctil que despliega el panel inferior de sincronización (Ready for Backlog Sync), garantizando la consistencia visual y de comportamiento con su respectivo diagrama de Wireflow.
+
+
+
+**Administración de Proyectos y Gestión de Historias de Usuario**
+
+**Descripción:** Este User Flow detalla la ruta interactiva (happy path) de alta fidelidad que recorre el usuario para supervisar la configuración y el backlog de un proyecto específico. El diagrama conecta en secuencia los Mock-ups finales del producto digital (Dashboard, Projects Archive, Project Settings y Project User Stories), validando de forma consistente las transiciones visuales de los datos y estados definidos previamente en la estructura funcional del Wireflow.
+
+
+
+**Navegación de Historias de Usuario a Historial, Integraciones y Facturación**
+
+**Descripción:** Este último User Flow consolida el camino operativo (happy path) de alta fidelidad que recorre el analista para transicionar entre la gestión del backlog y los módulos administrativos. El diagrama enlaza secuencialmente los Mock-ups finales (Project User Stories, Session History, Integrations Directory y Billing & Subscription) mediante interacciones en el menú inferior, garantizando una correspondencia estética y funcional exacta con el comportamiento definido en su Wireflow homólogo.
+
+
+
+## 6.5. Applications Prototyping
+
+**Web Application Prototyping**
+
+En esta sección se presenta el prototipo interactivo de alta fidelidad para la aplicación web de Reqs-AI, construido con Figma. El prototipo integra los mock-ups finales en una experiencia navegable que simula el comportamiento real de la plataforma, permitiendo validar la usabilidad, la consistencia visual y la fluidez de las transiciones entre las pantallas principales.
+
+El prototipo web permite recorrer los flujos más importantes del sistema, como el inicio de sesión, la creación del workspace, la navegación por el dashboard, la gestión de proyectos, el inicio de sesiones de descubrimiento, la revisión de historias de usuario generadas por IA, la conexión con Jira, la administración de la suscripción y la configuración del equipo.
+
+
+
+**Enlace al prototipo:**
+
+El prototipo interactivo de la aplicación web de Reqs-AI se encuentra disponible en el siguiente enlace: [Reqs-AI Web Application Prototype](https://www.figma.com/proto/UVAwp3YUbl7HdyW36b40d6/Web-application-prototype?node-id=25-16791&p=f&t=eUjvMWP8QbWcmZbl-1&scaling=min-zoom&content-scaling=fixed&page-id=0%3A1&starting-point-node-id=25%3A16791&show-proto-sidebar=1)
+
+El video del prototipo interactivo se encuentra disponible en el siguiente enlace: [Reqs-AI Web Application Prototype Video](https://upcedupe-my.sharepoint.com/:v:/g/personal/u202319668_upc_edu_pe/IQDz-JGNFecGR5wGEjgFKkb1Ab_PQSFGMfoLZ4QStDYVWiw?nav=eyJyZWZlcnJhbEluZm8iOnsicmVmZXJyYWxBcHAiOiJPbmVEcml2ZUZvckJ1c2luZXNzIiwicmVmZXJyYWxBcHBQbGF0Zm9ybSI6IldlYiIsInJlZmVycmFsTW9kZSI6InZpZXciLCJyZWZlcnJhbFZpZXciOiJNeUZpbGVzTGlua0NvcHkifX0&e=ThYQDY)
+
+**Mobile Application Prototyping**
+
+En esta sección se presentan el prototipo interactivo de alta fidelidad para la aplicación móvil de Reqs-AI, construido con Figma. El prototipo integra los Mock-ups finales en una experiencia navegable que simula el comportamiento real del producto digital, permitiendo validar la usabilidad, la consistencia visual y la fluidez de las transiciones entre pantallas.
+
+
+
+**Enlace al prototipo:**
+
+El prototipo interactivo de la aplicación móvil de Reqs-AI se encuentra disponible en el siguiente enlace: [Reqs-AI Mobile Application Prototype](https://www.figma.com/proto/TBYTXyq5REHaJd57XdMFe3/Mobile-App?node-id=10-275&viewport=-1730%2C-1243%2C0.17&t=4JoIIEahuM82Ubyn-1&scaling=min-zoom&content-scaling=fixed&starting-point-node-id=10%3A275&show-proto-sidebar=1&page-id=0%3A1)
+
+El video del prototipo interactivo se encuentra disponible en el siguiente enlace: [Reqs-AI Mobile Application Prototype Video](https://upcedupe-my.sharepoint.com/:v:/g/personal/u20201e843_upc_edu_pe/IQAQ5aiOb23nSI7phtra3Un_AQX1hqL_qhVPW8CldVvTLv0?nav=eyJyZWZlcnJhbEluZm8iOnsicmVmZXJyYWxBcHAiOiJPbmVEcml2ZUZvckJ1c2luZXNzIiwicmVmZXJyYWxBcHBQbGF0Zm9ybSI6IldlYiIsInJlZmVycmFsTW9kZSI6InZpZXciLCJyZWZlcnJhbFZpZXciOiJNeUZpbGVzTGlua0NvcHkifX0&e=BmdCkh)
+
+# Capítulo VII: Product Implementation, Validation & Deployment
+
+## 7.1. Software Configuration Management
+
+### 7.1.1. Software Development Environment Configuration
+
+### 7.1.2. Source Code Management
+
+### 7.1.3. Source Code Style Guide & Conventions
+
+### 7.1.4. Software Deployment Configuration
+
+## 7.2. Solution Implementation
+
+### 7.2.X. Sprint n
+
+#### 7.2.X.1. Sprint Planning n
+
+#### 7.2.X.2. Sprint Backlog n
+
+#### 7.2.X.3. Development Evidence for Sprint Review
+
+#### 7.2.X.4. Testing Suite Evidence for Sprint Review
+
+#### 7.2.X.5. Execution Evidence for Sprint Review
+
+#### 7.2.X.6. Services Documentation Evidence for Sprint Review
+
+#### 7.2.X.7. Software Deployment Evidence for Sprint Review
+
+#### 7.2.X.8. Team Collaboration Insights during Sprint
+
+## 7.3. Validation Interviews
+
+### 7.3.1. Diseño de Entrevistas
+
+### 7.3.2. Registro de Entrevistas
+
+### 7.3.3. Evaluaciones según heurísticas
+
+## 7.4. Video About-the-Product
+
+# Conclusiones
+
+El equipo concluye que el problema abordado es real, recurrente y de alto impacto en el ciclo de vida del software: la ambigüedad en el levantamiento de requisitos y la sobrecarga de postprocesamiento generan retrabajo, retrasos y riesgo de construir funcionalidades incorrectas. La evidencia obtenida en entrevistas confirma un patrón consistente en ambos segmentos objetivo (Líder Técnico de Startup y Analista de Sistemas/Producto): transformar conversaciones en requisitos claros, trazables y accionables sigue siendo el principal cuello de botella.
+
+Sobre esta base, Reqs-AI se consolida como una propuesta de valor pertinente al combinar asistencia en tiempo real, generación estructurada de historias de usuario y criterios de aceptación, y mecanismos de integración con herramientas de gestión del backlog. El enfoque del producto no reemplaza el criterio profesional del analista o líder técnico, sino que lo potencia para reducir omisiones, acelerar la claridad funcional y mejorar la calidad de entrada hacia desarrollo y QA.
+
+Asimismo, el trabajo desarrollado en el informe demuestra coherencia metodológica entre descubrimiento, análisis y diseño de solución. Los artefactos de Lean UX, entrevistas, need finding, user stories, backlog e impact mapping se enlazan con decisiones arquitectónicas estratégicas (DDD, EventStorming, Bounded Contexts y lineamientos de seguridad multitenancy con RLS), aportando trazabilidad desde la necesidad del usuario hasta la estructura técnica propuesta.
+
+Respecto a las hipótesis planteadas, el equipo considera que cuentan con validación inicial de problema y de deseabilidad, debido a la convergencia de hallazgos cualitativos y cuantitativos en las entrevistas. Sin embargo, su validación de desempeño y negocio permanece parcial, ya que métricas objetivas como reducción de reuniones de aclaración, tiempo de edición manual por sesión, retención de uso y sincronización efectiva al backlog deben medirse con el producto en operación real.
+
+La principal limitación actual del proyecto es que aún no se presenta evidencia completa de implementación, pruebas de campo y resultados longitudinales de adopción. En consecuencia, aunque la arquitectura y el diseño funcional están sólidamente fundamentados, todavía es necesario contrastar el comportamiento del sistema en escenarios productivos con usuarios reales y condiciones de carga, seguridad y dependencia de servicios externos de IA.
+
+Como siguientes pasos, se recomienda priorizar un MVP enfocado en el flujo crítico end-to-end (captura de reunión, síntesis guiada, generación de historias con criterios de aceptación y exportación a backlog), ejecutar pilotos controlados en startups y entornos enterprise, y definir un tablero de métricas para validar hipótesis de valor, eficiencia y confianza. Con ello, Reqs-AI podrá transitar de una solución bien diseñada en el plano estratégico a una plataforma validada en impacto operativo y escalabilidad de negocio.
+
+# Bibliografía
+
+>Pulse of the Profession (2018) Success in Disruptive Times. Project Management Institute. Recuperado el 15 de Abril de 2025, de https://www.pmi.org/learning/thought-leadership/pulse/pulse-of-the-profession-2018
+
+>Jhonson J (2020) CHAOS Report: Beyond Infinity. Standish Group. Recuperado el 15 de Abril de 2025, de https://www.standishgroup.com/products/copy-of-chaos-report-beyond-infinity-digital-version
# Anexos
diff --git a/assets/architecture/container-diagram.png b/assets/architecture/container-diagram.png
deleted file mode 100644
index b9186fc..0000000
Binary files a/assets/architecture/container-diagram.png and /dev/null differ
diff --git a/assets/architecture/deployment-diagram.png b/assets/architecture/deployment-diagram.png
deleted file mode 100644
index 8535983..0000000
Binary files a/assets/architecture/deployment-diagram.png and /dev/null differ
diff --git a/assets/architecture/system-context.png b/assets/architecture/system-context.png
deleted file mode 100644
index 0700784..0000000
Binary files a/assets/architecture/system-context.png and /dev/null differ
diff --git a/assets/architecture/system-landscape.png b/assets/architecture/system-landscape.png
deleted file mode 100644
index b85c2fa..0000000
Binary files a/assets/architecture/system-landscape.png and /dev/null differ
diff --git a/assets/ddd/bounded-contexts.jpg b/assets/ddd/bounded-contexts.jpg
index c0771b2..3f77c31 100644
Binary files a/assets/ddd/bounded-contexts.jpg and b/assets/ddd/bounded-contexts.jpg differ
diff --git a/assets/diagrams/architecture/container-diagram.png b/assets/diagrams/architecture/container-diagram.png
new file mode 100644
index 0000000..3721985
Binary files /dev/null and b/assets/diagrams/architecture/container-diagram.png differ
diff --git a/assets/diagrams/architecture/container-diagram.puml b/assets/diagrams/architecture/container-diagram.puml
new file mode 100644
index 0000000..e83ac8d
--- /dev/null
+++ b/assets/diagrams/architecture/container-diagram.puml
@@ -0,0 +1,90 @@
+@startuml container-diagram
+!include ../c4/C4_Container.puml
+!include ../c4/C4_Component.puml
+!include ../styles/reqsai-palette.puml
+
+HIDE_PERSON_SPRITE()
+
+skinparam defaultFontName "Segoe UI"
+skinparam shadowing false
+
+UpdateElementStyle(person, $bgColor=$REQSAI_NAVY_800, $fontColor="#FFFFFF", $borderColor="#1A3A5C")
+UpdateElementStyle(system_ext, $bgColor="#455A64", $fontColor="#FFFFFF", $borderColor="#263238")
+UpdateElementStyle(container, $bgColor=$REQSAI_BLUE_700, $fontColor="#FFFFFF", $borderColor=$REQSAI_BLUE_800)
+UpdateElementStyle(containerDb, $bgColor=$REQSAI_TEAL_800, $fontColor="#FFFFFF", $borderColor=$REQSAI_TEAL_900)
+UpdateElementStyle(component, $bgColor=$REQSAI_BLUE_600, $fontColor="#FFFFFF", $borderColor=$REQSAI_BLUE_700)
+
+AddContainerTag("edge", $bgColor="#37474F", $fontColor="#FFFFFF", $borderColor="#263238", $legendText="Edge / Routing Layer (AWS)")
+AddContainerTag("frontend", $bgColor=$REQSAI_NAVY_800, $fontColor="#FFFFFF", $borderColor="#1A3A5C", $legendText="Frontend Application")
+
+title Container Diagram -- ReqsAI (C4 Level 2)
+
+' ── Actors ──────────────────────────────────────────────────────────
+Person(techLead, "Technical Lead", "Inicia grabaciones y\naprueba historias de usuario.")
+Person(analyst, "Enterprise Analyst", "Administra la organizacion\ny el plan de suscripcion.")
+
+' ── Edge layer ──────────────────────────────────────────────────────
+Container(cdn, "CDN & Reverse Proxy", "Amazon CloudFront", "Sirve los activos estaticos del SPA Angular\ndesde ubicaciones globales (Edge Locations),\ncachea respuestas, mitiga DDoS y enruta\nel trafico de API hacia el API Gateway.", $tags="edge")
+Container(apiGw, "API Gateway", "AWS API Gateway", "Punto de entrada unificado para peticiones\nREST y WebSocket desde web y mobile.\nGestiona throttling, metricas y SSL.", $tags="edge")
+
+' ── Frontends ────────────────────────────────────────────────────────
+Container(web, "Web Application", "Angular", "SPA web principal. Revision de historias,\nconfiguracion de proyectos y administracion\nde la organizacion. Servida por CloudFront.", $tags="frontend")
+Container(mobile, "Mobile App", "Flutter", "App movil multiplataforma (iOS/Android).\nGrabacion de reuniones y revision\nde requerimientos. Llama al API Gateway\ndirectamente (no pasa por CDN).", $tags="frontend")
+
+' ── Backend: Monolito Modular ─────────────────────────────────────────
+Container_Boundary(backend, "ReqsAI Backend Service [Java 25 + Spring Boot 4 -- Monolito Modular / Spring Modulith]") {
+
+ Component(iam, "IAM", "Spring Modulith Module", "Autenticacion JWT, registro de cuentas,\nverificacion de email, sesiones y\ngestion de perfil de usuario.")
+
+ Component(billing, "Billing & Subscriptions", "Spring Modulith Module", "Ciclo de vida de suscripciones, control de\ncuotas de tokens e integracion con\nla pasarela de pagos externa.")
+
+ Component(workspace, "Workspace Management", "Spring Modulith Module", "Organizaciones, proyectos, miembros, roles,\ndocumentos, glosarios y aplicacion de\nlimites de plan (Row Level Security).")
+
+ Component(discovery, "Requirement Discovery", "Spring Modulith Module", "Captura de audio, transcripcion STT,\nmotor RAG con embeddings y generacion\nde historias Gherkin via LLM.")
+
+ Component(gateway, "Integration Gateway", "Spring Modulith Module", "Exportacion de historias de usuario\naprobadas a herramientas externas\nde gestion de proyectos.")
+}
+
+' ── Database ─────────────────────────────────────────────────────────
+ContainerDb(db, "Database", "PostgreSQL + pgvector\n[AWS RDS]", "Base de datos relacional administrada.\nLa extension pgvector habilita almacenamiento\nde embeddings vectoriales para el motor RAG.")
+
+' ── External Systems ─────────────────────────────────────────────────
+System_Ext(email, "Email Service Provider", "Correos transaccionales:\nverificacion, recuperacion, invitaciones.")
+System_Ext(payment, "Payment Gateway", "Procesamiento de pagos B2B.\nEj: Stripe, Culqi, Mercado Pago.")
+System_Ext(stt, "STT API", "Speech-to-Text: convierte audio\nen texto en tiempo real (< 2 seg).")
+System_Ext(embedApi, "Embedding API", "Convierte texto en vectores para\nel indice RAG (pgvector). Ej: OpenAI\ntext-embedding-3-small, Cohere Embed.")
+System_Ext(llm, "LLM API", "Large Language Model generativo.\nEj: GPT-4o, Claude, Gemini.")
+System_Ext(pmtool, "Project Management API", "Crea issues automaticamente\nen el backlog. Ej: Jira, Trello, Linear.")
+
+' ── Relations ────────────────────────────────────────────────────────
+' Web: pasa por CDN
+Rel(techLead, cdn, "Accede via navegador", "HTTPS")
+Rel(analyst, cdn, "Accede via navegador", "HTTPS")
+Rel(cdn, web, "Sirve SPA estatico", "HTTPS")
+Rel(cdn, apiGw, "Enruta llamadas API", "HTTPS")
+Rel(web, apiGw, "Llamadas API", "HTTPS / REST")
+
+' Mobile: directo al API Gateway (app instalada desde App Store, no desde CDN)
+Rel(techLead, mobile, "Usa app movil", "App Store / Play Store")
+Rel(mobile, apiGw, "Llamadas API directas","HTTPS / REST + WebSocket")
+
+Rel(apiGw, backend, "Enruta peticiones al monolito", "HTTPS / REST")
+
+Rel(iam, db, "Lee y escribe", "JDBC / JPA")
+Rel(billing, db, "Lee y escribe", "JDBC / JPA")
+Rel(workspace, db, "Lee y escribe", "JDBC / JPA")
+Rel(discovery, db, "Lee y escribe", "JDBC / JPA")
+Rel(gateway, db, "Lee y escribe", "JDBC / JPA")
+
+Rel(iam, email, "Envia correos transaccionales via", "REST API")
+Rel(billing, payment, "Procesa pagos de suscripcion via", "REST API")
+Rel(workspace, embedApi, "Vectoriza docs + glosario para RAG via", "REST API")
+Rel(workspace, llm, "Procesa contenido de documentos via", "REST API")
+Rel(discovery, stt, "Envia audio para transcripcion via", "REST / Streaming")
+Rel(discovery, embedApi, "Vectoriza user stories generadas via", "REST API")
+Rel(discovery, llm, "Infiere historias en Gherkin via", "REST API")
+Rel(gateway, pmtool, "Exporta historias aprobadas via", "REST API")
+
+SHOW_LEGEND()
+
+@enduml
diff --git a/assets/diagrams/architecture/deployment-diagram.png b/assets/diagrams/architecture/deployment-diagram.png
new file mode 100644
index 0000000..8953e89
Binary files /dev/null and b/assets/diagrams/architecture/deployment-diagram.png differ
diff --git a/assets/diagrams/architecture/deployment-diagram.puml b/assets/diagrams/architecture/deployment-diagram.puml
new file mode 100644
index 0000000..be33fb1
--- /dev/null
+++ b/assets/diagrams/architecture/deployment-diagram.puml
@@ -0,0 +1,128 @@
+@startuml deployment-diagram
+!include ../styles/reqsai-palette.puml
+
+skinparam defaultFontName "Segoe UI"
+skinparam shadowing false
+skinparam backgroundColor #FFFFFF
+skinparam ArrowColor $REQSAI_ARROW
+skinparam ArrowFontColor $REQSAI_NEUTRAL_800
+skinparam ArrowFontSize 11
+
+skinparam node {
+ BackgroundColor $REQSAI_NEUTRAL_100
+ BorderColor $REQSAI_NEUTRAL_600
+ FontColor $REQSAI_NEUTRAL_800
+ FontSize 12
+ FontStyle bold
+}
+
+skinparam artifact {
+ BackgroundColor $REQSAI_BLUE_700
+ BorderColor $REQSAI_BLUE_900
+ FontColor #FFFFFF
+ FontSize 11
+}
+
+skinparam database {
+ BackgroundColor $REQSAI_TEAL_800
+ BorderColor $REQSAI_TEAL_900
+ FontColor #FFFFFF
+ FontSize 11
+}
+
+skinparam component {
+ BackgroundColor $REQSAI_NAVY_800
+ BorderColor "#1A3A5C"
+ FontColor #FFFFFF
+ FontSize 11
+}
+
+
+title Deployment Diagram -- ReqsAI (C4 Level 4)
+
+' ────────────────────────────────────────────────────────────────────
+' CLIENT SIDE
+' ────────────────────────────────────────────────────────────────────
+node "Mobile Devices [iOS / Android]" as mobileDevices {
+ node "User Smartphone" as smartphone {
+ artifact "Mobile App\n[Flutter Engine]" as mobileApp
+ }
+}
+
+node "User Workstations [Windows / macOS / Linux]" as workstations {
+ node "Web Browser [Browser Runtime]" as browser {
+ artifact "Web Application\n[Angular SPA]" as webApp
+ }
+}
+
+' ────────────────────────────────────────────────────────────────────
+' AWS EDGE LOCATION
+' ────────────────────────────────────────────────────────────────────
+node "AWS Edge Location [Amazon CloudFront]" as edgeLayer {
+ artifact "CDN & Reverse Proxy\n[Amazon CloudFront]\nSirve SPA estatico + enruta API" as cdn
+}
+
+' ────────────────────────────────────────────────────────────────────
+' AWS NORTH AMERICA (us-east-1 — Virginia)
+' ────────────────────────────────────────────────────────────────────
+node "AWS North America [AWS Region us-east-1 (Virginia)]" as awsNorthAmerica {
+
+ node "API Gateway [AWS API Gateway]" as apiGatewayNode {
+ artifact "API Gateway\n[AWS API Gateway]\nRouting REST + WebSocket" as apiGw
+ }
+
+ node "ECS Cluster [AWS ECS + Fargate]" as ecsCluster {
+ component "ReqsAI Backend Service\n[Java 25 + Spring Boot 4 / Docker Container]\n\nModulos: IAM · Billing · Workspace\nRequirement Discovery · Integration Gateway" as backend
+ artifact "Grafana Alloy\n[Sidecar Container]\nColecta metricas, logs y trazas\ndel backend y los envia al\nservidor de observabilidad" as alloy
+ }
+
+ node "Observability Server [AWS EC2 + Docker Compose]" as obsServer {
+ component "Prometheus\n[Metricas]" as prometheus
+ component "Loki\n[Logs]" as loki
+ component "Tempo\n[Trazas distribuidas]" as tempo
+ component "Grafana\n[Dashboards]" as grafana
+ }
+}
+
+' ────────────────────────────────────────────────────────────────────
+' AWS RDS
+' ────────────────────────────────────────────────────────────────────
+node "AWS RDS [Managed Relational Database]" as dbNode {
+ database "PostgreSQL + pgvector\n[ReqsAI Main Database]" as db
+}
+
+' ────────────────────────────────────────────────────────────────────
+' RELATIONS
+' ────────────────────────────────────────────────────────────────────
+' Web: pasa por CloudFront
+webApp --> cdn : "HTTPS"
+cdn --> webApp : "Sirve SPA estatico\n(Edge Locations)"
+cdn --> apiGw : "Enruta trafico API\nHTTPS"
+
+' Mobile: directo al API Gateway (app instalada, no servida por CDN)
+mobileApp --> apiGw : "Llamadas API directas\nHTTPS / REST + WebSocket"
+
+apiGw --> backend : "Route all requests\nHTTPS / REST"
+
+' Observabilidad: Alloy como sidecar recolecta del backend
+backend --> alloy : "Metricas /actuator/prometheus\nLogs stdout · Trazas OTLP"
+alloy --> prometheus : "Push metricas\nRemote Write"
+alloy --> loki : "Push logs"
+alloy --> tempo : "Push trazas\nOTLP"
+grafana --> prometheus : "Query metricas\nPromQL"
+grafana --> loki : "Query logs\nLogQL"
+grafana --> tempo : "Query trazas\nTraceQL"
+
+' Persistencia
+backend --> db : "Reads and writes\nJDBC / JPA"
+
+legend bottom right
+ |= Elemento |= Descripcion |
+ |