Une couche de gouvernance à 7 fichiers pour prévenir la dérive de session des LLM

Un développeur sur r/LocalLLaMA a partagé une solution pour empêcher les assistants de codage LLM comme Claude d'annuler silencieusement des décisions architecturales entre les sessions. Au lieu de traiter les sessions LLM comme des conversations, ils les traitent désormais comme des processus sans état qui nécessitent un protocole.

Le problème central

Chaque session LLM commence avec une mémoire nulle. Vous réexpliquez, elle réinterprète, et elle dérive avec confiance. Le développeur a noté : "Vous ne le remarquerez même pas avant d'être profondément dans le projet, peut-être trois ou quatre fichiers plus loin, ou qui sait, même à la dernière partie du projet."

La couche de gouvernance à 7 fichiers

La solution n'est pas un meilleur prompt mais une couche de gouvernance que n'importe quel modèle peut lire et utiliser immédiatement. Le système utilise sept fichiers, chacun possédant une préoccupation spécifique sans chevauchement :

• active_context.md - Contrôleur de session, définit ce qui est dans le champ d'application actuel
• contracts.md - Loi comportementale, schémas de données, valeurs d'énumération, comportement requis
• agent_core.md - Discipline d'exécution, comment opérer, valider, rapporter
• agent_project.md - Intention du projet, pourquoi ce système existe, résultats attendus
• decisions.md - Journal ADR, choix non évidents et pourquoi ils ont été acceptés
• build_plan.md - Feuille de route des modules, ordre d'implémentation et livrables
• state.md - Journal vivant, ce qui est fait, ce qui a changé, ce qui reste

Décisions de conception clés

Le développeur a expliqué deux séparations critiques :

Séparer contracts.md de agent_core.md : "Lorsqu'un conflit comportemental est apparu, le modèle n'avait aucun moyen de savoir à quelle couche se référer. Était-ce une règle de schéma ou une préférence d'exécution ? Lorsqu'elles sont séparées, la hiérarchie est sans ambiguïté, les contrats l'emportent toujours."

Inclure decisions.md : "J'ai failli le sauter ('Je m'en souviendrai'). Trois semaines plus tard, je ne pouvais pas reconstruire pourquoi nous avions choisi Postgres plutôt que SQLite pour un module spécifique. Le journal ADR existe précisément parce que 'Je m'en souviendrai' n'est pas un protocole."

La boucle opérationnelle

Chaque session suit cet ordre, sans exception :

1. Lire active_context.md → extraire ce qui est dans le champ d'application
2. Se réancrer contre contracts.md → règles comportementales verrouillées
3. Confirmer les contraintes opérationnelles de agent_core.md + agent_project.md
4. Vérifier decisions.md → ne pas inverser les choix acceptés
5. Exécuter uniquement ce que active_context.md autorise, selon build_plan.md
6. Valider avec des tests — ne pas déclarer terminé sans preuve
7. Mettre à jour state.md avec les résultats factuels
8. Si une nouvelle décision non triviale a été prise, la consigner dans decisions.md

Impact sur le flux de travail

Le verrouillage de portée de active_context.md s'est avéré particulièrement précieux : "Avant cela, je commençais une session pour corriger un bug et je finissais par refactoriser un module non lié parce que 'il était juste là'. Cela semblait productif.........et ça l'était."