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 ;