system_update/validation_tache2.md

Protocole de validation — Tâche 2 (moteur de templates de mise à jour)

Type : grille de validation. Utilisée par l'agent orchestrateur (Claude Code principal) après qu'un agent sous-traitant a rendu la mission décrite dans tache2.md. But : vérifier que les livrables de la tâche 2 sont complets, respectent le périmètre, et s'intègrent correctement à l'application existante sans rien casser. ⚠️ Gate obligatoire : cette validation doit être passée AVANT toute phase de développement. Tant que le verdict n'est pas ✅ Accepté, aucune implémentation des livrables de la tâche 2 ne démarre (ni par l'agent sous-traitant, ni par l'orchestrateur). Le design est figé et validé d'abord ; le code vient après. Rappel : la tâche 2 est une mission de design/investigation (pas d'implémentation). On valide donc des documents de design/spec, pas du code de production. Les vérifications de non-régression servent uniquement à confirmer que l'existant n'a pas été touché.

---

0. Quand lancer cette validation

• La mission tache2.md est annoncée terminée.
• Le fichier tache2.md a bien été mis à jour avec sa section « État d'avancement / Ce qui a été fait » (clôture obligatoire).
• Les livrables de design sont présents sous docs/ (ou l'emplacement proposé par l'agent).

Si l'un de ces points manque → rejet immédiat, renvoyer à l'agent.

---

1. Discipline & périmètre (l'agent n'a pas débordé)

Vérifier via git status / git diff et lecture des commits :

• Aucun code de production modifié ou ajouté : pas de changement sous server/, client/, shared/, templates/, ni dans les configs (package.json, tsup.config.ts, vite.config.ts, etc.). Seuls des fichiers docs/** et tache2.md doivent avoir changé.
• Jalon 1 et jalon 2 intacts : aucun fichier de ces jalons touché.
• Aucun autre chantier démarré hors du périmètre de tache2.md (les idées hors-scope doivent figurer comme suggestions, pas comme du travail réalisé).
• Les dépôts de référence (linux-update-dashboard/, nas-ops/) n'ont pas été copiés tels quels dans le code (respect licence AGPL).

Si du code de production a été écrit → rejet : la mission devait s'arrêter au design.

---

2. Complétude des livrables

Confronter au § « Livrables attendus » et aux 5 axes de tache2.md :

Axes couverts :

• Axe A — Templates APT (update, upgrade, full-upgrade, dist-upgrade, clean, autoremove, reboot) avec sémantique clarifiée et profils OS (Debian/Ubuntu/Proxmox/RPi) + gestion proxy apt-cacher-ng.
• Axe B — Capture des updates prévus (snapshot) et appliqués (diff avant/après), consommable par Hermes (déduplication + réduction).
• Axe C — Taxonomie des erreurs + stratégie de gestion/remédiation.
• Axe D — Docker : scan, pull, up, down, prune images inutilisées, détection des stacks (labels + fallback répertoires déclarés), JSON compact.
• Axe E — Scripts personnalisés (post-install, install paquets) + overrides par machine + garde-fous.

Livrables (§4 de tache2.md) :

• Inventaire des templates.
• Contenu proposé des templates clés (pseudo-shell réaliste, convention ===SU:XXX===).
• Schémas JSON canoniques étendus (snapshot + résultat, APT + Docker + erreurs + custom).
• Taxonomie des erreurs.
• Modèle des profils OS + overrides.
• Modèle des scripts personnalisés.
• Note de sécurité.
• Découpage en sous-jalons priorisé.

Questions d'investigation (§3) :

• Les 7 questions sont tranchées, chacune avec MVP recommandé / alternatives / risques.

Tout livrable ou question manquant → renvoi pour complément.

---

3. Cohérence & intégration avec l'application existante

C'est le cœur de la validation : le design doit s'emboîter avec ce qui existe.

• Types JSON : les extensions proposées sont compatibles avec shared/types.ts (UpdateSnapshot, ExecutionResult). Les ajouts sont rétro-compatibles (champs optionnels, pas de rupture du jalon 1). Vérifier qu'un snapshot/exécution du jalon 1 resterait valide.
• Convention des templates : les templates proposés suivent la convention existante (marqueurs ===SU:XXX===, LC_ALL=C, exécution sous sudo -S, sortie parsable). Cohérent avec templates/apt/*.tpl, server/templates/render.ts, server/services/aptParse.ts.
• Parsing : la stratégie retenue (JSON-in-shell vs parsing-TS) est explicite, justifiée, et compatible avec server/services/ ou propose une migration claire sans casser le refresh/upgrade actuels.
• Couche SSH : le design réutilise server/ssh/client.ts (pas de nouveau mécanisme d'exécution non justifié) ; opérations longues/détachées traitées de façon cohérente.
• Frontière Hermes/MCP : aucun secret n'atteint Hermes/MCP ; la surface MCP reste minimale ; les données envoyées au LLM passent par la réduction déterministe (aptReduce.ts ou équivalent étendu).
• Sécurité : actions destructives (prune, down, reboot, dist-upgrade) exigent une validation explicite côté webapp ; pas de secret en clair (logs/UI/MCP).
• Profils OS : le mécanisme proposé n'invalide pas le comportement Debian/Ubuntu prouvé en prod au jalon 1.
• Découpage en sous-jalons : chaque sous-jalon est implémentable indépendamment et produit un logiciel testable (compatible avec le workflow spec → plan → implémentation).

---

4. Non-régression (l'existant tourne toujours)

Confirmer que rien n'a été cassé (puisque la mission ne devait pas toucher le code) :

• rtk pnpm check → 0 erreur TypeScript.
• rtk pnpm test → suite verte (au moins les tests du jalon 1, + jalon 2 s'il est mergé).
• rtk pnpm build → dist/index.js + dist/client produits.
• Les flux prouvés du jalon 1 (ajout machine, refresh APT, full-upgrade, reboot, rapport) restent inchangés dans le code.

Une régression ici signifie que l'agent a touché au code malgré la consigne → rejet.

---

5. Verdict

Rédiger une conclusion explicite :

• ✅ Accepté : tous les blocs cochés. → On peut enchaîner sur writing-plans pour le 1ᵉʳ sous-jalon recommandé.
• 🟡 Accepté avec réserves : livrables complets mais points de design à ajuster → lister les corrections, renvoyer pour itération courte.
• ❌ Rejeté : périmètre débordé, code de production écrit, livrables incomplets, ou incohérence majeure avec l'appli → renvoyer à l'agent avec les points bloquants précis.

Consigner le verdict (date, blocs en échec, actions de suite) en bas de ce fichier ou dans un commit dédié.

---

6. Notes de validation (à remplir au moment de la revue)

(Section laissée vide ; à compléter lors de la validation effective : date, verdict, points relevés, décisions.)