# Delta 0.1.4-pre.001-fix.002 — panneau `.env` et validation complète de l'environnement Config ## Base requise ```text 0.1.4-pre.001-fix.001 workspace.package.version = "0.1.4-pre.1" ``` Ce second correctif reste exclusivement documentaire. Il complète le plan de `pre.001` avant son approbation définitive et n'ouvre pas `pre.002`. Les deltas historiques : ```text deltas/0.1.4/pre.001.md deltas/0.1.4/pre.001-fix.001.md ``` restent inchangés. Le présent fix porte uniquement la correction supplémentaire demandée après validation partielle du plan. ## Objet `ksp-app-config-desk` doit servir de banc de validation réel de `ksp-config-lib`. Le plan couvrait déjà les rapports d'environnement et les mutations `.env`, mais ne les formulait pas encore comme un **panneau fonctionnel de test/management `.env`** avec une matrice de validation explicite. Le correctif rend donc obligatoire un panneau `Environnement / .env` capable de démontrer depuis l'UI : - les rapports `desired` / `effective` / source / shadowing ; - la classification `Public` / `Internal` / `Secret` et les safe values ; - la création et la modification d'une entrée `.env` via `ConfigManagement::set_dotenv_value()` ; - la suppression via `ConfigManagement::remove_dotenv_value()` ; - le retour `source_changed` / `effective_changed` / `shadowed_by_process_environment` / `reload_required` ; - le rechargement d'un rapport frais après mutation ; - la priorité `process > .env > fallback` avec un cas de shadowing observable ; - l'impossibilité pour l'application de modifier l'environnement déjà hérité du processus parent ; - la propagation d'une mutation `.env` vers une nouvelle résolution Config dépendante d'un placeholder ; - les frontières de reveal Secret déjà prévues, sans préchargement automatique d'une ancienne valeur Secret réelle dans l'éditeur. Aucun accès direct au fichier `.env` n'est ajouté à l'application. ## Cas de validation Config existant Le plan utilise un cas déjà présent dans la base stable, sans inventer de nouveau document Config : ```text config/std.logging.json logs_directory = "${KSP_LOGS_DIRECTORY:-logs}" ``` Le panneau doit permettre de modifier `KSP_LOGS_DIRECTORY` via Config puis de demander une nouvelle résolution du document/profil Logging. Deux résultats doivent être démontrables : 1. sans valeur process prioritaire, la nouvelle valeur `.env` devient effective et la provenance/résolution change ; 2. avec une valeur process prioritaire, la valeur `.env` désirée change mais la résolution effective reste celle du process et l'UI signale le shadowing. Ce second cas est reproductible en lançant l'application avec `KSP_LOGS_DIRECTORY=`, puis en modifiant la même variable dans `.env` depuis l'UI. Le frontend ne résout jamais `${KSP_LOGS_DIRECTORY:-logs}` lui-même : l'autorité reste `ksp-config-lib`. ## UX du panneau `.env` Le panneau est composé d'au moins : ```text Rapport - variable - sensibilité - desired_safe_value - effective_safe_value - source effective - shadowed Éditeur/test - variable existante ou nouveau nom KSP_*/KSPB_* - nouvelle valeur - Créer/Modifier - Supprimer - Recharger Résultat de mutation - source_changed - effective_changed - shadowed_by_process_environment - reload_required ``` Pour un `Secret` : - le champ de saisie est traité comme sensible ; - l'ancienne valeur réelle n'est pas chargée automatiquement ; - une nouvelle valeur peut être saisie explicitement pour remplacement ; - la consultation d'une valeur existante utilise uniquement la commande/DTO privilégié de reveal ; - aucune valeur réelle ne rejoint logs, diagnostics, snapshot ou état persistant. ## Frontière Tauri/Config Le flux reste : ```text UI -> commande Tauri centralisée dans tauri.rs -> environment_service -> ConfigManagement -> set_dotenv_value/remove_dotenv_value/environment_report ``` La crate applicative ne : - lit pas `.env` avec `std::fs` ; - n'écrit pas `.env` avec `std::fs` ; - ne parse pas le format dotenv comme autorité ; - ne lit pas `std::env::var*` pour KSP/KSPB ; - ne simule pas elle-même la priorité process/`.env`/fallback. ## Découpage souple mis à jour Le budget cible reste **environ 15–20 minutes de travail effectif par prerelease**. Pour éviter une tranche Environnement trop large, elle est scindée en deux : ```text pre.011 Environnement — rapports - desired/effective/source/shadow - sensibilité + safe values - table issue uniquement de Config - refresh/reload pre.012 Environnement — management/test .env - create/update - remove - résultat de mutation - cas process > .env - cas placeholder KSP_LOGS_DIRECTORY pre.013 Secrets privilégiés ... pre.017 panneau Test Logging pre.018 robustesse/extensibilité/tests desktop pre.019 clôture candidate ``` `pre.019` n'est pas un numéro de clôture contractuel. Les tranches restent scindables, fusionnables ou réordonnables selon la durée réelle et les dépendances rencontrées. ## Critères de clôture ajoutés La release ne pourra pas être fermée sans démonstration depuis `ksp-app-config-desk` de : - création d'une entrée `.env` ; - modification d'une entrée `.env` ; - suppression d'une entrée `.env` ; - rapport frais après chaque mutation ; - distinction desired/effective ; - source process ou `.env` ; - shadowing réel ; - comportement `source_changed` / `effective_changed` / `reload_required` ; - résolution Config affectée par `KSP_LOGS_DIRECTORY` lorsque la valeur n'est pas shadowée ; - absence de résolution frontend des placeholders ; - traitement sûr des variables `Secret`. Cette matrice complète la matrice Logging déjà renforcée par `pre.001-fix.001`. ## Fichier modifié ```text docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md ``` Le header du plan passe de `version: 2` à `version: 3`. ## Fichier ajouté ```text deltas/0.1.4/pre.001-fix.002.md ``` ## Version Cargo Aucune modification de `Cargo.toml`. Le correctif est documentaire uniquement ; `workspace.package.version` reste : ```text 0.1.4-pre.1 ``` L'identifiant de livraison est : ```text 0.1.4-pre.001-fix.002 ``` ## Validations du correctif À contrôler avant livraison : - header `file:` / `version:` des deux fichiers ; - plan en `version: 3` ; - absence de modification de `Cargo.toml` ; - absence de modification des deltas `pre.001` et `pre.001-fix.001` ; - présence explicite du panneau `Environnement / .env` ; - présence des quatre indicateurs du `ConfigEnvironmentChangeReport` ; - create/update/remove uniquement via `ConfigManagement` ; - cas de shadowing process > `.env` ; - cas de résolution `${KSP_LOGS_DIRECTORY:-logs}` ; - aucune lecture/écriture `.env` directe attribuée à l'application ; - découpage Environnement sur deux prereleases d'environ 15–20 minutes ; - critères de clôture `.env` explicites ; - équilibre des fences Markdown ; - archive limitée au plan modifié et au nouveau delta. Aucune commande Cargo n'est requise spécifiquement pour ce correctif documentaire. Les validations Cargo globales restent celles prévues au passage effectif vers les tranches de développement et à la clôture de la release.