siesa-agents 2.1.89 → 2.1.91

package/siesa-agents/bmm/workflows/3-solutioning/wds-visual-proposals/templates/trigger-map-bridge.md

@@ -0,0 +1,54 @@
+---
+type: wds-trigger-map
+status: bridged-from-planning
+source: siesa-planning-bridge
+generated_date: ""
+source_files: []
+stepsCompleted: []
+---
+
+# Trigger Map — {{project_name}}
+
+> Prerequisito de Fase 2 (WDS) generado desde el PRD + épicas. Mapea la psicología del usuario a los objetivos de negocio. Es lo que Freya usa para crear escenarios.
+
+## Personas
+
+> Una persona por archivo: `B-Trigger-Map/NN-persona-<nombre>-<arquetipo>.md`. Nombres aliterados (ej. "Carla la Cajera"). Aquí va el resumen.
+
+| Persona | Arquetipo | Awareness stage | Archivo |
+|---|---|---|---|
+| {{persona_1_name}} | {{persona_1_archetype}} | {{persona_1_awareness}} | {{persona_1_file}} |
+
+## Driving Forces (por persona)
+
+### {{persona_1_name}}
+
+**Fuerzas positivas** (deseos, aspiraciones):
+- {{positive_1}}
+
+**Fuerzas negativas** (miedos, frustraciones):
+- {{negative_1}}
+
+[Source: {{prd_pains_gains_source}}]
+
+## Business Goals ↔ Triggers
+
+| Objetivo de negocio | Trigger del usuario | Persona |
+|---|---|---|
+| {{biz_goal_1}} | {{trigger_1}} | {{persona_ref_1}} |
+
+[Source: {{prd_goals_source}}]
+
+## Feature Impact
+
+> Detalle completo en `B-Trigger-Map/feature-impact.md` (épica/feature × persona × driving force).
+
+| Épica / Feature | Persona | Driving force | Impacto |
+|---|---|---|---|
+| {{feature_1}} | {{persona_ref}} | {{force}} | {{impact}} |
+
+[Source: {{epics_source}}]
+
+---
+
+_Provenance: derivado de los archivos en `source_files`. Marcar `⚠️ [Asunción — confirmar]` donde el planning no lo especifica._

package/siesa-agents/bmm/workflows/3-solutioning/wds-visual-proposals/workflow.md

@@ -0,0 +1,82 @@
+---
+name: wds-visual-proposals
+description: Toma los artefactos de planning ya existentes (PRD, épicas/historias, UX spec, arquitectura) y los usa como base para que el módulo WDS (Freya) genere propuestas visuales — escenarios UX, page-specs y prototipos renderizados con siesa-ui-kit — ayudando a los diseñadores.
+web_bundle: true
+---
+
+# WDS Visual Proposals — Del Planning a las Propuestas Visuales
+
+**Goal:** Tomar los artefactos de planning ya hechos del proyecto (PRD, épicas/historias, `ux-design-specification.md`, arquitectura) como **base**, traducirlos a la fundación estratégica que el módulo **WDS** necesita, y dirigir a **Freya** para producir **propuestas visuales**: escenarios UX + page-specs (formato WDS) **y** prototipos renderizados con los componentes reales de **siesa-ui-kit**. El resultado ayuda al equipo de diseño a iterar sobre algo tangible en vez de partir de cero.
+
+**Your Role:** In addition to your name, communication_style, and persona, you are also a **UX Bridge Engineer + Design Facilitator** collaborating with the **Design Team and Product Owners**. This is a partnership, not a client-vendor relationship. You bring expertise in translating product requirements into WDS-compatible design foundations and in driving the WDS/Freya design loop with siesa-ui-kit fidelity, while the user brings product knowledge and design judgment. Work together as equals.
+
+---
+
+## RELACIÓN CON EL MÓDULO WDS
+
+Este workflow es un **adaptador + director**. NO reimplementa el diseño: reutiliza el módulo WDS instalado en `{project-root}/_siesa-agents/wds/`.
+
+- **Puente (Phases 0–2 de WDS):** sintetiza los prerequisitos que Freya exige —`A-Product-Brief/product-brief.md`, `B-Trigger-Map/trigger-map.md`, outline de escenarios y `_progress/wds-project-outline.yaml`— a partir de los artefactos de planning de SIESA. Sin este puente, Freya no puede empezar.
+- **Kit Warm-up (step-02b, anti-alucinación):** antes de diseñar, instala/usa el paquete **real** de siesa-ui-kit, lo compila/renderiza y produce `kit-grounding.md` (nombres/props reales). Es la fuente de verdad que consumen las specs y los prototipos.
+- **Diseño (Phases 3–4 de WDS):** usa los scripts scaffold de WDS (`_siesa-agents/wds/scripts/*.js`) para crear escenarios y page-specs, y el design loop de Freya (`_siesa-agents/wds/data/agent-guides/freya/`) para renderizar y verificar prototipos.
+- **siesa-ui-kit primero:** todo objeto UI se mapea contra `kit-grounding.md` (verdad del paquete) y el catálogo `https://siesa-ui-kit.pages.dev/llms.txt`. Si discrepan, **gana el grounding**. Texto de UI siempre en **español**.
+
+---
+
+## WORKFLOW ARCHITECTURE
+
+This uses **step-file architecture** for disciplined execution:
+
+### Core Principles
+
+- **Micro-file Design**: Each step is a self contained instruction file that is part of an overall workflow that must be followed exactly
+- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until told to do so
+- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
+- **State Tracking**: Document progress in the WDS project outline (`_progress/wds-project-outline.yaml`) and design log; use `stepsCompleted` array in any output document frontmatter
+- **Append-Only Building**: Build documents by appending content as directed; never overwrite existing WDS artifacts blindly
+
+### Step Processing Rules
+
+1. **READ COMPLETELY**: Always read the entire step file before taking any action
+2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
+3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
+4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
+5. **SAVE STATE**: Update the project outline / design log before loading next step
+6. **LOAD NEXT**: When directed, load, read entire file, then execute the next step file
+
+### Critical Rules (NO EXCEPTIONS)
+
+- 🛑 **NEVER** load multiple step files simultaneously
+- 📖 **ALWAYS** read entire step file before execution
+- 🚫 **NEVER** skip steps or optimize the sequence
+- 💾 **ALWAYS** update state when writing the final output for a specific step
+- 🎯 **ALWAYS** follow the exact instructions in the step file
+- ⏸️ **ALWAYS** halt at menus and wait for user input
+- 📋 **NEVER** create mental todo lists from future steps
+- 🧩 **NEVER** write raw WDS markdown by hand — use the scaffold scripts (`wds-init-scenario.js`, `wds-init-page.js`, `wds-add-object.js`, `wds-add-spacing.js`, `wds-nav.js`) and validate with `wds-validate.js`
+- 🇪🇸 **ALWAYS** write user-facing UI text in **Spanish**; **ALWAYS** check siesa-ui-kit FIRST before proposing any custom component
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+---
+
+## INITIALIZATION SEQUENCE
+
+### 1. Configuration Loading
+
+Load and read full config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
+
+- `project_name`, `output_folder`, `user_name`, `communication_language`, `document_output_language`
+- `planning_artifacts`, `implementation_artifacts`, `project_knowledge`
+
+Then load `{project-root}/_siesa-agents/wds/config.yaml` and resolve:
+
+- `design_artifacts` (base path where WDS artifacts live — scripts write `C-UX-Scenarios/` under it)
+- `output_folder` (WDS `_bmad-output` base), `communication_language`, `document_output_language`
+
+If the two configs disagree on a value, **WDS `config.yaml` wins** for any WDS artifact path; otherwise use `_bmad/bmm/config.yaml`.
+
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### 2. First Step EXECUTION
+
+Load, read the full file and then execute `{project-root}/_siesa-agents/bmm/workflows/3-solutioning/wds-visual-proposals/steps/step-01-init.md` to begin the workflow.

package/siesa-agents/bmm/workflows/3-solutioning/wds-visual-proposals/workflow_ext.md

@@ -0,0 +1,195 @@
+# MANDATORY RULES: WDS-VISUAL-PROPOSALS WORKFLOW
+
+These Siesa-specific rules are injected into memory BEFORE the base workflow runs and remain active throughout. They are non-negotiable.
+
+---
+
+## 1. MANDATORY RULE — PHASE BRANCH CREATION AT WORKFLOW START
+
+**TRIGGER:** Immediately when the user initiates this workflow (e.g., `/wds-visual-proposals`).
+
+**CRITICAL INSTRUCTION:** Before executing any workflow step, you MUST invoke the `generate-commits-by-phase` skill to create the **Phase 2 (planning)** branch. Visual proposals are a planning-phase activity.
+
+### EXECUTION STEPS (PERFORM THESE ACTIONS NOW, BEFORE ANYTHING ELSE)
+
+**STEP 1: INVOKE THE SKILL — CREATE PHASE 2 BRANCH**
+
+```bash
+node _siesa-agents/scripts/phases/phase2.js
+```
+
+- If the `planning` branch already exists, the script will report it — continue normally.
+- If it is created successfully, confirm to the user and proceed.
+
+**STEP 2: CONFIRM AND CONTINUE**
+
+Output to the user:
+> `✅ Rama Phase 2 (planning) lista. Procediendo con la generación de propuestas visuales WDS...`
+
+**DO NOT proceed to the workflow steps until this rule is fully executed.**
+
+---
+
+## 2. CONTEXT AND STANDARDS SETUP
+
+Establish the following context paths for use throughout all steps:
+
+- `company_standards_path` = `{project-root}/_siesa-agents/bmm/workflows/3-solutioning/create-architecture/data/company-standards`
+- `wds_module_path` = `{project-root}/_siesa-agents/wds`
+- `wds_scripts_path` = `{wds_module_path}/scripts`
+- `siesa_uikit_catalog_url` = `https://siesa-ui-kit.pages.dev/llms.txt`
+- `base_ux_spec` = `{project-root}/_siesa-agents/resources/ux-ui/ux-design-specification.md`
+- `frontend_base_repo` = `https://github.com/SiesaTeams/BaseFrontend`
+- `frontend_dir` = `{design_artifacts}/_kit-playground` (el harness del frontend ES un clon de `frontend_base_repo`)
+
+### Company Standards Integration
+
+🔴 **CRITICAL**: Load these before producing any spec or prototype:
+- `{company_standards_path}/frontend-standards.md` — **siesa-ui-kit** rules + component strategy
+- `{company_standards_path}/technical-preferences-ux.md` — UX/UI preferences and patterns
+
+| Priority | Rule | Why Critical |
+|----------|------|--------------|
+| 🔴 P0 | **siesa-ui-kit obligatorio** | Check siesa-ui-kit (via `{siesa_uikit_catalog_url}`) before proposing ANY component |
+| 🔴 P0 | **UI text in Spanish** | All user-facing text MUST be in Spanish |
+| 🔴 P0 | **Vite over Next.js** | Any rendered prototype harness uses Vite + React + Tailwind v4, never Next.js |
+| 🔴 P0 | **Fidelidad al diseño de referencia** | Si el usuario entregó un diseño a seguir (mockup HTML, imagen, Figma), **renderízalo** y replícalo; su look manda sobre los defaults del kit y se **verifica lado a lado** (ver §3C) |
+| 🟡 P1 | Design tokens | Use the tokens defined in `{base_ux_spec}` and the project `ux-design-specification.md` |
+
+---
+
+## 3. SIESA-UI-KIT MANDATORY CHECK (applies to step-04 and step-05)
+
+**BEFORE mapping any object to a component or rendering any prototype, you MUST:**
+
+1. Fetch the live catalog from `{siesa_uikit_catalog_url}` (authoritative source of available components).
+2. Resolve the **actual installed package name** by reading the target frontend app's `package.json` — do NOT assume `@siesa/ui-kit`. `llms.txt` does not declare the npm name.
+3. Follow the Component Decision Protocol:
+
+```
+Component needed  →  ¿Está en siesa-ui-kit (per llms.txt / kit-grounding.md)?
+   ├── YES → USA el componente siesa-ui-kit tal cual
+   └── NO  → busca en shadcn (registro MCP de shadcn)
+              ├── existe     → usa el componente shadcn
+              └── no existe  → el agente lo CREA (compone primitivos + tokens de marca)
+   (AUTOMÁTICO — no preguntar al usuario; registrar la decisión kit/shadcn/custom en el design log.)
+```
+
+4. Prefer siesa-ui-kit **view-level** components when they fit the page (e.g. `LoginView`, `SignUpView`, `RecoverPasswordView`, `Dashboard`, `LayoutBase`, `ProductsView`, `MasterCrud`) — they raise fidelity and reduce effort.
+
+### UI Text Language Rule
+
+🔴 **MANDATORY**: All user-facing text MUST be in Spanish.
+- ✅ "Guardar", "Cancelar", "Enviar", "Nombre de usuario", "Datos guardados correctamente"
+- ❌ "Save", "Cancel", mixed "Save cambios"
+
+> **Note on the bilingual scaffold:** the WDS scripts (`wds-add-object.js`) expose `--se` (Swedish) and `--en` (English) fields. For Siesa, put the **Spanish** UI string in `--se` (primary product language) and the English reference in `--en`. Spanish is the language the prototype renders.
+
+---
+
+## 3A. MANDATORY RULE — CLONA Y TRABAJA BAJO BaseFrontend
+
+**TRIGGER:** En step-02b (Kit Warm-up), al montar el harness del frontend, y durante todo step-05.
+
+🔴 **CRITICAL:** El frontend NO se scaffoldea a mano. Se **clona el repositorio base oficial** `{frontend_base_repo}` en `{frontend_dir}` y se trabaja **dentro de él**. Ese repo ya trae Vite 6 + React 19 + TS + Tailwind v4 + `siesa-ui-kit@^1.0.109` con TODOS los peers instalados, TanStack Router (file-based), Clean Architecture por módulos, capa mock en memoria y un shell (`LayoutBase`) ya cableado. No reinventar nada de eso.
+
+```bash
+git clone --depth 1 {frontend_base_repo} {frontend_dir}
+rm -rf {frontend_dir}/.git   # el clon vive DENTRO del repo SIESA; no anidar .git
+cd {frontend_dir} && npm install
+```
+
+- **`.git` fuera:** tras clonar, borra `{frontend_dir}/.git` para que los fuentes queden versionados por el repo SIESA padre (no como submódulo). `node_modules/` ya está en el `.gitignore` del propio base.
+- **Ejecución:** el prototipo se ve con `npm run dev` (modo standalone, **puerto 3010**, todos los permisos activos, datos en memoria mock). NUNCA Next.js.
+- **Convenciones del base (respétalas, no las reescribas):**
+  - **Shell = `_app.tsx`** → usa `LayoutBase` de siesa-ui-kit con `navigationItems` de `src/config/navigation.tsx` + `<Outlet/>`. Este ES el shell persistente; no hay que construir Navbar/rail a mano.
+  - **Un módulo por dominio** en `src/modules/<dominio>/` con las 4 capas `domain / application / infrastructure / presentation` (copia el patrón de los módulos de ejemplo `agentes` y `colaboradores`, que luego se reemplazan).
+  - **Listado + CRUD** → componente `MasterCrud` dirigido por un array `fields` (accessorKey/header/type/config) + un `service` que implementa `CrudService<T>` + schema Zod. No coloques objetos a mano cuando `MasterCrud` cubre la pantalla.
+  - **Estado compartido = capa mock** (`src/lib/mock/*.mock.ts`): BD en memoria por entidad. Los flujos conectados entre módulos (eliminar padre → hijos huérfanos, asociar/reasignar reflejado en ambos, enlaces cruzados) se implementan sobre estos stores.
+  - **Rutas** = TanStack Router file-based: una ruta por módulo en `src/routes/_app/<modulo>.tsx` + su ítem en `config/navigation.tsx`. `routeTree.gen.ts` se autogenera (no editar).
+
+---
+
+## 3B. MANDATORY RULE — KIT WARM-UP GROUNDING BEFORE DESIGN
+
+**TRIGGER:** After the strategic bridge (step-02) and BEFORE generating scenarios/specs (step-03+).
+
+🔴 **CRITICAL:** El agente NO debe diseñar contra el catálogo `llms.txt` solo. Debe ejecutar **step-02b (Kit Warm-up)**: clonar BaseFrontend (§3A), instalarlo, verificar con `npm run build`/render que el paquete **real** de siesa-ui-kit compila, y producir `{frontend_dir}/kit-grounding.md` con nombres y props **reales**.
+
+- **Source of truth:** cuando `kit-grounding.md` y el catálogo discrepan, **gana el grounding** (usa el export real: p. ej. `ContentLayout` no `LayoutContent`; no inventes `Dashboard`/`StatCard` → compón con `Card`). BaseFrontend ya usa `LayoutBase` y `MasterCrud` con contratos reales — documéntalos en el grounding.
+- **No silent skip:** si no se puede clonar/instalar (sin red/registro), `kit-grounding.md` se escribe igual desde el catálogo pero marcado `⚠️ NO VERIFICADO EN RUNTIME`.
+- **Spec Sync (feedback obligatorio):** todo hallazgo del warm-up que invalide un supuesto del `ux-design-specification.md` (nombre/contrato inexistente) debe reflejarse en una sección "Kit Grounding — Spec Sync" del spec en el mismo ciclo.
+
+🔴 **ENTREGABLE = LA APP CLONADA (BaseFrontend) INTEGRADA, NO pantallas sueltas.** Step-05 trabaja **dentro de `{frontend_dir}`**: reemplaza los módulos de ejemplo por **un módulo por dominio** del alcance, siguiendo las convenciones del base (shell `LayoutBase`, `MasterCrud` data-driven, stores mock compartidos, rutas + nav). Resultado: una app navegable de punta a punta con `npm run dev`, **estado compartido** entre módulos y **flujos conectados** (eliminar padre → hijos huérfanos; asociar/reasignar refleja en ambos; enlaces cruzados navegables). Las épicas de relación se integran DENTRO de los módulos que relacionan; la épica de shell YA es el shell del base. **Prohibido** entregar un prototipo aislado por épica, y **prohibido** HTML+CSS que se auto-rotule como si usara el kit (`<div class="rail" title="NavigationRail">`, `/* siesa-ui-kit Button */`) — esa es la alucinación que este flujo elimina. Todo con componentes reales, `npm run build` exit 0. **Entregable estático = la app compilada en UN HTML autocontenido (`propuesta-app.html`, vía vite-plugin-singlefile + hash routing), NO una galería de screenshots** (los screenshots son solo verificación interna del agente). Gotchas obligatorios (el base ya resuelve varios): `ContentLayout` = master-detail (no header); `GenericEntityModal`/`ContactManager` requieren `QueryClientProvider` (el base ya lo provee en `config/query-client.ts`); `LookupField` requiere `fetcher` mock.
+
+---
+
+## 3C. MANDATORY RULE — REFERENCE DESIGN FIDELITY (cuando el usuario entrega un diseño a seguir)
+
+**TRIGGER:** El usuario aportó, en cualquier punto del flujo, un **diseño de referencia** que la propuesta debe replicar: un mockup HTML (incluidos los HTML autocontenidos/"bundled" que se auto-desempaquetan), una imagen (PNG/JPG), un PDF de pantallas, o un enlace de Figma. step-01 lo detecta e ingesta; step-05 lo replica; **esta regla aplica durante todo el flujo.**
+
+🔴 **Regla de oro: NO se diseña contra una descripción textual del diseño — se diseña contra el diseño RENDERIZADO.** El fallo que esta regla previene es construir "de memoria"/desde texto y declarar fidelidad sin haber visto nunca el diseño real.
+
+### A. Renderizar el diseño de referencia a imágenes (obligatorio antes de diseñar)
+
+Convierte el diseño a screenshots que sean la **verdad visual** (guárdalos en `{design_artifacts}/_design-ref/`):
+
+- **Imagen/PDF** → úsala directamente (o exporta cada página del PDF a PNG).
+- **HTML autocontenido/bundled** (abre por sí solo, p. ej. un export con assets en base64) → renderízalo en **Chrome headless**:
+  `chrome --headless=new --disable-gpu --hide-scrollbars --window-size=1600,1050 --virtual-time-budget=8000 --screenshot=<out.png> "file:///<ruta-del-html>"`.
+  Dale tiempo (`--virtual-time-budget`) si el HTML se desempaqueta/renderiza vía JS.
+- **HTML interactivo / multi-pantalla** (la pantalla objetivo se alcanza haciendo clic, p. ej. "Crear/Editar") → **NO basta la pantalla inicial**: conduce el Chrome instalado con `puppeteer-core` (`npm i puppeteer-core`, `executablePath` = Chrome local), navega/haz clic hacia cada estado (lista, crear, editar, diálogos) y captura **un screenshot por pantalla**.
+- **Figma/URL** → exporta los frames a PNG (o pide al usuario los PNG exportados). Si no hay acceso, avísalo y trabaja con lo que haya.
+
+Registra las referencias en `_progress/wds-project-outline.yaml` (`reference_design: [rutas]`) y en el design log.
+
+### B. Extraer sus tokens (gotcha que deja todo sin estilo)
+
+Si el diseño define tokens como custom properties CSS (`:root { --surface-card: …; --space-4: …; --radius-xl: …; --text-sm: … }`), **cópialos al harness** (`{kit_playground}/src/styles/tokens.css`, importado desde `src/index.css`) **antes** de escribir componentes custom. Los componentes que referencian `var(--…)` sin esas definiciones renderizan **colapsados/sin estilo** (flex/gap 0, sin fondos ni bordes) — `siesa-ui-kit/styles.css` define SUS tokens, no los del diseño de referencia.
+
+### C. Precedencia de fidelidad (el diseño manda sobre los defaults del kit)
+
+siesa-ui-kit primero **sigue vigente para primitivos** (`Input`, `Textarea`, `Select`, `Switch`, `Badge`, `Button`, `LookupField`, `Table`). Pero los **componentes de vista** (`MasterCrud`, `LayoutBase`, etc.) imponen un look que **puede no parecerse en nada** al diseño de referencia (p. ej. el diseño usa barra superior sin rail y una tabla limpia con pills de color, no el toolbar por defecto de `MasterCrud`). Cuando el default del kit diverge del diseño: **compón la presentación a medida para igualar el diseño**, importando primitivos del kit donde encajen. La fidelidad al diseño entregado por el usuario tiene prioridad sobre "usar el componente de vista del kit". Registra kit/custom en el design log.
+
+### D. Verificación lado a lado (antes de declarar "listo")
+
+Para CADA página del alcance: renderiza tu build y ponlo **al lado del screenshot de referencia**; solo pasa si coinciden **layout, colores, espaciado, tipografía y componentes**. 🚫 **PROHIBIDO declarar fidelidad** contra tu propio modelo mental, contra una descripción textual, o contra la pantalla inicial cuando la referencia tiene más pantallas. Si no coincide, corrige e itera antes de presentar.
+
+---
+
+## 4. PATH RECONCILIATION (WDS docs are internally inconsistent)
+
+WDS docs disagree on output paths. Resolve at runtime in this order:
+
+1. Read `{wds_module_path}/config.yaml`. Use its `design_artifacts` value as the **base output path** for all WDS scaffold scripts (`--output <design_artifacts>`). Scripts create `C-UX-Scenarios/` under it.
+2. Place the bridge artifacts as Freya's activation expects them, relative to that base:
+   - `{design_artifacts}/A-Product-Brief/product-brief.md`
+   - `{design_artifacts}/B-Trigger-Map/trigger-map.md` (+ personas)
+   - `{design_artifacts}/C-UX-Scenarios/` (scenarios + page specs)
+   - `{design_artifacts}/_progress/wds-project-outline.yaml` and `_progress/00-design-log.md`
+3. NEVER hardcode `_bmad-output` vs `design-artifacts`. Always derive from `config.yaml`.
+
+---
+
+## 5. MANDATORY RULE — PHASE COMMIT AT WORKFLOW END
+
+**TRIGGER:** Immediately after the visual proposals (specs + prototype + index) are generated and saved (end of step-06).
+
+**STEP 1: INSPECT CHANGES**
+1. `git status --short`
+2. `git diff --stat`
+
+**STEP 2: GENERATE COMMIT MESSAGE**
+Format: `[Phase 2 - Planning] <brief description>` — e.g. `[Phase 2 - Planning] add WDS visual proposals for <project name>`. Write it in `{communication_language}`.
+
+**STEP 3: INVOKE THE SKILL — COMMIT PHASE 2 CHANGES**
+
+```bash
+node _siesa-agents/scripts/phases/phase2.js --commit "<generated commit message>"
+```
+
+**STEP 4: CONFIRM COMPLETION**
+Output to the user:
+> `✅ Propuestas visuales WDS committeadas en la rama Phase 2 (planning).`
+
+**This is the LAST action of the workflow. Do not execute any further steps after this commit.**

package/siesa-agents/sa/sa-init-devops/scripts/sa-init-devops.js

@@ -1,9 +1,9 @@
 #!/usr/bin/env node
-// sa-init-devops.js — Bootstrap the DevOps workspace and skills in Siesa-Agents.
+// sa-init-devops.js — Bootstrap the DevOps workspace and commands in Siesa-Agents.
 //
 // In one invocation the script:
-//   1. Clones (or pulls) architecture-sa-devops into `_siesa-agents/devops/`.
-//   2. Detects conflicts: for each upstream `.claude/skills/sa-*/SKILL.md` and
+//   1. Clones (or pulls) business-shared-deploy into `_siesa-agents/devops/`.
+//   2. Detects conflicts: for each upstream `.claude/commands/*.md` and
 //      `.github/workflows/*.yml`, compares to the local copy in Siesa-Agents. If any local
 //      file differs from upstream and no policy flag was passed, aborts with `status:
 //      "conflicts"` and lists the conflicting items so the caller can ask the user how to
@@ -19,7 +19,7 @@
 //                              entirely new in upstream.
 //   --keep-local=<csv>         Keep these specific files (comma-separated names) local;
 //                              overwrite the rest. Example:
-//                              --keep-local=sa-aplicar,infra-pipeline-qa.yml
+//                              --keep-local=flow-aplicar.md,infra-pipeline-qa.yml
 //
 // Idempotency: between runs the clone's `.claude/` and `.github/` directories are gone from
 // the working tree but still tracked in upstream HEAD. The script restores those paths
@@ -46,9 +46,7 @@ const fs = require('fs')
 const path = require('path')
 const { spawnSync } = require('child_process')
 
-// TODO(siesa-admin): change to https://github.com/SiesaTeams/architecture-sa-devops.git
-// once the repo is transferred to the SiesaTeams organization.
-const REMOTE_URL = 'https://github.com/ssancheze912/architecture-sa-devops.git'
+const REMOTE_URL = 'https://github.com/SiesaTeams/business-shared-deploy.git'
 const REMOTE_NAME = 'origin'
 const DEFAULT_BRANCH = 'main'
 
@@ -171,56 +169,54 @@ function decideAction(name, upstreamPath, localPaths, policy) {
   return 'conflict'
 }
 
-// MOVE `<sourceDir>/.claude/skills/sa-*/SKILL.md` into Siesa-Agents `.claude/skills/sa-*/`
-// (and `claude/skills/sa-*/`) according to the policy. Records conflicts in
-// status.skill_conflicts; the caller checks that before any mutation happens.
-function planAndApplySkills(sourceDir, projectRoot, status, policy, dryRun) {
-  const srcSkillsDir = path.join(sourceDir, '.claude', 'skills')
-  status.skills_created = []
-  status.skills_overwritten = []
-  status.skills_kept_local = []
-  status.skills_unchanged = []
-  status.skill_conflicts = []
-
-  if (!fs.existsSync(srcSkillsDir)) {
-    status.skills_source_missing = true
+// MOVE `<sourceDir>/.claude/commands/*.md` into Siesa-Agents `.claude/commands/` (and
+// `claude/commands/`) according to the policy. Records conflicts in status.command_conflicts;
+// the caller checks that before any mutation happens.
+function planAndApplyCommands(sourceDir, projectRoot, status, policy, dryRun) {
+  const srcCommandsDir = path.join(sourceDir, '.claude', 'commands')
+  status.commands_created = []
+  status.commands_overwritten = []
+  status.commands_kept_local = []
+  status.commands_unchanged = []
+  status.command_conflicts = []
+
+  if (!fs.existsSync(srcCommandsDir)) {
+    status.commands_source_missing = true
     return
   }
 
-  const dstA = path.join(projectRoot, '.claude', 'skills')
-  const dstB = path.join(projectRoot, 'claude', 'skills')
+  const dstA = path.join(projectRoot, '.claude', 'commands')
+  const dstB = path.join(projectRoot, 'claude', 'commands')
 
-  for (const entry of fs.readdirSync(srcSkillsDir, { withFileTypes: true })) {
-    if (!entry.isDirectory()) continue
-    if (!entry.name.startsWith('sa-')) continue
-    if (entry.name === 'sa-init-devops') continue   // never overwrite the bootstrap itself
-    const srcSkill = path.join(srcSkillsDir, entry.name, 'SKILL.md')
-    if (!fs.existsSync(srcSkill)) continue
+  for (const entry of fs.readdirSync(srcCommandsDir, { withFileTypes: true })) {
+    if (!entry.isFile()) continue
+    if (!entry.name.endsWith('.md')) continue
 
-    const dstSkillA = path.join(dstA, entry.name, 'SKILL.md')
-    const dstSkillB = path.join(dstB, entry.name, 'SKILL.md')
+    const srcCommand = path.join(srcCommandsDir, entry.name)
+    const dstCommandA = path.join(dstA, entry.name)
+    const dstCommandB = path.join(dstB, entry.name)
 
-    const action = decideAction(entry.name, srcSkill, [dstSkillA, dstSkillB], policy)
+    const action = decideAction(entry.name, srcCommand, [dstCommandA, dstCommandB], policy)
 
     if (action === 'conflict') {
-      status.skill_conflicts.push(entry.name)
+      status.command_conflicts.push(entry.name)
       continue
     }
     if (action === 'identical') {
-      status.skills_unchanged.push(entry.name)
+      status.commands_unchanged.push(entry.name)
       continue
     }
     if (dryRun) continue
 
     if (action === 'create' || action === 'overwrite') {
-      fs.mkdirSync(path.dirname(dstSkillA), { recursive: true })
-      fs.mkdirSync(path.dirname(dstSkillB), { recursive: true })
-      fs.copyFileSync(srcSkill, dstSkillA)
-      fs.copyFileSync(srcSkill, dstSkillB)
-      if (action === 'create') status.skills_created.push(entry.name)
-      else status.skills_overwritten.push(entry.name)
+      fs.mkdirSync(dstA, { recursive: true })
+      fs.mkdirSync(dstB, { recursive: true })
+      fs.copyFileSync(srcCommand, dstCommandA)
+      fs.copyFileSync(srcCommand, dstCommandB)
+      if (action === 'create') status.commands_created.push(entry.name)
+      else status.commands_overwritten.push(entry.name)
     } else if (action === 'keep-local') {
-      status.skills_kept_local.push(entry.name)
+      status.commands_kept_local.push(entry.name)
     }
   }
 }
@@ -356,11 +352,11 @@ function runCheck(projectRoot) {
   // Dry-run conflict detection so callers can preview before running default mode.
   restoreClonePaths(sourceDir)
   const policy = { takeUpstream: false, keepLocalAll: false, keepLocalList: null }
-  planAndApplySkills(sourceDir, projectRoot, state, policy, true)
+  planAndApplyCommands(sourceDir, projectRoot, state, policy, true)
   planAndApplyWorkflows(sourceDir, projectRoot, state, policy, true)
 
   state.status = 'already-cloned'
-  const conflictCount = state.skill_conflicts.length + state.workflow_conflicts.length
+  const conflictCount = state.command_conflicts.length + state.workflow_conflicts.length
   state.message = `${sourceDir} is a clean clone of ${REMOTE_URL}. ${conflictCount} conflict(s) would be raised by a default run.`
   emit(state)
   return 0
@@ -475,30 +471,30 @@ function runClone(projectRoot, mirrorOnly, args) {
 
 function finalizeMoveAndMirror(sourceDir, projectRoot, mirrorDir, status, policy, terminalStatus) {
   // Phase A: dry-run to compute the action plan and conflicts.
-  planAndApplySkills(sourceDir, projectRoot, status, policy, true)
+  planAndApplyCommands(sourceDir, projectRoot, status, policy, true)
   planAndApplyWorkflows(sourceDir, projectRoot, status, policy, true)
 
-  const totalConflicts = status.skill_conflicts.length + status.workflow_conflicts.length
+  const totalConflicts = status.command_conflicts.length + status.workflow_conflicts.length
   if (totalConflicts > 0) {
     // Abort without mutating. The caller (Claude/SKILL.md) asks the user and re-runs with
     // a policy flag.
     status.status = 'conflicts'
-    status.message = `Detected ${status.skill_conflicts.length} skill conflict(s) and ${status.workflow_conflicts.length} workflow conflict(s). Re-run with one of: --take-upstream (overwrite all), --keep-local (keep all local versions), or --keep-local=<csv> (keep specific ones).`
+    status.message = `Detected ${status.command_conflicts.length} command conflict(s) and ${status.workflow_conflicts.length} workflow conflict(s). Re-run with one of: --take-upstream (overwrite all), --keep-local (keep all local versions), or --keep-local=<csv> (keep specific ones).`
     emit(status)
     return 4
   }
 
   // Phase B: real apply (no conflicts left to resolve).
-  planAndApplySkills(sourceDir, projectRoot, status, policy, false)
+  planAndApplyCommands(sourceDir, projectRoot, status, policy, false)
   planAndApplyWorkflows(sourceDir, projectRoot, status, policy, false)
   cleanCloneDirs(sourceDir)
   refreshMirror(sourceDir, mirrorDir, status)
 
   status.status = terminalStatus
-  const created = status.skills_created.length + status.workflows_created.length
-  const over = status.skills_overwritten.length + status.workflows_overwritten.length
-  const kept = status.skills_kept_local.length + status.workflows_kept_local.length
-  const unch = status.skills_unchanged.length + status.workflows_unchanged.length
+  const created = status.commands_created.length + status.workflows_created.length
+  const over = status.commands_overwritten.length + status.workflows_overwritten.length
+  const kept = status.commands_kept_local.length + status.workflows_kept_local.length
+  const unch = status.commands_unchanged.length + status.workflows_unchanged.length
   status.message = `${terminalStatus === 'cloned' ? 'Cloned' : (terminalStatus === 'updated' ? 'Pulled' : 'No upstream change')}. Created ${created}, overwrote ${over}, kept local ${kept}, unchanged ${unch}. Mirror refreshed.`
   emit(status)
   return 0

package/siesa-agents/wds/config.yaml

@@ -0,0 +1,20 @@
+# WDS Module Configuration
+# Generated by BMAD installer
+# Version: 6.9.0
+# Date: 2026-06-25T17:13:35.737Z
+
+project_knowledge: "{project-root}/docs"
+project_type: digital_product
+design_artifacts: "{project-root}/design-artifacts"
+design_system_mode: none
+methodology_version: wds-v6
+product_languages:
+  - en
+design_experience: intermediate
+
+# Core Configuration Values
+user_name: Ssancheze
+project_name: Dev
+communication_language: Spanish
+document_output_language: English
+output_folder: "{project-root}/_bmad-output"

package/siesa-agents/wds/data/agent-contracts.md

@@ -0,0 +1,72 @@
+# WDS Agent Contracts
+
+Defines what each agent owns, what they explicitly do not own, and how they hand off to each other.
+All agents load this file at activation. These rules are non-negotiable.
+
+---
+
+## Domain Boundaries
+
+| Agent | Owns | Does NOT own |
+|-------|------|--------------|
+| **Saga** | Phases 0–2: Alignment, Product Brief, Trigger Mapping | Any design work. Any code. Scenarios (Phase 3+). |
+| **Freya** | Phases 3–4: UX Scenarios, UX Design. Phases 6–7: Asset Generation, Design System. | Discovery (Phases 1–2). Any code. PRDs. |
+| **Mimir** | Phase 5: Tech Audit, PRD, Build. Phase 8: Product Evolution. | Discovery. Design. Writing specs without a Work Order. |
+
+**If a user asks an agent to do work outside its domain:** name the right agent and offer to hand off. Never attempt the work yourself.
+
+---
+
+## Prerequisites
+
+Each agent requires the following before starting core work:
+
+| Agent | Required | Blocks |
+|-------|----------|--------|
+| Saga | Nothing | — |
+| Freya | `A-Product-Brief/product-brief.md` + `B-Trigger-Map/00-trigger-map.md` | Cannot design without strategic foundation |
+| Mimir | At least one Work Order from Freya | Cannot build without a WO. Cannot PRD without a WO. |
+| Mimir (existing codebase) | `E-Development/000-tech-audit.md` | Cannot PRD without knowing the codebase |
+
+---
+
+## Handoff Rules
+
+**Saga → Freya**
+Trigger: Product Brief and Trigger Map are complete and aligned.
+Action: Saga runs `/wrap freya`. Freya picks up with `/freya progress/freya.md`.
+Never: Saga does not write scenarios or design anything before handing off.
+
+**Freya → Mimir**
+Trigger: Work Order written, page spec complete, ready for implementation.
+Action: Freya runs `/wrap mimir` or `/handoff mimir`. Mimir picks up the Work Order.
+Never: Freya does not write code. Freya does not write PRDs.
+
+**Mimir → Freya**
+Trigger: Implementation complete, browser-verified. Or: blocked on design decision.
+Action: Mimir runs `/handoff freya` with the specific question or completion note.
+Never: Mimir does not modify specs or Work Orders. He implements what they say.
+
+---
+
+## Quality Rules (all agents)
+
+- **One task at a time.** Complete and verify before moving on.
+- **No plausible-looking wrong output.** If you cannot follow the template exactly, stop and say so. Wrong-but-plausible output breaks every downstream phase.
+- **Read the template before writing.** Every artifact has a template. Load it, follow it.
+- **Decisions are documented.** Any deviation from a template or unexpected choice goes in the design log.
+
+---
+
+## Out-of-Scope (explicit)
+
+Things no WDS agent does, ever:
+
+- Produce output in a custom format when a WDS template exists
+- Write to `progress/` without going through the memory tool
+- Commit without a meaningful message (conventional commits required)
+- Force push, skip hooks, or bypass git safety
+- Start a new phase without the prerequisite documents
+- Write code without a PRD (Mimir only)
+- Mark a requirement done without browser verification (Mimir only)
+- Design without a Trigger Map (Freya only)