v0.3.10-pre.006-fix.002

docs/architecture/005-DEPENDENCY_GRAPH.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/005-DEPENDENCY_GRAPH.md -->
-<!-- version: 24 -->
+<!-- version: 25 -->
 
 # Graphe de dépendances KSP
 
@@ -251,19 +251,47 @@ D1 RAW
 
 ### RAW
 
+La canonicalisation `RawTransaction` source-neutral est une lower layer explicite, séparée du Transport et de la persistence runtime :
+
 ```text
-transport model
+ksp-raw-transaction-lib
+    -> ksp-store-api
+    -> ksp-core-lib
+    -> base64 / serde_json / sha2
+```
+
+Interdictions :
+
+```text
+ksp-raw-transaction-lib -X-> ksp-onchain-transport-lib
+ksp-raw-transaction-lib -X-> ksp-store-lib
+ksp-raw-transaction-lib -X-> ksp-job-api / ksp-job-backfill-lib
+ksp-raw-transaction-lib -X-> ksp-worker-api / concrete workers
+ksp-raw-transaction-lib -X-> Config / runtime async / backend Store
+```
+
+Le flux de composition devient :
+
+```text
+transport model / fixture source-neutral
     |
     v
-composition/RAW ingestion
+producer adapter
     |
     v
-ksp-store-api
+ksp-raw-transaction-lib
+    |
+    +--> RawTransaction + RawTransactionObservation (types ksp-store-api)
+    |
+    v
+producer concret
     |
     v
 ksp-store-lib
 ```
 
+Le Job Backfill et le Worker RAW peuvent donc partager exactement la canonicalisation et le wire sans que la common crate possède le runtime, le Transport ou le backend.
+
 ### CORE
 
 ```text
@@ -375,9 +403,10 @@ ksp-job-backfill-lib
     -> ksp-core-lib
     -> ksp-logging-lib
     -> ksp-onchain-transport-lib
+    -> ksp-raw-transaction-lib    # canonicalisation/wire RAW v1 partagés
     -> ksp-store-lib              # default-features = false ; aucun backend imposé
     -> futures-util / tokio       # runtime privé du job, jamais dans ksp-job-api
-    -> serde_json / sha2          # canonicalisation RAW v1 et digest
+    -> serde_json / sha2          # usages résiduels propres au job tant qu'ils existent
 ```
 
 Il remplit RAW et ne décode aucun programme. Il ne dépend pas de Config : la composition supérieure construit explicitement Transport, Store et `BackfillRequest`. Le réseau appartient au scope/à l'identité durable `(network, signature)` ; rôle, provider, endpoint et protocole restent des choix ou provenances d'acquisition et ne deviennent jamais une clé de transaction.
@@ -393,6 +422,7 @@ ksp-worker-api
 ksp-worker-raw-transaction-ingest-lib
     -> ksp-worker-api
     -> ksp-onchain-transport-lib
+    -> ksp-raw-transaction-lib
     -> ksp-store-lib
     -> ksp-logging-lib
     # Config reste possédé par la composition supérieure ; aucune dépendance backend/provider physique
@@ -406,7 +436,7 @@ ksp-worker-control-lib
 
 Le worker RAW Transaction n'est pas défini comme « un worker WebSocket » ou « un worker gRPC ». Il reçoit une ou plusieurs stratégies d'acquisition construites au-dessus des façades KSP réellement disponibles ; celles-ci peuvent être alternatives, complémentaires (discovery + hydration), redondantes entre providers ou spécialisées live/catch-up/gap-repair. La transaction canonique reste identifiée indépendamment de la source et chaque acquisition utile conserve sa propre observation/provenance Store.
 
-RAW worker et CORE worker sont introduits à la fin de leur couche respective, lorsque persistence/backlog sont disponibles. Les workers DECODE/SPECIALIZED sont introduits avec les groupes Program concernés plutôt que tous anticipés en bloc.
+RAW worker puis STRUCTURAL worker sont introduits à la fin de leur couche respective, lorsque persistence/backlog sont disponibles. Le traitement RAW -> CORE borné est porté par un STRUCTURAL job distinct du service continu. Les workers DECODE/SPECIALIZED sont introduits avec les groupes Program concernés plutôt que tous anticipés en bloc.
 
 ## Apps