v0.3.13-pre.003

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

@@ -1,5 +1,5 @@
 <!-- file: crates/ksp-worker-raw-transaction-ingest-lib/README.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # ksp-worker-raw-transaction-ingest-lib
 
@@ -12,7 +12,8 @@ RawTransactionIngestWorker::start
     -> fondation source-neutral, sans source productive
 
 RawTransactionIngestWorker::start_with_runtime_resources
-    -> même runtime + une source Yellowstone productive supervisée
+    -> même runtime + une source productive supervisée
+       Yellowstone ou WS standard logsSubscribe
        + hydration HTTP getTransaction
 ```
 
@@ -20,14 +21,20 @@ Le Worker reste indépendant de Config et de tout backend Store physique. Le cal
 
 ## Pipeline productif actuel
 
-La première verticale live est :
+Les verticales live productives sont :
 
 ```text
 Yellowstone standard subscribe
     -> Transaction / TransactionStatus / Block
     -> signal source-neutral (network, signature, slot, commitment, provenance sûre)
+
+Solana standard WS logsSubscribe
+    -> context.slot + signature
+    -> signal source-neutral (network, signature, slot, commitment, provenance sûre)
+
+les deux chemins
     -> coalescence bornée par (network, signature, commitment)
-    -> HTTP getTransaction observed
+    -> HTTP getTransaction observed, Base64, maxSupportedTransactionVersion=1
     -> ksp-raw-transaction-lib
     -> admission centrale bornée
     -> ksp-store-lib
@@ -58,7 +65,23 @@ La construction est sans I/O et refuse notamment :
 - une provenance provider/endpoint non représentable ;
 - l'absence d'une route HTTP compatible pour `getTransaction` sur le même réseau.
 
-Le runtime-resource aggregate public contient exactement une source Yellowstone validée. Il n'expose ni enum provider, ni collection de sources, ni callback, ni queue d'enqueue, ni client inférieur.
+Le runtime-resource aggregate public accepte une collection validée de 1 à 32 sources logiques. `pre.003` sait exécuter une source unique Yellowstone ou une source unique Standard Logs ; une activation simultanée de plusieurs sources reste rejetée avant spawn jusqu'au supervisor dédié. La collection interne, les `source_key`, les URLs, les filtres et les clients inférieurs ne sont pas exposés.
+
+## Contrat de source Standard Logs + HTTP
+
+`RawTransactionIngestStandardLogsSource::new` reçoit :
+
+```text
+WsEndpointSettings kind solana_standard
+SolanaLogsSubscribeFilter
+SolanaCommitment Confirmed ou Finalized
+HttpTransportPool
+HttpRoleName d'hydration
+```
+
+La construction est sans I/O. Elle refuse un endpoint WS invalide ou non standard, `Processed`, un réseau/provenance non représentable et l'absence de route HTTP `getTransaction` compatible sur le même réseau. Le filtre `All`, `AllWithVotes` ou `Mentions(pubkey)` participe uniquement à une empreinte privée ; le pubkey d'un filtre `Mentions` n'est pas recopié dans `Debug`, snapshot ou provenance textuelle.
+
+Au runtime, le Worker ouvre `SolanaStandardWsSession::connect`, puis `logs_subscribe`. Les lignes de logs et `err` restent dans Transport et ne sont jamais stockées dans le signal Worker. Seuls `context.slot` et `signature` sont projetés vers l'hydration commune. Reconnect, resubscribe et backpressure de la subscription restent possédés par Transport.
 
 ## Runtime et lifecycle
 
@@ -77,11 +100,11 @@ Le shutdown est borné par `shutdown_drain_timeout`. Les tâches source, hydrati
 
 La queue centrale est un `tokio::sync::mpsc` privé borné par `admission_queue_capacity`. Les sources internes subissent la backpressure ; aucune queue non bornée ni silent drop n'est autorisé.
 
-La source Yellowstone possède également un coordinateur d'hydration borné :
+Le Worker possède un coordinateur d'hydration source-neutral borné, réutilisé par Yellowstone et Standard Logs :
 
 ```text
 in-flight hydration <= persistence_concurrency
-pending source signals <= 65_536
+pending source signals <= admission_queue_capacity
 ```
 
 Les signaux partageant le même `(network, signature, commitment)` sont coalescés avant le fan-out HTTP. Les provenances utiles restent néanmoins conservées pour les ingress produits après hydration.
@@ -196,7 +219,7 @@ La crate ne dépend pas de Config, Job, `ksp-store-api` directement, backend Sto
 La verticale actuelle ne possède pas :
 
 - plusieurs sources productives simultanées dans `RawTransactionIngestRuntimeResources` ;
-- source WS/Helius-specific ou HTTP polling Worker ;
+- source `blockSubscribe`, Helius `transactionSubscribe` ou HTTP polling Worker ;
 - sélection Config interne au Worker ;
 - checkpoint persistent de processing frontier ;
 - campagne de réparation historique automatique ;