# 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 ```