v0.3.8-pre.013

docs/architecture/002-LAYERS_AND_DEPENDENCIES.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/002-LAYERS_AND_DEPENDENCIES.md -->
-<!-- version: 10 -->
+<!-- version: 11 -->
 
 # Couches et dépendances KSP
 
@@ -134,7 +134,7 @@ Les applications Tauri restent minces :
 - instrumentation frontend ;
 - aucun déplacement de logique de transport, Wallet, Config, Program, Store ou Materializer dans Tauri.
 
-Des applications spécialisées sont ajoutées au fur et à mesure pour valider les couches : Config Desk, Wallet Desk, `ksp-app-solprices-desk`, `ksp-app-backfill-desk`, Store/RAW tooling, CORE tooling puis Market Desk. `ksp-app-solprices-desk` reste une HID mince : elle consomme l’inventaire, les observations, les états et les opérations génériques de `ksp-offchain-transport-lib` sans connaître les providers, leurs endpoints, leurs credentials ni leurs limites. `ksp-app-backfill-desk` compose Config, Transport HTTP, Store et `ksp-job-backfill-lib` sans absorber découverte, retry/rate-limit, persistance ou checkpoint ; son frontend ne reçoit que des DTOs sûrs et le checkpoint de reprise reste Rust-only.
+Des applications spécialisées sont ajoutées au fur et à mesure pour valider les couches : Config Desk, Wallet Desk, `ksp-app-solprices-desk`, `ksp-app-backfill-desk`, `ksp-app-store-desk`, CORE tooling puis Market Desk. `ksp-app-solprices-desk` reste une HID mince : elle consomme l’inventaire, les observations, les états et les opérations génériques de `ksp-offchain-transport-lib` sans connaître les providers, leurs endpoints, leurs credentials ni leurs limites. `ksp-app-backfill-desk` compose Config, Transport HTTP, Store et `ksp-job-backfill-lib` sans absorber découverte, retry/rate-limit, persistance ou checkpoint ; son frontend ne reçoit que des DTOs sûrs et le checkpoint de reprise reste Rust-only. `ksp-app-store-desk` compose Config, Logging et `ksp-store-lib` pour une inspection RAW read-only : il n'accède ni au backend physique ni au SQL et sépare la pagination random-access de l'interface de la pagination cursor/keyset réservée aux consumers machine.
 
 ## Workers et jobs
 

docs/architecture/003-COMPONENT_CONTRACTS.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/003-COMPONENT_CONTRACTS.md -->
-<!-- version: 14 -->
+<!-- version: 15 -->
 
 # Contrats initiaux des composants KSP
 
@@ -214,6 +214,8 @@ Une application globale reste future.
 
 `ksp-app-backfill-desk` est l'interface spécialisée du premier job historique. Elle dépend des façades KSP nécessaires à la composition (`ksp-config-lib`, `ksp-job-api`, `ksp-job-backfill-lib`, `ksp-onchain-transport-lib`, `ksp-store-lib`, Core et Logging), garde Store/Transport/checkpoint côté Rust et expose uniquement les options, demandes opérateur bornées, états latest-value et acquittements de contrôle sûrs.
 
+`ksp-app-store-desk` est l'interface spécialisée d'inspection du Store RAW. Elle dépend de `ksp-config-lib`, `ksp-core-lib`, `ksp-logging-lib` et `ksp-store-lib`, conserve le Store ouvert côté Rust, expose uniquement des DTOs app-owned backend-neutral et ne fournit aucun command d'écriture. Les tables utilisent les capabilities d'inspection random-access ; les détails rechargent une seule entité et bornent les previews RAW sans déplacer la rétention ou le backend dans Tauri.
+
 ## Progression verticale Program
 
 À partir de DECODE :

docs/architecture/004-COMPONENT_INVENTORY.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/004-COMPONENT_INVENTORY.md -->
-<!-- version: 32 -->
+<!-- version: 33 -->
 
 # Inventaire initial des composants KSP
 
@@ -43,6 +43,7 @@ Ce document maintient l'inventaire synthétique des composants retenus ou presse
 | Job lifecycle           | `ksp-job-api`                            | API           | Implémenté   | `0.3.6`                         | identité/lifecycle/annulation/notifications latest-value runtime-neutral                    |
 | Backfill                | `ksp-job-backfill-lib`                   | lib           | Implémenté   | `0.3.6`                         | backfill `RawTransaction` borné via Transport observé + Store, checkpoint et runtime        |
 | Backfill Desk           | `ksp-app-backfill-desk`                  | app           | Implémenté   | `0.3.7`                         | Start/monitoring/Cancel/Resume in-session du backfill RAW via façades KSP                   |
+| Store Desk              | `ksp-app-store-desk`                     | app           | Implémenté   | `0.3.8`                         | inspection RAW read-only Transaction/Account/Observation via façade Store                   |
 | Worker lifecycle        | `ksp-worker-api`                         | API           | Retenu       | fin couche RAW                  | lifecycle des services continus                                                             |
 | RAW worker              | `ksp-worker-raw-retriever` ou nom révisé | worker        | Retenu       | fin couche RAW                  | acquisition live vers RAW                                                                   |
 | CORE processor          | nom à fixer                              | processor/lib | Retenu       | couche CORE                     | normalisation Solana générique RAW -> CORE                                                  |
@@ -150,7 +151,6 @@ Market Desk est progressive : V1 après les DEX prioritaires, puis enrichissemen
 
 ## Questions restantes
 
-- nom exact de Backfill Desk ;
 - nécessité future d'un pool automatique WS ;
 - types exacts `ksp-materializer-api` lors de l'ouverture DECODE ;
 - nom/packaging précis du premier RAW worker et du CORE normalizer ;

docs/architecture/005-DEPENDENCY_GRAPH.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/005-DEPENDENCY_GRAPH.md -->
-<!-- version: 21 -->
+<!-- version: 22 -->
 
 # Graphe de dépendances KSP
 
@@ -440,6 +440,18 @@ ksp-app-backfill-desk
 
 La Desk compose les ressources et contrôles du job sans traverser la façade Store : aucune dépendance directe à `ksp-store-api`, `ksp-store-postgres-lib`, `tokio-postgres`, `reqwest`, `tonic` ou `yellowstone-grpc-proto`. Le frontend ne connaît que des rôles HTTP logiques et des DTOs sûrs ; endpoints, credentials, backend Store, RAW et checkpoint concret restent sous les composants Rust propriétaires.
 
+### Store Desk
+
+```text
+ksp-app-store-desk
+    -> ksp-config-lib
+    -> ksp-core-lib
+    -> ksp-logging-lib
+    -> ksp-store-lib
+```
+
+Store Desk est un consumer read-only de la façade Store. Il ne dépend pas directement de `ksp-store-api`, `ksp-store-postgres-lib` ou `tokio-postgres`, ne possède aucun SQL et n'ouvre aucun Transport. Les capabilities d'inspection random-access alimentent les DataTables server-side ; les reads par identité alimentent les détails bornés. Les URI, secrets, handles backend, payloads complets et source bytes ne traversent pas la frontière frontend.
+
 ### Market Desk
 
 ```text

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.

docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md -->
-<!-- version: 9 -->
+<!-- version: 10 -->
 
 # Applications, services, scenarios et control plane
 
@@ -117,6 +117,9 @@ ksp-app-backfill-desk
     -> ksp-store-lib
 
 ksp-app-store-desk
+    -> ksp-config-lib
+    -> ksp-core-lib
+    -> ksp-logging-lib
     -> ksp-store-lib
 ```
 
@@ -124,6 +127,8 @@ ksp-app-store-desk
 
 Backfill Desk suit exactement cette règle : elle ouvre Store via `ksp-store-lib`, construit le pool HTTP via `ksp-onchain-transport-lib`, puis remet ces ressources à `ksp-job-backfill-lib`. Start/Cancel/Resume restent des opérations applicatives de composition ; le checkpoint de reprise et les ressources physiques ne deviennent jamais des DTOs Tauri.
 
+Store Desk suit la même frontière sans Transport : Config sélectionne Logging + Store, `ksp-store-lib` fournit health, reads et inspection backend-neutral, et le Store ouvert reste côté Rust. Les DataTables frontend consomment des summaries server-side et counts exacts ; les détails chargent une seule entité avec preview bornée. Aucun command d'écriture, SQL, cursor opaque, backend physique ou secret Store n'est exposé à Tauri/TypeScript.
+
 Les couches N1–N4 expriment des responsabilités et une direction de dépendances ; elles n'imposent pas de traverser toutes les couches intermédiaires.
 
 ## Tauri