0.0.5-alpha.7.fix.1

docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md -->
-<!-- version: 9 -->
+<!-- version: 10 -->
 
 # Plan 0.0.5 — réconciliation réelle avec KSP et sasedev-games
 
@@ -116,6 +116,8 @@ La nomenclature des crates devient également explicite : préfixe projet/abrév
 
 Le skeleton Rust/Cargo et le guide de manifest reflètent ces choix. Aucun gros audit composite n'est importé ; le marqueur KSP spécifique des trait imports n'est pas généralisé et les contrôles déjà possédés par Clippy, rustc ou l'audit de façade restent chez leur owner.
 
+La gate mécanique `alpha.7` est propre, mais la revue fonctionnelle post-gate montre que cette première matérialisation ne donnait pas encore de contrat architectural aux suffixes. `alpha.7.fix.1` complète donc la tranche sans la replanifier : `-api` devient un vrai contrat extensible/passif et n'est jamais créé par symétrie ; `-lib` identifie l'implémentation réutilisable ; les exécutables sont des packages distincts et minces par défaut ; `tracing` et un owner de logging commun sont fortement recommandés dans les workspaces multi-runtime. L'ancienne préférence KSP pour un worker mixte lib/bin n'est pas généralisée. Tauri reste l'exception framework actuelle et impose des noms de targets lib/bin réellement distincts.
+
 ### alpha.8 — formatage Rust structurel et audits monotâches
 
 Réconcilier les règles KSP de blocs homogènes, visibilité, ordre alphabétique, espacement, modules et réexports avec les conventions plus légères de Games. Décider précisément ce qui appartient à `rustfmt`, aux audits PGR existants (`blank_lines`, `const_blocks`) ou à un nouvel audit monotâche justifié.

docs/rules/510-RUST_CARGO.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/510-RUST_CARGO.md -->
-<!-- version: 5 -->
+<!-- version: 6 -->
 
 # Profil Rust / Cargo
 
@@ -68,6 +68,32 @@ Cette liste n'est ni exhaustive ni un vocabulaire imposé. Un suffixe ou classif
 
 Un projet historique MAY conserver un ordre local déjà stable, par exemple un rôle placé avant la responsabilité, si sa nomenclature est documentée et cohérente. PGR n'impose aucune campagne de renommage rétroactive uniquement pour adopter la grammaire recommandée.
 
+### Les suffixes portent un contrat architectural
+
+Dans un projet contrôlé, les classificateurs de nom ne sont pas décoratifs. Lorsqu'ils sont utilisés, ils décrivent une responsabilité que l'architecture et le graphe de dépendances doivent respecter.
+
+Une crate terminée par `-api` porte principalement des contrats réutilisables : traits, types, DTOs, identifiants et primitives nécessaires à des implémentations séparées. Elle SHOULD rester passive et sans runtime. Une crate `-api` purement déclarative MUST NOT dépendre d'une crate de logging/tracing uniquement pour satisfaire une convention transversale. Une instrumentation n'y est ajoutée que si la crate possède un comportement réel à observer.
+
+Une crate `-api` MUST NOT être créée uniquement pour obtenir une paire de noms symétrique. Elle est justifiée lorsqu'au moins une frontière réelle existe : implémentations multiples ou remplaçables, implémentation externe, backend injectable, lifecycle partagé ou contrat public dont l'implémentation doit pouvoir vivre dans une autre crate. Lorsqu'une seule implémentation est réellement prévue et qu'aucune frontière de contrat séparée n'apporte de valeur, une seule crate `-lib` est préférée.
+
+Une crate terminée par `-lib` porte une implémentation ou fonctionnalité réutilisable. Par défaut, elle est une crate bibliothèque sans cible binaire. Des familles comme `worker`, `job`, `store`, `transport` ou `scenario` MAY apparaître dans la responsabilité avant le suffixe `-lib` lorsqu'elles décrivent ce que la bibliothèque implémente ; le suffixe terminal `-lib` continue alors d'indiquer qu'il s'agit d'une unité réutilisable et non d'un launcher.
+
+### Séparation bibliothèques / exécutables
+
+Hors exception de framework ou plateforme explicitement documentée, un package contrôlé MUST NOT combiner une bibliothèque réutilisable et une cible binaire uniquement par commodité. La logique réutilisable appartient à une ou plusieurs crates `-lib`; l'exécutable appartient à un package distinct qui les consomme.
+
+Le nom d'un package exécutable SHOULD rendre visible son rôle de processus ou d'interface, par exemple `-cli`, `-desk`, `-worker`, `-job` ou `-server` lorsque ces termes décrivent réellement le launcher. Le binaire SHOULD rester une couche de composition mince : initialisation du processus, verrou/single-instance lorsque nécessaire, arguments CLI, wiring des bibliothèques, lifecycle et arrêt. La logique métier ou technique réutilisable ne doit pas être dupliquée dans `main.rs`.
+
+Tauri constitue l'exception framework actuellement reconnue par PGR à cette séparation par défaut : son profil peut demander un package mixte bibliothèque + binaire pour servir simultanément les entrées desktop/mobile. Cette exception est possédée par [`710-TAURI.md`](710-TAURI.md) et ne justifie pas de généraliser les packages mixtes aux workers, jobs ou autres exécutables. Toute autre exception mixte demande une règle locale et une raison technique identifiable.
+
+## Diagnostics structurés et ownership du logging
+
+Pour les nouveaux projets Rust contrôlés, `tracing` est le mécanisme recommandé de diagnostics structurés. La façade `log` MAY être conservée comme bridge de compatibilité lorsqu'une dépendance l'impose, mais elle SHOULD NOT devenir le mécanisme principal d'un nouveau projet lorsqu'aucune contrainte externe ne le requiert.
+
+Lorsqu'un workspace possède plusieurs crates runtime partageant les mêmes règles de diagnostics, il SHOULD centraliser la configuration de logging/tracing dans une crate transverse dédiée, typiquement `<project>-logging-lib` ou un nom équivalent conforme à la nomenclature locale. Dès que plusieurs exécutables ou bibliothèques ont besoin du même subscriber, des mêmes filtres/sinks ou du même lifecycle de guard, cet owner commun SHOULD remplacer les initialisations dupliquées. Un petit projet à exécutable unique n'est pas obligé de créer une crate dédiée sans valeur de réutilisation.
+
+Cette crate commune possède normalement la composition de `tracing-subscriber`, l'usage de `tracing-appender` lorsque nécessaire, les filtres/sinks/formats partagés et le lifecycle d'initialisation. Une bibliothèque métier ou technique MAY émettre des événements structurés, mais SHOULD NOT installer silencieusement un subscriber global. Les crates `-api` purement déclaratives restent normalement sans dépendance de logging.
+
 ## Manifests et dépendances Cargo
 
 Dans un workspace, une dépendance tierce réellement partagée par plusieurs crates SHOULD posséder sa contrainte de version canonique sous `[workspace.dependencies]`.

docs/rules/710-TAURI.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/710-TAURI.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->
 
 # Profil Tauri 2
 
@@ -72,14 +72,18 @@ Le host SHOULD être une crate Cargo mixte directement lisible, sans couche `src
 
 Un fichier comme `vite.config.ts` appartient également à la racine lorsque Vite est le bundler sélectionné. Un projet externe MAY conserver `src-tauri/` ou une autre organisation lorsque cette structure est imposée ou qu'une migration n'apporte pas de valeur suffisante.
 
-Dans le host Rust :
+Dans le host Rust, le package mixte `lib + bin` constitue l'exception framework explicite à la séparation générale définie par `510-RUST_CARGO.md`. Pour une nouvelle baseline Tauri contrôlée :
 
-- `src/lib.rs` SHOULD rester une façade de modules/réexports ;
-- `src/main.rs` SHOULD rester un launcher mince vers une fonction publique de la bibliothèque applicative ;
+- le package SHOULD déclarer explicitement une cible bibliothèque et une cible binaire ;
+- leurs noms MUST être distincts même après la normalisation Cargo usuelle des tirets en underscores ; un modèle valide est package/bin `project-feature-desk` et lib `project_feature_desk_lib` ;
+- `src/lib.rs` SHOULD rester une façade de modules/réexports et porter l'accès à la fonctionnalité applicative réutilisable ;
+- `src/main.rs` SHOULD rester un launcher mince vers une fonction publique de la bibliothèque applicative ; il MAY posséder le verrou/single-instance, les arguments strictement process et le bootstrap exécutable qui ne peut pas appartenir à la bibliothèque ;
 - `src/tauri.rs` SHOULD posséder l'assemblage Tauri et les wrappers `#[tauri::command]`, qui délèguent aux modules propriétaires plutôt que porter la logique métier ;
 - une fenêtre ou responsabilité UI non triviale SHOULD posséder un module cohérent, avec sous-modules si nécessaire ; les helpers réellement partagés entre plusieurs fenêtres/responsabilités SHOULD être déplacés dans des modules communs dédiés ;
 - un préfixe local comme `tw_` MAY être utilisé pour identifier les modules de fenêtres, mais PGR n'impose pas ce préfixe à tous les projets.
 
+Lorsque le workspace possède une crate de logging/tracing commune, le host Tauri l'utilise pour initialiser le runtime de diagnostics. Un plugin Tauri de tracing sert alors d'adapter à la frontière desktop/mobile ; il ne remplace pas l'owner Rust de `tracing-subscriber`, des sinks ou du lifecycle de logging.
+
 Lorsque le frontend sélectionné est TypeScript, les structures, énumérations et DTO Rust **possédés par le host** et partagés avec le frontend MUST utiliser TS-RS comme source de génération dans le profil strict, sauf incompatibilité technique explicitement documentée. Le contrat Rust reste la source de vérité ; les bindings générés ne sont pas modifiés manuellement et SHOULD rester hors Git lorsqu'ils sont entièrement reproductibles. Le skeleton MAY normaliser leur sortie sous `frontend/ts/bindings/`.
 
 Pour les projets contrôlés, `frontend/` est le répertoire recommandé pour les sources Web versionnées. Vite + TypeScript + Sass constitue la stack candidate par défaut et Bootstrap est la baseline de présentation privilégiée lorsque le projet a besoin d'un framework CSS généraliste. Tailwind CSS n'est pas interdit par le profil Tauri, mais il n'est pas le choix PGR par défaut et son adoption demande une décision explicite du projet. Ces choix restent possédés par le futur skeleton et les profils Web correspondants.

docs/skeletons/002-RUST_CARGO_WORKSPACE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/skeletons/002-RUST_CARGO_WORKSPACE.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Skeleton — Rust/Cargo workspace
 
@@ -72,8 +72,10 @@ Avant de considérer la specialization comme instanciée, résoudre explicitemen
 7. les niveaux de lints hérités, les éventuelles exceptions locales et tout besoin réel d'`unsafe` dans un scope étroit ;
 8. les paramètres `rustfmt.toml` et `clippy.toml` à conserver ou adapter ;
 9. l'emplacement des artefacts Cargo et l'identifiant unique utilisé dans `.cargo/config.toml` si cette politique externe au dépôt est retenue ;
-10. les exceptions éventuelles au profil Rust strict ; pour une nouvelle baseline contrôlée, la façade crate-root et les chemins explicites sont sélectionnés par défaut, tandis que les audits de style supplémentaires restent décidés séparément ;
-11. les validations Cargo réellement nécessaires au code et aux manifests créés.
+10. les frontières `-api` / `-lib` réellement justifiées, les packages exécutables distincts de leurs bibliothèques et toute exception framework à cette séparation ;
+11. l'ownership du logging/tracing : simple exécutable local ou crate transverse commune lorsque plusieurs runtimes partagent subscriber, sinks ou policy ;
+12. les exceptions éventuelles au profil Rust strict ; pour une nouvelle baseline contrôlée, la façade crate-root et les chemins explicites sont sélectionnés par défaut, tandis que les audits de style supplémentaires restent décidés séparément ;
+13. les validations Cargo réellement nécessaires au code et aux manifests créés.
 
 Les valeurs `0.1.0`, `2024`, `project-name`, `project-core-lib`, les seuils Clippy et les chemins de build présents dans les templates sont des exemples ou baselines à revoir. Ils ne deviennent jamais des valeurs universelles par simple copie.
 
@@ -105,6 +107,10 @@ Pour chaque crate réellement nécessaire, utiliser `templates/rust-cargo/crates
 
 `project-core-lib` n'est pas un nom de crate imposé. Dans une nouvelle baseline contrôlée, remplacer `project` par le nom court/abréviation du projet et choisir une responsabilité puis un rôle/cible lisibles conformément à `510-RUST_CARGO.md`. Une crate bibliothèque, binaire ou spécialisée doit conserver le layout et les héritages qui correspondent à son rôle réel ; un suffixe n'est pas ajouté uniquement pour obtenir une symétrie artificielle.
 
+Avant de créer une paire `*-api` / `*-lib`, démontrer la frontière contractuelle qui justifie deux packages. Une implémentation unique sans extension/backend/lifecycle séparé reste normalement une seule crate `-lib`. À l'inverse, une vraie crate `-api` reste principalement déclarative et ne reçoit pas le runtime de logging du projet par automatisme.
+
+Les exécutables sont des packages distincts des bibliothèques qu'ils composent, sauf exception de framework sélectionnée. Leur `main.rs` reste mince. Si plusieurs crates runtime partagent la même configuration de diagnostics, prévoir une crate transverse de logging/tracing ; ne pas répliquer l'initialisation du subscriber dans chaque binaire ou bibliothèque.
+
 Lorsque le membre hérite de la politique commune, `version.workspace = true`, `edition.workspace = true`, `publish.workspace = true` et `[lints] workspace = true` restent cohérents. Une exception locale, notamment de lint ou de safety, doit suivre le contrat de `510-RUST_CARGO.md` et ne pas affaiblir silencieusement les autres membres.
 
 Le code source minimal requis par Cargo appartient au projet destinataire. PGR ne fournit pas de `src/lib.rs` ou `src/main.rs` universel, car leur contenu dépend du rôle réel de la crate.

docs/studies/001-KSP_GAMES_RECONCILIATION.md

@@ -1,5 +1,5 @@
 <!-- file: docs/studies/001-KSP_GAMES_RECONCILIATION.md -->
-<!-- version: 8 -->
+<!-- version: 9 -->
 
 # Étude de réconciliation PGR / KSP / sasedev-games
 
@@ -206,6 +206,18 @@ La nomenclature converge sur une propriété utile sans imposer les vocabulaires
 
 Les règles de blocs homogènes, visibilité, espacement et ordre alphabétique restent volontairement hors de cette décision et appartiennent à `alpha.8`.
 
+#### Correction `alpha.7.fix.1` — suffixes, packaging et tracing
+
+La gate mécanique de `alpha.7` passe, mais la revue fonctionnelle opérateur révèle que la première matérialisation traitait encore les suffixes comme de simples indications de lisibilité. Le corpus KSP contient pourtant un contrat plus fort : `KSP-NAME-001..003` distingue implémentation réutilisable `-lib` et contrat extensible `-api`, `KSP-API-007` interdit de créer une API par symétrie, et `002-LAYERS_AND_DEPENDENCIES.md` réserve le logging aux crates ayant réellement du comportement.
+
+La règle PGR devient donc sémantique : `-api` signifie frontière de contrat réellement justifiée et principalement passive ; `-lib` signifie implémentation/fonctionnalité réutilisable. Une implémentation unique sans besoin d'extension/backend/lifecycle ne crée pas artificiellement une paire `-api` / `-lib`. Les rôles `worker`, `job`, `store`, etc. peuvent faire partie du nom d'une bibliothèque, mais `-lib` continue d'indiquer qu'elle n'est pas le launcher.
+
+Sur le packaging, les deux corpus ne doivent pas être fusionnés mécaniquement. Games `GAME-WS-007` sépare explicitement la lib de jeu et son runner Desktop. KSP contient encore `KSP-WORKER-014`, qui préférait à terme un package worker mixte bibliothèque + binaire. Cette dernière préférence n'est **pas généralisée** : la clarification opérateur retient désormais la séparation package bibliothèque / package exécutable par défaut, les exécutables restant des couches de composition minces. Tauri est l'exception framework actuelle.
+
+Cette exception est elle-même fortement observée : les `6` hosts Tauri KSP `0.3.16` et les `2` hosts Tauri Games `0.3.5` déclarent une cible `lib` et une cible `bin` distinctes ; les libs utilisent un nom terminé par `_lib` tandis que le binaire conserve le nom applicatif. PGR exige donc, dans une nouvelle baseline Tauri contrôlée, des noms de targets distincts même après normalisation `-` → `_`. Le motif cross-platform exact à l'origine de cette convention n'est pas utilisé comme preuve normative ici ; le contrat observable et reproductible suffit.
+
+Le logging converge également fortement. KSP possède `ksp-logging-lib` comme façade/runtime commun et garde ses `*-api` déclaratives sans logging ; Games définit `tracing` comme mécanisme canonique, `tracing-subscriber` comme owner de composition, `tracing-appender` lorsque nécessaire et `game-logging-lib` comme crate transverse. PGR retient donc `tracing` par défaut et recommande une crate commune de logging dès que plusieurs runtimes partagent subscriber, sinks, filtres ou lifecycle ; la façade `log` reste seulement une compatibilité possible, pas le default d'une nouvelle baseline contrôlée.
+
 #### Politique de version Tauri/frontend réconciliée
 
 La baseline KSP `0.3.16` illustre le défaut de l'ancienne convention : les six `tauri.conf.json` n'ont pas de champ `version`, tandis que leurs `package.json` portent des versions historiques différentes (`0.2.6`, `0.2.12-pre.9`, `0.3.7`, `0.3.8` ou `0.3.15`) sans représenter uniformément la release courante. Games `0.3.5` suit la même famille de règles. Cette situation réduit les modifications mécaniques mais affaiblit la lisibilité des manifests.

docs/templates/002-CARGO_MANIFESTS.md

@@ -1,5 +1,5 @@
 <!-- file: docs/templates/002-CARGO_MANIFESTS.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Modèles de manifests Cargo workspace et crate membre
 
@@ -27,7 +27,13 @@ Copier le membre vers `crates/<nom>/Cargo.toml`, adapter `name`, son chemin dans
 
 Le bloc `[dependencies]` vide se remplit selon les besoins de la crate. Pour une dépendance déjà déclarée sous `[workspace.dependencies]`, utiliser localement `nom = { workspace = true }`, avec `features = [...]` au besoin. Pour une dépendance strictement locale, choisir sa contrainte directement dans ce membre ; aucune liste tierce arbitraire n'est copiée par ce modèle.
 
-Une application binaire peut reprendre les mêmes héritages après adaptation du nom, du layout et de sa cible `src/main.rs` ; ne pas fabriquer un deuxième manifest quasi identique. Une crate à version ou politique de publication réellement indépendante doit déclarer ses valeurs locales et ne plus hériter ces champs par automatisme.
+Pour une nouvelle baseline contrôlée, une bibliothèque réutilisable et son exécutable sont normalement deux packages Cargo distincts. Le package binaire peut reprendre les mêmes héritages de workspace, mais son manifest est légitime parce qu'il exprime une frontière de packaging et de dépendances différente : il dépend des crates `-lib`, conserve un `main.rs` mince et porte un nom révélant son rôle (`-cli`, `-desk`, `-worker`, `-job`, `-server`, etc.) lorsque ce classificateur est réellement applicable. Ne pas fusionner `lib` + `bin` dans un seul package uniquement pour éviter un manifest membre supplémentaire.
+
+Une paire `*-api` / `*-lib` n'est créée que si un vrai contrat séparé le justifie. Une crate `-api` purement déclarative ne reçoit normalement ni subscriber global ni dépendance vers la crate de logging. Une crate `-lib` unique suffit lorsqu'il n'existe qu'une implémentation utile et aucune frontière d'extension/backend/lifecycle.
+
+Tauri est une exception framework documentée par [`710-TAURI.md`](../rules/710-TAURI.md) : son host peut être un package mixte `lib + bin`, mais les deux targets doivent alors posséder des noms distincts selon le contrat Tauri.
+
+Une crate à version ou politique de publication réellement indépendante doit déclarer ses valeurs locales et ne plus hériter ces champs par automatisme.
 
 ## Exception locale de lints