chore(wip): consolidation intermédiaire multi-tickets (sprints Statistiques, UI, Bug resolution, Serveur-client)
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>
This commit is contained in:
15
.ideai/tickets/143/carnet.md
Normal file
15
.ideai/tickets/143/carnet.md
Normal file
@ -0,0 +1,15 @@
|
||||
---
|
||||
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.
|
||||
18
.ideai/tickets/143/issue.md
Normal file
18
.ideai/tickets/143/issue.md
Normal file
@ -0,0 +1,18 @@
|
||||
---
|
||||
id: "689ab05c-3710-4bf0-bec1-f088d3022aef"
|
||||
number: 143
|
||||
title: "Statistiques terrain de basket"
|
||||
status: "open"
|
||||
priority: "low"
|
||||
sprint: null
|
||||
links: []
|
||||
agentRefs: [{"agentId":"57695b92-24d0-4876-837c-76116e70a6ae","role":"assigned"}]
|
||||
createdBy: {"kind":"user"}
|
||||
updatedBy: {"kind":"agent","agent_id":"f3408f5d-469c-4f64-9485-d8b218f3ff26"}
|
||||
createdAt: 1785142583079
|
||||
updatedAt: 1785143072501
|
||||
version: 4
|
||||
---
|
||||
J'ai une idée qui, je pense, est réalisable avec une montre connectée qui possède un gps. J'aimerais qu'il soit possible, pendant notre séance, de connaitre les endroits sur le terrain ou on a le plus pris de shoot. Pour cela, il faudrait faire deux choses. Dans un premier temps, il faudrait que l'utilisateur puisse créer dans l'interface un terrain avec les coordonnée gps. C'est a dire que l'utilisateur puisse entrer les 4 bords du terrain grace a la fonctionnalité gps de sa montre. Ainsi l'application saura ou le joueur se situe sur le terrain a partir des coordonnées en direct de sa montre.
|
||||
|
||||
La deuxieme fonctionnalité serait de réussir a determiner quand le joueur prends un shhot avec le gyroscope de la montre. Ainsi, l'application pourra créer une hotmap de l'endroit ou le joueur a le plus pris de shoot.
|
||||
Reference in New Issue
Block a user