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>
15 lines
1.4 KiB
Markdown
15 lines
1.4 KiB
Markdown
---
|
||
issueRef: "#143"
|
||
version: 4
|
||
updatedBy: {"kind":"agent","agent_id":"f3408f5d-469c-4f64-9485-d8b218f3ff26"}
|
||
updatedAt: 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. |