@@ -15,7 +15,7 @@ Un plan décrit le périmètre, les décisions déjà acquises, les questions ou
- [`004-V0_1_2_LOGGING_FOUNDATION_PLAN.md`](004-V0_1_2_LOGGING_FOUNDATION_PLAN.md) — plan historique clôturé de la release stable `0.1.2`, établi par `0.1.2-pre.001` puis consolidé jusqu'à `0.1.2-rel.001`.
- [`005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](005-V0_1_3_CONFIG_FOUNDATION_PLAN.md) — plan historique clôturé de la release stable `0.1.3 — Configuration foundation`, établi par `0.1.3-pre.001`, exécuté jusqu'à `pre.015` puis publié par `0.1.3-rel.001`.
- [`006-V0_1_4_CONFIG_DESKTOP_PLAN.md`](006-V0_1_4_CONFIG_DESKTOP_PLAN.md) — plan historique clôturé de la release stable `0.1.4 — ksp-app-config-desk`, établi par `0.1.4-pre.001` puis consolidé jusqu'à `0.1.4-rel.001`.
- [`007-V0_2_0_SERIES_PLANNING.md`](007-V0_2_0_SERIES_PLANNING.md) — plan actif de `0.2.0`, ouvert par `pre.001` puis consolidé par `pre.002` avec l'ordre `0.2.1+`, la stratégie RAW/CORE/DECODE/SPECIALIZED, les vertical slices Program et le prompt préparatoire`0.2.1`.
- [`007-V0_2_0_SERIES_PLANNING.md`](007-V0_2_0_SERIES_PLANNING.md) — plan actif de `0.2.0`, ouvert par `pre.001`, consolidé par `pre.002` puis finalisé/audité par `pre.003` avec l'ordre `0.2.1+`, la stratégie RAW/CORE/DECODE/SPECIALIZED, les vertical slices Program, les fiches de release et le prompt finalisé`0.2.1`.
Le `pre.001` de chaque release fonctionnelle peut introduire son propre plan détaillé lorsque la release s'ouvre.
# Série `0.2.x` — accès Solana, Wallet et contrats initiaux
`0.2.0` reste la release de cadrage. `0.2.0-pre.002` fixe maintenant le début de la séquence fonctionnelle suivante :
`0.2.0` reste la release de cadrage. `0.2.0-pre.002` a fixé le début de la séquence fonctionnelle suivante et `0.2.0-pre.003` en réalise l'audit final de cohérence avant publication stable :
```text
0.2.1 on-chain transport HTTP foundation
@@ -546,10 +546,10 @@ Les releases `0.1.1` à `0.1.4` sont stables et leurs plans/prompts restent hist
prompts/005-V0_2_0_START_PROMPT.md
```
`0.2.0-pre.001` a construit la première cartographie. `0.2.0-pre.002` fixe la trajectoire ci-dessus et prépare :
`0.2.0-pre.001` a construit la première cartographie. `0.2.0-pre.002` a fixé la trajectoire ci-dessus. `0.2.0-pre.003` corrige les décisions résiduelles supersédées, complète les fiches de release et finalise :
```text
prompts/006-V0_2_1_START_PROMPT.md
```
Le prompt `0.2.1`reste un brouillon vivant jusqu'à la publication stable de `v0.2.0`.
Le prompt `0.2.1` est finalisé côté contenu par `0.2.0-pre.003`; il ne devient applicable qu'après publication stable de `v0.2.0`.
Cette valeur est utilisée par `build.frontendDist` dans `tauri.conf.json`. `vite.config.ts` utilise la même destination comme `build.outDir` depuis son introduction en `pre.005`. Elle remplace le `../dist`/`../../dist` historique du gabarit bot3.
# 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é.
- **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.
- **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.
- **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.
- **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.
- **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.
- **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
| 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
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
