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

package/dist/artifacts/20-anadir-seccion-reasoning-agent-task/researcher/research.md

@@ -1,142 +0,0 @@
----
-artifact: research
-phase: phase-1-research
-owner: researcher-agent
-status: draft
-related_task: 20-anadir-seccion-reasoning-templates-ejecucion
----
-
-# Research Report — 20-anadir-seccion-reasoning-templates-ejecucion
-
-> [!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
-
-🔬 **researcher-agent**: Investigación para identificar todos los templates de ejecución que requieren la sección "Reasoning".
-
-**Problema investigado**: Definir el alcance preciso de templates a modificar según AC-5.
-
-**Fuentes**: Estructura de `.agent/templates/` + Research Task #19 (Chain of Thought).
-
----
-
-## 2. Hallazgos: Clasificación de Templates
-
-### 2.1 Templates de Ejecución (Requieren Reasoning)
-
-| Template | Owner | Propósito | Tiene Input/Output |
-|----------|-------|-----------|-------------------|
-| `agent-task.md` | {{agent}} | Tareas delegadas a agentes | ✅ Sí |
-| `driver-create.md` | driver-agent | Creación de drivers | ❌ No explícito |
-| `driver-refactor.md` | driver-agent | Refactor de drivers | ❌ No explícito |
-| `driver-delete.md` | driver-agent | Eliminación de drivers | ❌ No explícito |
-| `module-create.md` | module-agent | Creación de módulos | ❌ No explícito |
-| `module-refactor.md` | module-agent | Refactor de módulos | ❌ No explícito |
-| `module-delete.md` | module-agent | Eliminación de módulos | ❌ No explícito |
-
-### 2.2 Templates Obsoletos
-
-| Template | Estado | Nota |
-|----------|--------|------|
-| `subtask-implementation.md` | @deprecated | Usar agent-task.md |
-
-### 2.3 Templates de Documentación (NO Requieren Reasoning)
-
-| Template | Propósito | Razón para excluir |
-|----------|-----------|-------------------|
-| `research.md` | Documentar hallazgos | No hay decisiones de implementación |
-| `analysis.md` | Analizar alternativas | El análisis ES el razonamiento |
-| `planning.md` | Definir plan | El plan ES el razonamiento |
-| `verification.md` | Reportar tests | No hay decisiones |
-| `review.md` | Revisión arquitectónica | Ya incluye evaluación |
-| `results-acceptance.md` | Resumen final | No hay decisiones |
-| `changelog.md` | Log de cambios | Solo registro |
-| `todo-item.md` | Backlog item | Solo información |
-| `init.md` | Bootstrap | Solo configuración |
-| `task.md` | Definición tarea | Solo metadata |
-| `brief.md` | Short cycle brief | Ya incluye análisis |
-| `closure.md` | Short cycle cierre | Solo resumen |
-| `task-metrics.md` | Métricas | Solo datos |
-| `agent-scores.md` | Puntuaciones | Solo datos |
-| `index.md` | Índice | Solo navegación |
-
----
-
-## 3. Hallazgos: Estructura Actual de agent-task.md
-
-```markdown
-## Input (REQUIRED)      ← Posición actual
-- Objetivo
-- Alcance
-- Dependencias
-
-## Output (REQUIRED)     ← AC-1: Reasoning va ENTRE estos
-- Entregables
-- Evidencia requerida
-
-## Execution             ← YAML status
-
-## Implementation Report ← Aquí documenta después
-- Cambios realizados
-- Decisiones técnicas  ← Esto se mueve a Reasoning
-```
-
----
-
-## 4. Hallazgos: Patrones existentes de razonamiento
-
-### En driver-create.md (sección 3)
-```markdown
-## 3. Decisiones tecnicas
-- Decisiones clave y su justificacion
-- Alternativas consideradas y por que se descartaron
-```
-
-### En module-create.md
-No tiene sección explícita de decisiones.
-
-### En subtask-implementation.md (deprecated)
-```markdown
-## 3. Decisiones tecnicas
-- Decisiones clave y su justificacion
-- Alternativas consideradas y por que se descartaron
-```
-
----
-
-## 5. Hallazgos: Referencia Chain of Thought (Task #19)
-
-Según el research de Task #19:
-
-| Técnica | Aplicación |
-|---------|------------|
-| Zero-Shot CoT | "Let's think step by step" implícito |
-| Few-Shot CoT | Ejemplos con pasos de razonamiento |
-
-Subsecciones propuestas (AC-2):
-- Análisis del objetivo
-- Opciones consideradas
-- Decisión tomada
-
----
-
-## 6. Fuentes
-
-### Internas
-- `.agent/templates/` (23 ficheros analizados)
-- Research Task #19, sección 3.5 (Chain of Thought)
-
----
-
-## 7. Aprobación del desarrollador (OBLIGATORIA)
-
-```yaml
-approval:
-  developer:
-    decision: SI
-    date: 2026-01-18T21:57:02+01:00
-    comments: Aprobado
-```

package/dist/artifacts/20-anadir-seccion-reasoning-agent-task/task.md

@@ -1,143 +0,0 @@
----
-artifact: task
-phase: phase-0-acceptance-criteria
-owner: architect-agent
-status: in-progress
----
-
-# Task #20 — Añadir Sección Reasoning a Templates de Ejecución
-
-## Identificación
-- **ID**: 20
-- **Título**: anadir-seccion-reasoning-templates-ejecucion
-- **Origen**: TODO #001 (`.agent/todo/001-anadir-seccion-reasoning.md`)
-- **Fecha creación**: 2026-01-18T21:52:01+01:00
-
-## Descripción
-Añadir una sección "Reasoning" obligatoria a todos los templates de ejecución de tareas/procesos para implementar el patrón Chain of Thought (CoT). Esta sección forzará a los agentes a documentar su proceso de razonamiento antes de implementar.
-
-## Objetivo
-Mejorar la calidad de las decisiones de los agentes mediante:
-- Documentación obligatoria del razonamiento antes de actuar
-- Trazabilidad de opciones consideradas y decisiones tomadas
-- Detección temprana de errores de lógica
-
----
-
-## Lifecycle Status
-
-```yaml
-task:
-  id: 20
-  title: "anadir-seccion-reasoning-templates-ejecucion"
-  strategy: "long"
-  phase:
-    current: "phase-6-results-acceptance"
-    validated_by: "architect-agent"
-    updated_at: "2026-01-18T22:03:12+01:00"
-  lifecycle:
-    phases:
-      phase-0-acceptance-criteria:
-        completed: true
-        validated_by: architect-agent
-        validated_at: "2026-01-18T21:53:28+01:00"
-      phase-1-research:
-        completed: true
-        validated_by: researcher-agent
-        validated_at: "2026-01-18T21:57:02+01:00"
-      phase-2-analysis:
-        completed: true
-        validated_by: architect-agent
-        validated_at: "2026-01-18T21:58:48+01:00"
-      phase-3-planning:
-        completed: true
-        validated_by: architect-agent
-        validated_at: "2026-01-18T22:00:18+01:00"
-      phase-4-implementation:
-        completed: true
-        validated_by: architect-agent
-        validated_at: "2026-01-18T22:03:12+01:00"
-      phase-5-verification:
-        completed: true
-        validated_by: qa-agent
-        validated_at: "2026-01-18T22:03:12+01:00"
-      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 (Phase 0)
-
-### Q1: ¿Dónde colocar la sección Reasoning?
-**Respuesta**: A) Entre Input y Output (antes de definir entregables)
-
-### Q2: ¿Qué subsecciones debe tener Reasoning?
-**Respuesta**: La propuesta: "Análisis del objetivo", "Opciones consideradas", "Decisión tomada"
-
-### Q3: ¿Es obligatorio completar Reasoning antes de Implementation Report?
-**Respuesta**: Sí, bloqueante
-
-### Q4: ¿Formato estructurado (YAML) o libre (markdown)?
-**Respuesta**: El más óptimo → Híbrido (headers markdown para legibilidad + estructura clara)
-
-### Q5: ¿Aplicar solo a agent-task.md o también a otros templates?
-**Respuesta**: A todos los templates de ejecución de tareas o procesos
-
----
-
-## Acceptance Criteria (Derivados)
-
-### AC-1: Posición de la sección
-La sección "Reasoning" se ubica **entre Input y Output** en todos los templates afectados.
-
-### AC-2: Subsecciones obligatorias
-La sección incluye exactamente 3 subsecciones:
-- "Análisis del objetivo"
-- "Opciones consideradas" 
-- "Decisión tomada"
-
-### AC-3: Carácter bloqueante
-La sección "Reasoning" es **OBLIGATORIA** y debe completarse antes del "Implementation Report".
-
-### AC-4: Formato híbrido
-Se usa formato markdown con headers claros, optimizado para legibilidad y estructura.
-
-### AC-5: Alcance ampliado
-Se aplica a **todos los templates de ejecución**:
-- `templates/agent-task.md` (principal)
-- Otros templates de procesos que requieran decisiones
-
----
-
-## Templates afectados (a confirmar en Analysis)
-- `templates/agent-task.md` ✅ Confirmado
-- `templates/research.md` ❓ A evaluar
-- `templates/analysis.md` ❓ A evaluar
-- `templates/planning.md` ❓ A evaluar
-
----
-
-## Aprobación Phase 0
-
-```yaml
-approval:
-  developer:
-    decision: SI
-    date: 2026-01-18T21:53:28+01:00
-    comments: Aprobado
-```

package/dist/artifacts/20-anadir-seccion-reasoning-agent-task/verification.md

@@ -1,53 +0,0 @@
----
-artifact: verification
-phase: phase-5-verification
-owner: qa-agent
-status: completed
-related_task: 20-anadir-seccion-reasoning-templates-ejecucion
----
-
-# Verification Report — 20-anadir-seccion-reasoning-templates-ejecucion
-
-🧪 **qa-agent**: Verificación completada.
-
-## 1. Templates Verificados
-
-| Template | Reasoning | Posición | Subsecciones | IMPORTANT |
-|----------|-----------|----------|--------------|-----------|
-| agent-task.md | ✅ | Entre Input/Output | ✅ 3 | ✅ |
-| driver-create.md | ✅ | Sección 2.5 | ✅ 3 | ✅ |
-| driver-refactor.md | ✅ | Sección 2.5 | ✅ 3 | ✅ |
-| driver-delete.md | ✅ | Sección 2.5 | ✅ 3 | ✅ |
-| module-create.md | ✅ | Sección 2.5 | ✅ 3 | ✅ |
-| module-refactor.md | ✅ | Sección 2.5 | ✅ 3 | ✅ |
-| module-delete.md | ✅ | Sección 2.5 | ✅ 3 | ✅ |
-
-## 2. Acceptance Criteria
-
-| AC | Verificación | Estado |
-|----|--------------|--------|
-| AC-1 | Posición entre Input/Output o equivalente | ✅ PASS |
-| AC-2 | 3 subsecciones (Análisis, Opciones, Decisión) | ✅ PASS |
-| AC-3 | Regla OBLIGATORIO con alerta IMPORTANT | ✅ PASS |
-| AC-4 | Formato híbrido markdown | ✅ PASS |
-| AC-5 | Todos los templates de ejecución | ✅ PASS (7/7) |
-
-## 3. Tests Automatizados
-
-No aplica — cambios en templates markdown.
-
-## 4. Conclusión
-
-**VERIFICACIÓN COMPLETA** — Todos los acceptance criteria validados.
-
----
-
-## Aprobación
-
-```yaml
-approval:
-  developer:
-    decision: SI
-    date: 2026-01-18T22:03:12+01:00
-    comments: Implícito por aprobación de Tasks 1-7
-```

package/dist/artifacts/2026-01-19-orchestration-init/brief.md

@@ -1,88 +0,0 @@
----
-artifact: brief
-phase: short-phase-1-brief
-owner: architect-agent
-status: draft
-related_task: 2026-01-19-orchestration-init
----
-
-# Brief — 2026-01-19-orchestration-init
-
-## 1. Identificación de la tarea
-
-**Título**: Analyze Orchestration Rules Injection in Init
-**Objetivo**: Analizar si es conveniente explicar al LLM las normas de orquestación del sistema durante la fase `init` para evitar que se salte gates o tome decisiones propias priorizando la velocidad o la autodeterminación en fases posteriores.
-**Estrategia**: Short
-
----
-
-## 2. Las 5 Preguntas Obligatorias
-
-| # | Pregunta (formulada por architect) | Respuesta (del desarrollador) |
-|---|-----------------------------------|-------------------------------|
-| 1 | Problema Específico | El LLM se suele saltar los gates de cada fase y no suele cambiar los roles cuando toca hacer las tareas. |
-| 2 | Alcance de la Inyección | Valorar qué es mejor, pero debe ser en el init. |
-| 3 | Riesgo de Contexto | No, nunca consumirá más si es controlado; sino deberá leer rutas que puede llevar a mayor contexto. |
-| 4 | Criterio de Éxito | En el día a día (observación empírica de adherencia). |
-| 5 | Alternativas | Init debe dar el contexto suficiente para que el LLM no interprete las normas al libre decisión. constitution.agents_behavior debe ser ya más por tarea. |
-
----
-
-## 3. Acceptance Criteria
-
-Derivados de las respuestas anteriores:
-
-1. **Alcance**: Modificar el workflow `init` para incluir instrucciones explícitas sobre orquestación, gates y roles.
-2. **Entradas/Datos**: `workflow.init.md` actual y reglas de `agents_behavior`.
-3. **Salidas esperadas**: Un `workflow.init` reforzado que "impronte" al LLM con la obligación de respetar gates y roles desde el inicio.
-4. **Restricciones**: No aumentar excesivamente el contexto, mantener la claridad.
-5. **Criterio de Done**: Verificación visual del cambio y posterior verificación empírica en el uso diario.
-
----
-
-## 4. Análisis simplificado
-
-### Estado actual (As-Is)
-- Estructura afectada: `workflow.init` es el punto de entrada. Actualmente carga reglas pero quizás no enfatiza la *meta-regla* de "NO saltar pasos".
-- Limitaciones conocidas: Los LLMs tienen a optimizar por velocidad y "completar" tareas, a veces asumiendo aprobaciones implícitas.
-
-### Evaluación de complejidad
-
-| Indicador | Estado | Comentario |
-|-----------|--------|------------|
-| Afecta más de 3 paquetes | ☐ Sí ☑ No | Solo afecta workflows/reglas internas. |
-| Requiere investigación APIs | ☐ Sí ☑ No | |
-| Cambios breaking | ☐ Sí ☑ No | Es un cambio de proceso, no de código funcional. |
-| Tests E2E complejos | ☐ Sí ☑ No | |
-
-**Resultado de complejidad**: ☑ BAJA (continuar Short) ☐ ALTA (recomendar abortar a Long)
-
----
-
-## 5. Plan de implementación
-
-### Pasos ordenados
-
-1. **Análisis de `workflow.init` y `constitution.agents_behavior`**
-   - Descripción: Revisar cómo se cargan las reglas hoy y dónde insertar la instrucción "Blocker".
-   - Entregables: Propuesta de cambio en texto.
-
-2. **Modificación de `workflow.init`**
-   - Descripción: Inyectar una sección de "Orquestación y Disciplina" en el prompt del workflow o cargar una regla específica `rules.orchestration_discipline` si se considera mejor.
-   - Entregables: `workflow.init.md` actualizado.
-
-### Verificación prevista
-- Tipo de tests: Manual (Review del diff y ejecución de prueba del init).
-- Criterios de éxito: El LLM reconoce explícitamente estas restricciones al ejecutar init.
-
----
-
-## 6. Aprobación del desarrollador (OBLIGATORIA)
-
-```yaml
-approval:
-  developer:
-    decision: SI | NO
-    date: <ISO-8601>
-    comments: <opcional>
-```

package/dist/artifacts/2026-01-19-orchestration-init/closure.md

@@ -1,80 +0,0 @@
----
-artifact: closure
-phase: short-phase-3-closure
-owner: architect-agent
-status: draft
-related_task: 2026-01-19-orchestration-init
----
-
-# Closure — 2026-01-19-orchestration-init
-
-## 1. Resumen de la tarea
-
-**Título**: Analyze Orchestration Rules Injection in Init
-**Estrategia**: Short
-**Estado final**: ☑ Completada ☐ Abortada
-
----
-
-## 2. Verificación
-
-### Tests ejecutados
-
-| Tipo | Comando/Método | Resultado |
-|------|----------------|-----------|
-| Unit | N/A | ☐ Pass ☐ Fail ☑ N/A |
-| Integration | N/A | ☐ Pass ☐ Fail ☑ N/A |
-| E2E | Manual Init Test | ☑ Pass ☐ Fail ☐ N/A |
-
-### Justificación (si no hay tests)
-La tarea consistía en una modificación textual de un workflow (`workflow.init`). La verificación fue manual, revisando el diff y visualizando el renderizado final para asegurar claridad.
-
----
-
-## 3. Estado de Acceptance Criteria
-
-| AC | Descripción | Estado |
-|----|-------------|--------|
-| 1 | Modificar `workflow.init` con instrucciones explícitas | ☑ ✅ ☐ ❌ |
-| 2 | Entradas: `workflow.init.md` y `agents_behavior` | ☑ ✅ ☐ ❌ |
-| 3 | Salidas: `workflow.init` reforzado | ☑ ✅ ☐ ❌ |
-| 4 | Restricciones: No aumentar excesivamente contexto (añadido ~15 líneas) | ☑ ✅ ☐ ❌ |
-| 5 | Criterio de Done: Verificación visual | ☑ ✅ ☐ ❌ |
-
----
-
-## 4. Cambios realizados
-
-### Ficheros modificados/creados
-
-| Fichero | Acción | Descripción |
-|---------|--------|-------------|
-| `.agent/workflows/init.md` | Modified | Inyección de sección `Orquestación y Disciplina`. |
-
-### Commits (si aplica)
-
-```
-docs(workflow): inject orchestration rules into init workflow
-```
-
----
-
-## 5. Aceptación final del desarrollador (OBLIGATORIA)
-
-```yaml
-approval:
-  developer:
-    decision: SI
-    date: 2026-01-19T08:09:29+01:00
-    comments: Score: 8
-
----
-
-## 6. Push final (si aplica)
-
-```yaml
-push:
-  approved: SI
-  branch: main
-  date: 2026-01-19T08:09:29+01:00
-```

package/dist/artifacts/2026-01-19-orchestration-init/implementation.md

@@ -1,20 +0,0 @@
-# Implementation Report — 2026-01-19-orchestration-init
-
-## Changes Realized
-1.  **Modified `workflow.init.md`**:
-    - Injected new section `## Orquestación y Disciplina (SYSTEM INJECTION)`.
-    - Added 3 core meta-rules:
-        1.  **Respeto Absoluto a Gates**: Explicit prohibition of implicit approvals.
-        2.  **Identidad de Roles**: Mandatory role switching and labeling.
-        3.  **Prioridad de Proceso**: Process integrity > Task speed.
-
-## Files Modified
-- `.agent/workflows/init.md`
-
-## Architectural Review
-- **Consistency**: The changes align with strict agentic behavior requirements defined in `constitution.agents_behavior` without modifying the constitution itself, but enforcing it at the entry point.
-- **Context Impact**: The added text is concise (~15 lines) and high-value, justifying the minimal context cost.
-- **Risk**: Low risk of regression. High potential for behavioral improvement.
-
-## State
-**APPROVED**

package/dist/artifacts/21-portable-agentic-system/researcher/research.md

@@ -1,121 +0,0 @@
----
-artifact: research
-phase: phase-1-research
-owner: researcher-agent
-status: draft
-related_task: 21-portable-agentic-system
----
-
-# Research Report — 21-portable-agentic-system
-
-> [!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**: Cómo distribuir el sistema de orquestación agéntica de Extensio como un paquete npm independiente y agnóstico.
-- **Objetivo de la investigacion**: Identificar la estructura de empaquetado, herramientas de CLI para scaffolding y puntos de acoplamiento con el framework Extensio.
-- **Principales hallazgos**: Existen librerías modernas como `@clack/prompts` para interfaces CLI premium. El sistema `.agent` tiene dependencias directas en constituciones de Extensio que deben ser "neutralizadas".
-
----
-
-## 2. Necesidades detectadas
-- **Portabilidad**: El sistema debe funcionar en cualquier proyecto mediante un comando `init`.
-- **CLI (`agentic-workflow`)**: Necesidad de una herramienta que gestione la instalación de la estructura `.agent` y el archivo `AGENTS.md`.
-- **Desacoplamiento**: Eliminar referencias a "Extensio", "mcp-extensio-cli", y constituciones específicas de extensiones.
-- **Asistente de configuración**: Un wizard interactivo para guiar al usuario en la configuración inicial y personalización de roles.
-
----
-
-## 3. Hallazgos técnicos
-- **CLI Frameworks**:
-  - `@clack/prompts`: Usado por herramientas como Astro y T3. Ofrece una UX minimalista y estética.
-  - `Commander.js`: Estándar para definición de comandos y argumentos.
-- **Scaffolding**:
-  - `fs-extra`: Para copiado recursivo de directorios de plantillas.
-  - `Handlebars`: Para inyectar variables (nombre del proyecto, autor) en los archivos `.md` portados.
-- **Configuración Persistente**:
-  - `conf`: Librería para persistir configuraciones globales del usuario si fuera necesario.
-
----
-
-## 4. APIs Web / WebExtensions relevantes
-- No aplica (lógica de archivos locales y empaquetado npm).
-
----
-
-## 5. Compatibilidad multi-browser
-- No aplica directamente, pero el sistema debe ser compatible con entornos Node.js >= 18.
-
----
-
-## 6. Oportunidades AI-first detectadas
-- **Detección automática de contexto**: El CLI podría intentar detectar el tipo de proyecto (react, node, etc.) para sugerir roles específicos.
-- **Validación de MCP**: Capacidad de verificar si el entorno tiene acceso a los servidores MCP declarados en `rules/roles`.
-
----
-
-## 7. Hallazgo: Consistencia Fase-Artefacto (1:1)
-- **Deficiencia detectada**: La Fase 0 actualmente no produce un artefacto independiente, lo que dificulta la validación automatizada de Gates y sobrecarga el `task.md`.
-- **Propuesta**: Crear un template dedicado `templates.acceptance` que genere un archivo `acceptance.md` por cada tarea.
-
-### Draft: templates.acceptance (v1.0.0)
-```markdown
-# Acceptance Criteria — {{task.id}}-{{task.title}}
-
-## 1. Definición Consolidada
-{{consolidated_definition}}
-
-## 2. Respuestas a Preguntas de Clarificación
-| # | Pregunta | Respuesta |
-|---|----------|-----------|
-| 1 | {{q1}} | {{a1}} |
-| 2 | {{q2}} | {{a2}} |
-| 3 | {{q3}} | {{a3}} |
-| 4 | {{q4}} | {{a4}} |
-| 5 | {{q5}} | {{a5}} |
-
-## 3. Criterios de Aceptación Verificables
-- [ ] **Funcionalidad**: {{criteria.functionality}}
-- [ ] **Datos/Entradas**: {{criteria.data}}
-- [ ] **Resultado/Salida**: {{criteria.output}}
-- [ ] **Restricciones**: {{criteria.constraints}}
-
-## 4. Definición de "Done"
-{{definition_of_done}}
-
----
-## Aprobación (Gate 0)
-```yaml
-approval:
-  developer:
-    decision: null
-    date: null
-```
-
----
-
-## 8. Riesgos identificados
-- **Riesgo: Degradación del Proceso**: Al facilitar la personalización, se corre el riesgo de que el usuario elimine Gates críticos, invalidando la robustez del sistema. (Severidad: Alta).
-- **Riesgo: Dependencias de MCP**: Si el sistema depende de herramientas de Antigravity/Gemini específicas, su uso en otros IDEs podría verse limitado. (Severidad: Media).
-- **Riesgo: "Template Drift"**: Dificultad para actualizar la estructura `.agent` en proyectos que ya han sido inicializados y personalizados. (Severidad: Baja).
-
----
-
-## 9. Fuentes
-- [Clack documentation](https://github.com/natemoo-re/clack)
-- [Commander.js docs](https://github.com/tj/commander.js)
-- `.agent/workflows/tasklifecycle-long/` (referencia de arquitectura actual)
-- Tarea 6: "Exportar ciclo .agent a zip" (antecedente de portabilidad)
-
----
-
-## 10. Aprobación del desarrollador (OBLIGATORIA)
-```yaml
-approval:
-  developer:
-    decision: null
-    date: null
-    comments: null
-```