<!-- file: deltas/0.1.3/pre.008.md -->
<!-- version: 1 -->

# Delta 0.1.3-pre.008

## Base requise

Livraison précédente validée :

```text
0.1.3-pre.007
```

Version technique de cette base :

```text
workspace.package.version = "0.1.3-pre.7"
Cargo.toml header version = 48
```

Validations utilisateur exécutées le 2026-08-15 :

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

`cargo tree -p ksp-config-lib -d` ne signale qu'une coexistence transitive `syn 2.0.119` / `syn 3.0.3`, portée par l'écosystème `jsonschema`/ICU/proc-macros. Le graphe observé ne contient pas de stack HTTP/TLS de résolution distante avec `jsonschema default-features = false`; aucun changement de dépendance n'est donc justifié dans cette tranche.

## Objet de pre.008

Fermer la résolution des paramètres globaux, profils et `default_profile` avant d'introduire les composites :

```text
validated standard document
    -> validate profile identities/default_profile
    -> select default or explicit profile
    -> retain globals
    -> retain selected profile
    -> build effective top-level view
    -> preserve Global/Profile provenance
```

Cette tranche reste générique : le moteur de profils n'est pas un type Logging. `std.logging.json` est uniquement le premier document standard qui l'exerce.

## Contrat générique des profils

Un document standard profilé possède deux clés structurelles réservées :

```text
default_profile
profiles
```

Toutes les autres propriétés top-level sont considérées comme des paramètres globaux du document.

Garanties désormais validées après JSON Schema :

- `profiles` contient au moins un objet ;
- chaque profil possède un `profile_id` non vide ;
- les `profile_id` sont uniques dans le document ;
- `default_profile` est autonome au niveau global ;
- `default_profile` référence obligatoirement un `profile_id` existant.

Un document qui viole ces invariants retourne :

```text
config.document_semantic_invalid
```

## Résolution publique

`ConfigDocumentEngine` expose maintenant :

```text
load_resolved_profile(file_id, None)
    -> sélectionne default_profile

load_resolved_profile(file_id, Some(profile_id))
    -> sélection explicite
```

Un profil explicitement demandé mais absent retourne un diagnostic distinct :

```text
config.profile_not_found
```

Cette erreur ne signifie pas que le document source est invalide : le document peut être parfaitement valide tout en ne contenant pas le profil demandé par le caller.

## `ResolvedConfigProfile`

La nouvelle surface publique conserve :

```text
file_id
source path
profile_id sélectionné
selection_source = DefaultProfile | Explicit
globals
profile
effective
origin(key) = Global | Profile
```

`globals` exclut volontairement :

```text
default_profile
profiles
```

`profile` conserve l'objet du profil sélectionné, y compris son `profile_id`.

`effective` est une vue top-level déterministe :

1. insertion des globals ;
2. insertion des propriétés du profil sélectionné.

Si un futur schema permet une même clé aux deux niveaux, la valeur du profil est prioritaire et sa provenance devient `Profile`. Les schemas spécialisés restent libres d'interdire ce cas lorsqu'une propriété doit rester strictement globale.

La provenance documentaire commune reste disponible par :

```text
file_id
path
```

et la provenance de chaque valeur top-level par :

```text
ConfigValueOrigin::Global
ConfigValueOrigin::Profile
```

Les futures couches composite/env/sensibilité devront enrichir cette provenance sans la perdre.

## `std.logging.json`

Le fichier runtime et son schema ne nécessitent aucun changement dans cette tranche.

Le document commité :

```text
default_profile = local_dev
```

résout maintenant réellement le profil `local_dev`.

Exemples de provenance :

```text
logs_directory -> Global
default_filter  -> Profile
```

Le placeholder :

```text
${KSP_LOGS_DIRECTORY:-logs}
```

reste non interprété en `pre.008`; il sera résolu par la tranche environnement prévue plus tard.

## Tests

Les tests ajoutés couvrent :

- résolution du `default_profile` commité ;
- sélection explicite d'un profil existant ;
- distinction `DefaultProfile` / `Explicit` ;
- conservation séparée des globals et du profil ;
- construction de la vue effective ;
- provenance `Global` / `Profile` ;
- profil explicite inconnu -> `config.profile_not_found` ;
- `profile_id` dupliqués -> document sémantiquement invalide ;
- `default_profile` ne référençant aucun profil -> document sémantiquement invalide ;
- consommation de la nouvelle surface depuis le crate-root dans le test d'intégration public.

## Hors scope

Cette tranche n'introduit pas encore :

- document composite ;
- `schema.composite` ;
- override de profil depuis un composite ;
- `.env` ;
- lecture `std::env` applicative ;
- interpolation `${...}` ;
- `Public/Internal/Secret` ;
- redaction ;
- adaptation vers `ksp_logging_lib::LoggingSettings` ;
- mutation/persistence.

## Dépendances

Aucune dépendance externe ou feature Cargo supplémentaire n'est ajoutée.

`ksp-config-lib` ne dépend toujours pas de `ksp-logging-lib` dans cette tranche.

## Version technique

La prerelease devient :

```text
workspace.package.version = "0.1.3-pre.8"
Cargo.toml header version = 49
```

## Fichiers ajoutés

```text
crates/ksp-config-lib/src/profile.rs
crates/ksp-config-lib/unit_tests/profile.rs
deltas/0.1.3/pre.008.md
```

## Fichiers modifiés

```text
Cargo.toml
crates/ksp-config-lib/src/document.rs
crates/ksp-config-lib/src/error.rs
crates/ksp-config-lib/src/lib.rs
crates/ksp-config-lib/tests/public_api.rs
crates/ksp-config-lib/unit_tests/document.rs
docs/plans/000-README.md
docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md
docs/rules/FILE_CONTRACTS.md
```

## Fichiers supprimés

Aucun.

## Contrôles exécutés dans l'environnement de génération

- comparaison du delta avec la base `pre.007` ;
- contrôle des headers/version modifiés ;
- contrôle de l'absence de nouvelle dépendance Cargo ;
- contrôle statique des interdictions `unsafe`, `unwrap`, `expect`, opérateur `?` dans les nouveaux sources de production ;
- contrôle de la composition exacte de l'archive delta ;
- réapplication du delta sur une copie de `pre.007` pour vérifier la reproduction de l'arbre livré.

`cargo`, `rustc` et `rustfmt` ne sont pas disponibles dans l'environnement de génération. Aucune validation Rust n'est déclarée réussie ici.

## Validations utilisateur à exécuter

```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
```

Après validation de `pre.008`, la prochaine tranche planifiée est :

```text
0.1.3-pre.009 — compositions génériques par file_id
```