khadhroony-solana-project/crates/ksp-config-lib/TODO.md

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.

0.1.4-pre.003 ferme la seconde lacune révélée pendant pre.001 : ConfigManagement::save_source_candidate() permet de soumettre le texte corrigé d'un file_id Config connu, de le parser et de le valider entièrement, puis de le persister atomiquement sans accès filesystem direct de l'application. Les deux extensions Config préalables au shell desktop sont donc traitées.

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.