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

0.3.0-2-beta.2

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-20 14:30:55 +02:00
parent ff1ec09d68
commit fca477eb23
13 changed files with 354 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
Cargo.toml
View File

@@ -20,7 +20,7 @@ members = [
]
[workspace.package]
version = "0.3.0-2-beta.1"
version = "0.3.0-2-beta.2"
edition = "2024"
license = "MIT"
repository = "https://git.sasedev.com/Sasedev/games"

4
README.md
View File

@@ -1,5 +1,5 @@
<!-- file: README.md -->
<!-- version: 37 -->
<!-- version: 38 -->
# games.sasedev
@@ -26,7 +26,7 @@ Workspace expérimental puis productif pour des jeux multiplateformes principale
Version stable de référence : `0.2.0`.
Version de développement : `0.3.0-2-beta.1`.
Version de développement : `0.3.0-2-beta.2`.
Les deux premiers jeux sont des POC structurels : `game-reflex-poc` et `game-snake-poc`. Ils existent d'abord pour valider les frontières du workspace, le moteur, les assets et le packaging multiplateforme.

12
ROADMAP.md
View File

@@ -1,5 +1,5 @@
<!-- file: ROADMAP.md -->
<!-- version: 20 -->
<!-- version: 21 -->
# Roadmap
@@ -38,11 +38,11 @@ Le détail historique des prereleases `0.1.0-*` reste dans `deltas/0.1.0/` et `h
## 0.3.0 — Baseline Snake + premier POC Web direct
- ( ) `0.3.0` — nettoyer la baseline Snake sans introduire de logique Uroburas et maintenir le runner Desktop SDL3 fonctionnel.
- ( ) `0.3.0` — produire une adaptation WASM dédiée à Snake sans déplacer le gameplay hors de `game-snake-poc`.
- ( ) `0.3.0` — réaliser un POC navigateur direct Snake couvrant clavier, boutons directionnels tactiles, resize, lifecycle, logging, assets et provenance runtime.
- ( ) `0.3.0` — utiliser uniquement Cargo, `wasm-bindgen` et Vite/npm pour le chemin de build Web ; aucun script Python ne pilote ce build.
- ( ) `0.3.0` — documenter les duplications observées, les extractions réellement justifiées et les reports avant promotion RC.
- (x) `0.3.0` — nettoyer la baseline Snake sans introduire de logique Uroburas et maintenir le runner Desktop SDL3 fonctionnel.
- (x) `0.3.0` — produire une adaptation WASM dédiée à Snake sans déplacer le gameplay hors de `game-snake-poc`.
- (x) `0.3.0` — réaliser un POC navigateur direct Snake couvrant clavier, boutons directionnels tactiles, resize, lifecycle, logging, assets et provenance runtime.
- (x) `0.3.0` — utiliser uniquement Cargo, `wasm-bindgen` et Vite/npm pour le chemin de build Web ; aucun script Python ne pilote ce build.
- (x) `0.3.0` — documenter les duplications observées et conserver les adapters Web/WASM spécifiques tant qu’un second consommateur ne justifie pas une extraction commune.
## Série 0.3.x — trajectoire actuelle après 0.3.0

2
Web/game-snake-poc/package.json
View File

@@ -1,7 +1,7 @@
{
"name": "game-snake-poc-web",
"private": true,
"version": "0.3.0-2-beta.1",
"version": "0.3.0-2-beta.2",
"type": "module",
"scripts": {
"dev": "vite",

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

@@ -0,0 +1,45 @@
<!-- file: deltas/0.3.0/2-beta.2.md -->
<!-- version: 1 -->
# Delta 0.3.0-2-beta.2
## Objectif
Consolider la version feature-complete après validation de `2-beta.1`, préparer le gel RC et transmettre un contexte autonome à `0.3.1`, sans modifier le comportement runtime.
## Baseline acceptée
`0.3.0-2-beta.1` est validée : audits, format/check/Clippy, 34 tests workspace, Desktop Snake release et Web/WASM release passent.
## Changements
- passage de la version workspace et du package Web à `0.3.0-2-beta.2` ;
- ajout de `history/0.3.0/2-beta.1.md` ;
- classement des lignes `0.3.0` réellement livrées dans `ROADMAP.md` ;
- ajout d'une baseline architecturale consolidée du POC Snake Web direct ;
- ajout d'une matrice RC spécifique à `0.3.0` ;
- réconciliation de l'étude `pre.1` avec le contrat autoritaire des archives de tag ;
- mise à jour du plan actif avec le résultat beta ;
- ajout du prompt `003-V0_3_1_START_PROMPT.md` pour le second host Snake Tauri Android.
`CHANGELOG.md` est revu mais ne reçoit pas d'entrée beta : `DOC-CHG-002` et `DOC-CHG-003` réservent la synthèse publiée aux RC et stables. La matière de la future entrée RC est consolidée dans les documents durables de cette tranche.
## Validation attendue
```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
cargo check --workspace
(cd Web/game-snake-poc && npm install && npm run build)
```
Aucun test/smoke complet n'est requis par ce delta documentaire + métadonnées : `2-beta.1` vient de valider les artefacts release, et aucun code/runtime n'est modifié.
## Après validation
Si cette consolidation est acceptée, produire `0.3.0-3-rc.1` : gel fonctionnel, entrée RC du `CHANGELOG.md`, historique `2-beta.2`, réexécution de la matrice RC et vérification finale du prompt `0.3.1`.

3
docs/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/000-README.md -->
<!-- version: 25 -->
<!-- version: 26 -->
# Documentation games.sasedev
@@ -68,6 +68,7 @@ Voir [`../RULES.md`](../RULES.md), notamment [`rules/RULES_DOCUMENTATION.md`](ru
- [`testing/001-TEST_ARCHITECTURE.md`](testing/001-TEST_ARCHITECTURE.md) — séparation `unit_tests/` / `tests/`, tests ciblés et tracing de test.
- [`testing/002-BETA_VALIDATION_MATRIX.md`](testing/002-BETA_VALIDATION_MATRIX.md) — matrice beta Desktop SDL3, Tauri/WASM et Android multi-appareils.
- [`testing/003-RC_VALIDATION_MATRIX.md`](testing/003-RC_VALIDATION_MATRIX.md) — matrice RC de reproductibilité, packaging final et promotion vers `0.1.0`.
- [`testing/004-V0_3_0_RC_VALIDATION_MATRIX.md`](testing/004-V0_3_0_RC_VALIDATION_MATRIX.md) — gate RC spécifique au POC Snake Web direct et à son témoin Desktop SDL3.
- [`development/003-TRACING_AND_DIAGNOSTICS.md`](development/003-TRACING_AND_DIAGNOSTICS.md) — socle `tracing`, subscriber et appender communs.
- [`development/004-SDL3_DESKTOP_PREREQUISITES.md`](development/004-SDL3_DESKTOP_PREREQUISITES.md) — prérequis SDL3 Desktop, stratégie de liaison système et vérification `pkg-config`.
- [`development/005-DESKTOP_WINDOW_POLICY.md`](development/005-DESKTOP_WINDOW_POLICY.md) — taille initiale, redimensionnement et séparation future entre fenêtre physique et résolution virtuelle.

14
docs/architecture/015-PLATFORM_POC_ARCHITECTURE.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/015-PLATFORM_POC_ARCHITECTURE.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Architecture des POC plateforme et réseau
@@ -11,12 +11,12 @@ Snake est le jeu-sonde principal.
## POC plateforme prioritaires
Première vague :
Première vague, réordonnée à partir du résultat réel de `0.3.0` :
- Tauri Android + Snake ;
- Web navigateur direct + Snake ;
- Tauri Desktop + Snake ;
- build Android multi-ABI avec outils natifs.
- Web navigateur direct + Snake — validé par `0.3.0` ;
- Tauri Android + Snake — prochain host prévu par `0.3.1` ;
- Tauri Desktop + Snake — prévu ensuite pour éprouver la factorisation WebView ;
- build Android multi-ABI avec outils natifs — tranche dédiée après les POC WebView.
Plateformes supplémentaires lorsque l'environnement existe : Windows SDL natif, macOS SDL natif et iOS SDL natif.
@@ -38,6 +38,8 @@ Un POC sert à identifier duplication, adapters manquants, capability réellemen
Une abstraction n'est pas extraite avant observation d'un besoin concret.
Le POC Web direct `0.3.0` n'a pas justifié d'extraire prématurément un adapter WASM commun entre Reflex et Snake : les deux adapters spécifiques restent acceptés. Le second host Snake doit d'abord fournir un second besoin réel avant toute factorisation.
## Relation avec Uroburas
Les résultats des POC `0.3.x` déterminent les choix techniques conservés pour la trajectoire Uroburas `0.4.x`.

91
docs/architecture/018-V0_3_0_WEB_SNAKE_BASELINE.md Normal file
View File

@@ -0,0 +1,91 @@
<!-- file: docs/architecture/018-V0_3_0_WEB_SNAKE_BASELINE.md -->
<!-- version: 1 -->
# Baseline consolidée 0.3.0 — Snake Web direct
## Statut
Ce document consolide les résultats effectivement validés du premier POC plateforme de la série `0.3.x`. Il prépare le gel RC de `0.3.0` et sert de baseline au second host Snake prévu en `0.3.1`.
## Chaîne validée
Le chemin Web direct retenu est :
```text
game-snake-poc
↓
game-snake-poc-wasm
↓ wasm-bindgen --target web
Web/game-snake-poc
↓
Vite / TypeScript / Bootstrap 5 / Canvas
```
`game-snake-poc` reste indépendant de SDL3, DOM, Canvas, Tauri et des APIs plateforme. `game-snake-poc-wasm` adapte la scène et les entrées au host Web et porte la provenance runtime ; le frontend gère DOM, lifecycle navigateur, rendu Canvas et shell UI.
## Input et cadence
Les entrées navigateur sont converties vers les quatre actions Snake `Left`, `Right`, `Up`, `Down`. Une entrée ne fait pas avancer directement la simulation : la direction est mise en attente puis consommée au prochain `tick()` WASM.
Le host valide clavier, contrôles pointer/tactiles, resize et pause/reprise sans rattrapage massif après masquage d'onglet.
## Shell Web
Le frontend reprend les conventions utiles des applications Desk KSP sans dépendre de Tauri :
- Vite + TypeScript ;
- Bootstrap 5 / Bootswatch Pulse ;
- Font Awesome ;
- Sass ;
- SimpleBar et `resize-observer-polyfill` ;
- header/footer fixes et zone centrale scrollable ;
- Canvas conservant le ratio logique Snake `12 × 20`.
Le frontend reste un host : il ne contient aucune règle de gameplay.
## Assets
Les assets sources restent hors des crates sous `assets/`. Le build Web conserve les namespaces logiques :
```text
assets/common/data/runtime.json → /common/data/runtime.json
assets/game-snake-poc/data/game.json → /game/data/game.json
```
Les mêmes routes sont valides en développement Vite et dans le bundle production.
## Provenance runtime
La session Web conserve `RuntimeProvenance` dans l'adapter WASM. Les dimensions fixes sont `Web / Browser / Wasm`; la classe d'appareil et le profil d'entrée sont renseignés à partir de l'environnement et des entrées réellement observées.
Le smoke validé expose notamment :
```text
web / browser / wasm / desktop / keyboard-mouse
```
## Build
Le chemin Web direct ne dépend d'aucun orchestrateur Python :
```text
Cargo
→ wasm-bindgen
→ Vite/npm
```
Les artefacts générés restent hors dépôt sous `../builds/sasedev-games/`.
## Résultat de l'extraction
`0.3.0` ne justifie pas encore une abstraction WASM commune entre Reflex et Snake. Les deux adapters spécifiques restent préférables à une factorisation spéculative.
Le prochain host Snake doit réutiliser cette baseline et fournir un second cas réel avant extraction d'une couche commune WebView/WASM.
## Témoin Desktop
Le runner `game-snake-poc-desktop` reste le témoin SDL3 natif. La beta `0.3.0-2-beta.1` a validé son build release et son smoke sans modification de gameplay ni de runtime SDL3.
## Suite
`0.3.1` doit éprouver Tauri Android + Snake. `0.3.2` peut ensuite tester Tauri Desktop et décider, sur deux consommateurs réels, si une factorisation WebView/frontend est justifiée.

10
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: 12 -->
<!-- version: 13 -->
# Plan v0.3.0 — baseline Snake et premier POC Web direct
@@ -103,13 +103,17 @@ Décision après `0-pre.5.fix.1` : aucun besoin d'extraction/correction structur
Scope feature-complete. La tranche ne crée aucun nouveau comportement : elle bascule la version workspace et le package Web au jalon `0.3.0-2-beta.1`, enregistre la validation de `0-pre.5.fix.1` et exécute la gate large de frontière de phase. Celle-ci comprend audits, formatage/check/Clippy, tests workspace complets, build + smoke Desktop Snake en release, build WASM Snake en release, `wasm-bindgen`, build Vite production et smoke du `dist` via `npm run preview`. Aucun nouveau scope.
Validation : la gate est acceptée par l'utilisateur. Les audits sont propres, les tests workspace totalisent 34 tests réussis sans échec, le binaire Desktop Snake release démarre et s'arrête proprement après 144 frames, et le bundle Web/WASM release est construit puis servi par `vite preview` sans défaut remonté.
### `2-beta.2` — consolidation documentaire et transmission
Réconcilier l'état réellement validé avec la documentation durable et le plan actif, puis mettre à jour `CHANGELOG.md`, `ROADMAP.md` et l'historique applicable. Préparer et vérifier le prompt de la version/session suivante à partir de cet état, sans prétendre à des validations non exécutées.
Réconcilier l'état réellement validé avec la documentation durable et le plan actif, mettre à jour `ROADMAP.md`, enregistrer `2-beta.1` dans l'historique et préparer le prompt de `0.3.1` à partir de cet état. La synthèse destinée au `CHANGELOG.md` est consolidée ici, mais l'entrée n'est écrite qu'en RC conformément à `DOC-CHG-002` et `DOC-CHG-003`.
Livraison candidate : synthèse durable de la baseline Web Snake `0.3.0`, matrice RC spécifique, roadmap `0.3.0` classée réalisée, audit `pre.1` réconcilié avec le contrat des archives taggées et prompt `003-V0_3_1_START_PROMPT.md`. Aucun code ni comportement runtime n'est modifié.
Cette tranche est une responsabilité obligatoire du cycle même si son numéro doit être décalé par des fixes ou une beta supplémentaire. La documentation spécifique à une fonctionnalité reste mise à jour dans la tranche qui introduit cette fonctionnalité ; `2-beta.2` réalise la consolidation transversale, elle ne sert pas à reporter toute la documentation en fin de version.
Gate : cohérence docs/plan/deltas/`CHANGELOG.md`/`ROADMAP.md`/history/prompt, puis audits documentaires applicables.
Gate : cohérence docs/plan/deltas/`CHANGELOG.md`/`ROADMAP.md`/history/prompt, audits documentaires, `cargo check --workspace` pour le bump de version et `npm run build` pour confirmer la version frontend.
### `3-rc.1` — candidate gelée

4
docs/studies/023-V0_3_0_PLATFORM_POC_AUDIT.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/studies/023-V0_3_0_PLATFORM_POC_AUDIT.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# 0.3.0 — audit de baseline et cadrage du premier POC plateforme
@@ -13,7 +13,7 @@ Elle décrit l'état observé de la stable `0.2.0`, les requirements réellement
Base déclarée : tag stable `v0.2.0`, fourni sous forme d'archive `games-v0.2.0.zip`.
L'intégrité ZIP est propre. L'archive ne contient pas `.git` : l'état du commit, le tag effectif et la propreté du working tree ne peuvent donc pas être vérifiés dans cet environnement.
L'intégrité ZIP est propre. L'archive est fournie explicitement comme téléchargement du tag stable `v0.2.0` et constitue donc la baseline autoritaire de ce tag conformément à `CMD-GIT-003`. L'absence de `.git` dans une archive de tag est normale et ne constitue pas une validation manquante ; les contrôles Git locaux ne s'appliquent que lorsqu'un checkout Git est effectivement fourni.
La version workspace observée avant modification est `0.2.0`.

67
docs/testing/004-V0_3_0_RC_VALIDATION_MATRIX.md Normal file
View File

@@ -0,0 +1,67 @@
<!-- file: docs/testing/004-V0_3_0_RC_VALIDATION_MATRIX.md -->
<!-- version: 1 -->
# Matrice RC 0.3.0 — Snake Web direct
## Objet
La RC `0.3.0` gèle le premier POC Snake Web direct. Elle ne crée aucune fonctionnalité et vérifie que l'état validé en beta reste reproductible avant promotion mécanique vers la stable.
## Gate statique et workspace
```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
cargo check --workspace
cargo clippy --workspace --all-targets --all-features -- -D warnings
cargo test --workspace --all-targets --all-features
```
## Desktop Snake release
```bash
cargo build -p game-snake-poc-desktop --release
../builds/sasedev-games/target/release/game-snake-poc-desktop
```
Critères : démarrage, rendu, contrôles et arrêt propre.
## Web/WASM release
```bash
cargo build -p game-snake-poc-wasm --release --target wasm32-unknown-unknown
wasm-bindgen \
../builds/sasedev-games/target/wasm32-unknown-unknown/release/game_snake_poc_wasm.wasm \
--target web \
--out-dir ../builds/sasedev-games/game-snake-poc-web/wasm \
--out-name game_snake_poc_wasm
(cd Web/game-snake-poc && npm install && npm run build && npm run preview)
```
Ouvrir `http://127.0.0.1:4174/main.html`.
Critères :
- Canvas au ratio attendu ;
- clavier et contrôles pointer/tactiles ;
- SimpleBar ;
- assets `snake / engine-v1` ;
- provenance Web/WASM cohérente ;
- resize ;
- pause/reprise sans rattrapage massif ;
- aucune erreur runtime bloquante.
## Artefacts et dépôt
Les artefacts Rust/WASM/Vite restent sous `../builds/sasedev-games/`. Aucun `node_modules`, `dist`, cache WASM ou artefact Cargo n'est livré dans le dépôt.
## Promotion
La promotion vers `0.3.0` est mécanique lorsque `3-rc.1` est validée sans défaut nécessitant une modification fonctionnelle. Tout correctif de release reste limité par `VER-RC-*`.

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

@@ -0,0 +1,52 @@
<!-- file: history/0.3.0/2-beta.1.md -->
<!-- version: 1 -->
# Historique 0.3.0-2-beta.1
## Statut
Gate beta feature-complete validée par l'utilisateur le 2026-09-20. Aucun défaut fonctionnel ou de packaging n'est remonté ; la version peut entrer dans la consolidation `2-beta.2`.
## Gate workspace
Les validations suivantes passent :
```text
General Rust rule audit: clean
Rust export completeness audit: 0 candidate(s)
games.sasedev workspace audit: clean
Markdown table audit: clean (5 table(s), 193 file(s))
Distribution layout audit: clean (31 required path(s), 1 forbidden path(s) absent)
cargo fmt --all -- --check: clean
cargo check --workspace: clean
cargo clippy --workspace --all-targets --all-features -- -D warnings: clean
cargo test --workspace --all-targets --all-features: 34 passed, 0 failed
```
## Desktop Snake release
Le build release passe et le smoke SDL3 se ferme proprement :
```text
desktop SDL3 runner started game="snake"
SDL3 runtime started title=Snake POC width=405 height=720
SDL3 runtime stopped frames=144
```
## Web/WASM release
Le module Snake WASM release compile, `wasm-bindgen --target web` termine sans erreur, puis le frontend passe :
```text
npm install: 64 packages audités, 0 vulnérabilité
npm run build: clean, 30 modules transformés, 2 assets copiés
npm run preview: Vite démarré sur 127.0.0.1:4174
```
Le warning npm non bloquant relatif au script d'installation de `@parcel/watcher@2.6.0` reste présent.
L'utilisateur accepte le résultat de la gate beta sans défaut supplémentaire remonté.
## Suite
`0.3.0-2-beta.2` consolide documentation durable, roadmap, historique, matrice RC et prompt `0.3.1`, sans nouveau comportement.

70
prompts/003-V0_3_1_START_PROMPT.md Normal file
View File

@@ -0,0 +1,70 @@
<!-- file: prompts/003-V0_3_1_START_PROMPT.md -->
<!-- version: 1 -->
# Prompt de démarrage 0.3.1 — second host Snake Tauri Android
Partir de la version stable `0.3.0`. Si ce prompt est lu avant la publication effective de `0.3.0`, ne pas ouvrir `0.3.1` : terminer d'abord la RC et la release stable.
Lire intégralement `RULES.md`, `ROADMAP.md`, `CHANGELOG.md`, `docs/000-README.md`, `docs/architecture/015-PLATFORM_POC_ARCHITECTURE.md`, `docs/architecture/018-V0_3_0_WEB_SNAKE_BASELINE.md`, `docs/plans/` et le dernier historique validé de `0.3.0` avant toute proposition.
## Mission
`0.3.1` doit produire le second host Snake : Tauri Android. Le but est d'éprouver la réutilisation de la baseline Web/WASM validée en `0.3.0`, pas de refactorer préventivement le framework.
Le résultat attendu est un Snake exécutable dans le WebView Tauri Android, avec lifecycle, input, assets, logging et provenance cohérents, construit par les toolchains natives prévues sans nouvel orchestrateur Python.
## `0.3.1-0-pre.1` — cadrage obligatoire
Avant le développement lourd :
- auditer la stable `0.3.0` et ses résultats Web/WASM ;
- auditer le POC historique `game-reflex-poc-tauri` et ses hooks ;
- auditer la baseline Android Java/SDL/JNI sans la confondre avec le host Tauri Android ;
- identifier les prérequis Tauri Android/SDK/NDK réellement disponibles ;
- déterminer ce qui peut être réutilisé tel quel depuis `game-snake-poc-wasm` et `Web/game-snake-poc` ;
- repérer la duplication réelle avant toute extraction ;
- définir les smokes appareil/émulateur et la provenance attendue ;
- créer ou réviser le plan `0.3.1` sous `docs/plans/` avec découpage prévisionnel souple jusqu'à la stable.
## Contraintes gelées
- `game-snake-poc` reste indépendant de Tauri, Android, DOM et providers ;
- `game-snake-poc-wasm` reste l'adapter WASM Snake tant qu'un besoin réel ne justifie pas une extraction ;
- ne pas copier le gameplay dans le frontend Tauri ;
- ne pas généraliser le frontend Web avant observation du second consommateur ;
- si une factorisation Web/WebView devient justifiée, la documenter avec ses deux consommateurs réels ;
- ne pas réintroduire `scripts/build_reflex_tauri_wasm.py` ni créer un nouvel orchestrateur Python pour le chemin touché ;
- les builds sont pilotés par Cargo, Tauri CLI, npm/Vite et les toolchains Android natives appropriées ;
- ne pas démarrer Tauri Desktop, Android SDL multi-ABI, réseau realtime ou Uroburas dans `0.3.1`.
## Forecast initial souple
Le forecast doit être confirmé ou corrigé pendant `0-pre.1`. Une trajectoire plausible est :
```text
0-pre.1 audit / requirements / sizing / plan
0-pre.2 host Tauri Android Snake minimal + build natif
0-pre.3 lifecycle / input / assets / provenance / logging
0-pre.4 factorisation uniquement si deux consommateurs la justifient
2-beta.1 validation large Android + non-régression Web/Desktop
2-beta.2 consolidation documentaire et transmission
3-rc.1 candidate gelée
0.3.1 release mécanique
```
Cette numérotation reste révisable conformément aux règles de session.
## Validation attendue
Les commandes exactes sont fixées en `pre.1` à partir de l'environnement disponible. Au minimum, conserver :
- audits statiques du dépôt ;
- format/check/Clippy/tests Rust proportionnels ;
- build Tauri Android par le chemin natif retenu ;
- smoke sur émulateur ou appareil réellement disponible ;
- non-régression du host Web Snake `0.3.0` ;
- non-régression Desktop SDL3 lorsque la frontière Snake/WASM est touchée.
## Condition de fin de session
La session ne s'arrête normalement pas sur une prerelease. Elle doit fermer `0.3.1` jusqu'à la stable ou reporter explicitement le scope non indispensable vers une version suivante si le sizing de `pre.1` démontre que la cible est trop grande.