3.7 KiB

Raw Blame History

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)

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).
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.
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.
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.
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

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).
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>.
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.
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.

3.7 KiB Raw Blame History