v0.0.3-pre.002

prompts/001-V0_1_X_START_PROMPT.md

@@ -1,64 +1,70 @@
 <!-- file: prompts/001-V0_1_X_START_PROMPT.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Prompt de démarrage KSP 0.1.x
 
-**Status : Brouillon vivant — ne pas utiliser comme prompt final tant que `0.0.3` n'est pas clôturée.**
+**Status : Brouillon vivant — prompt de démarrage de la série N1, à finaliser avec la première release concrète avant clôture de `0.0.3`.**
 
-## Mission provisoire
+## 1. Identité
 
-Commencer le développement fonctionnel KSP sur les fondations N1 nécessaires au reste du projet, principalement :
+Série fonctionnelle : `0.1.x` — fondations N1.
+
+`0.1.x` ne représente pas une seule session. La planification finale doit choisir la première release concrète (`0.1.1` ou autre) et lui donner un périmètre compatible avec une session de qualité.
+
+## 2. Mission de la série
+
+Construire progressivement :
 
 - `ksp-core-lib` ;
 - `ksp-logging-lib` ;
 - `ksp-config-lib` ;
-- `ksp-app-config-desk`.
+- `ksp-app-config-desk` ;
+- uniquement les contrats précoces strictement nécessaires aux étapes suivantes.
 
-## Décisions déjà acquises
+Ces objectifs pourront être répartis entre plusieurs releases `0.1.N`.
 
-- Le développement fonctionnel commence en `0.1.x`.
-- Chaque delta est commité à partir de cette série.
-- Les bibliothèques d'implémentation réutilisables utilisent `ksp-<role>-lib`.
-- Les crates de contrats publics extensibles utilisent `ksp-<domain>-api`, sans suffixe `-lib`.
-- Une crate `*-api` n'est pas une implémentation directement destinée à être appelée par un exécutable.
-- Éviter un `ksp-api-lib` monolithique ; les APIs restent séparées par domaine.
-- `ksp-program-api`, `ksp-materializer-api` et `ksp-store-api` sont les premiers contrats d'extension prévus.
-- Les workers et jobs possèdent des APIs communes séparées : `ksp-worker-api` et `ksp-job-api`.
-- Les notifications de données restent indépendantes du worker/job producteur ; `ksp-store-api` est le propriétaire candidat des notifications de données persistées.
-- `ksp-store-lib` contient PostgreSQL comme implémentation de référence.
-- Les applications restent des interfaces/compositions au-dessus des composants KSP.
+## 3. Base requise
+
+À finaliser à la clôture de `0.0.3`.
+
+## 4. État validé à préserver
+
+À compléter à la clôture de `0.0.3`.
+
+## 5. Sources de vérité
+
+Relire au minimum `RULES.md`, `ROADMAP.md`, `docs/000-README.md`, `docs/rules/PROMPT_STRUCTURE.md`, les documents d'architecture `001` à `004`, le plan de version actif et les questions pertinentes de `docs/IDEAS.md`.
+
+## 6. Décisions acquises pertinentes
+
+- Chaque delta est commité à partir de `0.1.x`.
+- Une série `0.1.x` peut contenir plusieurs releases/sessions.
+- Chaque release concrète commence par `pre.001` de brainstorming/planification.
+- Une prerelease intermédiaire estimée au-delà d'environ 15–20 minutes doit être scindée.
+- Une release concrète trop grosse doit être répartie sur plusieurs releases de la même série plutôt que forcer toute la série dans une session.
+- Les bibliothèques d'implémentation utilisent `ksp-<role>-lib` ; les APIs extensibles utilisent `ksp-<domain>-api` uniquement lorsqu'un besoin réel le justifie.
+- Les applications restent des interfaces/compositions.
 - Les exécutables ne dépendent pas directement de crates Solana/protocoles externes.
-- `ksp-core-lib`, `ksp-config-lib`, `ksp-logging-lib` et `ksp-interface-lib` sont des fondations N1.
-- `ksp-core-lib` doit posséder les Program IDs fondamentaux et un type d'erreur public commun.
-- Les règles fines de nommage des items publics/arborescence seront définies à partir des premières APIs réelles.
-- Les prereleases intermédiaires sont planifiées comme des tranches bornées d'environ 15–20 minutes maximum de travail effectif estimé.
-- Si le plan complet de `0.1.x` risque de saturer une seule session, il doit être réparti sur plusieurs sessions et/ou versions avant développement.
+- `ksp-core-lib` doit posséder les Program IDs fondamentaux et le type d'erreur commun.
+- Les règles fines de naming/arborescence/API publique seront définies à partir des premières APIs réelles.
 
-## Objectifs provisoires
+## 7. Hors périmètre de la série N1
 
-1. Stabiliser le premier contrat utile de `ksp-core-lib`.
-2. Définir le modèle commun `Error` sans rendre N1 dépendant des domaines supérieurs.
-3. Intégrer les Program IDs fondamentaux dans `ksp-core-lib`.
-4. Créer `ksp-logging-lib`.
-5. Créer `ksp-config-lib`.
-6. Créer `ksp-app-config-desk` comme interface de manipulation de la configuration.
-7. Ajouter les règles API/naming/arborescence rendues nécessaires par les premiers vrais contrats.
-8. Préparer uniquement les contrats minimaux requis pour `0.2.x` lorsque leur définition précoce est utile.
+Sauf contrat minimal nécessaire au futur : program implementations, wallet, transport, materializers/store, workers/jobs, protocoles trading et Trading Intelligence.
 
-## Hors périmètre provisoire
+## 8. Travail à effectuer avant démarrage
 
-- implémentation réelle de `ksp-program-api` / `ksp-program-lib` au-delà des contrats strictement nécessaires ;
-- implémentation complète de `ksp-interface-lib` ;
-- wallet ;
-- transport on-chain ;
-- storage/materializers ;
-- workers/jobs ;
-- protocoles trading ;
-- Trading Intelligence.
+Pendant `0.0.3-pre.007/pre.008` :
 
-## Validations attendues
+1. choisir la première release concrète de `0.1.x` ;
+2. lui donner une mission unique/cohérente ;
+3. produire son plan `pre.001` ;
+4. vérifier sa charge ;
+5. compléter ce prompt avec la version, l'état validé, les sources et validations exactes.
 
-Au minimum, lorsque du code Rust est introduit :
+## 9. Validations générales attendues
+
+Lorsque du code Rust est introduit :
 
 ```bash
 cargo fmt --all