198 lines
14 KiB
Markdown
198 lines
14 KiB
Markdown
<!-- file: docs/validation/002-V0_2_0_SERIES_PLANNING.md -->
|
||
<!-- version: 3 -->
|
||
|
||
# Validation `0.2.0` — audit bot3 et planification de la série `0.2.x`
|
||
|
||
## Objet
|
||
|
||
Cette matrice synthétise l'audit final de `0.2.0`, les preuves opérateur de `pre.003` et la clôture publiée par `0.2.0-rel.001` conformément au cadrage demandé par `prompts/005-V0_2_0_START_PROMPT.md`.
|
||
|
||
Elle ne remplace ni `docs/plans/007-V0_2_0_SERIES_PLANNING.md` ni les deltas `0.2.0`.
|
||
|
||
## Base auditée
|
||
|
||
```text
|
||
KSP : khadhroony-solana-project_v0.2.0-pre.002-full-from-git.zip
|
||
bot3 : khadhroony-bot3_v0.5.3-pre.005-fix010.zip
|
||
```
|
||
|
||
Audit final réalisé le :
|
||
|
||
```text
|
||
2026-08-17
|
||
```
|
||
|
||
## Matrice de clôture
|
||
|
||
| Critère | Statut après `pre.003` | Preuve / décision |
|
||
|-------------------------------------------------------------------------------------------------|------------------------|----------------------------------------------------------------------------------------------------------------------|
|
||
| Méthode d'audit bot3 définie | OK | `007`, sections 1–3 |
|
||
| Cartographie Wallet / Transport / Interface / Program / scenarios | OK | `007`, matrice section 16 + architecture KSP |
|
||
| Distinction fonctionnalité / implémentation / contrat / dépendance / convention | OK | `007`, section 3 |
|
||
| Matrice reprendre / adapter / refondre / abandonner / ajouter | OK | `007`, section 16 |
|
||
| Config reste propriétaire exclusif de Config/env | OK | Transport ne dépend pas de Config ; adapter Config -> Transport |
|
||
| Logging reste façade runtime | OK | warnings Transport imposés via `ksp-logging-lib` |
|
||
| Wallet temporaire bot2/bot3 abandonné | OK | `.kspwallet` devient le format natif ; scenarios futurs utilisent de vrais wallets |
|
||
| `WalletPolicy` sortie du Wallet | OK | future `ksp-execution-policy-api` / policy contextuelle |
|
||
| TODO import/export bot3 utiles préservés | OK | `IDEAS.md` inclut Solana CLI/Base58, Phantom, Solflare/keystore, Backpack, Trust Wallet, Base app et distinction CDP |
|
||
| Ordre `0.2.1+` justifié par dépendances | OK | HTTP précède Wallet/Wallet Desk ; transports live puis off-chain puis Interface/Program |
|
||
| Chaque release `0.2.1+` possède mission/périmètre/hors-périmètre/dépendances/clôture/estimation | OK | `007`, section 4.8 |
|
||
| Discipline ~15–20 min/prerelease | OK | règles release/prompt |
|
||
| Une release concrète = une seule session de chat | OK | gate de sizing obligatoire à `pre.001` |
|
||
| Transport couvre toute documentation normative ciblée | OK | règle `KSP-TRANSPORT-006` |
|
||
| Deprecated/obsolete encore fonctionnel => `warn` | OK | règle `KSP-TRANSPORT-006` |
|
||
| Unstable/experimental => `warn` | OK | règle `KSP-TRANSPORT-006` |
|
||
| RAW -> CORE indépendant de Program decoding | OK | règles/architecture corrigées depuis `pre.002` |
|
||
| Pipeline durable RAW -> CORE -> DECODE -> SPECIALIZED | OK | architecture 008/009, plans 002/007 |
|
||
| RAW et CORE progressent horizontalement | OK | workers/jobs/apps ajoutés à la fin de chaque couche selon besoin |
|
||
| DECODE+ progresse verticalement groupe par groupe | OK | `KSP-FLOW-001` |
|
||
| Satellites protocole restent dans leur groupe | OK | `KSP-FLOW-002` |
|
||
| Ancienne chaîne globale materializer/projector supprimée comme décision active | OK | `KSP-WORKER-008`, `KSP-JOB-009` corrigé, IDEAS requalifié |
|
||
| Ordre Program orienté trading défini | OK | Core -> SPL token -> metadata -> Anchor -> Meteora/Raydium/Pump/Orca -> routing -> trading-adjacent -> généraliste |
|
||
| Market Desk progressive prévue | OK | V1 après DEX prioritaires, enrichissement après routing |
|
||
| Première release fonctionnelle décidée | OK | `0.2.1 — ksp-onchain-transport-lib / HTTP Solana foundation` |
|
||
| Prompt `0.2.1` finalisé | OK | `prompts/006-V0_2_1_START_PROMPT.md` version 2 |
|
||
| Collisions d'identifiants normatifs | CORRIGÉ | `KSP-TRANSPORT-006`, `KSP-FLOW-001/002`; les IDs notification existants restent inchangés |
|
||
| Jobs de replay globaux historiques | CORRIGÉ | aucune liste DECODE/SPECIALIZED globale figée ; replay introduit par frontière/groupe réel |
|
||
|
||
## Spot-check Transport HTTP avant `0.2.1`
|
||
|
||
Ce contrôle n'est **pas** la matrice normative de `0.2.1`; il sert uniquement à vérifier que le sizing du prompt est crédible et que bot3 ne constitue pas la source de vérité.
|
||
|
||
### Documentation Solana observée le 2026-08-17
|
||
|
||
Index HTTP officiel :
|
||
|
||
```text
|
||
https://solana.com/docs/rpc/http
|
||
```
|
||
|
||
Le spot-check recense **52 méthodes dans l'index HTTP courant**.
|
||
|
||
La documentation Solana possède aussi une section `Deprecated Methods` séparée. Le spot-check observe **14 noms deprecated** dans cette section. Une page deprecated peut indiquer une suppression attendue dans une ancienne génération de `solana-core`; `0.2.1-pre.001` doit donc vérifier la disponibilité runtime actuelle avant de conclure qu'elle reste supportable.
|
||
|
||
Exemple de source officielle :
|
||
|
||
```text
|
||
https://solana.com/docs/rpc/deprecated/getrecentblockhash
|
||
```
|
||
|
||
### Comparaison bot3
|
||
|
||
`ks-onchain-transport/src/standard_methods.rs` contient les **52 noms de l'index HTTP courant** observé lors de ce spot-check, mais ne contient pas les 14 anciennes méthodes deprecated séparées.
|
||
|
||
Cette égalité de noms ne signifie pas égalité de contrat : bot3 distingue notamment des méthodes avec typed adapter et des méthodes seulement enregistrées/raw JSON. KSP doit auditer request/response/status/tests méthode par méthode.
|
||
|
||
Conclusion :
|
||
|
||
- l'existant bot3 est une bonne source d'inventaire et de comportements historiques ;
|
||
- il n'est pas la norme ;
|
||
- `0.2.1-pre.001` doit refaire la matrice depuis la documentation officielle du jour ;
|
||
- la section deprecated séparée doit être inspectée explicitement ;
|
||
- si le nombre réel de méthodes + niveau de typage + pools/config rendent `0.2.1` trop risquée pour une seule session, la release est redécoupée **avant** l'implémentation lourde.
|
||
|
||
## Écarts trouvés dans `pre.002` et corrigés par `pre.003`
|
||
|
||
### IDs normatifs dupliqués
|
||
|
||
`RULES_KSP.md` réutilisait :
|
||
|
||
```text
|
||
KSP-TRANSPORT-001
|
||
KSP-DATA-001
|
||
KSP-DATA-002
|
||
```
|
||
|
||
pour deux décisions différentes chacune.
|
||
|
||
Correction :
|
||
|
||
```text
|
||
KSP-TRANSPORT-001 conserve la décision de ne pas créer ksp-onchain-transport-api
|
||
KSP-TRANSPORT-006 porte la couverture documentaire exhaustive
|
||
KSP-DATA-001/002 restent les règles historiques de notification de données
|
||
KSP-FLOW-001/002 portent la progression durable et les satellites de protocole
|
||
```
|
||
|
||
### Replay jobs supersédés
|
||
|
||
`KSP-JOB-009` imposait encore :
|
||
|
||
```text
|
||
ksp-job-replay-core
|
||
ksp-job-replay-generic-materialization
|
||
ksp-job-replay-domain-projection
|
||
```
|
||
|
||
La règle est remplacée par une introduction need-driven des replays : CORE lorsqu'il existe, puis groupes/capacités verticaux à partir de DECODE.
|
||
|
||
### Diagramme workers encore trop figé
|
||
|
||
`docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md` conservait encore un schéma `W1 -> D1 -> W2 -> D2 -> W3 -> D3 -> W4 -> D4`. Même sans noms concrets, il pouvait réintroduire l'idée de quatre workers globaux correspondant mécaniquement aux quatre niveaux durables. `pre.003` le remplace par un diagramme des **frontières de données D1–D4** et précise que RAW/CORE peuvent avoir leurs workers horizontaux tandis que DECODE/SPECIALIZED utilisent des workers/processors need-driven par groupe vertical.
|
||
|
||
### IDEAS Wallet incomplet
|
||
|
||
Le TODO bot3 conservait plusieurs cibles étudiées mais non implémentées. Elles sont maintenant explicitement reportées dans KSP sans en faire des engagements prématurés : Backpack, Trust Wallet, Solflare Keystore, Base app/ex-Coinbase Wallet et distinction Coinbase Developer Platform.
|
||
|
||
### Plan directeur incomplet sur les releases
|
||
|
||
Le prompt `0.2.0` demandait pour chaque release `0.2.1+` : mission, périmètre, hors-périmètre, dépendances, critères de clôture et estimation souple des prereleases. `pre.002` n'avait pas encore regroupé ces six dimensions pour toutes les releases. `pre.003` ajoute les fiches correspondantes dans `007`.
|
||
|
||
## Anomalie historique non bloquante
|
||
|
||
Le scan global des headers Markdown détecte un ancien delta déjà livré :
|
||
|
||
```text
|
||
deltas/0.1.4/pre.016-fix.002.md
|
||
```
|
||
|
||
qui ne possède pas les deux commentaires d'en-tête `file/version` utilisés par la convention actuelle. Ce fichier appartient à l'historique publié `0.1.4` et n'est **pas réécrit silencieusement** dans `0.2.0-pre.003`, conformément à la règle d'immutabilité pratique des deltas livrés. Cette anomalie ne modifie aucune règle/architecture active et ne bloque pas `0.2.0`.
|
||
|
||
## Preuves opérateur finales de `pre.003`
|
||
|
||
Le user a communiqué le 2026-08-17, sur le commit :
|
||
|
||
```text
|
||
e721464a7c2cbf4c564757061a2a44dd7913facb
|
||
v0.2.0-pre.003
|
||
```
|
||
|
||
les validations suivantes avec succès :
|
||
|
||
```bash
|
||
cargo fmt --all
|
||
cargo check --workspace
|
||
cargo clippy --workspace --all-targets
|
||
cargo test --workspace
|
||
git diff --check
|
||
git status --short
|
||
```
|
||
|
||
Résultats synthétiques :
|
||
|
||
- `cargo check --workspace` : succès ;
|
||
- `cargo clippy --workspace --all-targets` : succès sans warning communiqué ;
|
||
- `cargo test --workspace` : **241 tests réussis**, aucun échec ; le probe diagnostic d'overhead de `ksp-logging-lib` reste volontairement `ignored` ;
|
||
- `git diff --check` : aucune sortie ;
|
||
- `git status --short` : aucune sortie, working tree propre ;
|
||
- `git log -1 --oneline --decorate` confirme `e721464 (HEAD -> master, origin/master) v0.2.0-pre.003`.
|
||
|
||
Aucun écart supplémentaire n'a été révélé par cette validation. Aucune `pre.004` n'est donc requise.
|
||
|
||
## Statut de clôture
|
||
|
||
`0.2.0-rel.001` publie le cadrage sous `workspace.package.version = "0.2.0"` sans développement N2 ni nouvelle décision architecturale.
|
||
|
||
Après validation du delta stable, les identifiants Git attendus sont :
|
||
|
||
```text
|
||
commit : v0.2.0-rel.001
|
||
tag : v0.2.0
|
||
```
|
||
|
||
La release suivante s'ouvre avec :
|
||
|
||
```text
|
||
prompts/006-V0_2_1_START_PROMPT.md
|
||
```
|