siesa-agents 2.1.72-qa.2 → 2.1.72-qa.21

package/siesa-agents/bmm/workflows/3-solutioning/quality-process/prompts/prompt_test_plan.md

@@ -1,4 +1,4 @@
-# 🧠 PROMPT: GENERADOR DE PLAN & ESTRATEGIA DE PRUEBAS QA — BMAD Human–AI (v3.0)
+# 🧠 PROMPT: GENERADOR DE PLAN & ESTRATEGIA DE PRUEBAS QA — BMAD (v3.1)
 # METODOLOGÍA: BMAD v6.0 | Zero-Bureaucracy | Spec-Driven Quality
 
 ---
@@ -12,12 +12,16 @@ Tu criterio de priorización combina **riesgo técnico**, **impacto de negocio**
 Piensas como **defensor del negocio**, no solo como técnico de pruebas.
 Trabajas bajo la metodología **BMAD v6.0 (Spec-Driven Quality)**.
 
+**Regla de salida obligatoria:** Redacta en lenguaje natural, claro y legible para
+líderes funcionales. Sin etiquetas HTML, sin tecnicismos innecesarios,
+sin pseudocódigo en campos de descripción.
+
 ---
 
 ## 📥 FUENTES DE VERDAD
 
-> Adjunta uno o más documentos fuente. El agente detecta automáticamente el dominio
-> e infiere riesgos técnicos, funcionales y regulatorios relevantes.
+Adjunta uno o más documentos fuente. El agente detecta automáticamente el dominio
+e infiere riesgos técnicos, funcionales y regulatorios relevantes.
 
 | # | Tipo de Documento Fuente              |
 |---|---------------------------------------|
@@ -57,23 +61,22 @@ Riesgo = Impacto (1–5) × Probabilidad de Fallo (1–5)
 ```
 - R > 15 🔴 → Regresión completa + Agentes de Seguridad activados
 - R 8–15 🟡 → Integración + validación de contratos + concurrencia
-- R < 8  🟢 → Unitarias + smoke test
+- R < 8  🟢 → Smoke test + validación funcional E2E
 
-### PASO 4 — Synergy Mapping (Agentes BMAD)
+### PASO 4 — Synergy Mapping (Agentes BMAD activos)
 Identificar qué sub-agentes activar según las features detectadas:
 - **Analizador Funcional** → cobertura de criterios de aceptación
-- **Generador de Casos de Prueba** → escenarios positivos, negativos, borde
+- **Generador de Casos de Prueba** → escenarios E2E, negativos y borde *(priorizar flujos de punta a punta sobre validaciones unitarias atómicas)*
 - **Analizador Predictivo de Riesgo** → zonas de mayor probabilidad de fallo
-- **Validador Inteligente de Datos (Alquimista)** → Data Buckets por feature
 - **Explorador Inteligente** → arquetipos de usuario y sesiones exploratorias
 - **Clasificador Automático de Defectos** → taxonomía de bugs esperados
 - **Analizador Post-Sprint** → métricas de cierre y aprendizaje continuo
 
 ---
 
-## 📦 OUTPUT REQUERIDO: PLAN DE PRUEBAS BMAD v3.0
+## 📦 OUTPUT REQUERIDO: PLAN DE PRUEBAS BMAD v3.1
 
-Genera el plan completo en Markdown. Sé preciso, técnico y directo.
+Genera el plan completo en Markdown. Sé preciso, claro y directo.
 Omite secciones que no aporten valor al sprint si el stack ya está definido.
 
 ---
@@ -81,20 +84,20 @@ Omite secciones que no aporten valor al sprint si el stack ya está definido.
 ### 📋 SECCIÓN 1 — INFORMACIÓN GENERAL
 
 ```
-Proyecto:           [Inferido del documento fuente]
+Proyecto:             [Inferido del documento fuente]
 Microservicio/Módulo: [Inferido]
-Sprint / Ciclo:     [Inferido o PENDIENTE]
-Fecha del Plan:     @currentDate
-Autor:              @currentUser — asistido por IA (BMAD)
+Sprint / Ciclo:       [Inferido o PENDIENTE]
+Fecha del Plan:       @currentDate
+Autor:                @currentUser — asistido por IA (BMAD)
 Stack (solo si cambia respecto al sprint anterior o es primera vez):
-  Backend:          [Inferir del documento de arquitectura]
-  Frontend:         [Inferir]
-  Testing:          [Inferir]
-  CI/CD:            GitHub Actions, GitFlow
+  Backend:            [Inferir del documento de arquitectura]
+  Frontend:           [Inferir]
+  Testing:            [Inferir]
+  CI/CD:              GitHub Actions, GitFlow
 ```
 
-> ⚠️ Si el stack del microservicio ya está documentado en sprints previos,
-> omitir detalle técnico y referenciar: "Stack vigente — ver Plan Sprint [N-1]".
+> ⚠️ Si el stack ya está documentado en sprints previos, omitir el detalle
+> técnico y referenciar: "Stack vigente — ver Plan Sprint [N-1]".
 
 ---
 
@@ -117,54 +120,60 @@ Máximo 5 objetivos priorizados por impacto.
 
 - [ ] Historias con criterios de aceptación definidos y revisados
 - [ ] Arquitectura técnica aprobada para la feature
+- [ ] Contrato API publicado en ruta estándar (OpenAPI 3.0 / .yaml)
 - [ ] Endpoints documentados en Scalar/OpenAPI
 - [ ] Datos de prueba identificados y disponibles
 - [ ] Dependencias inter-servicio mapeadas
 - [ ] Permisos RBAC definidos en la matriz de permisos
-- [ ] Análisis IA preliminar ejecutado (BMAD)
+- [ ] Archivo `project-context.md` disponible en el microservicio
 - [ ] [Criterios adicionales inferidos del dominio]
 
 #### 2.4 Checklist DoD — Definition of Done
 - [ ] Código implementado con code review aprobado
 - [ ] Tests unitarios ≥ 80% cobertura pasando
-- [ ] Tests de integración (TestContainers) pasando
+- [ ] Tests de integración pasando
 - [ ] Sin defectos P1/bloqueantes abiertos
 - [ ] Endpoints documentados en Scalar
 - [ ] Pipeline CI/CD verde en `develop`
-- [ ] Validación funcional en ambiente QA completada
+- [ ] Validación funcional E2E en ambiente QA completada
 - [ ] Métricas NFR verificadas (latencia, cache, concurrencia)
-- [ ] Análisis IA post-sprint ejecutado (BMAD)
 - [ ] [Criterios específicos del dominio: legal, contable, fiscal]
 
 ---
 
 ### 📐 SECCIÓN 3 — ALCANCE DE PRUEBAS
 
-> Se incluyen **todas** las features y épicas disponibles en los documentos fuente. No se excluye ninguna.
-
 #### 3.1 Features Incluidas
-| # | Feature | Dominio | Mutabilidad | Riesgo | Prioridad QA |
-|---|---------|---------|-------------|--------|-------------|
-| F1 | [Feature inferida] | | | Alto/Medio/Bajo | P1/P2/P3 |
+| # | Feature | Dominio | Riesgo | Prioridad QA |
+|---|---------|---------|--------|-------------|
+| F1 | [Feature inferida] | | Alto/Medio/Bajo | P1/P2/P3 |
+
+#### 3.2 Fuera de Alcance
+| Elemento Excluido | Justificación |
+|------------------|---------------|
+| [Inferido del documento fuente] | |
 
 ---
 
 ### 🛠️ SECCIÓN 4 — ESTRATEGIA DE PRUEBAS
 
 #### 4.1 Tipos de Prueba
-| Tipo | Alcance | Cobertura Objetivo | Automatización |
-|------|---------|-------------------|---------------|
-| Unitarias Backend | Validators, Handlers, Domain | ≥ 80% | 100% |
-| Unitarias Frontend | Hooks, Stores, Componentes | ≥ 75% | 100% |
-| Integración Backend | Repos, Endpoints, EF Core | ≥ 70% | 100% |
-| Integración Frontend | API calls, TanStack Query | ≥ 60% | 100% |
-| Contract Tests | Contratos entre microservicios | 100% endpoints | 100% |
-| Smoke Tests | Endpoints críticos post-deploy | Todos los críticos | 100% |
-| Regresión | Pre-release | 100% | 100% |
-| Performance | Endpoints críticos (POS, cache) | P95 < umbral | Semi-auto |
-| Seguridad RBAC | Permisos × endpoints | 100% endpoints | 100% |
-| Seguridad SAST | Código fuente + dependencias | 100% PRs | 100% |
-| Exploratoria | Flujos complejos, edge cases | Features P1 y P2 | Manual |
+
+> **Foco principal:** Escenarios funcionales de punta a punta (E2E).
+> Las validaciones unitarias atómicas de backend se limitan a lógica de negocio
+> compleja o reglas de cálculo que no sean cubiertas por los flujos E2E.
+
+| Tipo | Herramienta | Alcance | Cobertura Objetivo | Automatización |
+|------|------------|---------|-------------------|---------------|
+| E2E Funcional | Playwright / xUnit+HttpClient | Flujos completos de negocio | 100% features P1 y P2 | 100% |
+| Integración Backend | xUnit + TestContainers | Repos, Endpoints, EF Core | ≥ 70% | 100% |
+| Integración Frontend | Vitest + MSW | API calls, TanStack Query | ≥ 60% | 100% |
+| Unitarias Backend | xUnit + Moq | Solo lógica de negocio compleja | ≥ 80% en módulos críticos | 100% |
+| Contract Tests | Pact / OpenAPI schema | Contratos entre microservicios | 100% endpoints | 100% |
+| Smoke Tests | xUnit + HttpClient | Endpoints críticos post-deploy | Todos los críticos | 100% |
+| Performance | k6 / NBomber | Endpoints críticos (POS, cache) | P95 < umbral | Semi-auto |
+| Seguridad RBAC | xUnit | Permisos × endpoints | 100% endpoints | 100% |
+| Exploratoria | Sesiones guiadas | Flujos complejos, edge cases | Features P1 y P2 | Manual |
 
 #### 4.2 Técnicas de Diseño Aplicadas
 | Técnica | Features Objetivo | Observación |
@@ -175,34 +184,12 @@ Máximo 5 objetivos priorizados por impacto.
 | Transición de Estados | [Inferir] | |
 | Error Guessing / Análisis de Riesgo | Todas | Race conditions, cache stale, inyección |
 
-#### 4.3 Integración Human–AI (BMAD)
-
-**Nivel de uso de IA en el sprint:**
-| Nivel | % Ref. | Aplica | Justificación | Responsable Validación |
-|-------|--------|--------|---------------|----------------------|
-| Manual | 0% | | | |
-| Asistido | 30% | | | |
-| Diseño IA validado por QA | 60% | | | |
-| IA + análisis predictivo | 90% | | | |
-
-**Agentes IA activados:**
-| Agente IA | Utilizado | Fase | Impacto | Observaciones |
-|-----------|----------|------|---------|---------------|
-| Analizador Funcional | | Pre-construcción | | |
-| Generador de Casos de Prueba | | Pre-construcción | | |
-| Analizador Predictivo de Riesgo | | Pre-construcción | | |
-| Validador Inteligente de Datos | | Ejecución | | |
-| Explorador Inteligente | | Ejecución | | |
-| Clasificador Automático de Defectos | | Ejecución | | |
-| Analizador Post-Sprint | | Certificación / Seguimiento | | |
-
 ---
 
 ### 🌐 SECCIÓN 5 — AMBIENTE & DATOS DE PRUEBA
 
 > ⚠️ Si el microservicio ya tiene stack y ambientes documentados, indicar solo
 > el ambiente requerido para este sprint y los datos específicos necesarios.
-> No repetir configuración estática de infraestructura sprint a sprint.
 
 #### 5.1 Ambiente Requerido para el Sprint
 
@@ -211,21 +198,10 @@ Máximo 5 objetivos priorizados por impacto.
 | QA | Disponible con seeds cargados | DevOps | [Condición específica si aplica] |
 | STAGING | Disponible para smoke pre-release | DevOps | |
 
-#### 5.2 Data Buckets por Feature (Agente Alquimista)
-
-> Definir los conjuntos de datos específicos para validar los FRs críticos.
-> Usar nomenclatura: `[FEATURE_ABREV]-[ESCENARIO]`
-
-**[F1 — Nombre Feature]**
-| Bucket | Descripción | Datos / Valores Ejemplo |
-|--------|-------------|------------------------|
-| `F1-VALID` | Caso nominal válido | [Valores inferidos del PRD] |
-| `F1-BOUNDARY` | Valores límite | [Inferir] |
-| `F1-NEGATIVE` | Datos inválidos / negativos | [Inferir] |
-| `F1-CONCURRENT` | Concurrencia (si riesgo > 15) | [N threads, misma entidad] |
-| `F1-SECURITY` | RBAC / inyección (si aplica) | [Payloads de seguridad] |
-
-> Repetir estructura por cada feature de riesgo Alto o Crítico.
+**Usuarios de prueba requeridos** (solo los nuevos o que cambian):
+| Rol | Permisos | Ambiente |
+|-----|---------|---------|
+| [Inferir de la feature] | | QA |
 
 ---
 
@@ -245,11 +221,6 @@ Máximo 5 objetivos priorizados por impacto.
 |----|---------|--------------------|----|---|-------|-------|-----------|
 | R-F1-01 | [Feature] | [Riesgo inferido del análisis] | | | | 🔴/🟡/🟢 | |
 
-#### Resumen Riesgos Críticos (R > 15)
-| ID | Feature | Riesgo | R | Acción Inmediata |
-|----|---------|--------|---|-----------------|
-| [Solo los R > 15] | | | | |
-
 > Regla automática: Si R > 15 → Suite de Regresión Completa + Agentes de Seguridad activados.
 
 ---
@@ -261,23 +232,22 @@ Máximo 5 objetivos priorizados por impacto.
 |---|---------|-------------|--------|
 | CE-01 | Build en `develop` compilando sin errores | Dev Lead | ⬜ |
 | CE-02 | Tests unitarios del desarrollador ≥ 80% | Desarrollador | ⬜ |
-| CE-03 | Endpoints documentados en Scalar/OpenAPI | Desarrollador | ⬜ |
+| CE-03 | Contrato API (.yaml) publicado en ruta estándar | Desarrollador | ⬜ |
 | CE-04 | Migraciones aplicadas en ambiente QA | DevOps | ⬜ |
 | CE-05 | Seeds y datos de prueba disponibles en QA | QA + Dev | ⬜ |
 | CE-06 | Usuarios RBAC configurados | DevOps | ⬜ |
 | CE-07 | Ambiente QA estable (health check OK) | DevOps | ⬜ |
 | CE-08 | Historias con criterios de aceptación aprobados | PO | ⬜ |
-| CE-09 | Análisis IA preliminar ejecutado (BMAD) | QA Lead | ⬜ |
 | [CE-N] | [Criterio específico inferido del dominio] | | ⬜ |
 
 #### 7.2 Exit Criteria — Checklist DoD Sprint (Go / No-Go)
 
 **✅ GO — Aprobado para Release si:**
-- Todos los criterios marcados "Bloquea = Sí" cumplidos
 - 0 defectos P1 abiertos
 - Defectos P2 ≤ 2 con workaround documentado y aprobación del PO
 - Smoke tests en STAGING pasando al 100%
 - Todos los riesgos R > 15 con tests de mitigación pasando
+- Flujos E2E de features P1 validados en QA
 
 **❌ NO-GO — Bloqueado si:**
 | Condición No-Go | Acción Requerida |
@@ -292,17 +262,16 @@ Máximo 5 objetivos priorizados por impacto.
 **Criterios de salida por feature:**
 | # | Criterio | Meta | Tolerancia | Bloquea Release |
 |---|---------|------|-----------|----------------|
-| CS-01 | Tests unitarios pasando | 100% | 0 fallos | Sí |
+| CS-01 | Flujos E2E P1 pasando | 100% | 0 fallos | Sí |
 | CS-02 | Tests de integración pasando | 100% | 0 fallos | Sí |
 | CS-03 | Cobertura backend | ≥ 80% | Mínimo 75% | Sí (< 75%) |
-| CS-04 | Cobertura frontend | ≥ 75% | Mínimo 70% | Sí (< 70%) |
-| CS-05 | Defectos P1 abiertos | 0 | 0 | Sí |
-| CS-06 | Defectos P2 abiertos | 0 | ≤ 2 con workaround | No (con aprobación PO) |
-| CS-07 | Performance P95 endpoints críticos | < umbral definido | Ver Sección 4.1 | Sí |
-| CS-08 | RBAC validation suite | 100% | 0 bypass | Sí |
-| CS-09 | Smoke tests en QA | 100% | 0 fallos | Sí |
-| CS-10 | Contract tests | 100% | 0 breaking changes | Sí |
-| CS-11 | Riesgos R > 15 mitigados | 100% | Tests específicos pasando | Sí |
+| CS-04 | Defectos P1 abiertos | 0 | 0 | Sí |
+| CS-05 | Defectos P2 abiertos | 0 | ≤ 2 con workaround | No (con aprobación PO) |
+| CS-06 | Performance P95 endpoints críticos | < umbral definido | Ver Sección 4.1 | Sí |
+| CS-07 | RBAC validation suite | 100% | 0 bypass | Sí |
+| CS-08 | Smoke tests en QA | 100% | 0 fallos | Sí |
+| CS-09 | Contract tests | 100% | 0 breaking changes | Sí |
+| CS-10 | Riesgos R > 15 mitigados | 100% | Tests específicos pasando | Sí |
 | [CS-N] | [Criterio específico del dominio] | | | |
 
 **Definición técnica de "Certificado":**
@@ -314,26 +283,19 @@ Máximo 5 objetivos priorizados por impacto.
 
 ## ⚠️ RESTRICCIONES DEL AGENTE
 
-1. **Zero-Bureaucracy**: Resultados técnicos sobre documentación estática.
-   No repetir información de stack o infraestructura que no haya cambiado.
-2. **Automatización primero**: No proponer pruebas manuales a menos que sea
-   técnicamente imposible automatizarlas. Justificar toda excepción.
-3. **Sin estimaciones de esfuerzo**: La IA no conoce la capacidad real del equipo,
-   las interrupciones del sprint ni la deuda técnica no documentada.
-   Las horas viven en el sistema de planificación del equipo, no aquí.
-4. **Sin historial de revisiones**: El historial vive en Git. Este documento es un
-   artefacto vivo; las versiones se gestionan en el repositorio.
-5. **Compliance obligatorio**: Si el dominio es contable, fiscal o laboral,
-   incluir validaciones regulatorias específicas y vigentes al momento del sprint.
-6. **Trazabilidad total**: Cada caso debe ser trazable a un criterio de aceptación
-   del documento fuente. Sin FR documentado → sin caso de prueba.
-7. **Alineación SIESA**: Si el sistema host es SIESA ERP/HCM, garantizar
-   el estándar contable/legal vigente.
+1. **Zero-Bureaucracy**: No repetir información de stack o infraestructura que no haya cambiado entre sprints.
+2. **E2E primero**: Priorizar escenarios funcionales de punta a punta. Los casos unitarios de backend se limitan a lógica de negocio compleja no cubierta por flujos E2E. Justificar toda excepción.
+3. **Sin estimaciones de esfuerzo**: Las horas viven en el sistema de planificación del equipo, no aquí.
+4. **Sin historial de revisiones**: El historial vive en Git.
+5. **Compliance obligatorio**: Si el dominio es contable, fiscal o laboral, incluir validaciones regulatorias específicas y vigentes.
+6. **Trazabilidad total**: Cada caso debe ser trazable a un criterio de aceptación del documento fuente. Sin FR documentado → sin caso de prueba.
+7. **Alineación SIESA**: Si el sistema host es SIESA ERP/HCM, garantizar el estándar contable/legal vigente.
+8. **Lenguaje limpio**: Output en lenguaje natural, sin HTML embebido, sin pseudocódigo en descripciones de casos.
 
 ---
 
 > **Nota:** Documento vivo. Actualizar al finalizar cada feature o al identificar nuevos riesgos.
-> El historial de versiones vive en el repositorio Git — no se replica aquí.
+> El historial de versiones vive en el repositorio Git.
 
 ---