Sasedev/pgr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.0.5-alpha.7

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-25 11:45:10 +02:00
parent 4e1c1cd6f0
commit ac03b78708
8 changed files with 398 additions and 28 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
docs/skeletons/002-RUST_CARGO_WORKSPACE.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/skeletons/002-RUST_CARGO_WORKSPACE.md -->
<!-- version: 2 -->
<!-- version: 3 -->
# Skeleton — Rust/Cargo workspace
@@ -64,15 +64,15 @@ templates/rust-cargo/crates/project-core-lib/Cargo.toml
Avant de considérer la specialization comme instanciée, résoudre explicitement au minimum :
1. le release unit gouverné et la relation entre son `VERSION` et `[workspace.package].version` ;
2. la liste réelle des packages membres, leurs noms, leurs rôles et leurs chemins ;
3. l'édition Rust, le resolver Cargo et la toolchain stable compatible ;
2. le nom court/abréviation canonique du projet, la liste réelle des packages membres, leurs responsabilités, rôles et chemins, puis la conformité de leurs noms au contrat de `510-RUST_CARGO.md` ;
3. l'édition Rust 2024, le resolver Cargo et la toolchain stable compatible, ou l'exception externe explicitement documentée ;
4. la politique de publication et les métadonnées réelles communes (`license`, `repository`, `authors`) lorsqu'elles existent ;
5. les dépendances réellement partagées, leurs contraintes de version et les features qui doivent rester locales à chaque membre ;
6. la politique de versionnement de `Cargo.lock` adaptée au type de produit ;
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 audits Rust facultatifs réellement adoptés, dont éventuellement le contrat de façade crate-root, et leur scope exact ;
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.
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.
@@ -103,7 +103,7 @@ Le projet ne doit pas remplir les champs manquants avec des identités fictives
Pour chaque crate réellement nécessaire, utiliser `templates/rust-cargo/crates/project-core-lib/Cargo.toml` comme exemple de manifest membre puis adapter son chemin et son nom.
`project-core-lib` n'est pas un nom de crate imposé. Une crate bibliothèque, binaire ou spécialisée doit conserver le layout et les héritages qui correspondent à son rôle réel.
`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.
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.
@@ -131,9 +131,9 @@ Décider explicitement si `Cargo.lock` est versionné selon le type de produit,
Si le projet adopte les conventions documentées dans [`../validation/002-RUST_STYLE_AUDITS.md`](../validation/002-RUST_STYLE_AUDITS.md), copier les scripts de style concernés et adapter leurs headers à leurs chemins locaux. La sélection des fichiers doit rester explicite. En particulier, l'audit des blocs de constantes ne doit jamais réordonner une table de protocole, une séquence de migrations ou toute autre structure dont l'ordre possède une sémantique propre.
Si le projet adopte le contrat de façade décrit dans [`../validation/003-RUST_EXPORT_COMPLETENESS.md`](../validation/003-RUST_EXPORT_COMPLETENESS.md), copier `audit_rust_export_completeness.py` avec `_rust_audit_common.py`. Une adoption d'un projet existant SHOULD commencer en `--report-only`, résoudre les écarts ou exceptions locales, puis seulement rendre l'audit bloquant.
Pour une nouvelle baseline contrôlée, le contrat de façade décrit dans [`../validation/003-RUST_EXPORT_COMPLETENESS.md`](../validation/003-RUST_EXPORT_COMPLETENESS.md) appartient au profil strict ; `audit_rust_export_completeness.py` avec `_rust_audit_common.py` SHOULD être adopté afin de contrôler les propriétés que `rustc` et Clippy ne possèdent pas. Une adoption d'un projet existant SHOULD commencer en `--report-only`, résoudre les écarts ou exceptions locales, puis seulement rendre l'audit bloquant.
Ne pas copier ces scripts uniquement parce qu'ils existent dans PGR.
Les audits de style de `002-RUST_STYLE_AUDITS.md` restent séparés et ne sont copiés que lorsque leurs conventions sont retenues. Aucun script n'est copié uniquement parce qu'il existe dans PGR.
## Validation initiale
@@ -158,7 +158,9 @@ La validation doit aussi confirmer :
CHECK VERSION et workspace.package.version cohérents pour un train de release unique
CHECK aucun placeholder project-name/project-core-lib non résolu dans les fichiers adoptés
CHECK édition Rust cohérente entre Cargo.toml et rustfmt.toml
CHECK membres du workspace existants et correctement nommés
CHECK membres du workspace existants, préfixés et nommés selon leur responsabilité/rôle
CHECK édition Rust 2024 ou exception externe explicitement documentée
CHECK profil strict de chemins/façade appliqué ou override borné documenté
CHECK politique Cargo.lock explicitement décidée
CHECK artefacts Cargo hors des livraisons source selon la politique locale
REVIEW dépendances/features, lints et métadonnées réellement nécessaires