# 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

- [x] Aucun code de production modifié : la tâche est déclarée design-only et aucune modification de code n'est demandée.
- [x] 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).
- [x] Icônes par `ui-kit`/Font Awesome en premier ; SVG custom uniquement pour les concepts manquants listés.
- [x] SVG spécifiques délégués à `consigne_icon.md` (lien présent en §3).
- [x] 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

- [x] Vue globale ASCII définie en §4 (header / volet Hermes / centre / terminal / footer).
- [x] Volet Hermes : ne masque pas la zone centrale — explicitée en §4 (contrainte).
- [x] Terminal droit : ne recouvre pas les tuiles — explicitée en §4 (contrainte).
- [x] 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.
- [x] 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é.
- [x] 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

- [x] État compact défini (§5, maquette ASCII détaillée).
- [x] État Docker ouvert défini (§5, état Docker déplié).
- [x] État Post-install ouvert défini (§5, état Post-install déplié).
- [x] État machine physique/Proxmox/hardware défini (§5, état complet hôte physique / Proxmox).
- [x] OS et type machine visibles (§5, badge `debian · vm · amd64 · qemu` et champs ajout machine).
- [x] APT, Docker, Post-install, Hardware et Alerts représentés. Health (CPU/RAM/disk) présent dans les maquettes compactes et Proxmox.
- [x] Actions dangereuses identifiées (upgrade, full-upgrade, reboot, prune mode agressif demandent confirmation — §6, §7). `<Popup>` exigé à la place de `window.alert`.
- [x] 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

- [x] Vue onglet Paramètres définie (maquette ASCII §9 : nav gauche + panneau droit avec catégories).
- [x] Catégories minimales présentes : Général/Apparence, Machines, Docker, Scripts, Hermes/MCP, Terminal SSH, Nettoyage, Sécurité, Découverte, Icônes/application.
- [x] 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`.
- [x] 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

- [x] Discussion Hermes : messages utilisateur/Hermes/système distingués (§9, volet Hermes). Horodatage, état streaming, saisie multi-ligne définis.
- [x] Copier-coller natif + boutons copier prévus (§9, volet Hermes).
- [x] 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 »).
- [x] Cartes de validation séparées du texte Hermes : « actions proposées affichées comme cartes séparées, jamais comme texte ambigu » (§9).
- [x] 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.
- [x] Terminal SSH interactif désactivable : bouton explicite, paramètre global d'activation/désactivation (§9).

---

### Section 6 — Icônes et assets

- [x] `favicon.svg`, `favicon.ico`, `apple-touch-icon.png`, icônes PWA (`192x192`, `512x512`, masquable) spécifiés (§3).
- [x] 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).
- [x] Icônes SVG custom candidates priorisées : `consigne_icon.md` §6 liste priorité haute/moyenne/basse.
- [x] Style Gruvbox seventies : défini comme contrainte principale.
- [x] 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

- [x] Frontend consomme uniquement JSON canonique : règle explicite en §10 et en §12 (Définition de terminé).
- [x] 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 »).
- [x] Références rapports/logs affichées par liens/actions : mentionné en §9 (terminal — « lien rapport/log brut après fin d'exécution »).
- [x] 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.