gilles
0fbca06d3d
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>
147 lines
6.8 KiB
Markdown
147 lines
6.8 KiB
Markdown
# Protocole de validation — Tâche 8 (app locale Rust/GNOME)
|
||
|
||
> **Type** : grille de validation. Utilisée après la mission décrite dans `tache8.md`.
|
||
> **But** : vérifier que l'app locale future est conçue comme client API sûr, sans dupliquer la logique SSH/backend.
|
||
> **Gate validé par l'utilisateur le 2026-06-05** : le développement Rust peut démarrer.
|
||
> **Rappel** : l'app locale reste cliente du backend et ne remplace pas la webapp serveur.
|
||
|
||
---
|
||
|
||
## 0. Quand lancer cette validation
|
||
|
||
- La mission `tache8.md` avance par incréments.
|
||
- Les choix techniques Rust/GNOME restent argumentés au fur et à mesure.
|
||
- Le contrat API attendu est défini avant chaque intégration UI.
|
||
|
||
---
|
||
|
||
## 1. Discipline & périmètre
|
||
|
||
- [x] Le code Rust créé reste dans le périmètre `app_rust/system-update-gnome`.
|
||
- [x] L'app locale reste future, pas bloquante pour la webapp MVP.
|
||
- [x] L'app ne fait pas de SSH direct au MVP.
|
||
- [x] Les credentials machines restent côté backend.
|
||
- [x] Le design réutilise les contrats JSON existants.
|
||
|
||
---
|
||
|
||
## 2. Architecture
|
||
|
||
- [x] Rust + GTK4/libadwaita étudié.
|
||
- [x] Alternatives comme `relm4`/`iced` comparées si utile.
|
||
- [x] Client HTTP/WebSocket défini.
|
||
- [x] Cache local lecture seule défini.
|
||
- [x] Notifications desktop prévues.
|
||
- [x] Configuration serveur/token prévue.
|
||
|
||
---
|
||
|
||
## 3. API commune
|
||
|
||
- [x] `/api/capabilities`.
|
||
- [x] Machines/state/hardware/metrics.
|
||
- [x] Snapshots/executions/reports/messages.
|
||
- [x] Actions via backend.
|
||
- [x] Live output via WS/SSE.
|
||
- [x] Settings si scope admin.
|
||
- [~] Erreurs structurées et version API. *(jalons 8.1/8.2 non encore couverts)*
|
||
|
||
---
|
||
|
||
## 4. Sécurité
|
||
|
||
- [~] Token stocké via trousseau local. *(keyring prévu dans tache8.md §6 et plan_8.md jalon 8.3 ; pas encore implémenté)*
|
||
- [x] Token jamais stocké en clair. *(README et règles explicites ; token lu en env var dans le scaffold — acceptable à ce stade)*
|
||
- [x] Scopes de token définis. *(tache1.9.md api_clients + tache8.md §6)*
|
||
- [x] Révocation/rotation prévues. *(tache1.9.md api_clients : champ revoked_at, status)*
|
||
- [x] Actions dangereuses confirmées dans l'app. *(tache8.md §6)*
|
||
- [x] Logs locaux sans secret. *(tache8.md §6 ; pas de log de token dans le scaffold)*
|
||
- [~] HTTPS/certificats traités. *(api.rs rejette explicitement https:// avec un test nommé "until_tls_client_is_added" — accepté comme dette connue et documentée)*
|
||
|
||
---
|
||
|
||
## 5. UX native
|
||
|
||
- [x] Layout GNOME HeaderBar/Sidebar spécifié.
|
||
- [x] Tuiles machine adaptées.
|
||
- [x] Détail machine avec onglets.
|
||
- [x] Paramètres natifs spécifiés.
|
||
- [x] Thème Gruvbox via tokens GNOME.
|
||
- [x] Différences webapp/app locale assumées.
|
||
|
||
---
|
||
|
||
## 6. Cohérence avec objectif final webserver Docker Compose
|
||
|
||
- [x] L'app locale consomme le serveur Docker Compose, elle ne le remplace pas.
|
||
- [x] Le backend reste la source de vérité.
|
||
- [x] La webapp reste utilisable sans app locale.
|
||
- [x] Les API nécessaires sont compatibles avec un backend containerisé.
|
||
|
||
---
|
||
|
||
## 7. Verdict
|
||
|
||
**🟡 Accepté avec réserves**
|
||
|
||
Le premier incrément (jalon 8.0 et scaffold 8.3 partiel) est cohérent, bien périmétré et non bloquant pour le MVP web. Les réserves ci-dessous sont attendues et planifiées pour les jalons 8.1–8.3 ; elles ne remettent pas en cause la direction.
|
||
|
||
---
|
||
|
||
## 8. Notes de validation
|
||
|
||
> 2026-06-05 — revue effectuée par l'orchestrateur (validation déléguée).
|
||
|
||
### Résumé de la revue
|
||
|
||
**Périmètre scaffold**
|
||
|
||
Le dossier `app_rust/system-update-gnome/` contient uniquement : `Cargo.toml`, `Cargo.lock`, `.gitignore`, `README.md`, `src/main.rs`, `src/api.rs`, `src/config.rs`. Le dossier `target/` est ignoré par `.gitignore`. Aucun fichier Rust n'a été créé en dehors de ce périmètre. Conforme.
|
||
|
||
Le `Cargo.toml` déclare `edition = "2024"` et n'a aucune dépendance externe (`[dependencies]` vide), ce qui est cohérent avec la priorité « client API avant UI GTK » et permet un premier build vérifiable sans accès réseau.
|
||
|
||
**Contrat API / capabilities**
|
||
|
||
`GET /api/capabilities` est exposé par le backend (`server/routes/index.ts`), généré par `server/services/capabilities.ts`, typé dans `shared/types.ts` (`ServerCapabilities`). Le client Rust (`api.rs`) consomme cet endpoint. La chaîne est complète pour le jalon 8.0.
|
||
|
||
**SSH direct**
|
||
|
||
Aucune référence SSH dans le code Rust. Le README rappelle explicitement la règle. Conforme.
|
||
|
||
**Credentials machines**
|
||
|
||
Le scaffold ne manipule que l'URL serveur et un token API optionnel. Pas de credential machine. Conforme.
|
||
|
||
**Sécurité token**
|
||
|
||
Le token est lu depuis la variable d'environnement `SYSTEM_UPDATE_TOKEN` ou la CLI `--token`, jamais écrit dans un fichier. La crate `keyring` est bien listée dans `tache8.md §4` et dans la checklist §11 ; son implémentation est planifiée au jalon 8.3. Acceptable à ce stade ; à réaliser avant tout déploiement.
|
||
|
||
**HTTPS**
|
||
|
||
Le client HTTP artisanal (`std::net::TcpStream`) supporte uniquement `http://` et rejette `https://` avec un test unitaire explicitement nommé `rejects_https_until_tls_client_is_added`. C'est une dette assumée et documentée. À traiter (crate `rustls` ou `reqwest` avec TLS) avant toute utilisation hors localhost.
|
||
|
||
**Erreurs structurées / version API**
|
||
|
||
Non encore couverts dans le code Rust (jalons 8.1/8.2). La structure de base existe côté backend (`apiVersion: "1"` dans capabilities). La tache8.md §5 liste les besoins. Réserve mineure.
|
||
|
||
**Cohérence inter-tâches**
|
||
|
||
- `tache1.9.md` : table `api_clients` avec `token_hash`, `scopes_json`, `status`, `revoked_at` — cohérente avec le modèle de sécurité de tache8.md.
|
||
- `tache5.md` : `GET /api/capabilities` listé parmi les endpoints API ; cohérent.
|
||
- `design_system/tokens/tokens.gnome.css` : fichier présent, référencé dans tache8.md §4 et §11 ; le scaffold ne l'utilise pas encore (normal : UI GTK pas commencée).
|
||
- `tache7.md` : référencé pour sécurité token/cache/metrics — cohérent.
|
||
- L'app ne remplace pas la webapp, elle en est cliente. Conforme à l'objectif Docker Compose.
|
||
|
||
### Réserves (non bloquantes pour ce jalon)
|
||
|
||
1. **HTTPS/TLS** : à implémenter avant tout usage hors localhost (jalon 8.3). La dette est documentée dans le code.
|
||
2. **Keyring** : le token n'est pas encore stocké via le trousseau système. À réaliser au jalon 8.3 avant toute distribution.
|
||
3. **Erreurs structurées et pagination** : jalons 8.1/8.2 non démarrés ; nécessaires avant l'UI GTK.
|
||
4. **Choix GTK4 direct vs relm4** : case du gate cochée (comparaison mentionnée dans tache8.md) mais la décision formelle est reportée au démarrage du jalon 8.4 (normal à ce stade).
|
||
|
||
### Coquilles corrigées
|
||
|
||
Dans `plan_8.md` :
|
||
- Sections 5 et 6 étaient inversées dans l'ordre de numérotation (section 6 apparaissait avant la section 5) : corrigé.
|
||
- Faute de conjugaison ligne 120 : « pour que tu commence le dev » → « pour que tu commences le dev » : corrigé.
|