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>
123 lines
3.8 KiB
Markdown
123 lines
3.8 KiB
Markdown
# Revue de cohérence — tâches system_update
|
|
|
|
> **But** : vérifier que les tâches 1.9 à 8 s'enchaînent proprement vers l'objectif final : une webapp serveur `system_update` exploitable via Docker Compose, avec API extensible et clients futurs.
|
|
|
|
---
|
|
|
|
## 1. Verdict global
|
|
|
|
Les tâches sont globalement cohérentes.
|
|
|
|
Il n'y a pas de contradiction bloquante détectée entre :
|
|
|
|
- moteur templates/scripts ;
|
|
- frontend web ;
|
|
- backend/API ;
|
|
- BDD ;
|
|
- Hermes/MCP ;
|
|
- optimisation/nettoyage ;
|
|
- app locale future.
|
|
|
|
Les recouvrements repérés sont normaux : certains sujets sont transverses et doivent apparaître dans plusieurs tâches, mais avec responsabilités différentes.
|
|
|
|
---
|
|
|
|
## 2. Flux de développement recommandé
|
|
|
|
Ordre logique :
|
|
|
|
```text
|
|
1. Validation tâche 1.9 → schéma BDD cible
|
|
2. Validation tâche 2 → templates, APT, Docker, contrats JSON
|
|
3. Validation tâche 4 → scripts post-install/hardware/profils
|
|
4. Validation tâche 5 → backend/API/jobs/storage
|
|
5. Validation tâche 3 → frontend web/tuiles/paramètres/layout
|
|
6. Validation tâche 6 → Hermes/MCP/skills
|
|
7. Validation tâche 7 → optimisation/nettoyage/sécurité/découverte
|
|
8. Validation tâche 8 → app Rust/GNOME future
|
|
```
|
|
|
|
Pourquoi cet ordre :
|
|
|
|
- la BDD et les contrats JSON structurent tout ;
|
|
- les scripts/templates produisent les données ;
|
|
- le backend stocke, orchestre et expose ;
|
|
- le frontend consomme ces contrats ;
|
|
- Hermes/MCP et optimisations s'appuient sur le backend ;
|
|
- l'app Rust/GNOME reste une évolution future via API commune.
|
|
|
|
---
|
|
|
|
## 3. Recouvrements acceptés
|
|
|
|
### Métriques simples
|
|
|
|
- `tache4.md` : définit le script SSH `machine_metrics_simple`.
|
|
- `tache5.md` : définit stockage/API/snapshot.
|
|
- `tache7.md` : définit affichage footer, optimisation et usage observabilité.
|
|
- `tache1.9.md` : définit tables `machine_metrics_latest`.
|
|
|
|
Ce n'est pas un doublon : chaque tâche couvre une couche différente.
|
|
|
|
### Logs, rapports et messages importants
|
|
|
|
- `tache5.md` : stockage backend, API, rétention.
|
|
- `tache6.md` : accès Hermes/MCP.
|
|
- `tache7.md` : nettoyage/rétention.
|
|
- `tache1.9.md` : tables.
|
|
|
|
Ce recouvrement est nécessaire.
|
|
|
|
### Paramètres frontend
|
|
|
|
- `tache3.md` : UX paramètres.
|
|
- `tache1.9.md` : stockage `app_settings`, `user_preferences`, `machine_ui_state`.
|
|
- `tache5.md` : API `/api/settings`.
|
|
|
|
Ce découpage est cohérent.
|
|
|
|
### App locale Rust/GNOME
|
|
|
|
- `tache8.md` : client natif futur.
|
|
- `tache5.md` : API commune/capabilities.
|
|
- `tache1.9.md` : table `api_clients`.
|
|
|
|
Ce n'est pas un chantier immédiat ; il doit rester futur.
|
|
|
|
---
|
|
|
|
## 4. Points corrigés pendant la revue
|
|
|
|
- `tache2.md` et `validation_tache2.md` parlaient encore de 7 questions d'investigation alors que la tâche en contient 8 après ajout des profils machine. Corrigé.
|
|
|
|
---
|
|
|
|
## 5. Objectif final Docker Compose
|
|
|
|
Objectif final confirmé :
|
|
|
|
```text
|
|
Une webapp serveur system_update déployable via Docker Compose :
|
|
- backend API ;
|
|
- frontend web servi par le backend ou reverse proxy ;
|
|
- SQLite persisté en volume ;
|
|
- reports/logs persistés en volume ;
|
|
- configuration via variables d'environnement ;
|
|
- secrets master key hors image ;
|
|
- accès réseau vers machines SSH ;
|
|
- option future reverse proxy/TLS.
|
|
```
|
|
|
|
Cet objectif doit rester un critère transversal dans les validations, surtout tâches 5, 7 et le plan d'implémentation final.
|
|
|
|
---
|
|
|
|
## 6. Risques à surveiller
|
|
|
|
- Ne pas implémenter toutes les tâches en un seul jalon : trop grand.
|
|
- Garder les actions dangereuses validées UI, même si Hermes ou l'app Rust les demande.
|
|
- Ne pas exposer les credentials SSH/sudo/API dans logs, UI, Hermes, MCP ou clients locaux.
|
|
- Garder SQLite au MVP, mais écrire le schéma pour migrer vers PostgreSQL.
|
|
- Garder les scripts critiques versionnés sur disque, pas uniquement en BDD.
|
|
- Ne pas confondre terminal live d'exécution, vrai terminal SSH interactif et conversation Hermes.
|