# Consigne de dev — Design des tuiles machine et paramètres frontend > **Type** : mission de **design UX/UI + spec frontend** (PAS d'implémentation). > **Langue** : français. > **Livrable final attendu** : document(s) de design/spec prêts à passer en plan d'implémentation. --- ## 0. Contexte Le projet `system_update` est une webapp de mise à jour distante de machines Linux, Docker Compose et scripts post-install, pilotée par SSH agentless. Le jalon actuel affiche des tuiles machine simples : nom, IP, OS, compteur APT, boutons `Refresh`, `Upgrade`, `Reboot`. La prochaine étape UI doit transformer chaque tuile en **cockpit machine compact et extensible**, compatible avec : - APT update/analyse/upgrade/reboot ; - Docker Compose : installation Docker, paramétrage des roots Compose, scan, stacks, upgrade, prune ; - Post-install : profils cochables, champs dynamiques, preview, exécution ; - Design system Gruvbox seventies. À lire avant de travailler : - `CLAUDE.md` - `design_system/consigne_design_system.md` - `docs/superpowers/specs/2026-06-04-jalon1-tranche-verticale-apt-design.md` - `docs/superpowers/specs/2026-06-05-jalon2-polish-design-system-design.md` - `validation_tache2.md` - `client/src/App.tsx` - `client/src/panels/Dashboard.tsx` - `client/src/features/machines/MachineTile.tsx` - `client/src/components/ui-kit.tsx` - `client/src/styles/app.css` --- ## 1. Objectif Concevoir le design des **tuiles machine extensibles** et des paramètres frontend liés. La tuile doit rester lisible par défaut, puis s'agrandir automatiquement quand l'utilisateur ouvre les sections Docker ou Post-install. Par défaut, on voit uniquement le bloc système : - statut machine ; - nom ; - IP/port ; - OS ; - compteur updates ; - dernier check ; - reboot requis ; - actions système en icônes. Deux sections doivent être repliables : - **Docker** - **Post-install** Quand une section s'ouvre, la tuile s'agrandit en hauteur. Si le contenu devient important, le design doit prévoir une variante `expanded` qui peut occuper toute la largeur de la grille (`grid-column: 1 / -1`) sans masquer les autres volets. --- ## 2. Contraintes design system Respect strict de `design_system/consigne_design_system.md` : - variables CSS uniquement ; - composants existants du `ui-kit` ; - icônes via `` / ``, jamais emoji/SVG inline ; - tooltips obligatoires sur icônes seules ; - pas de hover décoratif, seulement pression `.interactive` ; - polices Inter / JetBrains Mono / Share Tech Mono ; - labels uppercase `.label` ; - tuiles `glass`, rayon 10-12px ; - UI dense, lisible dark + light ; - ne pas utiliser `window.alert` / `confirm`, utiliser ``. Les boutons texte doivent être réservés aux commandes explicites longues ou primaires. Dès que possible, remplacer par des icônes : - analyse/refresh : `refresh` - upgrade/apply : `download` ou alias à ajouter si besoin - reboot/power : `power` - paramètres : `cog` - rapport/log : `list` ou `terminal` - ouvrir/fermer section : `chevD` / `chevR` - installer/ajouter : `plus` ou `download` - erreur : `alert` - dossier/roots compose : `folder` Si une icône manque, proposer l'ajout d'un alias dans `ICON_MAP` du ui-kit, sans inventer de SVG. --- ## 3. Identité app, favicon et icônes La webapp doit disposer d'une identité visuelle propre, compatible desktop et smartphone. Assets à prévoir : - `favicon.svg` : favicon principal vectoriel ; - `favicon.ico` : fallback navigateur ; - `apple-touch-icon.png` : icône smartphone/tablette ; - `web-app-manifest` ou équivalent futur : icônes `192x192` et `512x512` ; - icône monochrome/masque si l'app devient PWA ; - icône large éventuelle pour page d'accueil/launcher. Direction visuelle : - thème Gruvbox seventies ; - symbole simple et lisible en petit format ; - évoquer monitoring système + update + machines ; - éviter les logos de distributions ou marques propriétaires ; - éviter emoji, gradient SaaS, mascotte, illustration complexe ; - formes robustes : terminal, serveur, flèche d'update, LED, grille machine. Un fichier dédié [consigne_icon.md](/home/gilles/Documents/projet/system_update/consigne_icon.md) doit servir de brief à un agent de création SVG. ### Icônes applicatives utiles Le frontend doit d'abord utiliser Font Awesome via `Icon`/`IconButton`. Les SVG spécifiques ne sont à créer que si Font Awesome ne couvre pas assez bien le besoin ou si l'app a besoin d'un pictogramme propriétaire. Alias à prévoir ou vérifier dans `ICON_MAP` : ```text Navigation/layout - app-logo - hermes - machines - settings - terminal - logs - report - copy - open-external - fullscreen - collapse Actions système - refresh - analyze - upgrade - full-upgrade - reboot - stop - dry-run - approve - reject Machine/profil - server - vm - physical-host - proxmox - raspberry-pi - container - gpu - cpu - memory - disk - network - health APT/Docker/Post-install - package - repository - firmware - driver - docker - compose-stack - image - prune - script - profile Sécurité/états - ok - warning - error - locked - secret - key - shield - disconnected - running ``` Les icônes spécifiques SVG candidates : - `app-logo` : identité de l'application ; - `hermes` : si l'agent a une identité visuelle locale distincte ; - `proxmox` : pictogramme générique d'hyperviseur, sans reprendre le logo officiel ; - `compose-stack` : pile de conteneurs/stacks, plus précis que `server` ; - `firmware-driver` : composant matériel + puce ; - `machine-probe` : loupe + serveur ; - `reboot-verified` : power + check. --- ## 4. Layout global de la webapp Le design cible reste un dashboard 3 zones avec header et footer fixes. ```text ┌──────────────────────────────────────────────────────────────────────────────┐ │ HEADER System Update [search] [scan ssh] [+ machine] [theme] [⚙] │ ├──────────────────┬─────────────────────────────────────┬───────────────────┤ │ HERMES │ MACHINES │ TERMINAL │ │ chat clair │ grille de tuiles │ logs/action SSH │ │ │ │ │ │ user message │ ┌─────────────────────────────────┐ │ vm_mqtt │ │ hermes answer │ │ machine tile compact/expanded │ │ live output │ │ command blocks │ └─────────────────────────────────┘ │ search/filter │ │ action cards │ ┌─────────────────────────────────┐ │ report/log links │ │ │ │ machine tile compact/expanded │ │ │ ├──────────────────┴─────────────────────────────────────┴───────────────────┤ │ FOOTER mode · machines · apt · docker · jobs · cpu · ram · db · hermes · ts │ └──────────────────────────────────────────────────────────────────────────────┘ ``` Contraintes : - le volet Hermes gauche ne masque jamais les tuiles ; - le terminal droit ne recouvre jamais la section centrale ; - les largeurs sont redimensionnables mais bornées ; - le centre garde `min-width: 0` et scrolle indépendamment ; - sur mobile, ce layout devient des onglets/pages, pas trois colonnes compressées. --- ## 5. Tuile machine — structure cible ### Ajout machine — sélection OS et type Lors de l'ajout d'une machine, le frontend doit prévoir deux champs distincts : - **OS** : Debian, Ubuntu, Proxmox VE, Raspberry Pi OS, autre Linux ; - **Type de machine** : VM, machine physique, hôte Proxmox, LXC/container, Raspberry Pi, serveur GPU/workstation. Le formulaire doit permettre : - choix manuel rapide ; - bouton d'auto-détection après test SSH ; - affichage du résultat détecté avec possibilité de correction ; - explication courte des conséquences, sans texte long : les scripts proposés changent selon le profil ; - avertissement si incohérence, par exemple OS Proxmox mais type VM, ou Raspberry Pi OS sans architecture ARM. Exemple UX : ```text Ajouter machine ┌──────────────────────────────────────────────┐ │ Nom [ vm_mqtt ] │ │ Hôte/IP [ 10.0.0.3 ] │ │ OS [ Debian v ] │ │ Type machine [ VM v ] │ │ │ │ [tester SSH] [détecter OS/hardware] │ └──────────────────────────────────────────────┘ ``` Après détection, la tuile peut afficher un badge compact : ```text debian · vm · amd64 · qemu proxmox · physical · zfs raspios · raspberry_pi · arm64 ``` ### État compact ```text ┌────────────────────────────────────────────────────────────────────┐ │ ● vm_mqtt debian 13 · vm · amd64 · qemu │ │ 10.0.0.3:22 last check 06:42 │ ├────────────────────────────────────────────────────────────────────┤ │ SYSTEM APT 4 updates Reboot no Warnings 1 │ │ HEALTH CPU 0.08/4c RAM 26% / 29% │ │ │ │ [refresh] analyse [download] upgrade [power] reboot [list] log │ │ │ │ ▸ Docker 1 stack update · prune ready │ │ ▸ Post-install 0 selected · 3 recommended │ │ ▸ Hardware VM tools ok · no GPU │ └────────────────────────────────────────────────────────────────────┘ ``` ### État complet hôte physique / Proxmox ```text ┌────────────────────────────────────────────────────────────────────┐ │ ● proxmox-01 proxmox 9 · physical · amd64 │ │ 10.0.0.10:22 zfs · gpu detected · last 06:42 │ ├────────────────────────────────────────────────────────────────────┤ │ SYSTEM APT 12 updates Reboot yes Warnings 2 │ │ HEALTH CPU 0.42/16c RAM 41% / 68% /tank 72% │ │ ALERTS repo warning · firmware update available │ │ │ │ [refresh] [download] dist-upgrade [power] reboot [list] [cog] │ │ │ │ ▾ Docker 3 stacks · 1 update │ │ ok mqtt up-to-date │ │ warn frigate image update available │ │ [refresh] pull-check [download] apply [list] report │ │ ok paperless up-to-date │ │ [prune] images │ │ │ │ ▾ Post-install 2 recommended │ │ [ ] firmware tools physical host │ │ [ ] gpu drivers NVIDIA detected │ │ [ ] benchmark tools optional │ │ │ │ ▾ Hardware │ │ CPU 16c · RAM 64G · GPU NVIDIA · disks 4 · smart ok │ └────────────────────────────────────────────────────────────────────┘ ``` ### État Docker déplié ```text ┌────────────────────────────────────────────────────────────────────┐ │ ● vm_mqtt debian · 10.0.0.3:22 │ │ SYSTEM Updates: 4 Reboot: no Last check: 06:42 │ │ [↻] [⇩] [⏻] [▤] │ │ │ │ ▾ Docker installed · 3 stacks │ │ Roots: /home/gilles/docker, /opt/stacks [⚙] [↻] │ │ │ │ ✓ homeassistant 1 update available [⇩] │ │ ✓ mqtt up to date [✓] │ │ ⚠ paperless pull error [!] │ │ │ │ Prune images: 2 old images · 740 MB reclaimable [🧹] │ │ │ │ ▸ Post-install 0 profile selected │ └────────────────────────────────────────────────────────────────────┘ ``` Le rendu final doit utiliser des icônes Font Awesome via le design system, pas les symboles ASCII ci-dessus. ### État Post-install déplié ```text ┌────────────────────────────────────────────────────────────────────┐ │ ● debian-new debian · 10.0.2.81:22│ │ SYSTEM Updates: unknown Reboot: unknown │ │ [↻] analyse │ │ │ │ ▸ Docker not installed [⇩] │ │ ▾ Post-install │ │ ☑ Hostname + IP statique risk: net │ │ Hostname [ debian-docker-01 ] │ │ Interface [ ens18 ▼ ] │ │ Address [ 10.0.4.25/24 ] │ │ Gateway [ 10.0.0.1 ] │ │ DNS [ 10.0.0.1, 10.0.0.10 ] │ │ │ │ ☑ Base tools nano less tmux htop ncdu rsync... │ │ ☐ Sharing samba nfs avahi wsdd2 │ │ ☑ Docker officiel user: gilles · dir: /home/gilles/docker │ │ │ │ [preview] [run selected] │ └────────────────────────────────────────────────────────────────────┘ ``` Les cases à cocher doivent être de vrais contrôles du design system (`Toggle` ou checkbox stylée), pas du texte décoratif. --- ## 6. Section système La section système est toujours visible. Elle doit afficher : - statut : `ok`, `updates_available`, `running`, `warning`, `error`, `unknown` ; - machine : nom, hostname/IP, port, OS family/version ; - APT : - updates prévues ; - dernier `apt_update_analyze` ; - reboot requis ; - erreurs éventuelles ; - lien rapport/log si disponible. Actions : - analyser (`apt_update_analyze`) ; - upgrade simple ; - full/dist-upgrade si disponible ; - reboot vérifié ; - rapport/log. Règles : - `upgrade`, `full/dist-upgrade`, `reboot` demandent confirmation UI ; - actions désactivées si une action est déjà en cours ; - action d'upgrade désactivée si aucune analyse récente n'existe, ou affichée avec warning explicite ; - les erreurs doivent être lisibles directement dans la tuile sans ouvrir le terminal. --- ## 7. Section Docker La section Docker est repliée par défaut. Cas à couvrir : ### Docker non installé Afficher : - statut `Docker absent` ; - action installer Docker officiel ; - info courte : "installation via script officiel enregistré". Action : - bouton icône + tooltip `Installer Docker officiel`. - confirmation obligatoire. ### Docker installé, stacks non configurés Afficher : - statut `Docker installé`; - bouton paramètres section Docker ; - bouton scan ; - message : "Aucun root Compose validé". Paramètres Docker : - roots Compose par machine ; - profondeur de scan ; - stacks activés/désactivés ; - chemins ignorés ; - mode prune prudent/agressif. ### Stacks Compose détectés/configurés Afficher une liste compacte : - nom stack ; - chemin court ; - statut check ; - nombre de services ; - update dispo ; - erreur éventuelle ; - action upgrade si update dispo. Bouton `docker prune` : - actif uniquement après analyse Docker ; - indique l'espace récupérable si connu ; - confirmation obligatoire ; - mode agressif séparé et clairement marqué comme risqué. --- ## 8. Section Post-install La section Post-install est repliée par défaut. Elle contient des profils cochables : - `bootstrap_root` - `identity_network` - `base_tools` - `network_tools` - `dev_git` - `sharing` - `docker_official` - `home_automation` - `dev_tools` - `embedded_esp_platformio` - `terminal_customization` - `vm_guest_tools` - `storage_health` - `media_tools` - `security_audit` - `security_lab` (high risk) - `backup_sync` - `monitoring` - `network_services` Quand un profil est coché : - il déplie ses champs obligatoires ; - les champs peuvent être préremplis ; - le bouton run reste désactivé tant que les champs requis sont invalides ; - une preview du script rendu est disponible ; - les actions à risque demandent confirmation. Exemple Hostname + réseau : ```text ┌────────────────────────────────────────────────────────────────────┐ │ POST-INSTALL · Hostname + IP statique │ │ risk: network_change · reboot required │ ├────────────────────────────────────────────────────────────────────┤ │ ☑ Activer ce script │ │ Hostname [ debian-docker-01 ] │ │ Domaine local [ home ] │ │ Interface [ ens18 ▼ ] │ │ Adresse statique [ 10.0.4.25/24 ] │ │ Passerelle [ 10.0.0.1 ] │ │ DNS [ 10.0.0.1, 10.0.0.10 ] │ │ Reconnexion via [ 10.0.4.25 ] │ │ [preview] [run selected] │ └────────────────────────────────────────────────────────────────────┘ ``` --- ## 9. Paramètres frontend à concevoir Créer une spec pour les écrans/sections de paramètres suivants : Les paramètres frontend persistants doivent être sauvegardés côté backend/BDD : - thème ; - densité ; - zoom ; - taille/densité des tuiles ; - sections ouvertes par défaut ; - largeur des volets Hermes et terminal ; - activation du terminal SSH interactif ; - préférences de filtres terminal. Le navigateur peut garder une copie locale temporaire pour éviter un flash visuel au chargement, mais la source durable doit rester en BDD. ### Vue globale onglet Paramètres L'onglet paramètres doit rester dense et opérationnel, sans page marketing. ```text ┌──────────────────────────────────────────────────────────────────────────────┐ │ HEADER System Update [save] [close] │ ├──────────────────┬───────────────────────────────────────────────────────────┤ │ SETTINGS NAV │ PARAMETRES │ │ │ │ │ > Général │ Général │ │ Apparence │ Theme [dark v] Density [compact v] Zoom [100%] │ │ Machines │ Panels Hermes [280px] Terminal [420px] │ │ Docker │ │ │ Scripts │ Icônes / application │ │ Hermes/MCP │ Favicon [preview] Smartphone icon [preview] │ │ Terminal SSH │ App name [System Update] PWA enabled [off] │ │ Nettoyage │ │ │ Sécurité │ Docker │ │ Découverte │ Default scan depth [4] Prune mode [safe v] │ │ │ │ │ │ Scripts d'installation │ │ │ [Docker officiel] [Node] [Rust] [PlatformIO] [custom +] │ │ │ │ │ │ Terminal SSH │ │ │ Enable interactive SSH [off] Record sessions [off] │ ├──────────────────┴───────────────────────────────────────────────────────────┤ │ FOOTER settings · unsaved changes 0 · db ok · hermes connected · 06:42 │ └──────────────────────────────────────────────────────────────────────────────┘ ``` Catégories minimales : - Général/apparence ; - Machines et valeurs par défaut ; - Docker ; - Scripts d'installation ; - Hermes/MCP ; - Terminal SSH ; - Logs/rapports/nettoyage ; - Sécurité/secrets ; - Découverte réseau ; - Icônes/application. ### Terminal volet droit Le volet terminal droit doit être amélioré comme un vrai outil d'exploitation, pas seulement une zone xterm brute. Fonctions à concevoir : - en-tête clair avec machine sélectionnée : nom, IP, statut, action courante ; - séparation visuelle forte quand on change de machine ; - replay du buffer récent ; - autoscroll activable/désactivable ; - bouton pause/reprendre flux ; - bouton clear local ; - bouton copier sélection ; - recherche dans le terminal ; - filtre lignes importantes ; - mode log brut / mode réduit ; - indication WebSocket connecté/déconnecté ; - lien rapport/log brut après fin d'exécution ; - état "aucune machine sélectionnée" utile ; - redimensionnement robuste avec xterm fit ; - terminal plein écran ou drawer dédié sur petit écran. Deux modes doivent être distingués : 1. **Mode exécution suivie** : terminal attaché aux actions lancées par la webapp (`apt`, Docker, post-install, reboot). 2. **Mode SSH interactif** : ouverture d'un vrai shell SSH vers la machine sélectionnée, avec saisie de commandes par l'utilisateur. Le mode SSH interactif doit être clairement identifié comme plus risqué : - bouton d'ouverture explicite ; - indication machine/IP/utilisateur en permanence ; - confirmation si l'utilisateur ouvre un shell root ou sudo ; - journalisation de l'ouverture/fermeture de session ; - pas d'envoi automatique des commandes tapées à Hermes ; - masquage/censure des secrets dans le replay UI quand c'est possible ; - désactivation possible par paramètre global. Actions en icônes avec tooltips : - `terminal` : focus terminal ; - `pause` / `play` : pause/reprendre ; - `search` : chercher ; - `close` : clear local ou fermer drawer selon contexte ; - `download` : rapport/log ; - `alert` : erreurs filtrées. Le terminal ne doit jamais afficher de secret. Si une sortie contient un motif sensible, le design doit prévoir une étape backend de masquage avant diffusion UI. ### Volet Hermes gauche Le volet Hermes doit présenter une discussion claire, distincte du terminal : - bulles ou lignes différenciées `Utilisateur` / `Hermes` / `Système` ; - horodatage discret ; - état streaming / génération en cours ; - bouton copier sur chaque message ; - sélection et copier-coller natifs dans le texte ; - historique scrollable sans masquer le dashboard ; - zone de saisie stable, multi-ligne, avec envoi contrôlé ; - rendu lisible des blocs de commande ; - bouton copier sur chaque bloc de commande ; - actions proposées affichées comme cartes séparées, jamais comme texte ambigu ; - lien vers rapports, logs réduits, snapshots ou exécutions quand Hermes les cite. Les commandes proposées par Hermes doivent être faciles à relire et copier : ```text Hermes ┌────────────────────────────────────┐ │ Commande proposée │ │ apt-get update │ │ apt-get -s dist-upgrade │ │ [copier] │ └────────────────────────────────────┘ ``` Une commande copiée depuis Hermes ne doit pas être exécutée automatiquement. Toute action SSH lancée par la webapp passe par les boutons/actions validées. ### Mode smartphone / responsive Prévoir un brainstorming frontend spécifique pour le mode smartphone avant implémentation. Le layout desktop 3 volets ne peut pas simplement être compressé. Questions à trancher : - navigation par tabs ou bottom bar : `Hermes`, `Machines`, `Terminal` ; - terminal en drawer plein écran ou page dédiée ; - tuile machine en carte verticale ; - sections Docker/Post-install repliées par défaut ; - actions dangereuses en popup plein écran ; - clavier mobile pour champs IP/CIDR/hostname ; - taille minimale des touch targets ; - comportement du terminal avec clavier virtuel ; - conservation de la lisibilité dark/light ; - possibilité de masquer Hermes ou terminal pour garder le dashboard lisible. Proposition MVP mobile : ```text ┌────────────────────────────┐ │ System Update [☰] │ ├────────────────────────────┤ │ Machines │ │ ┌────────────────────────┐ │ │ │ ● vm_mqtt │ │ │ │ APT 4 · Docker 1 │ │ │ │ [↻] [⇩] [⏻] [▤] │ │ │ │ ▸ Docker │ │ │ │ ▸ Post-install │ │ │ └────────────────────────┘ │ ├────────────────────────────┤ │ [Hermes] [Machines] [Term] │ └────────────────────────────┘ ``` Cette partie doit produire une spec dédiée : breakpoints, écrans, composants, interactions tactiles, gestion terminal et validations. ### Paramètres Docker par machine - roots Compose ; - profondeur de scan ; - stacks validés ; - stacks ignorés ; - mode prune ; - dernier scan ; - erreurs. ### Paramètres scripts d'installation Catalogue global de scripts réutilisables : ```text Paramètres └─ Scripts d’installation ├─ Docker officiel Debian ├─ Rust via rustup ├─ Node.js via nvm / NodeSource ├─ Python uv ├─ PlatformIO / ESP ├─ Personnalisation terminal ├─ Script perso domotique └─ ... ``` Chaque script doit afficher : - nom ; - catégorie ; - source ; - statut enabled/draft ; - variables attendues ; - niveau de risque ; - preview ; - dernière utilisation ; - JSON retour attendu. ### Paramètres affichage tuile - sections ouvertes par défaut ou non ; - densité compacte/confort ; - affichage des chemins complets ou courts ; - seuil de fraîcheur d'une analyse APT/Docker ; - comportement expanded full-width. --- ## 10. JSON et intégration API Même si cette tâche est frontend, le design doit décrire les données nécessaires. Chaque interrogation/action affichée dans la tuile doit correspondre à un échange JSON : - snapshot machine ; - snapshot OS/profil machine ; - snapshot hardware ; - snapshot métriques simples ; - snapshot APT ; - snapshot Docker ; - manifeste post-install ; - preview template ; - résultat d'exécution ; - erreurs structurées. - messages importants extraits des logs : warnings, dépréciations, évolutions futures, erreurs ; - références de rapport/log consultables. Le frontend ne doit jamais parser du log brut pour décider l'état d'une tuile. Il consomme le JSON canonique produit par la webapp/backend. Hermes/MCP ne reçoivent que le JSON réduit, jamais de secret. --- ## 11. Livrables attendus À produire sous `docs/` : 1. Design détaillé des tuiles machine. 2. États UI : compact, Docker ouvert, Post-install ouvert, erreur, running, machine sans Docker. 3. ASCII draw final + maquettes textuelles. 4. Liste des composants design system à utiliser. 5. Liste des icônes nécessaires et alias à ajouter au ui-kit. 6. Spécification favicon, icônes smartphone et assets PWA. 7. Vue globale page web : header, volet Hermes, centre, terminal, footer. 8. Vue globale onglet paramètres. 9. Spécification des paramètres frontend. 10. Contrats JSON nécessaires côté frontend. 11. Spec UX du volet Hermes : discussion, copier-coller, blocs de commandes, cartes de validation. 12. Spec UX du terminal droit : exécution suivie vs SSH interactif. 13. Découpage en sous-jalons d'implémentation. --- ## 12. Définition de terminé - Le design respecte le design system. - La tuile répond aux besoins APT, Docker et Post-install. - Les sections s'ouvrent sans masquer la zone centrale ni le terminal. - Les actions dangereuses sont clairement identifiées. - Les champs dynamiques post-install sont spécifiés. - Les vues globales dashboard et paramètres sont spécifiées. - Les besoins favicon, icônes smartphone et icônes SVG spécifiques sont listés. - Les échanges JSON nécessaires sont listés. - Le volet Hermes permet une discussion lisible, des messages copiables et des commandes copiables sans exécution automatique. - Le terminal SSH interactif est distingué du terminal de logs d'exécution et reste désactivable. - Aucun code de production n'est livré pendant cette mission de design. --- ## 13. Technos à utiliser — checklist - [ ] React + TypeScript. - [ ] Vite pour build frontend. - [ ] Design system `Gruvbox seventies`. - [ ] CSS variables uniquement, dark/light. - [ ] `ui-kit` existant avant création de composants. - [ ] Font Awesome via `Icon`/`IconButton`. - [ ] SVG custom uniquement pour icônes spécifiques validées dans `consigne_icon.md`. - [ ] xterm.js pour terminal web. - [ ] WebSocket/SSE pour flux live. - [ ] Web App Manifest + favicon/app icons si PWA prévue. - [ ] API backend uniquement, pas de parsing log brut côté client. ## 14. URLs utiles - React TypeScript : https://react.dev/learn/typescript - Vite : https://vite.dev/guide/ - Font Awesome : https://fontawesome.com/docs - xterm.js : https://xtermjs.org/ - MDN Web App Manifest : https://developer.mozilla.org/en-US/docs/Web/Manifest - MDN Responsive design : https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/CSS_layout/Responsive_Design - MDN WebSocket : https://developer.mozilla.org/en-US/docs/Web/API/WebSocket - MDN Server-sent events : https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events ## 15. Liens parent/enfant avec les autres tâches - Parents : - `tache1.9.md` pour paramètres frontend et état courant. - `tache2.md` pour contrats JSON APT/Docker. - `tache4.md` pour profils/scripts à afficher. - `tache5.md` pour API et WebSocket/SSE. - Enfants : - `tache6.md` pour volet Hermes. - `tache7.md` pour métriques/footer/mobile. - `tache8.md` pour reprise partielle en app Rust/GNOME. - `consigne_icon.md` pour création icônes. - Validation : `validation_tache3.md`.