v0.3.15-pre.017

Cargo.toml

@@ -1,12 +1,12 @@
 # file: Cargo.toml
-# version: 634
+# version: 635
 
 [workspace]
 resolver = "3"
 members = ["crates/ksp-app-backfill-desk", "crates/ksp-app-config-desk", "crates/ksp-app-raw-transaction-ingest-desk", "crates/ksp-app-solprices-desk", "crates/ksp-app-store-desk", "crates/ksp-app-wallet-desk", "crates/ksp-config-lib", "crates/ksp-core-lib", "crates/ksp-interface-lib", "crates/ksp-job-api", "crates/ksp-job-backfill-lib", "crates/ksp-logging-lib", "crates/ksp-offchain-transport-lib", "crates/ksp-onchain-transport-lib", "crates/ksp-program-api", "crates/ksp-raw-transaction-lib", "crates/ksp-store-api", "crates/ksp-store-lib", "crates/ksp-store-postgres-lib", "crates/ksp-wallet-lib", "crates/ksp-worker-api", "crates/ksp-worker-raw-transaction-ingest-lib"]
 
 [workspace.package]
-version = "0.3.15-pre.16"
+version = "0.3.15-pre.17"
 edition = "2024"
 license = "MIT"
 repository = "https://git.sasedev.com/Sasedev/khadhroony-solana-project"

README.md

@@ -1,5 +1,5 @@
 <!-- file: README.md -->
-<!-- version: 14 -->
+<!-- version: 15 -->
 
 # Khadhroony Solana Project
 
@@ -57,7 +57,9 @@ La couche RAW dispose d'une façade Store backend-neutral et d'un premier job hi
 
 `ksp-worker-api` fournit désormais la fondation générique des services continus : identité Worker, lifecycle borné, health/activity, intention de stop coopératif et observation latest-value. Cette API reste Core-only, runtime-neutral et sans connaissance Solana, Transport, Store ou Job. Elle ne démarre ni n'arrête elle-même un runtime concret.
 
-`ksp-worker-raw-transaction-ingest-lib` est le premier Worker concret distinct du Job Backfill. Il conserve sa fondation Start/Stop, admission bornée, Common RAW, Store backend-neutral, shutdown borné et snapshots latest-value. Ses sources productives couvrent maintenant Yellowstone + hydration HTTP `getTransaction`, Standard WS `logsSubscribe` + hydration, Standard WS `blockSubscribe` RAW-direct, Helius `transactionSubscribe` + hydration et Solana HTTP live block polling. Le polling HTTP démarre au `getSlot` observé du run, découvre uniquement les blocs live via `getBlocksWithLimit` puis matérialise les slots listés via `getBlock observed`; il n'est jamais utilisé comme Backfill implicite. Les signaux hydratés de même `(network, signature, commitment)` convergent vers le même coordinator, tandis que les voies block RAW-direct passent par la même admission Common RAW. Le reconnect/replay reste propriétaire de Transport, la frontier de traitement reste run-local et un gap de rétention prouvé provoque un fault au lieu de lancer une campagne historique. `ksp-job-backfill-lib` conserve son rôle historique paramétré et borné ; les deux producteurs restent indépendants et convergent uniquement vers les mêmes contrats RAW/Store.
+`ksp-worker-raw-transaction-ingest-lib` est le premier Worker concret distinct du Job Backfill. Il conserve sa fondation Start/Stop, admission bornée, Common RAW, Store backend-neutral, shutdown borné et snapshots latest-value. Ses cinq familles productives couvrent Yellowstone, Standard WS `logsSubscribe`, Standard WS `blockSubscribe`, Helius `transactionSubscribe` et Solana HTTP live block polling. Les signaux transactionnels Yellowstone/Standard Logs/Helius utilisent l'hydration HTTP `getTransaction`, tandis que le mode Yellowstone Block utilisé par la route Mainnet du Desk emploie le bloc gRPC comme trigger puis réconcilie le slot par HTTP `getBlock` Full/Base64 avec concurrence bornée. Standard Block et HTTP Block Polling qualifient directement leurs transactions Legacy/V0/V1 vers Common RAW. Les queues restent bornées ; une saturation durable de la livraison Yellowstone applique désormais une backpressure asynchrone au stream gRPC au lieu de produire un overflow local. Le Store accepte aussi l'exception étroite déjà prouvée où un canonique complet reçoit ensuite une observation identique hors `logMessages` explicitement tronqués ; le canonique complet est conservé et les autres divergences restent fail-closed en `0.3.15`. Le reconnect/replay reste propriétaire de Transport, la frontier de traitement reste run-local et un gap de rétention prouvé provoque un fault au lieu de lancer une campagne historique. `ksp-job-backfill-lib` conserve son rôle historique paramétré et borné ; les deux producteurs restent indépendants et convergent uniquement vers les mêmes contrats RAW/Store.
+
+`ksp-app-raw-transaction-ingest-desk` compose et supervise ces routes live sans déplacer leurs responsabilités dans l'UI. Les profils applicatifs sont réseau-centriques, plusieurs routes d'un même réseau peuvent partager un Store tout en gardant des Workers indépendants, et le monitoring latest-value expose lifecycle, health, activité, persistence, reconnect/replay, continuité, gaps et repair sans URL, secret, payload RAW ou handle physique. Le gate `0.3.15` valide notamment le fonctionnement parallèle Mainnet de Yellowstone Block + HTTP `getBlock` et HTTP Block Polling, la fermeture coopérative de Yellowstone après half-close et le build Tauri Linux de la Desk.
 
 ## Points d'entrée
 

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

@@ -1,5 +1,5 @@
 <!-- file: crates/ksp-app-raw-transaction-ingest-desk/README.md -->
-<!-- version: 14 -->
+<!-- version: 15 -->
 
 # `ksp-app-raw-transaction-ingest-desk`
 
@@ -54,7 +54,9 @@ Les profils standard publics committés déclarent `Block` en plus de `Logs`; `s
 
 Une route `Configured` est uniquement **composable depuis Config**. La disponibilité réelle du Store et du Worker est revalidée lors du Start avant publication de l'accusé runtime. Le backend relaie désormais chaque Worker actif par un snapshot latest-value sûr : lifecycle, health, activity, admission/persistence, backpressure, reconnect/replay, continuité, gaps et repair. Les mises à jour sont coalescées côté backend à une cadence bornée de `500 ms` maximum par route, émises via l'événement Tauri `ksp-raw-ingest-route-status` et peuvent être resynchronisées avec `get_route_monitoring`. Les compteurs et slots `u64` sont projetés en texte décimal afin de rester exacts côté JavaScript. Le frontend consomme maintenant ce flux en temps réel et via resynchronisation explicite : chaque route affiche lifecycle/health/activity, persisted/source/gap summaries et ouvre un détail complet pipeline/persistence, reconnect/replay, continuité, gaps et repair. Les événements monitoring mettent aussi à jour les états actifs/terminaux afin que le sélecteur réseau et le Store partagé suivent le lifecycle réellement publié par le Worker. Les snapshots steady-state patchent les champs de carte en place ; la reconstruction des contrôles Start/Stop est réservée aux changements de lifecycle, afin de préserver la réactivité des interactions.
 
-Pour `yellowstone-hydrated`, la stratégie Mainnet n'effectue plus un `getTransaction` par notification transactionnelle. Le Desk construit un abonnement Yellowstone Block léger ; chaque bloc observé déclenche une reconciliation HTTP `getBlock` Full/Base64 sur le même réseau. Le profil `publicnode_mainnet` expose un pool HTTP logique `default` contenant PublicNode et le RPC public Solana comme fallback de même priorité. Le pool conserve les limites propres à chaque endpoint, son health/cooldown et son round-robin interne. La reconciliation Yellowstone tolère un décalage bref entre le gRPC et les RPC HTTP grâce à un retry borné et interruptible par Stop. Le chemin protobuf -> RAW direct reste différé tant que la canonicalisation exacte du meta n'est pas prouvée pour toutes les formes supportées.
+Pour `yellowstone-hydrated`, la stratégie Mainnet n'effectue plus un `getTransaction` par notification transactionnelle. Le Desk construit un abonnement Yellowstone Block léger ; chaque bloc observé déclenche une reconciliation HTTP `getBlock` Full/Base64 sur le même réseau. Le profil `publicnode_mainnet` expose un pool HTTP logique `default` contenant PublicNode et le RPC public Solana comme fallback de même priorité. Le pool conserve les limites propres à chaque endpoint, son health/cooldown et son round-robin interne. La reconciliation Yellowstone tolère un décalage bref entre le gRPC et les RPC HTTP grâce à un retry borné et interruptible par Stop. Les slots gRPC et hydrations `getBlock` restent bornés ; lorsqu'un consumer est saturé, la queue Transport attend de la capacité et propage la backpressure au stream au lieu de produire un `grpc_backpressure_overflow` local. Après un Stop explicite, un status provider reçu pendant le half-close ne remplace plus la fermeture coopérative ; un status observé pendant une session active reste soumis au reconnect/failure normal. Le chemin protobuf -> RAW direct reste différé tant que la canonicalisation exacte du meta n'est pas prouvée pour toutes les formes supportées.
+
+La convergence Store de `0.3.15` conserve également une exception volontairement étroite : si un canonique complet existe déjà et qu'une route apporte le même RAW hors `logMessages` avec un marqueur exact `Log truncated` après un préfixe identique, l'observation moins complète est acceptée sans remplacer le canonique ni fault la route. Le sens inverse et toute divergence non prouvée restent des conflits terminaux dans cette version ; la gestion durable de variantes/résolutions appartient à `0.3.16`.
 
 ## Ports de développement
 

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

@@ -1,5 +1,5 @@
 <!-- file: crates/ksp-app-raw-transaction-ingest-desk/USAGE.md -->
-<!-- version: 13 -->
+<!-- version: 14 -->
 
 # Utilisation de `ksp-app-raw-transaction-ingest-desk`
 
@@ -48,7 +48,9 @@ Un Stop peut être demandé même si le Start ciblé n'a pas encore fini d'ouvri
 
 Le backend expose désormais un flux latest-value par route via l'événement Tauri `ksp-raw-ingest-route-status`. Chaque projection contient uniquement l'identité logique sûre de la route, lifecycle/health/activity, compteurs admission/persistence, backpressure, reconnect/replay, continuité, gaps et repair. La commande `get_route_monitoring` permet une resynchronisation explicite des routes actives et des derniers terminaux retenus dans la session runtime courante. Les séquences, slots et compteurs `u64` sont transmis en texte décimal pour préserver leur exactitude côté JavaScript. Le bouton `Resync monitoring` recharge explicitement les latest values backend ; les événements `ksp-raw-ingest-route-status` actualisent ensuite les cartes sans polling frontend. Le relais backend coalesce les changements à une cadence maximale d'une émission toutes les `500 ms` par route, et les changements steady-state mettent à jour la carte en place sans recréer les boutons Start/Stop. Une carte disposant d'un snapshot montre un résumé sûr (`health`, `activity`, persisted, sources actives, gaps) et le bouton `Supervision` ouvre le détail pipeline/persistence, sources, reconnect/replay, continuité et repair. Les derniers terminaux de la session restent consultables jusqu'à remplacement par un nouveau Start ou changement de session réseau.
 
-Sur Mainnet, `yellowstone-hydrated` utilise un abonnement Yellowstone Block comme signal de temps réel puis reconcile chaque slot via `getBlock` Full/Base64. Cette stratégie évite l'hydration `getTransaction` unitaire par transaction. Le profil PublicNode peut exposer plusieurs endpoints HTTP sous le même rôle logique ; Transport distribue alors les requêtes selon ses règles de priorité, disponibilité, concurrence et cooldown. La conversion directe du payload Yellowstone vers le RAW canonique reste réservée à une évolution ultérieure tant que la parité complète du meta n'est pas prouvée.
+Sur Mainnet, `yellowstone-hydrated` utilise un abonnement Yellowstone Block comme signal de temps réel puis reconcile chaque slot via `getBlock` Full/Base64. Cette stratégie évite l'hydration `getTransaction` unitaire par transaction. Le profil PublicNode peut exposer plusieurs endpoints HTTP sous le même rôle logique ; Transport distribue alors les requêtes selon ses règles de priorité, disponibilité, concurrence et cooldown. La livraison gRPC et les hydrations restent bornées : une saturation locale applique de la backpressure au stream au lieu de dropper les updates ou de fault sur `grpc_backpressure_overflow`. Lors d'un Stop ciblé, un status distant reçu après le half-close local est une fermeture coopérative ; une erreur gRPC observée avant Stop reste une panne source/reconnect normale. La conversion directe du payload Yellowstone vers le RAW canonique reste réservée à une évolution ultérieure tant que la parité complète du meta n'est pas prouvée.
+
+Lorsque plusieurs routes observent la même transaction, l'entité canonique reste unique et les provenances restent séparées. Le cas `canonique complet + entrant explicitement Log truncated compatible` est accepté sans remplacer le canonique ni passer la route en `Faulted`. Les autres divergences de contenu restent fail-closed en `0.3.15`; les variantes conflictuelles durables et leur résolution via Store Desk sont prévues pour `0.3.16`.
 
 ## 3. Raisons d'indisponibilité
 

crates/ksp-worker-raw-transaction-ingest-lib/README.md

@@ -1,5 +1,5 @@
 <!-- file: crates/ksp-worker-raw-transaction-ingest-lib/README.md -->
-<!-- version: 16 -->
+<!-- version: 17 -->
 
 # ksp-worker-raw-transaction-ingest-lib
 
@@ -169,7 +169,7 @@ Le Worker s'exécute sur le runtime Tokio courant du caller. Il ne crée pas de
 - utiliser la même source via `WorkerSnapshotSource` ;
 - attendre le terminal après drain et join des tâches possédées.
 
-Le shutdown est borné par `shutdown_drain_timeout` (10 s par défaut). Le supervisor multi-source relaie le stop à toutes les sources et les rejoint avant de rendre son résultat au supervisor Worker ; les tâches source, hydration et persistence possédées sont ensuite drainées ou abort+join avant publication terminale. Si la deadline expire, l'abort du wrapper source détruit aussi son `JoinSet` interne et annule ses tâches imbriquées avant le terminal. Une faute déjà observée n'est pas remplacée par un stop concurrent, sauf le `drain_timeout` terminal lorsqu'une récupération bornée dépasse sa deadline. Pour Yellowstone, un timeout de fermeture Transport survenant après un Stop déjà demandé est traité comme une fermeture coopérative : `SolanaYellowstoneGrpcSubscribeSession::close()` a déjà aborté puis joint son acteur avant de retourner ce timeout. Les autres erreurs de fermeture restent terminales. L'abandon terminal d'une hydration retire son pending run-local sans le convertir artificiellement en travail `settled`.
+Le shutdown est borné par `shutdown_drain_timeout` (10 s par défaut). Le supervisor multi-source relaie le stop à toutes les sources et les rejoint avant de rendre son résultat au supervisor Worker ; les tâches source, hydration et persistence possédées sont ensuite drainées ou abort+join avant publication terminale. Si la deadline expire, l'abort du wrapper source détruit aussi son `JoinSet` interne et annule ses tâches imbriquées avant le terminal. Une faute déjà observée n'est pas remplacée par un stop concurrent, sauf le `drain_timeout` terminal lorsqu'une récupération bornée dépasse sa deadline. Pour Yellowstone, un `Status` distant reçu après le half-close local explicitement engagé est classé `Closed` par Transport et ne remplace plus le Stop coopératif ; un timeout de fermeture Transport survenant après un Stop déjà demandé reste lui aussi accepté par le Worker comme fermeture coopérative bornée. En revanche, un `grpc_status` observé pendant une session active conserve la politique normale reconnect/failure. L'abandon terminal d'une hydration retire son pending run-local sans le convertir artificiellement en travail `settled`.
 
 ## Admission, coalescence et backpressure
 
@@ -187,7 +187,7 @@ source hydratante active => quota pending >= 1 et quota in-flight >= 1
 
 Pour garantir simultanément ces bornes et l'absence de starvation structurelle, le démarrage échoue avant spawn si le nombre de sources hydratantes dépasse `admission_queue_capacity` ou `persistence_concurrency`. Le registre des hydrations transactionnelles protège en plus l'ouverture effective des `getTransaction`; Yellowstone Block reste borné par sa partition déterministe et son `JoinSet` possédé.
 
-Les signaux partageant le même `(network, signature, commitment)` sont coalescés cross-source avant le fan-out HTTP. La publication du résultat partagé notifie les followers sous le verrou de registry avant de retirer la clé : une nouvelle génération de leader ne peut donc pas s'intercaler entre retrait et notification. Après canonicalisation, une cache run-local bornée sérialise les acquisitions de même `(network, signature)` : la première passe par l'écriture atomique entity + observation, les suivantes de contenu canonique identique ajoutent uniquement leur observation déterministe. Une divergence de slot, block time, format ou hash canonique devient un content conflict terminal ; aucune majorité, préférence provider ou overwrite n'est appliqué. Le Store conserve son guard durable final.
+Les signaux partageant le même `(network, signature, commitment)` sont coalescés cross-source avant le fan-out HTTP. La publication du résultat partagé notifie les followers sous le verrou de registry avant de retirer la clé : une nouvelle génération de leader ne peut donc pas s'intercaler entre retrait et notification. Après canonicalisation, une cache run-local bornée sérialise les acquisitions de même `(network, signature)` : la première passe par l'écriture atomique entity + observation, les suivantes de contenu canonique identique ajoutent uniquement leur observation déterministe. Le Store conserve le guard durable final. En `0.3.15`, il accepte aussi un entrant strictement moins complet lorsque l'unique divergence prouvée est `meta.logMessages` avec exactement un marqueur `Log truncated` après un préfixe identique alors que le canonique stocké n'est pas tronqué ; le canonique complet reste inchangé et l'observation est conservée. Toute autre divergence, ainsi que le sens tronqué -> complet, reste un `content_conflict` terminal. Aucune majorité, préférence provider ou overwrite n'est appliqué.
 
 Les retries/reroutages HTTP appartiennent à `ksp-onchain-transport-lib`. Le Worker ne possède pas une seconde boucle de retry autour de `getTransaction`.
 
@@ -287,7 +287,7 @@ content conflict
 store failure
 ```
 
-Un content conflict est terminal et n'est jamais converti en succès idempotent.
+Un content conflict réel reste terminal en `0.3.15` et n'est jamais converti en succès idempotent. L'exception `logMessages` tronqués décrite ci-dessus est classée avant le conflit comme observation compatible moins complète ; elle ne remplace pas le canonique et n'incrémente pas le terminal `content_conflict`. La conservation de variantes conflictuelles et leur résolution sans arrêt du Worker appartiennent à `0.3.16`.
 
 ## Snapshots et erreurs
 

crates/ksp-worker-raw-transaction-ingest-lib/USAGE.md

@@ -1,5 +1,5 @@
 <!-- file: crates/ksp-worker-raw-transaction-ingest-lib/USAGE.md -->
-<!-- version: 14 -->
+<!-- version: 15 -->
 
 # Utilisation de ksp-worker-raw-transaction-ingest-lib
 
@@ -232,7 +232,7 @@ La `YellowstoneSubscribeRequest` doit :
 - utiliser explicitement `Confirmed` ou `Finalized` ;
 - rester compatible avec le réseau du `YellowstoneGrpcChannel`.
 
-Le `HttpTransportPool` doit posséder au moins une route compatible avec le rôle d'hydration et `getTransaction` sur le même réseau. La construction de `RawTransactionIngestYellowstoneSource` vérifie ces invariants sans ouvrir la connexion réseau.
+Le `HttpTransportPool` doit posséder au moins une route compatible avec le rôle d'hydration sur le même réseau. Les familles Transaction/TransactionStatus exigent `getTransaction`; un abonnement Yellowstone Block pur exige `getBlock`. La construction de `RawTransactionIngestYellowstoneSource` vérifie ces invariants sans ouvrir la connexion réseau.
 
 Le caller ne passe pas de signature, `program_id`, plage de slots ou limite historique au Worker. Ces paramètres appartiennent à un Job Backfill, pas au service continu.
 
@@ -243,7 +243,7 @@ Les familles productives sont traitées ainsi :
 ```text
 Yellowstone Transaction       -> signal -> HTTP getTransaction -> Common RAW -> admission
 Yellowstone TransactionStatus -> signal -> HTTP getTransaction -> Common RAW -> admission
-Yellowstone Block             -> un signal par transaction -> HTTP getTransaction -> Common RAW -> admission
+Yellowstone Block             -> trigger slot -> HTTP getBlock Full/Base64 -> Common RAW par transaction -> admission
 Standard WS logsSubscribe     -> context.slot + signature -> HTTP getTransaction -> Common RAW -> admission
 Standard WS blockSubscribe    -> Full/Base64 Legacy|V0|V1 -> Common RAW direct par transaction -> admission
 Helius transactionSubscribe   -> Full envelope -> signature/slot/index -> HTTP getTransaction -> Common RAW -> admission
@@ -253,7 +253,7 @@ Yellowstone Slot              -> continuity-only
 Yellowstone Account/Ping/Pong/Entry -> sans RAW Transaction dans cette verticale
 ```
 
-Les signaux de même `(network, signature, commitment)` sont coalescés globalement avant l'hydration HTTP. Si plusieurs sources produisent ensuite la même transaction canonique, le Worker conserve une seule entité RAW et enregistre séparément les observations déterministes propres à chaque source. Le Worker ne possède pas une boucle de retry HTTP : reroutage/retry/backoff restent dans `ksp-onchain-transport-lib`.
+Les signaux de même `(network, signature, commitment)` sont coalescés globalement avant l'hydration HTTP. Si plusieurs sources produisent ensuite la même transaction canonique, le Worker conserve une seule entité RAW et enregistre séparément les observations déterministes propres à chaque source. Pour Yellowstone Block, les slots gRPC sont coordonnés dans une borne pending distincte et plusieurs `getBlock` peuvent progresser jusqu'au quota in-flight de la source ; si l'aval sature, Transport attend de la capacité sur sa queue bornée et propage la backpressure au stream gRPC au lieu de dropper l'update ou de produire un overflow local. Le Worker ne possède pas une boucle de retry HTTP : reroutage/retry/backoff restent dans `ksp-onchain-transport-lib`.
 
 Les sources qui nécessitent `getTransaction` partagent des quotas bornés et déterministes. Pour une composition valide :
 
@@ -266,7 +266,7 @@ somme de leurs tâches d'hydration actives <= persistence_concurrency
 
 Ces contraintes garantissent au moins une part à chaque source reference-bearing sans introduire de scheduler pondéré. Si les settings ne permettent pas cette répartition, le démarrage échoue avant spawn avec `runtime_invalid`; le caller doit augmenter la capacité concernée ou réduire le nombre de sources nécessitant une hydration.
 
-Pour une même identité `(network, signature)`, une divergence canonique de slot, block time, format ou hash est un `content_conflict`. Le Worker ne choisit ni majorité ni provider préféré et n'écrase pas un contenu divergent ; le Store reste l'autorité durable finale du conflit.
+Pour une même identité `(network, signature)`, le Worker ne choisit ni majorité ni provider préféré et n'écrase pas un contenu divergent ; le Store reste l'autorité durable finale. En `0.3.15`, un canonique complet peut accepter comme observation supplémentaire un entrant identique hors `meta.logMessages` lorsque celui-ci contient exactement un marqueur `Log truncated` après un préfixe identique. Le canonique n'est pas réécrit. Le sens tronqué -> complet et toute autre divergence non prouvée restent des `content_conflict` terminaux ; leur stockage en variantes et leur résolution sont réservés à `0.3.16`.
 
 ## Observer le snapshot concret
 

deltas/0.3.15/pre.017.md

@@ -0,0 +1,109 @@
+<!-- file: deltas/0.3.15/pre.017.md -->
+<!-- version: 1 -->
+
+# Delta v0.3.15-pre.017 — réconciliation documentaire finale
+
+## Base
+
+```text
+ksp-general-0.3.15-pre.016.zip
+SHA-256: 2d892564c00283424e49d35d35fc7b60d1afd6038ae7616f74eb85de5735eb52
+```
+
+Le gate opérateur de `pre.016` est vert : audits Rust/Markdown propres, `cargo check --workspace`, Clippy strict, suites ciblées et workspace sans échec reporté. Les canaris récents restent notamment verts avec `396/396` unitaires Transport, `49/49` release completeness Transport, `161/161` unitaires Worker et `50/50` unitaires Raw Transaction Ingest Desk. Les graphes Cargo demandés ont été rejoués et `cargo tauri build` a produit les bundles Linux `.deb`, `.rpm` et `.AppImage` en `0.3.15-pre.16`.
+
+La preuve live héritée reste valide puisque `pre.016` n'a changé aucun runtime : Yellowstone Mainnet et HTTP Block Polling ont tourné ensemble environ 19 minutes sans overflow/fault terminal puis ont terminé `Stopped/Healthy`.
+
+## Objet
+
+Exécuter exclusivement la réconciliation documentaire finale imposée par `VER-LIFECYCLE-006` avant la préparation de publication. La documentation active est alignée sur le comportement réellement livré par `0.3.10`–`0.3.15`, en particulier :
+
+```text
+Common RAW partagé et cinq familles Worker live
+Yellowstone Block : trigger gRPC + HTTP getBlock Full/Base64 borné/concurrent
+backpressure Yellowstone soutenue propagée au stream sans overflow local
+Stop Yellowstone post-half-close coopératif sans masquer les erreurs actives
+compatibilité étroite canonique complet + incoming logMessages explicitement tronqués
+Raw Transaction Ingest Desk multi-route same-network avec Store partagé
+handoff 0.3.16 variantes/conflits/retries/Store Desk
+0.3.17 Backfill multi-route puis 0.3.18 Backfill Desk adapté
+```
+
+Aucun comportement runtime, test, frontend, Config, schema, migration, dépendance ou manifest de crate n'est modifié.
+
+## Version
+
+```text
+workspace.package.version : 0.3.15-pre.17
+root Cargo header counter  : 635
+```
+
+Le bump est obligatoire pour une prerelease non-fix même documentaire (`VER-ID-009`).
+
+## Frontière lifecycle
+
+Conformément à `VER-LIFECYCLE-006`, cette tranche ne modifie pas :
+
+```text
+CHANGELOG.md
+ROADMAP.md
+prompts/**
+```
+
+Ces artefacts sont réservés à `0.3.15-pre.018`, dernière prerelease de préparation de publication. Aucun rattrapage durable ne doit être repoussé dans `pre.018`.
+
+## Documents réconciliés
+
+- le README racine décrit désormais le Worker cinq familles, Yellowstone Block + `getBlock`, la backpressure soutenue, la convergence tronquée étroite et le Desk multi-route ;
+- l'index `docs/000-README.md` référence les plans/validations `0.3.10`–`0.3.15` et le handoff `0.3.16` ;
+- la séquence fonctionnelle et les documents d'architecture retirent les formulations « future Desk / extension live » devenues obsolètes ;
+- l'architecture RAW fixe explicitement ce que `0.3.15` résout et ce qui reste réservé au moteur de variantes/conflits de `0.3.16` ;
+- les README/USAGE Worker et Raw Transaction Ingest Desk documentent le chemin Yellowstone Block réel, les bornes/backpressure, le Stop post-half-close et la règle de `Log truncated` ;
+- le plan et la validation `0.3.15` enregistrent le PASS opérateur `pre.016` et ouvrent uniquement la réconciliation documentaire `pre.017`.
+
+## Fichiers ajoutés
+
+```text
+deltas/0.3.15/pre.017.md
+```
+
+## Fichiers modifiés
+
+```text
+Cargo.toml
+README.md
+docs/000-README.md
+docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
+docs/architecture/004-COMPONENT_INVENTORY.md
+docs/architecture/005-DEPENDENCY_GRAPH.md
+docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md
+docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md
+crates/ksp-worker-raw-transaction-ingest-lib/README.md
+crates/ksp-worker-raw-transaction-ingest-lib/USAGE.md
+crates/ksp-app-raw-transaction-ingest-desk/README.md
+crates/ksp-app-raw-transaction-ingest-desk/USAGE.md
+docs/plans/036-V0_3_15_RAW_TRANSACTION_INGEST_DESK_PLAN.md
+docs/validation/032-V0_3_15_RAW_TRANSACTION_INGEST_DESK.md
+```
+
+## Fichiers supprimés
+
+Aucun.
+
+## Validation attendue opérateur
+
+```bash
+cargo fmt --all -- --check
+python3 scripts/audit_rust_workspace_rules.py
+python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates deltas/0.3.15
+cargo check --workspace
+```
+
+Aucun nouveau live ni nouveau build Tauri n'est requis tant que le différentiel reste strictement celui de cette tranche documentaire hors bump racine.
+
+## Suite
+
+```text
+0.3.15-pre.018 — préparation publication minimale : CHANGELOG + ROADMAP + prompt 0.3.16
+0.3.15-rel.001 — publication stable mécanique
+```

docs/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 73 -->
+<!-- version: 74 -->
 
 # Documentation KSP
 
@@ -67,7 +67,14 @@ docs/
 │   ├── 027-V0_3_6_JOB_API_BACKFILL_PLAN.md
 │   ├── 028-V0_3_7_BACKFILL_DESK_PLAN.md
 │   ├── 029-V0_3_8_STORE_DESK_PLAN.md
-│   └── 030-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT_PLAN.md
+│   ├── 030-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT_PLAN.md
+│   ├── 031-V0_3_10_RAW_TRANSACTION_INGEST_PLAN.md
+│   ├── 032-V0_3_11_RAW_TRANSACTION_INGEST_WORKER_FOUNDATION_PLAN.md
+│   ├── 033-V0_3_12_YELLOWSTONE_HYDRATION_CONTINUITY_PLAN.md
+│   ├── 034-V0_3_13_MULTI_SOURCE_LIVE_CONVERGENCE_PLAN.md
+│   ├── 035-V0_3_14_MULTI_SOURCE_GAP_REPAIR_HARDENING_PLAN.md
+│   ├── 036-V0_3_15_RAW_TRANSACTION_INGEST_DESK_PLAN.md
+│   └── 037-V0_3_16_RAW_RESILIENCE_CONFLICT_HANDOFF.md
 ├── validation/
 │   ├── 000-README.md
 │   ├── 001-V0_1_4_CONFIG_DESKTOP.md
@@ -95,7 +102,13 @@ docs/
 │   ├── 023-V0_3_6_JOB_API_BACKFILL.md
 │   ├── 024-V0_3_7_BACKFILL_DESK.md
 │   ├── 025-V0_3_8_STORE_DESK.md
-│   └── 026-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT.md
+│   ├── 026-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT.md
+│   ├── 027-V0_3_10_RAW_TRANSACTION_INGEST.md
+│   ├── 028-V0_3_11_RAW_TRANSACTION_INGEST_WORKER_FOUNDATION.md
+│   ├── 029-V0_3_12_YELLOWSTONE_HYDRATION_CONTINUITY.md
+│   ├── 030-V0_3_13_MULTI_SOURCE_LIVE_CONVERGENCE.md
+│   ├── 031-V0_3_14_MULTI_SOURCE_GAP_REPAIR_HARDENING.md
+│   └── 032-V0_3_15_RAW_TRANSACTION_INGEST_DESK.md
 └── rules/
     ├── FILE_CONTRACTS.md
     ├── PROMPT_STRUCTURE.md
@@ -120,6 +133,8 @@ Le plan historique de la phase fondatrice clôturée est conservé dans [`plans/
 
 La candidate `0.3.9 — Worker API générique + audit RAW Transaction` est réconciliée dans [`plans/030-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT_PLAN.md`](plans/030-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT_PLAN.md) avec [`validation/026-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT.md`](validation/026-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT.md). `ksp-worker-api` reste Core-only et runtime-neutral pour les services continus ; l'architecture RAW place Store/`RawTransaction` au centre et sépare strictement le Job Backfill historique paramétré du futur Worker Ingest continu start/stop. [`../crates/ksp-worker-api/README.md`](../crates/ksp-worker-api/README.md), [`../crates/ksp-worker-api/USAGE.md`](../crates/ksp-worker-api/USAGE.md), [`architecture/009-ACQUISITION_WORKERS_AND_JOBS.md`](architecture/009-ACQUISITION_WORKERS_AND_JOBS.md) et [`architecture/011-RAW_TRANSACTION_ACQUISITION.md`](architecture/011-RAW_TRANSACTION_ACQUISITION.md) constituent les références durables avant la lane de publication.
 
+Les candidates `0.3.10` à `0.3.15` prolongent cette trajectoire RAW dans [`plans/031-V0_3_10_RAW_TRANSACTION_INGEST_PLAN.md`](plans/031-V0_3_10_RAW_TRANSACTION_INGEST_PLAN.md), [`plans/032-V0_3_11_RAW_TRANSACTION_INGEST_WORKER_FOUNDATION_PLAN.md`](plans/032-V0_3_11_RAW_TRANSACTION_INGEST_WORKER_FOUNDATION_PLAN.md), [`plans/033-V0_3_12_YELLOWSTONE_HYDRATION_CONTINUITY_PLAN.md`](plans/033-V0_3_12_YELLOWSTONE_HYDRATION_CONTINUITY_PLAN.md), [`plans/034-V0_3_13_MULTI_SOURCE_LIVE_CONVERGENCE_PLAN.md`](plans/034-V0_3_13_MULTI_SOURCE_LIVE_CONVERGENCE_PLAN.md), [`plans/035-V0_3_14_MULTI_SOURCE_GAP_REPAIR_HARDENING_PLAN.md`](plans/035-V0_3_14_MULTI_SOURCE_GAP_REPAIR_HARDENING_PLAN.md) et [`plans/036-V0_3_15_RAW_TRANSACTION_INGEST_DESK_PLAN.md`](plans/036-V0_3_15_RAW_TRANSACTION_INGEST_DESK_PLAN.md), avec leurs matrices [`validation/027-V0_3_10_RAW_TRANSACTION_INGEST.md`](validation/027-V0_3_10_RAW_TRANSACTION_INGEST.md) à [`validation/032-V0_3_15_RAW_TRANSACTION_INGEST_DESK.md`](validation/032-V0_3_15_RAW_TRANSACTION_INGEST_DESK.md). Cette séquence matérialise le Common RAW partagé, la fondation Worker, Yellowstone live, cinq familles multi-source, la continuité/gap repair puis le Desk multi-route ; `0.3.15` ferme en plus les anomalies Mainnet observées de convergence `logMessages`, backpressure Yellowstone soutenue et shutdown post-half-close. Le handoff [`plans/037-V0_3_16_RAW_RESILIENCE_CONFLICT_HANDOFF.md`](plans/037-V0_3_16_RAW_RESILIENCE_CONFLICT_HANDOFF.md) réserve explicitement à `0.3.16` les variantes RAW durables, la résolution des conflits, les retries Store/Transport et les vues correspondantes de Store Desk ; `0.3.17` et `0.3.18` portent ensuite le Backfill multi-route et son Desk adapté.
+
 ## Spécifications de formats
 
 Les formats durables, interopérables et destinés à être réimplémentables hors de KSP sont indexés depuis [`formats/000-README.md`](formats/000-README.md). [`.kspwallet` V1](formats/KSPWALLET_V1.md) reste le format JSON historique stable publié par `0.2.5`. [`.kspwallet` V2](formats/KSPWALLET_V2.md), publié stable avec `0.2.6`, ajoute le wire binaire canonique KSP, le runtime multi-version/default V2 et la migration explicite OWNER-authentifiée V1 -> V2.

docs/architecture/004-COMPONENT_INVENTORY.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/004-COMPONENT_INVENTORY.md -->
-<!-- version: 42 -->
+<!-- version: 43 -->
 
 # Inventaire initial des composants KSP
 
@@ -19,7 +19,7 @@ Ce document maintient l'inventaire synthétique des composants retenus ou presse
 ## Inventaire synthétique
 
 | Domaine                 | Composant                               | Type        | Statut       | Première cible actuelle          | Mission                                                                                              |
-|-------------------------|-----------------------------------------|-------------|--------------|---------------------------------|--------------------------------------------------------------------------------------------------|
+|-------------------------|-----------------------------------------|-------------|--------------|----------------------------------|------------------------------------------------------------------------------------------------------|
 | Core                    | `ksp-core-lib`                          | lib         | Stable       | `0.1.1`                          | Error/Result, Program IDs et primitives fondamentales                                                |
 | Logging                 | `ksp-logging-lib`                       | lib         | Stable       | `0.1.2`                          | façade unique tracing KSP                                                                            |
 | Config                  | `ksp-config-lib`                        | lib         | Stable       | `0.1.3`                          | documents, profils, env et persistence Config                                                        |
@@ -46,8 +46,8 @@ Ce document maintient l'inventaire synthétique des composants retenus ou presse
 | Store Desk              | `ksp-app-store-desk`                    | app         | Implémenté   | `0.3.8`, extension `0.3.16`      | inspection RAW + vues conflits/variantes/historique et résolution manuelle réversible                |
 | RAW transaction common  | `ksp-raw-transaction-lib`               | lib         | Implémenté   | `0.3.10`                         | canonicalisation/wire RAW Transaction v1 source-neutral partagé entre producteurs                    |
 | Worker lifecycle        | `ksp-worker-api`                        | API         | Implémenté   | `0.3.9`                          | lifecycle/health/progression génériques des services continus                                        |
-| RAW transaction worker  | `ksp-worker-raw-transaction-ingest-lib` | worker/lib  | Implémenté   | `0.3.11`–`0.3.16`               | live multi-route ; `0.3.16` sépare défaut transport et conflits RAW locaux durablement gérés     |
+| RAW transaction worker  | `ksp-worker-raw-transaction-ingest-lib` | worker/lib  | Implémenté   | `0.3.11`–`0.3.15`, ext. `0.3.16` | live cinq familles, continuité/repair et backpressure bornée ; conflits durables étendus en `0.3.16` |
-| RAW ingest Desk         | `ksp-app-raw-transaction-ingest-desk`   | app         | Retenu       | `0.3.15`                        | choix/supervision d’une ou plusieurs sources/méthodes sans réimplémenter le worker               |
+| RAW ingest Desk         | `ksp-app-raw-transaction-ingest-desk`   | app         | Implémenté   | `0.3.15`                         | composition réseau-centrique et supervision simultanée de plusieurs routes live                      |
 | STRUCTURAL job          | nom à fixer                             | job/lib     | Retenu       | couche STRUCTURAL                | normalisation Solana générique RAW -> STRUCTURAL bornée/rejouable                                    |
 | STRUCTURAL worker       | nom à fixer                             | worker/lib  | Retenu       | fin couche STRUCTURAL            | backlog RAW -> STRUCTURAL continu                                                                    |
 | Materializer API        | `ksp-materializer-api`                  | API         | Retenu       | premier groupe DECODED           | contrats extensibles matérialisation                                                                 |
@@ -90,7 +90,7 @@ La Config standard Transport appartient à `ksp-config-lib`, qui adapte vers les
 
 Les WebSockets supportent plusieurs sessions pour un même endpoint URL, mais un pool/scheduler automatique n'est créé qu'après besoin démontré.
 
-Les providers Yellowstone spécifiques restent des extensions futures ; le contrat standard est provider-neutral.
+Le contrat Yellowstone standard/provider-neutral est implémenté. PublicNode et OrbitFlare restent des compositions Config/credentials autour de ce même contrat ; toute extension provider-specific future doit conserver cette frontière au lieu de créer un second moteur Yellowstone.
 
 `ksp-offchain-transport-lib` ouvre en `0.2.11` une première surface SOL/USD multi-provider. La crate possède les adapters `reqwest`, les capacités/rate limits, l’état runtime et le refresh individuel/multiple. Elle ne dépend pas de Config et n’expose aucun wire provider comme contrat de l’application. `ksp-app-solprices-desk`, prévu en `0.2.12`, consomme exclusivement cette surface générique et reste une HID sans connaissance provider.
 

docs/architecture/005-DEPENDENCY_GRAPH.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/005-DEPENDENCY_GRAPH.md -->
-<!-- version: 30 -->
+<!-- version: 31 -->
 
 # Graphe de dépendances KSP
 
@@ -433,9 +433,9 @@ ksp-worker-control-lib                       # composant retenu, non matérialis
     -> ksp-core-lib
 ```
 
-`ksp-worker-api` est ouvert en `0.3.9` comme contrat générique de services continus et ne connaît ni Solana, ni Transport, ni Store, ni Tauri. `ksp-worker-raw-transaction-ingest-lib` est son premier consumer concret : sa fondation `0.3.11` possède admission/persistence/snapshots/shutdown ; `0.3.12` ouvre la première verticale Yellowstone + hydration HTTP ; `0.3.13` matérialise la composition live multi-source ; `0.3.14` ferme la continuité run-local par gaps bornés, preuves de coverage, repair conservatif, health gap-aware et shutdown/fairness durcis. Config et le backend physique restent hors du Worker.
+`ksp-worker-api` est ouvert en `0.3.9` comme contrat générique de services continus et ne connaît ni Solana, ni Transport, ni Store, ni Tauri. `ksp-worker-raw-transaction-ingest-lib` est son premier consumer concret : sa fondation `0.3.11` possède admission/persistence/snapshots/shutdown ; `0.3.12` ouvre la première verticale Yellowstone + hydration HTTP ; `0.3.13` matérialise la composition live multi-source ; `0.3.14` ferme la continuité run-local par gaps bornés, preuves de coverage, repair conservatif, health gap-aware et shutdown/fairness durcis ; `0.3.15` ferme le chemin d'exploitation Desk et les défauts Mainnet observés de convergence tronquée, saturation Yellowstone et fermeture coopérative. Config et le backend physique restent hors du Worker.
 
-La verticale actuelle n'est ni « un worker WebSocket » ni un moteur historique : `RawTransactionIngestRuntimeResources` contient de `1` à `32` sources logiques validées d'un même réseau parmi cinq familles — Yellowstone, Standard WS `logsSubscribe`, Standard WS `blockSubscribe`, Helius `transactionSubscribe` et HTTP live block polling. Yellowstone, Standard Logs et Helius convergent vers une registry globale d'hydration HTTP `getTransaction`; Standard Block et HTTP Block Polling qualifient directement le wire Base64 Legacy/V0/V1 vers Common RAW. Toutes les acquisitions rejoignent la même admission/persistence, la convergence canonique `(network, signature)` et des observations distinctes par provenance. Reconnect, `from_slot`, replay natif et retries réseau restent propriétaires de Transport. Le Worker observe leurs preuves sûres, maintient processing/continuity frontiers distinctes, réconcilie uniquement des gaps du run courant avec coverage explicite et mécanismes bornés, et n'appelle jamais le Job Backfill. Une source perdue ne peut rester absente que si sa perte passée est réconciliée et si les sources restantes prouvent encore tout le `TargetCoverage` futur.
+La verticale actuelle n'est ni « un worker WebSocket » ni un moteur historique : `RawTransactionIngestRuntimeResources` contient de `1` à `32` sources logiques validées d'un même réseau parmi cinq familles — Yellowstone, Standard WS `logsSubscribe`, Standard WS `blockSubscribe`, Helius `transactionSubscribe` et HTTP live block polling. Les signaux Yellowstone Transaction/TransactionStatus, Standard Logs et Helius convergent vers une registry globale d'hydration HTTP `getTransaction`. Un mode Yellowstone Block pur utilise le bloc gRPC comme trigger de slot puis exécute un `getBlock` HTTP borné/concurrent ; Standard Block et HTTP Block Polling qualifient directement le wire Base64 Legacy/V0/V1 vers Common RAW. Toutes les acquisitions rejoignent la même admission/persistence, la convergence canonique `(network, signature)` et des observations distinctes par provenance. Reconnect, `from_slot`, replay natif, retry réseau et backpressure du stream restent propriétaires de Transport. Le Worker observe leurs preuves sûres, maintient processing/continuity frontiers distinctes, réconcilie uniquement des gaps du run courant avec coverage explicite et mécanismes bornés, et n'appelle jamais le Job Backfill. Une source perdue ne peut rester absente que si sa perte passée est réconciliée et si les sources restantes prouvent encore tout le `TargetCoverage` futur.
 
 RAW worker puis STRUCTURAL worker sont introduits à la fin de leur couche respective, lorsque persistence/backlog sont disponibles. Le traitement RAW -> STRUCTURAL borné est porté par un STRUCTURAL job distinct du service continu. Les workers DECODED/DOMAIN sont introduits avec les groupes Program concernés plutôt que tous anticipés en bloc.
 
@@ -493,7 +493,7 @@ ksp-app-raw-transaction-ingest-desk
     -> ksp-store-lib
 ```
 
-La Desk sélectionne et supervise les stratégies d'acquisition exposées par le worker et par la composition Config/Transport. Elle peut activer plusieurs sources lorsqu'elles sont compatibles, mais ne reconstruit ni discovery, ni hydration, ni déduplication, ni provenance dans Tauri/TypeScript. Les endpoints, credentials, capacités provider et handles Transport/Store restent Rust-owned.
+La Desk sélectionne et supervise les stratégies d'acquisition exposées par le Worker et par la composition Config/Transport. Plusieurs routes d'un même réseau peuvent tourner simultanément avec des Workers indépendants sur un Store partagé ; le dernier terminal ferme ce Store. Le frontend ne reconstruit ni discovery, ni hydration, ni déduplication, ni provenance et ne reçoit que des projections latest-value sûres. Les endpoints, credentials, capacités provider et handles Transport/Store restent Rust-owned.
 
 ### Store Desk
 

docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md -->
-<!-- version: 21 -->
+<!-- version: 22 -->
 
 # Acquisition, workers, jobs et pipelines spécialisés
 
@@ -451,7 +451,7 @@ Les événements utiles comprennent notamment :
 
 ### RAW backfill
 
-État actuel avant extraction de la normalisation commune :
+État matérialisé après extraction de la normalisation commune :
 
 ```text
 ksp-job-backfill-lib
@@ -459,24 +459,17 @@ ksp-job-backfill-lib
     -> ksp-core-lib
     -> ksp-logging-lib
     -> ksp-onchain-transport-lib
+    -> ksp-raw-transaction-lib
     -> ksp-store-lib       # façade Store ; default-features=false côté Job
     -> futures-util/tokio  # runtime privé de Backfill
-    -> serde_json/sha2     # RAW v1 canonique + digest actuellement locaux
+    -> serde_json/sha2     # discovery/checkpoint/observation propres au Job
 ```
 
-Cible après matérialisation de la lower-layer commune :
+Le Job conserve seul ses scopes, campagnes, checkpoints et lifecycle. La canonicalisation transactionnelle partagée appartient désormais à `ksp-raw-transaction-lib`; `0.3.17` étendra les stratégies historiques sans déplacer ce rôle.
-
-```text
-ksp-job-backfill-lib
-    -> ksp-raw-transaction-lib
-    -> ksp-store-lib
-```
-
-Le Job conserve seul ses scopes, campagnes, checkpoints et lifecycle.
 
 ### RAW worker
 
-Fondation source-neutral matérialisée :
+Fondation et acquisition live matérialisées :
 
 ```text
 ksp-worker-raw-transaction-ingest-lib
@@ -485,24 +478,18 @@ ksp-worker-raw-transaction-ingest-lib
     -> ksp-raw-transaction-lib
     -> ksp-store-lib       # façade Store ; default-features=false ; aucun backend physique direct
     -> ksp-logging-lib
+    -> ksp-onchain-transport-lib
     -> sha2 / tokio        # observation key + runtime privé
-```
 
-Extension live ultérieure :
+ksp-app-raw-transaction-ingest-desk
-
-```text
-ksp-worker-raw-transaction-ingest-lib
-    -> ksp-onchain-transport-lib   # seulement lorsque les adapters sources productifs sont matérialisés
-    -> ksp-interface-lib           # seulement si un fait passif partagé aide réellement la composition live
-
-composition supérieure / future Desk
     -> ksp-config-lib
+    -> ksp-worker-api
     -> ksp-worker-raw-transaction-ingest-lib
     -> ksp-onchain-transport-lib
     -> ksp-store-lib
 ```
 
-Le Worker conserve seul son runtime continu, ses sources actives lorsqu'elles existent, sa continuité et son lifecycle. Il n'appelle ni ne pilote le Job Backfill. La fondation n'expose aucun ingress public : les sources internes futures alimentent la queue bornée et subissent sa backpressure.
+Le Worker conserve seul son runtime continu, ses sources actives, sa continuité et son lifecycle. Il n'appelle ni ne pilote le Job Backfill et n'expose aucun ingress public : ses sources internes validées alimentent les queues bornées et subissent leur backpressure. Le Desk possède uniquement la composition et la supervision ; plusieurs routes d'un même réseau peuvent avoir des Workers indépendants sur le Store partagé sans déplacer acquisition ou persistance vers Tauri/TypeScript.
 
 Les événements Interface peuvent servir de signal provider-neutral à la composition live, mais ne constituent jamais le backlog durable. Après crash ou perte d'un événement, la reprise s'appuie sur Store et sur les primitives de replay/hydratation appropriées.
 

docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md -->
-<!-- version: 17 -->
+<!-- version: 18 -->
 
 # Acquisition et alimentation `RawTransaction`
 
@@ -833,6 +833,11 @@ coverage exacte/superset conservative avec epochs prouvés
 repair borné réutilisant Transport/Common RAW/admission/Store existants
 source-loss continuation uniquement sous TargetCoverage prouvée
 snapshots gap/repair source-neutral et health gap-aware
+Desk réseau-centrique multi-route avec Store partagé et Workers indépendants
+Yellowstone Block Mainnet : trigger gRPC + HTTP getBlock Full/Base64 borné/concurrent
+backpressure Yellowstone soutenue propagée au stream gRPC au lieu d'un overflow local
+Stop Yellowstone post-half-close : status distant tardif classé Closed, status actif toujours fautif/reconnectable
+compatibilité étroite : canonique complet + incoming logMessages avec marqueur exact Log truncated
 ```
 
 Reste hors de cette verticale et nécessite une tranche dédiée :
@@ -840,7 +845,9 @@ Reste hors de cette verticale et nécessite une tranche dédiée :
 ```text
 sources EARLY / pre-execution
 campagne historique multi-source ou caller-paramétrable
-Worker multi-source -> Store live E2E avec environnement complet provisionné
+variantes RAW durables et résolution générale des conflits
+promotion canonique d'une représentation moins complète vers une plus complète
+retry Store et reconnexion Transport configurables au niveau prévu par 0.3.16
 ```
 
 ### 14.3 Gaps Transport Worker
@@ -869,6 +876,12 @@ settings techniques nécessaires
 
 Elle peut activer plusieurs providers/endpoints simultanément. Les secrets restent Config-owned, avec réutilisation unique de `KSP_SECRET_HELIUS_API_KEY` pour les surfaces Helius concernées.
 
+### 14.4.1 Politique de convergence effectivement livrée en `0.3.15`
+
+La règle générale reste fail-closed : une divergence canonique non reconnue produit `content_conflict`; le Worker ne choisit ni majorité ni provider préféré. Une seule exception de qualité a été démontrée et livrée avant la généralisation `0.3.16` : si le RAW déjà stocké est complet, que l'entrant possède la même référence/slot/block time/format, la même transaction/version/index et le même `meta` hors `logMessages`, que le canonique ne contient aucun marqueur exact `Log truncated` et que l'entrant en contient exactement un après un préfixe identique, l'entrant est traité comme observation compatible moins complète. Le canonique n'est pas réécrit et aucun `content_conflict` n'est produit.
+
+Le sens inverse reste volontairement non résolu en `0.3.15` : un canonique tronqué suivi d'une représentation complète n'est pas promu automatiquement. Deux contenus complets divergents, un préfixe incompatible, une différence hors `logMessages` ou toute relation de troncature non prouvée restent des conflits. Cette asymétrie est précisément le point d'entrée du modèle de variantes/promotion/résolution de `0.3.16`.
+
 ## 14.5 Handoff `0.3.16` : résilience RAW et conflits durables
 
 `0.3.16` doit déplacer la résolution des divergences RAW dans le contrat Store partagé, afin que Worker live et futurs Jobs historiques convergent avec la même politique. Une divergence de contenu n'est plus assimilée automatiquement à une panne d'acquisition.
@@ -923,7 +936,10 @@ Ordre conseillé :
 0.3.13 P0 : WS logs + hydration, blockSubscribe, Helius transactionSubscribe, HTTP live polling
 0.3.13 P1 : multi-source convergence, dedup, provenance, content conflict, backpressure/fairness
 0.3.13 P2 : health source-neutral, shutdown/races, completeness/security et gate live keyless
-0.3.14     : trajectoire suivante définie par son prompt dédié ; ne pas réintroduire implicitement un scope reporté
+0.3.14 P0 : gaps run-local, coverage prouvée, repair borné, source-loss et shutdown/fairness cross-layer
+0.3.15 P0 : Raw Transaction Ingest Desk multi-route + stabilité Mainnet Yellowstone/getBlock/polling
+0.3.15 P1 : diagnostic/convergence logMessages tronqués + backpressure gRPC soutenue + Stop post-half-close
+0.3.16 P0 : variantes/conflits RAW durables, promotions/résolutions, retries et Store Desk conflicts
 0.3.17 P0 : block scan historique
 0.3.17 P0 : replay Yellowstone borné
 0.3.17 P1 : provider history/archive

docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md -->
-<!-- version: 101 -->
+<!-- version: 102 -->
 
 # Séquence des releases fonctionnelles KSP
 
@@ -585,14 +585,14 @@ La séquence effective a évolué par sizing et validation réels. La référenc
 0.3.11       fondation source-neutral ksp-worker-raw-transaction-ingest-lib
 0.3.12       première verticale live Yellowstone + hydration/replay continuity
 0.3.13       cinq familles live + convergence multi-source/fairness/health/hardening
-0.3.14       tranche suivante de la trajectoire RAW selon prompt dédié
+0.3.14       gaps run-local + coverage/repair + shutdown/fairness/completeness cross-layer
-0.3.15       ksp-app-raw-transaction-ingest-desk
+0.3.15       ksp-app-raw-transaction-ingest-desk + composition multi-route + fermeture Mainnet
 0.3.16       RAW resilience / conflict variants / Store Desk conflict management
 0.3.17       ksp-job-backfill-lib multi-route / multi-stratégie
 0.3.18       ksp-app-backfill-desk adapté au Backfill multi-route
 ```
 
-Cette série ferme la couche RAW et ses outils d'exploitation avant l'ouverture fonctionnelle de STRUCTURAL. Le Worker live RAW reste distinct des jobs historiques et ne constitue pas encore une transformation RAW -> STRUCTURAL.
+Cette série ferme la couche RAW et ses outils d'exploitation avant l'ouverture fonctionnelle de STRUCTURAL. `0.3.15` ajoute le Desk réseau-centrique multi-route, stabilise la route Mainnet Yellowstone Block + HTTP `getBlock`, conserve la backpressure bornée jusqu'au stream gRPC et accepte uniquement la divergence de `logMessages` explicitement tronquée déjà démontrée lorsque le canonique complet existe. La généralisation des variantes/résolutions reste réservée à `0.3.16`. Le Worker live RAW reste distinct des jobs historiques et ne constitue pas encore une transformation RAW -> STRUCTURAL.
 
 Aucune release RAW ne crée par anticipation la persistence DECODED/DOMAIN.
 

docs/plans/036-V0_3_15_RAW_TRANSACTION_INGEST_DESK_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/036-V0_3_15_RAW_TRANSACTION_INGEST_DESK_PLAN.md -->
-<!-- version: 25 -->
+<!-- version: 26 -->
 
 # Plan v0.3.15 — Raw Transaction Ingest Desk
 
@@ -863,6 +863,8 @@ La tranche ne normalise ni n'ignore `logMessages`. Elle ajoute un diagnostic de
 
 Le live doit comparer les fingerprints au slot du conflit. Fingerprints différents au même slot indiquent deux vues de bloc/fork différentes au commitment observé ; fingerprint identique avec `logMessages` divergents indique une divergence de réponse/recording RPC entre providers pour le même bloc. Ce diagnostic précède toute décision de canonicalisation durable.
 
+`pre.014-fix.001` ferme ensuite uniquement le cas démontré : canonique complet déjà présent + entrant identique hors `logMessages` avec un marqueur exact `Log truncated` après préfixe identique. L'observation entrante est conservée, le canonique n'est pas réécrit et le Worker ne fault pas. La promotion inverse et les variantes conflictuelles générales restent réservées à `0.3.16`.
+
 Les canaris de clôture continuent de vérifier dependency firewalls, API publique, redaction et absence de seconde pipeline ou d'orchestration Backfill.
 
 Budget cible : une tranche de convergence/completeness cross-layer, sans modification de la politique fail-closed.
@@ -881,17 +883,17 @@ Budget consommé : correction Transport/acquisition sans croissance d'API publiq
 
 ### `pre.016` — gate technique/live final
 
-**État : ouvert.** Aucun nouveau comportement métier ou runtime n'est introduit. La preuve live de `pre.015-fix.001` est la baseline autoritaire puisque `pre.016` ne modifie ni source, ni test fonctionnel, ni Config, ni manifest de crate, ni frontend.
+**État : fermé / PASS opérateur.** Aucun nouveau comportement métier ou runtime n'a été introduit. La preuve live de `pre.015-fix.001` reste la baseline autoritaire puisque `pre.016` n'a modifié ni source, ni test fonctionnel, ni Config, ni manifest de crate, ni frontend.
 
-Le gate final rejoue : format, audits, `cargo check`, Clippy strict, suites ciblées Store/Transport/Worker/Desk, workspace all-targets/all-features, graphes Cargo des trois composants critiques, duplicates et `cargo tauri build` de la Desk. Les smokes live déjà fournis restent valides tant qu'aucun fichier runtime n'est modifié dans cette tranche.
+Le gate final a rejoué avec succès : format, audits, `cargo check`, Clippy strict, suites ciblées Store/Transport/Worker/Desk et workspace all-targets/all-features. Les graphes Cargo des trois composants critiques et `cargo tree --duplicates` ont été rejoués, puis `cargo tauri build` a produit les trois bundles Linux `.deb`, `.rpm` et `.AppImage` en version `0.3.15-pre.16`. Aucun `test result: FAILED`, `error[E...]`, `could not compile` ou panic n'apparaît dans le retour opérateur fourni.
 
-Tout défaut découvert ici ouvre `pre.016-fix.NNN`. Toute anomalie appartenant à un couloir antérieur ouvre une nouvelle prerelease dédiée conformément à `VER-LIFECYCLE-010`, puis les couloirs de clôture sont rejoués.
+Budget consommé : une tranche technique de clôture uniquement.
-
-Budget cible : une tranche technique de clôture uniquement.
 
 ### `pre.017` — réconciliation documentaire finale
 
-Réconcilier plan, validation, README/USAGE et documents durables réellement affectés. Ne pas modifier CHANGELOG, ROADMAP ni le prompt suivant.
+**État : matérialisé dans cette tranche.** Le plan, la validation, les README/USAGE Worker/Desk et les documents architecturaux durables sont réconciliés sur l'état effectivement livré : cinq familles live, Yellowstone Block + HTTP `getBlock`, multi-route Desk, convergence `logMessages` tronqués étroite, backpressure gRPC soutenue et Stop post-half-close. Aucun runtime, test, Config, schema, migration ou dépendance n'est modifié.
+
+Conformément à `VER-LIFECYCLE-006`, `CHANGELOG.md`, `ROADMAP.md` et le prompt `0.3.16` restent strictement réservés à `pre.018`.
 
 Budget cible : une tranche documentaire.
 

docs/validation/032-V0_3_15_RAW_TRANSACTION_INGEST_DESK.md

@@ -1,5 +1,5 @@
 <!-- file: docs/validation/032-V0_3_15_RAW_TRANSACTION_INGEST_DESK.md -->
-<!-- version: 34 -->
+<!-- version: 35 -->
 
 # Validation v0.3.15 — Raw Transaction Ingest Desk
 
@@ -1128,3 +1128,46 @@ cargo tree --duplicates
 ```
 
 Aucun nouveau live n'est requis par cette archive tant que ce scope reste strictement mécanique/documentaire : la base immédiatement précédente possède déjà le run long requis et `pre.016` ne change aucun fichier consommé par le runtime. Une modification runtime découverte nécessaire pendant le gate invaliderait cette non-claim et devrait être portée par un fix ou une nouvelle prerelease conforme au lifecycle.
+
+### `pre.016` — clôture du gate opérateur
+
+Le rejeu opérateur de `0.3.15-pre.016` ferme le gate technique final. Les audits annoncent :
+
+```text
+General Rust rule audit: clean
+Rust export completeness audit: 0 candidate(s)
+KSP workspace Rust rule audit: clean
+Markdown table audit: clean (318 tables, 229 files)
+```
+
+`cargo check --workspace` et Clippy strict terminent sans erreur. Les suites ciblées confirment notamment Store PostgreSQL `75/75` unitaires, Transport `396/396` unitaires et `49/49` release completeness, Worker `161/161` unitaires avec ses suites cross-layer/dependency/hardening/public/release, et Raw Transaction Ingest Desk `50/50` unitaires avec ses suites desktop/dependency/public/release. Le rejeu `cargo test --workspace --all-targets --all-features` ne contient aucun `test result: FAILED`, aucune erreur de compilation Rust et aucun panic dans le log fourni.
+
+Les graphes demandés ont été produits pour Transport, Worker et Raw Transaction Ingest Desk, ainsi que `cargo tree --duplicates`. Enfin, `cargo tauri build` termine le profil release et produit les trois bundles Linux :
+
+```text
+KSP Raw Transaction Ingest Desk_0.3.15-pre.16_amd64.deb
+KSP Raw Transaction Ingest Desk-0.3.15-pre.16-1.x86_64.rpm
+KSP Raw Transaction Ingest Desk_0.3.15-pre.16_amd64.AppImage
+```
+
+Aucun nouveau live n'était nécessaire : `pre.016` n'a modifié aucun artefact runtime et la preuve longue immédiatement précédente reste applicable.
+
+### `pre.017` — réconciliation documentaire finale
+
+Cette tranche réconcilie uniquement les documents durables et le numéro de prerelease workspace imposé par `VER-ID-009`. Elle ne modifie aucun fichier `src`, `tests`, `unit_tests`, frontend, Config, schema, migration, manifest de crate ou dépendance. Elle fixe notamment dans la documentation active :
+
+```text
+Yellowstone Block Mainnet -> trigger gRPC + HTTP getBlock Full/Base64
+backpressure queue Yellowstone -> attente bornée/asynchrone vers le stream, pas d'overflow local
+Stop Yellowstone -> status post-half-close coopératif ; status actif toujours fautif/reconnectable
+canonique complet + incoming Log truncated compatible -> observation acceptée, canonique conservé
+reverse promotion et variantes/résolutions générales -> 0.3.16
+Raw Transaction Ingest Desk -> multi-route same-network, Workers indépendants, Store partagé
+0.3.17 -> Backfill multi-route / multi-stratégie
+0.3.18 -> Backfill Desk adapté
+```
+
+Non-claims : `pre.017` ne transforme pas encore un vrai `content_conflict` en quarantaine durable, ne promeut pas un canonique tronqué vers une version complète, n'ajoute aucune politique Store retry/Transport reconnect configurable de `0.3.16`, et ne modifie ni `CHANGELOG.md`, ni `ROADMAP.md`, ni le prompt suivant. Ces trois derniers artefacts appartiennent à `pre.018` conformément à `VER-LIFECYCLE-003` et `VER-LIFECYCLE-006`.
+
+Gate documentaire attendu : audits Rust/Markdown, `cargo fmt --all -- --check` et `cargo check --workspace` suffisent à confirmer que le bump workspace `0.3.15-pre.17` et les documents restent cohérents avec la candidate déjà techniquement validée. Aucun nouveau live n'est requis tant que le différentiel reste strictement documentaire hors `Cargo.toml` racine.
+