khadhroony-solana-project/deltas/0.2.0/pre.001.md

Delta 0.2.0-pre.001

Base requise

Release stable attendue :

v0.1.4

L'archive KSP fournie contient :

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 :

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 :

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 :

0.1.4

à :

0.2.0-pre.1

L'identifiant de livraison reste :

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 :

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 :

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

docs/plans/007-V0_2_0_SERIES_PLANNING.md
deltas/0.2.0/pre.001.md

Fichiers modifiés

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 :

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é.