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 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-<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).
• 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.