Sasedev/khadhroony-solana-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
778ea58ee18b94de9b9fd9b2d0f2f683b7f46332
khadhroony-solana-project/deltas/0.1.4/pre.008-fix.002.md

9.4 KiB
Raw Blame History

0.1.4-pre.008-fix.002 — Clippy Tauri, racine Config, timings splash et header principal

1. Motif du fix

La validation locale de 0.1.4-pre.8.fix.1 confirme que cargo check, les tests de l'application et les tests Config passent, mais cargo clippy --workspace --all-targets révèle encore trois erreurs :

  • deux closures de test violent clippy::implicit_return ;
  • l'expansion générée par Tauri pour la commande async splash_frontend_ready utilise l'opérateur ?, alors que le workspace refuse clippy::question_mark_used.

Le test desktop révèle en parallèle un point runtime plus important : le démarrage utilise toujours le fallback Logging avec json_file_read_failed, alors que config/std.logging.json existe à la racine du workspace. Le même bootstrap résout les timings du splash via ConfigEnvironment; le .env racine peut donc être manqué pour la même raison lorsque Tauri lance cargo run depuis la crate applicative.

Le correctif traite également les remarques UI liées à la tranche pre.008 : identité du header et traçage fin des changements de tabs.

2. Version technique

Le fix touche Rust, TypeScript, HTML et documentation :

workspace.package.version = "0.1.4-pre.8.fix.2"

La version applicative frontend/Tauri reste 0.1.4 selon la politique KSP courante.

3. Clippy sur les closures de test

Les predicates passés à Iterator::any() sont écrits avec le return explicite requis par le workspace :

.any(|field| return field.key() == "maximum_ms" && field.value() == "60000")

et :

.any(|field| return field.key() == "maximum_ms" && field.value() == "10000")

Le test du fallback est en plus renforcé pour verrouiller :

minimum_source = fallback
fade_source = fallback
expected_backend_lifecycle_ms = 1500

4. Exception Clippy strictement bornée au code généré Tauri

Le code source KSP de splash_frontend_ready n'utilise toujours aucun ?.

La violation provient de l'expansion de tauri::generate_handler! pour une commande async. L'exception est donc placée uniquement sur le helper d'assemblage qui invoque ce macro :

#[allow(clippy::question_mark_used)] // Tauri generates `?` internally for async command dispatch.
fn configure_commands(...)

Aucun allow global et aucune détente de clippy::question_mark / clippy::question_mark_used au niveau workspace ne sont introduits.

5. Current working directory du runtime debug

Le workflow KSP lance l'application depuis la racine avec :

cargo tauri dev -c crates/ksp-app-config-desk/tauri.conf.json

Tauri peut néanmoins exécuter le cargo run applicatif depuis la crate Tauri. Les defaults de ksp-config-lib restent volontairement :

config/
config/schemas/
./.env

Afin de conserver ces ressources enracinées au projet sans transférer leur ownership à l'application, main.rs normalise en build debug le current working directory Rust vers :

env!("CARGO_MANIFEST_DIR")/../..

avant d'appeler le bootstrap Config.

Cette adaptation :

  • ne lit pas .env ;
  • ne parse aucune variable KSP_* / KSPB_* ;
  • ne lit aucun JSON Config ;
  • laisse ConfigBootstrapOptions, ConfigFileRegistry, ConfigManagement et ConfigEnvironment effectuer toutes les lectures ;
  • ne s'applique pas au build release, dont le modèle de ressources distribuées sera traité séparément.

Le test desktop doit confirmer que le warning json_file_read_failed disparaît lorsque config/std.logging.json racine est valide.

6. Instrumentation Rust du lifecycle splash

SplashSettings conserve désormais la provenance sûre de chaque valeur :

process

dotenv

fallback

Le runtime journalise en debug :

  1. les valeurs résolues et leur provenance ;
  2. la readiness acceptée ;
  3. la fin de l'attente minimale avec durée configurée et durée réelle ;
  4. la fin de l'attente du fade-out avec durée configurée et durée réelle ;
  5. la destruction du splash après activation de main, avec durée totale attendue/réelle.

Le contrat temporel KSP reste celui fixé par pre.008 :

readiness
-> emit fade_in
-> wait minimum
-> emit fade_out
-> wait fade
-> show/focus main
-> destroy splash

Il n'est pas remplacé par les trois temporisations historiques de bot3. Avec :

KSP_DESK_SPLASH_MINIMUM_MS=12000
KSP_DESK_SPLASH_FADE_MS=3000

le lifecycle backend attendu de readiness à activation de main est donc approximativement :

15000 ms

Les nouveaux logs permettent de distinguer immédiatement un défaut de résolution .env d'un défaut d'attente async.

7. Header principal et tabs

Le logo contenant déjà l'identité visuelle KSP, le header n'affiche plus KSP — Config Desk.

La convention devient :

[logo K] Config Desk — <vue active>

Par exemple :

Config Desk — Vue d'ensemble
Config Desk — Documents
Config Desk — Logging

Le <title> WebView suit la même vue active.

Les cinq commandes principales restent sous forme de pills/tabs alignées à droite, adaptée à cette application monofenêtre compacte. La règle de gabarit prévoit un dropdown lorsque le nombre de commandes devient trop important.

Le frontend trace désormais :

  • chaque clic de tab en trace ;
  • l'état de tab actif après changement en trace ;
  • l'activation utilisateur significative de la vue en debug ;
  • les remplacements de contenu restent en trace.

8. @fltsci/tauri-plugin-tracing et console WebKit

Le plugin Rust tauri-plugin-tracing reste réellement installé ; ce qui n'est pas encore utilisé est la façade JS officielle pour le routing applicatif.

Le bridge KSP actuel fournit :

console/WebView JS
-> affichage dans la console WebKit originale
-> emit_frontend_log
-> ksp-logging-lib
-> runtime Rust

Il ne fournit pas encore le trajet général inverse :

événement tracing Rust
-> console WebKit

Le package officiel expose attachConsole(), interceptConsole() et takeoverConsole(), mais avec le subscriber custom possédé par KSP, le retour Rust -> WebView nécessite que ce subscriber intègre tauri_plugin_tracing::WebviewLayer.

Décision : ne pas appeler artificiellement takeoverConsole() dans ce fix. Une future tranche raccordera éventuellement WebviewLayer à ksp-logging-lib, de façon à pouvoir utiliser attachConsole() sans second subscriber, sans double émission JS -> Rust et sans boucle avec frontend_log.ts.

9. Règles et plan

RULES_KSP.md ajoute :

  • KSP-APP-028 pour l'identité de header et le choix tabs/pills vs dropdown ;
  • KSP-APP-029 pour la normalisation du CWD debug avant bootstrap Config dans un workspace Tauri multi-app.

Le plan 0.1.4 passe en version 9 et documente :

  • la sémantique temporelle exacte du splash ;
  • les métriques debug ;
  • le CWD runtime debug ;
  • la convention du header ;
  • l'état réel du bridge console et le besoin futur de WebviewLayer.

10. Fichiers modifiés

Fichier Action
Cargo.toml modifié
crates/ksp-app-config-desk/src/main.rs modifié
crates/ksp-app-config-desk/src/tauri.rs modifié
crates/ksp-app-config-desk/src/splash.rs modifié
crates/ksp-app-config-desk/src/app_state.rs modifié
crates/ksp-app-config-desk/src/tw_splash.rs modifié
crates/ksp-app-config-desk/unit_tests/splash.rs modifié
crates/ksp-app-config-desk/frontend/main.html modifié
crates/ksp-app-config-desk/frontend/ts/main.ts modifié
crates/ksp-app-config-desk/README.md modifié
crates/ksp-app-config-desk/USAGE.md modifié
crates/ksp-app-config-desk/TODO.md modifié
docs/rules/RULES_KSP.md modifié
docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md modifié
deltas/0.1.4/pre.008-fix.002.md ajouté

Aucune dépendance n'est ajoutée et aucun asset binaire n'est modifié.

11. Validations demandées

Depuis la racine du workspace :

cargo fmt --all
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test -p ksp-app-config-desk
cargo test -p ksp-config-lib
cargo tree -p ksp-app-config-desk
cargo tauri dev -c crates/ksp-app-config-desk/tauri.conf.json

Avec le .env utilisateur :

KSP_DESK_SPLASH_MINIMUM_MS=12000
KSP_DESK_SPLASH_FADE_MS=3000

le lancement doit notamment montrer en debug :

minimum_ms=12000
minimum_source="dotenv"
fade_ms=3000
fade_source="dotenv"
expected_backend_lifecycle_ms=15000

puis deux attentes proches de 12000 ms et 3000 ms, et une durée backend totale proche de 15000 ms avant activation de main.

Le lancement doit également confirmer :

  • disparition de json_file_read_failed si le document Logging racine est valide ;
  • chargement du profil Logging local_dev au lieu du fallback startup ;
  • header Config Desk — Vue d'ensemble puis mise à jour du titre lors des changements de tabs ;
  • logs trace sur les clics/changements de tabs lorsque le filtre runtime laisse passer trace.

12. Suite

Après validation de ce fix, pre.008 peut être considérée fermée et pre.009 peut commencer la surface Documents + diagnostics.

Reference in New Issue View Git Blame Copy Permalink