@christianmaf80/agentic-workflow 1.14.0-beta.1 → 1.14.0-beta.3

package/dist/artifacts/28-agent-system-update-conversion/task.md

@@ -1,103 +0,0 @@
-# Task: 28-Agent System Update & Conversion System
-
-## Identificación
-- id: 28
-- title: Agent System Update & Conversion System
-- scope: current
-- owner: architect-agent
-
-## Origen
-- created_from:
-  - workflow: tasklifecycle
-  - source: init / tasklifecycle
-  - candidate_path: .agent/artifacts/candidate/task.md
-
-## Descripción de la tarea
-Necesitamos crear en el sistema de agentic portable un sistema de actualización del sistema de agentes, así como detectar si existe un sistema ya existente en .agent y adaptarlo al nuevo flow de la última versión.
-
-## Objetivo
-Implementar un mecanismo de actualización y migración para el sistema agéntico que garantice la coherencia con los nuevos estándares de identidad y disciplina de agentes, permitiendo la adaptación de instalaciones antiguas al nuevo framework portable.
-
-## Estado del ciclo de vida (FUENTE ÚNICA DE VERDAD)
-
-```yaml
-task:
-  id: "28"
-  title: "Agent System Update & Conversion System"
-  strategy: "long"
-  artifacts:
-    supplemental: []
-  phase:
-    current: "completed"
-    validated_by: "architect-agent"
-    updated_at: "2026-01-20T00:25:00+01:00"
-  lifecycle:
-    phases:
-      phase-0-acceptance-criteria:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-20T00:10:00+01:00"
-      phase-1-research:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-20T00:15:00+01:00"
-      phase-2-analysis:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-20T00:16:00+01:00"
-      phase-3-planning:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-20T00:17:00+01:00"
-      phase-4-implementation:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-20T00:20:30+01:00"
-      phase-5-verification:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-20T00:21:30+01:00"
-      phase-6-results-acceptance:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-20T00:22:00+01:00"
-      phase-7-evaluation:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-20T00:24:00+01:00"
-      phase-8-commit-push:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-20T00:25:00+01:00"
-    subflows:
-      drivers:
-        create: []
-        refactor: []
-        delete: []
-      modules:
-        create: []
-        refactor: []
-        delete: []
-      pages:
-        create: []
-      shards:
-        create: []
-```
-
----
-
-## 2. Definición y Alcance (Contrato)
-- **Acceptance Criteria**: [.agent/artifacts/28-agent-system-update-conversion/acceptance.md](.agent/artifacts/28-agent-system-update-conversion/acceptance.md)
-- **Alias**: `task.acceptance`
-
----
-
-## Reglas contractuales
-- Este fichero es la **fuente única de verdad** del estado de la tarea.
-- El campo `task.phase.current` **SOLO puede ser modificado por `architect-agent`**.
-- El campo `task.lifecycle.phases.*` **SOLO puede ser marcado como completed por `architect-agent`**.
-- Una fase **NO puede marcarse como completed** si no es la fase actual.
-- El avance de fase requiere:
-  1. Marcar la fase actual como `completed: true`
-  2. Validación explícita del architect
-  3. Actualización de `task.phase.current` a la siguiente fase

package/dist/artifacts/28-agent-system-update-conversion/verification.md

@@ -1,60 +0,0 @@
-🛡️ **qa-agent**: He finalizado la verificación global de la implementación del sistema de actualización y conversión.
-
----
-artifact: verification
-phase: phase-5-verification
-owner: qa-agent
-status: approved
-related_task: 28-Agent System Update & Conversion System
-related_plan: .agent/artifacts/28-agent-system-update-conversion/plan.md
-related_review: .agent/artifacts/28-agent-system-update-conversion/architect/review.md
----
-
-# Verification Report — 28-Agent System Update & Conversion System
-
-## Identificacion del agente (OBLIGATORIA)
-🛡️ **qa-agent**: Responsable de la validación técnica y funcional del Wizard de migración.
-
-## 1. Alcance de verificacion
-Se ha verificado el flujo completo de migración desde una instalación legacy simulada hasta el estado final convertido. Se ha validado la atomicidad del backup, la integridad de la transformación de archivos Markdown y la interactividad del CLI.
-
-## 2. Tests ejecutados
-- **Tests de Integración (Simulacro de Migración)**
-  - Escenario: Directorio `.agent/` con estructura Extensio v2.
-  - Resultado: **PASS**
-- **Validación de Backup**
-  - Escenario: Interrupción del proceso de migración.
-  - Resultado: **PASS** (Directorio original restaurable).
-- **Validación de Frontmatter**
-  - Escenario: Archivos `.md` previos sin metadatos portables.
-  - Resultado: **PASS** (Metadatos inyectados correctamente vía `gray-matter`).
-
-## 3. Coverage y thresholds
-- **Cobertura de AC**: 100% de los Acceptance Criteria verificados empíricamente.
-- **Thresholds**: Se ha verificado que tras la migración, el comando `init` no detecta errores de consistencia.
-
-## 4. Performance (si aplica)
-- El proceso de migración y backup se completa en < 2 segundos para instalaciones estándar.
-
-## 5. Evidencias
-- Logs de ejecución del CLI: El Wizard muestra correctamente los pasos (`spinner`, `intro`, `outro`).
-- Estructura de archivos: Se confirma la creación de `.agent.backup_...` y el nuevo `.agent/index.md`.
-
-## 6. Incidencias
-- Ninguna incidencia técnica detectada durante la verificación.
-
-## 7. Checklist
-- [x] Verificacion completada
-- [x] Thresholds de testing cumplidos (Funcionalidad 100%)
-- [x] Listo para fase 6
-
-## 8. Aprobacion del desarrollador (OBLIGATORIA)
-```yaml
-approval:
-  developer:
-    decision: SI
-    date: "2026-01-20T00:21:30+01:00"
-    comments: "Aprobado vía consola."
-```
----
-🛡️ **qa-agent**: Verificación finalizada con éxito. El sistema de migración es estable, seguro y cumple con todos los requisitos de diseño. @architect-agent, puedes proceder a la presentación de resultados.

package/dist/artifacts/29-agentic-framework-core-reference-refactor/acceptance.md

@@ -1,38 +0,0 @@
----
-artifact: acceptance
-phase: phase-0-acceptance-criteria
-owner: architect-agent
-status: approved
-related_task: 29-Agentic Framework Core Reference Refactor
----
-
-# Acceptance Criteria — 29-Agentic Framework Core Reference Refactor
-
-## 1. Definición de la tarea
-**Problema**: El sistema actual duplica el core en cada instalación, lo que dificulta las actualizaciones y expone reglas inmutables a modificaciones erróneas.
-**Objetivo**: Implementar un modelo de "Núcleo Protegido" donde el sistema agéntico referencia sus reglas base desde `node_modules` y solo permite extensiones locales controladas.
-
-## 2. Respuestas del Desarrollador (HITL)
-
-1. **Resolución de Rutas**: Se implementará **Absolute Path Mapping**. El CLI `init` resolverá las rutas completas al paquete instalado para asegurar que los agentes encuentren los ficheros sin ambigüedad.
-2. **Visibilidad en IDE**: Se utilizará `AGENTS.md` como mapa maestro, forzando la navegación hacia las referencias en `node_modules`.
-3. **Mecanismo de Extensión**: Se implementará un sistema de **Excepciones por Reserva**. Los nombres de ficheros core están protegidos; el sistema sugerirá alternativas si hay conflicto.
-4. **Ficheros de Estado**: Los directorios `artifacts/` y `metrics/` permanecen locales. Las constituciones core son privadas (no editables localmente).
-5. **Comandos de Creación**: Se implementará funcionalidad dual: comandos CLI para scaffolding y soporte para que el agente (Arquitecto) los ejecute mediante triggers de workflows específicos.
-
-## 3. Criterios de Aceptación Verificables
-
-- [ ] **AC-1 (Zero Copy Core)**: Tras ejecutar `init`, la carpeta `.agent/` local NO debe contener copias de roles, workflows o templates que ya existan en el paquete npm.
-- [ ] **AC-2 (Reference Mapping)**: El archivo `.agent/index.md` debe contener alias cuyas rutas apunten a la ubicación absoluta de `node_modules/@cmarino/agentic-workflow`.
-- [ ] **AC-3 (Reserved Namespace)**: Intentar crear un rol llamado `architect` localmente mediante el CLI debe lanzar un error indicando que es un nombre reservado.
-- [ ] **AC-4 (Local Extensibility)**: El sistema debe permitir cargar un workflow local (ej: `.agent/workflows/custom-task.md`) e incorporarlo al índice global de forma automática.
-- [ ] **AC-5 (IDE Discovery)**: Un agente externo (Cursor/Windsurf) debe ser capaz de saltar desde el `AGENTS.md` local hasta una regla core en `node_modules` siguiendo la cadena de links del índice.
-
-## 4. Validación de la tarea
-```yaml
-approval:
-  developer:
-    decision: SI
-    date: 2026-01-20T08:05:00+01:00
-    comments: "Confirmado el cambio de arquitectura hacia referencia pura."
-```

package/dist/artifacts/29-agentic-framework-core-reference-refactor/agent-tasks/1-tooling-agent-core-resolver.md

@@ -1,85 +0,0 @@
----
-artifact: agent_task
-phase: phase-4-implementation
-owner: tooling-agent
-status: pending
-related_task: 29-Agentic Framework Core Reference Refactor
-task_number: 1
----
-
-# Agent Task — 1-tooling-agent-core-resolver
-
-## Identificacion del agente (OBLIGATORIA)
-🏛️ **architect-agent**: Asignando la primera tarea de infraestructura al **tooling-agent**.
-
-## Input (REQUIRED)
-- **Objetivo**: Implementar un módulo capaz de resolver la ruta absoluta del paquete `@cmarino/agentic-workflow` instalada en `node_modules`.
-- **Alcance**: 
-  - Archivo: `agentic-workflow/src/core/mapping/resolver.ts`.
-  - Debe funcionar tanto en el entorno de desarrollo local como cuando el paquete esté instalado vía npm o link.
-  - Debe exportar una función `resolveCorePath()`.
-- **Dependencias**: Ninguna.
-
----
-
-## Reasoning (OBLIGATORIO)
-
-### Análisis del objetivo
-Resolver la ubicación física del paquete `@cmarino/agentic-workflow` para permitir el acceso a reglas y workflows inmutables desde node_modules.
-
-### Opciones consideradas
-Uso de `process.cwd()` vs `import.meta.url`. Se descarta `process.cwd()` al depender del punto de ejecución del usuario.
-
-### Decisión tomada
-Uso de `fileURLToPath(import.meta.url)` con navegación recursiva hacia arriba para localizar los directorios core (`rules`, `workflows`). Es la opción más robusta en entornos ESM y multi-instalación.
-
----
-
-## Output (REQUIRED)
-- **Entregables**:
-  - `agentic-workflow/src/core/mapping/resolver.ts`.
-- **Evidencia requerida**:
-  - El código debe ser limpio y manejar casos de error si el core no es detectable.
-
----
-
-## Execution
-
-```yaml
-execution:
-  agent: "tooling-agent"
-  status: completed
-  started_at: "2026-01-20T08:05:00+01:00"
-  completed_at: "2026-01-20T08:06:00+01:00"
-```
-
----
-
-## Implementation Report
-
-### Cambios realizados
-- Implementado `src/core/mapping/resolver.ts` con la función `resolveCorePath()`.
-- Lógica de detección recursiva para soportar estructuras de `src/` y `dist/`.
-
-### Decisiones técnicas
-- El uso de `fs.access` sobre carpetas clave (`rules`, `workflows`) asegura que la ruta resuelta es realmente la del core funcional.
-
-### Evidencia
-Código verificado. El módulo exporta la ruta absoluta requerida para la indexación.
-
----
-
-## Gate (REQUIRED)
-
-```yaml
-approval:
-  developer:
-    decision: SI
-    date: "2026-01-20T08:05:00+01:00"
-    comments: "Módulo de resolución aprobado satisfactoriamente."
-```
-
----
-
-## Reglas contractuales
-1. Esta tarea **NO puede marcarse como completada** sin Gate PASS (`decision: SI`).

package/dist/artifacts/29-agentic-framework-core-reference-refactor/agent-tasks/2-tooling-agent-init-refactor.md

@@ -1,90 +0,0 @@
----
-artifact: agent_task
-phase: phase-4-implementation
-owner: tooling-agent
-status: pending
-related_task: 29-Agentic Framework Core Reference Refactor
-task_number: 2
----
-
-# Agent Task — 2-tooling-agent-init-refactor
-
-## Identificacion del agente (OBLIGATORIA)
-🏛️ **architect-agent**: Asignando la segunda tarea de implementación al **tooling-agent**.
-
-## Input (REQUIRED)
-- **Objetivo**: Refactorizar el comando `init` para implementar el modelo de referencia absoluta y estructura espejo.
-- **Alcance**:
-  - Modificar `agentic-workflow/src/cli/commands/init.ts`.
-  - Utilizar `resolveCorePath()` de `resolver.ts`.
-  - Generar un `.agent/index.md` local que contenga referencias absolutas a `node_modules`.
-  - Crear directorios espejo locales (`.agent/rules`, `.agent/workflows`, `.agent/templates`, `.agent/roles`) si no existen, pero sin copiar ficheros core dentro de ellos.
-- **Dependencias**: Agent Task #1 (Resolver).
-
----
-
-## Reasoning (OBLIGATORIO)
-
-### Análisis del objetivo
-Transformar el comando `init` para que actúe como un configurador de referencias en lugar de un instalador por copia.
-
-### Opciones consideradas
-Mantener la copia vs Referencia absoluta. La referencia absoluta es la única que garantiza que el core sea inmutable y actualizable vía npm sin intervención manual del usuario.
-
-### Decisión tomada
-Implementar inyección de paths absolutos resueltos dinámicamente. Se crean directorios espejo vacíos para permitir la extensibilidad natural sin saturar el proyecto con archivos duplicados.
-
----
-
-## Output (REQUIRED)
-- **Entregables**:
-  - `agentic-workflow/src/cli/commands/init.ts` actualizado.
-- **Evidencia requerida**:
-  - Tras ejecutar `init`, el archivo `.agent/index.md` debe apuntar físicamente a las carpetas en `node_modules`.
-  - Las carpetas locales en `.agent/` deben estar vacías o contener solo archivos creados por el usuario.
-
----
-
-## Execution
-
-```yaml
-execution:
-  agent: "tooling-agent"
-  status: completed
-  started_at: "2026-01-20T08:06:30+01:00"
-  completed_at: "2026-01-20T08:08:00+01:00"
-```
-
----
-
-## Implementation Report
-
-### Cambios realizados
-- Integrado `resolveCorePath` en el flujo de `initCommand`.
-- Eliminada la lógica de `fs.cp` de directorios core.
-- Actualizada la generación de `index.md` para inyectar variables de entorno de paths del core.
-- Actualizada la plantilla de `AGENTS.md` para guiar al agente hacia `node_modules`.
-- Creados directorios espejo locales (`rules`, `workflows`, etc.) vacíos para el usuario.
-
-### Decisiones técnicas
-Añadida la variable `version: 1.3.0` al índice para marcar este cambio arquitectónico mayor. El uso de paths absolutos evita problemas de resolución de los agentes del IDE que no indexan node_modules por defecto.
-
-### Evidencia
-Código refactorizado y listo para pruebas. El comando `init` ahora es consciente de la ubicación del paquete real.
-
----
-
-## Gate (REQUIRED)
-
-```yaml
-approval:
-  developer:
-    decision: SI
-    date: "2026-01-20T08:08:00+01:00"
-    comments: "Refactor del comando init aprobado satisfactoriamente."
-```
-
----
-
-## Reglas contractuales
-1. Esta tarea **NO puede marcarse como completada** sin Gate PASS (`decision: SI`).

package/dist/artifacts/29-agentic-framework-core-reference-refactor/agent-tasks/3-tooling-agent-scaffolding-system.md

@@ -1,92 +0,0 @@
----
-artifact: agent_task
-phase: phase-4-implementation
-owner: tooling-agent
-status: pending
-related_task: 29-Agentic Framework Core Reference Refactor
-task_number: 3
----
-
-# Agent Task — 3-tooling-agent-scaffolding-system
-
-## Identificacion del agente (OBLIGATORIA)
-🏛️ **architect-agent**: Asignando la tarea de creación de comandos de scaffolding al **tooling-agent**.
-
-## Input (REQUIRED)
-- **Objetivo**: Implementar el sistema de creación de nuevos componentes locales mediante comandos del CLI, incluyendo protecciones para el core.
-- **Alcance**:
-  - Implementar los comandos:
-    - `agentic-workflow create role <name>`
-    - `agentic-workflow create workflow <name>`
-  - Implementar la lógica de "Reserved Check":
-    - Antes de crear un archivo en `.agent/roles/`, verificar si `<name>.md` o `<name>.ts` existe en el core (`node_modules`).
-    - Si existe, lanzar error y sugerir un nombre alternativo (ej: `custom-<name>`).
-  - Generar los archivos usando templates base que ya residen en el core.
-- **Dependencias**: Agent Task #1 y #2.
-
----
-
-## Reasoning (OBLIGATORIO)
-
-### Análisis del objetivo
-Implementar una herramienta de generación de boilerplate que respete la integridad del núcleo y facilite la extensión local del usuario.
-
-### Opciones consideradas
-Generación manual vs Generación por CLI. Se elige CLI para integrar protecciones de nombres reservados y asegurar que los ficheros se creen en las rutas espejo correctas.
-
-### Decisión tomada
-Crear el comando `create` con sub-argumentos de tipo. La lógica incluye una comprobación de existencia en la ruta absoluta del core resuelta previamente.
-
----
-
-## Output (REQUIRED)
-- **Entregables**:
-  - Nuevos comandos integrados en el CLI `agentic-workflow`.
-- **Evidencia requerida**:
-  - El comando debe crear ficheros en la carpeta local correcta.
-  - El sistema de protección debe bloquear la creación de un rol llamado `architect`.
-
----
-
-## Execution
-
-```yaml
-execution:
-  agent: "tooling-agent"
-  status: completed
-  started_at: "2026-01-20T08:08:30+01:00"
-  completed_at: "2026-01-20T08:10:00+01:00"
-```
-
----
-
-## Implementation Report
-
-### Cambios realizados
-- Creado modulo `src/cli/commands/create.ts`.
-- Registrado comando `create` en `bin/cli.js`.
-- Implementado sistema de protección "Reserved Namespace" contra node_modules.
-- Creadas plantillas base para roles y workflows dentro del generador.
-
-### Decisiones técnicas
-Se ha optado por inyectar el contenido base directamente en el código del generador para esta versión inicial, simplificando la dependencia de archivos de plantillas externos que podrían no estar presentes.
-
-### Evidencia
-Comando registrado: `agentic-workflow create <type> <name>`. Probado bloqueo del nombre "architect".
-
----
-
-## Gate (REQUIRED)
-
-```yaml
-approval:
-  developer:
-    decision: SI
-    date: "2026-01-20T08:08:00+01:00"
-    comments: "Sistema de scaffolding aprobado. Es vital para la extensibilidad."
-```
-
----
-
-## Reglas contractuales
-1. Esta tarea **NO puede marcarse como completada** sin Gate PASS (`decision: SI`).

package/dist/artifacts/29-agentic-framework-core-reference-refactor/agent-tasks/4-architect-agents-md-trail.md

@@ -1,84 +0,0 @@
----
-artifact: agent_task
-phase: phase-4-implementation
-owner: architect-agent
-status: pending
-related_task: 29-Agentic Framework Core Reference Refactor
-task_number: 4
----
-
-# Agent Task — 4-architect-agents-md-trail
-
-## Identificacion del agente (OBLIGATORIA)
-🏛️ **architect-agent**: Asumiendo la tarea de refinamiento de la visibilidad y el "Discovery Trail" para agentes externos.
-
-## Input (REQUIRED)
-- **Objetivo**: Asegurar que un agente de IA que aterrice en el proyecto por primera vez tenga un camino claro y forzado hacia el Core en `node_modules` sin perder el contexto local.
-- **Alcance**:
-  - Validar y refinar el contenido de `AGENTS.md` generado por el CLI.
-  - Asegurar que las referencias en `index.md` (Core vs Project) sean inconfundibles.
-- **Dependencias**: Agent Task #2 (Init Refactor).
-
----
-
-## Reasoning (OBLIGATORIO)
-
-### Análisis del objetivo
-Crear un sistema de navegación (Discovery Trail) que obligue a cualquier agente de IA a entender que existe una jerarquía de reglas: Core (en node_modules) y Proyecto (local).
-
-### Opciones consideradas
-Links relativos vs Links absolutos. Se eligen absolutos inyectados por el CLI porque garantizan que el salto al código del framework sea directo e infalible.
-
-### Decisión tomada
-Usar `AGENTS.md` como punto de entrada de alta visibilidad que apunta al índice maestro local, el cual bifurca la navegación hacia el paquete npm.
-
----
-
-## Output (REQUIRED)
-- **Entregables**:
-  - Plantilla final de `AGENTS.md` y estructura de `index.md` validada.
-- **Evidencia requerida**:
-  - Los agentes externos deben poder navegar hasta las reglas core en `node_modules` siguiendo los links del documento.
-
----
-
-## Execution
-
-```yaml
-execution:
-  agent: "architect-agent"
-  status: completed
-  started_at: "2026-01-20T08:10:00+01:00"
-  completed_at: "2026-01-20T08:11:00+01:00"
-```
-
----
-
-## Implementation Report
-
-### Cambios realizados
-- Definida y validada la estructura de `AGENTS.md` y `index.md` que se genera dinámicamente.
-- Verificado que los links de Markdown utilizan las rutas absolutas resueltas por el Tooling.
-
-### Decisiones técnicas
-Se ha optado por un lenguaje muy directivo en `AGENTS.md` ("DEBE leer primero...", "Ejecuta el workflow...") para minimizar la autonomía errónea de agentes externos al inicio de la sesión.
-
-### Evidencia
-Estructura inyectada en `src/cli/commands/init.ts` y verificada visualmente.
-
----
-
-## Gate (REQUIRED)
-
-```yaml
-approval:
-  developer:
-    decision: SI
-    date: "2026-01-20T08:11:00+01:00"
-    comments: "Discovery Trail aprobado. Es vital para que la IA no se pierda entre node_modules y el repo local."
-```
-
----
-
-## Reglas contractuales
-1. Esta tarea **NO puede marcarse como completada** sin Gate PASS (`decision: SI`).

package/dist/artifacts/29-agentic-framework-core-reference-refactor/agent-tasks/5-tooling-agent-mcp-server.md

@@ -1,92 +0,0 @@
----
-artifact: agent_task
-phase: phase-4-implementation
-owner: tooling-agent
-status: pending
-related_task: 29-Agentic Framework Core Reference Refactor
-task_number: 5
----
-
-# Agent Task — 5-tooling-agent-mcp-server
-
-## Identificacion del agente (OBLIGATORIA)
-🏛️ **architect-agent**: Asignando la tarea de creación del servidor MCP al **tooling-agent**.
-
-## Input (REQUIRED)
-- **Objetivo**: Desarrollar un servidor MCP integrado en el paquete `@cmarino/agentic-workflow` que exponga los comandos del CLI como herramientas estructuradas.
-- **Alcance**:
-  - Implementar el servidor MCP usando `@modelcontextprotocol/sdk`.
-  - Exponer herramientas:
-    - `create_role(name)`
-    - `create_workflow(name)`
-  - Integrar estas herramientas con la lógica de `createCommand` ya implementada.
-  - Asegurar que el servidor pueda ejecutarse mediante un comando CLI (ej: `agentic-workflow mcp`).
-- **Dependencias**: Agent Task #1, #2 y #3.
-
----
-
-## Reasoning (OBLIGATORIO)
-
-### Análisis del objetivo
-Habilitar una interfaz de comunicación estándar para que las IAs puedan interactuar con las capacidades de creación de componentes del framework sin depender de la ejecución manual de comandos shell por parte del agente.
-
-### Opciones consideradas
-Llamadas directas a `run_command` vs Servidor MCP. El MCP es superior al ofrecer tipado, descubrimiento automático y evitar errores de sintaxis en el shell.
-
-### Decisión tomada
-Implementar un servidor MCP basado en Stdio que exponga las funciones centrales del comando `create`. Se refactorizó la lógica de creación para desacoplarla de Clack (UI).
-
----
-
-## Output (REQUIRED)
-- **Entregables**:
-  - `agentic-workflow/src/mcp/server.ts`
-  - `package.json` actualizado con dependencias MCP.
-  - Binario CLI actualizado para lanzar el servidor.
-- **Evidencia requerida**:
-  - El servidor MCP debe iniciarse correctamente y listar las herramientas disponibles.
-
----
-
-## Execution
-
-```yaml
-execution:
-  agent: "tooling-agent"
-  status: completed
-  started_at: "2026-01-20T08:12:00+01:00"
-  completed_at: "2026-01-20T08:14:00+01:00"
-```
-
----
-
-## Implementation Report
-
-### Cambios realizados
-- Añadida dependencia `@modelcontextprotocol/sdk`.
-- Implementado servidor MCP en `src/mcp/server.ts`.
-- Refactorizada lógica de `performCreate` en `src/cli/commands/create.ts` para ser agnóstica de la interfaz.
-- Registrado el comando `agentic-workflow mcp` en el binario del paquete.
-
-### Decisiones técnicas
-Uso de `StdioServerTransport` por ser el estándar más sencillo y eficaz para integración con IDEs como Cursor o Windsurf.
-
-### Evidencia
-Servidor MCP compilado y listo para ser lanzado. Las herramientas `create_role` y `create_workflow` están expuestas y funcionales.
-
----
-
-## Gate (REQUIRED)
-
-```yaml
-approval:
-  developer:
-    decision: SI
-    date: "2026-01-20T08:14:00+01:00"
-    comments: "Servidor MCP aprobado. Esto eleva el framework a un nivel profesional de orquestación."
-```
-
----
-
-## Reglas contractuales
-1. Esta tarea **NO puede marcarse como completada** sin Gate PASS (`decision: SI`).