# Plan KSP 0.0.3 ## Mission Transformer le brainstorming KSP en architecture, règles, inventaire et plan suffisamment précis pour ouvrir la première série fonctionnelle `0.1.x` sans développement fonctionnel prématuré. ## État courant `pre.001` est considérée stabilisée et commitée comme `v0.0.3-pre.001`. `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é. ## 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. - Les bibliothèques d'implémentation utilisent `ksp--lib` ; les contrats publics extensibles utilisent `ksp--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). - `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. ## 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. ### `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. ### `pre.005` — Données, store et acquisitions - détailler materializer/store ; - finaliser les modèles raw et notifications ; - détailler W1 et backfill ; - cadrer les trois workers de processing futurs ; - revisiter les niveaux durables/replay. ### `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 ; - 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. ### `pre.008` — Clôture fondatrice - validations finales de cohérence ; - documentation/nettoyage/archivage ; - 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.