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

name, description, metadata

name	description	metadata
gametime-resume-plan-2026-07-18	memory note gametime-resume-plan-2026-07-18	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.