@christianmaf80/agentic-workflow 1.24.0-beta.4 → 1.25.0-beta.3

package/README.es.md

@@ -11,9 +11,8 @@
 ## ✨ Características Principales
 
 - **Protocolo AHRP (Agentic Handover & Reasoning Protocol)**: Impone un flujo estricto de Triple-Puerta para cada tarea (Activación, Aprobación de Razonamiento y Aceptación de Resultados).
-- **Gobernanza de Runtime y MCP**: Integración profunda con un servidor MCP para seguimiento de ciclos de vida, validación de puertas y logs a prueba de manipulaciones.
-- **Skills Agénticos**: Capacidades modulares para los agentes, incluyendo habilidades de gobernanza localizadas (ej: `skill.runtime-governance`).
 - **Arquitectura local**: Copia las reglas y workflows del core dentro de `.agent/` para evitar dependencias de acceso continuado a `node_modules`.
+- **Gobernanza de Tolerancia Cero**: Penalizaciones automáticas de rendimiento por violaciones del protocolo.
 - **Independiente y Portátil**: Funciona en cualquier proyecto, siempre que el agente del IDE pueda leer archivos Markdown.
 
 ## 📦 Instalación
@@ -41,69 +40,28 @@ Inicializa el sistema agéntico en el directorio actual.
 npx agentic-workflow init
 ```
 
-### `create <role|workflow|skill> <name>`
-Genera el andamiaje (scaffolding) para un nuevo componente específico del proyecto.
+### `create <role|workflow> <name>`
+Genera el andamiaje (scaffolding) para un nuevo componente personalizado.
 - **role**: Crea un nuevo rol de agente con reglas de identificación obligatorias.
 - **workflow**: Crea una plantilla de ciclo de trabajo personalizado.
-- **skill**: Crea una nueva habilidad modular con su propia plantilla `SKILL.md`.
 ```bash
 npx agentic-workflow create role neo
 ```
 
 ### `restore`
-Recuepra la configuración de `.agent/` desde una copia de seguridad previa.
+Recupera la configuración de `.agent/` desde una copia de seguridad previa.
+- Los backups se almacenan como `.agent.backup_<timestamp>` en la raíz del proyecto.
+- Permite seleccionar versiones antes de un cambio destructivo.
 ```bash
 npx agentic-workflow restore
 ```
 
-### `clean`
-Elimina archivos de configuración temporales o heredados (ej: configuraciones MCP obsoletas).
-```bash
-npx agentic-workflow clean
-```
-
-### `mcp`
-Inicia el servidor local del Runtime MCP (modo stdio).
-```bash
-npx agentic-workflow mcp
-```
-
-### `register-mcp`
-Registra automáticamente el servidor local en la configuración de Antigravity/Gemini.
-```bash
-npx agentic-workflow register-mcp
-```
-
-## ⚙️ Configuración Avanzada
-
-### Integración de Runtime MCP
-El sistema utiliza un servidor MCP para rastrear el estado del flujo. Para conectarlo con tu asistente de IDE:
-1. Ejecuta `npx agentic-workflow register-mcp`.
-2. Asegúrate de que `mcp_config.json` apunte al binario local del CLI.
-3. Los logs de ejecución se guardan en `agentic-runtime.log` para auditoría y depuración.
-
 ## 🧠 Conceptos Core
 
 ### Ciclos de Vida
 El framework soporta dos flujos principales según la complejidad de la tarea:
-
-#### 1. Ciclo de Vida Largo (9 Fases)
-Diseñado para funcionalidades complejas, cambios arquitectónicos o tareas con alto riesgo. Garantiza el máximo razonamiento antes de escribir una sola línea de código.
-- **Fase 0: Criterios de Aceptación**: Elimina la ambigüedad definiendo exactamente qué significa el éxito.
-- **Fase 1: Investigación**: Recopilación de contexto. Necesaria para entender el código existente o APIs externas.
-- **Fase 2: Análisis**: Evaluación de impacto. Identifica riesgos y restricciones arquitectónicas.
-- **Fase 3: Planificación**: Plan de implementación detallado. Crucial para la alineación con el desarrollador.
-- **Fase 4: Implementación**: El proceso de codificación propiamente dicho.
-- **Fase 5: Verificación**: Pruebas rigurosas y validación de los cambios realizados.
-- **Fase 6: Aceptación de Resultados**: Firma final del desarrollador sobre el valor entregado.
-- **Fase 7: Evaluación**: Retrospectiva sobre el desempeño del agente y eficiencia del proceso.
-- **Fase 8: Commit & Push**: Persistencia segura de los cambios en el repositorio.
-
-#### 2. Ciclo de Vida Corto (3 Fases)
-Optimizado para correcciones rápidas, actualizaciones simples de documentación o cambios de bajo riesgo.
-- **Fase 1: Brief**: Fusiona Aceptación, Análisis y Planificación en un solo paso para mayor agilidad.
-- **Fase 2: Implementación**: Codificación y verificación combinadas.
-- **Fase 3: Cierre**: Aceptación de resultados y limpieza final.
+1. **Ciclo de Vida Largo (9 Fases)**: Para funcionalidades complejas que requieren Investigación, Análisis, Planificación y Revisión Arquitectónica formal.
+2. **Ciclo de Vida Corto (3 Fases)**: Para correcciones rápidas o actualizaciones simples, fusionando Aceptación, Implementación y Cierre.
 
 ### Protocolo AHRP
 Cada tarea de un agente sigue el **Protocolo de Traspaso y Razonamiento Agéntico**:
@@ -114,14 +72,12 @@ Cada tarea de un agente sigue el **Protocolo de Traspaso y Razonamiento Agéntic
 ### Arquitectura por Instalación
 Para garantizar la estabilidad, la lógica central del framework (reglas y workflows) se instala dentro de la carpeta `.agent` del proyecto. Esto ofrece una copia local limpia que se puede extender sin tocar el paquete publicado.
 
-### Sistema de Indexación por Dominios
-El sistema utiliza una **Arquitectura de Indexación en Cascada** para una trazabilidad absoluta:
-1. **Root Index** (`.agent/index.md`): Declara los puntos de entrada para todos los dominios del sistema (reglas, workflows, templates, skills, artefactos).
-2. **Índices de Dominio**: Cada carpeta contiene su propio `index.md` donde se asignan **alias** a los archivos.
-3. **Modelo de Referencia**: Los agentes nunca utilizan rutas absolutas. Resuelven las referencias a través del sistema de alias (ej: `skill.runtime-governance` → `.agent/skills/runtime-governance/SKILL.md`), lo que garantiza que la lógica se pueda mover o actualizar sin romper los flujos de trabajo.
+## ⚖️ Gobernanza
 
-### Responsabilidad en Runtime
-Todas las transiciones de ciclo de vida se registran a través de un Runtime MCP dedicado. Las acciones realizadas sin una "Huella de Gobernanza" correspondiente (logs de MCP) se consideran inválidas y están sujetas a reversión.
+Este framework se basa en el principio de **Máxima Disciplina**. Los agentes deben:
+1. Identificarse con un prefijo obligatorio.
+2. Enviar un plan de razonamiento antes de cualquier modificación.
+3. Obtener la aprobación explícita del desarrollador (`SI`) para cada transición.
 
 ## 📄 Licencia
 

package/README.md

@@ -11,10 +11,11 @@
 ## ✨ Key Features
 
 - **AHRP (Agentic Handover & Reasoning Protocol)**: Enforces a strict Triple-Gate flow for every task (Activation, Reasoning Approval, and Results Acceptance).
-- **Runtime Governance & MCP**: Deep integration with an MCP server for lifecycle tracking, gate validation, and tamper-proof logging.
-- **Agentic Skills**: Modular capabilities for agents, including localized and specialized governance skills (e.g., `skill.runtime-governance`).
 - **Local Core Snapshot**: Copies core rules and workflows into `.agent/` so runtime no longer depends on `node_modules` access.
+- **Zero-Tolerance Governance**: Automatic performance penalties for protocol violations.
 - **Standalone & Portable**: Works in any project provided the IDE agent can read Markdown files.
+- **CLI-First**: Fully functional via command line, decoupling the agentic system from specific IDE extensions.
+
 
 ## 📦 Installation
 
@@ -41,69 +42,28 @@ Initializes the agentic system in the current directory.
 npx agentic-workflow init
 ```
 
-### `create <role|workflow|skill> <name>`
-Scaffolds a new project-specific component.
+### `create <role|workflow> <name>`
+Scaffolds a new custom component.
 - **role**: Creates a new agent role with mandatory identification rules.
 - **workflow**: Creates a custom work cycle template.
-- **skill**: Creates a new modular skill with its own `SKILL.md` template.
 ```bash
 npx agentic-workflow create role neo
 ```
 
 ### `restore`
 Recovers the `.agent/` configuration from a previous backup.
+- Backups are stored as `.agent.backup_<timestamp>` in the project root.
+- Allows selecting versions before a destructive change.
 ```bash
 npx agentic-workflow restore
 ```
 
-### `clean`
-Removes legacy or temporary configuration files (e.g., outdated MCP setups).
-```bash
-npx agentic-workflow clean
-```
-
-### `mcp`
-Starts the local MCP Runtime server (stdio mode).
-```bash
-npx agentic-workflow mcp
-```
-
-### `register-mcp`
-Automatically registers the local server in the Antigravity/Gemini config.
-```bash
-npx agentic-workflow register-mcp
-```
-
-## ⚙️ Advanced Configuration
-
-### MCP Runtime Integration
-The system relies on an MCP server to track the workflow state. To connect it with your IDE assistant (like Antigravity):
-1. Run `npx agentic-workflow register-mcp`.
-2. Ensure `mcp_config.json` (or equivalent) points to the local CLI binary.
-3. The Runtime logs are stored in `agentic-runtime.log` for debugging.
-
 ## 🧠 Core Concepts
 
 ### Lifecycles
 The framework supports two main workflows depending on task complexity:
-
-#### 1. Long Lifecycle (9 Phases)
-Designed for complex features, architectural changes, or tasks with high risk. It ensures maximum reasoning before a single line of code is written.
-- **Phase 0: Acceptance Criteria**: Eliminates ambiguity by defining exactly what success looks like.
-- **Phase 1: Research**: Context gathering. Necessary to understand existing code or external APIs.
-- **Phase 2: Analysis**: Impact evaluation. Identifies risks and architectural constraints.
-- **Phase 3: Planning**: Detailed implementation plan. Crucial for developer alignment before execution.
-- **Phase 4: Implementation**: The actual coding process.
-- **Phase 5: Verification**: Rigorous testing and validation of the implemented changes.
-- **Phase 6: Results Acceptance**: Final developer sign-off on the delivered value.
-- **Phase 7: Evaluation**: Retrospective on the agent's performance and process efficiency.
-- **Phase 8: Commit & Push**: Safely persisting the changes to the repository.
-
-#### 2. Short Lifecycle (3 Phases)
-Optimized for quick fixes, simple documentation updates, or low-risk changes.
-- **Phase 1: Brief**: Merges Acceptance, Analysis, and Planning into a single step for speed.
-- **Phase 2: Implementation**: Combined coding and verification.
-- **Phase 3: Closure**: Results acceptance and final cleanup.
+1. **Long Lifecycle (9 Phases)**: For complex features requiring Research, Analysis, Planning, and formal Architectural Review.
+2. **Short Lifecycle (3 Phases)**: For quick fixes or simple updates, merging Acceptance, Implementation, and Closure.
 
 ### AHRP Protocol
 Every agent task follows the **Agentic Handover & Reasoning Protocol**:
@@ -114,14 +74,12 @@ Every agent task follows the **Agentic Handover & Reasoning Protocol**:
 ### Architecture by Install
 To ensure stability, the framework's core logic (rules and workflows) is installed into your project's `.agent` folder. This provides a clean, local copy that can be extended without touching the published package.
 
-### Domain Indexing System
-The system uses a **Cascading Indexing Architecture** for absolute traceability:
-1. **Root Index** (`.agent/index.md`): Declares the entry points for all system domains (rules, workflows, templates, skills, artifacts).
-2. **Domain Indexes**: Each folder contains its own `index.md` where files are assigned **aliases**.
-3. **Reference Model**: Agents never use absolute paths. They resolve references through the alias system (e.g., `skill.runtime-governance` → `.agent/skills/runtime-governance/SKILL.md`), ensuring that logic can be moved or updated without breaking workflows.
+## ⚖️ Governance
 
-### Runtime Accountability
-All lifecycle transitions are recorded through a dedicated MCP Runtime. Actions performed without a corresponding "Governance Trace" (MCP logs) are considered invalid and subject to reversal.
+This framework is built on the principle of **Maximum Discipline**. Agents are required to:
+1. Identify themselves with a mandatory prefix.
+2. Submit a reasoning plan before any modification.
+3. Obtain explicit developer approval (`YES`) for every transition.
 
 ## 📄 License
 

package/bin/cli.js

@@ -5,48 +5,41 @@ import { createCommand } from '../dist/cli/commands/create.js';
 import { restoreCommand } from '../dist/cli/commands/restore.js';
 import { cleanCommand } from '../dist/cli/commands/clean.js';
 import { mcpCommand } from '../dist/cli/commands/mcp.js';
-import { registerMcpCommand } from '../dist/cli/commands/register-mcp.js';
 
 const program = new Command();
 
 program
-  .name('agentic-workflow')
-  .description('Portable agentic orchestration system')
-  .version('1.24.0-beta.3');
+    .name('agentic-workflow')
+    .description('Portable agentic orchestration system')
+    .version('1.0.0');
 
 program
-  .command('init')
-  .description('Initialize the agentic system in the current directory')
-  .option('--non-interactive', 'Run without prompts (assume YES)')
-  .option('--start-mcp', 'Start MCP server after initialization (foreground)')
-  .action((options) => initCommand(options));
+    .command('init')
+    .description('Initialize the agentic system in the current directory')
+    .option('--non-interactive', 'Run without prompts (assume YES)')
+    .option('--start-mcp', 'Start MCP server after initialization (foreground)')
+    .action((options) => initCommand(options));
 
 program
-  .command('create')
-  .argument('<type>', 'The type of element to create (role, workflow, skill)')
-  .argument('<name>', 'The name for the new element')
-  .description('Scaffold a new project-specific element')
-  .action(createCommand);
+    .command('create')
+    .argument('<type>', 'The type of element to create (role, workflow)')
+    .argument('<name>', 'The name for the new element')
+    .description('Scaffold a new project-specific element')
+    .action(createCommand);
 
 program
-  .command('restore')
-  .description('Restore the agentic system from a backup')
-  .action(restoreCommand);
+    .command('restore')
+    .description('Restore the agentic system from a backup')
+    .action(restoreCommand);
 
 program
-  .command('clean')
-  .description('Remove legacy configuration files (e.g. MCP)')
-  .action(cleanCommand);
+    .command('clean')
+    .description('Remove legacy configuration files (e.g. MCP)')
+    .action(cleanCommand);
 
 program
-  .command('mcp')
-  .description('Start MCP runtime server (stdio)')
-  .action(() => mcpCommand());
-
-program
-  .command('register-mcp')
-  .description('Register MCP server in Gemini CLI (Antigravity) and/or Codex CLI')
-  .action(() => registerMcpCommand());
+    .command('mcp')
+    .description('Start MCP runtime server (stdio)')
+    .action(() => mcpCommand());
 
 program.parse();
-

package/dist/agent/artifacts/1-scaffold-extension-vscode-agentinc/acceptance.md

@@ -1,9 +1,3 @@
----
-kind: artifact
-name: acceptance
-source: agentic-system-structure
----
-
 🏛️ **architect-agent**: Acceptance criteria definidos para scaffold vscode-agentinc.
 
 # Acceptance Criteria — 1-scaffold-extension-vscode-agentinc

package/dist/agent/artifacts/1-scaffold-extension-vscode-agentinc/agent-scores.md

@@ -1,9 +1,3 @@
----
-kind: artifact
-name: agent-scores
-source: agentic-system-structure
----
-
 🏛️ **architect-agent**: Actualizacion de puntuaciones por agente.
 
 ---

package/dist/agent/artifacts/1-scaffold-extension-vscode-agentinc/agent-tasks/1-dev-agent-scaffold.md

@@ -1,9 +1,3 @@
----
-kind: artifact
-name: 1-dev-agent-scaffold
-source: agentic-system-structure
----
-
 🧑‍💻 **dev-agent**: Tarea asignada para generar scaffold oficial.
 
 ---

package/dist/agent/artifacts/1-scaffold-extension-vscode-agentinc/agent-tasks/2-dev-agent-manifest-command.md

@@ -1,9 +1,3 @@
----
-kind: artifact
-name: 2-dev-agent-manifest-command
-source: agentic-system-structure
----
-
 🧑‍💻 **dev-agent**: Tarea asignada para revisar manifesto y comando minimo.
 
 ---

package/dist/agent/artifacts/1-scaffold-extension-vscode-agentinc/agent-tasks/3-dev-agent-marketplace-evidence.md

@@ -1,9 +1,3 @@
----
-kind: artifact
-name: 3-dev-agent-marketplace-evidence
-source: agentic-system-structure
----
-
 🧑‍💻 **dev-agent**: Tarea asignada para documentar evidencia de Marketplace.
 
 ---

package/dist/agent/artifacts/1-scaffold-extension-vscode-agentinc/agent-tasks/4-qa-agent-verify-build.md

@@ -1,9 +1,3 @@
----
-kind: artifact
-name: 4-qa-agent-verify-build
-source: agentic-system-structure
----
-
 🛡️ **qa-agent**: Tarea asignada para verificacion de build y comando.
 
 ---

package/dist/agent/artifacts/1-scaffold-extension-vscode-agentinc/analysis.md

@@ -1,9 +1,3 @@
----
-kind: artifact
-name: analysis
-source: agentic-system-structure
----
-
 🏛️ **architect-agent**: Analisis inicial para scaffold de extension VS Code.
 
 ---

package/dist/agent/artifacts/1-scaffold-extension-vscode-agentinc/architect/review.md

@@ -1,9 +1,3 @@
----
-kind: artifact
-name: review
-source: agentic-system-structure
----
-
 🏛️ **architect-agent**: Revision de implementacion de fase 4.
 
 ---

package/dist/agent/artifacts/1-scaffold-extension-vscode-agentinc/metrics.md

@@ -1,9 +1,3 @@
----
-kind: artifact
-name: metrics
-source: agentic-system-structure
----
-
 🏛️ **architect-agent**: Metricas de evaluacion de agentes.
 
 ---

package/dist/agent/artifacts/1-scaffold-extension-vscode-agentinc/plan.md

@@ -1,9 +1,3 @@
----
-kind: artifact
-name: plan
-source: agentic-system-structure
----
-
 🏛️ **architect-agent**: Plan de implementacion para scaffold VS Code.
 
 ---

package/dist/agent/artifacts/1-scaffold-extension-vscode-agentinc/researcher/research.md

@@ -1,9 +1,3 @@
----
-kind: artifact
-name: research
-source: agentic-system-structure
----
-
 🔍 **researcher-agent**: Informe de investigacion preparado para la fase 1.
 
 ---

package/dist/agent/artifacts/1-scaffold-extension-vscode-agentinc/results-acceptance.md

@@ -1,9 +1,3 @@
----
-kind: artifact
-name: results-acceptance
-source: agentic-system-structure
----
-
 🏛️ **architect-agent**: Informe final de resultados preparado.
 
 ---

package/dist/agent/artifacts/1-scaffold-extension-vscode-agentinc/task.md

@@ -1,9 +1,3 @@
----
-kind: artifact
-name: task
-source: agentic-system-structure
----
-
 # Task (Template)
 
 ## Identificacion

package/dist/agent/artifacts/1-scaffold-extension-vscode-agentinc/verification.md

@@ -1,9 +1,3 @@
----
-kind: artifact
-name: verification
-source: agentic-system-structure
----
-
 🛡️ **qa-agent**: Informe de verificacion de scaffold VS Code.
 
 ---

package/dist/agent/artifacts/11-refinement-capas-constitution/analysis.md

@@ -0,0 +1,24 @@
+# Analysis Report — T11: Refinamiento de Constituciones
+
+## 1. Contexto
+La arquitectura actual modular (`src/extension/modules/*`) requiere reglas estrictas.
+
+## 2. Propuesta de Reglas Constitucionales
+
+### 2.1 Backend Layer (`constitution.backend`)
+1.  **Inheritance**: Extender `AbstractServer` (de `core/backend`).
+2.  **Isolation**: Sin dependencias de `vscode` ni `dom`.
+3.  **Transport Agnostic**.
+
+### 2.2 Background Layer (`constitution.background`)
+1.  **Module Registration**: `App.register`.
+2.  **Messaging Bridge**: `Messaging` (de `core/messaging`) obligatorio.
+3.  **Gateway**: Único punto de acceso a `vscode`.
+
+### 2.3 View Layer (`constitution.view`)
+1.  **Lit Framework**: LitElements obligatorios.
+2.  **Structure**: `index.ts`, `html.ts`, `styles.ts`.
+3.  **No Logic in View**.
+
+## 3. Impacto en Roadmap
+Reset masivo de tareas D1-D6.

package/dist/agent/artifacts/11-refinement-capas-constitution/roadmap-audit.md

@@ -0,0 +1,34 @@
+# Roadmap Audit Report — T11 (Revised)
+
+## Identification
+- id: audit-T11-rev2
+- title: Roadmap vs Current Codebase Audit (Deep Dive)
+- date: 2026-02-15
+- owner: architect-agent
+- related_task: 11
+
+## Purpose
+Determinar con precisión el estado de los entregables del Roadmap frente a la estructura actual del proyecto.
+
+## Context
+El usuario solicitó una re-evaluación profunda. Investigación confirma que la estructura `src/extension/modules` es la única fuente de verdad.
+
+## Findings Details
+
+### 🔴 DOMINIO D1: Setup/Config (Estado Real: NO INICIADO)
+- **T002, T003, T004**: No existen implementaciones funcionales en `modules/setup`.
+
+### 🟡 DOMINIO D3: Backend/Extension Host (Estado Real: PARCIAL)
+- **T010**: No existe session endpoint.
+- **T011**: Bridge básico en `core/messaging`.
+- **T012**: Backend client es un mock.
+
+### 🟡 DOMINIO D2, D4, D6 (Estado Real: PENDIENTE/RESTART)
+- Se ha procedido a resetear el estado de estas tareas en el Roadmap para reflejar la realidad del código.
+
+## Decisions & Recommendations
+1. **Declarar Bancarrota Técnica del Roadmap Antiguo**.
+2. **Re-Planificación Estricta**.
+
+## References
+- `ls src/extension/modules`

package/dist/agent/artifacts/11-refinement-capas-constitution/task.md

@@ -0,0 +1,58 @@
+---
+id: "11"
+title: "refinement-capas-constitution"
+owner: "architect-agent"
+strategy: "long"
+---
+
+# Task: Refinamiento de Constitución de Capas y Roadmap
+
+## Current Phase: phase-6-commit
+
+- [x] Phase 0: Acceptance Criteria
+    - [x] Formular preguntas aclaratorias
+    - [x] Consolidar respuestas del desarrollador
+    - [x] Crear artefactos de tarea y aceptación
+    - [x] Obtener aprobación de criterios de aceptación
+- [x] Phase 1: Research
+    - [x] Auditoría del código actual vs Roadmap
+    - [x] Análisis de las constituciones existentes
+- [x] Phase 2: Analysis
+    - [x] Definir reglas para Backend (AbstractServer, etc.)
+    - [x] Definir reglas para Background (Messaging, App)
+    - [x] Definir reglas para View (Lit, HTML)
+- [x] Phase 3: Planning
+    - [x] Crear Implementation Plan (realizado en Phase 1)
+    - [x] Obtener aprobación del plan
+- [x] Phase 4: Implementation
+    - [x] Actualizar constitution/backend.md
+    - [x] Actualizar constitution/background.md
+    - [x] Actualizar constitution/view.md
+    - [x] Actualizar ROADMAP-BACKLOG.md
+- [x] Phase 5: Verification
+    - [x] Verificar existencia de archivos de constitución
+    - [x] Verificar integridad del Roadmap (Reset realizado)
+
+---
+
+## Task Identification
+- **UUID**: 11
+- **Strategy**: long
+- **Implementation Owner**: architect-agent
+
+---
+
+## Lifecycle History
+| Phase | Action | Agent | Date | Result |
+|-------|--------|-------|------|--------|
+| phase-0-acceptance-criteria | Definition | architect-agent | 2026-02-15T16:22:00Z | YES |
+| phase-1-research | Start | architect-agent | 2026-02-15T16:23:00Z | YES |
+| phase-2-analysis | Analysis | architect-agent | 2026-02-15T16:24:00Z | YES |
+| phase-3-planning | Plan | architect-agent | 2026-02-15T16:25:00Z | YES |
+| phase-4-implementation | Coding | architect-agent | 2026-02-15T16:26:00Z | YES |
+| phase-5-verification | Tests | architect-agent | 2026-02-15T16:28:00Z | YES |
+
+---
+
+## 2. Definición y Alcance (Contrato)
+- **Acceptance Criteria**: `acceptance.md`

package/dist/agent/artifacts/12-npm-workspaces/acceptance.md

@@ -0,0 +1,78 @@
+🏛️ **architect-agent**: Acceptance criteria para la tarea T012 — npm-workspaces.
+
+# Acceptance Criteria — 12-npm-workspaces
+
+## 1. Definición Consolidada
+Migrar el proyecto actual a npm workspaces convirtiendo los módulos `app`, `core` y `cli` en packages npm privados e independientes. Cada package tendrá su propio `package.json` con sus dependencias específicas. El proyecto root coordinará los workspaces y ofrecerá un build unificado. La estructura de extensión VSCode debe mantenerse funcional.
+
+## 2. Respuestas a Preguntas de Clarificación
+
+| # | Pregunta (formulada por architect) | Respuesta (del desarrollador) |
+|---|-----------------------------------|-------------------------------|
+| 1 | ¿Qué elementos deben convertirse en packages npm independientes? | `src/extension/modules/*` (app, core) + `src/cli` |
+| 2 | ¿Qué convención de nombres usar para los packages? | `@agentic-workflow/app`, `@agentic-workflow/core`, `@agentic-workflow/cli` |
+| 3 | ¿Packages públicos o privados? | Private (solo para uso interno del workspace) |
+| 4 | ¿Cómo gestionar dependencias compartidas? | Cada package define sus propias dependencias |
+| 5 | ¿Cómo deben funcionar los scripts de build? | Build unificado desde root |
+
+---
+
+## 3. Criterios de Aceptación Verificables
+
+1. **Alcance**:
+   - `src/extension/modules/app` → package `@agentic-workflow/app`
+   - `src/extension/modules/core` → package `@agentic-workflow/core`
+   - `src/cli` → package `@agentic-workflow/cli`
+   - Root `package.json` configura `workspaces`
+
+2. **Entradas / Datos**:
+   - Código fuente actual en `src/extension/modules/app`, `src/extension/modules/core`, `src/cli`
+   - `package.json` root actual con todas las dependencias centralizadas
+   - `tsconfig.json` actual
+
+3. **Salidas / Resultado esperado**:
+   - Cada package tiene su propio `package.json` con `"private": true`
+   - Root `package.json` incluye campo `"workspaces"` apuntando a los packages
+   - Dependencias distribuidas correctamente en cada package
+   - Build unificado funcional desde root (`npm run compile` / `npm run build`)
+   - La extensión VSCode sigue compilando y ejecutándose correctamente
+
+4. **Restricciones**:
+   - Packages privados (no publicables)
+   - Cada package gestiona sus propias dependencias (sin hoisting forzado)
+   - La estructura de carpetas existente se mantiene (no mover archivos de sitio)
+   - Compatibilidad con el build de extensión VSCode
+
+5. **Criterio de aceptación (Done)**:
+   > **Gate principal**: La tarea se da por terminada si los tests e2e siguen funcionando exactamente igual que antes de la migración.
+   - [ ] **Tests e2e pasan idénticamente** (`npm run test:e2e`) — criterio bloqueante
+   - [ ] `npm install` desde root instala todas las dependencias de todos los workspaces
+   - [ ] `npm run compile` desde root compila exitosamente todos los workspaces
+   - [ ] Cada package tiene `package.json` válido con `"private": true`
+   - [ ] Root `package.json` contiene campo `"workspaces"` correctamente configurado
+   - [ ] Las dependencias inter-package se resuelven vía workspace (ej: `"@agentic-workflow/core": "workspace:*"`)
+   - [ ] La extensión VSCode se ejecuta correctamente tras la migración
+
+---
+
+## Aprobación (Gate 0)
+
+```yaml
+approval:
+  developer:
+    decision: SI
+    date: "2026-02-16T07:32:24+01:00"
+    comments: "Tests e2e como gate principal bloqueante"
+```
+
+---
+
+## Historial de validaciones (Phase 0)
+```yaml
+history:
+  - phase: "phase-0-acceptance-criteria"
+    action: "created"
+    validated_by: "architect-agent"
+    timestamp: "2026-02-16T07:29:25+01:00"
+    notes: "Acceptance criteria definidos con 5 preguntas respondidas"
+```