# Réutilisation et delta attendu des POC plateforme ## Statut Étude non normative pour `0.2.0-0-pre.4`. ## Principe Un POC plateforme est utile s'il répond à une question avec peu de code neuf. S'il nécessite immédiatement une réécriture large du jeu, cela indique soit : - une mauvaise frontière actuelle ; - un adapter manquant ; - une capability mal placée ; - un POC trop ambitieux. ## Éléments à ne pas dupliquer ### Gameplay Les crates `game-*` restent source de vérité des règles. ### Assets Les assets communs et game-specific existants doivent être réutilisés. ### Logging Le POC doit brancher les domaines de tracing existants plutôt que créer un logger spécifique. ### Runtime provenance Chaque nouveau host/backend doit enrichir la provenance existante, pas créer un mécanisme parallèle. ### Semantic input Les nouvelles entrées touch/keyboard/pointer doivent converger vers les actions sémantiques du jeu. ## Éléments probablement à extraire Les POC peuvent révéler des duplications aujourd'hui acceptables dans le POC `0.1.0`. Candidats : - bridge WASM générique ; - frontend shell commun ; - input adapter Web ; - lifecycle Web/Tauri ; - asset loader Web ; - tracing frontend commun ; - fullscreen/resize ; - mobile lifecycle abstraction ; - packaging/build tooling. Aucune extraction n'est imposée avant d'avoir vu la duplication réelle. ## Snake comme sonde unique des POC plateforme Snake devient le jeu-sonde de référence pour les POC plateforme de la future série `0.3.x`. Il exerce simultanément : - keyboard/swipe/touch ; - update continu ; - grille et déplacements ; - plusieurs entités ; - état de jeu persistant ; - obstacles/collision ; - score/lives potentiels ; - resize/orientation ; - besoin potentiel de virtual controls ; - future extension multi-snake/multiplayer. Les briques Tauri/WASM déjà construites avec Reflex restent des références techniques à réutiliser, mais les nouveaux POC ne doivent plus utiliser Reflex comme jeu principal. ## Règle de modification minimale Pour chaque POC, documenter : 1. fichiers/crates réutilisés sans changement ; 2. fichiers modifiés ; 3. nouveaux adapters ; 4. nouveau code strictement platform-specific ; 5. duplications provisoires ; 6. extractions candidates détectées. Cette comparaison servira à décider le découpage final du framework.