@christianmaf80/agentic-workflow 1.33.2-beta.7 → 1.34.1-beta.8

package/dist/agent/workflows/tasklifecycle-short/short-phase-1-brief.md

@@ -1,110 +0,0 @@
----
-id: workflow.tasklifecycle-short.short-phase-1-brief
-description: Fase 1 del ciclo Short. Fusiona Acceptance + Analysis + Planning. Incluye 5 preguntas obligatorias y detección de complejidad.
-owner: architect-agent
-version: 1.0.0
-severity: PERMANENT
-trigger:
-  commands: ["short-phase-1", "brief"]
-blocking: true
----
-
-# WORKFLOW: tasklifecycle-short.short-phase-1-brief
-
-## Input (REQUIRED)
-- Existe task candidate con `task.strategy: short`.
-- El desarrollador ha proporcionado título y objetivo.
-
-> [!IMPORTANT]
-> **Constitución activa (OBLIGATORIO)**:
-> - Cargar `constitution.clean_code` antes de iniciar
-> - Cargar `constitution.agents_behavior` (sección 7: Gates, sección 8: Constitución)
-> - **Activar `skill.runtime-governance`** (Para validación de gate y trazabilidad por el Architect)
-
-## Output (REQUIRED)
-- Artefacto: `.agent/artifacts/<taskId>-<taskTitle>/brief.md`
-- Artefacto: `.agent/artifacts/<taskId>-<taskTitle>/acceptance.md` (NUEVO)
-- Task actualizado con fase actual = `short-phase-1-brief`
-
-## Objetivo (ONLY)
-- Ejecutar las **5 preguntas obligatorias** para definir acceptance criteria.
-- Realizar un **análisis profundo** para detectar complejidad.
-- Crear un **plan simplificado** de implementación.
-- Si se detecta complejidad alta, **ofrecer abortar** y reiniciar en modo Long.
-
-> Esta fase **NO implementa código**.  
-> Esta fase **REQUIERE aprobación explícita del desarrollador (SI/NO)**.
-
----
-
-## Pasos obligatorios
-
-0. Activar `architect-agent` y usar prefijo obligatorio en cada mensaje.
-
-### 1. Verificar inputs
-- Existe task candidate.
-- `task.strategy == "short"`.
-- Si falla → **FAIL**.
-
-### 2. Ejecutar 5 preguntas obligatorias
-El architect-agent **DEBE** formular 5 preguntas específicas basadas en la tarea:
-- Las preguntas varían según la tarea concreta.
-- Sin respuestas completas, la fase NO avanza.
-
-### 3. Análisis de complejidad
-Evaluar indicadores de complejidad:
-- ¿Afecta más de 3 paquetes/módulos? → Alta
-- ¿Requiere investigación de APIs externas? → Alta
-- ¿Introduce cambios breaking? → Alta
-- ¿Necesita tests E2E complejos? → Alta
-
-**Si complejidad es ALTA**:
-- Notificar al desarrollador.
-- Ofrecer opción de abortar y crear nueva tarea en modo Long.
-- Si decide abortar → terminar fase con estado "aborted".
-### 4. Crear artefactos (brief.md y acceptance.md)
-- Usar templates `templates.brief` y `templates.acceptance`.
-- En `acceptance.md` incluir:
-  - Acceptance criteria derivados de las 5 preguntas.
-- En `brief.md` incluir:
-  - Análisis simplificado del estado actual.
-  - Plan de implementación con pasos ejecutables.
-  - Evaluación de complejidad.
-  - **Evaluación de Agentes**: Desempeño y propuestas de mejora.
-
-### 5. Solicitar aprobación del desarrollador (por consola)
-```yaml
-approval:
-  developer:
-    decision: SI | NO
-    date: <ISO-8601>
-    comments: <opcional>
-```
-- Si `decision != SI` → **FAIL**.
-
-### 6. PASS
-- Actualizar task.md:
-  - Marcar fase como completada.
-  - Establecer `task.lifecycle.phases.short-phase-1-brief.validated_at = <ISO-8601>`.
-  - Actualizar `task.phase.updated_at = <ISO-8601>`.
-  - Avanzar a `short-phase-2-implementation`.
-
----
-
-## Gate (REQUIRED)
-Requisitos (todos obligatorios):
-1. Existen `brief.md` y `acceptance.md` con templates correctos.
-2. El `brief.md` inicia con el prefijo del `architect-agent`.
-3. Las 5 preguntas están respondidas.
-4. La evaluación de complejidad está documentada.
-5. Existe aprobación explícita del desarrollador.
-6. task.md refleja fase completada.
-7. task.md refleja timestamp y estado:
-   - `task.lifecycle.phases.short-phase-1-brief.completed == true`
-   - `task.lifecycle.phases.short-phase-1-brief.validated_at` no nulo
-   - `task.phase.updated_at` no nulo
-8. **Gobernanza verificada**: El historial de logs muestra la secuencia de herramientas MCP definida en `skill.runtime-governance`.
-
-Si Gate FAIL:
-- Indicar qué requisito falta.
-- Bloquear hasta resolver.

package/dist/agent/workflows/tasklifecycle-short/short-phase-3-closure.md

@@ -1,104 +0,0 @@
----
-id: workflow.tasklifecycle-short.short-phase-3-closure
-description: Fase 3 del ciclo Short. Fusiona Verification + Results + Commit.
-owner: architect-agent
-version: 1.0.0
-severity: PERMANENT
-trigger:
-  commands: ["short-phase-3", "closure"]
-blocking: true
----
-
-# WORKFLOW: tasklifecycle-short.short-phase-3-closure
-
-## Input (REQUIRED)
-- Existe informe de implementación aprobado.
-- task.md refleja `task.phase.current == "short-phase-3-closure"`
-
-> [!IMPORTANT]
-> **Constitución activa (OBLIGATORIO)**:
-> - Cargar `constitution.clean_code` antes de iniciar
-> - Cargar `constitution.agents_behavior` (sección 7: Gates, sección 8: Constitución)
-
-## Output (REQUIRED)
-- Artefacto de cierre: `.agent/artifacts/<taskId>-<taskTitle>/closure.md`
-- Commits realizados (si aplica).
-- Task completado.
-
-## Objetivo (ONLY)
-- Verificar la implementación mediante tests (si aplica).
-- Presentar resultados al desarrollador.
-- Obtener aceptación final.
-- Consolidar y realizar commit.
-
-> Esta fase **NO implementa código nuevo**.  
-> Esta fase **CIERRA el ciclo de la tarea**.
-
----
-
-## Pasos obligatorios
-
-0. Activar `architect-agent` y usar prefijo obligatorio en cada mensaje.
-
-### 1. Protocolo de Validación Pre-Vuelo (OBLIGATORIO)
-- El agente **DEBE** leer físicamente el informe de implementación aprobado: `.agent/artifacts/<taskId>-<taskTitle>/architect/implementation.md`.
-- **Citar explícitamente** la decisión de aprobación (ej: "Estado: APROBADO").
-- Si el informe no existe o no está aprobado, el proceso **DEBE** detenerse inmediatamente (FAIL).
-- Verificar que la fase en `task.md` sea la correcta.
-
-### 2. Ejecutar verificación
-Si la tarea requiere tests:
-- Ejecutar tests según `constitution.clean_code`.
-- Documentar resultados.
-
-Si no requiere tests:
-- Documentar justificación.
-
-### 3. Crear artefacto closure.md
-- Usar template `templates.closure`.
-- Incluir:
-  - Resumen de verificación.
-  - Estado de cada acceptance criteria (✅/❌).
-  - Evidencia de tests (si aplica).
-
-### 4. Presentar resultados al desarrollador
-- Mostrar closure.md.
-- Resolver dudas.
-- Solicitar aceptación final por consola (SI/NO) y registrarla en `closure.md`.
-
-### 6. Evaluar agentes (OBLIGATORIO)
-- Solicitar puntuación (1-10) del desarrollador para cada agente que haya intervenido.
-- **GATE OBLIGATORIO**: Sin puntuación, la tarea NO puede cerrarse.
-- Registrar las puntuaciones en `closure.md`.
-
-### 7. Consolidar commits
-Si hay cambios de código:
-- Preparar commits siguiendo Conventional Commits.
-- Solicitar aprobación del desarrollador para push.
-
-### 8. PASS
-- Marcar tarea como **COMPLETADA**.
-- Generar changelog (si aplica).
-- Actualizar task.md con estado final.
-  - Establecer `task.lifecycle.phases.short-phase-3-closure.validated_at = <ISO-8601>`.
-  - Actualizar `task.phase.updated_at = <ISO-8601>`.
-
----
-
-## Gate (REQUIRED)
-Requisitos (todos obligatorios):
-1. Existe closure.md con template correcto.
-2. El `closure.md` inicia con el prefijo del `architect-agent`.
-3. Todos los acceptance criteria están marcados.
-4. Existe aceptación final del desarrollador.
-5. Se han registrado las puntuaciones de los agentes en `closure.md`.
-6. Commits realizados (si aplica).
-7. task.md refleja tarea completada.
-8. task.md refleja timestamp y estado:
-   - `task.lifecycle.phases.short-phase-3-closure.completed == true`
-   - `task.lifecycle.phases.short-phase-3-closure.validated_at` no nulo
-   - `task.phase.updated_at` no nulo
-
-Si Gate FAIL:
-- Indicar qué requisito falta.
-- Bloquear hasta resolver.