0.3.3-3-rc.1.fix.1

prompts/005-V0_3_4_START_PROMPT.md

@@ -1,5 +1,5 @@
 <!-- file: prompts/005-V0_3_4_START_PROMPT.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Prompt de démarrage `0.3.4` — transport realtime et baseline WebSocket
 
@@ -249,19 +249,197 @@ Un échec de `alpha.1` produit `alpha.1.fix.1`, pas un retour vers l'ancienne co
 
 ## 12. Forecast initial non contraignant
 
-`alpha.1` doit le réviser à partir de l'audit, mais la direction initiale est :
+Ce forecast est une **hypothèse de travail initiale**, pas un contrat de numérotation. Il doit être relu et réécrit dans le plan `0.3.4` pendant `alpha.1` à partir des constats réels de la baseline, des dépendances actuelles, des tests possibles et du sizing obtenu.
+
+Règles de lecture du forecast :
+
+- les jalons ci-dessous donnent un **ordre logique probable**, pas une obligation de produire exactement ce nombre de prereleases ;
+- une tranche peut être fusionnée avec la suivante si son contenu devient trivial et reste validable comme une unité cohérente ;
+- une tranche doit être scindée si elle dépasse le budget habituel de 15–30 minutes, mélange plusieurs responsabilités indépendantes ou nécessite des validations hétérogènes ;
+- tout défaut découvert après livraison d'un jalon reste dans `<jalon>.fix.N` tant que son objectif fonctionnel n'est pas rouvert ;
+- aucune tranche ne doit être créée uniquement pour respecter la séquence ci-dessous ;
+- si l'audit `alpha.1` montre qu'une partie relève plutôt de `0.3.5` ou d'une nouvelle version, la reporter avant développement lourd ;
+- le plan actif sous `docs/plans/` devient l'autorité prévisionnelle après `alpha.1` et peut diverger de ce forecast sans réécrire ce prompt historique.
+
+### `0.3.4-alpha.1` — migration de gouvernance + audit + contrat transport
+
+Objectif probable : fermer tout le cadrage avant de figer une API réseau.
+
+Travail attendu :
+
+- appliquer la nouvelle nomenclature aux **règles prospectives uniquement** ;
+- adapter les audits qui reconnaissent les prereleases sans modifier l'historique `0.1.x`–`0.3.3` ;
+- vérifier que la baseline stable `0.3.3` est propre ;
+- relire les études réseau et confronter leurs hypothèses au code actuel ;
+- vérifier les versions actuelles de Tokio, `tokio-tungstenite`, `tungstenite`, TLS éventuel et autres dépendances réellement nécessaires ;
+- décider si l'API durable vit dans une crate dédiée, une crate existante ou plusieurs crates ;
+- définir les responsabilités client/server communes sans créer un framework abstrait prématuré ;
+- définir le modèle d'erreur, fermeture, cancellation, timeout, backpressure et limites ;
+- décider le codec de **preuve** initial sans le présenter comme protocole gameplay final ;
+- définir la matrice de tests et les gates de chaque tranche ;
+- créer `docs/plans/004-V0_3_4_REALTIME_TRANSPORT_WEBSOCKET_PLAN.md` avec un forecast révisé jusqu'à stable.
+
+Livrables probables : gouvernance migrée, étude/résultats d'audit si nécessaire, plan actif, ownership décidé, premier contrat API suffisamment précis pour démarrer l'implémentation suivante.
+
+Gate de sortie : aucune ambiguïté majeure sur l'ownership ou le sens des dépendances ; scope `0.3.4` dimensionné pour tenir dans la session ; validations futures identifiées ; aucune dépendance réseau introduite dans les crates gameplay.
+
+### `0.3.4-alpha.2` — API de transport async minimale
+
+Objectif probable : introduire la frontière transport indépendamment de WebSocket.
+
+Travail candidat :
+
+- types de connexion/endpoint strictement nécessaires ;
+- contrat async send/receive ou équivalent retenu par l'audit ;
+- fermeture locale/distante explicite ;
+- cancellation propre ;
+- erreurs typées ;
+- taille/limites élémentaires des messages ;
+- tests unitaires du contrat sans réseau réel lorsque possible ;
+- façade `lib.rs` et documentation publique conformes aux règles du dépôt.
+
+À éviter : codec métier complet, session gameplay, heartbeat produit définitif, simulation authoritative ou abstraction multi-transport sophistiquée.
+
+Gate de sortie : API consommable par un backend WebSocket futur et testable indépendamment de celui-ci ; aucun couplage direct au gameplay.
+
+### `0.3.4-alpha.3` — backend WebSocket `tokio-tungstenite`
+
+Objectif probable : fournir la première implémentation concrète de la frontière transport.
+
+Travail candidat :
+
+- connect/listen WebSocket selon l'ownership retenu ;
+- mapping frames ↔ messages du transport ;
+- fermeture WebSocket propre ;
+- propagation des erreurs ;
+- timeouts/cancellation minimum nécessaires ;
+- tracing du domaine transport ;
+- test loopback localhost déterministe client ↔ serveur ;
+- absence de dépendance à Axum si elle n'apporte rien à la preuve transport.
+
+Gate de sortie : round-trip local reproductible, fermeture des deux côtés vérifiée, aucune tâche async orpheline connue, erreurs observables.
+
+### `0.3.4-alpha.4` — robustesse : limites, backpressure et lifecycle
+
+Cette tranche est **conditionnelle** : la fusion avec `alpha.3` est préférable si les mécanismes restent petits et cohérents.
+
+Travail candidat :
+
+- bornes de taille et files internes ;
+- comportement explicite en cas de consommateur lent ;
+- timeout de connexion/lecture/écriture uniquement là où il est justifié ;
+- comportement sur fermeture distante, connexion interrompue et cancellation ;
+- vérification qu'aucune boucle ne spin ou ne masque une erreur ;
+- tests négatifs ciblés ;
+- métriques/tracing minimaux permettant de diagnostiquer le transport sans mélanger session/sync/simulation.
+
+Gate de sortie : les principaux modes d'échec du transport sont déterministes, bornés et testés.
+
+### `0.3.4-alpha.5` — intégration consommateur/démo minimale, si utile
+
+Cette tranche n'existe que si une preuve supplémentaire apporte une valeur réelle après `alpha.3/alpha.4`.
+
+Candidats acceptables :
+
+- petit demo/CLI client-server ;
+- intégration à un launcher de POC sans logique gameplay réseau ;
+- harness de test permettant de mesurer connexion, échange et fermeture.
+
+Ne pas créer d'application ou de crate uniquement pour « montrer » l'API si les tests loopback prouvent déjà tout le contrat utile.
+
+Gate de sortie : preuve reproductible du chemin public du transport, sans introduire la session gameplay.
+
+### `0.3.4-alpha.N` — consolidation de développement
+
+Avant beta, réserver explicitement une tranche de consolidation si les alpha précédentes ont réellement introduit plusieurs composants.
+
+Cette tranche peut couvrir :
+
+- réconciliation docs/API/README/USAGE réellement nécessaires ;
+- suppression de duplication ou dette née pendant les alpha, uniquement si bornée ;
+- audit du graphe de dépendances ;
+- vérification que `transport -> wire codec -> session -> sync -> simulation` reste respecté ;
+- confirmation de ce qui est volontairement reporté à `0.3.5` ou `0.4.x` ;
+- préparation d'une gate beta large et reproductible.
+
+Elle peut être fusionnée avec la dernière alpha fonctionnelle si aucune consolidation autonome n'est nécessaire.
+
+### `0.3.4-beta.1` — validation large
+
+Objectif probable : valider le produit de `0.3.4` comme baseline transport complète, pas ajouter des fonctionnalités.
+
+Gate candidate :
+
+- audits dépôt applicables ;
+- format/check/Clippy workspace ;
+- tests ciblés des nouvelles crates/modules ;
+- test workspace complet si le plan le confirme ;
+- tests loopback client/server ;
+- tests de fermeture/cancellation/backpressure retenus ;
+- éventuel demo/CLI reproductible si créé ;
+- vérification du graphe de dépendances ;
+- confirmation qu'aucune crate gameplay ne dépend du backend WebSocket ;
+- documentation opérateur/API cohérente avec le comportement réel.
+
+Un défaut trouvé ici produit `beta.1.fix.N` tant que le périmètre reste fermé. Une capacité réseau manquante importante impose de revenir à une alpha suivante au lieu de maquiller une nouvelle fonctionnalité en fix beta.
+
+### `0.3.4-rc.1` — candidate gelée
+
+Objectif probable : candidate de publication sans nouveau comportement.
+
+Travail attendu :
+
+- scope fonctionnel gelé ;
+- revalidation des gates importantes de beta ;
+- consolidation `CHANGELOG.md` ;
+- état macro `ROADMAP.md` cohérent ;
+- historique applicable ;
+- documentation finale de l'API transport et de la baseline WebSocket ;
+- préparation/vérification du prompt `0.3.5` WebTransport/QUIC avec transmission précise de la baseline WebSocket à comparer ;
+- aucune optimisation ou abstraction nouvelle sans défaut de release démontré.
+
+Les correctifs strictement nécessaires restent sous `rc.1.fix.N`. Toute réouverture fonctionnelle revient à une phase adaptée avant une nouvelle RC.
+
+### `0.3.4` — promotion stable mécanique
+
+La stable doit normalement se limiter à :
+
+- version stable ;
+- historique RC ;
+- changelog stable ;
+- clôture du plan ;
+- statut roadmap si requis ;
+- delta/release final ;
+- ajustements strictement mécaniques du prompt suivant si une référence de baseline devient certaine.
+
+Aucune nouvelle API, dépendance ou décision architecturale ne doit apparaître pour la première fois dans la stable.
+
+### Branches de redécoupage explicitement admises
+
+Le forecast initial doit être révisé sans hésitation dans les cas suivants :
 
 ```text
-alpha.1  migration nomenclature + audit + requirements + plan + contrat minimal
-alpha.2  API transport async + types/erreurs/tests unitaires
-alpha.3  backend WebSocket tokio-tungstenite + loopback
-alpha.4  intégration/diagnostics/backpressure/fermeture propre
-beta.1   validation large et POC reproductible
-rc.1     gel, documentation finale, prompt suivant
-0.3.4    promotion mécanique
+API transport + backend WebSocket restent très petits
+    -> fusion possible alpha.2 + alpha.3
+
+backpressure/lifecycle nécessitent un travail autonome
+    -> conserver alpha.4 ou la scinder
+
+le demo n'apporte aucune preuve supplémentaire
+    -> supprimer alpha.5
+
+un vrai wire codec réutilisable devient indispensable
+    -> décider en alpha.1 s'il appartient encore à 0.3.4
+       ou s'il mérite une version distincte
+
+l'abstraction WebTransport exige déjà des choix QUIC
+    -> reporter à 0.3.5 ; ne pas polluer 0.3.4
+
+le serveur de jeu/session protocol commence à apparaître
+    -> arrêter et reporter au scope Uroburas approprié
 ```
 
-Les numéros peuvent être regroupés ou scindés ; aucune phase ne doit être créée par cérémonial.
+Le critère n'est donc pas « suivre tous les numéros », mais obtenir à la fin de `0.3.4` une frontière de transport claire, un backend WebSocket reproductible et suffisamment robuste pour devenir la baseline comparative de `0.3.5`.
 
 ## 13. Condition de fin de session