# 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 : ```text 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 : ```bash cargo clean -p cargo clean --release cargo clean --profile cargo clean --target 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 : ```bash while IFS= read -r path; do rm -rf -- "$path" done < deltas/0.2.0/0-pre.1.fix.1.delete.txt ``` ## Validation automatique ```bash 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 : ```bash (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.