0.2.0-0-pre.7

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.