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>
194 lines
12 KiB
Markdown
194 lines
12 KiB
Markdown
# 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.
|