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	—	Rust ou dépendance Cargo modifiée	pre
CMD-002	cargo fmt --all -- --check	CMD-001	Rust ou dépendance Cargo modifiée	pre
CMD-010	python3 scripts/audit_rust_workspace_rules.py	—	Rust/Cargo/workspace/règles Rust concernés	pre
CMD-011	python3 scripts/audit_markdown_tables.py ...	—	Markdown concerné	pre
CMD-012	python3 scripts/audit_distribution_layout.py	—	layout/build/distribution concerné	pre
CMD-020	cargo check -p <crate>	audits applicables	diagnostic ciblé facultatif	pre
CMD-021	cargo test -p <crate> --all-targets --all-features	CMD-023, CMD-024	comportement/API crate	pre
CMD-022	tests ciblés des crates consommatrices impactées	CMD-021	API publique/contrat partagé modifié	pre
CMD-023	cargo check --workspace	CMD-002, audits applicables	Rust ou dépendance Cargo modifiée	pre
CMD-024	cargo clippy --workspace --all-targets --all-features -- -D warnings	CMD-023	Rust ou dépendance Cargo modifiée	pre
CMD-025	cargo test --workspace --all-targets --all-features	CMD-024	gate rare planifiée / portée transverse incertaine	selon plan
CMD-026	cargo tree -p <crate> --edges normal ou variante ciblée	—	dépendances/features modifiées ou diagnostic	selon portée
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	(cd <tauri-app> && cargo tauri dev)	gates Rust/frontend applicables	smoke interactif Tauri Desktop	pre/beta
CMD-041	(cd <tauri-app> && cargo tauri build)	gates Rust/frontend applicables	packaging Tauri Desktop final/prefinal	beta/RC
CMD-042	build Rust wasm32-unknown-unknown + wasm-bindgen --target web	gates Rust de l'adapter	adapter WASM/Web direct touché	pre
CMD-043	(cd Web/<game> && npm install && npm run build)	CMD-042 si frontend avec WASM	frontend Web direct touché	pre
CMD-044	smoke navigateur du host Web direct	CMD-043	Canvas/input/responsive Web touchés	pre/beta
CMD-045	(cd <tauri-app> && cargo tauri android init)	environnement Android/Tauri	initialisation unique de la cible Tauri Android	pre
CMD-046	(cd <tauri-app> && cargo tauri android dev)	gates Rust/frontend applicables	smoke interactif Tauri Android	pre/beta
CMD-047	(cd <tauri-app> && cargo tauri android build)	gates Rust/frontend applicables	packaging Tauri Android final/prefinal	beta/RC
CMD-050	build Rust Android ABI ciblé	gates Rust applicables	Android/JNI/backend natif touché	pre/beta
CMD-051	(cd Android && ./gradlew :<app>:assembleDebug)	CMD-050 si 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

Sélection proportionnelle

Les audits CMD-010 à CMD-012 sont sélectionnés selon les fichiers touchés ; ils ne forment pas un trio obligatoire.

Dès que du Rust ou une dépendance Cargo change, la séquence minimale obligatoire est CMD-001 → CMD-002 → audits applicables → CMD-023 → CMD-024. Les tests CMD-021/CMD-022 restent ciblés par défaut.

CMD-025 est planifié seulement à un ou quelques jalons de la version/session, par exemple un état initial lorsqu'une baseline globale doit être confirmée, une validation préfinale/finale, ou un changement dont la portée transverse ne peut pas être bornée avec confiance.

CMD-026 est ajouté lorsqu'un graphe de dépendances/features a changé ou doit être diagnostiqué ; il est omis des validations ordinaires sans changement de dépendances.

Toute commande avec changement de répertoire utilise un sous-shell, comme le montrent CMD-040, CMD-041, CMD-043, CMD-045 à CMD-047 et CMD-051.

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.