v0.0.3-pre.010

docs/architecture/005-DEPENDENCY_GRAPH.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/005-DEPENDENCY_GRAPH.md -->
-<!-- version: 6 -->
+<!-- version: 7 -->
 
 # Graphe de dépendances KSP
 
@@ -144,14 +144,17 @@ ksp-program-lib
 
 Il est également le propriétaire candidat du **contrat d'opération préparée** produit par la sémantique programme et consommé par la couche d'exécution.
 
-Noms exacts à définir en `pre.004`, par exemple conceptuellement :
+Le contrat de préparation retenu est centré sur :
 
 ```text
-PreparedProgramOperation
-ProgramExecutionPlan
+ProgramExecutionRequest
+        ↓
+ProgramExecutionPreparer
+        ↓
+PreparedProgramExecution
 ```
 
-Le choix du nom/type final n'est pas décidé ici.
+Les champs Rust exacts restent à définir avec la première implémentation, sans rouvrir la séparation préparation/exécution.
 
 ## Interdictions Program
 
@@ -456,7 +459,7 @@ notify
 
 Le payload privilégie une référence durable compacte.
 
-Le mécanisme concret peut être channel, PostgreSQL LISTEN/NOTIFY, IPC ou broker. Le choix détaillé est reporté à `pre.007`.
+Le contrat reste indépendant du mécanisme. PostgreSQL `LISTEN/NOTIFY` est retenu comme mécanisme initial de référence de wake-up, combiné à un polling périodique du backlog.
 
 ---
 
@@ -849,29 +852,13 @@ Les conversions entre Program/Materializer/Store ne sont pas résolues par des d
 
 ---
 
-# Questions reportées
+# Questions restantes
 
-`pre.004` doit détailler :
+Les grandes frontières de dépendances sont désormais fixées. Restent à résoudre avec les premières implémentations :
 
-- noms/types exacts des entrées/sorties de `ksp-program-api` ;
-- forme exacte de l'opération préparée ;
-- appel/injection entre program implementation et `ksp-execution-lib` ;
-- contrat exact de `ksp-execution-policy-api` ;
-- frontière entre préparation, policy, simulation, signature, envoi et confirmation.
-
-`pre.005` doit détailler :
-
-- DTO raw/Core/materialization/projection du store ;
-- entrées/sorties `ksp-materializer-api` ;
-- conversion Core runtime <-> store Core ;
-- notifications et transport de notifications ;
-- niveaux durables/replay/idempotence/provenance ;
-- rôle précis des deux workers de matérialisation.
-
-`pre.006` doit détailler :
-
-- managers spécialisés ;
-- processus/IPC éventuels ;
-- norme des scenarios ;
-- apps demo ;
-- orchestrateur futur et pipelines spécialisés.
+- types Rust exacts de `ksp-program-api`, `ksp-materializer-api` et `ksp-store-api` ;
+- représentation ouverte/persistable des résultats Program ;
+- schémas SQL, transactions, claims/leases et pagination PostgreSQL ;
+- mécanisme IPC du premier manager de worker autonome ;
+- injection du contexte nécessaire aux `DomainProjector` stateful ;
+- éventuel orchestrateur commun uniquement si un besoin opérationnel concret apparaît.