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/MEMORY.md

@@ -0,0 +1,5 @@
+# Memory Index
+
+- [gametime-product-scope](gametime-product-scope.md) — memory note gametime-product-scope
+- [gametime-ux-conception](gametime-ux-conception.md) — memory note gametime-ux-conception
+- [gametime-architecture-initial-stack-data-model](gametime-architecture-initial-stack-data-model.md) — memory note gametime-architecture-initial-stack-data-model

.ideai/memory/gametime-architecture-initial-stack-data-model.md

@@ -0,0 +1,30 @@
+---
+name: gametime-architecture-initial-stack-data-model
+description: memory note gametime-architecture-initial-stack-data-model
+metadata:
+  type: project
+---
+GameTime retient Flutter pour l'app iOS/Android, avec priorité performance UI cross-device, open source et maturité mobile.
+
+Le stockage local retenu est SQLite via Drift. L'app est strictement offline-first. Les médias sont stockés en fichiers locaux et référencés par une table MediaAsset.
+
+Le modèle doit utiliser des IDs stables générés localement (UUIDv7 ou ULID), timestamps, soft delete, localRevision, originDeviceId, syncState et un change_log pour préparer une sync serveur incrémentale future.
+
+Les programmes gardent des snapshots lisibles des exercices. Les séances-modèles sont composées de snapshots indépendants des programmes sources. Elles autorisent uniquement des overrides locaux du nombre de séries et des valeurs cibles numériques des mesures déjà actives. L'historique est un snapshot autonome complet de la séance jouée, avec lien optionnel vers la séance-modèle source.
+
+## Architecture logique (hexagonale)
+- domain : entités métier, invariants (ne connaît ni Flutter ni Drift).
+- application : use cases, ports de repositories.
+- infrastructure/local : adapters SQLite/Drift, fichiers médias.
+- presentation : UI Flutter, état écran, navigation.
+
+## Entités principales
+Exercise, MediaAsset, Program, ProgramExercise (snapshot d'exercice + mesures activées + cibles + repos), WorkoutTemplate, WorkoutTemplateProgram (snapshot de programme), WorkoutTemplateExerciseOverride (surcharge locale setsCount/cibles uniquement), ActiveWorkoutSession + ActiveSetResult + ActiveRestState (état de séance en cours, reprenable, basé sur horodatages), WorkoutHistory + WorkoutHistorySetResult (snapshot figé et autonome).
+
+## Points de friction actés
+- Repos matérialisé comme événements concrets à l'exécution (pas juste une règle statique), pour survivre aux réordonnancements et aux ajustements +/-15s.
+- Exercice jamais supprimé dur (archivedAt) ; copies lisibles conservées dans programmes/historique.
+- Score stocké en valeur numérique décimale + label/unité snapshotés (le label/unité de l'exercice source peut évoluer sans casser l'historique).
+- Pas d'IDs auto-incrémentés : IDs stables générés localement, pensés sync dès le départ.
+
+Détail complet (schémas de champs par entité) disponible dans la réponse Architect du 2026-07-17, à ressolliciter auprès de l'agent Architect si besoin de le retrouver précisément.

.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.

.ideai/memory/gametime-ux-conception.md

@@ -0,0 +1,39 @@
+---
+name: gametime-ux-conception
+description: memory note gametime-ux-conception
+metadata:
+  type: project
+---
+# GameTime — Conception UX initiale (par UX)
+
+Navigation principale : Accueil, Exercices, Programmes, Séances, Historique.
+
+## Motif transverse anti-surcharge
+Badges de conditions (Temps/Répétitions/Score) + ligne résumé partout où un objet est listé (ex: "3 séries · Temps + Score · Repos 45 s") + sections progressives (seuls les réglages activés s'affichent). Score toujours affiché avec son unité.
+
+## 1. Bibliothèque d'exercices
+Liste avec recherche + filtres chips par mesure. Création/édition : nom, description, image/vidéo optionnelles, section "Mesures disponibles" (toggles Temps/Répétitions/Score, avec label + unité si Score). Règle : au moins une mesure obligatoire. Avertissement non bloquant si on modifie les mesures d'un exercice déjà utilisé (les programmes existants restent inchangés).
+
+## 2. Programme
+Liste de programmes avec résumé (nb exercices, séries). Création : nom, "Repos par défaut" global, ajout d'exercices depuis la bibliothèque (recherche + badges), cartes réordonnables par exercice. Config par exercice dans le programme : nb séries, mesures à suivre (sous-ensemble de celles autorisées par l'exercice), cible par mesure activée, "Repos après chaque série" (hérite du défaut programme, surchargeable par exercice). Cas limite : exercice supprimé de la bibliothèque → conserver copie lisible + badge "Exercice archivé".
+
+## 3. Séance-modèle
+Liste avec nb programmes/exercices, dernier lancement, action "Lancer". Création : nom, ajout de programmes (copie/snapshot au moment de l'ajout — message explicite à l'utilisateur), réordonnancement des programmes. Indépendance actée : modifier le programme source ne change pas la séance déjà composée.
+
+**Décision produit tranchée** : dans une séance-modèle, l'utilisateur PEUT éditer la copie d'un programme intégré, mais seulement sur deux aspects : le nombre de séries, et les valeurs numériques cibles des conditions de complétion déjà choisies (ex: passer de 10 à 15 répétitions, ou de 45s à 30s, ou changer l'objectif de score). Il ne peut PAS changer quelles conditions sont actives (temps/répétitions/score) ni la liste/l'ordre des exercices du programme depuis la séance — ça reste au niveau du programme source. Raison : selon la séance, l'utilisateur veut pouvoir doser l'exigence (plus ou moins de séries, objectifs plus ou moins ambitieux) sans dupliquer un programme entier pour chaque variante.
+
+Implication data : la copie du programme dans la séance-modèle doit permettre une surcharge locale de `nombre de séries` et des `valeurs cibles numériques` par exercice, sans toucher à la structure (quelles mesures actives, quels exercices, quel ordre) qui reste héritée du snapshot initial.
+
+## 4. Exécution de séance
+Surface la plus critique — optimisée usage à l'effort (grandes zones tactiles, une main). En-tête : nom séance, temps écoulé, pause. Progression Programme X/Y · Exercice X/Y · Série X/Y. Hiérarchie de saisie quand mesures cumulées : Temps (bloc principal) > Répétitions (stepper) > Score (champ + unité, clavier adapté). Écran "Repos" dédié entre séries avec ajustement ±15s et "Ignorer le repos". Pause avec "Quitter et sauvegarder" (recommandé comme action sûre) vs "Abandonner" (destructif confirmé). Reprise après interruption : bandeau "Séance en cours" avec horodatage pour robustesse arrière-plan/app fermée. Fin de séance : récap (temps, scores) + "Relancer cette séance".
+
+## 5. Historique
+Liste groupée par période (Aujourd'hui/Cette semaine/Plus ancien), résumé par séance. Détail : par programme puis exercice puis série (temps/répétitions/score si suivis). Relance : utilise la séance-modèle associée si elle existe encore, sinon relance depuis le snapshot historique avec message explicite.
+
+## Exigences de données remontées à Architect
+- Conditions disponibles par exercice + label/unité du score.
+- Snapshot vs référence : programme ajouté à une séance-modèle = copie indépendante de la structure (exercices, ordre, mesures actives), mais avec surcharge locale possible du nombre de séries et des valeurs cibles numériques par exercice.
+- Repos rattaché à la série/l'exercice précédent (portable lors d'un réordonnancement), avec surcharge possible à l'exécution.
+- État de séance interruptible/reprenable avec horodatages (robustesse arrière-plan).
+- Historique = snapshot complet et autonome, avec lien optionnel (non structurant) vers la séance-modèle source.
+- Exercice supprimé mais référencé ailleurs → conserver copie/référence historique lisible ("archivé").