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

package/dist/artifacts/11-revision-sistema-agentic/task.md

@@ -1,145 +0,0 @@
-# Task: Revisión de Constitución y Workflows Agénticos
-
-## Identificación
-- id: 11-revision-sistema-agentic
-- title: Revisión de Constitución y Workflows Agénticos
-- 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
-Revisión exhaustiva de las reglas de constitución para módulos, páginas y shards, seguida de un análisis y redefinición de los workflows operativos del sistema agéntico. El desarrollador ha detectado debilidades arquitectónicas en la implementación de estos elementos que causan interpretaciones erróneas por parte de los agentes.
-
-## Objetivo
-Analizar y consolidar la normativa del framework (Modules, Pages, Shards) y optimizar los flujos de trabajo (workflows) para asegurar la coherencia arquitectónica y la eficiencia del ciclo de vida de desarrollo, incluyendo la creación de workflows específicos para Page y Shard.
-
-## Estado del ciclo de vida (FUENTE ÚNICA DE VERDAD)
-
-```yaml
-task:
-  id: "11-revision-sistema-agentic"
-  title: "Revisión de Constitución y Workflows Agénticos"
-  phase:
-    current: "phase-4-implementation"
-    validated_by: "architect-agent"
-    updated_at: "2026-01-13T23:48:00+01:00"
-  lifecycle:
-    phases:
-      phase-0-acceptance-criteria:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-13T09:25:00+01:00"
-      phase-1-research:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-13T09:43:00+01:00"
-      phase-2-analysis:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-13T22:00:00+01:00"
-      phase-3-planning:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-13T22:15:00+01:00"
-      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
-```
-
-## 5 Preguntas Obligatorias (REQUERIDO - Phase 0)
-
-| # | Pregunta (formulada por architect) | Respuesta (del desarrollador) |
-|---|-----------------------------------|-------------------------------|
-| 1 | ¿Cuál es el problema principal o la "desconexión" que has detectado actualmente en las constituciones de módulos, páginas y shards que motiva esta revisión? | Inconsistencias y debilidades arquitectónicas que causan implementaciones incompletas y mala interpretación de los agentes sobre las reglas e integración. |
-| 2 | Respecto a los workflows, ¿buscas una simplificación de los pasos actuales o una mayor automatización y rigurosidad en las validaciones entre fases? | Perfeccionar los existentes e incluir workflows específicos y necesarios para Page y Shard. |
-| 3 | En el análisis de la constitución, ¿prefieres que el architect-agent proponga cambios basados en `extensio-architecture.md` o guiarás el análisis punto por punto? | El arquitecto debe guiar con recomendaciones y valoraciones objetivas sobre las decisiones del desarrollador. |
-| 4 | ¿Deseas que los resultados se materialicen en nuevos documentos de constitución (`modules.md`, `pages.md`, `shards.md`) o en una actualización profunda de los existentes? | Crear nuevos si no existen y refactorizar profundamente los existentes. |
-| 5 | ¿Debemos considerar el impacto de estos cambios en las herramientas del CLI y el `mcp-server` durante la redefinición de los workflows? | Sí. |
-
----
-
-## Acceptance Criteria (OBLIGATORIO PARA CURRENT TASK)
-
-1. Alcance:
-   - Revisión y actualización de las constituciones `modules.md`, `pages.md` y `shards.md`.
-   - Creación de nuevos workflows contractuales para la creación/gestión de Pages y Shards.
-   - Refactorización de los workflows existentes del sistema agéntico para mayor rigurosidad.
-
-2. Entradas / Datos:
-   - `extensio-architecture.md` como fuente de verdad arquitectónica.
-   - Constituciones actuales en `.agent/rules/constitution/`.
-   - Workflows actuales en `.agent/workflows/`.
-
-3. Salidas / Resultado esperado:
-   - Documentos de constitución (`modules.md`, `pages.md`, `shards.md`) robustos, claros y sin ambigüedades.
-   - Workflows para Page (`pages.create.md`) y Shard (`shards.create.md`) implementados y registrados.
-   - Informe de impacto en CLI y MCP-server sobre los cambios estructurales.
-
-4. Restricciones:
-   - No romper la retrocompatibilidad con la lógica de Core sin aviso.
-   - Mantener el aislamiento estricto entre módulos.
-   - Formato Markdown estricto para las reglas (`PERMANENT`, `MEMORY`, etc.).
-
-5. Criterio de aceptación (Done):
-   - Aprobación explícita (SI) por parte de la autoridad técnica del desarrollador tras la revisión de los nuevos documentos y flujos.
-
-## Historial de validaciones (append-only)
-```yaml
-history:
-  - phase: "phase-0-acceptance-criteria"
-    action: "completed"
-    validated_by: "architect-agent"
-    timestamp: "2026-01-13T09:25:00+01:00"
-    notes: "Acceptance criteria definidos y validados. Iniciando Fase 1."
-  - phase: "phase-1-research"
-    action: "completed"
-    validated_by: "architect-agent"
-    timestamp: "2026-01-13T09:43:00+01:00"
-    notes: "Investigación completada. Se ha analizado la lógica de build de shards/pages y las debilidades de la constitución actual. Iniciando Fase 2."
-```
-  - phase: "phase-1-research"
-    action: "completed"
-    validated_by: "architect-agent"
-    timestamp: "2026-01-13T09:43:00+01:00"
-    notes: "Investigación completada. Análisis de constituciones y workflows."
-  - phase: "phase-2-analysis"
-    action: "completed"
-    validated_by: "architect-agent"
-    timestamp: "2026-01-13T22:00:00+01:00"
-    notes: "Análisis de impacto completado. Identificados gaps en CLI y Core."
-  - phase: "phase-3-planning"
-    action: "completed"
-    validated_by: "architect-agent"
-    timestamp: "2026-01-13T22:15:00+01:00"
-    notes: "Plan de implementación implícito en los documentos de impacto."
-  - phase: "phase-4-implementation"
-    action: "started"
-    validated_by: "architect-agent"
-    timestamp: "2026-01-13T23:48:00+01:00"
-    notes: "Constituciones y workflows actualizados. Pendiente: cambios en Core y CLI."

package/dist/artifacts/11-revision-sistema-agentic/verification.md

@@ -1,119 +0,0 @@
-# Informe de Verificación - Phase 5
-
-## Fecha: 2026-01-13T23:50:00+01:00
-## Tarea: 11-revision-sistema-agentic
-## Verificador: architect-agent
-
----
-
-## 1. Entregables Verificados
-
-### 1.1 Constituciones
-
-| Archivo | Versión | Líneas | Estado |
-|---------|---------|--------|--------|
-| `extensio-architecture.md` | - | 131 | ✅ Verificado |
-| `modules.md` | v2.0.0 | 250 | ✅ Verificado |
-| `pages.md` | v2.1.0 | 454 | ✅ Verificado |
-| `shards.md` | v2.0.0 | 484 | ✅ Verificado |
-
-### 1.2 Workflows
-
-| Archivo | Versión | Líneas | Estado |
-|---------|---------|--------|--------|
-| `modules/create.md` | v2.0.0 | 126 | ✅ Verificado |
-| `modules/pages.create.md` | v2.0.0 | 202 | ✅ Verificado |
-| `modules/shards.create.md` | v2.0.0 | 183 | ✅ Verificado |
-
-### 1.3 Roles
-
-| Archivo | Versión | Líneas | Estado |
-|---------|---------|--------|--------|
-| `roles/module.md` | v2.0.0 | 145 | ✅ Verificado |
-
-### 1.4 Índices
-
-| Archivo | Versión | Estado |
-|---------|---------|--------|
-| `rules/constitution/index.md` | v2.0.0 | ✅ Verificado |
-| `workflows/modules/index.md` | v2.0.0 | ✅ Verificado |
-
----
-
-## 2. Acceptance Criteria - Verificación
-
-### AC1: Revisión y actualización de constituciones
-- ✅ `modules.md` - Actualizado con ciclo de vida detallado, reactividad, estructura
-- ✅ `pages.md` - Creado desde 21 líneas a 454 líneas con responsabilidades SRP
-- ✅ `shards.md` - Creado desde 24 líneas a 484 líneas con ciclo de vida y registry
-
-### AC2: Creación de workflows para Pages y Shards
-- ✅ `pages.create.md` - Workflow completo con estructura, ciclo de vida, hooks
-- ✅ `shards.create.md` - Workflow completo con registro, métodos abstractos, hooks
-
-### AC3: Refactorización de workflows existentes
-- ✅ `modules/create.md` - Actualizado para verificar Surfaces (Pages/Shards)
-- ✅ `roles/module.md` - Actualizado para delegar a workflows de Surfaces
-
-### AC4: Informe de impacto en CLI y MCP-server
-- ✅ `cli-mcp-impact.md` - Gaps identificados en templates y comandos
-- ✅ `core-impact.md` - Cambios de código requeridos en Core
-
----
-
-## 3. Contenido Clave Verificado
-
-### 3.1 Pages (constitution.pages)
-- ✅ §1-2: Definición y jerarquía (Core → Surface → Page)
-- ✅ §3: Estructura obligatoria
-- ✅ §4: Ciclo de vida (run → listen → start → render → onMount)
-- ✅ §5: Navegación (navigate, onNavigate)
-- ✅ §7: Build y CLI
-- ✅ §11-12: Responsabilidades SRP y restricciones
-- ✅ §13: Hooks automáticos
-
-### 3.2 Shards (constitution.shards)
-- ✅ §1-2: Definición y jerarquía (Core → Surface → Shard)
-- ✅ §3: Estructura obligatoria
-- ✅ §4: Ciclo de vida (mount → render → onMount → unmount)
-- ✅ §5: Registro como WebComponent
-- ✅ §6: Dos contextos (Page vs Engine)
-- ✅ §7: Comunicación con Engine (@onShard)
-- ✅ §8-9: Responsabilidades y restricciones
-- ✅ §14: Hooks automáticos
-
----
-
-## 4. Gaps Documentados (Fuera de alcance actual)
-
-| Gap | Documento | Prioridad |
-|-----|-----------|-----------|
-| Shard hereda de Core (debe ser Surface) | `core-impact.md` | 🔴 Alta |
-| onMount debe ser automático | `core-impact.md` | 🔴 Alta |
-| Template page.ts.ejs incompleto | `cli-mcp-impact.md` | 🔴 Alta |
-| Template shard.ts.ejs sin getTagName | `cli-mcp-impact.md` | 🟡 Media |
-
----
-
-## 5. Resultado de Verificación
-
-| Criterio | Resultado |
-|----------|-----------|
-| Todos los entregables existen | ✅ PASS |
-| Versiones actualizadas a 2.0.0 | ✅ PASS |
-| Acceptance Criteria cubiertos | ✅ PASS |
-| Contenido coherente con arquitectura | ✅ PASS |
-| Gaps documentados | ✅ PASS |
-
-## Decisión Final
-
-**✅ VERIFICACIÓN APROBADA**
-
-Los entregables de documentación (constituciones, workflows, roles) están completos y son coherentes con la arquitectura de Extensio.
-
-Los cambios de código (Core, CLI) están documentados pero fuera del alcance de esta tarea.
-
----
-
-Verificado por: architect-agent
-Fecha: 2026-01-13T23:50:00+01:00

package/dist/artifacts/12-adaptacion-core-cli-surfaces/analysis-architecture-change.md

@@ -1,305 +0,0 @@
----
-artifact: analysis-addendum
-phase: phase-2-analysis
-owner: architect-agent
-status: draft
-related_task: 12-adaptacion-core-cli-surfaces
----
-
-# Análisis de Cambio Arquitectónico: Page como Controller
-
-## Propuesta del Desarrollador
-
-> "Page debe disponer del método del engine para poder cargar shards para mantener la misma coherencia con el ciclo de cargar shards. Por eso creo que Pages debe actuar más como un controller persistente en memoria a diferencia de engine que es más event driven. Creo conveniente por tanto quitar la capacidad de render a Pages y que sean solo los Shards quienes dispongan de esa capacidad."
-
----
-
-## 1. Análisis Comparativo: Engine vs Page
-
-| Aspecto | Engine | Page (propuesta) |
-|---------|--------|------------------|
-| **Entorno** | Service Worker (background) | DOM (documento HTML) |
-| **Persistencia** | Ephemeral (puede morir/revivir) | Persistente mientras tab esté abierto |
-| **Acceso DOM** | ❌ No tiene acceso | ✅ Acceso directo |
-| **Modelo** | Event-driven (listeners de Storage, Runtime) | Controller persistente en memoria |
-| **Renderizado** | ❌ No renderiza | ❌ **No renderiza** (propuesta) |
-| **Carga Shards** | `loadShard()` vía Scripting driver | `loadShard()` directo en DOM |
-| **Comunicación** | Runtime.sendMessage | Directo a Shards (mismo contexto) |
-
----
-
-## 2. Implicaciones del Cambio
-
-### 2.1 Page como Controller (sin render)
-
-**Ventajas:**
-- **Separación de responsabilidades clara**: Page orquesta, Shard renderiza
-- **Coherencia arquitectónica**: Un único patrón de renderizado (Shards)
-- **Reutilización**: El mismo Shard puede usarse en Page o en navegación orgánica
-- **Simplicidad en templates**: No hay que decidir si Page renderiza con Lit/React/Vanilla
-- **Testabilidad**: Shards se testean aislados, Pages se testean como controllers
-
-### 2.2 Page con `loadShard()`
-
-**Implementación propuesta:**
-
-```typescript
-// Page como controller
-class MyPage extends Page {
-  override start() {
-    // Cargar shards en el DOM de la Page
-    const container = document.getElementById('shards-container');
-    this.loadShard(MyShard, { container });
-  }
-}
-```
-
-**Diferencia con Engine.loadShard():**
-
-| Engine.loadShard() | Page.loadShard() |
-|--------------------|------------------|
-| Usa `Scripting.executeScript` | Instancia directa en DOM |
-| Inyecta en tab externo | Monta en contenedor de la Page |
-| Cross-context (Service Worker → Tab) | Same-context (Page DOM) |
-
----
-
-## 3. Nueva Jerarquía Propuesta
-
-```
-Core
-  └── Surface (abstracta)
-        ├── onMount() / onUnmount()
-        ├── Sistema reactivo (@property, @onChanged)
-        │
-        ├── Page (controller, SIN render)
-        │     ├── loadShard(shardClass, options)
-        │     ├── unloadShard(shardId)
-        │     └── getShards(): Shard[]
-        │
-        └── Shard (visual, CON render)
-              ├── mount(container)
-              ├── render()
-              ├── update(props)
-              └── unmount()
-```
-
----
-
-## 4. Cambios en Constitución de Pages
-
-### Antes (constitución actual)
-```
-Page se renderiza en su propio contexto
-Page puede tener método render()
-```
-
-### Después (propuesta)
-```
-Page NO renderiza directamente
-Page actúa como CONTROLLER:
-  - Orquesta Shards
-  - Gestiona lifecycle de Shards
-  - Responde a eventos del usuario delegando a Shards
-```
-
-### Nuevas responsabilidades de Page:
-1. **Orquestación de Shards**: Cargar/descargar Shards según lógica de UI
-2. **Layout management**: Definir dónde se montan los Shards
-3. **Comunicación inter-Shard**: Coordinar datos entre Shards
-4. **Navegación interna**: Cambiar vistas (cargar diferentes Shards)
-
----
-
-## 5. Implementación de `Page.loadShard()`
-
-```typescript
-// Page con capacidad de cargar Shards
-export class Page extends Surface {
-  private _shards: Map<string, Shard> = new Map();
-
-  /**
-   * Carga un Shard en el DOM de la Page.
-   * Similar a Engine.loadShard() pero para contexto DOM directo.
-   */
-  public async loadShard<T extends Shard>(
-    ShardClass: new (context: ShardContext) => T,
-    options: PageShardOptions = {}
-  ): Promise<T> {
-    const { container, containerId, props } = options;
-    
-    // Resolver contenedor
-    const targetContainer = container || 
-      (containerId ? document.getElementById(containerId) : document.body);
-    
-    if (!targetContainer) {
-      throw new Error(`Container not found for Shard`);
-    }
-
-    // Crear contexto para el Shard
-    const context: ShardContext = {
-      tabId: 0, // Mismo tab
-      url: window.location.href,
-      documentId: document.documentElement.id,
-    };
-
-    // Instanciar y montar
-    const shard = new ShardClass(context);
-    await shard.mount(targetContainer);
-    
-    if (props) {
-      shard.update(props);
-    }
-
-    this._shards.set(shard.id, shard);
-    return shard;
-  }
-
-  public unloadShard(shardId: string): void {
-    const shard = this._shards.get(shardId);
-    if (shard) {
-      shard.unmount();
-      this._shards.delete(shardId);
-    }
-  }
-
-  public getShards(): Shard[] {
-    return Array.from(this._shards.values());
-  }
-
-  // Override onUnmount para limpiar Shards
-  protected override onUnmount(): void {
-    for (const shard of this._shards.values()) {
-      shard.unmount();
-    }
-    this._shards.clear();
-    super.onUnmount();
-  }
-}
-```
-
----
-
-## 6. Ejemplo de Uso
-
-```typescript
-// MyDashboardPage.mts
-import { Page } from '@extensio/core/surface/pages';
-import { ChartShard, TableShard, FilterShard } from './shards';
-
-class MyDashboardPage extends Page {
-  constructor() {
-    super('dashboard-page');
-  }
-
-  override async start() {
-    // Page no renderiza, solo carga Shards
-    await this.loadShard(FilterShard, { 
-      containerId: 'filters-container' 
-    });
-    
-    await this.loadShard(ChartShard, { 
-      containerId: 'chart-container',
-      props: { type: 'bar' }
-    });
-    
-    await this.loadShard(TableShard, { 
-      containerId: 'table-container' 
-    });
-  }
-}
-```
-
-```html
-<!-- dashboard/index.html -->
-<!DOCTYPE html>
-<html>
-<head>
-  <title>Dashboard</title>
-</head>
-<body>
-  <!-- Page no renderiza, solo define containers para Shards -->
-  <div id="filters-container"></div>
-  <div id="chart-container"></div>
-  <div id="table-container"></div>
-  
-  <script type="module" src="./index.mts"></script>
-</body>
-</html>
-```
-
----
-
-## 7. Impacto en Templates CLI
-
-Los templates de Page deberían:
-- **NO** usar Lit/React/decoradores de renderizado
-- **SÍ** definir containers HTML para Shards
-- **SÍ** importar y cargar Shards
-
-```typescript
-// Template de Page propuesto
-import { Page } from '@extensio/core/surface/pages';
-// import Shards que usará la Page
-
-class <%= name %>Page extends Page {
-  constructor() {
-    super('<%= name.toLowerCase() %>-page');
-  }
-
-  override async start() {
-    // Cargar Shards aquí
-    // await this.loadShard(MyShard, { containerId: 'container' });
-  }
-}
-
-const page = new <%= name %>Page();
-page.run();
-```
-
----
-
-## 8. Validación de Coherencia Arquitectónica
-
-| Principio | Cumplimiento |
-|-----------|--------------|
-| **SRP**: Page orquesta, Shard renderiza | ✅ Claro |
-| **Consistencia**: loadShard() en Engine y Page | ✅ Mismo patrón |
-| **Reusabilidad**: Shards en cualquier contexto | ✅ Máxima |
-| **Mantenibilidad**: Menos código en Page | ✅ Simplicidad |
-| **Extensio Architecture**: Surface → Page/Shard | ✅ Respeta jerarquía |
-
----
-
-## 9. Recomendación del Architect
-
-**✅ APRUEBO** el cambio arquitectónico propuesto.
-
-**Razones:**
-1. Page como controller sin render es más coherente con el rol de orquestador
-2. Shards como único componente de render simplifica el modelo mental
-3. `loadShard()` en Page mantiene coherencia con Engine
-4. Facilita testing: Page se testea como controller, Shard como componente visual
-
-**Cambios requeridos:**
-1. Actualizar constitución de Pages (quitar render, añadir loadShard)
-2. Implementar `Page.loadShard()`, `Page.unloadShard()`, `Page.getShards()`
-3. Actualizar templates CLI de Pages
-4. Actualizar demo para reflejar nuevo patrón
-
----
-
-## 10. Próximos pasos
-
-Si el desarrollador aprueba, se actualizará:
-1. `analysis.md` con este cambio
-2. Constitución de Pages (v2.2.0)
-3. Plan de implementación
-
-```yaml
-approval:
-  developer:
-    decision: SI
-    date: 2026-01-14T08:03:49+01:00
-    comments: Aprobado
-```