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

<!-- file: deltas/0.1.4/pre.002.md -->
<!-- version: 1 -->

# Delta 0.1.4-pre.002 — inventaire public du registre Config

## Base requise

```text
0.1.4-pre.001-fix.003
workspace.package.version = "0.1.4-pre.1"
```

Le plan `docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md` est considéré comme validé dans sa révision issue de `pre.001-fix.003`.

## Objectif

Traiter la première lacune `ksp-config-lib` identifiée par `pre.001` avant la construction du shell desktop : permettre à un consumer de management d'inventorier les fichiers enregistrés dans `ConfigFileRegistry` sans maintenir une liste parallèle de `file_id` et sans obtenir de capacité de mutation supplémentaire.

Cette tranche reste volontairement limitée à l'inventaire public du registre. La soumission/réparation d'un source candidat invalide reste réservée à `pre.003`.

## Version Cargo

Conformément à `VER-ID-009`, `workspace.package.version` passe de :

```text
0.1.4-pre.1
```

à :

```text
0.1.4-pre.2
```

L'identifiant de livraison est :

```text
0.1.4-pre.002
```

## 1. API publique du registre

`ConfigFileRegistry` expose désormais :

```rust
pub fn descriptors(&self) -> impl std::iter::Iterator<Item = &ConfigFileDescriptor> + '_
```

Le contrat est volontairement read-only :

- aucun descripteur n'est copié dans une seconde structure propriétaire ;
- aucune mutation du registre n'est exposée ;
- l'itération reflète les éventuels overrides de filename déjà appliqués ;
- `file_id`, `kind` et association de schema restent ceux du descripteur enregistré ;
- l'ordre est déterministe et correspond à l'ordre logique des `ConfigFileId` porté par le `BTreeMap` interne.

Avec le registre par défaut actuel, l'ordre est :

```text
cfg.std.logging
schema.composite
schema.std.logging
```

L'API ne crée pas de DTO applicatif. `ksp-app-config-desk` pourra convertir ces descripteurs vers ses propres DTO Tauri dans sa frontière applicative.

## 2. Tests unitaires

`unit_tests/registry.rs` couvre maintenant explicitement :

- l'inventaire complet du registre par défaut ;
- l'ordre déterministe par `file_id` ;
- le `ConfigFileKind` de chaque famille ;
- l'association `cfg.std.logging -> schema.std.logging` ;
- la conservation de ces métadonnées après un override de filename ;
- la visibilité du filename effectivement overridé depuis l'inventaire.

Les tests existants de lookup, résolution de path, validation des mappings, doublons et associations de schema restent inchangés dans leur responsabilité.

## 3. Test de surface publique

`tests/public_api.rs` vérifie que le consumer externe peut appeler `ConfigFileRegistry::descriptors()` depuis la racine de crate et exploiter les `ConfigFileDescriptor` publics sans accès à une API interne.

Le test couvre l'ordre et les métadonnées nécessaires au futur panneau Documents de Config Desk.

## 4. Documentation Config

`README.md` précise maintenant que le registre possède un inventaire public read-only ordonné par `file_id`.

`USAGE.md` ajoute un exemple version-neutral montrant comment parcourir :

- `file_id` ;
- `kind` ;
- filename courant ;
- schema associé éventuel.

`TODO.md` distingue désormais les deux lacunes révélées par `0.1.4` :

- inventaire public du registre : **traité par `pre.002`** ;
- réparation/persistence d'un source candidat par `file_id` connu : **reste à traiter dans `pre.003`**.

## 5. Ownership et extensibilité

Cette tranche conserve les frontières décidées :

```text
ConfigFileRegistry
    -> possède les descripteurs connus
    -> expose leur inventaire read-only

ksp-app-config-desk
    -> consommera l'inventaire
    -> construira ses DTO applicatifs
    -> ne maintiendra pas de liste parallèle de file_id
```

L'ajout futur d'un nouveau descripteur au registre le rendra donc automatiquement découvrable par le shell de management, indépendamment de la présence ou non d'un éditeur spécialisé pour ce `file_id`.

## Hors scope confirmé

Cette tranche n'ajoute pas :

- `ksp-app-config-desk` ;
- Tauri ou dépendance frontend ;
- DTO TS-RS ;
- API de modification arbitraire du registre ;
- API de réparation/persistence de source candidat ;
- nouveau document Config ou nouveau schema ;
- variable `.env` ;
- modification du runtime Logging.

## Fichiers ajoutés

```text
deltas/0.1.4/pre.002.md
```

## Fichiers modifiés

| Fichier                                        | Version précédente | Nouvelle version |
|------------------------------------------------|-------------------:|-----------------:|
| `Cargo.toml`                                   |                 62 |               63 |
| `crates/ksp-config-lib/src/registry.rs`        |                  3 |                4 |
| `crates/ksp-config-lib/unit_tests/registry.rs` |                  3 |                4 |
| `crates/ksp-config-lib/tests/public_api.rs`    |                 10 |               11 |
| `crates/ksp-config-lib/README.md`              |                  1 |                2 |
| `crates/ksp-config-lib/USAGE.md`               |                  2 |                3 |
| `crates/ksp-config-lib/TODO.md`                |                  1 |                2 |

## Fichiers supprimés

Aucun.

## Validations exécutées

Dans l'environnement de préparation disponible :

- contrôle statique du diff borné à l'inventaire du registre ;
- vérification de `workspace.package.version = "0.1.4-pre.2"` ;
- vérification des headers `file:` / `version:` des fichiers modifiés ;
- vérification de l'absence de `?`, `unwrap`, `expect`, `panic` et `unsafe` dans le nouveau code Rust ;
- vérification des lignes Rust modifiées vis-à-vis de la limite KSP de 160 colonnes ;
- vérification de la documentation publique de `ConfigFileRegistry::descriptors()` ;
- vérification que les tests couvrent ordre, kind, schema et override ;
- vérification syntaxique TOML du `Cargo.toml` avec le parseur disponible ;
- contrôle des fences Markdown et des espaces de fin de ligne dans les fichiers livrés.

## Validations non exécutées

Le sandbox de préparation ne fournit pas les binaires Rust/Cargo. Les validations obligatoires suivantes ne peuvent donc pas être exécutées ici :

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

Elles doivent être exécutées sur le workspace de développement après application du delta et avant validation/commit de `pre.002`.

`cargo test --workspace` n'est pas requis pour cette tranche ciblée selon le plan de `0.1.4`; il reste réservé aux frontières globales justifiées et à la clôture de la release.

## Décisions prises

- l'inventaire reste une vue du registre existant, pas une collection dupliquée ;
- l'ordre public est déterministe par `file_id` ;
- les overrides restent visibles sans altérer l'identité logique et les associations de schema ;
- aucun DTO Config spécifique au desktop n'entre dans `ksp-config-lib` ;
- `pre.003` reste la tranche dédiée à la réparation validée/persistée d'un source candidat.

## Questions ouvertes

Aucune question bloquante pour `pre.002`.