# Delta `0.1.2-rel.001` — publication stable Logging ## Base requise `0.1.2-pre.006` avec le correctif documentaire `0.1.2-pre.006-fix.001`, au sens des commits de livraison correspondants, avec : ```text workspace.package.version = "0.1.2-pre.6" ``` Le correctif `pre.006-fix.001` ne modifie pas la version Cargo. ## Objectif Publier la release stable `0.1.2`, clôturer `Logging foundation` et préparer l'ouverture de `0.1.3 — Configuration foundation` sans modifier la surface fonctionnelle de `ksp-logging-lib`. ## Version Cargo `workspace.package.version` passe de : ```text 0.1.2-pre.6 ``` à : ```text 0.1.2 ``` Le header de `Cargo.toml` passe de version 38 à 39. Les contraintes de dépendances restent inchangées : ```toml [workspace.dependencies] solana-pubkey = { version = "^4.3", default-features = false } tracing = { version = "^0.1", default-features = false, features = ["std"] } tracing-subscriber = { version = "^0.3", default-features = false, features = ["fmt"] } tracing-appender = { version = "^0.2", default-features = false } tokio = { version = "^1.53", default-features = false, features = ["rt", "rt-multi-thread", "macros"] } ``` Tokio reste uniquement une dev-dependency de `ksp-logging-lib` et n'appartient pas à son graphe normal. ## Validations finales exécutées par le user Commandes exécutées avec succès le 2026-08-14 sur `0.1.2-pre.6` : ```bash cargo fmt --all cargo check --workspace cargo build -p ksp-logging-lib cargo clippy --workspace --all-targets cargo test --workspace cargo test -p ksp-logging-lib --test overhead -- --ignored --nocapture cargo tree -p ksp-logging-lib cargo tree -p ksp-logging-lib -d cargo tree -p ksp-logging-lib -e features cargo tree -p ksp-logging-lib -e normal cargo tree -p ksp-logging-lib -e dev ``` Résultats communiqués : - `cargo check --workspace` : succès ; - `cargo build -p ksp-logging-lib` : succès sur le graphe normal ; - `cargo clippy --workspace --all-targets` : succès sans warning communiqué ; - `cargo test --workspace` : tous les tests exécutés réussissent, dont les tests de takeover, saturation non bloquante, hot reload concurrent, lifecycle span et les deux tests Tokio réels ; - probe d'overhead explicite : succès sur 200000 itérations, `baseline=16.959425ms`, `reload=24.942444ms` ; - `cargo tree -p ksp-logging-lib -d` : aucun doublon ; - `cargo tree -p ksp-logging-lib -e normal` : Tokio absent ; - `cargo tree -p ksp-logging-lib -e dev` : Tokio présent comme seule dev-dependency directe ; - features Tokio observées : `macros`, `rt`, `rt-multi-thread`, sans feature `full`. Le correctif documentaire `pre.006-fix.001` appliqué après ces validations ne modifie ni Rust, ni manifest, ni runtime. ## Surface stable publiée `0.1.2` stabilise notamment : - `ksp-logging-lib` comme façade runtime KSP unique de logging/tracing ; - les macros `error!`, `warn!`, `info!`, `debug!`, `trace!` avec target KSP explicite et callsite consommateur préservé ; - les spans KSP synchrones et `instrument(span, future)` pour l'async sans dépendance `tracing` directe chez les consumers ; - `LoggingSettings`, `LogFilterLevel`, `TargetFilter`, `SpanEvents`, `ConsoleSettings`, `FileSettings` et `FileRotation` ; - `initialize()` unique, `reinitialize()` à chaud et `LoggingGuard` ; - takeover KSP avec silence externe par défaut et overrides par préfixe `ksp-*` ; - console et fichier non bloquants avec `WorkerGuard` possédés par Logging ; - mode lossy sans backpressure sur le hot path et observation cumulée des lignes abandonnées via `DroppedLines` ; - rotation fichier `Never`, `Hourly`, `Daily` ; - suppression des séquences ANSI avant persistence fichier ; - reconfiguration transactionnelle conservant l'ancienne configuration si la nouvelle préparation échoue ; - lifecycle spans `Off`, `NewAndClose`, `Full`, avec `busy`/`idle` lorsque demandé ; - tests de concurrence/reload, saturation, ownership de la stack tracing, callsites et instrumentation Tokio current-thread/multi-thread ; - ownership exclusif de `tracing`, `tracing-subscriber` et `tracing-appender` par `ksp-logging-lib` dans le workspace KSP. Aucune nouvelle primitive ou API n'est ajoutée par le présent delta de publication. ## Documentation de clôture Le présent delta : - marque `0.1.2` réalisée dans `ROADMAP.md` ; - conserve `004-V0_1_2_LOGGING_FOUNDATION_PLAN.md` comme plan historique clôturé ; - ajoute ce plan aux index de documentation/plans ; - remplace le périmètre candidat Logging dans la séquence fonctionnelle par la surface réellement stabilisée ; - réaligne la section Config de la séquence fonctionnelle sur les décisions de `pre.006-fix.001` : `KSP_*`/`KSPB_*`, `config/examples/`, documents unitaires + composites, ownership exclusif de Config et accès explicite aux secrets pour les surfaces autorisées ; - conserve `prompts/003-V0_1_3_START_PROMPT.md` comme prompt final d'ouverture de `0.1.3`. Aucun changelog général n'existe dans la base actuelle ; aucun changelog artificiel n'est créé. ## Fichiers ajoutés ```text deltas/0.1.2/rel.001.md ``` ## Fichiers modifiés ```text Cargo.toml ROADMAP.md docs/000-README.md docs/plans/000-README.md docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md docs/plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md ``` ## Fichiers supprimés Aucun. ## Décisions Aucune nouvelle décision fonctionnelle concernant Logging. La publication stable confirme les décisions, contrats et corrections stabilisés pendant les prereleases `0.1.2` et leurs fixes. La synchronisation de la documentation Config en clôture ne remplace pas le brainstorming `0.1.3-pre.001`; elle ne fait qu'enregistrer les décisions déjà prises dans `pre.006-fix.001`. ## Validations non exécutées dans cette livraison L'environnement de génération du delta ne dispose pas de Cargo/Rust. Les commandes Cargo ne sont donc pas réexécutées ici sur la version finale `0.1.2`. Après application du delta, le user doit exécuter au minimum : ```bash cargo fmt --all cargo check --workspace cargo clippy --workspace --all-targets cargo test --workspace ``` Le build normal et les graphes Cargo peuvent également être rejoués pour confirmer une dernière fois l'absence de Tokio dans le graphe runtime. ## Publication Git Après application et validation de ce delta : 1. vérifier que le working tree ne contient que les modifications attendues ; 2. exécuter les validations finales sur `workspace.package.version = "0.1.2"` ; 3. créer le commit de release : ```text v0.1.2-rel.001 ``` 4. marquer ce commit comme release stable avec le tag : ```text v0.1.2 ``` Aucun tag supplémentaire n'est requis pour les prereleases/fixes historiques. ## Suite Après le tag stable `v0.1.2`, ouvrir : ```text 0.1.3-pre.001 ``` avec : ```text prompts/003-V0_1_3_START_PROMPT.md ``` La première prerelease de `0.1.3` reste une phase de brainstorming, audit et planification avant développement fonctionnel de `ksp-config-lib`.