v0.0.3-pre.002

ROADMAP.md

@@ -1,9 +1,9 @@
 <!-- file: ROADMAP.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->
 
 # Roadmap KSP
 
-Le roadmap décrit les objectifs à atteindre et les grandes étapes prévues pour y parvenir. Il ne remplace ni les plans détaillés de version ni les deltas de livraison.
+Le roadmap décrit les objectifs à atteindre et les grandes étapes prévues pour y parvenir. Une série `X.Y.x` regroupe une famille fonctionnelle de travaux ; elle peut contenir plusieurs releases concrètes et plusieurs sessions.
 
 ## Légende
 
@@ -11,189 +11,92 @@ Le roadmap décrit les objectifs à atteindre et les grandes étapes prévues po
 - `[/]` — en cours ;
 - `[X]` — réalisé et validé ;
 - `[C]` — annulé ;
-- `[R]` — reporté vers une autre phase ou version.
+- `[R]` — reporté.
 
-Une case `[X]` signifie que l'étape est considérée terminée selon ses critères de validation, et pas seulement qu'une modification a été écrite.
+## 0.0.x — Fondation
 
-## 0.0.x — Fondation de Khadhroony Solana Project
-
-### Objectifs
-
-Définir l'identité, les règles, les conventions, l'architecture initiale et le mode de travail de KSP avant le début du développement fonctionnel. La phase doit aboutir à un workspace initial cohérent, à un plan global suffisamment précis pour guider les premières versions de développement et à un prompt de reprise permettant d'ouvrir `0.1.x` sans réinventer les décisions fondatrices.
-
-### Étapes
-
-- [X] `0.0.1` — Initialiser le dépôt avec le `.gitignore` de base.
-- [X] `0.0.2` — Installer le squelette minimal, les règles initiales et les documents de cadrage nécessaires.
-- [/] `0.0.3` — Définir les objectifs produits, domaines fonctionnels, couches, responsabilités, dépendances, contrats publics, applications/workers/jobs/demos et plan global de développement.
+- [X] `0.0.1` — Initialiser le dépôt.
+- [X] `0.0.2` — Installer le squelette minimal et les règles initiales.
+- [/] `0.0.3` — Définir domaines, composants, dépendances, contrats, workers/jobs/scénarios/apps et plan global.
 - [/] Construire progressivement le prompt de démarrage `0.1.x`.
-- [ ] Clôturer la phase fondatrice avec les documents finaux, le squelette nécessaire et le prompt final permettant d'ouvrir `0.1.x`.
+- [ ] Clôturer la fondation avec documentation, validations et prompt final.
 
-### Status
-
-En cours.
-
-## 0.1.x — Fondations KSP
+## 0.1.x — Fondations N1
 
 ### Objectifs
 
-Construire les premières fondations réellement transversales et valider le principe selon lequel une application spécialisée reste une interface au-dessus de la bibliothèque qu'elle manipule.
+Regrouper les releases consacrées aux fondations N1. La série n'est pas destinée à tenir dans une seule session : chaque release concrète (`0.1.1`, `0.1.2`, etc.) sera dimensionnée séparément.
 
 ### Étapes
 
-- [ ] Stabiliser les premiers contrats de `ksp-core-lib`, dont le type d'erreur commun et les Program IDs.
+- [ ] Stabiliser `ksp-core-lib`, dont `Error` et Program IDs.
 - [ ] Introduire `ksp-logging-lib`.
 - [ ] Introduire `ksp-config-lib`.
-- [ ] Introduire `ksp-app-config-desk` comme interface de lecture/modification des paramètres autorisés.
-- [ ] Définir suffisamment tôt les premiers contrats publics nécessaires aux couches suivantes sans implémenter prématurément leurs fonctionnalités.
-
-### Status
-
-Planifié.
+- [ ] Introduire `ksp-app-config-desk`.
+- [ ] Définir au besoin les premiers contrats publics requis par les couches suivantes sans anticiper leur implémentation complète.
 
 ## 0.2.x — Accès Solana et fondation programmes
 
-### Objectifs
-
-Fournir les transports et identités nécessaires pour interagir avec Solana, établir la façade wire KSP et exposer les premiers contrats publics extensibles de décodage/exécution.
-
-### Étapes
-
-- [ ] Introduire `ksp-onchain-transport-lib`.
-- [ ] Introduire `ksp-wallet-lib`.
-- [ ] Introduire `ksp-app-wallet-desk`.
+- [ ] Introduire `ksp-onchain-transport-lib` avec des modèles de transport homogènes indépendants du store.
+- [ ] Introduire `ksp-wallet-lib` et `ksp-app-wallet-desk`.
 - [ ] Développer la première surface utile de `ksp-interface-lib`.
-- [ ] Introduire `ksp-program-api` comme contrat public extensible des decoders/executors.
-- [ ] Introduire `ksp-program-lib` comme implémentation officielle intégrée des programmes supportés.
-- [ ] Garantir que les contrats `ksp-program-api` puissent être implémentés et testés depuis des crates séparées sans dépendre de `ksp-program-lib`.
-- [ ] Introduire `ksp-offchain-transport-lib` seulement si un besoin concret apparaît pendant cette phase.
-
-### Status
-
-Planifié.
+- [ ] Introduire `ksp-program-api` puis `ksp-program-lib`.
+- [ ] Étudier/introduire `ksp-execution-policy-api` et `ksp-execution-lib` selon le graphe validé.
+- [ ] Ne pas créer `ksp-onchain-transport-api` ni `ksp-wallet-api` sans nouveau besoin concret.
+- [ ] Introduire `ksp-offchain-transport-lib` seulement au premier besoin réel.
 
 ## 0.3.x — Données, stockage et acquisition raw
 
-### Objectifs
-
-Mettre en place les contrats de matérialisation et de stockage, l'acquisition raw live/quasi-live et des jobs historiques/ponctuels séparés des workers continus.
-
-### Étapes
-
-- [ ] Introduire `ksp-materializer-api` comme contrat public/extensible de matérialisation.
-- [ ] Introduire `ksp-materializer-lib` comme implémentation officielle des materializers KSP.
-- [ ] Introduire `ksp-store-api` comme frontière backend-agnostic et propriétaire des contrats canoniques de notification de données persistées.
-- [ ] Introduire `ksp-store-lib` avec PostgreSQL comme implémentation de référence.
+- [ ] Introduire `ksp-materializer-api` / `ksp-materializer-lib`.
+- [ ] Introduire `ksp-store-api` / `ksp-store-lib` avec PostgreSQL de référence.
 - [ ] Introduire `ksp-app-store-desk`.
-- [ ] Introduire W1 pour l'acquisition raw live/quasi-live uniquement.
-- [ ] Permettre à W1 de modifier à chaud ce qu'il écoute/rapatrie/stocke.
-- [ ] Introduire `ksp-worker-api` pour les contrats communs des workers sans y inclure les jobs.
-- [ ] Introduire les premières capacités de contrôle/manager de W1, avec `ksp-worker-control-lib` comme candidat d'implémentation lorsque nécessaire.
-- [ ] Introduire `ksp-job-api` pour les contrats communs des jobs, séparément des workers.
-- [ ] Introduire `ksp-job-backfill` comme job historique à la demande, avec checkpoint/reprise et gouvernance propres.
-- [ ] Utiliser les mêmes contrats de notification de données pour une même donnée, qu'elle provienne de W1, d'un backfill ou d'une autre source.
-
-### Status
-
-Planifié.
+- [ ] Introduire `ksp-worker-api` et `ksp-worker-raw-retriever`.
+- [ ] Introduire `ksp-worker-control-lib` lorsque le manager W1 crée le premier besoin concret.
+- [ ] Introduire `ksp-job-api` et `ksp-job-backfill`.
+- [ ] Normaliser les notifications de données persistées indépendamment de leur producteur.
 
 ## 0.4.x — Baseline Solana, SPL et metadata
 
-### Objectifs
-
-Commencer la couverture fonctionnelle des programmes nécessaires à l'objectif trading court terme et aux couches suivantes, en validant décodage, exécution technique, matérialisation et scénarios spécialisés.
-
-### Étapes
-
-- [ ] Ajouter les premiers decoders/executors Solana Core utiles.
-- [ ] Ajouter les premières surfaces SPL utiles : Token, Token-2022, ATA et autres besoins identifiés.
-- [ ] Ajouter les metadata d'assets/tokens nécessaires.
-- [ ] Introduire `ksp-offchain-transport-lib` au plus tard au premier besoin réel externe.
-- [ ] Ajouter les materializers correspondants.
-- [ ] Ajouter les jobs ponctuels nécessaires, par exemple metadata/off-chain, uniquement lorsqu'un besoin concret le justifie.
-- [ ] Ajouter les tools/scénarios de validation spécialisés dans des crates séparées par domaine cohérent.
-- [ ] Maintenir les demos/scénarios Memo, Token, ATA et Token-2022 séparés.
-- [ ] Permettre une famille metadata commune pour Metaplex Token Metadata + Token-2022 Metadata.
-- [ ] Maintenir Solana Program Metadata dans une famille distincte.
-
-### Status
-
-Planifié.
+- [ ] Ajouter progressivement les decoders/executors Core/SPL nécessaires.
+- [ ] Ajouter Token, Token-2022, ATA et metadata utiles.
+- [ ] Introduire `ksp-offchain-transport-lib` au plus tard au premier besoin externe.
+- [ ] Ajouter materializers et jobs ponctuels nécessaires.
+- [ ] Ajouter les crates `ksp-scenario-<domain>-lib` spécialisées.
+- [ ] Ajouter les demos `ksp-app-scenario-<domain>-<environment>-desk-demo` correspondantes.
+- [ ] Garder Memo, Token, ATA, Token-2022 séparés ; regrouper uniquement Metaplex Token Metadata + Token-2022 Metadata dans la famille metadata ; garder SPM séparé.
 
 ## 0.5.x — Anchor et protocoles trading
 
-### Objectifs
-
-Étendre progressivement KSP vers Anchor et les protocoles/infrastructures nécessaires à l'analyse et au trading Solana, une surface cohérente et bornée par release.
-
-### Étapes
-
-- [ ] Introduire la fondation Anchor.
-- [ ] Étendre progressivement Meteora par surfaces distinctes.
-- [ ] Étendre progressivement Raydium par surfaces distinctes.
+- [ ] Introduire Anchor.
+- [ ] Étendre Meteora par surfaces bornées.
+- [ ] Étendre Raydium par surfaces bornées.
 - [ ] Ajouter progressivement Pump, Orca, Jupiter, OKX et autres intégrations utiles.
-- [ ] Ajouter pour chaque surface les interfaces, decoders/executors, materializers, jobs éventuels, scénarios et validations nécessaires.
-- [ ] Maintenir l'ordre précis des releases adaptable aux dépendances découvertes et aux priorités du trading court terme.
-
-### Status
-
-Planifié.
+- [ ] Ajouter interfaces, program implementations, materializers, jobs/scénarios/demos nécessaires pour chaque surface.
 
 ## 0.6.x — Processing autonome et orchestration
 
-### Objectifs
-
-Introduire le processing continu des données acquises, la gouvernance de plusieurs workers et une application globale de supervision sans déplacer leur logique dans l'interface.
-
-### Étapes
-
-- [ ] Introduire W2 pour les traitements live de décodage/matérialisation selon les contrats alors stabilisés.
-- [ ] Réutiliser `ksp-worker-api` pour les contrats communs des workers.
-- [ ] Introduire/étendre `ksp-worker-control-lib` lorsque plusieurs workers justifient un contrôle commun.
-- [ ] Garder les contrats et contrôles des jobs séparés de ceux des workers.
-- [ ] Introduire un orchestrateur commun lorsque plusieurs managers/workers le justifient.
-- [ ] Introduire une application globale de supervision et contrôle.
-- [ ] Exposer les états, health, backlog, erreurs, reprises et commandes nécessaires sans dupliquer la logique des workers/jobs.
-
-### Status
-
-Planifié.
+- [ ] Introduire `ksp-worker-core-processor` pour raw -> Core canonique.
+- [ ] Introduire `ksp-worker-generic-materializer` pour Core -> matérialisation générique.
+- [ ] Introduire `ksp-worker-domain-projector` pour les projections spécialisées ; nom révisable.
+- [ ] Étendre `ksp-worker-control-lib` à la gouvernance de plusieurs workers.
+- [ ] Garder jobs et workers sous des lifecycle APIs séparées.
+- [ ] Introduire un orchestrateur global lorsqu'il existe plusieurs managers/workers à coordonner.
+- [ ] Introduire l'application globale de supervision/contrôle.
 
 ## 0.7.x — Trading Intelligence
 
-### Objectifs
+- [ ] Statistiques et métriques.
+- [ ] Features et datasets historiques.
+- [ ] Signaux et risque.
+- [ ] Replay analytique/backtests.
+- [ ] Patterns/anomalies.
+- [ ] XGBoost puis autres modèles lorsque les contrats sont stables.
 
-Construire la couche d'analyse statistique et d'intelligence nécessaire aux futures automatisations de trading, avant de stabiliser l'application de trading proprement dite.
+## 0.8.x et suivantes — Trading opérationnel et expansion produits
 
-### Étapes
-
-- [ ] Définir statistiques et métriques utiles.
-- [ ] Définir les features et datasets historiques.
-- [ ] Définir les contrats de signal et risque.
-- [ ] Introduire replay analytique et backtests.
-- [ ] Détecter patterns et anomalies.
-- [ ] Intégrer XGBoost lorsque les contrats d'entrée/sortie sont suffisamment stables.
-- [ ] Préparer l'intégration d'autres modèles et les futures couches de décision/automatisation.
-
-### Status
-
-Planifié.
-
-## 0.8.x et suivantes — Extension continue et applications trading
-
-### Objectifs
-
-Poursuivre la couverture Solana, exploiter Trading Intelligence dans des couches de trading opérationnelles puis faire évoluer les autres produits au-dessus des mêmes contrats KSP.
-
-### Étapes
-
-- [ ] Étendre continuellement les Program IDs, interfaces, decoders/executors et materializers utiles.
-- [ ] Construire progressivement les couches de trading opérationnelles et l'application de trading monoposte.
+- [ ] Construire les couches puis l'application de trading monoposte au-dessus de Trading Intelligence.
 - [ ] Étendre l'automatisation de trading.
+- [ ] Étendre continuellement Program IDs, decoders/executors/materializers.
 - [ ] Construire progressivement l'explorer Solana.
 - [ ] Construire progressivement l'explorer/analyse DEX.
-- [ ] Étendre Trading Intelligence et les modèles disponibles.
-
-### Status
-
-Planifié.
+- [ ] Étudier plus tard d'autres applications utilisant `ksp-wallet-lib`, notamment mobile, extensions navigateur et web.