GameTime/.ideai/memory/gametime-resume-plan-2026-07-18.md

---
name: gametime-resume-plan-2026-07-18
description: memory note gametime-resume-plan-2026-07-18
metadata:
  type: project
---
# GameTime — Plan de reprise (consigné suite à interruption pour limite de tokens, 2026-07-18)

## Instruction utilisateur explicite
1. Attendre le reset de tokens (~3h du matin) avant de reprendre.
2. Terminer ce qui était en cours (voir "État exact au moment de l'interruption" ci-dessous).
3. Enchaîner ensuite sur TOUS les tickets restants, en commençant par ceux du sprint **"Bug resolution"**.
4. Puis les autres tickets par ordre de priorité, en tenant compte des dépendances — l'utilisateur laisse Main juger de l'ordre exact, il ne sera pas devant l'écran.
5. **Règle importante pour les bugs** : ne PAS passer les tickets de bug en `closed` une fois corrigés — les passer en statut `QA`. L'utilisateur testera lui-même avec l'APK et les clôturera à la main.
6. Une fois absolument tout terminé, rebuild l'APK final (`flutter build apk --debug`), pour que l'utilisateur ait un seul APK à jour avec tous les tickets faits.

## État exact au moment de l'interruption
Ticket **#26** ([DevFrontend] Configuration du Score chrono — exercice + programme), branche `feature/#26-score-chrono-config`, en cours de débogage d'un dernier test qui échoue de façon persistante après plusieurs itérations :

Test : `test/presentation/exercise_library_screen_test.dart` — "basculer en chrono intégré masque l'unité et affiche le badge" (ligne ~129).
Échec : `expect(find.bySemanticsLabel('Score chrono'), findsOneWidget)` ne trouve rien, alors que :
- Le widget `MeasureBadge` (lib/presentation/exercise_library_screen.dart ~ligne 655-684) a bien la logique correcte : si `measure == WorkoutMeasure.score && scoreInputMode == ScoreInputMode.stopwatch`, `label = 'Score chrono'`, rendu via `Semantics(label: label, child: Chip(...))`.
- Le site d'appel dans `ExerciseListTile` (~ligne 246) passe bien `scoreInputMode: exercise.scoreInputMode` à `MeasureBadge`.
- Le test vérifie bien `saved.scoreInputMode == ScoreInputMode.stopwatch` à la ligne 120 (ça passe), puis reconstruit `ExerciseListTile(exercise: saved)` dans un nouveau `pumpWidget` (lignes 122-127), `pumpAndSettle()`, puis cherche le badge (ligne 129) — et ne le trouve pas.

**Hypothèse non encore vérifiée à l'interruption** : `exercise.availableMeasures` (domain/entities.dart ligne 166) dépend de `hasScoreMeasure` — vérifier si `saved.hasScoreMeasure` est bien `true` après la sauvegarde du formulaire en mode "Chrono intégré" (il est possible que le formulaire ne coche/persiste pas `hasScoreMeasure=true` correctement quand on passe directement en mode chrono sans que le switch "Score" ait été committé avant le changement de mode radio — à vérifier dans `exercise_library_screen.dart`, la logique de sauvegarde du formulaire ExerciseFormScreen, autour de la construction de l'objet Exercise final avant `save()`). C'est la piste la plus probable à vérifier en premier à la reprise, avant de relancer un nouvel aller-retour avec DevFrontend.

## Chaîne de tickets score chrono (ticket parent #18)
- #25 [DevBackend] Domain et migration — **terminé et mergé** (tag v1.5.0-debug + ce qui suit).
- #26 [DevFrontend] Configuration Score chrono — **en cours**, cf. ci-dessus. Branche `feature/#26-score-chrono-config` non mergée.
- #27 [DevFrontend] Chrono score intégré dans l'exécution — dépend de #25, #26. Pas commencé.
- #28 [DevFrontend] Affichage Score chrono dans plan/historique — dépend de #27. Pas commencé.

## État des branches/tags au moment de l'interruption
- `main`/`develop` à jour au tag `v1.5.0-debug` (inclut tickets #1-23, #12, #31).
- Branche `feature/#26-score-chrono-config` en cours, non mergée, contient le travail du ticket #26 (avec le test encore rouge).

## Tickets connus restants après #26/#27/#28
- Tout ticket dans le sprint "Bug resolution" (sprintId `abc4f969-b169-45f7-988c-daeeab762201`) — vérifier `idea_ticket_list` pour la liste à jour, le sprint pourrait contenir de nouveaux tickets créés pendant l'interruption/l'absence de l'utilisateur.
- Vérifier aussi `idea_ticket_list` pour tout ticket créé par l'utilisateur pendant l'absence (comme le ticket #31 et #18 créés en cours de route précédemment) — ne pas supposer que la liste est figée.

## Environnement de build (rappel)
Voir mémoire "gametime-dev-environment" pour les commandes exactes (ANDROID_HOME, PATH, flutter analyze/test/build). Toujours vérifier soi-même (Main) via Bash après chaque implémentation d'agent, les sandbox des agents n'ont pas accès réseau.

## Process à respecter pour chaque ticket restant
Même cycle que jusqu'ici : Git crée la branche → agent (DevBackend/DevFrontend selon le domaine) implémente → Main vérifie réellement (pub get si besoin, build_runner si schéma Drift touché, analyze, test, build apk) → relais des échecs réels bruts à l'agent si besoin → Git merge dans main + develop + nettoyage branche + tag incrémental (vX.Y.0-debug). Consulter UX/Architect en amont si un ticket touche à la conception produit ou au modèle de données de façon non triviale (comme cela a été fait pour #18 → #25/#26/#27/#28).

Pour les tickets de type [Bug] : à la fin de l'implémentation et de la vérification technique (analyze/test/build OK), passer le statut à `QA` (pas `closed`) et laisser un message clair dans le carnet du ticket résumant ce qui a été corrigé, pour que l'utilisateur puisse tester sur l'APK final.