khadhroony-solana-project/prompts/004-V0_1_4_START_PROMPT.md

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 :

v0.1.3
workspace.package.version = "0.1.3"

Le workspace doit contenir au minimum :

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 :

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 :

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.