games/deltas/0.3.5/alpha.1.md

Delta 0.3.5-alpha.1

Base

Base autoritaire : archive fournie games-v0.3.4.zip, annoncée comme téléchargement ZIP du tag Gitea v0.3.4.

La version workspace de la base est :

0.3.4

L'archive taggée est utilisée telle quelle conformément à CMD-GIT-003 et CMD-GIT-004. L'absence de .git est normale et aucun fichier local absent du ZIP n'est inventé.

Objet

Ouvrir 0.3.5 par le gate obligatoire alpha.1 : auditer la stable, relire les preuves 0.3.4, rechercher l'écosystème WebTransport/QUIC actuel, sélectionner la stack POC primaire, challenger le contrat commun, fermer la stratégie TLS/fallback, ajouter les smoke tests nécessaires et redécouper la version afin que chaque delta reste normalement dans la cible 15 à 30 minutes.

Cette tranche n'ajoute aucune crate WebTransport, aucune dépendance QUIC/Rustls et aucun comportement runtime.

Version

La version workspace passe de :

0.3.4

à :

0.3.5-alpha.1

Conformément à VER-DOCFIX-002, une prerelease non-fix synchronise sa version technique même si le contenu de cette tranche est principalement documentaire.

Aucune version npm/Tauri/Android n'est modifiée : aucun package de ces plateformes n'est touché.

Audit de l'archive

Avant modification, l'environnement de génération a obtenu :

unzip -t : no errors
General Rust rule audit: clean
Rust export completeness audit: 0 candidate(s)
games.sasedev workspace audit: clean
Markdown table audit: clean (5 table(s), 263 file(s))
Distribution layout audit: clean (50 required path(s), 8 forbidden path(s) absent)

Inventaire indépendant :

437 fichiers dans le ZIP
267 fichiers Markdown extraits
68 fichiers Rust
18 Cargo.toml, dont le manifest racine
17 membres workspace
workspace.package.version = 0.3.4
0 symlink
0 chemin absolu/traversal
0 target/, node_modules/, build/ ou gen/android/ généré

Le log utilisateur fourni à l'ouverture de session confirme également :

cargo fmt --all -- --check : clean
audits Rust/Markdown/distribution : clean
cargo check --workspace : clean

Son audit Markdown annonce 279 fichiers contre 263 dans le scan de l'archive fournie. Le delta reste construit exclusivement depuis le ZIP autoritaire reçu et enregistre cet écart sans l'extrapoler.

Audit des règles et du workflow

La lecture du prompt 006, de RULES.md, des règles détaillées, des documents réseau/plateforme et des preuves 0.3.4 confirme :

• alpha.1 doit produire le plan actif avant développement lourd ;
• un delta vise environ 15 à 30 minutes de travail effectif ;
• une tranche clairement trop lourde doit être scindée avant exécution ;
• le full test workspace doit être rare et explicitement planifié ;
• une tranche de consolidation doit apparaître avant la candidate finale ;
• les builds/tests/smokes de validation sont attestés côté utilisateur ;
• les audits statiques peuvent être exécutés dans l'environnement de génération ;
• history/ n'est créé qu'après validation réelle d'un jalon ;
• CHANGELOG.md reste normalement silencieux avant la phase de consolidation/RC ;
• ROADMAP.md reste macroscopique et n'a pas besoin de changer pour ce cadrage.

Le forecast initial du prompt est fonctionnellement correct mais trop agrégé sur trois risques : backend natif, browser/TLS et fallback/mesures. Le plan actif les sépare et ajoute beta.2 comme consolidation explicite pré-RC.

Recherche WebTransport/QUIC actuelle

État vérifié au 2026-09-21 :

web-transport          0.12.0
web-transport-quinn    0.12.1
web-transport-wasm     0.6.0
wtransport             0.7.2

Constats structurants :

• web-transport fournit une façade native + WASM, avec Quinn côté natif et API navigateur côté WASM ;
• la documentation amont traite explicitement la différence Send/!Send entre natif et WASM, cohérente avec la frontière 0.3.4 ;
• le build WASM nécessite actuellement --cfg=web_sys_unstable_apis ;
• wtransport reste un candidat natif robuste et documenté, notamment pour certificats/hash W3C, mais ne fournit pas la même façade Rust WASM ;
• MDN classe WebTransport « Baseline 2026 » depuis mars 2026 sur navigateurs récents et impose un contexte sécurisé ;
• WebTransport/HTTP3 reste draft-ietf-webtrans-http3-16, Internet-Draft en WG Last Call, donc pas encore un RFC final.

L'étude détaillée est ajoutée dans :

docs/studies/026-V0_3_5_WEBTRANSPORT_QUIC_STACK_AUDIT.md

Stack primaire retenue

Le POC commence avec la famille :

web-transport 0.12.x

wtransport 0.7.x reste le candidat de repli si une exigence concrète échoue.

Aucune dépendance n'est ajoutée dans alpha.1; la résolution Cargo exacte et le choix des features crypto sont fermés dans alpha.2 avec cargo tree.

Contrat transport et framing

Le contrat game-realtime-transport-lib reste inchangé.

Pour préserver sa sémantique fiable/ordonnée/message-oriented, le backend WebTransport utilisera un stream bidirectionnel principal et un framing privé :

u32 big-endian length + payload bytes

La taille est bornée avant allocation/écriture. Ce framing n'est pas un wire codec métier et ne contient aucun joueur, room, tick ou version de protocole gameplay.

Les datagrams restent hors du contrat commun parce qu'ils sont non fiables/non ordonnés. Ils seront challengés séparément sans créer une capability commune prématurée.

TLS et navigateur

Le POC retient une stratégie de développement compatible avec les contraintes W3C :

• certificat self-signed court ;
• ECDSA P-256 ;
• validité inférieure à deux semaines ;
• hash SHA-256 épinglé côté client ;
• aucune clé privée durable dans le dépôt ;
• aucune désactivation permanente de validation TLS.

Le smoke navigateur est désormais une preuve explicitement planifiée et distincte du simple build WASM.

Fallback

Le fallback WebSocket est possédé par la composition/application du POC :

attempt WebTransport
    success -> WebTransport
    classified unavailable/establishment failure -> WebSocket

Le plan exige une branche WebTransport forcée, une branche fallback forcée et une erreur non-fallback visible. Aucun TransportManager ou registry n'est créé dans ce cadrage.

Forecast révisé

Le plan actif retient désormais :

0.3.5-alpha.1   audit + recherche + design + plan
0.3.5-alpha.2   crate/dépendances + établissement natif/TLS pinning
0.3.5-alpha.3   stream fiable + framing + contrat commun
0.3.5-alpha.4   robustesse/lifecycle/limites/timeouts
0.3.5-alpha.5   smoke WebTransport natif + graphe
0.3.5-alpha.6   chemin Rust WASM compilable
0.3.5-alpha.7   smoke navigateur + TLS local réel
0.3.5-alpha.8   fallback WebSocket au niveau composition
0.3.5-alpha.9   datagram POC conditionnel et isolé
0.3.5-alpha.10  mesures WebSocket vs WebTransport
0.3.5-beta.1    validation large + full workspace + smokes
0.3.5-beta.2    consolidation durable + conclusion + prompt 0.3.6
0.3.5-rc.1      candidate gelée + gates de publication
0.3.5           promotion stable mécanique

Les numéros restent souples : une tranche peut être fusionnée si elle devient micro-scopique ou scindée avant exécution si elle dépasse clairement 30 minutes.

Le point important est que alpha.6 et alpha.7 sont séparées : compiler le client Rust WASM et faire fonctionner un navigateur avec certificat/UDP/serveur sont deux risques différents. De même, la consolidation n'est plus reportée dans la RC.

Full tests et smoke tests planifiés

cargo test --workspace --all-targets --all-features est explicitement réservé à :

0.3.5-beta.1
0.3.5-rc.1

sauf changement transverse inattendu imposant une gate supplémentaire.

Smokes prévus :

cargo run -p game-realtime-websocket-smoke
cargo run -p game-realtime-webtransport-smoke
browser/WASM WebTransport smoke (workflow fixé en alpha.7)
fallback branch smoke/proof (intégré à un launcher existant si possible)

Le benchmark reste un outil borné, pas une infrastructure permanente disproportionnée.

Fichiers

Ajoutés :

deltas/0.3.5/alpha.1.md
docs/plans/005-V0_3_5_WEBTRANSPORT_QUIC_POC_PLAN.md
docs/studies/026-V0_3_5_WEBTRANSPORT_QUIC_STACK_AUDIT.md

Modifiés :

Cargo.toml
README.md
docs/000-README.md
docs/plans/000-README.md
docs/studies/000-README.md

Inchangés volontairement :

ROADMAP.md
CHANGELOG.md
prompts/006-V0_3_5_START_PROMPT.md
crates/**
Android/**
Web/**

Validations exécutées dans l'environnement de génération

Après constitution de l'état livré, le générateur a exécuté uniquement les audits statiques autorisés :

General Rust rule audit: clean
Rust export completeness audit: 0 candidate(s)
games.sasedev workspace audit: clean
Markdown table audit: clean (5 table(s), 266 file(s))
Distribution layout audit: clean (50 required path(s), 8 forbidden path(s) absent)
alpha.1 targeted consistency: clean

Le contrôle ciblé confirme en particulier workspace.package.version = 0.3.5-alpha.1, la présence du plan/étude/delta, l'absence volontaire de history/0.3.5/alpha.1.md avant validation et l'absence d'entrée 0.3.5-alpha.1 dans CHANGELOG.md.

Aucun cargo check, Clippy, test, benchmark ou smoke post-delta n'est attribué au générateur.

Validation utilisateur demandée

Cargo.toml change uniquement pour la version workspace et les fichiers Markdown changent. Aucune dépendance ni source Rust n'est encore ajoutée.

Depuis la racine :

cargo fmt --all -- --check

python3 scripts/audit_rust_workspace_rules.py
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

cargo check --workspace

Clippy et tests ne sont pas requis par cérémonie dans alpha.1 car aucun code Rust, feature ou dépendance fonctionnelle n'est modifié. Le log d'ouverture a déjà confirmé cargo check --workspace propre sur la stable 0.3.4; la commande ci-dessus valide la synchronisation de version du nouvel état.

Suite après validation

Si cette gate est propre, alpha.2 :

• crée history/0.3.5/alpha.1.md à partir de la sortie réelle ;
• ajoute game-realtime-webtransport-lib ;
• introduit la stack primaire avec features minimales ;
• ferme la configuration TLS/hash et l'établissement natif ;
• ne cherche pas encore à absorber framing, robustesse, browser smoke et fallback dans la même tranche.

Un échec du cadrage, des audits ou de la synchronisation de version produit d'abord 0.3.5-alpha.1.fix.N.