Blomios
917777e18b
Regroupe l'état de travail en cours réalisé dans un même worktree sur plusieurs tickets/sprints (#85, #136, #145, #155-160, #162-164), mélangeant des tickets QA et inProgress. Ne constitue pas une feature terminée : commit de sauvegarde avant triage/split par ticket en branches feature/* dédiées. Exclut les dossiers d'environnement de build locaux et le heap dump parasite (.gitignore mis à jour). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1.4 KiB
1.4 KiB
issueRef, version, updatedBy, updatedAt
| issueRef | version | updatedBy | updatedAt | ||||
|---|---|---|---|---|---|---|---|
| #143 | 4 |
|
1785143072501 |
Cadrage UX (agent UX, 2026-07-27)
Nature : trop exploratoire pour une implémentation immédiate — pas un ticket UX/dev prêt à l'emploi, mais une idée produit qui nécessite un spike de faisabilité technique d'abord.
Pourquoi :
- GPS indoor : la précision GPS grand public en intérieur (gymnase/salle) est dégradée (multipath, perte de signal), alors qu'un terrain de basket (~15×28 m) demanderait une précision de l'ordre du mètre pour qu'une hotmap ait du sens. Sans mesure terrain réelle de la précision obtenue avec une montre connectée, tout cadrage UX (comment dessiner/calibrer le terrain, comment afficher la hotmap) reposerait sur une hypothèse technique non vérifiée.
- Détection de shoot au gyroscope : reconnaissance de geste non triviale (faux positifs probables : dribble, passe, contact défensif), nécessiterait un modèle/calibration, aucun précédent dans le projet.
Recommandation : ne pas cadrer l'UX maintenant. Garder #143 en dormant comme idée produit, et proposer un ticket de spike technique séparé (Architect/DevMobile) : « Faisabilité GPS terrain + détection de shoot montre », avant tout travail UX. Le cadrage UX (création de terrain, affichage hotmap) ne devient exploitable qu'une fois la précision réelle mesurée.