gilles/system_update
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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>
This commit is contained in:
gilles soulier
2026-06-05 19:50:25 +02:00
parent f9ce991ec5
commit 0fbca06d3d
39 changed files with 11916 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tache3.md
+835
View File
@@ -0,0 +1,835 @@
# 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](/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`.