245 lines
9.8 KiB
Markdown
245 lines
9.8 KiB
Markdown
<!-- 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.
|