1.7 KiB
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.