# Delta 0.1.3-pre.002 ## Base requise Livraison documentaire précédente validée : ```text 0.1.3-pre.001-fix.003 ``` La base porte : ```text 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 : ```toml 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 : ```text 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 : ```text 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 : ```text --cfgpath --schemapath ``` Le parser accepte les deux formes : ```text --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` : ```text config.bootstrap_argument_missing_value config.bootstrap_invalid_path ``` Ils utilisent les contrats existants de Core : ```text ksp_core_lib::Error ksp_core_lib::ErrorCode ksp_core_lib::Result ``` 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 : ```text workspace.package.version = "0.1.3-pre.2" ``` Le manifest racine devient : ```text # version: 41 ``` Le plan Config devient : ```text ``` ## Fichiers ajoutés ```text 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 ```text 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 ```bash 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 : ```text 0.1.3-pre.003 — registre logique file_id -> filename + --filemap ``` Elle ne doit pas encore lire les documents JSON ou leurs schemas.