0.0.3-alpha.2

docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md

@@ -1,11 +1,11 @@
 <!-- file: docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Plan 0.0.3 — templates initiaux et audits réutilisables
 
 ## Statut et sources
 
-Plan de cadrage créé dans `0.0.3-alpha.1` et corrigé dans `0.0.3-alpha.1.fix.1` après sa validation mécanique. Les tranches suivantes sont une prévision, non un état validé. Aucun template ni audit nouveau n'est encore matérialisé.
+Plan de cadrage créé dans `0.0.3-alpha.1` et corrigé dans `0.0.3-alpha.1.fix.1` après sa validation mécanique. `alpha.2` intègre la convention opérateur sur les fichiers d'outillage Rust et matérialise les premiers templates. Les tranches suivantes sont une prévision, non un état validé.
 
 La source autoritaire est l'archive Gitea fournie `pgr-v0.0.2.zip`, issue selon l'opérateur du tag `v0.0.2`. Son SHA-256 vérifié localement est :
 
@@ -54,7 +54,7 @@ KSP `0.3.16` et Games `0.3.5` possèdent chacun un workspace Cargo virtuel avec
 
 Les `22` crates KSP héritent des lints workspace par `[lints] workspace = true`. Parmi `23` crates Games, `22` utilisent ce même héritage ; l'entrée Android déclare des lints locaux pour ajuster `unsafe_code` à sa frontière FFI. La capacité d'exception locale est donc réelle et doit être expliquée sans rendre l'exception Android générale.
 
-Les deux `rustfmt.toml` ont un contenu technique identique et seulement un numéro de révision de fichier différent. Les deux `clippy.toml` partagent leurs seuils principaux et divergent sur les identifiants courts autorisés et quelques entrées vides. Ces seuils et listes sont des préférences de projet à examiner : leur répétition ne prouve pas qu'ils soient de bons défauts universels. Les deux `.cargo/config.toml` déplacent les artefacts de build vers des chemins propres au projet ; Games ajoute des flags Web. Ce fichier est un candidat conditionnel, pas un chemin à copier tel quel.
+Les deux `rustfmt.toml` ont un contenu technique identique et seulement un numéro de révision de fichier différent. Les deux `clippy.toml` partagent leurs seuils principaux et divergent sur les identifiants courts autorisés et quelques entrées vides. L'opérateur confirme qu'il réutilise ces conventions comme baseline de départ, telles quelles ou avec de petites adaptations. Les deux `.cargo/config.toml` déplacent les artefacts de build vers `../builds/<projet>/target/` ; Games ajoute des flags Web propres à sa cible. La configuration générique de déplacement est donc retenue avec un nom de projet à remplacer.
 
 ## Sélection des templates
 
@@ -63,13 +63,14 @@ Les deux `rustfmt.toml` ont un contenu technique identique et seulement un numé
 Le besoin concret n'est pas limité à `rustfmt.toml`. La première famille doit couvrir quatre responsabilités distinctes :
 
 1. `rustfmt.toml` : options communes dont la valeur est justifiée ; alignement de `edition` avec le projet destinataire ; ne pas reprendre mécaniquement chaque préférence des deux sources ;
-2. configuration Clippy : niveaux de lint Rust/Clippy dans les sections Cargo `[workspace.lints.rust]` et `[workspace.lints.clippy]`, plus un `clippy.toml` minimal seulement pour les paramètres Clippy qui apportent une valeur vérifiée et ne sont pas des seuils arbitraires ;
-3. `Cargo.toml` workspace : sections `[workspace]`, `[workspace.package]`, `[workspace.dependencies]` et `[workspace.lints.*]` avec les responsabilités et champs de décision explicités ; `VERSION` doit correspondre à `workspace.package.version` seulement pour une unité de release commune ;
-4. `Cargo.toml` d'une crate membre ordinaire : identité locale, héritage explicite des métadonnées communes et des lints, et dépendances/features limitées aux besoins de la crate. Une adaptation locale des lints doit être documentée comme exception ciblée ; elle ne devient pas un deuxième jeu de valeurs globales.
+2. configuration Clippy : niveaux de lint Rust/Clippy dans les sections Cargo `[workspace.lints.rust]` et `[workspace.lints.clippy]`, plus `clippy.toml` pour les seuils et réglages conservés dans le profil de départ éprouvé ; chaque projet peut adapter ces choix ;
+3. `.cargo/config.toml` : `target-dir` et `build-dir` vers un dossier frère `../builds/<projet>/target/`, après remplacement explicite du nom ; les flags Web et les autres particularités restent locaux ;
+4. `Cargo.toml` workspace : sections `[workspace]`, `[workspace.package]`, `[workspace.dependencies]` et `[workspace.lints.*]` avec les responsabilités et champs de décision explicités ; `VERSION` doit correspondre à `workspace.package.version` seulement pour une unité de release commune ;
+5. `Cargo.toml` d'une crate membre ordinaire : identité locale, héritage explicite des métadonnées communes et des lints, et dépendances/features limitées aux besoins de la crate. Une adaptation locale des lints doit être documentée comme exception ciblée ; elle ne devient pas un deuxième jeu de valeurs globales.
 
 Ces fichiers ou extraits doivent être copiables et compréhensibles sans figer le nom de projet, la version, les dépendances, le layout de toutes les crates, la publication, la toolchain ni le minimum de plateforme. Lorsqu'un champ obligatoire ne peut pas avoir de valeur générique sûre, des instructions Markdown guident son remplacement avant l'usage ; un fichier TOML présenté comme prêt à l'emploi doit être valide. Les crates bibliothèque et application peuvent partager un tronc commun, leurs différences réelles restant documentées sans créer des dizaines de variantes.
 
-Pour la validation, comparer les templates au profil `510`, parser les manifests avec Cargo ou un parseur TOML, et exercer sur un workspace d'essai les héritages et le cas d'une exception locale si l'environnement le permet. Tester `rustfmt` et Clippy seulement pour les réglages réellement livrés ; une compilation de KSP/Games n'est pas une gate de PGR.
+Pour la validation, comparer les templates au profil `510`, parser les configs/manifests avec un parseur TOML et exercer sur un workspace d'essai les héritages et le cas d'une exception locale quand les toolchains sont disponibles. Tester `rustfmt` et Clippy pour les réglages réellement livrés dans un projet Rust concerné ; une compilation de KSP/Games n'est pas une gate de PGR.
 
 ### Candidat conditionnel : template de prompt manuel de nouvelle session
 
@@ -77,7 +78,7 @@ Les prompts `002` et `003` montrent un besoin récurrent de transmission de la b
 
 ### Différés
 
-Les fichiers Maven/Gradle complets, wrappers, Android `local.properties` ou signing, règles `.gitignore` universelles, versions de dépendances et chemins `.cargo/config.toml` ne sont pas copiés par anticipation. Games fournit un exemple Android concret, mais sa matrice AGP/Gradle/JDK, son build natif et ses chemins restent propres à ce projet. Les wrappers restent soumis aux outils officiels et à la décision du projet ; un `local.properties` entièrement régénéré ne justifie pas d'exemple.
+Les fichiers Maven/Gradle complets, wrappers, Android `local.properties` ou signing, règles `.gitignore` universelles et versions de dépendances ne sont pas copiés par anticipation. Games fournit un exemple Android concret, mais sa matrice AGP/Gradle/JDK, son build natif et ses flags Cargo Web restent propres à ce projet. Les wrappers restent soumis aux outils officiels et à la décision du projet ; un `local.properties` entièrement régénéré ne justifie pas d'exemple.
 
 Les spécifications complètes de skeleton restent réservées à `0.0.4` ; Rust/JNI, Web/WASM, Tauri et les autres profils différés n'entrent pas dans cette release par simple proximité technologique.
 
@@ -101,9 +102,9 @@ Enregistrer l'audit de la stable, confronter le prompt au dépôt réel, invento
 
 Après le history et le commit de `alpha.1`, documenter la comparaison réelle de KSP/Games, élargir les templates Rust à Cargo et Clippy et redimensionner les tranches. Aucun template ou audit nouveau dans ce fix.
 
-### alpha.2 — formatage et configuration Clippy
+### alpha.2 — outillage Rust/Cargo partagé
 
-Créer le template `rustfmt.toml` et documenter les réglages Clippy retenus : les niveaux de lint appartiennent aux manifests Cargo ; un `clippy.toml` est livré uniquement si ses paramètres distincts sont justifiés après revue des deux corpus. Valider syntaxe et comportement des seules options sélectionnées.
+Créer les templates `rustfmt.toml`, `clippy.toml` et `.cargo/config.toml` à partir du noyau éprouvé dans KSP et Games. Documenter les responsabilités distinctes : formatage, paramètres Clippy, sortie Cargo hors du dépôt. Le nom du projet, l'édition Rust et les seuils ajustables sont explicités au point de copie ; vérifier syntaxe et chemins relatifs. Les niveaux de lint dans `Cargo.toml` restent à la tranche suivante, qui les reliera au profil Clippy retenu.
 
 ### alpha.3 — manifests Cargo workspace et crate membre
 
@@ -131,6 +132,6 @@ Promouvoir la RC validée, produire le history de clôture pré-tag, committer e
 
 ## Points de décision et validation
 
-Le plan doit être revu si les templates Cargo/Clippy exigent des choix de projet incompatibles avec un modèle minimal, si l'audit de headers ne peut rester fiable et monotâche, si le template de workflow duplique le plan, ou si un autre examen des corpus révèle des contraintes nouvelles. Un REPLAN explicite indique `CONTINUE`, `SPLIT`, `CONTINUE-NEXT-SESSION` ou `ABANDON` ; la durée d'une conversation ne crée pas une nouvelle version.
+Le plan doit être revu si les manifests Cargo exigent des choix de projet incompatibles avec un modèle minimal, si l'audit de headers ne peut rester fiable et monotâche, si le template de workflow duplique le plan, ou si un autre examen des corpus révèle des contraintes nouvelles. Un REPLAN explicite indique `CONTINUE`, `SPLIT`, `CONTINUE-NEXT-SESSION` ou `ABANDON` ; la durée d'une conversation ne crée pas une nouvelle version.
 
 La validation `alpha.1` a porté sur l'identité de `VERSION`, la portée du delta, les headers et audits Markdown, l'absence de changement historique rétroactif et le contrôle Git du dépôt de l'opérateur. Ses résultats observés sont conservés dans `history/0.0.3/alpha.1.md`. Le fix documentaire décrit ci-dessus possède sa propre gate et son propre history : le PASS de `alpha.1` ne vaut pas validation anticipée de `alpha.1.fix.1`.