# Protocole de validation — Tâche 7 (optimisation, métriques, nettoyage, sécurité) > **Type** : grille de validation. Utilisée après la mission décrite dans `tache7.md`. > **But** : vérifier que l'observabilité, la réduction tokens, le nettoyage et la sécurité sont conçus sans perdre de données importantes. > **Gate obligatoire** : cette validation doit être passée avant implémentation des optimisations transverses. > **Rappel** : la tâche 7 est une mission design optimisation, pas d'implémentation. --- ## 0. Quand lancer cette validation - La mission `tache7.md` est annoncée terminée. - Les politiques métriques, tokens, nettoyage, discovery et secrets sont spécifiées. --- ## 1. Discipline & périmètre - [ ] Aucun code de production modifié. - [ ] Aucun nettoyage destructif appliqué. - [ ] Aucun scan réseau lancé. - [ ] Aucun secret déplacé ou exposé. --- ## 2. Observabilité - [ ] Footer métriques backend spécifié. - [ ] `/api/system/status`, `/metrics`, `/storage` ou équivalent définis. - [ ] Métriques simples par machine distinguées des métriques backend. - [ ] Seuils warning et tooltips prévus. - [ ] Pas de dépendance obligatoire à un agent installé sur les machines. --- ## 3. Optimisation Hermes/tokens - [ ] Réduction déterministe définie. - [ ] Données brutes conservées côté webapp. - [ ] Références rehydratables prévues. - [ ] Usage tokens mesuré. - [ ] Diffs/dédup/pagination prévus. - [ ] Aucune perte de donnée critique. --- ## 4. Nettoyage DB/logs - [ ] Politique de rétention paramétrable. - [ ] Dry-run obligatoire avant purge manuelle. - [ ] Rapports épinglés conservés. - [ ] Erreurs conservées plus longtemps. - [ ] Messages importants non acquittés conservés. - [ ] Maintenance SQLite : optimize, checkpoint, vacuum contrôlé. - [ ] Export/sauvegarde avant purge majeure. --- ## 5. Sécurité secrets - [ ] Mots de passe/keys chiffrés au repos. - [ ] Host key policy prévue. - [ ] Pas de secret en localStorage/sessionStorage. - [ ] Redaction logs/UI/Hermes/MCP. - [ ] Rotation/révocation prévues. - [ ] Terminal SSH interactif encadré. --- ## 6. Découverte réseau - [ ] Bouton scan SSH à l'ajout machine spécifié. - [ ] CIDR allowlist. - [ ] Scan port 22 contrôlé. - [ ] Comparatif nmap vs scanner TCP. - [ ] Sortie structurée. - [ ] Journalisation des scans. --- ## 7. Objectif final Docker Compose webserver - [ ] Nettoyage compatible volumes Docker. - [ ] Métriques DB/WAL compatibles container. - [ ] Variables d'environnement pour rétention/secrets. - [ ] Pas de dépendance à des chemins hôte non montés. --- ## 8. Verdict - **✅ Accepté** : optimisation sûre et exploitable. - **🟡 Accepté avec réserves** : seuils/rétention à préciser. - **❌ Rejeté** : perte de données importantes, secrets exposés ou scan non encadré. --- ## 9. Notes de validation > Revue effectuée le 2026-06-05 (orchestrateur, validation déléguée). ### Verdict global **🟡 Accepté avec réserves** La spec couvre l'essentiel du périmètre. Les principes structurants sont solides et cohérents avec `tache1.9.md`, `tache5.md`, `tache6.md`, `server/crypto/secrets.ts` et `server/templates/aptReduce.ts`. Aucun risque de perte de donnée critique, aucun secret exposé, aucun scan non encadré. Les réserves ci-dessous ne bloquent pas l'implémentation mais devront être levées au plus tard lors du plan d'implémentation. --- ### Cases du gate #### Section 1 — Discipline & périmètre - **Aucun code de production modifié** : conforme — tâche design explicitement délimitée. ✅ - **Aucun nettoyage destructif appliqué** : conforme — purge uniquement spécifiée. ✅ - **Aucun scan réseau lancé** : conforme — design seul. ✅ - **Aucun secret déplacé ou exposé** : conforme. ✅ #### Section 2 — Observabilité - **Footer métriques backend spécifié** : OUI — exemple texte complet + liste métriques (section 2). ✅ - **`/api/system/status`, `/metrics`, `/storage` définis** : OUI — les trois endpoints sont listés avec exemple JSON (section 2). ✅ - **Métriques simples par machine distinguées des métriques backend** : OUI — section "Métriques simples par machine" explicitement séparée, avec note "Ces métriques concernent le backend `system_update`, pas le monitoring détaillé des hôtes distants." ✅ - **Seuils warning et tooltips prévus** : PARTIELLEMENT — les tooltips sont mentionnés dans les contraintes design ("tooltips sur métriques peu évidentes"), et la section paramètres (section 8) liste "seuils warning". Mais aucune valeur de seuil (ex. RAM > X %, disk > Y %) n'est proposée dans la spec. 🟡 **Réserve mineure** : à préciser au plan d'implémentation. - **Pas de dépendance obligatoire à un agent installé sur les machines** : OUI — "agentless, via SSH" (section 2). ✅ #### Section 3 — Optimisation Hermes/tokens - **Réduction déterministe définie** : OUI — reducers par domaine listés (APT, Docker, post-install, reboot, erreurs). Cohérent avec `aptReduce.ts` existant. ✅ - **Données brutes conservées côté webapp** : OUI — principe "Ne jamais perdre la donnée" + liste explicite (log brut, JSON complet, rapport Markdown, historique, diff, erreurs structurées). ✅ - **Références rehydratables prévues** : OUI — `snapshotId`, `executionId`, `reportRef` dans le payload réduit, avec MCP tools `get_machine_snapshot`, `get_machine_execution`, `get_report`. ✅ - **Usage tokens mesuré** : OUI — section 5 avec table `hermes_usage` et champs `rawBytes`, `reducedBytes`, `reductionRatio`, `cachedTokens`. ✅ - **Diffs/dédup/pagination prévus** : OUI — section 4. ✅ - **Aucune perte de donnée critique** : OUI — architecture clairement séparée webapp / payload Hermes. ✅ #### Section 4 — Nettoyage DB/logs - **Politique de rétention paramétrable** : OUI — JSON de rétention avec jours configurables par catégorie (section 6). ✅ - **Dry-run obligatoire avant purge manuelle** : OUI — "mode dry-run obligatoire avant suppression manuelle" et dans l'exemple de tâche (`"mode": "dry_run"`). ✅ - **Rapports épinglés conservés** : OUI — `keepPinnedReportsForever: true`, règle "ne jamais supprimer un rapport épinglé". ✅ - **Erreurs conservées plus longtemps** : OUI — `keepFailedExecutionsDays: 365` vs `executionsDays: 180`. ✅ - **Messages importants non acquittés conservés** : OUI — `keepUnacknowledgedWarningsForever: true`, règle explicite sur les warnings de sécurité/dépôt/dépréciation. ✅ - **Maintenance SQLite : optimize, checkpoint, vacuum contrôlé** : OUI — section 6 "SQLite maintenance" couvre les trois avec nuances correctes (VACUUM contrôlé car coûteux). ✅ - **Export/sauvegarde avant purge majeure** : OUI — mentionné ("politique de sauvegarde avant purge majeure"). 🟡 **Réserve mineure** : la procédure (format export, destination, déclencheur) n'est pas détaillée dans la spec — à préciser au plan. #### Section 5 — Sécurité secrets - **Mots de passe/keys chiffrés au repos** : OUI — référence explicite au chiffrement existant AES-256-GCM (`server/crypto/secrets.ts`), à "conserver et renforcer". ✅ - **Host key policy prévue** : OUI — code d'erreur `host_key_changed`, `validation host key`, `fingerprint`, paramètre "host key policy" (section 8). ✅ - **Pas de secret en localStorage/sessionStorage** : OUI — interdit explicitement. ✅ - **Redaction logs/UI/Hermes/MCP** : OUI — section 3 liste tous les vecteurs (stdout/stderr, exceptions backend, terminal live, rapports, notifications, payloads Hermes). ✅ - **Rotation/révocation prévues** : OUI — "rotation des credentials par machine". ✅ - **Terminal SSH interactif encadré** : PARTIELLEMENT — tache7 mentionne le masquage des secrets dans le terminal (section 3 : "jamais de secret dans [...] terminal live") et dans les paramètres ("terminal SSH interactif encadré" en section 8). Les règles détaillées sont dans `tache6.md` et `tache1.9.md` (`ssh_terminal_sessions`). 🟡 **Réserve mineure** : tache7 en propre ne répète pas les règles complètes (désactivation globale, auditabilité, enregistrement) — acceptable dans un design multi-tâches mais à référencer explicitement. #### Section 6 — Découverte réseau - **Bouton scan SSH à l'ajout machine spécifié** : OUI — bouton "[scanner le réseau]" dans l'UI "Ajouter une machine" (section 7). ✅ - **CIDR allowlist** : OUI — "scan uniquement sur plages autorisées en paramètres", paramètre "CIDR autorisés" (section 8). ✅ - **Scan port 22 contrôlé** : OUI — port 22 seul, CIDR configuré, pas de scan agressif, pas de détection intrusive. ✅ - **Comparatif nmap vs TCP scanner** : OUI — "Le design doit comparer MVP nmap vs TCP scanner maison" (section 7). ✅ - **Sortie structurée** : OUI — JSON candidats avec champs structurés (`host`, `port`, `service`, `hostKeyFingerprint`, `reverseDns`, `alreadyKnown`). ✅ - **Journalisation des scans** : OUI — "journaliser scans" + table `discovery_scans` dans `tache1.9.md`. ✅ #### Section 7 — Docker Compose webserver - **Nettoyage compatible volumes Docker** : OUI — checklist section 11 "Docker volumes compatibles purge/logs". ✅ - **Métriques DB/WAL compatibles container** : PARTIELLEMENT — les métriques lisent `sizeBytes` sur le chemin DB, qui doit être monté. Ceci est implicitement couvert par `tache5.md` et `tache1.9.md` (volumes Docker Compose pour DB/WAL) mais pas rappelé dans tache7. 🟡 **Réserve mineure** : tache7 ne mentionne pas explicitement que le chemin DB doit correspondre au volume monté dans le container. - **Variables d'environnement pour rétention/secrets** : OUI — paramètres via API/settings et env vars mentionnés. ✅ - **Pas de dépendance à des chemins hôte non montés** : NON TRAITÉ explicitement dans tache7. La contrainte est portée par `tache5.md` et `tache1.9.md` mais tache7 n'y fait pas référence pour les chemins logs/rapports/DB de son périmètre. 🟡 **Réserve mineure** : à vérifier au plan d'implémentation que les chemins `rawLogDays`, `reports/`, `system-update.db` sont bien sous le préfixe `DATA_DIR` monté. --- ### Réserves à lever au plan d'implémentation 1. **Seuils warning observabilité** : valeurs concrètes manquantes (ex. CPU > 80 %, RAM RSS > 500 Mo, DB > 500 Mo). À définir dans le plan ou une config par défaut. 2. **Procédure d'export avant purge majeure** : format (JSON, tar, CSV ?), destination (même répertoire `data/` ? volume séparé ?), déclencheur (automatique avant tout cleanup `apply` > N lignes ?). Non précisé. 3. **Encadrement terminal SSH interactif dans tache7** : ajouter une référence explicite vers `tache6.md` section 5 et `tache1.9.md` table `ssh_terminal_sessions` pour que la spec tache7 soit auto-suffisante sur ce point. 4. **Compatibilité Docker Compose pour métriques et nettoyage** : préciser que `database.path`, `rawLogsDirs` et `reportsDir` doivent être sous un `DATA_DIR` monté en volume dans le Compose — ne pas laisser cela à l'implémentation sans contrainte documentée. --- ### Coquilles corrigées dans `tache7.md` - Ligne 16 (section 0) : `.` remplacé par `;` en fin d'item de liste (cohérence de ponctuation). - Ligne 52 (section 1) : `.` remplacé par `;` en fin d'item de liste (cohérence de ponctuation). --- ### Incohérences avec les tâches parentes Aucune incohérence structurelle majeure détectée : - Les reducers déterministes de tache7 s'appuient et étendent `aptReduce.ts` — cohérent. - La table `hermes_usage` est identique entre tache7 (section 5) et `tache1.9.md` (section 12) — cohérent. - Les tables `discovery_scans` / `discovery_candidates` / `system_metrics` / `cleanup_runs` de tache7 correspondent exactement aux tables "Optimisation / maintenance" de `tache1.9.md` — cohérent. - Le chiffrement AES-256-GCM de `server/crypto/secrets.ts` est explicitement référencé comme existant — cohérent. - L'endpoint `/api/system/status` de tache7 est présent dans la liste API de `tache5.md` — cohérent. - La table `machine_metrics_latest` de `tache1.9.md` correspond au `machine_metrics_simple` de tache7 — cohérent dans l'intention, mais le nom `machine_metrics_latest` (BDD) vs `machine_metrics_simple` (snapshot kind) doit être aligné au plan. **Point d'attention** : tache7 section 5 liste le code d'erreur `secret_redaction_failed` — ceci implique un mécanisme de redaction actif côté backend. La spec ne précise pas comment ce cas est détecté ni quelle est l'action de fallback (fail-safe : bloquer l'envoi ? logguer séparément ? alerter ?). À préciser au plan.