59 lines
4.5 KiB
Markdown
59 lines
4.5 KiB
Markdown
<!-- file: crates/ksp-config-lib/TODO.md -->
|
||
<!-- version: 6 -->
|
||
|
||
# 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.
|
||
|
||
## Extension `0.2.1` — Transport HTTP
|
||
|
||
`0.2.1-pre.006` introduit le premier nouveau domaine standard depuis Logging : `std.transport.json`, son schema, son exemple, son enregistrement et l'adapter Config -> `HttpTransportSettings`. Cette extension confirme que les nouveaux domaines restent ajoutés à la demande d'un consumer réel, sans transformer Config en propriétaire du runtime Transport.
|
||
|
||
## Extension `0.2.6` — Wallet Desk
|
||
|
||
`0.2.6-pre.003` ajoute le domaine standard Wallet au moment où son premier consumer réel en a besoin : `cfg.std.wallet`, `schema.std.wallet`, `ResolvedWalletConfig` et le composite concret `cfg.composite.ksp-app-wallet-desk`. `wallets_directory` reste global ; `wallets_subdirectory` est optionnel par profil et ne peut pas sortir de la racine par syntaxe de path. L’adapter Config résout les paths et leur provenance mais ne crée pas de répertoire et ne dépend pas de `ksp-wallet-lib`.
|
||
|
||
Le même delta ajoute les entrées `resolve_*_config_profile` nécessaires pour mapper un profil Logging/Wallet déjà sélectionné par un composite sans perdre sa provenance `Composite`. La préparation filesystem du répertoire effectif appartient à `ksp-app-wallet-desk`.
|
||
|
||
Les passwords `KSP_SECRET_WALLET_PASS_*` restent hors du JSON `std.wallet` et sont désormais consommés par Wallet Desk comme candidats explicitement sélectionnés ; Config reste leur propriétaire process/`.env` et ne projette jamais leur valeur vers le frontend.
|
||
|
||
`0.2.6-pre.018` ajoute également le contrat de runtime packagé : Config prépare une racine KSP user-writable à partir des resources Tauri, seed les documents Config uniquement lorsqu'ils sont absents, resynchronise les schemas et n'embarque jamais `.env`. Cette capacité reste possédée par Config et partagée par les applications desk.
|
||
|
||
## Futur, uniquement au besoin
|
||
|
||
Les capacités suivantes sont différées jusqu'à l'apparition de composants réels :
|
||
|
||
- documents `std.<domain>.json` supplémentaires 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`.
|