v0.1.4-pre.019
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/000-README.md -->
|
||||
<!-- version: 14 -->
|
||||
<!-- version: 15 -->
|
||||
|
||||
# Documentation KSP
|
||||
|
||||
@@ -39,6 +39,9 @@ docs/
|
||||
│ ├── 004-V0_1_2_LOGGING_FOUNDATION_PLAN.md
|
||||
│ ├── 005-V0_1_3_CONFIG_FOUNDATION_PLAN.md
|
||||
│ └── 006-V0_1_4_CONFIG_DESKTOP_PLAN.md
|
||||
├── validation/
|
||||
│ ├── 000-README.md
|
||||
│ └── 001-V0_1_4_CONFIG_DESKTOP.md
|
||||
└── rules/
|
||||
├── FILE_CONTRACTS.md
|
||||
├── PROMPT_STRUCTURE.md
|
||||
@@ -55,7 +58,7 @@ D'autres sous-répertoires seront ajoutés uniquement lorsque leur rôle aura é
|
||||
|
||||
## Documents de planification
|
||||
|
||||
Le plan historique de la phase fondatrice clôturée est conservé dans [`plans/001-V0_0_3_PLAN.md`](plans/001-V0_0_3_PLAN.md). La séquence active des premières releases fonctionnelles est définie dans [`plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md`](plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md). Le plan détaillé de la release stable `0.1.1` est conservé comme historique clôturé dans [`plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md`](plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.2` est conservé comme historique clôturé dans [`plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md`](plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.3 — Configuration foundation` est conservé comme historique clôturé dans [`plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md). La release active `0.1.4 — ksp-app-config-desk` est ouverte par `pre.001` et son plan détaillé est [`plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md`](plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md) ; son prompt d'ouverture reste [`../prompts/004-V0_1_4_START_PROMPT.md`](../prompts/004-V0_1_4_START_PROMPT.md).
|
||||
Le plan historique de la phase fondatrice clôturée est conservé dans [`plans/001-V0_0_3_PLAN.md`](plans/001-V0_0_3_PLAN.md). La séquence active des premières releases fonctionnelles est définie dans [`plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md`](plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md). Le plan détaillé de la release stable `0.1.1` est conservé comme historique clôturé dans [`plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md`](plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.2` est conservé comme historique clôturé dans [`plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md`](plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.3 — Configuration foundation` est conservé comme historique clôturé dans [`plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md). La release `0.1.4 — ksp-app-config-desk` est dans sa tranche finale `pre.019`; son plan détaillé est [`plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md`](plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md) et sa matrice de clôture est [`validation/001-V0_1_4_CONFIG_DESKTOP.md`](validation/001-V0_1_4_CONFIG_DESKTOP.md). Son prompt d'ouverture historique reste [`../prompts/004-V0_1_4_START_PROMPT.md`](../prompts/004-V0_1_4_START_PROMPT.md).
|
||||
|
||||
`IDEAS.md` conserve les pistes et questions qui ne sont pas encore des engagements du roadmap ni des décisions architecturales.
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/IDEAS.md -->
|
||||
<!-- version: 14 -->
|
||||
<!-- version: 15 -->
|
||||
|
||||
# Idées à explorer
|
||||
|
||||
@@ -304,6 +304,16 @@ Les workers sont des services autonomes. Une app manager devra donc disposer d'u
|
||||
|
||||
Ne pas créer de `ksp-ipc-api` générique avant de connaître les contraintes réelles du premier manager : plateforme, framing, discovery, authentication locale et lifecycle.
|
||||
|
||||
## Applications desktop — idées de diagnostic
|
||||
|
||||
### Réflexion Rust -> console WebKit
|
||||
|
||||
**Status :** Reporté hors `0.1.4`, à réévaluer au premier besoin de diagnostic WebView
|
||||
|
||||
Le bridge Config Desk validé en `0.1.4` couvre `console.*`/helpers frontend -> commande Tauri -> `ksp-logging-lib` tout en conservant l’affichage local dans la console WebKit. Le retour général des événements Rust vers la console WebKit n’est pas nécessaire au contrat fonctionnel actuel.
|
||||
|
||||
Si cette capacité devient utile, l’intégration doit être conçue dans la pile possédée par `ksp-logging-lib` afin de conserver un subscriber global unique. Elle doit vérifier explicitement l’absence de double émission et de boucle avec le bridge frontend avant toute adoption d’un mécanisme de type `WebviewLayer`/console attachée.
|
||||
|
||||
## Séquencement des releases futures
|
||||
|
||||
### Numérotation fine après `0.1.x`
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md -->
|
||||
<!-- version: 22 -->
|
||||
<!-- version: 23 -->
|
||||
|
||||
# Séquence des releases fonctionnelles KSP
|
||||
|
||||
@@ -38,7 +38,7 @@ Séquence par défaut :
|
||||
|
||||
`0.1.1`, `0.1.2` et `0.1.3` sont désormais des releases stables.
|
||||
|
||||
`0.1.4 — ksp-app-config-desk` est l'étape active suivante. Elle doit valider réellement la fondation Config et établir le modèle de référence des futures applications Tauri KSP sans déplacer la logique Config dans l'application.
|
||||
`0.1.4 — ksp-app-config-desk` a atteint sa tranche finale `pre.019`. Sa publication stable par `rel.001` doit intervenir seulement après la matrice finale ; elle établit le modèle de référence des futures applications Tauri KSP sans déplacer la logique Config dans l'application.
|
||||
|
||||
## `0.1.1` — Core foundation
|
||||
|
||||
@@ -440,3 +440,14 @@ prompts/001-V0_1_1_START_PROMPT.md
|
||||
0.1.2 — Logging foundation
|
||||
prompts/002-V0_1_2_START_PROMPT.md
|
||||
```
|
||||
|
||||
## Ouverture de `0.2.1`
|
||||
|
||||
Après publication stable de `0.1.4`, la session suivante s’ouvre avec :
|
||||
|
||||
```text
|
||||
0.2.1-pre.001
|
||||
prompts/005-V0_2_1_START_PROMPT.md
|
||||
```
|
||||
|
||||
Cette première prerelease reste une tranche de brainstorming/audit/planification. Elle doit réévaluer les dépendances réelles et sélectionner un **premier périmètre N2 borné** parmi Wallet, transport on-chain et Interface/wire au lieu d’implémenter les trois simultanément. La mission concrète de `0.2.1` est figée dans son plan après cette sélection.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md -->
|
||||
<!-- version: 22 -->
|
||||
<!-- version: 23 -->
|
||||
|
||||
# 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` :
|
||||
|
||||
@@ -1073,7 +1073,7 @@ selon la tranche.
|
||||
Le frontend reste suffisamment mince pour ne pas nécessiter dès le départ un framework de test lourd. Les validations minimum prévues :
|
||||
|
||||
- `tsc` strict ;
|
||||
- build Vite ;
|
||||
- build Vite uniquement via le `beforeBuildCommand` de la validation finale `cargo tauri build` ;
|
||||
- tests de fonctions pures TypeScript uniquement si une logique non triviale apparaît ;
|
||||
- parcours manuel reproductible du panneau `.env` (create/update/delete/reload/shadowing) ;
|
||||
- parcours manuel reproductible des panneaux et de la matrice Logging.
|
||||
@@ -1270,13 +1270,13 @@ pre.017 panneau Test Logging [réalisé]
|
||||
- preuve routing avant/après hot reload
|
||||
- preuve bridge frontend
|
||||
|
||||
pre.018 robustesse/extensibilité/tests desktop [en cours]
|
||||
pre.018 robustesse/extensibilité/tests desktop [réalisé]
|
||||
- invalid source au démarrage
|
||||
- audits secrets/Config ownership/tracing
|
||||
- tests frontend/Tauri/build
|
||||
- ajout futur file_id/editor sans refonte shell
|
||||
|
||||
pre.019 clôture
|
||||
pre.019 clôture [en cours]
|
||||
- fmt/check/clippy
|
||||
- tests ciblés + cargo test --workspace
|
||||
- cargo tree pertinents
|
||||
@@ -1291,6 +1291,13 @@ pre.019 clôture
|
||||
|
||||
Ce découpage est une **prévision**, pas une obligation de produire exactement dix-neuf prereleases. Lorsqu'une tranche atteint son objectif en moins de temps, elle peut absorber le début logique de la suivante ; lorsqu'elle dépasse 20 minutes de façon significative, elle doit préférentiellement être scindée plutôt que compressée. Un défaut déjà livré est corrigé par un `fix` conformément au workflow KSP.
|
||||
|
||||
### 18.1 État de clôture `pre.019`
|
||||
|
||||
La tranche finale remet la configuration Logging canonique à une baseline de release `info`/`warn`, retire le profil de test de la source de référence, ferme les TODO bloquants `0.1.4`, crée une matrice de validation durable sous `docs/validation/`, et prépare le prompt d’ouverture de `0.2.1-pre.001`.
|
||||
|
||||
La validation finale suit KSP-APP-034 : tous les contrôles Rust et frontend, puis le parcours `tauri dev`, puis **`cargo tauri build` en toute dernière opération**. `rel.001` ne doit être préparée qu’après succès de cette matrice.
|
||||
|
||||
|
||||
## 19. Dépendances et ordre d'introduction
|
||||
|
||||
Aucune dépendance n'est ajoutée par `pre.001`.
|
||||
@@ -1442,6 +1449,6 @@ Aucune question n'empêche d'ouvrir le développement après validation du prés
|
||||
2. nom exact et nombre minimal de variables splash Config/.env ;
|
||||
3. features Cargo minimales de Tauri/Tokio nécessaires au shell/splash ;
|
||||
4. détails du fallback Logging minimal utilisé uniquement lorsque la Config Logging ne peut pas être résolue au démarrage ;
|
||||
5. implémentation exacte du retour Rust -> console WebKit : `attachConsole()` est retenu comme capacité candidate, mais seulement après intégration d'une `tauri_plugin_tracing::WebviewLayer` dans le subscriber possédé par `ksp-logging-lib`; `interceptConsole()`/`takeoverConsole()` ne doivent pas doubler le bridge JS -> Rust KSP ni réintroduire des targets non conformes.
|
||||
5. retour Rust -> console WebKit : étudié à la clôture `pre.019` puis **reporté hors `0.1.4`**. Le bridge WebView -> Rust -> KSP et le panneau Test Logging couvrent le besoin fonctionnel de cette release. Une future réflexion Rust -> WebKit devra rester sous ownership de `ksp-logging-lib`, sans second subscriber, double émission ni boucle avec le bridge `console.*`.
|
||||
|
||||
Ces points doivent être résolus par code/tests dans les prereleases prévues, pas par contournement applicatif.
|
||||
|
||||
12
docs/validation/000-README.md
Normal file
12
docs/validation/000-README.md
Normal file
@@ -0,0 +1,12 @@
|
||||
<!-- file: docs/validation/000-README.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Validations KSP
|
||||
|
||||
Ce répertoire conserve les matrices de validation durables utilisées pour clôturer une release ou une capacité importante.
|
||||
|
||||
Les deltas restent l’historique autoritatif des livraisons ; une matrice de validation synthétise les critères et preuves attendues sans remplacer les deltas.
|
||||
|
||||
Documents :
|
||||
|
||||
- [`001-V0_1_4_CONFIG_DESKTOP.md`](001-V0_1_4_CONFIG_DESKTOP.md) — matrice finale de `0.1.4 — ksp-app-config-desk`.
|
||||
79
docs/validation/001-V0_1_4_CONFIG_DESKTOP.md
Normal file
79
docs/validation/001-V0_1_4_CONFIG_DESKTOP.md
Normal file
@@ -0,0 +1,79 @@
|
||||
<!-- file: docs/validation/001-V0_1_4_CONFIG_DESKTOP.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Validation finale `0.1.4` — Config Desk
|
||||
|
||||
## Objet
|
||||
|
||||
Cette matrice ferme fonctionnellement `ksp-app-config-desk` avant `0.1.4-rel.001`. Les preuves détaillées restent dans `deltas/0.1.4/` et dans les logs de validation opérateur.
|
||||
|
||||
## Fonctionnel déjà validé avant `pre.019`
|
||||
|
||||
- [X] splash -> fenêtre principale ;
|
||||
- [X] inventaire Documents depuis le registre Config ;
|
||||
- [X] diagnostic JSON/schema/sémantique/effective et réparation de source via Config ;
|
||||
- [X] inspection `default_profile`, profils, globals/effective et provenance sûre ;
|
||||
- [X] rapport Environnement sûr ;
|
||||
- [X] create/update/remove `.env` exclusivement via Config ;
|
||||
- [X] shadowing process > `.env` observable ;
|
||||
- [X] reveal Secret séparé, privilégié, transitoire et non persisté dans l’UI ;
|
||||
- [X] aucun `window.alert` / `window.confirm` / `window.prompt` applicatif ;
|
||||
- [X] éditeur Logging typé multi-profils, 0/1/N file sinks et target filters ;
|
||||
- [X] persistence atomique et hot reload immédiat ;
|
||||
- [X] rollback source/runtime sur échec ;
|
||||
- [X] profil runtime explicite distinct de `default_profile` ;
|
||||
- [X] génération runtime observable ;
|
||||
- [X] fichiers de logs distincts par lancement avec identité applicative + timestamp ;
|
||||
- [X] panneau Test Logging backend et bridge frontend ;
|
||||
- [X] routing `target`/`domain`/niveau démontré avant/après hot reload ;
|
||||
- [X] registre d’éditeurs spécialisés `file_id -> view` ;
|
||||
- [X] audit bootstrap fallback avant installation du subscriber ;
|
||||
- [X] audits Config ownership / Logging ownership / desktop security.
|
||||
|
||||
## Baseline de release `pre.019`
|
||||
|
||||
- [X] `std.logging.json` canonique revenu à `info`/`warn` ;
|
||||
- [X] profil de test manuel retiré de la source canonique ;
|
||||
- [X] TODO bloquants `0.1.4` fermés ;
|
||||
- [X] retour Rust -> console WebKit explicitement reporté hors `0.1.4` ;
|
||||
- [X] README/USAGE/plan/roadmap/prompt suivant synchronisés ;
|
||||
- [X] aucun `PRESENTATION.md` ajouté.
|
||||
|
||||
## Validation technique finale à exécuter sur `pre.019`
|
||||
|
||||
Exécuter dans cet ordre :
|
||||
|
||||
```bash
|
||||
cargo fmt --all
|
||||
cargo check --workspace
|
||||
cargo clippy --workspace --all-targets
|
||||
cargo test --workspace
|
||||
cargo tree -p ksp-app-config-desk
|
||||
cargo tree -p ksp-config-lib
|
||||
cargo tree -p ksp-logging-lib
|
||||
cd crates/ksp-app-config-desk
|
||||
npm run check
|
||||
cd ../..
|
||||
cargo tauri dev -c crates/ksp-app-config-desk/tauri.conf.json
|
||||
```
|
||||
|
||||
Parcours fonctionnel final minimum :
|
||||
|
||||
1. vérifier le démarrage et `active_profile=local_dev` ;
|
||||
2. vérifier que la baseline Logging affichée est `info`/`warn` ;
|
||||
3. Documents -> `cfg.std.logging` -> éditeur Logging ;
|
||||
4. vérifier Documents, Profils, Environnement et Logging sans mutation inattendue ;
|
||||
5. émettre un test Logging `info` backend et frontend ;
|
||||
6. confirmer qu’aucun profil de test manuel n’est présent dans la source canonique.
|
||||
|
||||
Lorsque tout ce qui précède est validé, exécuter **en toute dernière opération** :
|
||||
|
||||
```bash
|
||||
cargo tauri build -c crates/ksp-app-config-desk/tauri.conf.json
|
||||
```
|
||||
|
||||
Le build final doit produire les bundles attendus pour la plateforme. Aucun `vite build` standalone n’est exécuté avant lui.
|
||||
|
||||
## Passage à `rel.001`
|
||||
|
||||
`0.1.4-rel.001` peut être préparée uniquement après succès de cette séquence. La release finale synchronise `workspace.package.version = "0.1.4"`, le changelog stable, le statut roadmap/plan et le tag stable `v0.1.4` après validation du commit de release.
|
||||
Reference in New Issue
Block a user