khadhroony-solana-project/prompts/018-V0_2_13_START_PROMPT.md

<!-- file: prompts/018-V0_2_13_START_PROMPT.md -->
<!-- version: 2 -->

# Prompt de démarrage `0.2.13` — Interface / wire foundation

## 1. Identité de la release et base exacte requise

La base attendue est **exclusivement** la release stable :

```text
v0.2.12
```

Ne pas ouvrir `0.2.13` depuis :

```text
0.2.12-pre.*
0.2.12-pre.*-fix.*
0.2.12-rel.* non encore validé stable
une archive intermédiaire de travail
l'ancien dépôt khadhroony-bot3
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. Une divergence entre la base réelle et ce prompt déclenche un audit explicite ; elle ne se résout jamais par supposition.

La release à ouvrir est :

```text
0.2.13 — Interface / wire foundation
```

La première tranche est :

```text
0.2.13-pre.001
```

`pre.001` est obligatoirement une tranche **lecture + audit interne + audit d'héritage kbot3 + audit externe ciblé + brainstorming + frontières + dependency graph + threat/robustness model + sizing + planification**.

Aucune API wire lourde, aucun trait Program et aucun portage de code kbot3 ne doit commencer avant la sortie cohérente de ce gate.

À l'ouverture, vérifier au minimum :

```text
git describe / tag stable si metadata Git disponible
workspace.package.version = 0.2.12
deltas/0.2.12/rel.001.md présent
prompts/018-V0_2_13_START_PROMPT.md présent
ksp-interface-lib absent au démarrage sauf contradiction de la base réelle
ksp-program-api absent au démarrage sauf contradiction de la base réelle
```

---

## 2. Mission et résultat attendu

La mission de `0.2.13` est d'introduire la **première surface de `ksp-interface-lib`**, conformément à l'architecture KSP actuelle :

```text
façade wire officielle KSP
API publique wire réutilisable
contrats passifs / codecs / validation locale
pas de comportement Program
pas de runtime réseau
pas de persistence
```

La release doit préparer proprement :

```text
0.2.14 — ksp-program-api foundation
```

sans implémenter cette release par anticipation.

Résultat attendu à la clôture, sous réserve du scope exact décidé en `pre.001` :

```text
ksp-interface-lib existe comme crate membre du workspace
façade publique explicite via crate root
surface wire minimale réellement justifiée par le futur Program API
ownership Core / Interface / Program clairement séparé
codec(s) wire seulement si un contrat réel l'exige
validation/bornes déterministes des données exposées
aucune logique decode/reconnaissance/exécution/materialisation
aucune dépendance reverse vers Transport/Store/Wallet/App
aucune dépendance protocolaire opportuniste non auditée
canari consumer externe/public API
canaris de dependency firewall
round-trips/adversarial tests si sérialisation retenue
README/USAGE durables réconciliés avant publication
plan/validation de release complets
prompt 0.2.14 préparé dans le couloir final dédié
```

Le résultat n'est **pas** de recréer un modèle universel de transaction/replay ni de remplir Interface par symétrie avec l'ancien `ks-lib`.

La question centrale de la release est :

> quel est le **minimum wire public KSP-owned** qu'il faut stabiliser maintenant pour que `ksp-program-api` puisse être conçu proprement en `0.2.14`, sans anticiper les wires génériques RAW/CORE réservés aux séries suivantes ?

---

## 3. Sources de vérité internes obligatoires — ordre de lecture

### 3.1 Règles globales

Lire d'abord, dans cet ordre :

```text
RULES.md
docs/000-README.md

docs/rules/RULES_GENERAL.md
docs/rules/RULES_KSP.md
docs/rules/RULES_RUST.md
docs/rules/RULES_DEPENDENCIES.md
docs/rules/RULES_DOCUMENTATION.md
docs/rules/FILE_CONTRACTS.md
docs/rules/VERSION_WORKFLOW.md
docs/rules/PROMPT_STRUCTURE.md
```

Le présent prompt est un contrat opératoire autonome, mais **ne remplace aucune règle normative**.

Rappels qui conditionnent directement cette release :

```text
Rust 2024
unsafe / unwrap / expect / panic interdits selon les règles KSP
? interdit en production selon les lints KSP
#![warn(missing_docs)]
#![deny(unreachable_pub)]
#![forbid(unsafe_code)]

pas de pub mod comme raccourci de façade
surface publique réexportée explicitement depuis crate root
unit tests sous unit_tests/ autant que possible
tests/ réservé aux tests d'intégration consommant l'API publique
Error/Result communs possédés par ksp-core-lib
Program IDs fondamentaux possédés par ksp-core-lib
Pubkey consommé via ksp-core-lib lorsque la frontière KSP l'exige
```

Règles wire/dependency à relire particulièrement :

```text
KSP-WIRE-001..003
DEP-WIRE-001..007
DEP-PROGRAM-001..004
DEP-KSP-001..005
DEP-CARGO-001..007
```

Après toute modification Rust :

```bash
cargo fmt --all
python3 scripts/audit_rust_workspace_rules.py
cargo check --workspace
cargo clippy --workspace --all-targets
```

Pour tout Markdown touché :

```bash
python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates deltas/0.2.13
```

Une commande non exécutée n'est jamais déclarée PASS.

### 3.2 Architecture durable à préserver

Lire ensuite, dans cet ordre :

```text
docs/architecture/000-README.md
docs/architecture/001-PROJECT_OBJECTIVES.md
docs/architecture/002-LAYERS_AND_DEPENDENCIES.md
docs/architecture/003-COMPONENT_CONTRACTS.md
docs/architecture/004-COMPONENT_INVENTORY.md
docs/architecture/005-DEPENDENCY_GRAPH.md
docs/architecture/006-WIRE_AND_PROGRAM.md
docs/architecture/007-EXECUTION_AND_POLICY.md
docs/architecture/008-DATA_MATERIALIZATION_AND_STORE.md
docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md
```

`docs/architecture/006-WIRE_AND_PROGRAM.md` est la référence architecturale centrale de cette release.

Points acquis à préserver :

```text
ksp-interface-lib = façade wire officielle + API wire publique
pas de ksp-interface-api séparée actuellement
Program IDs fondamentaux restent dans Core
Interface peut posséder codecs/layouts/discriminants/seeds/constructeurs wire lorsqu'ils appartiennent réellement au contrat
Interface ne possède pas interprétation métier/decode Program/policy/exécution réseau
ksp-program-api est ouvert/extensible et vient ensuite
ksp-program-lib porte plus tard les implémentations officielles
une extension externe peut consommer les wires officiels sans dépendre de ksp-program-lib
RAW -> CORE reste générique et ne dépend pas de Program
CORE -> DECODE est la première frontière qui peut utiliser Program API
```

Ne pas remplacer ces décisions par la structure de kbot3.

### 3.3 Plans, roadmap et clôture `0.2.12`

Relire :

```text
ROADMAP.md
CHANGELOG.md

docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
docs/plans/019-V0_2_12_SOL_PRICES_DESK_PLAN.md
docs/validation/015-V0_2_12_SOL_PRICES_DESK.md

deltas/0.2.12/rel.001.md
```

Le but n'est pas de rouvrir `0.2.12`, mais de confirmer la base stable et la séquence retenue :

```text
0.2.13 interface/wire foundation
0.2.14 program-api foundation
0.3.1 Store RAW
0.3.2 extension Interface pour wires génériques acquisition/CORE
```

Cette séquence est une contrainte importante : `0.2.13` ne doit pas absorber prématurément `0.3.2`.

### 3.4 Code réel à inventorier avant design

Inventorier au minimum :

```text
Cargo.toml
crates/ksp-core-lib/Cargo.toml
crates/ksp-core-lib/src/lib.rs
crates/ksp-core-lib/src/program_ids.rs

crates/ksp-onchain-transport-lib/Cargo.toml
crates/ksp-onchain-transport-lib/src/lib.rs
crates/ksp-onchain-transport-lib/src/rpc_common.rs
crates/ksp-onchain-transport-lib/src/rpc_accounts.rs
crates/ksp-onchain-transport-lib/src/rpc_transactions.rs
crates/ksp-onchain-transport-lib/src/rpc_blocks.rs
crates/ksp-onchain-transport-lib/src/ws_*.rs selon types réellement pertinents
crates/ksp-onchain-transport-lib/src/grpc_*.rs selon types réellement pertinents
```

L'inventaire doit distinguer :

```text
type fondamental déjà possédé par Core
wire/provider DTO privé de Transport
type générique potentiellement partageable mais actuellement transport-owned
contrat nouveau réellement nécessaire à Interface
type qui appartient seulement à RAW/CORE plus tard
```

Ne pas déplacer un DTO Transport vers Interface uniquement pour réduire une duplication apparente. Ownership et stabilité priment.

---

## 4. Sources externes normatives à réauditer en `pre.001`

La release ne doit pas figer un wire Solana ou choisir un codec depuis des souvenirs historiques.

Selon le scope candidat retenu pendant l'audit, consulter en priorité les sources **officielles et actuelles** suivantes :

```text
Documentation officielle Solana / Anza correspondant aux structures wire réellement ciblées
sources Agave / crates officielles actuelles lorsque leur comportement wire fait autorité
crates officielles d'interface Solana/Anza candidates à un réexport contrôlé
API actuelle de solana-pubkey déjà utilisée par Core
sources primaires des codecs candidats : borsh, wincode ou équivalent seulement si un besoin réel existe
```

Pour toute crate candidate :

```text
vérifier version stable réellement courante
vérifier ownership/source officielle ou normative
vérifier MSRV/edition/features utiles si pertinents
vérifier default-features et features réellement nécessaires
inspecter dépendances transitives fondamentales
cargo tree -d
cargo tree -i <codec-ou-primitive> si ajouté
```

L'exemple historique `solana-loader-v3-interface` dans l'architecture doit être **réaudité** s'il devient pertinent ; il n'est pas une dépendance obligatoire. De même, le rejet historique de `mpl-token-metadata` illustre une politique de contrôle du wire, pas une règle imposant son implémentation dans `0.2.13`.

Aucun résultat externe ancien n'est considéré frais par défaut.

---

## 5. État validé à préserver depuis `v0.2.12`

### 5.1 Workspace et Core

État attendu :

```text
workspace Rust 2024 stable
ksp-core-lib possède Error / ErrorCode / ErrorContext / Result
ksp-core-lib réexporte la Pubkey KSP
ksp-core-lib possède le registry des Program IDs fondamentaux
18 Program IDs fondamentaux couverts par les canaris actuels
ksp-interface-lib absent
ksp-program-api absent
```

`0.2.13` ne doit pas déplacer les Program IDs fondamentaux hors de Core.

### 5.2 Transport

Les transports on-chain sont déjà fonctionnels et séparés :

```text
HTTP typed complet
WebSocket standard
Helius LaserStream WebSocket
Yellowstone gRPC standard/provider-neutral
```

Ils restent propriétaires de leurs DTOs réseau/provider et ne doivent pas acquérir une dépendance vers Interface/Program par commodité.

Frontière durable :

```text
Transport -X-> ksp-interface-lib sauf besoin architectural explicitement décidé plus tard
Transport -X-> ksp-program-api
Transport -X-> ksp-program-lib
```

`0.2.13` n'est pas une refactorisation générale de Transport.

### 5.3 Off-chain, Wallet et Desks

Les surfaces stabilisées jusqu'à `0.2.12` restent hors chantier :

```text
ksp-offchain-transport-lib
ksp-wallet-lib
ksp-app-config-desk
ksp-app-wallet-desk
ksp-app-solprices-desk
```

Ne pas les modifier pour démontrer Interface, sauf si un gate de dépendance global révèle une violation préexistante directement bloquante et que le workflow impose une tranche dédiée.

### 5.4 Pipeline durable

Préserver :

```text
RAW -> CORE -> DECODE -> SPECIALIZED
```

Avec :

```text
RAW -> CORE -X-> Program API
RAW -> CORE -X-> Program Lib
CORE -> DECODE peut utiliser Program API plus tard
```

Les modèles d'acquisition/replay/store ne sont pas la mission de `0.2.13`.

---

## 6. Décisions acquises — ne pas redébattre sans contradiction réelle

Les décisions suivantes sont considérées acquises :

1. la crate cible s'appelle `ksp-interface-lib` ;
2. aucune crate `ksp-interface-api` séparée n'est créée par symétrie ;
3. `ksp-interface-lib` expose une API wire publique réutilisable par les implémentations officielles et externes ;
4. `ksp-interface-lib` ne dépend pas de `ksp-program-api` ni de `ksp-program-lib` ;
5. `ksp-program-api` est réservé à `0.2.14` ;
6. `ksp-program-lib` et les implémentations officielles concrètes sont reportés à des vertical slices ultérieures ;
7. Program IDs fondamentaux et `Pubkey` KSP restent possédés par Core ;
8. les codecs wire officiels utilisés directement par KSP appartiennent normalement à Interface ;
9. une crate protocolaire externe incompatible peut être remplacée par une implémentation KSP bornée ;
10. une extension Program externe peut temporairement posséder son propre wire lorsqu'Interface ne le possède pas encore ;
11. l'ancien `khadhroony-bot3` est une source d'idées, **jamais une autorité architecturale** ;
12. aucun monolithe équivalent à l'ancien `ks-lib` n'est recréé ;
13. la compatibilité automatique avec les anciens types kbot3 n'est pas un objectif ;
14. `0.3.2` reste propriétaire de l'extension Interface nécessaire aux acquisitions et à la normalisation CORE ;
15. une release concrète doit rester clôturable dans une seule session et être réduite si le sizing est négatif.

Une contradiction avec la base stable réelle se traite par audit et décision documentée, pas par réécriture silencieuse de ces acquis.

---

## 7. Questions réellement ouvertes à trancher pendant `pre.001`

### 7.1 Premier périmètre wire concret

Décider ce qui constitue réellement la **première surface** de `ksp-interface-lib` :

```text
scaffold + primitives publiques uniquement
wire Program générique minimal
autre lot officiel minimal démontré par l'architecture
```

Ne pas forcer une famille de types parce qu'elle existait dans kbot3.

### 7.2 Frontière Program-facing vs acquisition-facing

Pour chaque candidat — instruction identity, CPI path, account meta, logs, return data, transaction failure, balance deltas, contexte de replay — décider explicitement :

```text
nécessaire à Program API dès 0.2.14
utile mais acquisition/CORE -> reporter 0.3.2+
spécifique à un transport -> rester Transport
spécifique à un Program concret -> vertical slice ultérieure
```

### 7.3 Réutilisation Core vs nouveau wrapper

Déterminer :

```text
quand utiliser directement ksp_core_lib::Pubkey
quand créer un newtype KSP-owned
quand un simple alias serait insuffisant
quels identifiants ont déjà un owner canonique
```

Aucun wrapper ne doit être créé uniquement pour renommer un type stable déjà possédé par Core.

### 7.4 Représentation des bytes et bornes

Si la surface contient des données binaires :

```text
Vec<u8> borné ?
newtype borné ?
encodage texte seulement à la frontière serde ?
limites maximales exactes ou conservatrices ?
validation avant allocation pathologique ?
Debug complet, résumé ou redacted/bounded ?
```

La décision doit être justifiée par le wire réel et les usages publics.

### 7.5 Sérialisation et codecs

Décider si `serde`, `borsh`, `wincode` ou autre est réellement requis dans `0.2.13`.

Questions :

```text
le contrat public a-t-il besoin d'un round-trip stable dès maintenant ?
le codec appartient-il au wire du protocole ou seulement à un stockage futur ?
une crate officielle actuelle peut-elle être réexportée/wrappée proprement ?
une réimplémentation KSP est-elle préférable à un graphe incompatible ?
```

Ne pas ajouter plusieurs codecs « pour préparer la suite ».

### 7.6 Versionnement du contrat wire

Ne pas introduire `format_version`, `contract_version` ou enum V1/V2 par réflexe.

Si une version explicite est retenue, documenter :

```text
ce qui est versionné
pourquoi l'évolution incompatible est plausible
qui choisit/interprète la version
comment unknown/future est traité
```

### 7.7 Error model et validation locale

Décider quelles erreurs sont :

```text
construction invalide
borne dépassée
wire malformed
unsupported local
invariant structurel
```

Utiliser l'Error KSP commun lorsque cela correspond au contrat actuel. Ne pas inventer une hiérarchie d'erreurs Program avant `ksp-program-api`.

### 7.8 Surface d'extension externe

Définir le canari minimum prouvant qu'une crate externe peut :

```text
dépendre de ksp-interface-lib
importer uniquement les exports crate-root
construire/lire les types publics retenus
sérialiser/désérialiser si cette capacité fait partie du contrat
ne pas dépendre de modules privés ni de ksp-program-lib
```

### 7.9 Héritage kbot3

Pour les concepts historiques pertinents, produire une matrice :

```text
REPRENDRE
REDESSINER
REPORTER
REJETER
```

Chaque ligne doit expliquer **pourquoi**, et vers quelle couche/version un report est effectué.

### 7.10 Sizing

Confirmer que le scope retenu tient dans une release/session.

Si le premier wire officiel complet est trop large :

```text
réduire 0.2.13 au socle public réellement nécessaire
reporter les familles additionnelles
ne pas ouvrir plusieurs protocoles en parallèle
```

---

## 8. Héritage `khadhroony-bot3` — audit historique contrôlé

L'archive historique fournie avant la publication de `v0.2.12` est :

```text
khadhroony-bot3_v0.5.3-pre.005-fix010.zip
```

Elle peut être redonnée dans la nouvelle session pour inspection complète.

La reconnaissance préalable a identifié dans l'ancien `ks-lib` plusieurs familles d'idées :

```text
identités et modèles wire
instruction path / contexte CPI
accounts résolus / instruction accounts
payload brut / return data / logs
état d'échec transaction
version de contrat

contrats decoder historiques
identity / surfaces / coverage
recognize / outcome
diagnostics / proof
external decoder canaries

contrats execution/materialization historiques
prepared execution plans
required signers / policy
materializer contracts
```

Deux leçons négatives sont déjà acquises :

```text
ancien ks-lib = monolithe de plusieurs centaines de fichiers
plusieurs générations de Decoder API y coexistent
```

Donc :

- ne copier aucun dossier/module entier ;
- ne conserver aucun nom historique uniquement pour compatibilité ;
- ne créer aucun trait Decoder/Executor/Materializer dans `0.2.13` ;
- ne considérer un type historique que si son **concept** répond à un besoin KSP actuel démontré ;
- comparer l'idée à l'architecture KSP avant de comparer le code ligne par ligne.

Si l'archive n'est pas disponible au démarrage, ne pas inventer ses détails. Utiliser seulement le seed ci-dessus et signaler les points nécessitant une nouvelle inspection opérateur.

---

## 9. Objectifs et livrables de `0.2.13`

Le scope exact est recalibré par `pre.001`, mais la release doit viser les livrables suivants.

### 9.1 Crate et façade

```text
crates/ksp-interface-lib/
Cargo.toml
src/lib.rs
README.md
USAGE.md
unit_tests/
tests/
```

La crate respecte les conventions workspace et n'expose pas ses modules privés comme API.

### 9.2 Surface wire publique

Le lot retenu doit posséder :

```text
rustdoc public
constructeurs/validation explicites si nécessaires
invariants et bornes définis
ordre sémantique préservé
états optionnels fidèles au wire réel
Debug maîtrisé
serde/codec seulement si décidé
```

### 9.3 Dependency firewall

Prouver au minimum :

```text
Interface -> Core autorisé
Interface -X-> Program API
Interface -X-> Program Lib
Interface -X-> Config
Interface -X-> Transport
Interface -X-> Store
Interface -X-> Wallet
Interface -X-> Tauri
Interface -X-> reqwest / tonic / runtime réseau
```

Une dépendance logging n'est ajoutée que si un comportement runtime réel à instrumenter existe ; une crate wire déclarative ne doit pas ajouter Logging par réflexe.

### 9.4 Consumer externe

Créer un canari integration/downstream-style démontrant que la surface voulue est consommable uniquement via l'API publique.

### 9.5 Documentation et validation

`pre.001` doit créer :

```text
docs/plans/020-V0_2_13_INTERFACE_PLAN.md
docs/validation/016-V0_2_13_INTERFACE.md
```

Ces noms sont la suite documentaire attendue si la base stable ne contient pas déjà ces numéros. En cas de contradiction réelle, conserver la nomenclature effective de la base et documenter l'écart.

---

## 10. Hors périmètre explicite

Ne pas implémenter dans `0.2.13` :

```text
ksp-program-api
ksp-program-lib
ProgramInstructionDecoder
ProgramAccountDecoder
ProgramEventDecoder
ProgramReturnDataDecoder
registry comportemental Program
recognition / coverage / decoder outcome définitifs
ProgramExecutionPreparer
PreparedProgramExecution définitif
materializer
execution policy
execution orchestration
System/SPL/Token-2022/Metadata/Anchor/DEX decoder concret
IDL parser/generator
Store/persistence RAW ou CORE
replay ledger / claims / jobs / workers
application Tauri
provider réseau
plugin dynamique / ABI C / WASM sandbox
compatibilité automatique avec ks-lib
migration des anciens modèles kbot3
```

Ne pas implémenter non plus un modèle complet :

```text
RawBlock
CoreTransactionReplayInput
CoreInstructionReplayInput
pipeline acquisition universel
```

uniquement parce que ces structures pourront être utiles plus tard. Les wires génériques d'acquisition/CORE restent notamment attendus en `0.3.2`.

---

## 11. Contraintes sécurité, API et architecture spécifiques

### 11.1 Robustesse des données

Toute donnée de taille variable doit avoir une politique explicite :

```text
limite
moment de validation
allocation
conversion
Debug
serde
```

Rejeter avant allocation/copie pathologique lorsque techniquement possible.

### 11.2 Fidélité wire

Ne pas confondre :

```text
absent
null / None lorsque le wire le permet
empty
zero
unknown/future
```

Ne pas normaliser une distinction wire utile pour simplifier l'API.

### 11.3 Ordre

Préserver l'ordre lorsque Solana lui donne une sémantique :

```text
account metas
instruction accounts
instruction order
CPI path si retenu
```

Ne pas remplacer une séquence ordonnée par une map/set sans justification.

### 11.4 Numeric safety

Aucune vérité canonique lossless ne passe par `f32`/`f64`.

Les slots, indexes, offsets, lengths et counts utilisent des types/bornes compatibles avec le wire réel et les conversions sont vérifiées.

### 11.5 API évolutive

Pour les enums publics susceptibles d'acquérir de nouvelles variantes externes, évaluer `#[non_exhaustive]` explicitement.

Ne pas appliquer `#[non_exhaustive]` mécaniquement à chaque enum ; documenter le choix lorsqu'il affecte l'extensibilité downstream.

### 11.6 Debug et données volumineuses

Une structure contenant des bytes ou collections potentiellement importantes ne doit pas produire accidentellement un `Debug` gigantesque.

Choisir selon le contrat :

```text
Debug dérivé sûr et borné par construction
Debug custom résumant length/hash/metadata non sensible
pas de Debug public si inutile
```

### 11.7 Pas de comportement Program prématuré

Une méthode passive de validation/codec/constructeur wire est autorisée lorsqu'elle appartient au contrat de données.

Une méthode qui choisit :

```text
quel decoder
si une instruction est reconnue
quelle sémantique canonique produire
comment matérialiser
comment exécuter
```

appartient aux couches Program/Materializer/Execution ultérieures.

---

## 12. Première mission `0.2.13-pre.001` — gate obligatoire

### 12.1 Baseline stable

Avant toute modification lourde :

```bash
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.13
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test --workspace
```

Pour une base stable intacte, `cargo fmt --all` ne doit pas servir à introduire des modifications opportunistes. Si une commande modifie ou échoue sur la base stable, documenter le constat avant d'avancer.

### 12.2 Audit interne complet

Produire un inventaire concret :

```text
Core public API utile
Program IDs / Pubkey ownership
DTOs Transport potentiellement ressemblants
règles wire/dependency
architecture 006
roadmap 0.2.13 / 0.2.14 / 0.3.2
workspace dependencies actuelles
```

Pour chaque type candidat déjà existant :

```text
owner actuel
visibilité
consumer actuel
sémantique
raison éventuelle de réutiliser / laisser en place / redessiner
```

### 12.3 Audit kbot3

Si l'archive est disponible :

1. inventorier uniquement les familles pertinentes ;
2. identifier les concepts, pas seulement les noms de fichiers ;
3. produire la matrice `REPRENDRE / REDESSINER / REPORTER / REJETER` ;
4. distinguer clairement les idées Interface des idées Program API/Program Lib/Materializer/Execution ;
5. noter les anti-patterns historiques à ne pas reproduire.

Ne pas porter de code pendant cette étape.

### 12.4 Audit externe actuel

Pour chaque dépendance/wire externe réellement candidat :

```text
source primaire
version stable courante
contrat wire actuel
features requises
dépendances transitives
compatibilité avec solana-pubkey/Core actuel
codec generations
licence si nouvelle dépendance
```

Ne pas auditer vingt crates spéculatives : seulement les candidates du scope retenu.

### 12.5 Matrice de frontières

Produire une matrice explicite, au minimum :

```text
concept/type
owner cible
0.2.13 ?
0.2.14 ?
0.3.2+ ?
source d'autorité
raison
```

Cette matrice doit empêcher la fuite entre :

```text
Core
Interface
Transport
Program API
Program Lib
RAW/CORE
Store
```

### 12.6 Surface API proposée

Avant implémentation, écrire conceptuellement la façade visée :

```text
exports crate-root
principaux types publics
constructeurs
validation
serde/codec éventuel
erreurs
bornes
```

Les noms restent modifiables pendant `pre.001`; le but est de vérifier la cohérence, pas de figer prématurément tous les détails.

### 12.7 Threat / robustness model

Auditer :

```text
oversized byte payload
oversized collection
integer overflow / index conversion
malformed wire
unknown enum/discriminant
nested structures pathologiques
Debug volumineux
allocation/copie excessive
serde hostile
panic/unwrap/expect
```

Pour chaque risque retenu, indiquer le test/canari prévu.

### 12.8 Dependency graph cible

Établir la cible réelle, par exemple :

```text
ksp-interface-lib
    -> ksp-core-lib
    -> serde ?
    -> codec(s) réellement retenu(s) ?
    -> interface officielle compatible ?
```

et prouver explicitement les interdictions.

Si une nouvelle dépendance externe est proposée, prévoir les `cargo tree` de validation.

### 12.9 Stratégie de tests

Décider avant le développement :

```text
unit tests privés
integration public API
external consumer compile canary
round-trip fixtures
malformed fixtures
oversized/adversarial
compile-fail si utile
cargo tree/firewall
```

Aucun smoke réseau n'est requis par défaut pour une crate wire pure.

### 12.10 Sizing

Estimer chaque tranche intermédiaire avec le budget KSP d'environ **15–20 minutes de travail effectif** comme outil de découpage, jamais comme promesse.

Si une tranche est manifestement trop grosse, la scinder avant implémentation.

Si la release entière paraît impossible à clôturer raisonnablement dans la session, réduire le scope fonctionnel de `0.2.13` avant de coder.

### 12.11 Documents de sortie

Créer ou mettre à jour au minimum :

```text
docs/plans/020-V0_2_13_INTERFACE_PLAN.md
docs/validation/016-V0_2_13_INTERFACE.md
deltas/0.2.13/pre.001.md
```

Le plan doit contenir la prévision souple recalibrée sous forme de headings `### pre.NNN`, avec statuts et éventuels fixes imbriqués conformément aux conventions KSP utilisées dans les releases récentes.

### Critères de sortie de `pre.001`

`pre.001` n'est fermé que si :

```text
sources internes obligatoires réellement relues
base stable confirmée
surface Core/Transport pertinente inventoriée
architecture 006 confrontée à la base réelle
archive kbot3 auditée si disponible ou absence explicitement notée
matrice REPRENDRE/REDESSINER/REPORTER/REJETER produite
frontière 0.2.13 / 0.2.14 / 0.3.2 explicite
premier lot wire exact décidé ou réduit
ownership des types décidé
dépendances candidates auditables et bornées
threat/robustness model écrit
strategy de tests définie
dependency graph cible défini
plan + validation créés
forecast recalibré
sizing compatible avec une release/session
aucune implémentation Program lourde commencée
```

Si l'une de ces sorties reste ambiguë, `pre.001` continue ou reçoit un fix ; `pre.002` ne commence pas par défaut.

---

## 13. Prévision souple initiale des prereleases

Cette trajectoire est un **forecast de départ**. `pre.001` doit la fusionner, scinder, supprimer ou prolonger selon le scope réellement démontré.

### `pre.001` — Audit actuel + héritage kbot3 + frontières + sizing

**Statut : prévu**

Lectures obligatoires, baseline, audit Core/Transport, audit kbot3, audit externe ciblé, matrice d'ownership, threat model, dependency graph, plan/validation et sizing. Aucun développement fonctionnel lourd.

### `pre.002` — Scaffold `ksp-interface-lib` + façade + firewall

**Statut : prévu**

Créer la crate, l'ajouter au workspace, poser la façade publique minimale, README/USAGE initiaux et canaris de dépendances. Ne pas introduire encore une grande famille wire si le scaffold suffit pour fermer la tranche.

### `pre.003` — Primitives publiques retenues

**Statut : prévu**

Introduire uniquement les wrappers/identités/bornes réellement confirmés par `pre.001`, en réutilisant Core lorsque possible. Aucun modèle d'acquisition général par anticipation.

### `pre.004` — Premier lot wire officiel retenu

**Statut : prévu**

Matérialiser le premier lot fonctionnel réellement justifié : layouts/types/codec/constructeurs wire selon le plan final. Aucun decode sémantique.

### `pre.005` — Second lot wire uniquement si démontré

**Statut : optionnel**

Ajouter une seconde famille uniquement si `pre.001` a démontré qu'elle appartient réellement à la foundation `0.2.13`. Supprimer cette tranche si le minimum est déjà complet.

### `pre.006` — Sérialisation / bornes / adversarial

**Statut : prévu**

Durcir round-trips, malformed/unknown, tailles hostiles, integer conversions, Debug, ordre et options. Si aucun codec n'est retenu, convertir cette tranche en hardening structurel pertinent plutôt que d'inventer de la sérialisation.

### `pre.007` — Consumer externe + API/dependency hardening

**Statut : prévu**

Prouver la consommation via crate-root, stabilité de la façade, firewall interne/externe, docs publiques et graphes Cargo. Aucun nouveau domaine wire opportuniste.

### `pre.008` — Gate technique final

**Statut : prévu**

Gate workspace complet, canaris public API/dependencies, `cargo tree` pertinents et audit de complétude de la surface retenue. Aucun README/USAGE final ni préparation de publication dans cette tranche.

### `pre.009` — Réconciliation documentaire finale

**Statut : prévu**

Réconcilier plan, validation, README/USAGE et architectures/références durables réellement affectées. Ne pas finaliser `CHANGELOG.md`, `ROADMAP.md` ni le prompt suivant.

### `pre.010` — Préparation de publication minimale

**Statut : prévu**

Modifier fonctionnellement uniquement :

```text
prompts/019-V0_2_14_START_PROMPT.md
CHANGELOG.md
ROADMAP.md
```

plus `Cargo.toml` et le delta mécanique requis. Aucun code, test, README, USAGE, plan, validation, règle ou architecture n'est rouvert.

### `rel.001` — Publication stable

**Statut : prévu**

Passer la version Cargo à `0.2.13`, exécuter le gate de publication requis, créer le commit de livraison puis le tag stable `v0.2.13` conformément au workflow KSP.

Les responsabilités de fermeture restent donc séparées :

```text
gate technique final
réconciliation documentaire
préparation de publication minimale
rel.001
```

Un `fix` reste strictement local à la responsabilité de sa tranche.

---

## 14. Versionnement, deltas, commits, archives et tags

Version Cargo des prereleases :

```text
0.2.13-pre.1
0.2.13-pre.2
...
0.2.13-pre.N.fix.M
```

Deltas :

```text
deltas/0.2.13/pre.001.md
deltas/0.2.13/pre.002.md
...
deltas/0.2.13/pre.NNN-fix.MMM.md
deltas/0.2.13/rel.001.md
```

Commits de livraison :

```text
v0.2.13-pre.001
v0.2.13-pre.002
v0.2.13-pre.NNN-fix.MMM
v0.2.13-rel.001
```

Aucun tag Git pour prerelease/fix/rel.

Seule la release stable reçoit :

```text
v0.2.13
```

Archives :

```text
ksp-general-<delivery-id>.zip
ksp-doc-<delivery-id>.zip lorsque le payload est strictement documentaire/prompts
```

Chaque archive contient uniquement les fichiers ajoutés/modifiés du delta plus son fichier delta. Les suppressions sont listées explicitement.

Une prerelease non-fix synchronise `workspace.package.version` même si elle est documentaire. Un fix purement documentaire ne force pas de bump Cargo ; un fix code/build/runtime/config suit l'identifiant SemVer technique prévu par `VERSION_WORKFLOW.md`.

Chaque delta est commité à partir de `0.1.x`; un fix ne réécrit jamais silencieusement le delta d'origine.

---

## 15. Validation opérateur et procédure d'application

Le mode opératoire reste celui des releases KSP récentes :

1. l'assistant travaille à partir de la base opérateur réellement validée ;
2. il produit un delta ZIP minimal ;
3. l'opérateur applique l'archive dans son checkout ;
4. l'opérateur exécute les gates ;
5. les logs réels font autorité pour fermer la tranche ou produire un fix ;
6. un fix reste dans le scope exact de la tranche défectueuse.

Gate Rust standard après modification :

```bash
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.13
cargo check --workspace
cargo clippy --workspace --all-targets
```

Puis tests ciblés de la crate :

```bash
cargo test -p ksp-interface-lib
```

Aux gates globaux :

```bash
cargo test --workspace
```

Lorsque le graphe change ou qu'une dépendance wire est ajoutée :

```bash
cargo tree -p ksp-interface-lib --edges normal
cargo tree --duplicates
cargo tree -i <dependency-fondamentale> si pertinent
```

Ne jamais déclarer PASS :

```text
cargo fmt
rust audit
cargo check
clippy
tests
cargo tree
```

si la commande correspondante n'a pas réellement été exécutée.

Il n'y a **aucun gate Tauri** par défaut pour `0.2.13`, car la release ne doit modifier aucune application.

Il n'y a **aucun smoke réseau** par défaut pour une crate wire pure. Si `pre.001` découvre un besoin réellement justifié, le gate doit être défini explicitement avant implémentation et ne doit pas transformer Interface en consumer réseau.

---

## 16. Tests et canaris attendus

Le plan final doit couvrir, selon la surface retenue :

### 16.1 Public API

```text
exports crate-root complets
aucun pub mod opportuniste
rustdoc public
consumer externe compile
aucun import de module privé nécessaire
```

### 16.2 Dependency firewall

```text
Interface -> Core seulement selon besoins réels
Interface -X-> Program API / Program Lib
Interface -X-> Config
Interface -X-> Transport
Interface -X-> Store
Interface -X-> Wallet
Interface -X-> Tauri
Interface -X-> reqwest / tonic / provider SDK
codec/direct protocol deps uniquement si possédés par le wire retenu
```

### 16.3 Wire fidelity

Selon le contrat :

```text
round-trip exact
fixtures officielles/externes lorsque disponibles
ordre préservé
unknown/malformed géré
absent/empty/value distingués
integer conversions vérifiées
no f64 canonical truth
```

### 16.4 Adversarial

```text
oversized bytes
oversized collections
invalid discriminant
truncated input
trailing data si interdit par le wire
path/index overflow
nested/pathological input
Debug borné
```

### 16.5 Architecture

Canaris empêchant l'introduction prématurée de :

```text
Decoder trait
Program registry comportemental
Materializer trait
Execution preparer
Store DTO
Transport dependency
```

### 16.6 External consumer

Le canari doit simuler une crate externe qui ne dépend pas de l'implémentation officielle Program et n'accède qu'à l'API publique Interface.

---

## 17. Critères de clôture de `0.2.13`

La release peut devenir stable seulement si :

```text
ksp-interface-lib existe dans le workspace
scope public final correspond au plan recalibré de pre.001
aucun trait Program n'a fuité dans Interface
aucun modèle RAW/CORE prématuré n'a été imposé
Program IDs fondamentaux restent dans Core
ownership de chaque type public est documenté
surface publique est consommable depuis crate externe
bornes/adversarial canaris verts
codec/serde éventuels sont justifiés et testés
dependency firewall vert
cargo tree pertinent inspecté si graphe modifié
cargo fmt + audit Rust + check + clippy verts
cargo test -p ksp-interface-lib vert
cargo test --workspace vert
aucun smoke réseau inventé sans besoin
README/USAGE finaux réconciliés dans la tranche documentaire dédiée
plan/validation/architecture durable réconciliés dans cette même tranche documentaire
prompt 0.2.14 finalisé seulement dans la dernière prerelease
CHANGELOG/ROADMAP finalisés seulement dans la dernière prerelease
aucun rattrapage code/doc dans rel.001
```

Le numéro de prerelease prévu n'est jamais un critère de clôture.

---

## 18. Release/session suivante envisagée

La release suivante est :

```text
0.2.14 — Program API foundation
```

Elle doit ouvrir `ksp-program-api` comme contrat **ouvert et extensible** pour les comportements Program réellement démontrés.

Inputs historiques utiles à réauditer alors, notamment depuis kbot3 :

```text
identity / descriptor
surfaces / capabilities
recognition
instruction/account decoder families
outcomes / diagnostics / proof
prepared execution boundary
external implementation canaries
```

Mais `0.2.13` ne doit pas figer leur forme trait avant cet audit.

Après `0.2.14`, les implémentations officielles `ksp-program-lib` arrivent avec les vertical slices qui en ont réellement besoin, et non comme une grande couche monolithique préalable.

La trajectoire RAW/CORE reste séparée :

```text
0.3.1  Store RAW
0.3.2  extension Interface pour wires génériques acquisition/CORE
```

---

## 19. Instruction d'ouverture

Au début de la session `0.2.13` :

1. confirmer la base stable `v0.2.12` ou l'archive stable opérateur autoritaire ;
2. vérifier `workspace.package.version = 0.2.12` et `deltas/0.2.12/rel.001.md` ;
3. lire les règles de la section 3.1 dans l'ordre ;
4. lire l'architecture de la section 3.2, en particulier `006-WIRE_AND_PROGRAM.md` ;
5. relire la séquence fonctionnelle et la clôture `0.2.12` ;
6. exécuter la baseline complète avant développement lourd ;
7. inventorier la surface publique réelle Core et les DTOs Transport pertinents ;
8. réinspecter l'archive kbot3 si elle est disponible ;
9. produire la matrice `REPRENDRE / REDESSINER / REPORTER / REJETER` ;
10. auditer uniquement les sources externes réellement candidates et leurs versions actuelles ;
11. décider le premier minimum wire de `ksp-interface-lib` ;
12. produire la matrice d'ownership `Core / Interface / Transport / Program API / 0.3.2+` ;
13. décider bytes/bornes/serde/codec/versionnement/error model ;
14. produire la façade publique conceptuelle et le dependency graph cible ;
15. produire le threat/robustness model et la stratégie de tests ;
16. dimensionner la release et chaque tranche ;
17. créer le plan `020`, la validation `016` et `deltas/0.2.13/pre.001.md` ;
18. **ne pas commencer les traits Program, les decoders, les materializers, l'execution ou un modèle RAW/CORE complet avant la fermeture de ce gate**.

La première réponse de travail de la nouvelle session doit donc être un **audit/sizing `0.2.13-pre.001` complet**, avec matrice d'héritage kbot3, frontières, surface wire proposée, dépendances, risques, tests et forecast recalibré — pas un scaffold déjà figé ni un portage de `ks-lib`.