0.2.0-0-pre.7

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.