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

package/dist/artifacts/13-dual-lifecycle-system/researcher/research.md

@@ -1,243 +0,0 @@
----
-artifact: research
-phase: phase-1-research
-owner: researcher-agent
-status: approved
-related_task: 13-dual-lifecycle-system
----
-
-# Research Report — 13-dual-lifecycle-system
-
-## 1. Resumen ejecutivo
-
-**Problema investigado**: El ciclo de vida actual del sistema agéntico (`tasklifecycle`) impone 9 fases obligatorias para cualquier tarea, generando overhead innecesario para tareas simples.
-
-**Objetivo**: Diseñar un sistema de ciclo dual (Long/Short) que permita al desarrollador elegir la estrategia adecuada según la complejidad, sin perder la integridad de los gates arquitectónicos.
-
-**Principales hallazgos**:
-1. El ciclo Long actual tiene 9 fases (P0-P8) con gates bloqueantes en cada transición.
-2. Las fases se pueden agrupar lógicamente en 3 macro-bloques para el ciclo Short.
-3. El switch debe ser persistente en `task.md` para permitir continuidad entre sesiones.
-4. El modelo de 5 preguntas es crucial y debe mantenerse en ambos ciclos.
-
----
-
-## 2. Necesidades detectadas
-
-### Requisitos del desarrollador
-- **Agilidad**: Ejecutar tareas simples sin pasar por 9 fases.
-- **Persistencia**: La decisión de ciclo debe sobrevivir a cambios de sesión/contexto.
-- **Seguridad**: Mantener gates que prevengan errores arquitectónicos.
-- **Reversibilidad limitada**: Si se detecta complejidad, permitir abortar y reiniciar en Long.
-
-### Límites arquitectónicos
-- El switch NO puede modificar el comportamiento del ciclo Long existente.
-- Los workflow files del ciclo Short deben ser nuevos, no modificaciones de los existentes.
-- El campo `task.strategy` debe añadirse al template `task.md`.
-
----
-
-## 3. Análisis del ciclo actual (Long)
-
-### Fases existentes y su propósito
-
-| Fase | ID | Propósito | Artefacto |
-|------|----|-----------|-----------|
-| P0 | acceptance-criteria | Definir alcance y 5 preguntas | task.md |
-| P1 | research | Investigación técnica profunda | research.md |
-| P2 | analysis | Análisis arquitectónico | analysis.md |
-| P3 | planning | Plan de implementación | plan.md |
-| P4 | implementation | Escritura de código | subtask-implementation.md |
-| P5 | verification | Tests y validación | verification.md |
-| P6 | results-acceptance | Presentación de resultados | results-acceptance.md |
-| P7 | evaluation | Métricas de agentes | metrics.md |
-| P8 | commit-push | Consolidación y commit | changelog.md |
-
----
-
-## 4. Diseño propuesto del ciclo Short
-
-### Mapeo de fases fusionadas
-
-```
-CICLO SHORT (3 fases)
-═══════════════════════════════════════════════════════════════
-
-┌─────────────────────────────────────────────────────────────┐
-│ SHORT-P1: Brief (Análisis + Planificación)                  │
-│                                                             │
-│ Fusiona:                                                    │
-│   - P0 (Acceptance): 5 preguntas obligatorias               │
-│   - P2 (Analysis): Análisis profundo para detectar          │
-│     complejidad                                             │
-│   - P3 (Planning): Plan de implementación simplificado      │
-│                                                             │
-│ NOTA: P1 (Research) se OMITE pero el análisis debe ser      │
-│       profundo para compensar.                              │
-│                                                             │
-│ Artefacto: brief.md                                         │
-│ Gate: Detectar complejidad → ofrecer abortar a Long         │
-└─────────────────────────────────────────────────────────────┘
-                              │
-                              ▼
-┌─────────────────────────────────────────────────────────────┐
-│ SHORT-P2: Implementation                                    │
-│                                                             │
-│ Equivale a:                                                 │
-│   - P4 (Implementation): Ejecución del plan                 │
-│                                                             │
-│ Artefacto: implementation.md                                │
-│ Gate: Revisión arquitectónica obligatoria                   │
-└─────────────────────────────────────────────────────────────┘
-                              │
-                              ▼
-┌─────────────────────────────────────────────────────────────┐
-│ SHORT-P3: Closure (Verificación + Resultados + Commit)      │
-│                                                             │
-│ Fusiona:                                                    │
-│   - P5 (Verification): Tests y validación                   │
-│   - P6 (Results): Presentación al desarrollador             │
-│   - P8 (Commit): Consolidación y push                       │
-│                                                             │
-│ NOTA: P7 (Evaluation) se OMITE en Short.                    │
-│                                                             │
-│ Artefacto: closure.md                                       │
-│ Gate: Aprobación del desarrollador + commit                 │
-└─────────────────────────────────────────────────────────────┘
-```
-
----
-
-## 5. Impacto en la arquitectura
-
-### Renombrado de carpeta (Breaking Change controlado)
-
-| Actual | Nuevo | Motivo |
-|--------|-------|--------|
-| `.agent/workflows/tasklifecycle/` | `.agent/workflows/tasklifecycle-long/` | Simetría semántica con `tasklifecycle-short` |
-
-### Ficheros a crear
-
-| Tipo | Path | Propósito |
-|------|------|-----------|
-| Workflow Index | `.agent/workflows/tasklifecycle-short/index.md` | Índice del ciclo Short |
-| Fase 1 | `.agent/workflows/tasklifecycle-short/short-phase-1-brief.md` | Brief (Análisis + Plan) |
-| Fase 2 | `.agent/workflows/tasklifecycle-short/short-phase-2-implementation.md` | Implementación |
-| Fase 3 | `.agent/workflows/tasklifecycle-short/short-phase-3-closure.md` | Cierre (Verificación + Commit) |
-| Template | `.agent/templates/brief.md` | Template para Brief |
-| Template | `.agent/templates/closure.md` | Template para Closure |
-
-### Ficheros a modificar
-
-| Fichero | Cambio |
-|---------|--------|
-| `.agent/workflows/tasklifecycle-long/index.md` | Actualizar ID y aliases tras rename |
-| `.agent/workflows/init.md` | Añadir paso de selección Long/Short + actualizar referencia |
-| `.agent/templates/task.md` | Añadir campo `task.strategy: long \| short` |
-| `.agent/workflows/index.md` | Actualizar alias `tasklifecycle` → `tasklifecycle-long` + registrar `tasklifecycle-short` |
-| `.agent/templates/index.md` | Registrar nuevos templates `brief` y `closure` |
-
----
-
-## 6. Mecanismo de detección de complejidad
-
-En SHORT-P1 (Brief), el arquitecto debe evaluar si la tarea es apta para Short:
-
-**Indicadores de complejidad alta** (requieren Long):
-- La tarea afecta más de 3 paquetes/módulos.
-- Requiere investigación de APIs externas.
-- Introduce cambios breaking en interfaces públicas.
-- Necesita tests E2E complejos.
-
-**Flujo de decisión**:
-```
-┌─────────────────────────────┐
-│ Análisis en Brief           │
-└─────────────────────────────┘
-              │
-              ▼
-    ┌─────────────────────┐
-    │ ¿Complejidad alta?  │
-    └─────────────────────┘
-         │          │
-        YES        NO
-         │          │
-         ▼          ▼
-   ┌───────────┐  ┌──────────────┐
-   │ Notificar │  │ Continuar    │
-   │ y ofrecer │  │ con Short    │
-   │ abortar   │  └──────────────┘
-   └───────────┘
-```
-
----
-
-## 7. Verificación del sistema de índices y aliases (OBLIGATORIO)
-
-Tras el rename y la creación de nuevos workflows, se **DEBE** verificar la integridad del sistema de índices:
-
-### Checklist de verificación
-
-| Verificación | Fichero | Criterio de éxito |
-|--------------|---------|-------------------|
-| Alias `tasklifecycle-long` registrado | `.agent/workflows/index.md` | El alias apunta a la nueva ruta |
-| Alias `tasklifecycle-short` registrado | `.agent/workflows/index.md` | El alias apunta al nuevo index.md |
-| Aliases de fases Long actualizados | `.agent/workflows/tasklifecycle-long/index.md` | Rutas correctas post-rename |
-| Aliases de fases Short definidos | `.agent/workflows/tasklifecycle-short/index.md` | 3 fases con rutas válidas |
-| Templates `brief` y `closure` registrados | `.agent/templates/index.md` | Aliases funcionales |
-| Campo `task.strategy` en template | `.agent/templates/task.md` | Acepta `long \| short` |
-
-### Prueba de resolución de alias
-
-El agente **DEBE** poder resolver la siguiente cadena sin errores:
-
-```
-.agent/index.md 
-  → workflows.index 
-    → tasklifecycle-long.index 
-      → phase_0.workflow (debe existir y ser legible)
-    → tasklifecycle-short.index 
-      → short_phase_1.workflow (debe existir y ser legible)
-```
-
-### Gate de verificación
-
-Si algún alias no resuelve correctamente:
-- **FAIL**: No se puede completar la implementación.
-- **Acción**: Corregir el índice o fichero faltante antes de continuar.
-
----
-
-## 8. Riesgos y mitigaciones
-
-| Riesgo | Severidad | Mitigación |
-|--------|-----------|------------|
-| Subestimar complejidad en Short | ALTA | Análisis profundo + detección obligatoria en Brief |
-| Pérdida de métricas (sin P7) | MEDIA | Aceptable según requisitos del desarrollador |
-| Inconsistencia entre ciclos | ALTA | Templates diferentes, gates comunes |
-| Confusión en sesiones mixtas | MEDIA | `task.strategy` persistido en task.md |
-| Alias rotos tras rename | ALTA | Verificación obligatoria de cadena de resolución |
-
----
-
-## 9. Fuentes
-
-- Análisis directo de workflows existentes:
-  - `phase-2-analysis.md` (142 líneas)
-  - `phase-3-planning.md` (171 líneas)
-  - `phase-4-implementation.md` (161 líneas)
-  - `phase-5-verification.md` (150 líneas)
-  - `phase-6-results-acceptance.md` (130 líneas)
-- Arquitectura de Extensio: `extensio-architecture.md`
-- Template de tareas: `templates.task`
-
----
-
-## 10. Aprobación del desarrollador (OBLIGATORIA)
-```yaml
-approval:
-  developer:
-    decision: SI
-    date: 2026-01-16T00:02:48+01:00
-    comments: Aprobado con scope ampliado (rename + verificación de aliases)
-```

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

@@ -1,130 +0,0 @@
-# Task (Template)
-
-## Identificación
-- id: 13
-- title: Sistema de Ciclo de Vida Dual (Long/Short)
-- scope: current
-- owner: architect-agent
-
-## Origen
-- created_from:
-  - workflow: tasklifecycle
-  - source: init
-  - candidate_path: artifacts.candidate.task
-
-## Descripción de la tarea
-Crear un mecanismo de switch en el proceso de inicialización para permitir al desarrollador elegir entre el ciclo de vida estándar (Long) y uno simplificado (Short). Implementar los nuevos workflows y lógica necesaria para el ciclo Short.
-
-## Objetivo
-Disponer de flexibilidad operativa según la complejidad de la tarea sin perder la integridad del sistema agéntico. El ciclo Short debe constar de 3 fases: 1. Análisis y Planificación, 2. Implementación, 3. Verificación y Resultados.
-
-## Estado del ciclo de vida (FUENTE ÚNICA DE VERDAD)
-
-```yaml
-task:
-  id: "13"
-  title: "Sistema de Ciclo de Vida Dual (Long/Short)"
-  strategy: "long" # Esta tarea técnica se ejecuta en modo long por su impacto estructural
-  phase:
-    current: "phase-8-commit-push"
-    validated_by: "architect-agent"
-    updated_at: "2026-01-16T17:47:04+01:00"
-  lifecycle:
-    phases:
-      phase-0-acceptance-criteria:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-15T23:55:00+01:00"
-      phase-1-research:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-16T00:02:48+01:00"
-      phase-2-analysis:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-16T00:06:01+01:00"
-      phase-3-planning:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-16T07:48:25+01:00"
-      phase-4-implementation:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-16T17:45:00+01:00"
-      phase-5-verification:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-16T17:47:04+01:00"
-      phase-6-results-acceptance:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-16T17:47:04+01:00"
-      phase-7-evaluation:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-16T17:47:04+01:00"
-      phase-8-commit-push:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-16T17:53:59+01:00"
-```
-
-## 5 Preguntas Obligatorias (REQUERIDO - Phase 0)
-> Sin respuestas completas, la tarea NO puede avanzar a Phase 1.
-
-| # | Pregunta (formulada por architect) | Respuesta (del desarrollador) |
-|---|-----------------------------------|-------------------------------|
-| 1 | ¿La decisión de usar el modo Short debe quedar grabada en el task.md de cada tarea individual, o prefieres que sea una configuración global de la sesión? | Debe estar grabada en task.md para que pueda ser interpretada fuera de la session o incluso en otra session |
-| 2 | ¿Para las fases fusionadas (ej: Análisis y Planificación), creamos un único documento unificado o prefieres mantener los ficheros separados? | No, crear nuevos ficheros para ese nuevo flow |
-| 3 | ¿En el modo Short, el architect-agent debe seguir haciendo una revisión manual de los Gates, o buscamos un sistema más automático? | No, la estructura de los ficheros de workflow debe respetarse por lo que el gate es crucial |
-| 4 | ¿Una vez que una tarea se inicia en modo Short, debe poder convertirse al modo Long si la complejidad aumenta? | Por ahora debe ser definitiva. Si se identifica complejidad, el desarrollador decide si abortar y crear una nueva tarea en modo long. |
-| 5 | ¿Confirmas que para el caso de uso Short es un trade-off aceptable perder Research y Evaluación? | Si, pero dentro del analisis de short debe ser un analisis profundo para detectar complejidad. Por eso sigue siendo crucial el modelo de 5 preguntas. |
-
----
-
-## Acceptance Criteria (OBLIGATORIO PARA CURRENT TASK)
-
-1. Alcance:
-   - Modificación de `workflow.init` para incluir el selector.
-   - Creación de `workflow.tasklifecycle.short` y ficheros de fases mergeadas.
-   - Actualización de `templates.task` para incluir el campo `strategy`.
-
-2. Entradas / Datos:
-   - Selección de estrategia (Long/Short) durante el comando `init`.
-   - Respuestas a las 5 preguntas (cruciales para detectar complejidad en modo Short).
-
-3. Salidas / Resultado esperado:
-   - Nuevo directorio de workflows para el ciclo Short.
-   - Versión de `task.md` con soporte para el switch de estrategia.
-   - Selector funcional en el proceso de inicialización.
-
-4. Restricciones:
-   - Mantener la integridad de los Gates arquitectónicos.
-   - El modo Short NO debe sacrificar la profundidad del Análisis inicial.
-
-5. Criterio de aceptación (Done):
-   - El desarrollador puede elegir "Short" al iniciar una tarea y completar el flujo de 3 fases con validación exitosa del arquitecto.
-
-## Historial de validaciones (append-only)
-```yaml
-history:
-  - phase: "phase-0-acceptance-criteria"
-    action: "completed"
-    validated_by: "architect-agent"
-    timestamp: "2026-01-15T23:55:00+01:00"
-    notes: "Acceptance criteria definidos y validados. Iniciamos Phase 1."
-  - phase: "phase-1-research"
-    action: "completed"
-    validated_by: "architect-agent"
-    timestamp: "2026-01-16T00:02:48+01:00"
-    notes: "Research aprobado por desarrollador. Scope ampliado con rename de carpeta y verificación de aliases."
-  - phase: "phase-2-analysis"
-    action: "completed"
-    validated_by: "architect-agent"
-    timestamp: "2026-01-16T00:06:01+01:00"
-    notes: "Analysis aprobado. Cobertura completa de 5 ACs, 6 ficheros nuevos, 5 modificaciones, 1 rename."
-```
-
-## 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.

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

@@ -1,84 +0,0 @@
----
-artifact: verification
-phase: phase-5-verification
-owner: qa-agent
-status: draft
-related_task: 13-dual-lifecycle-system
----
-
-# Verification Report — 13-dual-lifecycle-system
-
-## 1. Resumen
-
-Verificación del Sistema de Ciclo de Vida Dual (Long/Short) implementado en Phase 4.
-
-## 2. Tests ejecutados
-
-Esta tarea modifica ficheros de configuración del sistema agéntico, no código funcional. **No existen tests automatizados** para workflows.
-
-| Tipo | Estado | Justificación |
-|------|--------|---------------|
-| Unit | N/A | No hay código funcional |
-| Integration | N/A | Los workflows no tienen tests automatizados |
-| E2E | N/A | Verificación manual requerida |
-
-## 3. Verificación manual
-
-### Checklist de verificación (del Research aprobado)
-
-| Verificación | Estado |
-|--------------|--------|
-| ✅ Alias `tasklifecycle-long` registrado en `workflows/index.md` | PASS |
-| ✅ Alias `tasklifecycle-short` registrado en `workflows/index.md` | PASS |
-| ✅ Aliases de fases Long actualizados con nuevas rutas | PASS |
-| ✅ Aliases de 3 fases Short definidos en `tasklifecycle-short/index.md` | PASS |
-| ✅ Templates `brief` y `closure` registrados en `templates/index.md` | PASS |
-| ✅ Campo `task.strategy` en template `task.md` | PASS |
-
-### Prueba de resolución de alias
-
-```
-.agent/index.md 
-  → workflows.index 
-    → tasklifecycle-long.index ✅
-      → phase_0.workflow ✅ (phase-0-acceptance-criteria.md existe)
-    → tasklifecycle-short.index ✅
-      → short_phase_1.workflow ✅ (short-phase-1-brief.md existe)
-```
-
-## 4. Estado de Acceptance Criteria
-
-| AC | Descripción | Estado |
-|----|-------------|--------|
-| 1 | Selector Long/Short en init.md | ✅ |
-| 2 | Workflows Short (4 ficheros) | ✅ |
-| 3 | Campo strategy en task.md template | ✅ |
-| 4 | Gates intactos en workflows Short | ✅ |
-| 5 | Detección de complejidad en Brief | ✅ |
-
-## 5. Ficheros creados/modificados
-
-| Fichero | Acción |
-|---------|--------|
-| `workflows/tasklifecycle-long/` | Renamed |
-| `workflows/tasklifecycle-long/index.md` | Modified |
-| `workflows/tasklifecycle-short/index.md` | Created |
-| `workflows/tasklifecycle-short/short-phase-1-brief.md` | Created |
-| `workflows/tasklifecycle-short/short-phase-2-implementation.md` | Created |
-| `workflows/tasklifecycle-short/short-phase-3-closure.md` | Created |
-| `templates/brief.md` | Created |
-| `templates/closure.md` | Created |
-| `templates/index.md` | Modified |
-| `templates/task.md` | Modified |
-| `workflows/index.md` | Modified |
-| `workflows/init.md` | Modified |
-
-## 6. Aprobación del desarrollador (OBLIGATORIA)
-
-```yaml
-approval:
-  developer:
-    decision: SI
-    date: 2026-01-16T17:47:04+01:00
-    comments: Verificación aprobada
-```