runbook: audit data/ 3 instances Hermes 09/07 (complement consolidation)

common/audit-data-hermes-20260709.md

@@ -0,0 +1,34 @@
+# Audit data/ des 3 instances Hermes — 09/07/2026 (complément consolidation nas-runbooks)
+
+**Date** : 2026-07-09
+**Sphères concernées** : hermes-tt, hermes-nyora, hermes-perso (les 3)
+**Contexte** : volet data/ de la consolidation du 09/07 — inaccessible depuis mcp-nas (data/ en 0700 uid 1026, cap_drop ALL, voir common/mcp-nas-reference.md), réalisé depuis le Mac via SSH Best0f (port 22222).
+
+## Résultat de l'audit
+
+| Volet | Verdict |
+|---|---|
+| config.yaml (3 instances) | ✅ conformes à common/opencode-go-migration.md (tt/perso deepseek-v4-flash, nyora mimo-v2.5 max_tokens 8192, fallbacks opencode-go/deepseek-v4-flash key_env OPENCODE_GO_API_KEY) |
+| SOUL.md | ✅ aucune fuite inter-sphères ; ⚠️ sections ROUTING périmées (corrigées, voir plus bas) |
+| cron/jobs.json | ✅ aucun openrouter, jobs model=null désactivés ou hérite du défaut sain ; ⚠️ 1 job perso référençait un skill archivé (voir piège n°1) |
+| skills/ | ✅ archives document-skills 02+04/07 intactes, generation-contenu-volumineux sur les 3, sobriete-code sur tt+nyora (perso exclu par design) |
+
+## Corrections appliquées (GO Nabil 09/07)
+
+1. **data.bak_20260620_100538 supprimés** sur les 3 instances → 17,4 Go récupérés (tt 6,7 / nyora 6,0 / perso 4,7).
+2. **chown 1026:100** des fichiers root:root dans data/ (skills/context-hub et skills/generation-contenu-volumineux sur les 3, mail-o365-tt.md sur tt, backups+__pycache__ sur nyora) — voir piège n°2.
+3. **Purge des backups anciens** — politique : garder les 2 plus récents par famille (config.yaml.bak, .env.bak, jobs.json.bak, veille_*.py.bak, deny-ip-list*), suppression des zips de mai (SOUL.zip, config.zip…), swarm.yaml vide, get-docker.sh, .gateway_state_*.tmp.
+4. **Cron perso « Veille Orientini 2026 »** : référence au skill archivé pptx-presentation retirée, génération PPTX routée vers nyora-doc-api (POST http://nyora-doc-api:8000/v1/generate). Procédure docker stop → édition jobs.json → docker start (même précaution que config.yaml). Backup : cron/cron_jobs_backup_20260709_orientini_docapi.json.
+5. **SOUL tt + nyora** : sections ROUTING mises à jour pour refléter l'état réel des modèles (tt disait « deepseek-v4-pro modèle principal », nyora disait « glm-5.1 modèle principal » + budget OpenRouter/Claude Sonnet).
+
+## Pièges réutilisables
+
+1. **Archiver un skill ne met pas à jour les cron qui le référencent.** Le job tourne sans erreur (last_status ok) et retombe sur la génération locale — exactement le contournement que l'archivage devait empêcher. **Règle : après tout archivage de skill, grep `cron/jobs.json` des 3 instances sur le nom du skill** (champs `skill` et `skills[]` + prompt).
+2. **Les sessions root (mcp-nas pré-hardening, sessions Portainer exec) laissent des fichiers root:root dans data/** (attendu 1026:100). Lisibles par l'agent si 644/755 mais ingérables par le curator. Fix sans restart ni sudo : `docker exec -u 0 hermes-agent-<i> chown -R 1026:100 <chemins sous /opt/data>`.
+3. **SOUL.md est éditable à chaud** (contrairement à config.yaml, il n'est pas réécrit au shutdown). jobs.json en revanche : appliquer la même procédure stop→éditer→start que config.yaml.
+4. **Les sections routing du SOUL divergent de config.yaml à chaque changement de modèle.** Checklist changement de modèle : config.yaml + SOUL (sections ROUTING) + cron jobs épinglés (`model`/`provider`) en même temps.
+
+## Signalé non traité (backlog)
+
+- Secrets en clair : token Baserow dans les prompts cron tt/nyora (Mission Control Log), X-Webhook-Token dans SOUL nyora, `.openrouter_key` résiduel sur perso (06/06).
+- `state.db` volumineux (tt 347 Mo, nyora 317 Mo, perso 398 Mo) — à surveiller, pas d'action.