games/docs/rules/RULES_SESSION_PLANNING.md

<!-- file: docs/rules/RULES_SESSION_PLANNING.md -->
<!-- version: 3 -->

# Règles de cadrage des versions, sessions et prompts

## Objet

Ces règles imposent un découpage suffisamment petit pour qu'une version puisse être développée complètement dans une seule session et reprise sans ambiguïté.

## `pre.1` — cadrage obligatoire

- **SESSION-001** — Toute nouvelle version commence par une `0-pre.1` de cadrage.
- **SESSION-002** — Cette tranche couvre au minimum l'audit de la base, le brainstorming/recherche de requirements, le sizing, les dépendances, les validations prévues et le découpage prévisionnel.
- **SESSION-003** — Une première implémentation peut être incluse dans `0-pre.1` uniquement si elle est petite, cohérente et n'empêche pas le cadrage d'être terminé.
- **SESSION-004** — Si le sizing montre que l'objectif global ne peut raisonnablement pas être terminé dans la session, il est scindé en plusieurs versions avant le développement lourd.
- **SESSION-005** — `0-pre.1` crée ou révise obligatoirement le plan de la version sous `docs/plans/`. Ce plan est un livrable du cadrage, pas une note optionnelle.
- **SESSION-006** — Le plan de version contient au minimum l'objectif et le scope, les décisions acquises, les dépendances/risques utiles, les validations attendues, les hors-périmètre et une prévision souple des tranches jusqu'à la release stable.
- **SESSION-007** — La prévision du plan n'est pas un calendrier figé : une tranche peut être scindée, fusionnée, déplacée ou complétée par un fix lorsque les résultats réels le justifient. Le plan actif est alors réconcilié et le delta explique le changement.
- **SESSION-008** — `ROADMAP.md` reste macroscopique, le plan porte le découpage prévisionnel fin de la version et les deltas enregistrent ce qui a réellement été livré.
- **SESSION-009** — Le forecast créé en `0-pre.1` rend explicitement visible une tranche de consolidation avant la candidate finale ; cette tranche couvre au minimum la réconciliation de la documentation durable, `CHANGELOG.md`, `ROADMAP.md`, l'historique applicable et le prompt de la version/session suivante, même si son numéro exact reste prévisionnel.

## Taille des tranches

- **SESSION-010** — Une tranche `pre.N`, `alpha.N`, `beta.N`, `rc.N` ou `fix.N` vise normalement un delta correspondant à environ 15 à 30 minutes de travail effectif.
- **SESSION-011** — Une tranche clairement plus lourde est scindée avant exécution.
- **SESSION-012** — Plusieurs micro-tranches sans valeur de validation indépendante peuvent être regroupées.
- **SESSION-013** — Le découpage suit des unités fonctionnelles complètes et validables ; une fonctionnalité ne doit pas être volontairement coupée au milieu uniquement pour respecter un numéro de prerelease.
- **SESSION-014** — Chaque tranche livre son delta et ses validations proportionnelles avant la tranche suivante.

## Une version par session

- **SESSION-020** — Une session de développement est dimensionnée pour livrer au minimum une version concrète complète, de son cadrage jusqu'à sa release stable.
- **SESSION-021** — Une prerelease est une tranche interne de progression et ne constitue pas une cible normale de fin de session ; la session ne doit pas être planifiée pour s'arrêter au milieu de la version ouverte.
- **SESSION-022** — Si de nouvelles informations rendent la version trop grande, le scope restant est replanifié explicitement vers une ou plusieurs versions suivantes au lieu de prolonger indéfiniment la version courante.
- **SESSION-023** — Le découpage prévisionnel doit donc permettre de suivre toute la progression de la version dans la même session, tout en restant assez souple pour insérer des fixes ou déplacer du scope sans forcer artificiellement la fermeture.

## Dernières tranches

- **SESSION-030** — Les dernières tranches consolident les validations, la documentation durable, `CHANGELOG.md`, `ROADMAP.md`, l'historique applicable et le prompt de la prochaine session.
- **SESSION-031** — La release stable reste autant que possible mécanique et n'introduit pas de nouveau scope fonctionnel ou architectural.

## Prompt de prochaine session

- **PROMPT-001** — Le prompt suivant est préparé à partir d'un état réellement validé ; il ne prétend jamais qu'une validation future a déjà été exécutée.
- **PROMPT-002** — Le prompt indique la base exacte, la version cible, l'objectif, le scope inclus/exclus, les décisions gelées, les points ouverts et les validations attendues.
- **PROMPT-003** — Le prompt distingue explicitement les résultats déjà validés des commandes à exécuter dans la nouvelle session.
- **PROMPT-004** — Le prompt donne une trajectoire prévisionnelle des tranches sans rendre cette prévision immuable.
- **PROMPT-005** — Le prompt rappelle les invariants essentiels mais renvoie aux RULES pour les détails normatifs au lieu de les recopier intégralement.
- **PROMPT-006** — Le prompt contient suffisamment de contexte pour reprendre la version sans dépendre de la mémoire conversationnelle ni relire toute l'histoire du dépôt.
- **PROMPT-007** — Le prompt précise la condition de fin de session et les livrables attendus.
- **PROMPT-008** — Si `pre.1` invalide le sizing prévu par le prompt, le nouveau découpage est documenté immédiatement avant le développement lourd.

## Relation avec VERSION_WORKFLOW

`VERSION_WORKFLOW.md` définit le cycle SemVer et la maturation. Le présent document précise comment dimensionner et transmettre une session de travail.