siesa-agents 2.1.78 → 2.1.80

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

@@ -6,6 +6,142 @@
 
 Las siguientes reglas deben mantenerse en memoria y aplicarse en el momento oportuno sin alterar el flujo estándar del workflow:
 
+## 0. PRE-WORKFLOW: Menú de Selección de Modo (EJECUTAR ANTES DEL STEP 1)
+
+<!-- INSTRUCCIONES DE WORKFLOW — NO mostrar al usuario -->
+
+**ACCIÓN INMEDIATA:** Antes de ejecutar cualquier step del workflow, el agente DEBE presentar al usuario el menú de selección de modo usando la herramienta `AskUserQuestion`.
+
+### Pregunta principal — Selección de modo:
+
+Invocar `AskUserQuestion` con la siguiente configuración:
+
+```
+question: "¿Cómo deseas iniciar la generación del PRD?"
+header: "Modo PRD"
+options:
+  - label: "Documentación base"
+    description: "Cargo documentación existente, seleccionas los features a trabajar, y genero el PRD automáticamente."
+  - label: "Agregar feature"
+    description: "Extraigo un feature de Jira o lo describes manualmente. Agrego el Feature como un shard dentro de tu prd/"
+  - label: "Flujo estándar"
+    description: "Workflow interactivo paso a paso, colaborando conmigo en cada decisión."
+```
+
+### Preguntas de seguimiento según selección:
+
+**Si el usuario selecciona "Documentación base":**
+
+Invocar `AskUserQuestion`:
+```
+question: "¿Cuál es la ruta del directorio o archivos de documentación base?"
+header: "Ruta docs"
+options:
+  - label: "_bmad-output/"
+    description: "Usar la carpeta de output del proyecto actual."
+  - label: "docs/"
+    description: "Usar la carpeta docs del proyecto."
+```
+(El usuario puede elegir una opción sugerida o escribir una ruta personalizada vía "Other".)
+
+**Si el usuario selecciona "Agregar feature":**
+
+Invocar `AskUserQuestion`:
+```
+question: "¿El feature ya existe en Jira?"
+header: "Origen"
+options:
+  - label: "Sí, extraer de Jira"
+    description: "Necesitaré el issue key (ej: PROY-123) para extraer el detalle."
+  - label: "No, lo describiré manualmente"
+    description: "Podrás describir el feature en texto libre."
+```
+
+- **Si elige "Sí, extraer de Jira":** Invocar `AskUserQuestion` pidiendo el issue key:
+  ```
+  question: "¿Cuál es el issue key del feature en Jira? (ej: PROY-123)"
+  header: "Issue key"
+  options:
+    - label: "Buscar en Jira"
+      description: "Ejecuto una búsqueda en Jira para encontrar el feature."
+    - label: "Lo tengo"
+      description: "Escribiré el issue key directamente."
+  ```
+  Si elige "Buscar en Jira": ejecutar `node {project-root}/_siesa-agents/scripts/jira/search.js --jql "project = {project_key} AND issuetype = Story" --fields "summary,status" --max 20` y presentar los resultados para que el usuario seleccione.
+  Si elige "Lo tengo": el usuario proporciona el issue key vía "Other".
+
+- **Si elige "No, lo describiré manualmente":** Invocar `AskUserQuestion`:
+  ```
+  question: "Describe brevemente el feature que deseas agregar:"
+  header: "Feature"
+  options:
+    - label: "Feature de integración"
+      description: "Conectar con sistemas externos, APIs, servicios."
+    - label: "Feature de UI/UX"
+      description: "Nueva pantalla, componente, o flujo de usuario."
+    - label: "Feature de negocio"
+      description: "Nueva regla, proceso, o lógica de dominio."
+  ```
+  (El usuario elige una categoría o describe libremente vía "Other".)
+
+- **Después de obtener el feature (Jira o manual)**, invocar `AskUserQuestion`:
+  ```
+  question: "¿Tienes documentación base de soporte para este feature?"
+  header: "Docs soporte"
+  options:
+    - label: "Sí"
+      description: "Indicaré la ruta de la documentación."
+    - label: "No"
+      description: "Solo usaré la información del feature."
+  ```
+  Si elige "Sí": pedir ruta con otra `AskUserQuestion` (igual que en "Documentación base").
+
+### Procesamiento según modo seleccionado:
+
+**Modo "Documentación base":**
+1. Cargar toda la documentación de la ruta indicada en memoria (archivos `.md`, `.txt`, o cualquier documento encontrado en el directorio). Si es un directorio, cargar recursivamente. Si tiene `index.md`, usarlo como guía.
+2. **Proceder al Step 1 normalmente** (inicialización del workspace y descubrimiento de documentos estándar).
+3. **En el Step 2 (Discovery):** Este paso SÍ es interactivo. El agente debe:
+   - Analizar la documentación base cargada e identificar los features/capacidades presentes.
+   - Presentar al usuario la lista de features identificados usando `AskUserQuestion` con `multiSelect: true` y preguntarle: *"¿Sobre cuáles features deseas trabajar en este PRD?"*
+   - El usuario selecciona los features deseados.
+   - El agente filtra la documentación base, extrayendo SOLO la información relevante a los features seleccionados.
+   - A partir de aquí, el agente genera el contenido del Step 2 (Executive Summary, clasificación, etc.) basándose en la documentación filtrada, SIN preguntar al usuario.
+4. **Desde el Step 3 en adelante → MODO AUTO-RESPUESTA:**
+   - El agente genera el contenido de cada step basándose en la documentación base filtrada y el contexto acumulado.
+   - **NO pregunta al usuario** en ningún step.
+   - Los menús A/P/C se auto-resuelven como `[C] Continue` automáticamente.
+   - El agente procesa step tras step hasta completar el workflow.
+   - La regla `🛑 NEVER generate content without user input` queda SUSPENDIDA para este modo — la documentación base ES el input del usuario.
+   - **NIVEL DE PROFUNDIDAD:** El PRD generado DEBE ser un **documento maestro general / esqueleto**. Contiene la definición base de cada feature a nivel de alcance, objetivos y requisitos generales — NO el detalle profundo de implementación. El detalle se desarrolla después del sharding, en cada shard individual. Esto aplica a TODOS los steps: generar contenido conciso y estructural, no exhaustivo.
+
+**Modo "Agregar feature":**
+1. **Si viene de Jira:**
+   - Ejecutar: `node {project-root}/_siesa-agents/scripts/jira/get-issue.js --issue {jiraIssueKey} --fields "summary,description,acceptance_criteria,subtasks,components,labels"` para extraer el detalle completo del feature.
+   - Almacenar el resultado como contexto del feature.
+2. **Si es manual:** Almacenar la descripción proporcionada como contexto del feature.
+3. **Si tiene documentación de soporte:** Cargar toda la documentación de la ruta indicada en memoria.
+4. **Proceder al Step 1 normalmente** (inicialización).
+5. **El Step 2 (Discovery) se considera RESUELTO:**
+   - El feature extraído de Jira o descrito manualmente ES el feature a trabajar.
+   - El agente genera el contenido del Step 2 (Executive Summary, clasificación) automáticamente usando el contexto del feature + documentación de soporte.
+   - NO presenta el menú de descubrimiento de features al usuario.
+   - Auto-resuelve el menú A/P/C como `[C] Continue`.
+6. **Desde el Step 3 en adelante → MODO AUTO-RESPUESTA** (idéntico al modo "Documentación base", punto 4):
+   - Genera contenido automáticamente sin preguntar.
+   - Menús A/P/C se auto-resuelven como `[C] Continue`.
+   - Usa el contexto del feature + documentación como base para todo el contenido.
+   - **NIVEL DE PROFUNDIDAD:** El resultado de este modo es un **shard de feature** (`prd/f{N}-*.md`), NO un PRD maestro. El agente alimenta el shard con la información disponible (Jira + documentación de soporte). Si la información es insuficiente o parcial, generar un shard esqueleto con lo que haya — el ingeniero lo completará después.
+
+**Modo "Flujo estándar":**
+- No se aplica ninguna modificación. El workflow se ejecuta normalmente, step a step, interactivo con el usuario. Todas las reglas estándar aplican sin cambios.
+
+**Si el usuario responde "Other" en la pregunta principal:**
+- Interpretar la respuesta libre del usuario y mapearla al modo más cercano. Si no es claro, preguntar de nuevo.
+
+### Regla de transición al workflow estándar:
+Una vez procesado el resultado del menú y establecido el modo, continuar con la secuencia normal del workflow (Step 1 → Step 2 → ... → Step 11), aplicando las reglas del modo seleccionado en cada step.
+
 ## 1. Durante el Step 2 (Descubrimiento): Solicitar Features
 
 Cuando el workflow llegue a la fase de descubrimiento, presentar al usuario este menú exacto:

package/siesa-agents/bmm/workflows/3-solutioning/create-architecture/workflow_ext.md

@@ -28,6 +28,10 @@ Output to the user:
 
 ## INITIALIZATION
 
+Establish the following context path for use throughout all steps of this workflow:
+
+- `company_standards_path` = `{project-root}/_siesa-agents/bmm/workflows/3-solutioning/create-architecture/data/company-standards`
+
 Before doing anything else, search for an existing architecture document:
 
 1. Look for a file named `architecture.md` inside the `{planning_artifacts}/` folder located at the project root.
@@ -35,6 +39,203 @@ Before doing anything else, search for an existing architecture document:
 
 ---
 
+## STEP-01 INTERVENTION — A2. Load Company Standards
+
+**TRIGGER:** During execution of `step-01-init.md`, immediately after completing section **A. Input Document Discovery** and before proceeding to section **B. Validate Required Inputs**.
+
+Check for company standards at `{company_standards_path}`:
+
+- If the directory exists, load ALL `.md` files found inside it
+- Set `workflowMode` = "strict" if standards were loaded, else `workflowMode` = "discovery"
+- If `workflowMode` = "strict", report to the user: "✅ Estándares corporativos cargados. Modo: ESTRICTO"
+
+---
+
+## STEP-01 INTERVENTION — B. Validate Required Inputs (siesa-ui-kit)
+
+**TRIGGER:** During execution of `step-01-init.md`, during section **B. Validate Required Inputs**, append the following two validation blocks for frontend projects.
+
+**UI Kit Validation (if frontend project):**
+
+- Check `{project-root}/package.json` for `"siesa-ui-kit"`
+- If NOT found, warn the user: "⚠️ siesa-ui-kit no instalado. Ejecuta: npm i siesa-ui-kit"
+
+**UI Kit Component Reference (if frontend project):**
+
+- Fetch the siesa-ui-kit component catalog from: `https://siesa-ui-kit.pages.dev/llms.txt`
+- This provides the complete inventory of available UI components (forms, navigation, display, POS, business, layout views)
+- Use this catalog during architectural decisions to ensure component reuse over custom development
+- Store the component list in memory for reference throughout the architecture workflow
+- If the URL is unreachable, warn the user: "⚠️ No se pudo acceder al catálogo de componentes de siesa-ui-kit. Las decisiones de componentes se basarán en los estándares corporativos locales."
+
+---
+
+## STEP-03 INTERVENTION — STRICT MODE CHECK
+
+**TRIGGER:** At the very beginning of `step-03-starter.md`, before section **0. Check Technical Preferences & Context**.
+
+```markdown
+### STRICT MODE CHECK
+
+IF `workflowMode` == "strict":
+- Skip preference discovery (sections 0-7)
+- Extract stack from loaded `technology-stack.md`
+- Present: "📋 Stack corporativo aplicado: {stack_from_standards}"
+- If frontend: Include "npm i siesa-ui-kit" in initialization
+- Go directly to section 8 (Generate content)
+
+ELSE: Continue with discovery mode below.
+```
+
+---
+
+## STEP-03 INTERVENTION — Starter Options (Corporate Stack)
+
+**TRIGGER:** During execution of `step-03-starter.md`, in section **0. Check Technical Preferences** and section **1. Identify Primary Technology Domain**.
+
+**🚫 FORBIDDEN:** Do NOT recommend, suggest, or mention Next.js as a starter or framework option under any circumstance. Next.js is not part of the corporate stack.
+
+**✅ MANDATORY:** The corporate frontend stack is **Vite + TanStack Router + siesa-ui-kit**. This is non-negotiable regardless of user preferences.
+
+Apply the following replacements unconditionally:
+
+- **Frameworks preference (section 0):** Present as `React, Vue, Angular, **Vite**, etc.` — Next.js must be omitted
+- **Web application starters (section 1):** Present as `Vite, Remix, SvelteKit` — Next.js must be omitted
+- **Full-stack starters (section 1):** Present as `T3, RedwoodJS, Blitz` — Next.js must be omitted
+
+If the user explicitly asks about Next.js, respond: "⚠️ Next.js no forma parte del stack corporativo. El stack frontend estándar es Vite + TanStack Router + siesa-ui-kit."
+
+---
+
+## STEP-04 INTERVENTION — STRICT MODE CHECK
+
+**TRIGGER:** At the very beginning of `step-04-decisions.md`, before the **DECISION MAKING SEQUENCE**, when `workflowMode` is set.
+
+```markdown
+### STRICT MODE CHECK
+
+IF `workflowMode` == "strict":
+- Extract decisions from `backend-standards.md` and `frontend-standards.md`
+- Present: "📋 Decisiones corporativas aplicadas automáticamente"
+- Only facilitate decisions NOT covered by company standards
+- Skip web searches for predefined technologies
+
+ELSE: Continue with discovery mode below.
+```
+---
+
+## STEP-05 INTERVENTION — STRICT MODE CHECK
+
+**TRIGGER:** At the very beginning of `step-05-patterns.md`, before the **PATTERNS DEFINITION SEQUENCE**, when `workflowMode` is set.
+
+```markdown
+### STRICT MODE CHECK
+
+IF `workflowMode` == "strict":
+- Load patterns from `architecture-patterns.md`
+- Present: "📋 Patrones corporativos aplicados"
+- Only ask for patterns NOT covered by company standards
+
+ELSE: Continue with discovery mode below.
+```
+
+---
+
+## STEP-06 INTERVENTION — Corporate Project Tree (Vite + TanStack)
+
+**TRIGGER:** During execution of `step-06-structure.md`, in section **4. Create Complete Project Tree**, when generating the **Technology-Specific Structure Examples**.
+
+**🚫 FORBIDDEN:** Do NOT use, present, or generate any directory structure based on Next.js under any circumstance. Next.js is not part of the corporate stack — this applies unconditionally, regardless of user preferences or project type.
+
+**✅ MANDATORY:** The corporate frontend stack is **Vite + TanStack Router + siesa-ui-kit**. All project tree examples for web/full-stack projects MUST reflect this stack. This is non-negotiable.
+
+If the user explicitly requests a Next.js structure, respond: "⚠️ Next.js no forma parte del stack corporativo. La estructura estándar utiliza Vite + TanStack Router + siesa-ui-kit."
+
+Replace the `Next.js Full-Stack` example unconditionally with the following **Vite + TanStack Full-Stack** corporate structure:
+
+```
+project-name/
+├── README.md
+├── package.json
+├── vite.config.ts
+├── tailwind.config.js
+├── tsconfig.json
+├── .env
+├── .env.example
+├── .gitignore
+├── .github/
+│   └── workflows/
+│       └── ci.yml
+├── src/
+│   ├── main.tsx
+│   ├── App.tsx
+│   ├── routes/
+│   │   ├── __root.tsx
+│   │   └── index.tsx
+│   ├── components/
+│   │   ├── ui/
+│   │   ├── forms/
+│   │   └── features/
+│   ├── stores/
+│   │   └── index.ts
+│   ├── lib/
+│   │   ├── auth.ts
+│   │   └── utils.ts
+│   └── types/
+├── tests/
+│   ├── __mocks__/
+│   ├── components/
+│   └── e2e/
+└── public/
+    └── assets/
+```
+
+Key structural differences from Next.js:
+- `vite.config.ts` replaces `next.config.js`
+- `src/main.tsx` + `src/App.tsx` replace `src/app/layout.tsx` + `src/app/page.tsx`
+- `src/routes/` (TanStack Router) replaces `src/app/` (Next.js App Router)
+- `src/stores/` included for state management
+- No `prisma/` — ORM/DB config is defined separately per project needs
+
+---
+
+## STEP-07 INTERVENTION — Company Standards Adherence (STRICT MODE)
+
+**TRIGGER:** During execution of `step-07-validation.md`, at the very beginning of the **VALIDATION SEQUENCE**, before section **1. Coherence Validation**.
+
+**🚫 FORBIDDEN:** Do NOT validate or approve any architecture that includes Next.js. If Next.js is detected in any architectural decision, project structure, or technology stack, it MUST be flagged as a CRITICAL non-conformance and rejected unconditionally.
+
+**✅ MANDATORY:** The corporate frontend stack is **Vite + TanStack Router + siesa-ui-kit**. Validation MUST confirm its presence. An architecture without it is considered non-compliant and cannot proceed to implementation.
+
+Inject the following as section **0** of the validation sequence:
+
+```markdown
+### 0. Company Standards Adherence (STRICT MODE)
+
+IF `workflowMode` == "strict":
+- Validate all decisions match company standards loaded in step-01
+- Check `package.json` includes `siesa-ui-kit` (if frontend project)
+- Verify `vite.config.ts` is present and `next.config.js` is absent
+- Verify routing uses TanStack Router (`src/routes/`) not Next.js App Router (`src/app/`)
+- Report: "✅ Arquitectura 100% conforme con estándares corporativos"
+- If any deviation is found, flag it as a CRITICAL gap before proceeding to section 1
+
+ELSE: Skip this section and continue with section 1.
+```
+
+Additionally, append the following item to the **Architecture Completeness Checklist** inside the generated validation content (section 6):
+
+```markdown
+**✅ Corporate Standards Adherence** *(STRICT MODE)*
+
+- [x] All decisions validated against company standards
+- [x] siesa-ui-kit present in package.json
+- [x] Vite + TanStack Router confirmed as frontend stack
+- [x] No Next.js references in architecture decisions or structure
+```
+
+---
+
 ## DECISION BRANCH
 
 ### If `architecture.md` EXISTS
@@ -59,7 +260,7 @@ Wait for the user's selection and act accordingly:
 
 ### If `architecture.md` does NOT EXIST
 
-LOAD the FULL @_bmad/bmm/workflows/3-solutioning/create-architecture/workflow.md, READ its entire contents and follow its directions exactly!
+LOAD the FULL @.claude/skills/bmad-create-architecture/workflow.md, READ its entire contents and follow its directions exactly!
 
 ---
 

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

@@ -0,0 +1,46 @@
+# Siesa Extension — Epic Template AC Override
+
+This file extends the BMAD base epics template with a mandatory Acceptance Criteria section for QA validation.
+
+Add the following block inside each Epic section, **after the Epic goal statement and before the FRs covered line**:
+
+---
+
+```markdown
+### Acceptance Criteria (QA Validation)
+
+<!--
+  High-level criteria for QA team validation.
+  Write from end-user perspective, using business language.
+  Each criterion should be verifiable without technical knowledge.
+  These criteria validate the COMPLETE epic functionality.
+-->
+
+- [ ] **AC-E{{N}}.1:** {{high_level_criterion_1}}
+- [ ] **AC-E{{N}}.2:** {{high_level_criterion_2}}
+- [ ] **AC-E{{N}}.3:** {{high_level_criterion_3}}
+
+**FRs covered:** {{epic_frs}}
+```
+
+---
+
+## Writing Guidelines
+
+**✅ DO (Correct examples — business language, user perspective):**
+- "A new user can complete registration and receive a confirmation email"
+- "Users can search for products and see relevant results"
+- "The shopping cart persists across browser sessions"
+- "Users receive a notification when their order status changes"
+
+**❌ DON'T (Wrong examples — too technical):**
+- "API returns 200 status code with JWT token"
+- "Database query executes in less than 100ms"
+- "Redis cache invalidates on entity update"
+- "WebSocket connection established with heartbeat"
+
+## Numbering Convention
+
+- Epic N → criteria are `AC-E{N}.1`, `AC-E{N}.2`, `AC-E{N}.3`
+- Minimum 3, maximum 5 criteria per epic
+- Each criterion must map to at least one story within the epic

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

@@ -144,3 +144,62 @@ Output to the user:
 > `✅ Epics and Stories changes committed to Phase 3 (solutioning) branch.`
 
 **This is the LAST action of the workflow. Do not execute any further steps after this commit.**
+
+---
+
+# ============================================================================
+# MANDATORY RULE — EPIC ACCEPTANCE CRITERIA (QA VALIDATION)
+# ============================================================================
+
+## During step-02 (Design Epics): Include QA Acceptance Criteria
+
+**TRIGGER:** When designing and writing each epic in step-02.
+
+For EACH epic, after the goal statement, add **3-5 high-level Acceptance Criteria (QA Validation)**:
+
+```markdown
+#### Acceptance Criteria (QA Validation)
+- [ ] **AC-E{N}.1:** [High-level criterion from user perspective]
+- [ ] **AC-E{N}.2:** [High-level criterion from user perspective]
+- [ ] **AC-E{N}.3:** [High-level criterion from user perspective]
+```
+
+**🎯 WRITING GUIDELINES:**
+
+✅ **DO (Business language, user perspective):**
+- "A new user can complete registration and receive confirmation email"
+- "Users can search for products and see relevant results"
+- "The shopping cart persists across browser sessions"
+
+❌ **DON'T (Too technical):**
+- "API returns 200 status code with JWT token"
+- "Database query executes in less than 100ms"
+
+**Rules:**
+- Write from end-user perspective using business language
+- Make them verifiable by QA without code knowledge
+- Each AC must map to at least one story within the epic
+- Minimum 3, maximum 5 criteria per epic
+
+Template reference: `@_siesa-agents/bmm/workflows/3-solutioning/create-epics-and-stories/templates/epics-template.md`
+
+---
+
+## During step-04 (Final Validation): Epic AC Coverage Check (CRITICAL)
+
+After all epics and stories are generated, validate that every Epic AC has at least one supporting story:
+
+```
+Epic N: [Title]
+├── AC-EN.1: [Criterion] → Supported by: Story N.X, Story N.Y
+├── AC-EN.2: [Criterion] → Supported by: Story N.Z
+└── AC-EN.3: [Criterion] → Supported by: Story N.X, Story N.W
+```
+
+**🚨 VALIDATION RULES:**
+- ❌ FAIL: Epic AC has NO supporting stories
+- ❌ FAIL: Epic AC uses technical jargon instead of business language
+- ✅ PASS: Every Epic AC maps to at least one story
+- ✅ PASS: Epic AC is verifiable by QA without technical knowledge
+
+**If gaps found:** Recommend adding stories OR adjusting Epic AC. Do NOT proceed until all Epic AC have story support.

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

@@ -14,8 +14,9 @@ parameters:
 
 **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 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 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.
+- **Fase 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.
 
 **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.
 
@@ -66,10 +67,6 @@ El proceso de calidad tiene tres fases:
                          Planes de Ejecución (PEP) y links de trazabilidad.
                          (Requiere: Fase 1 completada y validada por el equipo QA)
 
-  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)
-
 ¿Qué fase deseas ejecutar?
 ```
 
@@ -896,4 +893,4 @@ Parsear la salida final del script y presentar al usuario:
   💾 State file guardado en:
     {ruta relativa}/bmad_state_{feature_code}.json
     (Idempotente: re-ejecutar la Fase 3 con el mismo diseño es seguro)
-```
+```

package/siesa-agents/bmm/workflows/4-implementation/code-review/steps/step-01-load-story.md

@@ -0,0 +1,101 @@
+---
+name: 'step-01-load-story'
+description: 'Load story file and discover actual implementation changes via git'
+
+# Path Definitions
+workflow_path: '{project-root}/_siesa-agents/bmm/workflows/4-implementation/code-review'
+
+# File References
+thisStepFile: '{workflow_path}/steps/step-01-load-story.md'
+nextStepFile: '{workflow_path}/steps/step-02-build-plan.md'
+workflowFile: '{workflow_path}/workflow.md'
+outputFile: '{output_folder}/review-{story_key}.md'
+
+# Data References
+checklist: '{workflow_path}/checklist.md'
+---
+
+# Step 1: Load Story and Discover Changes
+
+## STEP GOAL:
+To load the target story file, identify the implementation scope, and discover the actual changes in the codebase using git.
+
+## MANDATORY EXECUTION RULES:
+- 🛑 NEVER generate content without user input
+- 📖 Read the complete step file before taking any action
+- 📋 YOU ARE AN ADVERSARIAL CODE REVIEWER - Skeptical and thorough
+
+## EXECUTION PROTOCOLS:
+- 🎯 Load story and parse requirements
+- 🔍 Detect git changes
+- 💾 meaningful frontmatter updates
+
+## Sequence of Instructions
+
+### 1. Identify Target Story
+
+If `{{story_path}}` is not already defined in variables:
+Ask the user: "Which story file should we review? (Provide path or key)"
+
+### 2. Load Story Content
+
+1. Load and read the COMPLETE story file from `{{story_path}}`
+2. Extract the `story_key` (e.g., from filename "1-2-user-auth.md" -> "1-2-user-auth")
+3. Parse the following sections:
+   - **Story Description**
+   - **Acceptance Criteria**
+   - **Tasks/Subtasks**
+   - **Dev Agent Record** (specifically the File List)
+   - **Change Log**
+
+### 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 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)
+
+### 4. Cross-Reference Claims vs Reality
+
+Compare the Story's **Dev Agent Record -> File List** with the **Actual Changed Files**:
+- Identify **Files in Git but NOT in Story** (Undocumented changes)
+- Identify **Files in Story but NOT in Git** (False claims)
+- Identify **Missing Documentation**
+
+### 5. Load Project Context
+
+Load `{project_context}` (usually `**/project-context.md`) to understand coding standards.
+
+### 6. Initialize Output Review Document
+
+Create `{outputFile}` with initial analysis:
+
+```markdown
+# Code Review: {{story_key}}
+
+- **Date**: {{date}}
+- **Reviewer**: {{user_name}} (AI Agent)
+- **Status**: In Progress
+
+## Initial Discovery
+- **Undocumented Changes**: [List]
+- **Missing Files**: [List]
+```
+
+### 7. Present MENU OPTIONS
+
+Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
+
+#### Menu Handling Logic:
+- IF A: Execute {advancedElicitationTask}
+- IF P: Execute {partyModeWorkflow}
+- IF C: Save analysis to {outputFile}, update frontmatter `stepsCompleted: [1]`, `story_path: ...`, `story_key: ...`, then only then load, read entire file, then execute {nextStepFile}
+- IF Others: Handle queries then redisplay menu
+
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input
+- ONLY proceed to next step when user selects 'C'