khadhroony-solana-project/deltas/0.1.3/pre.002.md

Delta 0.1.3-pre.002

Base requise

Livraison documentaire précédente validée :

0.1.3-pre.001-fix.003

La base porte :

workspace.package.version = "0.1.3-pre.1"
Cargo.toml header version = 40

Le plan docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md est en version 4 et borne pre.002 à la création de ksp-config-lib et au bootstrap cfgpath / schemapath uniquement.

Objet de pre.002

Cette tranche ouvre le développement fonctionnel de Config sans anticiper les tranches suivantes.

Elle :

• crée ksp-config-lib ;
• ajoute la crate au workspace ;
• fixe les deux racines bootstrap non récursives ;
• expose leur équivalent programmatique ;
• possède le parsing des deux arguments CLI correspondants ;
• valide les chemins bootstrap ;
• introduit uniquement les erreurs Config nécessaires à cette surface ;
• ajoute les tests unitaires et d'intégration de cette API publique.

Elle n'introduit pas encore :

• le registre file_id -> filename ;
• --filemap ;
• serde, serde_json ou jsonschema ;
• les documents JSON runtime ;
• les profils/composites ;
• .env ou std::env::var ;
• l'interpolation ${...} ;
• les secrets ;
• la persistence ;
• une dépendance directe à ksp-logging-lib tant qu'aucun événement Config ne l'utilise réellement.

Crate ksp-config-lib

La nouvelle crate hérite de la version, de l'édition, du repository et des lints du workspace.

Sa seule dépendance est actuellement :

ksp-core-lib = { path = "../ksp-core-lib" }

Cela respecte la règle d'ajout des dépendances uniquement lorsqu'elles sont réellement utilisées. La direction architecturale future reste ksp-config-lib -> ksp-logging-lib, mais cette dépendance n'est pas ajoutée prématurément dans pre.002.

Bootstrap non récursif

Les défauts KSP sont codés dans Config :

DEFAULT_CFG_PATH    = "config"
DEFAULT_SCHEMA_PATH = "config/schemas"

Ils ne dépendent d'aucun document Config, .env ou variable applicative.

La surface publique introduite est :

ConfigBootstrapOptions::defaults()
ConfigBootstrapOptions::from_paths(...)
ConfigBootstrapOptions::from_args(...)
ConfigBootstrapOptions::cfg_path()
ConfigBootstrapOptions::schema_path()
ConfigBootstrapOptions::with_cfg_path(...)
ConfigBootstrapOptions::with_schema_path(...)

Les arguments possédés par Config sont :

--cfgpath
--schemapath

Le parser accepte les deux formes :

--cfgpath=/path/to/configs
--cfgpath /path/to/configs

--schemapath=/path/to/schemas
--schemapath /path/to/schemas

Les arguments étrangers sont ignorés afin qu'une application puisse transmettre son vecteur d'arguments complet à Config. Si un même path est fourni plusieurs fois, le dernier override explicite gagne.

Les deux roots restent indépendants : remplacer cfgpath ne modifie pas schemapath, et inversement.

Validation des chemins

pre.002 applique seulement les garanties qui sont valides avant la création des premiers documents runtime :

• path vide : refusé ;
• path existant et répertoire : accepté ;
• path existant mais non répertoire : refusé ;
• path inexistant : accepté, car config/ et config/schemas/ ne sont créés que dans une tranche ultérieure ;
• path relatif ou absolu : accepté.

Un argument séparé sans valeur, ou immédiatement suivi d'une autre option --..., produit une erreur dédiée.

Erreurs Config initiales

Les codes restent possédés par ksp-config-lib avec le domaine config :

config.bootstrap_argument_missing_value
config.bootstrap_invalid_path

Ils utilisent les contrats existants de Core :

ksp_core_lib::Error
ksp_core_lib::ErrorCode
ksp_core_lib::Result<T>

Core ne reçoit aucune connaissance métier Config.

Tests ajoutés

Les tests unitaires couvrent notamment :

• les deux défauts hardcodés ;
• l'indépendance des overrides cfg/schema ;
• les formes CLI inline et séparées ;
• la règle du dernier override ;
• l'ignorance des arguments étrangers ;
• l'absence de valeur ;
• le refus d'un path vide ;
• l'acceptation d'un path programmatique inexistant ;
• le refus d'un path existant qui est un fichier.

Les tests d'intégration vérifient la façade publique au crate-root et le parsing consommable par une crate externe.

Version technique

La prerelease devient :

workspace.package.version = "0.1.3-pre.2"

Le manifest racine devient :

# version: 41

Le plan Config devient :

<!-- version: 5 -->

Fichiers ajoutés

crates/ksp-config-lib/Cargo.toml
crates/ksp-config-lib/src/bootstrap.rs
crates/ksp-config-lib/src/error.rs
crates/ksp-config-lib/src/lib.rs
crates/ksp-config-lib/unit_tests/bootstrap.rs
crates/ksp-config-lib/tests/public_api.rs
deltas/0.1.3/pre.002.md

Fichiers modifiés

Cargo.toml
docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md

Fichiers supprimés

Aucun.

Validations non exécutées à faire dans l'environnement utilisateur

cargo fmt --all
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test --workspace
cargo tree -p ksp-config-lib
cargo tree -p ksp-config-lib -d
cargo tree -p ksp-config-lib -e features

Aucun script d'audit Rust/KSP exécutable n'est présent dans la base reconstruite de cette tranche.

L'environnement de génération du delta ne fournit pas cargo, rustc ni rustfmt. Aucune commande Cargo ci-dessus n'est donc déclarée réussie avant la validation dans l'environnement utilisateur.

Validations exécutées avant livraison

Des contrôles statiques ont vérifié avant livraison :

• headers file: / version: présents sur les nouveaux fichiers ;
• aucune ligne Rust supérieure à 160 colonnes avant formatage ;
• aucun unsafe, unwrap, expect, panic! ou opérateur ? dans src/ ;
• aucun use de non-trait ;
• aucune lecture de variable applicative par std::env dans src/ ;
• aucune dépendance externe nouvelle ;
• aucun Cargo.lock ajouté au delta.

Suite après validation

Si pre.002 est validée, la prochaine tranche prévue est :

0.1.3-pre.003 — registre logique file_id -> filename + --filemap

Elle ne doit pas encore lire les documents JSON ou leurs schemas.