Files
khadhroony-solana-project/deltas/0.1.4/pre.001.md
2026-08-16 08:52:09 +02:00

9.7 KiB
Raw Blame History

Delta 0.1.4-pre.001

Base requise

Release stable/taguée attendue :

v0.1.3

L'archive fournie khadhroony-solana-project-v0.1.3.zip contient bien :

  • workspace.package.version = "0.1.3" ;
  • ksp-core-lib ;
  • ksp-logging-lib ;
  • ksp-config-lib ;
  • les ressources config/ et .env.example attendues ;
  • deltas/0.1.3/rel.001.md ;
  • prompts/004-V0_1_4_START_PROMPT.md.

L'archive n'embarque pas .git ; le tag v0.1.3 n'est donc pas revérifiable localement depuis le zip. La base stable fournie est utilisée comme prérequis validé de la session.

Objectif

Ouvrir 0.1.4 par la tranche obligatoire de brainstorming, audit et planification de ksp-app-config-desk, sans commencer l'implémentation Tauri fonctionnelle.

Le plan détaillé est ajouté dans :

docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md

Version Cargo

Conformément à VER-ID-009, workspace.package.version passe de :

0.1.3

à :

0.1.4-pre.1

L'identifiant de livraison reste 0.1.4-pre.001.

Aucune dépendance Tauri/frontend n'est ajoutée par cette tranche.

Audit de la base Config/Logging

La surface 0.1.3 répond déjà à l'essentiel de la future application : bootstrap, registre, validation, profils, environnement, sensibilité, management, persistence Logging/.env, mapping Logging et hot reload.

Deux lacunes publiques ont cependant été identifiées avant tout code UI :

  1. ConfigFileRegistry n'expose pas encore d'itération publique sur les descripteurs enregistrés ;
  2. ConfigManagement::read_source() sait lire un document invalide, mais aucune API publique ne permet encore de soumettre un texte corrigé, le faire revalider par Config puis le persister atomiquement.

Décision : compléter ces deux contrats dans ksp-config-lib avant de construire l'UI correspondante. L'application ne codera pas une liste parallèle de file_id et n'écrira jamais directement le fichier physique.

Audit Tauri bot3

La référence kb-app-demo-desktop confirme la valeur des choix suivants :

  • package Rust mixte lib + bin ;
  • single-instance ;
  • tauri.rs central ;
  • LoggingGuard durable dans l'état ;
  • splash + main ;
  • Vite/Vanilla TypeScript ;
  • SCSS/Bootstrap/Font Awesome ;
  • DTO TS-RS applicatifs.

Ne sont pas recopiés tels quels :

  • timings splash codés en dur ;
  • gros ensemble de dépendances de démo ;
  • markdown-it sans vue de présentation ;
  • init_rustls sans besoin TLS réel ;
  • package JS tracing déclaré mais inutilisé.

Audit dépendances actuelles

Versions candidates vérifiées le 2026-08-16 depuis les sources officielles :

tauri                          2.11.5
tauri-build                    2.6.3
tauri-plugin-tracing           0.3.4
ts-rs                           12.0.1
fs2                              0.4.3
@tauri-apps/api                 2.11.1
@tauri-apps/cli                 2.11.4
vite                             8.2.1
typescript                       7.0.2
sass-embedded                    1.102.0
bootstrap                        5.3.8
@fortawesome/fontawesome-free    7.3.1

Elles seront revérifiées lors de leur ajout réel. pre.001 n'ajoute rien par anticipation.

Décision tracing Tauri

tauri-plugin-tracing 0.3.4 ne pose pas de subscriber global par défaut ; KSP utilisera donc le plugin Rust sans with_default_subscriber(). ksp-logging-lib reste l'unique propriétaire du subscriber/runtime global.

L'audit source du plugin montre que sa commande frontend log émet actuellement avec un target vide. Cela est incompatible avec la politique de targets ksp-* de ksp-logging-lib.

Décision :

  • plugin Rust intégré à la frontière Tauri ;
  • pas de tauri-plugin-log ;
  • pas de second subscriber ;
  • pas d'assouplissement de Logging pour accepter le target vide ;
  • pas de package JS tracing tant qu'un adapter réellement compatible ksp-* n'existe pas ;
  • probes Logging de 0.1.4 émis par la façade ksp-logging-lib avec target KSP contrôlé.

Architecture décidée

La future crate :

crates/ksp-app-config-desk

sera :

  • mixte lib + bin ;
  • monofenêtre fonctionnelle (main) + splash ;
  • Vanilla TypeScript/Vite/SCSS/Bootstrap/Font Awesome ;
  • sans framework frontend ;
  • sans vue de présentation ;
  • sans PRESENTATION.md ni markdown-it ;
  • avec toutes les commandes #[tauri::command] dans tauri.rs ;
  • avec services Rust séparés pour Config/Environment/Logging/Secrets ;
  • avec modules tw_main.rs et tw_splash.rs ;
  • avec DTO ordinaires séparés des DTO de reveal Secret.

Ownership Logging

L'état cible conserve :

ConfigManagement
Mutex<LoggingRuntimeState>
    ├── LoggingGuard
    ├── active_profile_id
    └── generation

La sauvegarde du document et l'application d'un profil sont deux actions distinctes. Un reload échoué ne modifie pas les métadonnées runtime et doit laisser le guard/runtime précédent valide.

Sécurité secrets

Le reveal est une action séparée et explicitement confirmée. 0.1.4 protège avant tout contre la divulgation accidentelle : pas de secret réel dans snapshots/DTO généraux/logs/diagnostics/state persistant.

Aucune ré-authentification biométrique/keychain ou mot de passe maison n'est ajoutée. La session desktop locale constitue l'identité de base ; le reveal est une autorisation applicative explicite et transitoire.

Splash

0.1.4 établira la référence commune KSP sans créer prématurément une crate Tauri partagée avec un seul consumer.

Les noms exacts des variables Config/.env de timing seront fixés dans la tranche qui implémente le splash. Elles respecteront KSP_*/KSP_PUBLIC_* et seront ajoutées à .env.example dans le même delta que leur première utilisation.

Présentation

Décision : aucune vue de présentation dans 0.1.4.

Donc :

PRESENTATION.md absent
markdown-it absent
README.md jamais chargé dans une webview

Extensibilité

Le shell Documents doit découvrir les documents depuis le registre Config. Logging est le premier éditeur spécialisé lié à cfg.std.logging, mais le mécanisme shell/diagnostic/source reste générique.

Un futur file_id pourra ajouter son adapter/panneau spécialisé sans dupliquer parsing, validation ou persistence Config.

Prévision souple

Le plan fixe l'ordre candidat suivant :

pre.001  audit + plan
pre.002  extensions Config nécessaires au desktop
pre.003  squelette Tauri/frontend + single-instance + tracing plugin
pre.004  bootstrap/AppState/LoggingGuard/errors
pre.005  shell + splash configurable
pre.006  documents/diagnostics/réparation
pre.007  profils/provenance
pre.008  environnement/.env/shadow
pre.009  reveal secrets
pre.010  Logging editor contrats
pre.011  opérations profils + persistence
pre.012  apply/hot reload/probe
pre.013  matrice fonctionnelle Logging
pre.014  robustesse/extensibilité/audits desktop
pre.015  clôture/docs/validations/prompt suivant

Chaque tranche vise environ 1520 minutes de travail effectif et peut être scindée.

Fichiers ajoutés

docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md
deltas/0.1.4/pre.001.md

Fichiers modifiés

Cargo.toml
docs/000-README.md
docs/plans/000-README.md
docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
ROADMAP.md

Fichiers supprimés

Aucun.

Validations exécutées

  • audit statique de l'archive KSP 0.1.3 ;
  • audit ciblé de ksp-config-lib : registre, document engine, management, environment, logging adapter et error codes ;
  • audit ciblé de ksp-logging-lib : LoggingGuard, initialize, reinitialize, target filters ;
  • audit de l'archive bot3 Tauri : Cargo lib/bin, main.rs, tauri.rs, AppState, splash, Vite, TypeScript, SCSS et package frontend ;
  • vérification web des versions actuelles des dépendances candidates depuis crates.io/npm/Tauri/Vite et du comportement actuel de tauri-plugin-tracing ;
  • contrôle documentaire final de la livraison et de l'archive d'échange.

Validations non exécutées

Aucune source Rust applicative n'est ajoutée ou modifiée dans ce delta.

Le sandbox de préparation ne fournit pas le binaire cargo. Les validations Cargo suivantes n'ont donc pas pu être exécutées ici :

cargo fmt --all
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test --workspace

Le Cargo.toml modifié est néanmoins validé syntaxiquement par le parseur TOML disponible dans le sandbox. Les commandes Cargo devront être exécutées sur le poste de développement avant commit/validation définitive de pre.001.

Décisions prises

  • première application Tauri = référence KSP, mais pas duplication de logique Config ;
  • deux petites extensions Config précèdent l'UI ;
  • shell monofenêtre + splash ;
  • Vanilla TypeScript/Vite/SCSS/Bootstrap/Font Awesome ;
  • aucune présentation/markdown-it ;
  • tauri.rs frontière unique des commandes ;
  • LoggingGuard durable dans AppState ;
  • save Logging séparé de apply ;
  • probe Logging contrôlé ;
  • reveal Secret séparé/transitoire ;
  • pas de tauri-plugin-log ;
  • plugin tracing sans subscriber propre ;
  • pas de JS tracing tant que le target vide du plugin reste incompatible avec ksp-* ;
  • splash configurable via Config/.env, variables nommées lors de l'implémentation ;
  • extensibilité fondée sur le registre Config + éditeurs spécialisés par file_id.

Questions ouvertes

Aucune question ne bloque pre.002 après validation du plan par l'utilisateur.

Les détails reportés à leur tranche sont listés dans le plan : nom final des nouvelles APIs Config, nom des variables splash, features Cargo minimales et forme exacte du fallback Logging de réparation au démarrage.