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

package/dist/artifacts/3-developer-feedback-gate/changelog.md

@@ -1,10 +0,0 @@
-# Changelog - Developer Feedback Gate
-
-## Commits
-- **feat(workflows): implement developer feedback gate**
-  - Modificado `phase-7-evaluation.md` para incluir solicitud de aprobación explícita.
-  - Modificado `phase-8-commit-push.md` para validar existencia de aprobación en métricas.
-- **docs(templates): add validation field to task metrics**
-  - Actualizado `task-metrics.md` con campos de Aprobado, Puntuación y Comentarios.
-- **docs(artifacts): add artifacts for developer feedback gate**
-  - Añadidos reportes de análisis, planificación, verificación y métricas de la tarea 3.

package/dist/artifacts/3-developer-feedback-gate/implementation_plan.md

@@ -1,32 +0,0 @@
-# Plan de Implementación - Developer Feedback Gate
-
-## Archivos a Modificar
-
-### 1. Workflow: Phase 7 (Evaluation)
-**Archivo**: `.agent/workflows/tasklifecycle/phase-7-evaluation.md`
-- **Cambio**:
-  - Insertar nuevo **Paso 6**: Solicitud interactivas de feedback.
-  - Renumerar paso actual "PASS" a **Paso 7**.
-  - Actualizar sección **Gate** para exigir `Aprobado: SI` en metrics.
-
-### 2. Workflow: Phase 8 (Commit)
-**Archivo**: `.agent/workflows/tasklifecycle/phase-8-commit-push.md`
-- **Cambio**:
-  - Actualizar **Paso 1 (Verificar inputs)**.
-  - Añadir condición: `Existe metrics.md y contiene 'Aprobado: SI'`.
-
-### 3. Template: Metrics
-**Archivo**: `.agent/templates/task-metrics.md`
-- **Cambio**:
-  - Añadir al final del archivo:
-    ```markdown
-    ## 4. Validación del Desarrollador
-    - Aprobado: [SI/NO]
-    - Puntuación (0-5):
-    - Comentario:
-    ```
-
-## Estrategia de Verificación
-Debido a que modificamos la lógica del sistema, la verificación será una revisión del código estático y una simulación lógica:
-1. Confirmar que los pasos son secuenciales.
-2. Confirmar que la condición de bloqueo en Phase 8 coincide con el output de Phase 7.

package/dist/artifacts/3-developer-feedback-gate/init.md

@@ -1,13 +0,0 @@
-# Task Candidate: Initialize Session
-
-## Objectives
-- [x] Activate `architect-agent`
-- [x] Load global rules indices
-- [x] Load `constitution.extensio_architecture`
-- [x] Load `constitution.clean_code`
-- [x] Load `constitution.GEMINI_location`
-- [x] Confirm language: Spanish
-- [x] Create `init.md`
-
-## Status: READY
-The environment is prepared for a new task lifecycle. Waiting for user input.

package/dist/artifacts/3-developer-feedback-gate/metrics.md

@@ -1,34 +0,0 @@
----
-artifact: task_metrics
-phase: phase-7-evaluation
-owner: architect-agent
-status: pending
-related_task: developer-feedback-gate
----
-
-# Task Metrics — Developer Feedback Gate
-
-## 1. Agentes evaluados
-- architect-agent
-- qa-agent
-
----
-
-## 2. Puntuacion por agente (0-10)
-- **architect-agent**: 10
-  - Diseño robusto e implementación limpia de los cambios en workflows y templates. Gestión correcta del abort/retry solicitado por el usuario.
-- **qa-agent**: 10
-  - Verificación lógica exhaustiva cubriendo escenarios de Aprobación, Rechazo y Bypass.
-
----
-
-## 3. Puntuacion global de la tarea
-- Promedio ponderado: 10
-- Observaciones: La tarea establece un precedente importante para el gobierno del proyecto.
-
----
-
-## 4. Validación del Desarrollador
-- Aprobado: SI
-- Puntuación del desarrollador (0-5): 3
-- Comentarios: Todo corrceto pero no se han generado los artifacts 

package/dist/artifacts/3-developer-feedback-gate/research.md

@@ -1,28 +0,0 @@
-# Research Report - Developer Feedback Gate
-
-## 1. Estado Actual (Baseline)
-
-### Phase 7 (Evaluation)
-- **Workflow**: Calcula puntuaciones internas automáticamente.
-- **Interacción**: Nula. No solicita confirmación al usuario.
-- **Salida**: Genera `metrics.md` y actualiza `agent-scores.md`.
-- **Gate**: Solo verifica la existencia de archivos, no su contenido cualitativo.
-
-### Phase 8 (Commit & Push)
-- **Entrada**: Requiere `metrics.md`.
-- **Validación**: Verifica existencia del archivo, pero no busca marcas de aprobación.
-- **Riesgo**: Permite cerrar tareas aunque el desarrollador esté insatisfecho con la evaluación.
-
-### Template `task-metrics.md`
-- **Contenido**: Solo puntuaciones numéricas y justificaciones del agente.
-- **Faltante**: No hay campos para `Aprobado`, `Rating Usuario` o `Comentarios`.
-
-## 2. Factibilidad Técnica
-- **Herramienta**: `notify_user` permite bloquear la ejecución hasta recibir respuesta.
-- **Persistencia**: Markdown es flexible, añadir una sección de validación es trivial y fácil de parsear (regex simple de "Aprobado: SI").
-- **Bloqueo**: Los workflows de Extensio soportan pasos de fallo explícito (Steps FAIL), lo que es ideal para este gate.
-
-## 3. Recomendación
-Proceder con la implementación de un **"Hard Gate"**:
-1. Phase 7 se detiene obligatoriamente.
-2. Phase 8 falla obligatoriamente si no se cumple la condición.

package/dist/artifacts/3-developer-feedback-gate/results-acceptance.md

@@ -1,17 +0,0 @@
-# Results Acceptance - Developer Feedback Gate
-
-## Resumen
-Se ha integrado exitosamente un "Gate" de aprobación del desarrollador en el ciclo de vida de las tareas.
-
-## Entregables Finales
-1. **Workflow Phase 7 Updated**: Incluye paso interactivo para solicitar feedback.
-2. **Workflow Phase 8 Updated**: Incluye validación pre-condición de aprobación.
-3. **Template Metrics Updated**: Incluye campos estandarizados para validación.
-
-## Cumplimiento de Objetivos
-- [x] **Gate Bloqueante**: Confirmado. Phase 8 no arranca sin aprobación.
-- [x] **Captura de Feedback**: Confirmado. Template actualizado.
-- [x] **Integridad del Flujo**: Confirmado. Sin regresiones en los pasos existentes.
-
-## Instrucciones de Cierre
-Al aprobar este resultado (`SI`), procederemos a la evaluación de **esta** tarea usando el nuevo sistema (aunque el gate ya está activo en el código, lo ejecutaremos "manualmente" como parte del proceso standard si aplica, o simplemente cerraremos esta tarea de infraestructura).

package/dist/artifacts/3-developer-feedback-gate/task.md

@@ -1,17 +0,0 @@
-# Task: Developer Feedback Gate in Evaluation Phase
-
-## Objectives
-- [x] Implement a blocking gate in `Phase 7: Evaluation` requiring developer input.
-- [x] Ensure `metrics.md` captures developer rating and feedback.
-- [x] Prevent transition to `Phase 8: Commit` without explicit approval.
-
-## Progress
-- [x] Phase 0: Acceptance Criteria
-- [x] Phase 1: Research
-- [x] Phase 2: Analysis
-- [x] Phase 3: Planning
-- [x] Phase 4: Implementation
-- [x] Phase 5: Verification
-- [x] Phase 6: Results Acceptance
-- [x] Phase 7: Evaluation
-- [ ] Phase 8: Commit & Push

package/dist/artifacts/3-developer-feedback-gate/verification.md

@@ -1,35 +0,0 @@
-# Verification Report - Developer Feedback Gate
-
-## 1. Verificación Estática
-- [x] **Phase 7 Workflow**:
-  - Contiene paso de solicitud de feedback (Paso 6).
-  - El Gate final exige `metrics.md` con `Aprobado: SI`.
-- [x] **Phase 8 Workflow**:
-  - El paso de verificación de inputs exige `metrics.md` con `Aprobado: SI`.
-- [x] **Template**:
-  - `task-metrics.md` incluye la sección "4. Validación del Desarrollador".
-
-## 2. Escenarios de Prueba Lógica
-
-### Escenario A: Usuario rechaza
-1. Phase 7 llega al paso 6.
-2. Usuario responde "NO".
-3. Resultado: FAIL (Paso 9).
-4. Phase 8 nunca inicia.
-   **Resultado**: CORRECTO.
-
-### Escenario B: Usuario aprueba
-1. Phase 7 llega al paso 6.
-2. Usuario responde "SI" y da puntuación.
-3. Se escribe "Aprobado: SI" en `metrics.md`.
-4. Phase 7 pasa el Gate.
-5. Inicia Phase 8.
-6. Phase 8 verifica inputs -> Encuentra "Aprobado: SI".
-7. Phase 8 continúa.
-   **Resultado**: CORRECTO.
-
-### Escenario C: Bypass intento (Phase 8 directo)
-1. Usuario intenta ejecutar Phase 8 sin pasar por Phase 7.
-2. `metrics.md` no existe o no tiene "Aprobado: SI".
-3. Phase 8 falla en Paso 1 (Verificar Inputs).
-   **Resultado**: CORRECTO.

package/dist/artifacts/30-task-execution-protocol-gates/acceptance.md

@@ -1,46 +0,0 @@
----
-artifact: acceptance
-phase: phase-0-acceptance-criteria
-owner: architect-agent
-status: pending
-related_task: 30-AHRP: Agentic Handover & Reasoning Protocol
----
-
-# Acceptance Criteria — 30-AHRP: Agentic Handover & Reasoning Protocol
-
-## Identificación del agente
-🏛️ **architect-agent**: Definiendo los criterios de éxito para el protocolo de seguridad AHRP.
-
-## User Requirements
-- Protocolo rígido y visual para el traspaso de tareas.
-- Validación de identidad asignada antes de empezar.
-- Aprobación obligatoria del "Reasoning" antes del primer cambio de código.
-- Nueva Constitución del Sistema Agéntico (`constitution.agent_system`).
-
-## Acceptance Criteria
-- [ ] **AC-1: Constitution.agent_system**: Creado nuevo documento core que defina normas, comandos, jerarquía y flujos del framework.
-- [ ] **AC-2: Protocolo AHRP**: Definido el flujo de Triple Gate (Activación -> Reasoning -> Resultados).
-- [ ] **AC-3: Template Agent-Task**: Refactorizado para incluir visualmente los bloques de Activación y Aprobación de Reasoning.
-- [ ] **AC-4: Identity Lock**: Impedir por regla que un agente ejecute herramientas si el "Gate A: Activación" no está firmado con "SI" por el desarrollador.
-- [ ] **AC-5: Workflow Enforcement**: Actualizados los workflows `long` y `short` para integrar el AHRP en sus pasos de implementación.
-- [ ] **AC-6: Zero-Tolerance Penalty**: Implementada la regla de puntuación 0 automática por saltarse cualquier Gate del protocolo AHRP.
-- [ ] **AC-7: Metrics Awareness**: El sistema de métricas debe ser inyectado y notificado en cada nueva tarea creada.
-
-## 5 Preguntas de Validación Técnica
-1. **Naming**: ¿Se usará el nombre AHRP (Agentic Handover & Reasoning Protocol) en toda la documentación core?
-2. **Visual Block**: ¿Qué elemento gráfico usaremos para denotar que una tarea está "BLOQUEADA: Esperando Activación"?
-3. **Escalabilidad**: ¿Cómo afecta este triple gate al ciclo de vida "Short"? (Se debe simplificar pero mantener la esencia).
-4. **Indisciplina**: ¿Cómo automatizaremos la detección de una "ejecución no autorizada" para aplicar el 0 inmediato en métricas?
-5. **Architect Responsibility**: El arquitecto NO puede activar tareas. ¿Cómo se registrará esta restricción en el nuevo CLI?
-
----
-
-## Gate de Aprobación
-
-```yaml
-approval:
-  developer:
-    decision: null # SI | NO
-    date: null
-    comments: null
-```

package/dist/artifacts/30-task-execution-protocol-gates/researcher/research.md

@@ -1,34 +0,0 @@
----
-artifact: research
-phase: phase-1-research
-owner: researcher-agent
-status: in_progress
-related_task: 30-AHRP: Agentic Handover & Reasoning Protocol
----
-
-# Research Report — AHRP & Agentic System Constitution
-
-## Identificación del agente
-🔬 **researcher-agent**: Investigando los cimientos del protocolo AHRP y el sistema de penalización.
-
-## 1. Objetivos de Investigación
-- Analizar las mejores prácticas para "Handover protocols" en sistemas multi-agente.
-- Diseñar la estructura de la `constitution.agent_system.md`.
-- Investigar mecanismos técnicos para la automatización de la penalización "0" en métricas ante fallos de gate.
-- Proponer un formato visual "rígido" para el bloqueo de tareas.
-
-## 2. Web & Internal Research
-- **Handover Protocols**: La literatura sobre sistemas multi-agente sugiere que el "Handover" debe incluir un "Contract of Intent" (Reasoning) antes del "Contract of Execution".
-- **Visual Compliance**: Los agentes de IA son altamente sensibles a bloques de comentarios masivos (hashtags/caracteres especiales) que rompen el flujo visual del markdown, sirviendo como guardrails efectivos.
-- **Persistence**: La persistencia de métricas en archivos locales `.agent/metrics/*.json` es la forma más robusta de evitar que el LLM "olvide" su historial de indisciplina.
-
-## 3. Alternativas Técnicas
-- **Opción A (Soft Enforcement)**: Solo avisos en el texto de la tarea. (Descartada por falta de rigor).
-- **Opción B (Hard Enforcement via CLI)**: Modificar el CLI para que detecte el estado del gate antes de ejecutar. (Ideal a largo plazo).
-- **Opción C (Document-Driven Enforcement)**: El AHRP mediante bloques visuales obligatorios en `agent-task.md`. (Recomendada para implementación inmediata).
-
-## 4. Recomendación Inicial
-1. Crear `constitution.agent_system.md` como fuente de verdad.
-2. Adoptar el **Triple Gate (A/B/C)** como estándar innegociable.
-3. Implementar el bloque visual de "STOP" en los templates de tarea.
-4. Establecer la penalización automática de 0 firmada por el `qa-agent`.

package/dist/artifacts/30-task-execution-protocol-gates/task.md

@@ -1,77 +0,0 @@
-# Task: 30-AHRP: Agentic Handover & Reasoning Protocol
-
-## Identificación
-- id: 30
-- title: AHRP: Agentic Handover & Reasoning Protocol
-- scope: core / orchestration
-- owner: architect-agent
-
-## Origen
-- created_from:
-  - workflow: tasklifecycle
-  - source: Problemas detectados en Tarea #29 (Disciplina Agéntica)
-  - candidate_path: .agent/artifacts/candidate/init.md
-
-## Descripción de la tarea
-Institucionalizar el protocolo **AHRP** (Agentic Handover & Reasoning Protocol) mediante la creación de la `constitution.agent_system`. Se implementará una secuencia obligatoria de Triple Gate (Activación -> Reasoning -> Resultados) para cada tarea.
-
-## Objetivo
-Eliminar la autonomía no autorizada y asegurar la separación de dominios mediante un proceso de "Doble Aprobación Pre-Ejecución".
-
-## Estado del ciclo de vida (FUENTE ÚNICA DE VERDAD)
-
-```yaml
-task:
-  id: "30"
-  title: "Task Execution Protocol & Activation Gates"
-  strategy: "long"
-  status: "in_progress"
-  phase:
-    current: "phase-2-analysis"
-    validated_by: "architect-agent"
-    updated_at: "2026-01-20T08:35:00+01:00"
-  lifecycle:
-    phases:
-      phase-0-acceptance-criteria:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-20T08:33:00+01:00"
-      phase-1-research:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-20T08:35:00+01:00"
-      phase-2-analysis:
-        completed: false
-        validated_by: null
-        validated_at: null
-      phase-3-planning:
-        completed: false
-        validated_by: null
-        validated_at: null
-      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
-```
-
----
-
-## 2. Definición y Alcance (Contrato)
-- **Acceptance Criteria**: [.agent/artifacts/30-task-execution-protocol-gates/acceptance.md](.agent/artifacts/30-task-execution-protocol-gates/acceptance.md)
-- **Alias**: `task.acceptance`