v0.1.3-pre.015-fix.001

2026-08-16 07:54:49 +02:00
parent 64136c99ad
commit ee8fdedf86
5 changed files with 298 additions and 12 deletions
--- a/crates/ksp-config-lib/USAGE.md
+++ b/crates/ksp-config-lib/USAGE.md
@@ -1,5 +1,5 @@
 <!-- file: crates/ksp-config-lib/USAGE.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->

 # Utilisation de ksp-config-lib

@@ -182,3 +182,106 @@ Toute nouvelle variable runtime concrète `KSP_*` / `KSPB_*` introduite dans le
 Une application Tauri doit appeler les APIs ci-dessus via ses commandes/DTO applicatifs. Elle ne lit ni JSON ni `.env` directement et ne résout jamais elle-même les placeholders.

 Les valeurs `Secret` ne doivent pas être incluses par défaut dans les DTO publics. Une action UI explicitement autorisée peut appeler une méthode `reveal_*` et transporter le résultat par un DTO spécifique, sans log ni diagnostic contenant la valeur réelle.
+
+## 10. Index de la surface publique
+
+Ce guide reste volontairement indépendant des numéros de release. Les contrats publics sont regroupés ci-dessous par usage ; les constantes de noms/erreurs accompagnent les mêmes familles et ne constituent pas des workflows séparés.
+
+| Famille publique       | Contrats principaux                                                                                                                                    | Exemple                  |
+|------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------|
+| Bootstrap              | `ConfigBootstrapOptions`, `ARG_CFG_PATH`, `ARG_SCHEMA_PATH`, `DEFAULT_CFG_PATH`, `DEFAULT_SCHEMA_PATH`                                                 | §1                       |
+| Registre logique       | `ConfigFileRegistry`, `ConfigFileId`, `ConfigFileDescriptor`, `ConfigFileKind`, `ARG_FILE_MAP`, constantes `FILE_ID_*` / `DEFAULT_*_FILENAME`          | §1–2                     |
+| Documents              | `ConfigDocumentEngine`, `ConfigJsonDocument`                                                                                                           | §2                       |
+| Profils                | `ResolvedConfigProfile`, `ConfigProfileSelectionSource`, `ConfigValueOrigin`                                                                           | §5                       |
+| Composites             | `ResolvedConfigComposite`, `ResolvedCompositeComponent`                                                                                                | §5                       |
+| Environnement          | `ConfigEnvironment`, `ConfigEnvironmentSource`, `ConfigEnvironmentValue`, `DEFAULT_DOTENV_PATH`, `DEFAULT_DOTENV_EXAMPLE_PATH`                         | §3, §7–8                 |
+| Sensibilité/provenance | `ConfigSensitivity`, `ConfigValueProvenance`, `ResolvedConfigText`, `ResolvedConfigJson`, `REDACTED_CONFIG_VALUE`                                      | §3                       |
+| Logging effectif       | `ResolvedLoggingConfig`                                                                                                                                | §4                       |
+| Management             | `ConfigManagement`, `ConfigManagedSource`, `ConfigDocumentChangeReport`, `ConfigEnvironmentReport`, `ConfigEnvironmentChangeReport`                    | §6–7                     |
+| Source Logging typée   | `LoggingConfigDocument`, `LoggingProfileConfig`, `LoggingConsoleConfig`, `LoggingFileConfig`, `LoggingOutputFilterConfig`, `LoggingTargetFilterConfig` | §6 et exemple ci-dessous |
+| Erreurs Config         | constantes `ERROR_CODE_*` réexportées par la crate                                                                                                     | exemple ci-dessous       |
+
+### 10.1 Modifier une configuration Logging typée
+
+Les getters permettent d'inspecter la source ; les setters et vues `*_mut()` permettent de construire un candidat avant validation/persistence :
+
+```rust
+let mut document = match management.load_logging_document() {
+    std::result::Result::Ok(value) => value,
+    std::result::Result::Err(error) => return std::result::Result::Err(error),
+};
+
+document.set_logs_directory("${KSP_LOGS_DIRECTORY:-logs}");
+
+if let std::option::Option::Some(profile) = document.profiles_mut().first_mut() {
+    profile.set_default_filter("debug");
+    profile.console_mut().set_enabled(true);
+    profile.console_mut().filter_mut().set_level("info");
+    profile.console_mut().filter_mut().domains_mut().push("config".to_owned());
+}
+
+let saved = match management.save_logging_document(&document) {
+    std::result::Result::Ok(value) => value,
+    std::result::Result::Err(error) => return std::result::Result::Err(error),
+};
+
+if saved.source_changed() && saved.reload_required() {
+    // The application decides when/how to reload the affected runtime consumer.
+}
+```
+
+La construction depuis zéro utilise les constructeurs publics `LoggingConfigDocument::new`, `LoggingProfileConfig::new`, `LoggingConsoleConfig::new`, `LoggingFileConfig::new`, `LoggingOutputFilterConfig::new` et `LoggingTargetFilterConfig::new`. Les mêmes contraintes schema/sémantiques sont appliquées au moment de `save_logging_document()`.
+
+### 10.2 Inspecter un source enregistré sans contourner Config
+
+```rust
+let source = match management.read_source(&file_id) {
+    std::result::Result::Ok(value) => value,
+    std::result::Result::Err(error) => return std::result::Result::Err(error),
+};
+
+let logical_id = source.file_id();
+let managed_path = source.path();
+let raw_content = source.content();
+```
+
+Cette API est notamment destinée à une UI de réparation lorsque le document n'est plus validable. Elle n'autorise pas la lecture d'un chemin arbitraire.
+
+### 10.3 Exploiter les rapports `.env`
+
+```rust
+let reports = match management.environment_report() {
+    std::result::Result::Ok(value) => value,
+    std::result::Result::Err(error) => return std::result::Result::Err(error),
+};
+
+for report in reports {
+    let name = report.variable_name();
+    let sensitivity = report.sensitivity();
+    let desired = report.desired_safe_value();
+    let effective = report.effective_safe_value();
+    let source = report.effective_source();
+    let shadowed = report.shadowed_by_process_environment();
+    let _ = (name, sensitivity, desired, effective, source, shadowed);
+}
+```
+
+Après une mutation, `ConfigEnvironmentChangeReport` expose `source_changed()`, `effective_changed()`, `shadowed_by_process_environment()` et `reload_required()`.
+
+### 10.4 Distinguer un code d'erreur Config
+
+Les codes publics permettent à une UI/service de brancher sa logique sans parser le texte du message :
+
+```rust
+let loaded = engine.load_validated_document(&file_id);
+
+if let std::result::Result::Err(error) = loaded {
+    if error.code() == ksp_config_lib::ERROR_CODE_SCHEMA_VALIDATION_FAILED {
+        // Present a schema-specific diagnostic path to the caller.
+    }
+    return std::result::Result::Err(error);
+}
+```
+
+Le message/context d'erreur reste destiné au diagnostic ; l'identité machine-readable passe par `ErrorCode`.
+
--- a/deltas/0.1.3/pre.015-fix.001.md
+++ b/deltas/0.1.3/pre.015-fix.001.md
@@ -0,0 +1,93 @@
+<!-- file: deltas/0.1.3/pre.015-fix.001.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.3-pre.015-fix.001 — règles de validation, documentation et gabarit Tauri
+
+## Base requise
+
+```text
+0.1.3-pre.015
+workspace.package.version = "0.1.3-pre.15"
+```
+
+Ce correctif est exclusivement documentaire. Il ne modifie aucun fichier Rust, manifest Cargo, fichier Config runtime, schema ou variable d'environnement. Conformément à la règle de version technique, `workspace.package.version` reste `0.1.3-pre.15`.
+
+## Objet
+
+Le correctif fige les conventions demandées avant `rel.001` et avant l'ouverture de `0.1.4 — ksp-app-config-desk`.
+
+### Validation Cargo
+
+Après toute modification d'un fichier Rust, une tranche doit exécuter :
+
+```bash
+cargo fmt --all
+cargo check --workspace
+cargo clippy --workspace --all-targets
+```
+
+Pendant le développement courant, les tests privilégient la crate concernée :
+
+```bash
+cargo test -p <crate>
+```
+
+`cargo test --workspace` est conservé pour les ouvertures/fermetures de session ou de version et les contrôles globaux justifiés. Les audits `cargo tree` pertinents restent exécutés pour les crates travaillées/complétées.
+
+### Documentation de fin de crate/application
+
+Une crate/composant complété possède un `README.md`. Une bibliothèque complétée possède un `USAGE.md` durable, sans notes de version, centré sur sa surface publique et fournissant des exemples d'utilisation des APIs publiques directement consommables. Une application Tauri complétée possède un `USAGE.md` décrivant ses fenêtres et leur utilisation.
+
+`crates/ksp-config-lib/USAGE.md` est renforcé immédiatement pour servir de premier exemple de cette convention.
+
+### Gabarit Tauri de référence
+
+`ksp-app-config-desk` doit servir de modèle aux futures applications Tauri KSP et réutiliser/refondre les acquis utiles de khadhroony-bot3 : SASS/SCSS, packages frontend, gabarit et icône, Vite/TypeScript, package Rust `lib` + `bin` aux noms distincts, launcher `main.rs` minimal, `lib.rs` déclaratif, `tauri.rs` propriétaire de `run` et des wrappers `#[tauri::command]`, modules de fenêtres `tw_*`, helpers communs, single-instance et splashscreen factorisé.
+
+La temporisation du splashscreen est pilotée par Config/.env. Le nom de la variable sera choisi quand l'implémentation en aura réellement besoin puis ajouté dans le même delta à `.env.example` avec commentaire.
+
+Le prompt corrige aussi le layout applicatif : la crate est `crates/ksp-app-config-desk`, pas `apps/ksp-app-config-desk`.
+
+### `PRESENTATION.md`
+
+Le `README.md` d'une application Tauri n'est jamais utilisé comme contenu de présentation embarqué. Si une application possède une vue de présentation Markdown, elle utilise `PRESENTATION.md`; `markdown-it` reste le renderer de référence hérité de bot3 lorsque ce besoin existe et sa version doit être vérifiée avant ajout.
+
+`PRESENTATION.md` ne contient aucun lien navigable Markdown/HTML susceptible de casser la navigation ou le lifecycle des fenêtres Tauri. Une application monofenêtre sans présentation ne crée pas ce fichier et n'ajoute pas `markdown-it` uniquement par symétrie.
+
+## Fichiers modifiés
+
+```text
+docs/rules/RULES_KSP.md
+docs/rules/FILE_CONTRACTS.md
+prompts/004-V0_1_4_START_PROMPT.md
+crates/ksp-config-lib/USAGE.md
+```
+
+## Fichier ajouté
+
+```text
+deltas/0.1.3/pre.015-fix.001.md
+```
+
+## Version Cargo
+
+Aucune modification :
+
+```text
+workspace.package.version = "0.1.3-pre.15"
+```
+
+Le fix ne touche aucun artefact participant au code/build/runtime/config/migrations.
+
+## Validation du correctif
+
+Le correctif documentaire est contrôlé par :
+
+- headers `file:` / `version:` ;
+- cohérence des références `crates/ksp-app-config-desk` ;
+- absence de modification Rust/Cargo/config ;
+- absence de nouvelle variable runtime ou modification `.env.example` ;
+- équilibre des fences Markdown ;
+- archive limitée aux cinq fichiers ci-dessus.
+
+Aucune commande Cargo n'est requise spécifiquement pour ce fix documentaire. La validation globale de fermeture de `pre.015` reste cependant celle prévue avant `rel.001`, incluant `cargo test --workspace` parce que la version est en clôture.
--- a/docs/rules/FILE_CONTRACTS.md
+++ b/docs/rules/FILE_CONTRACTS.md
@@ -1,5 +1,5 @@
 <!-- file: docs/rules/FILE_CONTRACTS.md -->
-<!-- version: 14 -->
+<!-- version: 15 -->

 # Contrats des fichiers

@@ -86,3 +86,23 @@ Pour un document standard profilé, `default_profile` et `profiles` sont des cl
 - **FILE-GEN-001** — Un fichier généré n'est jamais modifié manuellement lorsque sa source de vérité est un générateur.
 - **FILE-GEN-002** — Le choix de versionner ou ignorer une famille générée est décidé explicitement lorsqu'elle apparaît.
 - **FILE-GEN-003** — Les futurs artefacts Tauri `bindings/` et `gen/` ne sont pas encore une convention KSP ; ils seront traités lorsqu'ils apparaîtront.
+
+## Documentation durable des crates et applications
+
+Une crate ou un composant considéré comme complété possède un `README.md` descriptif durable.
+
+Une bibliothèque complétée possède également un `USAGE.md` sans notes de version. Ce guide privilégie la surface publique et fournit un exemple d'utilisation pour chaque API publique destinée à être consommée directement ; plusieurs APIs étroitement liées peuvent être démontrées dans le même exemple lorsque le flux réel les compose. Les notes de release restent dans `CHANGELOG.md` et les deltas.
+
+Une application Tauri complétée possède un `USAGE.md` orienté opérateur décrivant les fenêtres, leurs rôles, les actions disponibles et les flux usuels.
+
+Le `README.md` d'une application Tauri n'est jamais chargé comme contenu de présentation de l'interface. Si l'application possède une vue/fenêtre de présentation Markdown, elle utilise un fichier dédié :
+
+```text
+PRESENTATION.md
+```
+
+Ce fichier est optionnel. Une application monofenêtre sans présentation ne le crée pas. Lorsqu'il existe :
+
+- il est destiné au renderer Markdown embarqué de l'application (`markdown-it` est la référence historique KSP lorsqu'un renderer est nécessaire) ;
+- il ne contient aucun lien navigable Markdown ou HTML susceptible de provoquer une navigation hors du flux Tauri ;
+- il reste distinct du `README.md` de package et du `USAGE.md` opérateur.
--- a/docs/rules/RULES_KSP.md
+++ b/docs/rules/RULES_KSP.md
@@ -1,5 +1,5 @@
 <!-- file: docs/rules/RULES_KSP.md -->
-<!-- version: 19 -->
+<!-- version: 21 -->

 # Règles spécifiques à KSP

@@ -200,6 +200,17 @@
 - **KSP-APP-005** — Les applications spécialisées précèdent toute future application globale ; aucune app globale n'est un livrable actuel.
 - **KSP-APP-006** — Une app manager worker utilise le control plane et ne modifie pas directement l'état interne de processing du worker en base.
 - **KSP-APP-007** — Une future application globale est conservée comme idée produit et sera cadrée seulement après validation suffisante des apps spécialisées/demos.
+- **KSP-APP-008** — `ksp-app-config-desk` est l'application desktop de référence destinée à établir le gabarit des futures applications Tauri KSP. Les applications suivantes réutilisent ce gabarit sauf justification explicite documentée.
+- **KSP-APP-009** — Le gabarit desktop KSP réutilise/refond les éléments éprouvés de khadhroony-bot3 : organisation SASS/SCSS, dépendances frontend utiles, gabarit visuel initial, icône de base et fichiers de build TypeScript/Vite similaires. Cette référence est auditée et adaptée ; elle n'est pas copiée aveuglément.
+- **KSP-APP-010** — Une application Tauri KSP est un package Rust mixte avec cible bibliothèque et cible binaire de noms distincts. Le binaire reste un launcher mince.
+- **KSP-APP-011** — `main.rs` d'une application Tauri appelle essentiellement la fonction publique `run` de la bibliothèque applicative ; il porte uniquement le bootstrap strictement exécutable, notamment le verrou single-instance et les arguments CLI lorsqu'ils sont nécessaires.
+- **KSP-APP-012** — `lib.rs` d'une application Tauri reste un point de déclaration de modules et de réexport des fonctions/contrats nécessaires ; la logique des fenêtres et opérations n'y est pas accumulée.
+- **KSP-APP-013** — `tauri.rs` possède la fonction `run`, les wrappers `#[tauri::command]` vers les fonctions déclarées dans leurs modules, ainsi que les helpers Tauri/démarrage communs lorsqu'ils sont réellement partagés (`init_rustls`, `open_or_focus_window`, etc.). Les annotations `#[tauri::command]` ne sont pas dispersées dans les modules métier/fenêtre.
+- **KSP-APP-014** — Les modules propres à une fenêtre Tauri utilisent le préfixe `tw_` (`Tauri window`) sauf convention équivalente explicitement décidée avant implémentation. Les helpers réutilisables entre fenêtres sont regroupés dans des modules communs au lieu d'être dupliqués.
+- **KSP-APP-015** — Toutes les applications Tauri KSP réutilisent un splashscreen commun et son lifecycle de démarrage. Les paramètres de temporisation du splashscreen sont configurables via Config/.env, jamais codés en dur dans chaque application.
+- **KSP-APP-016** — Toute variable d'environnement introduite pour le splashscreen ou une autre capacité desktop respecte les namespaces KSP/KSPB et est ajoutée à `.env.example`, avec commentaire, dans le même delta que sa première utilisation runtime conformément à `KSP-CONFIG-005/006`.
+- **KSP-APP-017** — Le `README.md` d'une application Tauri documente le package et ne sert jamais de source Markdown chargée dans une fenêtre de présentation. Lorsqu'une application affiche une présentation embarquée, le contenu UI appartient à un fichier dédié `PRESENTATION.md`; `markdown-it` est la référence de rendu issue de khadhroony-bot3 lorsque ce besoin existe et sa version est auditée avant ajout.
+- **KSP-APP-018** — `PRESENTATION.md` est optionnel : une application monofenêtre qui ne possède aucune vue de présentation n'en crée pas. Lorsqu'il existe, il contient du contenu Markdown statique destiné à l'UI et aucun lien navigable Markdown ou HTML (`[texte](...)`, `<a ...>`, URL brute destinée à la navigation) susceptible de détourner ou casser le comportement des fenêtres Tauri.

 ## Data plane / control plane

@@ -219,3 +230,10 @@
 - **KSP-REL-006** — Une release ou prerelease trop grosse est scindée plutôt que compressée pour respecter un numéro prévu.
 - **KSP-REL-007** — La dernière prerelease d'une release fonctionnelle réalise par défaut validations finales, documentation, nettoyage/archivage, changelog et prompt de la release suivante.
 - **KSP-REL-008** — La première release fonctionnelle sélectionnée est `0.1.1`, dédiée à la stabilisation de `ksp-core-lib`.
+- **KSP-REL-009** — Après toute modification d'un fichier Rust, la tranche concernée exécute avant livraison au minimum `cargo fmt --all`, `cargo check --workspace` et `cargo clippy --workspace --all-targets`. Une commande non exécutée n'est jamais déclarée réussie.
+- **KSP-REL-010** — Pendant le développement courant d'une crate, les tests Rust privilégient la portée ciblée `cargo test -p <crate>` et, si utile, ses tests d'intégration nommés. `cargo test --workspace` est conservé pour l'ouverture ou la fermeture d'une session/version et pour les validations globales explicitement justifiées.
+- **KSP-REL-011** — Les validations d'une crate incluent les audits `cargo tree` pertinents pour son graphe réel : arbre normal, doublons et features lorsque ces vues apportent une information utile. Les crates fondamentales/complétées conservent leurs canaries de dépendances.
+- **KSP-REL-012** — Toute crate ou composant KSP considéré comme complété possède un `README.md` descriptif durable avant clôture de sa release.
+- **KSP-REL-013** — Toute bibliothèque KSP considérée comme complétée possède un `USAGE.md` durable, sans notes de version, présentant sa surface publique et un exemple d'utilisation pour chaque API publique destinée à être consommée directement ; plusieurs APIs étroitement liées peuvent partager un même exemple lorsque leur usage réel est composé. Les changements de release appartiennent au changelog/delta, pas au guide d'utilisation.
+- **KSP-REL-014** — Toute application/binaire Tauri KSP considéré comme complété possède un `USAGE.md` durable décrivant ses fenêtres, leurs objectifs, leurs flux principaux et leur utilisation opérateur.
+- **KSP-REL-015** — Une application Tauri complétée ne crée `PRESENTATION.md` que si elle possède réellement une vue de présentation embarquée ; dans ce cas le fichier est finalisé comme contenu UI sans liens navigables et reste distinct du `README.md` et du `USAGE.md`.
--- a/prompts/004-V0_1_4_START_PROMPT.md
+++ b/prompts/004-V0_1_4_START_PROMPT.md
@@ -1,5 +1,5 @@
 <!-- file: prompts/004-V0_1_4_START_PROMPT.md -->
-<!-- version: 1 -->
+<!-- version: 3 -->

 # Prompt de démarrage `0.1.4` — ksp-app-config-desk

@@ -99,7 +99,13 @@ L'application est une composition/interface. Elle ne devient pas propriétaire :
 - du mapping Logging ;
 - de la persistence Config.

-La structure sous `apps/` et l'intégration au workspace doivent être confirmées dans le plan `pre.001` à partir des règles KSP actives et des contraintes Tauri actuelles.
+La crate applicative est placée directement sous :
+
+```text
+crates/ksp-app-config-desk
+```
+
+conformément au layout KSP. Son intégration au workspace et l'organisation interne frontend/Tauri doivent être confirmées dans le plan `pre.001` à partir des règles KSP actives et des contraintes Tauri actuelles.

 ## 5. Capacités desktop à valider

@@ -159,6 +165,42 @@ Conserver les règles KSP déjà retenues :

 Le `pre.001` doit vérifier les versions actuelles de Tauri et des dépendances frontend réellement nécessaires avant leur ajout. Les dépendances communes sont déclarées au niveau workspace lorsqu'elles sont partagées ; aucune dépendance n'est ajoutée sans usage immédiat.

+### 6.1 Gabarit Tauri de référence à établir
+
+`ksp-app-config-desk` doit servir de **modèle de référence** pour les futures applications Tauri KSP. `pre.001` doit auditer la base khadhroony-bot3 puis décider précisément ce qui est réutilisé/refondu, notamment :
+
+- organisation SASS/SCSS et dépendances frontend/package utiles ;
+- même gabarit visuel initial à affiner et même icône de base tant qu'aucune identité graphique KSP plus spécifique n'est décidée ;
+- `vite.config.ts`, `tsconfig.json` et fichiers frontend/build équivalents structurés de manière cohérente avec le modèle éprouvé ;
+- package Rust mixte `lib` + `bin`, avec noms de cibles distincts ;
+- `main.rs` minimal : verrou single-instance, parsing/bootstrap des éventuels arguments CLI nécessaires, puis appel de la fonction `run` exposée par la bibliothèque applicative ;
+- `lib.rs` limité aux déclarations de modules et réexports nécessaires ;
+- `tauri.rs` propriétaire de `run`, des wrappers `#[tauri::command]` et des helpers Tauri/démarrage partagés (`init_rustls`, `open_or_focus_window`, etc.) ;
+- fonctions métier/fenêtre implémentées dans leurs modules puis appelées par les wrappers de `tauri.rs` ; aucune annotation `#[tauri::command]` dispersée hors de cette frontière ;
+- modules spécifiques aux fenêtres nommés `tw_*` (`Tauri window`) sauf meilleure convention explicitement décidée pendant `pre.001` ;
+- helpers communs regroupés dans des modules partagés et non copiés entre fenêtres.
+
+Cette réutilisation de bot3 est une référence de conception : le `pre.001` doit vérifier ce qui reste pertinent avec les versions Tauri/Vite/TypeScript actuelles avant intégration.
+
+### 6.2 Splashscreen commun
+
+Le splashscreen et ses fonctionnalités doivent devenir une capacité commune aux applications Tauri KSP :
+
+- même lifecycle de splashscreen réutilisable ;
+- comportement configurable plutôt que recopié par application ;
+- durée/temporisation configurée via Config/.env ;
+- le nom exact de la ou des variables est décidé au moment où le besoin runtime est implémenté, en respectant `KSP_*`/`KSP_PUBLIC_*` selon l'exposition nécessaire ;
+- toute nouvelle clé est ajoutée à `.env.example` avec commentaire **dans le même delta que sa première utilisation** ;
+- aucune temporisation sensible à l'environnement n'est codée en dur dans chaque application.
+
+### 6.3 Documentation affichée dans l'UI
+
+Ne jamais charger `README.md` comme contenu d'une fenêtre Tauri. Le README reste la documentation du package.
+
+Si `ksp-app-config-desk` retient une vue/fenêtre de présentation, créer un `PRESENTATION.md` dédié et utiliser `markdown-it` comme renderer de référence, après vérification de la version réellement actuelle/compatible avant ajout de la dépendance. `PRESENTATION.md` ne contient aucun lien navigable Markdown ou HTML susceptible de modifier la navigation de la webview ou d'ouvrir/casser une fenêtre.
+
+Si l'application finale est monofenêtre et n'affiche aucune présentation, ne pas créer `PRESENTATION.md` et ne pas ajouter `markdown-it` uniquement par symétrie avec bot3.
+
 ## 7. Sécurité et redaction

 Le desktop Config est une application de management privilégiée, mais cela ne supprime pas les frontières de sécurité :
@@ -190,6 +232,10 @@ Conserver notamment :
 - versions caret de génération compatibles ;
 - aucun `Cargo.lock`/lockfile frontend versionné selon la politique KSP actuelle ;
 - chaque delta `0.1.x` est commité ; un défaut livré est corrigé par un `fix`, jamais réécrit silencieusement.
+- après toute modification Rust : `cargo fmt --all`, `cargo check --workspace` et `cargo clippy --workspace --all-targets` sont obligatoires avant livraison ;
+- pendant une tranche de développement, préférer `cargo test -p <crate>` pour la crate travaillée ; réserver `cargo test --workspace` aux ouvertures/fermetures de session/version et aux contrôles globaux justifiés ;
+- exécuter les `cargo tree` pertinents pour les crates modifiées/complétées ;
+- toute crate complétée possède un `README.md`; une bibliothèque complétée possède un `USAGE.md` version-neutral centré sur l'API publique avec exemples ; une application Tauri complétée possède un `USAGE.md` décrivant ses fenêtres et leur utilisation.

 ## 9. Hors scope par défaut de `0.1.4`

@@ -218,16 +264,20 @@ Il doit produire au minimum :

 1. audit exact de la base stable `v0.1.3` ;
 2. audit des règles Tauri/app existantes ;
-3. choix du layout `apps/ksp-app-config-desk` et de son intégration workspace ;
+3. choix du layout interne de `crates/ksp-app-config-desk` et de son intégration workspace ;
 4. matrice commandes Tauri / services internes / APIs Config appelées ;
 5. matrice DTO ordinaires / DTO secrets privilégiés ;
 6. modèle d'état applicatif et ownership de `LoggingGuard` ;
 7. écrans/panneaux minimums et flux utilisateur ;
-8. stratégie de tests Rust, Tauri et frontend ;
-9. dépendances externes réellement nécessaires et versions actuelles vérifiées ;
-10. hors-scope confirmés ;
-11. prévision souple des prereleases, chaque tranche visant environ 15–20 minutes de travail effectif ;
-12. critères de validation de la release.
+8. stratégie de tests Rust, Tauri et frontend, avec tests ciblés par package pendant le développement et `cargo test --workspace` aux frontières globales ;
+9. audit du gabarit bot3 à réutiliser/refondre : SASS/SCSS, packages, Vite/TypeScript, icône, layout frontend et splashscreen ;
+10. contrat exact `lib` + `bin`, `main.rs`, `lib.rs`, `tauri.rs`, modules `tw_*`, helpers communs et single-instance ;
+11. stratégie de splashscreen commun et choix futur de la/des variable(s) Config/.env avec mise à jour obligatoire de `.env.example` lors de leur première utilisation ;
+12. dépendances externes réellement nécessaires et versions actuelles vérifiées ;
+13. hors-scope confirmés ;
+14. prévision souple des prereleases, chaque tranche visant environ 15–20 minutes de travail effectif ;
+15. décision explicite sur la présence d'une vue de présentation : `PRESENTATION.md` + `markdown-it` si elle existe, aucun fichier/dépendance de présentation si elle n'existe pas ;
+16. critères de validation de la release et documentation finale `README.md` / `USAGE.md` / `PRESENTATION.md` conditionnel.

 Ne commencer `pre.002` qu'après validation de ce plan.

@@ -235,8 +285,10 @@ Ne commencer `pre.002` qu'après validation de ce plan.

 La dernière prerelease de `0.1.4` devra comme d'habitude :

- exécuter les validations finales ;
+- exécuter les validations finales, dont `cargo test --workspace` puisque la release se ferme ;
 - consolider la documentation ;
+- finaliser le `README.md` de l'application et son `USAGE.md` décrivant chaque fenêtre et son utilisation ;
+- finaliser `PRESENTATION.md` uniquement si l'application possède réellement une vue de présentation, et vérifier l'absence de liens navigables Markdown/HTML ;
 - fermer/report explicitement les TODO ;
 - nettoyer/archiver ce qui doit l'être ;
 - synchroniser le changelog général lors de la publication stable ;