# Matrice de validation des POC plateforme ## Statut Étude non normative pour `0.2.0-0-pre.4`. ## Dimensions communes Chaque POC doit produire des observations comparables. | Dimension | Mesure / validation attendue | |----------------------|-------------------------------------------------------------------| | Build | commande reproductible, dépendances, durée indicative | | Artifact | type, taille, emplacement | | Startup | lancement réussi, erreurs, temps indicatif | | Render | grille/Snake visibles, multi-entités, resize/orientation | | Input | Snake : directions, keyboard/swipe/touch, latence perçue | | Lifecycle | pause/resume/background/quit selon host | | Logging | domaines visibles sur le canal plateforme | | Assets | chargement sans chemin hardcodé | | Runtime provenance | dimensions correctes | | Packaging | APK/AAB/app bundle/static web/binary selon cible | | Distribution | contraintes de signature/store identifiées | | Platform integration | faisabilité auth/ads/IAP/notifications sans implémentation finale | | Code reuse | part de `game-snake-poc`, adapters et front réutilisée | | Duplication | duplication nouvelle explicitement recensée | | Maintenance | complexité qualitative et outils nécessaires | ## Critères de réussite Un POC n'est pas jugé uniquement sur « ça démarre ». Il doit permettre de conclure : - quel code est réutilisé ; - quel adapter est nécessaire ; - quelles dépendances sont spécifiques ; - quelles limitations sont structurelles ; - quelle stratégie mérite d'être conservée. ## Critères d'arrêt Un POC peut être arrêté si : - la plateforme n'est pas accessible dans l'environnement disponible ; - le coût de setup dépasse l'information recherchée ; - une contrainte externe rend le résultat non représentatif ; - un POC précédent répond déjà à la question. Un arrêt documenté n'est pas un échec de version.