15 lines
1.7 KiB
Markdown
15 lines
1.7 KiB
Markdown
<!-- file: prompts/000-V0_1_0_START_PROMPT.md -->
|
||
<!-- version: 4 -->
|
||
|
||
# Prompt de reprise 0.1.0
|
||
|
||
Partir de la dernière livraison `0.1.0-*`, lire `RULES.md`, `ROADMAP.md`, `CHANGELOG.md`, le dernier delta et les documents d'architecture concernés. Vérifier l'état réel du workspace avant toute modification. Respecter le format de livraison delta, le cycle SemVer défini dans `docs/rules/VERSION_WORKFLOW.md` et la politique d’exécution de `docs/rules/RULES_COMMANDS.md`. Pour une évolution de gameplay portable, privilégier le runner Desktop du jeu avant Android lorsque la fonctionnalité ne dépend pas d’une API Android.
|
||
|
||
## Validation et enchaînement
|
||
|
||
La validation Cargo finale d'un delta est exécutée par l'utilisateur sauf demande explicite contraire. Le delta suivant doit reprendre le statut de cette validation. Une gate entièrement propre autorise le passage automatique au delta suivant ; une gate en échec impose un `.fix.N` du delta courant avant progression, sauf décision explicite contraire.
|
||
|
||
## Formatage, tests et diagnostics
|
||
|
||
Lorsqu’un delta modifie du Rust, demander `cargo fmt --all` avant `cargo fmt --all -- --check`. Les seules modifications produites par rustfmt n’imposent pas d’incrémenter les en-têtes `// version: N`. Préférer les tests `cargo test -p ... --all-targets --all-features` ciblés ; réserver la suite workspace complète aux frontières de version/phase, aux changements transverses ou aux cas où la portée n’est pas sûre. Les tests unitaires résident sous `unit_tests/`, les tests d’intégration/environnement sous `tests/`, jamais sous `src/`. Utiliser le socle `game-logging-lib`/`tracing` pour les diagnostics structurés lorsque pertinent.
|