0.2.0-0-pre.7

Android/game-reflex-poc/build.gradle

@@ -1,5 +1,5 @@
 // file: Android/game-reflex-poc/build.gradle
-// version: 40
+// version: 41
 
 plugins {
     id 'com.android.application'
@@ -18,7 +18,7 @@ android {
         minSdk 21
         targetSdk 36
         versionCode 2
-        versionName '0.2.0-0-pre.6.fix.1'
+        versionName '0.2.0-0-pre.7'
     }
 
     compileOptions {

Android/game-snake-poc/build.gradle

@@ -1,5 +1,5 @@
 // file: Android/game-snake-poc/build.gradle
-// version: 40
+// version: 41
 
 plugins {
     id 'com.android.application'
@@ -18,7 +18,7 @@ android {
         minSdk 21
         targetSdk 36
         versionCode 2
-        versionName '0.2.0-0-pre.6.fix.1'
+        versionName '0.2.0-0-pre.7'
     }
 
     compileOptions {

Cargo.toml

@@ -1,5 +1,5 @@
 # file: Cargo.toml
-# version: 52
+# version: 53
 
 [workspace]
 resolver = "3"
@@ -19,7 +19,7 @@ members = [
 ]
 
 [workspace.package]
-version = "0.2.0-0-pre.6.fix.1"
+version = "0.2.0-0-pre.7"
 edition = "2024"
 license = "MIT"
 repository = "https://git.sasedev.com/Sasedev/games"

README.md

@@ -1,5 +1,5 @@
 <!-- file: README.md -->
-<!-- version: 20 -->
+<!-- version: 21 -->
 
 # games.sasedev
 
@@ -25,7 +25,7 @@ Workspace expérimental puis productif pour des jeux multiplateformes principale
 
 Version stable de référence : `0.1.0`.
 
-Version candidate en cours de conception : `0.2.0-0-pre.6.fix.1`.
+Version candidate en cours de conception : `0.2.0-0-pre.7`.
 
 Les deux premiers jeux sont des POC structurels : `game-reflex-poc` et `game-snake-poc`. Ils existent d'abord pour valider les frontières du workspace, le moteur, les assets et le packaging multiplateforme.
 

ROADMAP.md

@@ -1,5 +1,5 @@
 <!-- file: ROADMAP.md -->
-<!-- version: 17 -->
+<!-- version: 18 -->
 
 # Roadmap
 
@@ -30,7 +30,7 @@ Le détail historique des prereleases `0.1.0-*` reste dans `deltas/0.1.0/` et `h
 - ( ) `0.2.0` — établir la matrice plateformes et les archétypes de jeux utilisés pour challenger l'architecture.
 - ( ) `0.2.0` — définir le modèle de composition statique, le manifest produit/jeu et l'architecture cible des crates.
 - ( ) `0.2.0` — définir la trajectoire d'implémentation progressive des versions suivantes seulement après revue de la conception.
-- ( ) `0.2.0` — consolider les études acceptées en architecture/règles durables et fermer les points de classification encore candidats.
+- ( ) `0.2.0` — consolider les études acceptées en architecture/règles durables, notamment ownership, réseau, Uroburas et POC, puis fermer les points encore candidats.
 - ( ) `0.2.0` — formaliser la stratégie réseau : Actix Web pour le Web/API, asset delivery auto-hébergé H2/H3, WebSocket baseline et WebTransport/QUIC candidat.
 - ( ) `0.2.0` — préparer une trajectoire `0.3.x` dédiée aux POC plateforme/réseau avec Snake comme jeu-sonde.
 - ( ) `0.2.0` — préparer la trajectoire `0.4.x` Uroburas Mode 1 et le prompt de session associé après gel de la conception.

RULES.md

@@ -1,5 +1,5 @@
 <!-- file: RULES.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Index normatif games.sasedev
 
@@ -16,7 +16,9 @@ Les règles détaillées sont maintenues sous `docs/rules/` et sont cumulatives
 5. [`docs/rules/FILE_CONTRACTS.md`](docs/rules/FILE_CONTRACTS.md) — responsabilités des principales familles de fichiers ;
 6. [`docs/rules/VERSION_WORKFLOW.md`](docs/rules/VERSION_WORKFLOW.md) — SemVer, niveaux de maturité, fixes, deltas et livraisons ;
 7. [`docs/rules/RULES_COMMANDS.md`](docs/rules/RULES_COMMANDS.md) — politique d’exécution des commandes Cargo, audits, runners, Android, Web et Git ;
-8. [`docs/rules/RULES_VALIDATION_MATRIX.md`](docs/rules/RULES_VALIDATION_MATRIX.md) — matrice évolutive des commandes, dépendances de validation et politiques de nettoyage.
+8. [`docs/rules/RULES_VALIDATION_MATRIX.md`](docs/rules/RULES_VALIDATION_MATRIX.md) — matrice évolutive des commandes, dépendances de validation et politiques de nettoyage ;
+9. [`docs/rules/RULES_SESSION_PLANNING.md`](docs/rules/RULES_SESSION_PLANNING.md) — cadrage `pre.1`, dimensionnement des sessions et contrat des prompts de reprise ;
+10. [`docs/rules/RULES_SERVER_HOSTING.md`](docs/rules/RULES_SERVER_HOSTING.md) — contraintes durables de portabilité et préférence d'auto-hébergement.
 
 ## Hiérarchie
 

deltas/0.2.0/0-pre.7.md

@@ -0,0 +1,82 @@
+<!-- file: deltas/0.2.0/0-pre.7.md -->
+<!-- version: 1 -->
+
+# Delta 0.2.0-0-pre.7
+
+## Base
+
+Base déclarée : `0.2.0-0-pre.6.fix.1`.
+
+Cette base est utilisée comme état de travail. Aucune entrée d'historique ne prétend que `0-pre.6.fix.1` a déjà passé une validation utilisateur non fournie.
+
+## Objet
+
+Promouvoir les décisions retenues des études `0.2.0` vers des documents durables d'architecture et de règles.
+
+## Architecture consolidée
+
+Documents ajoutés :
+
+- architecture modulaire et ownership ;
+- architecture réseau/serveur ;
+- architecture cible Uroburas ;
+- architecture des POC plateforme/réseau.
+
+Les études restent comme justification et historique de conception ; les nouveaux documents portent les orientations durables.
+
+## Règles consolidées
+
+Deux règles durables sont ajoutées :
+
+- cadrage des versions/sessions/prompts ;
+- portabilité et auto-hébergement serveur.
+
+La cible opérationnelle préférée est Debian Stable, actuellement Debian 13 `trixie`, sans dépendance métier à cette version.
+
+Les choix futurs HAProxy/nginx/HTTP3 edge/storage restent explicitement hors gel `0.2.0`.
+
+## Réseau durable
+
+- Actix Web reste la référence Web/API ;
+- Maud reste la référence HTML server-side ;
+- Fluent/fluent-bundle porte la localisation ;
+- Lettre porte l'email transactionnel ;
+- WebSocket/tokio-tungstenite est la baseline realtime ;
+- WebTransport/QUIC reste un candidat POC ;
+- gRPC/Tonic est conditionnel aux frontières server-to-server ;
+- asset delivery reste auto-hébergé et compatible H2/H3 selon disponibilité.
+
+## Workflow durable
+
+`pre.1` devient la tranche obligatoire de cadrage.
+
+Une version est dimensionnée pour tenir dans une session.
+
+Les tranches visent normalement 15 à 30 minutes et restent fonctionnellement complètes.
+
+La fin de version consolide CHANGELOG, ROADMAP et le prompt suivant ; la stable reste mécanique.
+
+## ROADMAP
+
+Les lignes de scope `0.2.0` ne sont pas marquées comme complètes dans ce delta avant revue humaine de la consolidation.
+
+## Suite attendue
+
+Après validation de `0-pre.7` :
+
+1. audit documentaire global ;
+2. réconciliation finale studies/architecture/rules/ROADMAP ;
+3. CHANGELOG de candidate ;
+4. prompt de session `0.3.x` ;
+5. RC documentaire ;
+6. release stable mécanique.
+
+## Validation
+
+```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
+```
+
+Aucune gate Cargo/Gradle/smoke n'est requise : `0.2.0` reste strictement documentaire hors métadonnées de version.

docs/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 18 -->
+<!-- version: 19 -->
 
 # Documentation games.sasedev
 
@@ -22,6 +22,10 @@
 - [`architecture/009-ENGINE_V1_RENDER_SCENE.md`](architecture/009-ENGINE_V1_RENDER_SCENE.md) — scène 2D portable, rectangles normalisés et backend SDL3.
 - [`architecture/010-RUNTIME_PROVENANCE.md`](architecture/010-RUNTIME_PROVENANCE.md) — provenance plateforme/device/runtime/input pour sessions, scores et analytics.
 - [`architecture/011-POST_0_1_0_DIRECTION.md`](architecture/011-POST_0_1_0_DIRECTION.md) — décisions de transition entre le POC stable 0.1.0 et la conception modulaire 0.2.0.
+- [`architecture/012-MODULAR_LAYERING_AND_OWNERSHIP.md`](architecture/012-MODULAR_LAYERING_AND_OWNERSHIP.md) — architecture durable kernel/capabilities/game-systems/games/adapters/providers/services/tooling.
+- [`architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md`](architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md) — Web/API, realtime, transports, asset delivery auto-hébergé et frontières serveur.
+- [`architecture/014-UROBURAS_TARGET_ARCHITECTURE.md`](architecture/014-UROBURAS_TARGET_ARCHITECTURE.md) — ownership cible des besoins Uroburas et ordre Mode 1 → Mode 3 → Mode 2.
+- [`architecture/015-PLATFORM_POC_ARCHITECTURE.md`](architecture/015-PLATFORM_POC_ARCHITECTURE.md) — rôle des POC `0.3.x`, Snake comme sonde et critères d'extraction.
 
 ## Jeux
 
@@ -45,7 +49,7 @@
 
 ## Règles
 
-Voir [`../RULES.md`](../RULES.md), notamment [`rules/RULES_DOCUMENTATION.md`](rules/RULES_DOCUMENTATION.md) pour la gouvernance documentaire, [`rules/RULES_COMMANDS.md`](rules/RULES_COMMANDS.md) pour la politique d'exécution et [`rules/RULES_VALIDATION_MATRIX.md`](rules/RULES_VALIDATION_MATRIX.md) pour la matrice des gates.
+Voir [`../RULES.md`](../RULES.md), notamment [`rules/RULES_DOCUMENTATION.md`](rules/RULES_DOCUMENTATION.md) pour la gouvernance documentaire, [`rules/RULES_COMMANDS.md`](rules/RULES_COMMANDS.md) pour la politique d'exécution, [`rules/RULES_VALIDATION_MATRIX.md`](rules/RULES_VALIDATION_MATRIX.md) pour la matrice des gates, [`rules/RULES_SESSION_PLANNING.md`](rules/RULES_SESSION_PLANNING.md) pour le cadrage des sessions et [`rules/RULES_SERVER_HOSTING.md`](rules/RULES_SERVER_HOSTING.md) pour la portabilité d'auto-hébergement.
 
 ## Validation
 

docs/architecture/012-MODULAR_LAYERING_AND_OWNERSHIP.md

@@ -0,0 +1,56 @@
+<!-- file: docs/architecture/012-MODULAR_LAYERING_AND_OWNERSHIP.md -->
+<!-- version: 1 -->
+
+# Architecture modulaire et ownership
+
+## Décision
+
+Le framework est structuré par responsabilité et non par jeu ou plateforme unique.
+
+```text
+game-specific
+    ↓
+game-systems
+    ↓
+technical capabilities
+    ↓
+engine kernel contracts
+```
+
+La composition produit ajoute latéralement les platform adapters, providers, server contracts et tooling.
+
+## Engine kernel
+
+Le kernel contient uniquement les primitives nécessaires à tous les jeux consommateurs : lifecycle, update/render, temps, runtime events, provenance et contrats minimaux input/render.
+
+Il ne contient pas de logique Snake, publicité, authentification, HTTP ou règles Uroburas.
+
+## Technical capabilities
+
+Les capabilities fournissent des mécanismes techniques réutilisables : input, rendu 2D, audio, assets/content, localisation, persistence, networking et logging/telemetry.
+
+## Game-systems
+
+Les game-systems portent des mécaniques réutilisables entre jeux lorsque leur API est réellement justifiée : grid/tilemap, collision, caméra gameplay, stages, score, vies/attempts, timed entities, pickups/inventory et status effects lorsque leur généralisation devient réelle.
+
+## Game-specific
+
+Une crate jeu conserve les règles propres au jeu, la composition des systèmes et les concepts qui n'ont pas encore de second consommateur crédible.
+
+Une mécanique n'est pas extraite uniquement parce qu'elle pourrait théoriquement servir ailleurs.
+
+## Adapters, providers et services
+
+Les adapters traduisent un environnement local. Les providers encapsulent un service externe. Le gameplay ne dépend pas directement d'un adapter ou SDK provider concret.
+
+Les services serveur possèdent leurs modèles métier et leurs contrats de transport dédiés. Actix, Tungstenite, Protobuf ou Maud ne remontent pas dans le gameplay.
+
+## Tooling
+
+Éditeurs, build tooling, audits et outils de publication restent séparés du runtime du jeu.
+
+## Création de crates
+
+Une nouvelle crate est justifiée par une frontière stable ou un besoin de réutilisation réel.
+
+Le projet évite à la fois la crate jeu monolithique et l'explosion artificielle en une crate par concept minuscule.

docs/architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md

@@ -0,0 +1,85 @@
+<!-- file: docs/architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md -->
+<!-- version: 1 -->
+
+# Architecture réseau et serveur
+
+## Web/API
+
+La stack serveur Web de référence est :
+
+```text
+Tokio
+Actix Web
+Maud
+Fluent / fluent-bundle
+Lettre
+```
+
+Actix Web porte le Web/API, l'authentification, les comptes, Hall of Fame, metadata de contenu, reward authority et administration initiale.
+
+## Realtime
+
+Le realtime est séparé du Web/API classique.
+
+Baseline :
+
+```text
+Tokio
+tokio-tungstenite
+WebSocket
+```
+
+Candidat à évaluer :
+
+```text
+WebTransport
+QUIC
+```
+
+La simulation authoritative ne dépend directement d'aucun de ces transports.
+
+## Frontière de transport
+
+```text
+transport
+    ↓
+wire codec
+    ↓
+session protocol
+    ↓
+synchronization
+    ↓
+authoritative simulation
+```
+
+Le client utilise une realtime transport API. WebSocket reste le fallback de référence. WebTransport est évalué lorsqu'il apporte un bénéfice mesuré.
+
+## gRPC
+
+`tonic`/gRPC est réservé aux frontières server-to-server qui le justifient. Il n'est pas un transport obligatoire entre le client public et le serveur realtime.
+
+## Asset delivery
+
+Les assets sont auto-hébergés par défaut.
+
+```text
+assets.games.sasedev.com
+    HTTP/2
+    HTTP/3/QUIC si disponible
+```
+
+H2 et H3 peuvent coexister sur le même hostname avec fallback.
+
+Content metadata/authorization et transfert lourd d'assets sont deux responsabilités distinctes.
+
+## Déploiement progressif
+
+Une seule machine peut initialement héberger plusieurs services logiques.
+
+L'architecture permet ensuite de séparer Web/API, Assets, Realtime, Database et Media/replay, puis de multiplier les nœuds selon la charge.
+
+## Portabilité d'exploitation
+
+Debian Stable est la cible opérationnelle préférée.
+
+Le choix futur d'un edge/reverse proxy HTTP/3, stockage ou composant d'infrastructure reste reporté aux POC correspondants et doit tenir compte de la disponibilité/maturité sur Debian Stable.

docs/architecture/014-UROBURAS_TARGET_ARCHITECTURE.md

@@ -0,0 +1,74 @@
+<!-- file: docs/architecture/014-UROBURAS_TARGET_ARCHITECTURE.md -->
+<!-- version: 1 -->
+
+# Architecture cible Uroburas
+
+## Principe
+
+Uroburas n'est pas une crate monolithique.
+
+La crate jeu conserve ce qui décrit réellement Uroburas ; les mécanismes réutilisables, services serveur, intégrations provider et tooling vivent dans leurs couches respectives.
+
+## Première trajectoire
+
+```text
+Mode 1 — Challenge
+    ↓
+Mode 3 — Persistent Battle Royale
+    ↓
+Mode 2 — PvP Battles
+```
+
+La première version réelle stabilise d'abord les moteurs du Mode 1.
+
+## Réutilisable hors Uroburas
+
+À implémenter comme capabilities ou game-systems lorsque les frontières sont suffisamment claires :
+
+- input abstrait ;
+- virtual directional controls ;
+- rendu sprite/rotation ;
+- grid/tilemap toroïdale ;
+- collision ;
+- caméra ;
+- stages ;
+- vies/attempts ;
+- score ;
+- timed entities ;
+- pickups ;
+- assets/content download/cache ;
+- localisation Fluent ;
+- networking client.
+
+## Uroburas-specific
+
+Reste spécifique au jeu au départ :
+
+- anatomie tête + cou + corps extensible + queue ;
+- longueur minimale de quatre unités ;
+- mouvement Snake ;
+- géométrie du corps ;
+- règles propres aux maps Uroburas ;
+- règles de run Challenge ;
+- modes Uroburas ;
+- combat feu/glace/poison/protections/téléporteurs tant qu'aucun second jeu ne justifie leur généralisation.
+
+## Serveur Mode 1
+
+La première trajectoire serveur couvre PlayerId/auth, comptes, map/asset metadata, contenu téléchargeable, Hall of Fame, rewarded continue, rewarded stage multiplier, validation/idempotence et échanges HTTP sécurisés/versionnés.
+
+Le realtime n'est pas requis pour le Mode 1.
+
+## Mode 3 puis Mode 2
+
+Le Mode 3 introduit authoritative simulation, realtime transport, bots, spectator, snapshots/deltas, interest management, rejoin cooldown et persistent world lifecycle.
+
+Le Mode 2 réutilise ensuite ces briques pour les matches bornés, privés, matchmaking, équipes et règles de vie.
+
+## Tooling
+
+Le map editor démarre lorsque le format de map est suffisamment stable.
+
+Le skin editor vient après stabilisation du contrat graphique des skins.
+
+Ils restent séparés du runtime du jeu.

docs/architecture/015-PLATFORM_POC_ARCHITECTURE.md

@@ -0,0 +1,45 @@
+<!-- file: docs/architecture/015-PLATFORM_POC_ARCHITECTURE.md -->
+<!-- version: 1 -->
+
+# Architecture des POC plateforme et réseau
+
+## Rôle de la série 0.3.x
+
+La série `0.3.x` doit éprouver les frontières décidées en `0.2.0` avant le développement Uroburas réel.
+
+Snake est le jeu-sonde principal.
+
+## POC plateforme prioritaires
+
+Première vague :
+
+- Tauri Android + Snake ;
+- Web navigateur direct + Snake ;
+- Tauri Desktop + Snake ;
+- build Android multi-ABI avec outils natifs.
+
+Plateformes supplémentaires lorsque l'environnement existe : Windows SDL natif, macOS SDL natif et iOS SDL natif.
+
+## POC réseau
+
+Avant le Mode 3, comparer au minimum WebSocket/tokio-tungstenite, WebTransport/QUIC, fallback automatique, charge, reconnect/resync, backpressure, snapshots/deltas et mobilité réseau.
+
+Le même protocole métier doit pouvoir être exercé sur plusieurs transports.
+
+## Build
+
+Les builds utilisent Cargo, Gradle, Tauri CLI et les toolchains plateforme.
+
+Python reste limité aux audits, validations complémentaires et contrôles statiques.
+
+## Critère d'extraction
+
+Un POC sert à identifier duplication, adapters manquants, capability réellement réutilisable, frontières mal placées et coût de maintenance.
+
+Une abstraction n'est pas extraite avant observation d'un besoin concret.
+
+## Relation avec Uroburas
+
+Les résultats des POC `0.3.x` déterminent les choix techniques conservés pour la trajectoire Uroburas `0.4.x`.
+
+Le POC ne doit pas réimplémenter le futur jeu ; il valide ses fondations.

docs/rules/RULES_SERVER_HOSTING.md

@@ -0,0 +1,31 @@
+<!-- file: docs/rules/RULES_SERVER_HOSTING.md -->
+<!-- version: 1 -->
+
+# Règles de portabilité et d'auto-hébergement serveur
+
+## Portabilité
+
+- **HOST-001** — Le logiciel serveur Rust reste indépendant d'une version précise de distribution Linux au niveau métier.
+- **HOST-002** — Les dépendances propres au déploiement, à `systemd`, au firewall, au reverse proxy, aux certificats et au layout filesystem restent hors du domaine métier.
+- **HOST-003** — Une décision d'infrastructure ne doit pas contaminer les crates de gameplay ou les contrats réseau publics.
+
+## Cible opérationnelle préférée
+
+- **HOST-010** — La cible d'auto-hébergement de référence est Debian Stable.
+- **HOST-011** — Debian 13 « trixie » est l'environnement courant de développement/test serveur, sans constituer une dépendance fonctionnelle à cette version.
+- **HOST-012** — Les paquets des dépôts officiels Debian sont préférés.
+- **HOST-013** — Les dépôts tiers sont évités par défaut et ne sont admis que pour un outil spécifique lorsque le besoin est justifié et la source suffisamment stable.
+- **HOST-014** — Ubuntu LTS peut être évalué comme solution secondaire lorsqu'une contrainte technique matérielle rend Debian impraticable ; il n'est pas la cible par défaut.
+
+## Choix futurs d'infrastructure
+
+- **HOST-020** — Les choix futurs tels que HAProxy, nginx, serveur HTTP/3, stockage objet ou autres composants sont évalués au moment du POC/déploiement correspondant.
+- **HOST-021** — Leur compatibilité avec Debian Stable, leur maturité, leur disponibilité sans dépôt tiers, leur maintenance et leur support de protocole font partie des critères.
+- **HOST-022** — Aucun composant edge/reverse-proxy n'est figé par `0.2.0`.
+
+## Auto-hébergement progressif
+
+- **HOST-030** — Les services peuvent commencer sur une même machine avec séparation logique par service/hostname.
+- **HOST-031** — La séparation physique sur plusieurs machines est motivée par charge, sécurité, isolation ou cycle de déploiement.
+- **HOST-032** — L'architecture doit permettre de déplacer Web/API, assets, realtime, base de données et media/replay sans modifier les règles Uroburas.
+- **HOST-033** — Un CDN tiers n'est pas une dépendance obligatoire ; l'asset delivery auto-hébergé et sa distribution progressive restent une trajectoire supportée.

docs/rules/RULES_SESSION_PLANNING.md

@@ -0,0 +1,49 @@
+<!-- file: docs/rules/RULES_SESSION_PLANNING.md -->
+<!-- version: 1 -->
+
+# 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.
+
+## 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 vise une version complète, de son cadrage jusqu'à sa release ou à sa candidate de publication selon le scope décidé.
+- **SESSION-021** — Une session ne doit pas être planifiée de façon à s'arrêter normalement au milieu d'une version.
+- **SESSION-022** — Si de nouvelles informations rendent la version trop grande, le scope restant est replanifié explicitement vers une version suivante au lieu de prolonger indéfiniment la session.
+
+## 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.