8.0 KiB
0.1.4-pre.006 — Bootstrap backend, AppState et runtime Logging initial
1. Objectif
Cette tranche raccorde pour la première fois ksp-app-config-desk aux fondations Config et Logging qu'elle doit valider. Elle reste volontairement bornée au bootstrap backend et au premier contrat Tauri/TS-RS ; les services Documents/Environment/Logging éditable et le bridge frontend logging restent dans les tranches suivantes.
La base 0.1.4-pre.5.fix.1 a été validée localement avec installation npm, cargo fmt, check workspace, Clippy, tests de l'application, tests Config, cargo tree et lancement réel :
cargo tauri dev -c crates/ksp-app-config-desk/tauri.conf.json
Vite a démarré sur 1430 et le binaire Tauri a été lancé depuis le target externe du workspace.
2. Version technique
La tranche modifie le runtime Rust et les dépendances de la crate :
workspace.package.version = "0.1.4-pre.6"
Les versions frontend/Tauri applicatives restent 0.1.4 selon la politique courante.
3. Bootstrap Config
src/bootstrap.rs construit exclusivement à travers ksp-config-lib :
argv complet
-> ConfigBootstrapOptions::from_args(...)
-> ConfigFileRegistry::from_args(...)
-> ConfigDocumentEngine
-> ConfigManagement
L'application ne parse donc pas elle-même --cfgpath, --schemapath ou --filemap, ne lit aucun KSP_* directement et ne résout aucun chemin physique Config en dehors de la façade Config.
ConfigManagement est conservé durablement dans AppState pour les services des tranches suivantes.
4. Bootstrap Logging et fallback de réparation
Le chemin nominal est :
ConfigEnvironment::load()
-> load_resolved_logging_config(None, env)
-> ResolvedLoggingConfig::into_settings()
-> ksp_logging_lib::initialize(...)
-> LoggingGuard
None sélectionne le default_profile du document std.logging.json.
Pour respecter l'exigence de réparation de Config Desk, une erreur lors du chargement/résolution Logging ou de la préparation du runtime configuré ne condamne pas automatiquement l'application. Tant qu'aucun subscriber global n'a pu être installé, Config Desk tente un fallback transitoire en mémoire :
default_filter : Info
span_events : Off
console : stderr / Human
files : aucun
persistence : aucune
Le fallback :
- n'est jamais écrit dans
std.logging.json; - ne modifie aucun profil utilisateur ;
- conserve un diagnostic frontend borné ;
- permet à l'application de rester utilisable pour réparer la configuration ;
- installe toujours le subscriber via
ksp-logging-lib, jamais via l'application outauri-plugin-tracing.
Si le fallback lui-même ne peut pas installer le runtime global, le bootstrap échoue explicitement avec config_desk.logging_bootstrap_failed.
5. Ownership AppState
L'état backend devient :
AppState
├── ConfigManagement
└── Mutex<LoggingRuntimeState>
├── LoggingGuard
├── active_profile_id
├── generation = 1
├── fallback_active
└── startup_diagnostic
Le LoggingGuard vit donc avec l'application et prépare le futur reinitialize() transactionnel. Le guard et les métadonnées runtime sont regroupés sous le même mutex afin que les futures mutations restent atomiques au niveau applicatif.
6. Premier contrat Tauri + TS-RS
La crate introduit ts-rs = "^12.0" au niveau workspace et les premiers DTO applicatifs :
CommandErrorDto
AppSnapshotDto
Les exports sont générés sous :
frontend/ts/bindings/ksp_app_config_desk/dto_common/
CommandErrorDto projette uniquement :
domain
code
message
Il ne sérialise jamais automatiquement Error::context() ni la chaîne des sources.
La première commande réelle est :
get_app_snapshot
Elle retourne notamment la version applicative, le nombre de descripteurs Config, le profil Logging actif éventuel, la génération runtime, l'état fallback et le diagnostic de bootstrap sûr.
Toutes les annotations #[tauri::command] restent centralisées dans tauri.rs.
7. Builder Tauri
Le builder reste volontairement découpé :
configure_state
configure_plugins
configure_commands
configure_setup
Le plugin tracing conserve Builder::new() sans with_default_subscriber(). ksp-logging-lib::initialize() reste le seul propriétaire de l'installation du subscriber global KSP.
8. Police du splash bot3
L'audit du gabarit bot3 confirme une seule police locale spécifique au splash :
DOS_Amazigh.ttf
font-family: Dos Amazigh
Source auditée :
kb-app-demo-desktop/frontend/fonts/DOS_Amazigh.ttf
Destination KSP :
crates/ksp-app-config-desk/frontend/fonts/DOS_Amazigh.ttf
Empreinte de la copie bot3 auditée :
SHA-256 a01ff4b5a0d699db7cefcf5336bf0e379ff6fbf0d096087571a13c8782f9aa02
Le répertoire frontend/fonts/ et son manifeste sont ajoutés dès cette tranche. Le style @font-face et l'animation/lifecycle final restent associés à pre.008, afin de ne pas coupler le bootstrap backend à la finition du splash.
9. Tests ajoutés
Tests unitaires hors src/ :
- le fallback Logging est console-only, stderr,
Info, sans fichier et sans span lifecycle ; - le DTO d'erreur commun ne reprend pas les champs de contexte KSP arbitraires.
Les dérives #[ts(export)] ajoutent également les tests d'export TS-RS au package.
10. Dépendances
Nouvelles dépendances directes de ksp-app-config-desk :
ksp-config-lib
ksp-logging-lib
serde
ts-rs
ts-rs est centralisé dans [workspace.dependencies] avec une contrainte ^12.0. Aucune dépendance Solana/protocole supplémentaire n'est introduite.
11. Fichiers
| Fichier | Action |
|---|---|
Cargo.toml |
modifié |
crates/ksp-app-config-desk/Cargo.toml |
modifié |
crates/ksp-app-config-desk/src/app_state.rs |
ajouté |
crates/ksp-app-config-desk/src/bootstrap.rs |
ajouté |
crates/ksp-app-config-desk/src/constants.rs |
ajouté |
crates/ksp-app-config-desk/src/dto_common.rs |
ajouté |
crates/ksp-app-config-desk/src/errors.rs |
modifié |
crates/ksp-app-config-desk/src/lib.rs |
modifié |
crates/ksp-app-config-desk/src/tauri.rs |
modifié |
crates/ksp-app-config-desk/unit_tests/bootstrap.rs |
ajouté |
crates/ksp-app-config-desk/unit_tests/dto_common.rs |
ajouté |
crates/ksp-app-config-desk/frontend/fonts/README.md |
ajouté |
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/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md |
modifié |
deltas/0.1.4/pre.006.md |
ajouté |
12. Validations à exécuter
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
Après cargo test -p ksp-app-config-desk, vérifier également que les bindings ont été générés sous :
crates/ksp-app-config-desk/frontend/ts/bindings/ksp_app_config_desk/dto_common/
Le lancement desktop nominal doit utiliser le profil Logging par défaut de config/std.logging.json. Le diagnostic de fallback sera validé plus profondément avec les écrans Documents/Logging des tranches suivantes.
13. Suite
Après validation, pre.007 reprend/refond le bridge frontend_log.ts de bot3 : targets KSP whitelistés, commande emit_frontend_log centralisée dans tauri.rs et émission finale exclusivement via ksp-logging-lib.