<!-- file: prompts/001-V0_1_X_START_PROMPT.md -->
<!-- version: 8 -->

# 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` :

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.

## 9. Validations générales attendues

Lorsque du code Rust est introduit :

```bash
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.