diff --git a/crates/ksp-config-lib/USAGE.md b/crates/ksp-config-lib/USAGE.md index 45c8e22..b0b725d 100644 --- a/crates/ksp-config-lib/USAGE.md +++ b/crates/ksp-config-lib/USAGE.md @@ -1,5 +1,5 @@ - + # 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`. + diff --git a/deltas/0.1.3/pre.015-fix.001.md b/deltas/0.1.3/pre.015-fix.001.md new file mode 100644 index 0000000..0939871 --- /dev/null +++ b/deltas/0.1.3/pre.015-fix.001.md @@ -0,0 +1,93 @@ + + + +# 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 +``` + +`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. diff --git a/docs/rules/FILE_CONTRACTS.md b/docs/rules/FILE_CONTRACTS.md index 7f76c7c..b29aa7a 100644 --- a/docs/rules/FILE_CONTRACTS.md +++ b/docs/rules/FILE_CONTRACTS.md @@ -1,5 +1,5 @@ - + # 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. diff --git a/docs/rules/RULES_KSP.md b/docs/rules/RULES_KSP.md index ac1d5c5..9494387 100644 --- a/docs/rules/RULES_KSP.md +++ b/docs/rules/RULES_KSP.md @@ -1,5 +1,5 @@ - + # 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](...)`, ``, 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 ` 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`. diff --git a/prompts/004-V0_1_4_START_PROMPT.md b/prompts/004-V0_1_4_START_PROMPT.md index f53abc4..7534294 100644 --- a/prompts/004-V0_1_4_START_PROMPT.md +++ b/prompts/004-V0_1_4_START_PROMPT.md @@ -1,5 +1,5 @@ - + # 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 ` 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 ;