560 lines
25 KiB
Markdown
560 lines
25 KiB
Markdown
<!-- file: docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md -->
|
||
<!-- version: 34 -->
|
||
|
||
# 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`, `0.2.0` et `0.2.1` 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 standard foundation
|
||
0.2.10 off-chain price transport
|
||
0.2.11 price visualization desk
|
||
0.2.12 interface/wire foundation
|
||
0.2.13 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 effectué ce réaudit : la partition reste 22 méthodes (5 Accounts + 5 Tokens + 12 Cluster) et le gate de sizing est positif. Le plan d'exécution actif est `docs/plans/009-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER_PLAN.md`.
|
||
|
||
## `0.2.5` — Wallet foundation
|
||
|
||
Mission : créer `ksp-wallet-lib` et le format `.kspwallet`.
|
||
|
||
Inclure protection du secret, pubkey/identity, signature, import/export extensible, changement de mot de passe et publication sûre.
|
||
|
||
Exclure : temporary wallet JSON historique et `WalletPolicy`.
|
||
|
||
## `0.2.6` — Wallet Desk
|
||
|
||
Mission : valider Config composite + `.kspwallet` + transport HTTP dans une application Tauri mince.
|
||
|
||
Le solde d'un wallet constitue un premier cas de validation réseau obligatoire.
|
||
|
||
## `0.2.7` — WebSocket Solana standard
|
||
|
||
Mission : couvrir la surface WebSocket standard officielle ciblée.
|
||
|
||
Une URL peut avoir plusieurs sessions physiques ; une session peut avoir plusieurs subscriptions. Un pool automatique de sessions est reporté jusqu'à besoin concret.
|
||
|
||
## `0.2.8` — Helius LaserStream WebSocket
|
||
|
||
Mission : étendre le moteur WebSocket standard avec les opérations/filtres/capabilities Helius ciblés sans copier le client.
|
||
|
||
## `0.2.9` — Yellowstone gRPC standard
|
||
|
||
Mission : introduire un backend Yellowstone standard/provider-neutral.
|
||
|
||
Le `pre.001` est un gate de sizing : inventorier toute la surface normative cible et scinder la release avant implémentation si sa clôture dans une session paraît incertaine.
|
||
|
||
Les profiles/adapters Helius/Triton/ERPC/Chainstack/Shyft sont reportés après les priorités fondatrices.
|
||
|
||
## `0.2.10` / `0.2.11` — Off-chain price + app
|
||
|
||
`0.2.10` introduit `ksp-offchain-transport-lib` avec au minimum SOL/USD et SOL/EUR via une abstraction indépendante du premier provider.
|
||
|
||
`0.2.11` ajoute une petite application desk de visualisation/validation.
|
||
|
||
Metadata HTTP/IPFS/Arweave viendra au premier besoin Metadata réel.
|
||
|
||
## `0.2.12` — Interface foundation
|
||
|
||
`ksp-interface-lib` devient la façade wire officielle et expose une API publique wire utilisable par les implementations officielles et externes.
|
||
|
||
Aucune `ksp-interface-api` séparée n'est retenue pour l'instant.
|
||
|
||
## `0.2.13` — Program API foundation
|
||
|
||
Introduire `ksp-program-api`, sans suffixe `-lib`, comme contrat d'extension Program.
|
||
|
||
`ksp-program-lib` et les vertical slices réels arrivent plus tard.
|
||
|
||
# Architecture durable : RAW -> CORE -> DECODE -> SPECIALIZED
|
||
|
||
La chaîne de données est :
|
||
|
||
```text
|
||
D1 RAW
|
||
-> D2 CORE
|
||
-> D3 DECODE
|
||
-> D4 SPECIALIZED
|
||
```
|
||
|
||
RAW et CORE ne nécessitent aucun decoder Program.
|
||
|
||
`RAW -> CORE` est une normalisation générique Solana ; le premier decoder intervient à `CORE -> DECODE`.
|
||
|
||
# Série `0.3.x` — RAW / acquisition persistée
|
||
|
||
Début décidé :
|
||
|
||
```text
|
||
0.3.1 ksp-store-api + ksp-store-lib, RAW only
|
||
0.3.2 ksp-interface-lib, wires génériques acquisition/CORE
|
||
0.3.3 ksp-job-api + backfill
|
||
0.3.4 application backfill/RAW
|
||
```
|
||
|
||
La suite de la série termine la couche RAW avec worker/service live et outils d'exploitation utiles avant l'ouverture de CORE.
|
||
|
||
`0.3.1` ne doit pas créer par anticipation les modèles/tables DECODE/SPECIALIZED.
|
||
|
||
# Série CORE suivante
|
||
|
||
Objectif : rendre CORE exploitable sans aucun decoder Program :
|
||
|
||
```text
|
||
RAW persisted
|
||
-> Solana generic normalization
|
||
-> CORE persistence
|
||
-> RAW->CORE replay/backfill
|
||
-> CORE worker/service
|
||
-> CORE inspection/control app
|
||
```
|
||
|
||
# Séries DECODE/SPECIALIZED/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 SPECIALIZED 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.
|