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

836 lines
34 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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`.
Reference in New Issue View Git Blame Copy Permalink