v0.1.3-pre.015

2026-08-16 07:52:59 +02:00
parent 92982667ac
commit 64136c99ad
14 changed files with 876 additions and 25 deletions
--- a/prompts/000-README.md
+++ b/prompts/000-README.md
@@ -1,5 +1,5 @@
 <!-- file: prompts/000-README.md -->
-<!-- version: 5 -->
+<!-- version: 6 -->

 # Prompts KSP

@@ -23,4 +23,5 @@ Le prompt générique `0.1.x` a été affiné pendant `0.0.3` puis remplacé par

 - [`001-V0_1_1_START_PROMPT.md`](001-V0_1_1_START_PROMPT.md) — prompt historique ouvrant la première release fonctionnelle `0.1.1` après publication stable de `0.0.3` ;
 - [`002-V0_1_2_START_PROMPT.md`](002-V0_1_2_START_PROMPT.md) — prompt final destiné à ouvrir `0.1.2 — Logging foundation` après publication stable de `0.1.1`.
- [`003-V0_1_3_START_PROMPT.md`](003-V0_1_3_START_PROMPT.md) — prompt final destiné à ouvrir `0.1.3 — Configuration foundation` après publication stable de `0.1.2`.
+- [`003-V0_1_3_START_PROMPT.md`](003-V0_1_3_START_PROMPT.md) — prompt historique destiné à ouvrir `0.1.3 — Configuration foundation` après publication stable de `0.1.2` ;
+- [`004-V0_1_4_START_PROMPT.md`](004-V0_1_4_START_PROMPT.md) — prompt final destiné à ouvrir `0.1.4 — ksp-app-config-desk` après publication stable de `0.1.3`.
--- a/prompts/004-V0_1_4_START_PROMPT.md
+++ b/prompts/004-V0_1_4_START_PROMPT.md
@@ -0,0 +1,244 @@
+<!-- file: prompts/004-V0_1_4_START_PROMPT.md -->
+<!-- version: 1 -->
+
+# Prompt de démarrage `0.1.4` — ksp-app-config-desk
+
+## 1. Mission
+
+Ouvrir `0.1.4` uniquement après publication et tag validés de `v0.1.3`.
+
+La mission de cette release est d'introduire `ksp-app-config-desk`, première application desktop spécialisée KSP, afin de valider réellement `ksp-config-lib` et la frontière Tauri sans déplacer la logique Config dans l'application.
+
+La **première prerelease `0.1.4-pre.001` doit être consacrée au brainstorming, à l'audit et au plan détaillé**. Ne pas commencer directement par une implémentation Tauri dispersée. Le `pre.001` doit décider les écrans, commandes, DTO, lifecycle Logging, risques secrets, packaging et découpage des prereleases avant le développement fonctionnel.
+
+## 2. Base requise
+
+Base stable attendue :
+
+```text
+v0.1.3
+workspace.package.version = "0.1.3"
+```
+
+Le workspace doit contenir au minimum :
+
+```text
+crates/ksp-core-lib
+crates/ksp-logging-lib
+crates/ksp-config-lib
+config/std.logging.json
+config/schemas/std.logging.schema.json
+config/schemas/composite.schema.json
+config/examples/std.logging.example.json
+config/examples/composite.example.json
+.env.example
+```
+
+Avant toute modification, relire :
+
+```text
+README.md
+RULES.md
+ROADMAP.md
+CHANGELOG.md
+docs/000-README.md
+docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
+docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md
+crates/ksp-config-lib/README.md
+crates/ksp-config-lib/USAGE.md
+crates/ksp-config-lib/TODO.md
+crates/ksp-logging-lib/README.md
+crates/ksp-logging-lib/USAGE.md
+```
+
+Relire également les règles Tauri/Rust/documentation avant de choisir la structure finale de l'application.
+
+## 3. Surface Config stable à réutiliser
+
+`ksp-config-lib 0.1.3` possède déjà :
+
+- `ConfigBootstrapOptions` et les arguments `--cfgpath` / `--schemapath` ;
+- `ConfigFileRegistry`, `ConfigFileId` et `--filemap` ;
+- `ConfigDocumentEngine` ;
+- validation JSON/JSON Schema et invariants sémantiques ;
+- globals, profils, `default_profile` et provenance ;
+- composites génériques par `file_id` ;
+- `ConfigEnvironment` avec priorité process > `.env` > fallback ;
+- `${NAME}` / `${NAME:-fallback}` ;
+- `Public` / `Internal` / `Secret`, real/safe/provenance ;
+- `ResolvedLoggingConfig` et le mapping vers `ksp_logging_lib::LoggingSettings` ;
+- `ConfigManagement` ;
+- lecture source brute d'un `file_id` connu ;
+- `LoggingConfigDocument` et ses sous-contrats typés mutables ;
+- persistence atomique de `std.logging.json` ;
+- rapports d'environnement desired/effective/shadow ;
+- `reveal_effective_environment_value()` / `reveal_dotenv_value()` comme frontières explicites d'accès au réel ;
+- `set_dotenv_value()` / `remove_dotenv_value()` ;
+- audits workspace de non-contournement Config et couverture `.env.example`.
+
+L'application doit **consommer ces APIs**, pas reproduire leur comportement.
+
+## 4. Architecture cible à auditer pendant `pre.001`
+
+Direction attendue :
+
+```text
+ksp-app-config-desk
+    -> ksp-config-lib
+    -> ksp-logging-lib
+    -> ksp-core-lib via les contrats KSP nécessaires
+```
+
+L'application est une composition/interface. Elle ne devient pas propriétaire :
+
+- du parsing JSON ;
+- des schemas ;
+- de `.env` ;
+- des placeholders ;
+- de la classification des secrets ;
+- 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.
+
+## 5. Capacités desktop à valider
+
+Le brainstorming `pre.001` doit au minimum cadrer une UI permettant de tester réellement :
+
+### Documents et diagnostics
+
+- afficher les documents Config enregistrés par `file_id` ;
+- afficher le source brut lorsqu'un document est invalide afin de permettre sa réparation ;
+- distinguer erreurs JSON, schema, sémantiques et erreurs de configuration effective ;
+- ne jamais demander à l'UI de reconstruire elle-même les validations.
+
+### Profils
+
+- afficher `default_profile` ;
+- lister les profils disponibles ;
+- sélectionner explicitement un profil pour inspection/résolution ;
+- montrer distinctement source/global/profile/effective lorsque cela est utile à l'opérateur.
+
+### Environnement
+
+- afficher les variables KSP/KSPB via les rapports Config ;
+- distinguer desired `.env`, effective, source process/`.env` et shadowing ;
+- ne montrer par défaut que `safe_value` ;
+- créer/modifier/supprimer une entrée `.env` uniquement via `ConfigManagement` ;
+- signaler clairement qu'une valeur process peut masquer une modification `.env` et qu'un process parent ne peut pas être modifié par l'application.
+
+### Secrets
+
+- aucune valeur `Secret` réelle dans un DTO général, un log, un diagnostic ou un état UI persistant par défaut ;
+- une action utilisateur explicitement privilégiée peut appeler une méthode `reveal_*` ;
+- l'authentification/autorisation de cette action appartient à l'application, pas à `ksp-config-lib` ;
+- le `pre.001` doit décider le contrat UX/DTO précis de reveal sans journaliser le secret.
+
+### Logging
+
+- charger `std.logging.json` via Config ;
+- éditer ses profils/sinks via les types de management Config ;
+- sauvegarder via `save_logging_document()` ;
+- construire la configuration effective via `load_resolved_logging_config()` ;
+- initialiser/reconfigurer `ksp-logging-lib` ;
+- conserver `LoggingGuard` dans l'état applicatif/orchestration approprié ;
+- vérifier qu'une erreur de nouvelle configuration ne détruit pas le runtime Logging déjà valide.
+
+## 6. Frontière Tauri
+
+Conserver les règles KSP déjà retenues :
+
+- TS-RS principalement à la frontière de l'application ;
+- les DTO Tauri appartiennent à `ksp-app-config-desk`, pas à `ksp-config-lib`, sauf contrat externe générique explicitement justifié ;
+- le `pre.001` doit décider et formaliser l’emplacement exact des `#[tauri::command]`; conserver comme direction héritée un adapter Tauri centralisé plutôt que des annotations dispersées ;
+- pas de `?`, `unwrap`, `expect` ou `panic` dans les commandes ;
+- l'application reste mince et appelle des fonctions/services internes qui réutilisent les crates KSP ;
+- aucune dépendance directe aux crates `tracing*` dans l'application : Logging reste la façade ;
+- aucune lecture directe `std::env::var*` pour `KSP_*` / `KSPB_*` ;
+- aucune lecture/écriture directe des fichiers physiques Config/`.env`.
+
+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.
+
+## 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é :
+
+- les secrets ne sont jamais loggés ;
+- `Debug`/diagnostics utilisent les vues sûres ;
+- les APIs `reveal_*` sont appelées uniquement pour une intention explicite ;
+- les DTO de reveal sont séparés des DTO ordinaires ;
+- l'application doit éviter de conserver inutilement les secrets en mémoire/état UI ;
+- une capture d'erreur ne doit pas recopier une valeur réelle dans son message/context ;
+- le fichier `.env` reste non versionné ; `.env.example` reste l'inventaire versionné.
+
+## 8. Règles Rust et projet à conserver
+
+Conserver notamment :
+
+- Rust 2024 ;
+- `unsafe` interdit ;
+- pas de `unwrap`, `expect`, `panic` dans le code production ;
+- pas d'opérateur `?` ;
+- retours explicites selon Clippy workspace ;
+- pas de `mod.rs` ;
+- pas de `pub(super)` / `pub(in ...)` ;
+- code/Rustdoc en anglais ;
+- Markdown projet en français ;
+- tests unitaires hors `src` avec structure miroir ;
+- tests publics dans `tests/` ;
+- dépendances externes communes sous `[workspace.dependencies]` puis `.workspace = true` ;
+- 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.
+
+## 9. Hors scope par défaut de `0.1.4`
+
+Ne pas ouvrir automatiquement :
+
+- Wallet ;
+- Store/PostgreSQL ;
+- RPC/WS/provider ;
+- Program/decoder/executor ;
+- workers/jobs/pipelines ;
+- trading/ML ;
+- nouveaux documents Config pour des composants inexistants ;
+- watcher filesystem générique ;
+- service distribué de configuration ;
+- secrets manager distant ;
+- chiffrement maison de `.env` ;
+- application de contrôle globale KSP.
+
+Toute extension doit être justifiée dans `pre.001` ou reportée.
+
+## 10. Première livraison attendue : `0.1.4-pre.001`
+
+`pre.001` doit être un **plan de travail**, pas une grosse implémentation.
+
+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 ;
+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.
+
+Ne commencer `pre.002` qu'après validation de ce plan.
+
+## 11. Clôture future de `0.1.4`
+
+La dernière prerelease de `0.1.4` devra comme d'habitude :
+
+- exécuter les validations finales ;
+- consolider la documentation ;
+- fermer/report explicitement les TODO ;
+- nettoyer/archiver ce qui doit l'être ;
+- synchroniser le changelog général lors de la publication stable ;
+- produire le prompt de la release suivante ;
+- préparer `rel.001` puis le tag stable `v0.1.4` après validation utilisateur.