# 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 à : ```text 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 : ```bash cargo fmt --all cargo check --workspace cargo test --workspace cargo clippy --workspace --all-targets ``` Aucun code fonctionnel n'est ajouté dans cette tranche.