system_update/validation_tache7.md

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.