v0.1.2-pre.006-fix.001

prompts/003-V0_1_3_START_PROMPT.md

@@ -1,5 +1,5 @@
 <!-- file: prompts/003-V0_1_3_START_PROMPT.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Prompt de démarrage KSP 0.1.3
 
@@ -23,7 +23,9 @@ Release à développer :
 
 ## 2. Mission
 
-Introduire `ksp-config-lib` comme propriétaire des documents de configuration KSP, de leur résolution, de leurs profils, de leur validation et des modifications/persistences explicitement autorisées.
+Introduire `ksp-config-lib` comme propriétaire unique KSP de la configuration applicative : documents de configuration unitaires et composites, résolution des profils, variables d'environnement, validation, lecture et modifications/persistences explicitement autorisées.
+
+Les autres crates et applications KSP ne doivent pas lire, résoudre ou modifier directement les fichiers de configuration ni les variables d'environnement. Elles consomment les contrats de `ksp-config-lib`. Une application dédiée au management de configuration utilise donc Config comme unique frontière, y compris lorsqu'elle doit afficher ou modifier des valeurs sensibles explicitement autorisées.
 
 La première prerelease est obligatoirement une tranche de brainstorming, audit et planification. Ne pas commencer directement par une implémentation large de Config.
 
@@ -54,12 +56,12 @@ Elle doit notamment :
 
 1. auditer l'état réel du workspace stable `0.1.2` ;
 2. réauditer les règles Config déjà présentes dans le dépôt et les archives historiques pertinentes sans les copier aveuglément ;
-3. inventorier les documents de configuration nécessaires à court terme ;
-4. distinguer valeurs globales, valeurs profilées, sélection du profil et composition propre aux exécutables ;
-5. fixer la politique de résolution document -> profil -> env override -> valeur effective ;
+3. inventorier les documents de configuration unitaires nécessaires à court terme et les fichiers composites qui les assemblent pour un exécutable/application ;
+4. distinguer valeurs globales, valeurs profilées, sélection du profil, documents unitaires réutilisables et composition propre aux exécutables ;
+5. fixer la politique de résolution document unitaire -> composition -> profil -> env override -> valeur effective ;
 6. fixer la validation, les diagnostics et les erreurs Core nécessaires ;
 7. fixer les opérations de modification/sauvegarde autorisées et leurs garanties d'atomicité ;
-8. fixer la frontière secrets/public/debug ;
+8. fixer la frontière secrets/public/debug et les droits explicites permettant à une application de management Config d'accéder aux secrets lorsqu'elle doit les consulter ou les modifier ;
 9. définir la relation exacte avec `LoggingSettings` et le hot reload Logging ;
 10. décider si le périmètre Config tient proprement dans une seule release `0.1.3` ou doit être scindé ;
 11. produire `docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md` et le plan souple des prereleases suivantes.
@@ -80,19 +82,30 @@ séparé de la configuration applicative générale.
 
 Le `pre.001` doit inventorier les autres documents réellement nécessaires au premier cycle et éviter de créer prématurément des fichiers pour des composants non développés.
 
-Les schemas doivent être placés sous :
+La structure doit conserver la séparation déjà utile dans khadhroony-bot3 entre **documents unitaires** et **fichiers composites** :
 
-```text
-config/schemas/
-```
+- un document unitaire possède une responsabilité spécialisée et reste réutilisable indépendamment des exécutables ;
+- un fichier composite assemble les documents requis par un exécutable/application et peut sélectionner ou remplacer les profils nécessaires sans dupliquer les documents spécialisés.
 
-et les exemples sous :
+Les vrais fichiers de configuration runtime appartiennent sous :
 
 ```text
 config/
 ```
 
-La structure exacte reste à valider dans le plan Config.
+Les schemas appartiennent sous :
+
+```text
+config/schemas/
+```
+
+Les exemples ne doivent pas être mélangés aux fichiers runtime réels et appartiennent sous :
+
+```text
+config/examples/
+```
+
+Les noms exacts, la nomenclature des fichiers composites et leur format restent à valider dans le plan Config `pre.001`.
 
 ## 6. Valeurs globales et profils
 
@@ -107,7 +120,7 @@ wallets_directory
 
 Le `default_profile` est autonome : il sélectionne un profil par défaut mais ne doit pas être artificiellement imbriqué dans chacun des profils.
 
-Les fichiers de composition propres à un binaire peuvent sélectionner les documents utilisés et remplacer les profils choisis lorsqu'un besoin concret l'exige.
+Les fichiers composites propres à un binaire/application sélectionnent les documents unitaires utilisés et peuvent remplacer les profils choisis lorsqu'un besoin concret l'exige. Cette composition doit rester possédée et résolue par `ksp-config-lib`, pas par chaque exécutable séparément.
 
 ## 7. Variables d'environnement
 
@@ -116,34 +129,38 @@ Toutes les variables d'environnement applicatives doivent être namespacées sel
 Pour les composants génériques KSP / `ksp-*` :
 
 ```text
-KS_*
-KS_PUBLIC_*
-KS_SECRET_*
+KSP_*
+KSP_PUBLIC_*
+KSP_SECRET_*
 ```
 
-Pour les futures applications/composants bot `kb-*` lorsqu'ils existent :
+Pour les futures applications/composants bot du projet :
 
 ```text
-KB_*
-KB_PUBLIC_*
-KB_SECRET_*
+KSPB_*
+KSPB_PUBLIC_*
+KSPB_SECRET_*
 ```
 
+`ksp-config-lib` est le propriétaire unique de la lecture, de la résolution, de la validation et de l'écriture éventuelle des variables d'environnement KSP. Les autres crates/applications ne doivent pas contourner cette frontière par des lectures directes de l'environnement applicatif.
+
 Le `pre.001` doit formaliser précisément la correspondance entre document, clé de configuration et override d'environnement.
 
-Aucune variable sans préfixe propriétaire ne doit être introduite.
+Aucune variable applicative sans préfixe propriétaire ne doit être introduite.
 
 ## 8. Secrets, public et debug
 
-La résolution Config doit distinguer les valeurs exposables de celles qui ne doivent jamais traverser une frontière publique.
+La classification Config doit distinguer les valeurs publiques, ordinaires et secrètes, mais **secret ne signifie pas interdiction absolue de lecture**.
 
-Politique déjà retenue :
+Direction déjà retenue :
 
-- `KS_SECRET_*` / `KB_SECRET_*` : jamais exposés ;
-- `KS_PUBLIC_*` / `KB_PUBLIC_*` : exposables ;
-- autres valeurs : exposition autorisée uniquement dans le contexte debug prévu par les contrats applicatifs.
+- `KSP_SECRET_*` / `KSPB_SECRET_*` : valeurs sensibles, jamais exposées accidentellement dans les logs, diagnostics ordinaires ou surfaces publiques génériques ;
+- `KSP_PUBLIC_*` / `KSPB_PUBLIC_*` : valeurs explicitement exposables ;
+- autres valeurs : politique d'exposition à fixer selon le contrat applicatif et le contexte debug ;
+- les composants runtime qui ont légitimement besoin d'un secret doivent pouvoir l'obtenir via un contrat Config explicite ;
+- une application possédant une fonctionnalité de **management de configuration** doit pouvoir, via une surface Config explicitement prévue et contrôlée, consulter et modifier les secrets nécessaires. Cela couvre notamment la future `ksp-app-config-desk` et, plus tard, la partie Config d'une éventuelle application générale.
 
-La surface Config ne doit pas transformer cette politique en simple convention documentaire : le plan doit préciser où elle est appliquée et testée.
+La surface Config doit donc formaliser une **politique d'accès** aux secrets, et non une règle simpliste « jamais exposé ». Le `pre.001` doit décider les contrats distincts de lecture runtime, consultation de management, mutation et exposition Tauri/DTO afin d'éviter toute fuite implicite tout en permettant l'administration légitime.
 
 Cela ne change pas la responsabilité de Logging concernant le contenu des messages : `ksp-logging-lib` ne scanne ni ne redacte automatiquement les secrets fournis par ses callers.
 
@@ -215,7 +232,7 @@ La validation desktop complète est prévue ensuite, par défaut dans :
 0.1.4 — ksp-app-config-desk
 ```
 
-Les DTO/bindings Tauri n'appartiennent donc pas automatiquement à `ksp-config-lib`. TS-RS reste principalement une frontière des applications Tauri et ne doit être dérivé dans une crate générique que pour un contrat externe réellement générique et indépendant de Tauri.
+Les DTO/bindings Tauri n'appartiennent donc pas automatiquement à `ksp-config-lib`. TS-RS reste principalement une frontière des applications Tauri et ne doit être dérivé dans une crate générique que pour un contrat externe réellement générique et indépendant de Tauri. Une application Config desktop pourra toutefois exposer, par des commandes/DTO applicatifs dédiés, les opérations privilégiées de consultation/modification de secrets que `ksp-config-lib` autorise explicitement ; elle ne doit jamais contourner Config en lisant les fichiers ou l'environnement directement.
 
 ## 13. Règles Rust et Cargo à conserver
 
@@ -343,9 +360,10 @@ Le `pre.001` est terminé lorsque nous savons précisément :
 - quels documents existent dans la première surface Config ;
 - ce qui est global et ce qui est profilé ;
 - comment fonctionne `default_profile` ;
-- comment se résolvent les overrides `KS_*`/`KB_*` ;
-- comment les secrets/public/debug sont classifiés ;
-- quels contrats de lecture/résolution/validation/mutation sont publics ;
+- comment se résolvent les overrides `KSP_*`/`KSPB_*` ;
+- comment documents unitaires et fichiers composites sont séparés puis résolus ;
+- comment les secrets/public/debug sont classifiés et quels contrats autorisent leur lecture/mutation ;
+- quels contrats de lecture/résolution/validation/mutation sont publics ou privilégiés, et comment `ksp-config-lib` reste l'unique manager des fichiers Config et variables d'environnement ;
 - comment Config construit `LoggingSettings` sans dépendance inverse ;
 - quelles dépendances externes sont réellement nécessaires ;
 - si `0.1.3` reste une seule release ou doit être scindée ;