siesa-agents 2.1.78 → 2.1.79

package/siesa-agents/EXTENSIONS.md

@@ -0,0 +1,151 @@
+# Siesa-Agents Extension Module
+
+## Purpose
+
+`_siesa-agents/` is the **Siesa extension layer** for [BMAD v5](https://github.com/bmad-ai/bmad-method). It adds Siesa-specific customizations on top of the pristine BMAD core without modifying BMAD source files.
+
+`bmad/` (and its installed twin `_bmad/` in consumer projects) remains **100% unmodified** — always upgradeable to new BMAD releases.
+
+---
+
+## How the Extension Mechanism Works
+
+### 1. Launcher wiring (`.claude/commands/bmad/bmm/workflows/<name>.md`)
+
+Each workflow has a launcher slash-command. The launcher:
+1. **Loads `_siesa-agents/.../workflow_ext.md` FIRST** — Siesa-specific rules are injected into memory.
+2. Then loads `_bmad/core/tasks/workflow.xml` (BMAD core OS).
+3. Then passes the base workflow config (`_bmad/.../workflow.md` or `workflow.yaml`) to the core OS.
+4. The AI agent executes the workflow with Siesa rules active throughout.
+
+### 2. Extension file convention (`workflow_ext.md`)
+
+Every overridden workflow has a `workflow_ext.md` at a **path-mirror** of the BMAD workflow:
+
+```
+_siesa-agents/bmm/workflows/<same-path-as-bmad>/workflow_ext.md
+```
+
+The `workflow_ext.md` contains:
+- **Pre-step rules** — mandatory actions before workflow starts (branch creation, standard loading)
+- **Step amendments** — "During step-XX: use the following definition for point N..."
+- **Step replacements** — "REPLACE entirely with..." for sections with Siesa logic
+- **Post-step rules** — actions after workflow completes (phase commits)
+
+### 3. Companion step-files
+
+For workflows that use a step-file architecture (code-review, create-story, dev-story), the Siesa step-files live at:
+
+```
+_siesa-agents/bmm/workflows/4-implementation/<workflow>/steps/step-NN-<name>.md
+```
+
+The `workflow_ext.md` lists these step-files explicitly so the AI knows to load them instead of the base `instructions.xml`.
+
+### 4. New workflows (no BMAD equivalent)
+
+Wholly new Siesa workflows go under `_siesa-agents/bmm/workflows/<phase>/` with a full `workflow.md` (not `_ext`). The launcher loads this file directly.
+
+### 5. Company-standards data
+
+Siesa-specific reference data (8 standards documents, ~160 KB) lives at:
+
+```
+_siesa-agents/bmm/workflows/3-solutioning/create-architecture/data/company-standards/
+```
+
+### 6. Mirror (`siesa-agents/`)
+
+`siesa-agents/` (without underscore) is the **distribution copy** published by the npx installer. It must always be a byte-for-byte copy of `_siesa-agents/`. Source of truth is `_siesa-agents/`. Sync after every change.
+
+### 7. Scripts and shared resources
+
+- `_siesa-agents/scripts/jira/` — OAuth-aware Jira CLI scripts
+- `_siesa-agents/scripts/phases/phase{1,2,3}.js` — Git branch/commit automation
+- `_siesa-agents/resources/architecture/` — Consolidated architecture docs
+- `_siesa-agents/resources/ux-ui/` — UX/UI shared templates
+- `_siesa-agents/sa/` — Wholly new Siesa workflows (not overrides)
+
+---
+
+## Extension Map
+
+### Overrides (`workflow_ext.md`)
+
+| Workflow | BMAD path | Extension | Key customizations |
+|---|---|---|---|
+| create-product-brief | `1-analysis/create-product-brief/` | `workflow_ext.md` | Phase branch |
+| create-ux-design | `2-plan-workflows/create-ux-design/` | `workflow_ext.md` | Phase branch, siesa-ui-kit P0, llms.txt, Spanish UI |
+| create-prd | `2-plan-workflows/prd/` | `workflow_ext.md` | Phase branch, feature sharding |
+| check-implementation-readiness | `3-solutioning/check-implementation-readiness/` | `workflow_ext.md` | Phase branch |
+| create-architecture | `3-solutioning/create-architecture/` | `workflow_ext.md` | Phase branch, company-standards Strict Mode, Vite-over-Next |
+| create-epics-and-stories | `3-solutioning/create-epics-and-stories/` | `workflow_ext.md` | Phase branch, sharding, FEATURE_CODE_JIRA, Epic AC QA |
+| quality-process | `3-solutioning/quality-process/` | `workflow.md` (full) | AgileTest integration (full replacement, not ext) |
+| code-review | `4-implementation/code-review/` | `workflow_ext.md` + `steps/` | Step-file arch, Git worktree discovery, Jira sync, commit/push |
+| correct-course | `4-implementation/correct-course/` | `workflow_ext.md` | Phase branch |
+| create-story | `4-implementation/create-story/` | `workflow_ext.md` + `steps/` | Step-file arch, feature context injection, mastercrud |
+| dev-story | `4-implementation/dev-story/` | `workflow_ext.md` + `steps/` + `checklist_ext.md` | Step-file arch, gitflow branch naming, worktree, UI-kit checklist |
+| sprint-planning | `4-implementation/sprint-planning/` | `workflow_ext.md` | Epic source traceability, incremental re-run, date idempotency |
+| sprint-status | `4-implementation/sprint-status/` | `workflow_ext.md` | Phase branch |
+| generate-project-context | `generate-project-context/` | `workflow_ext.md` | Feature-specific mode, company-standards, siesa-ui-kit catalog |
+| workflow-status | `workflow-status/init/` | `workflow_ext.md` | Initialization |
+| testarch-framework | `testarch/framework/` | `workflow_ext.md` | Vite over Next.js |
+
+### New phases (no BMAD equivalent)
+
+| Workflow | Path | Description |
+|---|---|---|
+| create-user-guide | `5-documentation/create-user-guide/` | Generates user guides in Spanish from epics/PRDs |
+
+### Companion step-file sets
+
+| Workflow | Step files |
+|---|---|
+| code-review | `4-implementation/code-review/steps/` — 7 files (step-01 to step-07) |
+| create-story | `4-implementation/create-story/steps/` — 6 files (step-01 to step-06) |
+| dev-story | `4-implementation/dev-story/steps/` — 12 files (step-01 to step-12) |
+
+### Company-standards data
+
+| File | Content |
+|---|---|
+| `3-solutioning/create-architecture/data/company-standards/architecture-patterns.md` | Siesa architectural patterns (443 lines) |
+| `3-solutioning/create-architecture/data/company-standards/backend-standards.md` | .NET backend standards (811 lines) |
+| `3-solutioning/create-architecture/data/company-standards/database-conventions.md` | PostgreSQL conventions (667 lines) |
+| `3-solutioning/create-architecture/data/company-standards/frontend-standards.md` | Frontend + siesa-ui-kit (1200 lines) |
+| `3-solutioning/create-architecture/data/company-standards/mastercrud-use-reference.md` | MasterCRUD component API (276 lines) |
+| `3-solutioning/create-architecture/data/company-standards/technical-preferences-ux.md` | UX technical preferences (423 lines) |
+| `3-solutioning/create-architecture/data/company-standards/technology-stack.md` | Corporate stack: .NET 10, Vite 7+ (293 lines) |
+| `3-solutioning/create-architecture/data/company-standards/vite-config-standard.md` | Standard Vite configuration (535 lines) |
+
+---
+
+## Cross-cutting Siesa Patterns
+
+| Pattern | Files affected |
+|---|---|
+| **siesa-ui-kit P0 mandatory** | create-ux-design, create-architecture, generate-project-context, dev-story checklist |
+| **llms.txt component catalog fetch** | create-ux-design, create-architecture, generate-project-context |
+| **Vite over Next.js** | create-architecture, testarch/framework, generate-project-context |
+| **Company Standards Strict Mode** | create-architecture (steps 01, 03, 04, 05, 07) |
+| **UI text in Spanish** | create-ux-design |
+| **Epic QA Acceptance Criteria** | create-epics-and-stories (steps 02 + 04), epics-template.md |
+| **Date idempotency** | sprint-planning (step 3.5) |
+| **Step-file architecture** | code-review (7), create-story (6), dev-story (12) |
+| **Jira OAuth sync** | code-review (step-06), scripts/jira/ |
+| **Automated commit/push** | code-review (step-07), scripts/phases/ |
+| **Feature-specific context** | generate-project-context, create-story, dev-story |
+| **FEATURE_CODE_JIRA marker** | create-epics-and-stories |
+
+---
+
+## Keeping the Mirror in Sync
+
+After any change to `_siesa-agents/`, run:
+
+```bash
+# From Siesa-Agents/ root
+rsync -av --delete _siesa-agents/ siesa-agents/
+```
+
+The only intentional difference: `_siesa-agents/scripts/bmad_to_agiletest.py` may not be in `siesa-agents/` (internal tooling not distributed via npx).

package/siesa-agents/bmm/workflows/2-plan-workflows/create-ux-design/workflow_ext.md

@@ -30,7 +30,179 @@ Output to the user:
 
 ---
 
-## 2. INITIALIZATION — CHECK FOR EXISTING UX DESIGN DOCUMENT
+## 2. CONTEXT AND STANDARDS SETUP
+
+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`
+
+### Company Standards Integration
+
+🔴 **CRITICAL**: Load company standards for UX specifications:
+
+If `{company_standards_path}` exists, load these files:
+- `frontend-standards.md` - Contains **siesa-ui-kit** rules and component strategy
+- `technical-preferences-ux.md` - UX/UI preferences and patterns
+
+**Priority Rules from Company Standards:**
+| Priority | Rule | Why Critical |
+|----------|------|--------------|
+| 🔴 P0 | **siesa-ui-kit obligatorio** | Must check siesa-ui-kit before creating ANY component |
+| 🔴 P0 | **UI text in Spanish** | All user-facing text MUST be in Spanish |
+| 🟡 P1 | Design system tokens | Use company-defined colors, spacing, typography |
+
+---
+
+## 3. STEP-11 INTERVENTION — Component Strategy (siesa-ui-kit First)
+
+**TRIGGER:** At the very beginning of `step-11-component-strategy.md`, before section `## YOUR TASK`.
+
+Inject the following section immediately before `## YOUR TASK`:
+
+```markdown
+## 🔴 CRITICAL: SIESA-UI-KIT MANDATORY CHECK
+
+**BEFORE defining ANY component strategy, you MUST:**
+
+1. **Load Company Standards** from `{company_standards_path}/frontend-standards.md`
+2. **Check siesa-ui-kit FIRST** for every component need identified
+3. **Follow the Component Decision Protocol** below
+
+### Component Decision Protocol
+
+For EVERY component needed in the UX specification:
+
+┌─────────────────────────────────────────┐
+│  Component Needed: [Component Name]      │
+└─────────────────────────────────────────┘
+                    │
+                    ▼
+┌─────────────────────────────────────────┐
+│  Is it in siesa-ui-kit?                 │
+└─────────────────────────────────────────┘
+          │                    │
+         YES                   NO
+          │                    │
+          ▼                    ▼
+┌─────────────────┐  ┌─────────────────────────┐
+│ USE siesa-ui-kit │  │ ASK USER:               │
+│ component AS-IS  │  │ [1] Use shadcn directly │
+└─────────────────┘  │ [2] Create custom for   │
+                     │     siesa-ui-kit (MR)   │
+                     └─────────────────────────┘
+
+### Why This Matters
+
+| Rule | Impact |
+|------|--------|
+| **siesa-ui-kit first** | 90% fewer bugs vs manual creation |
+| **Consistency** | Unified experience across all Siesa products |
+| **Maintenance** | Platform team maintains shared components |
+| **Compliance** | Meets company visual and accessibility standards |
+
+### UI Text Language Rule
+
+🔴 **MANDATORY**: All user-facing text in UX specifications MUST be in Spanish.
+
+**✅ CORRECT:**
+- Buttons: "Guardar", "Cancelar", "Enviar"
+- Labels: "Nombre de usuario", "Contraseña"
+- Messages: "Datos guardados correctamente"
+
+**❌ INCORRECT:**
+- Mixed: "Save cambios", "Failed al guardar"
+- English: "Save", "Cancel", "Submit"
+```
+
+---
+
+Replace `### 1. Analyze Design System Coverage` with:
+
+```markdown
+### 1. Load siesa-ui-kit and Company Standards
+
+🔴 **FIRST**: Before any analysis, load:
+- `{company_standards_path}/frontend-standards.md`
+- Check if siesa-ui-kit documentation exists in project
+
+🔴 **MANDATORY - Load siesa-ui-kit Component Inventory:**
+- Fetch the component catalog from: `https://siesa-ui-kit.pages.dev/llms.txt`
+- This file contains the complete, up-to-date list of all available siesa-ui-kit components
+- Parse and use this inventory as the **authoritative source**
+- If the URL is unreachable, warn the user: "⚠️ No se pudo acceder al catálogo de siesa-ui-kit..."
+
+"Before we analyze components, let me load the company standards and the **siesa-ui-kit component catalog**..."
+```
+
+---
+
+Replace `### 2. Design Custom Components` with:
+
+```markdown
+### 2. Analyze Component Coverage (siesa-ui-kit FIRST)
+
+Review components in this priority order:
+1. **siesa-ui-kit** (company shared components) - USE FIRST
+2. **Design System** from step 6 (shadcn/Radix) - fallback
+3. **Custom components** - only if not in above
+
+...
+**Gap Analysis (Components NOT in siesa-ui-kit or Design System):**
+For each gap, we need to ask:
+- [Gap 1] → [1] Use shadcn directly OR [2] Create for siesa-ui-kit?
+```
+
+*(What was `### 2.` becomes `### 3.`, and subsequent steps renumber accordingly.)*
+
+---
+
+Replace the output document structure inside `### 6. Generate Component Strategy Content` with:
+
+```markdown
+## Component Strategy
+
+### siesa-ui-kit Components (Priority 1)
+[List all components from siesa-ui-kit that will be used - THESE ARE MANDATORY]
+
+### Design System Components (Priority 2)
+[Components from shadcn/Radix not covered by siesa-ui-kit]
+
+### Custom Components (Priority 3)
+[Custom component specifications - only for gaps not covered above]
+[Include decision: shadcn direct OR create for siesa-ui-kit MR]
+
+### Component Implementation Strategy
+[Component implementation strategy based on conversation]
+[Include UI text language: Spanish for all user-facing text]
+
+### Implementation Roadmap
+[Implementation roadmap based on conversation]
+```
+
+---
+
+Append to `## SUCCESS METRICS:`:
+
+```
+✅ **siesa-ui-kit checked FIRST** before any component decisions
+✅ Company standards loaded from `{company_standards_path}`
+✅ **All UI text in Spanish** for user-facing elements
+```
+
+---
+
+Append to `## FAILURE MODES:`:
+
+```
+❌ **CRITICAL**: NOT checking siesa-ui-kit FIRST - creates components that already exist
+❌ **CRITICAL**: Creating custom components without asking user (shadcn vs siesa-ui-kit MR)
+❌ **CRITICAL**: UI text in English instead of Spanish
+❌ Not loading company standards from `{company_standards_path}`
+```
+
+---
+
+## 4. INITIALIZATION — CHECK FOR EXISTING UX DESIGN DOCUMENT
 
 Before executing any workflow step, search for an existing UX design document:
 
@@ -39,7 +211,7 @@ Before executing any workflow step, search for an existing UX design document:
 
 ---
 
-## 3. DECISION BRANCH
+## 5. DECISION BRANCH
 
 ### If `ux-design-specification.md` EXISTS
 
@@ -61,16 +233,17 @@ Wait for the user's selection and act accordingly:
 
 ### If `ux-design-specification.md` does NOT EXIST
 
-LOAD the FULL `@_bmad/bmm/workflows/2-plan-workflows/create-ux-design/workflow.md`, READ its entire contents and follow its directions exactly!
+LOAD the FULL `@.claude/skills/bmad-create-ux-design/workflow.md`, READ its entire contents and follow its directions exactly!
 
 ---
 
-## 4. MANDATORY RULE — PHASE COMMIT AT WORKFLOW END
+## 6. MANDATORY RULE — PHASE COMMIT AT WORKFLOW END
 
 **TRIGGER:** Immediately after all workflow steps complete and the UX Design document has been generated/saved.
 
 **CRITICAL INSTRUCTION:** As the final action of this workflow, you MUST invoke the `generate-commits-by-phase` skill to commit all changes for Phase 2.
 
+
 ### EXECUTION STEPS (PERFORM THESE ACTIONS AT THE END)
 
 **STEP 1: INSPECT CHANGES**

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: