@christianmaf80/agentic-workflow 1.41.0-beta.11 → 1.42.0

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,106 +40,28 @@ Inicializa el sistema agéntico en el directorio actual.
 npx agentic-workflow init
 ```
 
-#### Selección del workspace (recomendado)
-Si ejecutas desde `npx`, el comando puede arrancar en un directorio temporal. Para evitarlo, pasa el workspace explícitamente:
-```bash
-npx agentic-workflow init --workspace /ruta/a/tu/proyecto
-```
-También puedes fijarlo por entorno:
-```bash
-AGENTIC_WORKSPACE=/ruta/a/tu/proyecto 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
-```
-
-## 📦 Instalación y Registro MCP
-
-### Instalar y Ejecutar
-Instalación global:
-```bash
-npm install -g @christianmaf80/agentic-workflow
-agentic-workflow mcp
-```
-
-Con `npx` (sin instalación global):
-```bash
-npx agentic-workflow mcp
-```
-
-### Registrar o Actualizar Cliente MCP
-Registrar (Antigravity/Gemini o Codex CLI si está presente):
-```bash
-npx agentic-workflow register-mcp
-```
-
-Si necesitas actualizar el registro en Codex, elimina el bloque
-`[mcp_servers.agentic-workflow]` de `~/.codex/config.toml` y vuelve
-a ejecutar `register-mcp`. En Antigravity se actualiza en el lugar.
-
-### Parar y Logs
-Detén el servidor MCP con `Ctrl+C`. Los logs del runtime se escriben en `agentic-runtime.log`.
-
-## ⚙️ 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**:
@@ -151,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
 
@@ -36,112 +37,33 @@ The agent will use its terminal tools to set up the environment, create the `.ag
 Initializes the agentic system in the current directory.
 - Detects legacy systems and offers migration with automatic backups.
 - Creates/refreshes the `.agent/` structure with the core files.
-- Copies `skills` into `.agent/skills` to enable governance and specialized capabilities.
 - Generates `AGENTS.md`, the entry point for IDE assistants.
 ```bash
 npx agentic-workflow init
 ```
 
-#### Workspace selection (recommended)
-When running via `npx`, the command may start in a temporary directory. To avoid this, pass the workspace explicitly:
-```bash
-npx agentic-workflow init --workspace /path/to/your/project
-```
-You can also set it via env:
-```bash
-AGENTIC_WORKSPACE=/path/to/your/project 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
-```
-
-## 📦 Install and MCP Registration
-
-### Install and Run
-Global install:
-```bash
-npm install -g @christianmaf80/agentic-workflow
-agentic-workflow mcp
-```
-
-With `npx` (no global install):
-```bash
-npx agentic-workflow mcp
-```
-
-### Register or Update MCP Client
-Register (Antigravity/Gemini or Codex CLI if present):
-```bash
-npx agentic-workflow register-mcp
-```
-
-If you need to update a Codex registration, remove the existing
-`[mcp_servers.agentic-workflow]` block from `~/.codex/config.toml`,
-then run `register-mcp` again. Antigravity updates in place.
-
-### Stop and Logs
-Stop the MCP server with `Ctrl+C`. Runtime logs are written to `agentic-runtime.log`.
-
-## ⚙️ 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**:
@@ -152,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/RELEASE_PROCESS.md

@@ -22,9 +22,6 @@ The project uses GitHub Actions for automated releases to npm.
 ### Manual Steps for Release
 1. Update version: `npm version prerelease --preid=beta` (or appropriate semver command).
 2. Update `CHANGELOG.md`.
-3. Build the distributable: `npm run build` (generates `dist/`).
-   - TODO: Ensure the build copies all resources under `src/agentic-system-structure` (rules, workflows, templates, artifacts, skills, and any new domains).
-4. Verify `agentic-workflow init` scaffolds `.agent/skills` as part of the core copy.
-5. (Optional) Generate local package: `npm run package`. The `.tgz` file will be moved to `.backups/npm-packages/`.
-6. Create a branch: `git checkout -b ci/publish-beta-x.x.x`.
-7. Push and create PR.
+3. (Optional) Generate local package: `npm run package`. The `.tgz` file will be moved to `.backups/npm-packages/`.
+4. Create a branch: `git checkout -b ci/publish-beta-x.x.x`.
+5. Push and create PR.

package/bin/cli.js

@@ -1,99 +1,58 @@
 #!/usr/bin/env node
 import { Command } from 'commander';
-import { readFileSync } from 'fs';
-import { fileURLToPath } from 'url';
-import { dirname, join } from 'path';
 import { initCommand } from '../dist/cli/commands/init.js';
+import { scaffoldCommand } from '../dist/cli/commands/scaffold.js';
+import { forkCommand } from '../dist/cli/commands/fork.js';
 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 { bootstrapCommand } from '../dist/cli/commands/bootstrap.js';
-import { registerMcpCommand } from '../dist/cli/commands/register-mcp.js';
-
-const __filename = fileURLToPath(import.meta.url);
-const __dirname = dirname(__filename);
-const pkg = JSON.parse(readFileSync(join(__dirname, '..', 'package.json'), 'utf-8'));
-
-function checkDevEnvironment() {
-  try {
-    const cwd = process.cwd();
-    const pkgPath = join(cwd, 'package.json');
-    // Check if we are in the repo
-    const cwdPkg = JSON.parse(readFileSync(pkgPath, 'utf-8'));
-    if (cwdPkg.name === '@christianmaf80/agentic-workflow') {
-      // We are in the repo. Check if we are running the local binary.
-      // __filename is the absolute path of the executing script.
-      if (!__filename.startsWith(cwd)) {
-        console.warn('\x1b[33m%s\x1b[0m', '--------------------------------------------------------------------------------');
-        console.warn('\x1b[33m%s\x1b[0m', '⚠️  WARNING: DEVELOPMENT ENVIRONMENT DETECTED');
-        console.warn('\x1b[33m%s\x1b[0m', '   You are running a global/external version of agentic-workflow inside the source repo.');
-        console.warn('\x1b[33m%s\x1b[0m', '   This may cause version mismatches (missing MCP tools, etc).');
-        console.warn('\x1b[33m%s\x1b[0m', '   PLEASE RUN: npm run dev:setup');
-        console.warn('\x1b[33m%s\x1b[0m', '--------------------------------------------------------------------------------');
-      }
-    }
-  } catch (e) {
-    // Ignore errors (e.g. no package.json in cwd), just proceed.
-  }
-}
-checkDevEnvironment();
 
 const program = new Command();
 
 program
-  .name('agentic-workflow')
-  .description('Portable agentic orchestration system')
-  .version(pkg.version);
+    .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('-y, --yes', 'Alias for --non-interactive')
-  .option('--no-prompt', 'Alias for --non-interactive')
-  .option('--workspace <path>', 'Workspace root (absolute path)')
-  .option('--start-mcp', 'Start MCP server after initialization (foreground)')
-  .action((options) => {
-    const nonInteractive =
-      Boolean(options.nonInteractive) ||
-      Boolean(options.yes) ||
-      options.prompt === false;
-    return initCommand({ ...options, nonInteractive });
-  });
+    .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('scaffold <directory>')
+    .description('Scaffold the agentic system into a custom directory name (instead of .agent)')
+    .option('--non-interactive', 'Run without prompts (assume YES)')
+    .action((directory, options) => scaffoldCommand(directory, options));
 
 program
-  .command('clean')
-  .description('Remove legacy configuration files (e.g. MCP)')
-  .action(cleanCommand);
+    .command('fork <directory>')
+    .description('Clone the entire Agentic Workflow framework source code to build an independent fork')
+    .action((directory) => forkCommand(directory));
 
 program
-  .command('mcp')
-  .description('Start MCP runtime server (stdio)')
-  .option('--workspace <path>', 'Workspace root (absolute path)')
-  .action((options) => mcpCommand(options));
+    .command('restore')
+    .description('Restore the agentic system from a backup')
+    .action(restoreCommand);
 
 program
-  .command('register-mcp')
-  .description('Register MCP server in Gemini CLI (Antigravity) and/or Codex CLI')
-  .action(() => registerMcpCommand());
+    .command('clean')
+    .description('Remove legacy configuration files (e.g. MCP)')
+    .action(cleanCommand);
 
 program
-  .command('bootstrap')
-  .argument('<path>', 'Destination path for the standalone core')
-  .description('Bootstrap a standalone copy of the agentic core structure')
-  .action(bootstrapCommand);
+    .command('mcp')
+    .description('Start MCP runtime server (stdio)')
+    .action(() => mcpCommand());
 
 program.parse();

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

@@ -0,0 +1,70 @@
+🏛️ **architect-agent**: Acceptance criteria definidos para scaffold vscode-agentinc.
+
+# Acceptance Criteria — 1-scaffold-extension-vscode-agentinc
+
+## Identificacion del agente (OBLIGATORIA)
+Primera linea del documento:
+`<icono> **<nombre-agente>**: <mensaje>`
+
+## 1. Definicion Consolidada
+Crear el scaffold oficial de una extension de VS Code llamada "vscode-agentinc" usando el generador `yo code` (TypeScript + npm), ubicandolo en `src/extension` como base para el desarrollo de la API de chat AI. Debe incluir un comando minimo activable y la estructura estandar de extension. Se debe validar en el Marketplace si existe el nombre "vscode-agentinc" tanto como display name como identificador de extension (cualquier publisher).
+
+## 2. Respuestas a Preguntas de Clarificacion
+> Esta seccion documenta las respuestas del desarrollador a las 5 preguntas formuladas por el architect-agent.
+
+| # | Pregunta (formulada por architect) | Respuesta (del desarrollador) |
+|---|-----------------------------------|-------------------------------|
+| 1 | ¿En que carpeta exacta del repo debe vivir el scaffolding de la extension (ruta relativa)? | Empezar en `src/extension` (luego `src` sera root del code). |
+| 2 | ¿Quieres generar el scaffold con `yo code` (TypeScript) o prefieres una plantilla manual (JS/TS)? | Usar `yo code` como generador oficial. |
+| 3 | ¿Que funcionalidad minima debe incluir la extension (p. ej., comando “Hello World”, activacion por comando, panel, etc.)? | Lo minimo para comenzar a desarrollar bajo la API de chat AI. |
+| 4 | ¿Que configuracion de build/publicacion esperas (uso de `vsce`, scripts npm, nombre de publisher)? | No conoce la diferencia entre `vsce` y npm; proyecto TypeScript con npm. |
+| 5 | Sobre la validacion del nombre “vscode-agentinc”: ¿debo comprobar solo el “display name” en Marketplace o tambien el identificador completo `publisher.vscode-agentinc`? | Ambos. |
+
+---
+
+## 3. Criterios de Aceptacion Verificables
+> Listado de criterios derivados de las respuestas anteriores que deben ser verificados en la Fase 5.
+
+1. Alcance:
+   - Existe un scaffold oficial de extension de VS Code en `src/extension` generado con `yo code` (TypeScript + npm) y nombrado "vscode-agentinc".
+
+2. Entradas / Datos:
+   - Se usan como entradas el nombre de la extension, el path `src/extension` y la configuracion TypeScript + npm del generador.
+
+3. Salidas / Resultado esperado:
+   - El scaffold incluye `package.json`, `tsconfig.json`, `src/extension.ts` (o equivalente), comandos registrados y scripts npm para compilar.
+   - Se deja evidencia documentada de la verificacion en el Marketplace del nombre "vscode-agentinc" como display name y como identificador de extension (cualquier publisher).
+
+4. Restricciones:
+   - El scaffold se genera con el generador oficial `yo code` y se mantiene dentro de `src/extension`.
+   - No se alteran otros paquetes del repo fuera del scaffold necesario.
+
+5. Criterio de aceptacion (Done):
+   - `npm run compile` funciona dentro de `src/extension`.
+   - La extension se puede cargar en modo development y el comando minimo aparece en la paleta.
+   - La validacion del Marketplace queda registrada en un documento del proyecto (p. ej., README del scaffold o nota dedicada).
+
+---
+
+## Aprobacion (Gate 0)
+Este documento constituye el contrato de la tarea. Su aprobacion es bloqueante para pasar a Phase 1.
+
+```yaml
+approval:
+  developer:
+    decision: SI # SI | NO
+    date: 2026-01-24T15:59:05Z
+    comments: null
+```
+
+---
+
+## Historial de validaciones (Phase 0)
+```yaml
+history:
+  - phase: "phase-0-acceptance-criteria"
+    action: "completed"
+    validated_by: "architect-agent"
+    timestamp: "2026-01-24T15:56:00Z"
+    notes: "Acceptance criteria definidos"
+```

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

@@ -0,0 +1,22 @@
+🏛️ **architect-agent**: Actualizacion de puntuaciones por agente.
+
+---
+artifact: agent_scores
+owner: architect-agent
+status: ongoing
+---
+
+# Agent Scores
+
+## 1. Resumen por agente
+- **dev-agent**
+  - score: 9 (dev=8)
+  - notas: Scaffold y evidencia Marketplace completados sin desviaciones.
+- **qa-agent**
+  - score: 8 (dev=8)
+  - notas: Verificacion de build completa; verificacion GUI pendiente del desarrollador.
+
+---
+
+## 2. Meta
+  - Ultima actualizacion: 2026-01-24T21:23:07Z

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

@@ -0,0 +1,106 @@
+🧑‍💻 **dev-agent**: Tarea asignada para generar scaffold oficial.
+
+---
+artifact: agent_task
+phase: phase-4-implementation
+owner: dev-agent
+status: pending
+related_task: 1-scaffold-extension-vscode-agentinc
+task_number: 1
+---
+
+# Agent Task — 1-dev-agent-scaffold
+
+## Identificacion del agente (OBLIGATORIA)
+Primera linea del documento:
+`<icono> **<nombre-agente>**: <mensaje>`
+
+## Input (REQUIRED)
+- **Objetivo**: Generar el scaffold oficial de la extension VS Code con `yo code` en `src/extension` usando TypeScript + npm.
+- **Alcance**: Crear la estructura base dentro de `src/extension` sin modificar otros dominios.
+- **Dependencias**: Node.js, npm, `yo`, `generator-code`.
+
+---
+
+## Reasoning (OBLIGATORIO)
+
+> [!IMPORTANT]
+> El agente **DEBE** completar esta sección ANTES de ejecutar.
+> Documentar el razonamiento mejora la calidad y permite detectar errores temprano.
+
+### Analisis del objetivo
+- Generar el scaffold oficial con `yo code` en `src/extension` usando TypeScript + npm.
+- Se requiere instalar herramientas si no existen.
+
+### Opciones consideradas
+- **Opcion A**: Instalar `yo` y `generator-code` y ejecutar `yo code` con prompts.
+- **Opcion B**: Crear el scaffold manualmente.
+
+### Decision tomada
+- Opcion elegida: Opcion A.
+- Justificacion: El plan y los AC requieren usar el generador oficial.
+
+---
+
+## Output (REQUIRED)
+- **Entregables**:
+  - `src/extension/` con scaffold generado.
+- **Evidencia requerida**:
+  - Lista de archivos generados y comando usado.
+
+---
+
+## Execution
+
+```yaml
+execution:
+  agent: "dev-agent"
+  status: completed
+  started_at: 2026-01-24T21:12:10Z
+  completed_at: 2026-01-24T21:13:37Z
+```
+
+---
+
+## Implementation Report
+
+> Esta seccion la completa el agente asignado durante la ejecucion.
+
+### Cambios realizados
+- Generado scaffold con `yo code` en `src/extension`.
+- Dependencias instaladas en `src/extension`.
+
+### Decisiones tecnicas
+- Uso de `yo code` con flags `-t=ts`, `-n`, `--extensionId`, `--extensionDescription`, `--pkgManager npm`, `-q`.
+
+### Evidencia
+- Comando: `yo code src/extension -t=ts -n "vscode-agentinc" --extensionId "vscode-agentinc" --extensionDescription "VS Code extension scaffold for agentic workflow" --pkgManager npm -q --skipOpen`.
+- Archivos creados: `.vscode/*`, `package.json`, `tsconfig.json`, `src/extension.ts`, `README.md`, `CHANGELOG.md`, `vsc-extension-quickstart.md`, `eslint.config.mjs`.
+
+### Desviaciones del objetivo
+- Ninguna.
+
+---
+
+## Gate (REQUIRED)
+
+El desarrollador **DEBE** aprobar esta tarea antes de que el arquitecto asigne la siguiente.
+
+```yaml
+approval:
+  developer:
+    decision: SI # SI | NO
+    date: 2026-01-24T21:14:31Z
+    comments: null
+```
+
+---
+
+## Reglas contractuales
+
+1. Esta tarea **NO puede marcarse como completada** sin Gate PASS (`decision: SI`).
+2. Si Gate FAIL (`decision: NO`):
+   - El arquitecto define acciones correctivas.
+   - Se genera una nueva tarea de correccion si procede.
+3. El agente asignado **NO puede modificar** el Input ni el Output definidos por el arquitecto.
+4. El Gate es **sincrono y bloqueante**: el flujo se detiene hasta obtener respuesta del desarrollador.