Menu
Patrón de 3 capas (Alcance, Criterios, Evidencias) para [juez] checkpoints en tasks de vault
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Patrón de escalado de capacidad del modelo por subtarea — cuándo cambiar RALPH_MODEL_CAPABILITY en .ralph/.env
Metodología de planificación para el bucle ralph en AbadIA-MCP — granularidad, estructura de tareas y prerrequisitos
Estrategia para promover componentes compartidos en vault/components/ — cuándo emitir un fichero vs. anotar en pending-components.md
Estructura modular del vault de AbadIA-MCP — separación server-core/server-map y orden de dependencias entre pasadas
Reglas universales al escribir ficheros en vault/ — frontmatter de provenance, bloques Evidence y prohibición de código fuente
Estrategia para emitir edges tipados en vault/relations/ — cuándo crear un fichero de edge vs. anotar en pending-relations.md
| 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"} |
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:
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?"
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.
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.).
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.
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).