# 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.