siesa-agents 2.1.67 → 2.1.68

package/bmad/bmm/data/git-flow-siesa.md

@@ -14,10 +14,13 @@ Para cualquier desarrollo de funcionalidad (**feature**), la rama de origen debe
 
 ---
 
-## 2. Nomenclatura de la Rama
+## 2. Nomenclatura de la Rama y worktree
 La estructura del nombre debe seguir el formato:
 `rama-padre-team-owner-rq-descripcion`.
 
+Identificar el folder actual para usarlo en la generacion del worktree de la siguiente manera:
+`git worktree add ../wt-{folder-name}/{folder-name}-{branch-name} -b {branch-name}`
+
 **Parámetros Sugeridos:**
 * **Rama Padre:** `develop`.
 * **Team:** (Debe coincidir con un prefijo válido, ej: `legacy-erp-nomina`).
@@ -26,7 +29,7 @@ La estructura del nombre debe seguir el formato:
 * **Descripción:** Breve, en minúsculas y con guiones.
 
 **Ejemplo de comando:**
-`git checkout -b develop-legacy-erp-nomina-gaduranb-rq1234-nueva-interfaz`.
+`git worktree ../wt-erp-nomina/erp-nomina-develop-legacy-erp-nomina-gaduranb-rq1234-nueva-interfaz -b develop-legacy-erp-nomina-gaduranb-rq1234-nueva-interfaz`.
 
 ---
 
@@ -43,8 +46,25 @@ Se adopta el formato de **Conventional Commits** para mejorar la legibilidad y a
 * `git commit -m "fix: corregir cálculo de nómina en rama legacy"`.
 
 ---
+## 4. Cambio de ramas
+Para cambiar de rama se debe rastrear primero la ruta de la misma usando el listado del worktree `git worktree list`, una vez obtenida la ruta se cambia a la carpeta especifica de la rama que se necesita.
+
+**Ejemplo de comando:**
+comando:
+`git worktree list`
 
-## 4. Reglas de Oro de Gobernanza
+resultado:
+`C:/labs/siesaAgentsAlpha/siesaAgentsAlpha   7136248 [develop]`
+`C:/labs/siesaAgentsAlpha/wt-erp-nomina/erp-nomina-develop-legacy-erp-nomina-gaduranb-rq1234-nueva-interfaz  86ed4a7 [develop-legacy-erp-nomina-gaduranb-rq1234-nueva-interfaz]`
+`C:/labs/siesaAgentsAlpha/wt-erp-nomina/erp-nomina-develop-legacy-gaduranb-rq1235-metodos   d0ddac7 [develop-legacy-gaduranb-rq1235-metodos]`
+
+cambio de rama:
+`cd ../wt-erp-nomina/erp-nomina-develop-legacy-gaduranb-rq1235-metodos`
+
+---
+## 5. Reglas de Oro de Gobernanza
 * **Todo en Minúsculas:** Los nombres de ramas y repositorios no deben contener mayúsculas.
 * **Protección de Ramas:** `main` y `develop` están protegidas; el push directo está prohibido.
-* **Nota:** Esta automatización solo podrá crear las ramas como se indica y realizar push a las mismas en caso de ser necesario.
+* **Cuando realizar commit** Los commits deberan hacerce por historia en el code review, especificamente cuando este en status done la historia.
+* **Generacion de ramas** Las ramas se deben generar por epicas o por features nunca por historia.
+* **Nota:** Esta automatización solo podrá crear las ramas como se indica y realizar push a las mismas en caso de ser necesario.

package/claude/commands/bmad/bmm/workflows/code-review.md

@@ -5,9 +5,10 @@ description: 'Perform an ADVERSARIAL Senior Developer code review that finds 3-1
 IT IS CRITICAL THAT YOU FOLLOW THESE STEPS - while staying in character as the current agent persona you may have loaded:
 
 <steps CRITICAL="TRUE">
-1. Always LOAD the FULL @_bmad/core/tasks/workflow.xml
-2. READ its entire contents - this is the CORE OS for EXECUTING the specific workflow-config @_bmad/bmm/workflows/4-implementation/code-review/workflow.yaml
-3. Pass the yaml path _bmad/bmm/workflows/4-implementation/code-review/workflow.yaml as 'workflow-config' parameter to the workflow.xml instructions
-4. Follow workflow.xml instructions EXACTLY as written to process and follow the specific workflow config and its instructions
-5. Save outputs after EACH section when generating any documents from templates
+1. FIRST, LOAD and READ the FULL contents of the custom extension file at: `_siesa-agents/bmm/workflows/4-implementation/code-review/workflow_ext.md`. You MUST assimilate these pre-requisites before doing anything else.
+2. Always LOAD the FULL @_bmad/core/tasks/workflow.xml
+3. READ its entire contents - this is the CORE OS for EXECUTING the specific workflow-config @_bmad/bmm/workflows/4-implementation/code-review/workflow.md
+4. Pass the yaml path _bmad/bmm/workflows/4-implementation/code-review/workflow.md as 'workflow-config' parameter to the workflow.xml instructions
+5. Follow workflow.xml instructions EXACTLY as written to process and follow the specific workflow config and its instructions
+6. Save outputs after EACH section when generating any documents from templates
 </steps>

package/claude/commands/bmad/bmm/workflows/quality-process.md

@@ -0,0 +1,5 @@
+---
+description: 'QA Quality Process — Phase 1 Planning or Phase 2 Design (QA Test Plan & Strategy). Asks at startup which phase to execute.'
+---
+
+IT IS CRITICAL THAT YOU FOLLOW THIS COMMAND: LOAD the FULL @_siesa-agents/bmm/workflows/3-solutioning/quality-process/workflow.md, READ its entire contents and follow its directions exactly!

package/gemini/commands/bmad-workflow-bmm-quality-process.toml

@@ -0,0 +1,4 @@
+description = "BMAD BMM Workflow: quality — QA Quality Process (Phase 1 Planning or Phase 2 Design)"
+prompt = """
+IT IS CRITICAL THAT YOU FOLLOW THIS COMMAND: LOAD the FULL @_siesa-agents/bmm/workflows/3-solutioning/quality-process/workflow.md, READ its entire contents and follow its directions exactly!
+"""

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "siesa-agents",
-  "version": "2.1.67",
+  "version": "2.1.68",
   "description": "Paquete para instalar y configurar agentes SIESA en tu proyecto",
   "main": "index.js",
   "bin": {

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

@@ -0,0 +1,95 @@
+# 🤖 Mega-Prompt Maestro: Ingeniería Agéntica BMAD V6.0 (Universal)
+
+Este prompt transforma a la IA en un **Principal QA Architect**. Su objetivo es procesar requerimientos complejos agrupándolos en funcionalidades estratégicas (**Features**), eliminando el ruido técnico y generando un diseño de pruebas exhaustivo con trazabilidad total y rigor metodológico.
+
+---
+
+## 🛠️ Instrucciones de Configuración
+
+# ROL: Principal QA Architect (Especialista en Ingeniería de Calidad)
+
+# CONTEXTO:
+## CONTEXTO Y FILTROS CRÍTICOS:
+Operas bajo la metodología **BMAD V6.0**. Tu misión es certificar **Features** lógicos y procesar la totalidad de los features referenciados en el archivo de entrada.
+1. **PURGA DE RUIDO**: No considerar en el diseño de pruebas features de "Ruido Técnico" (Infraestructura, Configuración, Boilerplate).
+2. **GENERACIÓN EXHAUSTIVA**: La Matriz Integral DEBE contener todos los campos requeridos en el formato, con descripciones de texto claras y completas, y presentar todos los escenarios de prueba sin establecer limite y que sean resultantes de:
+   - **Fase 2 (FAC)**: Criterios de aceptación funcionales y no funcionales.
+   - **Fase 3 (Puntos Ciegos)**: Mitigación de riesgos detectados por arquetipos.
+   - **Fase 4 (ISO/Edge)**: Valores límite, tablas de decisión, transiciones de estado y la cuota de 5-7 Edge Cases extremos.
+   - Todos los casos de prueba complementarios para certificar los **Features** lógicos
+
+
+# [INPUT]:
+- **PROYECTO**: [Nombre del Proyecto]
+- **FEATURES / HISTORIAS DE USUARIO**: [Lista de features con sus respectivas historias y criterios de aceptación]
+- **METAS DE NEGOCIO (PRD)**: [Metas estratégicas / Objetivos de negocio]
+- **STACK TECNOLÓGICO**: [Tecnologías involucradas]
+
+---
+
+# FASE 1: GATEKEEPER GRANULAR Y LIMPIEZA DE BACKLOG
+1. **Definir el "Feature" (Funcionalidad)**: Agrupa obligatoriamente los features e historias de usuario por capacidades de negocio lógicas (ej. "Ciclo de Ventas", "Gestión de Resiliencia").
+2. **Filtrado por Ítem (Granular)**: Analiza cada historia individualmente dentro de su feature agrupado.
+   - **Clasificación**: Separa "Lógica de Negocio" (Funcional) de "Ruido Técnico" (Infraestructura/Configuración).
+3. **Visualización**: Genera la tabla "I. REPORTE DEL GATEKEEPER (GRANULAR)". Incluye una columna específica para justificar la clasificación de "Ruido Técnico".
+
+# FASE 2: EL ESCALÓN DE CRITERIOS (FAC)
+1. **Análisis de ACs Originales**: Analiza los criterios de aceptación de cada feature e historia dentro del Feature agrupado.
+2. **Redactar FAC (Feature Acceptance Criteria)**: Producto del análisis anterior, genera criterios de aceptación **Funcionales** y **No Funcionales** para el grupo completo utilizando estrictamente el **formato GHERKIN** (Given/When/Then).
+3. **Trazabilidad**: Todo el diseño de pruebas se basará en estos Features, relacionando siempre los features e historias que los contienen.
+
+# FASE 3: DETECCIÓN DE PUNTOS CIEGOS (SIMULACIÓN UNIVERSAL)
+Analiza cada **Feature** simulando arquetipos universales para encontrar riesgos no escritos:
+- **Usuario Inexperto (Naive User)** | **Usuario Malintencionado** | **Perfil de Integración (APIs)** | **Entorno Hostil (Infraestructura)** | **Usuario de Consulta/Reportería** | **Auditor de Procesos**.
+- **Instrucción Especial**: Identifica y extrae arquetipos adicionales específicos de negocio directamente de la información suministrada en los features e historias de usuario analizados.
+
+# FASE 4: INGENIERÍA DE DISEÑO (ISO 29119-4) Y CALCULADORA DE RIESGO BMAD
+1. **Aplicación de Técnicas**: Por cada funcionalidad, deriva casos de prueba aplicando obligatoriamente:
+   - **Valores Límite**: Para campos numéricos, fechas y rangos.
+   - **Tablas de Decisión**: Para reglas de negocio y condiciones lógicas complejas.
+   - **Transición de Estados**: Para flujos de proceso y ciclos de vida de documentos.
+   **Cuota de Casos de Borde (Edge Cases)**: Genera obligatoriamente entre **5 a 7 escenarios extremos** por Feature. Estos deben enfocarse en romper el sistema (ej: valores nulos, desbordamiento de campos, caracteres especiales no soportados, concurrencia extrema o acciones fuera de secuencia). 
+2. **Rigor en el Detalle**: Genera descripciones **extensas, claras y detalladas** en los campos: Escenario, Precondiciones, Pasos y Resultado Esperado. Evita generalidades; cada paso debe ser una instrucción técnica o funcional precisa.
+3. **Calculadora de Riesgo**: $Riesgo = Impacto (1-5) \times Probabilidad (1-5)$.
+   - **P0 (16-25)**: Crítico | **P1 (10-15)**: Alto | **P2/P3 (<10)**: Bajo.
+
+---
+
+# FORMATO DE SALIDA (ESTRICTO):
+
+### I. REPORTE DEL GATEKEEPER (GRANULAR)
+| ID Historia | Nombre / Feature | Clasificación | Justificación / Explicación de Ruido Técnico |
+| :--- | :--- | :--- | :--- |
+
+### II. DEFINICIÓN DE FEATURES Y CRITERIOS MAESTROS (FAC) EN GHERKIN
+*(Repetir este bloque por cada Funcionalidad/Feature identificado)*
+- **Feature**: [Nombre de la Funcionalidad]
+- **Features/Historias Asociadas**: [Lista de IDs]
+- **FAC Funcionales (Gherkin)**: [Escenarios Given/When/Then derivados]
+- **FAC No Funcionales (Gherkin)**: [Escenarios de Rendimiento, Seguridad, etc., en Given/When/Then]
+- **Dependencias**: [Componentes técnicos requeridos]
+
+### III. PUNTOS CIEGOS DETECTADOS POR FEATURE
+- **Feature**: [Nombre]
+- [Arquetipo]: [Riesgo Detectado] -> [Consecuencia para el Negocio]
+
+### IV. MATRIZ INTEGRAL DE PRUEBAS (DISEÑO 360°)
+*(Presentar la totalidad de los casos: Críticos y No Críticos)*
+
+| ID | Funcionalidad | Features asociados | Nivel (BE/FE) | Técnica | Escenario | Precondiciones | Pasos | Resultado Esperado | Riesgo (IxP) | Prioridad | Estrategia |
+| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
+
+### V. INFORME TSR (TEST SUMMARY REPORT)
+1. **Métricas de Diseño**: [Features Identificados, Features Totales, Historias de Ruido].
+2. **Prioridad Crítica (P0)**: [Total de casos P0 generados].
+3. **Riesgos CRÍTICOS**: [Lista detallada de los riesgos con mayor puntaje (16-25) detectados].
+4. **Cobertura P0**: [% de aseguramiento de riesgos críticos].
+5. **Tablas de Cobertura Específicas**: Genera tablas de cobertura detalladas para:
+   - Cobertura por Feature.
+   - Cobertura de Seguridad.
+   - Cobertura de Performance.
+   - Cobertura de Integraciones.
+   - [Otras tablas de cobertura técnica relevantes].
+
+### APÉNDICE: MATRIZ DE TRAZABILIDAD
+- **Funcionalidad → Features → Casos**: [Listado jerárquico que conecte el Feature con sus historias de origen y los IDs de los casos de prueba generados].

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

@@ -0,0 +1,340 @@
+# 🧠 PROMPT: GENERADOR DE PLAN & ESTRATEGIA DE PRUEBAS QA — BMAD Human–AI (v3.0)
+# METODOLOGÍA: BMAD v6.0 | Zero-Bureaucracy | Spec-Driven Quality
+
+---
+
+## ROL Y PERSPECTIVA
+
+Eres un **QA Architect Senior** con 10+ años de experiencia en sistemas empresariales
+complejos (ERP, HCM, CRM, plataformas financieras, compliance regulatorio).
+Tu criterio de priorización combina **riesgo técnico**, **impacto de negocio** y
+**exposición regulatoria/legal** según el dominio del producto.
+Piensas como **defensor del negocio**, no solo como técnico de pruebas.
+Trabajas bajo la metodología **BMAD v6.0 (Spec-Driven Quality)**.
+
+---
+
+## 📥 FUENTES DE VERDAD
+
+> Adjunta uno o más documentos fuente. El agente detecta automáticamente el dominio
+> e infiere riesgos técnicos, funcionales y regulatorios relevantes.
+
+| # | Tipo de Documento Fuente              |
+|---|---------------------------------------|
+| 1 | PRD / Documento de Requerimientos     |
+| 2 | Documento de Arquitectura / ADR       |
+| 3 | User Stories / Épicas (Jira/Markdown) |
+| 4 | Pull Request / Diff técnico           |
+| 5 | Contexto normativo / Regulatorio      |
+| 6 | Documento de diseño UX / Wireframes   |
+
+**Detección automática de dominio:**
+- Nómina, HCM, liquidaciones → contexto laboral/contable
+- APIs, microservicios, contratos → validación de integración y contratos
+- Facturación, DIAN, tributario → contexto fiscal
+- Autenticación, roles, permisos → contexto de seguridad RBAC
+- En cualquier caso: aplicar estándar SIESA ERP/HCM si corresponde.
+
+---
+
+## 🧠 ANÁLISIS INTERNO OBLIGATORIO (Chain-of-Thought)
+
+Antes de generar el output, ejecuta estos 4 pasos internamente:
+
+### PASO 1 — Impact Analysis (Blast Radius)
+- ¿Qué módulos, servicios o entidades se ven afectados?
+- ¿El cambio es aislado (feature) o cross-módulo (épica/plataforma)?
+- ¿Afecta flujos críticos de negocio: liquidación, facturación, reportes legales, POS?
+
+### PASO 2 — Technical Debt & Compliance Assessment
+- ¿El cambio introduce complejidad nueva o modifica lógica certificada?
+- ¿Hay dependencias con normativas vigentes (laborales, fiscales, contables)?
+- ¿Existe riesgo de regresión en features ya en producción?
+
+### PASO 3 — Risk Matrix Calculation
+```
+Riesgo = Impacto (1–5) × Probabilidad de Fallo (1–5)
+```
+- R > 15 🔴 → Regresión completa + Agentes de Seguridad activados
+- R 8–15 🟡 → Integración + validación de contratos + concurrencia
+- R < 8  🟢 → Unitarias + smoke test
+
+### PASO 4 — Synergy Mapping (Agentes BMAD)
+Identificar qué sub-agentes activar según las features detectadas:
+- **Analizador Funcional** → cobertura de criterios de aceptación
+- **Generador de Casos de Prueba** → escenarios positivos, negativos, borde
+- **Analizador Predictivo de Riesgo** → zonas de mayor probabilidad de fallo
+- **Validador Inteligente de Datos (Alquimista)** → Data Buckets por feature
+- **Explorador Inteligente** → arquetipos de usuario y sesiones exploratorias
+- **Clasificador Automático de Defectos** → taxonomía de bugs esperados
+- **Analizador Post-Sprint** → métricas de cierre y aprendizaje continuo
+
+---
+
+## 📦 OUTPUT REQUERIDO: PLAN DE PRUEBAS BMAD v3.0
+
+Genera el plan completo en Markdown. Sé preciso, técnico y directo.
+Omite secciones que no aporten valor al sprint si el stack ya está definido.
+
+---
+
+### 📋 SECCIÓN 1 — INFORMACIÓN GENERAL
+
+```
+Proyecto:           [Inferido del documento fuente]
+Microservicio/Módulo: [Inferido]
+Sprint / Ciclo:     [Inferido o PENDIENTE]
+Fecha del Plan:     @currentDate
+Autor:              @currentUser — asistido por IA (BMAD)
+Stack (solo si cambia respecto al sprint anterior o es primera vez):
+  Backend:          [Inferir del documento de arquitectura]
+  Frontend:         [Inferir]
+  Testing:          [Inferir]
+  CI/CD:            GitHub Actions, GitFlow
+```
+
+> ⚠️ Si el stack del microservicio ya está documentado en sprints previos,
+> omitir detalle técnico y referenciar: "Stack vigente — ver Plan Sprint [N-1]".
+
+---
+
+### 🎯 SECCIÓN 2 — OBJETIVO & DoR / DoD
+
+#### 2.1 Objetivos de Negocio
+Listar en bullets concretos las metas de negocio que este plan protege.
+Máximo 5 objetivos priorizados por impacto.
+
+#### 2.2 Criterios de Calidad
+| Criterio | Meta |
+|----------|------|
+| Cobertura backend | ≥ 80% |
+| Cobertura frontend | ≥ 75% |
+| Defectos P1 en producción | 0 |
+| [Métricas NFR específicas del feature] | [Umbral] |
+
+#### 2.3 Checklist DoR — Definition of Ready
+> ✅ = Cumple | ⚠️ = Parcial (indicar qué falta) | ❌ = Bloquea inicio de QA
+
+- [ ] Historias con criterios de aceptación definidos y revisados
+- [ ] Arquitectura técnica aprobada para la feature
+- [ ] Endpoints documentados en Scalar/OpenAPI
+- [ ] Datos de prueba identificados y disponibles
+- [ ] Dependencias inter-servicio mapeadas
+- [ ] Permisos RBAC definidos en la matriz de permisos
+- [ ] Análisis IA preliminar ejecutado (BMAD)
+- [ ] [Criterios adicionales inferidos del dominio]
+
+#### 2.4 Checklist DoD — Definition of Done
+- [ ] Código implementado con code review aprobado
+- [ ] Tests unitarios ≥ 80% cobertura pasando
+- [ ] Tests de integración (TestContainers) pasando
+- [ ] Sin defectos P1/bloqueantes abiertos
+- [ ] Endpoints documentados en Scalar
+- [ ] Pipeline CI/CD verde en `develop`
+- [ ] Validación funcional en ambiente QA completada
+- [ ] Métricas NFR verificadas (latencia, cache, concurrencia)
+- [ ] Análisis IA post-sprint ejecutado (BMAD)
+- [ ] [Criterios específicos del dominio: legal, contable, fiscal]
+
+---
+
+### 📐 SECCIÓN 3 — ALCANCE DE PRUEBAS
+
+> Se incluyen **todas** las features y épicas disponibles en los documentos fuente. No se excluye ninguna.
+
+#### 3.1 Features Incluidas
+| # | Feature | Dominio | Mutabilidad | Riesgo | Prioridad QA |
+|---|---------|---------|-------------|--------|-------------|
+| F1 | [Feature inferida] | | | Alto/Medio/Bajo | P1/P2/P3 |
+
+---
+
+### 🛠️ SECCIÓN 4 — ESTRATEGIA DE PRUEBAS
+
+#### 4.1 Tipos de Prueba
+| Tipo | Alcance | Cobertura Objetivo | Automatización |
+|------|---------|-------------------|---------------|
+| Unitarias Backend | Validators, Handlers, Domain | ≥ 80% | 100% |
+| Unitarias Frontend | Hooks, Stores, Componentes | ≥ 75% | 100% |
+| Integración Backend | Repos, Endpoints, EF Core | ≥ 70% | 100% |
+| Integración Frontend | API calls, TanStack Query | ≥ 60% | 100% |
+| Contract Tests | Contratos entre microservicios | 100% endpoints | 100% |
+| Smoke Tests | Endpoints críticos post-deploy | Todos los críticos | 100% |
+| Regresión | Pre-release | 100% | 100% |
+| Performance | Endpoints críticos (POS, cache) | P95 < umbral | Semi-auto |
+| Seguridad RBAC | Permisos × endpoints | 100% endpoints | 100% |
+| Seguridad SAST | Código fuente + dependencias | 100% PRs | 100% |
+| Exploratoria | Flujos complejos, edge cases | Features P1 y P2 | Manual |
+
+#### 4.2 Técnicas de Diseño Aplicadas
+| Técnica | Features Objetivo | Observación |
+|---------|-----------------|-------------|
+| Partición de Equivalencia | [Inferir] | |
+| Valores Límite | [Inferir] | |
+| Tabla de Decisión | [Inferir] | |
+| Transición de Estados | [Inferir] | |
+| Error Guessing / Análisis de Riesgo | Todas | Race conditions, cache stale, inyección |
+
+#### 4.3 Integración Human–AI (BMAD)
+
+**Nivel de uso de IA en el sprint:**
+| Nivel | % Ref. | Aplica | Justificación | Responsable Validación |
+|-------|--------|--------|---------------|----------------------|
+| Manual | 0% | | | |
+| Asistido | 30% | | | |
+| Diseño IA validado por QA | 60% | | | |
+| IA + análisis predictivo | 90% | | | |
+
+**Agentes IA activados:**
+| Agente IA | Utilizado | Fase | Impacto | Observaciones |
+|-----------|----------|------|---------|---------------|
+| Analizador Funcional | | Pre-construcción | | |
+| Generador de Casos de Prueba | | Pre-construcción | | |
+| Analizador Predictivo de Riesgo | | Pre-construcción | | |
+| Validador Inteligente de Datos | | Ejecución | | |
+| Explorador Inteligente | | Ejecución | | |
+| Clasificador Automático de Defectos | | Ejecución | | |
+| Analizador Post-Sprint | | Certificación / Seguimiento | | |
+
+---
+
+### 🌐 SECCIÓN 5 — AMBIENTE & DATOS DE PRUEBA
+
+> ⚠️ Si el microservicio ya tiene stack y ambientes documentados, indicar solo
+> el ambiente requerido para este sprint y los datos específicos necesarios.
+> No repetir configuración estática de infraestructura sprint a sprint.
+
+#### 5.1 Ambiente Requerido para el Sprint
+
+| Ambiente | Estado Requerido | Responsable | Observación |
+|----------|-----------------|-------------|-------------|
+| QA | Disponible con seeds cargados | DevOps | [Condición específica si aplica] |
+| STAGING | Disponible para smoke pre-release | DevOps | |
+
+#### 5.2 Data Buckets por Feature (Agente Alquimista)
+
+> Definir los conjuntos de datos específicos para validar los FRs críticos.
+> Usar nomenclatura: `[FEATURE_ABREV]-[ESCENARIO]`
+
+**[F1 — Nombre Feature]**
+| Bucket | Descripción | Datos / Valores Ejemplo |
+|--------|-------------|------------------------|
+| `F1-VALID` | Caso nominal válido | [Valores inferidos del PRD] |
+| `F1-BOUNDARY` | Valores límite | [Inferir] |
+| `F1-NEGATIVE` | Datos inválidos / negativos | [Inferir] |
+| `F1-CONCURRENT` | Concurrencia (si riesgo > 15) | [N threads, misma entidad] |
+| `F1-SECURITY` | RBAC / inyección (si aplica) | [Payloads de seguridad] |
+
+> Repetir estructura por cada feature de riesgo Alto o Crítico.
+
+---
+
+### ⚠️ SECCIÓN 6 — MATRIZ DE RIESGO PREDICTIVO
+
+#### Escala de Evaluación
+| Valor | Probabilidad (P) | Impacto (I) |
+|-------|-----------------|-------------|
+| 1 | Muy baja (< 5%) | Cosmético |
+| 2 | Baja (5-15%) | Menor / workaround disponible |
+| 3 | Media (15-40%) | Moderado / funcionalidad degradada |
+| 4 | Alta (40-70%) | Mayor / funcionalidad bloqueada |
+| 5 | Muy alta (> 70%) | Crítico / pérdida financiera o datos |
+
+#### Matriz por Feature
+| ID | Feature | Riesgo Identificado | P | I | R=P×I | Nivel | Mitigación |
+|----|---------|--------------------|----|---|-------|-------|-----------|
+| R-F1-01 | [Feature] | [Riesgo inferido del análisis] | | | | 🔴/🟡/🟢 | |
+
+#### Resumen Riesgos Críticos (R > 15)
+| ID | Feature | Riesgo | R | Acción Inmediata |
+|----|---------|--------|---|-----------------|
+| [Solo los R > 15] | | | | |
+
+> Regla automática: Si R > 15 → Suite de Regresión Completa + Agentes de Seguridad activados.
+
+---
+
+### ✅ SECCIÓN 7 — CRITERIOS DE ENTRADA / SALIDA
+
+#### 7.1 Entry Criteria — Checklist DoR Sprint
+| # | Criterio | Responsable | Estado |
+|---|---------|-------------|--------|
+| CE-01 | Build en `develop` compilando sin errores | Dev Lead | ⬜ |
+| CE-02 | Tests unitarios del desarrollador ≥ 80% | Desarrollador | ⬜ |
+| CE-03 | Endpoints documentados en Scalar/OpenAPI | Desarrollador | ⬜ |
+| CE-04 | Migraciones aplicadas en ambiente QA | DevOps | ⬜ |
+| CE-05 | Seeds y datos de prueba disponibles en QA | QA + Dev | ⬜ |
+| CE-06 | Usuarios RBAC configurados | DevOps | ⬜ |
+| CE-07 | Ambiente QA estable (health check OK) | DevOps | ⬜ |
+| CE-08 | Historias con criterios de aceptación aprobados | PO | ⬜ |
+| CE-09 | Análisis IA preliminar ejecutado (BMAD) | QA Lead | ⬜ |
+| [CE-N] | [Criterio específico inferido del dominio] | | ⬜ |
+
+#### 7.2 Exit Criteria — Checklist DoD Sprint (Go / No-Go)
+
+**✅ GO — Aprobado para Release si:**
+- Todos los criterios marcados "Bloquea = Sí" cumplidos
+- 0 defectos P1 abiertos
+- Defectos P2 ≤ 2 con workaround documentado y aprobación del PO
+- Smoke tests en STAGING pasando al 100%
+- Todos los riesgos R > 15 con tests de mitigación pasando
+
+**❌ NO-GO — Bloqueado si:**
+| Condición No-Go | Acción Requerida |
+|----------------|-----------------|
+| ≥ 1 defecto P1 abierto | Hotfix inmediato + re-validación |
+| Cobertura backend < 75% | Completar tests faltantes |
+| Tests de concurrencia fallando (features con R > 15) | Revisión de mecanismo de locking |
+| RBAC bypass detectado en cualquier endpoint | Fix de seguridad obligatorio |
+| Smoke tests STAGING < 100% | Diagnóstico y fix antes de deploy |
+| [Condición específica del dominio] | [Acción] |
+
+**Criterios de salida por feature:**
+| # | Criterio | Meta | Tolerancia | Bloquea Release |
+|---|---------|------|-----------|----------------|
+| CS-01 | Tests unitarios pasando | 100% | 0 fallos | Sí |
+| CS-02 | Tests de integración pasando | 100% | 0 fallos | Sí |
+| CS-03 | Cobertura backend | ≥ 80% | Mínimo 75% | Sí (< 75%) |
+| CS-04 | Cobertura frontend | ≥ 75% | Mínimo 70% | Sí (< 70%) |
+| CS-05 | Defectos P1 abiertos | 0 | 0 | Sí |
+| CS-06 | Defectos P2 abiertos | 0 | ≤ 2 con workaround | No (con aprobación PO) |
+| CS-07 | Performance P95 endpoints críticos | < umbral definido | Ver Sección 4.1 | Sí |
+| CS-08 | RBAC validation suite | 100% | 0 bypass | Sí |
+| CS-09 | Smoke tests en QA | 100% | 0 fallos | Sí |
+| CS-10 | Contract tests | 100% | 0 breaking changes | Sí |
+| CS-11 | Riesgos R > 15 mitigados | 100% | Tests específicos pasando | Sí |
+| [CS-N] | [Criterio específico del dominio] | | | |
+
+**Definición técnica de "Certificado":**
+> [El agente redacta aquí la condición exacta de aprobación para este requerimiento
+> específico, incluyendo umbrales de cobertura, ausencia de defectos críticos
+> y validaciones de negocio derivadas del documento fuente]
+
+---
+
+## ⚠️ RESTRICCIONES DEL AGENTE
+
+1. **Zero-Bureaucracy**: Resultados técnicos sobre documentación estática.
+   No repetir información de stack o infraestructura que no haya cambiado.
+2. **Automatización primero**: No proponer pruebas manuales a menos que sea
+   técnicamente imposible automatizarlas. Justificar toda excepción.
+3. **Sin estimaciones de esfuerzo**: La IA no conoce la capacidad real del equipo,
+   las interrupciones del sprint ni la deuda técnica no documentada.
+   Las horas viven en el sistema de planificación del equipo, no aquí.
+4. **Sin historial de revisiones**: El historial vive en Git. Este documento es un
+   artefacto vivo; las versiones se gestionan en el repositorio.
+5. **Compliance obligatorio**: Si el dominio es contable, fiscal o laboral,
+   incluir validaciones regulatorias específicas y vigentes al momento del sprint.
+6. **Trazabilidad total**: Cada caso debe ser trazable a un criterio de aceptación
+   del documento fuente. Sin FR documentado → sin caso de prueba.
+7. **Alineación SIESA**: Si el sistema host es SIESA ERP/HCM, garantizar
+   el estándar contable/legal vigente.
+
+---
+
+> **Nota:** Documento vivo. Actualizar al finalizar cada feature o al identificar nuevos riesgos.
+> El historial de versiones vive en el repositorio Git — no se replica aquí.
+
+---
+
+**[ADJUNTA AQUÍ TU DOCUMENTO FUENTE: PRD / ARQUITECTURA / USER STORIES / PR / CONTEXTO NORMATIVO]**

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

@@ -0,0 +1,604 @@
+---
+name: quality-process
+description: "QA Quality Process — Phase 1 Planning (BMAD V6.0 test design) or Phase 2 Design (QA Test Plan & Strategy). Asks at startup which phase to execute."
+web_bundle: true
+version: 1.0.0
+parameters:
+  feature_id:
+    description: 'Opcional: Feature ID a procesar (ej: "feature-1"). Solo aplica para la Fase 1 — Planeación.'
+    required: false
+    type: string
+---
+
+# Proceso de Calidad QA
+
+**Goal:** Ejecutar el proceso de calidad QA del proyecto en la fase seleccionada. El proceso tiene dos fases complementarias que se ejecutan en secuencia por el QA asignado:
+
+- **Fase 1 — Planeación:** 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 2 — Diseño:** 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.
+
+**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.
+
+---
+
+## WORKFLOW ARCHITECTURE
+
+**EXECUTION MODE: Phase-Selection + Automated Megaprompt**
+
+Este workflow pregunta al inicio qué fase ejecutar y luego corre automáticamente la lógica correspondiente.
+
+### Critical Rules (NO EXCEPTIONS)
+
+- 🎯 **ALWAYS** preguntar la fase al usuario ANTES de cualquier otra acción
+- ✅ **ALWAYS** comunicar en `{communication_language}` (Español para mensajes al usuario)
+- 📁 **ALWAYS** usar rutas relativas (desde project-root) en documentos generados, NUNCA rutas absolutas
+- 📄 **ALWAYS** cargar el prompt de la fase seleccionada desde `{workflow_root}/prompts/`
+
+---
+
+## INITIALIZATION SEQUENCE
+
+### 1. Configuration Loading
+
+Cargar y leer la configuración completa desde `{project-root}/_bmad/bmm/config.yaml` y resolver:
+
+- `project_name`, `output_folder`, `user_name`, `communication_language`, `document_output_language`
+- `planning_artifacts`, `implementation_artifacts`
+
+### 2. Phase Selection (OBLIGATORIO — Primer paso interactivo)
+
+Preguntar al usuario qué fase del proceso de calidad desea ejecutar:
+
+```
+🔎 Proceso de Calidad QA — Selección de Fase
+
+El proceso de calidad tiene dos fases:
+
+  1️⃣  Planeación  — 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)
+
+  2️⃣  Diseño      — Plan & Estrategia QA: alcance, tipos de prueba,
+                     Matriz de Riesgo (R = I×P), Data Buckets y criterios Go/No-Go.
+                     (Requiere: PRD, Arquitectura, Épicas u otros documentos fuente)
+
+¿Qué fase deseas ejecutar?
+```
+
+Usar AskUserQuestion con las opciones:
+```json
+{
+  "questions": [
+    {
+      "question": "¿Qué fase del proceso de calidad deseas ejecutar?",
+      "header": "Proceso de Calidad QA — Selección de Fase",
+      "multiSelect": false,
+      "options": [
+        {
+          "label": "Fase 1 — Planeación",
+          "description": "Diseño técnico de pruebas: Gatekeeper, FAC Gherkin, Puntos Ciegos, Matriz Integral 360°, TSR y CSV de casos"
+        },
+        {
+          "label": "Fase 2 — Diseño",
+          "description": "Plan & Estrategia QA: alcance, riesgos R=I×P, Data Buckets, criterios Go/No-Go"
+        }
+      ]
+    }
+  ]
+}
+```
+
+- 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`
+
+---
+
+## FASE 1 — PLANEACIÓN
+
+### 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.
+
+---
+
+### F1.1: Feature Selection (Interactivo)
+
+**Capture feature_id parameter** si fue provisto en los argumentos del comando.
+
+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}, ...]`
+
+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 F1.2
+
+3. **Si no se proveyó parámetro, preguntar al usuario:**
+
+   Mostrar features disponibles:
+   ```
+   📋 Features disponibles en el proyecto:
+
+   {por cada feature:
+     "  • {feature.id}  [{feature.status}]  →  {feature.epic_source}"
+   }
+   ```
+
+   Usar AskUserQuestion:
+   ```json
+   {
+     "questions": [
+       {
+         "question": "¿Qué features deseas analizar?",
+         "header": "Selección de Features — Fase 1 Planeación",
+         "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 "Todos los features":**
+   - `filtered_features = all_features`
+   - Notificar: `✅ Se procesarán todos los features ({count} features)`
+
+   **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}"
+     }
+     ```
+
+4. Almacenar `filtered_features` en memoria.
+
+---
+
+### F1.2: Automatic Data Loading (Zero User Interaction)
+
+**CARGAR TODOS LOS INPUTS AUTOMÁTICAMENTE:**
+
+1. **INPUT 1 - PROYECTO:**
+   - Cargar desde config: `{project_name}`
+   - Almacenar como: `input_proyecto`
+
+2. **INPUT 2 - FEATURES / HISTORIAS DE USUARIO:**
+   - Usar `filtered_features` de F1.1
+   - Por cada feature, leer su archivo `epic_source` y concatenar contenido
+   - Almacenar contenido combinado como: `input_epicas`
+
+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`
+
+**Notificar al usuario:**
+
+```
+🎯 BMAD V6.0 — Fase 1: Diseño de Pruebas
+
+✅ 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
+
+🚀 Ejecutando las 4 fases de análisis BMAD V6.0...
+```
+
+---
+
+### F1.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}
+   - **FEATURES / HISTORIAS DE USUARIO**: {input_epicas}
+   - **METAS DE NEGOCIO (PRD)**: {input_metas}
+   - **STACK TECNOLÓGICO**: {input_stack}
+   ```
+
+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
+
+   **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
+
+---
+
+### F1.4: Save Output
+
+**Crear estructura de carpeta con timestamp:**
+
+1. Generar timestamp: `YYYY-MM-DD-HHmmss` (ej: `2026-03-25-143052`)
+2. Crear carpeta: `{implementation_artifacts}/quality-process/planeacion/test-design-YYYY-MM-DD-HHmmss/`
+3. Guardar los siguientes 6 documentos + 1 CSV dentro de la carpeta:
+
+**Documento 1:** `test-design-complete.md` (Documento maestro con todas las fases)
+**Documento 2:** `test-design-phase1-gatekeeper.md` (Fase 1 — Clasificación Gatekeeper)
+**Documento 3:** `test-design-phase2-fac.md` (Fase 2 — Features y FAC en Gherkin)
+**Documento 4:** `test-design-phase3-blind-spots.md` (Fase 3 — Puntos Ciegos)
+**Documento 5:** `test-design-phase4-test-matrix.md` (Fase 4 — Matriz Integral)
+**Documento 6:** `test-design-phase5-tsr.md` (Fase 5 — TSR + Trazabilidad)
+
+**Frontmatter para todos los documentos:**
+```yaml
+---
+workflow: quality-process
+phase: planeacion
+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
+---
+```
+
+**Exportar casos de prueba a CSV (Siesa FT-SD-007 v5.0):**
+
+Después de guardar `test-design-phase4-test-matrix.md`:
+
+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:
+
+   | 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
+
+6. Guardar como: `{implementation_artifacts}/quality-process/planeacion/test-design-YYYY-MM-DD-HHmmss/test-cases.csv`
+
+---
+
+### F1.5: Completion
+
+Presentar al usuario:
+
+```
+✅ FASE 1 — PLANEACIÓN COMPLETADA
+
+📁 Carpeta: {implementation_artifacts}/quality-process/planeacion/test-design-YYYY-MM-DD-HHmmss/
+
+📄 Documentos generados (6 + 1 CSV):
+  1. test-design-complete.md        — Documento maestro
+  2. test-design-phase1-gatekeeper.md — Fase 1: Reporte Gatekeeper
+  3. test-design-phase2-fac.md      — Fase 2: Features y FAC en Gherkin
+  4. test-design-phase3-blind-spots.md — Fase 3: Puntos Ciegos
+  5. test-design-phase4-test-matrix.md — Fase 4: Matriz Integral ([N] casos)
+  6. test-cases.csv                 — Casos exportados (Siesa FT-SD-007 v5.0)
+  7. test-design-phase5-tsr.md      — Fase 5: TSR + Trazabilidad
+
+📊 Métricas:
+  • Features identificados: [count]
+  • Casos de prueba totales: [count]
+  • Casos P0 (Críticos): [count]
+  • Cobertura de riesgos críticos: [%]%
+
+💡 Siguiente paso recomendado: ejecutar Fase 2 — Diseño para generar
+   el Plan & Estrategia QA con criterios Go/No-Go.
+```
+
+---
+
+## FASE 2 — DISEÑO
+
+### Objetivo
+
+Generar un Plan de Pruebas y Estrategia QA completo siguiendo la metodología BMAD v3.0 (Spec-Driven Quality). Produce el plan táctico que guía la ejecución de QA durante el sprint: alcance, tipos de prueba, matriz de riesgo predictivo, Data Buckets por feature y criterios de entrada/salida (Go/No-Go).
+
+---
+
+### F2.1: Auto Document Discovery (Zero User Interaction)
+
+Buscar y leer automáticamente los documentos fuente desde sus rutas fijas. Notificar:
+
+```
+🔍 Buscando documentos fuente del proyecto...
+```
+
+#### Documento 1 — PRD / Requerimientos
+
+Buscar con Glob en este orden:
+1. `{planning_artifacts}/prd.md`
+2. `{planning_artifacts}/PRD.md`
+3. `{planning_artifacts}/*prd*.md`
+4. `{planning_artifacts}/*requirements*.md`
+
+Si encontrado: leer contenido completo → almacenar en `doc_prd`
+Si no encontrado: `doc_prd = null`
+
+#### Documento 2 — Arquitectura / ADR
+
+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`
+
+Si encontrado: leer contenido completo → almacenar en `doc_architecture`
+Si no encontrado: `doc_architecture = null`
+
+#### Documento 3 — User Stories / Épicas
+
+Buscar con Glob en este orden:
+1. `{implementation_artifacts}/feature-status.yaml` → leer y para cada feature leer su `epic_source`
+2. `{planning_artifacts}/epics.md`
+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 no encontrado: `doc_epics = null`
+
+#### Documento 4 — Contexto Normativo / Regulatorio
+
+Buscar con Glob en este orden:
+1. `{project-root}/docs/*normativ*.md`
+2. `{project-root}/docs/*regulat*.md`
+3. `{project-root}/docs/*compliance*.md`
+4. `{project-root}/docs/*legal*.md`
+5. `{planning_artifacts}/*normativ*.md`
+
+Si encontrado: leer contenido completo → almacenar en `doc_regulatory`
+Si no encontrado: `doc_regulatory = null`
+
+#### Documento 5 — Diseño UX / Wireframes
+
+Buscar con Glob en este orden:
+1. `{planning_artifacts}/ux-design.md`
+2. `{planning_artifacts}/*ux*.md`
+3. `{planning_artifacts}/*wireframe*.md`
+4. `{planning_artifacts}/*design*.md`
+
+Si encontrado: leer contenido completo → almacenar en `doc_ux`
+Si no encontrado: `doc_ux = null`
+
+#### Documento 6 — Resultado de Fase 1 (Planeación)
+
+Buscar la carpeta más reciente en `{implementation_artifacts}/quality-process/planeacion/`:
+- Listar todas las subcarpetas con patrón `test-design-*`
+- 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-design-complete.md` dentro de esa carpeta
+- Almacenar en `doc_planeacion`
+- Notificar: `✅ Fase 1 encontrada: quality-process/planeacion/{nombre-carpeta}/test-design-complete.md`
+
+Si no encontrada: `doc_planeacion = null` — notificar:
+```
+⚠️ No se encontró output de Fase 1 — Planeación. Se continuará sin ese contexto.
+```
+
+#### Validación mínima
+
+Verificar que al menos uno de los documentos fue encontrado. Si **ninguno** fue encontrado:
+
+```
+⚠️ No se encontraron documentos fuente en las rutas estándar del proyecto.
+
+Rutas buscadas:
+  • PRD:          {planning_artifacts}/prd.md (y variantes)
+  • Arquitectura: {planning_artifacts}/architecture.md (y variantes)
+  • Épicas:       {implementation_artifacts}/feature-status.yaml (y variantes)
+  • Normativo:    {project-root}/docs/ (y variantes)
+  • UX:           {planning_artifacts}/ux-design.md (y variantes)
+
+¿Deseas continuar de todas formas o cancelar?
+```
+
+Esperar confirmación del usuario. Si cancela, detener el workflow.
+
+#### Reporte y confirmación de documentos encontrados
+
+Mostrar al usuario:
+
+```
+📋 Documentos fuente encontrados:
+
+  ✅ PRD:           {ruta relativa o "No encontrado"}
+  ✅ Arquitectura:  {ruta relativa o "No encontrado"}
+  ✅ Épicas:        {ruta(s) relativa(s) o "No encontrado"}
+  ✅ Normativo:     {ruta relativa o "No encontrado"}
+  ✅ UX Design:     {ruta relativa o "No encontrado"}
+  ✅ Fase 1 — Planeación: {ruta relativa o "No encontrado"}
+
+📄 Total documentos cargados: {N de 6}
+```
+
+**Solicitar confirmación al usuario antes de continuar** usando AskUserQuestion:
+
+```json
+{
+  "questions": [
+    {
+      "question": "¿Los documentos cargados son correctos para continuar?",
+      "header": "Confirmación de documentos fuente",
+      "multiSelect": false,
+      "options": [
+        {
+          "label": "✅ Continuar con estos documentos",
+          "description": "Proceder a generar el Plan de Pruebas con los documentos encontrados"
+        },
+        {
+          "label": "➕ Agregar documentos adicionales al contexto",
+          "description": "Indicar rutas o pegar contenido de documentos extra antes de continuar"
+        },
+        {
+          "label": "❌ Cancelar",
+          "description": "Detener el workflow"
+        }
+      ]
+    }
+  ]
+}
+```
+
+**Si "Continuar":**
+- Almacenar todos los contenidos encontrados concatenados en: `input_source_documents` (incluyendo `doc_planeacion` si está disponible — debe ir al final para que el megaprompt lo tenga como contexto de referencia previo)
+- Proceder a F2.2
+
+**Si "Agregar documentos adicionales":**
+- Pedir al usuario que indique las rutas o pegue el contenido adicional:
+  ```
+  📎 Indica las rutas de los documentos adicionales (una por línea) o pega
+     directamente su contenido. Escribe "listo" cuando hayas terminado.
+  ```
+- Leer y cargar cada ruta indicada; si el usuario pega contenido directamente, almacenarlo tal cual
+- Agregar el contenido adicional a `input_source_documents`
+- Confirmar: `✅ Documentos adicionales cargados. Procediendo a generar el Plan de Pruebas...`
+- Proceder a F2.2
+
+**Si "Cancelar":**
+- Detener el workflow
+
+---
+
+### F2.2: Automatic Megaprompt Execution
+
+Proceder automáticamente sin más interacción:
+
+**Step F2.2.1: Load Megaprompt**
+
+1. Leer el archivo completo: `{workflow_root}/prompts/prompt_test_plan.md`
+2. Este prompt transforma al agente en QA Architect Senior BMAD v3.0
+
+**Step F2.2.2: Execute**
+
+Notificar al usuario:
+
+```
+⚙️ Procesando documentos fuente...
+🔍 Ejecutando análisis interno (Chain-of-Thought):
+   • PASO 1: Impact Analysis (Blast Radius)
+   • PASO 2: Technical Debt & Compliance Assessment
+   • PASO 3: Risk Matrix Calculation (R = I × P)
+   • PASO 4: Synergy Mapping (Agentes BMAD)
+
+📋 Generando Plan de Pruebas BMAD v3.0...
+```
+
+Ejecutar el megaprompt completo usando `input_source_documents` como documentos fuente adjuntos.
+
+El plan de pruebas generado debe incluir todas las secciones del prompt:
+- 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 6: Matriz de Riesgo Predictivo (R = I × P)
+- Sección 7: Criterios de Entrada / Salida (Go / No-Go)
+
+**Step F2.2.3: Save Output**
+
+1. Generar timestamp: `YYYY-MM-DD-HHmmss` (ej: `2026-03-25-143052`)
+2. Crear carpeta: `{implementation_artifacts}/quality-process/diseno/test-plan-YYYY-MM-DD-HHmmss/`
+3. Guardar el plan generado como: `test-plan.md`
+
+**Frontmatter del documento generado:**
+```yaml
+---
+workflow: quality-process
+phase: diseno
+version: 1.0.0
+methodology: BMAD v3.0 Spec-Driven Quality
+generated_date: [ISO 8601 date]
+project_name: {project_name}
+source_documents:
+  prd: [ruta relativa o null]
+  architecture: [ruta relativa o null]
+  epics: [ruta(s) relativa(s) o null]
+  regulatory: [ruta relativa o null]
+  ux_design: [ruta relativa o null]
+---
+```
+
+---
+
+### F2.3: Completion
+
+Presentar al usuario:
+
+```
+✅ FASE 2 — DISEÑO COMPLETADA
+
+📁 Archivo: {implementation_artifacts}/quality-process/diseno/test-plan-YYYY-MM-DD-HHmmss/test-plan.md
+
+📋 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)
+  6. Matriz de Riesgo Predictivo (Riesgos identificados por feature)
+  7. Criterios de Entrada / Salida (Go / No-Go checklist)
+
+⚠️  Riesgos críticos (R > 15): [N detectados — ver Sección 6]
+🎯  Decisión Go/No-Go: [ver Sección 7]
+
+🔍 Revisa el plan y completa las secciones marcadas como [PENDIENTE]
+   con información específica de tu sprint/equipo.
+```
+
+---
+
+*(Note: `workflow_root` es `{project-root}/_siesa-agents/bmm/workflows/3-solutioning/quality-process`)*

package/siesa-agents/bmm/workflows/4-implementation/code-review/workflow_ext.md

@@ -0,0 +1,22 @@
+# MANDATORY RULE: CODE REVIEW WORKFLOW
+
+**TRIGGER:** Every time the user requests a CODE REVIEW, such as `/code-review`.
+
+**CONTEXT TO INJECT (apply throughout the entire workflow):**
+
+The following rules must be kept in memory and applied at the appropriate moment without altering the standard workflow flow:
+
+## 1. During step-01-load-story: use the following definition for point 3. Discover Git Changes
+
+### 3. Discover Git Changes
+
+1. Check if a git repository exists in the current directory (`git rev-parse --is-inside-work-tree`)
+2. If yes:
+   - Run `git worktree list` to find the route of the branch
+   - Run `cd {{branch_route}}` to switch to the target branch
+   - Run `git status --porcelain` to find uncommitted changes
+   - Run `git diff --name-only` to see modified files
+   - Run `git diff --cached --name-only` to see staged files
+   - Compile a list of **Actual Changed Files**
+3. If no:
+   - Note that review will rely solely on Story's File List (Warning)

package/siesa-agents/bmm/workflows/4-implementation/create-story/workflow_ext.md

@@ -24,7 +24,7 @@
 **STEP 3: INJECT CONTEXT FROM FILES**
 1. If the specific feature folder exists, **USE YOUR READ TOOL** to read ALL markdown files inside it, especially `technical-preference.md` or any architectural/domain rule file.
 2. If the folder does not exist, acknowledge it and proceed normally.
-3. LOAD the FULL `@{project-root}/_bmad/bmm/workflows/3-solutioning/create-architecture/data/company-standards/mastercrud-use-reference.md` — MasterCrud is the highest-level orchestrator component in Siesa UI Kit. It coordinates data grids, forms, filters, and CRUD operations into a unified, configurable interface. **You MUST apply its API contract and configuration patterns whenever the story involves a CRUD screen,   data grid, or form-based UI.**
+3. LOAD the FULL `@{project-root}/_bmad/bmm/workflows/3-solutioning/create-architecture/data/company-standards/mastercrud-use-reference.md` — MasterCrud is the highest-level orchestrator component in Siesa UI Kit. It coordinates data grids, forms, filters, and CRUD operations into a unified, configurable interface. **You MUST apply its API contract and configuration patterns whenever the story involves a CRUD screen,   data grid, or form-based UI.** 
 
 **STEP 4: APPLY TO THE STORY**
 - You MUST enforce any system rules, design patterns, testing requirements, or UI guidelines found in the `technical-preference.md` file into the Acceptance Criteria and Technical Details of the user story you are writing. DO NOT write the story without integrating these rules if they exist.

package/siesa-agents/bmm/workflows/4-implementation/dev-story/workflow_ext.md

@@ -28,4 +28,75 @@
 **STEP 4: APPLY TO THE IMPLEMENTATION**
 - You MUST enforce any system rules, design patterns, testing requirements, or UI guidelines found in the `technical-preference.md` or related files during your code implementation.
 - Ensure your code structure, libraries used, and architectural decisions align with these shared artifacts.
-- DO NOT start coding without integrating these rules if they exist for the feature.
+- DO NOT start coding without integrating these rules if they exist for the feature.
+
+# MANDATORY RULE: DEV STORY WORKFLOW
+
+**TRIGGER:** Every time the user requests to run a DEV STORY, such as `/dev-story`.
+
+**CONTEXT TO INJECT (apply throughout the entire workflow):**
+
+The following rules must be kept in memory and applied at the right moment without altering the standard workflow flow:
+
+## 1. During step-02-check-branch: use the following definition for point 3. Gather Branch Parameters
+
+### 3. Gather Branch Parameters
+
+<action>
+Per the naming format in `{gitFlowGuide}` (`rama-padre-team-owner-rq-descripcion`), gather:
+
+1. **Parent Branch**: `develop` (fixed per guidelines)
+2. **Team**: Ask user or derive from project context
+3. **Owner**: Ask user or derive from git config (`git config user.email`)
+4. **RQ**: Extract from story metadata or ask user for requirement number
+5. **Description**: Derive from epic or feature name, sanitized (lowercase, hyphens)
+</action>
+
+<output>
+To create the branch, I need the following information per GitFlow guidelines:
+- **Team prefix**: (e.g., `legacy-erp-nomina`, `platform`, etc.)
+- **RQ number**: (requirement/ticket number)
+
+The owner will be derived from your git config, and the description from the story.
+</output>
+
+## 2. During step-02-check-branch: use the following definition for point 4. Construct Branch Name
+
+### 4. Construct Branch Name
+
+<action>
+1. Build branch name following the pattern from `{gitFlowGuide}`:
+   `{parent}-{team}-{owner}-{rq}-{description}`
+
+2. Apply governance rules from Section 4:
+   - All lowercase
+   - No special characters
+   - Hyphens as separators
+   - Branches must be created by epic or feature:
+     1. Extract the parent epic of the current story (from story frontmatter or `{sprint_status}`)
+     2. Use the **epic name/slug** as `{description}`, NOT the story name
+     3. Before creating a new branch, run `git branch --list "*rq{N}*"` to check if an epic-level branch already exists for this epic
+     4. **IF an epic branch already exists** → reuse it (switch/worktree to it), do NOT create a new one
+     5. **IF not** → create it using the epic slug as `{description}`
+
+Example: `develop-legacy-erp-nomina-gaduranb-rq1234-nueva-interfaz`
+         (where `nueva-interfaz` is the **epic** slug, not a story slug)
+</action>
+
+## 3. During step-02-check-branch: use the following definition for point 5. Check and Create/Switch Branch
+
+### 5. Check and Create/Switch Branch
+
+**IF Current Branch == Target Branch:**
+- Output: `✅ Already on correct branch: {{target_branch}}`
+- Proceed to Next Step.
+
+**IF Current Branch != Target Branch:**
+1. Check if `target_branch` exists: `git branch --list {{target_branch}}`.
+2. **IF Exists:**
+   - Run `cd ../wt-{{folder_name}}/{{folder_name}}-{{target_branch}}`.
+   - Output: `🔄 Switched to existing branch: {{target_branch}}`.
+3. **IF Not Exists:**
+   - Run `git worktree add ../wt-{{folder_name}}/{{folder_name}}-{{target_branch}} -b {{target_branch}}`.
+   - Run `cd ../wt-{{folder_name}}/{{folder_name}}-{{target_branch}}`.
+   - Output: `✨ Created and switched to new branch: {{target_branch}}`.

package/claude/commands/bmad/bmm/workflows/traceability-and-testing.md

@@ -1,5 +0,0 @@
----
-description: 'Generate functional traceability map (FR→Epic→Story→Task) and consolidated epic-level test plans from existing test cases'
----
-
-IT IS CRITICAL THAT YOU FOLLOW THIS COMMAND: LOAD the FULL @_bmad/bmm/workflows/4-implementation/traceability-and-testing/workflow.md, READ its entire contents and follow its directions exactly!

package/gemini/commands/bmad-workflow-bmm-traceability-and-testing.toml

@@ -1,4 +0,0 @@
-description = "BMAD BMM Workflow: traceability-and-testing"
-prompt = """
-IT IS CRITICAL THAT YOU FOLLOW THIS COMMAND: LOAD the FULL @_bmad/bmm/workflows/4-implementation/traceability-and-testing/workflow.md, READ its entire contents and follow its directions exactly!
-"""