v0.1.2-pre.006-fix.001

deltas/0.1.2/pre.006-fix.001.md

@@ -0,0 +1,69 @@
+<!-- file: deltas/0.1.2/pre.006-fix.001.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.2-pre.006-fix.001
+
+## Nature
+
+Correctif **documentaire uniquement** appliqué après validation complète de `0.1.2-pre.006`.
+
+La version Cargo reste :
+
+```text
+workspace.package.version = "0.1.2-pre.6"
+Cargo.toml header version = 38
+```
+
+Aucun fichier Rust, manifest Cargo, dépendance ou comportement runtime n'est modifié.
+
+## Base validée
+
+La validation utilisateur de `pre.006` est propre :
+
+```text
+cargo fmt --all                                                        OK
+cargo check --workspace                                               OK
+cargo build -p ksp-logging-lib                                        OK
+cargo clippy --workspace --all-targets                                OK
+cargo test --workspace                                                OK
+cargo test -p ksp-logging-lib --test overhead -- --ignored --nocapture OK
+cargo tree -p ksp-logging-lib                                         OK
+cargo tree -p ksp-logging-lib -d                                      OK (aucun doublon)
+cargo tree -p ksp-logging-lib -e features                             OK
+cargo tree -p ksp-logging-lib -e normal                               OK (Tokio absent)
+cargo tree -p ksp-logging-lib -e dev                                  OK (Tokio seul dev-dependency)
+```
+
+Les deux tests Tokio réels passent et le build normal de `ksp-logging-lib` confirme que Tokio reste hors du graphe runtime normal.
+
+## Corrections du prompt `0.1.3`
+
+Le prompt Config est corrigé avant `rel.001` afin de ne pas démarrer la session suivante avec d'anciens contrats khadhroony-bot3 devenus incorrects.
+
+Décisions enregistrées :
+
+1. les vrais fichiers de configuration runtime sont sous `config/` ;
+2. les schemas sont sous `config/schemas/` ;
+3. les exemples sont sous `config/examples/`, séparés des fichiers réels ;
+4. la conception doit reprendre un système de **documents unitaires** spécialisés et de **fichiers composites** qui assemblent ces documents pour un exécutable/application et peuvent sélectionner/remplacer les profils ;
+5. `ksp-config-lib` est le propriétaire unique de la lecture, résolution, validation et mutation des fichiers Config ainsi que des variables d'environnement applicatives ; les autres crates/apps passent par ses APIs ;
+6. les namespaces d'environnement deviennent `KSP_*`, `KSP_PUBLIC_*`, `KSP_SECRET_*` pour KSP et `KSPB_*`, `KSPB_PUBLIC_*`, `KSPB_SECRET_*` pour la branche bot ;
+7. les secrets ne suivent plus une règle absolue « jamais exposés » : ils restent protégés contre toute exposition implicite, mais les composants légitimes et les applications de management Config doivent pouvoir les consulter/modifier via des contrats explicitement autorisés ;
+8. `ksp-app-config-desk` est cité comme premier consommateur probable d'une telle surface privilégiée, avant une éventuelle application générale disposant d'une section Config.
+
+Le détail des formats, contrats d'autorisation et découpage fonctionnel reste volontairement à décider lors du brainstorming obligatoire de `0.1.3-pre.001`.
+
+## Fichiers
+
+Modifiés :
+
+- `prompts/003-V0_1_3_START_PROMPT.md` ;
+- `docs/plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md`.
+
+Ajouté :
+
+- `deltas/0.1.2/pre.006-fix.001.md`.
+
+## Suite
+
+Après application de ce correctif documentaire, `0.1.2-pre.006` reste la dernière prerelease fonctionnelle validée. La prochaine livraison est `0.1.2-rel.001` avec passage à la version stable `0.1.2` et validations finales de publication.

docs/plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md

@@ -1,11 +1,11 @@
 <!-- file: docs/plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md -->
-<!-- version: 14 -->
+<!-- version: 15 -->
 
 # Plan KSP 0.1.2 — Logging foundation
 
 ## Statut
 
-Plan actif de `0.1.2`, établi par `0.1.2-pre.001`, corrigé par `0.1.2-pre.001-fix.001`, concrétisé par la façade de `0.1.2-pre.002`, étendu au runtime subscriber par `0.1.2-pre.003`/`pre.003-fix.001`, puis complété et corrigé par `pre.004`/`pre.004-fix.001..004`. `pre.005` a fermé la phase d'intégration/robustesse : saturation déterministe, concurrence pendant hot reload, audit de takeover, validation des spans de timing, documentation de crate et probe d'overhead grossier. `pre.005-fix.001` a supprimé la pollution console du stress test concurrent sans réduire la pression de reload. `pre.006` est la prerelease finale : elle ajoute une validation async sur executor Tokio réel uniquement en dev-dependency, consolide la documentation durable et prépare le prompt `0.1.3 — ksp-config-lib`.
+Plan actif de `0.1.2`, établi par `0.1.2-pre.001`, corrigé par `0.1.2-pre.001-fix.001`, concrétisé par la façade de `0.1.2-pre.002`, étendu au runtime subscriber par `0.1.2-pre.003`/`pre.003-fix.001`, puis complété et corrigé par `pre.004`/`pre.004-fix.001..004`. `pre.005` a fermé la phase d'intégration/robustesse : saturation déterministe, concurrence pendant hot reload, audit de takeover, validation des spans de timing, documentation de crate et probe d'overhead grossier. `pre.005-fix.001` a supprimé la pollution console du stress test concurrent sans réduire la pression de reload. `pre.006` est la prerelease finale : elle ajoute une validation async sur executor Tokio réel uniquement en dev-dependency, consolide la documentation durable et prépare le prompt `0.1.3 — ksp-config-lib`. Les validations utilisateur de `pre.006` sont propres, y compris le build normal de `ksp-logging-lib`, les deux tests Tokio, le probe d'overhead et les graphes Cargo confirmant que Tokio est uniquement une dev-dependency. `pre.006-fix.001` corrige ensuite uniquement le prompt Config : vrais fichiers sous `config/`, exemples sous `config/examples/`, namespaces `KSP_*`/`KSPB_*`, documents unitaires + composites, ownership exclusif de Config sur fichiers/env et accès explicite aux secrets pour les surfaces de management autorisées.
 
 `pre.003-fix.001` a été validé dans l'environnement de développement avec `cargo fmt --all`, `cargo check --workspace`, `cargo clippy --workspace --all-targets` et `cargo test --workspace` propres sur la version Cargo `0.1.2-pre.3.fix.1`. `pre.004` ajoute `tracing-appender`, remplace la console synchrone par un writer non bloquant, introduit le fichier `Never/Hourly/Daily`, possède les `WorkerGuard`, expose des compteurs cumulés de dropped lines, déporte le stripping ANSI côté worker fichier et conserve le hot reload transactionnel des sinks. `pre.004-fix.001` a rendu explicite le retrait des anciens layers avant leurs `WorkerGuard`, mais la validation utilisateur après `cargo clean` a reproduit exactement le même échec du marqueur fichier. Cette seconde validation a invalidé l'hypothèse selon laquelle ce défaut précis provenait du drain. La cause réelle est la sanitization ANSI native de `tracing-subscriber 0.3.23`, activée par défaut dans `fmt::Layer` : elle transforme les séquences de contrôle présentes dans les valeurs avant qu'elles n'atteignent le writer. `pre.004-fix.002` la conserve pour la console mais la désactive sur le formatter fichier afin que le `StripAnsiWriter` KSP, placé côté worker, reçoive les séquences ANSI originales et les supprime réellement. Le lifecycle explicite de `fix.001` est conservé car il reste correct pour le retrait des sinks non bloquants. La validation de `pre.004-fix.002` confirme ensuite que l'écriture fichier et le stripping ANSI fonctionnent, mais révèle que le target externe `sqlx` est encore persisté. La cause est la composition du filtre global comme enfant frère des formatters dans un `Vec<Layer>` : le `Vec` agrège l'intérêt de callsite en conservant l'intérêt le plus élevé de ses enfants, de sorte qu'un formatter intéressé peut masquer le `Interest::never()` du `Targets`. `pre.004-fix.003` compose donc `Targets` devant le `Vec` des sinks avec `Layer::and_then`; le filtre redevient global pour tout le groupe de sorties sans utiliser `with_filter`/`Filtered`. La validation de `pre.004-fix.003` confirme que tous les tests workspace passent, y compris le takeover externe et le fichier non bloquant, mais `cargo clippy --workspace --all-targets` signale encore `vec_init_then_push` dans la construction du composite reloadable. `pre.004-fix.004` applique uniquement cette correction de forme sans modifier le comportement runtime. La validation utilisateur finale de `pre.004-fix.004` sur `0.1.2-pre.4.fix.4` confirme `cargo fmt --all`, `cargo check --workspace`, `cargo clippy --workspace --all-targets` et `cargo test --workspace` propres ; le test runtime global passe avec takeover, fichier non bloquant, stripping ANSI et hot reload. Le graphe Cargo exécuté durant `pre.004` ne présentait aucun doublon et aucune activation KSP de `tracing-attributes`, `tracing-log`, `env-filter`, JSON/Serde ou ANSI formatter ; les dépendances n'ayant pas changé depuis, `pre.005` doit néanmoins refaire ces commandes avant validation de tranche.
 
@@ -1035,6 +1035,33 @@ cargo tree -p ksp-logging-lib -e dev
 
 Le contrôle spécifique de cette tranche est que Tokio soit visible dans le graphe dev des tests mais absent du graphe normal de `ksp-logging-lib`.
 
+Validation utilisateur finale de `pre.006` :
+
+```text
+cargo fmt --all                                                        OK
+cargo check --workspace                                               OK
+cargo build -p ksp-logging-lib                                        OK
+cargo clippy --workspace --all-targets                                OK
+cargo test --workspace                                                OK
+cargo test -p ksp-logging-lib --test overhead -- --ignored --nocapture OK
+cargo tree -p ksp-logging-lib                                         OK
+cargo tree -p ksp-logging-lib -d                                      OK (aucun doublon)
+cargo tree -p ksp-logging-lib -e features                             OK
+cargo tree -p ksp-logging-lib -e normal                               OK (Tokio absent)
+cargo tree -p ksp-logging-lib -e dev                                  OK (Tokio seul dev-dependency)
+```
+
+Le probe observé sur cette validation donne `baseline=16.959425ms`, `reload=24.942444ms` sur 200000 itérations et passe son garde-fou grossier. Les tests Tokio `current_thread` et `multi_thread` passent tous deux.
+
+`pre.006-fix.001` est documentaire uniquement et ne change pas la version Cargo `0.1.2-pre.6`. Il corrige le prompt `0.1.3` avec les décisions de clôture suivantes :
+
+- les fichiers runtime réels appartiennent sous `config/` ;
+- les exemples appartiennent sous `config/examples/` et les schemas sous `config/schemas/` ;
+- les namespaces d'environnement deviennent `KSP_*` pour KSP et `KSPB_*` pour la branche bot ;
+- Config doit reprendre le modèle documents unitaires + fichiers composites déjà utilisé dans khadhroony-bot3 ;
+- `ksp-config-lib` est la seule frontière qui lit/résout/modifie les fichiers Config et les variables d'environnement applicatives ;
+- les secrets sont protégés contre l'exposition implicite mais peuvent être consultés/modifiés via des contrats privilégiés explicites, notamment pour une application de management Config.
+
 Le découpage reste souple. Une tranche trop large est scindée ; une tranche devenue inutile est supprimée par correction explicite du plan.
 
 ## Hors scope confirmé

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 ;
+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 et composition propre aux exécutables ;
+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 -> profil -> env override -> valeur effective ;
+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
+- un document unitaire possède une responsabilité spécialisée et reste réutilisable indépendamment des exécutables ;
-config/schemas/
+- 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_*
+KSP_*
-KS_PUBLIC_*
+KSP_PUBLIC_*
-KS_SECRET_*
+KSP_SECRET_*
 ```
 
-Pour les futures applications/composants bot `kb-*` lorsqu'ils existent :
+Pour les futures applications/composants bot du projet :
 
 ```text
-KB_*
+KSPB_*
-KB_PUBLIC_*
+KSPB_PUBLIC_*
-KB_SECRET_*
+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 ;
+- `KSP_SECRET_*` / `KSPB_SECRET_*` : valeurs sensibles, jamais exposées accidentellement dans les logs, diagnostics ordinaires ou surfaces publiques génériques ;
-- `KS_PUBLIC_*` / `KB_PUBLIC_*` : exposables ;
+- `KSP_PUBLIC_*` / `KSPB_PUBLIC_*` : valeurs explicitement exposables ;
-- autres valeurs : exposition autorisée uniquement dans le contexte debug prévu par les contrats applicatifs.
+- 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 se résolvent les overrides `KSP_*`/`KSPB_*` ;
-- comment les secrets/public/debug sont classifiés ;
+- comment documents unitaires et fichiers composites sont séparés puis résolus ;
-- quels contrats de lecture/résolution/validation/mutation sont publics ;
+- 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 ;