v0.3.8-pre.013-fix.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: 10 -->
+<!-- version: 11 -->
 
 # Applications, services, scenarios et control plane
 
@@ -121,6 +121,15 @@ ksp-app-store-desk
     -> ksp-core-lib
     -> ksp-logging-lib
     -> ksp-store-lib
+
+ksp-app-raw-transaction-ingest-desk
+    -> ksp-config-lib
+    -> ksp-core-lib
+    -> ksp-logging-lib
+    -> ksp-worker-api
+    -> ksp-worker-raw-transaction-ingest-lib
+    -> ksp-onchain-transport-lib
+    -> ksp-store-lib
 ```
 
 `ksp-store-lib` réexporte la surface Store commune nécessaire aux applications ; une app ne dépend pas directement de `ksp-store-api` uniquement pour atteindre les modèles/capabilities, et ne dépend jamais d'une crate backend concrète.
@@ -129,6 +138,8 @@ Backfill Desk suit exactement cette règle : elle ouvre Store via `ksp-store-lib
 
 Store Desk suit la même frontière sans Transport : Config sélectionne Logging + Store, `ksp-store-lib` fournit health, reads et inspection backend-neutral, et le Store ouvert reste côté Rust. Les DataTables frontend consomment des summaries server-side et counts exacts ; les détails chargent une seule entité avec preview bornée. Aucun command d'écriture, SQL, cursor opaque, backend physique ou secret Store n'est exposé à Tauri/TypeScript.
 
+Raw Transaction Ingest Desk est la surface spécialisée de contrôle prévue après le premier worker concret. Elle peut sélectionner une ou plusieurs stratégies compatibles et afficher lifecycle/health/rates/backpressure/reconnect/recovery, mais la sélection d'une source ne déplace ni discovery, ni hydration, ni déduplication, ni provenance dans l'application. Les endpoints/credentials restent Config/Transport-owned et le détail des entités persistées reste Store Desk-owned.
+
 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
@@ -184,14 +195,17 @@ package ksp-worker-<role>
 Exemples conceptuels :
 
 ```text
-ksp-worker-raw-retriever
+ksp-worker-raw-transaction-ingest-lib   # premier runtime worker réutilisable retenu
+future autonomous raw-ingest binary     # seulement si un besoin de service séparé le justifie
 future CORE worker
 future group-specific DECODE/SPECIALIZED workers when justified
 ```
 
+Le premier worker RAW est volontairement prévu comme bibliothèque réutilisable afin qu'une Desk ou un futur host puisse le construire sans dupliquer sa logique. Un binaire autonome n'est pas créé par convention seule ; s'il apparaît, il reste un host mince au-dessus de la même bibliothèque et de `ksp-worker-api`.
+
 RAW et CORE reçoivent leurs workers à la fin de leur couche respective. Les workers DECODE/SPECIALIZED ne sont plus tous anticipés comme une chaîne globale fixe : leur granularité doit émerger des premiers vertical slices Program.
 
-Le binaire doit rester mince.
+Le binaire, lorsqu'il existe, doit rester mince.
 
 Il ne duplique pas le pipeline ni la logique de worker contenue dans la cible bibliothèque du même package.
 
@@ -469,26 +483,17 @@ Cette policy appartient au scenario, pas à `ksp-program-lib`.
 
 ## 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.
-
-Elle doit passer par le control plane et non modifier directement l'état interne du worker dans PostgreSQL.
-
-Conceptuellement :
+Une application spécialisée de worker peut être créée lorsqu'elle est utile pour développer/tester/exploiter ce service. La première application retenue est :
 
 ```text
-ksp-app-worker-<role>-desk
-        |
-        v
-ksp-worker-control-lib
-        |
-        v
-worker-api / remote proxy
-        |
-        v
-independent worker service
+ksp-app-raw-transaction-ingest-desk
 ```
 
-La nomenclature précise des apps sera fixée à la première implémentation pour éviter de multiplier prématurément les packages.
+Elle ne modifie jamais directement l'état interne du worker dans PostgreSQL. Elle passe par les contrats Worker et par la composition Rust propriétaire des ressources.
+
+Le premier déploiement peut piloter `ksp-worker-raw-transaction-ingest-lib` in-process si cela reste le choix le plus simple et le plus sûr. La sémantique de `ksp-worker-api` doit néanmoins rester compatible avec un futur proxy vers un worker autonome ; l'IPC/remote control ne doit pas être anticipé artificiellement avant besoin réel.
+
+La Desk RAW Transaction doit laisser choisir **une ou plusieurs sources/méthodes** parmi les capabilities effectivement configurées/admissibles par `0.3.10`, et superviser leur état sans dupliquer discovery/hydration/déduplication/recovery dans Tauri. Store Desk reste la surface d'inspection détaillée des RAW persistés.
 
 ## Configuration desired vs effective