v0.2.6-rel.001

docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->
 
 # Applications, services, scenarios et control plane
 
@@ -22,7 +22,7 @@ Les décisions portent sur :
 - futur IPC ;
 - futur orchestrateur/global app uniquement comme idées à conserver.
 
-# Principe général des applications
+## Principe général des applications
 
 Une application KSP est une interface et une couche de composition.
 
@@ -47,13 +47,13 @@ Elle ne doit pas réimplémenter :
 - lifecycle interne d'un worker/job ;
 - logique de pipeline réutilisable.
 
-# Applications de validation par couche
+## Applications de validation par couche
 
 KSP peut ajouter une petite application spécialisée à la fin d'une couche RAW ou CORE lorsque cela permet de valider et exploiter réellement la couche avant de passer à la suivante. Ces applications lisent les contrats KSP et ne recopient pas les processors dans Tauri.
 
 À partir des vertical slices Program, les applications restent attachées aux besoins réels : demos de scenarios pour l'exécution et Market Desk pour les projections de marché.
 
-# Priorité aux applications spécialisées
+## Priorité aux applications spécialisées
 
 KSP ne planifie pas actuellement de cockpit desktop global.
 
@@ -85,7 +85,7 @@ Les noms exacts des managers workers seront décidés avec les premières applic
 
 Une future application globale de contrôle/exploitation est considérée comme un produit futur attendu, mais elle n'est pas un livrable du roadmap actuel et ne doit pas influencer prématurément les contrats.
 
-# Applications spécialisées et dépendances directes
+## Applications spécialisées et dépendances directes
 
 Une application spécialisée peut dépendre directement de la bibliothèque KSP correspondant à sa responsabilité.
 
@@ -105,7 +105,7 @@ ksp-app-store-desk
 
 Les couches N1–N4 expriment des responsabilités et une direction de dépendances ; elles n'imposent pas de traverser toutes les couches intermédiaires.
 
-# Tauri
+## Tauri
 
 Les applications desktop Tauri restent des adapters/interfaces.
 
@@ -127,7 +127,7 @@ Une application Tauri peut devoir intégrer un plugin/framework de tracing, mais
 
 En distribution, une application Tauri KSP ne dépend pas du checkout source ni du CWD du launcher. Les resources Config/Schemas nécessaires sont embarquées dans le bundle ; Tauri résout leur racine immutable et `ksp-config-lib` prépare une racine KSP user-writable commune avant le bootstrap applicatif. Les Config utilisateur existantes sont conservées, les schemas package-owned sont resynchronisés et `.env` reste une ressource locale writable jamais embarquée. Cette adaptation de packaging ne transfère ni ownership Config ni accès filesystem au frontend.
 
-# Workers comme services indépendants
+## Workers comme services indépendants
 
 Les workers KSP doivent pouvoir fonctionner comme **services/processus indépendants**.
 
@@ -143,7 +143,7 @@ Les workers ne forment pas un pipeline process-to-process couplé.
 
 Ils synchronisent leur data plane via les niveaux durables du Store.
 
-## Packaging préféré
+### Packaging préféré
 
 Pour éviter de séparer artificiellement logique réutilisable et executable dans deux packages lorsqu'il n'y a pas encore de besoin, la direction préférée est :
 
@@ -171,7 +171,7 @@ Il ne duplique pas le pipeline ni la logique de worker contenue dans la cible bi
 
 Une séparation future en packages distincts `*-lib` / executable n'est introduite que si un besoin concret le justifie.
 
-# Responsabilité du binaire worker
+## Responsabilité du binaire worker
 
 Le binaire autonome peut notamment :
 
@@ -186,7 +186,7 @@ Le binaire autonome peut notamment :
 
 Il ne contient pas de logique de processing qui ne serait pas réutilisable depuis la bibliothèque worker.
 
-# Indépendance des workers
+## Indépendance des workers
 
 Aucun worker ne dépend directement d'un autre worker concret.
 
@@ -222,7 +222,7 @@ Les notifications accélèrent le réveil mais ne créent pas une connexion fonc
 
 Cette indépendance permet arrêt, restart ou mise à jour d'un worker sans arrêter volontairement les autres.
 
-# Ordre global de démarrage
+## Ordre global de démarrage
 
 Aucun ordre global strict de démarrage n'est figé dans cette prerelease.
 
@@ -234,11 +234,11 @@ La robustesse recherchée est :
 
 Un futur manager/orchestrateur pourra choisir un ordre pratique de démarrage/arrêt, mais cette policy n'est pas inscrite dans les contrats worker.
 
-# Data plane et control plane
+## Data plane et control plane
 
 KSP distingue explicitement deux plans.
 
-## Data plane
+### Data plane
 
 Le data plane transporte/persiste les données Solana et les résultats de processing :
 
@@ -253,7 +253,7 @@ avec notifications de données persistées comme wake-up.
 
 Les workers ne s'échangent pas leurs payloads via le control plane.
 
-## Control plane
+### Control plane
 
 Le control plane sert à :
 
@@ -276,7 +276,7 @@ future manager/orchestrator
 
 Le control plane n'est pas le data plane.
 
-# `ksp-worker-control-lib`
+## `ksp-worker-control-lib`
 
 `ksp-worker-control-lib` reste la bibliothèque de gouvernance réutilisable au-dessus de `ksp-worker-api`.
 
@@ -297,7 +297,7 @@ Elle ne connaît pas :
 - Tauri ;
 - les types propriétaires d'un worker concret au-delà des contrats publics nécessaires.
 
-# Worker local et worker distant
+## Worker local et worker distant
 
 La sémantique de `ksp-worker-api` ne doit pas dépendre du fait qu'un worker soit appelé :
 
@@ -323,7 +323,7 @@ Conceptuellement :
 
 Le type exact de proxy/transport n'est pas défini maintenant.
 
-# IPC
+## IPC
 
 Le besoin d'IPC existe naturellement dès qu'une app manager doit piloter un worker autonome.
 
@@ -345,7 +345,7 @@ Le premier manager/service réel devra choisir un mécanisme IPC adapté et pour
 
 Le choix du mécanisme exact est reporté à la release fonctionnelle concernée.
 
-# Jobs
+## Jobs
 
 Les jobs restent distincts des workers.
 
@@ -357,7 +357,7 @@ Le fait qu'un worker soit un process/service indépendant ne force pas les jobs
 
 Le packaging/exécution des jobs sera déterminé avec les premiers jobs réels.
 
-# Scenarios : logique dans la bibliothèque
+## Scenarios : logique dans la bibliothèque
 
 La source de vérité d'un scenario est toujours :
 
@@ -387,7 +387,7 @@ Elle peut être consommée par :
 - futur CLI/tool ;
 - CI/integration environment lorsque pertinent.
 
-# Pas de `ksp-scenario-api` actuellement
+## Pas de `ksp-scenario-api` actuellement
 
 Aucun trait universel de scenario n'est imposé.
 
@@ -395,7 +395,7 @@ Les premières implementations utilisent une norme documentaire commune définie
 
 Une API commune ne sera créée que si plusieurs scenarios réels révèlent un contrat réutilisable qui apporte plus que des conventions.
 
-# Applications desktop demo de scenarios
+## Applications desktop demo de scenarios
 
 Convention retenue :
 
@@ -429,7 +429,7 @@ KSP capabilities
 
 L'app ne construit pas un scenario parallèle.
 
-# Scenarios et execution policy
+## Scenarios et execution policy
 
 Une crate scenario peut fournir une implémentation de `ksp-execution-policy-api` adaptée à son environnement.
 
@@ -443,7 +443,7 @@ Exemple Devnet :
 
 Cette policy appartient au scenario, pas à `ksp-program-lib`.
 
-# Applications worker spécialisées
+## Applications worker spécialisées
 
 Une application spécialisée de worker peut être créée lorsqu'elle est utile pour développer/tester/exploiter ce service.
 
@@ -466,7 +466,7 @@ independent worker service
 
 La nomenclature précise des apps sera fixée à la première implémentation pour éviter de multiplier prématurément les packages.
 
-# Configuration desired vs effective
+## Configuration desired vs effective
 
 La configuration persistée/résolue et la configuration effectivement appliquée sont deux faits distincts.
 
@@ -483,7 +483,7 @@ worker status
 
 Une app spécialisée peut éditer une configuration puis demander son application, mais ne doit pas considérer l'écriture du document comme la preuve que le worker l'a appliquée.
 
-# Market Desk progressive
+## Market Desk progressive
 
 Après les groupes Meteora/Raydium/Pump/Orca, KSP prévoit une première application spécialisée candidate `ksp-app-market-desk`.
 
@@ -493,7 +493,7 @@ Après Jupiter/OKX, la même application est enrichie avec routes, legs, DEX imp
 
 Les OHLC sont matérialisés dans SPECIALIZED et consommés par l'application; ils ne sont pas recalculés à partir de tout l'historique lors de chaque rendu.
 
-# Future orchestrator
+## Future orchestrator
 
 Un orchestrateur global pourra devenir utile lorsque plusieurs services/managers/jobs devront être coordonnés.
 
@@ -509,7 +509,7 @@ Sa responsabilité éventuelle devra rester control plane :
 
 Il ne doit jamais devenir un nouveau propriétaire de Program, Store, transport ou materialization.
 
-# Future global application
+## Future global application
 
 Une application globale d'exploitation/contrôle est attendue à terme.
 
@@ -528,7 +528,7 @@ Avant elle, KSP doit disposer d'applications spécialisées et demos permettant
 
 Son nom et son scope ne sont pas définis.
 
-# Graphe synthétique
+## Graphe synthétique
 
 ```text
 specialized desktop app
@@ -551,7 +551,7 @@ transport -> RAW -> CORE -> DECODE -> SPECIALIZED
 
 Aucun payload de processing n'a besoin de transiter via l'UI/control plane.
 
-# Questions laissées ouvertes
+## Questions laissées ouvertes
 
 Les premières implementations concernées devront fixer :