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

package/dist/artifacts/12-adaptacion-core-cli-surfaces/task.md

@@ -1,167 +0,0 @@
-# Task
-
-## Identificación
-- id: 12
-- title: adaptacion-core-cli-surfaces
-- scope: current
-- owner: architect-agent
-
-## Origen
-- created_from:
-  - workflow: tasklifecycle
-  - source: init
-  - candidate_path: artifacts.candidate.task
-
-## Descripción de la tarea
-Verificar qué cambios a nivel de core (`@extensio/core`) y CLI (`extensio-cli`) son necesarios para adaptarse a la nueva arquitectura de Pages y Shards (Surfaces).
-
-## Objetivo
-Analizar el estado actual de `@extensio/core` y `extensio-cli`, contrastarlos con las constituciones de Pages y Shards recientemente definidas, e identificar:
-- Gaps de implementación en core (Surface base class, lifecycle hooks, exports)
-- Gaps en CLI (generadores, templates, comandos)
-- Cambios de breaking/non-breaking necesarios
-- Orden de implementación recomendado
-
-## Estado del ciclo de vida (FUENTE ÚNICA DE VERDAD)
-
-```yaml
-task:
-  id: "12"
-  title: "adaptacion-core-cli-surfaces"
-  phase:
-    current: "phase-4-implementation"
-    validated_by: "architect-agent"
-    updated_at: "2026-01-14T08:07:44+01:00"
-  lifecycle:
-    phases:
-      phase-0-acceptance-criteria:
-        completed: true
-        validated_by: architect-agent
-        validated_at: "2026-01-14T07:18:46+01:00"
-      phase-1-research:
-        completed: true
-        validated_by: architect-agent
-        validated_at: "2026-01-14T07:26:50+01:00"
-      phase-2-analysis:
-        completed: true
-        validated_by: architect-agent
-        validated_at: "2026-01-14T08:03:49+01:00"
-      phase-3-planning:
-        completed: true
-        validated_by: architect-agent
-        validated_at: "2026-01-14T08:07:44+01:00"
-      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 alcance exacto de "Surfaces"? ¿Incluye únicamente Pages y Shards, o también otros componentes visuales como popups, sidepanels u offscreen documents? | Solo Surfaces ya que con ambos Pages y Shards se pueden construir cualquier elemento visual |
-| 2 | ¿Existe ya una clase base `Surface` en core? ¿O debe crearse desde cero? Si existe, ¿qué funcionalidad tiene actualmente vs. lo que necesita según la constitución? | Sí existe, revisarlo para validar conformidad con constitución |
-| 3 | ¿Los lifecycle hooks (`onMount`, `onUnmount`) deben ser uniformes para Pages y Shards, o cada uno puede tener hooks específicos adicionales? | Sí deben ser a nivel de Surface (uniformes) |
-| 4 | ¿Qué nivel de cambios es aceptable en CLI? ¿Solo ajustes a templates existentes, o también nuevos comandos/generadores? | Lo necesario para que se pueda construir Pages y Shards correctamente sin fallos |
-| 5 | ¿Hay una demo existente que deba validar la nueva arquitectura? ¿O se debe crear una nueva demo específica? | Sí, en core existe carpeta demo. Borrar la actual y construir una nueva con el CLI, validar mediante E2E y Unit test de que todo es funcional en Chrome, Firefox y Safari |
-
----
-
-## Acceptance Criteria (OBLIGATORIO PARA CURRENT TASK)
-
-### 1. Alcance
-- Surfaces = Pages + Shards únicamente
-- La clase base `Surface` debe definir hooks uniformes que heredan tanto `Page` como `Shard`
-- No se contemplan otros tipos de componentes visuales en este alcance
-
-### 2. Entradas / Datos
-- Código actual de `@extensio/core`:
-  - `src/surface/surface.mts` (clase Surface existente)
-  - `src/surface/pages/index.mts` (clase Page existente)
-  - `src/surface/shards/index.mts` (clase Shard existente)
-- Código actual del CLI (`extensio-cli`):
-  - Generadores de modules, drivers
-  - Plugins de build (surface-pages, surface-shards)
-- Constituciones definidas:
-  - `constitution.pages` (v2.1.0)
-  - `constitution.shards` (v2.0.0)
-- Demo actual en `packages/core/demo/`
-
-### 3. Salidas / Resultado esperado
-- **Informe de gaps** documentando:
-  - Gaps entre implementación actual y constitución (core)
-  - Gaps en CLI (comandos, templates, plugins)
-  - Lista priorizada de cambios con clasificación breaking/non-breaking
-- **Core actualizado** (si aplica):
-  - Clase `Surface` con hooks `onMount()`, `onUnmount()` uniformes
-  - Clase `Page` conforme a constitución
-  - Clase `Shard` conforme a constitución
-  - Exports en `package.json` alineados
-- **CLI actualizado** (si aplica):
-  - Generadores `extensio create page`, `extensio create shard`
-  - Templates conformes a constitución
-  - Plugins de build funcionales
-- **Nueva demo** en `packages/core/demo/`:
-  - Construida con CLI
-  - Demuestra Pages y Shards funcionando
-  - Tests E2E y Unit pasando en Chrome, Firefox, Safari
-
-### 4. Restricciones
-- No mezclar lógica de negocio en Surfaces (solo UI)
-- Lifecycle hooks deben definirse en `Surface`, no duplicarse en subclases
-- La demo debe ser creada con el CLI, no manualmente
-- Tests deben pasar en los 3 navegadores antes de considerar la tarea completa
-
-### 5. Criterio de aceptación (Done)
-- [ ] Informe de gaps documentado
-- [ ] Clase `Surface` con hooks uniformes (`onMount`, `onUnmount`)
-- [ ] Clase `Page` hereda de `Surface` y cumple constitución
-- [ ] Clase `Shard` hereda de `Surface` y cumple constitución (nota: actualmente hereda de `Core`, hay gap potencial)
-- [ ] CLI puede generar Pages con `extensio create page`
-- [ ] CLI puede generar Shards con `extensio create shard`
-- [ ] Demo eliminada y reconstruida con CLI
-- [ ] Tests unitarios pasan
-- [ ] Tests E2E pasan en Chrome, Firefox, Safari
-- [ ] Build sin errores para los 3 navegadores
-
-## Historial de validaciones (append-only)
-```yaml
-history:
-  - phase: "phase-0-acceptance-criteria"
-    action: "completed"
-    validated_by: "architect-agent"
-    timestamp: "2026-01-14T07:18:46+01:00"
-    notes: "Acceptance criteria definidos. Se identificó un gap potencial: Shard hereda de Core, no de Surface."
-  - phase: "phase-1-research"
-    action: "completed"
-    validated_by: "architect-agent"
-    timestamp: "2026-01-14T07:26:50+01:00"
-    notes: "Research completado y aprobado. Gaps críticos identificados: Shard hereda Core no Surface, no hay comandos CLI para page/shard, demo incompleta."
-```
-
-## 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/artifacts/13-dual-lifecycle-system/analysis.md

@@ -1,173 +0,0 @@
----
-artifact: analysis
-phase: phase-2-analysis
-owner: architect-agent
-status: approved
-related_task: 13-dual-lifecycle-system
----
-
-# Analysis — 13-dual-lifecycle-system
-
-## 1. Resumen ejecutivo
-
-**Problema**
-El ciclo de vida actual (`tasklifecycle`) impone 9 fases obligatorias para cualquier tarea, generando overhead innecesario para tareas simples. El desarrollador necesita flexibilidad operativa.
-
-**Objetivo**
-Implementar un sistema dual (Long/Short) que permita elegir la estrategia adecuada según la complejidad, sin perder la integridad de los gates arquitectónicos.
-
-**Criterio de éxito**
-- El desarrollador puede elegir "Short" durante `init`.
-- El flujo Short completa 3 fases con validación exitosa del arquitecto.
-- El campo `task.strategy` persiste en `task.md` entre sesiones.
-- Los aliases resuelven correctamente en ambos ciclos.
-
----
-
-## 2. Estado del proyecto (As-Is)
-
-### Estructura relevante
-```
-.agent/
-├── workflows/
-│   ├── init.md
-│   ├── index.md
-│   └── tasklifecycle/           # Ciclo actual (9 fases)
-│       ├── index.md
-│       └── phase-[0-8]-*.md
-├── templates/
-│   ├── index.md
-│   └── task.md                   # Sin campo strategy
-└── artifacts/
-    └── index.md
-```
-
-### Limitaciones detectadas
-1. **Naming asimétrico**: Si creamos `tasklifecycle-short`, la carpeta original debería llamarse `tasklifecycle-long` para simetría.
-2. **Sin selector de estrategia**: El workflow `init.md` no tiene paso de selección Long/Short.
-3. **Template incompleto**: `task.md` no tiene campo `strategy`.
-4. **Aliases únicos**: Solo existe namespace para un ciclo.
-
----
-
-## 3. Cobertura de Acceptance Criteria
-
-### AC-1: Modificación de `workflow.init` para incluir el selector
-- **Interpretación**: Añadir un paso tras la confirmación de idioma para preguntar Long/Short.
-- **Verificación**: El agente debe poder ejecutar `init` y recibir la pregunta de estrategia.
-- **Riesgos**: Ninguno identificado.
-
-### AC-2: Creación de workflows y fases Short
-- **Interpretación**: Nueva carpeta `tasklifecycle-short/` con 3 fases y su `index.md`.
-- **Verificación**: Los ficheros existen y los aliases resuelven correctamente.
-- **Riesgos**: Inconsistencia en estructura de gates.
-
-### AC-3: Actualización de `templates.task` con campo `strategy`
-- **Interpretación**: Añadir `task.strategy: long | short` en el bloque YAML.
-- **Verificación**: El template incluye el campo y ambos valores son válidos.
-- **Riesgos**: Breaking change mínimo (los task.md existentes no tienen el campo).
-
-### AC-4: Gates arquitectónicos intactos
-- **Interpretación**: Cada fase Short tiene su propio gate con requisitos explícitos.
-- **Verificación**: Revisar que cada workflow Short tiene sección `## Gate (REQUIRED)`.
-- **Riesgos**: Omitir gates por simplificación excesiva.
-
-### AC-5: Análisis profundo en Short para detectar complejidad
-- **Interpretación**: La fase Brief incluye las 5 preguntas y evaluación de complejidad.
-- **Verificación**: El workflow Short-P1 incluye paso de detección y opción de abortar.
-- **Riesgos**: El desarrollador ignora la recomendación de abortar.
-
----
-
-## 4. Diseño técnico (basado en Research aprobado)
-
-### Rename de carpeta
-| Actual | Nuevo |
-|--------|-------|
-| `tasklifecycle/` | `tasklifecycle-long/` |
-
-### Nuevos ficheros a crear
-1. `.agent/workflows/tasklifecycle-short/index.md`
-2. `.agent/workflows/tasklifecycle-short/short-phase-1-brief.md`
-3. `.agent/workflows/tasklifecycle-short/short-phase-2-implementation.md`
-4. `.agent/workflows/tasklifecycle-short/short-phase-3-closure.md`
-5. `.agent/templates/brief.md`
-6. `.agent/templates/closure.md`
-
-### Ficheros a modificar
-1. `.agent/workflows/tasklifecycle-long/index.md` - Actualizar ID y aliases
-2. `.agent/workflows/init.md` - Añadir selector Long/Short
-3. `.agent/templates/task.md` - Añadir campo `strategy`
-4. `.agent/workflows/index.md` - Registrar ambos ciclos
-5. `.agent/templates/index.md` - Registrar nuevos templates
-
----
-
-## 5. Agentes participantes
-
-### architect-agent (Owner)
-- Responsable de crear los workflows Short.
-- Valida integridad de gates.
-- Ejecuta verificación de aliases.
-
-**No se requieren agentes adicionales** para esta tarea. Es puramente estructural.
-
-### Componentes necesarios
-- **Crear**: 6 ficheros nuevos (workflows + templates).
-- **Modificar**: 5 ficheros existentes.
-- **Eliminar**: Ninguno (rename, no delete).
-
-### Demo
-**No aplica**. Esta tarea modifica el sistema agéntico interno, no requiere demo funcional.
-
----
-
-## 6. Impacto de la tarea
-
-### Arquitectura
-- Introduce dualidad de ciclos (Long/Short).
-- Mantiene compatibilidad total con tareas existentes.
-
-### APIs / contratos
-- Nuevo campo `task.strategy` en el contrato de `task.md`.
-- Nuevos namespaces de aliases: `taskcycle-short.phases.*`.
-
-### Compatibilidad
-- **Breaking change controlado**: El rename de carpeta requiere actualizar referencias.
-- Las tareas existentes (sin `strategy`) se asumen como Long por defecto.
-
-### Testing / verificación
-- **No requiere tests de código** (es configuración de workflows).
-- **Verificación manual**: Ejecutar `init`, elegir Short, completar las 3 fases.
-- **Verificación de aliases**: Cadena de resolución debe funcionar.
-
----
-
-## 7. Riesgos y mitigaciones
-
-| Riesgo | Severidad | Mitigación |
-|--------|-----------|------------|
-| Alias rotos tras rename | ALTA | Verificación obligatoria de cadena de resolución |
-| Subestimar complejidad en Short | ALTA | Brief incluye detección + opción de abortar |
-| Tareas existentes sin `strategy` | MEDIA | Asumir Long por defecto si campo ausente |
-| Inconsistencia de gates | ALTA | Copiar estructura de gates desde ciclo Long |
-
----
-
-## 8. Preguntas abiertas
-Ninguna. Todas las dudas fueron resueltas en Phase 0 y Research.
-
----
-
-## 9. Aprobación
-Este análisis **requiere aprobación explícita del desarrollador**.
-
-```yaml
-approval:
-  developer:
-    decision: SI
-    date: 2026-01-16T00:06:01+01:00
-    comments: Análisis aprobado
-```
-
-> Sin aprobación, esta fase NO puede darse por completada ni avanzar a Phase 3 (Planning).

package/dist/artifacts/13-dual-lifecycle-system/architect/review.md

@@ -1,67 +0,0 @@
----
-artifact: implementation
-phase: phase-4-implementation
-owner: architect-agent
-status: APPROVED
-related_task: 13-dual-lifecycle-system
----
-
-# Architect Review — 13-dual-lifecycle-system
-
-## Resumen de implementación
-
-La implementación del Sistema de Ciclo de Vida Dual (Long/Short) se ha completado siguiendo los 13 pasos definidos en el plan.
-
-## Cambios realizados
-
-### Paso 1: Rename de carpeta
-- ✅ `tasklifecycle/` → `tasklifecycle-long/`
-
-### Pasos 2-3: Actualización de índices
-- ✅ `tasklifecycle-long/index.md` actualizado con nuevas rutas
-- ✅ `workflows/index.md` actualizado con aliases:
-  - `tasklifecycle-long`
-  - `tasklifecycle-short`
-
-### Pasos 4-7: Workflows del ciclo Short
-- ✅ `tasklifecycle-short/index.md` creado
-- ✅ `short-phase-1-brief.md` creado (5 preguntas + detección complejidad)
-- ✅ `short-phase-2-implementation.md` creado
-- ✅ `short-phase-3-closure.md` creado
-
-### Pasos 8-10: Templates
-- ✅ `templates/brief.md` creado
-- ✅ `templates/closure.md` creado
-- ✅ `templates/index.md` actualizado con aliases `brief` y `closure`
-
-### Paso 11: Template task.md
-- ✅ Campo `strategy: "{{task.strategy}}"` añadido
-
-### Paso 12: Workflow init.md
-- ✅ Versión actualizada a 4.0.0
-- ✅ Paso 5: Selector de estrategia Long/Short
-- ✅ Paso 10: Lanzar ciclo correspondiente según strategy
-- ✅ Gate: Incluye verificación de strategy
-
-### Paso 13: Verificación de aliases
-- ✅ `workflows.tasklifecycle-long` resuelve correctamente
-- ✅ `workflows.tasklifecycle-short` resuelve correctamente
-- ✅ `templates.brief` resuelve correctamente
-- ✅ `templates.closure` resuelve correctamente
-
-## Coherencia con el plan
-
-| Criterio | Estado |
-|----------|--------|
-| Rename de carpeta | ✅ |
-| 4 workflows Short + index | ✅ |
-| 2 templates nuevos | ✅ |
-| Campo strategy en task.md | ✅ |
-| Selector en init.md | ✅ |
-| Verificación de aliases | ✅ |
-
-## Decisión
-
-**Estado: APROBADO**
-
-La implementación es coherente con el plan aprobado. Todos los ficheros están en su ubicación correcta y los aliases resuelven sin errores.

package/dist/artifacts/13-dual-lifecycle-system/plan.md

@@ -1,230 +0,0 @@
----
-artifact: plan
-phase: phase-3-planning
-owner: architect-agent
-status: approved
-related_task: 13-dual-lifecycle-system
----
-
-# Implementation Plan — 13-dual-lifecycle-system
-
-## 1. Resumen del plan
-
-**Contexto**: El sistema agéntico actual solo soporta un ciclo de vida de 9 fases (Long). El desarrollador necesita un ciclo simplificado (Short) de 3 fases para tareas de baja complejidad.
-
-**Resultado esperado**:
-- Selector funcional Long/Short en el proceso `init`.
-- Carpeta `tasklifecycle-long/` (renombrada desde `tasklifecycle/`).
-- Nueva carpeta `tasklifecycle-short/` con 3 fases.
-- Campo `task.strategy` en el template de tareas.
-- Aliases verificados y funcionales para ambos ciclos.
-
-**Alcance**:
-- ✅ Incluye: rename, workflows Short, templates, modificación de init, verificación de aliases.
-- ❌ Excluye: modificaciones al comportamiento del ciclo Long, tests automatizados (no hay código funcional).
-
----
-
-## 2. Inputs contractuales
-
-- **Task**: `.agent/artifacts/13-dual-lifecycle-system/task.md`
-- **Analysis**: `.agent/artifacts/13-dual-lifecycle-system/analysis.md`
-- **Research**: `.agent/artifacts/13-dual-lifecycle-system/researcher/research.md`
-
-**Dispatch de dominios**
-```yaml
-plan:
-  workflows:
-    drivers:
-      action: none
-  dispatch: []
-```
-> No se requiere dispatch a otros dominios. Esta tarea es puramente estructural.
-
----
-
-## 3. Desglose de implementación (pasos)
-
-### Paso 1: Rename de carpeta tasklifecycle
-- **Descripción**: Renombrar `.agent/workflows/tasklifecycle/` → `.agent/workflows/tasklifecycle-long/`
-- **Dependencias**: Ninguna.
-- **Entregables**: Carpeta renombrada.
-- **Agente**: architect-agent
-- **Herramienta**: Terminal (`mv` command)
-
-### Paso 2: Actualizar index.md de tasklifecycle-long
-- **Descripción**: Cambiar el ID del workflow y las rutas de aliases para reflejar la nueva ubicación.
-- **Dependencias**: Paso 1.
-- **Entregables**: `.agent/workflows/tasklifecycle-long/index.md` actualizado.
-- **Agente**: architect-agent
-
-### Paso 3: Actualizar workflows/index.md
-- **Descripción**: Cambiar alias `tasklifecycle` → `tasklifecycle-long` y añadir alias `tasklifecycle-short`.
-- **Dependencias**: Paso 1.
-- **Entregables**: `.agent/workflows/index.md` actualizado.
-- **Agente**: architect-agent
-
-### Paso 4: Crear carpeta tasklifecycle-short
-- **Descripción**: Crear directorio y fichero `index.md` con aliases de las 3 fases.
-- **Dependencias**: Paso 3.
-- **Entregables**: `.agent/workflows/tasklifecycle-short/index.md`
-- **Agente**: architect-agent
-
-### Paso 5: Crear workflow short-phase-1-brief.md
-- **Descripción**: Workflow que fusiona Acceptance + Analysis + Planning. Incluye 5 preguntas obligatorias y detección de complejidad.
-- **Dependencias**: Paso 4.
-- **Entregables**: `.agent/workflows/tasklifecycle-short/short-phase-1-brief.md`
-- **Agente**: architect-agent
-
-### Paso 6: Crear workflow short-phase-2-implementation.md
-- **Descripción**: Workflow equivalente a P4 del ciclo Long. Incluye gate de revisión arquitectónica.
-- **Dependencias**: Paso 4.
-- **Entregables**: `.agent/workflows/tasklifecycle-short/short-phase-2-implementation.md`
-- **Agente**: architect-agent
-
-### Paso 7: Crear workflow short-phase-3-closure.md
-- **Descripción**: Workflow que fusiona Verification + Results + Commit. Incluye gate final y aprobación del desarrollador.
-- **Dependencias**: Paso 4.
-- **Entregables**: `.agent/workflows/tasklifecycle-short/short-phase-3-closure.md`
-- **Agente**: architect-agent
-
-### Paso 8: Crear template brief.md
-- **Descripción**: Template para el artefacto de la fase Brief (fusión de analysis + planning simplificados).
-- **Dependencias**: Paso 5.
-- **Entregables**: `.agent/templates/brief.md`
-- **Agente**: architect-agent
-
-### Paso 9: Crear template closure.md
-- **Descripción**: Template para el artefacto de la fase Closure (fusión de verification + results).
-- **Dependencias**: Paso 7.
-- **Entregables**: `.agent/templates/closure.md`
-- **Agente**: architect-agent
-
-### Paso 10: Actualizar templates/index.md
-- **Descripción**: Registrar aliases para `brief` y `closure`.
-- **Dependencias**: Pasos 8 y 9.
-- **Entregables**: `.agent/templates/index.md` actualizado.
-- **Agente**: architect-agent
-
-### Paso 11: Actualizar template task.md
-- **Descripción**: Añadir campo `task.strategy: long | short` en el bloque YAML del template.
-- **Dependencias**: Ninguna (puede ser paralelo).
-- **Entregables**: `.agent/templates/task.md` actualizado.
-- **Agente**: architect-agent
-
-### Paso 12: Modificar init.md
-- **Descripción**: Añadir paso de selección de estrategia (Long/Short) tras la confirmación de idioma.
-- **Dependencias**: Pasos 3 y 11.
-- **Entregables**: `.agent/workflows/init.md` actualizado.
-- **Agente**: architect-agent
-
-### Paso 13: Verificación de aliases
-- **Descripción**: Verificar que la cadena de resolución de aliases funciona para ambos ciclos.
-- **Dependencias**: Todos los pasos anteriores.
-- **Entregables**: Checklist de verificación completado.
-- **Agente**: architect-agent
-
----
-
-## 4. Asignación de responsabilidades
-
-### architect-agent (Único responsable)
-- Ejecutar todos los pasos.
-- Validar integridad de gates en workflows Short.
-- Ejecutar verificación de aliases.
-
-**No se requieren otros agentes** para esta tarea.
-
----
-
-## 5. Estrategia de testing y validación
-
-### Tests automatizados
-**No aplica**. Esta tarea modifica ficheros de configuración del sistema agéntico, no código funcional. No existe suite de tests para workflows.
-
-### Verificación manual (OBLIGATORIA)
-1. **Verificar rename**: Confirmar que la carpeta `tasklifecycle-long/` existe y la antigua no.
-2. **Verificar aliases Long**: 
-   - Resolver `.agent/index.md` → `workflows.index` → `tasklifecycle-long.index` → `phase_0.workflow`
-   - El fichero debe existir y ser legible.
-3. **Verificar aliases Short**:
-   - Resolver `.agent/index.md` → `workflows.index` → `tasklifecycle-short.index` → `short_phase_1.workflow`
-   - El fichero debe existir y ser legible.
-4. **Verificar templates**: Confirmar que `templates.brief` y `templates.closure` resuelven correctamente.
-5. **Verificar init.md**: Confirmar que el paso de selección de estrategia está presente.
-6. **Verificar task.md template**: Confirmar que el campo `task.strategy` está presente en el YAML.
-
-### Trazabilidad
-| Acceptance Criteria | Verificación |
-|---------------------|--------------|
-| AC-1: Selector en init | Verificación manual #5 |
-| AC-2: Workflows Short | Verificación manual #3 |
-| AC-3: Campo strategy | Verificación manual #6 |
-| AC-4: Gates intactos | Revisión de secciones Gate en workflows |
-| AC-5: Detección complejidad | Revisión de short-phase-1-brief.md |
-
----
-
-## 6. Plan de demo
-**No aplica**. Esta tarea modifica el sistema agéntico interno.
-
----
-
-## 7. Estimaciones
-
-| Paso | Esfuerzo |
-|------|----------|
-| P1-P3: Rename y actualización de índices | Bajo |
-| P4-P7: Creación de workflows Short | Medio |
-| P8-P10: Templates y registros | Bajo |
-| P11-P12: Modificación de task y init | Bajo |
-| P13: Verificación | Bajo |
-
-**Total estimado**: ~30-40 tool calls de implementación.
-
----
-
-## 8. Puntos críticos y resolución
-
-| Punto crítico | Riesgo | Resolución |
-|---------------|--------|------------|
-| Alias rotos tras rename | Referencias hardcodeadas a la ruta antigua | Buscar y reemplazar todas las ocurrencias |
-| Gates inconsistentes en Short | Fases sin validación adecuada | Copiar estructura de gates desde ciclo Long |
-| Detección de complejidad insuficiente | Tareas complejas ejecutadas en Short | Incluir criterios explícitos en Brief |
-
----
-
-## 9. Dependencias y compatibilidad
-
-**Dependencias internas**:
-- Sistema de índices (`.agent/index.md` y subdominios).
-- Arquitectura de workflows existente.
-
-**Dependencias externas**: Ninguna.
-
-**Compatibilidad entre navegadores**: No aplica (no es código de extensión).
-
----
-
-## 10. Criterios de finalización (Done)
-
-- [ ] Carpeta `tasklifecycle-long/` existe con aliases actualizados.
-- [ ] Carpeta `tasklifecycle-short/` existe con 3 workflows + index.
-- [ ] Templates `brief.md` y `closure.md` creados y registrados.
-- [ ] Campo `task.strategy` añadido al template `task.md`.
-- [ ] Selector Long/Short funcional en `init.md`.
-- [ ] Verificación de cadena de aliases completada sin errores.
-
----
-
-## 11. Aprobación del desarrollador (OBLIGATORIA)
-
-```yaml
-approval:
-  developer:
-    decision: SI
-    date: 2026-01-16T07:48:25+01:00
-    comments: Plan aprobado
-```
-
-> Sin aprobación, esta fase NO puede darse por completada ni avanzar a Phase 4 (Implementation).