Menü
Patrón de delimitación por ficheros entre módulos hermanos para evitar solapamiento de alcance en el vault
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
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
Patrón de 3 capas (Alcance, Criterios, Evidencias) para [juez] checkpoints en tasks de vault
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
| name | vault-scope-boundaries |
| description | Patrón de delimitación por ficheros entre módulos hermanos para evitar solapamiento de alcance en el vault |
| metadata | {"tipo":"decision","proyecto":"AbadIA-MCP","areas":["vault-architecture","scope-design"]} |
Cuando dos módulos comparten un directorio fuente (como server-core y server-map comparten server/), el alcance no se delimita por directorios, sino por ficheros específicos. Esta estrategia evita solapamiento de responsabilidades y permite que futures tareas de documentación (task/02 a task/07) trabajen sin ambigüedad sobre qué contenido corresponde a cada módulo.
En el caso de server-core vs server-map, la frontera es tajante:
map_definitions.py, map_utils.py, y todo el árbol de api/ (incluyendo api/v1/).Esta decisión se materializa en plan.md (línea 28) como "el alcance de cada uno está acotado por ficheros (core = lógica/runtime; map = map_*.py + api/)" y se detalla en task/01.md (líneas 15-17 y línea 28) con el inventario exacto.
La regla es universal: cuando un módulo documenta una región lógica dentro de un árbol compartido, lista explícitamente los ficheros (o patrones de fichero) que entran en su alcance. Ejemplos de aplicación futura:
Agent (task/02): Si el módulo agent contiene un submodule tools-internal/ (herramientas internas del agente) y otro tools-external/ (que invoca servicios externos), la frontera se declara por ruta de fichero. La documentación del vault debe registrar: "agent documenta tools-internal/ y tools-shared.py; no documenta herramientas específicas de otros módulos que viven en external-services/."
Scripts (task/03): Si existen scripts de utilidad en scripts/helpers.py que también podrían pertenecer a scripts/exec/ y scripts/tools/, el vault aclara: "documentamos scripts/exec/*.py y scripts/tools/config.py; los scripts de desarrollo en scripts/dev/ siguen otro patrón" (o similar).
Tests (task/04): La cobertura no se define por "tests que prueban server/" sino por "tests en tests/unit/server/ y tests/integration/server_api/; tests de smoke en tests/smoke/ se documentan bajo otro módulo o no se incluyen."
Docs (task/05): Si hay documentación técnica en docs/ y también en subdirectorios de módulos (p. ej., agent/docs/), la declaración es: "vault-docs documenta docs/*.md y docs/guides/; cada módulo documenta su propio <module>/docs/ en su sección."
map_*.py + api/)."map_definitions.py, map_utils.py y api/ (incl. api/v1/); NO documentar la lógica/runtime core (eso es server-core)."map_definitions.py, map_utils.py, api/ y api/v1/) y delimitar la frontera con server-core."Esta regla explícita previene que en tasks futuras haya conflictos sobre si un fichero pertenece a un módulo u otro, reduce la necesidad de revisar o reescribir documentación por ambigüedad de límites, y facilita auditoría: si alguien pregunta "¿por qué este fichero está documentado en agent y no en scripts?", la respuesta apunta a la lista de ficheros acotados en el plan o la config del vault.