games/deltas/0.3.4/alpha.1.md

Delta 0.3.4-alpha.1

Base

Base autoritaire : archive fournie games-v0.3.3.zip, téléchargée depuis le lien ZIP du tag Gitea v0.3.3.

La version workspace de la base est 0.3.3. L'archive taggée est utilisée telle quelle conformément à CMD-GIT-003 et CMD-GIT-004; aucun fichier local absent du ZIP n'est inventé ou réinjecté.

0.3.2 reste différée conformément à la roadmap.

Objet

Ouvrir 0.3.4 par le nouveau gate obligatoire alpha.1 : migrer la nomenclature prospective de version, auditer complètement la stable et les règles, réévaluer les études réseau, vérifier les dépendances amont envisagées, décider l'ownership physique du transport realtime, fermer le contrat minimal WebSocket et créer le plan vivant jusqu'à stable.

Cette tranche n'ajoute volontairement aucune crate réseau, aucune dépendance Tokio/WebSocket et aucun comportement runtime. L'implémentation commence seulement après validation de ce cadrage.

Migration de nomenclature

À partir de 0.3.4, les nouvelles prereleases suivent exclusivement :

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

alpha.1 remplace le rôle historique de 0-pre.1.

La migration réconcilie les règles prospectives et les README/index actifs concernés. Les anciens deltas, historiques, prompts et entrées de changelog restent inchangés avec leurs identifiants 0-pre, 1-alpha, 2-beta et 3-rc.

L'audit workspace sépare désormais explicitement :

• la convention courante, exigée pour le workspace et les versions explicites des crates ;
• la convention historique, acceptée uniquement pour les répertoires de versions déjà livrés avant 0.3.4.

Ainsi un nouveau jalon 0.3.4-0-pre.* est refusé sans casser la lecture de l'historique existant.

Version

La version workspace passe de :

0.3.3

à :

0.3.4-alpha.1

Aucune version npm/Tauri/Android n'est synchronisée : cette tranche ne change aucun produit packagé.

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), 242 file(s))
Distribution layout audit: clean (49 required path(s), 8 forbidden path(s) absent)

L'inventaire indépendant du ZIP confirme :

400 fichiers
246 fichiers Markdown
55 fichiers Rust
15 Cargo.toml, dont le manifest racine
14 membres workspace
workspace.package.version = 0.3.3
0 symlink
0 erreur de chemin/archive détectée

Aucune arborescence générée target/, node_modules/, gen/android/ ou build/ n'est livrée dans l'archive.

Le log utilisateur fourni à l'ouverture de session confirme également sur son checkout 0.3.3 : format Cargo propre, audits propres, cargo check --workspace et Clippy workspace strict réussis. Son audit Markdown annonce 258 fichiers, soit davantage que le ZIP taggé fourni. Cette différence n'est pas masquée : le delta est construit exclusivement depuis l'archive autoritaire reçue.

Audit des règles

La lecture intégrale demandée par prompts/005-V0_3_4_START_PROMPT.md confirme notamment :

• alpha.1 porte le cadrage, le sizing, les risques, les validations et le plan avant développement lourd ;
• les archives taggées peuvent être utilisées sans .git et constituent la baseline de travail déclarée ;
• les historiques validés sont immuables ;
• le transport doit rester séparé du wire codec, de la session, de la synchronisation et de la simulation authoritative ;
• aucune dépendance réseau concrète ne doit remonter dans le gameplay ;
• les builds, tests et smokes finaux sont attestés côté utilisateur ;
• une modification Cargo impose format/check/Clippy workspace côté utilisateur ;
• CHANGELOG.md reste silencieux avant RC et ROADMAP.md reste macroscopique.

La recherche prospective a trouvé des références à l'ancienne nomenclature au-delà des six fichiers minimum du prompt. RULES_VALIDATION_MATRIX.md, docs/plans/000-README.md, history/000-README.md et le README.md racine sont donc également réconciliés lorsqu'ils décrivent le workflow courant. Les références historiques restent intactes.

Aucune contradiction bloquante n'est trouvée entre le prompt, les règles, la roadmap, les études réseau et la baseline v0.3.3.

Vérification des dépendances envisagées

État amont vérifié le 2026-09-21 pour préparer les tranches d'implémentation :

Tokio                1.53.1
futures-util         0.3.34
tokio-tungstenite    0.30.0
tungstenite          0.30.0

Constats retenus :

• Tokio 1.53.1 annonce un MSRV 1.71 ;
• tokio-tungstenite 0.30.0 et tungstenite 0.30.0 annoncent un MSRV 1.85 ;
• tokio-tungstenite fournit connect/handshake par défaut mais pas de backend TLS obligatoire ;
• les features native-tls et rustls-* restent optionnelles ;
• Tungstenite expose déjà des limites configurables de message, frame et write buffer.

Aucune de ces dépendances n'est ajoutée dans alpha.1. Le plan les introduira uniquement dans la crate backend qui les consomme.

Ownership et contrat retenus

Le plan docs/plans/004-V0_3_4_REALTIME_TRANSPORT_WEBSOCKET_PLAN.md retient deux frontières physiques :

crates/common/game-realtime-transport-lib
crates/common/game-realtime-websocket-lib

game-realtime-transport-lib portera uniquement le contrat transport-neutral : payload binaire opaque, send/receive/close, fermeture distante, erreurs transport-neutral et split concurrent. Elle ne dépendra ni de Tokio ni de Tungstenite.

game-realtime-websocket-lib portera l'établissement client/server, Tokio, tokio-tungstenite, le mapping des frames, les limites, timeouts, close handshake, tracing et tests loopback localhost.

Décisions structurantes :

• runtime Tokio possédé par l'application/service/test consommateur, jamais créé globalement par le backend ;
• aucune tâche backend détachée nécessaire au chemin de base ;
• aucun codec métier dans 0.3.4 : le transport véhicule des octets opaques ;
• aucune abstraction générique Connector/Provider/runtime avant besoin démontré ;
• baseline locale en ws://, sans choix TLS prématuré ;
• aucune file interne non bornée ;
• tests loopback sur 127.0.0.1:0, sans Internet ni port fixe ;
• aucune dépendance tokio-tungstenite dans crates/games/ ou crates/engines/.

Les limites et timeouts candidats, le modèle d'erreur, le lifecycle, le tracing et la matrice de tests sont détaillés dans le plan actif. Les signatures Rust exactes restent volontairement à fermer dans alpha.2, après validation de ce cadrage.

Forecast révisé

Le plan actif retient :

0.3.4-alpha.1  gouvernance + audit + ownership + contrat
0.3.4-alpha.2  API game-realtime-transport-lib
0.3.4-alpha.3  backend game-realtime-websocket-lib + loopback
0.3.4-alpha.4  robustesse + limites + lifecycle + consolidation
0.3.4-alpha.5  uniquement si un demo/consolidation autonome est réellement utile
0.3.4-beta.1   validation large
0.3.4-rc.1     candidate gelée + publication documentaire
0.3.4          promotion mécanique stable

Le scope reste compatible avec une seule version/session tant qu'il ne dérive pas vers le wire codec, la session multijoueur, TLS/PKI produit ou WebTransport/QUIC.

Fichiers

Ajoutés :

deltas/0.3.4/alpha.1.md
docs/plans/004-V0_3_4_REALTIME_TRANSPORT_WEBSOCKET_PLAN.md

Modifiés :

Cargo.toml
README.md
RULES.md
docs/000-README.md
docs/plans/000-README.md
docs/rules/PROMPT_STRUCTURE.md
docs/rules/RULES_DOCUMENTATION.md
docs/rules/RULES_SESSION_PLANNING.md
docs/rules/RULES_VALIDATION_MATRIX.md
docs/rules/VERSION_WORKFLOW.md
history/000-README.md
scripts/audit_project_workspace_rules.py

ROADMAP.md, CHANGELOG.md, les anciens prompts, anciens deltas et anciens historiques restent inchangés.

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), 244 file(s))
Distribution layout audit: clean (49 required path(s), 8 forbidden path(s) absent)

Le contrôle ciblé de politique de version a également obtenu :

history/0.3.4/0-pre.1.md   -> DOC-010, rejet attendu
history/0.3.4/alpha.1.md   -> accepté
targeted version-policy probe: clean

L'historique antérieur à 0.3.4 reste accepté par l'audit workspace normal.

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

Validation utilisateur demandée

Le manifest Cargo et l'audit Python changent. Depuis la racine :

cargo fmt --all
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
cargo clippy --workspace --all-targets --all-features -- -D warnings

Aucun test workspace complet n'est demandé dans alpha.1 : aucun code Rust, aucune dépendance réseau et aucun comportement runtime ne changent.

Suite après validation

Si cette gate est propre, alpha.2 crée history/0.3.4/alpha.1.md avec les sorties réellement obtenues, puis introduit game-realtime-transport-lib sans Tokio/Tungstenite.

Une erreur de migration, d'audit, de plan ou de versionnement produit d'abord 0.3.4-alpha.1.fix.N.