v0.3.2-pre.001

docs/architecture/008-DATA_MATERIALIZATION_AND_STORE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/008-DATA_MATERIALIZATION_AND_STORE.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->
 
 # Data, Materialization et Store
 
@@ -291,26 +291,39 @@ La première implementation `0.3.1` est volontairement **RAW-only** : elle ne cr
 
 Les surfaces CORE/DECODE/SPECIALIZED sont ajoutées quand leurs couches sont réellement ouvertes.
 
-## `ksp-store-lib`
+## `ksp-store-lib` et backends physiques
 
-`ksp-store-lib` fournit PostgreSQL comme backend officiel de référence derrière `ksp-store-api`.
+`ksp-store-lib` est la façade/runtime Store commune derrière `ksp-store-api`. Il sélectionne uniquement les backends compilés par ses features, convertit ses settings KSP-owned vers le backend retenu, expose le lifecycle commun et masque les objets physiques du moteur.
 
-Il possède :
+Il possède notamment :
 
-- migrations ;
-- SQL ;
-- transactions ;
-- mapping backend ;
-- pagination ;
-- claim/lease lorsque nécessaire ;
-- notifications backend si retenues.
+- identité et sélection de backend côté façade ;
+- settings Store publics KSP-owned indépendants de Config ;
+- lifecycle commun `open` / `close` ;
+- dispatch vers le backend compilé ;
+- mapping des diagnostics/health backend vers une projection portable lorsque cette surface est justifiée ;
+- réexport de la surface `ksp-store-api` utile aux consumers.
 
-Il ne possède pas :
+Le backend PostgreSQL officiel appartient à `ksp-store-postgres-lib`. Cette crate dépend de `ksp-store-api`, ne dépend jamais de `ksp-store-lib` et possède seule :
 
-- transport réseau ;
+- `tokio-postgres` et le pool PostgreSQL ;
+- le connecteur TLS PostgreSQL ;
+- SQL et statements physiques ;
+- transactions PostgreSQL ;
+- migrations/bootstrap et metadata de schéma ;
+- mapping rows/backend ;
+- détails de cursorisation physique ;
+- diagnostics PostgreSQL internes.
+
+`ksp-store-lib` et les crates backend ne possèdent pas :
+
+- transport réseau d’acquisition ;
 - decoder Program ;
 - materializer ;
-- orchestration de worker/job.
+- orchestration de worker/job ;
+- politique de batch, backlog, priorité ou retry de processing.
+
+La pagination/cursorisation reste un contrat de navigation Store. Une limite demandée par l’appelant peut être validée pour sa forme/sécurité, mais aucun plafond métier global arbitraire ni batch-size de worker n’est introduit par le runtime Store.
 
 ## `ksp-materializer-api` et `ksp-materializer-lib`