v0.0.3-pre.002

docs/plans/001-V0_0_3_PLAN.md

@@ -1,101 +1,87 @@
 <!-- file: docs/plans/001-V0_0_3_PLAN.md -->
-<!-- version: 5 -->
+<!-- version: 6 -->
 
 # Plan KSP 0.0.3
 
 ## Mission
 
-Poursuivre la phase fondatrice sans développement fonctionnel afin de transformer le brainstorming KSP en architecture, règles, nomenclature et plan de développement suffisamment précis pour ouvrir `0.1.x`.
+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é.
 
-## Décisions structurantes acquises
+## État courant
 
-- Les bibliothèques d'implémentation utilisent `ksp-<role>-lib`.
-- Les crates de contrats publics extensibles utilisent `ksp-<domain>-api`, sans suffixe `-lib`.
-- Éviter un `ksp-api-lib` monolithique.
-- Couples API/implémentation retenus : program, materializer, store.
-- `ksp-store-lib` contient PostgreSQL comme implémentation de référence de `ksp-store-api`.
-- Les workers continus utilisent `ksp-worker-api`.
-- Les jobs à la demande utilisent `ksp-job-api`.
-- Workers et jobs ne partagent pas une abstraction de lifecycle commune.
-- W1 est strictement raw live/quasi-live et ne fait pas de backfill.
-- Le backfill historique est un job séparé, candidat `ksp-job-backfill`.
-- D'autres jobs pourront exister pour metadata, quotes et autres tâches ponctuelles.
-- Les notifications de données sont normalisées indépendamment de leur producteur ; `ksp-store-api` est le propriétaire candidat des notifications de données persistées.
-- `ksp-worker-control-lib` est le candidat pour une implémentation commune de contrôle des workers uniquement.
-- Aucun `ksp-pipeline-lib` monolithique ; pipelines séparés à la demande.
-- Aucun `ksp-scenarios-lib` monolithique ; scénarios séparés par crates de domaine.
-- Trading Intelligence précède la couche/application de trading opérationnelle.
+`pre.001` est considérée stabilisée et commitée comme `v0.0.3-pre.001`.
 
-## Ligne directrice du développement fonctionnel
+`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é.
 
-- `0.1.x` — `ksp-core-lib`, `ksp-logging-lib`, `ksp-config-lib`, `ksp-app-config-desk`.
-- `0.2.x` — `ksp-onchain-transport-lib`, wallet, `ksp-interface-lib`, `ksp-program-api`, `ksp-program-lib`.
-- `0.3.x` — `ksp-materializer-api`, `ksp-materializer-lib`, `ksp-store-api`, `ksp-store-lib`, W1, `ksp-worker-api`, `ksp-job-api`, backfill.
-- `0.4.x` — premières surfaces Core/SPL/metadata, matérialisations, off-chain transport selon besoin, jobs/scénarios/demos spécialisés.
-- `0.5.x` — Anchor puis protocoles trading par releases bornées.
-- `0.6.x` — W2, contrôle workers, managers, orchestrateur et application globale.
-- `0.7.x` — Trading Intelligence.
-- `0.8.x+` — couche/application trading, extension continue, explorer Solana et explorer/analyse DEX.
+## Décisions structurantes actuelles
 
-## Prévision souple des prereleases 0.0.3
+- `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.
 
-### `pre.001` — Base de planification
+## Prévision souple des prereleases restantes
 
-Considérée stabilisée après les fixes de cadrage.
+### `pre.002` — Inventaire initial des composants
 
-### `pre.002` — Domaines et crates candidates
+- 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`.
 
-- inventorier les domaines fonctionnels ;
-- fixer les couples `*-api` / `*-lib` réellement justifiés ;
-- définir workers vs jobs ;
-- définir les responsabilités des notifications de données ;
-- inventorier les scénarios/pipelines spécialisés ;
-- définir pour chaque crate candidate responsabilité, niveau, entrées/sorties et consommateurs ;
-- mettre à jour le brouillon de prompt `0.1.x`.
+### `pre.003` — Graphe de dépendances et correction de l'inventaire
 
-### `pre.003` — Graphe de dépendances
+- 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.
 
-- construire le graphe de dépendances autorisées/interdites ;
-- identifier les propriétaires des dépendances Solana externes ;
-- vérifier les risques de cycles ;
-- positionner précisément les crates `*-api` ;
-- préciser les dépendances autorisées de `ksp-program-api`, `ksp-materializer-api`, `ksp-store-api`, `ksp-worker-api` et `ksp-job-api`.
+### `pre.004` — Programmes, wire et exécution
 
-### `pre.004` — Programmes, décodage 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.
 
-- détailler `ksp-program-api` et `ksp-program-lib` ;
-- définir les interfaces wire et leur source de vérité ;
-- cadrer les tests de conformité ;
-- définir le niveau supérieur propriétaire de la sécurité d'exécution ;
-- traiter Metaplex/ElGamal comme exemples architecturaux sans développement fonctionnel.
+### `pre.005` — Données, store et acquisitions
 
-### `pre.005` — Données, storage 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.
 
-- détailler `ksp-materializer-api` / `ksp-materializer-lib` ;
-- détailler `ksp-store-api` / `ksp-store-lib` ;
-- finaliser W1, `ksp-worker-api` et ses notifications de données ;
-- détailler `ksp-job-api` et le backfill ;
-- cadrer W2 sans l'implémenter ;
-- définir les frontières backend et replay/reconstruction.
+### `pre.006` — Applications, workers, jobs, scenarios et pipelines spécialisés
 
-### `pre.006` — Applications, workers, jobs, demos et scénarios
+- 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.
 
-- formaliser config/store/wallet apps ;
-- finaliser la nomenclature réseau/environnement ;
-- détailler les crates de scénarios spécialisées ;
-- détailler managers workers/jobs et trajectoire vers l'orchestrateur ;
-- inventorier les pipelines spécialisés nécessaires sans crate pipeline monolithique.
+### `pre.007` — Plan des premières releases fonctionnelles
 
-### `pre.007` — Plan de développement et contrôle de charge
-
-- affiner le roadmap fonctionnel `0.1.x+` ;
-- détailler le premier plan `0.1.x` ;
-- transformer le brouillon de prompt en quasi-version finale ;
-- vérifier et redécouper la charge de la session suivante si nécessaire.
+- 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
 
-- vérifier la cohérence règles/architecture/plans ;
-- mettre à jour la documentation finale ;
-- nettoyer/archiver les éléments temporaires ;
-- finaliser le prompt de reprise `0.1.x`.
+- 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.