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

6.8 KiB
Raw Blame History

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

  • Le code Rust créé reste dans le périmètre app_rust/system-update-gnome.
  • L'app locale reste future, pas bloquante pour la webapp MVP.
  • L'app ne fait pas de SSH direct au MVP.
  • Les credentials machines restent côté backend.
  • Le design réutilise les contrats JSON existants.

2. Architecture

  • Rust + GTK4/libadwaita étudié.
  • Alternatives comme relm4/iced comparées si utile.
  • Client HTTP/WebSocket défini.
  • Cache local lecture seule défini.
  • Notifications desktop prévues.
  • Configuration serveur/token prévue.

3. API commune

  • /api/capabilities.
  • Machines/state/hardware/metrics.
  • Snapshots/executions/reports/messages.
  • Actions via backend.
  • Live output via WS/SSE.
  • 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é)
  • Token jamais stocké en clair. (README et règles explicites ; token lu en env var dans le scaffold — acceptable à ce stade)
  • Scopes de token définis. (tache1.9.md api_clients + tache8.md §6)
  • Révocation/rotation prévues. (tache1.9.md api_clients : champ revoked_at, status)
  • Actions dangereuses confirmées dans l'app. (tache8.md §6)
  • 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

  • Layout GNOME HeaderBar/Sidebar spécifié.
  • Tuiles machine adaptées.
  • Détail machine avec onglets.
  • Paramètres natifs spécifiés.
  • Thème Gruvbox via tokens GNOME.
  • Différences webapp/app locale assumées.

6. Cohérence avec objectif final webserver Docker Compose

  • L'app locale consomme le serveur Docker Compose, elle ne le remplace pas.
  • Le backend reste la source de vérité.
  • La webapp reste utilisable sans app locale.
  • 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é.
Reference in New Issue View Git Blame Copy Permalink