2.5 KiB
2.5 KiB
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.