v0.3.9-pre.006-fix.003

docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md -->
-<!-- version: 12 -->
+<!-- version: 13 -->
 
 # Acquisition, workers, jobs et pipelines spécialisés
 
@@ -204,20 +204,11 @@ L'archive kbot3 doit être relue uniquement comme **référence fonctionnelle**
 
 #### `mainnet` et `mainnet-beta`
 
-La terminologie réseau est un audit explicite avant toute modification. Les sources Solana actuelles utilisent de plus en plus `mainnet` alors que plusieurs surfaces/outils historiques conservent `mainnet-beta`.
+L'audit `0.3.9` a conclu que `mainnet` est l'identité logique canonique KSP du réseau de production Solana. `mainnet-beta` reste un alias legacy/externe ou un libellé provider lorsqu'une API externe l'emploie réellement ; il ne constitue plus l'identité persistée cible de Store/RAW/Config.
 
-KSP ne doit jamais créer deux identités persistées pour le même cluster par simple renommage. L'audit doit donc inventorier :
+Depuis `0.3.9-pre.006-fix.003`, les profils Mainnet engagés dans Config/Store/Transport utilisent `mainnet`, de même que les tests et exemples runtime associés. KSP ne crée donc pas deux identités persistées pour le même cluster. Les anciennes données N1 RAW portant `mainnet-beta` sont considérées comme expérimentales et peuvent être droppées/recréées ; aucune migration destructive n'est imposée avant finalisation des Jobs/Workers RAW.
 
-```text
-RawNetworkId et valeurs persistées Store
-Config profile ids / cluster labels
-Transport descriptors et provider metadata
-CLI/external aliases réellement acceptés
-compatibilité des checkpoints/fingerprints existants
-migration ou canonicalisation éventuellement nécessaire
-```
-
-Aucun renommage de données persistées ou de profil n'est effectué en `0.3.8`. `0.3.10` ne l'implémente que si l'audit `0.3.9` établit une stratégie de compatibilité sûre.
+Les frontières externes restent libres de documenter ou d'accepter un nom provider legacy lorsque nécessaire, sans recopier ce nom dans `RawNetworkId` canonique.
 
 #### Idempotence et multi-source
 
@@ -527,7 +518,7 @@ selon les capacités réellement introduites.
 
 - nom final de la crate pipeline RAW si la réutilisation worker + backfill justifie réellement une crate dédiée ;
 - taxonomie exacte des stratégies/source capabilities de `ksp-worker-raw-transaction-ingest-lib`, à décider par l'audit de fin `0.3.9` ;
-- stratégie sûre de canonicalisation/aliasing `mainnet` / `mainnet-beta`, si un changement KSP est réellement nécessaire ;
+- politique d'alias externe `mainnet-beta` à matérialiser uniquement aux frontières qui en ont réellement besoin, sans créer une seconde identité Store ;
 - modèle de claim/lease PostgreSQL pour les futurs processors continus ;
 - taille de batch et stratégie backpressure des workers de processing ;
 - découpage des workers DECODE/SPECIALIZED par groupe lorsque les premiers groupes existent ;

docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md -->
-<!-- version: 5 -->
+<!-- version: 6 -->
 
 # Acquisition et alimentation `RawTransaction`
 
@@ -609,7 +609,7 @@ priorités/composition
 
 Les prix/tiers d'audit ne doivent pas devenir une politique runtime.
 
-`mainnet` devient l'identité réseau durable KSP. `mainnet-beta` reste uniquement un alias de compatibilité/historique ou un libellé externe lorsqu'un provider/API l'emploie. La phase N1 RAW étant encore une phase de test, aucune donnée existante ne doit forcer la conservation de `mainnet-beta` comme identité canonique : la base peut être droppée/recréée lors de la normalisation si nécessaire.
+`mainnet` est l'identité réseau durable KSP. `mainnet-beta` reste uniquement un alias de compatibilité/historique ou un libellé externe lorsqu'un provider/API l'emploie. Depuis `0.3.9-pre.006-fix.003`, les profils Config/Store/Transport Mainnet engagés utilisent `mainnet` comme identité logique, et les exemples/tests associés ont été normalisés. Les endpoints publics Solana engagés suivent également la nomenclature Mainnet courante (`https://api.mainnet.solana.com` et `wss://api.mainnet.solana.com`). Aucune migration de données N1 n'est exigée : les données RAW Mainnet encore expérimentales peuvent être droppées/recréées si elles portent l'ancienne identité.
 
 ## 13. Normalisation RAW commune sans couplage Job/Worker
 

docs/plans/030-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/030-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT_PLAN.md -->
-<!-- version: 12 -->
+<!-- version: 13 -->
 
 # Plan v0.3.9 — Worker API générique + audit RAW Transaction
 
@@ -612,6 +612,12 @@ Réécriture complète de `docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md`
 
 La synthèse corrige la direction de compatibilité réseau : `mainnet` devient l'identité KSP canonique et `mainnet-beta` devient un alias legacy/externe, jamais l'inverse. Les libellés provider natifs qui utilisent encore `mainnet-beta` restent documentés comme tels, sans imposer cette valeur à l'identité Store. La base N1 RAW actuelle reste jetable tant que Jobs/Workers d'acquisition ne sont pas finalisés ; aucune donnée de test existante ne justifie donc de figer une convention de nommage indésirable. La normalisation runtime/Config/Store correspondante est un handoff technique ultérieur, pas un changement de code `0.3.9`. `workspace.package.version` reste `0.3.9-pre.6`.
 
+#### `pre.006-fix.003` — normalisation runtime/config de l'identité Mainnet
+
+**Statut : réalisé ; correctif configuration/runtime + tests.**
+
+La décision de `pre.006-fix.002` est matérialisée immédiatement pendant N1 RAW : les identités Mainnet engagées dans `std.store`, `std.transport`, leurs exemples/fixtures et les tests Store/Backfill passent de `mainnet-beta` à `mainnet`. Les endpoints publics Solana engagés utilisent la nomenclature courante `api.mainnet.solana.com` / `wss://api.mainnet.solana.com`. Les anciens RAW N1 restent jetables ; aucune migration de compatibilité n'est ajoutée. Les libellés historiques/provider `mainnet-beta` restent documentés lorsqu'ils décrivent réellement une source externe ou l'historique du projet. Ce correctif synchronise Cargo en `0.3.9-pre.6.fix.3` conformément à `VER-ID-007` et `VER-ID-010`.
+
 ### `pre.007` — gate technique final
 
 **Statut : prévu.**

docs/validation/026-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT.md

@@ -1,5 +1,5 @@
 <!-- file: docs/validation/026-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT.md -->
-<!-- version: 11 -->
+<!-- version: 12 -->
 
 # Validation v0.3.9 — Worker API + audit RAW Transaction
 
@@ -234,6 +234,17 @@ Aucun item ci-dessous n’est déclaré exécuté en `pre.001`.
 - [X] Aucun changement runtime/Config/Store n'est effectué dans ce correctif documentaire ; la migration technique reste un handoff ultérieur.
 - [X] `workspace.package.version` reste `0.3.9-pre.6`.
 
+#### `pre.006-fix.003` — normalisation technique `mainnet`
+
+- [X] `config/std.store.json` et son exemple utilisent `network = mainnet` pour le profil Mainnet.
+- [X] `config/std.transport.json`, son exemple et les fixtures utilisent `cluster = mainnet` pour l'identité logique KSP.
+- [X] Les endpoints publics engagés utilisent `https://api.mainnet.solana.com` et `wss://api.mainnet.solana.com`.
+- [X] Les tests Config, Store API/PostgreSQL, Job Backfill et Backfill/Store Desk concernés utilisent la nouvelle identité canonique.
+- [X] Les anciens libellés `mainnet-beta` ne subsistent que dans l'historique documentaire, les anciens deltas/plans ou comme description explicite de l'alias/provider externe.
+- [X] Aucun mécanisme de migration des données N1 n'est ajouté ; drop/recréation de la base de test reste admis.
+- [X] Gate opérateur complet fourni : audits propres, check/clippy PASS, workspace `--all-targets --all-features` PASS et cinq bundles Desk PASS ; smokes live restent opt-in/ignored.
+- [X] Version Cargo corrigée pour la livraison en `0.3.9-pre.6.fix.3` (`VER-ID-010`).
+
 ## 7. Couloirs de fermeture
 
 ### `pre.007` — gate technique final
@@ -281,4 +292,4 @@ Après la synthèse multi-source `pre.006`, l'état courant est :
 workspace.package.version = 0.3.9-pre.6
 ```
 
-`pre.002` reste la tranche non-fix `0.3.9-pre.2`. Les correctifs de conformité/compilation portent successivement `0.3.9-pre.2.fix.1` puis `0.3.9-pre.2.fix.2` conformément à `VER-ID-007` et `VER-ID-010`. `pre.003` reprend ensuite la séquence prerelease normale avec `0.3.9-pre.3`; son gate opérateur est PASS et freeze Worker API. `pre.004` poursuit avec `0.3.9-pre.4` sans changement runtime, uniquement l'audit standard Solana/KSP et la création de l'owner durable d'acquisition. `pre.005` passe à `0.3.9-pre.5` et enrichit cet owner avec l'audit Helius/Yellowstone/providers/kbot3 sans modifier le runtime. `pre.006` passe à `0.3.9-pre.6` et ferme la synthèse exhaustive possibilités/support/preuve ainsi que les handoffs `0.3.10`/`0.3.12`, toujours sans changement runtime. `pre.006-fix.001` réécrit ensuite l'owner d'architecture comme synthèse Store-centrique et corrige la séparation Worker live / Job historique sans modifier Cargo. L'état précédent `0.3.9-pre.1.fix.2` reste documenté dans `pre.001-fix.002`.
+`pre.002` reste la tranche non-fix `0.3.9-pre.2`. Les correctifs de conformité/compilation portent successivement `0.3.9-pre.2.fix.1` puis `0.3.9-pre.2.fix.2` conformément à `VER-ID-007` et `VER-ID-010`. `pre.003` reprend ensuite la séquence prerelease normale avec `0.3.9-pre.3`; son gate opérateur est PASS et freeze Worker API. `pre.004` poursuit avec `0.3.9-pre.4` sans changement runtime, uniquement l'audit standard Solana/KSP et la création de l'owner durable d'acquisition. `pre.005` passe à `0.3.9-pre.5` et enrichit cet owner avec l'audit Helius/Yellowstone/providers/kbot3 sans modifier le runtime. `pre.006` passe à `0.3.9-pre.6` et ferme la synthèse exhaustive possibilités/support/preuve ainsi que les handoffs `0.3.10`/`0.3.12`. `pre.006-fix.001` réécrit ensuite l'owner d'architecture comme synthèse Store-centrique et corrige la séparation Worker live / Job historique sans modifier Cargo ; `pre.006-fix.002` fixe `mainnet` comme identité canonique sans runtime. `pre.006-fix.003` matérialise finalement cette normalisation dans Config/Store/Transport/tests et porte la version Cargo `0.3.9-pre.6.fix.3`. L'état précédent `0.3.9-pre.1.fix.2` reste documenté dans `pre.001-fix.002`.