<!-- file: deltas/0.1.4/pre.005.md -->
<!-- version: 2 -->

# Delta 0.1.4-pre.005 — gabarit frontend Vite/TypeScript/SCSS et tracing Tauri

## Base requise

```text
0.1.4-pre.004-fix.001
workspace.package.version = "0.1.4-pre.4.fix.1"
```

`pre.004-fix.001` est considéré comme validé et commité. Les validations locales fournies avant cette tranche ont réussi : `cargo fmt --all`, `cargo check --workspace`, `cargo clippy --workspace --all-targets`, `cargo test -p ksp-app-config-desk` et `cargo tree -p ksp-app-config-desk`.

## Objectif

Rendre le squelette Tauri créé en `pre.004` réellement équipé de son gabarit frontend sans encore ouvrir les surfaces métier Config.

Cette tranche introduit :

- `package.json` ;
- `vite.config.ts` et `tsconfig.json` ;
- `frontend/main.html` et `frontend/splash.html` ;
- TypeScript minimal pour les deux fenêtres ;
- SCSS/Bootstrap/Font Awesome ;
- SimpleBar et `resize-observer-polyfill` ;
- les assets visuels de référence issus du gabarit bot3 ;
- `tauri-plugin-tracing` côté Rust ;
- `@fltsci/tauri-plugin-tracing` côté frontend ;
- la permission Tauri `tracing:default` ;
- Vite HTTP strict sur `1430` et WebSocket de développement sur `1431` ;
- la destination de build frontend externe demandée.

`AppState`, Config, Logging, le bridge `frontend_log.ts` KSP et le lifecycle splash configurable restent hors scope de cette tranche.

## Version Cargo

`workspace.package.version` passe de :

```text
0.1.4-pre.4.fix.1
```

à :

```text
0.1.4-pre.5
```

L'identifiant documentaire de livraison est :

```text
0.1.4-pre.005
```

## 1. Dépendance Rust tracing Tauri

Le workspace ajoute :

```toml
tauri-plugin-tracing = { version = "^0.3" }
```

La version actuelle auditée est `0.3.4`.

`ksp-app-config-desk` consomme la dépendance avec :

```toml
tauri-plugin-tracing.workspace = true
```

`tauri.rs` conserve un builder progressif :

```text
Builder::default
    -> configure_plugins
    -> configure_setup
    -> run
```

`configure_plugins()` construit le plugin avec `tauri_plugin_tracing::Builder::new()` puis l'ajoute au builder. Aucun `with_default_subscriber()` n'est appelé : cette tranche ne crée donc pas de second runtime tracing et ne prend pas l'ownership réservé à `ksp-logging-lib`.

`tauri-plugin-log` n'est pas ajouté.

## 2. Capability tracing

`capabilities/default.json` contient désormais :

```text
core:default
tracing:default
```

La permission tracing entre dans le même delta que le plugin, conformément à la décision prise après `pre.004`.

## 3. Dépendances frontend

Les générations actuelles ont été revérifiées avant rédaction du manifest :

| Dépendance                         | Version actuelle auditée | Contrainte déclarée |
| ---------------------------------- | -----------------------: | ------------------: |
| `@fltsci/tauri-plugin-tracing`     |                  `0.3.4` |              `^0.3` |
| `@fortawesome/fontawesome-free`    |                  `7.3.1` |              `^7.3` |
| `@tauri-apps/api`                  |                 `2.11.1` |             `^2.11` |
| `@types/node`                      |                 `26.1.2` |             `^26.1` |
| `bootstrap`                        |                  `5.3.8` |              `^5.3` |
| `resize-observer-polyfill`         |                  `1.5.1` |              `^1.5` |
| `sass-embedded`                    |                `1.102.0` |            `^1.102` |
| `simplebar`                        |                  `6.3.3` |              `^6.3` |
| `typescript`                       |                  `7.0.2` |              `^7.0` |
| `vite`                             |                  `8.2.0` |              `^8.2` |

Ces dépendances sont placées sous `devDependencies`, conformément à l'usage `npm i -D` retenu pour les applications desk : elles participent au build du bundle desktop et ne constituent pas un runtime Node déployé séparément.

`@tauri-apps/cli` n'est pas ajouté : le workflow retenu utilise la CLI Cargo/Tauri et npm uniquement pour la gestion des dépendances et pour les scripts internes appelés par Tauri.

Le lockfile npm reste ignoré.

## 4. Politique npm

`package.json` ne fournit que les scripts utilisés par Tauri :

```text
dev   -> vite
build -> tsc && vite build
```

Première installation après application du delta :

```bash
cd crates/ksp-app-config-desk
npm i -D
```

Le cycle normal reste ensuite :

```bash
cargo tauri dev
```

ou le build Tauri correspondant. Il n'est pas demandé de lancer directement `npm run dev` ou `npm run build` dans le workflow utilisateur.

L'environnement de préparation a tenté l'installation npm afin de vérifier le workflow, mais l'accès registry du sandbox a expiré avant téléchargement. Aucun `node_modules` ni `package-lock.json` n'est livré. Les versions ci-dessus ont donc été vérifiées depuis les registres/sources officielles, et l'installation effective doit être faite sur le poste de développement.

## 5. Vite 8 actualisé

Le gabarit bot3 utilisait encore `build.rollupOptions` et la configuration historique `server.hmr`. Avec Vite 8, le nouveau gabarit utilise :

```text
build.rolldownOptions
server.ws
```

afin de ne pas introduire dès la première application KSP des options désormais dépréciées.

Le serveur est configuré ainsi :

| Usage                    | Port | Politique |
| ------------------------ | ---: | --------- |
| Vite HTTP                | 1430 | strict    |
| WebSocket dev/HMR        | 1431 | dédié     |

`strictPort = true` interdit le basculement silencieux du serveur HTTP vers un autre port.

## 6. Destination frontend hors workspace source

`tauri.conf.json` possédait déjà :

```text
../../../builds/khadhroony-solana-project/ksp-app-config-desk/dist
```

`vite.config.ts` part maintenant de la racine de la crate puis résout **le même chemin contractuel** :

```text
../../../builds/khadhroony-solana-project/ksp-app-config-desk/dist
```

Le `root` Vite reste `frontend/`, mais l'utilisation d'un path absolu résolu depuis la crate évite que `build.outDir` ne soit accidentellement interprété relativement à `frontend/`.

Cette disposition place le `dist` à côté de la hiérarchie d'artefacts Rust définie par `.cargo/config.toml`, et non dans le workspace source.

## 7. Layout frontend

Le gabarit concret est :

```text
frontend/
├── imgs/
│   ├── logo.png
│   └── splash.png
├── sass/
│   ├── _app.scss
│   ├── _bootswatch.scss
│   ├── _fontawesome.scss
│   ├── _simplebar.scss
│   ├── _variables.scss
│   ├── main.scss
│   └── splash.scss
├── ts/
│   ├── main.ts
│   └── splash.ts
├── main.html
└── splash.html
```

Les assets, le thème Pulse, les bases SimpleBar, le splash et l'iconographie reprennent/refondent le gabarit audité de khadhroony-bot3.

Le shell `main` ne charge aucun `README.md` et aucun `PRESENTATION.md` n'est créé.

## 8. SimpleBar et resize observer

Le frontend importe :

```text
resize-observer-polyfill
simplebar
```

et installe le `ResizeObserver` de compatibilité sur `window` avant l'utilisation effective du shell scrollable.

La zone principale utilise `data-simplebar`, ce qui conserve le scrolling visuel du gabarit au lieu de retomber sur la scrollbar WebKitGTK native.

## 9. TypeScript et API Tauri

`main.ts` et `splash.ts` utilisent `getCurrentWindow()` depuis `@tauri-apps/api/window` afin de valider que les scripts sont bien exécutés dans leur fenêtre Tauri respective.

Aucune commande métier n'est encore invoquée.

Les futurs bindings TS-RS restent destinés à :

```text
frontend/ts/bindings/ksp_app_config_desk/...
```

`ts-rs` n'est toujours pas ajouté artificiellement : il entrera en `pre.006` avec les premiers DTO réels de bootstrap/state.

## 10. Frontend tracing : intégration sans faux contrat KSP

Le package officiel associé `@fltsci/tauri-plugin-tracing` est présent avec le plugin Rust, mais cette tranche n'appelle pas encore directement ses helpers `trace/debug/info/...` comme façade applicative KSP.

Cette décision évite de faire du target vide actuellement utilisé par le bridge générique un contrat de routage KSP. La tranche `pre.007` introduira le bridge `frontend_log.ts` repris/refondu depuis bot3 avec :

- targets KSP whitelistés ;
- commande centralisée dans `tauri.rs` ;
- émission finale via `ksp-logging-lib` ;
- intégration des fonctionnalités console du plugin uniquement lorsqu'elles restent compatibles avec cette ownership.

## 11. Splash/main à ce stade

Les deux pages sont maintenant bundlables.

La fenêtre `splash` reste la fenêtre visible au démarrage et `main` reste initialement invisible comme déclaré depuis `pre.004`. Cette tranche **ne code pas une temporisation splash temporaire** uniquement pour montrer `main` : le lifecycle réel et configurable reste réservé à `pre.008`.

Le premier `cargo tauri dev` doit donc au minimum prouver :

- lancement du serveur Vite sur `1430` ;
- WebSocket de développement réservé `1431` ;
- chargement de `splash.html` dans la WebView ;
- styles/assets visibles ;
- absence d'erreur de capability pour le plugin tracing.

## 12. Fichiers modifiés

| Fichier                                                | Version précédente | Nouvelle version |
|--------------------------------------------------------|-------------------:|-----------------:|
| `Cargo.toml`                                           |                 66 |               67 |
| `crates/ksp-app-config-desk/Cargo.toml`                |                  1 |                2 |
| `crates/ksp-app-config-desk/src/tauri.rs`              |                  1 |                2 |
| `crates/ksp-app-config-desk/capabilities/default.json` |                n/a |              n/a |
| `crates/ksp-app-config-desk/README.md`                 |                  1 |                2 |
| `crates/ksp-app-config-desk/USAGE.md`                  |                  1 |                2 |
| `crates/ksp-app-config-desk/TODO.md`                   |                  1 |                2 |

## 13. Fichiers ajoutés

```text
crates/ksp-app-config-desk/package.json
crates/ksp-app-config-desk/tsconfig.json
crates/ksp-app-config-desk/vite.config.ts
crates/ksp-app-config-desk/frontend/main.html
crates/ksp-app-config-desk/frontend/splash.html
crates/ksp-app-config-desk/frontend/ts/main.ts
crates/ksp-app-config-desk/frontend/ts/splash.ts
crates/ksp-app-config-desk/frontend/sass/_app.scss
crates/ksp-app-config-desk/frontend/sass/_bootswatch.scss
crates/ksp-app-config-desk/frontend/sass/_fontawesome.scss
crates/ksp-app-config-desk/frontend/sass/_simplebar.scss
crates/ksp-app-config-desk/frontend/sass/_variables.scss
crates/ksp-app-config-desk/frontend/sass/main.scss
crates/ksp-app-config-desk/frontend/sass/splash.scss
crates/ksp-app-config-desk/frontend/imgs/logo.png
crates/ksp-app-config-desk/frontend/imgs/splash.png
deltas/0.1.4/pre.005.md
```

## 14. Fichiers supprimés

Aucun.

## 15. Contrôles exécutés pendant la préparation

- comparaison du scope avec `pre.004-fix.001` ;
- parsing TOML du workspace et de la crate ;
- parsing JSON de `package.json`, `tsconfig.json`, `tauri.conf.json` et de la capability ;
- vérification de `workspace.package.version = "0.1.4-pre.5"` ;
- vérification de l'absence de `tauri-plugin-log` ;
- vérification de `tracing:default` dans la capability ;
- vérification de `1430` strict et `1431` dédié dans Vite ;
- vérification que le `frontendDist` Tauri et le `frontendDist` résolu par Vite désignent le même répertoire physique ;
- vérification des headers `file:` / `version:` sur les nouveaux fichiers texte KSP concernés ;
- vérification de la limite 160 colonnes sur le Rust modifié ;
- tentative de `npm i -D`, interrompue par timeout réseau du sandbox avant installation.

Le sandbox de préparation ne fournit pas Cargo. L'installation npm effective et les validations runtime sont donc à exécuter localement.

## 16. Validation locale demandée

Après application du delta :

```bash
cd crates/ksp-app-config-desk
npm i -D
cd ../..

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 -p ksp-app-config-desk
```

Si la syntaxe locale de la CLI Tauri installée ne prend pas `-p`, lancer la commande depuis `crates/ksp-app-config-desk` avec la forme habituelle du poste de développement. Le point important est que Tauri, et non une commande `npm run dev` lancée manuellement, pilote le serveur frontend.

À l'écran, le splash doit charger le visuel KSP et afficher son statut frontend. Le passage automatique vers `main` n'est pas encore attendu avant `pre.008`.

## 17. Suite

Après validation/commit de `pre.005`, `pre.006` introduira le bootstrap backend et `AppState` :

- arguments -> `ConfigBootstrapOptions` / registre / management ;
- première utilisation réelle de `ksp-config-lib` ;
- initialisation de `ksp-logging-lib` ;
- ownership durable de `LoggingGuard` ;
- fallback sûr si Logging Config est invalide ;
- premiers DTO applicatifs et bindings TS-RS réels.