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

package/dist/artifacts/19-refinar-sistema-agentes-ciclo-vida/plan.md

@@ -1,203 +0,0 @@
----
-artifact: plan
-phase: phase-3-planning
-owner: architect-agent
-status: draft
-related_task: 19-refinar-sistema-agentes-ciclo-vida
----
-
-# Implementation Plan — 19-refinar-sistema-agentes-ciclo-vida
-
-## 1. Resumen del plan
-
-🏛️ **architect-agent**: Plan de implementación basado en [analysis.md](file:///Users/milos/Documents/workspace/extensio/.agent/artifacts/19-refinar-sistema-agentes-ciclo-vida/analysis.md) (Alternativa B aprobada).
-
-- **Contexto**: Refactorizar el sistema de agentes para separar Research de Análisis, integrar TODO backlog, y reforzar la estructura de subtareas.
-- **Resultado esperado**: Workflows y templates actualizados siguiendo best practices de LLM prompting.
-- **Alcance**: 
-  - ✅ Incluye: 2 workflows, 2 templates modificados, 2 artefactos nuevos
-  - ❌ Excluye: Código funcional, cambios en constitution, nuevos agentes
-
----
-
-## 2. Inputs contractuales
-
-- **Task**: [task.md](file:///Users/milos/Documents/workspace/extensio/.agent/artifacts/19-refinar-sistema-agentes-ciclo-vida/task.md)
-- **Analysis**: [analysis.md](file:///Users/milos/Documents/workspace/extensio/.agent/artifacts/19-refinar-sistema-agentes-ciclo-vida/analysis.md)
-- **Research**: [research.md](file:///Users/milos/Documents/workspace/extensio/.agent/artifacts/19-refinar-sistema-agentes-ciclo-vida/researcher/research.md)
-
-**Dispatch de dominios**
-```yaml
-plan:
-  workflows:
-    drivers:
-      action: none
-  dispatch:
-    - domain: core
-      action: none
-```
-
-> No se requiere dispatch a dominios específicos; todos los cambios son en `.agent/`.
-
----
-
-## 3. Desglose de implementación
-
-### Tarea 1: Refactorizar template research.md
-| Campo | Valor |
-|-------|-------|
-| **Objetivo** | Eliminar secciones de análisis del template de research |
-| **Agente** | architect-agent |
-| **Dependencias** | Ninguna |
-| **Entregables** | `templates/research.md` modificado |
-| **Cambios** | Renombrar "Alternativas técnicas" → "Hallazgos técnicos", eliminar "Decisión recomendada" |
-
----
-
-### Tarea 2: Refactorizar template analysis.md
-| Campo | Valor |
-|-------|-------|
-| **Objetivo** | Añadir consulta obligatoria a TODO backlog |
-| **Agente** | architect-agent |
-| **Dependencias** | Ninguna |
-| **Entregables** | `templates/analysis.md` modificado |
-| **Cambios** | Añadir sección "TODO Backlog (Consulta obligatoria)" antes de Aprobación |
-
----
-
-### Tarea 3: Actualizar workflow phase-1-research.md
-| Campo | Valor |
-|-------|-------|
-| **Objetivo** | Reforzar que Research es solo documentación sin análisis |
-| **Agente** | architect-agent |
-| **Dependencias** | Tarea 1 completada |
-| **Entregables** | `workflows/tasklifecycle-long/phase-1-research.md` modificado |
-| **Cambios** | Añadir regla PERMANENT: "Research documenta, NO analiza" |
-
----
-
-### Tarea 4: Actualizar workflow phase-2-analysis.md
-| Campo | Valor |
-|-------|-------|
-| **Objetivo** | Hacer obligatoria la consulta a TODO backlog |
-| **Agente** | architect-agent |
-| **Dependencias** | Tarea 2 y Tarea 5 completadas |
-| **Entregables** | `workflows/tasklifecycle-long/phase-2-analysis.md` modificado |
-| **Cambios** | Añadir paso 4.5: "Consultar .agent/todo/" |
-
----
-
-### Tarea 5: Crear estructura TODO backlog
-| Campo | Valor |
-|-------|-------|
-| **Objetivo** | Crear template y README para backlog de mejora continua |
-| **Agente** | architect-agent |
-| **Dependencias** | Ninguna |
-| **Entregables** | `templates/todo-item.md`, `.agent/todo/README.md` |
-| **Cambios** | Nuevos ficheros |
-
----
-
-### Tarea 6: Validación final (QA)
-| Campo | Valor |
-|-------|-------|
-| **Objetivo** | Verificar que todos los cambios cumplen AC |
-| **Agente** | qa-agent |
-| **Dependencias** | Tareas 1-5 completadas |
-| **Entregables** | Informe de validación manual |
-| **Verificaciones** | Revisar templates, workflows, estructura TODO |
-
----
-
-## 4. Asignación de responsabilidades
-
-| Agente | Tareas | Responsabilidad |
-|--------|--------|-----------------|
-| **architect-agent** | 1, 2, 3, 4, 5 | Implementar cambios en templates y workflows |
-| **qa-agent** | 6 | Validar cumplimiento de acceptance criteria |
-
-**Handoffs**:
-- Tareas 1-5: architect-agent → qa-agent (cuando todas estén completadas)
-- Tarea 6: qa-agent → architect-agent (informe de validación)
-
-**Componentes**: No aplica (no hay drivers/módulos).
-
-**Demo**: No aplica (cambios internos al sistema agéntico).
-
----
-
-## 5. Estrategia de testing y validación
-
-| Tipo | Estrategia |
-|------|------------|
-| **Unit tests** | N/A (no hay código) |
-| **Integration tests** | N/A |
-| **Manual** | qa-agent revisa estructura de templates y workflows |
-
-**Trazabilidad**:
-| AC | Tarea | Verificación |
-|----|-------|--------------|
-| AC1 | 1, 3 | Template research sin análisis |
-| AC2 | 2, 4 | Workflow analysis consulta TODO |
-| AC3-5 | - | Ya implementado |
-| AC6 | 5 | Estructura TODO creada |
-
----
-
-## 6. Plan de demo
-
-No aplica — los cambios son internos al sistema agéntico y no tienen componente visual.
-
----
-
-## 7. Estimaciones
-
-| Tarea | Esfuerzo | Estimación |
-|-------|----------|------------|
-| 1 | Bajo | 5 min |
-| 2 | Bajo | 5 min |
-| 3 | Medio | 10 min |
-| 4 | Medio | 10 min |
-| 5 | Bajo | 10 min |
-| 6 | Bajo | 15 min |
-| **Total** | - | ~55 min |
-
----
-
-## 8. Puntos críticos y resolución
-
-| Punto crítico | Riesgo | Mitigación |
-|---------------|--------|------------|
-| Templates modificados rompen tareas en curso | Bajo | No hay tareas en curso usando estos templates |
-| Workflows modificados invalidan fases futuras | Bajo | Los cambios son aditivos, no eliminan funcionalidad |
-
----
-
-## 9. Dependencias
-
-- **Internas**: Ninguna (todos los ficheros existen)
-- **Externas**: Ninguna
-- **Compatibilidad navegadores**: N/A
-
----
-
-## 10. Criterios de finalización
-
-- [ ] `templates/research.md` no contiene secciones de análisis
-- [ ] `templates/analysis.md` incluye consulta TODO
-- [ ] `phase-1-research.md` refuerza "solo documentación"
-- [ ] `phase-2-analysis.md` incluye paso de consulta TODO
-- [ ] `.agent/todo/README.md` y `templates/todo-item.md` existen
-- [ ] qa-agent valida todos los cambios
-
----
-
-## 11. Aprobación del desarrollador (OBLIGATORIA)
-
-```yaml
-approval:
-  developer:
-    decision: SI
-    date: 2026-01-18T18:30:04+01:00
-    comments: Aprobado
-```

package/dist/artifacts/19-refinar-sistema-agentes-ciclo-vida/researcher/research.md

@@ -1,296 +0,0 @@
----
-artifact: research
-phase: phase-1-research
-owner: researcher-agent
-status: draft
-related_task: 19-refinar-sistema-agentes-ciclo-vida
----
-
-# Research Report — 19-refinar-sistema-agentes-ciclo-vida
-
-## 1. Resumen ejecutivo
-
-🔬 **researcher-agent**: Este informe documenta la investigación técnica sobre:
-- Best practices de prompting para LLMs en sistemas de agentes
-- Patrones de orquestación y delegación de tareas entre agentes AI
-- Estado actual de los workflows del ciclo de vida de Extensio
-- Arquitectura Extensio y su impacto en el sistema de agentes
-
-**Problema investigado**: Los workflows actuales mezclan responsabilidades entre fases (Research vs Análisis), la delegación de tareas no es suficientemente granular, y no existe un backlog de mejora continua integrado.
-
-**Objetivo**: Documentar hallazgos técnicos que permitan al architect-agent analizar y proponer mejoras al sistema de agentes.
-
----
-
-## 2. Necesidades detectadas
-
-### 2.1 Desde los Acceptance Criteria
-1. Separación estricta Research (documentación pura) vs Análisis (propuestas de solución)
-2. Delegación granular: 1 subtarea = 1 objetivo = 1 agente
-3. Gates obligatorios por cada subtarea durante implementación
-4. QA como autoridad auditora que delega correcciones sin modificar código
-5. Backlog TODO integrado en `.agent/todo/` consultable en cada análisis
-
-### 2.2 Desde la Arquitectura Extensio
-Referencia: `constitution.extensio_architecture`
-
-| Principio | Impacto en Sistema de Agentes |
-|-----------|-------------------------------|
-| SRP (Single Responsibility) | Cada agente debe tener una única responsabilidad |
-| Prohibición dependencias cruzadas | Los agentes no deben ejecutar tareas de otros dominios |
-| Reactividad basada en Storage | El estado debe ser persistente y trazable (task.md) |
-| CLI como único punto de entrada | `mcp_extensio-cli` para build/test |
-
----
-
-## 3. Hallazgos: LLM Prompting Best Practices
-
-### 3.1 Claridad y Especificidad (OpenAI Guidelines)
-**Fuente**: [OpenAI Prompt Engineering](https://platform.openai.com/docs/guides/prompt-engineering)
-
-- Proporcionar instrucciones detalladas y sin ambigüedades
-- Definir contexto, resultado esperado, longitud, formato y estilo
-- Evitar lenguaje vago que genere outputs inesperados
-
-> **Aplicación**: Los workflows deben tener secciones con formato explícito (Input/Output/Gate) y no permitir interpretación libre.
-
-### 3.2 Uso de Delimitadores
-**Fuente**: [OpenAI Best Practices](https://platform.openai.com/docs/guides/prompt-engineering/strategy-write-clear-instructions)
-
-- Usar `###`, `"""`, o XML tags para separar instrucciones del contexto
-- Ayuda al modelo a distinguir directivas del contenido a procesar
-
-> **Aplicación**: Los templates de artefactos deben usar secciones claramente delimitadas con headers y bloques YAML.
-
-### 3.3 Descomposición de Tareas Complejas
-**Fuentes**: OpenAI, Palantir, DigitalOcean
-
-- Descomponer tareas complejas en pasos más pequeños y manejables
-- Mejora la precisión del modelo al ejecutar cada paso
-- Evita abrumar al modelo con demasiada información
-
-> **Aplicación**: El Plan debe definir subtareas atómicas con un único objetivo cada una.
-
-### 3.4 Few-Shot Prompting (Ejemplos)
-**Fuentes**: AWS, ElevenLabs, Microsoft
-
-- Incluir ejemplos de alta calidad dentro del prompt
-- Demostrar el comportamiento, formato e intención deseados
-- Mejora el rendimiento respecto a zero-shot
-
-> **Aplicación**: Los templates deben incluir ejemplos concretos de cómo completar cada sección.
-
-### 3.5 Chain of Thought (CoT)
-**Fuentes**: PromptHub, DataCamp, LearnPrompting
-
-| Técnica | Descripción | Uso |
-|---------|-------------|-----|
-| Zero-Shot CoT | Añadir "Let's think step by step" | Tareas simples |
-| Few-Shot CoT | Ejemplos con pasos de razonamiento | Tareas complejas |
-| Auto-CoT | Generación automática de cadenas de razonamiento | Escalabilidad |
-| Tree of Thoughts | Explorar múltiples caminos de razonamiento | Problemas muy complejos |
-
-> **Aplicación**: Los agentes deben documentar su razonamiento antes de tomar decisiones (sección "Reasoning" en agent-tasks).
-
-### 3.6 Outputs Estructurados
-**Fuentes**: AWS, Instill AI, Medium
-
-- Especificar explícitamente el formato requerido (JSON, YAML)
-- Usar prefilling del output para guiar al modelo
-- Implementar validadores post-procesamiento (Pydantic, schemas)
-- Separar pasos de razonamiento de los de estructuración
-
-> **Aplicación**: Todos los artefactos deben tener schema YAML obligatorio con campos requeridos.
-
-### 3.7 Asignación de Roles/Personas
-**Fuentes**: OpenAI, PromptHub, Medium
-
-- Instruir al modelo para adoptar una persona o expertise específica
-- Guía el tono y estilo de respuesta
-- Los Custom GPTs usan "absolute commands" prioritarios
-
-> **Aplicación**: Cada agente tiene un rol definido en `constitution.agents_behavior` con prefijo obligatorio.
-
----
-
-## 4. Hallazgos: Patrones de Orquestación de Agentes
-
-### 4.1 Conductor/Supervisor Pattern (Orquestación Centralizada)
-**Fuentes**: IBM, Kore.ai, Medium
-
-- Un orquestador central (architect-agent) actúa como "cerebro"
-- Recibe request → descompone en subtareas → delega a agentes especializados
-- Monitorea progreso → valida outputs → sintetiza respuesta final
-- Ideal para workflows complejos donde la trazabilidad es crítica
-
-> **Estado actual Extensio**: El architect-agent ya actúa como orquestador, pero la granularidad de delegación es insuficiente.
-
-### 4.2 Assembly Line Pattern (Procesamiento Secuencial)
-**Fuentes**: AI-SDK, Medium
-
-- Ejecución de tareas en orden predefinido y lineal
-- Output de un paso = Input del siguiente
-- Efectivo para secuencias bien definidas
-
-> **Estado actual Extensio**: El ciclo de vida (Phase 0→8) es secuencial, pero las subtareas dentro de cada fase no están formalizadas.
-
-### 4.3 Task Force Pattern (Ejecución Paralela)
-**Fuentes**: AI-SDK, Medium
-
-- Múltiples tareas independientes ejecutadas simultáneamente
-- Útil cuando la velocidad es esencial y no hay dependencias
-
-> **Aplicación potencial**: En Phase 4, subtareas sin dependencias podrían paralelizarse.
-
-### 4.4 Routing/Dynamic Dispatch Pattern
-**Fuentes**: AI-SDK, Amazon
-
-- Un agente inteligente decide qué camino tomar basándose en contexto
-- Actúa como router entre diferentes ramas del workflow
-
-> **Aplicación potencial**: El architect-agent ya hace dispatch a diferentes agentes según el dominio (driver-agent, module-agent, etc.).
-
-### 4.5 Mecanismos de Delegación de Tareas
-**Fuentes**: Kanerika, SAP, LLumo.ai
-
-| Mecanismo | Descripción |
-|-----------|-------------|
-| Contract Net | "Manager" anuncia tarea, "contractors" pujan |
-| Role Assignment | Asignación directa basada en expertise |
-| Negotiation | Agentes negocian usando game theory |
-| Consensus | Algoritmos como Paxos/Raft para estado compartido |
-
-> **Estado actual Extensio**: Se usa Role Assignment directo.
-
----
-
-## 5. Hallazgos: Estado Actual de Workflows Extensio
-
-### 5.1 Phase 1: Research (Actual)
-
-```
-Owner: researcher-agent
-Problema detectado: El workflow NO especifica explícitamente que el research
-debe ser solo documentación sin análisis.
-```
-
-**Secciones actuales del template**:
-- Resumen ejecutivo
-- Necesidades detectadas
-- Alternativas técnicas (INCLUYE pros/cons → esto es análisis)
-- APIs Web/WebExtensions
-- Compatibilidad multi-browser
-- Recomendaciones AI-first (esto es análisis)
-- Riesgos y trade-offs (esto es análisis)
-- Fuentes
-
-**Problema**: Las secciones 3, 6 y 7 mezclan investigación con análisis.
-
-### 5.2 Phase 2: Analysis (Actual)
-
-```
-Owner: architect-agent
-Problema detectado: No referencia explícitamente el TODO backlog.
-```
-
-**Secciones que funcionan bien**:
-- Cobertura de acceptance criteria
-- Definición de agentes y subareas
-- Integración de research aprobado
-
-**Faltan**:
-- Consulta obligatoria a `.agent/todo/`
-- Propuesta de múltiples alternativas con trade-offs claros
-
-### 5.3 Phase 3: Planning (Actual)
-
-```
-Owner: architect-agent
-Problema detectado: Las subtareas no tienen estructura Input/Output/Gate individual.
-```
-
-**Secciones que funcionan bien**:
-- Definición de pasos de implementación
-- Asignación de responsabilidades por agente
-- Estrategia de testing
-
-**Faltan**:
-- Template individual por subtarea
-- Definición explícita de workflows/tools por subtarea
-
-### 5.4 Phase 4: Implementation (Actual)
-
-```
-Owner: architect-agent (delega)
-Estado: Buena estructura con agent-tasks/ y Gate por tarea.
-```
-
-**Funciona bien**:
-- Delegación a ficheros individuales por tarea
-- Gate obligatorio por tarea
-- Informe de revisión arquitectónica
-
-**Posible mejora**:
-- Gestión de TODOs detectados durante implementación
-
-### 5.5 Phase 5: Verification (Actual)
-
-```
-Owner: qa-agent
-Estado: Buena separación de responsabilidades.
-```
-
-**Funciona bien**:
-- QA no corrige código, delega
-- Crea tareas de corrección en agent-tasks/
-- El flujo vuelve a Phase 4 para correcciones
-
----
-
-## 6. Compatibilidad con Arquitectura Extensio
-
-| Componente | Impacto |
-|------------|---------|
-| Workflows (.agent/workflows/) | Modificación de 5 ficheros phase-*.md |
-| Templates (.agent/templates/) | Modificación de research.md, analysis.md; creación de todo.md |
-| Rules (.agent/rules/) | No requiere modificación |
-| Constitution | Ya define SRP, CLI, Clean Code |
-
----
-
-## 7. Fuentes
-
-### Oficiales
-- [OpenAI Prompt Engineering Guide](https://platform.openai.com/docs/guides/prompt-engineering)
-- [OpenAI Best Practices](https://platform.openai.com/docs/guides/prompt-engineering/strategy-write-clear-instructions)
-- [Microsoft Azure Prompt Engineering](https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/prompt-engineering)
-
-### Prestigio Técnico
-- [AWS - Structured Outputs](https://aws.amazon.com/blogs/machine-learning/structured-outputs-llms/)
-- [IBM - AI Agent Orchestration](https://www.ibm.com/think/topics/ai-agents)
-- [LearnPrompting - Chain of Thought](https://learnprompting.org/docs/intermediate/chain_of_thought)
-- [PromptHub - CoT Techniques](https://prompthub.us/blog/chain-of-thought-prompting)
-- [Kanerika - Multi-Agent Coordination](https://www.kanerika.com/articles/multi-agent-systems)
-- [AI-SDK - Workflow Patterns](https://ai-sdk.dev/docs/patterns)
-
-### Documentación Interna Extensio
-- `.agent/rules/constitution/extensio-architecture.md`
-- `.agent/rules/constitution/clean-code.md`
-- `.agent/rules/constitution/agents-behavior.md`
-- `.agent/workflows/tasklifecycle-long/phase-1-research.md`
-- `.agent/workflows/tasklifecycle-long/phase-2-analysis.md`
-- `.agent/workflows/tasklifecycle-long/phase-3-planning.md`
-- `.agent/workflows/tasklifecycle-long/phase-4-implementation.md`
-- `.agent/workflows/tasklifecycle-long/phase-5-verification.md`
-
----
-
-## 8. Aprobación del desarrollador (OBLIGATORIA)
-
-```yaml
-approval:
-  developer:
-    decision: SI
-    date: 2026-01-18T18:23:49+01:00
-    comments: ok
-```

package/dist/artifacts/19-refinar-sistema-agentes-ciclo-vida/task.md

@@ -1,132 +0,0 @@
-# Task: Refinar Sistema de Agentes y Ciclo de Vida
-
-## Identificación
-- id: 19
-- title: refinar-sistema-agentes-ciclo-vida
-- scope: current
-- owner: architect-agent
-
-## Origen
-- created_from:
-  - workflow: tasklifecycle
-  - source: init
-  - candidate_path: artifacts.candidate.task
-
-## Descripción de la tarea
-Optimizar el flujo de desarrollo agéntico del framework Extensio asegurando:
-- Separación estricta entre Research (investigación pura) y Análisis (propuestas de solución)
-- Delegación granular de tareas con aprobación obligatoria del desarrollador
-- Rol auditor del QA que delega correcciones en lugar de aplicarlas
-- Integración del backlog TODO en el ciclo de análisis
-
-## Objetivo
-Tener un flow de desarrollo ayudado por AI y auditado en todo momento por el desarrollador, donde cada fase tiene responsabilidades claras y los LLMs obedecen reglas arquitectónicas de forma estricta.
-
-## Estado del ciclo de vida (FUENTE ÚNICA DE VERDAD)
-
-```yaml
-task:
-  id: "19"
-  title: "refinar-sistema-agentes-ciclo-vida"
-  strategy: "long"
-  phase:
-    current: "phase-8-commit-push"
-    validated_by: "architect-agent"
-    updated_at: "2026-01-18T18:43:42+01:00"
-  lifecycle:
-    phases:
-      phase-0-acceptance-criteria:
-        completed: true
-        validated_by: architect-agent
-        validated_at: "2026-01-18T18:13:40+01:00"
-      phase-1-research:
-        completed: true
-        validated_by: researcher-agent
-        validated_at: "2026-01-18T18:23:49+01:00"
-      phase-2-analysis:
-        completed: true
-        validated_by: architect-agent
-        validated_at: "2026-01-18T18:27:46+01:00"
-      phase-3-planning:
-        completed: true
-        validated_by: architect-agent
-        validated_at: "2026-01-18T18:30:04+01:00"
-      phase-4-implementation:
-        completed: true
-        validated_by: architect-agent
-        validated_at: "2026-01-18T18:41:32+01:00"
-      phase-5-verification:
-        completed: true
-        validated_by: qa-agent
-        validated_at: "2026-01-18T18:42:47+01:00"
-      phase-6-results-acceptance:
-        completed: true
-        validated_by: architect-agent
-        validated_at: "2026-01-18T18:43:42+01:00"
-      phase-7-evaluation:
-        completed: true
-        validated_by: architect-agent
-        validated_at: "2026-01-18T18:43:42+01:00"
-      phase-8-commit-push:
-        completed: true
-        validated_by: architect-agent
-        validated_at: "2026-01-18T18:44:58+01:00"
-```
-
-## 5 Preguntas Obligatorias (Phase 0)
-
-| # | Pregunta | Respuesta |
-|---|----------|-----------|
-| 1 | ¿La investigación debe incluir búsqueda web de best practices para prompting de LLMs, o se limita a documentación interna? | Ambas. Buscar información en web es crucial pero debe ser verídica y de sitios oficiales o de prestigio. |
-| 2 | ¿Cuántas alternativas de solución mínimas debe proponer la fase de Análisis? | Las necesarias según el análisis, ya que depende de la investigación previa. |
-| 3 | ¿Una subtarea puede abarcar múltiples archivos del mismo componente? | Una subtarea debe tener un objetivo único. Si se crea una issue, el objetivo es solucionar ese problema específico. |
-| 4 | ¿Dónde debe residir la lista de TODOs detectados durante la Implementación? | En `.agent/todo/` al mismo nivel que rules. Será el backlog de mejora continua y debe incluirse en cada análisis. |
-| 5 | ¿El agente QA solo ejecuta tests automatizados o también validación manual? | Ambas: tests automatizados (Vitest/Playwright) y validación manual de workflows/reglas. |
-
----
-
-## Acceptance Criteria (OBLIGATORIO)
-
-1. **Alcance**:
-   - Modificar workflows de Phase 1 (Research), Phase 2 (Analysis), Phase 3 (Planning), Phase 4 (Implementation), Phase 5 (Verification)
-   - Crear estructura `.agent/todo/` para backlog de mejora continua
-
-2. **Entradas / Datos**:
-   - Workflows actuales en `.agent/workflows/tasklifecycle-long/`
-   - Templates actuales en `.agent/templates/`
-   - Constituciones en `.agent/rules/constitution/`
-   - Best practices de prompting de LLMs (fuentes oficiales)
-
-3. **Salidas / Resultado esperado**:
-   - Workflows actualizados con separación clara Research vs Análisis
-   - Template de TODO integrado en el ciclo
-   - Rol de QA reforzado como auditor final
-   - Documentación de best practices para obediencia de LLMs
-
-4. **Restricciones**:
-   - Solo fuentes oficiales o de prestigio para investigación web
-   - No romper compatibilidad con tareas existentes
-   - Cada subtarea = un objetivo único
-
-5. **Criterio de aceptación (Done)**:
-   - [ ] Research documenta sin analizar, referenciando arquitectura Extensio
-   - [ ] Análisis propone alternativas basadas exclusivamente en Research
-   - [ ] Plan asigna subtareas con un agente y objetivo únicos
-   - [ ] Implementación requiere Gate por cada subtarea
-   - [ ] QA delega correcciones al Arquitecto sin modificar código
-   - [ ] TODO backlog funcional en `.agent/todo/`
-
-## Historial de validaciones (append-only)
-```yaml
-history:
-  - phase: "phase-0-acceptance-criteria"
-    action: "completed"
-    validated_by: "architect-agent"
-    timestamp: "2026-01-18T18:13:40+01:00"
-    notes: "Acceptance criteria definidos tras 5 preguntas al desarrollador"
-```
-
-## 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`**.
-- Una fase **NO puede marcarse como completed** si no es la fase actual.