v0.3.15-pre.009

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: 12 -->
+<!-- version: 13 -->
 
 # Plan v0.3.15 — Raw Transaction Ingest Desk
 
@@ -238,7 +238,7 @@ Le frontend reçoit uniquement la projection sûre de ce modèle. Les ressources
 
 | Route V1                      | Network          | Required capability                                            | Optional capability                             | Config evidence                 | Worker resource                               | Composable aujourd’hui ?                                                          | Missing contract                               | Live-testable ?                      |
 |-------------------------------|------------------|----------------------------------------------------------------|-------------------------------------------------|---------------------------------|-----------------------------------------------|-----------------------------------------------------------------------------------|------------------------------------------------|--------------------------------------|
-| `yellowstone-hydrated`        | réseau du profil | Yellowstone gRPC Subscribe + HTTP `getTransaction` même réseau | scan HTTP repair si rôle compatible             | gRPC + HTTP role                | `RawTransactionIngestYellowstoneSource`       | oui sur profil complet et secrets résolus                                         | aucun contrat essentiel                        | provider-gated selon profil          |
+| `yellowstone-hydrated`        | réseau du profil | Yellowstone gRPC Block Subscribe + HTTP `getBlock` même réseau | reconciliation HTTP bloc multi-provider         | gRPC + HTTP role                | `RawTransactionIngestYellowstoneSource`       | oui sur profil complet et secrets résolus                                         | aucun contrat essentiel                        | provider-gated selon profil          |
 | `standard-logs-hydrated`      | réseau du profil | WS Solana standard `logsSubscribe` + HTTP `getTransaction`     | scan HTTP repair si rôle compatible             | `Logs` + HTTP role              | `RawTransactionIngestStandardLogsSource`      | oui côté Config sur profils déclarant `Logs` ; enforcement Worker en `pre.004`    | enforcement Worker minimal                     | oui, notamment Devnet keyless        |
 | `standard-block-direct`       | réseau du profil | WS Solana standard `blockSubscribe` explicitement déclaré      | aucune hydration obligatoire                    | WS capability `Block`           | `RawTransactionIngestStandardBlockSource`     | oui sur les profils publics standard qui déclarent explicitement `Block`          | enforcement Worker minimal + endpoint qualifié | seulement endpoint prouvé compatible |
 | `helius-transaction-hydrated` | réseau du profil | WS Helius `transactionSubscribe` + HTTP `getTransaction`       | scan HTTP repair si rôle compatible             | `HeliusTransaction` + HTTP role | `RawTransactionIngestHeliusTransactionSource` | oui côté Config sur `helius_*` si secret résolu ; enforcement Worker en `pre.004` | enforcement Worker minimal                     | provider-gated Helius                |
@@ -795,15 +795,17 @@ Le slot reste occupé pendant le drain terminal et la fermeture Store ; aucun se
 
 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`.
+Ce fix ne prétend pas rendre viable le firehose Mainnet complet par hydration unitaire. `pre.009` remplace finalement ce chemin nominal par Yellowstone Block -> `getBlock` multi-provider : l'hydratation `getTransaction` systématique disparaît de la route Desk, tandis que la projection protobuf -> RAW directe reste différée jusqu'à preuve de parité canonique complète.
 
 Budget cible : une tranche runtime mono-route.
 
 ### `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. 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.
+Matérialiser plusieurs routes simultanées avec **un Worker indépendant par route**, un même `Arc<Store>` partagé uniquement lorsque le réseau est strictement identique, Stop ciblé et isolation des faults. Le premier Start same-network ouvre/valide Store ; les suivants le réutilisent ; la dernière route terminale seule ferme Store. Aucun gap, frontier ou handle Worker n'est partagé entre routes.
 
-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.
+Pour Mainnet, remplacer le chemin Yellowstone nominal `transaction -> getTransaction` par `Yellowstone Block -> getBlock Full/Base64`. L'abonnement Block sert de trigger temps réel sans transporter le payload transactionnel ; la reconciliation HTTP récupère toutes les transactions du bloc en une requête, avec retry borné/interruptible afin d'absorber le décalage court entre disponibilité gRPC et HTTP. Cette tranche ne revendique pas encore une canonicalisation protobuf -> RAW directe.
+
+Le profil `publicnode_mainnet` expose un pool HTTP de même rôle contenant PublicNode et Solana public. Les limites, health, cooldown et concurrence restent endpoint-owned et `HttpTransportPool` conserve son routage/fallback. Store assure toujours l'idempotence `(network, signature)` et conserve les observations/provenances distinctes lorsque plusieurs routes voient la même transaction.
 
 Budget cible : une tranche runtime/throughput Mainnet + multi-route.