182 lines
4.9 KiB
Markdown
182 lines
4.9 KiB
Markdown
<!-- file: prompts/002-V0_3_X_START_PROMPT.md -->
|
|
<!-- version: 1 -->
|
|
|
|
# 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 :
|
|
|
|
1. Tauri Android + Snake ;
|
|
2. Web navigateur direct + Snake ;
|
|
3. Tauri Desktop + Snake ;
|
|
4. 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 :
|
|
|
|
```text
|
|
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 :
|
|
|
|
```text
|
|
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.
|