khadhroony-solana-project/docs/plans/001-V0_0_3_PLAN.md

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 — 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.

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 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, 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.
• 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.003 — Graphe de dépendances et correction de l'inventaire

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

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 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 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 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 ;
• 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 frontière supplémentaire doit être étudiée.