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

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

Base requise

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 :

0.1.4-pre.1

à :

0.1.4-pre.2

L'identifiant de livraison est :

0.1.4-pre.002

1. API publique du registre

ConfigFileRegistry expose désormais :

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 :

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 :

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

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 :

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.