القائمة
Patrón de 3 capas (Alcance, Criterios, Evidencias) para [juez] checkpoints en tasks de vault
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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).