siesa-agents 2.1.67 → 2.1.70

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/claude/commands/jira_sync/sync-epics-stories.md

@@ -0,0 +1,5 @@
+---
+description: 'Sync Epics and Stories'
+---
+
+IT IS CRITICAL THAT YOU FOLLOW THIS COMMAND: LOAD the FULL @_siesa-agents/sa/sync-epics-stories/workflow.md, READ its entire contents and follow its directions exactly!

package/claude/commands/sa-jira-sync.md

@@ -0,0 +1,11 @@
+---
+name: sa-jira-sync
+description: Query Jira and return a minimal hierarchy of Epics → Stories → Subtasks for a given project and epic status. Returns only id, key, name, and status for each level. Use when the user needs to inspect or export the epic/story/subtask structure from siesa-team or siesa-test-sandbox.
+argument-hint: [PROJECT-KEY] [--status "Epic Status"]
+user-invocable: true
+allowed-tools: Bash, Read, Write
+---
+
+Handle the Jira sync request: **$ARGUMENTS**
+
+IT IS CRITICAL THAT YOU FOLLOW THIS COMMAND: LOAD the FULL @_siesa-agents/sa/sa-jira-sync-api/jira-sync-api.md, READ its entire contents and follow its directions exactly!

package/gemini/commands/bmad-workflow-bmm-code-review.toml

@@ -3,10 +3,11 @@ prompt = """
 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.yaml
+4. Pass the yaml path _bmad/bmm/workflows/4-implementation/code-review/workflow.yaml 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/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/gemini/commands/sa-jira-sync.toml

@@ -0,0 +1,9 @@
+description = "SA: Query Jira and return a minimal hierarchy of Epics → Stories → Subtasks for a given project and epic status. Returns only id, key, name, and status for each level."
+prompt = """
+IT IS CRITICAL THAT YOU FOLLOW THIS COMMAND: LOAD the FULL @_siesa-agents/sa/sa-jira-sync-api/jira-sync-api.md, READ its entire contents and follow its directions exactly!
+
+Parse the user arguments: **$ARGUMENTS**
+- First positional arg → PROJECT_KEY (e.g. PPS)
+- --status "..." → filter epics by this status name (default: En curso)
+- If no PROJECT_KEY is provided, prompt the user for one.
+"""

package/gemini/commands/sa-workflow-sync-epics-stories.toml

@@ -0,0 +1,4 @@
+description = "SA Workflow: sync-epics-stories — Sync Epics and Stories with Jira"
+prompt = """
+IT IS CRITICAL THAT YOU FOLLOW THIS COMMAND: LOAD the FULL @_siesa-agents/sa/sync-epics-stories/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.70",
   "description": "Paquete para instalar y configurar agentes SIESA en tu proyecto",
   "main": "index.js",
   "bin": {

package/siesa-agents/bmm/workflows/2-plan-workflows/prd/workflow_ext.md

@@ -16,11 +16,30 @@ Cuando el workflow llegue a la fase de descubrimiento, presentar al usuario este
 > **2. Proporcionarlos manualmente** — Puedes pegarlos aquí, compartir un archivo `.txt` o `.md`, o describirlos en texto libre."
 
 <!-- INSTRUCCIONES DE WORKFLOW — NO mostrar al usuario -->
-- Si el usuario elige **opción 1 (Jira):** Invocar el skill `get-features` (UBICADO EN .claude\commands\get-features\SKILL.md) usando el Skill tool con `skill: "get-features"`. El skill se encargará de autenticarse con Jira, seleccionar instancia y proyecto, y generar el árbol de features en `_bmad-output/planning-artifacts/jira-trees/`. Una vez generado, leer ese archivo y extraer la lista de features del resultado para usarla como estructura del PRD.
-- Si el usuario elige **opción 2 (Manual):** Aceptar la lista de features que el usuario proporcione en cualquier formato (texto libre, `.txt`, `.md` o copia-pegado) y procesarla directamente.
+- Si el usuario elige **opción 1 (Jira):** Invocar el skill `get-features` (UBICADO EN .claude\commands\get-features\SKILL.md) usando el Skill tool con `skill: "get-features"`. El skill se encargará de autenticarse con Jira, seleccionar instancia y proyecto, y generar el árbol de features en `_bmad-output/planning-artifacts/jira-trees/`. Una vez generado, leer ese archivo y extraer la lista de features del resultado para usarla como estructura del PRD. Por cada feature extraído de Jira, **incluir obligatoriamente** el marcador `FEATURE_CODE_JIRA={ISSUE_KEY}` en su sección del PRD (donde `{ISSUE_KEY}` es el ID del issue en Jira, ej: `PROY-123`). Este marcador es crítico para la sincronización posterior con Jira:
+  - Los shards del PRD (`prd/f{N}-*.md`) y los shards de épicas (`epics/f{N}-*.md`) deben contener este marcador.
+  - Al sincronizar, el workflow resuelve el ID con este orden de prioridad: (1) busca `FEATURE_CODE_JIRA=` en el shard de la épica; (2) si no lo encuentra, lo busca en el shard del PRD correspondiente.
+  - ⚠️ Si ninguno de los dos shards contiene el marcador, la sincronización fallará para ese feature. Es responsabilidad del ingeniero asegurar que el marcador exista en al menos uno de los dos shards antes de ejecutar la sincronización.
+- Si el usuario elige **opción 2 (Manual):** Aceptar la lista de features que el usuario proporcione en cualquier formato (texto libre, `.txt`, `.md` o copia-pegado) y procesarla directamente. Por cada feature creado manualmente, incluir el marcador `FEATURE_CODE_JIRA=PENDING:{feature-slug}` (donde `{feature-slug}` es el nombre del feature en kebab-case, ej: `FEATURE_CODE_JIRA=PENDING:gestion-de-clientes`). Este valor temporal indica que el feature aún no existe en Jira y será creado automáticamente cuando el ingeniero ejecute `jira_sync`.
 
 Inyectar los features confirmados como estructura del PRD: cada feature debe quedar como una sección `### feature — {Name}` dentro del documento.
 
+<!-- INSTRUCCIONES DE WORKFLOW — NO mostrar al usuario -->
+**Si el PRD ya fue shardeado (existe la carpeta `prd/` con archivos `f{N}-*.md`):**
+- **NO modificar** el PRD maestro original.
+- Por cada nuevo feature que el ingeniero quiera agregar, ejecutar el siguiente flujo de resolución **antes de crear el shard**:
+
+  1. Invocar el skill `get-features` (usando el Skill tool con `skill: "get-features"`) para traer el árbol actualizado de features desde Jira.
+  2. Leer el árbol generado en `_bmad-output/planning-artifacts/jira-trees/` y filtrar los features que **no tienen shard local** (cuyo `ISSUE_KEY` no aparece en ningún `prd/f{N}-*.md` existente).
+  3. Mostrar al ingeniero la lista filtrada y preguntar:
+     > *"Se encontraron los siguientes features en Jira sin shard local. ¿Alguno corresponde al feature que acabas de describir?"*
+     - Listar cada feature con su KEY y nombre (ej: `PROY-89 — Gestión de Clientes`).
+     - Incluir siempre la opción: **"Ninguno — es un feature completamente nuevo, no existe en Jira"**.
+  4. **Si el ingeniero selecciona un feature de Jira** → crear el shard `f{N}-{feature-name}.md` con `FEATURE_CODE_JIRA={ISSUE_KEY}` del feature seleccionado.
+  5. **Si el ingeniero elige "Ninguno"** → crear el shard `f{N}-{feature-name}.md` con `FEATURE_CODE_JIRA=PENDING:{feature-slug}`.
+
+- Informar al ingeniero qué archivo shard fue creado y que puede enriquecerlo con detalle adicional de forma independiente.
+
 ## 2. Naturaleza del PRD Generado
 
 El PRD que produce este workflow es un **documento maestro general**. Contiene la definición base de cada feature a nivel de alcance, objetivos y requisitos generales — NO el detalle profundo de implementación de cada uno.

package/siesa-agents/bmm/workflows/3-solutioning/create-epics-and-stories/workflow_ext.md

@@ -63,5 +63,11 @@ Una vez confirmada la lista de features, inyectar las siguientes reglas de estru
 
 6. **Step 3 (Stories)**: Al generar épicas y stories, escribir cada feature como sección `##`, con sus épicas como `###` y stories como `####`. La numeración de stories sigue el patrón `{epic_num}.{story_num}` (ej: Story 3.1, Story 3.2 para Epic 3).
 
+7. **Marcador `FEATURE_CODE_JIRA`**: Cada archivo shard de épica debe comenzar con la siguiente línea como **primera línea del archivo**, antes de cualquier heading:
+   ```
+   <!-- FEATURE_CODE_JIRA=PENDING:{slug} -->
+   ```
+   donde `{slug}` es el mismo slug kebab-case del feature correspondiente en el PRD shard (ej: `gestion-de-clientes`, `asociacion-cliente-contacto`). Este marcador es requerido por el workflow `sync-epics-stories` para asociar el shard con su issue en Jira.
+
 **PASO 3: CONTINUAR CON WORKFLOW ESTÁNDAR**
 Después de inyectar el contexto, continuar con el flujo normal del workflow `create-epics-and-stories` (step-01 → step-02 → step-03 → step-04), aplicando las reglas de estructura en cada paso.

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]**