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>
104 lines
5.2 KiB
Markdown
104 lines
5.2 KiB
Markdown
# Protocole de validation — Tâche 1.9 (architecture BDD cible)
|
|
|
|
> **Type** : grille de validation. Utilisée après la mission décrite dans `tache1.9.md`.
|
|
> **But** : vérifier que le schéma de données cible est complet, cohérent avec les tâches 2 à 8, compatible SQLite MVP, et préparé pour les évolutions futures.
|
|
> **Gate obligatoire** : cette validation doit être passée avant toute migration BDD majeure.
|
|
> **Rappel** : la tâche 1.9 est une mission de design architecture BDD, pas d'implémentation.
|
|
|
|
---
|
|
|
|
## 0. Quand lancer cette validation
|
|
|
|
- La mission `tache1.9.md` est annoncée terminée.
|
|
- Les livrables de schéma/architecture sont présents.
|
|
- Les tâches 2 à 8 ont été prises en compte ou explicitement exclues avec justification.
|
|
|
|
Si un point manque → rejet immédiat.
|
|
|
|
---
|
|
|
|
## 1. Discipline & périmètre
|
|
|
|
- [ ] Aucun code de production modifié pour cette mission.
|
|
- [ ] Aucun schéma/migration appliqué sans plan de migration validé.
|
|
- [ ] Le schéma actuel `machines/snapshots/executions` est respecté comme point de départ.
|
|
- [ ] Les secrets ne sont pas mélangés aux tables publiques.
|
|
- [ ] Le design reste compatible SQLite/Drizzle au MVP.
|
|
|
|
---
|
|
|
|
## 2. Complétude du schéma
|
|
|
|
- [ ] Core : `machines`, credentials, host keys, tags, état courant.
|
|
- [ ] JSON/historique : snapshots, exécutions, événements, rapports, artefacts, messages importants.
|
|
- [ ] APT : paquets prévus, appliqués, erreurs.
|
|
- [ ] Docker : settings, roots Compose, stacks, services, image events.
|
|
- [ ] Post-install/scripts : profils, recettes, versions, état machine, presets.
|
|
- [ ] Jobs/schedules : jobs, schedules, locks, action requests.
|
|
- [ ] Hermes/MCP : sessions, runs, usage tokens, audit MCP.
|
|
- [ ] API clients : tokens hashés, scopes, révocation.
|
|
- [ ] Optimisation : métriques système, cleanup, discovery scans/candidates.
|
|
- [ ] Frontend : `app_settings`, `user_preferences`, `machine_ui_state`.
|
|
- [ ] Hardware/métriques machines : `machine_hardware`, `machine_metrics_latest`.
|
|
|
|
---
|
|
|
|
## 3. Cohérence des principes
|
|
|
|
- [ ] Chaque JSON canonique complet est archivé.
|
|
- [ ] Les colonnes dérivées nécessaires aux filtres/UI sont indexables.
|
|
- [ ] `machine_id` est la clé de rattachement des échanges machine ↔ serveur.
|
|
- [ ] Les logs bruts sont référencés, pas copiés partout en BDD.
|
|
- [ ] Les messages importants survivent à la purge des logs bruts.
|
|
- [ ] La rétention est modélisée sans supprimer les rapports épinglés.
|
|
- [ ] Les actions Hermes sont représentées par demandes validables, pas par exécution directe.
|
|
- [ ] Les paramètres frontend et app locale sont séparés des données métier.
|
|
|
|
---
|
|
|
|
## 4. Compatibilité futur Docker Compose webserver
|
|
|
|
- [ ] Le schéma prévoit volumes persistants : DB, reports/logs, artifacts.
|
|
- [ ] Le schéma ne dépend pas d'un chemin local non portable.
|
|
- [ ] Les chemins de fichiers sont stockés comme références maîtrisées.
|
|
- [ ] Les secrets master key/API tokens restent hors image Docker.
|
|
- [ ] Le modèle reste utilisable dans un container backend unique au MVP.
|
|
|
|
---
|
|
|
|
## 5. Migration progressive
|
|
|
|
- [ ] Les phases de migration sont ordonnées et réalistes.
|
|
- [ ] Chaque phase peut être testée indépendamment.
|
|
- [ ] La migration depuis le schéma actuel est décrite.
|
|
- [ ] Les index principaux sont listés.
|
|
- [ ] Le passage futur PostgreSQL est anticipé sans imposer PostgreSQL au MVP.
|
|
|
|
---
|
|
|
|
## 6. Verdict
|
|
|
|
- **✅ Accepté** : schéma complet, cohérent, migrable.
|
|
- **🟡 Accepté avec réserves** : ajustements mineurs à faire.
|
|
- **❌ Rejeté** : modèle incomplet, secrets mal placés, migration floue ou incompatible MVP.
|
|
|
|
---
|
|
|
|
## 7. Notes de validation
|
|
|
|
**Revue du 2026-06-05 (orchestrateur).**
|
|
|
|
**Verdict : ✅ Accepté.**
|
|
|
|
Le schéma cible (`tache1.9.md`) couvre l'ensemble des besoins des tâches 2 à 8, reste compatible MVP SQLite/Drizzle, isole les secrets (`machine_credentials`), conserve les JSON complets + colonnes dérivées indexées, et fournit un plan de migration en 9 phases depuis le schéma actuel.
|
|
|
|
- §1 Discipline & périmètre : ✓ (design only, schéma `machines/snapshots/executions` conservé comme base, secrets isolés, SQLite/Drizzle).
|
|
- §2 Complétude : ✓ (tous les groupes de tables présents : core, JSON/historique, APT planned/applied/errors, Docker, post-install, jobs/schedules/locks/action_requests, Hermes/MCP, api_clients, optim/cleanup/discovery, frontend app_settings/user_preferences/machine_ui_state, hardware/metrics).
|
|
- §3 Principes : ✓ (JSON complets + dérivés, `machine_id` clé, logs référencés, `important_messages` survit à la purge, rétention avec `pinned`, actions Hermes via `action_requests`).
|
|
- §4 Docker Compose : ✓ (volumes DB/reports/artifacts, chemins comme références, secrets hors image).
|
|
- §5 Migration : ✓ (phases 1→9 ordonnées et testables indépendamment, index listés §13, PostgreSQL anticipé sans l'imposer).
|
|
|
|
**Réserve mineure corrigée pendant la revue** : doublon `créer discovery_candidates` dans la §14 Phase 9 (appartient à Phase 8) — supprimé.
|
|
|
|
**Cohérence avec l'existant** : le WIP non commité ajoute déjà le type `ServerCapabilities` + endpoint `/api/capabilities` (relève de la tâche 5) et la table `api_clients` prévue ici sert la tâche 8 — pas de conflit.
|