khadhroony-solana-project/deltas/0.1.1/pre.001.md

Delta 0.1.1-pre.001

Base requise

Release stable/taguée attendue :

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 :

0.0.3

à :

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

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

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 :

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.