Prompt de démarrage KSP 0.1.x

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.

1. Identité

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 ;
uniquement les contrats précoces strictement nécessaires aux étapes suivantes.

Ces objectifs pourront être répartis entre plusieurs releases 0.1.N.

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 à 008, 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 doit posséder les Program IDs fondamentaux et le type d'erreur commun.
ksp-logging-lib est la façade KSP propriétaire de tracing, tracing-appender et tracing-subscriber; elle peut dépendre de Core pour Error / Result, tandis que Core n'a pas de dépendance logging requise.
Les dépendances basses suivent le graphe de docs/architecture/005-DEPENDENCY_GRAPH.md ; N1 ne doit pas dépendre de ses consommateurs supérieurs.
KSP évite les générations anciennes/dupliquées évitables de dépendances fondamentales ; toute contrainte de version non actuelle doit être motivée par un besoin réel.
Les règles fines de naming/arborescence/API publique seront définies à partir des premières APIs réelles.

7. Hors périmètre de la série N1

Sauf contrat minimal nécessaire au futur : program implementations, wallet, transport, materializers/store, workers/jobs, protocoles trading et Trading Intelligence.

8. Travail à effectuer avant démarrage

Pendant 0.0.3-pre.007/pre.008 :

choisir la première release concrète de 0.1.x ;
lui donner une mission unique/cohérente ;
produire son plan pre.001 ;
vérifier sa charge ;
compléter ce prompt avec la version, l'état validé, les sources et validations exactes.

9. Validations générales attendues

Lorsque du code Rust est introduit :

cargo fmt --all
cargo check --workspace
cargo test --workspace
cargo clippy --workspace --all-targets

Aucune validation non exécutée ne doit être déclarée réussie.

3.5 KiB Raw Blame History Unescape Escape