diff --git a/Android/game-reflex-poc/build.gradle b/Android/game-reflex-poc/build.gradle index 85f7f90..bb31435 100644 --- a/Android/game-reflex-poc/build.gradle +++ b/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 { diff --git a/Android/game-snake-poc/build.gradle b/Android/game-snake-poc/build.gradle index 1df5f3a..319ef88 100644 --- a/Android/game-snake-poc/build.gradle +++ b/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 { diff --git a/Cargo.toml b/Cargo.toml index 5548871..4bba8ea 100644 --- a/Cargo.toml +++ b/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" diff --git a/README.md b/README.md index d33ee93..b124828 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,5 @@ - + # 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. diff --git a/ROADMAP.md b/ROADMAP.md index 8d86bbb..03bc9b5 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -1,5 +1,5 @@ - + # 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. diff --git a/RULES.md b/RULES.md index 9798517..c0773e7 100644 --- a/RULES.md +++ b/RULES.md @@ -1,5 +1,5 @@ - + # 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 diff --git a/deltas/0.2.0/0-pre.7.md b/deltas/0.2.0/0-pre.7.md new file mode 100644 index 0000000..44978ef --- /dev/null +++ b/deltas/0.2.0/0-pre.7.md @@ -0,0 +1,82 @@ + + + +# 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. diff --git a/docs/000-README.md b/docs/000-README.md index de3e3f8..77f98a8 100644 --- a/docs/000-README.md +++ b/docs/000-README.md @@ -1,5 +1,5 @@ - + # 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 diff --git a/docs/architecture/012-MODULAR_LAYERING_AND_OWNERSHIP.md b/docs/architecture/012-MODULAR_LAYERING_AND_OWNERSHIP.md new file mode 100644 index 0000000..da03572 --- /dev/null +++ b/docs/architecture/012-MODULAR_LAYERING_AND_OWNERSHIP.md @@ -0,0 +1,56 @@ + + + +# 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. diff --git a/docs/architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md b/docs/architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md new file mode 100644 index 0000000..c5be747 --- /dev/null +++ b/docs/architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md @@ -0,0 +1,85 @@ + + + +# 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. diff --git a/docs/architecture/014-UROBURAS_TARGET_ARCHITECTURE.md b/docs/architecture/014-UROBURAS_TARGET_ARCHITECTURE.md new file mode 100644 index 0000000..f5e7c35 --- /dev/null +++ b/docs/architecture/014-UROBURAS_TARGET_ARCHITECTURE.md @@ -0,0 +1,74 @@ + + + +# 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. diff --git a/docs/architecture/015-PLATFORM_POC_ARCHITECTURE.md b/docs/architecture/015-PLATFORM_POC_ARCHITECTURE.md new file mode 100644 index 0000000..afdacd5 --- /dev/null +++ b/docs/architecture/015-PLATFORM_POC_ARCHITECTURE.md @@ -0,0 +1,45 @@ + + + +# 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. diff --git a/docs/rules/RULES_SERVER_HOSTING.md b/docs/rules/RULES_SERVER_HOSTING.md new file mode 100644 index 0000000..2b7ffa8 --- /dev/null +++ b/docs/rules/RULES_SERVER_HOSTING.md @@ -0,0 +1,31 @@ + + + +# 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. diff --git a/docs/rules/RULES_SESSION_PLANNING.md b/docs/rules/RULES_SESSION_PLANNING.md new file mode 100644 index 0000000..23419d4 --- /dev/null +++ b/docs/rules/RULES_SESSION_PLANNING.md @@ -0,0 +1,49 @@ + + + +# 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.