v0.0.3-pre.003

docs/plans/001-V0_0_3_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/001-V0_0_3_PLAN.md -->
-<!-- version: 6 -->
+<!-- version: 7 -->
 
 # Plan KSP 0.0.3
 
@@ -9,79 +9,92 @@ Transformer le brainstorming KSP en architecture, règles, inventaire et plan su
 
 ## État courant
 
-`pre.001` est considérée stabilisée et commitée comme `v0.0.3-pre.001`.
+- `pre.001` — base de planification stabilisée et commitée ;
+- `pre.002` — inventaire initial des composants ;
+- `pre.003` — graphe de dépendances, correction de l'inventaire et stabilisation des frontières de composition.
 
-`pre.002` produit le premier inventaire des composants et responsabilités. Cet inventaire est volontairement révisable dans `pre.003` lorsque le graphe de dépendances sera étudié.
+La prochaine tranche prévue est `pre.004`, consacrée à Program/Wire/Execution.
 
 ## Décisions structurantes actuelles
 
-- `0.1.x`, `0.2.x`, etc. sont des **séries fonctionnelles**, pas des unités de session.
-- Chaque release concrète d'une série doit être dimensionnée séparément pour une session raisonnable.
+- `0.1.x`, `0.2.x`, etc. sont des séries fonctionnelles, pas des unités de session.
+- Chaque release concrète d'une série est dimensionnée séparément.
 - Les bibliothèques d'implémentation utilisent `ksp-<role>-lib` ; les contrats publics extensibles utilisent `ksp-<domain>-api`.
-- Program, materializer et store ont un couple API/implémentation séparé.
-- Workers et jobs ont des lifecycle APIs distinctes.
-- `ksp-worker-raw-retriever` réalise uniquement l'acquisition live/quasi-live raw.
-- Le processing futur est séparé en `ksp-worker-core-processor`, `ksp-worker-generic-materializer` et `ksp-worker-domain-projector` (nom du dernier provisoire).
+- Program, Materializer et Store ont un couple API/implémentation séparé.
+- Workers et jobs ont des lifecycle APIs distinctes, sans parent commun.
+- `ksp-worker-raw-retriever` réalise uniquement l'acquisition raw live/quasi-live.
 - `ksp-job-backfill` réalise l'acquisition historique à la demande.
-- `ksp-worker-control-lib` est destiné à être réutilisé par managers/apps/orchestrateur ; aucune `ksp-job-control-lib` n'est prévue sans besoin concret.
-- `ksp-execution-policy-api` et `ksp-execution-lib` sont des candidats forts pour séparer policy et orchestration d'exécution de `ksp-program-lib`.
-- Pas de `ksp-onchain-transport-api`, `ksp-offchain-transport-api` ou `ksp-wallet-api` dans l'architecture actuelle.
-- `ksp-onchain-transport-lib` expose des modèles de transport homogènes mais indépendants du store.
-- Pas de `ksp-scenario-api` pour l'instant : privilégier une norme souple de scénarios spécialisés.
-- Pas de `ksp-pipeline-lib` monolithique ; pipelines spécialisés uniquement à la demande.
+- Le processing futur est séparé entre `ksp-worker-core-processor`, `ksp-worker-generic-materializer` et `ksp-worker-domain-projector`.
+- `ksp-worker-control-lib` est la gouvernance commune des workers ; aucune `ksp-job-control-lib` n'est prévue actuellement.
+- `ksp-execution-policy-api` est retenu.
+- `ksp-execution-lib` est retenu comme orchestration spécialisée et dépend de `ksp-program-api`, pas de `ksp-program-lib`.
+- `ksp-program-lib` ne dépend ni du wallet ni du transport.
+- `ksp-materializer-lib` ne dépend pas du store.
+- `ksp-store-api` reste indépendant de Program/Materializer/Transport.
+- Les workers/jobs spécialisés convertissent explicitement les modèles entre transport, processing et persistence.
+- `ksp-store-api` possède les notifications canoniques de données persistées ; leur transport concret reste séparé.
+- Aucun `ksp-data-api`, `ksp-pipeline-lib`, `ksp-scenario-api`, `ksp-onchain-transport-api`, `ksp-offchain-transport-api` ou `ksp-wallet-api` n'est prévu actuellement.
+- Les scenarios restent des crates spécialisées régies d'abord par une norme souple.
 
 ## Prévision souple des prereleases restantes
 
-### `pre.002` — Inventaire initial des composants
-
-- créer `docs/architecture/004-COMPONENT_INVENTORY.md` ;
-- fixer les responsabilités et statuts initiaux des composants ;
-- enregistrer les workers/jobs/scénarios/apps actuellement prévus ;
-- documenter les candidats `ksp-execution-policy-api` et `ksp-execution-lib` ;
-- corriger la règle de charge série/release/session ;
-- préparer explicitement les questions à résoudre dans `pre.003`.
-
 ### `pre.003` — Graphe de dépendances et correction de l'inventaire
 
-- construire le graphe autorisé/interdit ;
-- décider si `ksp-execution-lib` dépend de `ksp-program-api`, `ksp-program-lib` ou reçoit des implémentations injectées ;
-- définir la frontière program -> execution plan -> policy -> wallet/transport ;
-- vérifier que transport ne dépend pas du store tout en gardant une conversion simple des modèles ;
-- positionner materializer/store/notifications ;
-- rechercher et supprimer les cycles ;
-- corriger `004-COMPONENT_INVENTORY.md` si nécessaire.
+Livré :
+
+- `docs/architecture/005-DEPENDENCY_GRAPH.md` ;
+- graphe Program/Execution/Policy ;
+- graphe Materializer/Store ;
+- graphe Worker/Job ;
+- conversion explicite des modèles aux frontières ;
+- dépendances interdites et prévention des cycles ;
+- correction de `004-COMPONENT_INVENTORY.md` ;
+- suppression des décisions négatives présentées à tort comme tâches du roadmap.
 
 ### `pre.004` — Programmes, wire et exécution
 
-- détailler `ksp-interface-lib`, `ksp-program-api`, `ksp-program-lib` ;
-- détailler l'execution policy/orchestration si validées ;
-- cadrer conformité wire, historique/deprecated et sécurité supérieure.
+Objectifs prévus :
+
+- détailler `ksp-interface-lib` ;
+- détailler `ksp-program-api` et `ksp-program-lib` ;
+- définir précisément decoder API et executor API ;
+- définir le contrat d'opération préparée ;
+- définir `ksp-execution-policy-api` ;
+- détailler le cycle de `ksp-execution-lib` : préparation, policy, simulation, signature, envoi, confirmation ;
+- cadrer conformité wire, historique/deprecated et policy supérieure ;
+- vérifier que la tranche reste dans le budget de complexité, sinon la scinder.
 
 ### `pre.005` — Données, store et acquisitions
 
-- détailler materializer/store ;
-- finaliser les modèles raw et notifications ;
+- détailler `ksp-materializer-api` / `ksp-materializer-lib` ;
+- détailler `ksp-store-api` / `ksp-store-lib` ;
+- finaliser modèles raw/Core/generic/domain ;
+- détailler notifications et mécanismes de diffusion possibles ;
 - détailler W1 et backfill ;
-- cadrer les trois workers de processing futurs ;
-- revisiter les niveaux durables/replay.
+- cadrer les workers de processing ;
+- revisiter niveaux durables, replay, provenance et idempotence.
 
 ### `pre.006` — Applications, workers, jobs, scenarios et pipelines spécialisés
 
 - formaliser les apps spécialisées ;
 - détailler `ksp-worker-control-lib` ;
-- définir la norme des crates scénario et leurs apps demo ;
+- définir la norme des crates scenario et leurs apps demo ;
+- traiter les processus/IPC/managers ;
+- cadrer l'orchestrateur futur ;
 - inventorier les pipelines spécialisés réellement nécessaires.
 
 ### `pre.007` — Plan des premières releases fonctionnelles
 
 - transformer les séries `0.1.x+` en premières releases concrètes ;
-- dimensionner chaque release concrète plutôt que toute la série ;
-- préparer le prompt de la première release `0.1.x` réellement choisie.
+- dimensionner chaque release concrète ;
+- choisir la première release `0.1.N` ;
+- transformer le brouillon de prompt en prompt quasi-final de cette release concrète.
 
 ### `pre.008` — Clôture fondatrice
 
 - validations finales de cohérence ;
 - documentation/nettoyage/archivage ;
+- synchronisation du changelog si applicable ;
 - finalisation du prompt de la première release fonctionnelle.
 
-Le nombre de prereleases reste révisable si une tranche dépasse le budget de planification ou si une nouvelle frontière apparaît.
+Le nombre de prereleases reste révisable si une tranche dépasse le budget de planification ou si une frontière supplémentaire doit être étudiée.