0.3.0-2-beta.2.fix.1
This commit is contained in:
@@ -1,70 +1,560 @@
|
||||
<!-- file: prompts/003-V0_3_1_START_PROMPT.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Prompt de démarrage 0.3.1 — second host Snake Tauri Android
|
||||
# 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.
|
||||
## 1. Base exacte et autorité de la reprise
|
||||
|
||||
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 :
|
||||
Partir uniquement de la version stable/taggée :
|
||||
|
||||
```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
|
||||
v0.3.0
|
||||
```
|
||||
|
||||
Cette numérotation reste révisable conformément aux règles de session.
|
||||
Si ce prompt est lu avant la publication effective de `0.3.0`, ne pas ouvrir `0.3.1`. Terminer d'abord la RC puis la release stable `0.3.0`.
|
||||
|
||||
## Validation attendue
|
||||
Lorsqu'une archive est fournie comme téléchargement du tag `v0.3.0`, elle constitue la baseline autoritaire même si elle ne contient pas `.git`. Appliquer `CMD-GIT-003` et `CMD-GIT-004` : vérifier la cohérence interne des versions et des fichiers, ne pas inventer un état Git inaccessible.
|
||||
|
||||
Les commandes exactes sont fixées en `pre.1` à partir de l'environnement disponible. Au minimum, conserver :
|
||||
Version cible :
|
||||
|
||||
- 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.
|
||||
```text
|
||||
0.3.1
|
||||
```
|
||||
|
||||
## Condition de fin de session
|
||||
Première tranche obligatoire :
|
||||
|
||||
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.
|
||||
```text
|
||||
0.3.1-0-pre.1
|
||||
```
|
||||
|
||||
`0-pre.1` est un gate de lecture, audit, requirements, sizing, validation et planification. Ne pas commencer directement par le scaffold Android/Tauri ou par la copie du POC Reflex.
|
||||
|
||||
## 2. Sources de vérité — ordre de lecture obligatoire
|
||||
|
||||
Lire intégralement, dans cet ordre :
|
||||
|
||||
```text
|
||||
RULES.md
|
||||
ROADMAP.md
|
||||
CHANGELOG.md
|
||||
docs/000-README.md
|
||||
```
|
||||
|
||||
Puis lire les règles directement pertinentes :
|
||||
|
||||
```text
|
||||
docs/rules/RULES_GENERAL.md
|
||||
docs/rules/RULES_RUST.md
|
||||
docs/rules/RULES_PROJECT.md
|
||||
docs/rules/RULES_DOCUMENTATION.md
|
||||
docs/rules/FILE_CONTRACTS.md
|
||||
docs/rules/VERSION_WORKFLOW.md
|
||||
docs/rules/RULES_COMMANDS.md
|
||||
docs/rules/RULES_VALIDATION_MATRIX.md
|
||||
docs/rules/RULES_SESSION_PLANNING.md
|
||||
docs/rules/PROMPT_STRUCTURE.md
|
||||
```
|
||||
|
||||
Le prompt résume les garde-fous nécessaires à `0.3.1`; les règles restent normatives en cas de détail absent ici.
|
||||
|
||||
Lire ensuite la transmission `0.3.0` :
|
||||
|
||||
```text
|
||||
docs/plans/001-V0_3_0_WEB_SNAKE_POC_PLAN.md
|
||||
docs/architecture/015-PLATFORM_POC_ARCHITECTURE.md
|
||||
docs/architecture/018-V0_3_0_WEB_SNAKE_BASELINE.md
|
||||
docs/testing/004-V0_3_0_RC_VALIDATION_MATRIX.md
|
||||
history/0.3.0/
|
||||
deltas/0.3.0/
|
||||
```
|
||||
|
||||
Enfin auditer les implémentations réellement concernées :
|
||||
|
||||
```text
|
||||
crates/games/game-snake-poc/
|
||||
crates/apps/game-snake-poc-wasm/
|
||||
Web/game-snake-poc/
|
||||
crates/apps/game-snake-poc-desktop/
|
||||
crates/apps/game-reflex-poc-tauri/
|
||||
crates/apps/game-reflex-poc-wasm/
|
||||
Android/
|
||||
assets/
|
||||
```
|
||||
|
||||
Ne pas déduire l'état d'une crate depuis ce prompt lorsque le code stable `0.3.0` dit autre chose.
|
||||
|
||||
## 3. État hérité attendu de `0.3.0`
|
||||
|
||||
La stable `0.3.0` doit avoir validé au minimum :
|
||||
|
||||
```text
|
||||
Snake gameplay indépendant des hosts
|
||||
runner Desktop SDL3 fonctionnel
|
||||
adapter Snake WASM dédié
|
||||
host navigateur direct Vite/TypeScript
|
||||
shell HTML Bootstrap 5 / Bootswatch / SimpleBar
|
||||
Canvas respectant le ratio logique Snake
|
||||
clavier + contrôles pointer/tactiles
|
||||
lifecycle navigateur fixed-step sans catch-up massif
|
||||
assets common/game packagés depuis assets/
|
||||
logging frontend structuré
|
||||
RuntimeProvenance Web / Browser / Wasm
|
||||
build WASM release + wasm-bindgen
|
||||
build Vite production + preview
|
||||
```
|
||||
|
||||
Cette liste est un handoff attendu, pas une validation à réexécuter aveuglément au premier instant. Confirmer l'état réel de la stable puis définir les non-régressions nécessaires à `0.3.1`.
|
||||
|
||||
## 4. Mission de `0.3.1`
|
||||
|
||||
`0.3.1` doit produire le second host Snake : Tauri Android.
|
||||
|
||||
Le but est de vérifier que la baseline Web/WASM de `0.3.0` peut être réutilisée dans un WebView mobile Tauri sans recopier le gameplay, sans dupliquer inutilement le bridge WASM et sans créer un framework abstrait avant preuve d'un besoin partagé.
|
||||
|
||||
Résultat attendu :
|
||||
|
||||
```text
|
||||
Snake exécutable dans un host Tauri Android
|
||||
build Android piloté par les outils Tauri/Android natifs retenus
|
||||
lifecycle mobile cohérent
|
||||
input tactile et comportement WebView cohérents
|
||||
assets accessibles dans le package final
|
||||
logging Rust/Tauri/frontend cohérent
|
||||
RuntimeProvenance distincte du navigateur direct
|
||||
non-régression du host Web direct 0.3.0
|
||||
non-régression Desktop SDL3 si une frontière partagée change
|
||||
```
|
||||
|
||||
## 5. `0.3.1-0-pre.1` — cadrage obligatoire
|
||||
|
||||
Avant tout développement lourd, produire un audit réel de la stable `0.3.0` et de l'environnement disponible.
|
||||
|
||||
### 5.1 Baseline Snake
|
||||
|
||||
Auditer :
|
||||
|
||||
```text
|
||||
game-snake-poc
|
||||
game-snake-poc-wasm
|
||||
Web/game-snake-poc
|
||||
game-snake-poc-desktop
|
||||
engine-v1-common
|
||||
engine-v1-platform-api
|
||||
assets communs et Snake
|
||||
```
|
||||
|
||||
Identifier explicitement :
|
||||
|
||||
- ce qui est réutilisable tel quel ;
|
||||
- ce qui est spécifique au navigateur direct ;
|
||||
- ce qui appartient déjà à l'adapter WASM ;
|
||||
- ce qui deviendrait réellement partagé entre navigateur et WebView Tauri ;
|
||||
- toute duplication prouvée avant extraction.
|
||||
|
||||
### 5.2 Référence Tauri existante
|
||||
|
||||
Auditer intégralement :
|
||||
|
||||
```text
|
||||
crates/apps/game-reflex-poc-tauri/
|
||||
crates/apps/game-reflex-poc-wasm/
|
||||
docs/development/008-WASM_TAURI_POC.md
|
||||
```
|
||||
|
||||
Le POC Reflex est une référence technique de structure, de bridge Tauri, de frontend et de logging. Il n'est pas un template à copier aveuglément si sa baseline historique contredit les règles `0.3.x`.
|
||||
|
||||
Vérifier notamment :
|
||||
|
||||
```text
|
||||
src/lib.rs comme façade/reexports
|
||||
src/tauri.rs comme assemblage Tauri et pont Web/Rust
|
||||
modules propriétaires séparés
|
||||
tauri.conf.json / capabilities / permissions
|
||||
hooks frontend Vite
|
||||
tauri-plugin-tracing / @fltsci/tauri-plugin-tracing
|
||||
organisation frontend HTML/Sass/TypeScript
|
||||
```
|
||||
|
||||
### 5.3 Android existant
|
||||
|
||||
Auditer `Android/` et les documents Android existants pour distinguer :
|
||||
|
||||
```text
|
||||
baseline Android SDL3/Java/JNI
|
||||
host Tauri Android de 0.3.1
|
||||
```
|
||||
|
||||
Ils peuvent partager des contraintes plateforme, SDK/NDK ou documentation, mais ne doivent pas être confondus ni couplés artificiellement.
|
||||
|
||||
### 5.4 Toolchains réelles
|
||||
|
||||
Inventorier ce qui est réellement disponible dans l'environnement utilisateur :
|
||||
|
||||
```text
|
||||
Rust targets Android nécessaires
|
||||
Tauri CLI/version réellement utilisée
|
||||
Android SDK
|
||||
Android NDK
|
||||
Java/JDK
|
||||
Gradle/tooling éventuellement piloté par Tauri
|
||||
adb
|
||||
émulateur/AVD éventuel
|
||||
appareil réel éventuel
|
||||
Node/npm
|
||||
```
|
||||
|
||||
Ne pas déclarer un smoke appareil/émulateur possible avant de confirmer qu'une cible est effectivement accessible.
|
||||
|
||||
### 5.5 Sizing et plan
|
||||
|
||||
Créer ou réviser obligatoirement le plan de `0.3.1` sous :
|
||||
|
||||
```text
|
||||
docs/plans/
|
||||
```
|
||||
|
||||
Le plan doit contenir :
|
||||
|
||||
- objectif et scope ;
|
||||
- décisions acquises ;
|
||||
- risques/dépendances utiles ;
|
||||
- hors-périmètre ;
|
||||
- validations prévues ;
|
||||
- découpage prévisionnel souple jusqu'à `0.3.1` stable ;
|
||||
- tranche de validation large ;
|
||||
- tranche de consolidation documentaire ;
|
||||
- RC gelée ;
|
||||
- release stable mécanique.
|
||||
|
||||
Si le sizing montre que Tauri Android complet ne tient pas raisonnablement dans une session, réduire ou scinder le scope avant l'implémentation lourde.
|
||||
|
||||
## 6. Contraintes architecturales gelées
|
||||
|
||||
Préserver les frontières suivantes :
|
||||
|
||||
```text
|
||||
game-snake-poc
|
||||
gameplay et règles de jeu
|
||||
|
||||
engine-v1-common
|
||||
contrats moteur portables
|
||||
|
||||
engine-v1-platform-api
|
||||
provenance/capabilities plateforme
|
||||
|
||||
game-snake-poc-wasm
|
||||
adaptation WASM Snake
|
||||
|
||||
host Web direct / host Tauri
|
||||
lifecycle, DOM/WebView, inputs physiques, packaging et UI
|
||||
```
|
||||
|
||||
Règles spécifiques :
|
||||
|
||||
- `game-snake-poc` reste indépendant de Tauri, Android, DOM, Canvas et providers ;
|
||||
- ne pas copier le gameplay dans TypeScript, Java ou le backend Tauri ;
|
||||
- conserver `game-snake-poc-wasm` comme adapter WASM tant qu'un besoin réel ne justifie pas une extraction ;
|
||||
- ne pas généraliser `Web/game-snake-poc` avant observation du second consommateur ;
|
||||
- une extraction commune Web/WebView n'est autorisée que si deux consommateurs réels prouvent sa valeur ;
|
||||
- `lib.rs` d'une app Tauri reste une façade/reexport ;
|
||||
- `tauri.rs` assemble Tauri et délègue aux modules propriétaires ;
|
||||
- les traces frontend Tauri utilisent le bridge tracing prévu par les règles, pas des `console.*` applicatifs dispersés ;
|
||||
- ne pas réintroduire d'orchestrateur Python de build ;
|
||||
- ne pas utiliser `scripts/build_reflex_tauri_wasm.py` pour le nouveau chemin `0.3.x` ;
|
||||
- ne pas introduire réseau realtime, Uroburas, ads, billing ou leaderboard dans `0.3.1`.
|
||||
|
||||
## 7. Frontend Tauri et commandes Web
|
||||
|
||||
Le frontend Tauri peut reprendre les conventions de shell déjà éprouvées dans les applications Desk KSP et dans le POC existant lorsque cela reste pertinent :
|
||||
|
||||
```text
|
||||
Vite
|
||||
TypeScript
|
||||
HTML/Sass
|
||||
Bootstrap 5 / thème retenu
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
## 8. Provenance attendue
|
||||
|
||||
Le host Tauri Android doit produire une provenance distincte du navigateur direct.
|
||||
|
||||
`0-pre.1` doit auditer les enums/contrats réels de `engine-v1-platform-api` avant de fixer les valeurs exactes, mais préserver les dimensions :
|
||||
|
||||
```text
|
||||
platform family
|
||||
runtime host
|
||||
execution model
|
||||
device class
|
||||
input profile
|
||||
```
|
||||
|
||||
Ne pas ajouter une identification matérielle fine uniquement pour ce POC.
|
||||
|
||||
## 9. Documentation des crates/packages
|
||||
|
||||
Pendant `0-pre.1`, appliquer `DOC-CRATE-*` à tout composant créé ou finalisé.
|
||||
|
||||
La question doit être explicitement tranchée pour la nouvelle app Tauri :
|
||||
|
||||
```text
|
||||
README.md ?
|
||||
responsabilité / frontières / architecture locale / points d'entrée
|
||||
|
||||
USAGE.md ?
|
||||
prérequis / commandes / installation / lancement / smoke opérateur
|
||||
```
|
||||
|
||||
Ne pas créer des fichiers vides ou redondants. Si la documentation centrale couvre réellement un petit adapter, le plan peut documenter pourquoi un fichier local séparé n'apporte rien.
|
||||
|
||||
Lors de la consolidation finale, refaire cette revue pour chaque crate/package considéré durable dans `0.3.1`.
|
||||
|
||||
## 10. Deltas, history et état validé
|
||||
|
||||
Ne pas confondre :
|
||||
|
||||
```text
|
||||
deltas/<X.Y.Z>/
|
||||
décrit la livraison candidate
|
||||
base requise
|
||||
fichiers ajoutés/modifiés/supprimés
|
||||
décisions
|
||||
validations à exécuter
|
||||
validations non exécutées
|
||||
|
||||
history/<X.Y.Z>/
|
||||
décrit un jalon effectivement validé
|
||||
résultats réellement fournis par l'utilisateur
|
||||
défauts acceptés/corrigés
|
||||
état transmis au jalon suivant
|
||||
```
|
||||
|
||||
Une entrée `history/` n'est jamais pré-écrite pour le delta courant. Après validation utilisateur, le delta suivant ou son fix crée l'entrée historique du jalon accepté conformément à `DOC-HIST-*`.
|
||||
|
||||
Les anciens fichiers de `deltas/` et `history/` restent immuables sur le fond.
|
||||
|
||||
## 11. CHANGELOG, ROADMAP, plan et prompt suivant
|
||||
|
||||
Appliquer ces responsabilités sans les mélanger :
|
||||
|
||||
### Plan
|
||||
|
||||
`docs/plans/` porte le suivi fin et vivant de `0.3.1`. Il est créé/révisé en `0-pre.1` puis réconcilié lorsqu'un résultat réel modifie la trajectoire.
|
||||
|
||||
### ROADMAP
|
||||
|
||||
`ROADMAP.md` reste macroscopique. Le modifier lorsqu'un scope est ajouté, réalisé, reporté ou annulé ; ne pas ajouter une ligne pour chaque prerelease/fix.
|
||||
|
||||
### CHANGELOG
|
||||
|
||||
`CHANGELOG.md` est une synthèse de publication. Les `pre`, `alpha`, `beta` et fixes ne créent normalement pas d'entrée. Écrire la synthèse candidate à partir de la RC, puis la synthèse stable lors de la release.
|
||||
|
||||
### Prompt de la version suivante
|
||||
|
||||
Rédiger le prompt suivant pendant la consolidation finale de `0.3.1` lorsque la cible `0.3.2` est suffisamment connue. La première RC gelée vérifie/complète le prompt à partir de l'état réellement candidat à publication.
|
||||
|
||||
Ne jamais présenter dans ce prompt futur une validation RC/stable qui n'a pas encore été exécutée.
|
||||
|
||||
## 12. Commandes et matrice de validation
|
||||
|
||||
Ne pas inventer une procédure de commandes parallèle dans le prompt.
|
||||
|
||||
Sources normatives :
|
||||
|
||||
```text
|
||||
docs/rules/RULES_COMMANDS.md
|
||||
docs/rules/RULES_VALIDATION_MATRIX.md
|
||||
```
|
||||
|
||||
`RULES_COMMANDS.md` définit quand utiliser les audits, Cargo, Web, Android, Tauri et les smokes.
|
||||
|
||||
`RULES_VALIDATION_MATRIX.md` définit les IDs `CMD-*`, leurs dépendances et leurs déclencheurs.
|
||||
|
||||
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 :
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
Clippy/tests/builds/smokes sont ajoutés selon la matrice et la phase.
|
||||
|
||||
## 13. Qui exécute quoi
|
||||
|
||||
Le générateur peut exécuter les audits statiques en lecture seule afin de préparer un delta.
|
||||
|
||||
Les validations de build/runtime restent côté utilisateur :
|
||||
|
||||
```text
|
||||
cargo check/clippy/test final
|
||||
build Tauri Android
|
||||
Gradle/SDK/NDK lorsque le chemin Tauri les invoque
|
||||
installation émulateur/appareil
|
||||
smoke mobile
|
||||
smoke Web direct de non-régression
|
||||
smoke Desktop SDL3 si requis
|
||||
```
|
||||
|
||||
Ne jamais annoncer un build ou un smoke comme réussi uniquement parce que le code paraît correct.
|
||||
|
||||
Une gate utilisateur propre permet de passer automatiquement à la tranche planifiée suivante sauf instruction contraire. Une gate en échec reste normalement dans un `.fix.N` de la tranche courante.
|
||||
|
||||
## 14. Forecast initial souple
|
||||
|
||||
Le forecast suivant est une hypothèse à confirmer ou corriger en `0-pre.1`.
|
||||
|
||||
### `0-pre.1` — audit / requirements / sizing / plan
|
||||
|
||||
- audit stable `0.3.0` ;
|
||||
- audit Reflex Tauri/WASM ;
|
||||
- audit environnement Tauri Android ;
|
||||
- matrice réutilisation vs duplication ;
|
||||
- stratégie de build/smoke ;
|
||||
- plan `0.3.1` ;
|
||||
- décision README/USAGE attendue pour les nouveaux composants.
|
||||
|
||||
### `0-pre.2` — host Tauri Android Snake minimal
|
||||
|
||||
- nouvelle app Tauri Android au bon emplacement ;
|
||||
- consommation de l'adapter WASM Snake existant ou adaptation minimale justifiée ;
|
||||
- premier build natif reproductible ;
|
||||
- aucune généralisation prématurée.
|
||||
|
||||
### `0-pre.3` — lifecycle / input / assets / provenance / logging
|
||||
|
||||
- lifecycle WebView/mobile ;
|
||||
- tactile/input ;
|
||||
- assets ;
|
||||
- provenance ;
|
||||
- tracing Rust/Tauri/frontend ;
|
||||
- erreurs de runtime visibles et sûres.
|
||||
|
||||
### `0-pre.4` — extraction conditionnelle
|
||||
|
||||
Créer uniquement si le second host révèle une duplication partagée réelle entre navigateur direct et Tauri WebView.
|
||||
|
||||
Sinon omettre la tranche.
|
||||
|
||||
### `2-beta.1` — validation large
|
||||
|
||||
- workspace complet ;
|
||||
- build Tauri Android ;
|
||||
- smoke émulateur/appareil disponible ;
|
||||
- non-régression Web direct ;
|
||||
- non-régression Desktop SDL3 lorsque nécessaire ;
|
||||
- vérification dépendances/package/distribution.
|
||||
|
||||
### `2-beta.2` — consolidation documentaire
|
||||
|
||||
- documentation durable ;
|
||||
- README/USAGE réellement nécessaires ;
|
||||
- plan réconcilié ;
|
||||
- history ;
|
||||
- ROADMAP selon le scope réellement livré ;
|
||||
- préparation du prompt `0.3.2` ;
|
||||
- matière de CHANGELOG prête sans créer une entrée beta artificielle.
|
||||
|
||||
### `3-rc.1` — candidate gelée
|
||||
|
||||
- scope fonctionnel gelé ;
|
||||
- entrée RC du `CHANGELOG.md` ;
|
||||
- matrice RC ;
|
||||
- reproductibilité packaging ;
|
||||
- prompt `0.3.2` vérifié/complété ;
|
||||
- seulement bugs/release blockers ensuite.
|
||||
|
||||
### `0.3.1` — stable
|
||||
|
||||
Release mécanique de la RC validée : versions finales, synthèse stable, delta/release et tag selon le workflow applicable.
|
||||
|
||||
La numérotation est révisable. Les responsabilités ne doivent pas être fusionnées uniquement pour raccourcir artificiellement la version.
|
||||
|
||||
## 15. Hors-périmètre explicite
|
||||
|
||||
Ne pas ouvrir dans `0.3.1` sans décision de replanification :
|
||||
|
||||
```text
|
||||
Tauri Desktop Snake comme nouveau produit
|
||||
refonte générale engine-v1
|
||||
engine-v2
|
||||
Android SDL3 multi-ABI supplémentaire
|
||||
nouveau framework frontend générique
|
||||
serveur realtime
|
||||
WebSocket/WebTransport/QUIC gameplay
|
||||
Uroburas
|
||||
ads/billing
|
||||
leaderboard/auth
|
||||
refactor massif de Reflex
|
||||
mise à niveau opportuniste des dépendances
|
||||
```
|
||||
|
||||
Une dépendance peut être mise à jour uniquement si elle est nécessaire au chemin `0.3.1` et que le delta le documente.
|
||||
|
||||
## 16. Packaging et fichiers générés
|
||||
|
||||
Respecter :
|
||||
|
||||
```text
|
||||
../builds/sasedev-games/
|
||||
```
|
||||
|
||||
pour les sorties Cargo/Tauri/Vite et caches concernés.
|
||||
|
||||
Ne pas livrer :
|
||||
|
||||
```text
|
||||
node_modules/
|
||||
dist/
|
||||
target/
|
||||
bindings wasm générés
|
||||
caches
|
||||
secrets
|
||||
lockfiles interdits par les règles du dépôt
|
||||
```
|
||||
|
||||
Le ZIP d'un delta contient uniquement les fichiers ajoutés/modifiés par la tranche plus son document de delta, et les suppressions éventuelles utilisent le manifest contractuel prévu.
|
||||
|
||||
## 17. Première séquence de travail de la session
|
||||
|
||||
À l'ouverture de `0.3.1` :
|
||||
|
||||
1. vérifier que la base fournie correspond réellement à la stable `0.3.0` ;
|
||||
2. lire les sources de vérité dans l'ordre indiqué ;
|
||||
3. lire le dernier `history/0.3.0` et le delta/release stable ;
|
||||
4. exécuter les audits statiques applicables à la baseline ;
|
||||
5. auditer `game-reflex-poc-tauri` et le chemin Tauri Android disponible ;
|
||||
6. auditer `game-snake-poc-wasm` et le host Web direct ;
|
||||
7. inventorier SDK/NDK/Tauri/adb/AVD/appareil réellement accessibles ;
|
||||
8. produire requirements, risques, hors-périmètre et sizing ;
|
||||
9. créer le plan `0.3.1` sous `docs/plans/` ;
|
||||
10. seulement ensuite ouvrir le premier delta de développement.
|
||||
|
||||
## 18. Condition de fin de session
|
||||
|
||||
La session est dimensionnée pour fermer `0.3.1` jusqu'à sa stable.
|
||||
|
||||
Une prerelease n'est pas une cible normale de fin de session. Si le sizing ou une contrainte externe rend l'objectif trop grand, reporter explicitement le scope non indispensable vers `0.3.2+` plutôt que prolonger indéfiniment `0.3.1`.
|
||||
|
||||
La stable doit arriver avec :
|
||||
|
||||
```text
|
||||
scope validé
|
||||
builds/smokes applicables validés
|
||||
documentation durable réconciliée
|
||||
history complet des jalons acceptés
|
||||
ROADMAP cohérente
|
||||
CHANGELOG RC/stable cohérent
|
||||
prompt de la version suivante prêt et vérifié
|
||||
delta/release mécanique sans nouveau scope
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user