v0.2.0-pre.003
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/plans/007-V0_2_0_SERIES_PLANNING.md -->
|
||||
<!-- version: 2 -->
|
||||
<!-- version: 4 -->
|
||||
|
||||
# Plan `0.2.0` — audit bot3 et planification de la série `0.2.x`
|
||||
|
||||
@@ -58,7 +58,7 @@ Les statuts de décision sont :
|
||||
|
||||
`reprendre` ne signifie jamais « copier mécaniquement le code ».
|
||||
|
||||
## 4. Décisions de `0.2.0-pre.002`
|
||||
## 4. Décisions stabilisées par `0.2.0-pre.002` / `pre.003`
|
||||
|
||||
### 4.1 Ordre fonctionnel initial de la série
|
||||
|
||||
@@ -198,6 +198,113 @@ Le `pre.001` de `0.2.6` devra inventorier la surface normative Yellowstone réel
|
||||
|
||||
Les adaptations/provider profiles plus avancés sont reportés après les fondations prioritaires.
|
||||
|
||||
### 4.8 Fiches de releases `0.2.1+`
|
||||
|
||||
Ces fiches complètent la simple séquence numérique. Elles sont **souples** : le `pre.001` de chaque release refait le sizing sur les dépendances et documentations réellement actuelles. Une estimation ne justifie jamais d'ouvrir une release dont la clôture dans la même session paraît incertaine.
|
||||
|
||||
#### `0.2.1` — HTTP Solana foundation
|
||||
|
||||
- **Mission :** créer `ksp-onchain-transport-lib` avec JSON-RPC HTTP Solana complet, settings publics, pool logique d'endpoints, rôles/capabilities/limites et adapter Config -> Transport.
|
||||
- **Périmètre :** index HTTP officiel courant, méthodes deprecated/obsolete encore réellement utilisables, éventuelles méthodes HTTP unstable/experimental documentées, read/write technique, timeouts, retry/backoff, health et observabilité.
|
||||
- **Hors périmètre :** Wallet, WebSocket, LaserStream, gRPC, Store, Program, orchestration d'exécution.
|
||||
- **Dépendances :** fondations `0.1.x`; `ksp-config-lib` peut dépendre des contrats Transport pour l'adapter, jamais l'inverse.
|
||||
- **Clôture :** matrice documentaire exhaustive et testée, ownership propre, warnings de statut, pools/rôles validés, README/USAGE et prompt `0.2.2`.
|
||||
- **Estimation souple :** environ 8–12 prereleases courtes **si** le gate `pre.001` confirme qu'elles restent clôturables dans une seule session ; sinon scinder avant implémentation lourde.
|
||||
|
||||
#### `0.2.2` — Wallet foundation
|
||||
|
||||
- **Mission :** créer `ksp-wallet-lib` et le format natif `.kspwallet`.
|
||||
- **Périmètre :** création/ouverture, protection du secret, identité/pubkey, signature, changement de mot de passe, atomicité/no-clobber, import/export extensible et premiers formats réellement validés.
|
||||
- **Hors périmètre :** `WalletPolicy`, wallet JSON temporaire bot2/bot3, UI Tauri, lecture de solde réseau.
|
||||
- **Dépendances :** Core/Logging et primitives crypto/signature nécessaires ; aucun besoin de dépendre de Transport pour le cœur Wallet.
|
||||
- **Clôture :** format documenté/testé, secret non exposé, import/export round-trip retenu, README/USAGE et prompt Wallet Desk.
|
||||
- **Estimation souple :** environ 5–8 prereleases.
|
||||
|
||||
#### `0.2.3` — `ksp-app-wallet-desk`
|
||||
|
||||
- **Mission :** valider en Tauri Config composite + Wallet + HTTP.
|
||||
- **Périmètre :** sélection/ouverture de wallet, identité/pubkey, affichage du solde réel via `getBalance`, opérations Wallet utiles à la première UI, instrumentation Logging et modèle Tauri Config Desk.
|
||||
- **Hors périmètre :** WebSocket, trading, execution policy, duplication de cryptographie ou JSON-RPC dans l'app.
|
||||
- **Dépendances :** `0.2.1`, `0.2.2`, Config Desk/Tauri conventions.
|
||||
- **Clôture :** flux opérateur bout en bout sur un endpoint réel configurable, secrets protégés, build Tauri final exécuté en dernière opération de validation.
|
||||
- **Estimation souple :** environ 5–8 prereleases.
|
||||
|
||||
#### `0.2.4` — WebSocket Solana standard
|
||||
|
||||
- **Mission :** ajouter la surface WebSocket Solana standard complète au transport.
|
||||
- **Périmètre :** sessions persistantes, subscriptions/unsubscriptions/notifications documentées, reconnexion bornée, plusieurs sessions possibles sur une même URL, plusieurs subscriptions par session.
|
||||
- **Hors périmètre :** scheduler/pool automatique complexe de sessions, Helius-specific, Yellowstone.
|
||||
- **Dépendances :** `0.2.1` et contrats Transport déjà stabilisés.
|
||||
- **Clôture :** matrice WS exhaustive, lifecycle/reconnect/tests réseau opt-in et warnings pour toute surface unstable/deprecated concernée.
|
||||
- **Estimation souple :** environ 5–8 prereleases.
|
||||
|
||||
#### `0.2.5` — Helius LaserStream WebSocket
|
||||
|
||||
- **Mission :** étendre le moteur WS standard avec la surface Helius ciblée sans dupliquer le client.
|
||||
- **Périmètre :** opérations/filtres/notifications/capabilities Helius documentés et réellement disponibles au moment de la release.
|
||||
- **Hors périmètre :** gRPC LaserStream, autres providers, shred delivery.
|
||||
- **Dépendances :** `0.2.4`.
|
||||
- **Clôture :** extensions isolées du moteur commun, matrice Helius, tests opt-in selon credentials disponibles, absence de secret dans les logs.
|
||||
- **Estimation souple :** environ 3–5 prereleases.
|
||||
|
||||
#### `0.2.6` — Yellowstone gRPC standard foundation
|
||||
|
||||
- **Mission :** introduire un client/backend Yellowstone standard et provider-neutral.
|
||||
- **Périmètre :** surface normative retenue à `pre.001`, connexion/auth metadata générique, stream/subscription, filtres et lifecycle nécessaires.
|
||||
- **Hors périmètre :** profils commerciaux spécifiques Helius/Triton/ERPC/Chainstack/Shyft, shred/deshred et optimisations provider-only.
|
||||
- **Dépendances :** transport foundation ; aucun provider ne devient propriétaire du contrat.
|
||||
- **Clôture :** matrice protocolaire, test contre au moins un endpoint réellement accessible lorsque possible, comportement provider-neutral documenté.
|
||||
- **Estimation souple :** environ 4–7 prereleases, avec gate de découpage obligatoire si la surface normative courante dépasse ce qui est raisonnablement clôturable dans la session.
|
||||
|
||||
#### `0.2.7` — Off-chain price transport
|
||||
|
||||
- **Mission :** créer `ksp-offchain-transport-lib` sur un premier besoin réel de prix.
|
||||
- **Périmètre :** abstraction de lecture de prix, premier provider, au minimum SOL/USD et SOL/EUR, erreurs/timeouts/observabilité et settings publics nécessaires.
|
||||
- **Hors périmètre :** metadata HTTP/IPFS/Arweave, quotes/routing, agrégation multi-provider complexe.
|
||||
- **Dépendances :** fondations Core/Logging ; indépendante du transport on-chain sauf composition applicative.
|
||||
- **Clôture :** provider interchangeable derrière le contrat retenu, prix typés/testés, README/USAGE.
|
||||
- **Estimation souple :** environ 3–5 prereleases.
|
||||
|
||||
#### `0.2.8` — Price Desk
|
||||
|
||||
- **Mission :** valider le transport off-chain dans une petite application Tauri.
|
||||
- **Périmètre :** Config, sélection/refresh des paires supportées, affichage des prix et provenance/état utiles.
|
||||
- **Hors périmètre :** Market Desk DEX/OHLC, trading et metadata.
|
||||
- **Dépendances :** `0.2.7` + conventions Tauri stabilisées.
|
||||
- **Clôture :** UI mince fonctionnelle, refresh observable, erreurs sûres et build Tauri final.
|
||||
- **Estimation souple :** environ 3–5 prereleases.
|
||||
|
||||
#### `0.2.9` — `ksp-interface-lib` foundation
|
||||
|
||||
- **Mission :** ouvrir la façade wire officielle KSP et son API publique utilisable aussi par des crates externes.
|
||||
- **Périmètre :** organisation wire, règles réexport/wrapper/réimplémentation compatible, premiers types/interfaces Solana réellement nécessaires et canaries de compatibilité.
|
||||
- **Hors périmètre :** inventaire exhaustif de tous les protocoles Solana/SPL/Metaplex, Program implementations complètes.
|
||||
- **Dépendances :** Core et dépendances wire externes explicitement retenues/centralisées au workspace.
|
||||
- **Clôture :** API publique cohérente avec les implémentations internes, aucune dépendance métier externe inutile dans les couches supérieures, README/USAGE.
|
||||
- **Estimation souple :** environ 4–7 prereleases.
|
||||
|
||||
#### `0.2.10` — `ksp-program-api` foundation
|
||||
|
||||
- **Mission :** introduire le contrat extensible Program avant les vertical slices réels.
|
||||
- **Périmètre :** identité/capabilities, contrats de décodage et préparation d'exécution nécessaires à une implémentation externe, support/deprecation machine-readable et extension ouverte.
|
||||
- **Hors périmètre :** `ksp-program-lib` exhaustif, materializers, execution engine, scénarios.
|
||||
- **Dépendances :** Core + `ksp-interface-lib` lorsque les contrats wire le nécessitent.
|
||||
- **Clôture :** une implémentation externe fictive/test démontre que l'API n'impose pas `ksp-program-lib`; contrats documentés et prompt de la série suivante préparé.
|
||||
- **Estimation souple :** environ 3–5 prereleases.
|
||||
|
||||
### 4.9 Audit final `0.2.0-pre.003`
|
||||
|
||||
L'audit final de la base Git `0.2.0-pre.002` a relevé et corrige les écarts suivants avant release stable :
|
||||
|
||||
- collisions d'identifiants normatifs dans `RULES_KSP.md` (`KSP-TRANSPORT-001`, `KSP-DATA-001`, `KSP-DATA-002`) ;
|
||||
- ancienne règle `KSP-JOB-009` imposant encore trois jobs de replay globaux incompatibles avec la progression verticale décidée ;
|
||||
- ancien diagramme `W1 -> D1 -> W2 -> D2 -> W3 -> D3 -> W4 -> D4` dans `010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md`, encore susceptible d'être lu comme quatre workers globaux imposés ; il est remplacé par les frontières durables D1–D4 et une granularité worker need-driven ;
|
||||
- entrées `IDEAS.md` encore formulées autour de `generic-materialization` / `domain-projection` et d'un type global `DomainProjector` ;
|
||||
- TODO Wallet bot3 utiles non encore reportés explicitement : Backpack, Trust Wallet, Solflare keystore, Base app/ex-Coinbase Wallet et distinction Coinbase Developer Platform ;
|
||||
- absence dans le plan directeur des fiches mission/périmètre/hors-périmètre/dépendances/clôture/estimation demandées pour chaque release `0.2.1+`.
|
||||
|
||||
Un spot-check externe effectué le **2026-08-17** sur la documentation officielle Solana observe 52 méthodes dans l'index HTTP courant et 14 noms dans la section officielle Deprecated Methods. L'inventaire bot3 contient les 52 noms de l'index courant, mais pas la surface deprecated séparée. Cette observation confirme l'intérêt de réutiliser l'inventaire fonctionnel bot3 tout en imposant à `0.2.1-pre.001` un nouvel audit officiel complet ; **les nombres observés ici ne deviennent pas un contrat durable**.
|
||||
|
||||
## 5. Wallet
|
||||
|
||||
### 5.1 `0.2.2` — format natif `.kspwallet`
|
||||
@@ -581,31 +688,27 @@ Il est volontairement prématuré de figer maintenant chaque numéro jusqu'aux D
|
||||
| Backfill | bot3 pipelines/jobs historiques | refondre | `ksp-job-api` + job concret | `0.3.3` |
|
||||
| Market Desk | absent comme app KSP dédiée | ajouter | app spécialisée | après DEX prioritaires |
|
||||
|
||||
## 17. Prévision souple des prereleases restantes de `0.2.0`
|
||||
## 17. Clôture de `0.2.0`
|
||||
|
||||
`pre.001` a ouvert la méthode et la cartographie.
|
||||
|
||||
`pre.002` fixe la direction fonctionnelle principale de `0.2.x`, la stratégie RAW/CORE/DECODE/SPECIALIZED, la progression verticale Program, le dimensionnement de session et prépare le prompt `0.2.1`.
|
||||
`pre.002` a fixé la direction fonctionnelle principale de `0.2.x`, la stratégie RAW/CORE/DECODE/SPECIALIZED, la progression verticale Program, le dimensionnement de session et le premier prompt `0.2.1`.
|
||||
|
||||
La suite de `0.2.0` doit rester courte :
|
||||
`pre.003` est la **dernière prerelease planifiée de `0.2.0`**. Elle réalise l'audit de cohérence final, corrige les règles résiduelles supersédées, complète les fiches de release demandées par le prompt d'ouverture, préserve les TODO bot3 utiles et finalise le prompt `0.2.1`.
|
||||
|
||||
### `pre.003` candidate — audit de cohérence finale
|
||||
Aucune `pre.004` n'est prévue. Elle ne serait créée que si la validation de `pre.003` révélait un nouveau défaut ou une omission substantielle qui ne peut pas être honnêtement corrigée dans `rel.001`.
|
||||
|
||||
- relire le découpage complet `0.2.1 -> 0.3.x` ;
|
||||
- vérifier qu'aucune capacité bot3 pertinente au transport/wallet/interface/program n'est perdue ;
|
||||
- vérifier les dépendances et hors-périmètre ;
|
||||
- corriger les incohérences documentaires restantes ;
|
||||
- confirmer que `0.2.1` est suffisamment bornée.
|
||||
Après validation de `pre.003`, `0.2.0-rel.001` doit rester une publication de cadrage :
|
||||
|
||||
### dernière prerelease candidate
|
||||
- passer `workspace.package.version` à `0.2.0` ;
|
||||
- marquer `0.2.0` stable dans ROADMAP/indices/plans ;
|
||||
- ajouter l'entrée stable `0.2.0` au `CHANGELOG.md` ;
|
||||
- créer `deltas/0.2.0/rel.001.md` ;
|
||||
- exécuter les validations globales de clôture disponibles ;
|
||||
- commit `v0.2.0-rel.001`, puis tag stable Git `v0.2.0` ;
|
||||
- ne modifier le prompt `0.2.1` que si une validation de clôture révèle un écart réel.
|
||||
|
||||
- validations documentaires finales ;
|
||||
- nettoyage/archivage ;
|
||||
- mise à jour finale du changelog si prévue par le workflow ;
|
||||
- finalisation du prompt `0.2.1` ;
|
||||
- préparation de `0.2.0-rel.001`.
|
||||
|
||||
Le nombre exact reste souple : ne pas créer artificiellement une prerelease vide si `pre.003` suffit pour clôturer.
|
||||
La matrice de clôture durable est `docs/validation/002-V0_2_0_SERIES_PLANNING.md`.
|
||||
|
||||
## 18. Première release fonctionnelle décidée : `0.2.1`
|
||||
|
||||
@@ -617,10 +720,10 @@ La première release fonctionnelle de la série est désormais :
|
||||
|
||||
Sa mission est de fournir la première frontière réseau Solana KSP réellement exploitable par Wallet, applications futures, acquisition RAW et execution technique ultérieure.
|
||||
|
||||
Le prompt préparatoire est :
|
||||
Le prompt finalisé est :
|
||||
|
||||
```text
|
||||
prompts/006-V0_2_1_START_PROMPT.md
|
||||
```
|
||||
|
||||
Il reste un brouillon vivant jusqu'à la publication stable de `0.2.0`, puis devient le prompt de reprise de `0.2.1`.
|
||||
Son contenu est finalisé par `0.2.0-pre.003`. Il devient le prompt de reprise applicable dès publication/tag stable de `v0.2.0`.
|
||||
|
||||
Reference in New Issue
Block a user