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

0.3.0-2-beta.2.fix.2

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-20 15:07:25 +02:00
parent 54121215b4
commit 45c31d4721
9 changed files with 221 additions and 58 deletions
Download Patch File Download Diff File Expand all files Collapse all files

66
deltas/0.3.0/2-beta.2.fix.2.md Normal file
View File

@@ -0,0 +1,66 @@
<!-- file: deltas/0.3.0/2-beta.2.fix.2.md -->
<!-- version: 1 -->
# Delta 0.3.0-2-beta.2.fix.2
## Base requise
`0.3.0-2-beta.2.fix.1`.
## Objectif
Finaliser la gouvernance des commandes et des validations transmise au prompt `0.3.1`, afin d'éviter les gates surdimensionnées, les logs pollués et les workflows Tauri incorrects.
Ce correctif est strictement documentaire. Il ne modifie aucun code, manifeste runtime, dépendance, configuration de build ni version technique.
## Décisions consolidées
- un fix strictement documentaire ne modifie aucune version Cargo/npm/Gradle/Tauri/Android ou autre version consommée par le runtime/build ;
- tout changement de code Rust, manifeste Cargo, feature ou dépendance Rust déclenche `cargo fmt --all`, `cargo fmt --all -- --check`, `cargo check --workspace` puis `cargo clippy --workspace --all-targets --all-features -- -D warnings` ;
- les audits Python sont sélectionnés selon les fichiers réellement touchés ;
- `cargo test -p <crate> --all-targets --all-features` est la stratégie normale ;
- `cargo test --workspace --all-targets --all-features` est réservé à un ou quelques jalons explicitement planifiés ou à une portée transverse incertaine ;
- `cargo tree` n'est exécuté que si les dépendances/features changent ou qu'un diagnostic de frontière le justifie ;
- toute commande nécessitant un changement de répertoire utilise `(cd <dir> && <commande>)` ;
- dans une app Tauri, npm sert à gérer les dépendances frontend ; les smokes passent par `cargo tauri dev` et le packaging final/prefinal par `cargo tauri build`, les hooks Tauri possédant Vite/TypeScript/WASM.
## Fichiers ajoutés
```text
history/0.3.0/2-beta.2.fix.1.md
deltas/0.3.0/2-beta.2.fix.2.md
```
## Fichiers modifiés
```text
docs/plans/001-V0_3_0_WEB_SNAKE_POC_PLAN.md
docs/rules/PROMPT_STRUCTURE.md
docs/rules/RULES_COMMANDS.md
docs/rules/RULES_SESSION_PLANNING.md
docs/rules/RULES_VALIDATION_MATRIX.md
docs/rules/VERSION_WORKFLOW.md
prompts/003-V0_3_1_START_PROMPT.md
```
## Fichiers supprimés
Aucun.
## Version technique
Aucune version technique n'est modifiée. La workspace et le package Web restent `0.3.0-2-beta.2`.
## Validation attendue
Les seuls fichiers touchés sont Markdown. L'audit applicable est donc :
```bash
python3 scripts/audit_markdown_tables.py docs prompts deltas history
```
Aucun `cargo fmt`, `cargo check`, Clippy, test Cargo, `cargo tree`, audit de distribution, npm, Tauri ou smoke n'est requis pour ce correctif documentaire.
## Après validation
Si la revue humaine confirme ces règles, ouvrir `0.3.0-3-rc.1`. La RC appliquera la matrice finale, écrira l'entrée RC du `CHANGELOG.md` et vérifiera une dernière fois le prompt `0.3.1` sans rouvrir le scope fonctionnel.

4
docs/plans/001-V0_3_0_WEB_SNAKE_POC_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/001-V0_3_0_WEB_SNAKE_POC_PLAN.md -->
<!-- version: 14 -->
<!-- version: 15 -->
# Plan v0.3.0 — baseline Snake et premier POC Web direct
@@ -117,6 +117,8 @@ Gate : cohérence docs/plan/deltas/`CHANGELOG.md`/`ROADMAP.md`/history/prompt, a
Suivi `2-beta.2.fix.1` : la gate mécanique de `2-beta.2` passe, mais la revue humaine juge le prompt `0.3.1` trop synthétique pour éviter des rappels de workflow au cours de la prochaine session. Le fix enrichit ce prompt, formalise une structure durable de prompts, précise le timing prompt/RC/CHANGELOG/ROADMAP/history et introduit une politique non cérémonielle pour `README.md`/`USAGE.md`. Le fix est strictement documentaire et conserve donc la version technique `0.3.0-2-beta.2`.
Suivi `2-beta.2.fix.2` : la revue du prompt enrichi valide son niveau de contexte, mais précise la gouvernance des commandes afin d'éviter des validations trop larges ou répétitives. Le fix rend obligatoires `cargo fmt`, `cargo check --workspace` et Clippy workspace strict dès que Rust ou ses dépendances changent, garde les tests ciblés comme norme, réserve le test workspace complet à quelques jalons planifiés, limite `cargo tree` aux changements/diagnostics de dépendances, sélectionne les audits Python selon les fichiers touchés, impose les sous-shells pour les changements de répertoire et rappelle que Tauri possède Vite via `cargo tauri dev/build`. Ce correctif reste strictement documentaire et ne modifie aucune version technique.
### `3-rc.1` — candidate gelée
Reproductibilité, validation finale de la candidate et derniers défauts strictement nécessaires à la publication. Le prompt suivant préparé pendant la consolidation est vérifié/complété si l'état RC apporte une information nouvelle. Aucun nouveau POC ni nouvelle capability.

8
docs/rules/PROMPT_STRUCTURE.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/PROMPT_STRUCTURE.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Structure des prompts de reprise
@@ -19,6 +19,12 @@ Le prompt rappelle les invariants qui évitent les erreurs de workflow et renvoi
- **PROMPT-STR-006** — Le prompt contient un forecast souple jusqu'à la stable. Il réserve les responsabilités de développement, validation large, consolidation documentaire, préparation de publication/RC et release mécanique sans rendre les numéros immuables.
- **PROMPT-STR-007** — Le prompt rappelle où se trouve la définition des commandes : `docs/rules/RULES_COMMANDS.md` pour la politique d'exécution et `docs/rules/RULES_VALIDATION_MATRIX.md` pour les IDs, dépendances et déclencheurs. Il ne recopie que les commandes indispensables à la reprise ou au premier gate.
- **PROMPT-STR-008** — Le prompt rappelle la séparation utilisateur/générateur : les audits statiques peuvent être exécutés par le générateur, mais les builds, tests et smokes finaux restent côté utilisateur conformément à `CMD-BUILD-005` et ne sont jamais déclarés réussis sans sortie réelle.
- **PROMPT-STR-009** — Le prompt rappelle la cadence de validation sans recopier toute la matrice : audits Python sélectionnés selon les fichiers touchés ; `cargo fmt --all`, `cargo fmt --all -- --check`, `cargo check --workspace` et Clippy workspace strict obligatoires dès que du Rust ou une dépendance Cargo change ; tests `cargo test -p ...` ciblés par défaut ; test workspace complet réservé aux rares jalons planifiés ou aux changements transverses incertains ; `cargo tree` seulement lors d'un changement/diagnostic de dépendances.
## Commandes avec répertoire et Tauri
- **PROMPT-STR-016** — Le prompt rappelle que toute commande nécessitant un `cd` est englobée dans un sous-shell, par exemple `(cd <dir> && <commande>)`, afin de ne pas modifier le répertoire courant pour les commandes suivantes.
- **PROMPT-STR-017** — Lorsqu'une version touche Tauri, le prompt rappelle que `npm` sert à gérer les dépendances frontend mais que les builds/smokes passent par Tauri : `(cd <tauri-app> && cargo tauri dev)` pour le smoke courant et `(cd <tauri-app> && cargo tauri build)` aux phases finales de packaging prévues. Les hooks Tauri possèdent Vite/TypeScript/WASM ; `npm run dev`/`npm run build` ne deviennent pas des gates manuelles Tauri.
## Documentation et traçabilité à rappeler

32
docs/rules/RULES_COMMANDS.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/RULES_COMMANDS.md -->
<!-- version: 12 -->
<!-- version: 13 -->
# Règles d'exécution des commandes
@@ -16,18 +16,20 @@
- **CMD-GEN-009** — Lorsque l'utilisateur fournit une gate complète propre, le delta est considéré validé et le travail peut passer automatiquement au delta planifié suivant sauf instruction contraire.
- **CMD-GEN-010** — Si une gate échoue, la progression vers le delta suivant est suspendue ; le correctif est livré sous le suffixe `.fix.N` du delta courant, sauf décision explicite contraire.
- **CMD-GEN-011** — Les commandes d'audit Markdown couvrent également `history/` dès que cette arborescence existe.
- **CMD-GEN-012** — Les audits Python sont sélectionnés selon les fichiers réellement touchés : audit Rust/workspace pour le périmètre Rust/Cargo/workspace concerné, audit Markdown pour les fichiers Markdown concernés, audit de distribution pour les changements de layout/build/packaging. Ils ne sont pas tous exécutés par habitude sur chaque delta.
- **CMD-GEN-013** — Toute commande nécessitant un changement temporaire de répertoire est exécutée dans un sous-shell, par exemple `(cd Web/game-snake-poc && npm run build)`, afin de revenir automatiquement à la racine du workspace après la commande.
## Rust et Cargo
- **CMD-RUST-001** — Lorsqu’un delta a modifié au moins un fichier Rust, l’utilisateur exécute `cargo fmt --all` au début de la validation afin d’appliquer le formatage canonique; les changements purement produits par rustfmt constituent l’unique exception à l’incrément obligatoire de l’en-tête de version du fichier.
- **CMD-RUST-002** — `cargo fmt --all -- --check` suit immédiatement le formatage et constitue la gate canonique de conformité rustfmt.
- **CMD-RUST-003** — `cargo check --workspace` est la première gate de compilation globale après les audits statiques.
- **CMD-RUST-004** — `cargo clippy --workspace --all-targets --all-features -- -D warnings` est exécuté après un `cargo check --workspace` propre pour la gate complète.
- **CMD-RUST-005** — Les tests ciblés `cargo test -p <crate> --all-targets --all-features` sont la stratégie normale d’un delta et doivent couvrir toutes les crates directement ou transitivement affectées lorsque cela est raisonnablement déterminable.
- **CMD-RUST-006** — `cargo test --workspace --all-targets --all-features` est une gate lourde réservée au démarrage d’une nouvelle version `X.Y.Z`, à la fin d’une phase/version, aux changements transverses importants ou lorsqu’il existe un doute raisonnable sur la portée des tests ciblés.
- **CMD-RUST-001** — Dès qu'un delta modifie du code Rust, un manifeste Cargo, une feature ou une dépendance Rust, l'utilisateur exécute `cargo fmt --all`; les changements purement produits par rustfmt constituent l'unique exception à l'incrément obligatoire de l'en-tête de version du fichier.
- **CMD-RUST-002** — `cargo fmt --all -- --check` suit le formatage et constitue la gate canonique de conformité rustfmt.
- **CMD-RUST-003** — Tout delta qui touche du code Rust ou ses dépendances exécute `cargo check --workspace` après les audits statiques applicables. Un `cargo check -p <crate>` peut servir de diagnostic rapide, mais ne remplace pas cette gate workspace.
- **CMD-RUST-004** — Tout delta qui touche du code Rust ou ses dépendances exécute ensuite `cargo clippy --workspace --all-targets --all-features -- -D warnings`. Cette gate n'est pas réservée aux seules phases finales.
- **CMD-RUST-005** — Les tests ciblés `cargo test -p <crate> --all-targets --all-features` sont la stratégie normale d'un delta et couvrent les crates directement affectées ainsi que les consommateurs dont le contrat est réellement impacté.
- **CMD-RUST-006** — `cargo test --workspace --all-targets --all-features` est une gate lourde exécutée seulement un petit nombre de fois explicitement prévues dans le plan de version/session, typiquement à une validation initiale si elle apporte une valeur réelle, à une validation préfinale/finale, lors d'un changement transverse important ou lorsqu'il existe un doute raisonnable sur la portée des tests ciblés. Elle n'est pas répétée à chaque delta.
- **CMD-RUST-007** — `cargo run -p <desktop-runner>` sert aux smokes manuels Desktop et n'est pas substitué aux tests automatisés.
- **CMD-RUST-008** — `cargo build` est utilisé lorsqu'un artefact exécutable ou une bibliothèque est réellement nécessaire ; il n'est pas lancé systématiquement en plus de `cargo check`.
- **CMD-RUST-009** — `cargo tree` et ses variantes sont des commandes de diagnostic de dépendances, pas des gates obligatoires de chaque delta.
- **CMD-RUST-009** — `cargo tree` et ses variantes ne sont exécutés que lorsqu'un delta modifie les dépendances/features, lorsqu'une frontière de dépendances doit être vérifiée ou lorsqu'un diagnostic explicite le justifie. Ils ne font pas partie de la validation automatique d'un delta sans changement de dépendances.
- **CMD-RUST-010** — `cargo update` n'est jamais exécuté opportunistement. Toute mise à jour de dépendance doit appartenir à une tranche explicitement consacrée aux dépendances ou être nécessaire à la fonctionnalité en cours.
- **CMD-RUST-011** — `cargo clean` est l'outil canonique de remise à zéro complète du cache de build Cargo et peut être utilisé périodiquement pour maîtriser la taille de `../builds/sasedev-games/target`.
- **CMD-RUST-012** — Un nettoyage complet n'est pas exécuté à chaque delta. Il est planifié à un jalon de cycle approprié, normalement au démarrage de la première prerelease de développement lorsque l'ancien cache doit être évacué, ou au plus tard avant la validation finale RC/stable si l'accumulation disque le justifie.
@@ -58,10 +60,12 @@
- **CMD-WEB-002** — Lorsqu'une cible Web existe, ses commandes de build et test sont documentées avant d'être ajoutées aux gates.
- **CMD-WEB-003** — Le POC Tauri/WASM historique `0.1.0` utilise `scripts/build_reflex_tauri_wasm.py` ; ce script reste une référence de baseline mais ne doit pas être réutilisé comme orchestrateur par un POC `0.3.x`, conformément à `CMD-BUILD-004`.
- **CMD-WEB-004** — Les fichiers produits par `wasm-bindgen` sont générés localement et ne sont pas commités.
- **CMD-WEB-005** — `npm run dev` et `npm run build` du frontend Tauri sont pilotés par les hooks Tauri ; ils ne constituent pas des gates manuelles indépendantes.
- **CMD-WEB-006** — Pour un host Web navigateur direct sous `Web/<game>/`, `npm install`/`npm run build` et le serveur Vite peuvent être exécutés directement comme gates frontend ; ils ne sont pas couplés à Tauri.
- **CMD-WEB-007** — Le build d'un host Web direct qui consomme un adapter `wasm-bindgen` exécute d'abord le build Rust/WASM et la génération des bindings hors dépôt, puis seulement le build TypeScript/Vite.
- **CMD-WEB-008** — Un smoke navigateur manuel d'un host Web direct vérifie au minimum le chargement WASM, le Canvas, les entrées prévues par la tranche et le comportement responsive concerné.
- **CMD-WEB-005** — Dans une app Tauri, `npm` sert uniquement à gérer les dépendances frontend lorsque nécessaire, par exemple `npm i <package>`, `npm i -D <package>` ou leur opération inverse. Les scripts `npm run dev`, `npm run build` ou équivalents ne sont pas des gates manuelles : Vite/TypeScript/WASM sont déclenchés par les hooks Tauri configurés.
- **CMD-WEB-006** — Le smoke normal d'une app Tauri est lancé via `(cd <tauri-app> && cargo tauri dev)`. Cette commande possède le serveur Vite et les hooks frontend nécessaires.
- **CMD-WEB-007** — Le packaging Tauri est validé dans les phases finales prévues par le plan via `(cd <tauri-app> && cargo tauri build)`, typiquement en beta préfinale, RC ou avant release selon le scope. Il n'est pas exécuté après chaque petit delta Tauri.
- **CMD-WEB-008** — Pour un host Web navigateur direct sous `Web/<game>/`, les commandes npm/Vite peuvent être exécutées directement, toujours dans un sous-shell lorsqu'un changement de répertoire est nécessaire, par exemple `(cd Web/<game> && npm install && npm run build)`.
- **CMD-WEB-009** — Le build d'un host Web direct qui consomme un adapter `wasm-bindgen` exécute d'abord le build Rust/WASM et la génération des bindings hors dépôt, puis seulement le build TypeScript/Vite.
- **CMD-WEB-010** — Un smoke navigateur manuel d'un host Web direct vérifie au minimum le chargement WASM, le Canvas, les entrées prévues par la tranche et le comportement responsive concerné.
## Git et fichiers générés
@@ -74,7 +78,7 @@
- **CMD-BETA-001** — À l'entrée en beta, `scripts/audit_distribution_layout.py` vérifie les frontières statiques nécessaires aux runners et packagings supportés.
- **CMD-BETA-002** — La transition alpha vers beta exécute une suite Cargo workspace complète en plus des tests ciblés.
- **CMD-BETA-003** — Si la version touche le périmètre Tauri, au moins un build de packaging beta est lancé via `cargo tauri build`; ses hooks possèdent le build WASM et Vite/TypeScript.
- **CMD-BETA-003** — Si la version touche le périmètre Tauri, le plan réserve au moins une validation de packaging dans une phase finale appropriée via `(cd <tauri-app> && cargo tauri build)` ; les itérations et smokes courants utilisent `cargo tauri dev`.
- **CMD-BETA-004** — Les APK Debug servent à la validation multi-appareils beta ; la signature de publication appartient à la phase RC/stable.
## RC et release
@@ -82,7 +86,7 @@
- **CMD-RC-001** — L'entrée en RC gèle le périmètre fonctionnel de la version courante ; seuls les correctifs, la reproductibilité des builds, le packaging, la documentation de livraison et les défauts de release sont admis.
- **CMD-RC-002** — La validation d'une RC exécute `cargo test --workspace --all-targets --all-features` en plus des audits, du check et de Clippy strict.
- **CMD-RC-003** — Les deux runners Desktop natifs sont construits en `--release` et font l'objet d'un smoke sur les binaires de release.
- **CMD-RC-004** — Le POC Tauri est construit uniquement via `cargo tauri build`; ses hooks possèdent toujours le build WASM et Vite/TypeScript.
- **CMD-RC-004** — Une RC Tauri est construite via `(cd <tauri-app> && cargo tauri build)` ; ses hooks possèdent toujours le build WASM et Vite/TypeScript. Les smokes interactifs restent lancés avec `(cd <tauri-app> && cargo tauri dev)`.
- **CMD-RC-005** — Android RC revalide au minimum x86_64 sur AVD et ARM64 sur appareil réel avec les APK issus de l'état RC.
- **CMD-RC-006** — Les secrets de signature, keystores et credentials de publication ne sont jamais commités. Leur présence est une condition externe de publication, pas une donnée du dépôt.
- **CMD-RC-007** — Une RC n'est promue en stable que si aucun correctif `.fix.N` n'est nécessaire après la gate RC complète.

3
docs/rules/RULES_SESSION_PLANNING.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/RULES_SESSION_PLANNING.md -->
<!-- version: 4 -->
<!-- version: 5 -->
# Règles de cadrage des versions, sessions et prompts
@@ -26,6 +26,7 @@ Ces règles imposent un découpage suffisamment petit pour qu'une version puisse
- **SESSION-012** — Plusieurs micro-tranches sans valeur de validation indépendante peuvent être regroupées.
- **SESSION-013** — Le découpage suit des unités fonctionnelles complètes et validables ; une fonctionnalité ne doit pas être volontairement coupée au milieu uniquement pour respecter un numéro de prerelease.
- **SESSION-014** — Chaque tranche livre son delta et ses validations proportionnelles avant la tranche suivante.
- **SESSION-015** — Le plan créé en `0-pre.1` identifie explicitement le ou les rares jalons où `cargo test --workspace --all-targets --all-features` apporte une valeur globale (initial si nécessaire, préfinal/final ou changement transverse). Les autres tranches privilégient les tests `cargo test -p ...` ciblés.
## Une version par session

69
docs/rules/RULES_VALIDATION_MATRIX.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/RULES_VALIDATION_MATRIX.md -->
<!-- version: 3 -->
<!-- version: 4 -->
# Matrice normative des commandes et validations
@@ -13,33 +13,46 @@ Les commandes ciblées restent la norme pendant l'implémentation ; les gates wo
## 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-042` | build Rust `wasm32-unknown-unknown` + `wasm-bindgen --target web` | gates Rust de l'adapter | adapter WASM/Web direct touché | `pre` |
| `CMD-043` | `npm run build` depuis `Web/<game>/` | `CMD-042` si le frontend consomme 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-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 |
| 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 | `pre`/beta |
| `CMD-041` | `(cd <tauri-app> && cargo tauri build)` | gates Rust/frontend applicables | packaging Tauri 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-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` et `CMD-051`.
## Dépendances entre crates

4
docs/rules/VERSION_WORKFLOW.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/VERSION_WORKFLOW.md -->
<!-- version: 5 -->
<!-- version: 6 -->
# Versionnement, maturité et livraisons
@@ -105,7 +105,7 @@ La promotion `rc` puis stable d'une version de conception exige une validation h
## Correctifs strictement documentaires
- **VER-DOCFIX-001** — Un `.fix.N` limité à la documentation, aux prompts, aux deltas, à `history/` ou aux règles non consommées par le build/runtime ne modifie pas `workspace.package.version` ni les versions de packages runtime. L'identité du correctif est portée par le delta et son archive.
- **VER-DOCFIX-001** — Un `.fix.N` limité à la documentation, aux prompts, aux deltas, à `history/` ou aux règles non consommées par le build/runtime ne modifie aucune version technique : ni `workspace.package.version`/`Cargo.toml`, ni `package.json`, ni Gradle/Android, ni `tauri.conf.json`, ni autre métadonnée de version consommée par un build ou une distribution. L'identité du correctif est portée uniquement par le delta et son archive.
- **VER-DOCFIX-002** — Une prerelease non-fix (`pre.N`, `alpha.N`, `beta.N`, `rc.N`) synchronise sa version technique selon le workflow de phase même lorsque son contenu est principalement documentaire.
- **VER-DOCFIX-003** — Dès qu'un correctif touche du code, une configuration exécutable, un manifeste consommé par le build/runtime ou un artefact distribué, la version technique suit l'identifiant `.fix.N`.

38
history/0.3.0/2-beta.2.fix.1.md Normal file
View File

@@ -0,0 +1,38 @@
<!-- file: history/0.3.0/2-beta.2.fix.1.md -->
<!-- version: 1 -->
# Historique 0.3.0-2-beta.2.fix.1
## Statut
Revue humaine effectuée le 2026-09-20. Le niveau de détail du prompt `0.3.1` est jugé globalement satisfaisant, mais la politique de commandes doit encore être précisée avant RC ; `2-beta.2.fix.2` est donc ouvert.
## Résultat de revue
Éléments acceptés :
```text
prompt de reprise autonome sans reproduire toute la documentation KSP
timing du prompt suivant / RC / CHANGELOG / ROADMAP clarifié
rôle de deltas/ et history/ clarifié
politique README.md / USAGE.md jugée adaptée
fix strictement documentaire sans bump des versions runtime confirmé
```
Précisions demandées avant RC :
```text
cargo fmt/check workspace/Clippy strict obligatoires dès que Rust ou ses dépendances changent
audits Python sélectionnés selon les fichiers touchés
tests cargo ciblés privilégiés
test workspace complet limité à quelques jalons planifiés ou aux portées transverses incertaines
cargo tree uniquement lors de changements/diagnostics de dépendances
commandes nécessitant cd exécutées dans un sous-shell
Tauri : npm seulement pour gérer les dépendances ; smoke via cargo tauri dev ; packaging final via cargo tauri build
```
Aucune sortie d'audit ou de build spécifique à `2-beta.2.fix.1` n'a été fournie dans cette revue ; aucune gate mécanique supplémentaire n'est donc déclarée PASS ici.
## Suite
`2-beta.2.fix.2` formalise ces règles et met à jour le prompt `0.3.1` sans toucher aux versions techniques.

55
prompts/003-V0_3_1_START_PROMPT.md
View File

@@ -1,5 +1,5 @@
<!-- file: prompts/003-V0_3_1_START_PROMPT.md -->
<!-- version: 2 -->
<!-- version: 3 -->
# Prompt de démarrage `0.3.1` — second host Snake Tauri Android
@@ -276,7 +276,19 @@ Font Awesome
SimpleBar + ResizeObserver si le layout le nécessite
```
Mais appliquer `CMD-WEB-005` : pour une application Tauri, `npm run dev` et `npm run build` sont possédés par les hooks Tauri et ne deviennent pas automatiquement des gates manuelles indépendantes.
Pour une application Tauri, `npm` sert seulement à gérer les dépendances frontend lorsqu'une dépendance doit être ajoutée/retirée (`npm i`, `npm i -D`, etc.). Ne pas utiliser `npm run dev` ou `npm run build` comme gates Tauri manuelles : les hooks Tauri possèdent Vite/TypeScript/WASM.
Le smoke courant utilise :
```bash
(cd <tauri-app> && cargo tauri dev)
```
Le packaging est réservé aux phases finales prévues par le plan :
```bash
(cd <tauri-app> && cargo tauri build)
```
Ne pas traiter le host Tauri comme le host navigateur direct de `0.3.0` : le mode de lancement, le packaging, les permissions et les smokes sont différents.
@@ -377,18 +389,35 @@ docs/rules/RULES_VALIDATION_MATRIX.md
Chaque delta sélectionne les commandes proportionnelles à son scope. Une commande non exécutée n'est jamais déclarée PASS.
Après modification Rust, la base habituelle reste :
Les audits Python sont choisis selon les fichiers touchés : ne pas exécuter systématiquement les trois audits si un seul est pertinent.
Dès qu'un delta touche du code Rust, un manifeste Cargo, une feature ou une dépendance Rust, la base obligatoire est :
```bash
cargo fmt --all
cargo fmt --all -- --check
python3 scripts/audit_rust_workspace_rules.py
python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates Android Web deltas history
python3 scripts/audit_distribution_layout.py
# audits Python applicables au scope
cargo check --workspace
cargo clippy --workspace --all-targets --all-features -- -D warnings
```
Clippy/tests/builds/smokes sont ajoutés selon la matrice et la phase.
Les tests normaux sont ciblés :
```bash
cargo test -p <crate> --all-targets --all-features
```
Ajouter les tests ciblés des consommateurs uniquement lorsque leur contrat est affecté. `cargo test --workspace --all-targets --all-features` reste une gate rare, planifiée un petit nombre de fois dans la version/session (initiale si utile, préfinale/finale, ou portée transverse incertaine).
Ne lancer `cargo tree` que si les dépendances/features changent ou qu'un diagnostic de frontière le justifie. Ne pas le mettre automatiquement dans chaque log de validation.
Toute commande nécessitant un changement de répertoire est englobée dans un sous-shell :
```bash
(cd <répertoire> && <commande>)
```
Pour Tauri, utiliser `cargo tauri dev` pour les smokes et réserver `cargo tauri build` aux phases finales de packaging ; `npm` n'est utilisé directement que pour gérer les dépendances frontend.
## 13. Qui exécute quoi
@@ -397,8 +426,11 @@ Le générateur peut exécuter les audits statiques en lecture seule afin de pr
Les validations de build/runtime restent côté utilisateur :
```text
cargo check/clippy/test final
build Tauri Android
cargo check workspace + Clippy workspace strict lorsqu'un delta touche Rust/dépendances
tests cargo ciblés par défaut
test workspace complet seulement aux jalons planifiés/portées incertaines
(cd <tauri-app> && cargo tauri dev) pour les smokes Tauri
(cd <tauri-app> && cargo tauri build) pour les validations finales de packaging Tauri
Gradle/SDK/NDK lorsque le chemin Tauri les invoque
installation émulateur/appareil
smoke mobile
@@ -421,6 +453,7 @@ Le forecast suivant est une hypothèse à confirmer ou corriger en `0-pre.1`.
- audit environnement Tauri Android ;
- matrice réutilisation vs duplication ;
- stratégie de build/smoke ;
- positionnement explicite des rares gates `cargo test --workspace --all-targets --all-features` dans le plan ;
- plan `0.3.1` ;
- décision README/USAGE attendue pour les nouveaux composants.
@@ -449,8 +482,8 @@ Sinon omettre la tranche.
### `2-beta.1` — validation large
- workspace complet ;
- build Tauri Android ;
- smoke émulateur/appareil disponible ;
- `(cd <tauri-app> && cargo tauri build)` pour le packaging Tauri Android ;
- smoke via `(cd <tauri-app> && cargo tauri dev)` puis émulateur/appareil disponible ;
- non-régression Web direct ;
- non-régression Desktop SDL3 lorsque nécessaire ;
- vérification dépendances/package/distribution.