<!-- file: deltas/0.0.3/pre.009.md -->
<!-- version: 1 -->

# Delta 0.0.3-pre.009

## Base requise

`v0.0.3-pre.008`.

## Objectif

Transformer le roadmap fonctionnel en une première séquence de releases concrètes, sélectionner `0.1.1` et produire son prompt quasi-final sans sur-numéroter prématurément les séries futures.

## Version Cargo

`workspace.package.version` passe de :

```text
0.0.3-pre.8
```

à :

```text
0.0.3-pre.9
```

Le header de `Cargo.toml` passe de version 14 à 15.

## Fichiers ajoutés

- `docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md`
- `prompts/001-V0_1_1_START_PROMPT.md`
- `deltas/0.0.3/pre.009.md`

## Fichiers modifiés

- `Cargo.toml`
- `ROADMAP.md`
- `docs/architecture/004-COMPONENT_INVENTORY.md`
- `docs/plans/001-V0_0_3_PLAN.md`
- `docs/rules/RULES_KSP.md`
- `docs/IDEAS.md`

## Fichiers supprimés

- `prompts/001-V0_1_X_START_PROMPT.md`

La suppression est explicite dans ce delta : le nouveau prompt `V0_1_1` remplace le brouillon générique.

## Décisions principales

### Première release

La première release fonctionnelle est fixée :

```text
0.1.1 — ksp-core-lib
```

Mission : stabiliser le contrat Core N1 sans ouvrir les couches supérieures.

### `0.1.x`

Séquence par défaut :

```text
0.1.1  Core
0.1.2  Logging
0.1.3  Config
0.1.4  Config desktop
```

`0.1.1` et `0.1.2` sont fixées.

Si `0.1.3-pre.001` démontre que Config doit être scindé, une release est insérée et l'app Config est décalée.

### `0.1.1`

Périmètre candidat :

- `ksp_core_lib::Error` ;
- `Result<T>` ou équivalent ;
- Program IDs fondamentaux ;
- primitives N1 réellement nécessaires ;
- API/reexports/tests/docs.

`ksp-core-lib` ne dépend pas de Logging/Config ni des couches Solana supérieures.

### `0.1.2`

`ksp-logging-lib` dépend de Core et possède directement :

- `tracing` ;
- `tracing-appender` ;
- `tracing-subscriber`.

Il expose sa façade/settings sans dépendre de Config.

### `0.1.3` / `0.1.4`

Config puis son app desktop spécialisée constituent la séquence par défaut.

L'app sert de validation réelle de Config et de la frontière Tauri.

### Séries futures

`0.2.x+` reste ordonné fonctionnellement mais n'est pas numéroté finement.

Cette politique évite de figer des numéros qui seront probablement modifiés par les dépendances réelles découvertes pendant les premières releases.

### Git

À partir de `0.1.x`, chaque delta est commité.

Une étape erronée reste dans l'historique et est corrigée par un delta suivant.

Seul le commit stable reçoit le tag `vX.Y.Z`.

### Lifecycle

Le premier `pre.001` d'une release fonctionnelle est une phase de brainstorming/audit/plan détaillé/dimensionnement.

La dernière prerelease réalise validations finales, documentation, nettoyage/archivage, changelog et prompt de la release suivante.

### Prompt

Le brouillon :

```text
prompts/001-V0_1_X_START_PROMPT.md
```

est remplacé par :

```text
prompts/001-V0_1_1_START_PROMPT.md
```

Le nouveau prompt est quasi-final et sera seulement confirmé/corrigé en clôture `pre.010`.

## Plan restant

### `pre.010`

- audit global final ;
- cohérence docs/règles/architecture/roadmap/plans ;
- validations workspace applicables ;
- nettoyage/archivage ;
- changelog si disponible dans la base ;
- finalisation du prompt `0.1.1` ;
- préparation de la release stable `0.0.3`.

`pre.010` ne doit pas rouvrir une tranche de brainstorming architectural sauf incohérence critique.

## Validations

- headers `file:` / `version:` vérifiés ;
- `Cargo.toml` parsé et version `0.0.3-pre.9` vérifiée ;
- `ROADMAP.md` contient les releases concrètes `0.1.1`–`0.1.4` par défaut ;
- `docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md` ajouté ;
- prompt `V0_1_1` ajouté et ancien prompt `V0_1_X` déclaré supprimé ;
- première release `0.1.1` cohérente avec la dépendance `ksp-logging-lib -> ksp-core-lib` ;
- numérotation fine `0.2.x+` laissée volontairement ouverte ;
- plan `pre.010` limité à la clôture ;
- aucune commande Cargo build/test exécutée : ce delta reste documentaire.