0.1.0-0-pre.4-fix.1

This commit is contained in:
2026-09-16 01:08:49 +02:00
parent dc22011997
commit e1899a4098
10 changed files with 171 additions and 10 deletions

View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/RULES_COMMANDS.md -->
<!-- version: 3 -->
<!-- version: 4 -->
# Règles d'exécution des commandes
@@ -15,6 +15,7 @@
- **CMD-GEN-008** — Chaque fichier delta indique les commandes de validation que l'utilisateur doit exécuter et le statut connu de la validation du delta précédent.
- **CMD-GEN-009** — Lorsque l'utilisateur fournit une gate complète propre, le delta est considéré validé et le travail peut passer automatiquement au delta planifié suivant sauf instruction contraire.
- **CMD-GEN-010** — Si une gate échoue, la progression vers le delta suivant est suspendue ; le correctif est livré sous le suffixe `.fix.N` du delta courant, sauf décision explicite contraire.
- **CMD-GEN-011** — Les commandes d'audit Markdown couvrent également `history/` dès que cette arborescence existe.
## Rust et Cargo

View File

@@ -8,8 +8,14 @@
- **DOC-003** — Les documents normatifs résident sous `docs/rules/`.
- **DOC-004** — Les documents d'architecture résident sous `docs/architecture/`.
- **DOC-005** — Les documents de validation résident sous `docs/validation/`.
- **DOC-005A** — Les objectifs, classifications de jeux, évolutions moteur, monétisation, services et workflows résident dans leurs sous-répertoires thématiques de `docs/` et sont indexés par `docs/000-README.md`.
- **DOC-006** — Les documents internes sont en français ; code, symboles et extraits techniques conservent leur langue naturelle.
- **DOC-007** — Les tableaux Markdown suivent le format contrôlé par `scripts/audit_markdown_tables.py`.
- **DOC-008** — Deux lignes blanches consécutives sont interdites hors blocs de code.
- **DOC-009** — Un delta décrit les changements de sa version et ne devient pas un substitut au `CHANGELOG.md` ou aux règles durables.
- **DOC-009** — Un fichier sous `deltas/<X.Y.Z>/` décrit exactement la tranche livrée, son état de base et ses commandes de validation ; il est immuable après livraison.
- **DOC-010** — L'historique transitoire validé réside sous `history/<X.Y.Z>/` avec un fichier immuable par jalon accepté.
- **DOC-011** — Une entrée `history/` n'est créée qu'après validation du jalon qu'elle décrit ; le résultat d'une validation future n'est jamais pré-écrit.
- **DOC-012** — Le delta suivant, ou le fix suivant lorsqu'il existe, crée l'entrée `history/` du dernier jalon définitivement validé si elle n'existe pas encore.
- **DOC-013** — `CHANGELOG.md` reste une synthèse destinée aux jalons significatifs et ne reproduit pas l'historique détaillé des `pre.*` et de leurs fixes.
- **DOC-014** — Après la structuration initiale de `0.1.0`, les `pre.*` et `.fix.*` ne modifient normalement pas `CHANGELOG.md`. Les entrées `alpha` et `beta` peuvent y apparaître uniquement lorsqu'elles correspondent à un jalon externe significatif ; `rc` et releases stables y sont les jalons privilégiés.
- **DOC-015** — `ROADMAP.md` n'est pas modifié mécaniquement à chaque delta ; il change uniquement lorsque le périmètre, l'ordre, les objectifs ou les jalons planifiés évoluent réellement.
- **DOC-016** — `history/` et `deltas/` ont des rôles distincts : `deltas/` décrit une livraison candidate et sa validation attendue ; `history/` enregistre le résultat accepté et durable.