4.9 KiB
Prompt de démarrage — série 0.3.x POC plateforme et réseau
Base
Partir du tag stable v0.2.0 ou, avant publication, de la dernière candidate validée dont le contenu est strictement équivalent à la release.
Lire en priorité :
RULES.md;ROADMAP.md;CHANGELOG.md;docs/000-README.md;docs/rules/RULES_SESSION_PLANNING.md;docs/rules/RULES_COMMANDS.md;docs/rules/RULES_VALIDATION_MATRIX.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.
Objectif de session
La série 0.3.x est consacrée aux POC plateforme et réseau.
Elle ne développe pas encore Uroburas comme produit réel.
Snake est le jeu-sonde principal.
La session doit valider les frontières décidées en 0.2.0, mesurer les duplications, identifier les adapters/capabilities manquants et décider quels chemins techniques sont conservés avant 0.4.x.
Règle de cadrage
Commencer impérativement par 0.3.0-0-pre.1.
Cette première tranche doit :
- auditer la base stable ;
- vérifier les règles et scripts ;
- inventorier les POC réellement exécutables dans l'environnement courant ;
- dimensionner la série
0.3.x; - proposer le découpage en versions/sessions ;
- identifier les dépendances et commandes de validation ;
- signaler immédiatement tout objectif trop gros pour tenir dans une session.
Une version doit pouvoir être terminée dans une seule session.
Les deltas pre/alpha/beta/rc visent normalement 15 à 30 minutes de travail effectif.
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 seulement si l'environnement réel permet une validation :
- Windows SDL natif ;
- macOS SDL natif ;
- iOS SDL natif.
Ne pas simuler une validation plateforme avec un simple cross-build lorsque le smoke réel est requis.
POC réseau
Préparer un POC comparatif avant gel long terme du transport realtime :
- WebSocket /
tokio-tungstenite; - WebTransport / QUIC ;
- fallback automatique ;
- même protocole métier au-dessus des transports ;
- charge concurrente ;
- mémoire/connexion ;
- CPU ;
- p50/p95/p99 ;
- backpressure ;
- reconnect/resync ;
- mobilité réseau ;
- snapshots/deltas ;
- broadcast/interest management.
La simulation/game logic ne doit dépendre directement d'aucun type Tungstenite, QUIC ou WebTransport.
Web et assets
Conserver :
- Actix Web pour Web/API ;
- Maud pour HTML server-side ;
- Fluent/fluent-bundle pour localisation ;
- Lettre pour email ;
- auto-hébergement comme direction par défaut ;
- asset delivery séparé logiquement ;
- HTTP/2 baseline ;
- HTTP/3/QUIC à tester là où pertinent ;
- aucun CDN tiers obligatoire.
Debian Stable reste la cible opérationnelle préférée.
Ne pas figer HAProxy, nginx ou un autre edge avant POC/benchmark réel.
Build et validation
Les builds utilisent les outils natifs appropriés :
- Cargo ;
- Gradle ;
- Tauri CLI ;
- toolchains plateforme.
Les scripts Python sont autorisés pour audits, validations complémentaires et contrôles statiques, mais pas pour piloter le build.
L'utilisateur exécute les builds, tests unitaires, intégration et smoke tests demandés.
Le delta doit toujours lister les commandes exactes à exécuter.
Architecture à préserver
Ne pas transformer les POC en nouvelle architecture monolithique.
Maintenir les frontières :
game-specific
↓
game-systems
↓
technical capabilities
↓
engine kernel
et composer adapters/providers au niveau app/product.
Ne pas introduire une crate par concept sans frontière/API réellement justifiée.
Uroburas
Uroburas est réservé à la série 0.4.x.
Les POC 0.3.x doivent préparer ses fondations, notamment :
- grid/tilemap ;
- input Desktop/Mobile ;
- Web/WASM ;
- Tauri ;
- Android ;
- networking ;
- assets/content ;
- realtime transport.
Ils ne doivent pas implémenter les règles finales Uroburas sauf ce qui est strictement nécessaire à la sonde Snake.
Livraisons
Chaque tranche livre un delta ZIP immutable :
games-sasedev-<semver>-delta.zip
Les deltas précédents ne sont jamais enrichis sémantiquement.
Une erreur dans une tranche livrée se corrige par .fix.N.
Condition de fin de session
La session se termine lorsque la version ciblée par le sizing de pre.1 est entièrement développée, validée et livrée, avec :
- deltas ;
- validations ;
- documentation durable mise à jour ;
- ROADMAP/CHANGELOG selon le stade ;
- prompt suivant si la version clôt une session majeure.
Ne pas interrompre volontairement une version au milieu de son scope.