gilles/system_update
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
08919752e3f1a21161ab98558411335c5b88649c
system_update/tache3.md
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

34 KiB
Raw Blame History

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 <Icon> / <IconButton>, 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 <Popup>.

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

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.

┌──────────────────────────────────────────────────────────────────────────────┐
│ 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 :

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 :

debian · vm · amd64 · qemu
proxmox · physical · zfs
raspios · raspberry_pi · arm64

État compact

┌────────────────────────────────────────────────────────────────────┐
│ ● 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

┌────────────────────────────────────────────────────────────────────┐
│ ● 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é

┌────────────────────────────────────────────────────────────────────┐
│ ● 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é

┌────────────────────────────────────────────────────────────────────┐
│ ● 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 :

┌────────────────────────────────────────────────────────────────────┐
│ 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.

┌──────────────────────────────────────────────────────────────────────────────┐
│ 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 :

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 :

┌────────────────────────────┐
│ 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 :

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

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.
Reference in New Issue View Git Blame Copy Permalink