v0.1.4-pre.016

This commit is contained in:
2026-08-16 19:00:49 +02:00
parent d92eb01bc2
commit 5aa538ed5d
29 changed files with 994 additions and 73 deletions

View File

@@ -1,5 +1,5 @@
<!-- file: crates/ksp-logging-lib/README.md -->
<!-- version: 5 -->
<!-- version: 6 -->
# ksp-logging-lib
@@ -18,6 +18,8 @@ La crate possède :
- l'héritage du `domain` effectif à travers les spans, avec possibilité pour un event ou un span enfant de le remplacer explicitement ;
- l'installation unique du subscriber global ;
- le hot reload via `reinitialize` sans second subscriber global ;
- `LoggingRuntimeIdentity` pour isoler les fichiers persistants par lancement sans muter les `FileSettings` source ;
- l'observabilité des file sinks actifs via `RuntimeFileMetadata`, avec maintien de la même identité à travers les hot reloads ;
- le takeover des logs : les targets externes sont silencieux par défaut ;
- les writers non bloquants console/fichier et leurs `WorkerGuard` ;
- les compteurs agrégés de lignes abandonnées et le compteur cumulatif par `output_id` fichier ;
@@ -54,7 +56,7 @@ Une crate KSP comportementale qui journalise son activité dépend de `ksp-loggi
Les événements utiles issus d'une dépendance externe ne sont pas renommés : la crate KSP propriétaire de l'opération réémet explicitement l'information utile sous son propre target KSP.
`ksp-logging-lib` ne dépend pas de `ksp-config-lib`. Config pourra construire un `LoggingSettings` puis appeler `initialize` ou `reinitialize`.
`ksp-logging-lib` ne dépend pas de `ksp-config-lib`. Config peut construire un `LoggingSettings` puis une application appelle `initialize`, `initialize_with_identity` et `reinitialize` selon son besoin. L'identité de lancement reste une responsabilité de la couche application : Logging la valide, la conserve dans le `LoggingGuard` et l'applique aux noms de fichiers actifs.
## Documentation