122 lines
4.6 KiB
Markdown
122 lines
4.6 KiB
Markdown
<!-- file: deltas/0.2.0/0-pre.1.fix.1.md -->
|
|
<!-- version: 1 -->
|
|
|
|
# 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 <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 :
|
|
|
|
```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.
|