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

package/dist/agent/artifacts/12-npm-workspaces/researcher/research.md

@@ -0,0 +1,186 @@
+🔬 **researcher-agent**: Informe de investigación técnica para T012 — npm-workspaces.
+
+---
+artifact: research
+phase: phase-1-research
+owner: researcher-agent
+status: draft
+related_task: 12-npm-workspaces
+---
+
+# Research Report — 12-npm-workspaces
+
+> [!CAUTION]
+> **REGLA PERMANENT**: Este documento es SOLO documentación.
+> El researcher-agent documenta hallazgos SIN analizar, SIN recomendar, SIN proponer soluciones.
+> El análisis corresponde a Phase 2.
+
+## 1. Resumen ejecutivo
+- **Problema investigado**: Migración del proyecto monolítico a npm workspaces con packages independientes
+- **Objetivo de la investigación**: Documentar la estructura actual, dependencias entre módulos, y las capacidades de npm workspaces
+- **Principales hallazgos**: El proyecto tiene dependencias cruzadas entre `app→core` y `cli→infrastructure+runtime`. npm workspaces soporta este patrón de forma nativa desde Node 16+
+
+---
+
+## 2. Necesidades detectadas
+
+### Estructura actual del proyecto
+```
+src/
+├── extension/
+│   ├── extension.ts          → entry point VSCode (importa app)
+│   └── modules/
+│       ├── app/              → Package candidato @agentic-workflow/app
+│       │   ├── index.ts      → importa '../core/index.js'
+│       │   ├── backend/      → importa '../../core/backend/index.js'
+│       │   ├── background/   → importa '../../core/index.js'
+│       │   ├── view/         → importa '../../core/view/index.js'
+│       │   └── test/unit/    → importa '../../../core/...'
+│       └── core/             → Package candidato @agentic-workflow/core
+│           ├── index.ts      → re-exports de submodules
+│           ├── backend/      → AbstractBackend, VirtualServer
+│           ├── background/   → Background base class
+│           ├── messaging/    → Transport layer
+│           ├── view/         → View base + templates
+│           ├── logger.ts
+│           ├── constants.ts
+│           └── types.d.ts
+├── cli/                      → Package candidato @agentic-workflow/cli
+│   ├── index.ts              → re-exports commands
+│   └── commands/
+│       ├── init.ts           → importa '../../infrastructure/...'
+│       ├── create.ts         → importa '../../infrastructure/...'
+│       └── mcp.ts            → importa '../../runtime/...'
+├── infrastructure/           → NO es package (dependencia de cli)
+└── runtime/                  → NO es package (dependencia de cli)
+```
+
+### Mapa de dependencias cruzadas entre módulos
+| Origen | Destino | Archivos que importan |
+|--------|---------|----------------------|
+| `app/index.ts` | `core/index.js` | `App extends CoreApp` |
+| `app/backend/index.ts` | `core/backend/index.js` | `AbstractBackend` |
+| `app/background/index.ts` | `core/index.js` | `Background, ViewHtml, Message` |
+| `app/view/index.ts` | `core/view/index.js` | `View` |
+| `app/test/unit/background.test.ts` | `core/messaging/background.js`, `core/index.js` | Test imports |
+| `cli/commands/init.ts` | `infrastructure/...`, `runtime/...` | `detectAgentSystem`, `resolver`, `backup`, `startRuntimeMcpServer` |
+| `cli/commands/create.ts` | `infrastructure/mapping/resolver.js` | Resolver |
+| `cli/commands/mcp.ts` | `runtime/mcp/server.js` | `startRuntimeMcpServer` |
+
+### Configuración TypeScript actual
+- **tsconfig.json**: `rootDir: ./src`, `outDir: ./dist`, `module: NodeNext`
+- **tsconfig.build.json**: Excluye `src/extension/**` y tests (build solo cli/runtime/infra)
+- Sin TypeScript project references configuradas
+
+### Tests existentes
+- **E2E**: `test/e2e/extension.spec.ts` — Playwright, 1 archivo, config en `playwright.config.ts` (testDir: `./test/e2e`)
+- **Unit**: `src/extension/modules/app/test/unit/background.test.ts` — Vitest
+- **Scripts**: `npm run test:e2e` (Playwright), `npm run test:unit` (Vitest), `npm run compile` (tsc + build-view.mjs)
+
+### Build pipeline actual
+- `compile`: `tsc -p ./ && node scripts/build-view.mjs`
+- `build`: `clean-dist && tsc -p tsconfig.build.json && copy-assets`
+- `watch`: `tsc -watch -p ./ & node scripts/build-view.mjs --watch`
+
+---
+
+## 3. Hallazgos técnicos
+
+### 3.1 npm Workspaces
+- **Descripción**: Funcionalidad nativa de npm (desde v7 / Node 16) que permite gestionar múltiples packages dentro de un mismo repositorio.
+- **Estado**: Estable, soportado en producción
+- **Documentación oficial**: https://docs.npmjs.com/cli/v10/using-npm/workspaces
+- **Limitaciones conocidas**:
+  - Hoisting por defecto; se puede controlar con `.npmrc` (`install-strategy=nested`)
+  - `node_modules` compartido en root por defecto
+  - Requiere que cada workspace tenga su propio `package.json` con campo `name`
+
+### 3.2 workspace: protocol
+- **Descripción**: Protocolo para referenciar packages del workspace como dependencias (`"@agentic-workflow/core": "workspace:*"`)
+- **Estado**: Soportado nativamente por npm desde v9+
+- **Documentación**: https://docs.npmjs.com/cli/v10/configuring-npm/package-json#workspace-dependencies
+- **Limitaciones**: Packages con `workspace:*` no se pueden publicar directamente; npm los reemplaza en `npm pack`/`npm publish`
+
+### 3.3 TypeScript Project References
+- **Descripción**: Mecanismo nativo de TypeScript para compilar múltiples proyectos con dependencias entre ellos
+- **Estado**: Estable desde TypeScript 3.0+
+- **Documentación**: https://www.typescriptlang.org/docs/handbook/project-references.html
+- **Limitaciones**: Requiere `composite: true` y `declaration: true` en cada sub-proyecto
+
+### 3.4 VSCode Extension con Workspaces
+- **Descripción**: Las extensiones VSCode usan webpack/esbuild para bundling; npm workspaces puede coexistir
+- **Estado**: No documentado oficialmente por VSCode
+- **Documentación**: https://code.visualstudio.com/api/working-with-extensions/bundling-extension
+- **Limitaciones**: El entry point (`main` en package.json root) debe seguir apuntando al bundle final
+
+---
+
+## 4. APIs relevantes
+
+### npm CLI workspace commands
+| Comando | Descripción |
+|---------|-------------|
+| `npm install` | Instala deps de todos los workspaces automáticamente |
+| `npm run -w <name> <script>` | Ejecuta script en un workspace específico |
+| `npm run --ws <script>` | Ejecuta script en todos los workspaces |
+| `npm ls --ws` | Lista dependencias de workspaces |
+
+### package.json `workspaces` field
+```json
+{
+  "workspaces": [
+    "src/extension/modules/app",
+    "src/extension/modules/core",
+    "src/cli"
+  ]
+}
+```
+
+---
+
+## 5. Compatibilidad
+
+### Node.js / npm versions
+| Feature | Mínimo requerido | Actual en proyecto |
+|---------|:---:|:---:|
+| npm workspaces | npm 7+ / Node 16+ | Node 20+ (by engines) |
+| workspace: protocol | npm 9+ | Compatible |
+| TypeScript project references | TS 3.0+ | TS 5.9.3 |
+
+---
+
+## 6. Oportunidades detectadas
+- TypeScript project references podrían acelerar compilación incremental en monorepos
+- npm workspace symlinking automático elimina necesidad de `npm link` manual
+
+---
+
+## 7. Riesgos identificados
+
+| Riesgo | Severidad | Fuente |
+|--------|:---------:|--------|
+| `cli` importa `infrastructure` y `runtime` con rutas relativas `../../` — no son workspaces | Alta | Análisis de imports |
+| `extension.ts` importa `./modules/app/index.js` — ruta relativa que depende de la estructura de carpetas | Media | Código fuente |
+| Unit tests en app importan core con rutas relativas `../../../core/` | Media | Código fuente |
+| El `tsconfig.json` tiene `rootDir: ./src` — habrá que ajustar si cada package tiene su propio tsconfig | Alta | tsconfig.json |
+| VSCode extension main apunta a `./dist/extension/extension.js` — la ruta de output debe mantenerse | Alta | package.json |
+
+---
+
+## 8. Fuentes
+- [npm Workspaces](https://docs.npmjs.com/cli/v10/using-npm/workspaces)
+- [npm workspace: protocol](https://docs.npmjs.com/cli/v10/configuring-npm/package-json)
+- [TypeScript Project References](https://www.typescriptlang.org/docs/handbook/project-references.html)
+- [VSCode Extension Bundling](https://code.visualstudio.com/api/working-with-extensions/bundling-extension)
+- [Node.js Subpath Exports](https://nodejs.org/api/packages.html#subpath-exports)
+
+---
+
+## 9. Aprobacion del desarrollador (OBLIGATORIA)
+```yaml
+approval:
+  developer:
+    decision: SI
+    date: "2026-02-16T07:35:37+01:00"
+    comments: null
+```

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

@@ -0,0 +1,126 @@
+---
+id: 12
+title: npm-workspaces
+owner: architect-agent
+strategy: long
+---
+
+# Task
+
+## Identificación
+- id: 12
+- title: npm-workspaces
+- scope: current
+- owner: architect-agent
+
+## Origen
+- created_from:
+  - workflow: tasklifecycle-long
+  - source: init
+  - candidate_path: artifacts.candidate.task
+
+## Descripción de la tarea
+Convertir el proyecto en un monorepo con npm workspaces donde cada módulo se convierte en un package npm independiente con su propio `package.json`.
+
+## Objetivo
+Reestructurar el proyecto para que los módulos `app`, `core` y `cli` sean packages npm privados y las dependencias entre ellos se gestionen a través de referencias de workspace, con build unificado desde el root.
+
+## Estado del ciclo de vida (FUENTE ÚNICA DE VERDAD)
+
+```yaml
+task:
+  id: "12"
+  title: "npm-workspaces"
+  strategy: "long"
+  artifacts:
+    supplemental: []
+  phase:
+    current: "phase-8-commit-push"
+    validated_by: "architect-agent"
+    updated_at: "2026-02-16T07:54:25+01:00"
+  lifecycle:
+    phases:
+      phase-0-acceptance-criteria:
+        completed: true
+        validated_by: architect-agent
+        validated_at: "2026-02-16T07:32:24+01:00"
+      phase-1-research:
+        completed: true
+        validated_by: architect-agent
+        validated_at: "2026-02-16T07:35:37+01:00"
+      phase-2-analysis:
+        completed: true
+        validated_by: architect-agent
+        validated_at: "2026-02-16T07:39:57+01:00"
+      phase-3-planning:
+        completed: true
+        validated_by: architect-agent
+        validated_at: "2026-02-16T07:42:30+01:00"
+      phase-4-implementation:
+        completed: true
+        validated_by: architect-agent
+        validated_at: "2026-02-16T07:50:00+01:00"
+      phase-5-verification:
+        completed: true
+        validated_by: architect-agent
+        validated_at: "2026-02-16T07:54:25+01:00"
+      phase-6-results-acceptance:
+        completed: true
+        validated_by: architect-agent
+        validated_at: "2026-02-16T07:54:25+01:00"
+      phase-7-evaluation:
+        completed: true
+        validated_by: architect-agent
+        validated_at: "2026-02-16T07:54:25+01:00"
+      phase-8-commit-push:
+        completed: false
+        validated_by: null
+        validated_at: null
+    subflows:
+      components:
+        create: []
+        refactor:
+          - name: app-module-to-package
+            completed: true
+            validated_by: architect-agent
+            validated_at: "2026-02-16T07:54:25+01:00"
+          - name: core-module-to-package
+            completed: true
+            validated_by: architect-agent
+            validated_at: "2026-02-16T07:54:25+01:00"
+          - name: cli-to-package
+            completed: true
+            validated_by: architect-agent
+            validated_at: "2026-02-16T07:54:25+01:00"
+        delete: []
+      short-phase-1-brief:
+        completed: false
+        validated_by: null
+        validated_at: null
+      short-phase-2-implementation:
+        completed: false
+        validated_by: null
+        validated_at: null
+      short-phase-3-closure:
+        completed: false
+        validated_by: null
+        validated_at: null
+```
+
+---
+
+## 2. Definición y Alcance (Contrato)
+- **Acceptance Criteria**: [acceptance.md](file:///Users/milos/Documents/workspace/agentic-workflow/.agent/artifacts/12-npm-workspaces/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/agent/artifacts/13-implement-custom-chat-with-a2ui/acceptance.md

@@ -0,0 +1,75 @@
+# Acceptance Criteria — 13-Implement Custom Chat with A2UI
+
+## Agent Identification (MANDATORY)
+First line of the document:
+`<icon> **<agent-name>**: <message>`
+
+## 1. Consolidated Definition
+The user requires replacing the current VSCode ChatKit integration with a custom chat interface built using **A2UI** (Google's new framework for AI-rendered components). The goal is to completely remove dependencies on `vscode-chatkit` and implement a "Premium" chat experience that supports **Spanish UI labels** while maintaining the source code in **English**. Key features must include Markdown rendering, Streaming, Code Blocks, Slash Commands, and File Attachments. The design is not pre-defined, so a research phase is required to define the look & feel using A2UI capabilities.
+
+## 2. Answers to Clarification Questions
+> This section documents the developer's answers to the 5 questions formulated by the architect-agent.
+
+| # | Question (formulated by architect) | Answer (from developer) |
+|---|-----------------------------------|------------------------|
+| 1 | **Architecture (A2UI)**: What exactly is "A2UI"? Is it an existing NPM library, a local module, or a new framework we need to create from scratch? | A2UI is the new framework from Google to render components by AI Agents. |
+| 2 | **Scope (ChatKit)**: Does "Replace ChatKit" imply a complete removal of the `vscode-chatkit` dependency? Does this affect the backend `sessions` endpoint or just the frontend? | Yes, we have to eliminate any code made for OpenAI ChatKit. |
+| 3 | **Features**: What mandatory features must this "Custom Chat" support? (e.g., Markdown, Streaming, Code Blocks, Slash Commands, File Attachments)? | Yes (Markdown, Streaming, Code Blocks, Slash Commands, File Attachments). |
+| 4 | **Language**: Confirming "Spanish chat / English code": Does this mean **UI Labels/Texts** in Spanish and **Source Code** in English? Does it affect the System Prompt language? | Yes. |
+| 5 | **Design**: Is there a specific design/wireframe for A2UI? Should it look like VS Code native or have a custom "Premium" style? | No, do research. |
+
+---
+
+## 3. Verifiable Acceptance Criteria
+> List of criteria derived from the previous answers that must be verified in Phase 5.
+
+1. Scope:
+   - `vscode-chatkit` dependency is removed from `package.json` and `node_modules`.
+   - All `ChatKit` related code in `src/extension/` and `src/webview/` is removed or refactored.
+   - A new Chat Interface is implemented using A2UI framework.
+
+2. Inputs / Data:
+   - User types messages in Spanish/English.
+   - User can attach files.
+   - User can use slash commands (e.g., `/reset`, `/model`).
+
+3. Outputs / Expected Result:
+   - Chat UI renders messages with Markdown support.
+   - Code blocks are syntax highlighted and copyable.
+   - Responses stream in real-time.
+   - UI Labels (buttons, placeholders, errors) are in **Spanish**.
+
+4. Constraints:
+   - Source code variable names, comments, and structure must be in **English**.
+   - Must use **A2UI** framework.
+   - Must work within VS Code Webview.
+
+5. Acceptance Criterion (Done):
+   - A functional Chat Interface displayed in VS Code Side Bar.
+   - Can send a message and receive a streaming response from the Agent.
+   - "ChatKit" is nowhere to be found in the codebase.
+
+---
+
+## Approval (Gate 0)
+This document constitutes the task contract. Its approval is blocking to proceed to Phase 1.
+
+```yaml
+approval:
+  developer:
+    decision: SI
+    date: 2026-02-16T12:00:33+01:00
+    comments: "Approved via chat"
+```
+
+---
+
+## Validation History (Phase 0)
+```yaml
+history:
+  - phase: "phase-0-acceptance-criteria"
+    action: "completed"
+    validated_by: "architect-agent"
+    timestamp: "2026-02-16T11:59:02+01:00"
+    notes: "Acceptance criteria defined"
+```

package/dist/agent/artifacts/13-implement-custom-chat-with-a2ui/researcher/research.md

@@ -0,0 +1,121 @@
+---
+artifact: research
+phase: phase-1-research
+owner: researcher-agent
+status: approved
+related_task: 13-implement-custom-chat-with-a2ui
+---
+
+# Research Report — 13-Implement Custom Chat with A2UI
+
+## Agent Identification (MANDATORY)
+🔬 **researcher-agent**: Researching A2UI integration for VS Code.
+
+> [!CAUTION]
+> **PERMANENT RULE**: This document is ONLY documentation.
+> The researcher-agent documents findings WITHOUT analyzing, WITHOUT recommending, WITHOUT proposing solutions.
+> Analysis belongs to Phase 2.
+
+## 1. Executive Summary
+- **Problem investigated**: How to implement a custom A2UI-based chat interface in VS Code to replace a legacy (non-existent/removed) ChatKit implementation.
+- **Research objective**: Understand A2UI protocol, its integration with VS Code Webviews, and compliance with the "Spanish UI / English Code" requirement.
+- **Key findings**:
+  - A2UI is a JSON-based declarative UI protocol from Google.
+  - No legacy "ChatKit" code exists in the current `src`, offering a clean slate.
+  - Integration requires a Host (VS Code Extension) and a Client (Webview with A2UI Renderer).
+  - Official A2UI renderers exist for React and Angular; Lit (current project standard) might require a custom adapter or wrapping a React renderer.
+
+---
+
+## 2. Detected Needs
+- **Technical requirements**:
+  - VS Code Webview capable of rendering A2UI JSON.
+  - Streaming support for real-time AI responses.
+  - Multi-modal support (text, code blocks, file attachments).
+  - Localization support (Spanish UI labels).
+- **Assumptions and limitations**:
+  - The project currently uses `Lit` for webviews.
+  - `openai` dependency is present in `package.json` but seemingly unused in `src`.
+
+---
+
+## 3. Technical Findings
+
+### A2UI (Agent-to-User Interface)
+- **Concept**: A protocol where AI agents send declarative JSON describing the UI.
+- **Mechanism**:
+  1.  **Agent** generates JSON (e.g., `{ "type": "button", "label": "Save" }`).
+  2.  **Host** (Extension) forwards this JSON to the Client.
+  3.  **Client** (Webview) uses a **Renderer** to map JSON to native components.
+- **State**: Public Preview (v0.8).
+- **Documentation**: [a2ui.org](https://a2ui.org)
+
+### Integration with VS Code
+- **Architecture**:
+  - **Backend**: Node.js/TypeScript Extension Host. Acts as the A2UI "Server".
+  - **Frontend**: Webview. Acts as the A2UI "Client".
+  - **Transport**: `webview.postMessage` (Server -> Client) and `vscode.postMessage` (Client -> Server).
+- **Current Codebase State**:
+  - `src/extension/modules/app` is a basic Lit-based shell.
+  - No conflicting "ChatKit" code found in `src`.
+  - `openai` dependency exists (v6.17.0).
+
+---
+
+## 4. Relevant APIs
+- **VS Code API**:
+  - `vscode.window.createWebviewPanel`: To host the UI.
+  - `webview.asWebviewUri`: To load safe content.
+  - `webview.postMessage`: To stream A2UI chunks.
+- **A2UI Protocol**:
+  - `sc-msg` (Server-to-Client): `surfaceUpdate`, `dataModelUpdate`.
+  - `cs-msg` (Client-to-Server): `userAction`.
+
+---
+
+## 5. Multi-browser Compatibility
+- **VS Code Webview**: Uses a dedicated Electron instance (Chromium) on Desktop.
+- **Web Support**: If run in GitHub Codespaces (Browser), A2UI client works as a standard SPA.
+- **Mobile**: Not applicable for this VS Code extension scope.
+
+---
+
+## 6. Detected AI-first Opportunities
+- **Generative UI**: A2UI allows the agent to invent new UI controls on the fly (e.g., a "Confirm Deploy" card with specific parameters) without deploying new frontend code.
+- **Streaming**: A2UI supports streaming JSON, enabling the UI to build itself token-by-token.
+
+---
+
+## 7. Identified Risks
+1.  **Renderer Availability for Lit**:
+    - **Risk**: Current A2UI SDKs focus on React/Angular. The project uses Lit.
+    - **Source**: NPM Registry search for `@a2ui/lit` (not found).
+    - **Severity**: High. Might require building a custom renderer or using a React wrapper inside Lit.
+
+2.  **Localization**:
+    - **Risk**: Dynamic JSON from LLM might default to English unless system prompt is strictly controlled.
+    - **Source**: LLM behavior.
+    - **Severity**: Medium. Requires strict prompting ("Always generate labels in Spanish").
+
+3.  **Complexity**:
+    - **Risk**: Implementing a full A2UI client is complex compared to static HTML.
+    - **Source**: A2UI Specification.
+    - **Severity**: Medium.
+
+---
+
+## 8. Sources
+- [A2UI Official Site](https://a2ui.org)
+- [VS Code Webview API](https://code.visualstudio.com/api/extension-guides/webview)
+- Project Codebase Analysis (`grep`, `ls`, `package.json`).
+
+---
+
+## 9. Developer Approval (MANDATORY)
+```yaml
+approval:
+  developer:
+    decision: SI
+    date: 2026-02-16T12:06:32+01:00
+    comments: "Approved via chat to save documentation, but PAUSED execution to switch priority to Task D1."
+```

package/dist/agent/artifacts/13-implement-custom-chat-with-a2ui/task.md

@@ -0,0 +1,104 @@
+---
+id: 13
+title: Implement Custom Chat with A2UI
+owner: architect-agent
+strategy: long
+---
+
+# Task (Definitive)
+
+## Identification
+- id: 13
+- title: Implement Custom Chat with A2UI
+- scope: current
+- owner: architect-agent
+
+## Origin
+- created_from:
+  - workflow: tasklifecycle-long
+  - source: init
+  - candidate_path: artifacts.candidate.task
+
+## Task Description
+Replace the existing ChatKit integration with a custom chat interface using the A2UI framework (Google's new framework for AI-rendered components). This involves completely removing the `vscode-chatkit` dependency and implementing a new UI that meets the "Spanish chat" requirement while keeping the source code in English.
+
+## Objective
+Replace ChatKit with a custom chat interface using A2UI framework/library.
+
+## Lifecycle State (SINGLE SOURCE OF TRUTH)
+
+```yaml
+task:
+  id: "13"
+  title: "Implement Custom Chat with A2UI"
+  strategy: "long"
+  artifacts:
+    supplemental: []
+  phase:
+    current: "phase-2-analysis"
+    validated_by: "architect-agent"
+    updated_at: "2026-02-16T12:06:32+01:00"
+  lifecycle:
+    phases:
+      phase-0-acceptance-criteria:
+        completed: true
+        validated_by: "architect-agent"
+        validated_at: "2026-02-16T12:00:33+01:00"
+      phase-1-research:
+        completed: true
+        validated_by: "architect-agent"
+        validated_at: "2026-02-16T12:06:32+01:00"
+      phase-2-analysis:
+        completed: false
+        validated_by: null
+        validated_at: null
+      phase-3-planning:
+        completed: false
+        validated_by: null
+        validated_at: null
+      phase-4-implementation:
+        completed: false
+        validated_by: null
+        validated_at: null
+      phase-5-verification:
+        completed: false
+        validated_by: null
+        validated_at: null
+      phase-6-results-acceptance:
+        completed: false
+        validated_by: null
+        validated_at: null
+      phase-7-evaluation:
+        completed: false
+        validated_by: null
+        validated_at: null
+      phase-8-commit-push:
+        completed: false
+        validated_by: null
+        validated_at: null
+    subflows:
+      components:
+        create: []
+        refactor: []
+        delete: []
+```
+
+---
+
+## 2. Definition and Scope (Contract)
+- **Acceptance Criteria**: [acceptance.md](file:///.agent/artifacts/13-implement-custom-chat-with-a2ui/acceptance.md)
+- **Alias**: `task.acceptance`
+
+---
+
+## Contractual Rules
+- This file is the **single source of truth** of the task state.
+- The `task.phase.current` field can **ONLY be modified by `architect-agent`**.
+- The `task.lifecycle.phases.*` field can **ONLY be marked as completed by `architect-agent`**.
+- A phase **CANNOT be marked as completed** if it is not the current phase.
+- Phase advancement requires:
+  1. Marking the current phase as `completed: true`
+  2. Explicit architect validation
+  3. Updating `task.phase.current` to the next phase
+
+> **STATUS NOTE**: Task PAUSED at Phase 2 Analysis entry point.

package/dist/agent/artifacts/14-re-implement-setup-config-d1/acceptance.md

@@ -0,0 +1,75 @@
+# Acceptance Criteria — 14-Re-implement Setup/Config (D1)
+
+## Agent Identification (MANDATORY)
+First line of the document:
+`<icon> **<agent-name>**: <message>`
+
+## 1. Consolidated Definition
+The user requires a complete re-implementation of the Setup and Configuration domain (D1). This involves abstracting the "Core" to expose secure methods for accessing settings. The settings to be persisted include LLM Models (selection), OAuth/API Keys, Language, and Theme. The storage mechanism must follow security best practices (likely `SecretStorage` for keys and `GlobalState` for non-sensitive data). The UI must be built using **Lit** and **Google Material Design**, ensuring a premium look and feel. There is no legacy data to migrate.
+
+## 2. Answers to Clarification Questions
+> This section documents the developer's answers to the 5 questions formulated by the architect-agent.
+
+| # | Question (formulated by architect) | Answer (from developer) |
+|---|-----------------------------------|------------------------|
+| 1 | **Scope of Settings**: What specific settings must be persisted? | LLM -models (model selected), oAuth o API keys, Histori chat (pero es para otra tarea), language, theme |
+| 2 | **Storage Mechanism**: Should `SettingsStorage` use VS Code `globalState`/`workspaceState`, `secretStorage` (for keys), or a local JSON file? | Analizar la mejor solucion desde la perspectiva de seguridad y recomendacion de vscode |
+| 3 | **UI Framework**: Confirming usage of **Lit**. Should it be a standalone Webview (Settings Page) or integrated into the Chat Sidepanel? | Lit y Material Design de Google |
+| 4 | **Backend Logic**: Does the `core/background` layer need to expose a specific API (e.g., `getSettings`, `updateSettings`) via the message bus? | Core siempre es abstracto, puedo exponer metodos para acceder a datos seguros y poder asegurar que todos los modulos mantienen la seguridad |
+| 5 | **Migration**: Is there legacy data/configuration that needs to be migrated, or do we start with a fresh schema? | No, es nuevo |
+
+---
+
+## 3. Verifiable Acceptance Criteria
+> List of criteria derived from the previous answers that must be verified in Phase 5.
+
+1. Scope:
+   - Implement `SettingsStorage` service in `core/background`.
+   - Implement Settings UI using **Lit** and **Material Design** components.
+   - Expose abstract methods in Core for secure data access.
+
+2. Inputs / Data:
+   - User inputs API Keys (securely masked).
+   - User selects LLM Model from a dropdown.
+   - User selects Language and Theme.
+
+3. Outputs / Expected Result:
+   - Settings are persisted across VS Code restarts.
+   - API Keys are stored in VS Code `SecretStorage`.
+   - Non-sensitive settings are stored in `GlobalState` or `WorkspaceState`.
+   - UI reflects current settings state.
+
+4. Constraints:
+   - Must use **Lit** framework.
+   - Must use **Material Design** tokens/styles.
+   - Core layer must remain abstract and secure.
+
+5. Acceptance Criterion (Done):
+   - A functional Settings UI where users can configure the agent.
+   - Verification that keys are not stored in plain text.
+   - A clean, premium UI that matches Google's Material Design standards.
+
+---
+
+## Approval (Gate 0)
+This document constitutes the task contract. Its approval is blocking to proceed to Phase 1.
+
+```yaml
+approval:
+  developer:
+    decision: SI
+    date: 2026-02-16T12:14:51+01:00
+    comments: "Approved via chat"
+```
+
+---
+
+## Validation History (Phase 0)
+```yaml
+history:
+  - phase: "phase-0-acceptance-criteria"
+    action: "completed"
+    validated_by: "architect-agent"
+    timestamp: "2026-02-16T12:13:54+01:00"
+    notes: "Acceptance criteria defined"
+```