games/docs/rules/RULES_VALIDATION_MATRIX.md

Matrice normative des commandes et validations

Principes

La matrice associe un identifiant stable à chaque famille de commandes. Le delta sélectionne les commandes applicables selon les fichiers touchés, leurs dépendances et la phase de maturité.

Une commande dépendante n'est exécutée que lorsque ses prérequis applicables sont propres.

Les commandes ciblées restent la norme pendant l'implémentation ; les gates workspace et les smokes de distribution deviennent plus larges à mesure que la version approche de beta/RC.

Matrice

ID	Commande / action	Dépend de	Déclencheur principal	Phase minimale typique
CMD-001	cargo fmt --all	—	source Rust modifié	pre
CMD-002	cargo fmt --all -- --check	CMD-001 si formatage requis	source Rust modifié	pre
CMD-010	python3 scripts/audit_rust_workspace_rules.py	—	Rust/workspace/règles Rust	pre
CMD-011	python3 scripts/audit_markdown_tables.py ...	—	Markdown/règles/docs	pre
CMD-012	python3 scripts/audit_distribution_layout.py	—	layout/build/distribution	pre
CMD-020	cargo check -p <crate>	CMD-002, CMD-010	crate Rust ciblée	pre
CMD-021	cargo test -p <crate> --all-targets --all-features	CMD-020	comportement/API crate	pre
CMD-022	tests des crates consommatrices impactées	CMD-021	API publique/contrat partagé modifié	pre
CMD-023	cargo check --workspace	audits applicables	changement transverse / gate globale	selon portée
CMD-024	cargo clippy --workspace --all-targets --all-features -- -D warnings	CMD-023	gate complète	alpha/beta/RC
CMD-025	cargo test --workspace --all-targets --all-features	CMD-024	changement transverse / frontière de phase	beta/RC
CMD-030	build Desktop --release ciblé	gates Rust applicables	runner/distribution Desktop touché	beta
CMD-031	smoke Desktop release	CMD-030	runtime Desktop touché	beta
CMD-040	cargo tauri build	gates Rust/frontend applicables	périmètre Tauri touché	beta
CMD-041	smoke Tauri release	CMD-040	runtime Tauri touché	beta
CMD-050	build Rust Android ABI ciblé	gates Rust applicables	Android/JNI/backend natif touché	pre/beta
CMD-051	Gradle assembleDebug application ciblée	CMD-050 lorsque Rust natif change	Android/app/manifest/Java touché	pre/beta
CMD-052	install + smoke AVD	CMD-051	Android concerné	beta
CMD-053	install + smoke appareil réel	CMD-051	Android concerné	beta/RC
CMD-060	cargo clean --dry-run --verbose	—	contrôle disque / préparation nettoyage	maintenance
CMD-061	cargo clean	décision explicite de nettoyage	accumulation disque / jalon de cycle	maintenance
CMD-062	cargo clean -p <package> ou nettoyage par --release / --profile / --target	—	nettoyage ciblé suffisant	maintenance

Dépendances entre crates

Lorsqu'une crate A change :

1. exécuter les validations ciblées de A ;
2. déterminer les consommateurs dont le contrat est affecté ;
3. exécuter les validations ciblées des consommateurs concernés ;
4. passer aux gates workspace lorsque la portée ne peut plus être bornée raisonnablement ou lorsqu'une frontière de maturité l'exige.

Une modification interne sans changement de contrat ne force pas mécaniquement tous les consommateurs transitifs à être retestés.

Une modification d'API publique, de représentation partagée, de feature structurante ou de comportement contractuel élargit la portée des tests.

Nettoyage Cargo et contrôle disque

Le projet utilise ../builds/sasedev-games/target comme target-dir. Cette zone peut accumuler plusieurs profils, triples cibles, artefacts incrémentaux et anciennes variantes au cours d'un cycle de développement.

La politique est donc double :

• utiliser CMD-062 lorsqu'un nettoyage ciblé suffit ;
• utiliser CMD-061 périodiquement afin d'éviter une croissance non bornée du répertoire de build.

Le nettoyage complet est normalement positionné au début d'un nouveau cycle de développement lorsque l'on souhaite évacuer les artefacts de la version précédente, ou avant une validation finale RC/stable lorsqu'un rebuild propre est recherché et que l'espace disque le justifie.

Le delta ou le plan de version indique quel jalon de nettoyage est retenu. Il n'est pas nécessaire d'exécuter cargo clean à chaque prerelease.

Vérification des versions d'en-tête

Avant livraison d'un delta :

1. fichier modifié réellement et déjà versionné → en-tête incrémenté ;
2. fichier uniquement reformaté mécaniquement → en-tête inchangé ;
3. nouveau fichier versionné → version: 1 sauf règle spécialisée ;
4. renommage modifiant file: → en-tête incrémenté ;
5. delta antérieur → aucun ajout sémantique rétroactif.

Cette vérification fait partie de la revue de livraison même lorsqu'aucun audit automatisé ne dispose encore de la version précédente pour comparer.