# Roadmap ## Légende - `( )` — planned ; - `(x)` — completed ; - `(d)` — deferred ; - `(c)` — cancelled. Les marqueurs qualifient une ligne de scope. Une même version peut donc apparaître plusieurs fois si une partie est livrée, une partie reportée et une autre annulée. ## 0.1.0 — Fondation POC - (x) `0.1.0` — squelette du workspace, règles, architecture, versions et assets. - (x) `0.1.0` — moteur V1 POC, boucle de jeu, input abstrait et rendu SDL3 minimal. - (x) `0.1.0` — Reflex et Snake jouables comme POC de réutilisation. - (x) `0.1.0` — Desktop SDL3 natif, Android SDL3/Java/JNI et Tauri/WebView/WASM Reflex. - (x) `0.1.0` — tracing commun, provenance runtime, packaging et validation multi-appareils. Le détail historique des prereleases `0.1.0-*` reste dans `deltas/0.1.0/` et `history/0.1.0/`. ## 0.2.0 — Conception du framework modulaire - (x) `0.2.0` — fixer la gouvernance documentaire, la nomenclature et le cycle de maturation des idées et décisions. - (x) `0.2.0` — inventorier et réserver les capabilities déjà justifiées sans les implémenter prématurément. - (x) `0.2.0` — définir les couches, les dépendances autorisées et la frontière entre kernel, capability, plateforme, provider, système de jeu et service. - (x) `0.2.0` — établir la matrice plateformes et les archétypes de jeux utilisés pour challenger l'architecture. - (x) `0.2.0` — retenir la composition Rust statique comme direction de référence. - (d) `0.2.0` — figer un manifest produit/jeu et l'architecture physique définitive des crates → target TBD après observation des POC `0.3.x`. - (x) `0.2.0` — définir la trajectoire d'implémentation progressive `0.3.x` POC puis `0.4.x` Uroburas. - (x) `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. - (x) `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. - (x) `0.2.0` — préparer une trajectoire `0.3.x` dédiée aux POC plateforme/réseau avec Snake comme jeu-sonde. - (x) `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. ## 0.3.0 — Baseline Snake + premier POC Web direct - (x) `0.3.0` — nettoyer la baseline Snake sans introduire de logique Uroburas et maintenir le runner Desktop SDL3 fonctionnel. - (x) `0.3.0` — produire une adaptation WASM dédiée à Snake sans déplacer le gameplay hors de `game-snake-poc`. - (x) `0.3.0` — réaliser un POC navigateur direct Snake couvrant clavier, boutons directionnels tactiles, resize, lifecycle, logging, assets et provenance runtime. - (x) `0.3.0` — utiliser uniquement Cargo, `wasm-bindgen` et Vite/npm pour le chemin de build Web ; aucun script Python ne pilote ce build. - (x) `0.3.0` — documenter les duplications observées et conserver les adapters Web/WASM spécifiques tant qu’un second consommateur ne justifie pas une extraction commune. ## Série 0.3.x — trajectoire actuelle après 0.3.0 - ( ) `0.3.1` — second host Snake : Tauri Android, en réutilisant la baseline Web/WASM validée et en remplaçant toute orchestration Python du chemin touché. - ( ) `0.3.2` — Tauri Desktop + Snake et factorisation WebView uniquement lorsque deux consommateurs réels justifient l'extraction. - ( ) `0.3.3` — Android SDL natif multi-ABI avec Cargo/Gradle natifs, sans script Python de build. - ( ) `0.3.4` — API de transport realtime + WebSocket/tokio-tungstenite baseline, sans serveur Uroburas Mode 3. - ( ) `0.3.5` — POC WebTransport/QUIC sur le même protocole, avec comparaison mesurée et fallback WebSocket. - ( ) `0.3.6` — consolidation des POC plateforme/réseau et préparation de la baseline `0.4.x`. La numérotation `0.3.1+` reste révisable à partir des résultats réels ; les lignes ci-dessus décrivent le planning actuel, pas une obligation de créer des versions artificielles.