45 lines
2.6 KiB
Markdown
45 lines
2.6 KiB
Markdown
<!-- file: crates/ksp-config-lib/TODO.md -->
|
|
<!-- version: 2 -->
|
|
|
|
# TODO ksp-config-lib
|
|
|
|
## État de clôture `0.1.3`
|
|
|
|
Aucun TODO fonctionnel bloquant n'est ouvert pour la fondation Config `0.1.3`.
|
|
|
|
Les responsabilités prévues pour cette release sont implémentées et couvertes par les tests : bootstrap, registre `file_id`, JSON/JSON Schema, profils, composites, environnement process/`.env`, placeholders, sensibilité/provenance, adapter Logging, management/persistence et audits d'ownership.
|
|
|
|
## Extensions bornées révélées par `0.1.4`
|
|
|
|
`0.1.4-pre.002` ajoute l'inventaire public read-only de `ConfigFileRegistry`, nécessaire au shell Documents de `ksp-app-config-desk`. Le registre reste propriétaire des descripteurs ; l'application n'entretient pas de liste parallèle de `file_id`.
|
|
|
|
La seconde lacune révélée pendant `pre.001` reste à traiter dans la tranche suivante : une API Config bornée permettant de soumettre le source corrigé d'un `file_id` connu, le valider puis le persister atomiquement sans accès filesystem direct de l'application.
|
|
|
|
## Validation desktop de `0.1.4`
|
|
|
|
La validation applicative desktop appartient à `ksp-app-config-desk` :
|
|
|
|
- frontière Tauri et DTO TS-RS applicatifs ;
|
|
- affichage des sources et diagnostics Config ;
|
|
- sélection/inspection des profils ;
|
|
- affichage desired/effective/shadow des variables ;
|
|
- actions explicites de reveal de secrets avec contrôle d'autorisation côté application ;
|
|
- édition/sauvegarde de `std.logging.json` via `ConfigManagement` ;
|
|
- édition de `.env` via `ConfigManagement` ;
|
|
- orchestration réelle `Config -> LoggingSettings -> initialize/reinitialize` avec `LoggingGuard` possédé par l'application ;
|
|
- validation UX des erreurs de source invalide, des modifications non effectives car masquées par le process et des besoins de reload.
|
|
|
|
Ces points ne nécessitent pas de duplication de logique dans `ksp-config-lib`; toute lacune réelle révélée par l'application ouvrira un delta Config explicite.
|
|
|
|
## Futur, uniquement au besoin
|
|
|
|
Les capacités suivantes sont différées jusqu'à l'apparition de composants réels :
|
|
|
|
- nouveaux documents `std.<domain>.json` et schemas associés ;
|
|
- descriptors `cfg.composite.<consumer>` pour de vrais consumers ;
|
|
- contrats typés de management supplémentaires pour les nouveaux documents ;
|
|
- watcher filesystem/reload automatique si une application ou un service démontre le besoin ;
|
|
- intégration éventuelle d'un secrets manager externe.
|
|
|
|
Ne pas introduire par anticipation un JSON patch arbitraire, un watcher générique, un service distribué de configuration ou un chiffrement maison de `.env`.
|