v0.1.4-pre.001

This commit is contained in:
2026-08-16 08:52:09 +02:00
parent 513f57dd21
commit 6bd0b4e9b5
7 changed files with 1476 additions and 21 deletions

278
deltas/0.1.4/pre.001.md Normal file
View File

@@ -0,0 +1,278 @@
<!-- file: deltas/0.1.4/pre.001.md -->
<!-- version: 1 -->
# Delta 0.1.4-pre.001
## Base requise
Release stable/taguée attendue :
```text
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 :
```text
docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md
```
## Version Cargo
Conformément à `VER-ID-009`, `workspace.package.version` passe de :
```text
0.1.3
```
à :
```text
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 :
```text
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 :
```text
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 :
```text
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 :
```text
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 :
```text
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
```text
docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md
deltas/0.1.4/pre.001.md
```
## Fichiers modifiés
```text
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 :
```text
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.