v0.2.0-pre.1
This commit is contained in:
242
deltas/0.2.0/pre.001.md
Normal file
242
deltas/0.2.0/pre.001.md
Normal file
@@ -0,0 +1,242 @@
|
||||
<!-- 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é.
|
||||
Reference in New Issue
Block a user