0.0.3-alpha.1.fix.1

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: 1 -->
+<!-- version: 2 -->
 
 # Plan 0.0.3 — templates initiaux et audits réutilisables
 
 ## Statut et sources
 
-Plan de cadrage proposé dans `0.0.3-alpha.1`. 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. Les tranches suivantes sont une prévision, non un état validé. Aucun template ni audit nouveau n'est encore matérialisé.
 
 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 :
 
@@ -17,6 +17,15 @@ Le rapport séparé `pgr-0.0.2-publish.001-report.md` indique `PASS` et donne le
 
 Le contrat de démarrage est `prompts/003-V0_0_3_START_PROMPT.md`. Les règles applicables partent de `RULES.md`, puis des familles `200`, `210`, `300`, `400`, du modèle de profils `003` et des profils `500`/`510`, `520`, `600`/`610` selon leur scope. PGR reste un dépôt documentaire avec deux utilitaires Python ; les toolchains Rust, Java et Android ne deviennent pas des prérequis du dépôt.
 
+Deux corpus de comparaison supplémentaires, fournis après le gate initial de `alpha.1`, ont été inspectés pour ce fix documentaire :
+
+```text
+khadhroony-solana-project-v0.3.16.zip  SHA-256 db3cc1b3fc3fb07ee864b02e2a7346c673d4cf63b33e8e872aca6c6458856ca0
+games-v0.3.5.zip                       SHA-256 5f5fdee1a271386766d059657d6eaa831acdc263b3e722fed738808335c0a105
+```
+
+Ce sont des sources de comparaison pour les décisions de templates et d'audits, non la baseline PGR et non des dépendances de build. Leur présence ne rend pas les conventions locales de KSP ou Games normatives pour tous les projets.
+
 ## Audit indépendant de la stable `v0.0.2`
 
 L'inspection de l'archive, sa lecture et la comparaison des fichiers extraits avec les membres ZIP ont établi :
@@ -39,13 +48,28 @@ La vérification de structure et de gouvernance a constaté :
 
 Aucun écart bloquant n'a été constaté dans ces contrôles. Les scripts Markdown ont chacun une portée volontairement limitée : le contrôle des liens vérifie l'existence des cibles inline locales, pas les ancres ; celui des tableaux vérifie leur structure source. Leur PASS n'atteste donc pas des propriétés hors de leur contrat.
 
+## Comparaison réelle des corpus Rust
+
+KSP `0.3.16` et Games `0.3.5` possèdent chacun un workspace Cargo virtuel avec `resolver = "3"` et centralisent réellement dans `[workspace.package]` `version`, `edition`, `license`, `repository`, `authors` et `publish`. Ils utilisent `[workspace.dependencies]` pour des dépendances tierces, mais avec respectivement `37` et `19` entrées propres à leur projet. Les deux racines déclarent les mêmes trois lints Rust de base (`missing_docs`, `unreachable_pub`, `unsafe_code`) et les mêmes `18` niveaux Clippy ; les éventuels `allow` doivent être revus un par un avant réemploi.
+
+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.
+
 ## Sélection des templates
 
-### Retenu : configuration `rustfmt.toml`
+### Retenu : famille Rust/Cargo minimale
 
-Le profil `510-RUST_CARGO.md` possède déjà le contrat de formatage et donne les paramètres issus des corpus éprouvés. Un fichier de configuration minimal, accompagné d'instructions de copie et d'adaptation de l'édition Rust au projet, apporte une valeur immédiate. Il appartient au scope Rust/Cargo, sans imposer à PGR une toolchain Rust, un pin de version ou le layout d'un projet complet.
+Le besoin concret n'est pas limité à `rustfmt.toml`. La première famille doit couvrir quatre responsabilités distinctes :
 
-Avant de livrer le template, vérifier dans les corpus réellement disponibles que chaque option reste utile et compatible avec la toolchain cible ; expliciter comment adapter `edition` et la largeur. La validation de formatage s'effectuera sur un sujet Rust de test lorsque l'environnement le permet, sans prétendre compiler PGR.
+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.
+
+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.
 
 ### Candidat conditionnel : template de prompt manuel de nouvelle session
 
@@ -53,7 +77,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 et catalogues de versions ne sont pas copiés par anticipation. Les profils `520` et `610` définissent des contraintes, mais aucun projet sujet et aucune matrice AGP/Gradle/JDK concrète n'ont été fournis à cette session pour choisir leurs valeurs. 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, 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 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.
 
@@ -63,7 +87,9 @@ Les deux audits existants (`tables`, `liens locaux`) sont les premiers patterns
 
 Un contrôle supplémentaire de headers Markdown est candidat prioritaire. La propriété est précise : pour chaque fichier Markdown choisi, comparer `<!-- file: ... -->` à son chemin relatif et vérifier `<!-- version: N -->` avec `N >= 1`. Son owner est `docs/rules/300-DOCUMENTATION.md`, son sujet réel est le corpus de `73` Markdown PGR, et les gates précédents répètent ce contrôle en Python inline. Ni le compilateur ni les deux scripts existants ne le couvrent. Sa matérialisation doit garder la sélection de chemins explicite et tester au moins un header erroné, un header correct et un chemin absent.
 
-Les scripts d'audit Rust historiques de KSP et `sasedev-games` ne sont pas inclus dans l'archive fournie. Ils restent des corpus de comparaison à examiner sur leurs sources réelles avant toute extraction d'une propriété spécialisée. Un audit Rust/Java/Android ne sera pas créé sans sujet concret et sans valeur distincte des outils officiels. Le contrôle manuel du pairing delta/history reste suffisant à ce stade ; aucune collection d'audits n'est ouverte pour remplir une taxonomie.
+Les archives KSP et Games contiennent les mêmes familles `audit_rust_general_rules.py` et `audit_rust_export_completeness.py`, et un orchestrateur `audit_rust_workspace_rules.py`. Leur ressemblance vient de règles partagées entre ces projets ; les scripts généraux agrègent déjà plusieurs propriétés, telles que headers Rust, placement des imports, rustdoc, ordre d'items et façade publique. KSP ajoute un audit spécifique des dépendances/owners et Games un audit de layout avec des chemins Web/Android et versions Gradle propres au jeu. Un orchestrateur peut rester utile pour une gate, mais ne devient pas un nouvel audit propriétaire de plusieurs règles.
+
+Pour PGR, les candidats réutilisables à étudier après les templates Cargo sont : vérification du miroir `VERSION`/`workspace.package.version` lorsque le projet déclare une seule unité de release, vérification de l'héritage explicite des lints dans les crates et éventuel contrôle d'une façade publique uniquement dans un profil qui possède ce contrat. Chacun exigerait un owner, un sujet réel et une propriété isolée ; Cargo/Clippy doivent rester responsables des erreurs qu'ils savent déjà détecter. Aucune de ces idées ne justifie un script Rust spécialisé dans ce fix documentaire. Le contrôle manuel du pairing delta/history reste suffisant à ce stade.
 
 ## Trajectoire prévisionnelle
 
@@ -71,15 +97,23 @@ Les scripts d'audit Rust historiques de KSP et `sasedev-games` ne sont pas inclu
 
 Enregistrer l'audit de la stable, confronter le prompt au dépôt réel, inventorier les candidats, fixer le scope et produire le présent plan ainsi que le delta. Aucune matérialisation technique importante. Attendre la validation opérateur, le history distinct et le commit avant tout delta suivant.
 
-### alpha.2 — template Rust ciblé
+### alpha.1.fix.1 — correction documentaire du plan
 
-Créer uniquement la configuration `rustfmt.toml` et ses instructions de sélection/adaptation ; vérifier sa conformité au profil `510` et la portée de sa validation. Si la vérification d'un corpus ou la forme du template révèle un besoin plus large, revoir le plan.
+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.3 — audit de headers Markdown
+### alpha.2 — formatage et configuration Clippy
 
-Extraire le contrôle récurrent en un script read-only monotâche, documenter sa portée dans la matrice et vérifier des cas positifs et négatifs utiles. Ne pas fusionner cet audit avec les deux audits Markdown existants.
+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.
 
-### alpha.4 — décision sur le template de workflow
+### alpha.3 — manifests Cargo workspace et crate membre
+
+Fournir des modèles minimaux de `Cargo.toml` racine et membre, incluant l'héritage des métadonnées et des lints et une explication des variations de scope. Vérifier les exemples sur un workspace d'essai sans recopier les listes de dépendances, versions et chemins de KSP/Games. Si les modèles exigent trop de décisions pour former des fichiers TOML valides, livrer des extraits complets avec procédure de substitution documentée, sans prétendre qu'un placeholder est prêt à compiler.
+
+### alpha.4 — audit de headers Markdown
+
+Extraire le contrôle récurrent en un script read-only monotâche, documenter sa portée dans la matrice et vérifier des cas positifs et négatifs utiles. Ne pas fusionner cet audit avec les deux audits Markdown existants. Les autres audits candidats restent à l'étude jusqu'à un sujet/owner avéré.
+
+### alpha.5 — décision sur le template de workflow
 
 Factoriser le prompt manuel seulement si la revue des prompts et du workflow confirme un bénéfice net ; sinon constater explicitement son report et passer à la stabilisation sans artefact artificiel.
 
@@ -97,6 +131,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 le template exige une toolchain figée, si l'audit de headers ne peut rester fiable et monotâche, si le template de workflow duplique le plan, ou si une comparaison du corpus réel 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 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.
 
-La validation `alpha.1` est documentaire : identité de `VERSION`, portée du delta, headers et audits Markdown, revue des owners et des candidats, absence de changement historique rétroactif, contrôle Git dans le dépôt de l'opérateur. La prévalidation de l'archive source et du delta ne devient pas à elle seule un PASS opérateur ; ce résultat appartient au futur `history/0.0.3/alpha.1.md`.
+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`.