v0.3.15-pre.006

crates/ksp-app-raw-transaction-ingest-desk/USAGE.md

@@ -1,5 +1,5 @@
 <!-- file: crates/ksp-app-raw-transaction-ingest-desk/USAGE.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Utilisation de `ksp-app-raw-transaction-ingest-desk`
 
@@ -11,22 +11,56 @@ Depuis la racine du workspace :
 (cd crates/ksp-app-raw-transaction-ingest-desk && cargo tauri dev)
 ```
 
+Tauri déclenche lui-même les hooks frontend configurés. Les scripts npm applicatifs de développement, contrôle ou build ne sont pas lancés directement par l'opérateur.
+
 Le runtime prépare les ressources Config nécessaires, charge le composite dédié, initialise Logging puis ouvre le shell desktop.
 
 ## 2. Vue Routes
 
-La vue Routes présente les routes logiques connues par l'application et leur état applicatif. La présence d'un identifiant de route dans l'interface ne constitue pas, à elle seule, une preuve de composabilité ou de disponibilité runtime ; l'état projeté par le backend reste l'autorité.
+La vue Routes charge un inventaire déterministe construit côté Rust depuis le composite Config validé. Le sélecteur présente les profils logiques du composite et la vue projette, pour chaque route V1 :
 
-Les URLs, tokens, metadata secrètes, handles Transport/Store/Worker et payloads RAW restent backend-only.
+```text
+route_id
+famille et label sûrs
+réseau logique lorsque résolu
+état Config
+selectable oui/non
+raison sûre lorsque la route est indisponible
+génération d'inventaire
+```
 
-## 3. Diagnostics
+`Configured` signifie uniquement que toutes les requirements Config nécessaires à la route sont cohérentes. Aucun probe réseau, aucune ouverture de Store et aucun Worker ne sont déclenchés par l'inventaire.
 
-La vue Diagnostics expose uniquement des informations techniques sûres nécessaires à l'exploitation du Desk, notamment l'identité de version, l'état du shell, la composition Config active, l'état Logging et les diagnostics projetés par codes/messages sûrs.
+Un refresh reconstruit l'inventaire depuis Config et publie une nouvelle génération. La sélection visuelle d'un profil ne choisit aucune URL ou ressource physique et ne démarre aucune acquisition.
+
+Les URLs, tokens, metadata secrètes, handles Transport/Store/Worker, URI Store, source keys et payloads RAW restent backend-only.
+
+## 3. Raisons d'indisponibilité
+
+Les reasons exposées sont des codes applicatifs bornés, par exemple :
+
+```text
+profile_unresolved
+network_mismatch
+missing_http_get_transaction
+missing_http_block_scan
+missing_ws_logs_capability
+missing_ws_block_capability
+missing_helius_transaction_capability
+missing_yellowstone_grpc
+missing_required_secret
+```
+
+Le texte arbitraire d'une erreur provider ou d'un secret Config n'est jamais projeté dans l'inventaire.
+
+## 4. Diagnostics
+
+La vue Diagnostics expose uniquement des informations techniques sûres nécessaires à l'exploitation du Desk, notamment l'identité de version, l'état du shell, la composition Config bootstrap, l'état Logging et la génération d'inventaire.
 
 Les diagnostics ne doivent pas exposer de credentials, d'URI Store, d'URL d'endpoint, de source key, de handle runtime ou de payload `RawTransaction`.
 
-## 4. Runtime packagé
+## 5. Runtime packagé
 
 Le build Tauri embarque les documents Config et schemas enregistrés. `ksp-config-lib` prépare ensuite la racine KSP user-writable sans embarquer `.env`.
 
-Les fichiers Config et les secrets restent administrés par les mécanismes Config KSP ; l'interface ne doit pas contourner cette ownership.
+Les fichiers Config et les secrets restent administrés par les mécanismes Config KSP ; l'interface ne contourne pas cette ownership.