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

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

@@ -1,24 +1,25 @@
 ---
 name: quality-process
-description: "QA Quality Process — Phase 1 Planning (BMAD V6.0 test design), Phase 2 Design (QA Test Plan & Strategy), Phase 3 AgileTest Registration (push validated design to Jira/AgileTest), Phase 4 DOR Gate (verify Definition of Ready checklist), or Phase 5 Playwright Implementation (generate E2E test code from test-cases.csv gaps). Asks at startup which phase to execute."
+description: "QA Quality Process — Phase 1 Planning (QA Test Plan & Strategy), Phase 2 DOR Gate (verify Definition of Ready checklist), Phase 3 Design (BMAD V7.8 test design), Phase 4 QA Data Generation (provision synthetic test data in the real DB via MCP from the Fase 3 test-cases.csv, reusing existing QA data before generating), Phase 5 AgileTest Registration (push validated design to Jira/AgileTest), or Phase 6 E2E Implementation + Execution (Agente Ejecutor E2E: from test-design.yml generate, run and report Playwright tests via the Kit). Asks at startup which phase to execute."
 web_bundle: true
-version: 1.1.0
+version: 1.3.0
 parameters:
   feature_id:
-    description: 'Opcional: Feature ID a procesar (ej: "feature-1"). Solo aplica para la Fase 2 — Diseño.'
+    description: 'Opcional: Feature ID a procesar (ej: "feature-1"). Solo aplica para la Fase 3 — Diseño.'
     required: false
     type: string
 ---
 
 # Proceso de Calidad QA
 
-**Goal:** Ejecutar el proceso de calidad QA del proyecto en la fase seleccionada. El proceso tiene cinco fases complementarias ejecutadas por el QA asignado:
+**Goal:** Ejecutar el proceso de calidad QA del proyecto en la fase seleccionada. El proceso tiene seis fases complementarias ejecutadas por el QA asignado:
 
-- **Fase 1 — Planeación:** Genera el Plan de Pruebas y Estrategia QA (alcance, riesgos R=IxP, Data Buckets, criterios Go/No-Go) a partir de los documentos fuente del proyecto.
-- **Fase 2 — Diseño:** Genera el diseño de pruebas técnico (trazabilidad, Gatekeeper, FAC, Puntos Ciegos, Matriz Integral, TSR) usando BMAD V6.0 sobre los features del proyecto.
-- **Fase 3 — Registro AgileTest:** Empuja el diseño validado a Jira/AgileTest con trazabilidad completa.
-- **Fase 4 — DOR Gate:** Verifica que el requerimiento cumple el Definition of Ready (DoR) antes de iniciar cualquier labor de construcción. Genera reporte pass/fail por ítem.
-- **Fase 5 — Implementación Playwright:** Toma el `test-cases.csv` generado en Fase 2, identifica automáticamente los tests sin cobertura en los spec files existentes, clasifica cada test por tecnología (Playwright E2E, Vitest Unit, .NET xUnit), genera el código Playwright para los gaps, lo inyecta en los spec files con aprobación humana y actualiza el CSV.
+- **Fase 1 — Planeación:** Genera el Plan de Pruebas y Estrategia QA (alcance, riesgos R=IxP, ambiente & datos de prueba, criterios Go/No-Go) a partir de los documentos fuente del proyecto. *(Los Data Buckets por feature se movieron al agente de datos — Fase 4.)*
+- **Fase 2 — DOR Gate:** Verifica que el requerimiento cumple el Definition of Ready (DoR) antes de iniciar cualquier labor de construcción. Genera reporte pass/fail por ítem.
+- **Fase 3 — Diseño:** Genera el diseño de pruebas técnico (trazabilidad, Gatekeeper, FAC, Puntos Ciegos, Matriz Integral, TSR) usando BMAD V7.8 (modos Feature/Completo, niveles FU/INT/INT-X/E2E/E2E-X/REG/EC) sobre los features del proyecto.
+- **Fase 4 — Generación de Datos QA:** Toma el `test-cases.csv` generado en Fase 3 y, conectándose a la base de datos real vía MCP (PostgreSQL/SQL Server), infiere y confirma el negocio, reutiliza datos QA existentes antes de generar; provisiona únicamente los datos sintéticos faltantes con integridad referencial, bajo aprobación humana, y entrega 3 artefactos en disco: `test-data.md` (relación caso→datos agrupada por seed, lista para Playwright), `seed.sql` idempotente y `rollback.sql` acotado a la corrida. Delega en la skill `sa-qa-data-generator`.
+- **Fase 5 — Registro AgileTest:** Empuja el diseño validado a Jira/AgileTest con trazabilidad completa.
+- **Fase 6 — Implementación + Ejecución E2E:** Actúa como **Agente Ejecutor E2E**: consume el `test-design.yml` (Fase 3) + `test-data.md` (Fase 4), enriquece con el architecture brief, genera los `.spec.ts` con el ciclo Planner→Generator→Healer sobre el Kit Playwright, los promueve con aprobación humana, **ejecuta** la suite y deja los reportes (Allure/Monocart/test-results) listos para el RCA. Fallback a `test-cases.csv` si no hay YAML.
 
 **Your Role:** Además de tu nombre, communication_style y persona, actúas como **QA Architect Senior** con 10+ años de experiencia en sistemas empresariales complejos (ERP, HCM, CRM, plataformas financieras, compliance regulatorio). Piensas como defensor del negocio, no solo como técnico de pruebas. Trabajas bajo la metodología BMAD v6.0.
 
@@ -49,7 +50,8 @@ Cargar y leer la configuración completa desde `{project-root}/_bmad/bmm/config.
 
 ### 2. Phase Selection (OBLIGATORIO — Primer paso interactivo)
 
-Preguntar al usuario qué fase del proceso de calidad desea ejecutar:
+Preguntar al usuario qué fase del proceso de calidad desea ejecutar. Mostrar el menú
+descriptivo de las 6 fases y capturar la selección:
 
 ```
 🔎 Proceso de Calidad QA — Selección de Fase
@@ -58,94 +60,50 @@ Preguntar al usuario qué fase del proceso de calidad desea ejecutar:
                             Matriz de Riesgo (R = I×P), Data Buckets y criterios Go/No-Go.
                             (Requiere: PRD, Arquitectura, Épicas u otros documentos fuente)
 
-  2️⃣  Diseño             — Diseño técnico de pruebas: Gatekeeper, FAC en Gherkin,
-                            Puntos Ciegos, Matriz Integral 360°, TSR y CSV de casos.
-                            (Requiere: feature-status.yaml + archivos epic_source)
-
-  3️⃣  Registro AgileTest — Empuja el diseño validado a Jira/AgileTest:
-                            Requisitos, Test Cases con Steps, Planes de Prueba (PPR),
-                            Planes de Ejecución (PEP) y links de trazabilidad.
-                            (Requiere: Fase 2 completada y validada por el equipo QA)
-
-  4️⃣  DOR Gate           — Verifica el Definition of Ready del requerimiento:
+  2️⃣  DOR Gate           — Verifica el Definition of Ready del requerimiento:
                             completitud PRD ≥ 90%, consistencia con arquitectura,
                             métricas definidas, contratos de interfaz e inyección de contexto.
                             Genera reporte pass/fail por ítem.
                             (Requiere: PRD.md + Architecture.md)
 
-  5️⃣  Implementación Playwright
-                          — Gap analysis automático entre test-cases.csv y spec files
-                            existentes. Clasifica tests por tecnología (Playwright/Vitest/.NET),
-                            genera código E2E para los gaps, lo inyecta en los spec files
-                            con aprobación humana y actualiza el Estado del CSV.
-                            (Requiere: Fase 2 completada — test-cases.csv + spec files en frontend/)
+  3️⃣  Diseño             — Diseño técnico de pruebas: Gatekeeper, FAC en Gherkin,
+                            Puntos Ciegos, Matriz Integral 360°, TSR y CSV de casos.
+                            (Requiere: feature-status.yaml + archivos epic_source)
 
-¿Qué fase deseas ejecutar?
-```
+  4️⃣  Generación de Datos QA
+                          — Provisiona datos sintéticos en la base de datos real (vía MCP)
+                            para que los casos diseñados en Fase 3 puedan ejecutarse.
+                            Infiere y confirma el negocio, reutiliza datos QA existentes antes
+                            de generar, inserta solo lo faltante con aprobación humana y entrega
+                            3 artefactos: test-data.md, seed.sql y rollback.sql.
+                            (Requiere: Fase 3 completada — test-cases.csv + MCP de BD conectado)
 
-**STEP 1 — Grupo de fase** (AskUserQuestion, 2 opciones):
+  5️⃣  Registro AgileTest — Empuja el diseño validado a Jira/AgileTest:
+                            Requisitos, Test Cases con Steps, Planes de Prueba (PPR),
+                            Planes de Ejecución (PEP) y links de trazabilidad.
+                            (Requiere: Fase 3 completada y validada por el equipo QA)
 
-```json
-{
-  "questions": [
-    {
-      "question": "¿Qué grupo de fases deseas ejecutar?",
-      "header": "Selección de Fase",
-      "multiSelect": false,
-      "options": [
-        {
-          "label": "Fases 1–4 (QA Tradicional)",
-          "description": "Planeación, Diseño, Registro AgileTest o DOR Gate"
-        },
-        {
-          "label": "Fase 5 — Implementación Playwright",
-          "description": "Gap analysis CSV↔spec files: genera código E2E para los tests sin cobertura, inyecta en spec files con gate de aprobación y actualiza el CSV"
-        }
-      ]
-    }
-  ]
-}
-```
+  6️⃣  Implementación + Ejecución E2E
+                          — Agente Ejecutor E2E: del test-design.yml genera los .spec.ts
+                            (Planner→Generator→Healer sobre el Kit Playwright), los promueve
+                            con aprobación humana, EJECUTA la suite y deja reportes
+                            (Allure/Monocart/test-results) listos para el RCA.
+                            (Requiere: Fase 3 — test-design.yml/csv [+ Fase 4 test-data.md])
 
-- Si selecciona **Fase 5 — Implementación Playwright**: continuar directamente con la sección `FASE 5 — IMPLEMENTACIÓN PLAYWRIGHT`
-- Si selecciona **Fases 1–4**: continuar con el **STEP 2** a continuación
+¿Qué fase deseas ejecutar? (responde con el número 1–6)
+```
 
-**STEP 2 — Fase específica** (solo si eligió "Fases 1–4" en el STEP 1):
+**Captura de la selección (lista plana de 6):**
 
-```json
-{
-  "questions": [
-    {
-      "question": "¿Cuál fase QA deseas ejecutar?",
-      "header": "Fase QA",
-      "multiSelect": false,
-      "options": [
-        {
-          "label": "Fase 1 — Planeación",
-          "description": "Plan & Estrategia QA: alcance, riesgos R=I×P, Data Buckets, criterios Go/No-Go"
-        },
-        {
-          "label": "Fase 2 — Diseño",
-          "description": "Diseño técnico de pruebas: Gatekeeper, FAC en Gherkin, Puntos Ciegos, Matriz Integral 360°, TSR y CSV de casos"
-        },
-        {
-          "label": "Fase 3 — Registro AgileTest",
-          "description": "Empujar diseño validado a Jira/AgileTest: Requisitos, TCs con Steps, Planes (PPR), Ejecuciones (PEP) y links de trazabilidad"
-        },
-        {
-          "label": "Fase 4 — DOR Gate",
-          "description": "Verificar Definition of Ready: completitud PRD ≥ 90%, consistencia arquitectura, métricas, contratos e inyección de contexto. Genera dor-report.md con resultado pass/fail."
-        }
-      ]
-    }
-  ]
-}
-```
+Como `AskUserQuestion` admite un máximo de 4 opciones, la selección se hace por **texto**:
+el usuario responde con el número de la fase (1–6) o su nombre. Enrutar según la respuesta:
 
-- Si selecciona **Fase 1 — Planeación**: continuar con la sección `FASE 1 — PLANEACIÓN`
-- Si selecciona **Fase 2 — Diseño**: continuar con la sección `FASE 2 — DISEÑO`
-- Si selecciona **Fase 3 — Registro AgileTest**: continuar con la sección `FASE 3 — REGISTRO AGILETEST`
-- Si selecciona **Fase 4 — DOR Gate**: continuar con la sección `FASE 4 — DOR GATE`
+- **1 → Planeación:** continuar con la sección `FASE 1 — PLANEACIÓN`
+- **2 → DOR Gate:** continuar con la sección `FASE 2 — DOR GATE`
+- **3 → Diseño:** continuar con la sección `FASE 3 — DISEÑO`
+- **4 → Generación de Datos QA:** continuar con la sección `FASE 4 — GENERACIÓN DE DATOS QA`
+- **5 → Registro AgileTest:** continuar con la sección `FASE 5 — REGISTRO AGILETEST`
+- **6 → Implementación + Ejecución E2E:** continuar con la sección `FASE 6 — IMPLEMENTACIÓN + EJECUCIÓN E2E`
 
 ---
 
@@ -157,12 +115,42 @@ Generar un Plan de Pruebas y Estrategia QA completo siguiendo la metodología BM
 
 ---
 
-### F1.1: Auto Document Discovery (Zero User Interaction)
+### F1.0: Captura de Insumos del Sprint (GATE inicial — OBLIGATORIO)
+
+> **Principio:** La planeación se hace **sobre el alcance del sprint**, no sobre todo el proyecto.
+> NO inicies una lectura masiva del repositorio. Primero pregunta al usuario qué entra al sprint
+> y **acota** el descubrimiento de documentos (F1.1) a ese alcance.
+
+Antes de buscar o leer cualquier documento, **detente y pregunta** al usuario por los insumos
+específicos del sprint usando AskUserQuestion (o entrada libre si el usuario prefiere pegarlos):
+
+```
+🎯 Antes de planear, necesito el alcance de este sprint. Indícame:
+
+  1. Épicas en alcance     — IDs o nombres de las épicas que entran al sprint
+  2. Features a probar     — features/funcionalidades concretas a cubrir con QA
+  3. Alcance técnico       — servicios/módulos/APIs involucrados y lo que queda Fuera de Alcance
+
+Puedes pegar las rutas de los documentos relevantes o escribir el alcance directamente.
+```
+
+Almacenar las respuestas en `sprint_scope` con: `epicas_en_alcance`, `features_a_probar`,
+`alcance_tecnico`, `fuera_de_alcance`.
+
+- Si el usuario **no** conoce el alcance todavía o pide el comportamiento anterior, puede responder
+  "todo el proyecto" → en ese caso F1.1 hace el descubrimiento completo (modo legacy).
+- **No avances a F1.1 sin una respuesta.** Este es un gate de detención obligatoria.
+
+---
+
+### F1.1: Document Discovery (acotado al alcance del sprint)
 
-Buscar y leer automáticamente los documentos fuente desde sus rutas fijas. Notificar:
+Buscar y leer los documentos fuente, **filtrando por el `sprint_scope` capturado en F1.0**: cargar
+únicamente las épicas/features declaradas y los documentos del alcance técnico indicado, no el
+repositorio completo. Si `sprint_scope` = "todo el proyecto", cargar todo (modo legacy). Notificar:
 
 ```
-🔍 Buscando documentos fuente del proyecto...
+🔍 Buscando documentos fuente acotados al alcance del sprint...
 ```
 
 #### Documento 1 — PRD / Requerimientos
@@ -195,7 +183,9 @@ Buscar con Glob en este orden:
 3. `{planning_artifacts}/*epic*.md`
 4. `{implementation_artifacts}/*epic*.md`
 
-Si encontrado: leer contenido completo de todos los epic_source files y concatenar → almacenar en `doc_epics`
+Si encontrado: leer el contenido de los epic_source files y concatenar → almacenar en `doc_epics`.
+**Acotar por `sprint_scope.epicas_en_alcance`:** si el usuario declaró épicas específicas en F1.0,
+cargar SOLO esas épicas (no todas las del proyecto). Si declaró "todo el proyecto", cargar todas.
 Si no encontrado: `doc_epics = null`
 
 #### Documento 4 — Contexto Normativo / Regulatorio
@@ -328,14 +318,17 @@ Notificar al usuario:
 📋 Generando Plan de Pruebas BMAD v3.0...
 ```
 
-Ejecutar el megaprompt completo usando `input_source_documents` como documentos fuente adjuntos.
+Ejecutar el megaprompt completo usando `input_source_documents` como documentos fuente adjuntos
+y `sprint_scope` (capturado en F1.0) como alcance del plan: la Sección 3 (Alcance de Pruebas) debe
+reflejar las `features_a_probar` y el `fuera_de_alcance` declarados por el usuario, no inferir el
+alcance del barrido completo del proyecto.
 
-El plan de pruebas generado debe incluir todas las secciones del prompt:
+El plan de pruebas generado debe incluir todas las secciones del prompt (v3.1):
 - Sección 1: Información General
 - Sección 2: Objetivo & DoR / DoD
-- Sección 3: Alcance de Pruebas
-- Sección 4: Estrategia de Pruebas
-- Sección 5: Ambiente & Datos de Prueba (Data Buckets por feature)
+- Sección 3: Alcance de Pruebas (Features incluidas y Fuera de Alcance)
+- Sección 4: Estrategia de Pruebas (E2E-first; unitarias solo para lógica compleja)
+- Sección 5: Ambiente & Datos de Prueba
 - Sección 6: Matriz de Riesgo Predictivo (R = I × P)
 - Sección 7: Criterios de Entrada / Salida (Go / No-Go)
 
@@ -377,9 +370,9 @@ Presentar al usuario:
 📋 Secciones incluidas:
   1. Información General
   2. Objetivo & DoR / DoD (Checklist de entrada y salida)
-  3. Alcance de Pruebas (Features incluidas y excluidas)
-  4. Estrategia de Pruebas (Tipos, técnicas, integración Human–AI)
-  5. Ambiente & Datos de Prueba (Data Buckets por feature)
+  3. Alcance de Pruebas (Features incluidas y Fuera de Alcance)
+  4. Estrategia de Pruebas (Tipos E2E-first, técnicas de diseño)
+  5. Ambiente & Datos de Prueba
   6. Matriz de Riesgo Predictivo (Riesgos identificados por feature)
   7. Criterios de Entrada / Salida (Go / No-Go checklist)
 
@@ -390,621 +383,888 @@ Presentar al usuario:
    con información específica de tu sprint/equipo.
 ```
 
-**⚠️ NO sugerir continuar con Fase 2 ni ninguna acción adicional. El workflow termina aquí. El equipo de QA debe revisar y validar los documentos generados antes de ejecutar la Fase 2 — Diseño.**
+**⚠️ NO sugerir continuar con ninguna otra fase ni acción adicional. El workflow termina aquí. El equipo de QA debe revisar y validar los documentos generados antes de continuar con las siguientes fases.**
 
 ---
 
-## FASE 2 — DISEÑO
+## FASE 2 — DOR GATE
 
 ### Objetivo
 
-Generar el diseño técnico de pruebas completo aplicando la metodología BMAD V6.0. Produce trazabilidad funcional, criterios de aceptación en Gherkin, puntos ciegos por arquetipo, Matriz Integral de Pruebas 360° y Test Summary Report.
+Verificar que el requerimiento cumple el **Definition of Ready (DoR)** antes de iniciar cualquier labor de construcción o proceso de calidad. Evalúa los ítems activos del checklist DoR BMAD Enterprise y genera un reporte `dor-report.md` con resultado pass/fail por ítem, detalle de cada fallo y acción correctiva requerida.
+
+**Principio:** Si el Índice de Completitud es inferior al 90%, el sistema activa BLOQUEO TOTAL. El agente tiene prohibido iniciar cualquier labor de construcción.
 
 ---
 
-### F2.1: Feature Selection (Interactivo)
+### F2.1: Auto Document Discovery (Zero User Interaction)
 
-**Capture feature_id parameter** si fue provisto en los argumentos del comando.
+Buscar y leer automáticamente los documentos necesarios para evaluar el DoR:
 
-1. **Cargar el registro de features:**
-   - Leer: `{implementation_artifacts}/feature-status.yaml`
-   - Parsear YAML para extraer todos los features: `[{id, epic_source, status, last_update}, ...]`
+```
+🔍 DOR Gate — Buscando documentos fuente...
+```
 
-2. **Si `feature_id` fue provisto como parámetro:**
-   - Validar que existe en el registro; si no, listar IDs disponibles y detener
-   - `filtered_features = [ese feature]`
-   - Notificar: `✅ Feature seleccionado por parámetro: {feature_id}`
-   - Ir a F2.2
+#### Documento 1 — PRD / Requerimientos (OBLIGATORIO)
 
-3. **Si no se proveyó parámetro, preguntar al usuario:**
+El PRD siempre vive en `{planning_artifacts}/prd` — puede ser un archivo o una carpeta:
 
-   Mostrar features disponibles:
-   ```
-   📋 Features disponibles en el proyecto:
+**Caso A — archivo único:**
+- Buscar: `{planning_artifacts}/prd.md`
+- Si encontrado: leer contenido completo → almacenar en `dor_prd`
 
-   {por cada feature:
-     "  • {feature.id}  [{feature.status}]  →  {feature.epic_source}"
-   }
-   ```
+**Caso B — carpeta con múltiples archivos:**
+- Buscar con Glob: `{planning_artifacts}/prd/**/*.md`
+- Si encontrado: leer y concatenar el contenido de todos los archivos `.md` → almacenar en `dor_prd`
 
-   Usar AskUserQuestion:
-   ```json
-   {
-     "questions": [
-       {
-         "question": "¿Qué features deseas analizar?",
-         "header": "Selección de Features — Fase 2 Diseño",
-         "multiSelect": false,
-         "options": [
-           {
-             "label": "Todos los features",
-             "description": "Procesar todos los features del registro"
-           },
-           {
-             "label": "Seleccionar features específicos",
-             "description": "Elegir uno o más features por ID"
-           }
-         ]
-       }
-     ]
-   }
-   ```
+Si ninguno de los dos casos produce contenido: `dor_prd = null` → **BLOQUEO**: sin PRD no se puede evaluar el DoR
 
-   **Si "Todos los features":**
-   - `filtered_features = all_features`
-   - Notificar: `✅ Se procesarán todos los features ({count} features)`
+#### Documento 2 — Épicas / Historias de Usuario (para P1 y P2)
 
-   **Si "Seleccionar features específicos":**
-   - Si ≤ 4 features: usar AskUserQuestion multiSelect con una opción por feature
-   - Si > 4 features: pedir vía texto: "Ingresa los IDs separados por comas (ej: feature-1,feature-3):"
-   - Validar cada ID contra el registro
-   - `filtered_features = features encontrados`
-   - Notificar:
-     ```
-     ✅ Features seleccionados ({count}):
-     {por cada feature en filtered_features:
-       "  • {feature.id} → {feature.epic_source}"
-     }
-     ```
+El DOR se evalúa sobre features que ya tienen épicas creadas. Cargar usando el mismo patrón que las otras fases:
 
-4. Almacenar `filtered_features` en memoria.
+1. Leer `{implementation_artifacts}/feature-status.yaml`
+2. Por cada feature, leer su archivo `epic_source` y concatenar contenido → almacenar en `dor_epics`
+
+Si `feature-status.yaml` no existe:
+- Buscar con Glob: `{planning_artifacts}/*epic*.md`
+- Si encontrado: leer y concatenar → almacenar en `dor_epics`
+- Si no encontrado: `dor_epics = null` (continuar sin épicas — P1 se evalúa solo contra el PRD)
 
 ---
 
-### F2.2: Automatic Data Loading (Zero User Interaction)
+#### Documento 3 — Arquitectura (OBLIGATORIO para P2)
 
-**CARGAR TODOS LOS INPUTS AUTOMÁTICAMENTE:**
+Buscar con Glob en este orden:
+1. `{planning_artifacts}/architecture.md`
+2. `{planning_artifacts}/architecture-decision.md`
+3. `{planning_artifacts}/*architecture*.md`
+4. `{planning_artifacts}/*adr*.md`
 
-1. **INPUT 1 - PROYECTO:**
-   - Cargar desde config: `{project_name}`
-   - Almacenar como: `input_proyecto`
+Si encontrado: leer contenido completo → almacenar en `dor_architecture`
+Si no encontrado: `dor_architecture = null` → P2 se marcará como NO EVALUABLE
 
-2. **INPUT 2 - FEATURES / HISTORIAS DE USUARIO:**
-   - Usar `filtered_features` de F2.1
-   - Por cada feature, leer su archivo `epic_source` y concatenar contenido
-   - Almacenar contenido combinado como: `input_epicas`
+#### Documentos P4, P5, P8 — No cargados (ítems no evaluables)
 
-3. **INPUT 3 - METAS DE NEGOCIO (PRD):**
-   - Buscar en `{planning_artifacts}/`: `prd.md`, `PRD.md`, `product-requirements.md` o similar
-   - Si encontrado: leer y almacenar como `input_metas`
-   - Si no encontrado: extraer metas de negocio de los archivos epic_source → `input_metas`
+- **P4 (Contratos de Interfaz):** La ruta, formato y proceso de subida del esquema
+  OpenAPI/Swagger aún no están definidos. No se carga ningún documento.
+- **P5 (Estimación / Tamaño):** Descartado por ahora (decisión reunión 26-may-2026) —
+  la estimación de esfuerzo/tamaño no se evalúa con IA. No se carga ningún documento.
+- **P8 (Autodescubrimiento / Mapeo de esquemas de BD):** Descartado por ahora
+  (decisión reunión 26-may-2026) — no está definido cómo mapear esquemas de BD en el DoR.
+  No se carga ningún documento.
 
-4. **INPUT 4 - STACK TECNOLÓGICO:**
-   - Cargar desde: `{project-root}/_siesa-agents/bmm/data/company-standards/technology-stack.md`
-   - Almacenar como: `input_stack`
+#### Documento P6 — Plan de Pruebas
 
-5. **INPUT 5 - PLAN DE PRUEBAS (Fase 1 — Planeación):**
-   - Buscar la carpeta más reciente en `{implementation_artifacts}/quality-process/planeacion/`:
-     - Listar todas las subcarpetas con patrón `test-plan-*`
-     - Ordenar por nombre descendente (el timestamp garantiza el orden cronológico)
-     - Tomar la primera → es la ejecución más reciente
-   - Si encontrada: leer `test-plan.md` → almacenar en `input_test_plan`
-   - Si no encontrada: `input_test_plan = null`
+Listar todos los directorios en `{implementation_artifacts}/quality-process/planeacion/`
+que sigan el patrón `test-plan-*`. Ordenar descendente por nombre (el timestamp garantiza orden cronológico).
+Almacenar la lista como `dor_test_plan_options` para que P6 la use en la selección interactiva.
 
-**Notificar al usuario:**
+Si no existe ningún directorio con ese patrón: `dor_test_plan_options = []` (P6 marcará NO_PASA).
 
-```
-🎯 BMAD V6.0 — Fase 2: Diseño de Pruebas
+#### Documento P7 — Cargar project-context
 
-✅ Iniciando análisis automático...
+Buscar `_bmad-output/project-context.md`. Si existe, anotar la ruta como `dor_project_context`.
+Si no existe, `dor_project_context = null` (P7 marcará NO_PASA automáticamente).
 
-📋 Datos cargados:
-  • Proyecto: {input_proyecto}
-  • Features registry: {implementation_artifacts}/feature-status.yaml
-  • Features seleccionados: [lista de feature IDs]
-  • PRD: [ruta encontrada o "extraído de epic_source files"]
-  • Stack Tecnológico: _siesa-agents/bmm/data/company-standards/technology-stack.md
-  • Plan de Pruebas (Fase 1): [ruta encontrada o "No encontrado — se continuará sin ese contexto"]
+#### Validación mínima
+
+Si `dor_prd = null`: detener con mensaje:
 
-🚀 Ejecutando las 4 fases de análisis BMAD V6.0...
 ```
+❌ No se encontró el PRD en las rutas estándar del proyecto.
 
----
+Ruta esperada: {planning_artifacts}/prd.md (y variantes)
+
+El DOR Gate requiere un PRD para ejecutarse. Por favor sube el PRD
+al repositorio y vuelve a ejecutar la Fase 2.
+```
 
-### F2.3: Load and Execute Megaprompt
+#### Reporte de documentos encontrados
 
-1. **Cargar el Megaprompt:**
-   - Leer el archivo completo: `{workflow_root}/prompts/prompt_design_test.md`
-   - Este prompt transforma al agente en Principal QA Architect
+Mostrar al usuario:
 
-2. **Inyectar inputs:**
-   Reemplazar la sección `[INPUT]` del prompt:
-   ```
-   # [INPUT]:
-   - **PROYECTO**: {input_proyecto}
-   - **FEATURES / HISTORIAS DE USUARIO**: {input_epicas}
-   - **METAS DE NEGOCIO (PRD)**: {input_metas}
-   - **STACK TECNOLÓGICO**: {input_stack}
-   - **PLAN DE PRUEBAS (contexto)**: {input_test_plan}
-   ```
+```
+📋 DOR Gate — Documentos cargados:
 
-3. **Ejecutar las 4 FASES secuencialmente:**
-   - FASE 1: GATEKEEPER GRANULAR Y LIMPIEZA DE BACKLOG
-   - FASE 2: EL ESCALÓN DE CRITERIOS (FAC) en Gherkin
-   - FASE 3: DETECCIÓN DE PUNTOS CIEGOS (Simulación Universal)
-   - FASE 4: INGENIERÍA DE DISEÑO (ISO 29119-4) Y CALCULADORA DE RIESGO
+  {✅|❌} PRD:          {ruta relativa o "No encontrado — BLOQUEANTE"}
+  {✅|⚠️} Épicas:       {ruta(s) relativa(s) o "No encontrado — P1/P2 sin contexto de stories"}
+  {✅|⚠️} Arquitectura: {ruta relativa o "No encontrado — P2 no evaluable"}
+  ⏭  API Schema:      No evaluable — ruta/formato pendiente de definición (P4)
+  ⏭  Estimación/Tamaño: No evaluable — descartado por ahora (P5)
+  ⏭  Mapeo esquemas BD: No evaluable — descartado por ahora (P8)
+  {✅|⚠️} Plan de Pruebas: {implementation_artifacts}/quality-process/planeacion/test-plan-YYYY-MM-DD-HHmmss/test-plan.md ({N} plan(es) encontrado(s) — P6 pedirá selección)
+  {✅|⚠️} Project Context: {ruta relativa o "No encontrado — P7 marcará NO_PASA"}
 
-   **Generar outputs en FORMATO EXACTO:**
-   - I. REPORTE DEL GATEKEEPER (GRANULAR)
-   - II. DEFINICIÓN DE FEATURES Y CRITERIOS MAESTROS (FAC) EN GHERKIN
-   - III. PUNTOS CIEGOS DETECTADOS POR FEATURE
-   - IV. MATRIZ INTEGRAL DE PRUEBAS (DISEÑO 360°)
-   - V. INFORME TSR (TEST SUMMARY REPORT)
-   - APÉNDICE: MATRIZ DE TRAZABILIDAD
+🚀 Ejecutando evaluación DoR...
+```
+
+Proceder directamente a F2.2 sin esperar confirmación del usuario.
 
 ---
 
-### F2.4: Save Output
+### F2.2: Cargar y Ejecutar Megaprompt DOR
 
-**Crear estructura de carpeta con timestamp:**
+**Step F2.2.1: Cargar prompt**
 
-1. Generar timestamp: `YYYY-MM-DD-HHmmss` (ej: `2026-03-25-143052`)
-2. Crear estructura de carpetas:
-   - Raíz: `{implementation_artifacts}/quality-process/diseno/test-design-YYYY-MM-DD-HHmmss/`
-   - Shards: `{implementation_artifacts}/quality-process/diseno/test-design-YYYY-MM-DD-HHmmss/shards/`
-3. Guardar los 5 documentos dentro de la subcarpeta `shards/`:
+Leer el archivo completo: `{workflow_root}/prompts/prompt_dor_gate.md`
 
-**Documento 1:** `shards/test-design-phase1-gatekeeper.md` (Fase 1 — Clasificación Gatekeeper)
-**Documento 2:** `shards/test-design-phase2-fac.md` (Fase 2 — Features y FAC en Gherkin)
-**Documento 3:** `shards/test-design-phase3-blind-spots.md` (Fase 3 — Puntos Ciegos)
-**Documento 4:** `shards/test-design-phase4-test-matrix.md` (Fase 4 — Matriz Integral)
-**Documento 5:** `shards/test-design-phase5-tsr.md` (Fase 5 — TSR + Trazabilidad)
+**Step F2.2.2: Inyectar inputs**
 
-**Frontmatter para todos los documentos:**
-```yaml
----
-workflow: quality-process
-phase: diseno
-version: 1.0.0
-methodology: BMAD V6.0 MegaPrompt
-generated_date: [ISO 8601 date]
-project_name: {input_proyecto}
-input_documents:
-  epics: [ruta(s) relativa(s)]
-  prd: [ruta relativa o null]
-  technology_stack: _siesa-agents/bmm/data/company-standards/technology-stack.md
-  test_plan: [ruta relativa o null]
----
+```
+# [INPUT DOR]:
+- **PRD**: {dor_prd}
+- **ÉPICAS / HISTORIAS DE USUARIO**: {dor_epics}
+- **ARQUITECTURA**: {dor_architecture}
 ```
 
-**Exportar casos de prueba a CSV (Siesa FT-SD-007 v5.0):**
-
-Después de guardar `shards/test-design-phase4-test-matrix.md`:
+**Step F2.2.3: Ejecutar evaluación**
 
-1. Leer el contenido completo del archivo generado
-2. Identificar secciones `## F# — [Nombre Feature]` → `ID Épica` formato `EPIC-POS-F{n}`
-3. Parsear todas las filas de tabla `| TC-` extrayendo las 12 columnas de la matriz
-4. Mapear a las 13 columnas del formato Siesa CSV:
+Notificar al usuario:
 
-   | Columna Matriz | → Columna CSV |
-   |---|---|
-   | Header `## F{n} — ...` | `ID Épica` (ej: `EPIC-POS-F1`) |
-   | `ID` | `ID Caso de Prueba` |
-   | `Escenario` | `Título` |
-   | `Funcionalidad` + `: ` + `Escenario` | `Descripción Completa` |
-   | `Precondiciones` | `Precondiciones` |
-   | `Pasos` | `Pasos de Ejecución` |
-   | `Resultado Esperado` | `Resultados Esperados` |
-   | `Estrategia` | `Tipo prueba` |
-   | _(vacío)_ | `Fecha Ejecución` |
-   | `"Not Started"` | `Estado` |
-   | _(vacío)_ | `ID Defecto` |
-   | _(vacío)_ | `Descripción Fallo` |
-   | `Level: [Level] \| Technique: [Technique] \| Risk: [Risk] \| Priority: [Priority]` | `Notas` |
-
-5. **🚨 CRÍTICO — Compatibilidad Windows CSV:**
-   - ✅ Usar **Write tool ONLY** — NUNCA bash, cat, echo, sed, awk
-   - ✅ Construir el **string CSV completo en memoria** y luego llamar Write una vez
-   - ✅ Envolver **TODOS los campos** en comillas dobles
-   - ✅ Escapar comillas internas duplicándolas: `"` → `""`
-   - ✅ Encoding: UTF-8
+```
+⚙️ Evaluando ítems del DoR...
+   • P1: Índice de Completitud PRD (LLM scoring)
+   • P2: Consistencia PRD ↔ Arquitectura
+   • P3: Negocio y Valor (métricas/objetivos)
+   • P6: Plan de Pruebas (selección interactiva + 7 secciones)
+   • P7: Inyección de Contexto (project-context.md)
+   ─────────────────────────────────────────
+   ⏭  P4: Contratos de Interfaz — NO EVALUABLE (ruta/formato pendiente)
+   ⏭  P5: Estimación / Tamaño — NO EVALUABLE (descartado por ahora)
+   ⏭  P8: Mapeo de esquemas de BD — NO EVALUABLE (descartado por ahora)
+```
 
-6. Guardar como: `{implementation_artifacts}/quality-process/diseno/test-design-YYYY-MM-DD-HHmmss/test-cases.csv` (en la raíz, NO en shards/)
+Ejecutar el prompt con los inputs cargados. El prompt produce un JSON de resultados estructurado con el resultado de cada ítem.
 
 ---
 
-### F2.5: Completion
+### F2.3: Guardar Output
 
-Presentar al usuario:
+**Generar timestamp:** `YYYY-MM-DD-HHmmss`
 
+**Ruta de salida:**
+```
+{implementation_artifacts}/quality-process/dor/dor-report-YYYY-MM-DD-HHmmss/dor-report.md
 ```
-✅ FASE 2 — DISEÑO COMPLETADA
 
-📁 Carpeta: {implementation_artifacts}/quality-process/diseno/test-design-YYYY-MM-DD-HHmmss/
+**Frontmatter del documento generado:**
+```yaml
+---
+workflow: quality-process
+phase: dor
+version: 1.0.0
+methodology: BMAD DOR Gate
+generated_date: [ISO 8601]
+project_name: {project_name}
+resultado: PASA | NO PASA
+items_evaluados:
+  - P1
+  - P2
+  - P3
+  - P6
+  - P7
+items_no_evaluados:
+  P4: pendiente — ruta y formato del esquema API por definir
+  P5: descartado por ahora — estimación/tamaño no se evalúa con IA (decisión 26-may-2026)
+  P8: descartado por ahora — mapeo de esquemas de BD no definido (decisión 26-may-2026)
+source_documents:
+  prd: [ruta relativa o null]
+  architecture: [ruta relativa o null]
+  api_schema: [ruta relativa o null]
+  project_context: [ruta relativa o null]
+  test_plan: [ruta relativa o null]
+---
+```
 
-📄 Archivos en raíz:
-  • test-design.md   — Documento unificado (phases 1–5)
-  • test-cases.csv   — Casos exportados (Siesa FT-SD-007 v5.0)
+**Cuerpo del documento** — el título debe ser lo primero visible tras el frontmatter.
+El bloque JSON de resultados va al final dentro de un `<details>` colapsado:
 
-📂 shards/ (documentos individuales por fase):
-  • test-design-phase1-gatekeeper.md
-  • test-design-phase2-fac.md
-  • test-design-phase3-blind-spots.md
-  • test-design-phase4-test-matrix.md
-  • test-design-phase5-tsr.md
+```markdown
+# DOR Report — {project_name}
+
+**Resultado global: ✅ PASA / ❌ NO PASA**
+**Fecha:** {generated_date}
+
+## Resultado por ítem
+
+| Ítem | Estado | Score | Detalle |
+|------|--------|-------|---------|
+| P1 — Completitud PRD    | ✅/❌ | {score}% | {secciones faltantes o "—"} |
+| P2 — Consistencia Arq.  | ✅/❌ | —        | {entidades no encontradas o "—"} |
+| P3 — Negocio y Valor    | ✅/❌ | —        | {detalle o "—"} |
+| P4 — Contratos API      | ⏭    | —        | No evaluable — ruta y formato del esquema API por definir |
+| P5 — Estimación/Tamaño  | ⏭    | —        | No evaluable — descartado por ahora (estimación con IA) |
+| P6 — Plan de Pruebas    | ✅/❌ | —        | {plan seleccionado + secciones faltantes o "—"} |
+| P7 — Inyección Contexto | ✅/❌ | —        | {secciones faltantes o "—"} |
+| P8 — Mapeo esquemas BD  | ⏭    | —        | No evaluable — descartado por ahora (autodescubrimiento BD) |
+
+## Detalle P1 — Completitud PRD {✅/❌} {score}%
+
+| Sección | Score | Nota |
+|---------|-------|------|
+| Objetivos | {score}% | {nota} |
+| Alcance | {score}% | {nota} |
+| Criterios de Aceptación | {score}% | {nota} |
+| Métricas de Éxito | {score}% | {nota} |
+| Definiciones Técnicas | {score}% | {nota} |
+| Flujos / Reglas de Negocio | {score}% | {nota} |
+
+## Detalle P2 — Consistencia PRD ↔ Arquitectura {✅/❌} {score}%
+
+- **Entidades evaluadas:** {N}
+- **Encontradas:** {N} — {lista}
+- **No encontradas:** {lista o "ninguna"}
+- **Parciales:** {lista o "ninguna"}
+
+## Detalle P3 — Negocio y Valor {✅/❌} {score}%
+
+- **Objetivos:** {VÁLIDO/INVÁLIDO/AUSENTE} — {nota}
+- **Métricas:** {VÁLIDO/INVÁLIDO/AUSENTE} — {nota}
+
+## Acciones requeridas
+
+{Si PASA:}
+✅ El requerimiento cumple el DoR.
+
+{Si NO PASA:}
+❌ Corregir los siguientes ítems antes de continuar:
+{por cada ítem fallido: descripción exacta de qué falta y cómo corregirlo}
 
-📊 Métricas:
-  • Features identificados: [count]
-  • Casos de prueba totales: [count]
-  • Casos P0 (Críticos): [count]
-  • Cobertura de riesgos críticos: [%]%
 ```
 
-**⚠️ El workflow termina aquí. El equipo de QA debe revisar y validar los documentos generados.**
+**🚨 IMPORTANTE:** El JSON de resultados que produce el prompt se usa ÚNICAMENTE
+de forma interna para construir el reporte. **NO escribirlo en el archivo `dor-report.md`.**
 
 ---
 
-### F2.6: Merge Documents (Automatic)
+### F2.4: Completion
 
-Inmediatamente después de guardar los documentos en F2.4, ejecutar el script de merge usando la Bash tool:
+Presentar al usuario:
 
-```bash
-python {project-root}/_siesa-agents/scripts/merge_test_design.py "{carpeta_generada}"
 ```
+{Si PASA:}
+✅ DOR GATE — PASA
 
-Donde `{carpeta_generada}` es la ruta absoluta de la carpeta creada en F2.4 (ej: `{implementation_artifacts}/quality-process/diseno/test-design-YYYY-MM-DD-HHmmss/`).
+📁 Reporte: {implementation_artifacts}/quality-process/dor/dor-report-YYYY-MM-DD-HHmmss/dor-report.md
 
-El script lee los 5 documentos desde `{carpeta_generada}/shards/` y genera `test-design.md` en la raíz de `{carpeta_generada}`.
+📊 Resumen:
+  • P1 Completitud:       ✅ {score}%
+  • P2 Consistencia Arq.: ✅
+  • P3 Negocio y Valor:   ✅
+  • P4 Contratos API:     ⏭  No evaluable
+  • P5 Estimación/Tamaño: ⏭  No evaluable (descartado por ahora)
+  • P6 Plan de Pruebas:   ✅
+  • P7 Contexto:          ✅
+  • P8 Mapeo esquemas BD: ⏭  No evaluable (descartado por ahora)
 
-**No mostrar output técnico del script al usuario.**
+El requerimiento está listo para continuar.
 
----
+{Si NO PASA:}
+❌ DOR GATE — NO PASA
 
-*(Note: `workflow_root` es `{project-root}/_siesa-agents/bmm/workflows/3-solutioning/quality-process`)*
+📁 Reporte: {implementation_artifacts}/quality-process/dor/dor-report-YYYY-MM-DD-HHmmss/dor-report.md
+
+📊 Resumen:
+  • P1 Completitud:       {✅/❌} {score}%
+  • P2 Consistencia Arq.: {✅/❌}
+  • P3 Negocio y Valor:   {✅/❌}
+  • P4 Contratos API:     ⏭  No evaluable
+  • P5 Estimación/Tamaño: ⏭  No evaluable (descartado por ahora)
+  • P6 Plan de Pruebas:   {✅/❌}
+  • P7 Contexto:          {✅/❌}
+  • P8 Mapeo esquemas BD: ⏭  No evaluable (descartado por ahora)
+
+❌ Ítems fallidos: {N}
+→ Devolver a refinamiento. Ver sección "Acciones requeridas" en el reporte.
+```
+
+**⚠️ NO sugerir continuar con ninguna otra fase si el resultado es NO PASA. El workflow termina aquí.**
 
 ---
 
-## FASE 3 — REGISTRO AGILETEST
+## FASE 3 — DISEÑO
 
 ### Objetivo
 
-Empujar el diseño de pruebas validado por el equipo QA a Jira/AgileTest. Crea automáticamente los artefactos de la herramienta: Requisitos (Stories BL → Tareas), Test Cases con Steps (Gherkin → Pasos), Planes de Prueba (PPR), Planes de Ejecución (PEP) y todos los links de trazabilidad. Requiere aprobación humana explícita antes de crear cualquier issue.
-
-**Principio:** "La IA acelera, el humano dirige y autoriza."
+Generar el diseño técnico de pruebas completo aplicando la metodología BMAD V7.8 (Fase 0 interactiva de modo y ámbito, niveles de prueba diferenciados y distribución mínima por modo). Produce trazabilidad funcional, criterios de aceptación en Gherkin, puntos ciegos por arquetipo, Matriz Integral de Pruebas 360° y Test Summary Report.
 
 ---
 
-### F3.1: Seleccionar Diseño a Registrar
+### F3.1: Feature Selection (Interactivo)
 
-**Buscar diseños disponibles:**
-
-1. Listar todas las subcarpetas en `{implementation_artifacts}/quality-process/diseno/` con patrón `test-design-*`
-2. Para cada carpeta encontrada, verificar que existe `test-design.md` en su raíz
-3. Ordenar por nombre descendente (el timestamp garantiza orden cronológico — más reciente primero)
+**Capture feature_id parameter** si fue provisto en los argumentos del comando.
 
-**Mostrar lista al usuario:**
+1. **Cargar el registro de features:**
+   - Leer: `{implementation_artifacts}/feature-status.yaml`
+   - Parsear YAML para extraer todos los features: `[{id, epic_source, status, last_update}, ...]`
 
-```
-📁 Diseños de prueba disponibles:
+2. **Si `feature_id` fue provisto como parámetro:**
+   - Validar que existe en el registro; si no, listar IDs disponibles y detener
+   - `filtered_features = [ese feature]`
+   - Notificar: `✅ Feature seleccionado por parámetro: {feature_id}`
+   - Ir a F3.2
 
-  1. test-design-YYYY-MM-DD-HHmmss/  ← más reciente
-     • test-design.md ✅
-     • test-cases.csv ✅
+3. **Si no se proveyó parámetro, preguntar al usuario:**
 
-  2. test-design-YYYY-MM-DD-HHmmss/
-     ...
-```
+   Mostrar features disponibles:
+   ```
+   📋 Features disponibles en el proyecto:
 
-Si solo hay uno, seleccionarlo automáticamente y notificar:
-```
-✅ Diseño seleccionado automáticamente (único disponible):
-   {implementation_artifacts}/quality-process/diseno/test-design-YYYY-MM-DD-HHmmss/
-```
+   {por cada feature:
+     "  • {feature.id}  [{feature.status}]  →  {feature.epic_source}"
+   }
+   ```
 
-Si hay más de uno, preguntar al usuario:
-```json
-{
-  "questions": [
-    {
-      "question": "¿Qué diseño deseas registrar en AgileTest?",
-      "header": "Selección de Diseño — Fase 3 Registro AgileTest",
-      "multiSelect": false,
-      "options": [
-        { "label": "test-design-YYYY-MM-DD-HHmmss (más reciente)", "description": "N TCs — generado el DD/MM/YYYY" },
-        { "label": "test-design-YYYY-MM-DD-HHmmss", "description": "N TCs — generado el DD/MM/YYYY" }
-      ]
-    }
-  ]
-}
-```
+   Usar AskUserQuestion:
+   ```json
+   {
+     "questions": [
+       {
+         "question": "¿Qué features deseas analizar?",
+         "header": "Selección de Features — Fase 3 Diseño",
+         "multiSelect": false,
+         "options": [
+           {
+             "label": "Todos los features",
+             "description": "Procesar todos los features del registro"
+           },
+           {
+             "label": "Seleccionar features específicos",
+             "description": "Elegir uno o más features por ID"
+           }
+         ]
+       }
+     ]
+   }
+   ```
 
-**Almacenar:**
-- `selected_design_folder` → ruta absoluta a la carpeta seleccionada
-- `selected_test_design_path` → `{selected_design_folder}/test-design.md`
+   **Si "Todos los features":**
+   - `filtered_features = all_features`
+   - Notificar: `✅ Se procesarán todos los features ({count} features)`
 
-**Leer `test-design.md` y mostrar resumen rápido:**
+   **Si "Seleccionar features específicos":**
+   - Si ≤ 4 features: usar AskUserQuestion multiSelect con una opción por feature
+   - Si > 4 features: pedir vía texto: "Ingresa los IDs separados por comas (ej: feature-1,feature-3):"
+   - Validar cada ID contra el registro
+   - `filtered_features = features encontrados`
+   - Notificar:
+     ```
+     ✅ Features seleccionados ({count}):
+     {por cada feature en filtered_features:
+       "  • {feature.id} → {feature.epic_source}"
+     }
+     ```
 
-```
-📋 Diseño seleccionado:
-  • Archivo:    {ruta relativa}/test-design.md
-  • Features:   [extraer conteo de secciones ## F# del documento]
-  • Stories BL: [extraer de Sección I — Gatekeeper]
-  • Test Cases: [extraer de Sección IV — Matriz 360°]
-  • CSV:        test-cases.csv — [N filas]
-```
+4. Almacenar `filtered_features` en memoria.
 
 ---
 
-### F3.1b: Seleccionar Instancia Jira
+### F3.2: Automatic Data Loading (Zero User Interaction)
 
-**Cargar opciones:**
+**CARGAR TODOS LOS INPUTS AUTOMÁTICAMENTE:**
 
-Usar la herramienta **Read** sobre `{project-root}/.claude/commands/get-features/oauth-config.json`.
+1. **INPUT 1 - PROYECTO:**
+   - Cargar desde config: `{project_name}`
+   - Almacenar como: `input_proyecto`
 
-- Si no existe → la única opción disponible es "Otra instancia".
-- Si existe → parsear `instances[]` (campos: `name`, `url`, `id`).
+2. **INPUT 2 - FEATURES / HISTORIAS DE USUARIO:**
+   - Usar `filtered_features` de F3.1
+   - Por cada feature, leer su archivo `epic_source` y concatenar contenido
+   - Almacenar contenido combinado como: `input_epicas`
 
-**Presentar AskUserQuestion — opciones del array + "Otra instancia" al final:**
+3. **INPUT 3 - METAS DE NEGOCIO (PRD):**
+   - Buscar en `{planning_artifacts}/`: `prd.md`, `PRD.md`, `product-requirements.md` o similar
+   - Si encontrado: leer y almacenar como `input_metas`
+   - Si no encontrado: extraer metas de negocio de los archivos epic_source → `input_metas`
+
+4. **INPUT 4 - STACK TECNOLÓGICO:**
+   - Cargar desde: `{project-root}/_siesa-agents/bmm/data/company-standards/technology-stack.md`
+   - Almacenar como: `input_stack`
+
+5. **INPUT 5 - PLAN DE PRUEBAS (Fase 1 — Planeación):**
+   - Buscar la carpeta más reciente en `{implementation_artifacts}/quality-process/planeacion/`:
+     - Listar todas las subcarpetas con patrón `test-plan-*`
+     - Ordenar por nombre descendente (el timestamp garantiza el orden cronológico)
+     - Tomar la primera → es la ejecución más reciente
+   - Si encontrada: leer `test-plan.md` → almacenar en `input_test_plan`
+   - Si no encontrada: `input_test_plan = null`
+
+**Notificar al usuario:**
 
 ```
-Por cada entrada en instances[]:
-  label:       "{entry.name} — {entry.url}"
-  description: "cloud_id: {entry.id}"
+🎯 BMAD V7.8 — Fase 3: Diseño de Pruebas
 
-Última opción fija:
-  label:       "Otra instancia"
-  description: "Ingresa la URL base manualmente"
+✅ Iniciando análisis automático...
+
+📋 Datos cargados:
+  • Proyecto: {input_proyecto}
+  • Features registry: {implementation_artifacts}/feature-status.yaml
+  • Features seleccionados: [lista de feature IDs]
+  • PRD: [ruta encontrada o "extraído de epic_source files"]
+  • Stack Tecnológico: _siesa-agents/bmm/data/company-standards/technology-stack.md
+  • Plan de Pruebas (Fase 1): [ruta encontrada o "No encontrado — se continuará sin ese contexto"]
+
+🚀 Ejecutando la Fase 0 (interactiva) + las 4 fases de análisis BMAD V7.8...
 ```
 
-- Si selecciona una entrada del array → `jira_base_url` = `entry.url`, `instancia_es_otra` = false
-- Si selecciona "Otra instancia" → `jira_base_url` = null, `instancia_es_otra` = true
+---
 
-**Almacenar:** `jira_base_url`, `instancia_es_otra`
+### F3.3: Load and Execute Megaprompt
+
+1. **Cargar el Megaprompt:**
+   - Leer el archivo completo: `{workflow_root}/prompts/prompt_design_test.md`
+   - Este prompt transforma al agente en Principal QA Architect
+
+2. **Inyectar inputs:**
+   Reemplazar la sección `[INPUT]` del prompt:
+   ```
+   # [INPUT]:
+   - **PROYECTO**: {input_proyecto}
+   - **ÉPICAS / HISTORIAS DE USUARIO**: {input_epicas}
+   - **METAS DE NEGOCIO (PRD)**: {input_metas}
+   - **STACK TECNOLÓGICO**: {input_stack}
+   - **PLAN DE PRUEBAS (contexto)**: {input_test_plan}
+   ```
+
+3. **Ejecutar la FASE 0 (interactiva) y luego las 4 FASES de diseño:**
+
+   El megaprompt V7.8 inicia con una **Fase 0 interactiva obligatoria** que pregunta al
+   usuario (vía AskUserQuestion o texto) y debe completarse ANTES de generar casos:
+   - **Modo de ejecución:** `feature` (un feature aislado) o `completo` (integración entre features).
+   - **Validación de congruencia modo-features (RO-8):** los features en scope son los
+     seleccionados en F3.1. Si el modo no es congruente con su número, el prompt resuelve
+     con el usuario antes de seguir.
+   - **Tipo de interfaz** (`con frontend` / `sin frontend`) — solo en Modo Feature; define
+     si los casos se redactan en lenguaje de UI o de API.
+   - **Batching por macro-dominios (RO-7):** en Modo Completo con > 4 features, el prompt
+     descompone en cadenas de flujo (máx. 4 features por batch) y ofrece la estrategia de
+     ejecución; esta corrida diseña el batch confirmado y reporta los pendientes en el TSR.
+
+   Tras la Fase 0, ejecutar secuencialmente:
+   - FASE 1: GATEKEEPER GRANULAR Y LIMPIEZA DE BACKLOG
+   - FASE 2: EL ESCALÓN DE CRITERIOS (FAC) en Gherkin (etiquetados por nivel)
+   - FASE 3: DETECCIÓN DE PUNTOS CIEGOS (Simulación Universal)
+   - FASE 4: INGENIERÍA DE DISEÑO (ISO 29119-4), distribución por niveles
+     (FU/INT/INT-X/E2E/E2E-X/REG/EC) y CALCULADORA DE RIESGO
+
+   **Generar outputs en FORMATO EXACTO V7.8 (el parser de la Fase 5 y el exportador CSV dependen de esta estructura):**
+   - I. REPORTE DEL GATEKEEPER (GRANULAR) — tabla de 5 columnas (`ID Historia | Nombre/Épica | Feature Asociado | Clasificación | Justificación`)
+   - II. DEFINICIÓN DE FEATURES Y CRITERIOS MAESTROS (FAC) EN GHERKIN
+   - III. PUNTOS CIEGOS DETECTADOS POR FEATURE
+   - IV. DEPENDENCIAS ENTRE FEATURES *(solo Modo Completo)*
+   - V. MATRIZ INTEGRAL DE PRUEBAS (DISEÑO 360°) — tabla única de **13 columnas**
+     (`ID | Feature | Épicas Asociadas | Modo | Nivel | Tipo Interfaz | Técnica | Escenario | Precondiciones | Pasos | Resultado Esperado | Riesgo (IxP) | Prioridad`),
+     IDs `[FEATURE_CODE]-[NIVEL]-[NNN]` (ej. `VNT-FU-001`, `INV-INTX-001`)
+   - VI. INFORME TSR (TEST SUMMARY REPORT)
+   - APÉNDICE: MATRIZ DE TRAZABILIDAD
 
 ---
 
-### F3.1c: Seleccionar Proyecto Jira
+### F3.4: Save Output
 
-**Cargar opciones** (archivo ya leído en F3.1b):
+**Crear estructura de carpeta con timestamp:**
 
-Parsear `projects[]` del mismo JSON (campos: `key`, `name`).
+1. Generar timestamp: `YYYY-MM-DD-HHmmss` (ej: `2026-03-25-143052`)
+2. Crear estructura de carpetas:
+   - Raíz: `{implementation_artifacts}/quality-process/diseno/test-design-YYYY-MM-DD-HHmmss/`
+   - Shards: `{implementation_artifacts}/quality-process/diseno/test-design-YYYY-MM-DD-HHmmss/shards/`
+3. Guardar los 5 documentos dentro de la subcarpeta `shards/`:
 
-**Presentar AskUserQuestion — opciones del array + "Otro proyecto" al final:**
+**Documento 1:** `shards/test-design-phase1-gatekeeper.md` (Sección I — Gatekeeper)
+**Documento 2:** `shards/test-design-phase2-fac.md` (Sección II — Features y FAC en Gherkin)
+**Documento 3:** `shards/test-design-phase3-blind-spots.md` (Sección III — Puntos Ciegos + Sección IV — Dependencias entre Features)
+**Documento 4:** `shards/test-design-phase4-test-matrix.md` (Sección V — Matriz Integral 360°)
+**Documento 5:** `shards/test-design-phase5-tsr.md` (Sección VI — TSR + Apéndice de Trazabilidad)
 
-```
-Por cada entrada en projects[]:
-  label:       "{entry.key} — {entry.name}"
-  description: ""
+> **Nota:** los 5 shards se concatenan con `merge_test_design.py` en orden, produciendo el `test-design.md` con las secciones I→VI + Apéndice. El parser de la Fase 5 ancla la matriz en `## V. MATRIZ INTEGRAL` (corte en `## VI`).
 
-Última opción fija:
-  label:       "Otro proyecto"
-  description: "Ingresa el project key manualmente"
+**Frontmatter para todos los documentos:**
+```yaml
+---
+workflow: quality-process
+phase: diseno
+version: 1.0.0
+methodology: BMAD V7.8 MegaPrompt
+generated_date: [ISO 8601 date]
+project_name: {input_proyecto}
+input_documents:
+  epics: [ruta(s) relativa(s)]
+  prd: [ruta relativa o null]
+  technology_stack: _siesa-agents/bmm/data/company-standards/technology-stack.md
+  test_plan: [ruta relativa o null]
+---
 ```
 
-- Si selecciona una entrada del array → `jira_project_key` = `entry.key`, `proyecto_es_otro` = false
-- Si selecciona "Otro proyecto" → `jira_project_key` = null, `proyecto_es_otro` = true
+**Exportar casos de prueba a CSV (Siesa FT-SD-007 v5.0):**
 
-**Almacenar:** `jira_project_key`, `proyecto_es_otro`
+Después de guardar `shards/test-design-phase4-test-matrix.md` (Sección V — Matriz):
 
----
+1. Leer el contenido completo del archivo generado
+2. Derivar el `ID Épica` de cada caso desde la columna `Feature` (o el prefijo del `ID`,
+   ej. `VNT` en `VNT-FU-001`). En V7.8 la matriz es una tabla única (sin headers `## F#`).
+3. Parsear todas las filas de la matriz cuyo `ID` matchee `^[A-Z0-9]{2,}-[A-Z0-9-]+-\d+$`,
+   extrayendo las **13 columnas** de la matriz V7.8.
+4. Mapear a las 13 columnas del formato Siesa CSV:
 
-### F3.1d: Resolver valores manuales (solo si aplica)
+   | Columna Matriz (V7.8) | → Columna CSV |
+   |---|---|
+   | `Feature` (o prefijo del `ID`) | `ID Épica` |
+   | `ID` | `ID Caso de Prueba` |
+   | `Escenario` | `Título` |
+   | `Feature` + `: ` + `Escenario` | `Descripción Completa` |
+   | `Precondiciones` | `Precondiciones` |
+   | `Pasos` | `Pasos de Ejecución` |
+   | `Resultado Esperado` | `Resultados Esperados` |
+   | `Nivel` | `Tipo prueba` |
+   | _(vacío)_ | `Fecha Ejecución` |
+   | `"Not Started"` | `Estado` |
+   | _(vacío)_ | `ID Defecto` |
+   | _(vacío)_ | `Descripción Fallo` |
+   | `Modo: [Modo] \| Nivel: [Nivel] \| Interfaz: [Tipo Interfaz] \| Técnica: [Técnica] \| Risk: [Riesgo] \| Priority: [Prioridad]` | `Notas` |
 
-**Evaluar qué falta:**
+5. **🚨 CRÍTICO — Compatibilidad Windows CSV:**
+   - ✅ Usar **Write tool ONLY** — NUNCA bash, cat, echo, sed, awk
+   - ✅ Construir el **string CSV completo en memoria** y luego llamar Write una vez
+   - ✅ Envolver **TODOS los campos** en comillas dobles
+   - ✅ Escapar comillas internas duplicándolas: `"` → `""`
+   - ✅ Encoding: UTF-8
 
-- Si `instancia_es_otra` = false Y `proyecto_es_otro` = false → saltar este paso, ir a F3.2.
-- Si `instancia_es_otra` = true O `proyecto_es_otro` = true → hacer UNA SOLA pregunta combinada.
+6. Guardar como: `{implementation_artifacts}/quality-process/diseno/test-design-YYYY-MM-DD-HHmmss/test-cases.csv` (en la raíz, NO en shards/)
 
-**Una única pregunta que pide solo lo que falta:**
+**Exportar el diseño completo a YAML estructurado:**
 
-- Solo falta instancia → `"Ingresa la URL base de Jira (ej: https://miempresa.atlassian.net)"`
-- Solo falta proyecto → `"Ingresa el Project Key (ej: CON, CLOUD, RUTA)"`
-- Faltan ambos → `"Ingresa la URL base de Jira y el Project Key (ej: https://miempresa.atlassian.net CLOUD)"`
+Además del `test-design.md` (narrativo) y el `test-cases.csv` (casos tabulares), generar un
+`test-design.yml` que represente **todo el diseño en formato datos** (machine-readable).
 
-Parsear la respuesta y almacenar en `jira_base_url` y/o `jira_project_key` según corresponda.
+> **🚨 OBLIGATORIO — también (y especialmente) en Modo Completo / batch.** El `test-design.yml`
+> NO es opcional: es el insumo directo de AgileTest (Fase 5), del Motor de Datos (Fase 4) y del
+> Agente Ejecutor E2E (Fase 6). Debe generarse para el batch diseñado en esta corrida, sin importar
+> cuántos casos tenga la matriz.
+>
+> **Fuente de verdad = los shards ya guardados, NO la memoria.** En corridas largas (Modo Completo
+> con varios features) la matriz puede haber salido del contexto. Para construir el YAML de forma
+> robusta, **re-lee los archivos recién escritos** en `shards/` — sobre todo
+> `shards/test-design-phase4-test-matrix.md` (Sección V — Matriz) y los demás shards (I, II/III, VI)
+> — y serialízalos. Así el `.yml` no depende de que el diseño siga "en memoria".
 
-**No hacer preguntas adicionales después de este paso.**
+Serializar a YAML con esta estructura:
 
----
+```yaml
+metadata:
+  workflow: quality-process
+  phase: diseno
+  methodology: BMAD V7.8 MegaPrompt
+  generated_date: <ISO 8601>
+  project_name: {input_proyecto}
+  mode: feature | completo
+  interface_type: con-frontend | sin-frontend | null   # null si modo completo
+gatekeeper:                       # Sección I — clasificación de historias
+  - story_id: <ID Historia>
+    name: <Nombre/Épica>
+    feature: <Feature Asociado>
+    classification: <Clasificación>
+    justification: <Justificación>
+features:                         # Sección II + III
+  - code: <FEATURE_CODE>          # ej. VNT
+    name: <nombre del feature>
+    epics: [<EPIC-...>, ...]
+    fac:                          # Criterios maestros en Gherkin
+      - id: <FEATURE_CODE>-FAC-01
+        gherkin: |
+          Given ...
+          When ...
+          Then ...
+    blind_spots:                  # Puntos ciegos detectados
+      - archetype: <arquetipo>
+        description: <descripción>
+dependencies:                     # Sección IV — solo Modo Completo; [] si feature
+  - from: <FEATURE_CODE>
+    to: <FEATURE_CODE>
+    description: <descripción de la dependencia>
+test_matrix:                      # Sección V — Matriz Integral 360° (13 columnas)
+  - id: <FEATURE_CODE>-<NIVEL>-<NNN>   # ej. VNT-FU-001
+    feature: <FEATURE_CODE>
+    epics: [<EPIC-...>, ...]
+    mode: <Modo>
+    level: <Nivel>                # FU | INT | INT-X | E2E | E2E-X | REG | EC
+    interface_type: <Tipo Interfaz>
+    technique: <Técnica>
+    scenario: <Escenario>
+    preconditions: <Precondiciones>
+    steps:                        # ARRAY de pasos — 1 paso = 1 acción atómica (NO agrupar)
+      - paso: 1
+        accion: <acción concreta del paso>
+        resultado: <resultado verificable de ese paso>
+        datos: <datos usados en ese paso — insumo del Motor de Datos>
+      - paso: 2
+        accion: <...>
+        resultado: <...>
+        datos: <...>
+    expected_result: <Resultado Esperado>
+    risk: <Riesgo IxP>            # ej. "4x3=12"
+    priority: <Prioridad>         # P0 | P1 | P2 | P3
+tsr:                              # Sección VI — Test Summary Report
+  summary: <resumen ejecutivo>
+  metrics:
+    total_cases: <N>
+    p0: <N>
+    p1: <N>
+    p2: <N>
+    p3: <N>
+    critical_risk_coverage_pct: <N>
+  pending_batches: [<...>]        # batches no diseñados en esta corrida (Modo Completo); [] si ninguno
+traceability:                     # Apéndice — Matriz de Trazabilidad
+  - requirement: <ID/criterio>
+    cases: [<ID Caso>, ...]
+```
+
+**Reglas de serialización:**
+- ✅ Usar **Write tool ONLY** (encoding UTF-8). NUNCA bash, cat, echo, sed, awk.
+- ✅ Construir el string YAML completo en memoria y llamar Write una sola vez.
+- ✅ Los valores con `:`, `#`, comillas o saltos de línea deben ir entre comillas dobles o como
+  bloque literal (`|`).
+- ✅ **`steps` es un ARRAY de objetos** (`paso`, `accion`, `resultado`, `datos`), NO un string.
+  Regla: **1 paso = 1 acción atómica** — prohibido agrupar múltiples acciones en un solo paso.
+  El campo `datos` por paso es el insumo que el Motor de Datos (Fase 4) lee para generar seeds,
+  y el Agente Ejecutor E2E usa los pasos para generar el `.spec.ts` de Playwright.
+- ✅ Las claves `mode`, `interface_type`, `dependencies` deben ser congruentes con la Fase 0:
+  en Modo Feature → `dependencies: []`; en Modo Completo → `interface_type: null`.
+- ✅ El `test_matrix` debe tener **una entrada por cada fila** de la matriz (mismo conteo que el CSV).
+  El array `steps` de cada caso debe reflejar exactamente los pasos de la columna `Pasos` del Markdown.
+
+Guardar como: `{implementation_artifacts}/quality-process/diseno/test-design-YYYY-MM-DD-HHmmss/test-design.yml` (en la raíz, junto a `test-cases.csv`, NO en shards/)
+
+**Verificación obligatoria (guard) — no completar la Fase 3 sin el YAML:**
+
+Tras el Write, **verificar que `test-design.yml` exista y no esté vacío** (y que su `test_matrix`
+tenga el mismo número de entradas que filas tiene la matriz del CSV/Markdown):
+
+- Si el archivo **no existe, quedó vacío o truncado** (caso típico en batch grande): **regenerarlo
+  re-leyendo los shards** (`shards/test-design-phase4-test-matrix.md` + I, II/III, VI) y volver a
+  escribirlo. Repetir hasta que el `.yml` esté completo.
+- **No avanzar a F3.5** ni reportar la fase como completada mientras falte el `test-design.yml`.
 
-### F3.2: Validar Credenciales (Pre-flight)
+---
 
-Antes de ejecutar el dry-run, verificar que las credenciales están disponibles.
-El script las busca en este orden de prioridad:
-1. `_siesa-agents/bmm/config.secrets.yaml` (archivo local gitignoreado — forma recomendada)
-2. Variables de entorno `JIRA_API_TOKEN`, `AGILETEST_CLIENT_ID`, `AGILETEST_CLIENT_SECRET`
+### F3.5: Completion
 
-**Leer `_siesa-agents/bmm/config.secrets.yaml` y verificar que los tokens no estén vacíos:**
+Presentar al usuario:
 
 ```
-📋 Estado de credenciales en _siesa-agents/bmm/config.secrets.yaml:
-  jira_api_token:          [configurado ✅ | vacío ⚠️]
-  agiletest_client_id:     [configurado ✅ | vacío ⚠️]
-  agiletest_client_secret: [configurado ✅ | vacío ⚠️]
-```
+✅ FASE 3 — DISEÑO COMPLETADA
+
+📁 Carpeta: {implementation_artifacts}/quality-process/diseno/test-design-YYYY-MM-DD-HHmmss/
 
-**Si todos están configurados:** continuar a F3.3.
+📄 Archivos en raíz:
+  • test-design.md   — Documento unificado (phases 1–5)
+  • test-design.yml — Diseño completo estructurado (machine-readable)
+  • test-cases.csv   — Casos exportados (Siesa FT-SD-007 v5.0)
 
-**Si alguno está vacío**, mostrar instrucciones y DETENER:
+📂 shards/ (documentos individuales por fase):
+  • test-design-phase1-gatekeeper.md
+  • test-design-phase2-fac.md
+  • test-design-phase3-blind-spots.md
+  • test-design-phase4-test-matrix.md
+  • test-design-phase5-tsr.md
 
+📊 Métricas:
+  • Features identificados: [count]
+  • Casos de prueba totales: [count]
+  • Casos P0 (Críticos): [count]
+  • Cobertura de riesgos críticos: [%]%
 ```
-⚠️  Faltan credenciales en _siesa-agents/bmm/config.secrets.yaml
 
-Abre el archivo y completa los valores:
+**⚠️ El workflow termina aquí. El equipo de QA debe revisar y validar los documentos generados.**
 
-  agiletest:
-    jira_api_token: "tu-token-aqui"
-    agiletest_client_id: "tu-client-id"
-    agiletest_client_secret: "tu-client-secret"
+---
 
-Dónde obtenerlos:
-  • jira_api_token:          Jira → Profile → Security → API tokens → Create
-  • agiletest_client_id/secret: AgileTest plugin en Jira → Settings → API Keys
+### F3.6: Merge Documents (Automatic)
 
-El archivo ya está en .gitignore — es seguro guardar los tokens ahí.
-Una vez completados, vuelve a ejecutar la Fase 3.
+Inmediatamente después de guardar los documentos en F3.4, ejecutar el script de merge usando la Bash tool:
+
+```bash
+python {project-root}/_siesa-agents/scripts/merge_test_design.py "{carpeta_generada}"
 ```
 
+Donde `{carpeta_generada}` es la ruta absoluta de la carpeta creada en F3.4 (ej: `{implementation_artifacts}/quality-process/diseno/test-design-YYYY-MM-DD-HHmmss/`).
+
+El script lee los 5 documentos desde `{carpeta_generada}/shards/` y genera `test-design.md` en la raíz de `{carpeta_generada}`.
+
+**No mostrar output técnico del script al usuario.**
+
+---
+
+*(Note: `workflow_root` es `{project-root}/_siesa-agents/bmm/workflows/3-solutioning/quality-process`)*
+
 ---
 
-### F3.2b: Resolver agiletest_project_id
+## FASE 4 — GENERACIÓN DE DATOS QA
+
+### Objetivo
 
-**Verificar si ya está configurado:**
+Provisionar en la base de datos real (vía MCP) los datos sintéticos que los casos de prueba diseñados en la Fase 3 necesitan para poder ejecutarse. Esta fase **infiere y confirma el negocio** con el usuario, **reutiliza los datos QA ya existentes** antes de generar nada, inserta únicamente lo faltante respetando integridad referencial y tipos reales, y entrega **3 artefactos en disco**: `test-data.md` (relación caso→datos agrupada por seed, orientada a Playwright), `seed.sql` idempotente y `rollback.sql` acotado a la corrida.
 
-Leer `_siesa-agents/bmm/config.secrets.yaml`. Si `agiletest_project_id` tiene un valor no vacío, mostrar:
-```
-✅ agiletest_project_id ya configurado: {valor} — omitiendo resolución.
-```
-Y continuar a F3.3.
+**Principio:** "Reutilizar antes de generar. No se inserta nada sin aprobación humana. Es válido y esperado que una corrida termine con **0 inserciones** si toda la cobertura ya existe — pero aun así se escribe `test-data.md`."
 
-**Si está vacío:** resolver automáticamente vía la API de Jira usando Bash tool:
+**Fuente de verdad:** El protocolo de 7 fases vive en la skill `sa-qa-data-generator`. Esta fase orquesta esa skill dentro del ciclo de calidad para que el QA no tenga que invocarla como un comando aparte — el insumo es el `test-cases.csv` que la propia Fase 3 produjo.
 
-```bash
-python -c "
-import urllib.request, base64, json, re, sys
+---
 
-secrets_path = '{project-root}/_siesa-agents/bmm/config.secrets.yaml'
-with open(secrets_path, encoding='utf-8') as f:
-    content = f.read()
+### F4.1: Seleccionar Diseño Fuente (CSV)
 
-def extract(key, text):
-    m = re.search(rf'^\s+{key}:\s*[\"\'"]?(.+?)[\"\'"]?\s*$', text, re.MULTILINE)
-    return m.group(1).strip().strip('\"').strip(\"'\") if m else ''
+**Buscar diseños disponibles:**
 
-email   = extract('jira_user_email',   content)
-token   = extract('jira_api_token',    content)
-base    = '{jira_base_url}'
-key     = '{jira_project_key}'
+1. Listar todas las subcarpetas en `{implementation_artifacts}/quality-process/diseno/` con patrón `test-design-*`
+2. Para cada carpeta encontrada, verificar que existe `test-cases.csv` en su raíz
+3. Ordenar por nombre descendente — el timestamp garantiza orden cronológico (más reciente primero)
 
-creds   = base64.b64encode(f'{email}:{token}'.encode()).decode()
-req     = urllib.request.Request(
-    f'{base}/rest/api/3/project/{key}',
-    headers={'Authorization': f'Basic {creds}', 'Accept': 'application/json'}
-)
-with urllib.request.urlopen(req, timeout=10) as r:
-    data = json.loads(r.read().decode())
+**Si solo hay uno**, seleccionarlo automáticamente:
+```
+✅ CSV seleccionado automáticamente:
+   {implementation_artifacts}/quality-process/diseno/test-design-YYYY-MM-DD-HHmmss/test-cases.csv
+```
 
-project_id = str(data['id'])
-print(f'PROJECT_ID={project_id}')
-"
+**Si hay más de uno**, preguntar al usuario:
+```json
+{
+  "questions": [
+    {
+      "question": "¿De qué diseño quieres generar los datos de prueba?",
+      "header": "Selección de Diseño — Fase 4 Generación de Datos QA",
+      "multiSelect": false,
+      "options": [
+        { "label": "test-design-YYYY-MM-DD-HHmmss (más reciente)", "description": "N TCs — generado el DD/MM/YYYY" },
+        { "label": "test-design-YYYY-MM-DD-HHmmss", "description": "N TCs — generado el DD/MM/YYYY" }
+      ]
+    }
+  ]
+}
 ```
 
-**Parsear la salida:** extraer el valor después de `PROJECT_ID=` → almacenar en `resolved_project_id`.
+**Si no existe ningún `test-cases.csv`:** detener con mensaje:
+```
+❌ No se encontró ningún test-cases.csv en {implementation_artifacts}/quality-process/diseno/.
 
-**Si la llamada falla:** mostrar el error y DETENER — no continuar sin el ID porque los pasos 4, 6 y 7 de AgileTest fallarán con HTTP 400.
+La Fase 4 requiere los casos de prueba generados por la Fase 3 — Diseño.
+Ejecuta primero la Fase 3 y vuelve a intentar.
+```
 
-**Persistir en config.secrets.yaml usando Bash tool:**
+**Almacenar:**
+- `selected_csv_path` → ruta absoluta al `test-cases.csv` seleccionado
+- `selected_design_folder` → carpeta raíz del diseño seleccionado
 
-```bash
-python -c "
-import re
+Leer `test-cases.csv` y mostrar resumen rápido:
+```
+📋 CSV cargado:
+  • Archivo:   {ruta relativa}/test-cases.csv
+  • Total TCs: [N filas descontando header]
+  • Features:  [lista de IDs de épica únicos extraídos de columna "ID Épica"]
+```
 
-path = '{project-root}/_siesa-agents/bmm/config.secrets.yaml'
-with open(path, encoding='utf-8') as f:
-    content = f.read()
+---
 
-new_line = '  agiletest_project_id: \"{resolved_project_id}\"'
+### F4.2: Verificar Conexión MCP de Base de Datos (Pre-flight)
 
-if re.search(r'^\s+agiletest_project_id:', content, re.MULTILINE):
-    content = re.sub(r'^\s+agiletest_project_id:.*$', new_line, content, flags=re.MULTILINE)
-else:
-    content = re.sub(r'(agiletest:\n)', r'\1' + new_line + '\n', content)
+El agente de datos **no puede operar sin un MCP de base de datos conectado** (PostgreSQL o SQL Server). Sin él, cualquier dato generado sería inventado y causaría errores en cascada.
 
-with open(path, 'w', encoding='utf-8') as f:
-    f.write(content)
+1. Detectar si hay disponible un MCP de BD (herramientas tipo `describe_table`, `get_dependencies`, `get_foreign_keys`, `read_data`, `insert_data`, o sus equivalentes SQL Server).
+2. Hacer una verificación mínima no destructiva (ej. listar tablas o describir una tabla de catálogo conocida).
 
-print('OK')
-"
+**Si hay conexión:** notificar y continuar a F4.3:
+```
+✅ MCP de base de datos detectado: {postgresql | mssql}
+   Conexión verificada — listo para descubrir esquemas reales.
 ```
 
-**Confirmar al usuario:**
+**Si NO hay conexión**, mostrar instrucciones y DETENER:
 ```
-✅ agiletest_project_id resuelto y guardado: {resolved_project_id}
-   (Proyecto {jira_project_key} en {jira_base_url})
-   Guardado en config.secrets.yaml — no se volverá a resolver en próximas ejecuciones.
+⚠️  No se detectó un MCP de base de datos conectado.
+
+La Fase 4 necesita consultar el esquema real para generar datos válidos.
+Configura y conecta el MCP de tu motor antes de continuar:
+
+  • PostgreSQL / SQL Server: ver _siesa-agents/sa/mcp_database/
+  • Provisionar esquema y permisos del usuario dev: skill `sa-onboard-db`
+
+Una vez el MCP esté conectado, vuelve a ejecutar la Fase 4.
 ```
 
 ---
 
-### F3.3: Dry-run — Vista Previa Obligatoria
+### F4.3: Cargar y Ejecutar el Protocolo del Agente de Datos
 
-**Ejecutar dry-run usando Bash tool:**
+1. **Cargar el protocolo completo** desde la skill (fuente de verdad):
+   - Leer el archivo completo: `{project-root}/claude/skills/sa-qa-data-generator/SKILL.md`
+   - Este protocolo transforma al agente en el motor de datos sintéticos para QA.
 
-```bash
-python {project-root}/_siesa-agents/scripts/bmad_to_agiletest.py \
-  --input "{selected_test_design_path}" \
-  --config "{project-root}/_bmad/bmm/config.yaml" \
-  --jira-url "{jira_base_url}" \
-  --project-key "{jira_project_key}" \
-  --dry-run
-```
+2. **Inyectar el input:** el `Input: Test Case File` del protocolo es el `selected_csv_path` (ya cargado en F4.1). No pedir el archivo al usuario — ya está resuelto por el flujo.
 
-**Parsear la salida y presentar al usuario en tabla ordenada:**
+3. **Ejecutar las Fases 1–4 del protocolo** (sin inserción todavía):
+   - PHASE 1 — Lectura y análisis de casos (clasificación POSITIVE / EDGE / NEGATIVE)
+   - **PHASE 1.A — Inferencia y confirmación del negocio (GATE):** deducir el negocio/dominio
+     al que apuntan los casos, presentarlo al usuario y **esperar confirmación** antes de seguir.
+     El negocio confirmado encabeza `test-data.md` y nombra la carpeta de salida (F4.6).
+   - PHASE 2 — Descubrimiento de esquema vía MCP (NUNCA asumir columnas/tipos)
+   - PHASE 3 — Construcción del árbol de entidades (orden de inserción)
+   - PHASE 4 — Verificación de datos existentes y matching caso-por-caso (REUSABLE / PARTIAL / MISSING)
 
-```
-📊 Vista previa — Lo que se creará en Jira/AgileTest:
+   Notificar al usuario durante la ejecución:
+   ```
+   ⚙️ Agente de Datos QA — analizando casos contra la BD real:
+      • PHASE 1:   Lectura y clasificación de casos
+      • PHASE 1.A: Inferencia del negocio (requiere confirmación del usuario)
+      • PHASE 2:   Descubrimiento de esquemas (MCP)
+      • PHASE 3:   Árbol de entidades y orden de inserción
+      • PHASE 4:   Matching contra datos QA existentes (reutilizar antes de generar)
+   ```
 
-  ┌──────────────────────────┬──────────┐
-  │ Artefacto                │ Cantidad │
-  ├──────────────────────────┼──────────┤
-  │ Requisitos (Stories BL)  │    N     │
-  │ Test Cases               │    N     │
-  │   • P0 (Muy Alta)        │    N     │
-  │   • P1 (Alta)            │    N     │
-  │   • P2 (Media)           │    N     │
-  │   • P3 (Baja)            │    N     │
-  │ Planes de Prueba (PPR)   │    N     │
-  │ Planes de Ejecución (PEP)│    N     │
-  │ Links de trazabilidad    │  ~N      │
-  │ Steps de prueba          │  ~N      │
-  └──────────────────────────┴──────────┘
+   > El GATE de PHASE 1.A es **no omisible**: si el usuario no confirma el negocio (o corrige),
+   > no se continúa a PHASE 2.
 
-  📋 Distribución por Feature:
-    F1 — [Nombre]: N TCs
-    F2 — [Nombre]: N TCs
-    ...
+---
 
-  🎯 Proyecto Jira: {jira_project_key}
-  ⏱️  Tiempo estimado: ~5 minutos
-```
+### F4.4: Gate de Aprobación Humana (OBLIGATORIO)
 
----
+Este paso es **no omisible**. No se inserta ningún registro sin aprobación explícita.
 
-### F3.4: Gate de Aprobación Humana (OBLIGATORIO)
+Presentar el resultado del matching de PHASE 4:
+```
+📊 Matching de datos — Resumen
 
-Este paso es **no omisible**. No se crea ningún issue sin aprobación explícita.
+  Caso        │ Categoría  │ IDs reutilizables       │ Datos a crear
+  ────────────┼────────────┼─────────────────────────┼──────────────────
+  TC-F1-001   │ REUSABLE   │ invoices id=5001        │ —
+  TC-F1-002   │ PARTIAL    │ customers id=1001       │ invoice + detalle
+  TC-F2-005   │ MISSING    │ —                       │ customer+invoice+det
+  ...
 
-**Preguntar al usuario usando AskUserQuestion:**
+  🔢 Decisión: [N inserciones requeridas] | [0 inserciones — toda la cobertura ya existe]
+```
+
+**Si la decisión es "0 inserciones":**
+- No hay nada que aprobar. Saltar F4.5 e ir directo a F4.6 con el reporte 7.5 ("No se generaron datos nuevos"); se escribe **`test-data.md`** con todos los bloques en estado "reusado" y los IDs existentes a usar por caso (no se generan `seed.sql` ni `rollback.sql`).
 
+**Si hay al menos un caso PARTIAL o MISSING**, preguntar:
 ```json
 {
   "questions": [
     {
-      "question": "¿Apruebas la creación de estos N issues en Jira/AgileTest?",
-      "header": "⚠️ Confirmación Requerida — Creación en AgileTest",
+      "question": "¿Apruebas insertar los datos faltantes en la base de datos?",
+      "header": "⚠️ Confirmación Requerida — Inserción de Datos QA",
       "multiSelect": false,
       "options": [
         {
-          "label": "✅ Aprobar y crear en AgileTest",
-          "description": "Se crearán los N issues en el proyecto Jira. Esta acción es reversible (el script tiene modo --delete para limpiar)."
+          "label": "✅ Aprobar e insertar",
+          "description": "Se insertarán SOLO los datos faltantes (casos PARTIAL/MISSING) en el orden del árbol de entidades. Reversible vía el script de rollback que se generará."
         },
         {
-          "label": "🔍 Ver detalle de TCs antes de decidir",
-          "description": "Mostrar cada TC con sus pasos antes de aprobar"
+          "label": "🔍 Ver detalle de inserciones primero",
+          "description": "Mostrar tabla/registro a insertar por caso antes de aprobar"
         },
         {
-          "label": "❌ Cancelar — no crear nada",
-          "description": "Salir sin crear issues en Jira/AgileTest"
+          "label": "❌ Cancelar — no insertar nada",
+          "description": "Salir sin modificar la base de datos"
         }
       ]
     }
@@ -1012,697 +1272,760 @@ Este paso es **no omisible**. No se crea ningún issue sin aprobación explícit
 }
 ```
 
-**Si "Ver detalle":** Ejecutar con `--detail` y regresar a este mismo gate:
-
-```bash
-python {project-root}/_siesa-agents/scripts/bmad_to_agiletest.py \
-  --input "{selected_test_design_path}" \
-  --config "{project-root}/_bmad/bmm/config.yaml" \
-  --jira-url "{jira_base_url}" \
-  --project-key "{jira_project_key}" \
-  --dry-run --detail
-```
-
-Mostrar el detalle y volver a presentar el gate de aprobación.
+**Si "Ver detalle":** mostrar el plan de inserción detallado (tabla, schema, registros) y volver a este gate.
+**Si "Cancelar":** notificar `❌ Operación cancelada. No se insertó ningún dato.` y terminar.
+**Si "Aprobar":** continuar a F4.5.
 
-**Si "Cancelar":** Notificar `❌ Operación cancelada. No se creó ningún issue.` y terminar el workflow.
+---
 
-**Si "Aprobar":** Continuar a F3.5.
+### F4.5: Generación e Inserción (PHASE 5–6 del protocolo)
 
----
+Ejecutar únicamente para los casos PARTIAL/MISSING aprobados:
 
-### F3.5: Crear en AgileTest
+- PHASE 5 — Generación de datos (tipos reales, columnas NOT NULL, FKs válidas, marcador `QA_`/`TEST_`/`[SYNTHETIC DATA]`, sin PII real). Asignar un **ID de corrida** común (`QA_<fecha>_<seq>`) a todos los registros para poder acotar el rollback.
+- PHASE 6 — Inserción en BD en orden estricto del árbol (raíz/catálogo → maestras → focales → detalle → SP/funciones) **y, en paralelo, escritura de `seed.sql`** que reproduce las mismas inserciones (transaccional, idempotente con `ON CONFLICT DO NOTHING` / `IF NOT EXISTS`, comentado por caso, ordenado padres→hijos). Se guarda en F4.6.
 
-**Notificar inicio:**
+**Tras cada inserción:** verificar éxito. Si falla por FK/constraint/tipo: NO continuar con dependientes, diagnosticar re-consultando el esquema, corregir y reintentar; si no se resuelve, informar al usuario y detener.
 
-```
-🚀 Iniciando creación en Jira/AgileTest...
+---
 
-  Proyecto: {jira_project_key}
-  Input:    {ruta relativa}/test-design.md
-  State:    {ruta relativa}/bmad_state_{feature_code}.json
+### F4.6: Guardar los 3 Entregables
 
-  Progreso de los 8 pasos:
-```
+**Generar timestamp:** `YYYY-MM-DD-HHmmss`
 
-**Ejecutar el script usando Bash tool:**
+**Slug del negocio:** derivar de la PHASE 1.A un slug kebab-case del negocio confirmado (ej. "Una tienda de ropa" → `tienda-de-ropa`).
+
+**Crear carpeta:** `{implementation_artifacts}/quality-process/datos/data-gen-{negocio-slug}-YYYY-MM-DD-HHmmss/`
+
+Guardar los archivos (usar **Write tool**, encoding UTF-8). Construir cada string completo en memoria y llamar Write una sola vez — **NUNCA** bash/cat/echo/sed:
+
+1. **`test-data.md`** (entregable 1 — PHASE 7.2) — **se escribe SIEMPRE**, incluso con 0 inserciones:
+   - Encabezado `# Test Data — {negocio confirmado}` + metadata (proceso, BD, fecha, **ID de corrida**).
+   - Tabla-resumen de ejecución al inicio (REUSABLE / PARTIAL / MISSING, insertados vs reutilizados).
+   - Relación caso→datos **agrupada por seed**: casos con seed idéntico en un solo bloque; solo borde/negativo abren bloque individual. Valores literales (negrita = se digita en UI) + `id=` de BD para trazabilidad.
+   - Si fueron 0 inserciones: todos los bloques en estado "reusado" (reporte 7.5).
+
+   **Frontmatter:**
+   ```yaml
+   ---
+   workflow: quality-process
+   phase: datos
+   version: 1.1.0
+   engine: sa-qa-data-generator
+   generated_date: [ISO 8601 date]
+   project_name: {project_name}
+   negocio: [negocio confirmado en PHASE 1.A]
+   run_id: QA_<fecha>_<seq>
+   source_csv: [ruta relativa]/test-cases.csv
+   db_engine: postgresql | mssql
+   inserciones: [N]
+   reutilizados: [N]
+   casos_cubiertos: [N/M]
+   ---
+   ```
 
-```bash
-python {project-root}/_siesa-agents/scripts/bmad_to_agiletest.py \
-  --input "{selected_test_design_path}" \
-  --config "{project-root}/_bmad/bmm/config.yaml" \
-  --jira-url "{jira_base_url}" \
-  --project-key "{jira_project_key}" \
-  --state-dir "{selected_design_folder}" \
-  --create
-```
+2. **`seed.sql`** (entregable 2 — PHASE 7.3) — **solo si hubo inserciones**. Transaccional, idempotente (`ON CONFLICT DO NOTHING` / `IF NOT EXISTS` en SQL Server), ordenado padres→hijos, comentado por caso (`-- Cubre CP-...`), marcado con el ID de corrida, solo registros creados (no REUSABLE). Si fueron 0 inserciones, no generar este archivo.
 
-**Mostrar el output del script en tiempo real.**
+3. **`rollback.sql`** (entregable 3 — PHASE 7.4) — **solo si hubo inserciones**, acotado a los IDs/marcador de **esta** corrida (no un `LIKE 'QA_%'` amplio que borre datos reutilizados de corridas previas). Si fueron 0 inserciones, no generar este archivo.
 
-Si el script retorna un error:
-- Mostrar el error completo
-- Verificar si el state file fue creado (idempotencia: re-ejecutar es seguro)
-- Sugerir acción correctiva según el tipo de error
+**No tocar** datos previamente reutilizados ni datos que no fueron creados por esta corrida.
 
 ---
 
-### F3.6: Completion
+### F4.7: Completion
 
-Parsear la salida final del script y presentar al usuario:
+Presentar al usuario:
 
 ```
-✅ FASE 3 — REGISTRO AGILETEST COMPLETADO
+✅ FASE 4 — GENERACIÓN DE DATOS QA COMPLETADA
 
-  ┌──────────────────────────────┬──────────┬──────────────────────────┐
-  │ Artefacto                    │ Cantidad │ Rango Jira               │
-  ├──────────────────────────────┼──────────┼──────────────────────────┤
-  │ Requisitos (Stories)         │    N     │ {KEY}-XXXX → {KEY}-YYYY  │
-  │ Test Cases                   │    N     │ {KEY}-XXXX → {KEY}-YYYY  │
-  │ Test Plans (PPR)             │    N     │ {KEY}-XXXX, ...          │
-  │ Ejecuciones (PEP)            │    N     │ {KEY}-XXXX, ...          │
-  │ Links Jira (TC→Req+Plan+Exec)│    N     │ —                        │
-  │ Steps de prueba              │    N     │ —                        │
-  └──────────────────────────────┴──────────┴──────────────────────────┘
+📁 Carpeta: {implementation_artifacts}/quality-process/datos/data-gen-{negocio-slug}-YYYY-MM-DD-HHmmss/
 
-  ⏱️  Tiempo total: ~5 minutos
+🏷️  Negocio confirmado: [negocio de PHASE 1.A]
 
-  📋 Keys para el Dashboard Forge (Confluence):
-    planKeys:  {lista de keys PPR separados por coma}
-    execKeys:  {lista de keys PEP separados por coma}
+📊 Resumen:
+  • Casos de prueba:        [M]
+  • REUSABLE (0 inserción): [N]
+  • PARTIAL (parcial):      [N]
+  • MISSING (completo):     [N]
+  • Registros insertados:   [N]
+  • Registros reutilizados: [N]
+  • Cobertura de datos:     [N/M] casos
 
-  🔗 Verificar en AgileTest:
-    {jira_base_url}/browse/{primer key PEP}
+📄 Archivos:
+  • test-data.md  — relación caso→datos agrupada por seed (lista para Playwright)
+  • seed.sql      — inserciones idempotentes recargables {o "no generado (0 inserciones)"}
+  • rollback.sql  — limpieza acotada a esta corrida {o "no generado (0 inserciones)"}
 
-  💾 State file guardado en:
-    {ruta relativa}/bmad_state_{feature_code}.json
-    (Idempotente: re-ejecutar la Fase 3 con el mismo diseño es seguro)
+⚠️  seed.sql y rollback.sql deben ejecutarse SOLO en ambientes de prueba.
 ```
 
+**⚠️ El workflow termina aquí. El equipo de QA puede ejecutar los casos usando los IDs reportados.**
+
 ---
 
-## FASE 4 — DOR GATE
+## FASE 5 — REGISTRO AGILETEST
 
 ### Objetivo
 
-Verificar que el requerimiento cumple el **Definition of Ready (DoR)** antes de iniciar cualquier labor de construcción o proceso de calidad. Evalúa los ítems activos del checklist DoR BMAD Enterprise y genera un reporte `dor-report.md` con resultado pass/fail por ítem, detalle de cada fallo y acción correctiva requerida.
+Empujar el diseño de pruebas validado por el equipo QA a Jira/AgileTest. Crea automáticamente los artefactos de la herramienta: Requisitos (Stories BL → Tareas), Test Cases con Steps (Gherkin → Pasos), Planes de Prueba (PPR), Planes de Ejecución (PEP) y todos los links de trazabilidad. Requiere aprobación humana explícita antes de crear cualquier issue.
 
-**Principio:** Si el Índice de Completitud es inferior al 90%, el sistema activa BLOQUEO TOTAL. El agente tiene prohibido iniciar cualquier labor de construcción.
+**Principio:** "La IA acelera, el humano dirige y autoriza."
 
 ---
 
-### F4.1: Auto Document Discovery (Zero User Interaction)
+### F5.1: Seleccionar Diseño a Registrar
 
-Buscar y leer automáticamente los documentos necesarios para evaluar el DoR:
+**Buscar diseños disponibles:**
 
-```
-🔍 DOR Gate — Buscando documentos fuente...
-```
+1. Listar todas las subcarpetas en `{implementation_artifacts}/quality-process/diseno/` con patrón `test-design-*`
+2. Para cada carpeta encontrada, verificar que existe `test-design.md` (narrativo) **y** `test-design.yml` (machine-readable, el que consume el script) en su raíz
+3. Ordenar por nombre descendente (el timestamp garantiza orden cronológico — más reciente primero)
 
-#### Documento 1 — PRD / Requerimientos (OBLIGATORIO)
+**Mostrar lista al usuario:**
 
-El PRD siempre vive en `{planning_artifacts}/prd` — puede ser un archivo o una carpeta:
+```
+📁 Diseños de prueba disponibles:
 
-**Caso A — archivo único:**
-- Buscar: `{planning_artifacts}/prd.md`
-- Si encontrado: leer contenido completo → almacenar en `dor_prd`
+  1. test-design-YYYY-MM-DD-HHmmss/  ← más reciente
+     • test-design.md ✅
+     • test-cases.csv ✅
 
-**Caso B — carpeta con múltiples archivos:**
-- Buscar con Glob: `{planning_artifacts}/prd/**/*.md`
-- Si encontrado: leer y concatenar el contenido de todos los archivos `.md` → almacenar en `dor_prd`
+  2. test-design-YYYY-MM-DD-HHmmss/
+     ...
+```
 
-Si ninguno de los dos casos produce contenido: `dor_prd = null` → **BLOQUEO**: sin PRD no se puede evaluar el DoR
+Si solo hay uno, seleccionarlo automáticamente y notificar:
+```
+✅ Diseño seleccionado automáticamente (único disponible):
+   {implementation_artifacts}/quality-process/diseno/test-design-YYYY-MM-DD-HHmmss/
+```
 
-#### Documento 2 — Épicas / Historias de Usuario (para P1 y P2)
+Si hay más de uno, preguntar al usuario:
+```json
+{
+  "questions": [
+    {
+      "question": "¿Qué diseño deseas registrar en AgileTest?",
+      "header": "Selección de Diseño — Fase 5 Registro AgileTest",
+      "multiSelect": false,
+      "options": [
+        { "label": "test-design-YYYY-MM-DD-HHmmss (más reciente)", "description": "N TCs — generado el DD/MM/YYYY" },
+        { "label": "test-design-YYYY-MM-DD-HHmmss", "description": "N TCs — generado el DD/MM/YYYY" }
+      ]
+    }
+  ]
+}
+```
 
-El DOR se evalúa sobre features que ya tienen épicas creadas. Cargar usando el mismo patrón que las otras fases:
+**Almacenar:**
+- `selected_design_folder` → ruta absoluta a la carpeta seleccionada
+- `selected_test_design_path` → `{selected_design_folder}/test-design.yml` (el script `bmad_to_agiletest.py` parsea YAML, NO Markdown — pasar el `.yml`, no el `.md`)
 
-1. Leer `{implementation_artifacts}/feature-status.yaml`
-2. Por cada feature, leer su archivo `epic_source` y concatenar contenido → almacenar en `dor_epics`
+**Leer `test-design.md` y mostrar resumen rápido:**
 
-Si `feature-status.yaml` no existe:
-- Buscar con Glob: `{planning_artifacts}/*epic*.md`
-- Si encontrado: leer y concatenar → almacenar en `dor_epics`
-- Si no encontrado: `dor_epics = null` (continuar sin épicas — P1 se evalúa solo contra el PRD)
+```
+📋 Diseño seleccionado:
+  • Archivo:    {ruta relativa}/test-design.md
+  • Features:   [conteo de features distintos en la columna Feature de la Matriz]
+  • Stories BL: [extraer de Sección I — Gatekeeper]
+  • Test Cases: [extraer de Sección V — Matriz Integral 360°]
+  • CSV:        test-cases.csv — [N filas]
+```
 
 ---
 
-#### Documento 3 — Arquitectura (OBLIGATORIO para P2)
+### F5.1b: Seleccionar Instancia Jira
 
-Buscar con Glob en este orden:
-1. `{planning_artifacts}/architecture.md`
-2. `{planning_artifacts}/architecture-decision.md`
-3. `{planning_artifacts}/*architecture*.md`
-4. `{planning_artifacts}/*adr*.md`
+**Cargar opciones:**
 
-Si encontrado: leer contenido completo → almacenar en `dor_architecture`
-Si no encontrado: `dor_architecture = null` → P2 se marcará como NO EVALUABLE
+Usar la herramienta **Read** sobre `{project-root}/.claude/commands/get-features/oauth-config.json`.
 
-#### Documento P4 — No cargado (pendiente de definición)
+- Si no existe → la única opción disponible es "Otra instancia".
+- Si existe → parsear `instances[]` (campos: `name`, `url`, `id`).
 
-- **P4 (Contratos de Interfaz):** La ruta, formato y proceso de subida del esquema
-  OpenAPI/Swagger aún no están definidos. No se carga ningún documento.
+**Presentar AskUserQuestion — opciones del array + "Otra instancia" al final:**
 
-#### Documento P6 — Plan de Pruebas
+```
+Por cada entrada en instances[]:
+  label:       "{entry.name} — {entry.url}"
+  description: "cloud_id: {entry.id}"
 
-Listar todos los directorios en `{implementation_artifacts}/quality-process/planeacion/`
-que sigan el patrón `test-plan-*`. Ordenar descendente por nombre (el timestamp garantiza orden cronológico).
-Almacenar la lista como `dor_test_plan_options` para que P6 la use en la selección interactiva.
+Última opción fija:
+  label:       "Otra instancia"
+  description: "Ingresa la URL base manualmente"
+```
 
-Si no existe ningún directorio con ese patrón: `dor_test_plan_options = []` (P6 marcará NO_PASA).
+- Si selecciona una entrada del array → `jira_base_url` = `entry.url`, `instancia_es_otra` = false
+- Si selecciona "Otra instancia" → `jira_base_url` = null, `instancia_es_otra` = true
 
-#### Documento P7 — Cargar project-context
+**Almacenar:** `jira_base_url`, `instancia_es_otra`
 
-Buscar `_bmad-output/project-context.md`. Si existe, anotar la ruta como `dor_project_context`.
-Si no existe, `dor_project_context = null` (P7 marcará NO_PASA automáticamente).
+---
 
-#### Validación mínima
+### F5.1c: Seleccionar Proyecto Jira
 
-Si `dor_prd = null`: detener con mensaje:
+**Cargar opciones** (archivo ya leído en F5.1b):
 
-```
-❌ No se encontró el PRD en las rutas estándar del proyecto.
+Parsear `projects[]` del mismo JSON (campos: `key`, `name`).
 
-Ruta esperada: {planning_artifacts}/prd.md (y variantes)
+**Presentar AskUserQuestion — opciones del array + "Otro proyecto" al final:**
 
-El DOR Gate requiere un PRD para ejecutarse. Por favor sube el PRD
-al repositorio y vuelve a ejecutar la Fase 4.
 ```
+Por cada entrada en projects[]:
+  label:       "{entry.key} — {entry.name}"
+  description: ""
 
-#### Reporte de documentos encontrados
-
-Mostrar al usuario:
-
+Última opción fija:
+  label:       "Otro proyecto"
+  description: "Ingresa el project key manualmente"
 ```
-📋 DOR Gate — Documentos cargados:
-
-  {✅|❌} PRD:          {ruta relativa o "No encontrado — BLOQUEANTE"}
-  {✅|⚠️} Épicas:       {ruta(s) relativa(s) o "No encontrado — P1/P2 sin contexto de stories"}
-  {✅|⚠️} Arquitectura: {ruta relativa o "No encontrado — P2 no evaluable"}
-  ⏭  API Schema:      No evaluable — ruta/formato pendiente de definición (P4)
-  {✅|⚠️} Plan de Pruebas: {implementation_artifacts}/quality-process/planeacion/test-plan-YYYY-MM-DD-HHmmss/test-plan.md ({N} plan(es) encontrado(s) — P6 pedirá selección)
-  {✅|⚠️} Project Context: {ruta relativa o "No encontrado — P7 marcará NO_PASA"}
 
-🚀 Ejecutando evaluación DoR...
-```
+- Si selecciona una entrada del array → `jira_project_key` = `entry.key`, `proyecto_es_otro` = false
+- Si selecciona "Otro proyecto" → `jira_project_key` = null, `proyecto_es_otro` = true
 
-Proceder directamente a F4.2 sin esperar confirmación del usuario.
+**Almacenar:** `jira_project_key`, `proyecto_es_otro`
 
 ---
 
-### F4.2: Cargar y Ejecutar Megaprompt DOR
+### F5.1d: Resolver valores manuales (solo si aplica)
 
-**Step F4.2.1: Cargar prompt**
-
-Leer el archivo completo: `{workflow_root}/prompts/prompt_dor_gate.md`
-
-**Step F4.2.2: Inyectar inputs**
+**Evaluar qué falta:**
 
-```
-# [INPUT DOR]:
-- **PRD**: {dor_prd}
-- **ÉPICAS / HISTORIAS DE USUARIO**: {dor_epics}
-- **ARQUITECTURA**: {dor_architecture}
-```
+- Si `instancia_es_otra` = false Y `proyecto_es_otro` = false → saltar este paso, ir a F5.2.
+- Si `instancia_es_otra` = true O `proyecto_es_otro` = true → hacer UNA SOLA pregunta combinada.
 
-**Step F4.2.3: Ejecutar evaluación**
+**Una única pregunta que pide solo lo que falta:**
 
-Notificar al usuario:
+- Solo falta instancia → `"Ingresa la URL base de Jira (ej: https://miempresa.atlassian.net)"`
+- Solo falta proyecto → `"Ingresa el Project Key (ej: CON, CLOUD, RUTA)"`
+- Faltan ambos → `"Ingresa la URL base de Jira y el Project Key (ej: https://miempresa.atlassian.net CLOUD)"`
 
-```
-⚙️ Evaluando ítems del DoR...
-   • P1: Índice de Completitud PRD (LLM scoring)
-   • P2: Consistencia PRD ↔ Arquitectura
-   • P3: Negocio y Valor (métricas/objetivos)
-   • P6: Plan de Pruebas (selección interactiva + 7 secciones)
-   • P7: Inyección de Contexto (project-context.md)
-   ─────────────────────────────────────────
-   ⏭  P4: Contratos de Interfaz — NO EVALUABLE (ruta/formato pendiente)
-```
+Parsear la respuesta y almacenar en `jira_base_url` y/o `jira_project_key` según corresponda.
 
-Ejecutar el prompt con los inputs cargados. El prompt produce un JSON de resultados estructurado con el resultado de cada ítem.
+**No hacer preguntas adicionales después de este paso.**
 
 ---
 
-### F4.3: Guardar Output
+### F5.2: Validar Credenciales (Pre-flight)
 
-**Generar timestamp:** `YYYY-MM-DD-HHmmss`
+Antes de ejecutar el dry-run, verificar que las credenciales están disponibles.
+El script las busca en este orden de prioridad:
+1. `_siesa-agents/bmm/config.secrets.yaml` (archivo local gitignoreado — forma recomendada)
+2. Variables de entorno `JIRA_API_TOKEN`, `AGILETEST_CLIENT_ID`, `AGILETEST_CLIENT_SECRET`
 
-**Ruta de salida:**
-```
-{implementation_artifacts}/quality-process/dor/dor-report-YYYY-MM-DD-HHmmss/dor-report.md
-```
+**Leer `_siesa-agents/bmm/config.secrets.yaml` y verificar que los tokens no estén vacíos:**
 
-**Frontmatter del documento generado:**
-```yaml
----
-workflow: quality-process
-phase: dor
-version: 1.0.0
-methodology: BMAD DOR Gate
-generated_date: [ISO 8601]
-project_name: {project_name}
-resultado: PASA | NO PASA
-items_evaluados:
-  - P1
-  - P2
-  - P3
-  - P6
-  - P7
-items_no_evaluados:
-  P4: pendiente — ruta y formato del esquema API por definir
-source_documents:
-  prd: [ruta relativa o null]
-  architecture: [ruta relativa o null]
-  api_schema: [ruta relativa o null]
-  project_context: [ruta relativa o null]
-  test_plan: [ruta relativa o null]
----
+```
+📋 Estado de credenciales en _siesa-agents/bmm/config.secrets.yaml:
+  jira_api_token:          [configurado ✅ | vacío ⚠️]
+  agiletest_client_id:     [configurado ✅ | vacío ⚠️]
+  agiletest_client_secret: [configurado ✅ | vacío ⚠️]
 ```
 
-**Cuerpo del documento** — el título debe ser lo primero visible tras el frontmatter.
-El bloque JSON de resultados va al final dentro de un `<details>` colapsado:
+**Si todos están configurados:** continuar a F5.3.
 
-```markdown
-# DOR Report — {project_name}
+**Si alguno está vacío**, mostrar instrucciones y DETENER:
 
-**Resultado global: ✅ PASA / ❌ NO PASA**
-**Fecha:** {generated_date}
+```
+⚠️  Faltan credenciales en _siesa-agents/bmm/config.secrets.yaml
 
-## Resultado por ítem
+Abre el archivo y completa los valores:
 
-| Ítem | Estado | Score | Detalle |
-|------|--------|-------|---------|
-| P1 — Completitud PRD    | ✅/❌ | {score}% | {secciones faltantes o "—"} |
-| P2 — Consistencia Arq.  | ✅/❌ | —        | {entidades no encontradas o "—"} |
-| P3 — Negocio y Valor    | ✅/❌ | —        | {detalle o "—"} |
-| P4 — Contratos API      | ⏭    | —        | No evaluable — ruta y formato del esquema API por definir |
-| P6 — Plan de Pruebas    | ✅/❌ | —        | {plan seleccionado + secciones faltantes o "—"} |
-| P7 — Inyección Contexto | ✅/❌ | —        | {secciones faltantes o "—"} |
+  agiletest:
+    jira_api_token: "tu-token-aqui"
+    agiletest_client_id: "tu-client-id"
+    agiletest_client_secret: "tu-client-secret"
 
-## Detalle P1 — Completitud PRD {✅/❌} {score}%
+Dónde obtenerlos:
+  • jira_api_token:          Jira → Profile → Security → API tokens → Create
+  • agiletest_client_id/secret: AgileTest plugin en Jira → Settings → API Keys
 
-| Sección | Score | Nota |
-|---------|-------|------|
-| Objetivos | {score}% | {nota} |
-| Alcance | {score}% | {nota} |
-| Criterios de Aceptación | {score}% | {nota} |
-| Métricas de Éxito | {score}% | {nota} |
-| Definiciones Técnicas | {score}% | {nota} |
-| Flujos / Reglas de Negocio | {score}% | {nota} |
+El archivo ya está en .gitignore — es seguro guardar los tokens ahí.
+Una vez completados, vuelve a ejecutar la Fase 5.
+```
 
-## Detalle P2 — Consistencia PRD ↔ Arquitectura {✅/❌} {score}%
+---
 
-- **Entidades evaluadas:** {N}
-- **Encontradas:** {N} — {lista}
-- **No encontradas:** {lista o "ninguna"}
-- **Parciales:** {lista o "ninguna"}
+### F5.2b: Resolver agiletest_project_id
 
-## Detalle P3 — Negocio y Valor {✅/❌} {score}%
+**Verificar si ya está configurado:**
 
-- **Objetivos:** {VÁLIDO/INVÁLIDO/AUSENTE} — {nota}
-- **Métricas:** {VÁLIDO/INVÁLIDO/AUSENTE} — {nota}
+Leer `_siesa-agents/bmm/config.secrets.yaml`. Si `agiletest_project_id` tiene un valor no vacío, mostrar:
+```
+✅ agiletest_project_id ya configurado: {valor} — omitiendo resolución.
+```
+Y continuar a F5.3.
 
-## Acciones requeridas
+**Si está vacío:** resolver automáticamente vía la API de Jira usando Bash tool:
 
-{Si PASA:}
-✅ El requerimiento cumple el DoR. Puede continuar a Planeación (Fase 1).
+```bash
+python -c "
+import urllib.request, base64, json, re, sys
 
-{Si NO PASA:}
-❌ Corregir los siguientes ítems antes de continuar:
-{por cada ítem fallido: descripción exacta de qué falta y cómo corregirlo}
+secrets_path = '{project-root}/_siesa-agents/bmm/config.secrets.yaml'
+with open(secrets_path, encoding='utf-8') as f:
+    content = f.read()
 
-```
+def extract(key, text):
+    m = re.search(rf'^\s+{key}:\s*[\"\'"]?(.+?)[\"\'"]?\s*$', text, re.MULTILINE)
+    return m.group(1).strip().strip('\"').strip(\"'\") if m else ''
 
-**🚨 IMPORTANTE:** El JSON de resultados que produce el prompt se usa ÚNICAMENTE
-de forma interna para construir el reporte. **NO escribirlo en el archivo `dor-report.md`.**
+email   = extract('jira_user_email',   content)
+token   = extract('jira_api_token',    content)
+base    = '{jira_base_url}'
+key     = '{jira_project_key}'
 
----
+creds   = base64.b64encode(f'{email}:{token}'.encode()).decode()
+req     = urllib.request.Request(
+    f'{base}/rest/api/3/project/{key}',
+    headers={'Authorization': f'Basic {creds}', 'Accept': 'application/json'}
+)
+with urllib.request.urlopen(req, timeout=10) as r:
+    data = json.loads(r.read().decode())
 
-### F4.4: Completion
+project_id = str(data['id'])
+print(f'PROJECT_ID={project_id}')
+"
+```
 
-Presentar al usuario:
+**Parsear la salida:** extraer el valor después de `PROJECT_ID=` → almacenar en `resolved_project_id`.
 
-```
-{Si PASA:}
-✅ DOR GATE — PASA
+**Si la llamada falla:** mostrar el error y DETENER — no continuar sin el ID porque los pasos 4, 6 y 7 de AgileTest fallarán con HTTP 400.
 
-📁 Reporte: {implementation_artifacts}/quality-process/dor/dor-report-YYYY-MM-DD-HHmmss/dor-report.md
+**Persistir en config.secrets.yaml usando Bash tool:**
 
-📊 Resumen:
-  • P1 Completitud:       ✅ {score}%
-  • P2 Consistencia Arq.: ✅
-  • P3 Negocio y Valor:   ✅
-  • P4 Contratos API:     ⏭  No evaluable
-  • P6 Plan de Pruebas:   ✅
-  • P7 Contexto:          ✅
+```bash
+python -c "
+import re
 
-El requerimiento está listo para continuar.
+path = '{project-root}/_siesa-agents/bmm/config.secrets.yaml'
+with open(path, encoding='utf-8') as f:
+    content = f.read()
 
-{Si NO PASA:}
-❌ DOR GATE — NO PASA
+new_line = '  agiletest_project_id: \"{resolved_project_id}\"'
 
-📁 Reporte: {implementation_artifacts}/quality-process/dor/dor-report-YYYY-MM-DD-HHmmss/dor-report.md
+if re.search(r'^\s+agiletest_project_id:', content, re.MULTILINE):
+    content = re.sub(r'^\s+agiletest_project_id:.*$', new_line, content, flags=re.MULTILINE)
+else:
+    content = re.sub(r'(agiletest:\n)', r'\1' + new_line + '\n', content)
 
-📊 Resumen:
-  • P1 Completitud:       {✅/❌} {score}%
-  • P2 Consistencia Arq.: {✅/❌}
-  • P3 Negocio y Valor:   {✅/❌}
-  • P4 Contratos API:     ⏭  No evaluable
-  • P6 Plan de Pruebas:   {✅/❌}
-  • P7 Contexto:          {✅/❌}
+with open(path, 'w', encoding='utf-8') as f:
+    f.write(content)
 
-❌ Ítems fallidos: {N}
-→ Devolver a refinamiento. Ver sección "Acciones requeridas" en el reporte.
+print('OK')
+"
 ```
 
-**⚠️ NO sugerir continuar con ninguna otra fase si el resultado es NO PASA. El workflow termina aquí.**
+**Confirmar al usuario:**
+```
+✅ agiletest_project_id resuelto y guardado: {resolved_project_id}
+   (Proyecto {jira_project_key} en {jira_base_url})
+   Guardado en config.secrets.yaml — no se volverá a resolver en próximas ejecuciones.
+```
 
 ---
 
-## FASE 5 — IMPLEMENTACIÓN PLAYWRIGHT
+### F5.3: Dry-run — Vista Previa Obligatoria
 
-### Objetivo
+**Ejecutar dry-run usando Bash tool:**
 
-Generar código Playwright para los test cases del CSV (producido en Fase 2) que aún no tienen cobertura en los spec files del proyecto. La fase realiza un gap analysis automático, clasifica cada test por la tecnología correcta (Playwright E2E, Vitest Unit FE, .NET xUnit BE), genera el código E2E completo para los gaps en scope, lo inyecta en los archivos spec existentes con aprobación humana, y actualiza el estado del CSV.
+```bash
+python {project-root}/_siesa-agents/scripts/bmad_to_agiletest.py \
+  --input "{selected_test_design_path}" \
+  --config "{project-root}/_bmad/bmm/config.yaml" \
+  --jira-url "{jira_base_url}" \
+  --project-key "{jira_project_key}" \
+  --dry-run
+```
 
-**Principio:** "No se escribe ni un test sin gate humano. La IA genera, el humano aprueba."
+> **Flags opcionales para pruebas parciales** (útiles para validar el flujo sin procesar todo el diseño):
+> - `--pilot` → procesa solo la Feature `F4` (Events) — subconjunto fijo para smoke-test del flujo.
+> - `--feature-filter F1` → procesa solo la feature indicada (match exacto contra la clave de feature).
+> Ambos aplican igual a `--dry-run` y a `--create`.
 
----
+**Parsear la salida y presentar al usuario en tabla ordenada:**
 
-### F5.1: Seleccionar Diseño Fuente
+```
+📊 Vista previa — Lo que se creará en Jira/AgileTest:
 
-**Buscar diseños disponibles:**
+  ┌──────────────────────────┬──────────┐
+  │ Artefacto                │ Cantidad │
+  ├──────────────────────────┼──────────┤
+  │ Requisitos (Stories BL)  │    N     │
+  │ Test Cases               │    N     │
+  │   • P0 (Muy Alta)        │    N     │
+  │   • P1 (Alta)            │    N     │
+  │   • P2 (Media)           │    N     │
+  │   • P3 (Baja)            │    N     │
+  │ Planes de Prueba (PPR)   │    N     │
+  │ Planes de Ejecución (PEP)│    N     │
+  │ Links de trazabilidad    │  ~N      │
+  │ Steps de prueba          │  ~N      │
+  └──────────────────────────┴──────────┘
 
-1. Listar todas las subcarpetas en `{implementation_artifacts}/quality-process/diseno/` con patrón `test-design-*`
-2. Para cada carpeta encontrada, verificar que existe `test-cases.csv` en su raíz
-3. Ordenar por nombre descendente — el timestamp garantiza orden cronológico (más reciente primero)
+  📋 Distribución por Feature:
+    F1 — [Nombre]: N TCs
+    F2 — [Nombre]: N TCs
+    ...
 
-**Si solo hay uno**, seleccionarlo automáticamente:
-```
-✅ CSV seleccionado automáticamente:
-   {implementation_artifacts}/quality-process/diseno/test-design-YYYY-MM-DD-HHmmss/test-cases.csv
+  🎯 Proyecto Jira: {jira_project_key}
+  ⏱️  Tiempo estimado: ~5 minutos
 ```
 
-**Si hay más de uno**, preguntar al usuario:
+---
+
+### F5.4: Gate de Aprobación Humana (OBLIGATORIO)
+
+Este paso es **no omisible**. No se crea ningún issue sin aprobación explícita.
+
+**Preguntar al usuario usando AskUserQuestion:**
+
 ```json
 {
   "questions": [
     {
-      "question": "¿De qué diseño quieres implementar los test cases?",
-      "header": "Selección de Diseño — Fase 5 Implementación Playwright",
+      "question": "¿Apruebas la creación de estos N issues en Jira/AgileTest?",
+      "header": "⚠️ Confirmación Requerida — Creación en AgileTest",
       "multiSelect": false,
       "options": [
-        { "label": "test-design-YYYY-MM-DD-HHmmss (más reciente)", "description": "N TCs — generado el DD/MM/YYYY" },
-        { "label": "test-design-YYYY-MM-DD-HHmmss", "description": "N TCs — generado el DD/MM/YYYY" }
+        {
+          "label": "✅ Aprobar y crear en AgileTest",
+          "description": "Se crearán los N issues en el proyecto Jira. Esta acción es reversible (el script tiene modo --delete para limpiar)."
+        },
+        {
+          "label": "🔍 Ver detalle de TCs antes de decidir",
+          "description": "Mostrar cada TC con sus pasos antes de aprobar"
+        },
+        {
+          "label": "❌ Cancelar — no crear nada",
+          "description": "Salir sin crear issues en Jira/AgileTest"
+        }
       ]
     }
   ]
 }
 ```
 
-**Almacenar:**
-- `selected_csv_path` → ruta absoluta al `test-cases.csv` seleccionado
-- `selected_design_folder` → carpeta raíz del diseño seleccionado
-
-**Leer `test-cases.csv` completo** — almacenar en `csv_content`.
+**Si "Ver detalle":** Ejecutar con `--detail` y regresar a este mismo gate:
 
-Mostrar resumen rápido:
-```
-📋 CSV cargado:
-  • Archivo:   {ruta relativa}/test-cases.csv
-  • Total TCs: [N filas descontando header]
-  • Features:  [lista de IDs de épica únicos extraídos de columna "ID Épica"]
-  • P0:        [N TCs con Priority: P0 en columna Notas]
-  • P1:        [N TCs con Priority: P1]
+```bash
+python {project-root}/_siesa-agents/scripts/bmad_to_agiletest.py \
+  --input "{selected_test_design_path}" \
+  --config "{project-root}/_bmad/bmm/config.yaml" \
+  --jira-url "{jira_base_url}" \
+  --project-key "{jira_project_key}" \
+  --dry-run --detail
 ```
 
----
+Mostrar el detalle y volver a presentar el gate de aprobación.
 
-### F5.2: Carga de Spec Files Existentes (Zero User Interaction)
+**Si "Cancelar":** Notificar `❌ Operación cancelada. No se creó ningún issue.` y terminar el workflow.
 
-**Descubrir automáticamente los spec files del proyecto:**
+**Si "Aprobar":** Continuar a F5.5.
 
-1. Buscar con Glob: `{project-root}/frontend/tests/e2e/**/*.spec.ts`
-2. Para cada archivo encontrado, leer su contenido completo
-3. Almacenar como mapa `spec_files`: `{ ruta_relativa: contenido }`
+---
 
-**Notificar al usuario:**
-```
-🔍 Spec files encontrados:
-  • {ruta relativa 1} ({N} líneas)
-  • {ruta relativa 2} ({N} líneas)
-  ...
-  Total: {N} archivos | {N} líneas
-```
+### F5.5: Crear en AgileTest
 
-**También cargar configuración del proyecto de tests:**
+**Notificar inicio:**
 
-4. Leer `{project-root}/frontend/playwright.config.ts` → almacenar en `playwright_config`
-5. Leer `{project-root}/frontend/tests/support/fixtures/index.ts` (o el barrel de fixtures) → almacenar en `fixtures_api`
+```
+🚀 Iniciando creación en Jira/AgileTest...
 
-Si alguno no existe, continuar sin él (no es bloqueante).
+  Proyecto: {jira_project_key}
+  Input:    {ruta relativa}/test-design.yml
+  State:    {ruta relativa}/bmad_state_{feature_code}.json
 
----
+  Progreso de los 8 pasos:
+```
 
-### F5.3: Análisis de Cobertura + Generación de Código (Megaprompt)
+**Ejecutar el script usando Bash tool:**
 
-**Notificar al usuario:**
-```
-⚙️ Ejecutando análisis de cobertura y generación de tests...
-   • Paso 1: Clasificación por tecnología (Playwright / Vitest / .NET)
-   • Paso 2: Gap analysis (CSV vs spec files existentes)
-   • Paso 3: Generación de código Playwright para los gaps
-   • Paso 4: Revisión de casos especiales (multi-tab, XSS, performance, optimistic)
+```bash
+python {project-root}/_siesa-agents/scripts/bmad_to_agiletest.py \
+  --input "{selected_test_design_path}" \
+  --config "{project-root}/_bmad/bmm/config.yaml" \
+  --jira-url "{jira_base_url}" \
+  --project-key "{jira_project_key}" \
+  --state-dir "{selected_design_folder}" \
+  --create
 ```
 
-**Step F5.3.1: Cargar megaprompt**
+**Mostrar el output del script en tiempo real.**
+
+Si el script retorna un error:
+- Mostrar el error completo
+- Verificar si el state file fue creado (idempotencia: re-ejecutar es seguro)
+- Sugerir acción correctiva según el tipo de error
+
+---
 
-Leer el archivo completo: `{workflow_root}/prompts/prompt_playwright_impl.md`
+### F5.6: Completion
 
-**Step F5.3.2: Inyectar inputs**
+Parsear la salida final del script y presentar al usuario:
 
 ```
-# [INPUTS F5]:
-- **CSV CONTENT**: {csv_content}
-- **SPEC FILES**: {spec_files}
-- **PLAYWRIGHT CONFIG**: {playwright_config}
-- **FIXTURES API**: {fixtures_api}
-```
+✅ FASE 5 — REGISTRO AGILETEST COMPLETADO
+
+  ┌──────────────────────────────┬──────────┬──────────────────────────┐
+  │ Artefacto                    │ Cantidad │ Rango Jira               │
+  ├──────────────────────────────┼──────────┼──────────────────────────┤
+  │ Requisitos (Stories)         │    N     │ {KEY}-XXXX → {KEY}-YYYY  │
+  │ Test Cases                   │    N     │ {KEY}-XXXX → {KEY}-YYYY  │
+  │ Test Plans (PPR)             │    N     │ {KEY}-XXXX, ...          │
+  │ Ejecuciones (PEP)            │    N     │ {KEY}-XXXX, ...          │
+  │ Links Jira (TC→Req+Plan+Exec)│    N     │ —                        │
+  │ Steps de prueba              │    N     │ —                        │
+  └──────────────────────────────┴──────────┴──────────────────────────┘
 
-**Step F5.3.3: Ejecutar**
+  ⏱️  Tiempo total: ~5 minutos
 
-Ejecutar el megaprompt con los inputs inyectados. El prompt produce tres bloques de salida estructurados:
+  📋 Keys para el Dashboard Forge (Confluence):
+    planKeys:  {lista de keys PPR separados por coma}
+    execKeys:  {lista de keys PEP separados por coma}
 
-1. **BLOQUE A — CLASIFICACIÓN**: tabla de todos los TCs con su tecnología asignada y estado de cobertura
-2. **BLOQUE B — CÓDIGO PLAYWRIGHT**: bloques de código TypeScript listos para inyectar, agrupados por spec file destino
-3. **BLOQUE C — OUT-OF-SCOPE**: lista de TCs fuera del scope Playwright (Vitest/BE) con justificación
+  🔗 Verificar en AgileTest:
+    {jira_base_url}/browse/{primer key PEP}
 
-**Almacenar outputs:**
-- `classification_table` ← BLOQUE A
-- `generated_tests` ← BLOQUE B (mapa `spec_file → [test blocks]`)
-- `out_of_scope` ← BLOQUE C
+  💾 State file guardado en:
+    {ruta relativa}/bmad_state_{feature_code}.json
+    (Idempotente: re-ejecutar la Fase 5 con el mismo diseño es seguro)
+```
 
 ---
 
-### F5.4: Gate de Aprobación Humana (OBLIGATORIO)
+## FASE 6 — IMPLEMENTACIÓN + EJECUCIÓN E2E
 
-Presentar resumen al usuario antes de cualquier escritura:
+### Objetivo
 
-```
-📊 Análisis de Cobertura — Resumen
+Generar y **ejecutar** el código Playwright de los casos diseñados, actuando como el **Agente
+Ejecutor E2E** (Agente #4 — ISTQB Test Implementation + Execution). Consume el `test-design.yml`
+(fuente única de Fase 3) + `test-data.md` (Fase 4), enriquece a `.md` con el architecture brief,
+genera los `.spec.ts` con el ciclo **Planner → Generator → Healer** sobre el **Kit Playwright**,
+los promueve con aprobación humana, ejecuta la suite y deja los reportes listos para el RCA.
 
-  Tecnología        │ Total │ Ya cubiertos │ Gaps (nuevos)
-  ──────────────────┼───────┼──────────────┼──────────────
-  Playwright E2E    │  [N]  │     [N]      │     [N]
-  Vitest Unit FE    │  [N]  │     [N]      │     [N]
-  .NET xUnit BE     │  [N]  │     [N]      │     [N]
-  ──────────────────┴───────┴──────────────┴──────────────
-  TOTAL CSV         │  [N]  │     [N]      │     [N]
+**Principio:** "No se escribe ni un test sin gate humano. La IA genera y ejecuta, el humano aprueba."
 
-📝 Tests Playwright a agregar:
+> **Modo orquestado:** dentro del `quality-process` el agente NO rediseña casos (Fase 3) ni
+> genera datos (Fase 4). Su prompt vive en `{workflow_root}/prompts/prompt_e2e_executor.md`.
 
-  {por cada spec file destino:}
-  • {spec_file} → [N] tests nuevos
-    - TC-F*-NNN [PX] <título> (Risk: R=N)
-    - TC-F*-NNN [PX] <título> (Risk: R=N)
-    ...
+---
 
-⚠️  Fuera de scope Playwright:
-  • Vitest: {lista de TC-IDs}
-  • .NET:   {lista de TC-IDs}
-```
+### F6.0: Detección de Input y Pre-flight
+
+1. **Precedencia de input** (buscar en la carpeta de diseño más reciente — ver F6.1):
+   - Si existe `test-design.yml` → **modo YAML** (fuente única, steps atómicos). Preferido.
+   - Si solo existe `test-cases.csv` → **modo CSV** (fallback: gap analysis tradicional con
+     `prompt_playwright_impl.md`).
+2. **Cargar datos:** buscar el `test-data.md` más reciente en
+   `{implementation_artifacts}/quality-process/datos/` → `input_test_data` (opcional).
+3. **Verificar Kit:** confirmar que existe `{project-root}/_siesa-agents/resources/playwright-kit/`.
+   Si falta, avisar que la Etapa de cimientos no está instalada y detener.
+4. **Pre-flight de credenciales E2E (`.env` del Kit):** el `login()` de los specs lee
+   `BASE_URL`, `TEST_USER`, `TEST_PASS` y `DB_ENGINE` desde
+   `{project-root}/_siesa-agents/resources/playwright-kit/.env` (personal, gitignoreado).
+   Sin esto la corrida del Healer (F6.6) y la ejecución oficial (F6.7) **fallan en el login**.
+   - Leer ese `.env` (si existe) y verificar que `BASE_URL` y `TEST_USER`/`TEST_PASS` no estén vacíos.
+   - **Si falta o está incompleto, resolverlo ANTES de generar/ejecutar:** pedir al usuario con
+     AskUserQuestion la URL del ERP y las credenciales de prueba (usuario/clave + BD), y **escribir**
+     el archivo `.env` (a partir de `.env.example`) con esas claves. El `.env` es gitignoreado:
+     es seguro guardarlo ahí. Nunca imprimir el valor de `TEST_PASS` en la salida.
+     ```
+     BASE_URL=https://<erp-del-proyecto>
+     TEST_USER=<usuario_qa>
+     TEST_PASS=<clave_qa>
+     DB_ENGINE=<bd>     # texto a buscar en el combo de login (ej: sqlserver)
+     ```
+   - Confirmar: `✅ .env del Kit configurado (BASE_URL + credenciales).`
 
-**Preguntar al usuario:**
-```json
-{
-  "questions": [
-    {
-      "question": "¿Apruebas inyectar estos [N] tests en los spec files?",
-      "header": "⚠️ Confirmación Requerida — Inyección de Tests",
-      "multiSelect": false,
-      "options": [
-        {
-          "label": "✅ Aprobar e inyectar todos",
-          "description": "Se agregarán [N] tests a los spec files existentes. Los archivos son modificados en el lugar."
-        },
-        {
-          "label": "🔍 Ver código generado primero",
-          "description": "Mostrar el código completo de cada test antes de aprobar"
-        },
-        {
-          "label": "✏️ Aprobar parcialmente",
-          "description": "Seleccionar qué spec files o tests incluir"
-        },
-        {
-          "label": "❌ Cancelar",
-          "description": "No modificar ningún archivo"
-        }
-      ]
-    }
-  ]
-}
+Notificar:
+```
+🎯 Fase 6 — Agente Ejecutor E2E
+  • Input:        [test-design.yml (modo YAML) | test-cases.csv (modo CSV fallback)]
+  • Datos:        [test-data.md encontrado | sin datos — se usarán los del diseño]
+  • Kit:          _siesa-agents/resources/playwright-kit/ ✅
+  • Credenciales: .env del Kit [configurado ✅ | pendiente ⚠️]
 ```
 
-**Si "Ver código generado primero":**
-- Mostrar el código completo de `generated_tests` con bloques de código
-- Volver a presentar el mismo gate
+---
 
-**Si "Aprobar parcialmente":**
-- Preguntar qué spec files incluir (AskUserQuestion multiSelect con un ítem por spec file)
-- Filtrar `generated_tests` según la selección
-- Volver al gate con el subconjunto aprobado
+### F6.1: Seleccionar Diseño Fuente
 
-**Si "Cancelar":**
-- Notificar `❌ Operación cancelada. No se modificó ningún archivo.` y terminar
+1. Listar subcarpetas en `{implementation_artifacts}/quality-process/diseno/` con patrón `test-design-*`.
+2. Ordenar descendente (timestamp) — más reciente primero.
+3. Si solo hay una, seleccionarla automáticamente; si hay varias, preguntar con AskUserQuestion
+   (`Selección de Diseño — Fase 6 Ejecutor E2E`).
 
-**Si "Aprobar":** Continuar a F5.5
+**Almacenar:** `selected_design_folder`, y según el modo: `selected_yml_path` o `selected_csv_path`.
+Leer el archivo fuente → `design_content`. Mostrar resumen (total casos, features, P0/P1).
 
 ---
 
-### F5.5: Inyectar Tests en Spec Files
-
-**Por cada spec file con tests aprobados:**
+### F6.2: Resolver Architecture Brief
 
-1. Leer el archivo spec actual con Read tool
-2. Localizar el bloque de inserción correcto:
-   - Si hay un `test.describe('EPIC-SA-F*'` relacionado → insertar al final de ese describe
-   - Si no hay describe relacionado → insertar al final del archivo
-3. Usar Edit tool para agregar los tests
-4. Notificar: `✅ {spec_file} → {N} tests agregados`
+El brief eleva la autonomía del agente a ~85-90% (selectores + patrones + quirks).
 
-**Reglas de inserción:**
-
-- Mantener la agrupación por `EPIC-SA-F*` (no crear describes nuevos si ya existe el correcto)
-- Respetar el estilo del archivo: imports, indentación, convención de nombres
-- Cada test nuevo sigue el formato: `test('TC-F*-NNN [PX] descripción', async ({...}) => { // GIVEN / WHEN / THEN })`
-- NO modificar tests existentes, solo agregar
+1. Buscar el brief de la app en `{project-root}/_siesa-agents/resources/playwright-kit/specs/`
+   (`architecture-brief-siesa-erp.md` u otro del proyecto) → `input_brief`.
+2. Si no existe o está incompleto, ofrecer con AskUserQuestion:
+   - **Usar template** (`architecture-brief-template.md`) para que un dev lo complete, o
+   - **Grabar con el grabador** (`tools/locator-recorder.spec.ts`) en sesión exploratoria.
+3. Continuar con el brief disponible (no es bloqueante, pero advertir si falta — baja la autonomía).
 
 ---
 
-### F5.6: Actualizar CSV — Estado de Tests Implementados
+### F6.3: Enriquecer — YAML → `.md` de plan
 
-Una vez inyectados los tests con éxito:
+**Modo YAML:** convertir el `test-design.yml` al `.md` enriquecido que consume el Generator:
+```bash
+npx tsx {project-root}/_siesa-agents/scripts/playwright/yaml-to-playwright-spec.ts \
+  "{selected_yml_path}" --output "{run_folder}/specs/{modulo}.plan.md"
+```
+Luego inyectar el `input_brief` (selectores, patrones, problemas conocidos) en la sección
+"Contexto Técnico" del `.md`. Si los `steps` del YAML vienen narrativos (string), expandirlos a
+pasos atómicos antes de convertir.
 
-1. Leer el CSV actual desde `{selected_csv_path}`
-2. Para cada TC implementado, cambiar la columna `Estado` de `"Not Started"` a `"Implemented"`
-3. Dejar los TCs fuera de scope (Vitest/BE) como `"Not Started"` (no es responsabilidad de Playwright)
-4. Reconstruir el CSV completo en memoria respetando las mismas reglas de escape del Fase 2:
-   - Todos los campos entre comillas dobles
-   - Comillas internas duplicadas: `"` → `""`
-5. Guardar con Write tool en la misma ruta `{selected_csv_path}`
+**Modo CSV (fallback):** descubrir spec files existentes en `{project-root}/frontend/tests/e2e/**/*.spec.ts`
+y continuar con el gap analysis de `prompt_playwright_impl.md` (flujo previo).
 
-**Notificar:**
-```
-📄 CSV actualizado:
-  • {N} tests → Estado: "Implemented"
-  • {N} tests → Estado: "Not Started" (fuera de scope Playwright)
-  • Archivo: {ruta relativa}
-```
+`{run_folder}` = `{implementation_artifacts}/quality-process/playwright/e2e-run-YYYY-MM-DD-HHmmss/`.
 
 ---
 
-### F5.7: Guardar Reporte de Implementación
-
-Generar timestamp `YYYY-MM-DD-HHmmss` y guardar:
+### F6.4: Generación (Generator) — Megaprompt
 
-```
-{output_folder}/implementation-artifacts/quality-process/playwright/playwright-impl-YYYY-MM-DD-HHmmss/implementation-report.md
-```
+1. **Cargar el megaprompt:** leer `{workflow_root}/prompts/prompt_e2e_executor.md`.
+2. **Inyectar inputs:**
+   ```
+   - TEST DESIGN (YAML): {selected_yml_path | "—"}
+   - TEST DATA:          {input_test_data | "—"}
+   - TEST CASES (CSV):   {selected_csv_path | "—"}
+   - ARCHITECTURE BRIEF: {input_brief}
+   - SPEC FILES:         {spec_files | "—"}
+   - KIT:                _siesa-agents/resources/playwright-kit/
+   ```
+3. **Ejecutar.** El prompt produce 3 bloques: **A — Clasificación**, **B — Código Playwright**,
+   **C — Out-of-scope**. Escribir el código del Bloque B en `{run_folder}/proposed/*.spec.ts`
+   (staging — NUNCA directo a `tests/`).
 
-**Contenido del reporte:**
+**🔵 Review Gate #1:** presentar el plan/clasificación al usuario antes de generar todo el código.
 
-```markdown
 ---
-workflow: quality-process
-phase: playwright-impl
-version: 1.0.0
-generated_date: [ISO 8601]
-project_name: {project_name}
-source_csv: {ruta relativa}/test-cases.csv
+
+### F6.5: Gate de Aprobación Humana (OBLIGATORIO)
+
+Presentar resumen (cobertura por tecnología, tests nuevos por spec, out-of-scope) y preguntar con
+AskUserQuestion: **Aprobar e inyectar** / **Ver código primero** / **Aprobar parcialmente** /
+**Cancelar**. No se promueve ni ejecuta nada sin aprobación explícita.
+
 ---
 
-# Playwright Implementation Report
+### F6.6: Healer Loop (reparación)
 
-**Fecha:** {generated_date}
-**Tests implementados:** [N]
-**Tests fuera de scope:** [N]
+Ejecutar `{run_folder}/proposed/` en local/headless **solo para reparar** (no es la corrida oficial):
+```bash
+cd {project-root}/_siesa-agents/resources/playwright-kit
+npx playwright test {run_folder}/proposed/ --config playwright.config.ts
+```
+Por cada fallo: diagnosticar (cambio UI / bug real / flake), corregir el spec en `proposed/`, repetir
+(máx. N iteraciones). Consultar el brief y los "Problemas Conocidos". Si el Healer descubre un patrón
+nuevo, agregarlo al brief con prefijo `[HEALER]`.
+
+---
 
-## Cobertura por Feature
+### F6.7: Promover a `tests/` + Sync AgileTest
 
-| Feature | CSV Total | Ya existían | Nuevos | Vitest | .NET |
-|---|---|---|---|---|---|
-| F1 | N | N | N | N | N |
-| F2 | N | N | N | N | N |
-| F3 | N | N | N | N | N |
-| F4 | N | N | N | N | N |
+**🔵 Review Gate #2:** humano verifica assertions y selectores de los specs ya verdes.
 
-## Tests Implementados
+1. Mover los specs aprobados de `{run_folder}/proposed/` → `{run_folder}/tests/`.
+2. Si hay env vars de AgileTest (`AGILETEST_*`), el `reporters/agiletest-reporter.ts` sincroniza la
+   Execution (Pass/Fail por step). **Credenciales desde entorno / `config.secrets.yaml`, nunca literales.**
 
-| ID | Título | Risk | Archivo |
-|---|---|---|---|
-{fila por cada test implementado}
+---
+
+### F6.8: Ejecución Oficial (cierra el gap hacia el RCA)
 
-## Tests Fuera de Scope Playwright
+Preguntar con AskUserQuestion la ruta de ejecución:
 
-### Vitest (Unit FE)
-| ID | Título | Razón |
-|---|---|---|
+```json
+{
+  "questions": [
+    {
+      "question": "¿Cómo ejecutamos la suite oficial?",
+      "header": "Ejecución E2E — Fase 6",
+      "multiSelect": false,
+      "options": [
+        {
+          "label": "✅ Ejecutar aquí (Recomendado)",
+          "description": "Corre la suite sobre el Kit y genera allure-results/monocart-report/test-results (insumos directos del RCA)."
+        },
+        {
+          "label": "Delegar a CI",
+          "description": "Hace push y la GitHub Action ejecuta; la Fase 7 (RCA) leerá los artefactos del CI."
+        }
+      ]
+    }
+  ]
+}
+```
 
-### .NET xUnit (BE)
-| ID | Título | Razón |
-|---|---|---|
+**Ruta A — Ejecutar aquí:**
+```bash
+cd {project-root}/_siesa-agents/resources/playwright-kit
+SUITE_TITLE="E2E {modulo}" npx playwright test {run_folder}/tests/ --config playwright.config.ts
 ```
+Copiar/generar en `{run_folder}/`: `allure-results/`, `monocart-report/`, `test-results/`.
+
+**Ruta B — Delegar a CI:** registrar que la ejecución corre en CI; la Fase 7 leerá esos artefactos.
 
 ---
 
-### F5.8: Completion
+### F6.9: Actualizar Estado + Reportes + Completion
 
-Presentar al usuario:
+1. Actualizar el `Estado` de cada caso ejecutado en el `test-cases.csv` (`Implemented`/`Passed`/`Failed`)
+   y, si aplica, en el `test-design.yml`. Reglas de escape CSV de Fase 3 (todo entre comillas, `"`→`""`).
+2. Generar `{run_folder}/implementation-report.md` (cobertura por feature, tests implementados, out-of-scope).
+3. Dejar los reportes en la **ruta predecible para el RCA**:
+   ```
+   {implementation_artifacts}/quality-process/playwright/e2e-run-YYYY-MM-DD-HHmmss/
+     ├── architecture-brief.md
+     ├── specs/  ·  proposed/  ·  tests/  ·  captured-locators/
+     ├── implementation-report.md
+     ├── allure-results/  ·  monocart-report/  ·  test-results/   ← insumos del RCA (Fase 7)
+   ```
 
+**Frontmatter del reporte:**
+```yaml
+---
+workflow: quality-process
+phase: playwright-e2e
+version: 2.0.0
+agent: agente-ejecutor-e2e
+generated_date: [ISO 8601]
+project_name: {project_name}
+source: [test-design.yml | test-cases.csv]
+run_folder: [ruta relativa]
+---
 ```
-✅ FASE 5 — IMPLEMENTACIÓN PLAYWRIGHT COMPLETADA
 
-📊 Resumen:
-  • Tests Playwright implementados:    [N]
-  • Tests ya existentes (sin cambio):  [N]
-  • Tests fuera de scope — Vitest:     [N]
-  • Tests fuera de scope — .NET:       [N]
+Presentar al usuario:
+```
+✅ FASE 6 — IMPLEMENTACIÓN + EJECUCIÓN E2E COMPLETADA
 
-📝 Archivos modificados:
-  {por cada spec file modificado:}
-  • {ruta relativa} → +[N] tests
+📁 Corrida: {run_folder}
 
-📄 CSV actualizado:
-  • {ruta relativa}/test-cases.csv → [N] estados: "Implemented"
+📊 Resumen:
+  • Tests E2E generados:        [N]
+  • Promovidos a tests/:        [N]
+  • Ejecutados ([A: aquí | B: CI]): [N]   → Pass [N] / Fail [N]
+  • Fuera de scope (Vitest/.NET): [N]
 
-📁 Reporte:
-  • {output_folder}/implementation-artifacts/quality-process/playwright/playwright-impl-YYYY-MM-DD-HHmmss/implementation-report.md
+📄 Reportes (insumo del RCA):
+  • allure-results/ · monocart-report/ · test-results/
 
-🔍 Próximos pasos recomendados:
-  1. Ejecutar los tests: npx playwright test --reporter=html
-  2. Verificar que los [N] tests nuevos pasan en los 3 browsers (Chromium, Firefox, WebKit)
-  3. Implementar los [N] tests Vitest en frontend/src/**/__tests__/
-  4. Implementar los [N] tests .NET en el proyecto de tests de integración BE
+🔄 Sync AgileTest: [Execution actualizada | omitido — sin credenciales]
 ```
 
-**⚠️ El workflow termina aquí. El equipo debe ejecutar los tests y validar que pasan antes de marcar los TCs como "Passed" en el CSV.**
+**⚠️ El workflow termina aquí.** Si hubo fallos, la **Fase 7 (RCA)** analiza los reportes de
+`{run_folder}` para el análisis de causa raíz.