243 lines
8.6 KiB
Markdown
243 lines
8.6 KiB
Markdown
<!-- file: deltas/0.2.0/pre.001.md -->
|
|
<!-- version: 1 -->
|
|
|
|
# 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é.
|