Files

T

gilles 0fbca06d3d docs: roadmap tâches 1.9-8 (briefs, gates de validation, designs tâche 2) + plans d'implémentation

Cartographie complète (liste_taches/coherence_taches), briefs tacheN + gates
validation_tacheN, design tâche 2 (docs/design/tache2/), specs/plans jalon 1-2
et tâche 1.9/2 (Phase 1, Phase 2, SJ-0→3). Validations consignées (1.9 ✅, 2-8 🟡).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-06-05 19:50:25 +02:00

15 KiB

Raw Permalink Blame History

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 :

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

État « machine hors ligne / erreur » : pas de maquette ASCII dédiée, bien que le statut soit listé (voir livrable §11 point 2).
Mécanisme save paramètres (auto-save vs validation groupée) : à trancher à l'implémentation.
<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.

15 KiB Raw Permalink Blame History Unescape Escape