Una Capa de Gobernanza de 7 Archivos para Prevenir la Deriva de Sesión en LLM

Un desarrollador en r/LocalLLaMA compartió una solución para evitar que asistentes de programación con LLM como Claude deshagan silenciosamente decisiones arquitectónicas entre sesiones. En lugar de tratar las sesiones de LLM como conversaciones, ahora las tratan como procesos sin estado que necesitan un protocolo.

El Problema Central

Cada sesión de LLM comienza con memoria cero. Vuelves a explicar, reinterpreta y se desvía con confianza. El desarrollador señaló: "Ni siquiera te darás cuenta hasta que estés profundamente dentro del proyecto, tal vez tres archivos adentro o cuatro archivos o quién sabe incluso en la última parte del proyecto".

La Capa de Gobernanza de 7 Archivos

La solución no es un mejor prompt sino una capa de gobernanza que cualquier modelo puede leer y operar inmediatamente dentro de ella. El sistema utiliza siete archivos, cada uno con una preocupación específica sin superposición:

• active_context.md - Controlador de sesión, define lo que está en alcance en este momento
• contracts.md - Ley de comportamiento, esquemas de datos, valores de enumeración, comportamiento requerido
• agent_core.md - Disciplina de ejecución, cómo operar, validar, informar
• agent_project.md - Intención del proyecto, por qué existe este sistema, resultados esperados
• decisions.md - Registro ADR, elecciones no obvias y por qué fueron aceptadas
• build_plan.md - Hoja de ruta del módulo, orden de implementación y entregables
• state.md - Diario vivo, qué se hizo, qué cambió, qué queda

Decisiones de Diseño Clave

El desarrollador explicó dos separaciones críticas:

Separar contracts.md de agent_core.md: "Cuando apareció un conflicto de comportamiento, el modelo no tenía forma de saber a qué capa deferir. ¿Era esta una regla de esquema o una preferencia de ejecución? Cuando están separados, la jerarquía es inequívoca, los contratos siempre ganan".

Incluir decisions.md: "Casi lo omití ('solo lo recordaré'). Tres semanas después no pude reconstruir por qué habíamos elegido Postgres sobre SQLite para un módulo específico. El registro ADR existe precisamente porque 'lo recordaré' no es un protocolo".

El Bucle Operativo

Cada sesión sigue este orden, sin excepciones:

1. Leer active_context.md → extraer lo que está en alcance
2. Reafirmar contra contracts.md → reglas de comportamiento bloqueadas
3. Confirmar restricciones operativas de agent_core.md + agent_project.md
4. Verificar decisions.md → no revertir elecciones aceptadas
5. Ejecutar solo lo que active_context.md autoriza, según build_plan.md
6. Validar con pruebas — no declarar hecho sin evidencia
7. Actualizar state.md con resultados factuales
8. Si se tomó una nueva decisión no trivial, registrarla en decisions.md

Impacto en el Flujo de Trabajo

El bloqueo de alcance de active_context.md demostró ser particularmente valioso: "Antes de esto, comenzaba una sesión para corregir un error y terminaba refactorizando un módulo no relacionado porque 'estaba justo ahí'. Se sentía productivo.........y lo era".