v0.3.11-pre.012

docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md -->
-<!-- version: 11 -->
+<!-- version: 12 -->
 
 # Acquisition et alimentation `RawTransaction`
 
@@ -149,7 +149,7 @@ Il peut utiliser **HTTP, WS, Yellowstone gRPC, replay provider ou archive** si c
 
 ### 3.2 Worker Raw Transaction Ingest : acquisition continue start/stop
 
-`ksp-worker-raw-transaction-ingest-lib` a pour rôle de **remplir continuellement Store à partir du moment où il est démarré**.
+`ksp-worker-raw-transaction-ingest-lib` a pour rôle cible de **remplir continuellement Store à partir du moment où il est démarré**. Sa fondation source-neutral matérialise déjà le runtime, l'admission, la canonicalisation Common RAW, la persistence et les snapshots, mais aucune source réseau productive n'est encore branchée.
 
 Son contrôle métier V1 est volontairement court :
 
@@ -161,17 +161,17 @@ snapshot / notifications
 
 Le caller ne lui fournit pas une signature, un `program_id`, une plage historique, une limite de campagne ou une requête de backfill. Les endpoints, réseaux, sources activées, capabilities et secrets proviennent de Config/composition, pas d'un payload métier de `start`.
 
-À partir de son démarrage, le Worker :
+La fondation actuelle, lorsqu'elle démarre sans adapter source productif, publie son lifecycle/snapshot puis reste contrôlable jusqu'au stop. Dès qu'une source interne est matérialisée, le pipeline cible devient :
 
 ```text
 acquiert les nouvelles transactions disponibles
 hydrate les signaux live incomplets si nécessaire
 normalise puis persiste RawTransaction + observations
-publie ses notifications indépendamment de leurs lecteurs
+publie ses snapshots latest-value indépendamment de leurs lecteurs
 continue jusqu'à stop ou fault
 ```
 
-Le Worker peut utiliser **WS, Yellowstone gRPC, HTTP, block polling, provider streams ou sources EARLY** si ces capacités servent l'acquisition live.
+Le Worker peut ensuite utiliser **WS, Yellowstone gRPC, HTTP, block polling, provider streams ou sources EARLY** si ces capacités servent l'acquisition live. Ces sources restent internes au Worker ; le caller ne pousse pas directement des ingress dans sa queue privée.
 
 Il ne lance pas de campagne historique arbitraire.
 
@@ -648,7 +648,7 @@ Worker lifecycle
 backend Store physique
 ```
 
-Graphe conceptuel :
+Graphe matérialisé après la fondation Worker :
 
 ```text
 ksp-job-backfill-lib --------------------> ksp-raw-transaction-lib ----> ksp-store-api
@@ -657,12 +657,14 @@ ksp-worker-raw-transaction-ingest-lib ---> ksp-raw-transaction-lib ----> ksp-sto
 ksp-job-backfill-lib --------------------> ksp-store-lib
 ksp-worker-raw-transaction-ingest-lib ---> ksp-store-lib
 ksp-job-backfill-lib --------------------> ksp-onchain-transport-lib
-ksp-worker-raw-transaction-ingest-lib ---> ksp-onchain-transport-lib
+ksp-worker-raw-transaction-ingest-lib -X-> ksp-onchain-transport-lib   # aucun adapter live productif encore
 
 aucun edge Job <-> Worker
 aucun edge Transport <-> ksp-raw-transaction-lib
 ```
 
+Les tranches live suivantes peuvent matérialiser l'edge Worker -> Transport lorsqu'un adapter source productif le nécessite ; cet edge n'appartient pas à la fondation source-neutral.
+
 La migration doit préserver exactement les golden bytes/hash RAW v1 déjà prouvés. Aucun RAW v2 n'est justifié.
 
 ### 13.1 Transaction wire Legacy/V0/V1
@@ -711,9 +713,40 @@ Yellowstone Transaction/Block -> signal structuré + transaction wire fidèle
 RAW v1 complet                -> hydration HTTP avant persistence
 ```
 
-Aucun adapter productif n'est ajouté en `pre.006`. Conformément à `TR-C2`, l'adapter `Transport DTO -> common` demeure réservé au Worker concret, désormais ouvert en `0.3.11`.
+Aucun adapter productif n'est ajouté par la qualification cross-source. Conformément à `TR-C2`, l'adapter `Transport DTO -> common` demeure réservé au Worker concret. La fondation `0.3.11` est désormais matérialisée sans Transport ; le premier adapter productif reste donc une responsabilité des tranches live suivantes.
 
-## 14. Handoff Worker live `0.3.11` à `0.3.14`
+## 14. Handoff fondation Worker `0.3.11` vers live `0.3.12` à `0.3.14`
+
+### 14.0 État fermé par la fondation source-neutral
+
+La fondation du Worker est matérialisée avec :
+
+```text
+consumer de ksp-worker-api
+settings réseau/Worker bornés
+start/stop sur runtime Tokio caller-owned
+supervision privée des tâches
+mpsc central borné + backpressure
+canonicalisation et assembly via ksp-raw-transaction-lib
+observation key déterministe
+persistence atomique via ksp-store-lib en mode Normal
+concurrence Store bornée
+snapshots concrete + projection WorkerSnapshotSource
+faults Store/content/source/counter classifiés
+shutdown deadline + abort/join sans tâche orpheline
+```
+
+Elle ne possède encore :
+
+```text
+aucun adapter HTTP/WS/Yellowstone productif
+aucun edge ksp-onchain-transport-lib
+aucune lecture Config
+aucune API publique d'enqueue/source registration
+aucun replay/gap-repair live
+```
+
+Cette frontière est volontaire : les tranches live ajoutent des sources au supervisor existant au lieu d'introduire un second runtime ou une API d'admission publique.
 
 ### 14.1 Contrat fonctionnel
 
@@ -937,7 +970,8 @@ Transaction V1               = wire source-neutral Legacy/V0/V1 dans common ; ac
 Yellowstone pre.006          = transaction wire V1 qualifié ; RAW complet via hydration HTTP
 TR-C2                        = adapter productif Transport DTO -> common réservé au Worker concret
 0.3.10                       = common RAW + preuves cross-source
-0.3.11 à 0.3.14              = Worker live multi-source par responsabilités bornées
+0.3.11                       = fondation Worker source-neutral, persistence et observabilité
+0.3.12 à 0.3.14              = sources live multi-source, continuité et hardening par responsabilités bornées
 0.3.16                       = Job Backfill multi-stratégie historique
 ```