diff --git a/CHANGELOG.md b/CHANGELOG.md new file mode 100644 index 0000000..67a6a86 --- /dev/null +++ b/CHANGELOG.md @@ -0,0 +1,18 @@ + + + +# Changelog KSP + +Ce changelog résume uniquement les releases KSP considérées comme stables, dans l'ordre chronologique décroissant. Les détails de chaque livraison restent dans `deltas/`. + +## 0.1.2 — Logging foundation — 2026-08-14 + +`0.1.2` stabilise `ksp-logging-lib` comme façade KSP unique de logging/tracing runtime. La release introduit les événements et spans KSP, le takeover des targets, le subscriber global unique, `LoggingSettings`, les sorties console/fichier non bloquantes, rotation, stripping ANSI, compteurs de lignes abandonnées, hot reload transactionnel et instrumentation async indépendante de l'executor. La stack `tracing`, `tracing-subscriber` et `tracing-appender` reste possédée exclusivement par Logging ; Tokio est limité aux tests réels d'instrumentation async. + +## 0.1.1 — Core foundation — 2026-08-14 + +`0.1.1` stabilise `ksp-core-lib` avec le contrat commun `ErrorCode` / `ErrorContext` / `Error` / `Result`, la primitive `Pubkey`, les Program IDs Solana fondamentaux possédés par KSP et leur registre canonique recherché/filtrable. La release fixe également la taxonomie de classification et la politique Cargo workspace utilisée par les crates suivantes. + +## 0.0.3 — Fondation architecture et règles — 2026-08-14 + +`0.0.3` clôt la phase fondatrice : nomenclature KSP, règles Rust/Cargo/documentation, architecture en couches, contrats des composants, workers/jobs/pipelines/scénarios/apps, politique de versions/deltas et séquence des premières releases fonctionnelles. Elle prépare explicitement l'ouverture de `0.1.1` sans ajouter de fonctionnalité métier Solana. diff --git a/Cargo.toml b/Cargo.toml index 1834e5f..39323a2 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -1,12 +1,12 @@ # file: Cargo.toml -# version: 59 +# version: 60 [workspace] resolver = "3" members = ["crates/ksp-config-lib", "crates/ksp-core-lib", "crates/ksp-logging-lib"] [workspace.package] -version = "0.1.3-pre.14" +version = "0.1.3-pre.15" edition = "2024" license = "MIT" repository = "https://git.sasedev.com/Sasedev/khadhroony-solana-project" diff --git a/README.md b/README.md index aeabd10..9c3bdb5 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,5 @@ - + # Khadhroony Solana Project @@ -51,6 +51,7 @@ Les besoins du trading constituent une priorité produit à court terme mais ne - [`RULES.md`](RULES.md) — index des règles normatives ; - [`ROADMAP.md`](ROADMAP.md) — trajectoire globale du projet ; +- [`CHANGELOG.md`](CHANGELOG.md) — synthèse des releases stables ; - [`docs/000-README.md`](docs/000-README.md) — point d'entrée de la documentation ; - [`docs/IDEAS.md`](docs/IDEAS.md) — idées et sujets à explorer ; - [`prompts/000-README.md`](prompts/000-README.md) — prompts de reprise ; diff --git a/crates/ksp-config-lib/README.md b/crates/ksp-config-lib/README.md new file mode 100644 index 0000000..57a11dc --- /dev/null +++ b/crates/ksp-config-lib/README.md @@ -0,0 +1,82 @@ + + + +# ksp-config-lib + +`ksp-config-lib` est le propriétaire unique de la configuration applicative KSP. + +La crate centralise les documents JSON, leurs schemas, les profils et compositions, les variables d'environnement `KSP_*` / `KSPB_*`, le fichier `.env`, la résolution effective et les mutations persistantes explicitement autorisées. + +## Responsabilités + +`ksp-config-lib` possède : + +- le bootstrap non récursif `config/` / `config/schemas/` et les overrides `--cfgpath` / `--schemapath` ; +- le registre logique `file_id -> filename` et les overrides `--filemap==` ; +- la lecture JSON et la validation JSON Schema Draft 2020-12 ; +- les invariants sémantiques KSP des documents connus ; +- les globals, `default_profile`, profils nommés et leur provenance ; +- les compositions génériques par `file_id`, sans dépendance à un filename physique ; +- le snapshot des variables process KSP/KSPB et la lecture de `./.env` ; +- la priorité `process > .env > fallback > missing` ; +- les placeholders `${NAME}` et `${NAME:-fallback}` ; +- la classification `Public`, `Internal`, `Secret` ; +- les représentations réelle et sûre/redacted ainsi que la provenance des valeurs résolues ; +- l'adapter du document Logging effectif vers `ksp_logging_lib::LoggingSettings` ; +- la surface de management pour inspecter les sources, modifier `std.logging.json`, consulter les rapports d'environnement, révéler explicitement une valeur réelle et modifier `.env` ; +- les écritures atomiques JSON/`.env` et la protection des permissions `.env` ; +- les audits workspace empêchant les bypass d'ownership Config et les oublis dans `.env.example`. + +## Ressources gérées dans `0.1.3` + +Le registre par défaut connaît : + +```text +cfg.std.logging -> config/std.logging.json +schema.std.logging -> config/schemas/std.logging.schema.json +schema.composite -> config/schemas/composite.schema.json +``` + +`config/examples/composite.example.json` démontre le format composite sans créer de composite runtime fictif. + +Le fichier local d'environnement est : + +```text +./.env +``` + +Il n'est ni versionné ni livré. Le dépôt maintient `/.env.example` comme inventaire versionné des variables runtime utilisées. Toute nouvelle variable KSP/KSPB concrète doit y être ajoutée avec un commentaire d'usage dans le même delta que sa première utilisation. + +## Frontières + +Les autres crates et applications KSP ne doivent pas : + +- lire directement les variables applicatives `KSP_*` / `KSPB_*` ; +- parser ou écrire directement `.env` ; +- ouvrir directement les documents Config connus par leur filename physique ; +- réimplémenter la sélection de profils, les compositions ou les placeholders ; +- reconstruire elles-mêmes la configuration Logging depuis le JSON. + +`ksp-config-lib` dépend de `ksp-core-lib` pour `Error`/`Result` et de `ksp-logging-lib` pour les événements Config utiles et le contrat `LoggingSettings`. + +La dépendance inverse est interdite : `ksp-core-lib` et `ksp-logging-lib` ne dépendent pas de Config. + +Config ne possède pas le `LoggingGuard`. L'application ou le service qui orchestre le runtime construit la configuration effective puis possède le lifecycle `ksp_logging_lib::initialize/reinitialize`. + +Tauri et les DTO TS-RS restent hors de cette crate. La future `ksp-app-config-desk` doit rester une frontière applicative mince au-dessus des APIs Config. + +## Secrets + +Un secret reste accessible au runtime ou au management lorsqu'un consumer autorisé en a réellement besoin, mais les vues ordinaires utilisent la représentation sûre. + +Les méthodes `reveal_*` constituent un opt-in explicite au réel. L'authentification/autorisation de l'utilisateur humain appartient à l'application appelante et les valeurs retournées par ces méthodes ne doivent jamais être journalisées. + +Le document Logging refuse les valeurs de sensibilité `Secret` dans sa configuration effective. + +## Documentation + +- [`USAGE.md`](USAGE.md) — construction du moteur, résolution runtime et management ; +- [`TODO.md`](TODO.md) — points explicitement différés après `0.1.3` ; +- [`../../docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](../../docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md) — plan historique détaillé de la fondation Config ; +- [`../../config/std.logging.json`](../../config/std.logging.json) — premier document standard concret ; +- [`../../.env.example`](../../.env.example) — inventaire versionné des variables d'environnement runtime. diff --git a/crates/ksp-config-lib/TODO.md b/crates/ksp-config-lib/TODO.md new file mode 100644 index 0000000..9e44b42 --- /dev/null +++ b/crates/ksp-config-lib/TODO.md @@ -0,0 +1,38 @@ + + + +# TODO ksp-config-lib + +## État de clôture `0.1.3` + +Aucun TODO fonctionnel bloquant n'est ouvert pour la fondation Config `0.1.3`. + +Les responsabilités prévues pour cette release sont implémentées et couvertes par les tests : bootstrap, registre `file_id`, JSON/JSON Schema, profils, composites, environnement process/`.env`, placeholders, sensibilité/provenance, adapter Logging, management/persistence et audits d'ownership. + +## Reporté explicitement à `0.1.4` + +La validation applicative desktop appartient à `ksp-app-config-desk` : + +- frontière Tauri et DTO TS-RS applicatifs ; +- affichage des sources et diagnostics Config ; +- sélection/inspection des profils ; +- affichage desired/effective/shadow des variables ; +- actions explicites de reveal de secrets avec contrôle d'autorisation côté application ; +- édition/sauvegarde de `std.logging.json` via `ConfigManagement` ; +- édition de `.env` via `ConfigManagement` ; +- orchestration réelle `Config -> LoggingSettings -> initialize/reinitialize` avec `LoggingGuard` possédé par l'application ; +- validation UX des erreurs de source invalide, des modifications non effectives car masquées par le process et des besoins de reload. + +Ces points ne nécessitent pas de duplication de logique dans `ksp-config-lib`; toute lacune réelle révélée par l'application ouvrira un delta Config explicite. + +## Futur, uniquement au besoin + +Les capacités suivantes sont différées jusqu'à l'apparition de composants réels : + +- nouveaux documents `std..json` et schemas associés ; +- descriptors `cfg.composite.` pour de vrais consumers ; +- contrats typés de management supplémentaires pour les nouveaux documents ; +- watcher filesystem/reload automatique si une application ou un service démontre le besoin ; +- intégration éventuelle d'un secrets manager externe. + +Ne pas introduire par anticipation un JSON patch arbitraire, un watcher générique, un service distribué de configuration ou un chiffrement maison de `.env`. diff --git a/crates/ksp-config-lib/USAGE.md b/crates/ksp-config-lib/USAGE.md new file mode 100644 index 0000000..45c8e22 --- /dev/null +++ b/crates/ksp-config-lib/USAGE.md @@ -0,0 +1,184 @@ + + + +# Utilisation de ksp-config-lib + +## 1. Bootstrap et moteur documentaire + +Config doit interpréter ses propres arguments de bootstrap avant toute lecture de document : + +```rust +let args: std::vec::Vec = std::env::args_os().collect(); + +let bootstrap = match ksp_config_lib::ConfigBootstrapOptions::from_args(args.as_slice()) { + std::result::Result::Ok(value) => value, + std::result::Result::Err(error) => return std::result::Result::Err(error), +}; + +let registry = match ksp_config_lib::ConfigFileRegistry::from_args(args.as_slice()) { + std::result::Result::Ok(value) => value, + std::result::Result::Err(error) => return std::result::Result::Err(error), +}; + +let engine = ksp_config_lib::ConfigDocumentEngine::new(bootstrap, registry); +``` + +Les arguments compris par Config sont : + +```text +--cfgpath=/path/to/config +--schemapath=/path/to/schemas +--filemap=cfg.std.logging=my-logging.json +``` + +`cfgpath` et `schemapath` ne sont jamais lus depuis JSON, `.env` ou une variable KSP : cette règle évite un bootstrap récursif. + +## 2. Charger et valider un document connu + +Les consumers utilisent un `file_id` logique : + +```rust +let file_id = match ksp_config_lib::ConfigFileId::new(ksp_config_lib::FILE_ID_STD_LOGGING) { + std::result::Result::Ok(value) => value, + std::result::Result::Err(error) => return std::result::Result::Err(error), +}; + +let document = engine.load_validated_document(&file_id); +``` + +Le moteur résout le path physique via le registre, charge le schema associé, valide le schema lui-même, valide l'instance puis applique les invariants sémantiques KSP. + +## 3. Environnement effectif + +`ConfigEnvironment::load()` capture les variables process KSP/KSPB et lit `./.env` : + +```rust +let environment = match ksp_config_lib::ConfigEnvironment::load() { + std::result::Result::Ok(value) => value, + std::result::Result::Err(error) => return std::result::Result::Err(error), +}; +``` + +La priorité est : + +```text +process environment > .env > fallback > missing +``` + +Une chaîne vide explicitement présente est une valeur définie ; elle ne provoque pas l'utilisation du fallback. + +Exemples de placeholders : + +```text +${KSP_LOGS_DIRECTORY} +${KSP_LOGS_DIRECTORY:-logs} +``` + +Pour conserver la sensibilité et la provenance, préférer les variantes détaillées : + +```rust +let resolved = environment.resolve_text_detailed("${KSP_SECRET_EXAMPLE}"); +``` + +`ResolvedConfigText` / `ResolvedConfigJson` séparent valeur réelle et valeur sûre. Une représentation `Debug` ne doit pas révéler le réel d'un secret. + +## 4. Construire Logging depuis Config + +Le chemin normal consiste à charger le profil Logging, résoudre l'environnement puis construire directement le contrat Logging public : + +```rust +let resolved = match engine.load_resolved_logging_config(std::option::Option::None, &environment) { + std::result::Result::Ok(value) => value, + std::result::Result::Err(error) => return std::result::Result::Err(error), +}; + +let settings = resolved.into_settings(); +let initialized = ksp_logging_lib::initialize(&settings); +let mut logging_guard = match initialized { + std::result::Result::Ok(value) => value, + std::result::Result::Err(error) => return std::result::Result::Err(error), +}; +``` + +L'application/service possède `logging_guard`. Config ne conserve pas de singleton Logging. + +Un `logs_directory` relatif est ancré sur le current working directory du processus. Un path absolu est conservé. Une valeur explicite invalide produit une erreur effective : elle ne retombe pas silencieusement sur le fallback du placeholder. + +Les `files[].path` restent relatifs sous le root Logging, y compris après interpolation. + +## 5. Profils et composites + +Pour un document standard profilé : + +```rust +let profile = engine.load_resolved_profile(&file_id, std::option::Option::None); +``` + +`None` utilise le `default_profile`; `Some("profile_id")` impose un profil explicite. + +Un composite référence les documents par `file_id`, jamais par filename. `load_resolved_composite(...)` conserve chaque `ResolvedConfigProfile` composant et sa provenance plutôt que d'aplatir plusieurs domaines dans une map ambiguë. + +## 6. Management de `std.logging.json` + +Une application de management construit la façade à partir d'un moteur : + +```rust +let management = ksp_config_lib::ConfigManagement::new(engine); + +let document = match management.load_logging_document() { + std::result::Result::Ok(value) => value, + std::result::Result::Err(error) => return std::result::Result::Err(error), +}; +``` + +Le type `LoggingConfigDocument` et ses sous-structures exposent des setters/mutators typés. Après modification, la sauvegarde : + +```rust +let saved = management.save_logging_document(&document); +``` + +valide le candidat complet avant toute substitution du fichier. Un candidat invalide ne remplace pas la source existante. + +`read_source(file_id)` reste disponible pour une UI de réparation : il peut lire le texte brut d'un document enregistré même lorsque son JSON ou son schema est invalide. Il n'ouvre pas un path arbitraire. + +## 7. Management de `.env` + +Les rapports ordinaires sont sûrs : + +```rust +let report = management.environment_report(); +``` + +Ils distinguent notamment valeur souhaitée `.env`, valeur effective, source et shadowing process sans exposer un secret réel. + +L'accès au réel est volontairement explicite : + +```rust +let effective = management.reveal_effective_environment_value("KSP_SECRET_EXAMPLE"); +let persisted = management.reveal_dotenv_value("KSP_SECRET_EXAMPLE"); +``` + +Une application doit contrôler l'autorisation de l'utilisateur avant ces appels et ne jamais journaliser les valeurs retournées. + +Les mutations persistantes utilisent : + +```rust +let changed = management.set_dotenv_value("KSP_LOGS_DIRECTORY", "logs"); +let removed = management.remove_dotenv_value("KSP_LOGS_DIRECTORY"); +``` + +Elles n'altèrent jamais l'environnement hérité du processus. Une valeur process peut donc masquer une modification `.env`; `ConfigEnvironmentChangeReport` distingue `source_changed`, `effective_changed`, `shadowed_by_process_environment` et `reload_required`. + +Sur Unix, un nouveau `.env` est créé avec des permissions privées `0600`; les permissions existantes sont préservées lors des remplacements atomiques. + +## 8. `.env.example` + +`/.env.example` est l'inventaire versionné. `/.env` reste local et ignoré. + +Toute nouvelle variable runtime concrète `KSP_*` / `KSPB_*` introduite dans le code ou les documents Config doit être ajoutée à `.env.example` avec un commentaire expliquant son usage. Les audits `ksp-config-lib/tests/ownership.rs` font échouer `cargo test` lorsqu'une clé concrète est oubliée. + +## 9. Frontière Tauri + +Une application Tauri doit appeler les APIs ci-dessus via ses commandes/DTO applicatifs. Elle ne lit ni JSON ni `.env` directement et ne résout jamais elle-même les placeholders. + +Les valeurs `Secret` ne doivent pas être incluses par défaut dans les DTO publics. Une action UI explicitement autorisée peut appeler une méthode `reveal_*` et transporter le résultat par un DTO spécifique, sans log ni diagnostic contenant la valeur réelle. diff --git a/crates/ksp-config-lib/src/lib.rs b/crates/ksp-config-lib/src/lib.rs index 3f7c77f..61c8938 100644 --- a/crates/ksp-config-lib/src/lib.rs +++ b/crates/ksp-config-lib/src/lib.rs @@ -1,15 +1,15 @@ // file: crates/ksp-config-lib/src/lib.rs -// version: 9 +// version: 10 #![warn(missing_docs)] #![deny(unreachable_pub)] #![forbid(unsafe_code)] //! KSP-owned application configuration facade. //! -//! `0.1.3-pre.013` owns bootstrap roots, the logical file registry, generic JSON/JSON Schema loading, standard-document profile resolution, generic composite -//! resolution and KSP/KSPB environment resolution through process + `.env` + fallback precedence. The standard Logging document remains the first registered -//! runtime document. Environment-derived values preserve real/safe representations, sensitivity and provenance; the standard Logging profile can now be -//! mapped explicitly to `ksp_logging_lib::LoggingSettings`. Explicit management now owns typed Logging mutation, safe environment reports, privileged reveal calls and atomic JSON/`.env` persistence. +//! The `0.1.3` surface owns bootstrap roots, the logical file registry, JSON/JSON Schema validation, standard-document profiles, generic composites and +//! KSP/KSPB environment resolution through process + `.env` + fallback precedence. Resolved values preserve real/safe representations, sensitivity and +//! provenance. The standard Logging document maps explicitly to `ksp_logging_lib::LoggingSettings`, while the management surface provides typed Logging +//! mutation, safe environment reports, explicit privileged reveal calls and atomic JSON/`.env` persistence. mod bootstrap; mod composite; diff --git a/deltas/0.1.3/pre.015.md b/deltas/0.1.3/pre.015.md new file mode 100644 index 0000000..5cc09a2 --- /dev/null +++ b/deltas/0.1.3/pre.015.md @@ -0,0 +1,242 @@ + + + +# Delta 0.1.3-pre.015 — clôture Config + +## Base requise + +Livraison précédente validée : + +```text +0.1.3-pre.014 +workspace.package.version = "0.1.3-pre.14" +Cargo.toml header version = 59 +``` + +## Validation de `pre.014` + +Validations utilisateur exécutées le 2026-08-16 : + +```text +cargo fmt --all OK +cargo check --workspace OK +cargo clippy --workspace --all-targets OK +cargo test --workspace OK +cargo tree -p ksp-config-lib OK +cargo tree -p ksp-config-lib -d OK, doublon transitif syn 2/3 connu via jsonschema +cargo tree -p ksp-config-lib -e features OK +cargo tree -p ksp-logging-lib -d OK, aucun doublon +``` + +Le test workspace confirme : + +```text +ksp-config-lib unit tests 80 passed +Config ownership integration 4 passed +Config public API 11 passed +ksp-core-lib unit 14 passed +Core public API 3 passed +ksp-logging-lib unit 34 passed +Logging integrations all passed +``` + +## Objet de `pre.015` + +`pre.015` est la prerelease finale prévue de `0.1.3`. + +Elle ne développe aucune nouvelle capacité Config. Elle : + +- consolide la documentation durable de `ksp-config-lib` ; +- ferme ou reporte explicitement les TODO de release ; +- introduit le changelog général selon les règles déjà définies ; +- prépare le prompt de `0.1.4 — ksp-app-config-desk` ; +- réaligne les index et plans ; +- prépare les validations finales précédant `rel.001` ; +- confirme qu'aucun cleanup destructif supplémentaire n'est nécessaire. + +## Version technique + +Conformément à `VER-ID-009`, une prerelease non-fix synchronise toujours la version Cargo, même lorsque la tranche est principalement documentaire : + +```text +workspace.package.version = "0.1.3-pre.15" +Cargo.toml header version = 60 +``` + +Aucune dépendance ni feature Cargo ne change. + +## Documentation durable de `ksp-config-lib` + +Ajout de : + +```text +crates/ksp-config-lib/README.md +crates/ksp-config-lib/USAGE.md +crates/ksp-config-lib/TODO.md +``` + +Le README décrit les responsabilités et frontières stabilisées de Config. + +`USAGE.md` documente : + +- bootstrap + registre ; +- chargement/validation ; +- environnement effectif ; +- mapping Logging ; +- profils/composites ; +- management du document Logging ; +- management `.env` ; +- secret reveal explicite ; +- `.env.example` ; +- frontière Tauri. + +`TODO.md` confirme qu'aucun TODO fonctionnel bloquant ne reste dans `0.1.3`. Les validations desktop/Tauri sont transférées à `0.1.4`; les futurs documents/composites/watchers restent conditionnés à l'apparition d'un besoin concret. + +Le crate-level Rustdoc est rendu durable et ne décrit plus la surface comme limitée à `pre.013`. + +## Changelog général + +Ajout de : + +```text +CHANGELOG.md +``` + +Il applique `DOC-ROOT-008` : uniquement les releases stables et ordre décroissant. + +Il contient à cette étape : + +```text +0.1.2 +0.1.1 +0.0.3 +``` + +`0.1.3` n'y figure pas encore car `pre.015` n'est pas une release stable. Son entrée sera ajoutée dans `rel.001` après validation finale. + +## Prompt `0.1.4` + +Ajout de : + +```text +prompts/004-V0_1_4_START_PROMPT.md +``` + +Le prompt ne doit être utilisé qu'après publication stable `v0.1.3`. + +Il impose que `0.1.4-pre.001` commence par brainstorming + audit + planification, avant tout développement Tauri significatif, et cadre notamment : + +- application `ksp-app-config-desk` mince au-dessus de Config ; +- DTO/Tauri à la frontière applicative ; +- management de documents/profils/env ; +- reveal de secrets explicitement privilégié ; +- ownership applicatif du `LoggingGuard` ; +- tests et découpage des prereleases ; +- hors-scope de la release. + +## Cleanup / archivage + +Aucune suppression n'est nécessaire. + +Sont conservés intentionnellement : + +- tous les deltas `0.1.3` et leurs fixes ; +- les plans historiques `0.1.1`/`0.1.2` ; +- le plan `0.1.3` ; +- les prompts historiques ; +- les schemas et exemples Config ; +- `.env.example`. + +Le fichier local `.env` reste ignoré, non échangé et absent du delta. + +Aucun `Cargo.lock`, cache, build output ou archive imbriquée n'est ajouté. + +## TODO et reports + +Audit du code Config avant livraison : aucun marqueur `TODO`, `FIXME`, `XXX` ou `HACK` n'est présent dans les sources/manifest de la crate. + +Les reports utiles sont documentés dans `crates/ksp-config-lib/TODO.md` et concernent principalement : + +- validation desktop `0.1.4` ; +- futurs documents standards quand leurs composants existent ; +- composites de consumers réels ; +- watcher/reload automatique uniquement si un besoin concret l'exige ; +- éventuel secrets manager externe plus tard. + +Aucun de ces reports ne bloque `0.1.3`. + +## Fichiers ajoutés + +```text +CHANGELOG.md +crates/ksp-config-lib/README.md +crates/ksp-config-lib/TODO.md +crates/ksp-config-lib/USAGE.md +prompts/004-V0_1_4_START_PROMPT.md +deltas/0.1.3/pre.015.md +``` + +## Fichiers modifiés + +```text +Cargo.toml +README.md +crates/ksp-config-lib/src/lib.rs +docs/000-README.md +docs/plans/000-README.md +docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md +docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md +prompts/000-README.md +``` + +## Fichiers supprimés + +Aucun. + +## Validations finales demandées + +```bash +cargo fmt --all +cargo check --workspace +cargo build -p ksp-config-lib +cargo clippy --workspace --all-targets +cargo test --workspace +cargo test -p ksp-config-lib --test ownership +cargo tree -p ksp-config-lib +cargo tree -p ksp-config-lib -d +cargo tree -p ksp-config-lib -e features +cargo tree -p ksp-config-lib -e normal +cargo tree -p ksp-logging-lib -d +``` + +Vérifier également localement qu'aucun `.env` réel n'est suivi/ajouté au commit. + +## Étape suivante après validation + +Si `pre.015` est propre, préparer : + +```text +0.1.3-rel.001 +``` + +avec : + +```text +workspace.package.version = "0.1.3" +``` + +`rel.001` devra : + +- enregistrer les validations finales de `pre.015` ; +- ajouter la synthèse stable `0.1.3` à `CHANGELOG.md` en tête ; +- marquer `0.1.3` `[X]` dans `ROADMAP.md` ; +- classer le plan `005` comme historique clôturé ; +- réaligner les index/séquence ; +- ne modifier aucune surface fonctionnelle ; +- préparer le commit stable et, après validation, le tag `v0.1.3`. + +La session suivante peut ensuite démarrer avec : + +```text +prompts/004-V0_1_4_START_PROMPT.md +``` diff --git a/docs/000-README.md b/docs/000-README.md index 9915b25..429f222 100644 --- a/docs/000-README.md +++ b/docs/000-README.md @@ -1,5 +1,5 @@ - + # Documentation KSP @@ -36,7 +36,8 @@ docs/ │ ├── 001-V0_0_3_PLAN.md │ ├── 002-FUNCTIONAL_RELEASE_SEQUENCE.md │ ├── 003-V0_1_1_CORE_FOUNDATION_PLAN.md -│ └── 004-V0_1_2_LOGGING_FOUNDATION_PLAN.md +│ ├── 004-V0_1_2_LOGGING_FOUNDATION_PLAN.md +│ └── 005-V0_1_3_CONFIG_FOUNDATION_PLAN.md └── rules/ ├── FILE_CONTRACTS.md ├── PROMPT_STRUCTURE.md @@ -53,7 +54,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 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 `0.1.3 — Configuration foundation` est conservé dans [`plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md) et entre en clôture avec `pre.015`, avant publication stable `rel.001`. `IDEAS.md` conserve les pistes et questions qui ne sont pas encore des engagements du roadmap ni des décisions architecturales. diff --git a/docs/plans/000-README.md b/docs/plans/000-README.md index de0db27..ebcc1f0 100644 --- a/docs/plans/000-README.md +++ b/docs/plans/000-README.md @@ -1,5 +1,5 @@ - + # Plans KSP @@ -13,7 +13,7 @@ Un plan décrit le périmètre, les décisions déjà acquises, les questions ou - [`002-FUNCTIONAL_RELEASE_SEQUENCE.md`](002-FUNCTIONAL_RELEASE_SEQUENCE.md) — séquence active de référence des premières releases fonctionnelles ; - [`003-V0_1_1_CORE_FOUNDATION_PLAN.md`](003-V0_1_1_CORE_FOUNDATION_PLAN.md) — plan historique clôturé de la release stable `0.1.1`, établi par `0.1.1-pre.001` puis consolidé jusqu'à `0.1.1-rel.001`. - [`004-V0_1_2_LOGGING_FOUNDATION_PLAN.md`](004-V0_1_2_LOGGING_FOUNDATION_PLAN.md) — plan historique clôturé de la release stable `0.1.2`, établi par `0.1.2-pre.001` puis consolidé jusqu'à `0.1.2-rel.001`. -- [`005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](005-V0_1_3_CONFIG_FOUNDATION_PLAN.md) — plan actif de `0.1.3 — Configuration foundation`, établi par `0.1.3-pre.001`, corrigé par `pre.001-fix.001`, complété par `pre.001-fix.002` pour le registre `file_id`/bootstrap/non-régression Logging, regranularisé par `pre.001-fix.003`, puis rescindé pendant `pre.005`; `pre.006` a fermé le routing structuré `domain`, `pre.007` le moteur JSON/JSON Schema et le premier `std.logging.json`, `pre.008` la résolution globals/profils/`default_profile`, puis `pre.009` les compositions génériques par `file_id`; `pre.010` a livré `.env`, process env, `.env.example` et le resolver `${...}`; `pre.011` ajoute sensibilité, valeur réelle/sûre, redaction et provenance; `pre.012` a livré l'adapter Config -> Logging et la validation effective des chemins Logging; `pre.013` a livré management/persistence JSON/.env; `pre.014` ajoute les ownership audits exécutables et la vérification automatique de `.env.example`; `pre.015` assurera la clôture. +- [`005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](005-V0_1_3_CONFIG_FOUNDATION_PLAN.md) — plan de `0.1.3 — Configuration foundation`, établi par `0.1.3-pre.001` puis exécuté jusqu'à `pre.014`; `pre.015` consolide la documentation, ferme les TODO de release, prépare le prompt `0.1.4` et place la version en attente de validation finale avant `rel.001`. Le `pre.001` de chaque release fonctionnelle peut introduire son propre plan détaillé lorsque la release s'ouvre. diff --git a/docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md b/docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md index 8bceeb7..fcc2ef4 100644 --- a/docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md +++ b/docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md @@ -1,5 +1,5 @@ - + # Séquence des releases fonctionnelles KSP @@ -219,7 +219,35 @@ pre.015 clôture Cette prévision n'est pas un plafond : chaque prerelease doit rester une petite tranche, avec scission explicite si l'objectif dépasse environ 15–20 minutes de travail effectif. -`pre.006` a fermé le routing Logging structuré `domain`; `pre.007` a livré le moteur JSON/JSON Schema et `std.logging.json`; `pre.008` a ajouté la résolution générique globals/profils/`default_profile`; `pre.009` a ajouté les compositions génériques par `file_id`, avec `schema.composite` mais sans composite runtime fictif; `pre.010` a ajouté le snapshot process + `.env`, `.env.example` et le resolver `${...}`; `pre.011` a ajouté sensibilité, valeurs réelle/sûre, redaction et provenance enrichie; `pre.012` a livré l'adapter Config -> Logging, la validation effective de `logs_directory`/`files[].path` et le contrat de non-usage des secrets par Logging. `pre.013` a livré management + persistence JSON/.env avec source typée Logging, reports desired/effective/shadow, reveal explicite et écriture atomique. `pre.014` ajoute les audits exécutables d'ownership Config, verrouille la direction Core/Logging ->/ Config, interdit les lectures directes KSP/KSPB et les noms physiques gérés hors Config, puis vérifie automatiquement la couverture de `.env.example`. Après validation, `pre.015` ouvrira la clôture. +`pre.006` a fermé le routing Logging structuré `domain`; `pre.007` a livré le moteur JSON/JSON Schema et `std.logging.json`; `pre.008` a ajouté la résolution générique globals/profils/`default_profile`; `pre.009` les compositions génériques par `file_id`; `pre.010` le snapshot process + `.env`, `.env.example` et le resolver `${...}`; `pre.011` la sensibilité, les valeurs réelle/sûre, la redaction et la provenance enrichie; `pre.012` l'adapter Config -> Logging et la validation effective des chemins; `pre.013` management + persistence JSON/.env; `pre.014` les audits exécutables d'ownership et la couverture automatique de `.env.example`. `pre.015` constitue la prerelease finale : documentation durable de la crate, synthèse changelog, prompt `0.1.4`, clôture des TODO et préparation de `rel.001`. + +Trajectoire réellement suivie : + +```text +pre.001 brainstorming + audit + plan détaillé +pre.001-fix.001..003 corrections de cadrage, file_id/bootstrap et granularité +pre.002 crate Config + bootstrap cfgpath/schemapath +pre.002-fix.001 correction de la première tranche Config +pre.003 registre file_id + --filemap +pre.004 Logging contracts/settings multi-output +pre.005 Logging runtime multi-sink + routing level/target/formats +pre.005-fix.001 correction du test JSON runtime +pre.006 Logging routing structuré domain +pre.007 moteur JSON/JSON Schema + std.logging.json +pre.008 globals + profils + default_profile +pre.009 compositions génériques par file_id +pre.009-fix.001 correction Clippy du test composite +pre.010 process env + .env + placeholders + .env.example +pre.010-fix.001 correction des racines de fixtures de test +pre.011 sensibilité + real/safe/provenance +pre.011-fix.001 correction Clippy du test de provenance +pre.012 adapter Config -> Logging +pre.013 management + persistence JSON/.env +pre.013-fix.001 correction de syntaxe du warning persistence +pre.014 ownership audits + robustesse +pre.015 clôture/docs/prompt 0.1.4 +rel.001 publication stable après validation +``` ## `0.1.4` — Config desktop par défaut diff --git a/docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md b/docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md index b5df248..aa15e08 100644 --- a/docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md +++ b/docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md @@ -1,11 +1,11 @@ - + # Plan `0.1.3` — Configuration foundation ## 1. Statut et objectif -Ce plan a été établi par `0.1.3-pre.001`, corrigé par `0.1.3-pre.001-fix.001/.002/.003`, puis exécuté par petites tranches. `pre.002` a livré le bootstrap Config, `pre.003` le registre `file_id`, `pre.004` les contrats publics multi-output de Logging, `pre.005` le runtime multi-sink sur niveau/target/formats, `pre.006` le routing structuré `domain`, `pre.007` le moteur JSON/JSON Schema, `pre.008` la résolution des globals/profils/`default_profile`, `pre.009` les compositions génériques par `file_id`, `pre.010` le snapshot process + `.env` et le resolver `${...}`, `pre.011` la sensibilité et les représentations real/safe/provenance, puis `pre.012` l'adapter Config -> Logging. `pre.013` a livré management + persistence JSON/.env et son `fix.001` a corrigé la syntaxe du warning de cleanup. `pre.014` livre maintenant les ownership audits exécutables et la robustesse de frontière. La prochaine tranche est `pre.015` pour la clôture. +Ce plan a été établi par `0.1.3-pre.001`, corrigé par `0.1.3-pre.001-fix.001/.002/.003`, puis exécuté par petites tranches. `pre.002` a livré le bootstrap Config, `pre.003` le registre `file_id`, `pre.004` les contrats publics multi-output de Logging, `pre.005` le runtime multi-sink sur niveau/target/formats, `pre.006` le routing structuré `domain`, `pre.007` le moteur JSON/JSON Schema, `pre.008` la résolution des globals/profils/`default_profile`, `pre.009` les compositions génériques par `file_id`, `pre.010` le snapshot process + `.env` et le resolver `${...}`, `pre.011` la sensibilité et les représentations real/safe/provenance, puis `pre.012` l'adapter Config -> Logging. `pre.013` a livré management + persistence JSON/.env et son `fix.001` a corrigé la syntaxe du warning de cleanup. `pre.014` a livré les ownership audits exécutables et la robustesse de frontière puis a été validée intégralement par l'utilisateur. `pre.015` est la prerelease finale : elle consolide la documentation durable, ferme/reporte explicitement les TODO, introduit le changelog général stable, prépare le prompt `0.1.4` et place `0.1.3` en attente de `rel.001`. La base auditée reste la release stable `v0.1.2`. @@ -1880,12 +1880,20 @@ La validation utilisateur de `pre.013-fix.001` est acquise le 2026-08-16 : `fmt/ ### `0.1.3-pre.015` — clôture -- validations finales ; -- documentation durable ; -- cleanup/archivage requis ; -- TODO fermés ou reportés ; -- prompt `0.1.4 — ksp-app-config-desk` ; -- préparation `rel.001` puis tag stable après validation utilisateur. +Tranche livrée : + +- validation utilisateur de `pre.014` enregistrée : `fmt/check/clippy/test` propres, 80 tests unitaires Config, 4 audits ownership, 11 tests publics et aucun doublon dans le graphe Logging ; +- `workspace.package.version = "0.1.3-pre.15"` comme signal technique de la prerelease finale ; +- documentation durable `ksp-config-lib/README.md`, `USAGE.md` et `TODO.md` ; +- `CHANGELOG.md` général introduit selon les règles existantes avec uniquement les releases déjà stables `0.1.2`, `0.1.1` et `0.0.3`; `0.1.3` n'y sera ajouté qu'au `rel.001` ; +- index README/docs/plans/prompts réalignés ; +- prompt final `prompts/004-V0_1_4_START_PROMPT.md` préparé pour ouvrir `ksp-app-config-desk` uniquement après publication stable `v0.1.3` ; +- aucun TODO fonctionnel bloquant `0.1.3` trouvé dans la crate ; les validations Tauri/desktop sont reportées explicitement à `0.1.4`, les futurs documents/composites/watchers restant conditionnés à un besoin concret ; +- aucun cleanup ou archivage destructif nécessaire : les deltas historiques, schemas, exemples et prompts historiques restent intentionnellement conservés ; +- aucune nouvelle API, dépendance, variable runtime ou ressource Config exécutable ; +- `ROADMAP.md` reste en `[/]` pour `0.1.3` jusqu'à validation de cette prerelease et publication `rel.001`. + +Après validation de `pre.015`, la seule étape de `0.1.3` est la livraison `rel.001` : passage Cargo à `0.1.3`, synchronisation du changelog/roadmap/plans, puis tag `v0.1.3` sur le commit stable validé. Le découpage reste souple. Tout dépassement du budget de tranche est corrigé par une nouvelle scission explicite ; le nombre de prereleases n'est pas une cible à minimiser. @@ -1915,11 +1923,15 @@ Au minimum : ```bash cargo fmt --all cargo check --workspace +cargo build -p ksp-config-lib cargo clippy --workspace --all-targets cargo test --workspace +cargo test -p ksp-config-lib --test ownership cargo tree -p ksp-config-lib cargo tree -p ksp-config-lib -d cargo tree -p ksp-config-lib -e features +cargo tree -p ksp-config-lib -e normal +cargo tree -p ksp-logging-lib -d ``` Exécuter aussi tout script d'audit réellement présent au moment de la clôture. diff --git a/prompts/000-README.md b/prompts/000-README.md index 1fe4bc0..fe9a4d2 100644 --- a/prompts/000-README.md +++ b/prompts/000-README.md @@ -1,5 +1,5 @@ - + # Prompts KSP @@ -23,4 +23,5 @@ Le prompt générique `0.1.x` a été affiné pendant `0.0.3` puis remplacé par - [`001-V0_1_1_START_PROMPT.md`](001-V0_1_1_START_PROMPT.md) — prompt historique ouvrant la première release fonctionnelle `0.1.1` après publication stable de `0.0.3` ; - [`002-V0_1_2_START_PROMPT.md`](002-V0_1_2_START_PROMPT.md) — prompt final destiné à ouvrir `0.1.2 — Logging foundation` après publication stable de `0.1.1`. -- [`003-V0_1_3_START_PROMPT.md`](003-V0_1_3_START_PROMPT.md) — prompt final destiné à ouvrir `0.1.3 — Configuration foundation` après publication stable de `0.1.2`. +- [`003-V0_1_3_START_PROMPT.md`](003-V0_1_3_START_PROMPT.md) — prompt historique destiné à ouvrir `0.1.3 — Configuration foundation` après publication stable de `0.1.2` ; +- [`004-V0_1_4_START_PROMPT.md`](004-V0_1_4_START_PROMPT.md) — prompt final destiné à ouvrir `0.1.4 — ksp-app-config-desk` après publication stable de `0.1.3`. diff --git a/prompts/004-V0_1_4_START_PROMPT.md b/prompts/004-V0_1_4_START_PROMPT.md new file mode 100644 index 0000000..f53abc4 --- /dev/null +++ b/prompts/004-V0_1_4_START_PROMPT.md @@ -0,0 +1,244 @@ + + + +# Prompt de démarrage `0.1.4` — ksp-app-config-desk + +## 1. Mission + +Ouvrir `0.1.4` uniquement après publication et tag validés de `v0.1.3`. + +La mission de cette release est d'introduire `ksp-app-config-desk`, première application desktop spécialisée KSP, afin de valider réellement `ksp-config-lib` et la frontière Tauri sans déplacer la logique Config dans l'application. + +La **première prerelease `0.1.4-pre.001` doit être consacrée au brainstorming, à l'audit et au plan détaillé**. Ne pas commencer directement par une implémentation Tauri dispersée. Le `pre.001` doit décider les écrans, commandes, DTO, lifecycle Logging, risques secrets, packaging et découpage des prereleases avant le développement fonctionnel. + +## 2. Base requise + +Base stable attendue : + +```text +v0.1.3 +workspace.package.version = "0.1.3" +``` + +Le workspace doit contenir au minimum : + +```text +crates/ksp-core-lib +crates/ksp-logging-lib +crates/ksp-config-lib +config/std.logging.json +config/schemas/std.logging.schema.json +config/schemas/composite.schema.json +config/examples/std.logging.example.json +config/examples/composite.example.json +.env.example +``` + +Avant toute modification, relire : + +```text +README.md +RULES.md +ROADMAP.md +CHANGELOG.md +docs/000-README.md +docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md +docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md +crates/ksp-config-lib/README.md +crates/ksp-config-lib/USAGE.md +crates/ksp-config-lib/TODO.md +crates/ksp-logging-lib/README.md +crates/ksp-logging-lib/USAGE.md +``` + +Relire également les règles Tauri/Rust/documentation avant de choisir la structure finale de l'application. + +## 3. Surface Config stable à réutiliser + +`ksp-config-lib 0.1.3` possède déjà : + +- `ConfigBootstrapOptions` et les arguments `--cfgpath` / `--schemapath` ; +- `ConfigFileRegistry`, `ConfigFileId` et `--filemap` ; +- `ConfigDocumentEngine` ; +- validation JSON/JSON Schema et invariants sémantiques ; +- globals, profils, `default_profile` et provenance ; +- composites génériques par `file_id` ; +- `ConfigEnvironment` avec priorité process > `.env` > fallback ; +- `${NAME}` / `${NAME:-fallback}` ; +- `Public` / `Internal` / `Secret`, real/safe/provenance ; +- `ResolvedLoggingConfig` et le mapping vers `ksp_logging_lib::LoggingSettings` ; +- `ConfigManagement` ; +- lecture source brute d'un `file_id` connu ; +- `LoggingConfigDocument` et ses sous-contrats typés mutables ; +- persistence atomique de `std.logging.json` ; +- rapports d'environnement desired/effective/shadow ; +- `reveal_effective_environment_value()` / `reveal_dotenv_value()` comme frontières explicites d'accès au réel ; +- `set_dotenv_value()` / `remove_dotenv_value()` ; +- audits workspace de non-contournement Config et couverture `.env.example`. + +L'application doit **consommer ces APIs**, pas reproduire leur comportement. + +## 4. Architecture cible à auditer pendant `pre.001` + +Direction attendue : + +```text +ksp-app-config-desk + -> ksp-config-lib + -> ksp-logging-lib + -> ksp-core-lib via les contrats KSP nécessaires +``` + +L'application est une composition/interface. Elle ne devient pas propriétaire : + +- du parsing JSON ; +- des schemas ; +- de `.env` ; +- des placeholders ; +- de la classification des secrets ; +- du mapping Logging ; +- de la persistence Config. + +La structure sous `apps/` et l'intégration au workspace doivent être confirmées dans le plan `pre.001` à partir des règles KSP actives et des contraintes Tauri actuelles. + +## 5. Capacités desktop à valider + +Le brainstorming `pre.001` doit au minimum cadrer une UI permettant de tester réellement : + +### Documents et diagnostics + +- afficher les documents Config enregistrés par `file_id` ; +- afficher le source brut lorsqu'un document est invalide afin de permettre sa réparation ; +- distinguer erreurs JSON, schema, sémantiques et erreurs de configuration effective ; +- ne jamais demander à l'UI de reconstruire elle-même les validations. + +### Profils + +- afficher `default_profile` ; +- lister les profils disponibles ; +- sélectionner explicitement un profil pour inspection/résolution ; +- montrer distinctement source/global/profile/effective lorsque cela est utile à l'opérateur. + +### Environnement + +- afficher les variables KSP/KSPB via les rapports Config ; +- distinguer desired `.env`, effective, source process/`.env` et shadowing ; +- ne montrer par défaut que `safe_value` ; +- créer/modifier/supprimer une entrée `.env` uniquement via `ConfigManagement` ; +- signaler clairement qu'une valeur process peut masquer une modification `.env` et qu'un process parent ne peut pas être modifié par l'application. + +### Secrets + +- aucune valeur `Secret` réelle dans un DTO général, un log, un diagnostic ou un état UI persistant par défaut ; +- une action utilisateur explicitement privilégiée peut appeler une méthode `reveal_*` ; +- l'authentification/autorisation de cette action appartient à l'application, pas à `ksp-config-lib` ; +- le `pre.001` doit décider le contrat UX/DTO précis de reveal sans journaliser le secret. + +### Logging + +- charger `std.logging.json` via Config ; +- éditer ses profils/sinks via les types de management Config ; +- sauvegarder via `save_logging_document()` ; +- construire la configuration effective via `load_resolved_logging_config()` ; +- initialiser/reconfigurer `ksp-logging-lib` ; +- conserver `LoggingGuard` dans l'état applicatif/orchestration approprié ; +- vérifier qu'une erreur de nouvelle configuration ne détruit pas le runtime Logging déjà valide. + +## 6. Frontière Tauri + +Conserver les règles KSP déjà retenues : + +- TS-RS principalement à la frontière de l'application ; +- les DTO Tauri appartiennent à `ksp-app-config-desk`, pas à `ksp-config-lib`, sauf contrat externe générique explicitement justifié ; +- le `pre.001` doit décider et formaliser l’emplacement exact des `#[tauri::command]`; conserver comme direction héritée un adapter Tauri centralisé plutôt que des annotations dispersées ; +- pas de `?`, `unwrap`, `expect` ou `panic` dans les commandes ; +- l'application reste mince et appelle des fonctions/services internes qui réutilisent les crates KSP ; +- aucune dépendance directe aux crates `tracing*` dans l'application : Logging reste la façade ; +- aucune lecture directe `std::env::var*` pour `KSP_*` / `KSPB_*` ; +- aucune lecture/écriture directe des fichiers physiques Config/`.env`. + +Le `pre.001` doit vérifier les versions actuelles de Tauri et des dépendances frontend réellement nécessaires avant leur ajout. Les dépendances communes sont déclarées au niveau workspace lorsqu'elles sont partagées ; aucune dépendance n'est ajoutée sans usage immédiat. + +## 7. Sécurité et redaction + +Le desktop Config est une application de management privilégiée, mais cela ne supprime pas les frontières de sécurité : + +- les secrets ne sont jamais loggés ; +- `Debug`/diagnostics utilisent les vues sûres ; +- les APIs `reveal_*` sont appelées uniquement pour une intention explicite ; +- les DTO de reveal sont séparés des DTO ordinaires ; +- l'application doit éviter de conserver inutilement les secrets en mémoire/état UI ; +- une capture d'erreur ne doit pas recopier une valeur réelle dans son message/context ; +- le fichier `.env` reste non versionné ; `.env.example` reste l'inventaire versionné. + +## 8. Règles Rust et projet à conserver + +Conserver notamment : + +- Rust 2024 ; +- `unsafe` interdit ; +- pas de `unwrap`, `expect`, `panic` dans le code production ; +- pas d'opérateur `?` ; +- retours explicites selon Clippy workspace ; +- pas de `mod.rs` ; +- pas de `pub(super)` / `pub(in ...)` ; +- code/Rustdoc en anglais ; +- Markdown projet en français ; +- tests unitaires hors `src` avec structure miroir ; +- tests publics dans `tests/` ; +- dépendances externes communes sous `[workspace.dependencies]` puis `.workspace = true` ; +- versions caret de génération compatibles ; +- aucun `Cargo.lock`/lockfile frontend versionné selon la politique KSP actuelle ; +- chaque delta `0.1.x` est commité ; un défaut livré est corrigé par un `fix`, jamais réécrit silencieusement. + +## 9. Hors scope par défaut de `0.1.4` + +Ne pas ouvrir automatiquement : + +- Wallet ; +- Store/PostgreSQL ; +- RPC/WS/provider ; +- Program/decoder/executor ; +- workers/jobs/pipelines ; +- trading/ML ; +- nouveaux documents Config pour des composants inexistants ; +- watcher filesystem générique ; +- service distribué de configuration ; +- secrets manager distant ; +- chiffrement maison de `.env` ; +- application de contrôle globale KSP. + +Toute extension doit être justifiée dans `pre.001` ou reportée. + +## 10. Première livraison attendue : `0.1.4-pre.001` + +`pre.001` doit être un **plan de travail**, pas une grosse implémentation. + +Il doit produire au minimum : + +1. audit exact de la base stable `v0.1.3` ; +2. audit des règles Tauri/app existantes ; +3. choix du layout `apps/ksp-app-config-desk` et de son intégration workspace ; +4. matrice commandes Tauri / services internes / APIs Config appelées ; +5. matrice DTO ordinaires / DTO secrets privilégiés ; +6. modèle d'état applicatif et ownership de `LoggingGuard` ; +7. écrans/panneaux minimums et flux utilisateur ; +8. stratégie de tests Rust, Tauri et frontend ; +9. dépendances externes réellement nécessaires et versions actuelles vérifiées ; +10. hors-scope confirmés ; +11. prévision souple des prereleases, chaque tranche visant environ 15–20 minutes de travail effectif ; +12. critères de validation de la release. + +Ne commencer `pre.002` qu'après validation de ce plan. + +## 11. Clôture future de `0.1.4` + +La dernière prerelease de `0.1.4` devra comme d'habitude : + +- exécuter les validations finales ; +- consolider la documentation ; +- fermer/report explicitement les TODO ; +- nettoyer/archiver ce qui doit l'être ; +- synchroniser le changelog général lors de la publication stable ; +- produire le prompt de la release suivante ; +- préparer `rel.001` puis le tag stable `v0.1.4` après validation utilisateur.