v0.2.0-pre.003

This commit is contained in:
2026-08-17 16:05:58 +02:00
parent 259bff6707
commit e721464a7c
23 changed files with 609 additions and 96 deletions

View File

@@ -1,5 +1,5 @@
<!-- file: docs/validation/000-README.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Validations KSP
@@ -10,3 +10,4 @@ Les deltas restent lhistorique autoritatif des livraisons ; une matrice de va
Documents :
- [`001-V0_1_4_CONFIG_DESKTOP.md`](001-V0_1_4_CONFIG_DESKTOP.md) — matrice finale de `0.1.4 — ksp-app-config-desk`.
- [`002-V0_2_0_SERIES_PLANNING.md`](002-V0_2_0_SERIES_PLANNING.md) — audit final de cohérence et matrice de clôture documentaire de `0.2.0`.

View File

@@ -0,0 +1,173 @@
<!-- file: docs/validation/002-V0_2_0_SERIES_PLANNING.md -->
<!-- version: 2 -->
# 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` et vérifie que le cadrage demandé par `prompts/005-V0_2_0_START_PROMPT.md` est suffisamment complet avant publication stable.
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 13 |
| 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 ~1520 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 D1D4** 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`.
## Statut de clôture
Après application et validation de `0.2.0-pre.003`, aucun développement N2 n'est attendu dans `0.2.0`.
La publication `0.2.0-rel.001` peut être préparée si les validations locales ne révèlent pas d'écart supplémentaire.
Le `rel.001` doit essentiellement :
```text
workspace.package.version -> 0.2.0
ROADMAP / plans / indices -> 0.2.0 stable
CHANGELOG.md -> entrée stable 0.2.0
deltas/0.2.0/rel.001.md
validations globales finales
commit v0.2.0-rel.001
tag Git v0.2.0
```
Le prompt à utiliser ensuite est :
```text
prompts/006-V0_2_1_START_PROMPT.md
```