v0.2.12-pre.011

CHANGELOG.md

@@ -1,8 +1,18 @@
 <!-- file: CHANGELOG.md -->
-<!-- version: 15 -->
+<!-- version: 16 -->
 
 # Changelog KSP
 
+## 0.2.12 — SOL Prices Desk + projection prix Wallet — 2026-08-27
+
+`0.2.12` ajoute `ksp-app-solprices-desk`, troisième Desk Tauri spécialisé de KSP, comme HID strictement provider-neutral au-dessus de `ksp-offchain-transport-lib`. Son composite dédié sélectionne `std.logging` et `std.offchain_transport`; la vue Prices expose l’inventaire des huit providers SOL/USD, disponibilité, sémantique, auth, prix exact sous forme de chaîne, timestamps provider/KSP distincts et retry deadline sans inventer de fraîcheur. Les refresh manuel individuel, sélectionné et global passent exclusivement par `MarketPriceService`; les batchs sont bornés à `1..=64`, les états `in_flight` restent backend-owned et aucun polling, scheduler, fallback, moyenne ou prix canonique n’est introduit dans le Desk. Le frontend conserve l’absence de réseau/persistence navigateur et journalise les interactions sans prix, credential, URL, header ou payload provider.
+
+La même release étend `ksp-app-wallet-desk` de façon volontairement minimale. Le refresh de balance lance `getBalance` et le refresh SOL/USD générique, puis calcule côté Rust une moyenne arithmétique uniquement à partir des observations réussies du refresh courant et l’équivalent USD exact du solde, sans `f64`/`f32`. Le prix reste auxiliaire : une indisponibilité Off-chain n’invalide jamais une balance Solana réussie et produit simplement `N.A.`. Le Wallet ne connaît aucun provider concret, n’expose aucune commande Market Price dédiée au frontend et n’ajoute aucune valorisation persistée ou logique de consensus.
+
+Le hardening final ajoute une garde IPC hostile avant parsing pour les sélections de plus de 64 providers, un smoke live de composition `SOL Prices composite -> Config -> MarketPriceService -> refresh_all`, les canaris de frontières et les builds Tauri Linux. `pre.009-fix.001` corrige en outre la politique de version desktop : la version KSP/bundle est Cargo-owned, `tauri.conf.json` omet désormais `version` et les `package.json` privés ne sont plus forcés à suivre chaque bump workspace. Le gate opérateur passe audits Rust/Markdown, `cargo check`, Clippy, tests ciblés, `cargo test --workspace`, smoke live, puis builds `.deb`/`.rpm`/`.AppImage` pour SOL Prices, Wallet et Config Desk.
+
+La clôture documentaire réconcilie README/USAGE, architectures, plan et validation, puis prépare `prompts/018-V0_2_13_START_PROMPT.md`. Ce prompt ouvre `0.2.13 — Interface foundation` exclusivement depuis le tag stable `v0.2.12`. Une reconnaissance préalable de l’archive historique `khadhroony-bot3` fournit des idées de contrats wire et d’extension, mais `0.2.13-pre.001` doit les réauditer contre l’architecture KSP actuelle avant toute implémentation : `ksp-interface-lib` porte les données/wires publics, `ksp-program-api` reste réservé au comportement extensible de `0.2.14`, et les implémentations officielles `ksp-program-lib` arrivent plus tard.
+
 ## 0.2.11 — Off-chain price transport — 2026-08-26
 
 `0.2.11` crée `ksp-offchain-transport-lib` avec une première surface volontairement bornée à **SOL/USD** et huit adapters REST V1 : CoinGecko, CoinMarketCap, CoinPaprika, Kraken, Coinbase Exchange, Jupiter Price V3, Birdeye et DexScreener. Les adapters utilisent `reqwest` directement, sans SDK provider, avec origines HTTPS possédées par la crate, DTOs wire privés et prix normalisés par `MarketPriceDecimal` sans passage canonique par `f64`. `MarketPriceObservation` conserve paire, sémantique, provenance et timestamps réellement disponibles afin de ne pas confondre prix agrégé, dernier trade d'exchange, heuristique Solana, spot provider et prix DEX pair. DexScreener exige une paire Solana explicite et ne réalise aucune discovery ou sélection automatique de pool.

Cargo.toml

@@ -1,12 +1,12 @@
 # file: Cargo.toml
-# version: 300
+# version: 301
 
 [workspace]
 resolver = "3"
 members = ["crates/ksp-app-config-desk", "crates/ksp-app-solprices-desk", "crates/ksp-app-wallet-desk", "crates/ksp-config-lib", "crates/ksp-core-lib", "crates/ksp-logging-lib", "crates/ksp-offchain-transport-lib", "crates/ksp-onchain-transport-lib", "crates/ksp-wallet-lib"]
 
 [workspace.package]
-version = "0.2.12-pre.10"
+version = "0.2.12-pre.11"
 edition = "2024"
 license = "MIT"
 repository = "https://git.sasedev.com/Sasedev/khadhroony-solana-project"

ROADMAP.md

@@ -1,5 +1,5 @@
 <!-- file: ROADMAP.md -->
-<!-- version: 89 -->
+<!-- version: 90 -->
 
 # Roadmap KSP
 
@@ -56,9 +56,9 @@ Le roadmap décrit les objectifs à atteindre et les grandes étapes prévues. U
 - [X] `0.2.9` — Yellowstone gRPC standard/provider-neutral stable : moteur Tonic/Protobuf KSP partagé, sept unary standard retenues, `Subscribe` bidi et neuf variantes d’update, lifecycle/backpressure/reconnect/replay bornés sans promesse lossless, Config Transport V3 backward V1/V2 avec provider/protocol séparés, profils PublicNode Mainnet/Testnet authentifiés par `x-token`, smoke live `Subscribe -> Slot` 2/2 PASS et graphes Cargo finaux inspectés ; `SubscribeDeshred` reste hors scope.
 - [X] `0.2.10` — OrbitFlare Yellowstone gRPC stable : profil Config V3 Devnet, License Key injectée comme metadata secrète `x-token`, smoke live `Subscribe -> Slot + Ping` validé deux fois, sans modification du moteur N1/N2 ni heartbeat provider.
 - [X] `0.2.11` — Off-chain price transport stable : `ksp-offchain-transport-lib` expose SOL/USD via huit adapters REST `reqwest` sans SDK provider, décimal exact, sémantiques/provenance explicites, registry/availability/rate limits et refresh single/many/all génériques ; Config `std.offchain_transport` construit le service sans dépendance inverse, DexScreener reste lié à une paire explicite sans discovery, aucun consensus/fallback automatique n’est introduit, et le smoke live keyless final passe 7/7 après correction CoinMarketCap V2.
-- [ ] `0.2.12` — Introduire `ksp-app-solprices-desk` comme HID provider-agnostic consommant uniquement `ksp-offchain-transport-lib`, avec tableau prix/provider et refresh individuel/multiple ; puis intégrer cette capacité dans `ksp-app-wallet-desk` sans dupliquer la logique de récupération/normalisation.
+- [X] `0.2.12` — SOL Prices Desk + projection prix Wallet stables : HID provider-neutral avec refresh row/selected/all et batch `1..=64`, observations/timestamps exacts sans polling/consensus, puis refresh balance Wallet enrichi d’une moyenne SOL/USD consumer-owned et d’un équivalent USD exact best-effort ; smoke live de composition, workspace complet et bundles Tauri Linux validés.
-- [ ] `0.2.13` — Introduire la première surface de `ksp-interface-lib`, comprenant une API wire publique utilisable par les implémentations officielles et externes.
+- [ ] `0.2.13` — Introduire la première surface de `ksp-interface-lib`, façade wire KSP publique et passive utilisable par les implémentations officielles et externes ; `pre.001` doit confronter l’architecture actuelle aux contrats utiles de l’ancien `khadhroony-bot3` sans recréer son monolithe `ks-lib`, et séparer explicitement données wire, comportement Program et implémentations.
-- [ ] `0.2.14` — Introduire `ksp-program-api` comme premier contrat Program extensible, sans imposer encore `ksp-program-lib` complet.
+- [ ] `0.2.14` — Introduire `ksp-program-api` comme premier contrat Program extensible, sans imposer encore `ksp-program-lib` complet ; les traits de reconnaissance/decode/build et autres comportements ne doivent pas être aspirés prématurément dans `ksp-interface-lib`.
 
 ### TODO/IDEAS — providers Yellowstone non planifiés
 

deltas/0.2.12/pre.011.md

@@ -0,0 +1,102 @@
+<!-- file: deltas/0.2.12/pre.011.md -->
+<!-- version: 1 -->
+
+# Delta `0.2.12-pre.011` — préparation de publication et prompt `0.2.13`
+
+## Base requise
+
+```text
+0.2.12-pre.010
+workspace.package.version = 0.2.12-pre.10
+```
+
+Le gate opérateur de `pre.010` est propre : `cargo fmt`, audits Rust/Markdown, `cargo check --workspace`, Clippy `--all-targets` et `cargo test --workspace` passent. Les smokes live et builds Tauri avaient déjà été fermés dans le couloir technique `pre.009-fix.001`.
+
+## Objectif
+
+Couloir minimal de préparation de publication après la réconciliation documentaire finale de `pre.010` :
+
+- ajouter l'entrée stable préparatoire `0.2.12` dans `CHANGELOG.md` ;
+- fermer `0.2.12` dans `ROADMAP.md` et préciser la frontière `0.2.13/0.2.14` ;
+- produire `prompts/018-V0_2_13_START_PROMPT.md` ;
+- intégrer comme seed non normatif une reconnaissance ciblée de l'archive historique kbot3 fournie par l'opérateur ;
+- ne rouvrir aucun code, test, architecture, plan, validation ou documentation de crate.
+
+## Version Cargo
+
+Publication non-fix de prerelease :
+
+```text
+0.2.12-pre.10
+-> 0.2.12-pre.11
+```
+
+Aucun `tauri.conf.json` ou `package.json` n'est modifié. La version desktop reste Cargo-owned selon les règles stabilisées en `pre.009-fix.001`.
+
+## Fichiers ajoutés
+
+```text
+prompts/018-V0_2_13_START_PROMPT.md
+deltas/0.2.12/pre.011.md
+```
+
+## Fichiers modifiés
+
+```text
+Cargo.toml
+CHANGELOG.md
+ROADMAP.md
+```
+
+## Fichiers supprimés
+
+Aucun.
+
+## Reconnaissance kbot3 intégrée au prompt
+
+L'archive historique inspectée est :
+
+```text
+khadhroony-bot3_v0.5.3-pre.005-fix010.zip
+```
+
+Elle contient notamment un ancien `ks-lib` très large regroupant modèles, decoders, materializers et executors, ainsi que des canaris d'implémentations externes. Les concepts intéressants sont conservés comme inputs d'audit : identités wire, instruction path/CPI context, contrat versionné, reconnaissance/couverture/diagnostics/proofs, plans d'exécution et contrats materializer.
+
+Le prompt impose cependant la séparation suivante :
+
+```text
+0.2.13  ksp-interface-lib  -> données/wires passifs
+0.2.14  ksp-program-api    -> comportements/traits extensibles
+plus tard ksp-program-lib  -> implémentations officielles
+```
+
+Aucun type historique n'est copié tel quel et `pre.001` doit classer chaque idée `REPRENDRE / REDESSINER / REPORTER / REJETER`.
+
+## Discipline de scope
+
+Payload strict de préparation : cinq fichiers seulement. Aucun README, USAGE, règle, plan, validation, architecture, test, Config ou code fonctionnel n'est rouvert.
+
+## Gate attendu
+
+Cette tranche ne change aucun code fonctionnel. Le gate opérateur applicable reste :
+
+```text
+cargo fmt --all
+python3 scripts/audit_rust_workspace_rules.py
+python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates deltas/0.2.12
+cargo check --workspace
+cargo clippy --workspace --all-targets
+cargo test --workspace
+```
+
+Aucun nouveau smoke live ou build Tauri n'est requis avant `rel.001`, sauf si le gate révèle une régression nouvelle.
+
+## Étape suivante
+
+Si le gate reste propre :
+
+```text
+0.2.12-rel.001
+```
+
+La publication stable devra passer le workspace à `0.2.12`, produire le delta `rel.001`, créer le tag stable `v0.2.12` conformément au workflow KSP, puis la session suivante ouvrira `0.2.13` exclusivement depuis cette base stable.

prompts/018-V0_2_13_START_PROMPT.md

@@ -0,0 +1,403 @@
+<!-- file: prompts/018-V0_2_13_START_PROMPT.md -->
+<!-- version: 1 -->
+
+# Prompt de démarrage `0.2.13` — Interface foundation
+
+## 1. Identité de la release et base exacte
+
+La base attendue est **exclusivement** la release stable :
+
+```text
+v0.2.12
+```
+
+Ne pas ouvrir `0.2.13` depuis `0.2.12-pre.*`, `0.2.12-pre.*-fix.*`, une archive intermédiaire, l'ancien projet kbot3 ou un souvenir de session. Si une archive opérateur de `v0.2.12` est fournie au démarrage, cette archive réelle est la première autorité devant les snippets, anciennes archives, anciens prompts et mémoire de conversation.
+
+La release à ouvrir est :
+
+```text
+0.2.13 — Interface foundation
+```
+
+La première tranche est :
+
+```text
+0.2.13-pre.001
+```
+
+`pre.001` est obligatoirement une tranche d'**audit actuel + audit d'héritage kbot3 + brainstorming + décision de frontières + sizing**. Aucune implémentation fonctionnelle lourde de `ksp-interface-lib` ne doit précéder ce gate.
+
+## 2. Mission
+
+Introduire la première surface de `ksp-interface-lib` comme **façade wire KSP publique, passive, bornée et réutilisable**, destinée aux implémentations officielles futures et aux implémentations externes.
+
+La release doit préparer proprement `0.2.14 — ksp-program-api` sans l'implémenter par anticipation.
+
+La séparation cible est :
+
+```text
+ksp-core-lib
+    primitives KSP fondamentales / Error / Pubkey / Program IDs
+
+ksp-interface-lib
+    données et contrats wire publics passifs
+    sérialisation / validation / bornes / compatibilité
+    aucun comportement Program concret
+
+ksp-program-api            # 0.2.14
+    traits et contrats comportementaux extensibles
+    reconnaissance / decode / build / capabilities selon audit
+
+ksp-program-lib            # plus tard
+    implémentations officielles concrètes
+```
+
+`ksp-interface-lib` ne doit devenir ni un SDK Solana monolithique, ni un `ks-lib` renommé, ni une crate fourre-tout pour decoder/materializer/executor/store/pipeline.
+
+## 3. Autorités et lectures obligatoires avant toute décision
+
+Relire depuis la base réelle `v0.2.12`, au minimum :
+
+```text
+README.md
+RULES.md
+ROADMAP.md
+CHANGELOG.md
+Cargo.toml
+
+docs/000-README.md
+docs/rules/RULES_KSP.md
+docs/rules/RULES_RUST.md
+docs/rules/PROMPT_STRUCTURE.md
+docs/rules/VERSION_WORKFLOW.md
+docs/rules/FILE_CONTRACTS.md
+
+docs/architecture/001-LAYERS.md
+docs/architecture/002-DEPENDENCIES.md
+docs/architecture/003-COMPONENT_CONTRACTS.md
+docs/architecture/004-COMPONENT_INVENTORY.md
+docs/architecture/005-DEPENDENCY_GRAPH.md
+docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md
+
+docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
+```
+
+Relire aussi les surfaces publiques réelles de :
+
+```text
+crates/ksp-core-lib
+crates/ksp-onchain-transport-lib
+crates/ksp-offchain-transport-lib
+```
+
+Le but est d'éviter de dupliquer une primitive déjà possédée par Core ou de faire remonter dans Interface un DTO privé appartenant encore à Transport.
+
+## 4. Héritage `khadhroony-bot3` : source d'idées, jamais autorité
+
+Une archive historique fournie avant la publication de `v0.2.12` est :
+
+```text
+khadhroony-bot3_v0.5.3-pre.005-fix010.zip
+```
+
+Elle doit être traitée comme une **source d'idées à réévaluer**, pas comme une base de code ni comme une architecture à restaurer.
+
+La reconnaissance préalable à ce prompt a identifié dans l'ancien `ks-lib` plusieurs familles conceptuelles utiles :
+
+```text
+modèles wire / identité
+    signature
+    slot
+    program id / pubkey
+    instruction path
+    source kind
+    contract version
+
+contexte d'instruction
+    instruction top-level / CPI
+    parent path
+    stack height
+    accounts résolus
+    instruction accounts
+    payload brut
+    return data
+    logs
+    état d'échec transaction
+
+contrats d'extension historiques
+    decoder identity / surfaces / coverage
+    recognition / outcome
+    diagnostics / proof
+    external decoder compile canary
+    prepared execution plans / required signers / policy
+    event materializer contract
+```
+
+L'ancien projet contient également deux leçons négatives importantes :
+
+1. `ks-lib` concentre plusieurs centaines de fichiers de modèles, decoders, materializers et executors ; **ne pas reproduire ce monolithe** ;
+2. plusieurs générations d'API decoder coexistent (`DcApiProtocolDecoder` puis contrat contextuel plus riche) ; **ne pas créer deux API concurrentes par compatibilité avec l'ancien projet**.
+
+En `pre.001`, produire une matrice explicite pour chaque idée pertinente :
+
+```text
+REPRENDRE comme concept
+REDESSINER selon KSP actuel
+REPORTER vers ksp-program-api / ksp-program-lib / 0.3.2+
+REJETER
+```
+
+Si l'archive historique n'est pas disponible dans la nouvelle session, les éléments ci-dessus constituent seulement un seed de reconnaissance ; ne pas inventer le contenu manquant. L'opérateur peut fournir de nouveau l'archive si une inspection plus profonde est nécessaire.
+
+## 5. Frontière stricte `Interface` / `Program API` / `Program Lib`
+
+### `ksp-interface-lib` — autorisé dans `0.2.13`
+
+La crate peut posséder, après audit `pre.001`, des types publics KSP représentant des **faits wire génériques** nécessaires à la future extension Program : identités, chemins d'instruction, comptes/meta, données binaires bornées, contextes minimaux, enveloppes/version de contrat, sérialisation déterministe et validation locale.
+
+Les noms et le périmètre exacts doivent être décidés à partir des besoins démontrés de `0.2.14`, pas copiés depuis kbot3.
+
+### `ksp-program-api` — réservé à `0.2.14`
+
+Ne pas introduire dans `0.2.13` de trait comportemental public qui présuppose déjà l'architecture Program finale, notamment un équivalent prématuré de :
+
+```text
+InstructionDecoder
+ProtocolDecoder
+ProgramDecoder
+Executor
+TypedInstructionExecutor
+Materializer
+ProgramRegistry comportemental
+```
+
+Les notions historiques `identity`, `surfaces`, `coverage`, `recognize`, `decode`, `prepared plan`, `required signers`, `materialize` sont des **inputs de conception pour `0.2.14+`**, sauf si `pre.001` démontre qu'un type de données passif doit vivre dans Interface indépendamment du trait qui le consommera.
+
+### `ksp-program-lib` — hors scope
+
+Aucun decoder/executor/materializer officiel concret de System, SPL Token, Token-2022, Metadata, Anchor, Meteora, Raydium, Pump, Orca, Jupiter ou autre programme n'est implémenté ici.
+
+## 6. Frontière avec RAW / CORE / Store
+
+Le pipeline durable reste :
+
+```text
+RAW -> CORE -> DECODE -> SPECIALIZED
+```
+
+`0.2.13` ne doit pas anticiper `0.3.1`/`0.3.2` en transformant `ksp-interface-lib` en modèle complet d'acquisition ou de persistence RAW/CORE.
+
+Le roadmap réserve explicitement à `0.3.2` l'extension d'Interface avec les wires génériques nécessaires aux acquisitions et à la future normalisation CORE.
+
+Donc :
+
+- n'ajouter maintenant que les contrats indispensables à la future frontière Program ;
+- ne pas créer tables, DTO Store, replay ledger, observation persistence ou jobs ;
+- ne pas figer prématurément un `CoreInstructionReplayInput` complet simplement parce que kbot3 en possédait un ;
+- si un contexte transactionnel riche est utile mais pas encore requis par `0.2.14`, le documenter comme candidat `0.3.2+`.
+
+## 7. Dépendances et ownership
+
+`ksp-interface-lib` doit rester bas niveau et réutilisable.
+
+Baseline souhaitée à confronter au gate `pre.001` :
+
+```text
+ksp-interface-lib -> ksp-core-lib
+```
+
+Ajouter seulement les crates de sérialisation/utilitaires réellement nécessaires et autorisées par les règles workspace.
+
+Interdictions initiales :
+
+```text
+Interface -X-> Config
+Interface -X-> Logging runtime
+Interface -X-> Transport
+Interface -X-> Wallet
+Interface -X-> Store
+Interface -X-> Tauri
+Interface -X-> reqwest / tonic / tokio runtime
+Interface -X-> SDK/clients provider
+```
+
+Ne pas réintroduire un agrégat Solana ou des crates protocole simplement pour importer des types pratiques. Les représentations publiques doivent rester KSP-owned lorsque cela protège la stabilité et le firewall du workspace. Toute exception doit être justifiée par l'audit des règles et des dépendances officielles actuelles.
+
+## 8. Qualités obligatoires de la première surface wire
+
+Toute surface retenue doit viser :
+
+- types publics documentés et consommables depuis une crate externe ;
+- ownership explicite des identités et données ;
+- sérialisation/désérialisation uniquement lorsqu'elle est utile au contrat ;
+- aucune conversion canonique lossless -> `f64` ;
+- longueurs et collections bornées avant allocations pathologiques ;
+- données binaires sans `Debug` accidentellement gigantesque ou secret ;
+- distinction entre absence, valeur vide et valeur présente lorsque le wire la possède réellement ;
+- ordre préservé lorsque l'ordre Solana est sémantique ;
+- aucune dépendance à un backend de stockage ou à un transport ;
+- `#[non_exhaustive]` sur les enums publics susceptibles d'évoluer lorsqu'approprié ;
+- tests downstream-style prouvant que le contrat public suffit à un consumer externe.
+
+Ne pas versionner un contrat wire par réflexe. Si une version explicite est retenue, `pre.001` doit expliquer **ce qui nécessite une évolution de contrat** et comment la compatibilité sera gérée.
+
+## 9. Questions obligatoires de `pre.001`
+
+Avant d'écrire la surface définitive, répondre explicitement à ces questions :
+
+1. Quel besoin précis de `0.2.14` exige déjà `ksp-interface-lib` ?
+2. Quels types actuellement dans Core/Transport peuvent être réutilisés sans duplication ?
+3. Quelles données doivent être KSP-owned plutôt que des types Solana externes ?
+4. La première surface doit-elle couvrir instruction uniquement, instruction + account, ou un autre minimum ?
+5. Quelles informations CPI sont indispensables dès maintenant : path, parent, stack height, aucune ?
+6. Les logs, return data, balance deltas et erreurs transactionnelles appartiennent-ils à `0.2.13`, à `0.3.2`, ou à une autre couche ?
+7. Quel encodage public représente les bytes sans ambiguïté et avec bornes raisonnables ?
+8. Quels invariants peuvent être validés localement sans prétendre valider la sémantique d'un Program ?
+9. Quels anciens concepts kbot3 sont réellement utiles et lesquels reflètent seulement son ancienne architecture ?
+10. Le scope tient-il raisonnablement dans une session de release ? Sinon, réduire `0.2.13` avant toute implémentation lourde.
+
+## 10. Livrables attendus de `pre.001`
+
+`pre.001` doit produire au minimum :
+
+- audit de la surface actuelle de Core/Transport pertinente ;
+- audit ciblé de l'héritage kbot3 si l'archive est disponible ;
+- matrice `REPRENDRE / REDESSINER / REPORTER / REJETER` ;
+- décision exacte des types/wires qui appartiennent à `0.2.13` ;
+- décision explicite de ce qui reste pour `0.2.14` et `0.3.2+` ;
+- graphe de dépendances cible ;
+- threat/robustness model wire : tailles, allocations, debug, malformed input ;
+- plan détaillé et validation dédiés ;
+- sizing final et forecast de prereleases recalibré.
+
+`pre.001` peut rester principalement documentaire. Il ne doit pas créer une grosse API uniquement pour respecter le forecast initial ci-dessous.
+
+## 11. Prévisions souples initiales
+
+Ces tranches sont un **forecast de départ**, pas un contrat rigide. `pre.001` doit les fusionner, scinder ou supprimer si l'audit le justifie.
+
+### `pre.001` — Audit actuel + héritage kbot3 + frontières + sizing
+
+**Statut : prévu**
+
+Audit des besoins réels de `0.2.14`, des surfaces existantes Core/Transport, de l'archive kbot3 et des dépendances. Décider le minimum wire exact, créer plan/validation et confirmer le sizing.
+
+### `pre.002` — Scaffold `ksp-interface-lib` + firewall
+
+**Statut : prévu**
+
+Créer la crate, sa façade publique minimale, README/USAGE initiaux, tests de dépendances et canari de consommation externe, sans comportement Program.
+
+### `pre.003` — Primitives wire communes retenues
+
+**Statut : prévu**
+
+Introduire uniquement les identités, wrappers, bornes et représentations communes confirmées par `pre.001`, en réutilisant Core lorsque possible.
+
+### `pre.004` — Wire instruction
+
+**Statut : prévu**
+
+Matérialiser le contrat d'instruction générique retenu : program identity, comptes/meta ordonnés, données et contexte minimal démontré. Pas de decode.
+
+### `pre.005` — Wire account/contexte complémentaire retenu
+
+**Statut : prévu**
+
+Ajouter seulement le second lot démontré par l'audit — account wire et/ou contexte strictement nécessaire au futur Program API. Ne pas forcer cette tranche si le scope minimal n'en a pas besoin.
+
+### `pre.006` — Sérialisation, bornes et adversarial
+
+**Statut : prévu**
+
+Round-trips déterministes, malformed inputs, tailles/collections hostiles, représentation binaire, `Debug` sûr, ordre et états optionnels.
+
+### `pre.007` — External consumer contract + API hardening
+
+**Statut : prévu**
+
+Canaris downstream-style prouvant qu'une crate externe peut construire/lire la surface publique sans imports privés ni dépendances Program. Réaudit de la surface exposée et du graph Cargo.
+
+### `pre.008` — Gate technique et réconciliation documentaire finale
+
+**Statut : prévu**
+
+Workspace complet, Clippy/tests, audit public API/dependencies, README/USAGE/architecture/plan/validation. Aucune extension fonctionnelle opportuniste.
+
+### `pre.009` — Préparation de publication
+
+**Statut : prévu**
+
+Couloir minimal : prompt `0.2.14`, `CHANGELOG.md`, `ROADMAP.md`, version et delta. Ne pas fusionner avec la réconciliation documentaire si les règles de lifecycle en vigueur l'interdisent.
+
+### `rel.001` — Publication stable
+
+**Statut : prévu**
+
+Passage à `0.2.13`, gate final requis par les règles, commit/tag stable `v0.2.13` et conservation du seul tag stable attendu par le workflow KSP.
+
+## 12. Tests et canaris attendus
+
+Le plan final doit au moins prévoir :
+
+```text
+cargo fmt --all
+python3 scripts/audit_rust_workspace_rules.py
+python3 scripts/audit_markdown_tables.py ...
+cargo check --workspace
+cargo clippy --workspace --all-targets
+cargo test -p ksp-interface-lib
+cargo test --workspace
+```
+
+Canaris spécifiques attendus selon le scope retenu :
+
+- external consumer compile test depuis l'API publique ;
+- dependency firewall ;
+- aucun comportement Program concret ;
+- aucune dépendance Config/Transport/Store/Tauri ;
+- malformed/oversized input avant allocation pathologique ;
+- sérialisation/round-trip exacte si serde fait partie du contrat ;
+- ordre des comptes/instructions préservé ;
+- distinction des options wire utiles ;
+- surface publique documentée et exports complets.
+
+Aucun smoke réseau n'est requis par défaut pour une crate wire pure. Ne pas inventer un test live sans valeur technique réelle.
+
+## 13. Hors scope explicite
+
+Pour `0.2.13`, ne pas implémenter :
+
+- `ksp-program-api` ;
+- `ksp-program-lib` ;
+- decoder Program concret ;
+- Anchor generic decoder ;
+- IDL parser/generator ;
+- materializer ;
+- executor / transaction builder Program ;
+- Store/RAW/CORE persistence ;
+- jobs/workers/pipelines ;
+- UI/Tauri ;
+- provider réseau ;
+- plugin dynamique / ABI stable C / WASM sandbox ;
+- auto-discovery de Program IDs ;
+- registry de plugins runtime ;
+- compatibilité automatique avec les types historiques `ks-lib`.
+
+Les IDL et implémentations de l'ancien projet peuvent servir de références futures mais ne constituent pas la mission de cette release.
+
+## 14. Discipline de delta et de session
+
+Pour chaque prerelease :
+
+- partir exclusivement de la tranche opérateur réellement validée ;
+- relire les règles/architecture pertinentes avant de rédiger ou modifier un contrat ;
+- produire un delta immuable `deltas/0.2.13/pre.NNN.md` ;
+- en cas de défaut, produire `pre.NNN-fix.MMM` strictement limité à la responsabilité de la tranche ;
+- ne pas modifier `ROADMAP.md` en détail pendant les prereleases ordinaires ;
+- réserver `CHANGELOG.md` à la clôture ;
+- préserver le format RustRover de tous les tableaux Markdown touchés ;
+- exécuter les gates applicables avant de fermer une tranche ;
+- garder la release dimensionnée pour une seule session de chat.
+
+Les prévisions ci-dessus ne justifient jamais d'ajouter une surface qui n'est pas démontrée par l'audit.