594 lines
19 KiB
Markdown
594 lines
19 KiB
Markdown
<!-- file: prompts/003-V0_3_1_START_PROMPT.md -->
|
|
<!-- version: 4 -->
|
|
|
|
# Prompt de démarrage `0.3.1` — second host Snake Tauri Android
|
|
|
|
## 1. Base exacte et autorité de la reprise
|
|
|
|
Partir uniquement de la version stable/taggée :
|
|
|
|
```text
|
|
v0.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 puis la release stable `0.3.0`.
|
|
|
|
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.
|
|
|
|
Version cible :
|
|
|
|
```text
|
|
0.3.1
|
|
```
|
|
|
|
Première tranche obligatoire :
|
|
|
|
```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
|
|
```
|
|
|
|
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 android dev)
|
|
```
|
|
|
|
Le packaging est réservé aux phases finales prévues par le plan :
|
|
|
|
```bash
|
|
(cd <tauri-app> && cargo tauri android 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.
|
|
|
|
## 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.
|
|
|
|
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
|
|
# audits Python applicables au scope
|
|
cargo check --workspace
|
|
cargo clippy --workspace --all-targets --all-features -- -D warnings
|
|
```
|
|
|
|
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 android dev` pour les smokes Android et réserver `cargo tauri android build` aux phases finales de packaging Android ; `npm` n'est utilisé directement que pour gérer les dépendances frontend.
|
|
|
|
## 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 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 android dev) pour les smokes Tauri
|
|
(cd <tauri-app> && cargo tauri android build) pour les validations finales de packaging Tauri
|
|
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 ;
|
|
- 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.
|
|
|
|
### `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 ;
|
|
- `(cd <tauri-app> && cargo tauri android build)` pour le packaging Tauri Android ;
|
|
- smoke via `(cd <tauri-app> && cargo tauri android dev)` puis é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
|
|
```
|