games/prompts/002-V0_3_X_START_PROMPT.md

Prompt de démarrage — 0.3.0 / série 0.3.x POC plateforme et réseau

Base

Partir du tag stable v0.2.0.

Avant toute modification :

1. lire RULES.md, ROADMAP.md, CHANGELOG.md et docs/000-README.md ;
2. lire les règles de session, commandes et validation ;
3. lire les architectures consolidées 012 à 016 ;
4. lorsque la base est une archive téléchargée depuis le tag fourni, la traiter comme snapshot autoritaire sans exiger .git ; vérifier sa cohérence workspace/version ;
5. exécuter les audits applicables à la base ;
6. confirmer la version workspace avant 0.3.0-0-pre.1.

Documents prioritaires :

• docs/rules/RULES_SESSION_PLANNING.md ;
• docs/rules/RULES_COMMANDS.md ;
• docs/rules/RULES_VALIDATION_MATRIX.md ;
• docs/rules/RULES_SERVER_HOSTING.md ;
• docs/architecture/012-MODULAR_LAYERING_AND_OWNERSHIP.md ;
• docs/architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md ;
• docs/architecture/014-UROBURAS_TARGET_ARCHITECTURE.md ;
• docs/architecture/015-PLATFORM_POC_ARCHITECTURE.md ;
• docs/architecture/016-V0_2_0_CONSOLIDATED_BASELINE.md.

Mission de 0.3.0

0.3.0 ouvre la série de POC.

Son objectif n'est pas de commencer Uroburas, mais de rendre la base Snake suffisamment propre pour servir de sonde multiplateforme et de réaliser un premier POC de bout en bout sans duplication incontrôlée.

Résultat attendu :

• baseline Snake réutilisable ;
• inventaire des adapters/capabilities réellement nécessaires ;
• premier chemin POC exécuté de bout en bout ;
• procédures de build natives documentées ;
• validations reproductibles ;
• décision explicite sur ce qui est extrait, conservé localement ou reporté ;
• version suivante planifiée à partir des résultats réels.

Contraintes gelées

Préserver :

game-specific
    ↓
game-systems
    ↓
technical capabilities
    ↓
engine kernel

Les adapters/providers sont composés au niveau app/product.

Snake est le jeu-sonde principal de 0.3.x.

Uroburas reste réservé à 0.4.x.

Les builds utilisent Cargo, Gradle, Tauri CLI ou la toolchain native appropriée.

Python reste autorisé pour audits et validations complémentaires, jamais comme orchestrateur de build.

L'utilisateur exécute les builds, tests unitaires/intégration et smoke tests demandés.

0.3.0-0-pre.1 — cadrage obligatoire

Cette tranche précède toute implémentation lourde.

Elle doit couvrir :

Audit de la base

• crates Snake existantes ;
• Desktop SDL ;
• Android SDL/Java/JNI ;
• Tauri/WASM Reflex existant comme référence technique ;
• abstractions déjà réutilisables ;
• duplications ;
• scripts/outils ;
• procédures de build réellement disponibles ;
• contraintes de l'environnement courant.

Requirements POC

Identifier les besoins réels pour Snake :

• input clavier ;
• virtual directional buttons tactiles ;
• viewport/resize ;
• lifecycle ;
• runtime provenance ;
• assets ;
• logging ;
• WASM bridge ;
• Tauri bridge ;
• Android packaging ;
• multi-ABI.

Sizing

Le forecast ci-dessous est une hypothèse.

pre.1 doit explicitement :

• le confirmer ou le corriger ;
• fusionner les tranches trop petites ;
• scinder les tranches trop lourdes ;
• reporter ce qui ne tient pas dans 0.3.0 ;
• vérifier que 0.3.0 peut être terminé dans une seule session.

Si ce n'est pas réaliste, réduire immédiatement le scope de 0.3.0.

Forecast souple de 0.3.0

0-pre.1 — audit / brainstorming / requirements / sizing

Objectif :

• audit de la baseline ;
• requirements ;
• graphe de dépendances ;
• choix du premier POC ;
• plan actif sous docs/plans/ avec forecast corrigé ;
• commandes prévues ;
• critères de sortie.

Pas de gros développement avant fermeture de ce cadrage.

0-pre.2 — Snake portability baseline

Objectif candidat :

• corriger les dépendances trop spécifiques à un launcher ;
• stabiliser les semantic actions ;
• vérifier gameplay vs platform input ;
• préparer plusieurs hosts ;
• ne pas ajouter de logique Uroburas.

Validation candidate :

• tests ciblés Snake ;
• Desktop SDL toujours fonctionnel ;
• dependency audit ciblé.

0-pre.3 — adaptation Snake WASM

Décision issue de pre.1 :

• introduire la crate/adaptation WASM minimale de Snake ;
• générer les bindings avec wasm-bindgen ;
• conserver le gameplay dans game-snake-poc ;
• ne pas généraliser avant qu'un second consommateur ne le justifie.

0-pre.4 — frontend Web/Vite + shell Bootstrap 5

Décision issue de pre.1 : le premier host est Web navigateur direct + Snake.

Le frontend doit fournir :

• un document HTML responsive piloté par Vite/TypeScript ;
• Bootstrap 5 comme baseline de présentation/layout et pour les contrôles UI ;
• un Canvas dédié au rendu du jeu ;
• clavier et boutons directionnels tactiles ;
• états de chargement/erreur utiles au POC.

Le framework HTML/CSS reste strictement côté frontend : Rust/WASM conserve le gameplay et l'état du jeu.

0-pre.5 — intégration plateforme complète

Fermer les besoins de bout en bout du POC :

• resize/lifecycle ;
• assets ;
• logging ;
• runtime provenance ;
• non-régression du runner Desktop SDL3.

Compiler seul ne suffit pas : le smoke navigateur fait partie de la validation.

0-pre.6 — correction/extraction conditionnelle

Créer seulement si les tranches précédentes révèlent un besoin réel :

• supprimer duplication avérée ;
• corriger frontières mal placées ;
• ajouter tests nécessaires ;
• documenter ce qui reste spécifique.

Sinon, omettre cette tranche.

2-beta.1 — validation large

Objectif :

• feature-complete pour le scope réel de 0.3.0 ;
• builds/tests applicables ;
• smoke du POC ;
• documentation des commandes ;
• vérification qu'aucune abstraction spéculative n'a été ajoutée.

2-beta.2 — consolidation documentaire et transmission

Responsabilité obligatoire, même si sa numérotation finale glisse :

• réconcilier la documentation durable avec l'état validé ;
• mettre à jour CHANGELOG.md et ROADMAP.md ;
• mettre à jour l'historique applicable ;
• réconcilier le plan avec les deltas réellement livrés ;
• préparer et vérifier le prompt de la version/session suivante.

Cette tranche consolide la documentation ; elle ne reporte pas à la fin la documentation spécifique qui devait accompagner les tranches fonctionnelles.

3-rc.1 — candidate

Scope gelé.

Autorisé :

• bugfix ;
• tests ;
• documentation ;
• packaging ;
• compatibilité.

Interdit :

• nouveau POC ;
• nouvelle capability non nécessaire ;
• changement d'objectif.

0.3.0

Release mécanique après validation RC.

Forecast initial de la série 0.3.x

Ce forecast est indicatif et doit évoluer avec les résultats.

0.3.0 — baseline POC + premier host

• nettoyer la sonde Snake ;
• éprouver une première composition multiplateforme ;
• premier POC de bout en bout.

0.3.1 — second host Snake

Candidat :

• Web direct si Tauri Android a été fait en 0.3.0 ;
• Tauri Android si Web direct a été fait en 0.3.0.

But : vérifier que les abstractions du premier POC ne sont pas sur-spécialisées.

0.3.2 — Tauri Desktop + Snake / factorisation WebView

• éprouver la réutilisation bridge/frontend ;
• factoriser uniquement ce que les POC justifient.

0.3.3 — Android multi-ABI natif

• Cargo/Gradle réels ;
• ARM64 ;
• x86_64 ;
• Debug/Release selon scope ;
• procédures reproductibles ;
• aucun script Python de build.

0.3.4 — realtime transport API + WebSocket baseline

• API de transport indépendante ;
• tokio-tungstenite baseline ;
• codec/protocol/session séparés ;
• harness de test ;
• aucun serveur Uroburas Mode 3.

0.3.5 — WebTransport/QUIC POC

• implémentation candidate ;
• fallback WebSocket ;
• même protocole ;
• comparaison charge/latence/mémoire/backpressure/reconnect ;
• décision conserver/report/rejeter.

0.3.6 — consolidation POC

• réconcilier résultats plateforme/réseau ;
• promouvoir décisions validées ;
• retirer les abstractions non justifiées ;
• préparer la baseline 0.4.x.

La numérotation 0.3.1+ n'est pas contractuelle.

Une version peut être fusionnée, scindée, reportée ou supprimée.

Dépendances entre versions

Ne pas commencer un POC parce qu'il figure dans le forecast.

Avant ouverture :

• version précédente validée ;
• abstractions produites comprises ;
• nouvelle question technique encore ouverte ;
• environnement réel disponible.

Windows/macOS/iOS SDL ne sont ouverts qu'avec un environnement permettant une validation réelle.

POC réseau

Architecture à préserver :

realtime transport
    ↓
wire codec
    ↓
session protocol
    ↓
sync/reconnect
    ↓
consumer

Candidats :

WebSocket
    tokio-tungstenite

WebTransport
    QUIC

WebSocket reste baseline/fallback.

WebTransport n'est conservé que si les mesures justifient sa complexité.

Mesures candidates :

• connexions concurrentes ;
• mémoire/connexion ;
• CPU ;
• messages/s ;
• bytes/s ;
• p50/p95/p99 ;
• backpressure ;
• perte réseau ;
• reconnect ;
• changement réseau ;
• snapshots/deltas.

Web / serveur / auto-hébergement

Références :

Tokio
Actix Web
Maud
Fluent / fluent-bundle
Lettre

Tonic/gRPC reste conditionnel aux besoins server-to-server.

Asset delivery :

self-hosted
HTTP/2 baseline
HTTP/3/QUIC candidat

Debian Stable reste la cible opérationnelle préférée.

Ne pas figer HAProxy, nginx ou autre edge sans POC et vérification de maturité/disponibilité sur Debian Stable.

Validation

Appliquer les gates proportionnelles au scope.

Toujours distinguer :

• validations exécutées ;
• validations à exécuter par l'utilisateur ;
• validations impossibles dans l'environnement courant.

Les commandes doivent être copiables depuis le delta.

Préférer les validations ciblées pendant les tranches ; réserver les gates larges aux frontières beta/RC.

Livraison

Chaque tranche produit :

games-sasedev-<semver>-delta.zip

Les deltas sont immuables.

Une correction s'effectue via .fix.N.

Les changements réels incrémentent les en-têtes version.

Discipline de session

Le forecast sert à estimer et ordonner, pas à imposer des prereleases inutiles.

Une version doit être terminée dans une seule session.

Si un objectif devient trop gros :

• fermer proprement le scope courant ;
• reporter explicitement le reste ;
• ouvrir une version suivante.

Condition de fin de 0.3.0

0.3.0 est terminée lorsque :

• le scope corrigé en pre.1 est intégralement livré ;
• le premier POC choisi fonctionne réellement sur son host ;
• les builds utilisent les outils natifs ;
• Snake reste séparé des adapters ;
• les abstractions extraites sont justifiées ;
• tests/gates applicables validés ;
• documentation durable à jour ;
• ROADMAP/CHANGELOG mis à jour selon le stade ;
• version suivante préparée à partir des résultats réels.