0.0.2-alpha.3

2026-09-23 11:35:41 +02:00
parent 5f9b84c980
commit 34ac3a9286
6 changed files with 484 additions and 3 deletions
--- a/RULES.md
+++ b/RULES.md
@@ -1,5 +1,5 @@
 <!-- file: RULES.md -->
-<!-- version: 6 -->
+<!-- version: 7 -->

 # Index normatif Project Governance Rules

@@ -79,6 +79,7 @@ Familles actuellement actives :
 - [`docs/rules/300-DOCUMENTATION.md`](docs/rules/300-DOCUMENTATION.md) — rôles documentaires, taxonomie, révisions internes, documents vivants et conservation historique.
 - [`docs/rules/400-VALIDATION.md`](docs/rules/400-VALIDATION.md) — sélection proportionnelle des preuves, catégories de validation, tests utiles, doubles de test et autorité opérateur.
 - [`docs/rules/500-LANGUAGES.md`](docs/rules/500-LANGUAGES.md) — contrat commun des profils langage, écosystème et spécialisations de build associées.
+- [`docs/rules/510-RUST_CARGO.md`](docs/rules/510-RUST_CARGO.md) — profil Rust/Cargo : workspace, manifests, dépendances, lints, API, formatage, tests et validation spécialisée.
 - [`docs/rules/600-PLATFORMS.md`](docs/rules/600-PLATFORMS.md) — contrat commun des profils plateforme et de leur compatibilité de target/runtime.

 Le modèle de composition et d'ownership des profils est défini dans [`docs/architecture/003-RULE_PROFILE_MODEL.md`](docs/architecture/003-RULE_PROFILE_MODEL.md).
--- a/2
+++ b/2
@@ -1 +1 @@
-0.0.2-alpha.2
+0.0.2-alpha.3
--- a/deltas/0.0.2/alpha.3.md
+++ b/deltas/0.0.2/alpha.3.md
@@ -0,0 +1,166 @@
+<!-- file: deltas/0.0.2/alpha.3.md -->
+<!-- version: 1 -->
+
+# Delta 0.0.2-alpha.3 — premier profil Rust / Cargo
+
+## Baseline
+
+Version attendue avant application :
+
+```text
+0.0.2-alpha.2
+```
+
+Le history `history/0.0.2/alpha.2.md` MUST avoir été appliqué et committé avant ce delta.
+
+Version après application :
+
+```text
+0.0.2-alpha.3
+```
+
+## Objet
+
+Matérialiser le premier profil technologique réel de PGR : `Rust / Cargo`.
+
+Cette tranche sert aussi de point de mesure prévu par le plan `0.0.2`. Elle doit consolider uniquement les règles Rust/Cargo suffisamment générales pour être réutilisables, sans recopier les particularités métier ou les micro-conventions propres à KSP ou `sasedev-games`.
+
+## Réconciliation des corpus sources
+
+Les deux corpus historiques de référence convergent notamment sur :
+
+- l'utilisation d'un workspace Cargo structuré ;
+- la centralisation des métadonnées/lints et des dépendances réellement partagées ;
+- l'activation locale des features selon le besoin de la crate ;
+- une politique Rust stricte autour de `unsafe`, `unwrap`, `expect`, retours explicites et Clippy ;
+- une façade de crate explicite plutôt qu'une exposition accidentelle des modules internes ;
+- `rustfmt.toml` comme propriétaire du formatage ;
+- la séparation des tests unitaires et d'intégration ;
+- une gate `fmt` / audit applicable / `check` / `clippy`, avec tests ciblés par défaut et tests workspace aux gates larges ;
+- l'absence d'exécution opportuniste de `cargo update`, `cargo tree`, `cargo build` ou `cargo clean` sans besoin correspondant.
+
+La consolidation ne promeut pas automatiquement les divergences ou conventions trop spécifiques :
+
+- l'interdiction KSP de tous les imports `use` non-traits n'est pas élevée au profil Rust général ;
+- les micro-règles KSP de lignes vides/ordre interne ne remplacent pas `rustfmt` au niveau PGR ;
+- aucune dépendance, crate, version de bibliothèque ou règle Solana/games n'est reprise ;
+- la politique historique commune d'ignorer `Cargo.lock` n'est pas rendue universelle : le profil exige une politique explicite selon le type de produit ;
+- l'exception `unsafe` Android/JNI de games reste un exemple de spécialisation FFI locale et non une permission Rust générale ;
+- le chemin externe des artefacts Cargo n'est pas figé avant les futures règles de skeleton/layout.
+
+## Profil créé
+
+Le nouveau propriétaire normatif est :
+
+```text
+docs/rules/510-RUST_CARGO.md
+```
+
+Il couvre :
+
+- toolchain et édition ;
+- workspace et unités de release ;
+- manifests, dépendances et features ;
+- politique explicite de `Cargo.lock` ;
+- lints communs et safety ;
+- API, visibilité et rustdoc ;
+- contrôle de flux/erreurs du profil strict ;
+- `rustfmt.toml` ;
+- `.cargo/config.toml` et artefacts générés ;
+- organisation des tests ;
+- commandes de validation Rust/Cargo ;
+- stratégie future d'audits Rust monotâches.
+
+Aucun script Rust supplémentaire n'est créé dans cette tranche. PGR ne possède actuellement aucun workspace Rust réel à auditer ; introduire maintenant une copie simplifiée des auditeurs games/KSP créerait une gate sans sujet réel. Le premier audit PGR déjà matérialisé reste l'audit Markdown monotâche introduit lorsque son besoin a été observé.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+RULES.md
+docs/rules/000-README.md
+```
+
+ADD :
+
+```text
+docs/rules/510-RUST_CARGO.md
+deltas/0.0.2/alpha.3.md
+```
+
+DELETE : aucun.
+
+Aucun manifest de suppression n'est nécessaire.
+
+## Validation opérateur
+
+```bash
+test "$(cat VERSION)" = "0.0.2-alpha.3"
+
+test -f docs/rules/510-RUST_CARGO.md
+test -f deltas/0.0.2/alpha.3.md
+
+grep -F 'PGR MUST NOT imposer un pin exact de toolchain uniquement parce qu' docs/rules/510-RUST_CARGO.md
+grep -F 'le fichier PGR `VERSION` reste la version canonique de l' docs/rules/510-RUST_CARGO.md
+grep -F 'Une crate membre SHOULD consommer cette dépendance avec `workspace = true`' docs/rules/510-RUST_CARGO.md
+grep -F 'PGR ne généralise pas automatiquement la politique de lockfile' docs/rules/510-RUST_CARGO.md
+grep -F 'unsafe_code = "forbid"' docs/rules/510-RUST_CARGO.md
+grep -F 'PGR ne généralise pas l'"'"'interdiction KSP plus stricte de tous les `use` non-traits' docs/rules/510-RUST_CARGO.md
+grep -F 'cargo clippy --workspace --all-targets --all-features -- -D warnings' docs/rules/510-RUST_CARGO.md
+grep -F 'PGR SHOULD préférer plusieurs audits monotâches et lisibles' docs/rules/510-RUST_CARGO.md
+
+grep -F '510-RUST_CARGO.md' RULES.md
+grep -F '510-RUST_CARGO.md' docs/rules/000-README.md
+
+python3 -B scripts/audit_markdown_tables.py \
+    README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
+
+git diff --check
+
+git add VERSION RULES.md \
+    docs/rules/000-README.md \
+    docs/rules/510-RUST_CARGO.md \
+    deltas/0.0.2/alpha.3.md
+
+git diff --cached --check
+
+git status --short
+```
+
+La sortie attendue avant ajout du history est :
+
+```text
+M  RULES.md
+M  VERSION
+A  deltas/0.0.2/alpha.3.md
+M  docs/rules/000-README.md
+A  docs/rules/510-RUST_CARGO.md
+```
+
+Revue opérateur complémentaire :
+
+- confirmer que le profil distingue bien les règles Rust/Cargo générales des conventions strictement KSP ou games ;
+- confirmer que la politique de lockfile reste explicitement project-type-specific et n'est pas généralisée uniquement parce que les deux corpus historiques ignoraient `Cargo.lock` ;
+- confirmer que les contraintes FFI/plateforme restent des overrides locaux ;
+- confirmer qu'aucune version de crate ou de toolchain historique n'a été recopiée comme pin universel ;
+- confirmer qu'aucun audit Rust complexe n'a été ajouté avant d'avoir un sujet réel et une propriété mono-responsabilité à contrôler.
+
+## Point de mesure / REPLAN
+
+`alpha.3` est le point de mesure explicite prévu par le plan.
+
+Le profil Rust/Cargo tient dans une tranche documentaire autonome sans nécessiter de famille supplémentaire, de script d'audit complexe ou de sous-profil framework/plateforme. Le forecast `alpha.4 — Java / Maven / Gradle` reste donc raisonnable à ce stade.
+
+Si la validation de cette tranche révèle au contraire une dérive importante du modèle ou plusieurs corrections substantielles, effectuer un REPLAN avant `alpha.4` plutôt que poursuivre mécaniquement.
+
+## Transition
+
+### PASS
+
+Créer et appliquer séparément `history/0.0.2/alpha.3.md`, committer la tranche, puis préparer `0.0.2-alpha.4` consacré à `Java / Maven / Gradle`.
+
+### FAIL
+
+Rester dans `0.0.2-alpha.3.fix.M` tant que le premier profil réel ne respecte pas le modèle `alpha.2`. Un défaut de dimensionnement significatif peut déclencher un REPLAN avant toute tranche Java.
--- a/docs/rules/000-README.md
+++ b/docs/rules/000-README.md
@@ -1,5 +1,5 @@
 <!-- file: docs/rules/000-README.md -->
-<!-- version: 7 -->
+<!-- version: 8 -->

 # Index des règles PGR

@@ -16,6 +16,7 @@ Les règles générales actuellement nécessaires restent dans `RULES.md`. La fa
 - [`300-DOCUMENTATION.md`](300-DOCUMENTATION.md) — rôles des documents, taxonomie, révisions internes, documents vivants et snapshots historiques.
 - [`400-VALIDATION.md`](400-VALIDATION.md) — matrice de validation, preuves proportionnelles, tests/audits/diagnostics, doubles de test et autorité du gate opérateur.
 - [`500-LANGUAGES.md`](500-LANGUAGES.md) — contrat commun des profils langage/écosystème et de leurs spécialisations de build.
+- [`510-RUST_CARGO.md`](510-RUST_CARGO.md) — profil Rust/Cargo et règles réutilisables propres à cet écosystème.
 - [`600-PLATFORMS.md`](600-PLATFORMS.md) — contrat commun des profils plateforme.

 Le modèle transversal d'ownership, d'applicabilité et de composition est décrit dans [`../architecture/003-RULE_PROFILE_MODEL.md`](../architecture/003-RULE_PROFILE_MODEL.md).
--- a/docs/rules/510-RUST_CARGO.md
+++ b/docs/rules/510-RUST_CARGO.md
@@ -0,0 +1,191 @@
+<!-- file: docs/rules/510-RUST_CARGO.md -->
+<!-- version: 1 -->
+
+# Profil Rust / Cargo
+
+## Scope
+
+Ce profil s'applique aux projets qui utilisent Rust avec Cargo.
+
+Il spécialise [`500-LANGUAGES.md`](500-LANGUAGES.md) pour les responsabilités propres à Rust et Cargo. Il ne possède pas les contraintes particulières d'une plateforme, d'un framework, d'une FFI, d'un protocole ou d'un domaine métier.
+
+Une règle plus spécifique, par exemple Android, WASM, Tauri ou une frontière FFI, MAY raffiner ce profil dans son scope sans modifier la politique Rust générale.
+
+## Toolchain et édition
+
+Un nouveau projet Rust SHOULD utiliser une toolchain stable récente compatible avec ses dépendances et ses cibles. Une toolchain nightly, beta ou autre prerelease nécessite une justification explicite.
+
+PGR MUST NOT imposer un pin exact de toolchain uniquement parce qu'un projet source historique utilisait cette version. Un fichier `rust-toolchain.toml` ou équivalent SHOULD être ajouté uniquement lorsqu'un besoin réel de reproductibilité, de composant ou de compatibilité l'exige.
+
+Lorsqu'un workspace partage une politique d'édition unique, l'édition Rust SHOULD être déclarée une seule fois sous `[workspace.package]` et héritée par les membres. Une évolution d'édition est une décision de compatibilité/toolchain et non une modification opportuniste.
+
+## Workspace et unités de release
+
+Un projet Rust composé de plusieurs packages SHOULD utiliser un workspace Cargo lorsque les packages partagent réellement gouvernance, validation ou dépendances.
+
+Pour un workspace à train de release unique :
+
+- le fichier PGR `VERSION` reste la version canonique de l'unité de release ;
+- `[workspace.package].version` MUST refléter cette version lorsque Cargo exige une version de package ;
+- les crates membres SHOULD hériter de la version workspace plutôt que recopier la même valeur ;
+- les métadonnées réellement communes comme `edition`, `license`, `repository` ou `authors` SHOULD être centralisées puis héritées lorsqu'elles ont le même propriétaire.
+
+Un monorepo contenant plusieurs unités de release indépendantes MUST NOT fabriquer une fausse version Cargo globale uniquement pour appliquer ce modèle. Chaque unité conserve alors son propriétaire de version conformément aux règles générales PGR.
+
+Le répertoire `crates/` est le placement PGR recommandé pour les packages Rust d'un workspace structuré, sauf layout imposé par un framework, une plateforme ou un projet existant.
+
+## 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]`.
+
+Une crate membre SHOULD consommer cette dépendance avec `workspace = true` et activer localement uniquement les features nécessaires à son propre code. Une feature de plateforme ou de test MUST NOT être activée globalement par commodité lorsqu'un scope plus étroit suffit.
+
+Une dépendance utilisée uniquement par les tests, benchmarks ou exemples SHOULD rester dans la section de dépendances de développement appropriée.
+
+Les contraintes de version SHOULD exprimer l'intention de compatibilité réellement souhaitée. Un pin exact ou une version volontairement ancienne MUST avoir une raison identifiable : compatibilité, reproductibilité, sécurité, bug connu ou matrice imposée par un scope plus spécifique.
+
+`cargo update` MUST NOT être exécuté opportunistement dans une tranche sans rapport avec les dépendances. Une mise à jour de résolution ou de dépendance appartient au scope courant uniquement lorsqu'elle est nécessaire et explicitement vérifiée.
+
+## Politique de `Cargo.lock`
+
+PGR ne généralise pas automatiquement la politique de lockfile d'un projet source à tous les projets Rust.
+
+La décision de versionner ou non `Cargo.lock` MUST être explicite et cohérente avec le type de produit, le mode de publication et le besoin de reproductibilité du projet. Un profil plus spécifique MAY imposer une politique particulière.
+
+Dans tous les cas, un lockfile ne remplace jamais les contraintes de version et décisions de compatibilité appartenant aux manifests et à la documentation normative.
+
+## Lints communs
+
+Un workspace structuré SHOULD déclarer les lints communs au niveau racine et les crates membres SHOULD les hériter plutôt que maintenir plusieurs copies divergentes.
+
+Le profil strict PGR recommandé pour un nouveau workspace Rust comprend au minimum :
+
+```toml
+[workspace.lints.rust]
+missing_docs = "warn"
+unreachable_pub = "deny"
+unsafe_code = "forbid"
+
+[workspace.lints.clippy]
+unwrap_used = "deny"
+expect_used = "deny"
+implicit_return = "deny"
+question_mark = "deny"
+question_mark_used = "deny"
+```
+
+Des `allow` nécessaires pour éviter qu'un lint de suggestion contredise intentionnellement le style retenu MAY être déclarés au workspace, mais la liste doit rester minimale et justifiée par une règle réelle.
+
+## Safety et FFI
+
+Le code `unsafe` est interdit par défaut dans un projet suivant le profil strict PGR.
+
+Lorsqu'une FFI ou une plateforme impose réellement une opération `unsafe`, l'exception MUST appartenir au scope le plus étroit possible : crate, module, symbole ou attribut concerné. Elle MUST être documentée et ne doit pas affaiblir silencieusement le reste du workspace.
+
+Une exception FFI locale n'autorise donc pas à remplacer globalement `unsafe_code = "forbid"` par une politique permissive pour toutes les crates.
+
+## API, visibilité et rustdoc
+
+Tout élément `pub` ou `pub(crate)` SHOULD posséder une rustdoc utile au point de déclaration lorsque son contrat dépasse une implémentation triviale locale.
+
+Une crate réutilisable SHOULD exposer son API durable depuis son crate-root par des réexports explicites. Les modules d'implémentation SHOULD rester privés ; `pub mod` ne doit pas être utilisé uniquement pour éviter de concevoir une façade stable.
+
+Un élément partagé à l'échelle de sa propre crate SHOULD être consommable via `crate::Item` après réexport approprié. Les autres crates consomment l'API publique du crate propriétaire plutôt que ses chemins internes.
+
+Les glob imports SHOULD être évités. Un alias de réexport ne doit pas servir à masquer durablement une collision de noms dans l'API ; lorsqu'un nom fait partie du contrat public, le propriétaire SHOULD choisir un nom canonique non ambigu.
+
+PGR ne généralise pas l'interdiction KSP plus stricte de tous les `use` non-traits : cette convention appartient à un profil ou projet plus spécifique tant qu'elle n'est pas nécessaire au contrat Rust général.
+
+## Contrôle de flux et erreurs
+
+Dans le code de production du profil strict PGR :
+
+- `unwrap()` et `expect()` MUST NOT servir à traiter un chemin d'erreur récupérable ;
+- `panic!` MUST NOT représenter une erreur métier récupérable ;
+- les retours explicites sont la convention par défaut ;
+- l'opérateur `?` est désactivé par le profil Clippy strict afin de conserver des chemins d'erreur explicites.
+
+Une règle plus spécifique MAY définir une politique d'erreur différente lorsqu'elle possède une justification architecturale explicite. PGR ne généralise pas l'interdiction d'une bibliothèque d'erreur particulière à partir d'un seul projet source.
+
+## Formatage
+
+`rustfmt.toml` à la racine SHOULD être le propriétaire canonique du formatage Rust d'un workspace.
+
+Le profil PGR issu des corpus actuellement éprouvés utilise notamment :
+
+```toml
+edition = "2024"
+newline_style = "Unix"
+hard_tabs = false
+tab_spaces = 4
+max_width = 160
+reorder_imports = true
+reorder_modules = true
+use_try_shorthand = false
+force_explicit_abi = true
+```
+
+L'édition de ce fichier MUST rester cohérente avec l'édition réellement utilisée par le workspace ; l'exemple `2024` décrit la baseline actuelle et ne constitue pas un pin éternel pour les futures éditions Rust.
+
+Après une modification Rust, `cargo fmt --all` applique le formatage canonique puis `cargo fmt --all -- --check` vérifie l'état livré. Une modification produite uniquement par le formatter officiel ne crée pas artificiellement une nouvelle révision documentaire d'un fichier si aucun contenu réel n'a changé.
+
+Les micro-règles de mise en page qui ne sont pas communes aux corpus ou qui sont déjà correctement possédées par `rustfmt` ne sont pas élevées automatiquement au niveau PGR.
+
+## Configuration Cargo et artefacts générés
+
+`.cargo/config.toml` est le propriétaire naturel d'une configuration Cargo partagée par le projet lorsqu'une telle configuration est nécessaire.
+
+Si un projet choisit de placer les artefacts Cargo hors de l'arborescence source, `target-dir` et les autres paramètres correspondants SHOULD être définis dans cette configuration plutôt que répétés dans chaque commande. Le chemin exact reste une décision de projet ou de skeleton et n'est pas figé par ce profil.
+
+Les sorties `target/`, caches et artefacts de compilation MUST rester hors des livraisons source sauf contrat de packaging explicite.
+
+## Tests Rust
+
+Les tests MUST NOT élargir artificiellement la visibilité de l'API de production.
+
+Les tests d'intégration Cargo résident sous `tests/` de la crate concernée et consomment son API publique.
+
+Les tests unitaires restent sous la responsabilité de la crate ou du module testé. Un workspace MAY adopter une arborescence `unit_tests/` séparée et miroir de `src/` lorsqu'elle améliore la lisibilité ; cette convention doit alors être appliquée de manière cohérente sans transformer `tests/` en tests internes.
+
+Une dépendance ou feature exclusivement nécessaire aux tests SHOULD rester dans le scope de développement/test approprié.
+
+## Validation Rust / Cargo
+
+Les catégories, l'autorité du gate et la proportionnalité restent possédées par [`400-VALIDATION.md`](400-VALIDATION.md). Ce profil ajoute seulement les commandes propres à Rust/Cargo.
+
+Lorsqu'un delta modifie du code Rust, un manifeste Cargo, une feature ou une dépendance Rust, la séquence normale SHOULD inclure :
+
+```bash
+cargo fmt --all
+cargo fmt --all -- --check
+cargo check --workspace
+cargo clippy --workspace --all-targets --all-features -- -D warnings
+```
+
+Les audits structurels read-only réellement applicables s'insèrent après le formatage et avant ou autour des contrôles Cargo selon leur responsabilité.
+
+Les tests ciblés constituent la stratégie normale d'une tranche :
+
+```bash
+cargo test -p <crate> --all-targets --all-features
+```
+
+`cargo test --workspace --all-targets --all-features` est une gate plus large réservée aux changements transverses ou aux phases où une validation globale apporte une preuve supplémentaire réelle.
+
+`cargo build` SHOULD être exécuté lorsqu'un artefact est nécessaire ; il ne doit pas être ajouté systématiquement à `cargo check` sans besoin de build ou packaging.
+
+`cargo tree` et ses variantes SHOULD être utilisés lors d'une modification de dépendances/features ou d'un diagnostic de graphe, pas comme cérémonie de chaque delta.
+
+`cargo clean` est une opération de maintenance et MUST NOT être exécuté automatiquement à chaque tranche.
+
+La validation Cargo finale appartient à l'environnement autoritaire du projet. Une prévalidation par générateur ou CI supplémentaire ne remplace pas le gate opérateur défini par le projet.
+
+## Audits PGR pour Rust
+
+Les audits Rust historiques de projets sources peuvent combiner de nombreuses responsabilités. PGR ne doit pas recopier cette complexité comme point de départ.
+
+Lorsqu'une règle Rust devient objectivement automatisable dans un projet ou skeleton concret, PGR SHOULD préférer plusieurs audits monotâches et lisibles, par exemple un contrôle de manifests/workspace distinct d'un contrôle de headers ou de façade publique.
+
+Un éventuel wrapper d'orchestration MAY appeler plusieurs audits, mais chaque audit propriétaire doit conserver une responsabilité identifiable et rester read-only.
+
+Aucun nouvel audit Rust n'est imposé par cette tranche à PGR lui-même : le dépôt PGR courant ne contient pas de workspace Rust sur lequel une telle gate fournirait une preuve réelle.
--- a/history/0.0.2/alpha.3.md
+++ b/history/0.0.2/alpha.3.md
@@ -0,0 +1,122 @@
+<!-- file: history/0.0.2/alpha.3.md -->
+<!-- version: 1 -->
+
+# History 0.0.2-alpha.3 — premier profil Rust / Cargo
+
+## Statut
+
+PASS
+
+La tranche `0.0.2-alpha.3` a été validée par l'opérateur. Le premier profil technologique réel de PGR est en place et le point de mesure prévu par le plan ne révèle pas de dérive nécessitant un REPLAN avant `alpha.4`.
+
+## Baseline
+
+La tranche précédente `0.0.2-alpha.2` a été enregistrée `PASS`, puis committée et poussée sous le commit observé :
+
+```text
+5f9b84c
+```
+
+Version validée après application de `alpha.3` :
+
+```text
+0.0.2-alpha.3
+```
+
+## Validation opérateur observée
+
+L'opérateur a confirmé la version et la présence du nouveau profil :
+
+```bash
+test "$(cat VERSION)" = "0.0.2-alpha.3"
+test -f docs/rules/510-RUST_CARGO.md
+test -f deltas/0.0.2/alpha.3.md
+```
+
+Les contrats principaux ont été retrouvés par recherche littérale, notamment :
+
+```text
+PGR MUST NOT imposer un pin exact de toolchain uniquement parce qu'un projet source historique utilisait cette version.
+le fichier PGR `VERSION` reste la version canonique de l'unité de release
+Une crate membre SHOULD consommer cette dépendance avec `workspace = true`
+PGR ne généralise pas automatiquement la politique de lockfile
+unsafe_code = "forbid"
+PGR ne généralise pas l'interdiction KSP plus stricte de tous les `use` non-traits
+cargo clippy --workspace --all-targets --all-features -- -D warnings
+PGR SHOULD préférer plusieurs audits monotâches et lisibles
+```
+
+Les liens vers `510-RUST_CARGO.md` ont été retrouvés depuis `RULES.md` et `docs/rules/000-README.md`.
+
+L'audit Markdown PGR a été exécuté :
+
+```bash
+python3 -B scripts/audit_markdown_tables.py     README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
+```
+
+Résultat observé :
+
+```text
+Markdown table audit: clean (2 table(s), 53 file(s))
+```
+
+Les contrôles Git ont réussi :
+
+```bash
+git diff --check
+
+git add VERSION RULES.md     docs/rules/000-README.md     docs/rules/510-RUST_CARGO.md     deltas/0.0.2/alpha.3.md
+
+git diff --cached --check
+git status --short
+```
+
+`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
+
+La sortie finale observée avant ajout du présent history était exactement :
+
+```text
+M  RULES.md
+M  VERSION
+A  deltas/0.0.2/alpha.3.md
+M  docs/rules/000-README.md
+A  docs/rules/510-RUST_CARGO.md
+```
+
+Les marqueurs `EXEC >>` visibles dans la transcription proviennent du prompt Bash personnalisé de l'opérateur. Ils n'indiquent pas une erreur ou une commande supplémentaire dans la gate.
+
+## Revue qualitative
+
+L'état validé respecte le scope de `alpha.3` :
+
+- les règles Rust/Cargo réutilisables sont séparées des conventions propres à KSP et `sasedev-games` ;
+- la politique de `Cargo.lock` reste une décision explicitement liée au type de projet au lieu d'être généralisée depuis les corpus historiques ;
+- les exceptions FFI et plateforme restent bornées au scope qui les impose ;
+- aucune version de crate, dépendance ou toolchain historique n'est devenue un pin universel ;
+- aucun audit Rust complexe n'a été ajouté sans workspace Rust réel ni propriété stable à contrôler ;
+- le profil tient dans un propriétaire documentaire unique et cohérent sans matérialiser prématurément de famille supplémentaire.
+
+## Point de mesure
+
+Le point de mesure prévu par le plan est satisfaisant.
+
+La matérialisation d'un profil complet n'a pas nécessité de série de fixes ni de découpage supplémentaire. Le forecast suivant reste raisonnable :
+
+```text
+0.0.2-alpha.4 — Java / Maven / Gradle
+0.0.2-alpha.5 — Android
+```
+
+Un REPLAN reste obligatoire si une tranche ultérieure révèle une dérive significative ; aucune dérive de cette nature n'est observée ici.
+
+## Résultat
+
+`0.0.2-alpha.3` est validée `PASS`.
+
+La tranche suivante autorisée est :
+
+```text
+0.0.2-alpha.4
+```
+
+Elle est consacrée au profil `Java / Maven / Gradle`, en maintenant une frontière nette entre règles du langage Java, politique de build Maven/Gradle et contraintes de plateforme qui appartiendront notamment au futur profil Android.