system_update/validation_tache1.9.md

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.