# Delta 0.2.0-pre.001 ## Base requise Release stable attendue : ```text v0.1.4 ``` L'archive KSP fournie contient : ```text workspace.package.version = "0.1.4" ``` et les quatre fondations stabilisées : - `ksp-core-lib` ; - `ksp-logging-lib` ; - `ksp-config-lib` ; - `ksp-app-config-desk`. L'archive ne contient pas `.git`; le tag `v0.1.4` n'est donc pas revérifiable localement depuis le zip. Le snapshot `khadhroony-bot3` fourni pour audit est l'archive d'échange : ```text khadhroony-bot3_v0.5.3-pre.005-fix010.zip ``` Son `Cargo.toml` porte `workspace.package.version = "0.5.3-pre.5"`. ## Objectif Ouvrir `0.2.0` par la tranche obligatoire de brainstorming, inventaire et méthode d'audit, sans commencer l'implémentation d'une capacité Solana N2. Le plan directeur est créé dans : ```text docs/plans/007-V0_2_0_SERIES_PLANNING.md ``` ## Version Cargo Conformément à `VER-ID-009`, une prerelease non-fix synchronise la version Cargo même lorsque son contenu fonctionnel est documentaire. `workspace.package.version` passe donc de : ```text 0.1.4 ``` à : ```text 0.2.0-pre.1 ``` L'identifiant de livraison reste : ```text 0.2.0-pre.001 ``` Aucune nouvelle dépendance n'est ajoutée. ## Méthode d'audit définie Chaque élément bot3 est désormais séparé en : - fonctionnalité ; - implémentation historique ; - contrat public ; - dépendance externe ; - convention de projet. La décision `reprendre / adapter / refondre / abandonner / ajouter` porte d'abord sur le besoin et le contrat utile, jamais implicitement sur une copie du code. La fiche d'audit couvre ownership, dépendances, Config/environnement, Logging, tests/invariants, dette, risques et lot `0.2.x` candidat. ## Première cartographie bot3 Le snapshot a été inspecté par domaines. ### Wallet `ks-wallet` expose notamment alias/identité non secrète, wallet temporaire, manager multi-wallet, format `.kswallet` protégé, password redacted, `UnlockedWallet`, création atomique/no-clobber, changement de password, migration legacy, import/export Solana CLI JSON/Base58 et contrôles de collision. Les invariants de sécurité et le contrat de capacité de signature sont des candidats forts à la reprise/adaptation. Le store JSON legacy `TemporaryWalletStore` et le `lamport_spend_limit` situé dans `WalletPolicy` ne sont pas retenus comme frontières cibles. ### Transport `ks-onchain-transport` possède une surface HTTP/WS importante : JSON-RPC, pools, rôles/quota, typed standard methods, sessions/subscriptions/reconnect et méthodes techniques d'exécution. Deux couplages imposent déjà une refonte de frontière : - le public transport consomme directement des types `ks-config` ; - `getTransaction` et le trait RPC minimal dépendent de types `ks-lib`. KSP doit produire des modèles transport homogènes possédés par `ksp-onchain-transport-lib`, sans dépendance Program/Store. ### Interface / Program / Execution Bot3 ne possède pas de crate Interface isolée : wire, codecs et protocoles sont dispersés dans `ks-lib`, qui regroupe decoder, executor et materializer. Les API `DcApi*` / `ExApi*` contiennent des concepts utiles mais ne correspondent pas au découpage KSP cible. Elles seront utilisées comme inventaire de contrats et de preuves, puis réparties entre `ksp-interface-lib`, `ksp-program-api`, `ksp-program-lib`, `ksp-execution-policy-api` et éventuellement `ksp-execution-lib`. ### Scénarios/demos Le principe de scénarios réutilisables hors Tauri est conservé. En revanche la crate multi-domaines `ks-pipeline-demo-scenarios` et l'application omnibus `kb-app-demo-desktop` ne sont pas des modèles cibles KSP. ### Off-chain Aucune crate générale off-chain n'existe dans le snapshot. Le besoin reste conditionnel et ne sera pas introduit par anticipation. ## Première matrice Le plan `007` contient une première matrice provisoire couvrant Wallet, Transport, Interface, Program, Execution, scenarios/demos et off-chain. Aucun numéro `0.2.1+` n'est figé dans cette tranche. Les candidats restent des lots fonctionnels non numérotés. ## Graphe de dépendances initial Le plan confirme notamment : ```text Wallet ---------------------------+ | Interface -> Program API/Program -+-> Execution policy -> Execution | Transport ------------------------+ ``` avec les nuances suivantes : - Wallet, Transport et Interface sont largement indépendants au démarrage ; - Program dépend d'Interface pour la première surface wire réelle ; - Execution ne doit être créée que si un cycle réel justifie Program + Policy + Wallet + Transport ; - Store/Materializer/worker restent hors `0.2.x`. ## Prévision souple de `0.2.0` Le plan prévoit initialement : ```text pre.001 méthode + cartographie initiale pre.002 Wallet pre.003 transport on-chain pre.004 Interface/wire + dépendances pre.005 Program API/Program pre.006 policy/execution pre.007 scenarios/demos/off-chain gaps pre.008 matrice/graphe/découpage candidat pre.009 challenge et dimensionnement des releases 0.2.1+ pre.010 clôture/docs/nettoyage/prompt suivant ``` La séquence reste révisable. ## Fichiers ajoutés ```text docs/plans/007-V0_2_0_SERIES_PLANNING.md deltas/0.2.0/pre.001.md ``` ## Fichiers modifiés ```text Cargo.toml ROADMAP.md docs/000-README.md docs/plans/000-README.md docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md ``` ## Fichiers supprimés Aucun. ## Validations exécutées - lecture de `ROADMAP.md`, de `docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md`, des règles KSP et des documents d'architecture Program/Wire/Execution/Scenario ; - inspection du workspace KSP stable `0.1.4` ; - inspection du workspace bot3 fourni et de ses manifests ; - inventaire ciblé de `ks-wallet`, `ks-wallet-demo-scenarios`, `ks-onchain-transport`, `ks-lib`, `ks-pipeline`, `ks-pipeline-demo-scenarios` et `kb-app-demo-desktop` ; - inspection des guides/rapports Wallet bot3 et de la configuration historique Wallet/Transport/Execution ; - contrôle de la présence des surfaces public decoder/executor et des principaux couplages de dépendances ; - vérification documentaire de l'absence de développement N2 dans cette tranche. ## Validations non exécutées Aucune fonctionnalité Rust n'est ajoutée et aucune dépendance n'est modifiée hors signal de version Cargo. Les versions upstream des dépendances candidates ne sont pas auditées dans `pre.001` car aucune dépendance n'est introduite. Elles seront vérifiées depuis les sources officielles au moment où une tranche décide réellement de les ajouter. Le sandbox de préparation ne fournit pas le binaire `cargo` (`cargo: command not found`). Les validations suivantes n'ont donc pas pu être exécutées ici : ```text cargo fmt --all -- --check cargo check --workspace cargo clippy --workspace --all-targets cargo test --workspace ``` Elles devront être rejouées sur le poste de développement avant commit de `pre.001`. L'archive source KSP fournie ne contient pas de métadonnées `.git`. Le commit ne peut donc pas être créé ni vérifié dans ce sandbox. Après application de la livraison sur le checkout Git canonique et validation technique, le commit attendu suit `VER-GIT-001` : `v0.2.0-pre.001`. ## Décisions prises - `0.2.0` reste une release d'audit, pas la première release N2 ; - aucune migration mécanique de bot3 ; - fondations bot3 déjà remplacées par `0.1.x` utilisées uniquement comme référence historique ; - Wallet bot3 considéré comme candidat mature à reprendre/adapter, avec abandon du store JSON legacy comme cible ; - Transport bot3 considéré comme riche fonctionnellement mais nécessitant une nouvelle frontière publique sans `ks-lib` ; - `ks-lib` monolithique non retenu comme architecture cible ; - Interface/wire doit être auditée contrat par contrat ; - Program preparation, policy et execution restent séparés ; - scenarios réutilisables conservés comme méthode, mais spécialisés par domaine ; - off-chain reste `need-driven` ; - aucun numéro `0.2.1+` n'est figé dans `pre.001`. ## Questions ouvertes Les questions structurantes sont conservées dans le plan `007`, notamment : - compatibilité exacte du format `.kswallet` bot3 avec KSP ; - primitive signer publique minimale ; - séparation ou non des releases Transport HTTP/WS ; - frontière transport/Core de `getTransaction` ; - stratégie exacte de réexport/réimplémentation des interfaces Solana/SPL/Metaplex ; - choix du premier Program canari ; - nécessité réelle d'Execution dans `0.2.x`. La prochaine tranche prévue est l'audit Wallet détaillé.