Sasedev/khadhroony-solana-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.1.4-pre.018-fix.001

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-16 20:34:34 +02:00
parent 035e25cb1f
commit 8f7df2d06e
8 changed files with 164 additions and 48 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
Cargo.toml
View File

@@ -6,7 +6,7 @@ resolver = "3"
members = ["crates/ksp-app-config-desk", "crates/ksp-config-lib", "crates/ksp-core-lib", "crates/ksp-logging-lib"]
[workspace.package]
version = "0.1.4-pre.18"
version = "0.1.4-pre.18.fix.1"
edition = "2024"
license = "MIT"
repository = "https://git.sasedev.com/Sasedev/khadhroony-solana-project"

4
crates/ksp-app-config-desk/README.md
View File

@@ -1,5 +1,5 @@
<!-- file: crates/ksp-app-config-desk/README.md -->
<!-- version: 21 -->
<!-- version: 22 -->
# `ksp-app-config-desk`
@@ -82,7 +82,7 @@ Les DTO Rust applicatifs restent la source de vérité et les bindings généré
Le frontend possède désormais `shell_registry.ts`. Le registre décrit les vues du shell et les adapters d'éditeurs spécialisés par `file_id`. Le panneau Documents reste générique ; lorsqu'un document possède un adapter enregistré, **Ouvrir l'éditeur spécialisé** déclenche la navigation par événement de registre. `cfg.std.logging -> Logging` est le premier adapter. Ajouter un futur éditeur ne demande donc pas de réécrire le moteur Documents ni la logique générale d'activation des panneaux.
Deux audits d'intégration applicatifs complètent les audits Config/Logging existants : contrat Tauri/Vite/package scripts, centralisation des commandes Tauri, absence de `tauri-plugin-log`, interdiction des dialogues navigateur natifs et absence de stockage persistant pour le reveal Secret. Le script frontend `npm run check` exécute `tsc --noEmit` puis le build Vite.
Deux audits d'intégration applicatifs complètent les audits Config/Logging existants : contrat Tauri/Vite/package scripts, centralisation des commandes Tauri, absence de `tauri-plugin-log`, interdiction des dialogues navigateur natifs et absence de stockage persistant pour le reveal Secret. Le script frontend `npm run check` exécute uniquement `tsc --noEmit`. Le build Vite de production n’est pas lancé séparément : il appartient au `beforeBuildCommand` de `cargo tauri build`, qui reste la dernière validation après tous les contrôles Rust, le type-check frontend et le parcours fonctionnel `tauri dev`.
## Artefacts frontend

30
crates/ksp-app-config-desk/USAGE.md
View File

@@ -1,5 +1,5 @@
<!-- file: crates/ksp-app-config-desk/USAGE.md -->
<!-- version: 21 -->
<!-- version: 22 -->
# Utilisation de `ksp-app-config-desk`
@@ -285,19 +285,37 @@ Si la résolution ou la préparation du profil explicite échoue, `ksp_logging_l
## Validation desktop de robustesse
Depuis `crates/ksp-app-config-desk`, le contrôle frontend explicite est :
La validation suit un ordre strict. Depuis la racine du workspace, valider d’abord Rust :
```bash
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 test -p ksp-logging-lib
```
Puis effectuer uniquement le type-check frontend depuis `crates/ksp-app-config-desk` :
```bash
npm run check
```
Il exécute `tsc --noEmit` puis `vite build`. La validation intégrée de la tranche inclut aussi :
`npm run check` exécute seulement `tsc --noEmit`. Il ne lance pas `vite build` : le build frontend de production est déjà la responsabilité de Tauri via `beforeBuildCommand = npm run build`.
Revenir ensuite à la racine et effectuer le contrôle fonctionnel :
```bash
cargo tauri dev -c crates/ksp-app-config-desk/tauri.conf.json
```
**Seulement lorsque tous les contrôles précédents sont validés**, exécuter en toute dernière opération :
```bash
cargo test -p ksp-app-config-desk
cargo test -p ksp-config-lib
cargo test -p ksp-logging-lib
cargo tauri build -c crates/ksp-app-config-desk/tauri.conf.json
```
Cette dernière commande déclenche elle-même `npm run build`, donc `tsc && vite build`, avant le build/bundling Tauri. Aucun build Vite séparé n’est nécessaire dans le cycle de validation.
Un source Logging invalide au démarrage doit sélectionner le fallback transitoire sans persistence automatique. Après réparation du document, un nouveau lancement doit reprendre la configuration managée.

2
crates/ksp-app-config-desk/package.json
View File

@@ -8,7 +8,7 @@
"build": "tsc && vite build",
"preview": "vite preview",
"tauri": "tauri",
"check": "tsc --noEmit && vite build"
"check": "tsc --noEmit"
},
"dependencies": {
"@fltsci/tauri-plugin-tracing": "^0.3",

10
crates/ksp-app-config-desk/tests/desktop_contract.rs
View File

@@ -1,5 +1,5 @@
// file: crates/ksp-app-config-desk/tests/desktop_contract.rs
// version: 1
// version: 2
//! Desktop build/shell contract audits for Config Desk.
@@ -40,9 +40,9 @@ fn tauri_and_frontend_build_contracts_remain_explicit() {
std::option::Option::None => return,
};
assert_eq!(windows.len(), 2);
let labels = windows.iter().filter_map(|window| window.get("label").and_then(serde_json::Value::as_str)).collect::<std::vec::Vec<_>>();
let labels = windows.iter().filter_map(|window| return window.get("label").and_then(serde_json::Value::as_str)).collect::<std::vec::Vec<_>>();
assert_eq!(labels, ["splash", "main"]);
let main = windows.iter().find(|window| window.get("label").and_then(serde_json::Value::as_str) == std::option::Option::Some("main"));
let main = windows.iter().find(|window| return window.get("label").and_then(serde_json::Value::as_str) == std::option::Option::Some("main"));
assert!(main.is_some());
if let std::option::Option::Some(main) = main {
assert_eq!(main.get("visible").and_then(serde_json::Value::as_bool), std::option::Option::Some(false));
@@ -50,8 +50,8 @@ fn tauri_and_frontend_build_contracts_remain_explicit() {
let package = read_json(root.join("package.json").as_path());
let build = package.pointer("/scripts/build").and_then(serde_json::Value::as_str);
let check = package.pointer("/scripts/check").and_then(serde_json::Value::as_str);
assert!(build.is_some_and(|value| value.contains("tsc") && value.contains("vite build")));
assert!(check.is_some_and(|value| value.contains("tsc --noEmit") && value.contains("vite build")));
assert!(build.is_some_and(|value| return value.contains("tsc") && value.contains("vite build")));
assert_eq!(check, std::option::Option::Some("tsc --noEmit"));
}
#[test]

95
deltas/0.1.4/pre.018-fix.001.md Normal file
View File

@@ -0,0 +1,95 @@
<!-- file: deltas/0.1.4/pre.018-fix.001.md -->
<!-- version: 1 -->
# Delta `0.1.4-pre.018-fix.001` — validation frontend/Tauri et conformité Clippy
## Base
`0.1.4-pre.018` a été appliquée et le parcours fonctionnel du registre d'éditeurs spécialisés est validé. La validation a toutefois révélé deux défauts de tranche :
- `cargo clippy --workspace --all-targets` échoue sur quatre closures du nouveau test `desktop_contract.rs` à cause de la règle workspace `clippy::implicit-return` ;
- `npm run check` lance inutilement `vite build`, alors que le build frontend de production appartient déjà à `cargo tauri build` via `beforeBuildCommand = npm run build`.
Le build Tauri a également été exécuté trop tôt dans la séquence de validation. La politique KSP est clarifiée : **`cargo tauri build` est la dernière opération**, après tous les contrôles Rust, le type-check frontend et le parcours fonctionnel `tauri dev`.
## Corrections
### Clippy
Les closures de `tests/desktop_contract.rs` utilisent désormais des `return` explicites conformément aux règles Rust KSP. Aucun `#[allow(...)]` n'est ajouté.
### Contrôle frontend
`package.json` définit désormais :
```text
npm run check -> tsc --noEmit
```
Le script `build` reste :
```text
npm run build -> tsc && vite build
```
et demeure appelé exclusivement par le hook Tauri de build dans le cycle normal.
Le test de contrat desktop vérifie explicitement que :
- `beforeBuildCommand` reste `npm run build` ;
- `build` contient `tsc` + `vite build` ;
- `check` vaut exactement `tsc --noEmit` et ne produit donc aucun bundle.
### Ordre de validation
La règle normative **KSP-APP-034** formalise cette politique pour toutes les applications Tauri KSP. La documentation courante fixe l'ordre suivant :
1. `cargo fmt --all` ;
2. `cargo check --workspace` ;
3. `cargo clippy --workspace --all-targets` ;
4. tests Rust ciblés/workspace selon la tranche ;
5. `npm run check` (`tsc --noEmit` uniquement) ;
6. `cargo tauri dev -c crates/ksp-app-config-desk/tauri.conf.json` et parcours fonctionnel ;
7. **en dernier seulement**, `cargo tauri build -c crates/ksp-app-config-desk/tauri.conf.json`.
Le build Tauri déclenche lui-même le build frontend de production ; aucun `vite build` standalone n'est requis. `docs/rules/RULES_KSP.md` est mis à jour dans ce fix afin que cette règle ne dépende plus du seul plan `0.1.4`.
## Version technique
```text
workspace.package.version = 0.1.4-pre.18.fix.1
```
## Validation attendue
Depuis la racine :
```bash
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 test -p ksp-logging-lib
```
Puis :
```bash
cd crates/ksp-app-config-desk
npm run check
cd ../..
cargo tauri dev -c crates/ksp-app-config-desk/tauri.conf.json
```
Le parcours fonctionnel du registre spécialisé a déjà été validé sur `pre.018` ; un smoke test suffit après application du fix.
Après validation de **tout ce qui précède**, terminer par :
```bash
cargo tauri build -c crates/ksp-app-config-desk/tauri.conf.json
```
## Suite
Après validation de ce fix, `pre.018` peut être clôturée et `0.1.4-pre.019` peut commencer comme tranche finale de clôture de `0.1.4`.

66
docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md -->
<!-- version: 21 -->
<!-- version: 22 -->
# Plan `0.1.4` — `ksp-app-config-desk`
@@ -238,8 +238,8 @@ La gestion npm distingue le runtime frontend du tooling. Les bibliothèques cons
Chaque application Tauri desk KSP reçoit un couple de ports Vite/HMR propre. La première application réserve :
| Application | Port Vite HTTP | Port HMR |
|-----------------------|---------------:|---------:|
| `ksp-app-config-desk` | `1430` | `1431` |
| --------------------- | -------------: | -------: |
| `ksp-app-config-desk` | `1430` | `1431` |
Les applications suivantes incrémentent le couple de deux ports (`1432/1433`, puis `1434/1435`, etc.). Vite doit utiliser un port strict afin qu'une collision soit signalée au lieu de provoquer un basculement silencieux vers un autre port. Cette allocation permet de faire fonctionner simultanément plusieurs applications desk en mode développement.
@@ -249,20 +249,20 @@ Aucune dépendance n'est ajoutée par `pre.001`. Les versions suivantes ont ét
| Dépendance | Version actuelle auditée | Usage envisagé |
| ------------------------------- | -----------------------: | -------------------------------------------- |
| `tauri` | `2.11.5` | runtime desktop |
| `tauri-build` | `2.6.3` | build Tauri |
| `tauri-plugin-tracing` | `0.3.4` | intégration tracing à la frontière Tauri |
| `ts-rs` | `12.0.1` | bindings DTO applicatifs |
| `fs2` | `0.4.3` | verrou single-instance |
| `@fltsci/tauri-plugin-tracing` | `0.3.4` | package frontend compagnon du plugin tracing |
| `@tauri-apps/api` | `2.11.1` | frontend Tauri |
| `@tauri-apps/cli` | `2.11.4` | dev/build desktop |
| `@types/bootstrap` | `5.2.11` | typings Bootstrap |
| `vite` | `8.2.1` | build frontend |
| `typescript` | `7.0.2` | frontend TypeScript |
| `sass-embedded` | `1.102.0` | compilation SCSS |
| `bootstrap` | `5.3.8` | composants/layout |
| `@fortawesome/fontawesome-free` | `7.3.1` | iconographie |
| `tauri` | `2.11.5` | runtime desktop |
| `tauri-build` | `2.6.3` | build Tauri |
| `tauri-plugin-tracing` | `0.3.4` | intégration tracing à la frontière Tauri |
| `ts-rs` | `12.0.1` | bindings DTO applicatifs |
| `fs2` | `0.4.3` | verrou single-instance |
| `@fltsci/tauri-plugin-tracing` | `0.3.4` | package frontend compagnon du plugin tracing |
| `@tauri-apps/api` | `2.11.1` | frontend Tauri |
| `@tauri-apps/cli` | `2.11.4` | dev/build desktop |
| `@types/bootstrap` | `5.2.11` | typings Bootstrap |
| `vite` | `8.2.1` | build frontend |
| `typescript` | `7.0.2` | frontend TypeScript |
| `sass-embedded` | `1.102.0` | compilation SCSS |
| `bootstrap` | `5.3.8` | composants/layout |
| `@fortawesome/fontawesome-free` | `7.3.1` | iconographie |
Sources d'audit :
@@ -694,23 +694,23 @@ Le shell applique également une instrumentation frontend systématique : clics
Les noms ci-dessous sont les noms fonctionnels cibles ; ils pourront être normalisés avant implémentation, mais leurs responsabilités sont fixées.
| Commande Tauri | Service interne | API KSP principale | Secret réel ? |
| Commande Tauri | Service interne | API KSP principale | Secret réel ? |
| ------------------------------ | ------------------------------------ | --------------------------------------------------------------------------- | -------------------------------------------: |
| `get_app_snapshot` | `config_service` + `logging_service` | registry/management + runtime state | non |
| `list_config_documents` | `config_service` | future vue publique du `ConfigFileRegistry` | non |
| `inspect_config_document` | `config_service` | `load_validated_document` + `read_source` si erreur | non |
| `save_config_source_candidate` | `config_service` | future API Config de réparation validée | non |
| `inspect_profile` | `config_service` | `load_resolved_profile` + résolution détaillée | non |
| `get_environment_report` | `environment_service` | `ConfigManagement::environment_report` | non |
| `get_app_snapshot` | `config_service` + `logging_service` | registry/management + runtime state | non |
| `list_config_documents` | `config_service` | future vue publique du `ConfigFileRegistry` | non |
| `inspect_config_document` | `config_service` | `load_validated_document` + `read_source` si erreur | non |
| `save_config_source_candidate` | `config_service` | future API Config de réparation validée | non |
| `inspect_profile` | `config_service` | `load_resolved_profile` + résolution détaillée | non |
| `get_environment_report` | `environment_service` | `ConfigManagement::environment_report` | non |
| `set_dotenv_value` | `environment_service` | `ConfigManagement::set_dotenv_value` + rapport frais | entrée potentiellement Secret, jamais loggée |
| `remove_dotenv_value` | `environment_service` | `ConfigManagement::remove_dotenv_value` + rapport frais | non |
| `reveal_environment_value` | `secret_service` | `reveal_effective_environment_value` ou `reveal_dotenv_value` | **oui** |
| `get_logging_editor` | `logging_service` | `load_logging_document` | non |
| `save_logging_document` | `logging_service` | `save_logging_document` | non par design Logging |
| `apply_logging_profile` | `logging_service` | `ConfigEnvironment::load` + `load_resolved_logging_config` + `reinitialize` | valeurs resolved possibles, jamais DTO/log |
| `emit_frontend_log` | `frontend_logging_service` | façade `ksp-logging-lib` | non, message technique frontend seulement |
| `emit_logging_test` | `logging_service` | façade/macros `ksp-logging-lib` | non, message explicitement saisi pour test |
| `splash_frontend_ready` | `splash` | lifecycle Tauri + settings splash déjà résolus | non |
| `remove_dotenv_value` | `environment_service` | `ConfigManagement::remove_dotenv_value` + rapport frais | non |
| `reveal_environment_value` | `secret_service` | `reveal_effective_environment_value` ou `reveal_dotenv_value` | **oui** |
| `get_logging_editor` | `logging_service` | `load_logging_document` | non |
| `save_logging_document` | `logging_service` | `save_logging_document` | non par design Logging |
| `apply_logging_profile` | `logging_service` | `ConfigEnvironment::load` + `load_resolved_logging_config` + `reinitialize` | valeurs resolved possibles, jamais DTO/log |
| `emit_frontend_log` | `frontend_logging_service` | façade `ksp-logging-lib` | non, message technique frontend seulement |
| `emit_logging_test` | `logging_service` | façade/macros `ksp-logging-lib` | non, message explicitement saisi pour test |
| `splash_frontend_ready` | `splash` | lifecycle Tauri + settings splash déjà résolus | non |
Tous les wrappers dans `tauri.rs` :
@@ -1029,6 +1029,8 @@ Le shell applicatif matérialise désormais cette architecture dans `frontend/ts
Le bootstrap Logging sépare également la **résolution du plan de démarrage** de l'**installation du subscriber**. Une source invalide peut ainsi être testée comme plan fallback sans initialiser le subscriber global du binaire de tests.
La validation frontend de `pre.018` utilise `npm run check` pour **`tsc --noEmit` uniquement**. Le build Vite de production n'est pas lancé séparément : `cargo tauri build` déclenche déjà `npm run build` via `beforeBuildCommand`. Pour KSP, le build Tauri est réservé à la **dernière validation**, après `fmt/check/clippy`, les tests, le type-check frontend et le parcours fonctionnel `tauri dev`.
## 16. Stratégie de tests
### 16.1 `ksp-config-lib`

3
docs/rules/RULES_KSP.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/RULES_KSP.md -->
<!-- version: 29 -->
<!-- version: 30 -->
# Règles spécifiques à KSP
@@ -226,6 +226,7 @@
- **KSP-APP-031** — Le niveau de logging spécifique à une application/crate peut être élevé temporairement à `debug` ou `trace` pendant une phase de développement ou correction. Avant la clôture/release de cette application/crate, son niveau de référence est ramené à `info` ou `warn` selon le besoin opératoire ; il n’est remonté que lorsqu’un développement/correctif est explicitement rouvert.
- **KSP-APP-032** — Les interfaces desk KSP n’utilisent pas les dialogues bloquants natifs du navigateur (`window.alert`, `window.confirm`, `window.prompt`) pour les interactions applicatives normales. Les confirmations destructives ou privilégiées utilisent un modal Bootstrap intégré à l’UI, instrumenté par le bridge Logging ; toute exception doit être explicitement justifiée et documentée.
- **KSP-APP-033** — Un test d’une application ou d’un manager qui peut modifier un document Config du workspace ne traite jamais les valeurs courantes de ce document comme une fixture immuable. Les tests de valeurs exactes utilisent une fixture isolée ; les tests qui lisent la Config workspace vérifient uniquement des invariants, la validité et la cohérence source → résolution → runtime afin de rester valides après une édition légitime par Config Desk.
- **KSP-APP-034** — Pour une application Tauri KSP, un contrôle frontend standalone (`npm run check` ou équivalent) ne construit pas le bundle de production : il se limite au type-check/lint/tests frontend nécessaires. Le build frontend de production appartient au hook Tauri `beforeBuildCommand`. Dans une séquence de validation, `cargo tauri build -c crates/<app>/tauri.conf.json` est exécuté **en dernière opération**, uniquement après `fmt/check/clippy`, les tests, les contrôles frontend standalone et le parcours fonctionnel `cargo tauri dev`.
## Data plane / control plane