<!-- file: deltas/0.2.0/rel.001.md -->
<!-- version: 1 -->

# Delta `0.2.0-rel.001` — publication stable du cadrage `0.2.x`

## Base validée

La base requise est le commit :

```text
e721464a7c2cbf4c564757061a2a44dd7913facb
v0.2.0-pre.003
```

Le user a communiqué le 2026-08-17 les validations suivantes avec succès :

```bash
cargo fmt --all
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test --workspace
git diff --check
git status --short
```

`cargo test --workspace` exécute 241 tests avec succès ; le probe diagnostic d'overhead de `ksp-logging-lib` reste volontairement ignoré. `git diff --check` et `git status --short` ne produisent aucune sortie après le commit `pre.003`.

## Objet

Publier sous version stable le cadrage `0.2.0` déjà audité et validé, sans ajouter de capacité N2 ni modifier les décisions architecturales finalisées en `pre.003`.

## Changements

- `workspace.package.version` passe de `0.2.0-pre.3` à `0.2.0` ;
- `CHANGELOG.md` reçoit l'entrée stable `0.2.0` ;
- `ROADMAP.md` marque `0.2.0` et `0.2.0-pre.003` réalisés et enregistre `rel.001` ;
- l'index documentaire marque `007-V0_2_0_SERIES_PLANNING.md` comme plan historique clôturé ;
- la séquence fonctionnelle enregistre `0.2.0` stable et `0.2.1` comme prochaine release ;
- le plan `007` enregistre sa clôture par `rel.001` ;
- la matrice `docs/validation/002-V0_2_0_SERIES_PLANNING.md` enregistre les preuves opérateur finales de `pre.003` ;
- le prompt `prompts/006-V0_2_1_START_PROMPT.md` reste inchangé et devient le point d'entrée de la prochaine release après création du tag stable.

## Surface stable publiée

`0.2.0` stabilise notamment :

- l'ordre fonctionnel de `0.2.1+` : HTTP Solana -> Wallet -> Wallet Desk -> WebSocket standard -> Helius LaserStream WebSocket -> Yellowstone gRPC standard -> off-chain prix -> app prix -> Interface -> Program API ;
- `ksp-onchain-transport-lib` indépendant de `ksp-config-lib`, Store et Program, avec settings publics propres au transport et adapter Config -> Transport ;
- la règle de couverture exhaustive des méthodes/opérations documentées pour chaque surface Transport ciblée ;
- la conservation des méthodes deprecated/obsolete encore fonctionnelles avec warning KSP, et le warning KSP des méthodes unstable/experimental ;
- la progression durable `RAW -> CORE -> DECODE -> SPECIALIZED` ;
- RAW et CORE sans decoder Program, complétés horizontalement avec persistence/replay/jobs/workers/apps selon besoin ;
- à partir de DECODE, des vertical slices groupe par groupe : wire -> decode -> materialize -> specialized -> prepare -> policy -> execute -> scenario Devnet ;
- l'intégration des composants satellites dans leur groupe protocolaire, par exemple Meteora vaults avec Meteora et Pump fees avec Pump ;
- la priorité Solana Core -> SPL token/trading -> metadata token -> Anchor -> Meteora/Raydium/Pump/Orca -> Market Desk V1 -> Jupiter/OKX -> Market Desk V2 -> trading-adjacent -> décodage généraliste ;
- le gate de sizing : une prerelease vise environ 15–20 minutes et une release concrète doit rester clôturable dans une seule session de chat, sinon elle est redécoupée avant l'implémentation lourde.

## Hors périmètre

`0.2.0-rel.001` ne modifie pas :

- les crates Rust hors signal de version workspace ;
- `ksp-app-config-desk` runtime/frontend ;
- les versions `package.json` / `tauri.conf.json` de Config Desk ;
- les dépendances Cargo ;
- les contrats publics existants ;
- la configuration runtime ;
- le prompt `0.2.1` finalisé par `pre.003`.

Aucune nouvelle fonctionnalité N2 n'est introduite.

## Version technique

```text
workspace.package.version = "0.2.0"
```

## Validation de `rel.001`

Le delta modifie `Cargo.toml` et de la documentation, sans fichier Rust ni frontend/Tauri. Avant publication/tag, exécuter :

```bash
cargo fmt --all
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test --workspace
git diff --check
git status --short
```

Aucun `cargo tauri build` n'est requis : la version Tauri de `ksp-app-config-desk` reste `0.1.4` et aucun fichier de l'application n'est modifié par cette publication.

## Commit et tag

Après validation de `rel.001` :

```text
commit : v0.2.0-rel.001
tag    : v0.2.0
```

Seul le tag stable `v0.2.0` est attendu.

## Suite

Après création du tag `v0.2.0`, ouvrir :

```text
0.2.1-pre.001
```

avec :

```text
prompts/006-V0_2_1_START_PROMPT.md
```

`0.2.1` commence par audit de la documentation Solana HTTP actuelle, audit du transport bot3, matrice exhaustive des méthodes et gate de sizing avant toute implémentation fonctionnelle lourde.