685 lines
50 KiB
Markdown
685 lines
50 KiB
Markdown
<!-- file: docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md -->
|
||
<!-- version: 102 -->
|
||
|
||
# Séquence des releases fonctionnelles KSP
|
||
|
||
## Objet
|
||
|
||
Ce document formalise la sortie principale de `0.0.3-pre.009`.
|
||
|
||
Il transforme les séries fonctionnelles du roadmap en une première séquence de développement concrète sans prétendre connaître trop tôt tous les numéros des séries futures.
|
||
|
||
Principes :
|
||
|
||
- une série `X.Y.x` est une famille fonctionnelle ;
|
||
- une release concrète `X.Y.Z` est une unité de travail/session dimensionnée ;
|
||
- chaque release concrète possède ses propres prereleases ;
|
||
- une release trop grosse est scindée au lieu d'être forcée dans une session ;
|
||
- une session de chat peut enchaîner plusieurs releases si chacune est entièrement clôturée avant l'ouverture de la suivante et si le sizing de la suivante reste raisonnablement positif ; cette possibilité ne fusionne ni les numéros, ni les deltas, ni les validations ;
|
||
- les numéros futurs sont confirmés lorsque leur série approche et que les dépendances réelles sont connues.
|
||
|
||
## Première série fonctionnelle : `0.1.x`
|
||
|
||
La série `0.1.x` construit les fondations N1 dans l'ordre de dépendances réel.
|
||
|
||
Séquence par défaut :
|
||
|
||
```text
|
||
0.1.1 ksp-core-lib
|
||
|
|
||
v
|
||
0.1.2 ksp-logging-lib
|
||
|
|
||
v
|
||
0.1.3 ksp-config-lib
|
||
|
|
||
v
|
||
0.1.4 ksp-app-config-desk
|
||
```
|
||
|
||
`0.1.1`, `0.1.2`, `0.1.3`, `0.1.4` et `0.2.0` à `0.2.9` sont désormais des releases stables.
|
||
|
||
`0.1.4 — ksp-app-config-desk` établit le modèle de référence des futures applications Tauri KSP sans déplacer la logique Config dans l'application. Sa matrice finale a été validée avant `rel.001`, avec le build Tauri exécuté en dernière opération.
|
||
|
||
### `0.1.1` — Core foundation
|
||
|
||
#### Mission
|
||
|
||
Stabiliser `ksp-core-lib` comme fondation N1 minimale et durable.
|
||
|
||
Le Core possède uniquement les contrats réellement transversaux nécessaires aux couches supérieures.
|
||
|
||
#### Surface stabilisée
|
||
|
||
`0.1.1` stabilise :
|
||
|
||
- `ksp_core_lib::ErrorCode`, `ErrorContext`, `Error` et `Result<T>` comme contrat d'erreur ouvert aux domaines supérieurs ;
|
||
- `ksp_core_lib::Pubkey` comme primitive Solana réexportée par Core ;
|
||
- 18 Program IDs fondamentaux possédés par KSP avec paires `PRGID_*` / `PRGIDPK_*` ;
|
||
- `declare_program_id!` pour construire la représentation texte et `Pubkey` depuis une déclaration canonique unique ;
|
||
- `ProgramIdEntry`, `ProgramIdFilter`, `ProgramIdKind` et le registre enumerable/recherchable ;
|
||
- des vues par domaine/famille/protocole et `native_program_ids()` sans registres secondaires ;
|
||
- une taxonomie extensible séparant notamment `subfamily` et `program_version` ;
|
||
- les réexports crate-root, rustdocs et tests publics correspondants.
|
||
|
||
#### Dépendances
|
||
|
||
Core ne dépend pas de `ksp-logging-lib`, Config, Wallet, Store, Transport, Program ou Materializer.
|
||
|
||
La seule dépendance externe directe de `ksp-core-lib` à la clôture est `solana-pubkey`, déclarée au workspace avec la génération `^4.3`, `default-features = false`, puis héritée par la crate avec `.workspace = true`. Aucune feature optionnelle supplémentaire n'est activée dans `0.1.1`.
|
||
|
||
#### Hors scope
|
||
|
||
- logging ;
|
||
- configuration ;
|
||
- Tauri ;
|
||
- wallet/signing ;
|
||
- codecs wire ;
|
||
- decoders/Program registry ;
|
||
- transaction execution ;
|
||
- transport ;
|
||
- Store ;
|
||
- Materializer ;
|
||
- workers/jobs ;
|
||
- scenarios.
|
||
|
||
#### Lifecycle de la release
|
||
|
||
Trajectoire réellement suivie :
|
||
|
||
```text
|
||
pre.001 brainstorming + audit + plan détaillé
|
||
pre.001-fix.001/.002 corrections de cadrage Program IDs/taxonomie
|
||
pre.002 Error/Result + fondation API
|
||
pre.002-fix.001 corrections de tests/lints
|
||
pre.003 Pubkey + Program IDs
|
||
pre.003-fix.001 politique Cargo workspace + corrections Clippy
|
||
pre.004 intégration Core + audits
|
||
pre.005 validation finale/docs/cleanup/prompt 0.1.2
|
||
rel.001 publication stable validée de 0.1.1
|
||
```
|
||
|
||
### `0.1.2` — Logging foundation
|
||
|
||
#### Mission
|
||
|
||
Faire de `ksp-logging-lib` la façade KSP unique de logging/tracing pour les composants runtime.
|
||
|
||
#### Surface stabilisée
|
||
|
||
`0.1.2` stabilise :
|
||
|
||
- les macros KSP `error!`, `warn!`, `info!`, `debug!`, `trace!` avec `target:` KSP explicite et callsite consommateur préservé ;
|
||
- les spans KSP synchrones et l'instrumentation de futures async sans exposer `tracing` aux consumers ;
|
||
- `LoggingSettings`, niveaux, overrides par préfixe de target et lifecycle de spans ;
|
||
- `initialize()` unique et `reinitialize()` à chaud avec `LoggingGuard` ;
|
||
- le takeover des targets : targets externes silencieux par défaut, targets `ksp-*` gouvernés par la politique KSP ;
|
||
- console et fichier non bloquants, rotation, ownership des `WorkerGuard` et compteurs cumulés de lignes abandonnées ;
|
||
- stripping ANSI avant persistence fichier ;
|
||
- reconfiguration transactionnelle conservant l'ancien runtime en cas d'échec ;
|
||
- tests de saturation, concurrence/reload, lifecycle spans et instrumentation Tokio réelle ;
|
||
- audit d'ownership empêchant les autres crates workspace de dépendre directement de la stack `tracing*`.
|
||
|
||
#### Dépendances runtime
|
||
|
||
```text
|
||
ksp-logging-lib
|
||
-> ksp-core-lib
|
||
-> tracing
|
||
-> tracing-appender
|
||
-> tracing-subscriber
|
||
```
|
||
|
||
Tokio est uniquement une dev-dependency de `ksp-logging-lib` pour les tests async réels et n'appartient pas à son graphe normal.
|
||
|
||
`ksp-logging-lib` ne dépend pas de `ksp-config-lib`. Config pourra convertir ses documents résolus en `LoggingSettings` puis utiliser le lifecycle public de Logging.
|
||
|
||
#### Lifecycle de la release
|
||
|
||
Trajectoire réellement suivie :
|
||
|
||
```text
|
||
pre.001 brainstorming + audit + plan détaillé
|
||
pre.001-fix.001 corrections de cadrage takeover/reload/spans
|
||
pre.002 crate + settings + façade événements/spans
|
||
pre.002-fix.001 corrections tests/lints
|
||
pre.003 subscriber + takeover + console + reload
|
||
pre.003-fix.001 correction du montage reload/filter
|
||
pre.004 console/fichier non bloquants + guards + ANSI
|
||
pre.004-fix.001..004 corrections lifecycle, ANSI, takeover et Clippy
|
||
pre.005 robustesse, concurrence, saturation, audits
|
||
pre.005-fix.001 suppression du bruit console du stress test
|
||
pre.006 validation finale, Tokio dev-only, docs, prompt 0.1.3
|
||
pre.006-fix.001 correction documentaire du prompt Config
|
||
rel.001 publication stable validée de 0.1.2
|
||
```
|
||
|
||
### `0.1.3` — Configuration foundation
|
||
|
||
#### Dépendances stabilisées
|
||
|
||
```text
|
||
ksp-config-lib
|
||
-> ksp-core-lib
|
||
-> ksp-logging-lib
|
||
```
|
||
|
||
#### Mission
|
||
|
||
Introduire la configuration générale KSP.
|
||
|
||
Le `0.1.3-pre.001`, corrigé par `pre.001-fix.001`, `pre.001-fix.002` puis `pre.001-fix.003`, a revalidé ce périmètre et décidé qu'il tient dans une seule release à condition de limiter le premier cycle au socle générique, au document Logging, à la composition, à l'environnement KSP/KSPB, aux surfaces d'accès et à la persistence autorisée. Le plan normatif détaillé est `docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`.
|
||
|
||
Périmètre retenu :
|
||
|
||
- registre logique `file_id -> filename` des fichiers Config/schemas connus, avec mappings par défaut surchargeables au bootstrap ;
|
||
- bootstrap non récursif `--cfgpath` / `--schemapath` avec défauts codés en dur `config` / `config/schemas` ;
|
||
- override répétable des filenames par `--filemap=<file_id>=<filename>` ;
|
||
- documents spécialisés ;
|
||
- profils ;
|
||
- `default_profile` autonome ;
|
||
- valeurs globales hors profils lorsqu'elles ne varient pas ;
|
||
- résolution ;
|
||
- validation ;
|
||
- modification/sauvegarde ;
|
||
- variables d'environnement `KSP_*` / `KSPB_*`, résolues exclusivement par Config ;
|
||
- priorité process env > `.env` > fallback `${NAME:-fallback}` ;
|
||
- propagation de la sensibilité et représentation sûre/redacted des valeurs dérivées de `*_SECRET_*` ;
|
||
- secret/public/debug exposure policy ;
|
||
- premier document spécialisé concret `config/std.logging.json`, identifié logiquement par `cfg.std.logging` et validé par `schema.std.logging` ;
|
||
- vrais fichiers runtime sous `config/`, schemas sous `config/schemas/` et exemples sous `config/examples/` ;
|
||
- documents unitaires spécialisés + fichiers composites par application/exécutable, avec références inter-document par `file_id` et non par filename ;
|
||
- ownership exclusif de `ksp-config-lib` sur lecture/résolution/validation/mutation des fichiers Config et variables d'environnement ;
|
||
- accès explicite aux secrets pour les surfaces de management autorisées ;
|
||
- modèle Logging non régressif : console configurable et plusieurs sinks fichier/routings ; les capacités manquantes de `ksp-logging-lib 0.1.2` sont complétées dans Logging sans dépendance inverse vers Config.
|
||
|
||
#### Décision de scission
|
||
|
||
Le `pre.001` ne scinde pas Config : `0.1.3` reste une release unique et `0.1.4` reste réservée à `ksp-app-config-desk`.
|
||
|
||
Cette décision repose sur l'absence volontaire de documents Transport/Wallet/Store/Execution et de watcher générique dans le premier cycle. Si une tranche ultérieure révèle une contrainte technique majeure réellement non bornable, la séquence peut encore être corrigée par un delta explicite plutôt que de comprimer artificiellement le périmètre.
|
||
|
||
Prévision souple regranularisée par `pre.001-fix.003`, puis scindée à nouveau pendant `pre.005` afin de traiter `domain` comme un champ structuré distinct :
|
||
|
||
```text
|
||
pre.002 crate Config + bootstrap cfgpath/schemapath
|
||
pre.003 registre file_id -> filename + --filemap
|
||
pre.004 Logging : contrats/settings multi-output
|
||
pre.005 Logging : runtime multi-sink + level/target/formats
|
||
pre.006 Logging : routing structuré domain
|
||
pre.007 JSON/JSON Schema + std.logging.json
|
||
pre.008 globals + profils + default_profile
|
||
pre.009 compositions génériques par file_id
|
||
pre.010 .env + process env + resolver ${...}
|
||
pre.011 sensibilité + real/safe/provenance
|
||
pre.012 adapter Config -> Logging
|
||
pre.013 management + persistence JSON/.env
|
||
pre.014 ownership audits + robustesse
|
||
pre.015 clôture
|
||
```
|
||
|
||
Cette prévision n'est pas un plafond : chaque prerelease doit rester une petite tranche, avec scission explicite si l'objectif dépasse environ 15–20 minutes de travail effectif.
|
||
|
||
`pre.006` a fermé le routing Logging structuré `domain`; `pre.007` a livré le moteur JSON/JSON Schema et `std.logging.json`; `pre.008` a ajouté la résolution générique globals/profils/`default_profile`; `pre.009` les compositions génériques par `file_id`; `pre.010` le snapshot process + `.env`, `.env.example` et le resolver `${...}`; `pre.011` la sensibilité, les valeurs réelle/sûre, la redaction et la provenance enrichie; `pre.012` l'adapter Config -> Logging et la validation effective des chemins; `pre.013` management + persistence JSON/.env; `pre.014` les audits exécutables d'ownership et la couverture automatique de `.env.example`; `pre.015` la documentation durable et le prompt `0.1.4`, complétés par deux fixes documentaires sur les validations et le modèle Tauri. `rel.001` publie cette surface sous `0.1.3` stable.
|
||
|
||
Trajectoire réellement suivie :
|
||
|
||
```text
|
||
pre.001 brainstorming + audit + plan détaillé
|
||
pre.001-fix.001..003 corrections de cadrage, file_id/bootstrap et granularité
|
||
pre.002 crate Config + bootstrap cfgpath/schemapath
|
||
pre.002-fix.001 correction de la première tranche Config
|
||
pre.003 registre file_id + --filemap
|
||
pre.004 Logging contracts/settings multi-output
|
||
pre.005 Logging runtime multi-sink + routing level/target/formats
|
||
pre.005-fix.001 correction du test JSON runtime
|
||
pre.006 Logging routing structuré domain
|
||
pre.007 moteur JSON/JSON Schema + std.logging.json
|
||
pre.008 globals + profils + default_profile
|
||
pre.009 compositions génériques par file_id
|
||
pre.009-fix.001 correction Clippy du test composite
|
||
pre.010 process env + .env + placeholders + .env.example
|
||
pre.010-fix.001 correction des racines de fixtures de test
|
||
pre.011 sensibilité + real/safe/provenance
|
||
pre.011-fix.001 correction Clippy du test de provenance
|
||
pre.012 adapter Config -> Logging
|
||
pre.013 management + persistence JSON/.env
|
||
pre.013-fix.001 correction de syntaxe du warning persistence
|
||
pre.014 ownership audits + robustesse
|
||
pre.015 clôture/docs/prompt 0.1.4
|
||
pre.015-fix.001 règles validation/docs + modèle Tauri/PRESENTATION
|
||
pre.015-fix.002 tracing Tauri + critères fonctionnels de clôture 0.1.4
|
||
rel.001 publication stable validée de 0.1.3
|
||
```
|
||
|
||
### `0.1.4` — Config desktop par défaut
|
||
|
||
`0.1.4-pre.001` ouvre désormais cette release par l'audit et le plan détaillé :
|
||
|
||
```text
|
||
docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md
|
||
```
|
||
|
||
Mission :
|
||
|
||
```text
|
||
ksp-app-config-desk
|
||
-> ksp-config-lib
|
||
-> ksp-logging-lib
|
||
```
|
||
|
||
L'application doit valider réellement :
|
||
|
||
- inventaire des documents Config enregistrés ;
|
||
- diagnostics JSON/schema/sémantiques/effective ;
|
||
- inspection puis réparation validée d'un source invalide ;
|
||
- profils/default profile et provenance ;
|
||
- environnement desired/effective/shadow ;
|
||
- mutation `.env` exclusivement via Config ;
|
||
- reveal Secret explicitement privilégié et séparé ;
|
||
- édition typée de plusieurs profils Logging ;
|
||
- profil mono-fichier ;
|
||
- profil multi-fichiers avec console ;
|
||
- sauvegarde séparée de l'activation runtime ;
|
||
- hot reload Logging observable sans redémarrage ;
|
||
- conservation du runtime précédent lorsqu'un reload échoue ;
|
||
- conventions Tauri/DTO/TS-RS servant de référence aux futures apps KSP.
|
||
|
||
L'audit `pre.001` révèle deux extensions bornées à apporter d'abord à `ksp-config-lib` : une vue publique des descripteurs du registre et une frontière de sauvegarde d'un source candidat qui reste entièrement parsé, validé et persisté atomiquement par Config. L'application ne doit pas contourner ces manques par une liste parallèle de `file_id` ou par du filesystem direct.
|
||
|
||
Le shell retenu est une fenêtre principale de management plus splash, avec Vanilla TypeScript/Vite/SCSS/Bootstrap/Font Awesome. Aucune vue de présentation n'est retenue en `0.1.4`, donc aucun `PRESENTATION.md` ni `markdown-it` n'est prévu.
|
||
|
||
La logique Config reste dans `ksp-config-lib` et le subscriber/runtime `tracing` reste dans `ksp-logging-lib`.
|
||
|
||
`0.1.4-rel.001` publie cette surface sous `0.1.4` stable après validation complète de `pre.019` et de son fix documentaire.
|
||
|
||
## Règle Git à partir de `0.1.x`
|
||
|
||
À partir de la première release fonctionnelle, **chaque delta est commité**.
|
||
|
||
Exemples :
|
||
|
||
```text
|
||
0.1.1-pre.001
|
||
0.1.1-pre.002
|
||
0.1.1-pre.002-fix.001
|
||
...
|
||
0.1.1
|
||
```
|
||
|
||
Une étape intermédiaire erronée n'est pas supprimée de l'historique pour reconstruire artificiellement un développement parfait. Elle est corrigée par un delta/commit suivant.
|
||
|
||
Seul le commit de release stable reçoit le tag :
|
||
|
||
```text
|
||
v0.1.1
|
||
```
|
||
|
||
## Lifecycle standard d'une release fonctionnelle
|
||
|
||
### Première prerelease
|
||
|
||
Par défaut :
|
||
|
||
- relire la base validée ;
|
||
- brainstorming ;
|
||
- audit des besoins ;
|
||
- vérification des dépendances externes actuelles depuis les sources officielles lorsque concernées ;
|
||
- plan détaillé ;
|
||
- inventaire des fichiers/API touchés ;
|
||
- dimensionnement des prereleases ;
|
||
- décision explicite sur les hors-scope.
|
||
|
||
La première prerelease ne doit pas se transformer automatiquement en une grosse phase d'implémentation.
|
||
|
||
### Prereleases intermédiaires
|
||
|
||
Chaque prerelease porte un objectif borné et cohérent.
|
||
|
||
Une tranche de travail de planification/développement manifestement trop grosse est scindée. La cible de dimensionnement KSP est d'environ 15–20 minutes de travail effectif par prerelease ; ce budget est un garde-fou de granularité, pas une raison pour comprimer le périmètre.
|
||
|
||
### Dernière prerelease
|
||
|
||
Par défaut :
|
||
|
||
- validations complètes ;
|
||
- tests de conformité/audits ;
|
||
- documentation finale ;
|
||
- nettoyage/archivage ;
|
||
- changelog ;
|
||
- prompt de la release suivante ;
|
||
- vérification de cohérence des versions.
|
||
|
||
## Série `0.2.x` — accès Solana, Wallet et contrats initiaux
|
||
|
||
`0.2.0` est publiée stable par `0.2.0-rel.001`. `pre.002` a fixé le début de la séquence fonctionnelle suivante et `pre.003` en a réalisé l'audit final de cohérence :
|
||
|
||
```text
|
||
0.2.1 HTTP transport foundation + 4 méthodes canari
|
||
0.2.2 HTTP Accounts + Tokens + Cluster
|
||
0.2.3 HTTP Transactions
|
||
0.2.4 HTTP Blocks + Economics + compliance complète
|
||
0.2.5 wallet foundation (.kspwallet)
|
||
0.2.6 Wallet Desk
|
||
0.2.7 standard Solana WebSocket
|
||
0.2.8 Helius LaserStream WebSocket
|
||
0.2.9 Yellowstone gRPC engine + Solana standard + PublicNode
|
||
0.2.10 OrbitFlare Yellowstone gRPC
|
||
0.2.11 off-chain price transport
|
||
0.2.12 price visualization desk + intégration prix dans Wallet Desk
|
||
0.2.13 interface/wire foundation
|
||
0.2.14 program-api foundation
|
||
```
|
||
|
||
`0.2.1-pre.001` a appliqué le gate de sizing et refusé le scope HTTP monolithique initial : l'inventaire du 2026-08-17 contient 52 méthodes courantes et 14 méthodes Deprecated historiques. Ce premier delta avait réparti la couverture typée sur `0.2.1`–`0.2.6`. `0.2.1-pre.001-fix.001` recalibre ensuite les 48 méthodes restantes sur trois releases complémentaires `0.2.2`–`0.2.4`, soit trois sessions nominales au maximum si chaque release utilise sa session complète. Si une release se clôt plus vite que prévu, la même session peut enchaîner la suivante après clôture complète de la précédente et nouveau gate de sizing positif. Un Wallet Desk utile doit pouvoir lire le solde du wallet : `getBalance` fait donc partie des quatre canaris de la foundation `0.2.1`, avant Wallet. Les transports live arrivent ensuite ; Interface/Program restent préparés avant les couches de données décodées.
|
||
|
||
### `0.2.1` — HTTP transport foundation réduite
|
||
|
||
Mission : créer `ksp-onchain-transport-lib` avec la foundation HTTP JSON-RPC indépendante de Config/Store/Program, le registry documentaire exhaustif, la résilience/pool et quatre méthodes typed canari.
|
||
|
||
Inclure : settings publics ; endpoint/provider/cluster ; pool logique ; rôles/capabilities/request kinds ouverts ; priorités/limites/concurrence ; timeout/retry/backoff ; JSON-RPC ; metadata centrale de statut méthode + forme de requête + runtime ; warning centralisé lorsqu'un contrat supported est deprecated/unstable ; document Config standard + adapter Config -> Transport ; `getBalance`, `getGenesisHash`, `getHealth`, `getVersion`.
|
||
|
||
Le plan détaillé clôturé est `docs/plans/008-V0_2_1_ONCHAIN_HTTP_PLAN.md`. `0.2.1-rel.001` publie la foundation après validation des canaries de complétude, du smoke Devnet opt-in Config -> Transport, des README/USAGE et des graphes Cargo. Le smoke cross-crates hébergé dans Config est transitoire et devra migrer vers une future surface d’intégration/orchestration ; aucun futur smoke `Config + autre crate` ne doit prendre Config comme destination générale. Un appel raw/générique ne compte pas comme couverture typée des méthodes reportées.
|
||
|
||
### `0.2.2` à `0.2.4` — complétude HTTP Solana
|
||
|
||
- `0.2.2` : 5 Accounts restants + 5 Tokens + 12 Cluster restants = 22 méthodes ;
|
||
- `0.2.3` : 11 Transactions, y compris write/submission technique et no-resend ambigu ;
|
||
- `0.2.4` : 10 Blocks + 5 Economics = 15 méthodes, puis compliance finale des 52 méthodes courantes et 14 historiques Deprecated.
|
||
|
||
Ces trois releases constituent le découpage nominal, pas une obligation de trois chats distincts. Une session qui clôture complètement une release plus vite que prévu peut ouvrir immédiatement la suivante si son sizing permet encore raisonnablement de la clôturer dans cette même session. Les releases restent séparées : version, prereleases, delta, validations et clôture stable propres à chacune.
|
||
|
||
Chaque `pre.001` réaudite la documentation officielle actuelle. Les méthodes Deprecated réellement retirées restent tracées comme historiques/runtime removed au lieu d'être simulées.
|
||
|
||
`0.2.2-pre.001` a confirmé la partition de 22 méthodes et son fix documentaire a recoupé les formes wire avec Agave v4.2.1. Les tranches `pre.002`–`pre.006` ont livré les DTOs puis les 5 Accounts, 5 Tokens et 12 Cluster. `pre.007`, puis `pre.007-fix.001` et `pre.007-fix.002`, ont fermé les canaries exactes 22/22, le smoke Devnet Transport pur, README/USAGE, la matrice de validation `004` et le prompt `0.2.3`. `0.2.2-rel.001` publie cette surface stable après validation du workspace et des deux smokes Devnet. Le smoke cross-crates Config -> Transport de `0.2.1` reste séparé et transitoire.
|
||
|
||
`0.2.3-pre.001` réaudite le 2026-08-18 la catégorie Transactions contre la documentation Solana actuelle et Agave v4.2.1 : les 11 méthodes prévues restent exactes, la classification `8 Read / RetrySafe`, `2 WriteSubmission / NeverAfterDispatch` et `1 Simulation / RetrySafe` reste correcte, et le gate de sizing est positif. `pre.002`–`pre.007` livrent ensuite les primitives wire puis les 11 wrappers, `pre.008` réaudite rétroactivement `KSP-TRANSPORT-007` sur les 37 wrappers HTTP typés sans remédiation fonctionnelle, et `pre.009` prépare la candidate finale avec documentation, smoke Transport read-only étendu et prompt `0.2.4`. `0.2.3-rel.001` publie cette surface stable après validation du workspace, des graphes Cargo Transport/Config et des deux smokes Devnet. Aucun `base64`, `bs58`, `wincode` ni client RPC Solana supplémentaire n'est ajouté : les payloads sérialisés restent opaques dans Transport tant qu'un besoin de décodage local n'est pas démontré. Le plan détaillé clôturé est `docs/plans/010-V0_2_3_HTTP_TRANSACTIONS_PLAN.md`.
|
||
|
||
`0.2.4-pre.001` réaudite le même jour l'inventaire HTTP officiel et la baseline runtime actuelle : les 15 méthodes réservées restent exactement 10 Blocks + 5 Economics, la navigation Deprecated reste à 14 historiques et Agave stable `v4.2.1` confirme les overloads/limites/extensions sensibles (`getBlock` legacy, `getBlocks`, plafond 500_000, performance samples 720, `commissionBps`). Le gate de sizing est positif sans split de release. `pre.002`–`pre.008` livrent ensuite les DTOs/wires et les 15 wrappers ; `pre.008-fix.001` corrige uniquement la conformité Clippy. `pre.009` réaudite l'index officiel et les SIMDs HTTP sensibles, confirme l'égalité exacte des ensembles 52 current + 14 Deprecated avec le registre, ajoute les canaries de wrapper/compliance globales, étend le smoke Transport aux familles Blocks/Economics et synchronise la documentation. `pre.009-fix.001` finalise ensuite le prompt Wallet sans changement Cargo. `0.2.4-rel.001` publie la surface stable après validation du workspace et des deux smokes Devnet. Le plan détaillé clôturé est `docs/plans/011-V0_2_4_HTTP_BLOCKS_ECONOMICS_PLAN.md`.
|
||
|
||
### `0.2.5` — Wallet foundation
|
||
|
||
Mission : créer `ksp-wallet-lib` et le format natif interopérable `.kspwallet`, indépendants de Config/Transport/Tauri/ExecutionPolicy.
|
||
|
||
`0.2.5-pre.001` ouvre la release par un gate documentaire : l'ancien JSON temporaire et `.kswallet` ne sont pas migrés, mais leurs invariants utiles (keypair strict, signature sans getter secret, zeroization, `spawn_blocking`, no-clobber/atomic persistence, adapters CLI JSON/Base58) servent de canaris conceptuels. Le nouveau format cache Pubkey/alias/notes lorsqu'il est verrouillé et sépare VIEW/OWNER par content keys et key slots indépendants.
|
||
|
||
Le design retient un **metadata read-only VIEW de niveau B** : une clé Ed25519 d'administration du format, distincte de la keypair Solana, authentifie l'état OWNER-controlled, notamment metadata, identité Solana, secret, slot OWNER et descripteur stable du slot VIEW. Les paramètres Argon2id VIEW autorisés, le salt et le nonce/ciphertext de wrapping du slot VIEW restent volontairement auto-rotatables par VIEW afin qu'il puisse changer **son seul password VIEW** sans OWNER ; ils restent liés au même wallet/slot par AEAD/AAD et ne donnent aucun droit de modifier alias/notes, de signer, d'exporter le secret, de changer OWNER ou de désactiver/recréer VIEW. OWNER peut changer son propre password ainsi que le password VIEW et reste seul capable des mutations administratives. Les ACL/permissions OS sont hors du modèle Wallet ; remplacer intégralement le fichier par un autre `.kspwallet` valide revient seulement à substituer un autre wallet et ne révèle ni ne rend utilisable l'ancienne keypair.
|
||
|
||
Le format V1 est cadré comme JSON UTF-8 strict avec binary Base64url sans padding, `format_version`, paramètres Argon2id sérialisés, key slots génériques, owner-control/metadata/secret séparés et XChaCha20-Poly1305. **V1 est entièrement autonome** : aucun salt externe, pepper, OTP, secret KSP, service distant ou ancre externe n'est requis. Les paramètres Argon2 de création ne sont gelés qu'après benchmark. VIEW peut rewrapper le même accès metadata sous un nouveau password VIEW, ce qui remplace son credential courant sans constituer une révocation cryptographique forte d'un ancien détenteur ayant déjà extrait le matériau VIEW. OWNER peut également changer le password VIEW sans connaître l'ancien, changer son propre password, ou rekey les metadata pour une révocation VIEW forte, sans jamais changer la keypair Solana. La keypair V1 reste immuable après création/import. Tout import crée un nouveau `.kspwallet` avec sémantique no-clobber ; il ne remplace jamais un `.kspwallet` existant et ne sert jamais à muter sa keypair.
|
||
|
||
La release fournit `docs/formats/KSPWALLET_V1.md` comme spécification séparée et indépendante de Rust, accompagnée de vecteurs publics auto-contenus permettant une réimplémentation dans un autre langage. La trajectoire a été étendue jusqu'à `pre.010` afin de séparer codec, crypto, capabilities, persistence, administration, import/export, security audit et documentation interopérable. Le plan historique clôturé est `docs/plans/012-V0_2_5_WALLET_FOUNDATION_PLAN.md`.
|
||
|
||
`0.2.5-pre.002` matérialise la crate sans ouvrir encore le codec ou la cryptographie du fichier : `WalletView`/`WalletOwner`, `WalletCapability`, projections `LockedWalletInfo`/`WalletInfo`/`WalletNote`, wrappers `ViewPassword`/`OwnerPassword`, codes d’erreur Wallet et target de logging explicite `ksp-wallet-lib`. La crate dépend seulement de Core, Logging et `zeroize`; elle consomme la Pubkey exclusivement via `ksp_core_lib::Pubkey` et ne dépend directement ni de `solana-pubkey`, ni de Config, Transport, ExecutionPolicy, Store ou Tauri. Les primitives Solana keypair/signature ne seront ajoutées que lorsqu’elles seront réellement consommées.
|
||
|
||
`0.2.5-pre.003` ouvre le format sans effectuer encore de cryptographie : `KspWalletEnvelopeV1` parse/serialize le JSON strict borné à 1 MiB, impose Base64url sans padding canonique, exactement un slot OWNER et un slot VIEW optionnel lié par `view_descriptor`, puis produit les octets déterministes du transcript OWNER et des AAD par TLV domain-separated. `docs/formats/KSPWALLET_V1.md` devient l'autorité indépendante du code pour ce wire figé. Les paramètres Argon2 de création, KDF/AEAD effectifs, payloads et vérification Ed25519 restent `pre.004+`.
|
||
|
||
`0.2.5-pre.004` matérialise les primitives cryptographiques in-memory sans encore créer/ouvrir un wallet complet : Argon2id version 19 dérive une KEK de 32 octets depuis le password et les paramètres sérialisés, XChaCha20-Poly1305 wrappe/déwrappe les content keys avec les AAD figés, `getrandom` fournit le CSPRNG OS et les buffers secrets possédés sont zeroized. Un vecteur public test-only fixe l'interop KDF+AEAD. Le profil Argon2 de création n'est pas inventé : trois candidats sont benchmarkables par un test `#[ignore]` et le gate `pre.005` attend le résultat opérateur avant de figer le default.
|
||
|
||
`0.2.5-pre.005` consomme ce benchmark (`64 MiB / 3 / 1 ≈ 1742 ms`, `128 MiB ≈ 3459 ms`, `256 MiB ≈ 6925 ms` sur la machine opérateur) et retient pour les créations KSP V1 `65 536 KiB / 3 / 1` avec salt 32 octets, tout en conservant les paramètres sérialisés comme autorité de lecture de chaque wallet. La tranche fixe les payloads `owner_control` (seed Ed25519 d’administration + `K_metadata` + `K_secret`), metadata strictes et secret Solana 64 octets, ajoute une autorité Ed25519 séparée de la keypair Solana et vérifie sa signature d’état avant tout KDF. Les API in-memory `create_wallet_v1`, `open_wallet_view_v1`, `open_wallet_owner_v1` et `inspect_locked_wallet_v1` matérialisent l’indépendance VIEW/OWNER : VIEW ne déchiffre jamais `owner_control`/secret, OWNER ne dépend pas de VIEW et la Pubkey reste un `ksp_core_lib::Pubkey`. Un vecteur `.kspwallet` complet test-only, revérifiable hors Rust, ferme l’interop de cette tranche. La persistence filesystem reste explicitement `pre.006`; signature Solana publique et mutations/rotations restent `pre.007+`.
|
||
|
||
`0.2.5-pre.006` ajoute la persistence native sans Config : `create_wallet_file_v1` reçoit un chemin explicite du caller et publie uniquement en no-clobber via un fichier temporaire créé dans le même répertoire, écrit puis `sync_all` avant `persist_noclobber`; `open_wallet_view_file_v1`, `open_wallet_owner_file_v1` et `inspect_locked_wallet_file_v1` effectuent une lecture bornée à la limite V1 avant de déléguer au parser/crypto acquis. Les opérations filesystem bloquantes sont isolées par `spawn_blocking`. Les tests couvrent destination existante, concurrence avec un seul gagnant, fault injection avant publication, cleanup ordinaire des temporaires et rejet d'un fichier surdimensionné. La synchronisation du répertoire parent est best-effort sur Unix et n'est pas transformée en garantie portable de crash-durability. Les ACL/permissions OS restent hors du modèle Wallet.
|
||
|
||
`0.2.5-pre.007` complète l'administration native capability-bound : OWNER signe des messages Solana sans getter secret, modifie alias/notes, change son password ou celui de VIEW et peut disable/recreate VIEW avec rekey metadata fort ; VIEW ne peut que tourner son propre credential en rewrappant le même `K_metadata`. Les mutations sont staged puis remplacent le fichier uniquement si la destination courante correspond encore à l'enveloppe authentifiée attendue ; un handle stale ou une mauvaise cible reçoit `wallet.state_conflict`. Ce garde-fou ne prétend pas fournir un CAS filesystem portable ni un anti-rollback externe. La keypair reste encapsulée dans Wallet et aucune nouvelle dépendance tierce n'est ajoutée. `pre.008` ajoute ensuite les adapters `solana_cli_json` et `solana_keypair_base58`, l’inspection sûre limitée à Pubkey+format, l’import no-clobber vers un nouveau `.kspwallet` et l’export OWNER en mémoire/fichier. La source d’import reste inchangée, VIEW n’exporte jamais, aucun `bs58` direct n’est ajouté puisque `solana-keypair 3.1.2` possède déjà le codec Base58 complet. `pre.009` ferme ensuite le gate adversarial/security/interoperability/compliance : canaris de tampering et non-oracle, reproduction indépendante des vecteurs, audit des frontières et graphes Cargo. `pre.010` finalise README/USAGE, la spec, les graphes, la matrice de clôture et le prompt `0.2.6`. Les fixes `pre.010-fix.001`–`fix.003` mettent le Dalek direct à `3.0.0`, normalisent le Rust workspace, ajoutent l'audit structurel Python et réconcilient celui-ci avec rustfmt. Le checkpoint final est vert ; `0.2.5-rel.001` publie cette surface sans nouvelle capacité runtime.
|
||
|
||
### `0.2.6` — Wallet Desk
|
||
|
||
Mission : créer `ksp-app-wallet-desk` comme application Tauri mince de composition `Config + Wallet + Transport HTTP`, sans déplacer la cryptographie Wallet, la résolution Config ni le transport Solana dans le frontend. Le plan détaillé clôturé est `docs/plans/013-V0_2_6_WALLET_DESK_PLAN.md`.
|
||
|
||
Trajectoire exécutée :
|
||
|
||
- `pre.001`–`pre.004` : sizing, shell desktop, `std.wallet`, composite Wallet Desk, répertoires Config et inventory locked `.kspwallet` root-scoped ;
|
||
- `pre.005`–`pre.006` : création native, `WalletSession`, unlock VIEW/OWNER manuel et via candidats `KSP_SECRET_WALLET_PASS_*` résolus exclusivement par Config ;
|
||
- `pre.007` : composition du pool HTTP et `getBalance` depuis la Pubkey d'un handle VIEW/OWNER Rust, sans Pubkey ni endpoint fournis par le frontend ;
|
||
- `pre.008` : import Solana CLI JSON/Base58 via picker natif Rust, staging borné zéroïsable et publication no-clobber vers un nouveau `.kspwallet`.
|
||
|
||
Les correctifs de ces tranches restent tracés dans `deltas/0.2.6/` et ne sont pas dupliqués ici.
|
||
|
||
Clôture exécutée :
|
||
|
||
```text
|
||
pre.009 administration OWNER alias/notes + recovery wallet.state_conflict
|
||
pre.010 rotations OWNER/VIEW
|
||
pre.011 disable/recreate VIEW fort
|
||
pre.012 export OWNER fichier CLI JSON/Base58
|
||
pre.013 intégration, compliance, sécurité et smoke
|
||
pre.014 polish du gabarit Bootstrap et du splashscreen
|
||
pre.015 .kspwallet V2 wire binaire + codec canonique
|
||
pre.016 APIs génériques/versionnées + création/ouverture V2
|
||
pre.017 migration V1 -> V2 + persistence/canaris + régression Wallet Desk
|
||
pre.018 documentation finale, validations, prompt 0.2.7 et cargo tauri build en dernière opération
|
||
rel.001 publication stable 0.2.6
|
||
```
|
||
|
||
`pre.017` a matérialisé et validé la migration V1 -> V2 explicite, OWNER-authentifiée et séparée de toute ouverture normale, avec copie no-clobber et remplacement in-place stale-protected. `pre.018` a ensuite fermé la candidate : README/USAGE Wallet Desk, documentation/compliance, runtime packagé commun à Config Desk/Wallet Desk avec resources Config + racine user-writable et prompt `0.2.7`. `pre.018-fix.001` a corrigé le canari d’ownership Config et aligné les signaux Cargo/npm/Tauri ; le gate complet puis le build final Wallet Desk ont été validés, avec production des bundles Linux `.deb`, `.rpm` et `.AppImage`. `pre.018-fix.002`, documentaire uniquement, a renforcé le prompt autonome `0.2.7` sans invalider la preuve technique. `0.2.6-rel.001` publie désormais cette surface stable sans nouvelle capacité runtime.
|
||
|
||
La tranche historique `pre.014` a traité les défauts visuels/templating observés en usage réel, notamment le splashscreen et le layout desktop. Les décisions finales CWD/resources ont été fermées en `pre.018`. `ROADMAP.md` reste synthétique et `CHANGELOG.md` ne contient que les releases stables.
|
||
|
||
### `0.2.7` — WebSocket Solana standard
|
||
|
||
Mission accomplie : couvrir exhaustivement la surface WebSocket Solana standard officielle ciblée, avec sessions physiques explicites, subscriptions typées, lifecycle borné, reconnexion/resubscribe déterministes et observabilité sûre. Le plan historique clôturé est [`014-V0_2_7_ONCHAIN_WEBSOCKET_PLAN.md`](014-V0_2_7_ONCHAIN_WEBSOCKET_PLAN.md) et la matrice finale est [`../validation/010-V0_2_7_ONCHAIN_WEBSOCKET.md`](../validation/010-V0_2_7_ONCHAIN_WEBSOCKET.md).
|
||
|
||
Le gate `0.2.7-pre.001`, audité le 22 août 2026, inventorie exactement 18 opérations WebSocket documentées : 9 subscribe + 9 unsubscribe. `blockSubscribe`, `slotsUpdatesSubscribe` et `voteSubscribe` sont actuellement marquées unstable ; aucune méthode de l'index officiel courant n'est marquée Deprecated.
|
||
|
||
Une URL peut avoir plusieurs sessions physiques explicites ; une session peut avoir plusieurs subscriptions. Un pool/scheduler automatique de sessions reste reporté jusqu'à besoin concret. Les IDs de session/subscription KSP sont locaux et stables ; les IDs serveur restent internes et peuvent être remappés après reconnexion.
|
||
|
||
La candidate atteint `pre.014` après matérialisation des 9 familles standard, compliance 18/18, composition Config V2, reconnect/resubscribe/backpressure bornés, smoke WebSocket Devnet et audit du graphe Cargo. `pre.014-fix.001` renforce uniquement le prompt suivant, puis `0.2.7-rel.001` publie la surface stable sans nouvelle capacité runtime. `prompts/013-V0_2_8_START_PROMPT.md` devient le contrat actif pour `0.2.8` depuis `v0.2.7`.
|
||
|
||
### `0.2.8` — Helius LaserStream WebSocket
|
||
|
||
Mission accomplie : étendre le moteur WebSocket standard avec la surface Helius LaserStream WebSocket actuelle sans copier le client/session actor. Le gate et l'historique complet sont conservés dans [`015-V0_2_8_HELIUS_LASERSTREAM_WEBSOCKET_PLAN.md`](015-V0_2_8_HELIUS_LASERSTREAM_WEBSOCKET_PLAN.md) et la matrice finale dans [`../validation/011-V0_2_8_HELIUS_LASERSTREAM_WEBSOCKET.md`](../validation/011-V0_2_8_HELIUS_LASERSTREAM_WEBSOCKET.md).
|
||
|
||
Le réaudit final Helius du 23 août 2026 retient `helius_laserstream` comme protocol kind WebSocket : les sept familles standard `account/logs/program/root/signature/slot/slotsUpdates` réutilisent les wrappers publiés, `block/vote` restent absents et `transactionSubscribe`/`transactionUnsubscribe` constitue l'extension provider-specific. `slotsUpdates` conserve son statut unstable, `notifyOn` deprecated/no-op n'est pas exposé et le heartbeat Helius-only envoie un WebSocket Ping control frame toutes les 60 secondes depuis l'actor partagé.
|
||
|
||
`pre.010` ferme README/USAGE, la stratégie smoke live architecture-safe et les graphes Cargo finaux ; `pre.011` ferme la candidate documentaire et prépare [`../../prompts/014-V0_2_9_START_PROMPT.md`](../../prompts/014-V0_2_9_START_PROMPT.md). `0.2.8-rel.001` publie ensuite cette surface stable sans nouvelle capacité runtime. Aucun SDK Helius, aucune dépendance gRPC et aucun replay historique WebSocket ne sont introduits.
|
||
|
||
### `0.2.9` — Yellowstone gRPC engine + standard Solana + PublicNode
|
||
|
||
Mission accomplie : `0.2.9-rel.001` publie le moteur Yellowstone N1, le standard Solana N2, Config Transport V3 et la première intégration provider-neutral PublicNode. Les smokes Mainnet et Testnet ont validé `Subscribe -> Slot` avec metadata `x-token` secrète sans façade PublicNode spécifique.
|
||
|
||
Cette release devient la fondation stable des providers suivants. Le moteur physique et la surface standard ne sont pas redéfinis par une release provider : une divergence provider se compose au-dessus, ou devient un blocker architectural explicite si elle ne peut pas être composée proprement.
|
||
|
||
### `0.2.10` — OrbitFlare Yellowstone gRPC
|
||
|
||
Mission active : obtenir en priorité un provider Yellowstone gratuit sur **Devnet** pour les tests futurs, puis matérialiser uniquement les divergences OrbitFlare réellement prouvées. Le plan Free actuel annonce `gRPC Devnet only` et le CLI documente `http://devnet.rpc.orbitflare.com:10000`.
|
||
|
||
`0.2.10-pre.001` fixe un invariant renforcé : N1 gRPC et N2 Yellowstone restent immuables. L'auth Customer API, le token gRPC éventuel, le heartbeat, les quotas et les capabilities sont classifiés séparément. Le premier smoke doit tenter le standard N2 sans secret sur Devnet, observer un `Slot` et caractériser le `Ping` serveur Yellowstone avant toute façade/policy provider.
|
||
|
||
Le plan actif est [`017-V0_2_10_ORBITFLARE_YELLOWSTONE_GRPC_PLAN.md`](017-V0_2_10_ORBITFLARE_YELLOWSTONE_GRPC_PLAN.md) et la matrice active [`../validation/013-V0_2_10_ORBITFLARE_YELLOWSTONE_GRPC.md`](../validation/013-V0_2_10_ORBITFLARE_YELLOWSTONE_GRPC.md).
|
||
|
||
### TODO/IDEAS — providers Yellowstone en attente
|
||
|
||
Aucune release n'est réservée pour :
|
||
|
||
```text
|
||
TODO Helius LaserStream gRPC — réauditer lorsque l'accès live gRPC est disponible
|
||
TODO eRPC
|
||
TODO Triton
|
||
TODO Alchemy
|
||
TODO QuickNode
|
||
TODO Chainstack
|
||
IDEAS Tatum
|
||
IDEAS Shyft
|
||
IDEAS Solinfra
|
||
IDEAS NodeFlare
|
||
IDEAS autres providers à réauditer
|
||
```
|
||
|
||
Helius LaserStream gRPC est explicitement reporté : l'audit 2026-08-25 indique une compatibilité wire Yellowstone élevée et une intégration KSP probablement légère au-dessus de N1/N2, mais aucun accès live Helius gRPC n'est actuellement disponible sans plan payant. Il ne reçoit donc plus de numéro de release tant que l'auth, les endpoints, le Subscribe, le Ping, le replay/from_slot et les erreurs provider ne peuvent pas être validés live. Les extensions Helius non standard, notamment les preprocessed transactions, restent un sujet provider séparé.
|
||
|
||
Ces providers ne déplacent pas la séquence active et ne reçoivent ni façade, ni Config profile, ni smoke tant qu'une décision explicite d'implémentation n'est pas prise.
|
||
|
||
### `0.2.11` / `0.2.12` — Off-chain price + SOL Prices Desk
|
||
|
||
`0.2.11` introduit `ksp-offchain-transport-lib` avec une première surface volontairement limitée à SOL/USD. La release retient huit adapters REST (`CoinGecko`, `CoinMarketCap`, `CoinPaprika`, `Kraken`, `Coinbase Exchange`, `Jupiter Price V3`, `Birdeye`, `DexScreener`) utilisant `reqwest` et des DTOs KSP privés, sans SDK provider. Off-chain Transport possède le registry, les capacités/rate limits, les indisponibilités et les refresh individuels/multiples séquentiels ; Config construit le service depuis `std.offchain_transport`. Le gate live final keyless passe `7/7` après correction du paramètre CoinMarketCap Simple Price V2. Aucun consensus, fallback automatique ou découverte de pool DexScreener n'est introduit.
|
||
|
||
`0.2.12` ajoute `ksp-app-solprices-desk`, HID pure qui ne connaît aucun provider et consomme uniquement les descriptors, observations, états et opérations génériques de `ksp-offchain-transport-lib`. La vue Prices expose les états et timestamps distincts, le prix exact, le refresh individuel, sélectionné et global, avec garde batch `1..=64` et sans polling/auto-refresh. Le composite dédié utilise les ports 1434/1435 et un état de présentation backend en mémoire.
|
||
|
||
La même release étend `ksp-app-wallet-desk` de façon minimale : le refresh de balance déclenche aussi le refresh SOL/USD générique, calcule côté Rust une moyenne à partir des observations produites par ce refresh puis affiche cette moyenne et l'équivalent USD exact de la balance, ou `N.A.`. Cette moyenne est strictement consumer-owned et ne crée aucun consensus/fallback/prix canonique dans Off-chain Transport. Le gate final est conservé dans [`019-V0_2_12_SOL_PRICES_DESK_PLAN.md`](019-V0_2_12_SOL_PRICES_DESK_PLAN.md) avec [`../validation/015-V0_2_12_SOL_PRICES_DESK.md`](../validation/015-V0_2_12_SOL_PRICES_DESK.md).
|
||
|
||
Metadata HTTP/IPFS/Arweave viendra au premier besoin Metadata réel. SOL/EUR et les autres quotes restent une extension ultérieure explicite, sans conversion fiat cachée.
|
||
|
||
### `0.2.13` — Interface foundation
|
||
|
||
`ksp-interface-lib` matérialise la première façade wire officielle KSP, volontairement passive et Program-facing. La surface candidate stable réexporte le `Pubkey` canonique de Core et expose `ProgramAccountMeta` ainsi que `ProgramInstruction` avec champs privés, accessors explicites et admission bornée à `255` account metas et `10_240` bytes de data. L'ordre et les doublons sont conservés, les Program Pubkeys opaques restent acceptés et les diagnostics ne recopient ni payload ni account material arbitraire.
|
||
|
||
La dependency direction reste strictement `Interface -> Core`; aucun serde/codec générique, `solana-instruction`, runtime réseau ou logging n'est introduit. La façade crate-root est verrouillée par canaris public API, consumer externe, release completeness et dependency firewall. [`../../crates/ksp-interface-lib/README.md`](../../crates/ksp-interface-lib/README.md) et [`../../crates/ksp-interface-lib/USAGE.md`](../../crates/ksp-interface-lib/USAGE.md) deviennent les références durables de cette foundation. Le gate technique final `pre.006` est vert avant réconciliation documentaire.
|
||
|
||
Aucune `ksp-interface-api` séparée n'est retenue pour l'instant. Les codecs/layouts spécifiques restent conditionnés à un vertical réel. La décomposition STRUCTURAL générique reste reportée à la série STRUCTURAL ouverte seulement après fermeture de la couche RAW ; elle n'est plus associée à un ancien numéro `0.3.2+` devenu obsolète.
|
||
|
||
### `0.2.14` — Program API foundation
|
||
|
||
`ksp-program-api`, sans suffixe `-lib`, matérialise la première façade publique ouverte du domaine Program. La candidate reste volontairement instruction-only et dépend uniquement de Core + Interface.
|
||
|
||
La surface commune est :
|
||
|
||
```text
|
||
ProgramInstructionRecognition
|
||
NoMatch / ProgramMatch / ExactMatch
|
||
|
||
ProgramInstructionDecodeOutcome<Decoded>
|
||
Decoded(Decoded) / Unsupported
|
||
|
||
ProgramInstructionDecoder: Send + Sync
|
||
type Decoded
|
||
program_ids(&self) -> &[Pubkey]
|
||
recognize(&self, &ProgramInstruction) -> ProgramInstructionRecognition
|
||
decode(&self, &ProgramInstruction) -> Result<ProgramInstructionDecodeOutcome<Self::Decoded>>
|
||
```
|
||
|
||
L'output concret reste possédé par l'implémentation et ne reçoit aucun bound implicite `Debug/Clone/Send/Sync`. Une crate externe peut implémenter le trait pour un Program Pubkey absent du registry Core ; aucun enum central de Programs, `Any`, JSON, registry runtime ou descriptor global n'est requis.
|
||
|
||
Le hardening final verrouille l'inventaire crate-root exact, le passage d'une `ProgramInstruction` Interface maximale par référence, l'absence d'echo automatique de payload hostile, l'absence de default methods et le firewall `Program API -> Core + Interface`. `pre.006` ferme le gate technique avec audits/check/Clippy/tests workspace et graphe Cargo verts. [`../../crates/ksp-program-api/README.md`](../../crates/ksp-program-api/README.md) et [`../../crates/ksp-program-api/USAGE.md`](../../crates/ksp-program-api/USAGE.md) deviennent les références durables de la candidate.
|
||
|
||
Restent explicitement reportés : `ksp-program-lib`, payload canonique D3, registry runtime, identity/version/coverage génériques, autres familles de decoder et `ProgramExecutionPreparer`. Ils seront introduits uniquement par les vertical slices qui démontreront leurs contrats réels.
|
||
|
||
## Architecture durable : RAW -> STRUCTURAL -> DECODED -> DOMAIN
|
||
|
||
La chaîne de données est :
|
||
|
||
```text
|
||
D1 RAW
|
||
-> D2 STRUCTURAL
|
||
-> D3 DECODED
|
||
-> D4 DOMAIN
|
||
```
|
||
|
||
RAW et STRUCTURAL ne nécessitent aucun decoder Program.
|
||
|
||
`RAW -> STRUCTURAL` est une normalisation générique Solana ; le premier decoder intervient à `STRUCTURAL -> DECODED`.
|
||
|
||
## Série `0.3.x` — RAW / acquisition persistée
|
||
|
||
La séquence effective a évolué par sizing et validation réels. La référence détaillée reste `ROADMAP.md`; cette synthèse conserve uniquement les frontières fonctionnelles :
|
||
|
||
```text
|
||
0.3.1 ksp-store-api RAW
|
||
0.3.2 Store runtime + backend PostgreSQL foundation
|
||
0.3.3 persistence RawTransaction
|
||
0.3.4 persistence RawAccountState
|
||
0.3.5 Interface acquisition events
|
||
0.3.6 ksp-job-api + RawTransaction Backfill
|
||
0.3.7 ksp-app-backfill-desk
|
||
0.3.8 ksp-app-store-desk RAW
|
||
0.3.9 ksp-worker-api + audit acquisition RawTransaction
|
||
0.3.10 common ksp-raw-transaction-lib + preuves cross-source
|
||
0.3.11 fondation source-neutral ksp-worker-raw-transaction-ingest-lib
|
||
0.3.12 première verticale live Yellowstone + hydration/replay continuity
|
||
0.3.13 cinq familles live + convergence multi-source/fairness/health/hardening
|
||
0.3.14 gaps run-local + coverage/repair + shutdown/fairness/completeness cross-layer
|
||
0.3.15 ksp-app-raw-transaction-ingest-desk + composition multi-route + fermeture Mainnet
|
||
0.3.16 RAW resilience / conflict variants / Store Desk conflict management
|
||
0.3.17 ksp-job-backfill-lib multi-route / multi-stratégie
|
||
0.3.18 ksp-app-backfill-desk adapté au Backfill multi-route
|
||
```
|
||
|
||
Cette série ferme la couche RAW et ses outils d'exploitation avant l'ouverture fonctionnelle de STRUCTURAL. `0.3.15` ajoute le Desk réseau-centrique multi-route, stabilise la route Mainnet Yellowstone Block + HTTP `getBlock`, conserve la backpressure bornée jusqu'au stream gRPC et accepte uniquement la divergence de `logMessages` explicitement tronquée déjà démontrée lorsque le canonique complet existe. La généralisation des variantes/résolutions reste réservée à `0.3.16`. Le Worker live RAW reste distinct des jobs historiques et ne constitue pas encore une transformation RAW -> STRUCTURAL.
|
||
|
||
Aucune release RAW ne crée par anticipation la persistence DECODED/DOMAIN.
|
||
|
||
## Série STRUCTURAL suivante
|
||
|
||
Objectif : rendre la couche STRUCTURAL exploitable sans aucun decoder Program. Elle décompose les entrées RAW réellement décomposables en unités Solana génériques plus fines destinées au décodage ultérieur :
|
||
|
||
```text
|
||
RAW persisted
|
||
-> Solana generic structural decomposition
|
||
-> STRUCTURAL persistence
|
||
-> RAW -> STRUCTURAL replay/backfill
|
||
-> STRUCTURAL job borné/rejouable
|
||
-> STRUCTURAL worker/service continu
|
||
-> STRUCTURAL inspection/control dans ksp-app-store-desk lorsque pertinent
|
||
```
|
||
|
||
Le nom de couche historique `CORE` est abandonné. `Core` reste réservé à `ksp-core-lib`, à son domaine fondamental et aux noms propres tels que « Solana Core Programs ».
|
||
|
||
## Séries DECODED/DOMAIN/EXECUTION suivantes
|
||
|
||
À partir du décodage, KSP progresse par vertical slices complets et non par grandes couches de crates isolées :
|
||
|
||
```text
|
||
wire
|
||
-> decode
|
||
-> materialize
|
||
-> specialized projection si utile
|
||
-> execution preparation
|
||
-> execution policy
|
||
-> execute
|
||
-> Devnet scenario
|
||
```
|
||
|
||
Ordre prioritaire :
|
||
|
||
```text
|
||
Solana Core Programs
|
||
-> SPL token/trading
|
||
-> token metadata
|
||
-> Anchor
|
||
-> Meteora
|
||
-> Raydium
|
||
-> Pump
|
||
-> Orca
|
||
-> Market Desk V1
|
||
-> Jupiter/OKX routing
|
||
-> Market Desk V2
|
||
-> trading-adjacent
|
||
-> general decoding
|
||
```
|
||
|
||
Un programme satellite nécessaire reste dans son groupe protocolaire : Pump fee avec Pump, Meteora vaults avec Meteora, etc.
|
||
|
||
SPM est reporté au décodage généraliste ultérieur.
|
||
|
||
## Market Desk
|
||
|
||
Après les DEX prioritaires, introduire une petite `ksp-app-market-desk` consommant les projections KSP pour afficher tokens, pools, liquidité, trades, prix, volumes et OHLC.
|
||
|
||
Après Jupiter/OKX, enrichir la même app avec routes, legs, DEX impliqués, fees/slippage et quote/execution lorsque disponible.
|
||
|
||
L'app ne réimplémente pas les SDK/protocoles DEX ; elle consomme les faits DOMAIN normalisés.
|
||
|
||
## Discipline de sizing
|
||
|
||
Chaque prerelease vise environ 15–20 minutes de travail effectif.
|
||
|
||
Chaque release concrète doit pouvoir être ouverte et clôturée dans une seule session de chat. Si `pre.001` montre que ce n'est pas réaliste, scinder la release avant implémentation fonctionnelle lourde.
|
||
|
||
## Progression de la série `0.1.x`
|
||
|
||
Les releases `0.1.1` à `0.1.4` sont stables et leurs plans/prompts restent historiques.
|
||
|
||
## Clôture stable de `0.2.0` et ouverture de `0.2.1`
|
||
|
||
`0.2.0` a été ouverte par :
|
||
|
||
```text
|
||
prompts/005-V0_2_0_START_PROMPT.md
|
||
```
|
||
|
||
`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
|
||
```
|
||
|
||
`0.2.0-rel.001` publie ce cadrage sous la version stable `0.2.0`. Après validation du commit de release et création du tag `v0.2.0`, le prompt `0.2.1` devient le point d'entrée actif de la série.
|