vault-juez-checkpoint-template

name	vault-juez-checkpoint-template
description	Patrón de 3 capas (Alcance, Criterios, Evidencias) para [juez] checkpoints en tasks de vault
metadata	{"tipo":"metodologia","aplicable_a":"tasks"}

Estructura del patrón [juez]

El patrón de [juez] observado en plan/task/01.md (líneas 33-45 y 50-60) define un checkpoint de validación reproducible mediante tres capas estructuradas:

1. Alcance — Define explícitamente qué subtareas de implementación están siendo validadas. Cita directamente el texto de las subtareas anteriores que genera los artefactos siendo juzgados. Ejemplo: "Generar las secciones de documentación bajo vault/repos/server-map/..." (línea 34) y "Documentar la superficie de la API..." (línea 34). Esta capa responde "¿qué trabajo hacemos referencia?"

2. Criterios de aceptación — Especifica condiciones objetivas y cerradas que el trabajo debe cumplir. No son subjetivas. Ejemplo: "Existe el directorio vault/repos/server-map/ con al menos una sección de mapa y una de API" (línea 36), "Cada sección generada contiene un bloque ## Evidence..." (línea 37), "Ninguna sección copia código fuente" (línea 39). Cada criterio es verificable de forma binaria.

3. Evidencias requeridas — Lista comandos y rutas específicas, reproducibles y desatendidas, que el juez ejecutará para verificar los criterios. Ejemplo: ls vault/repos/server-map/ (línea 42), grep -rl "## Evidence" vault/repos/server-map/ (línea 43), python3 /Users/juantomas/.claude/skills/graph-vault/scripts/gv.py --vault vault validate (línea 45). Cada evidencia mapea a uno o más criterios.

Esta estructura es reutilizable en los [juez] de tasks 02-07 sin duplicación conceptual: cada task define el Alcance según su implementación específica, pero los Criterios y Evidencias siguen patrones consistentes dentro del dominio (documentación de módulos, validación de frontmatter, etc.).

Anti-patrón: [juez] sin evidencias específicas

Un [juez] sin la capa de Evidencias requeridas (o con evidencias vagas como "revisar el contenido manualmente") rompe la reproducibilidad y deja al juez sin guía operativa. Esto genera incertidumbre, rechazo sin causa clara, y acumula errores. El patrón documentado aquí evita esto forzando que cada criterio tenga al menos un comando o grep específico que lo valide.

Referencias

• plan/task/01.md, líneas 33-45: primer [juez] de task/01 (documentación de secciones de server-map).
• plan/task/01.md, líneas 50-60: segundo [juez] de task/01 (índice, repo-card, frontmatter).