gilles
f8a8478749
tache2.md: mission design/investigation, périmètre strict, clôture obligatoire. validation_tache2.md: grille de validation, gate avant toute phase de dev. amelioration.md: retour d'usage (séparation terminal entre machines). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
94 lines
6.9 KiB
Markdown
94 lines
6.9 KiB
Markdown
# 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.)_
|