# 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.