diff --git a/deltas/0.3.3/3-rc.1.fix.1.md b/deltas/0.3.3/3-rc.1.fix.1.md new file mode 100644 index 0000000..b3814c5 --- /dev/null +++ b/deltas/0.3.3/3-rc.1.fix.1.md @@ -0,0 +1,82 @@ + + + +# Delta 0.3.3-3-rc.1.fix.1 + +## Base requise + +`0.3.3-3-rc.1`. + +## Nature du correctif + +Correctif strictement documentaire de la candidate RC. Il ne modifie ni le runtime, ni le pipeline Android, ni Cargo, ni la version technique du workspace. + +Conformément à `VER-DOCFIX-001`, `workspace.package.version` reste donc : + +```text +0.3.3-3-rc.1 +``` + +L'identité `0.3.3-3-rc.1.fix.1` est portée par le présent delta et son archive. + +## Défaut corrigé + +Le prompt de reprise `prompts/005-V0_3_4_START_PROMPT.md` était fonctionnel mais trop pauvre comme transmission autonome de session, particulièrement dans son forecast initial : + +- chaque tranche n'expliquait pas suffisamment son intention ; +- les livrables probables et critères de sortie n'étaient pas explicités ; +- les points naturels de fusion/scission n'étaient pas indiqués ; +- le rôle conditionnel d'une tranche de robustesse ou d'un demo n'était pas assez clair ; +- la séparation entre forecast initial et plan actif produit par `alpha.1` pouvait être mieux verrouillée ; +- la progression vers beta, RC et stable manquait de critères opératoires. + +## Changements + +`prompts/005-V0_3_4_START_PROMPT.md` passe en version documentaire 2 et développe son forecast non contraignant avec : + +- règles explicites de lecture et de révision du forecast ; +- `alpha.1` détaillée pour la migration de gouvernance, l'audit, le sizing et le contrat transport ; +- `alpha.2` pour l'API async minimale ; +- `alpha.3` pour le backend WebSocket `tokio-tungstenite` et le loopback ; +- `alpha.4` conditionnelle pour robustesse, limites, backpressure et lifecycle ; +- `alpha.5` conditionnelle pour une preuve consommateur/demo uniquement si elle apporte une valeur réelle ; +- une tranche de consolidation de développement explicitement fusionnable ; +- critères de beta large, RC gelée et promotion stable mécanique ; +- branches explicites de redécoupage lorsque les résultats d'`alpha.1` invalident le découpage initial. + +Le forecast reste volontairement prévisionnel : `0.3.4-alpha.1` doit le réviser dans `docs/plans/004-V0_3_4_REALTIME_TRANSPORT_WEBSOCKET_PLAN.md`, qui devient ensuite l'autorité prévisionnelle active. + +## Immutabilité historique + +Ce fix n'applique toujours pas la nouvelle convention aux versions déjà livrées. Aucun fichier historique `deltas/`, `history/`, ancien prompt ou ancienne entrée de changelog n'est renommé ou réécrit pour harmoniser sa nomenclature. + +La migration effective des règles prospectives vers : + +```text +X.Y.Z-alpha.N +X.Y.Z-alpha.N.fix.M +X.Y.Z-beta.N +X.Y.Z-beta.N.fix.M +X.Y.Z-rc.N +X.Y.Z-rc.N.fix.M +X.Y.Z +``` + +reste la première action de la prochaine session `0.3.4`. + +## État RC connu avant ce fix + +La validation utilisateur de `0.3.3-3-rc.1` a déjà confirmé les audits, Cargo check/Clippy/tests workspace, rebuild Android Debug/Release quatre ABI, présence des quatre ABI dans APK/AAB et `zipalign -P 16` sur les deux APK. + +Le présent correctif documentaire n'attribue pas de validation future à la RC et ne crée pas `history/0.3.3/3-rc.1.md` avant acceptation complète du jalon. + +## Validation du fix + +Comme seuls des fichiers Markdown sont ajoutés/modifiés, exécuter : + +```bash +python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates Android Web deltas history +python3 scripts/audit_distribution_layout.py +``` + +Une fois ce contenu accepté, reprendre la matrice RC là où elle s'était arrêtée. Le correctif ne nécessite aucun rebuild Cargo/Gradle supplémentaire par lui-même. diff --git a/prompts/005-V0_3_4_START_PROMPT.md b/prompts/005-V0_3_4_START_PROMPT.md index 2916966..05f4a6f 100644 --- a/prompts/005-V0_3_4_START_PROMPT.md +++ b/prompts/005-V0_3_4_START_PROMPT.md @@ -1,5 +1,5 @@ - + # 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 `.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