gilles
0fbca06d3d
Cartographie complète (liste_taches/coherence_taches), briefs tacheN + gates validation_tacheN, design tâche 2 (docs/design/tache2/), specs/plans jalon 1-2 et tâche 1.9/2 (Phase 1, Phase 2, SJ-0→3). Validations consignées (1.9 ✅, 2-8 🟡). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
169 lines
8.3 KiB
Markdown
169 lines
8.3 KiB
Markdown
# 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.
|