games/deltas/0.2.0/0-pre.1.fix.1.md

Delta 0.2.0-0-pre.1.fix.1

Base

Base déclarée : 0.2.0-0-pre.1.

La prerelease précédente reste une candidate documentaire non validée. Ce fix corrige et complète les règles de gouvernance avant toute progression vers 0-pre.2.

Documentation et nomenclature

• adoption de 000-README.md comme point d'entrée des répertoires documentaires multi-fichiers ;
• renommage de docs/ideas/README.md, docs/studies/README.md et history/README.md ;
• généralisation des marqueurs ( ), (x), (d), (c) à toute liste durable de tâches ou d'état, pas seulement au ROADMAP ;
• conservation des listes descriptives simples sans marqueur artificiel.

Plateformes

La conception réserve désormais explicitement :

• Desktop : Linux, Windows, macOS ;
• Mobile : Android, iOS ;
• Web : navigateur/WASM.

Téléphone et tablette restent des classes de device séparées de l'OS et du backend technique. SDL3 reste le backend natif de référence du POC sans devenir l'identité architecturale d'une plateforme.

Tauri et versions

• tauri.conf.json n'embarque plus de version produit et laisse Tauri utiliser la version Cargo ;
• package.json n'est plus synchronisé à chaque pre.N / .fix.N et revient à la dernière version frontend significative 0.1.0 pendant cette phase documentaire ;
• Cargo reste la source canonique de version produit.

Workflow RC et prompt suivant

• une RC est fonctionnellement gelée ;
• les bugfixes, corrections de tests, packaging, sécurité et défauts de release peuvent modifier du code sans retour automatique en beta ;
• une réouverture fonctionnelle de la RC nécessite de revenir à une phase de développement adaptée, normalement beta ;
• le prompt de la version suivante devient recommandé après validation de la première RC réellement gelée, puis peut être affiné jusqu'à la stable.

Planification des versions de code

Le cycle conceptuel est :

PLAN → IMPLEMENT → INTEGRATE → VALIDATE → CANDIDATE → RELEASE

Ces phases n'imposent pas une prerelease chacune. Une petite version peut combiner PLAN et première implémentation dans pre.1; une version lourde peut réserver pre.1 à la décomposition.

Matrice de validation

Ajout de docs/rules/RULES_VALIDATION_MATRIX.md avec :

• identifiants stables CMD-* ;
• dépendances entre commandes ;
• portée ciblée par crate ;
• propagation vers les consommateurs impactés ;
• gates Desktop, Tauri et Android ;
• règles beta/RC ;
• commandes de maintenance disque.

Politique Cargo clean

Le besoin de contrôle disque est reconnu explicitement.

cargo clean complet peut être planifié périodiquement à un jalon de cycle afin d'éviter l'accumulation de dizaines ou centaines de Go sous ../builds/sasedev-games/target.

Entre deux cleans complets, utiliser si pertinent :

cargo clean -p <package>
cargo clean --release
cargo clean --profile <profile>
cargo clean --target <triple>
cargo clean --dry-run --verbose

Il n'existe pas de contrat projet consistant à conserver automatiquement « uniquement la dernière génération utile » des artefacts Cargo : les nettoyages ciblés ou complets sont donc des opérations explicites.

Suppressions nécessaires

Un overlay ZIP ne supprime pas les anciens fichiers. Après extraction du delta, appliquer :

while IFS= read -r path; do
    rm -rf -- "$path"
done < deltas/0.2.0/0-pre.1.fix.1.delete.txt

Validation automatique

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 deltas history
python3 scripts/audit_distribution_layout.py

La suppression de version dans tauri.conf.json modifie une configuration de build. Une vérification Tauri est donc recommandée avant validation définitive du fix :

(cd crates/apps/game-reflex-poc-tauri && cargo tauri build)

Aucun smoke gameplay supplémentaire n'est requis si le build Tauri est propre, car le gameplay et le runtime ne sont pas modifiés.

Validation humaine

Relire prioritairement :

• docs/rules/RULES_DOCUMENTATION.md ;
• docs/rules/RULES_COMMANDS.md ;
• docs/rules/RULES_VALIDATION_MATRIX.md ;
• docs/rules/VERSION_WORKFLOW.md ;
• docs/rules/FILE_CONTRACTS.md ;
• docs/architecture/003-SDL3_PLATFORM_ABSTRACTION.md ;
• docs/rules/RULES_PROJECT.md ;
• prompts/001-V0_2_0_START_PROMPT.md.

Ce fix ne valide toujours pas le catalogue fonctionnel 0.2.0 : la progression vers 0-pre.2 dépend de la revue humaine de cette gouvernance.