bolbol/nas-runbooks
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

runbook: guardrails flotte hermes (hard_stop, tirith, verificateur croise) + incidents decouverts

Browse Source
This commit is contained in:
Nabil Derouiche
2026-08-12 23:55:17 +01:00
parent abf58b7567
commit 75cbce7c50
2 changed files with 37 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
common/guardrails-flotte-hermes-hard-stop-tirith-verificateur-12-08-2026.md
+35
View File
@@ -0,0 +1,35 @@
# Guardrails flotte Hermes (NAS + VPS) — hard_stop, tirith, verificateur croise
## Contexte
Suite au succes du RAG hermes-tt (rapports d'evaluation, Excel, DCO livres sans retouche), demande explicite d'un Hermes avec garde-fous auto-actives + auto-contre independant, sur les 4 instances (hermes-tt, hermes-nyora, hermes-perso sur NAS + hermes-nabil sur VPS Contabo).
## Failles confirmees (lecture directe des config.yaml, pas une supposition)
- `tool_loop_guardrails.hard_stop_enabled: false` sur les 3 instances NAS et absent (donc false par defaut) sur hermes-nabil : l'agent ne fait qu'avertir sur boucle d'echec repetee, ne s'arrete jamais reellement. Recommandation officielle Nous Research pour deploiement gateway/non-surveille : l'activer.
- `security.tirith_enabled: false` explicitement sur les 3 instances NAS (le binaire tirith — scanner anti-prompt-injection, homograph URL, exfiltration credentials — n'etait pas actif) alors qu'il est actif par defaut (et le binaire present) sur hermes-nabil.
- Lecture code `nyora-notes-tt/pipeline_processor.py` + `mcp_server.py` : aucun marquage provenance/confiance sur le contenu mail avant ingestion RAG. Risque "sleeper channel" (cf. litterature academique sur les agents always-on) confirme reel, PAS corrige ce tour — chantier a part entiere (schema + formatage contexte), voir section "reste a faire".
## Changements appliques (12/08/2026, backups config.yaml.bak-guardrails-<timestamp> avant chaque edit)
| Instance | hard_stop_enabled | tirith_enabled | delegation (verificateur) |
|---|---|---|---|
| hermes-tt | false -> true | false -> true | deepseek-v4-pro -> **mimo-v2.5** (opencode-go, cle deja en place) |
| hermes-nyora | false -> true | false -> true | deja mimo-v2.5 (personne ne s'en souvenait) |
| hermes-perso | false -> true | false -> true | '' -> **mimo-v2.5** (opencode-go) |
| hermes-nabil (VPS) | absent -> true (bloc ajoute) | deja true par defaut, explicite maintenant | absent -> **deepseek/deepseek-v4-flash** via openrouter (cle OPENROUTER_API_KEY deja en .env) |
## Principe retenu
Le sous-agent verificateur (`delegate_task`) ne doit jamais tourner sur le meme modele que le generateur principal, pour eviter les angles morts partages (doc officielle Hermes : "the agent that does the work should not be its sole verifier"). NAS = generateur DeepSeek V4 Flash -> verificateur Mimo V2.5. hermes-nabil = generateur Mimo V2.5 (modele principal) -> verificateur DeepSeek V4 Flash. C'est l'inverse exact entre NAS et VPS, deliberement.
## Piege / a savoir
- `docker compose up -d` ne recharge PAS un `config.yaml` modifie si le container tourne deja (le fichier est un bind-mount, pas une image) — il faut un `docker restart <container>` explicite. `up -d` seul affiche "Running" sans rien faire.
- `data/` est gitignore sur les repos par-instance (hermes-tt, hermes-nyora, hermes-perso, hermes-nabil) — **ne jamais force-add `config.yaml`**, il contient des cles API en clair (Bifrost, OpenCode Zen). C'est un choix delibere du `.gitignore` existant, pas un oubli. Capitalisation via runbook + NyoraNotes uniquement pour ce type de fichier, pas de commit.
- Clone Gitea depuis le NAS : `gitea.bolbol.tn` (domaine externe) a timeout HTTP 504 en cours de session ; `192.168.100.33:3232` (LAN direct) fonctionne. A garder en tete si un futur clone echoue bizarrement.
## Incidents decouverts en cours de route (non lies au chantier, decouverts par effet de bord)
- hermes-agent-tt etait **down depuis 8h** avant intervention (Exited(0) cote Docker mais lifecycle_ledger interne Hermes indique mort non-propre, SIGKILL/VM death, vers 12/08 14h13, `suspected_oom=False`). Cause non identifiee. Relance faite, healthy.
- hermes-workspace-perso : Exited(128) depuis 24h, blocage au restart par un binding orphelin sur le port 3030 (host-level, PID invisible sans sudo — non resolu, necessite intervention avec privileges eleves ou redemarrage du daemon Docker).
## Reste a faire (session dediee)
- Provenance/tag "non fiable" sur le contenu mail avant ecriture RAG (nyora-notes-tt)
- Debloquer port 3030 (hermes-workspace-perso)
- Investiguer la cause de la mort hermes-agent-tt du 12/08 14h13
- Envisager `tirith_fail_open: false` une fois confirme en usage reel que tirith tourne correctement (actuellement `true` = mode conservateur partout)