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

# 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.**

## Mission provisoire

Commencer le développement fonctionnel KSP sur les fondations N1 nécessaires au reste du projet, principalement :

- `ksp-core-lib` ;
- `ksp-logging-lib` ;
- `ksp-config-lib` ;
- `ksp-app-config-desk`.

## Décisions déjà acquises

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

## Objectifs provisoires

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.

## Hors périmètre provisoire

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

## Validations attendues

Au minimum, 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.