process: mecanisme implication hermes-nyora/Gemini dans les garde-fous durables (24/08)

common/mecanisme-implication-hermes-gemini-garde-fous.md

@@ -0,0 +1,40 @@
+# Mécanisme d'implication Hermes/Gemini dans les améliorations d'infra (24/08/2026)
+
+## Contexte
+
+Suite à l'incident MCP hermes-tt/reglement-definitif (23-24/08/2026, voir `common/mcp-token-croise-reglement-definitif.md`), Nabil a remarqué que l'analyse post-action de Claude, les corrections et les garde-fous construits n'avaient coûté que 3% du quota hebdomadaire Claude.web. Discussion qui en a suivi : ce chiffre n'est pas un objectif à optimiser, mais un déclic qui a fait émerger un principe de collaboration plus explicite entre Claude, hermes-nyora et Gemini pour toute construction de garde-fou durable.
+
+Première application de ce mécanisme, réalisée le même jour en sens inverse (Claude a construit directement le hook plutôt que de le déléguer) : `common/mcp-token-croise-reglement-definitif.md` et `reglement-definitif/.agents/verify-reglement.sh`. Le mécanisme documenté ici est la doctrine à suivre pour les prochaines fois.
+
+## Le mécanisme
+
+Pour toute construction de garde-fou ou pattern **durable**, destiné à devenir un réflexe permanent de la flotte (nouveau Stop hook Antigravity, nouvelle règle de skill, nouveau protocole de vérification) :
+
+1. **Claude conçoit le motif** — le problème constaté, la logique de vérification (quoi tester, dans quel ordre, quel credential/état exact utiliser, quel signal fait échouer le check), le contrat de sortie attendu. Jamais un script clé-en-main : sinon Claude refait le travail de Gemini et hermes-nyora redevient un simple relais sans y gagner en compétence.
+2. **hermes-nyora cadre et fait exécuter** — traduit le motif en prompt de mission pour Gemini, applique son processus habituel (rapport d'analyse → GO conditionnel → exécution avec preuves brutes), documenté dans `nyora-project-execution/references/antigravity-delegation-workflow.md`.
+3. **Gemini installe** — écrit le script, le déploie, fournit les preuves d'exécution.
+4. **Claude fait un seul passage d'audit** — mais ce passage doit être un vrai test rejoué en direct (ex : réintroduire temporairement le bug visé pour vérifier que le garde-fou le détecte, puis confirmer le retour au vert une fois corrigé), jamais une lecture du rapport de clôture aussi détaillé soit-il. Lire un rapport affirmant "testé, fonctionnel" sans le rejouer reproduirait exactement le défaut de vérification que ce mécanisme cherche à corriger, à un niveau au-dessus.
+
+## Exceptions explicites (validées par Nabil, pas des entorses au principe)
+
+**(a) Correctif ponctuel.** Un problème déjà diagnostiqué avec certitude, qu'un seul geste/une seule commande suffit à corriger, et que Claude a déjà l'accès pour exécuter directement → Claude fait sans détour. Un cycle prompt/rapport/vérification n'ajouterait que de la latence et du coût pour un résultat identique, sans construire aucune compétence nouvelle chez la flotte.
+
+**Question à se poser avant de choisir la voie** : pas "est-ce que je respecte le mécanisme", mais **"est-ce que ce geste vaut la peine d'être appris par hermes-nyora/Gemini, ou est-ce juste un fait à corriger"**. Un nouveau pattern de vérification réutilisable → mécanisme complet. Un fichier de config à un seul endroit, déjà diagnostiqué → correction directe.
+
+**(b) AntiGravity/Gemini physiquement inaccessible à Nabil** au moment donné (ex. poste Windows sans accès à l'outil) → Claude fait directement, indépendamment de la catégorie du problème. Il n'y a pas de dilemme à trancher quand l'option alternative n'existe pas dans l'instant présent.
+
+## Escalade en cours de cycle
+
+Si Nabil remarque une dérive pendant l'exécution (avant la clôture), il consulte Claude immédiatement plutôt que d'attendre la fin du cycle. Cette consultation manuelle est une protection **transitoire** — utile tant qu'un garde-fou structurel (Stop hook) n'existe pas encore ou est en cours de construction pour ce projet précis. La vraie garantie de long terme reste le Stop hook lui-même : il protège en continu, sans dépendre de qui remarque quoi au bon moment.
+
+## Principe de fond
+
+Le budget de quota (hebdomadaire, session) est une contrainte à respecter, jamais un critère qui doit influencer la profondeur d'une vérification. Le jour où la rigueur d'un audit se réduit pour "rester dans le budget" plutôt que parce que le risque réel le justifie, c'est exactement le genre de dérive silencieuse que ce mécanisme cherche à éviter — et le genre d'erreur qui a produit l'incident du 23/08 en premier lieu.
+
+## Premier cas de test prévu
+
+Propager le pattern de Stop hook (déjà en place sur `rla-api-src` et `reglement-definitif`) vers un autre projet MCP existant (context-hub ou nyora-notes-tt), ou vers les skills de délégation de hermes-tt/hermes-perso s'ils en développent — à lancer quand Nabil aura accès à AntiGravity/Gemini (pas depuis un poste Windows).
+
+## Lien
+
+Le motif fondateur (règle MCP obligatoire, check du credential réel du consommateur) et son application complète : `common/mcp-token-croise-reglement-definitif.md`. Doctrine détaillée côté hermes-nyora : `nyora-project-execution/references/antigravity-delegation-workflow.md` (section "MÉCANISME D'IMPLICATION HERMES/GEMINI...", ajoutée 24/08/2026).