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

package/dist/artifacts/21-portable-agentic-system/task.md

@@ -1,115 +0,0 @@
-# Task (Current)
-
-## Identificación
-- id: 21
-- title: Portable Agentic System
-- scope: current
-- owner: architect-agent
-
-## Origen
-- created_from:
-  - workflow: tasklifecycle
-  - source: init
-  - candidate_path: artifacts.candidate.task
-
-## Descripción de la tarea
-Crear un paquete npm portable que permita distribuir el sistema de agentes para ser usado en cualquier otro proyecto (agnóstico de Extensio).
-
-## Objetivo
-Desacoplar la lógica de orquestación del framework Extensio, implementar un CLI (`agentic-workflow`) para inicialización y proveer la base de la constitución y estructura de agentes.
-
-## Estado del ciclo de vida (FUENTE ÚNICA DE VERDAD)
-
-```yaml
-task:
-  id: "21"
-  title: "Portable Agentic System"
-  strategy: "long"
-  phase:
-    current: "cancelled"
-    validated_by: "architect-agent"
-    updated_at: "2026-01-19T09:35:00Z"
-  lifecycle:
-    phases:
-      phase-0-acceptance-criteria:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-19T09:27:00Z"
-      phase-1-research:
-        completed: false
-        status: "cancelled"
-        validated_by: "architect-agent"
-        validated_at: "2026-01-19T09:35:00Z"
-      phase-2-analysis:
-        completed: false
-        status: "cancelled"
-      phase-3-planning:
-        completed: false
-        status: "cancelled"
-      phase-4-implementation:
-        completed: false
-        status: "cancelled"
-      phase-5-verification:
-        completed: false
-        status: "cancelled"
-      phase-6-results-acceptance:
-        completed: false
-        status: "cancelled"
-      phase-7-evaluation:
-        completed: false
-        status: "cancelled"
-      phase-8-commit-push:
-        completed: false
-        status: "cancelled"
-```
-
-## 5 Preguntas Obligatorias (REQUERIDO - Phase 0)
-
-| # | Pregunta (formulada por architect) | Respuesta (del desarrollador) |
-|---|-----------------------------------|-------------------------------|
-| 1 | ¿Qué nombre exacto tendrá el paquete npm (ej: `@cmarino/agentic-workflow`)? | @cmarino/agentic-workflow |
-| 2 | ¿Cuál es el conjunto mínimo de archivos/reglas que deben ser "portados" (ej: workflows, rules/constitution, templates)? | Sistemas Long y Short, roles de desarrollo y templates agnósticos. |
-| 3 | El CLI `init`, ¿qué estructura de directorios debería crear por defecto en el proyecto destino? | `AGENTS.md` en root y carpeta `.agent/` con estructura/scaffolding. |
-| 4 | ¿Cómo manejaremos las dependencias de MCP servers si el proyecto destino no las tiene configuradas? | Un asistente de configuración guiado tras la instalación. |
-| 5 | ¿Qué nivel de personalización de los agentes/roles permitiremos en esta primera versión portable? | Asistente guiará para customizar manteniendo formato y coherencia. |
-
----
-
-## Acceptance Criteria (OBLIGATORIO PARA CURRENT TASK)
-
-1. Alcance:
-   - Creación de paquete npm `@cmarino/agentic-workflow`.
-   - Implementación de CLI `agentic-workflow`.
-   - Portabilidad de workflows (Long/Short), roles y templates contractuales.
-   - Creación de `AGENTS.md` y carpeta `.agent/` en proyectos destino.
-
-2. Entradas / Datos:
-   - Workflows actuales del repositorio extensio.
-   - Constituciones de roles y arquitectura (agnósticas).
-   - Templates contractuales.
-
-3. Salidas / Resultado esperado:
-   - Paquete npm instalable.
-   - Comando CLI funcional para inicializar el sistema.
-   - Asistente interactivo de configuración post-instalación.
-   - Documentación básica en `AGENTS.md`.
-
-4. Restricciones:
-   - El sistema debe ser agnóstico de Extensio (eliminar referencias a extensiones).
-   - Mantener la coherencia del flow original (Gates, Roles, Fases).
-   - El asistente debe guiar la customización sin romper el formato.
-
-5. Criterio de aceptación (Done):
-   - Un proyecto vacío puede ser inicializado con el CLI y el sistema de agentes queda funcional (capaz de iniciar `init`).
-   - El asistente de configuración permite establecer la base del proyecto.
-   - El código es Clean Code y sigue la arquitectura de Extensio (aplicada a orquestación).
-
-## Historial de validaciones (append-only)
-```yaml
-history:
-  - phase: "phase-0-acceptance-criteria"
-    action: "completed"
-    validated_by: "architect-agent"
-    timestamp: "2026-01-19T09:27:00Z"
-    notes: "Acceptance criteria definidos y validados. Pasando a Phase 1."
-```

package/dist/artifacts/22-standardize-phase-0-artifact/architect/analysis.md

@@ -1,113 +0,0 @@
----
-artifact: analysis
-phase: phase-2-analysis
-owner: architect-agent
-status: draft
-related_task: 22-standardize-phase-0-artifact
----
-
-# Analysis — 22-standardize-phase-0-artifact
-
-## 1. Resumen ejecutivo
-**Problema**
-- El flujo actual de la Fase 0 (Acceptance Criteria) mezcla la gestión del estado de la tarea con la definición del contrato en un único archivo (`task.md`). Esto rompe la modularidad del sistema y dificulta la validación automática de Gates.
-
-**Objetivo**
-- Estandarizar el flujo para que cada fase produzca su propio artefacto, extrayendo los Criterios de Aceptación a un archivo dedicado `acceptance.md`.
-
-**Criterio de éxito**
-- Al finalizar la Fase 0, se debe haber generado un archivo `acceptance.md` que cumpla con el nuevo template.
-- El archivo `task.md` debe estar libre de secciones de preguntas y criterios, delegando esa información al nuevo artefacto mediante alias.
-
----
-
-## 2. Estado del proyecto (As-Is)
-**Estructura relevante**
-- `.agent/templates/task.md`: Contiene las secciones `## 5 Preguntas Obligatorias` y `## Acceptance Criteria`.
-- `.agent/workflows/tasklifecycle-long/phase-0-acceptance-criteria.md`: Workflow que orquesta la creación del `task.md` definitivo.
-- `.agent/workflows/tasklifecycle-short/short-phase-1-brief.md`: Workflow que orquesta el ciclo simplificado.
-
-**Drivers existentes**
-- No aplica (lógica de orquestación pura).
-
-**Limitaciones detectadas**
-- El parser de Gates actual debe buscar dentro de `task.md`, lo cual es inconsistente con el resto de fases (Research, Analysis, Planning) que generan archivos propios.
-
----
-
-## 3. Cobertura de Acceptance Criteria
-### AC-1: Alcance
-- **Interpretación**: Modificar los workflows y templates para separar la Fase 0.
-- **Verificación**: Comprobar que tras ejecutar Phase 0, existen `task.md` y `acceptance.md`.
-
-### AC-2: Entradas / Datos
-- **Interpretación**: Usar la estructura actual como base.
-
-### AC-3: Salidas / Resultado esperado
-- **Interpretación**: `task.md` limpio y `acceptance.md` generado.
-
-### AC-4: Restricciones
-- **Interpretación**: Mantener alias y retrocompatibilidad selectiva.
-- **Verificación**: Asegurar que las referencias `task.acceptance` sigan funcionando.
-
----
-
-## 4. Research técnico
-**Decisión recomendada**
-- **Enfoque de "Referencia por Alias"**: El archivo `task.md` contendrá una referencia al archivo `acceptance.md` en su sección de metadatos. El índice de artefactos (`.agent/artifacts/index.md`) se actualizará dinámicamente o los workflows usarán alias para acceder al contenido.
-- **Mantenimiento de `templates/task.md`**: Se debe crear un `templates/task.md` simplificado para las nuevas tareas.
-
----
-
-## 5. Agentes participantes
-- **architect-agent**: Responsable de modificar los workflows y templates estructurales.
-- **qa-agent**: Responsable de validar que el nuevo flujo genere los archivos correctos y que los Gates bloqueen si falta el artefacto.
-
-**Componentes necesarios**
-- `templates/acceptance.md` [NEW]
-- `templates/task.md` [MODIFY]
-- `templates/index.md` [MODIFY]
-- `workflows/tasklifecycle-long/phase-0-acceptance-criteria.md` [MODIFY]
-- `workflows/tasklifecycle-short/short-phase-1-brief.md` [MODIFY]
-
----
-
-## 6. Impacto de la tarea
-**Arquitectura**
-- Se refuerza el principio de "1 fase = 1 artefacto".
-
-**APIs / contratos**
-- El contrato de aceptación se vuelve modular y más fácil de auditar por agentes de QA.
-
-**Compatibilidad**
-- Las tareas 1-21 se mantienen como están. El cambio aplica a partir de la tarea 22 (esta misma tarea se usará como prueba de concepto para la siguiente).
-
----
-
-## 7. Riesgos y mitigaciones
-- **Riesgo 1: Rotura de scripts de parsing**: Si algún script asume que los AC están en `task.md`.
-  - **Mitigación**: Revisar todos los workflows en busca de lecturas directas a esas secciones de `task.md`.
-
----
-
-## 8. Preguntas abiertas
-- ¿Deberíamos mover también el historial de validaciones a un archivo `history.md` en el futuro? (Fuera de este alcance, se añadirá al TODO).
-
----
-
-## 9. TODO Backlog (Consulta obligatoria)
-**Estado actual**: 4 items pendientes.
-
-**Items relevantes para esta tarea**:
-- Ninguno directamente, pero esta tarea ayuda a la modularización necesaria para el item `004-portable-agentic-system`.
-
----
-
-## 10. Aprobación
-```yaml
-approval:
-  developer:
-    decision: null
-    date: null
-    comments: null
-```

package/dist/artifacts/22-standardize-phase-0-artifact/architect/plan.md

@@ -1,124 +0,0 @@
----
-artifact: plan
-phase: phase-3-planning
-owner: architect-agent
-status: draft
-related_task: 22-standardize-phase-0-artifact
----
-
-# Implementation Plan — 22-standardize-phase-0-artifact
-
-## 1. Resumen del plan
-- **Contexto**: Estandarizar la Fase 0 para que genere un artefacto independiente `acceptance.md`, mejorando la modularidad y el parsing de Gates.
-- **Resultado esperado**: 
-  - Nuevo template `templates/acceptance.md`.
-  - Workflows actualizados para generar `acceptance.md`.
-  - `task.md` simplificado.
-- **Alcance**: Ciclos Long y Short a partir de la Tarea 23.
-
----
-
-## 2. Inputs contractuales
-- **Task**: [task.md](file:///Users/milos/Documents/workspace/extensio/.agent/artifacts/22-standardize-phase-0-artifact/task.md)
-- **Analysis**: [analysis.md](file:///Users/milos/Documents/workspace/extensio/.agent/artifacts/22-standardize-phase-0-artifact/architect/analysis.md)
-- **Acceptance Criteria**: AC-1 a AC-5 definidos en la Fase 0.
-
-**Dispatch de dominios**
-```yaml
-plan:
-  dispatch:
-    - domain: core
-      action: refactor
-      workflow: workflow.tasklifecycle.phase-0-acceptance-criteria
-    - domain: core
-      action: refactor
-      workflow: workflow.tasklifecycle-short.short-phase-1-brief
-```
-
----
-
-## 3. Desglose de implementación (pasos)
-
-### Paso 1: Registro de nuevo template
-- **Descripción**: Añadir el alias `acceptance` a `templates/index.md`.
-- **Dependencias**: Ninguna.
-- **Entregables**: `templates/index.md` actualizado.
-- **Agente responsable**: architect-agent
-
-### Paso 2: Creación del template `acceptance.md`
-- **Descripción**: Crear el archivo `.agent/templates/acceptance.md` con la estructura definida en el research.
-- **Dependencias**: Paso 1.
-- **Entregables**: `templates/acceptance.md` [NEW].
-- **Agente responsable**: architect-agent
-
-### Paso 3: Refactor de `templates/task.md`
-- **Descripción**: Eliminar las secciones de preguntas y criterios de aceptación, dejando solo una referencia.
-- **Dependencias**: Paso 2.
-- **Entregables**: `templates/task.md` [MODIFY].
-- **Agente responsable**: architect-agent
-
-### Paso 4: Actualización del Workflow Long (Fase 0)
-- **Descripción**: Modificar `workflows/tasklifecycle-long/phase-0-acceptance-criteria.md` para:
-  1. Generar `acceptance.md`.
-  2. Verificar su existencia en el Gate.
-  3. No inyectar los AC en `task.md`.
-- **Dependencias**: Paso 3.
-- **Entregables**: `workflows/tasklifecycle-long/phase-0-acceptance-criteria.md` [MODIFY].
-- **Agente responsable**: architect-agent
-
-### Paso 5: Actualización del Workflow Short (Fase 1)
-- **Descripción**: Modificar `workflows/tasklifecycle-short/short-phase-1-brief.md` para generar también `acceptance.md` de forma independiente al `brief.md`.
-- **Dependencias**: Paso 4.
-- **Entregables**: `workflows/tasklifecycle-short/short-phase-1-brief.md` [MODIFY].
-- **Agente responsable**: architect-agent
-
----
-
-## 4. Asignación de responsabilidades (Agentes)
-- **Architect-Agent**
-  - Ejecuta todos los pasos de implementación ya que son cambios estructurales en el sistema de orquestación.
-- **QA / Verification-Agent**
-  - Validará el flujo creando una tarea de prueba (ID 23) y verificando que el Gate 0 pase correctamente con los nuevos archivos.
-
----
-
-## 5. Estrategia de testing y validación
-- **Manual / Simulación**:
-  1. Iniciar una nueva tarea candidate (`/init` o similar).
-  2. Ejecutar el flujo de Fase 0 (Long).
-  3. Verificar que se crean `task.md` y `acceptance.md` en el directorio de la tarea.
-  4. Verificar que el Gate de Fase 0 se cumple.
-  5. Repetir para el ciclo Short.
-
----
-
-## 6. Estimaciones y pesos de implementación
-- **Paso 1-2**: Bajo (1 pt)
-- **Paso 3**: Bajo (1 pt)
-- **Paso 4-5**: Medio (3 pts) - Requiere cuidado en el orden de escritura y validación.
-
----
-
-## 7. Puntos críticos y resolución
-- **Punto crítico 1**: El parser de Gates de Antigravity debe ser robusto ante el cambio de ubicación de los datos.
-  - **Resolución**: Asegurar que el Gate 0 del workflow usa `view_file` sobre el nuevo artefacto y no sobre `task.md`.
-
----
-
-## 8. Criterios de finalización
-- [ ] `templates/index.md` tiene el alias `acceptance`.
-- [ ] Existe `templates/acceptance.md`.
-- [ ] `templates/task.md` no tiene secciones de AC.
-- [ ] Los workflows Long/Short generan `acceptance.md`.
-- [ ] Una tarea nueva pasa el Gate 0 con éxito.
-
----
-
-## 9. Aprobación del desarrollador (OBLIGATORIA)
-```yaml
-approval:
-  developer:
-    decision: null
-    date: null
-    comments: null
-```

package/dist/artifacts/22-standardize-phase-0-artifact/researcher/research.md

@@ -1,76 +0,0 @@
----
-artifact: research
-phase: phase-1-research
-owner: researcher-agent
-status: draft
-related_task: 22-standardize-phase-0-artifact
----
-
-# Research Report — 22-standardize-phase-0-artifact
-
-> [!CAUTION]
-> **REGLA PERMANENT**: Este documento es SOLO documentación.
-> El researcher-agent documenta hallazgos SIN analizar, SIN recomendar, SIN proponer soluciones.
-> El análisis corresponde a Phase 2.
-
-## 1. Resumen ejecutivo
-- **Problema investigado**: Cómo estandarizar el flujo de la Fase 0 para que genere un artefacto independiente (`acceptance.md`) en lugar de saturar el `task.md`.
-- **Objetivo de la investigacion**: Identificar los templates, workflows e índices que deben ser modificados para implementar esta arquitectura de "1 fase = 1 artefacto".
-- **Principales hallazgos**: El sistema actual guarda preguntas y criterios en `task.md`. Tanto el ciclo Long como el Short se beneficiarán de la separación para mejorar la validación de Gates y la legibilidad.
-
----
-
-## 2. Necesidades detectadas
-- **Template dedicado**: Necesidad de `templates.acceptance` para el nuevo archivo.
-- **Limpieza de `task.md`**: Eliminar las secciones de preguntas y criterios del template base de tareas.
-- **Estandarización de Workflows**: Actualizar `phase-0-acceptance-criteria.md` y `short-phase-1-brief.md` para que escriban en el nuevo archivo.
-- **Gestión de Alias**: Asegurar que `task.acceptance` referencie correctamente al nuevo artefacto.
-
----
-
-## 3. Hallazgos técnicos
-- **Workflow Long**: Utiliza `templates.task` para crear el current task. Se debe modificar el paso de creación para que genere dos archivos o modifique el `task.md` inyectando solo el alias.
-- **Workflow Short**: Ya genera un `brief.md`. Se debe alinear para que los criterios de aceptación sigan la misma estructura que en el ciclo Long.
-- **Plantilla de Tareas**: Las líneas 72 a 104 de `templates/task.md` contienen lógica de Fase 0 que debe ser extraída.
-- **Índice de Plantillas**: `templates/index.md` es el punto central para registrar el nuevo alias `acceptance`.
-
----
-
-## 4. APIs Web / WebExtensions relevantes
-- No aplica.
-
----
-
-## 5. Compatibilidad multi-browser
-- No aplica.
-
----
-
-## 6. Oportunidades AI-first detectadas
-- **Validación Automática**: El uso de un archivo independiente facilita que agentes de auditoría verifiquen el cumplimiento del contrato sin parsear el estado de la tarea.
-- **Modularidad**: Permite que las herramientas de CLI operen sobre el "contrato de aceptación" de forma aislada.
-
----
-
-## 7. Riesgos identificados
-- **Riesgo: Retrocompatibilidad**: Las tareas en curso (1-21) no tendrán este archivo. (Mitigación: Aplicar solo a Tareas 23+).
-- **Riesgo: Fragmentación**: Tener demasiados archivos pequeños podría abrumar al desarrollador si no se gestionan bien los alias. (Mitigación: Uso estricto de alias en el índice de artefactos).
-
----
-
-## 8. Fuentes
-- `.agent/templates/task.md`
-- `.agent/workflows/tasklifecycle-long/phase-0-acceptance-criteria.md`
-- `.agent/workflows/tasklifecycle-short/short-phase-1-brief.md`
-- `.agent/templates/index.md`
-
----
-
-## 9. Aprobación del desarrollador (OBLIGATORIA)
-```yaml
-approval:
-  developer:
-    decision: null
-    date: null
-    comments: null
-```

package/dist/artifacts/22-standardize-phase-0-artifact/results.md

@@ -1,36 +0,0 @@
----
-artifact: results
-phase: phase-6-results-acceptance
-owner: architect-agent
-related_task: 22-standardize-phase-0-artifact
----
-
-# Results — 22-standardize-phase-0-artifact
-
-## 1. Conclusión técnica
-Se ha implementado con éxito la estandarización de la Fase 0 (Acceptance Criteria). El sistema ahora cumple con el principio de **"1 Fase = 1 Artefacto"**, lo que mejora la limpieza de los archivos y facilita la automatización del flujo.
-
-## 2. Cambios realizados
-
-### Templates
-- **`templates/acceptance.md`**: Nuevo artefacto para el contrato de la tarea.
-- **`templates/task.md`**: Simplificado a un centro de metadatos y estado.
-- **`templates/index.md`**: Registrado el alias `acceptance`.
-
-### Workflows
-- **`phase-0-acceptance-criteria` (Long)**: Ahora genera `task.md` y `acceptance.md` de forma independiente.
-- **`short-phase-1-brief` (Short)**: Ahora genera `brief.md` y `acceptance.md` de forma independiente.
-
-## 3. Verificación
-- Auditoría técnica de archivos completada.
-- Gates actualizados para validar ambos archivos obligatoriamente.
-
-## 4. Siguiente paso (Test Real)
-Para validar al 100% que el sistema portable funciona con esta nueva estructura, iniciaremos la **Tarea 23**.
-
----
-## Aceptación final
-```yaml
-decision: SI | NO
-date: 2026-01-19
-```

package/dist/artifacts/22-standardize-phase-0-artifact/task.md

@@ -1,115 +0,0 @@
-# Task (Current)
-
-## Identificación
-- id: 22
-- title: Standardize Phase 0 Artifact
-- scope: current
-- owner: architect-agent
-
-## Origen
-- created_from:
-  - workflow: tasklifecycle
-  - source: architect intervention
-  - candidate_path: artifacts.candidate.task
-
-## Descripción de la tarea
-Implementar un artefacto dedicado para la Fase 0 (`acceptance.md`) para estandarizar el flujo 1 fase = 1 artefacto. Esto desacopla la definición del contrato de la gestión del estado de la tarea en `task.md`.
-
-## Objetivo
-Crear el template `acceptance.md`, registrarlo en los índices y actualizar los workflows de la Fase 0 (Long y Short) para que generen y validen este nuevo archivo como output obligatorio, eliminando la redundancia en `task.md`.
-
-## Estado del ciclo de vida (FUENTE ÚNICA DE VERDAD)
-
-```yaml
-task:
-  id: "22"
-  title: "Standardize Phase 0 Artifact"
-  strategy: "long"
-  phase:
-    current: "phase-4-implementation"
-    validated_by: "architect-agent"
-    updated_at: "2026-01-19T09:43:00Z"
-  lifecycle:
-    phases:
-      phase-0-acceptance-criteria:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-19T09:40:00Z"
-      phase-1-research:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-19T09:41:00Z"
-      phase-2-analysis:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-19T09:42:00Z"
-      phase-3-planning:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-19T09:42:00Z"
-      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: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-19T09:44:00Z"
-      phase-7-evaluation:
-        completed: true
-        validated_by: "architect-agent"
-        validated_at: "2026-01-19T09:44:00Z"
-      phase-8-commit-push:
-        completed: false
-        status: "pending_manual_commit"
-```
-
-## 5 Preguntas Obligatorias (REQUERIDO - Phase 0)
-
-| # | Pregunta (formulada por architect) | Respuesta (del desarrollador) |
-|---|-----------------------------------|-------------------------------|
-| 1 | ¿Debemos mantener una copia de los criterios en `task.md` o solo una referencia al archivo `acceptance.md`? | Solo referencia para mantener el uso de alias. |
-| 2 | ¿Actualizamos tanto el ciclo Long como el Short con este cambio? | Si, ambos. |
-| 3 | ¿Qué nombre exacto tendrá la nueva clave en `templates/index.md`? | acceptance. |
-| 4 | ¿Deseas que el workflow de Fase 0 borre las secciones de criterios del `task.md` original en el template base? | Si. |
-| 5 | ¿Cómo manejaremos la retrocompatibilidad con las tareas actuales que no tienen `acceptance.md`? | Ignorarlas y aplicar el cambio. |
-
----
-
-## Acceptance Criteria (OBLIGATORIO PARA CURRENT TASK)
-
-1. Alcance:
-   - Modificación de workflows `phase-0-acceptance-criteria.md` y `short-phase-1-brief.md`.
-   - Creación de `templates/acceptance.md`.
-   - Registro del nuevo template en `templates/index.md`.
-   - Modificación de `templates/task.md` para eliminar secciones redundantes.
-
-2. Entradas / Datos:
-   - Estructura actual de workflows y templates.
-
-3. Salidas / Resultado esperado:
-   - Flujo de Fase 0 genera un archivo `acceptance.md` separado.
-   - `task.md` queda limpio de criterios detallados, manteniendo solo metadatos y estado.
-   - El alias `task.acceptance` apunta al nuevo archivo.
-
-4. Restricciones:
-   - Mantener compatibilidad de alias.
-   - Los Gates deben validar la existencia del nuevo archivo.
-
-5. Criterio de aceptación (Done):
-   - Una nueva tarea (ID 23+) genera automáticamente `acceptance.md`.
-   - El sistema valida el Gate 0 basándose en la existencia y formato del nuevo artefacto.
-
-## Historial de validaciones (append-only)
-```yaml
-history:
-  - phase: "phase-0-acceptance-criteria"
-    action: "completed"
-    validated_by: "architect-agent"
-    timestamp: "2026-01-19T09:40:00Z"
-    notes: "Estandarización de Fase 0 definida. Pasando a Research."
-```

package/dist/artifacts/22-standardize-phase-0-artifact/verification.md

@@ -1,41 +0,0 @@
----
-artifact: verification
-phase: phase-5-verification
-owner: architect-agent
-status: draft
-related_task: 22-standardize-phase-0-artifact
----
-
-# Verification — 22-standardize-phase-0-artifact
-
-## 1. Objetivos de la verificación
-- Validar que el flujo **Long** genera `task.md` y `acceptance.md` por separado.
-- Validar que el flujo **Short** genera `brief.md` y `acceptance.md` por separado.
-- Confirmar que los Gates bloquean correctamente si falta alguno de los archivos.
-- Verificar la limpieza de `task.md` (sin secciones redundantes).
-
-## 2. Resultados de las pruebas
-
-### Prueba 1: Auditoría de Código (Checklist)
-- [x] `templates/index.md`: Alias `acceptance` registrado.
-- [x] `templates/acceptance.md`: Creado y funcional.
-- [x] `templates/task.md`: Refactorizado (secciones extraídas).
-- [x] `workflows/tasklifecycle-long/phase-0-acceptance-criteria.md`: Modificado para multienfrentamiento de archivos.
-- [x] `workflows/tasklifecycle-short/short-phase-1-brief.md`: Modificado para multienfrentamiento de archivos.
-
-### Prueba 2: Simulación de Tarea 23 (Pendiente de confirmación del usuario)
-- Planeado: Iniciar Tarea 23 tras el cierre de la 22.
-
-## 3. Conclusión
-La implementación cumple con los requisitos técnicos y estructurales. El sistema ahora produce artefactos atómicos por cada fase, lo que mejora la trazabilidad y la escalabilidad del sistema portable.
-
----
-
-## 4. Aprobación del desarrollador
-```yaml
-approval:
-  developer:
-    decision: null
-    date: null
-    comments: null
-```

package/dist/artifacts/23-auditoria-de-indexes-y-alias/acceptance.md

@@ -1,62 +0,0 @@
-# Acceptance Criteria — 23-auditoria-de-indexes-y-alias
-
-## 1. Definición Consolidada
-Realizar una auditoría técnica completa de la infraestructura de direccionamiento por alias del sistema agéntico. El objetivo es confirmar que todos los recursos (reglas, flujos, plantillas y ficheros de agentes) están correctamente indexados y son accesibles sin ambigüedades.
-
-## 2. Respuestas a Preguntas de Clarificación
-> Esta sección documenta las respuestas del desarrollador a las 5 preguntas formuladas por el architect-agent.
-
-| # | Pregunta (formulada por architect) | Respuesta (del desarrollador) |
-|---|-----------------------------------|-------------------------------|
-| 1 | ¿Qué dominios específicos deben ser auditados prioritariamente? | Todos (rules, workflows, templates, artifacts). |
-| 2 | ¿Deseas un reporte puramente documental o que incluya correcciones? | Solo puramente documental (informe). |
-| 3 | ¿Debemos auditar también la consistencia de los alias en `AGENTS.md`? | Sí. |
-| 4 | ¿Existe algún alias o índice que sospeches que está dando problemas? | No, pero se hace por procedimiento y seguridad. |
-| 5 | ¿Cómo prefieres recibir el resultado de la auditoría? | Un informe. |
-
----
-
-## 3. Criterios de Aceptación Verificables
-> Listado de criterios derivados de las respuestas anteriores que deben ser verificados en la Fase 5.
-
-1. Alcance:
-   - Auditoría de los dominios: rules, workflows, templates, artifacts.
-   - Auditoría de alias en `AGENTS.md`.
-
-2. Entradas / Datos:
-   - Archivos `index.md` de cada dominio.
-   - Estructura de carpetas bajo `.agent/`.
-
-3. Salidas / Resultado esperado:
-   - Un informe de auditoría detallado detectando discrepancias (si las hay).
-
-4. Restricciones:
-   - El agente NO debe realizar correcciones automáticas, solo informar.
-
-5. Criterio de aceptación (Done):
-   - El informe cubre todos los dominios solicitados y confirma la validez de los alias o documenta los errores encontrados.
-
----
-
-## Aprobación (Gate 0)
-Este documento constituye el contrato de la tarea. Su aprobación es bloqueante para pasar a Phase 1.
-
-```yaml
-approval:
-  developer:
-    decision: null # SI | NO
-    date: null
-    comments: null
-```
-
----
-
-## Historial de validaciones (Phase 0)
-```yaml
-history:
-  - phase: "phase-0-acceptance-criteria"
-    action: "completed"
-    validated_by: "architect-agent"
-    timestamp: "2026-01-19T09:45:00Z"
-    notes: "Acceptance criteria definidos mediante flujo independiente."
-```