chore(repo): initialise le dépôt git et l'état de configuration IdeA

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>

.ideai/memory/gametime-product-scope.md

@@ -0,0 +1,34 @@
+---
+name: gametime-product-scope
+description: memory note gametime-product-scope
+metadata:
+  type: project
+---
+# 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.