Blomios
dffca7b6c2
Ajoute le .gitignore Flutter/Dart standard (build/, .dart_tool/, Pods, gradle, etc.) en prévision du scaffolding Flutter (ticket #2), ainsi que la configuration d'orchestration IdeA (agents, mémoire, tickets, sprints). L'état d'exécution transitoire (conversations, run/, live-state) reste ignoré du versionnement. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3.6 KiB
3.6 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| gametime-product-scope | memory note gametime-product-scope |
|
GameTime — cadrage produit initial
App mobile de suivi d'entraînement basket, sur le modèle des apps de musculation.
Entités clés
- Exercice : nom, description, image optionnelle, vidéo optionnelle. À la création, l'utilisateur définit quelles conditions de remplissage de série sont disponibles pour cet exercice (temps, répétitions, score) — cumulables entre elles (ex: shoot = répétitions + score de réussite). Le score est un champ texte/numérique libre avec une unité définissable par l'utilisateur (ex: "paniers", "%", "mètres").
- Programme : liste ordonnée d'exercices. Pour chaque exercice ajouté au programme, l'utilisateur choisit — parmi les conditions autorisées par l'exercice — lesquelles activer pour ce programme précis (un même exercice peut être configuré différemment selon le programme), + nombre de séries, + un minuteur de repos par série (durée par défaut configurable à la création du programme). Le minuteur est attaché à la série/l'exercice qui le précède (pas de minuteur après la dernière série d'un exercice, ni après le dernier exercice du programme) — ça permet de le déplacer avec l'exercice lors d'un réordonnancement.
- Séance-modèle : composition nommée et réutilisable d'un ou plusieurs programmes. Réordonnable librement par l'utilisateur (ordre par défaut = programmes à la suite les uns des autres). Indépendante des programmes sources une fois composée (modifier un programme source ne modifie pas rétroactivement les séances-modèles qui l'ont utilisé — à confirmer avec Architect).
- Exécution de séance : suit l'ordre défini par la séance-modèle. Minuteurs ajustables à la volée pendant l'exécution (en plus du réglage par défaut fait à la création du programme). La séance peut être interrompue et son état sauvegardé pour reprise. Résultats enregistrés : temps total de la séance + score par série pour les exercices concernés.
- Historique : chaque séance jouée est un enregistrement, relançable (relance la séance-modèle associée avec le même ordre).
Contraintes techniques actées avec l'utilisateur
- Stockage local d'abord (offline-first) : l'app doit rester pleinement utilisable sans réseau, y compris si la synchro serveur n'a jamais eu lieu.
- Sync serveur prévue plus tard, avec création de profils utilisateurs — à anticiper dans le modèle de données dès maintenant (ids stables, horodatage, structure sync-friendly) sans l'implémenter tout de suite.
- Préférence forte pour des solutions open source.
- Priorité forte sur la performance et la scalabilité UI cross-device (tailles d'écran, gammes de téléphones variées) — critère de choix de framework important pour l'utilisateur.
- Cibles : iOS + Android, mais test/dev possible uniquement sur Android pour l'instant côté utilisateur.
- Médias d'exercice (image/vidéo) : stockage local d'abord, sync plus tard.
- Stats prévues au démarrage : uniquement le temps de séance + les scores bruts par série. Pas d'agrégats/analytics avancés pour l'instant (peut évoluer).
- Mono-utilisateur local pour le moment (pas de login avant l'arrivée du serveur).
Décisions ouvertes / à trancher par Architect
- Choix du framework cross-platform (perf + scalabilité UI comme critère prioritaire, open source).
- Choix de la solution de stockage local offline-first pensée pour une synchro serveur incrémentale future.
- Stratégie de gestion des médias locaux → sync.