@thatix.io/context-first-agents-cli 0.1.1 → 0.2.1

package/templates/commands/es/engineer/work.md

@@ -0,0 +1,290 @@
+# Ejecución del Trabajo
+
+Este comando ejecuta una unidad de trabajo en el workspace actual, implementando parte del plan técnico.
+
+## 📋 Requisitos Previos
+
+Antes de ejecutar, asegúrese de que:
+- Ha ejecutado `/start` y `/plan` para obtener el plan técnico
+- Está en el workspace correcto: `<orchestrator>/.sessions/<ISSUE-ID>/`
+- Tiene disponibles los archivos `.sessions/<ISSUE-ID>/`:
+  - `context.md` (inmutable)
+  - `architecture.md` (inmutable)
+  - `plan.md` (mutable)
+
+## 📋 Configuración del Proyecto
+
+**⚠️ IMPORTANTE: ¡Siempre lea los archivos de configuración del proyecto ANTES de ejecutar este comando!**
+
+### Archivos Obligatorios
+
+1. **`context-manifest.json`** (raíz del orchestrator)
+   - Lista de repositorios del proyecto
+   - Roles de cada repositorio (metaspecs, application, etc.)
+   - URLs y dependencias entre repositorios
+
+2. **`ai.properties.md`** (raíz del orchestrator)
+   - Configuraciones del proyecto (`project_name`, `base_path`)
+   - Sistema de gestión de tareas (`task_management_system`)
+   - Credenciales y configuraciones específicas
+
+### Cómo Leer
+
+```bash
+# 1. Leer context-manifest.json
+cat context-manifest.json
+
+# 2. Leer ai.properties.md
+cat ai.properties.md
+```
+
+### Información Esencial
+
+Después de leer los archivos, tendrá:
+- ✅ Lista completa de repositorios del proyecto
+- ✅ Ubicación del repositorio de metaspecs
+- ✅ Base path para localizar repositorios
+- ✅ Sistema de gestión de tareas configurado
+- ✅ Configuraciones específicas del proyecto
+
+**🛑 NO continúe sin leer estos archivos!** ¡Contienen información crítica para la correcta ejecución del comando!
+
+
+## 📍 IMPORTANTE: Entienda la Estructura
+
+**Workspace** (donde trabaja):
+```
+<orchestrator>/.sessions/<ISSUE-ID>/
+├── repo-1/          # worktree con branch feature/<ISSUE-ID>
+├── repo-2/          # worktree con branch feature/<ISSUE-ID>
+├── context.md       # contexto (inmutable)
+├── architecture.md  # arquitectura (inmutable)
+└── plan.md          # plan (mutable)
+```
+
+**Repositorios principales** (NO tocar):
+```
+{base_path}/repo-1/  # repo principal (branch main/master)
+{base_path}/repo-2/  # repo principal (branch main/master)
+```
+
+**REGLA DE ORO**:
+- ✅ Trabaje SOLO dentro de `<orchestrator>/.sessions/<ISSUE-ID>/`
+- ✅ Haga commits en los worktrees dentro del workspace
+- ❌ NUNCA haga checkout en los repositorios principales
+- ❌ NUNCA navegue a `{base_path}/{repo-id}/`
+
+## 🛑 CRÍTICO: DÓNDE CREAR CÓDIGO
+
+**⚠️ ATENCIÓN: TODO CÓDIGO DEBE SER CREADO DENTRO DEL WORKTREE DEL REPOSITORIO!**
+
+**✅ CORRECTO** - Crear código dentro del worktree:
+```
+<orchestrator>/.sessions/<ISSUE-ID>/<repo-name>/src/file.ts  ✅
+<orchestrator>/.sessions/<ISSUE-ID>/<repo-name>/tests/test.ts  ✅
+<orchestrator>/.sessions/<ISSUE-ID>/<repo-name>/package.json  ✅
+```
+
+**❌ INCORRECTO** - NUNCA crear código directamente en .sessions:
+```
+<orchestrator>/.sessions/src/file.ts  ❌
+<orchestrator>/.sessions/<ISSUE-ID>/src/file.ts  ❌
+<orchestrator>/.sessions/<ISSUE-ID>/file.ts  ❌
+```
+
+**REGLA ABSOLUTA**:
+- 🛑 **TODO archivo de código** (`.ts`, `.js`, `.py`, `.java`, etc.) **DEBE estar dentro de** `<orchestrator>/.sessions/<ISSUE-ID>/<repo-name>/`
+- 🛑 **NUNCA cree código** directamente en `<orchestrator>/.sessions/` o `<orchestrator>/.sessions/<ISSUE-ID>/`
+- ✅ **Único lugar válido**: Dentro del worktree del repositorio específico
+
+## ⚠️ IMPORTANTE: Archivos Inmutables
+
+**Este comando debe LEER pero NO MODIFICAR:**
+- ✅ **LEER** `.sessions/<ISSUE-ID>/context.md` (inmutable)
+- ✅ **LEER** `.sessions/<ISSUE-ID>/architecture.md` (inmutable)
+- ✅ **ACTUALIZAR** `.sessions/<ISSUE-ID>/plan.md` (marcar progreso)
+- ✅ **IMPLEMENTAR** código **DENTRO DEL WORKTREE**: `.sessions/<ISSUE-ID>/<repo-name>/`
+- ✅ **HACER COMMITS** en los worktrees: `.sessions/<ISSUE-ID>/<repo-name>/`
+- ❌ **NO modificar `context.md` o `architecture.md`**
+- ❌ **NO hacer checkout de branches en los repositorios principales (fuera del workspace)**
+- 🛑 **NUNCA crear código en `.sessions/` o `.sessions/<ISSUE-ID>/` directamente**
+
+## 📚 Cargar MetaSpecs
+
+**Localizar MetaSpecs automáticamente**:
+1. Lea `context-manifest.json` del orchestrator
+2. Encuentre el repositorio con `"role": "metaspecs"`
+3. Lea `ai.properties.md` para obtener el `base_path`
+4. El metaspecs está en: `{base_path}/{metaspecs-repo-id}/`
+5. Lea los archivos `index.md` relevantes durante la implementación para:
+   - Seguir patrones de código
+   - Respetar arquitectura definida
+   - Usar convenciones correctas
+
+## 🎯 Objetivo
+
+Implementar una unidad de trabajo específica del plan, que puede involucrar:
+- Crear nuevos archivos/componentes
+- Modificar archivos existentes
+- Añadir pruebas
+- Actualizar documentación
+
+## 📝 Proceso de Trabajo
+
+**⚠️ IMPORTANTE: CONTROL DE PROGRESO**
+
+Este comando ejecuta el trabajo en **fases incrementales**. Después de completar cada **FASE PRINCIPAL** (ej: Fase 1 → Fase 2):
+
+1. 🛑 **PARE** la ejecución
+2. 📊 **PRESENTE** un resumen de lo realizado
+3. ❓ **PREGUNTE** al desarrollador si desea:
+   - Revisar el código implementado
+   - Hacer ajustes antes de continuar
+   - Continuar a la siguiente fase
+
+**IMPORTANTE**:
+- ✅ **PAUSE** entre fases principales (Fase 1 → Fase 2 → Fase 3)
+- ❌ **NO pause** entre subfases (Fase 1.1 → Fase 1.2 → Fase 1.3)
+
+**NO implemente todo de una vez**. Trabaje fase principal por fase principal, esperando confirmación del desarrollador.
+
+---
+
+### 1. Identificar Unidad de Trabajo
+
+Basado en el plan técnico (`./.sessions/<ISSUE-ID>/plan.md`), identifique:
+- Qué tarea específica se implementará ahora
+- En cuál(es) repositorio(s) del workspace
+- Qué archivos serán creados/modificados
+- Dependencias con otras tareas
+
+### 2. Implementación
+
+
+
+**IMPORTANTE**: Trabaje SOLO dentro del workspace en `.sessions/<ISSUE-ID>/`
+
+Para cada repositorio en el workspace:
+
+```bash
+# Navegue al worktree dentro del workspace
+cd <orchestrator>/.sessions/<ISSUE-ID>/<repo-name>/
+
+# Verifique que está en la rama correcta
+git branch  # debe mostrar * feature/<ISSUE-ID>
+
+# Implemente el código aquí
+```
+
+Ejecute la implementación siguiendo:
+- **Patrones del proyecto**: Consulte guías de estilo y arquitectura
+- **Stack aprobada**: Use solo tecnologías documentadas en metaspecs
+- **Pruebas**: Implemente pruebas conforme a los patrones del proyecto
+- **Documentación**: Actualice comentarios y docs cuando sea necesario
+
+
+
+### 3. Validación Local
+
+Antes de commitear:
+- Ejecute pruebas unitarias/integración
+- Verifique linting y formato
+- Confirme que no rompió funcionalidades existentes
+
+
+
+### 4. Commit
+
+Para cada repositorio modificado **dentro del workspace**:
+
+```bash
+# Navegue al worktree dentro del workspace
+cd <orchestrator>/.sessions/<ISSUE-ID>/<repo-name>/
+
+# Añada los cambios
+git add .
+
+# Commit
+git commit -m "tipo: descripción concisa
+
+- Detalle 1
+- Detalle 2
+
+Refs: <ISSUE-ID>"
+```
+
+**Tipos de commit**: `feat`, `fix`, `refactor`, `test`, `docs`, `chore`
+
+**⚠️ PAUSA OBLIGATORIA**: Después de completar TODA la fase principal (identificación + implementación + validación + commit + actualización del plan.md), **PARE** y muestre al desarrollador:
+- Resumen completo de la fase
+- Archivos creados/modificados
+- Commits realizados
+- Pregunte si desea revisar o continuar a la siguiente fase
+
+### 5. Actualización del Plan.md
+
+**POR CADA tarea completada**, actualice `./.sessions/<ISSUE-ID>/plan.md`:
+
+```markdown
+#### 1.1 - [Nombre de la Tarea] [Completada ✅]
+- [Detalle 1]
+- [Detalle 2]
+- [Detalle 3]
+
+**Archivos**:
+- `path/to/file1.ts` ✅
+- `path/to/file2.vue` ✅
+
+**Pruebas**:
+- Unit test: [Descripción] ✅
+- Integration test: [Descripción] ✅
+
+**Comentarios**:
+- Decisión: [Explicación de decisión técnica importante]
+- Aprendizaje: [Algo aprendido durante implementación]
+```
+
+**Marque estado de las tareas**:
+- `[No Iniciada ⏳]` - Tarea aún no comenzada
+- `[En Progreso ⏰]` - Tarea en curso
+- `[Completada ✅]` - Tarea finalizada y validada
+
+## 🔍 Checklist de Calidad
+
+Antes de considerar la unidad completa:
+- [ ] Código implementado y probado
+- [ ] Pruebas pasando
+- [ ] Linting/formato OK
+- [ ] Documentación actualizada (si es necesario)
+- [ ] Commit realizado en todos los repositorios afectados
+- [ ] `plan.md` actualizado con progreso y comentarios
+
+## ⚠️ Principio Jidoka
+
+Si encuentra problemas durante la implementación:
+1. 🛑 **PARE** la implementación
+2. 📝 **DOCUMENTE** el problema encontrado
+3. 💬 **ALERTE** al usuario y discuta soluciones
+4. 🔄 **AJUSTE** el plan si es necesario
+
+---
+
+**Argumentos proporcionados**:
+
+```
+#$ARGUMENTS
+```
+
+---
+
+## 🎯 Próximos Pasos
+
+- **Continuar implementación**: Ejecute `/work` nuevamente para la próxima unidad
+- **Finalizar feature**: Cuando todo esté implementado, ejecute `/pre-pr`
+
+## 💡 Consejos
+
+- Trabaje en unidades pequeñas e incrementales
+- Commit frecuente (commits atómicos)
+- Documente decisiones importantes en la sesión
+- Mantenga los repositorios sincronizados entre sí

package/templates/commands/es/orchestrate.md

@@ -0,0 +1,125 @@
+# /orchestrate — Orquestación de Agentes Efímeros Dinámicos
+
+Eres el **Orquestador**. Tu tarea es convertir una spec aprobada en el **grafo mínimo de
+agentes efímeros y especializados** y coordinar su ejecución — en vez de correr un único
+agente monolítico sobre un contexto gigante compartido.
+
+Este comando REEMPLAZA el flujo lineal `start → plan → work` por un grafo que el runtime
+deriva automáticamente. `/plan` y `/work` pueden seguir existiendo como escape hatches manuales.
+
+**Argumento**: `#$ARGUMENTS` (un ISSUE-ID y/o la ruta a un archivo de spec/task).
+
+---
+
+## Reglas de oro
+
+- ✅ Lee `context-manifest.json` + `ai.properties.md` del orquestador.
+- ✅ El contexto del propio Orquestador se mantiene LIGERO: coordinas, no implementas.
+- ✅ Cada unidad de trabajo la hace un **subagente (Task tool)** con un **contrato de contexto aislado**.
+- ✅ Nunca crees un catálogo de agentes de dominio (nada de `frontend-agent`, `payments-agent`).
+  Un worker se compila al vuelo: `arquetipo + objetivo + repositorio + contrato de contexto + herramientas`.
+- ❌ Nunca vuelques repositorios enteros en un subagente. Selecciona, no vuelques.
+- ❌ Nunca dejes que un subagente modifique specs normativas.
+
+---
+
+## Paso 1 — Cargar configuración
+
+1. Lee `context-manifest.json`. Extrae `repositories[]` (cada uno con `id`, `role`,
+   `hints`, opcionalmente `context`, `testCommand`, `mainBranch`) y el bloque
+   `orchestration` (`archetypes`, `riskSignals`, `parallelism`, `contextPolicy`,
+   `maxFilesPerWorker`, `indexes`).
+2. Lee `ai.properties.md` para `base_path` y la config del task manager (si existe).
+3. Localiza el repo de specs: el repositorio con `role: metaspecs` (o `specs-provider`).
+
+## Paso 2 — Cargar la spec
+
+- Si hay task manager y el argumento es un ISSUE-ID, lee el issue vía el MCP apropiado.
+  Si no, lee el archivo de spec pasado como argumento, o pídeselo al usuario.
+- Lee los `orchestration.indexes` relevantes (los routers de contexto) para ubicarte.
+  NO leas todo el codebase — aquí sólo clasificas y ruteas.
+
+## Paso 3 — Clasificar complejidad (reglas determinísticas)
+
+Calcula sobre el texto de la spec:
+
+- **repoHits** = nº de repositorios cuyo `id` O algún `hint` aparece en la spec.
+- **risks** = nº de `orchestration.riskSignals` que aparecen en la spec.
+- Si el frontmatter de la spec define `complexity: simple|medium|complex`, úsalo tal cual.
+
+En caso contrario:
+
+| Condición | Nivel |
+|---|---|
+| `repoHits ≥ 3` O `risks ≥ 2` O spec muy grande | **complex** |
+| `repoHits ≥ 2` O `risks ≥ 1` O spec moderadamente grande | **medium** |
+| en caso contrario | **simple** |
+
+Declara la clasificación y el motivo explícitamente antes de continuar.
+
+## Paso 4 — Construir el grafo de ejecución (DAG)
+
+Instancia workers desde `orchestration.archetypes`. Cada nodo tiene:
+`{ id, archetype, objective, repository, dependsOn[], contextHints[] }`.
+
+- **simple**
+  - `W1 implementer` en el único repo impactado
+  - `W2 reviewer` (dependsOn W1) — verificar contra la spec normativa
+
+- **medium**
+  - un `implementer` por repo impactado (corren en **paralelo**, sin deps entre sí)
+  - `integrator` (dependsOn todos los implementers) — chequear contratos/consistencia cross-repo
+  - `tester` (dependsOn integrator) — correr el `testCommand` de cada repo
+
+- **complex** = medium, más:
+  - `reviewer` (dependsOn integrator) — review **adversarial** de reglas de negocio,
+    seguridad, migraciones y premisas ocultas. Prefiere un reviewer especializado si los
+    riskSignals lo indican (ej.: datos, integraciones, multi-tenant).
+
+Respeta `parallelism.maxWorkers` y `maxPerRepository`. Si los repos impactados exceden el
+límite, hazlos por lotes y avísalo — nunca descartes un repo silenciosamente.
+
+Renderiza el grafo como una tabla corta (id, archetype, repo, dependsOn) y **pide
+aprobación del usuario** antes de spawnear cualquier cosa.
+
+## Paso 5 — Compilar un Contrato de Contexto por nodo
+
+Para cada worker, arma el contrato que se pegará en el prompt del subagente.
+Ver `agents/CONTEXT-CONTRACT.md` para el formato exacto. En resumen:
+
+- **read**: `orchestration.indexes` + el `context[]` de ese repo (sólo archivos que existen)
+- **mayDiscover**: referencias alcanzables desde los índices; archivos del repo que la task exige
+- **mustNotAssume**: reglas de negocio no dichas; contratos externos no indexados; nada fuera de la spec
+- **writeBoundary**: sólo el worktree de ese repo (o artefactos de la sesión para integrator/tester)
+- **limits**: `contextPolicy` (por defecto `select-do-not-dump`), `maxFilesPerWorker`
+- **return**: summary, changes, evidence, tests, unresolved, confidence
+
+## Paso 6 — Spawnear los agentes efímeros (Task tool)
+
+Ejecuta el DAG respetando `dependsOn`:
+
+1. **Ola paralela**: spawnea todos los nodos con dependencias satisfechas **en un único
+   mensaje con múltiples llamadas Task**, para que corran concurrentemente. Dale a cada
+   subagente SÓLO su contrato compilado + objetivo — nunca la conversación entera.
+2. Espera a que la ola termine. Recolecta el retorno estructurado de cada subagente.
+3. **Siguiente ola**: spawnea los nodos cuyas dependencias ya están satisfechas. Repite.
+
+Usa las plantillas de arquetipo en `agents/` (implementer, reviewer, integrator, tester…)
+como marco de cada subagente, rellenadas con objetivo, repositorio y contrato.
+
+Cada subagente es **efímero**: hace su trabajo acotado, retorna el reporte, y su contexto
+se descarta. El Orquestador sólo guarda los reportes.
+
+## Paso 7 — Integrar y reportar
+
+- Persiste artefactos en `.sessions/<ISSUE-ID>/`:
+  `execution-plan.md` (el DAG) y `workers/<agent-id>.md` (contrato + retorno de cada uno).
+- Resume: qué cambió por repo, evidencias, tests corridos, preguntas abiertas y cualquier
+  repo que quedó en lote/diferido.
+- Si un `reviewer` retornó hallazgos bloqueantes, NO sigas a PR — muéstralos y pregunta al
+  usuario cómo proceder.
+
+## Escalación
+
+Si un subagente llega a un stop Jidoka (ambigüedad, conflicto de spec, contrato faltante),
+debe retornar `unresolved` en vez de adivinar. Súbelo al usuario en vez de empujar.

package/templates/commands/es/products/check.md

@@ -0,0 +1,271 @@
+# Validación contra MetaSpecs
+
+Este comando valida requisitos, decisiones o implementaciones contra las metaspecs del proyecto.
+
+## ⚠️ IMPORTANTE: Modo de Operación
+
+**Este comando es para VALIDACIÓN:**
+- ✅ Validar contra metaspecs
+- ✅ **LEER** archivos de los repositorios (solo lectura)
+- ✅ Generar informe de validación
+- ❌ **NO hacer checkout de branches en los repositorios principales**
+- ❌ **NO modificar código**
+- ❌ **NO modificar `context.md` o `architecture.md`**
+
+## 📋 Configuración del Proyecto
+
+**⚠️ IMPORTANTE: ¡Siempre lea los archivos de configuración del proyecto ANTES de ejecutar este comando!**
+
+### Archivos Obligatorios
+
+1. **`context-manifest.json`** (raíz del orchestrator)
+   - Lista de repositorios del proyecto
+   - Roles de cada repositorio (metaspecs, application, etc.)
+   - URLs y dependencias entre repositorios
+
+2. **`ai.properties.md`** (raíz del orchestrator)
+   - Configuraciones del proyecto (`project_name`, `base_path`)
+   - Sistema de gestión de tareas (`task_management_system`)
+   - Credenciales y configuraciones específicas
+
+### Cómo Leer
+
+```bash
+# 1. Leer context-manifest.json
+cat context-manifest.json
+
+# 2. Leer ai.properties.md
+cat ai.properties.md
+```
+
+### Información Esencial
+
+Después de leer los archivos, tendrá:
+- ✅ Lista completa de repositorios del proyecto
+- ✅ Ubicación del repositorio de metaspecs
+- ✅ Base path para localizar repositorios
+- ✅ Sistema de gestión de tareas configurado
+- ✅ Configuraciones específicas del proyecto
+
+**🛑 NO continúe sin leer estos archivos!** Contienen información crítica para la correcta ejecución del comando.
+
+
+## 🎯 Objetivo
+
+Garantizar alineación con:
+- Estrategia de producto
+- Arquitectura técnica
+- Estándares y convenciones
+- ADRs (Architecture Decision Records)
+
+## 📋 Cuándo Usar
+
+Ejecute este comando:
+- Después de `/spec` - validar PRD
+- Después de `/plan` - validar plan técnico
+- Durante `/work` - validar decisiones de implementación
+- Antes de `/pr` - validación final
+
+## 📚 Cargar MetaSpecs
+
+**Localizar MetaSpecs automáticamente**:
+1. Lea `context-manifest.json` del orchestrator
+2. Encuentre el repositorio con `"role": "metaspecs"`
+3. Lea `ai.properties.md` para obtener el `base_path`
+4. El metaspecs está en: `{base_path}/{metaspecs-repo-id}/`
+
+## 🔍 Proceso de Validación
+
+### 1. Identificar MetaSpecs Disponibles
+
+Navegue hasta el directorio de metaspecs e identifique qué metaspecs existen:
+
+```bash
+ls -la {base_path}/{metaspecs-repo-id}/
+```
+
+### 2. Validación de Negocio
+
+Si existen metaspecs de negocio (`repositorio de MetaSpecs (sección de negocio)`):
+
+```markdown
+## Validación de Negocio
+
+### Estrategia de Producto
+- **Archivo**: `repositorio de MetaSpecs (sección de negocio)PRODUCT_STRATEGY.md`
+- **Validación**: [¿Esta feature está alineada con la estrategia?]
+- **Estado**: ✅ Alineado / ⚠️ Parcialmente / ❌ Desalineado
+- **Notas**: [Observaciones]
+
+### Personas
+- **Archivo**: `repositorio de MetaSpecs (sección de negocio)CUSTOMER_PERSONAS.md`
+- **Validación**: [¿Atiende a la persona correcta?]
+- **Estado**: ✅ Alineado / ⚠️ Parcialmente / ❌ Desalineado
+- **Notas**: [Observaciones]
+
+### Métricas
+- **Archivo**: `repositorio de MetaSpecs (sección de negocio)PRODUCT_METRICS.md`
+- **Validación**: [¿Métrica de éxito está documentada?]
+- **Estado**: ✅ Alineado / ⚠️ Parcialmente / ❌ Desalineado
+- **Notas**: [Observaciones]
+```
+
+### 3. Validación Técnica
+
+Si existen metaspecs técnicas (`repositorio de MetaSpecs (sección técnica)`):
+
+```markdown
+## Validación Técnica
+
+### Stack Tecnológica
+- **Archivo**: `repositorio de MetaSpecs (sección técnica)meta/stack.md`
+- **Validación**: [¿Usa solo tecnologías aprobadas?]
+- **Estado**: ✅ Conforme / ⚠️ Excepción justificada / ❌ No conforme
+- **Notas**: [Tecnologías usadas y justificaciones]
+
+### Arquitectura
+- **Archivo**: `repositorio de MetaSpecs (sección técnica)ARCHITECTURE.md`
+- **Validación**: [¿Sigue patrones arquitectónicos?]
+- **Estado**: ✅ Conforme / ⚠️ Parcialmente / ❌ No conforme
+- **Notas**: [Observaciones]
+
+### ADRs (Architecture Decision Records)
+- **Directorio**: `repositorio de MetaSpecs (sección técnica)adr/`
+- **Validación**: [¿Respeta decisiones arquitectónicas documentadas?]
+- **ADRs Relevantes**: [Lista de ADRs verificados]
+- **Estado**: ✅ Conforme / ⚠️ Conflicto menor / ❌ Conflicto crítico
+- **Notas**: [Observaciones]
+
+### Reglas de Negocio
+- **Archivo**: `repositorio de MetaSpecs (sección técnica)BUSINESS_LOGIC.md`
+- **Validación**: [¿Implementa reglas de negocio correctamente?]
+- **Estado**: ✅ Conforme / ⚠️ Parcialmente / ❌ No conforme
+- **Notas**: [Observaciones]
+```
+
+### 4. Validación de Estándares
+
+```markdown
+## Validación de Estándares
+
+### Código
+- **Archivo**: `repositorio de MetaSpecs (sección técnica)CODE_STANDARDS.md`
+- **Validación**: [¿Sigue estándares de código?]
+- **Estado**: ✅ Conforme / ⚠️ Pequeñas desviaciones / ❌ No conforme
+
+### Pruebas
+- **Archivo**: `repositorio de MetaSpecs (sección técnica)TEST_STANDARDS.md`
+- **Validación**: [¿Estrategia de pruebas adecuada?]
+- **Estado**: ✅ Conforme / ⚠️ Parcialmente / ❌ No conforme
+
+### Documentación
+- **Archivo**: `repositorio de MetaSpecs (sección técnica)DOC_STANDARDS.md`
+- **Validación**: [¿Documentación adecuada?]
+- **Estado**: ✅ Conforme / ⚠️ Parcialmente / ❌ No conforme
+```
+
+### 5. Identificación de Conflictos
+
+Si hay conflictos o desalineamientos:
+
+```markdown
+## Conflictos Identificados
+
+### Conflicto 1: [Descripción]
+- **Severidad**: Crítico / Alto / Medio / Bajo
+- **Metaspec**: [Archivo que está siendo violado]
+- **Descripción**: [Detalle del conflicto]
+- **Recomendación**: [Cómo resolver]
+
+### Conflicto 2: [Descripción]
+[Mismo formato arriba]
+```
+
+### 6. Excepciones Justificadas
+
+Si hay desviaciones justificadas:
+
+```markdown
+## Excepciones Justificadas
+
+### Excepción 1: [Descripción]
+- **Metaspec**: [Archivo que está siendo desviado]
+- **Desvío**: [Qué está diferente]
+- **Justificación**: [Por qué es necesario]
+- **Aprobación**: [Quién aprobó]
+- **Documentación**: [Dónde fue documentado]
+```
+
+## 📄 Guardado del Informe de Validación
+
+**PRIORIDAD 1: Usar MCP (Model Context Protocol)**
+
+- Lea `ai.properties.md` del orchestrator para identificar el `task_management_system`
+- Use el MCP apropiado para añadir el informe a la issue:
+  - Añada como comentario en la issue
+  - Actualice labels/tags según resultado (ej: "validated", "needs-adjustment", "blocked")
+  - Si hay conflictos críticos, actualice el estado de la issue
+- Informe al usuario: "✅ Informe de validación añadido a la issue [ID]"
+
+**FALLBACK: Crear archivo .md solo si MCP falla**
+
+Si el MCP no está disponible o falla, cree `./.sessions/<ISSUE-ID>/check-report.md`:
+
+```markdown
+# Informe de Validación - [ISSUE-ID]
+
+**Fecha**: [fecha/hora]
+**Fase**: [spec/plan/work/pre-pr]
+
+## Estado General
+✅ Validado / ⚠️ Validado con reservas / ❌ No validado
+
+## Validaciones Realizadas
+- Negocio: ✅ / ⚠️ / ❌
+- Técnica: ✅ / ⚠️ / ❌
+- Estándares: ✅ / ⚠️ / ❌
+
+## Conflictos
+[Lista de conflictos, si los hay]
+
+## Excepciones
+[Lista de excepciones justificadas, si las hay]
+
+## Recomendaciones
+1. [Recomendación 1]
+2. [Recomendación 2]
+
+## Aprobación
+- [ ] Aprobado para continuar
+- [ ] Requiere ajustes
+- [ ] Bloqueado
+```
+
+Informe al usuario: "⚠️ Informe guardado localmente en .sessions/ (gestor de tareas no disponible)"
+
+## 🚨 Acción en Caso de Conflictos
+
+Si se encuentran conflictos críticos:
+1. 🛑 **DETENGA** el proceso actual
+2. 📝 **DOCUMENTE** todos los conflictos
+3. 💬 **ALERTE** al usuario y stakeholders
+4. **Vía MCP**: Actualice el estado de la issue a "Bloqueado" o "Requiere Ajustes"
+5. 🔄 **AJUSTE** el plan/implementación según sea necesario
+6. ✅ **REVALIDE** tras los ajustes
+
+---
+
+**Argumentos proporcionados**:
+
+```
+#$ARGUMENTS
+```
+
+---
+
+## 🎯 Resultado
+
+Después de la validación:
+- Si ✅: Continúe a la siguiente fase
+- Si ⚠️: Documente reservas y continúe con aprobación
+- Si ❌: Corrija conflictos antes de continuar