v0.3.15-pre.008-fix.004

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: 11 -->
+<!-- version: 12 -->
 
 # Plan v0.3.15 — Raw Transaction Ingest Desk
 
@@ -791,13 +791,21 @@ Stop
 
 Le slot reste occupé pendant le drain terminal et la fermeture Store ; aucun second Start n'est admis durant cette fenêtre. Le frontend ne reçoit ni `WorkerId`, ni handle, ni endpoint, ni URI Store. La terminaison spontanée est nettoyée backend-side mais son streaming vers le frontend reste `pre.010`. Le partage d'un même Store entre plusieurs Workers reste `pre.009`.
 
+#### `pre.008-fix.004` — cohérence de source Yellowstone Mainnet
+
+Le test live Mainnet a montré que `yellowstone-hydrated` ouvrait bien le gRPC PublicNode mais reconstruisait son pool `getTransaction` à partir du Transport de base `mainnet_public`, donc `api.mainnet.solana.com`. Le fix impose que le gRPC Yellowstone et son hydration HTTP proviennent du même composant `transport.yellowstone`. Le profil `publicnode_mainnet` utilise désormais `https://solana-rpc.publicnode.com` pour son endpoint HTTP et n'hérite plus de la limite locale Solana-public `5 req/s`; la concurrence reste bornée et les `429` continuent à déclencher le cooldown Transport.
+
+Ce fix ne prétend pas rendre viable le firehose Mainnet complet par hydration unitaire. La suppression de l'hydration systématique quand Yellowstone porte déjà le matériau transactionnel, le pool HTTP multi-provider, le multi-route, la déduplication cross-route et le repair HTTP par bloc sont explicitement déplacés vers `pre.009`.
+
 Budget cible : une tranche runtime mono-route.
 
-### `pre.009` — multi-route et Store partagé
+### `pre.009` — optimisation Mainnet, multi-route et Store partagé
 
-Permettre plusieurs routes simultanées avec un Worker indépendant par route, un même Store partagé lorsque le réseau est strictement identique et une isolation des faults entre routes.
+Permettre plusieurs routes simultanées avec un Worker indépendant par route, un même Store partagé lorsque le réseau est strictement identique et une isolation des faults entre routes. La tranche doit également traiter le goulet observé sur Mainnet : privilégier un chemin Yellowstone direct lorsque le matériau RAW peut être reconstruit sans `getTransaction`, réserver HTTP à la réparation/hydration réellement nécessaire, et introduire un pool HTTP multi-provider dont les quotas, health, cooldown et capabilities restent endpoint-owned.
 
-Budget cible : une tranche runtime multi-route.
+Le Store conserve l'idempotence `(network, signature)` et les observations/provenances permettent à plusieurs routes de confirmer la même transaction sans créer une seconde entité RAW. Le repair HTTP doit privilégier le niveau bloc lorsqu'il permet de récupérer plusieurs transactions par requête.
+
+Budget cible : une tranche runtime/throughput Mainnet + multi-route.
 
 ### `pre.010` — snapshots et monitoring runtime
 

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: 12 -->
+<!-- version: 13 -->
 
 # Validation v0.3.15 — Raw Transaction Ingest Desk
 
@@ -413,9 +413,17 @@ Surface IPC sûre ajoutée : `start_route` et `stop_route`, avec `RawIngestRoute
 
 Le frontend fournit un contrôle minimal Start/Stop mono-route et le choix `confirmed`/`finalized`. Il ne prétend pas encore fournir le monitoring continu : une terminaison spontanée est nettoyée backend-side mais sa projection temps réel demeure `pre.010`. Multi-route, Store partagé entre Workers et isolation inter-route demeurent `pre.009`.
 
-### `pre.009` — runtime multi-route
+#### `pre.008-fix.004` — preuve live Mainnet et correction PublicNode
 
-Un Worker par route, même Store si réseau identique, isolation des faults.
+Le parcours live `pre.008-fix.003` prouve que le channel Yellowstone PublicNode Mainnet s'ouvre et produit des transactions, mais que l'hydration était construite depuis le Transport de base `mainnet_public`. Les traces montraient donc le gRPC `publicnode_solana_mainnet_yellowstone` suivi de requêtes `getTransaction` via `solana_mainnet_public`, puis rate-limit/cooldown et overflow de queue.
+
+Le fix corrige la composition : `prepare_yellowstone` prend désormais son role/pool HTTP dans le même `ResolvedTransportConfig` optionnel qui fournit le gRPC. Le profil `publicnode_mainnet` expose `publicnode_solana_mainnet_rpc` sur `https://solana-rpc.publicnode.com`, provider `publicnode`, sans recopier la limite locale `5 req/s` du profil Solana-public. La concurrence locale reste bornée à 8 et le cooldown Transport sur `429` reste actif.
+
+Non-claim : ce changement réduit une erreur de composition mais ne garantit pas qu'une hydration HTTP unitaire puisse suivre le firehose Mainnet. L'optimisation structurelle Yellowstone direct + pool HTTP multi-provider + repair bloc est reportée à `pre.009`.
+
+### `pre.009` — optimisation Mainnet et runtime multi-route
+
+Un Worker par route, même Store si réseau identique, isolation des faults, chemin Yellowstone direct lorsque possible, pool HTTP multi-provider et repair par bloc pour éviter que `getTransaction` unitaire soit le chemin nominal du temps réel.
 
 ### `pre.010` — monitoring