Sasedev/khadhroony-solana-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.1.1-pre.001

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-14 14:11:27 +02:00
parent 9bfcf105d5
commit ecc82f681d
5 changed files with 658 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
Cargo.toml
View File

@@ -1,12 +1,12 @@
# file: Cargo.toml
# version: 17
# version: 18
[workspace]
resolver = "3"
members = ["crates/ksp-core-lib"]
[workspace.package]
version = "0.0.3"
version = "0.1.1-pre.1"
edition = "2024"
license = "MIT"
repository = "https://git.sasedev.com/Sasedev/khadhroony-solana-project"

4
ROADMAP.md
View File

@@ -1,5 +1,5 @@
<!-- file: ROADMAP.md -->
<!-- version: 12 -->
<!-- version: 13 -->
# Roadmap KSP
@@ -31,7 +31,7 @@ Regrouper les releases consacrées aux fondations N1. Chaque release concrète e
### Releases concrètes
- [ ] `0.1.1` — Stabiliser `ksp-core-lib` : `Error`/`Result`, Program IDs fondamentaux et primitives réellement N1.
- [/] `0.1.1` — Stabiliser `ksp-core-lib` : `Error`/`Result`, Program IDs fondamentaux et primitives réellement N1.
- [ ] `0.1.2` — Introduire `ksp-logging-lib` comme façade KSP de `tracing`, `tracing-appender` et `tracing-subscriber`.
- [ ] `0.1.3` — Introduire `ksp-config-lib` : documents, profils, résolution, validation et modifications autorisées.
- [ ] `0.1.4` — Introduire `ksp-app-config-desk` pour valider réellement Config et la frontière Tauri.

219
deltas/0.1.1/pre.001.md Normal file
View File

@@ -0,0 +1,219 @@
<!-- file: deltas/0.1.1/pre.001.md -->
<!-- version: 1 -->
# Delta 0.1.1-pre.001
## Base requise
Release stable/taguée attendue :
```text
v0.0.3
```
L'archive de base fournie contient bien la version Cargo stable `0.0.3` et le delta final `deltas/0.0.3/rel.001.md`.
Elle ne contient pas `.git` : le working tree réel, le commit et le tag `v0.0.3` doivent être vérifiés sur le dépôt cible avant commit de ce delta.
## Objectif
Ouvrir `0.1.1` par la prerelease obligatoire de brainstorming, audit et planification, sans développement fonctionnel Core.
Cette tranche :
- inventorie la surface réelle de `ksp-core-lib` ;
- borne les contrats N1 de la release ;
- propose le contrat ouvert `Error` / `Result` ;
- borne les Program IDs fondamentaux ;
- audite les primitives Solana/Anza actuelles nécessaires ;
- fixe la stratégie d'API, tests et dépendances ;
- dimensionne `pre.002` à `pre.005` ;
- confirme les hors-scope.
## Version Cargo
`workspace.package.version` passe de :
```text
0.0.3
```
à :
```text
0.1.1-pre.1
```
L'identifiant Cargo respecte SemVer sans zéro initial ; l'identifiant de livraison reste `0.1.1-pre.001`.
Le header de `Cargo.toml` passe de version 17 à 18.
## Fichiers ajoutés
- `docs/plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md`
- `deltas/0.1.1/pre.001.md`
## Fichiers modifiés
- `Cargo.toml`
- `ROADMAP.md`
- `docs/plans/000-README.md`
## Fichiers supprimés
Aucun.
## Inventaire Core
`ksp-core-lib` est encore un squelette volontairement minimal :
- aucun module fonctionnel ;
- aucune dépendance externe ;
- aucun type public autre que la documentation de crate ;
- aucun test ;
- aucune surface Error/Result ou Program IDs existante à préserver pour compatibilité.
Cette situation permet de définir le contrat sans dette de compatibilité interne KSP.
## Décisions de planification
### Error/Result
Le modèle historique bot3 avec enum centrale de domaines n'est pas migré.
La direction retenue pour `pre.002` est :
- `Error` structuré ;
- `ErrorCode` ouvert avec domaine/code statiques ;
- `ErrorContext` structuré ;
- message lisible ;
- cause standard optionnelle `Send + Sync` ;
- alias `Result<T>` ;
- aucune connaissance dans Core des futurs domaines Config/Logging/Wallet/Transport/Store/Tauri/protocoles ;
- aucune liste centrale de conversions d'erreurs externes.
Le détail complet et les invariants figurent dans `docs/plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md`.
### Solana/Anza
Sources officielles consultées le 2026-08-14 : dépôt `anza-xyz/solana-sdk`, notamment la crate Pubkey, la primitive Address, `sdk-ids` et le manifest workspace.
État vérifié :
```text
solana-pubkey 4.3.0
solana-address 2.7.0
solana-sdk-ids 3.1.0 package
Solana SDK workspace MSRV 1.89.0
```
Direction retenue :
- runtime Core : `solana-pubkey` seulement, lorsque `pre.003` implémentera réellement les Program IDs ;
- `default-features = false` tant qu'aucune feature supplémentaire n'est démontrée nécessaire ;
- `Pubkey` réexporté depuis `ksp_core_lib` ;
- pas de dépendance directe KSP à `solana-address` ;
- `solana-sdk-ids` seulement comme dev-dependency candidate pour les tests de conformité, pas comme dépendance runtime ;
- aucune autre primitive Solana autorisée n'est ajoutée par anticipation.
Les versions seront revérifiées juste avant leur ajout réel au manifeste.
### Program IDs
Première surface proposée : 17 Program IDs fondamentaux exposés par la source officielle Solana SDK, incluant les loaders et précompiles de la frontière runtime :
- Address Lookup Table ;
- BPF Loader ;
- BPF Loader deprecated ;
- BPF Loader Upgradeable ;
- Compute Budget ;
- Config ;
- Ed25519 precompile ;
- Feature ;
- Loader v4 ;
- Native Loader ;
- Secp256k1 precompile ;
- Secp256r1 precompile ;
- Stake ;
- System ;
- Vote ;
- ZK ElGamal Proof ;
- ZK Token Proof.
Sont exclus : sysvars, incinerator, stake config account, SPL/protocoles, registre enumerable et alias bot3 historiques.
### Autres primitives
Aucune autre primitive commune n'est justifiée maintenant.
`Hash`, `Nonce`, Keypair, Signer, identité/version de module et provenance restent reportés jusqu'à un besoin concret.
## Prereleases prévues
```text
pre.001 audit + brainstorming + plan
pre.002 Error/Result + tests publics
pre.003 Pubkey + Program IDs + conformité Solana
pre.004 intégration Core + audits + compléments strictement justifiés
pre.005 validations finales + docs/cleanup + prompt 0.1.2
```
Le découpage reste souple ; une tranche trop large sera scindée plutôt que surchargée.
## Hors scope confirmé
- Logging ;
- Config ;
- Tauri ;
- Wallet/signing ;
- codecs wire ;
- Interface ;
- Program decoding/registry/preparation ;
- Execution ;
- Transport ;
- Store ;
- Materializer ;
- workers/jobs/pipelines ;
- scenarios ;
- trading/ML.
## Validations exécutées
Dans l'environnement de préparation de ce delta :
- lecture/audit de l'archive complète `0.0.3` fournie ;
- vérification de la version stable `0.0.3` dans le manifest ;
- vérification de la présence du delta `0.0.3/rel.001` et du prompt final `0.1.1` ;
- inventaire de `ksp-core-lib` ;
- lecture des règles, plans et documents d'architecture requis par le prompt ;
- audit de l'ancien `ks-core` / `ks-program-ids` de l'archive bot3 fournie comme référence historique, sans le traiter comme source de vérité KSP ;
- vérification des versions et surfaces actuelles sur les sources officielles Anza/Solana ;
- parsing TOML statique du manifest modifié ;
- contrôle statique des headers `file:` / `version:` des fichiers ajoutés/modifiés ;
- contrôle statique des liens Markdown locaux après modification.
## Validations non exécutées
L'environnement de préparation ne contient ni `cargo` ni `rustc`.
Les commandes suivantes n'ont donc pas pu être exécutées ici :
```bash
cargo fmt --all
cargo check --workspace
cargo test --workspace
cargo clippy --workspace --all-targets
```
Elles doivent être exécutées sur le dépôt réel après application du delta. Aucun succès Cargo n'est déclaré par ce delta.
Le tag Git et le working tree ne peuvent pas non plus être vérifiés depuis l'archive fournie, qui ne contient pas `.git`.
## Questions ouvertes
- validation par le user du modèle Error/Result proposé avant `pre.002` ;
- choix exact des méthodes ergonomiques de contexte et du format `Display`, à stabiliser par tests en `pre.002` ;
- revérification de la version Solana et du MSRV juste avant `pre.003` ;
- confirmation de l'utilité de `solana-sdk-ids` comme dev-dependency de conformité au moment où les tests sont écrits.
Aucune question ouverte ne justifie de commencer le développement fonctionnel avant validation de ce plan.

3
docs/plans/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/000-README.md -->
<!-- version: 3 -->
<!-- version: 4 -->
# Plans KSP
@@ -11,6 +11,7 @@ Un plan décrit le périmètre, les décisions déjà acquises, les questions ou
- [`001-V0_0_3_PLAN.md`](001-V0_0_3_PLAN.md) — plan historique de la phase fondatrice `0.0.3`, clôturée ;
- [`002-FUNCTIONAL_RELEASE_SEQUENCE.md`](002-FUNCTIONAL_RELEASE_SEQUENCE.md) — séquence active de référence des premières releases fonctionnelles, dont `0.1.1`.
- [`003-V0_1_1_CORE_FOUNDATION_PLAN.md`](003-V0_1_1_CORE_FOUNDATION_PLAN.md) — plan actif détaillé de `0.1.1`, établi par `0.1.1-pre.001`.
Le `pre.001` de chaque release fonctionnelle peut introduire son propre plan détaillé lorsque la release s'ouvre.

433
docs/plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md Normal file
View File

@@ -0,0 +1,433 @@
<!-- file: docs/plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md -->
<!-- version: 1 -->
# Plan KSP 0.1.1 — Core foundation
## Statut
Plan de travail de `0.1.1`, établi par `0.1.1-pre.001`.
Cette première prerelease reste une tranche de brainstorming, audit et planification. Elle ne développe pas encore la surface fonctionnelle Core.
## Base auditée
Base fournie :
```text
0.0.3 stable
```
Constats sur l'archive reçue :
- `workspace.package.version = "0.0.3"` ;
- seul `crates/ksp-core-lib` est membre du workspace ;
- `ksp-core-lib` ne possède encore aucune dépendance ;
- `crates/ksp-core-lib/src/lib.rs` contient uniquement la façade/squelette minimal et les lints de crate ;
- le delta final `deltas/0.0.3/rel.001.md` indique que les validations Cargo de publication ont été exécutées avec succès par le user avant stabilisation ;
- le prompt `prompts/001-V0_1_1_START_PROMPT.md` présent dans l'archive correspond au prompt final attendu pour cette session.
L'archive ne contient pas `.git`. L'état du working tree réel, le commit stable et le tag `v0.0.3` ne peuvent donc pas être vérifiés depuis cette archive et restent à confirmer sur le dépôt Git réel avant commit de `0.1.1-pre.001`.
## Mission bornée
`0.1.1` doit rendre `ksp-core-lib` immédiatement consommable par les prochaines fondations N1 sans lui faire absorber leurs responsabilités.
La surface retenue pour cette release est limitée à :
1. un contrat commun `Error` / `Result` ouvert aux domaines supérieurs ;
2. la primitive Solana d'adresse publique nécessaire aux Program IDs ;
3. les Program IDs fondamentaux du runtime Solana ;
4. les réexports crate-root, rustdocs et tests nécessaires à ces contrats.
Aucune autre primitive n'est ajoutée sans usage concret découvert pendant la release.
## Inventaire des contrats Core nécessaires maintenant
### `Error` / `Result`
Besoin concret immédiat : `0.1.2` Logging puis les autres crates KSP doivent pouvoir retourner une erreur KSP commune sans obliger leurs consommateurs à adopter une erreur propre à chaque couche.
Le modèle historique de bot3 fondé sur une enum centrale comportant des variantes telles que Config, Tracing, Tauri, HTTP ou DB n'est pas repris : une telle enum fait connaître à Core les domaines supérieurs et doit être modifiée à chaque nouveau domaine.
### `Pubkey`
Les Program IDs ont besoin d'une représentation Solana typée et commune. Core doit posséder cette dépendance fondamentale et peut réexporter le type afin que les crates KSP supérieures n'aient pas à importer directement la crate Solana correspondante uniquement pour manipuler un Program ID.
### Program IDs fondamentaux
Core doit posséder les identifiants du runtime Solana qui ne relèvent d'aucun protocole supérieur.
Cette responsabilité ne signifie pas qu'il doit posséder un registre de dispatch, des decoders, des instructions wire ou une taxonomie de protocoles.
## Contrat d'erreur proposé
### Forme générale
La direction retenue pour `pre.002` est un type structuré et extensible plutôt qu'une enum fermée.
Surface conceptuelle :
```text
ErrorCode
domain: &'static str
code: &'static str
ErrorContext
key: &'static str
value: String
Error
code: ErrorCode
message: String
context: Vec<ErrorContext>
source: Option<Box<dyn std::error::Error + Send + Sync + 'static>>
Result<T> = std::result::Result<T, Error>
```
Le détail syntaxique Rust exact reste à implémenter et tester dans `pre.002`, mais les invariants suivants font partie du plan.
### Invariants
- `Error` est le seul type d'erreur KSP commun exposé par Core.
- `Result<T>` est un alias public vers `std::result::Result<T, Error>`.
- `ErrorCode` sépare explicitement un domaine stable et un code stable sans enum centrale des domaines.
- Les domaines supérieurs définissent leurs propres constantes `ErrorCode` ; Core ne connaît pas Config, Logging, Wallet, Transport, Store, Tauri ou les protocoles.
- Les identifiants de domaine/code sont des chaînes statiques afin de favoriser des codes définis au code source et stables, pas des catégories dynamiques construites au runtime.
- `message` reste un diagnostic lisible par un humain.
- `ErrorContext` permet d'ajouter du contexte structuré sans étendre le type `Error` à chaque besoin métier.
- Les clés de contexte sont statiques ; les valeurs sont possédées.
- Le contexte d'erreur ne doit pas contenir de secret. Logging décidera plus tard quels champs sont effectivement émis.
- Une cause externe peut être conservée par `source` lorsqu'elle implémente `std::error::Error + Send + Sync + 'static`.
- Une erreur externe qui ne respecte pas ces bornes peut toujours être transformée explicitement en message/contexte sans être conservée comme `source`.
- `Error` implémente `std::fmt::Display` et `std::error::Error`.
- `Display` expose le code qualifié et le message principal ; il ne concatène pas automatiquement tout le contexte ou toute la chaîne de causes.
- Aucun `From<ExternalError>` générique ou inventaire de conversions propres aux futurs domaines n'est ajouté dans Core. Les crates propriétaires enveloppent explicitement leur cause avec leur propre `ErrorCode`.
- Aucun besoin de `Clone`, `Eq` ou `PartialEq` n'est imposé à `Error` : préserver une vraie cause d'erreur est prioritaire sur ces dérivations.
Exemple conceptuel de code qualifié :
```text
config.profile_missing
logging.initialization_failed
transport.http_request_failed
```
Ces exemples illustrent le contrat ouvert ; ils ne créent aucune connaissance de ces domaines dans Core.
## API publique Core prévue
La façade crate-root doit exposer directement les contrats consommables :
```text
ksp_core_lib::Error
ksp_core_lib::ErrorCode
ksp_core_lib::ErrorContext
ksp_core_lib::Result
ksp_core_lib::Pubkey
```
Les modules d'implémentation restent privés conformément aux règles Rust du dépôt.
Arborescence candidate après développement :
```text
crates/ksp-core-lib/
├── Cargo.toml
├── src/
│ ├── lib.rs
│ ├── error.rs
│ └── program_ids.rs
├── unit_tests/
│ ├── error.rs
│ └── program_ids.rs
└── tests/
└── public_api.rs
```
Cette arborescence peut être ajustée si l'implémentation révèle une séparation plus simple, sans introduire `mod.rs` ni `pub mod`.
## Audit Solana/Anza actuel
Audit effectué le 2026-08-14 sur les sources officielles actuelles du dépôt `anza-xyz/solana-sdk` et les métadonnées de publication correspondantes.
### `solana-pubkey`
État observé :
```text
solana-pubkey 4.3.0
MSRV officiel du workspace Solana SDK : Rust 1.89.0
```
La génération actuelle de `solana-pubkey` est une façade de compatibilité officielle sur `solana-address` : elle réexporte notamment `solana_address::Address` sous le nom `Pubkey`.
Décision pour `0.1.1` :
- conserver le vocabulaire/API KSP `Pubkey` déjà prévu par l'architecture ;
- utiliser directement `solana-pubkey` comme dépendance propriétaire de `ksp-core-lib` ;
- viser `4.3.0` comme génération de départ vérifiée ;
- désactiver les default features tant qu'aucun besoin ne justifie `std` ou une feature optionnelle de cette crate ;
- n'activer ni Borsh, ni Wincode, ni Serde, ni Rand, ni feature cryptographique par anticipation ;
- réexporter le type `Pubkey` depuis `ksp_core_lib` afin que son utilisation fasse partie intentionnellement du contrat Core.
La dépendance exacte ne sera ajoutée qu'en `pre.003`, au moment où le code Program IDs en aura réellement besoin. La version officielle actuelle devra être revérifiée juste avant modification du manifeste si cette prerelease est réalisée à une date ultérieure.
### `solana-address`
`solana-address 2.7.0` est la primitive interne actuelle derrière `solana-pubkey`.
Elle n'est pas ajoutée directement à KSP en `0.1.1` : l'ajouter en parallèle n'apporte aucun besoin Core supplémentaire et multiplierait les points d'entrée publics pour la même identité Solana.
### `solana-sdk-ids`
La source officielle `solana-sdk-ids` expose les identifiants canoniques du runtime et s'appuie sur `solana-address`.
État du package observé :
```text
solana-sdk-ids 3.1.0
```
Décision proposée : ne pas en faire une dépendance runtime de Core. KSP possède ses noms publics et constantes Core, construits avec `Pubkey`.
En revanche, `solana-sdk-ids` est un bon candidat de **dev-dependency uniquement** en `pre.003` pour vérifier que les constantes KSP correspondent aux identifiants officiels. Son ajout devra être confirmé par le test concret et revérifié au moment de l'implémentation.
### Crates explicitement non nécessaires à `0.1.1`
Ne pas ajouter :
- `solana-sdk` umbrella ;
- `solana-keypair` ;
- `solana-signer` ;
- `solana-hash` ;
- `solana-nonce` ;
- crates transaction/message/instruction ;
- crates RPC/client ;
- Borsh/Wincode/Serde pour une hypothétique future surface wire.
La génération actuelle de `solana-pubkey` requiert Rust 1.89.0. Avant son ajout en `pre.003`, la toolchain réelle du dépôt devra donc être vérifiée. Une toolchain plus ancienne ne doit pas conduire silencieusement à choisir une vieille génération Solana uniquement pour contourner cette exigence.
## Program IDs retenus pour la première surface Core
La première surface doit contenir uniquement les Program IDs fondamentaux actuellement exposés par la source officielle `solana-sdk-ids`, y compris les loaders et précompiles qui font partie de la frontière runtime :
```text
ADDRESS_LOOKUP_TABLE_PROGRAM_ID
BPF_LOADER_PROGRAM_ID
BPF_LOADER_DEPRECATED_PROGRAM_ID
BPF_LOADER_UPGRADEABLE_PROGRAM_ID
COMPUTE_BUDGET_PROGRAM_ID
CONFIG_PROGRAM_ID
ED25519_PROGRAM_ID
FEATURE_PROGRAM_ID
LOADER_V4_PROGRAM_ID
NATIVE_LOADER_PROGRAM_ID
SECP256K1_PROGRAM_ID
SECP256R1_PROGRAM_ID
STAKE_PROGRAM_ID
SYSTEM_PROGRAM_ID
VOTE_PROGRAM_ID
ZK_ELGAMAL_PROOF_PROGRAM_ID
ZK_TOKEN_PROOF_PROGRAM_ID
```
Les noms KSP définitifs seront confirmés au moment du code, mais doivent rester explicites et crate-root.
### Exclusions volontaires
Ne pas inclure dans cette première liste :
- SPL Token, Token-2022, ATA, Memo ou tout autre protocole SPL ;
- Metaplex et autres protocoles ;
- `incinerator`, qui est une adresse spéciale et non un Program ID exécutable ;
- le compte historique `stake::config` ;
- les sysvar account IDs ;
- un registre enumerable `ProgramIdEntry` ;
- une classification native/protocole destinée au futur `ksp-program-api` ;
- des alias de compatibilité historiques venant de bot3.
Les well-known account IDs pourront être ajoutés plus tard si un consommateur Core réel les nécessite. Ils ne doivent pas être confondus avec les Program IDs simplement pour agrandir la première surface.
## Construction et ownership des constantes
Les constantes KSP doivent être des valeurs typées `Pubkey` produites à la compilation à partir des adresses canoniques vérifiées.
KSP ne dépend pas d'un registre runtime externe pour les obtenir.
La source officielle Solana/Anza sert :
1. de source de vérité pour la valeur ;
2. éventuellement de référence de test via `solana-sdk-ids` en dev-dependency ;
3. de contrôle lors des audits de version.
Le code ne doit pas recopier d'architecture ou d'API supérieure de `solana-sdk-ids` au-delà des constantes réellement nécessaires.
## Primitives communes supplémentaires
Aucune primitive supplémentaire n'est démontrée nécessaire pendant `pre.001`.
Sont donc explicitement reportés :
- identité/version de module générique ;
- provenance/processor version ;
- `Hash` ;
- `Nonce` ;
- temps/slot ;
- identifiants de transport/provider ;
- types de transaction/instruction/account ;
- traits de module ou de composant.
L'ancien `ks-core::ModuleKind` / `ModuleName` / `ModuleVersion` de bot3 n'est pas migré par défaut. Une convention de provenance ne sera ajoutée que lorsqu'un consommateur réel l'exigera.
## Stratégie de tests
### `pre.002` — Error
Tests unitaires externes sous `unit_tests/` pour vérifier au minimum :
- conservation du domaine/code ;
- message ;
- ajout et ordre du contexte ;
- format `Display` ;
- absence du contexte/source dans le rendu si ce choix est conservé ;
- conservation de `source()` ;
- `Send + Sync` du type commun au moyen d'un test de compilation approprié.
Test d'intégration sous `tests/` pour vérifier que `Error`, `ErrorCode`, `ErrorContext` et `Result` sont réellement consommables depuis le crate-root.
### `pre.003` — Pubkey et Program IDs
Tests unitaires externes pour vérifier les invariants internes éventuels.
Tests d'intégration pour vérifier :
- `ksp_core_lib::Pubkey` consommable depuis la façade ;
- type exact des constantes ;
- valeurs attendues des Program IDs ;
- unicité des 17 Program IDs retenus ;
- conformité aux IDs officiels via `solana-sdk-ids` si la dev-dependency est retenue.
L'ordre d'une liste de test ne devient pas un contrat public si aucune liste n'est exposée par l'API.
## Validations prévues
Après chaque modification Rust applicable :
```bash
cargo fmt --all
cargo check --workspace
cargo test --workspace
cargo clippy --workspace --all-targets
```
Audits complémentaires prévus lorsque la dépendance Solana existe :
```bash
cargo tree -p ksp-core-lib
cargo tree -p ksp-core-lib -d
```
Objectifs :
- confirmer que Core ne tire aucune couche KSP supérieure ;
- confirmer l'absence de codecs wire ajoutés par KSP ;
- examiner toute duplication de génération fondamentale ;
- vérifier que seules les features Solana nécessaires sont actives.
Les scripts/audits propres au dépôt seront exécutés s'ils existent réellement au moment de chaque tranche. Aucun script de ce type n'est présent dans l'archive `0.0.3` auditée.
## Découpage des prereleases
### `0.1.1-pre.001` — audit + brainstorming + plan
Objectifs :
- inventorier Core ;
- fixer la direction Error/Result ;
- borner les Program IDs ;
- vérifier la génération Solana actuelle ;
- décider les dépendances réellement candidates ;
- fixer tests, API et hors-scope ;
- ouvrir le plan `003-V0_1_1_CORE_FOUNDATION_PLAN.md`.
Pas de développement fonctionnel Core.
### `0.1.1-pre.002` — Error/Result
Objectifs :
- implémenter `ErrorCode`, `ErrorContext`, `Error` et `Result<T>` ;
- mettre en place les modules privés et réexports crate-root associés ;
- ajouter les tests unitaires externes et tests d'intégration de cette surface ;
- valider l'absence de connaissance des domaines supérieurs.
Aucune dépendance Solana n'est nécessaire à cette tranche.
### `0.1.1-pre.003` — Pubkey + Program IDs
Objectifs :
- revérifier les versions Solana/Anza au jour de l'implémentation ;
- vérifier `rustc` par rapport au MSRV de la génération retenue ;
- ajouter `solana-pubkey` uniquement au propriétaire `ksp-core-lib` ;
- réexporter `Pubkey` ;
- implémenter les 17 Program IDs retenus ;
- ajouter les tests de conformité ;
- décider et, si utile, ajouter `solana-sdk-ids` uniquement en dev-dependency ;
- auditer le graphe/features réels.
### `0.1.1-pre.004` — intégration Core + audits
Objectifs :
- auditer ensemble Error/Result, Pubkey et Program IDs comme façade Core ;
- compléter rustdocs et tests publics manquants ;
- vérifier imports/réexports/visibilités et `unreachable_pub` ;
- vérifier le graphe de dépendances et les features ;
- n'ajouter une primitive N1 supplémentaire que si un besoin concret découvert par cet audit la justifie explicitement.
Cette tranche peut rester petite si `pre.002` et `pre.003` sont déjà complètes.
### `0.1.1-pre.005` — clôture
Objectifs :
- validations finales workspace ;
- audits documentaires applicables ;
- correction des écarts résiduels ;
- documentation finale et éventuel `USAGE.md` de Core si l'API justifie alors un exemple durable ;
- nettoyage/archivage des éléments temporaires ;
- mise à jour du changelog général s'il existe alors ;
- production du prompt final de démarrage `0.1.2` ;
- préparation de la publication stable et du tag `v0.1.1`.
Un `pre.NNN-fix.NNN` corrige la tranche correspondante sans réécrire son historique.
## Hors scope confirmé
`0.1.1` n'ouvre pas :
- `ksp-logging-lib` ;
- `ksp-config-lib` ;
- Tauri ;
- wallet/keypair/signer ;
- Borsh/Wincode et autres codecs wire ;
- `ksp-interface-lib` ;
- Program decoder/registry/`ProgramExecutionPreparer` ;
- execution policy/orchestration ;
- transport RPC/WS/Helius/Yellowstone ;
- Store/PostgreSQL ;
- materializers ;
- workers/jobs/pipelines ;
- scenarios ;
- trading/ML.
## Questions ouvertes non bloquantes
- Confirmer, pendant `pre.002`, si `ErrorContext` doit être ajouté par une méthode consommant `self` (`with_context`) ou par une méthode mutable ; privilégier l'API la plus simple compatible avec le style explicite KSP.
- Confirmer le format exact de `Display` par les tests avant de le considérer stable.
- Revérifier en `pre.003` les versions publiées de `solana-pubkey` et `solana-sdk-ids` ainsi que le MSRV officiel au jour du code.
- Décider en `pre.005`, à partir de l'API réellement stabilisée, si un `README.md`/`USAGE.md` de crate apporte suffisamment de valeur pour être créé maintenant.
Aucune de ces questions ne justifie d'élargir le périmètre fonctionnel de `0.1.1`.