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

Delta 0.0.3-pre.001

Base requise

Release v0.0.2.

Objectif

Ouvrir la phase de brainstorming/planification 0.0.3 sans développement fonctionnel.

Cette tranche formalise les objectifs produits déjà discutés, le premier modèle de couches, les règles de dépendances externes, les responsabilités des applications/demos/workers et une prévision souple des prereleases nécessaires pour terminer la fondation avant 0.1.x.

Version Cargo

workspace.package.version passe à :

0.0.3-pre.1

Cette synchronisation est obligatoire pour toute nouvelle prerelease non-fix, même lorsque la tranche est essentiellement documentaire.

Le fichier livré utilise # version: 7, en supposant que la publication finale v0.0.2 a synchronisé le Cargo.toml de la base vers la version fichier 6 conformément aux règles. Si la base locale ne correspond pas à cette hypothèse, la version de fichier doit être réconciliée avant commit sans changer l'identifiant fonctionnel 0.0.3-pre.1.

Fichiers ajoutés

• docs/architecture/000-README.md
• docs/architecture/001-PROJECT_OBJECTIVES.md
• docs/architecture/002-LAYERS_AND_DEPENDENCIES.md
• docs/plans/000-README.md
• docs/plans/001-V0_0_3_PLAN.md
• docs/rules/RULES_DEPENDENCIES.md
• deltas/0.0.3/pre.001.md

Fichiers modifiés

• Cargo.toml
• README.md
• RULES.md
• ROADMAP.md
• docs/000-README.md
• docs/IDEAS.md
• docs/rules/FILE_CONTRACTS.md
• docs/rules/RULES_KSP.md

Fichiers supprimés

Aucun.

Décisions enregistrées

• ksp-config-lib et ksp-logging-lib sont positionnés en N1 avec ksp-core-lib et la future crate d'interface/wire.
• Les niveaux servent à déterminer responsabilité et sens des dépendances ; ils ne forcent pas un passage par toutes les couches.
• Une application spécialisée peut dépendre directement de la bibliothèque KSP qu'elle manipule.
• Les applications et demos sont des interfaces/compositions et ne réimplémentent pas les opérations réutilisables.
• Une demo réutilise une bibliothèque de scénarios lorsqu'un scénario correspondant existe.
• Les workers peuvent posséder l'orchestration runtime nécessaire mais ne contournent pas les bibliothèques KSP.
• Applications, demos et workers ne dépendent pas directement de crates externes liées à Solana ou à un protocole Solana.
• Les dépendances Solana externes sont confinées aux bibliothèques KSP propriétaires appropriées.
• solana-pubkey, solana-keypair, solana-signer, solana-hash et solana-nonce sont retenues comme primitives fondamentales autorisées dans les bibliothèques appropriées.
• mpl-token-metadata, spl-elgamal-registry-interface et les crates protocolaires analogues sont interdites par défaut comme dépendances runtime ; KSP préfère posséder les contrats wire nécessaires.
• L'objectif court terme est une application de trading monoposte ; les objectifs moyen/long terme incluent un explorer Solana et une application d'exploration/analyse DEX plus complète.

Questions ouvertes

• nom définitif et périmètre exact de ksp-interface-lib ;
• découpage decoder / construction / exécution ;
• liste candidate et responsabilité précise des crates N2/N3 ;
• position exacte de wallet, transport, store, pipeline, replay et scénarios ;
• méthode de conformité wire contre les projets externes ;
• éventuel usage de crates protocolaires externes uniquement comme dépendances de test ;
• nomenclature finale de toutes les applications et workers ;
• plan exact des versions fonctionnelles 0.1.x+.

Validations exécutées

• vérification statique de la syntaxe TOML du Cargo.toml livré ;
• vérification de présence des en-têtes file: et version: des fichiers Markdown/TOML livrés ;
• vérification de l'arborescence et de l'identifiant du delta.

Validations non exécutées

Les commandes Cargo doivent être exécutées sur le dépôt cible après application :

cargo fmt --all
cargo check --workspace
cargo test --workspace
cargo clippy --workspace --all-targets

Aucun code fonctionnel n'est ajouté dans cette tranche.