system_update/validation_tache3.md

Protocole de validation — Tâche 3 (frontend web, tuiles, layout, paramètres)

Type : grille de validation. Utilisée après la mission décrite dans tache3.md. But : vérifier que la spec frontend est complète, respecte le design system, et s'intègre au backend/API sans inventer de logique métier côté client. Gate obligatoire : cette validation doit être passée avant implémentation frontend majeure. Rappel : la tâche 3 est une mission design UX/UI, pas d'implémentation.

---

0. Quand lancer cette validation

• La mission tache3.md est annoncée terminée.
• Les maquettes ASCII et specs frontend sont présentes.
• consigne_icon.md existe si des icônes spécifiques sont demandées.

---

1. Discipline & périmètre

• Aucun code de production frontend modifié dans cette mission de design.
• Le design respecte design_system/consigne_design_system.md.
• Les icônes passent d'abord par le ui-kit/Font Awesome.
• Les SVG spécifiques sont listés dans consigne_icon.md, pas improvisés dans le JSX.
• Aucun secret n'est affiché ou stocké côté navigateur.

---

2. Layout global webapp

• Vue globale header/volet Hermes/centre/terminal/footer définie.
• Le volet Hermes ne masque pas la zone centrale.
• Le terminal droit ne masque pas les tuiles.
• Les dimensions sont bornées, redimensionnables et responsive.
• Le footer contient les métriques compactes attendues.
• Le mode smartphone est traité comme une UX dédiée, pas comme trois colonnes compressées.

---

3. Tuiles machine

• État compact défini.
• État Docker ouvert défini.
• État Post-install ouvert défini.
• État machine physique/Proxmox/hardware défini.
• OS et type machine sont visibles.
• APT, Docker, Post-install, Hardware, Health et Alerts sont représentés.
• Les actions dangereuses sont clairement distinguées et validables.
• La tuile s'agrandit sans casser la grille.

---

4. Paramètres frontend

• Vue onglet Paramètres définie.
• Paramètres d'apparence, tuiles, volets, Docker, scripts, Hermes, terminal SSH et nettoyage présents.
• Les paramètres persistants sont destinés au backend/BDD, pas uniquement localStorage.
• Les paramètres app icons/favicon/PWA sont listés.

---

5. Hermes et terminal

• Discussion Hermes lisible : messages utilisateur/Hermes/système distingués.
• Copier-coller natif et boutons copier prévus.
• Blocs de commandes copiables mais non exécutés automatiquement.
• Cartes de validation séparées du texte Hermes.
• Terminal logs d'exécution distinct du vrai terminal SSH interactif.
• Terminal SSH interactif désactivable et clairement risqué.

---

6. Icônes et assets

• favicon.svg, favicon.ico, apple-touch-icon.png, icônes PWA sont spécifiés.
• Liste d'alias ICON_MAP à ajouter/vérifier.
• Liste d'icônes SVG custom candidates priorisée.
• Le style respecte Gruvbox seventies.
• Pas de logo propriétaire copié.

---

7. Intégration JSON/API

• Le frontend consomme uniquement JSON canonique/API.
• Le frontend ne parse jamais les logs bruts pour calculer un état.
• Les références rapports/logs sont affichées par liens/actions.
• Les erreurs structurées sont affichables sans ouvrir le terminal.

---

8. Verdict

• ✅ Accepté : spec UI complète et implémentable.
• 🟡 Accepté avec réserves : points UX mineurs à clarifier.
• ❌ Rejeté : design incomplet, non conforme au DS, ou logique métier côté client.

---

9. Notes de validation

Date : 2026-06-05. Relecteur : orchestrateur, validation déléguée.

---

Verdict global

Accepté avec réserves (🟡)

La spec tache3.md couvre l'essentiel du périmètre attendu : layout global, tuiles machine à plusieurs états, paramètres frontend, volet Hermes, terminal, icônes/favicon/PWA, intégration JSON/API. Les règles du design system sont explicitement rappelées et la distinction terminal de logs vs SSH interactif est traitée. Quelques points nécessitent une clarification ou un complément avant implémentation.

---

Section 1 — Discipline et périmètre

• Aucun code de production modifié : la tâche est déclarée design-only et aucune modification de code n'est demandée.
• Respect du DS formellement exigé : section 2 liste toutes les règles (variables CSS, ui-kit, <Icon>/<IconButton>, pas de hover sauf jauges, tooltips, polices, Popup, labels uppercase).
• Icônes par ui-kit/Font Awesome en premier ; SVG custom uniquement pour les concepts manquants listés.
• SVG spécifiques délégués à consigne_icon.md (lien présent en §3).
• Aucun secret affiché côté navigateur : règle explicite en §9 (terminal) et §10 (JSON). Masquage backend exigé avant diffusion UI.

Note : le ui-kit actuel (ui-kit.tsx) n'expose ni composant Checkbox ni composant Select/Dropdown ni Input. La spec §8 demande des « vraies cases à cocher du design system » (Toggle ou checkbox stylée) et les maquettes Post-install montrent des <select> (ex. Interface ens18 ▼). Toggle est disponible dans le ui-kit mais ne couvre pas exactement la sémantique d'une case à cocher de profil. Ce point est une réserve mineure : l'agent d'implémentation devra soit utiliser Toggle, soit créer un composant Checkbox dans le ui-kit (avec accord préalable).

---

Section 2 — Layout global webapp

• Vue globale ASCII définie en §4 (header / volet Hermes / centre / terminal / footer).
• Volet Hermes : ne masque pas la zone centrale — explicitée en §4 (contrainte).
• Terminal droit : ne recouvre pas les tuiles — explicitée en §4 (contrainte).
• Largeurs redimensionnables et bornées : mentionné en §4 ; valeurs cibles (px min/max) renvoyées aux paramètres §9 (Hermes 280px, Terminal 420px — visibles dans la maquette paramètres). Les valeurs précises min/max ne sont pas formalisées dans un tableau, mais les tokens DS (consigne_design_system.md §tailles) couvrent Sidebar 200-260px et Volet logs 320-360px — légère divergence avec les 280/420px de la maquette. Réserve mineure.
• Footer avec métriques compactes : présent dans la maquette ASCII §4 (mode · machines · apt · docker · jobs · cpu · ram · db · hermes · ts). La spec détaillée du footer est renvoyée à tache7.md — acceptable car explicitement référencé.
• Mode smartphone traité comme UX dédiée (§9, mode smartphone) : onglets / bottom bar explicites, liste de questions à trancher, proposition MVP mobile. La spec mobile complète (breakpoints, composants, interactions) est demandée comme livrable dédié — c'est une réserve attendue et déclarée.

---

Section 3 — Tuiles machine

• État compact défini (§5, maquette ASCII détaillée).
• État Docker ouvert défini (§5, état Docker déplié).
• État Post-install ouvert défini (§5, état Post-install déplié).
• État machine physique/Proxmox/hardware défini (§5, état complet hôte physique / Proxmox).
• OS et type machine visibles (§5, badge debian · vm · amd64 · qemu et champs ajout machine).
• APT, Docker, Post-install, Hardware et Alerts représentés. Health (CPU/RAM/disk) présent dans les maquettes compactes et Proxmox.
• Actions dangereuses identifiées (upgrade, full-upgrade, reboot, prune mode agressif demandent confirmation — §6, §7). <Popup> exigé à la place de window.alert.
• Agrandissement de tuile sans casser la grille : grid-column: 1 / -1 pour la variante expanded mentionné en §1.

Réserve mineure : l'état « erreur machine / machine hors ligne / machine déconnectée » (statut error ou unknown) est listé dans §6 mais aucune maquette ASCII ne le montre de façon dédiée. Le livrable §11 point 2 demande explicitement un état erreur — ce sera à produire dans le doc de design final.

---

Section 4 — Paramètres frontend

• Vue onglet Paramètres définie (maquette ASCII §9 : nav gauche + panneau droit avec catégories).
• Catégories minimales présentes : Général/Apparence, Machines, Docker, Scripts, Hermes/MCP, Terminal SSH, Nettoyage, Sécurité, Découverte, Icônes/application.
• Persistance backend/BDD explicitée : §9 « les paramètres frontend persistants doivent être sauvegardés côté backend/BDD » + règle complémentaire localStorage uniquement comme cache. Cohérent avec tache1.9.md tables app_settings / user_preferences / machine_ui_state.
• Paramètres app icons/favicon/PWA listés (§9, maquette, catégorie Icônes/application).

Note : la maquette paramètres affiche [save] [close] dans le header, ce qui implique un mécanisme de sauvegarde groupée. La spec ne détaille pas si les paramètres sont persistés à chaque changement (auto-save) ou à la validation. Ce point devra être tranché à l'implémentation.

---

Section 5 — Hermes et terminal

• Discussion Hermes : messages utilisateur/Hermes/système distingués (§9, volet Hermes). Horodatage, état streaming, saisie multi-ligne définis.
• Copier-coller natif + boutons copier prévus (§9, volet Hermes).
• Blocs de commandes copiables mais non exécutés automatiquement : règle explicite (§9, volet Hermes — « une commande copiée ne doit pas être exécutée automatiquement »).
• Cartes de validation séparées du texte Hermes : « actions proposées affichées comme cartes séparées, jamais comme texte ambigu » (§9).
• Terminal logs d'exécution distinct du terminal SSH interactif : deux modes définis (§9, terminal volet droit), avec règle de masquage des secrets.
• Terminal SSH interactif désactivable : bouton explicite, paramètre global d'activation/désactivation (§9).

---

Section 6 — Icônes et assets

• favicon.svg, favicon.ico, apple-touch-icon.png, icônes PWA (192x192, 512x512, masquable) spécifiés (§3).
• Liste d'alias ICON_MAP à ajouter : §3 fournit la liste complète en catégories (navigation, actions système, machine/profil, APT/Docker/post-install, sécurité/états).
• Icônes SVG custom candidates priorisées : consigne_icon.md §6 liste priorité haute/moyenne/basse.
• Style Gruvbox seventies : défini comme contrainte principale.
• Pas de logo propriétaire copié (§3 direction visuelle).

Réserve — incohérence inter-docs : tache3.md §3 dit « éviter les logos de distributions ou marques propriétaires » tandis que consigne_icon.md §2 dit « on peut utiliser des logos officiels de distributions, Docker, Proxmox, Raspberry Pi, NVIDIA, etc. ». Ces deux directives sont contradictoires. La consigne_icon.md est le brief de référence pour l'agent SVG : c'est elle qui fait foi pour la création des icônes. Mais la phrase de tache3.md sur la direction visuelle du favicon/app icon peut rester cohérente (le favicon principal est une icône maison, pas un logo redistribué). Il faudra clarifier dans la prochaine révision de tache3.md : les logos officiels sont admis pour les icônes de type de machine (proxmox-host, raspberry-pi, docker), mais pas pour le favicon ou l'app icon qui doit être une création originale.

---

Section 7 — Intégration JSON/API

• Frontend consomme uniquement JSON canonique : règle explicite en §10 et en §12 (Définition de terminé).
• Frontend ne parse jamais les logs bruts : règle explicite en §10 (« le frontend ne doit jamais parser du log brut pour décider l'état d'une tuile »).
• Références rapports/logs affichées par liens/actions : mentionné en §9 (terminal — « lien rapport/log brut après fin d'exécution »).
• Erreurs structurées lisibles sans ouvrir le terminal : règle explicite en §6 (« les erreurs doivent être lisibles directement dans la tuile sans ouvrir le terminal »).

---

Cohérence avec le jalon 2 (polish DS absorbé par tâche 3)

Le wiring DS (exports ESM ui-kit + Font Awesome + polices) est déjà commité selon 2026-06-05-jalon2-polish-design-system.md. La tâche 3 ne le contredit pas et le prend comme acquis (§13 checklist et §2 contraintes DS). La spec tâche 3 est cohérente avec ce qui a été livré : elle exige les mêmes composants (<Icon>, <IconButton>, <StatusLed>, <Popup>, <Button>, <Toggle>) et les mêmes règles (pas de hover, tooltips, deux thèmes). Pas de contradiction.

Note : l'état actuel de MachineTile.tsx utilise encore des <button className="interactive"> bruts et une pastille inline (pas <StatusLed>). La tâche 3 est une spec design, pas d'implémentation — ce delta est attendu et sera traité lors de l'implémentation.

---

Réserves majeures

Aucune réserve bloquante ne justifie un rejet. Les points ci-dessous sont des réserves à traiter avant ou pendant l'implémentation :

1. Incohérence logos officiels (tache3.md §3 vs consigne_icon.md §2) : à clarifier formellement. Suggestion : autoriser les logos officiels uniquement pour les icônes de type de machine ; le favicon/app icon reste une création originale.
2. Composant Checkbox absent du ui-kit : Toggle couvre on/off, mais les cases à cocher des profils Post-install ont une sémantique différente (sélection d'un profil dans une liste, pas un toggle binaire global). L'agent d'implémentation devra arbitrer ou créer un composant Checkbox ds-compliant.
3. Spec mobile incomplète : la spec déclare explicitement qu'elle doit être produite séparément (breakpoints, composants, interactions). Acceptable comme livrable différé — mais doit être produite avant implémentation du mode smartphone.
4. Largeurs min/max des volets : les valeurs cibles (280px Hermes, 420px Terminal) dans la maquette paramètres divergent légèrement des tokens DS (Sidebar 200-260px, Volet logs 320-360px). À aligner ou à justifier.

Réserves mineures

5. État « machine hors ligne / erreur » : pas de maquette ASCII dédiée, bien que le statut soit listé (voir livrable §11 point 2).
6. Mécanisme save paramètres (auto-save vs validation groupée) : à trancher à l'implémentation.
7. <Select> / <Dropdown> non présents dans le ui-kit actuel, alors que les maquettes montrent des menus déroulants (OS, type machine, interface réseau). À créer ou à utiliser un <select> HTML stylé en CSS DS.

Coquilles corrigées dans tache3.md

• Lignes 351 et 501 : 10.0.4.25/22 corrigé en 10.0.4.25/24. Le CIDR /22 (plage 10.0.0.0–10.0.3.255) était incorrect pour une adresse en 10.0.4.x ; /24 est le masque attendu pour l'exemple.

Coquille signalée (non corrigée — dans bloc ASCII illustratif)

• Ligne 330 : emoji 🧹 dans le bloc ASCII maquette « État Docker déplié ». Le document lui-même précise que « le rendu final doit utiliser des icônes Font Awesome via le design system, pas les symboles ASCII ci-dessus ». Cet emoji est donc toléré comme raccourci illustratif dans une maquette ASCII. L'alias prune (icône DS correspondante) est bien listé en §3. Aucune correction appliquée.