Visión y alcance

Estado: Aprobado · Última actualización: 2026-08-24 Deriva de: snapshot Notion "Aplicación flujo QA" + sesión de definición de alcance del 2026-08-20.

1. Visión

Argos QA es una plataforma de gestión de calidad y pruebas asistida por IA que convierte requerimientos poco estructurados en artefactos ejecutables y trazables: casos de uso, escenarios de prueba, criterios de aceptación, ciclos de ejecución, evidencia y reportes de calidad.

No es una herramienta de QA aislada. Es un motor de trazabilidad y validación conectado al ecosistema Flagare.

2. El problema

No existe un equipo QA dedicado. La validación recae en developers multifunción que analizan, desarrollan, prueban, corrigen y documentan. Sin un estándar, cada uno interpreta distinto qué significa "validado", con qué profundidad se prueba y qué evidencia debe quedar.

Consecuencias registradas en la fuente:

• Requerimientos ambiguos o incompletos.
• Casos de prueba inconsistentes entre personas.
• Validación dependiente del criterio individual.
• Dependencia excesiva del conocimiento de una persona específica.
• Bugs difíciles de reproducir por falta de evidencia y contexto.
• Poca trazabilidad entre tickets, pruebas y decisiones.
• Dificultad para medir la calidad real antes de liberar.

3. Propuesta de valor

Convertir el QA en un proceso operacional, guiado y repetible, ejecutable por perfiles no especializados. La plataforma debe permitir que un developer responda con claridad: qué probar, por qué, con qué datos, en qué ambiente, qué resultado se espera, qué evidencia queda, cuándo se considera aprobado y qué impacto tiene el resultado.

4. Posicionamiento en el ecosistema

Argos QA es una plataforma hermana independiente — repositorio, base de datos, API y despliegue propios. No reemplaza a Argos Operaciones (argos.flagare).

5. Alcance de esta fase de trabajo

Este espacio produce análisis funcional, por partes. La fase actual entrega:

El alcance funcional documentado corresponde al MVP / Fase 1. Todo lo que pertenezca a fases 2‑4 se marca explícitamente y no baja a detalle.

6. Alcance funcional del MVP

Dentro

1. Crear proyecto de QA importándolo desde Argos Operaciones.
2. Cargar requerimientos como texto pegado o Markdown.
3. Generar casos de uso con IA, o crearlos manualmente.
4. Revisar, ajustar, aprobar y congelar casos de uso.
5. Generar escenarios de prueba y criterios de aceptación.
6. Registrar el ambiente de pruebas, con credenciales solo por referencia. El ambiente es

un registro editable: su historial no vive en versiones propias sino en los snapshots inmutables que capturan los ciclos y las ejecuciones fuera de ciclo (DEC-046).

1. Abrir ciclos de QA contra un ambiente, capturando un snapshot inmutable de su

configuración. El ciclo es opcional: también se puede ejecutar un escenario suelto.

1. Ejecutar pruebas manuales guiadas paso a paso.
2. Capturar evidencia obligatoria: screenshots, logs y archivos adjuntos.
3. Registrar bugs, con creación automática del ticket espejo en Argos Operaciones, y bloqueos como

entidad propia.

1. Dashboard de cobertura, avance y estado de calidad, más reporte formal exportable.
2. Emitir eventos críticos hacia notifications.flagare y notificar en vivo por SSE.

Fuera (primera etapa)

• Reemplazar Argos Operaciones como gestor de proyectos, tickets o tiempos.
• Grabación de pantalla o de sesión del navegador — pasa a fase posterior.
• Dev specs — su inclusión está en evaluación, ver PA-002.
• RAG y pgvector — el contexto se envía directo mientras la ingesta sea texto.
• Ingesta de PDF, DOCX u otros formatos binarios.
• Automatización con Playwright.
• Testing mobile nativo, performance testing, pentesting.
• Entrenamiento de modelos propios.
• Editor visual de scripts Playwright.

7. Roles del MVP

Simplificados respecto de los seis del documento de Notion:

El rol QA es un sombrero, no un cargo. No hay equipo QA dedicado: el rol se asigna a quien vaya a conducir las pruebas de un proyecto, típicamente un developer. Los roles se asignan por la dupla usuario + proyecto, y una persona puede tener varios en el mismo proyecto (DEC-035).

Además de esos cuatro roles de proyecto, existen dos roles de plataforma —Admin (acceso total) y Product Manager (puede importar/crear proyectos)—, provistos por identity.flagare y distintos de los roles de proyecto. Es el nivel que autoriza a crear un proyecto antes de que exista rol de proyecto alguno (DEC-060, RN-085).

Los roles QA Lead y Tech Lead de la fuente quedan absorbidos por QA. Stakeholder se reparte entre Product Manager, para lo interno, y Client, para lo externo. El detalle está en roles y permisos.

8. Gobierno de artefactos

• Un solo validador humano: el Product Manager. Congela casos de uso y aprueba el plan

de pruebas. La concentración es deliberada — con un equipo sin QA dedicado, repartir la aprobación la diluye o la deja esperando a alguien que no está (DEC-037).

• Congelar es fijar una línea base inmutable. Un caso congelado no se edita ni se

descongela: modificarlo crea una versión nueva, y los escenarios derivados de la anterior se marcan como desactualizados para forzar revisión (DEC-028).

• La IA propone, el humano decide. Ningún artefacto se congela sin revisión humana.
• La IA nunca es obligatoria. Todo artefacto admite creación y edición manual, para

no bloquear al equipo si el proveedor de IA no está disponible.

• Sin evidencia no hay resultado. Ninguna ejecución se registra sin respaldo, incluido

un Pass. Es la regla que separa validar de afirmar (DEC-031).

9. Volumen y operación esperados

Escenario Bajo del documento de Notion:

Sin fecha comprometida y con equipo por definir: el análisis no asume restricción de capacidad, y lo que se produzca se ordenará por valor y dependencias técnicas.

10. Decisiones tomadas

Registro de las decisiones que cierran el alcance. Sesión del 2026-08-20; DEC-039 en adelante provienen de la revisión del 2026-08-24 (ver hallazgos de revisión).

Política de retención adoptada (DEC-020)

Las filas de video y trace no aplican al MVP (DEC-006) pero se dejan definidas porque condicionan el diseño del storage.

11. Criterios de éxito

La plataforma será exitosa si logra:

• Que cualquier developer ejecute pruebas siguiendo el mismo estándar.
• Reducir la ambigüedad en los criterios de aceptación.
• Conectar de forma verificable requerimiento → caso de uso → prueba → bug → resolución.
• Mejorar la calidad de la evidencia asociada a los bugs.
• Disminuir el retrabajo por validaciones incompletas.
• Detectar riesgos de liberación antes de producción.
• Compensar la ausencia de un equipo QA dedicado mediante proceso, no mediante personas.

12. Principios de diseño

Heredados de la fuente y vigentes:

1. Trazabilidad primero. Ningún artefacto crítico existe aislado.
2. IA como agente del pipeline, no como asistente de texto.
3. Validación humana en los puntos críticos.
4. Integración con la operación existente, no sustitución.
5. Evidencia auditable. Cada validación se justifica con datos.
6. Vistas por rol. Cada perfil ve lo que su flujo necesita.
7. Métricas accionables. Los reportes sirven para decidir si avanzar, bloquear o liberar.