v0.3.6-pre.012

docs/architecture/002-LAYERS_AND_DEPENDENCIES.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/002-LAYERS_AND_DEPENDENCIES.md -->
-<!-- version: 8 -->
+<!-- version: 9 -->
 
 # Couches et dépendances KSP
 
@@ -27,7 +27,7 @@ Les niveaux architecturaux N1–N4 décrivent les familles de composants du proj
 
 - `ksp-store-api` / `ksp-store-lib` ;
 - `ksp-materializer-api` / implementations lorsque DECODE s'ouvre ;
-- `ksp-job-api` et jobs ;
+- `ksp-job-api`, `ksp-job-backfill-lib` puis les jobs concrets introduits par les couches ;
 - `ksp-worker-api` et workers ;
 - processors/pipelines spécialisés réellement réutilisés.
 
@@ -138,11 +138,11 @@ Des applications spécialisées sont ajoutées au fur et à mesure pour valider
 
 ## Workers et jobs
 
-Un worker est un service continu/autonome ; un job est borné/terminable.
+Un worker est un service continu/autonome ; un job est borné/terminable. `ksp-job-api` porte le lifecycle commun et l'observation latest-value sans runtime concret. Le premier job, `ksp-job-backfill-lib`, fournit un runtime single-run historique vers RAW ; il compose Transport et Store sans devenir worker ni service permanent.
 
-Ils utilisent des APIs lifecycle distinctes et ne s'appellent pas entre eux pour transférer les payloads du data plane.
+Workers et jobs utilisent des APIs lifecycle distinctes et ne s'appellent pas entre eux pour transférer les payloads du data plane. Un checkpoint de job peut être caller-owned sans devenir automatiquement une persistence de control plane.
 
-Le Store reste le point durable de synchronisation entre couches de processing.
+Le Store reste le point durable de synchronisation des données entre couches de processing ; les snapshots Job décrivent l'état opérationnel du job et ne remplacent pas les données RAW persistées.
 
 ## Firewall des dépendances externes