system_update/validation_tache6.md

Protocole de validation — Tâche 6 (Hermes, MCP, skills et messagerie)

Type : grille de validation. Utilisée après la mission décrite dans tache6.md. But : vérifier que Hermes analyse et propose, sans accéder aux secrets ni exécuter SSH directement. Gate obligatoire : cette validation doit être passée avant intégration Hermes/MCP. Rappel : la tâche 6 est une mission design intégration agent, pas d'implémentation.

---

0. Quand lancer cette validation

• La mission tache6.md est annoncée terminée.
• Architecture API Hermes/MCP/skill est décrite.
• Les tools MCP sont listés.

---

1. Discipline & périmètre

• Aucun code Hermes/MCP/backend modifié.
• Hermes ne fait jamais de SSH direct.
• Hermes ne reçoit jamais de secret.
• Les actions dangereuses passent par request_action + validation UI.
• Le volet Hermes reste distinct du terminal SSH.

---

2. Architecture Hermes

• API Server Hermes configuré côté backend, clé jamais navigateur.
• MCP HTTP system_update défini.
• Skill system-update-ops défini.
• TUI/messagerie et volet web couverts.
• Webhooks/notifications couverts.
• Cron Hermes limité aux rapports/analyses, pas aux opérations SSH.

---

3. Tools MCP

• list_machines.
• get_machine_state.
• get_machine_hardware.
• get_machine_metrics.
• get_machine_snapshot.
• get_machine_execution.
• get_machine_messages.
• search_reports.
• get_report.
• search_log_artifacts.
• run_refresh.
• request_action.
• get_pending_actions.
• preview_template.
• list_templates.

---

4. Données envoyées à Hermes

• Priorité : état courant, JSON réduit, messages importants, rapports, extraits ciblés.
• Logs bruts complets jamais envoyés par défaut.
• Masquage secrets prévu.
• Usage tokens mesurable.
• Références rehydratables prévues.

---

5. UX volet Hermes

• Messages utilisateur/Hermes/système distingués.
• Blocs de commandes copiables.
• Actions proposées sous cartes de validation.
• Rapports/logs/snapshots cités par liens.
• Stop/streaming/health/capabilities prévus.

---

6. Verdict

• ✅ Accepté : Hermes utile et sûr.
• 🟡 Accepté avec réserves : tools ou skill à préciser.
• ❌ Rejeté : SSH direct, secrets exposés ou actions non validées.

---

7. Notes de validation

Revue du 2026-06-05 — orchestrateur, validation déléguée.

Verdict global

Accepté avec réserves mineures.

La tâche 6 couvre l'ensemble des points du gate. Les règles de sécurité fondamentales (pas de SSH direct, pas de secret transmis à Hermes, actions dangereuses via request_action + validation UI, clé API côté backend uniquement) sont présentes et cohérentes dans tous les paragraphes du document. La séparation volet Hermes / terminal SSH est explicitement formulée. La liste des tools MCP, le skill system-update-ops, les notifications/webhooks, la messagerie et les deux cas d'usage (volet web et TUI/messagerie) sont couverts. La cohérence avec tache1.9.md (tables hermes_sessions, hermes_runs, hermes_usage, mcp_audit_log, action_requests), tache5.md (API consommée par MCP) et tache7.md (réduction tokens, masquage secrets) est correcte.

---

Cases du gate passées

Section 1 — Discipline & périmètre

• Aucun code modifié : conforme (mission design uniquement, §0 et §11).
• Pas de SSH direct : conforme (§2 règle forte + §9 règle non négociable + §12 checklist).
• Pas de secret transmis : conforme (§3, §9, §12).
• Actions dangereuses via request_action + validation UI : conforme (§4, §5, §12).
• Volet Hermes distinct du terminal SSH : conforme (§5, terminal SSH décrit comme outil séparé dans le volet droit).

Section 2 — Architecture Hermes

• API Server côté backend, clé jamais navigateur : conforme (§1, §3 avec variable HERMES_API_KEY, §12).
• MCP HTTP system_update défini : conforme (§1, §4, §5).
• Skill system-update-ops défini : conforme (§6).
• TUI/messagerie et volet web couverts : conforme (§3 et §4).
• Webhooks/notifications couverts : conforme (§8).
• Cron Hermes limité rapports/analyses, pas SSH : conforme (§1 section Cron Hermes).

Section 3 — Tools MCP Tous les 15 tools du gate sont couverts dans la surface minimale (§5). Après correction des coquilles (voir ci-dessous), la liste include du yaml config Hermes (§4) est alignée avec la liste §5 et le gate.

Section 4 — Données envoyées à Hermes

• Priorité état courant / JSON réduit / messages importants / rapports / extraits ciblés : conforme (§5, §6 procédure).
• Logs bruts complets jamais par défaut : conforme (§5 "à éviter au MVP", §9).
• Masquage secrets prévu : conforme (§9 + renvoi explicite à tache7.md pour la spec de masquage).
• Usage tokens mesurable : conforme par référence à tache7.md §5 et tables tache1.9.md.
• Références rehydratables : conforme (tools MCP get_machine_snapshot, get_machine_execution, get_report).

Section 5 — UX volet Hermes

• Messages utilisateur/Hermes/système distingués : conforme (§3).
• Blocs de commandes copiables : conforme (§3 "blocs de commande monospace avec bouton copier").
• Actions proposées sous cartes de validation : conforme (§3 "carte de validation, pas comme exécution directe").
• Rapports/logs/snapshots cités par liens : conforme (§3 "références cliquables").
• Stop/streaming/health/capabilities prévus : conforme (§3 endpoints dédiés).

---

Réserves

R1 — Interdiction d'auto-exécution des commandes copiées non formulée explicitement Le gate vérifie "blocs de commandes copiables non auto-exécutés". tache6.md précise "bouton copier" mais ne formule pas explicitement l'interdiction pour la webapp d'injecter automatiquement une commande dans le terminal interactif. L'esprit du document l'implique (toute action passe par validation UI), mais la formulation directe manque. À clarifier lors du plan d'implémentation de tache3.md (volet UI).

R2 — Liste include yaml (§4) initialement incohérente avec surface minimale (§5) et gate (§3) La liste include du yaml config Hermes (§4) omettait get_all_snapshots, preview_template et list_templates, présents dans la surface minimale §5 et dans le gate. Corrigé dans la présente revue (coquille).

R3 — Usage tokens : pas de contrat propre dans tache6.md tache6.md délègue entièrement la spec de mesure tokens à tache7.md. Acceptable pour une tâche design, mais le plan d'implémentation devra s'assurer que les deux specs sont lues ensemble. Aucun blocage.

R4 — get_all_snapshots absent du gate get_all_snapshots figure dans la surface minimale §5 et a été ajouté dans la liste yaml (correction R2), mais il est absent de la liste du gate (section 3). Cela signifie que ce tool ne sera pas vérifié par le gate lors de la future revue d'implémentation. À porter en note lors de la mise à jour éventuelle du gate.

---

Coquilles corrigées dans tache6.md

1. §4 yaml config include : ajout de get_all_snapshots, preview_template, list_templates absents de la liste include alors qu'ils figurent dans §5 et le gate.
2. §5 mention get_log_excerpt : reformulation "futur, hors liste MVP" pour lever l'ambiguïté sur son statut (il était décrit dans §5 mais absent de la liste surface minimale).

---

Incohérences détectées (sans blocage)

• La liste MCP dans ajout.md (document d'origine) utilise request_action_plan et run_approved_action ; tache6.md consolide en request_action + get_pending_actions. Évolution volontaire et cohérente. Aucun conflit.
• get_all_snapshots est présent dans §5 de tache6.md mais absent du gate. Non bloquant : la surface est couverte côté design, la validation gate reste partielle sur ce point.

---

Conclusion

La tâche 6 satisfait les critères de sécurité fondamentaux et couvre les deux cas d'usage. Les réserves sont mineures et ne nécessitent pas de rééditer la spec avant le plan d'implémentation. Les coquilles d'alignement de liste ont été corrigées directement. Le passage en plan d'implémentation est autorisé, avec la charge pour l'implémenteur de lire tache7.md conjointement pour la politique de masquage et de mesure tokens.