khadhroony-solana-project/docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md

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 :

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.5 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 :

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

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 :

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

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 :

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 :

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é :

docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md

Mission :

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 :

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 :

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 :

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 + intégration prix dans Wallet 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 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 : 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. L'application garde les handles VIEW/OWNER côté Rust, ne persiste aucun password dans Config/frontend et délègue toute crypto/signature/administration à ksp-wallet-lib.

Le prompt ../../prompts/011-V0_2_6_START_PROMPT.md, préparé par 0.2.5-pre.010, impose un pre.001 d'audit/sizing couvrant Config std.wallet/composite, inventory/path safety, lifecycle VIEW/OWNER, balance getBalance, bridge Tauri/TS-RS, sécurité password/export, logging et validation finale Tauri.

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. Après stabilisation de cette application spécialisée, la même release doit intégrer la capacité de prix offchain dans ksp-app-wallet-desk sans dupliquer la récupération/normalisation appartenant au composant spécialisé.

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 :

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é :

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 :

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 :

wire
 -> decode
 -> materialize
 -> specialized projection si utile
 -> execution preparation
 -> execution policy
 -> execute
 -> Devnet scenario

Ordre prioritaire :

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 :

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 :

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.