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. vérifier l'état Git/workspace ;
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 ;
• 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 — adapters/capabilities minimaux

Objectif candidat :

• extraire uniquement ce que le premier POC prouve nécessaire ;
• éviter duplication bridge/frontend ;
• préparer input/resize/lifecycle/runtime provenance ;
• documenter les duplications provisoires.

Cette tranche peut être fusionnée avec pre.2.

0-pre.4 — premier POC de bout en bout

Préférence initiale :

Tauri Android + Snake

Alternative si pre.1 la juge plus rationnelle :

Web navigateur direct + Snake

Le POC doit couvrir :

• build avec outil natif ;
• lancement ;
• rendu ;
• contrôles ;
• resize/orientation selon host ;
• lifecycle ;
• logging ;
• assets ;
• runtime provenance.

Compiler seul ne suffit pas.

0-pre.5 — corrections/généralisation issues du POC

Créer seulement si le POC révèle 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.

1-alpha.1 — intégration éventuelle

À utiliser seulement si le volume de code nouveau justifie une phase distincte.

Objectif :

• stabiliser interfaces Snake/capabilities/host ;
• fermer les défauts structurels ;
• aucun nouveau scope.

Sinon, ne pas créer cette tranche artificiellement.

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.

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.