v0.3.8-pre.013

docs/architecture/008-DATA_MATERIALIZATION_AND_STORE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/008-DATA_MATERIALIZATION_AND_STORE.md -->
-<!-- version: 5 -->
+<!-- version: 6 -->
 
 # Data, Materialization et Store
 
@@ -325,6 +325,21 @@ Le backend PostgreSQL officiel appartient à `ksp-store-postgres-lib`. Cette cra
 
 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.
 
+### Navigation machine et inspection humaine
+
+Deux contrats complémentaires coexistent sans collision :
+
+```text
+workers / jobs / replay -> RawPageRequest + RawPageCursor -> keyset
+inspection UI           -> RawInspectionPageRequest      -> offset + limit + counts exacts
+```
+
+La voie cursor/keyset reste canonique pour la navigation machine et les replays : le cursor est opaque, lié au contexte de query et ne dépend pas d'un `OFFSET` profond.
+
+La voie `RawInspectionPageRequest` est backend-neutral mais conçue pour une inspection humaine random-access. Elle peut demander des counts exacts et un offset absolu ; le backend PostgreSQL peut implémenter cette capability avec `COUNT` et `OFFSET` privés. Ce choix ne réécrit jamais les statements keyset historiques.
+
+`ksp-app-store-desk` est le consumer actuel de cette voie d'inspection. DataTables possède l'unique pager visible et l'application ne reçoit aucun cursor Store. Les summaries d'inspection restent sans payload/data RAW ; un détail explicite peut recharger une seule entité avec une projection applicative bornée.
+
 ## `ksp-materializer-api` et `ksp-materializer-lib`
 
 Ils sont introduits seulement lorsque le premier groupe DECODE démontre le contrat réel.