v0.3.12-pre.004

docs/plans/033-V0_3_12_YELLOWSTONE_HYDRATION_CONTINUITY_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/033-V0_3_12_YELLOWSTONE_HYDRATION_CONTINUITY_PLAN.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Plan v0.3.12 — Yellowstone + hydration HTTP + continuité de run du Worker RawTransaction
 
@@ -962,7 +962,7 @@ Adapter les deux DTOs vers le signal Worker privé, sans HTTP ni persistence ré
 
 ### `pre.004` — hydration `getTransaction` + provenance composite
 
-Fermer signal -> HTTP observed -> Common RAW -> ingress existant, missing/mismatch/provenance, sans Block ni continuity.
+Fermer et qualifier déterministiquement signal -> HTTP observed -> Common RAW -> ingress existant, missing/mismatch/provenance, sans Block ni continuity. Tant que `pre.006` n'apporte pas le source task productif qui consomme cette chaîne, les adapters/hydration strictement privés sans consumer productif restent sous `#[cfg(test)]` conformément à `RUST-API-008`; `pre.004` ne crée pas artificiellement une surface publique pour contourner `dead_code`.
 
 ### `pre.005` — Block + BlockMeta + Slot
 

docs/validation/029-V0_3_12_YELLOWSTONE_HYDRATION_CONTINUITY.md

@@ -1,5 +1,5 @@
 <!-- file: docs/validation/029-V0_3_12_YELLOWSTONE_HYDRATION_CONTINUITY.md -->
-<!-- version: 6 -->
+<!-- version: 7 -->
 
 # Validation v0.3.12 — Yellowstone + hydration HTTP + continuité de run du Worker RawTransaction
 
@@ -812,3 +812,138 @@ Le correctif ne touche pas au contrat de production. Le canari recherche désorm
 
 Aucun lint n'est neutralisé, aucun helper n'est remis prématurément en production et aucune fonctionnalité de `pre.004` n'est avancée.
 
+## 34. Gate opérateur reçu pour `pre.003-fix.002`
+
+L'opérateur a exécuté après application de `pre.003-fix.002` :
+
+```text
+cargo fmt --all : PASS visible
+audit Rust : clean
+Rust export completeness : 0 candidate
+KSP workspace Rust rule audit : clean
+audit Markdown : clean (340 tables, 805 fichiers)
+cargo check --workspace : PASS visible
+cargo clippy --workspace --all-targets --all-features -- -D warnings : PASS visible
+cargo test -p ksp-worker-raw-transaction-ingest-lib : PASS
+unit tests Worker : 45 PASS, 0 fail
+dependency_boundary : 4 PASS
+hardening : 10 PASS
+public_api : 8 PASS
+release_completeness : 3 PASS
+doc-tests : 0 fail
+```
+
+Résultat : les deux correctifs `pre.003` sont clos et `0.3.12-pre.3.fix.2` devient la base autoritaire de `pre.004`.
+
+## 35. Gate `pre.004` — hydration HTTP qualifiée et provenance composite
+
+La tranche porte `workspace.package.version = 0.3.12-pre.4` et ferme la qualification déterministe suivante :
+
+```text
+signal Transaction / TransactionStatus
+    -> signature canonique 64 bytes -> Base58 commun
+    -> get_transaction_observed
+       encoding = base64
+       commitment = confirmed | finalized
+       maxSupportedTransactionVersion = 0
+    -> contrôle slot/index/signature embarquée
+    -> RawTransactionMaterial source-neutral
+    -> RawTransactionIngress existant
+```
+
+`getTransaction -> null` produit explicitement un résultat `Missing(RawTransactionReference)` et ne fabrique ni matériau RAW, ni provenance, ni ingress. Aucun retry Worker n'est ajouté autour du Transport dans cette tranche.
+
+La common RAW reçoit `format_raw_transaction_signature`, encodeur Base58 borné de `RawTransactionSignature` 64 bytes. Le round-trip avec `parse_raw_transaction_signature` est qualifié sur plusieurs signatures canoniques, y compris la signature nulle représentée par 64 caractères `1`. Le Worker n'embarque donc pas un second codec Base58.
+
+Avant toute admission, la hydration vérifie :
+
+```text
+network signal == network Worker == network source
+route signal == route source
+slot HTTP == slot signal
+transaction_index HTTP == signal lorsqu'il est présent des deux côtés
+signature extraite du wire Base64 HTTP == signature signal
+transaction HTTP réellement encodée en Base64
+```
+
+Un mismatch devient un fault Worker sûr `runtime_invalid` avec condition stable `hydration.*`; il n'est pas délégué au Store sous forme de content conflict.
+
+## 36. Provenance composite `pre.004`
+
+La provenance réutilise strictement `RawAcquisitionProvenance` et `RawProvenanceCode`; aucune migration Store n'est créée.
+
+Forme qualifiée :
+
+```text
+protocol = yellowstone_http
+provider = ys.<grpc_provider>:http.<http_provider_observé>
+endpoint_id = ys.<grpc_endpoint>:http.<http_endpoint_observé>
+acquisition_method = transaction_get_transaction | status_get_transaction
+origin = Live
+commitment = confirmed | finalized
+capture_session_id = WorkerId sûr
+filter_id = nom unique représentable | sha256.<fingerprint>
+observed_at = created_at Yellowstone seulement s'il est représentable et <= received_at
+```
+
+Les identités HTTP proviennent de `HttpObservedValue`, donc de l'endpoint réellement gagnant après routage/retry Transport. URL, headers, token, body HTTP brut et remote error ne sont jamais copiés dans la provenance ou les diagnostics Worker.
+
+Le constructeur de `RawTransactionIngestYellowstoneSource` valide désormais que chaque route HTTP compatible peut former les codes composites provider/endpoint sans dépasser les bornes Store. Une route non représentable est rejetée ; aucune troncature n'est autorisée.
+
+## 37. Application de `RUST-API-008` pendant `pre.004`
+
+`pre.004` ne crée toujours pas le source task productif : son ouverture reste réservée à `pre.006`. La chaîne signal/hydration n'a donc pas encore de consumer productif dans le build normal.
+
+Conformément à `RUST-API-008`, les adapters privés Transaction/TransactionStatus et le helper de hydration restent sous `#[cfg(test)]` pendant cette tranche. Ils sont exécutés par des fixtures déterministes réelles contre le `HttpTransportPool`, mais aucune fonction privée morte n'est laissée dans le build normal et aucun `#[allow(dead_code)]`/`#[expect(dead_code)]` n'est utilisé.
+
+Cela précise l'anticipation écrite dans `pre.003-fix.002` selon laquelle `pre.004` remettrait nécessairement ces helpers en production : la première consommation productive est en réalité celle du source task `pre.006`. La frontière fonctionnelle ne change pas ; seule la date d'activation de compilation productive est alignée avec la règle Rust du workspace.
+
+`pre.004` possède néanmoins deux effets productifs immédiatement valides :
+
+```text
+API common RAW de formatage Base58
+validation de représentabilité de la future provenance composite dans le constructeur de source
+```
+
+## 38. Canaris déterministes `pre.004`
+
+Les nouvelles preuves couvrent :
+
+```text
+round-trip Base58 64 bytes <-> texte canonique
+requête getTransaction avec confirmed/base64/max version 0
+winner HTTP observé dans provider/endpoint composites
+Legacy + meta valeur + block_time valeur + index présent
+V0 + meta null + block_time null + index omis
+filter unique direct et multi-filter fingerprint borné
+Transaction et TransactionStatus vers méthodes de provenance distinctes
+created_at futur ignoré pour observed_at
+getTransaction null -> Missing sans ingress et sans retry Worker
+slot mismatch
+index mismatch
+signature wire mismatch
+network mismatch avant I/O
+absence de Block/getBlock/stream Yellowstone/source spawn
+absence de Config/Backfill/backend/reqwest/tonic/proto direct dans le Worker
+```
+
+## 39. Validation locale et non-claims `pre.004`
+
+L'environnement d'assemblage exécute les audits Python et l'audit Markdown après finalisation du delta. `cargo`, `rustc` et `rustfmt` n'y sont pas disponibles ; aucun résultat Cargo local n'est inventé.
+
+`pre.004` ne prétend pas avoir :
+
+```text
+ouvert open_standard_subscribe
+consommé une update réseau live
+spawn un source task Yellowstone
+branché Block / BlockMeta / Slot
+coalescé des hydrations productives
+modifié la processing frontier
+branché from_slot / ReplayInfo
+persisté une transaction issue d'un stream Yellowstone réel
+exécuté un smoke live Worker
+```
+
+La tranche suivante reste `pre.005` : adapters Block transactionnels et signaux continuity-only BlockMeta/Slot, toujours sans politique reconnect Worker.
+