Blomios
917777e18b
Regroupe l'état de travail en cours réalisé dans un même worktree sur plusieurs tickets/sprints (#85, #136, #145, #155-160, #162-164), mélangeant des tickets QA et inProgress. Ne constitue pas une feature terminée : commit de sauvegarde avant triage/split par ticket en branches feature/* dédiées. Exclut les dossiers d'environnement de build locaux et le heap dump parasite (.gitignore mis à jour). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1.1 KiB
issueRef, version, updatedBy, updatedAt
| issueRef | version | updatedBy | updatedAt | ||
|---|---|---|---|---|---|
| #61 | 6 |
|
1785243150941 |
Plan de séance : résumé de séquence par série (via ActiveExerciseStepUseCases.readProgress). Historique : détail des résultats d'étapes groupés par passage (durée/répétitions, score d'étape, badge "Passée" pour skipped), réutilise WorkoutHistory.stepResults déjà peuplé par #58. 102/102 tests verts, flutter analyze clean, APK debug buildé avec succès.
Écart potentiel vs description initiale du ticket (rédigée par Architect) : la description mentionne aussi "l'édition ponctuelle d'une série passée/terminée permet de corriger les valeurs enregistrées [d'étapes] sans rejouer la séquence interactive" — mon brief à DevFrontend n'a couvert que l'AFFICHAGE des résultats d'étapes dans le plan/historique, pas leur édition a posteriori. Le flux existant "modifier une série passée" (upsertSetResultAtPosition) n'a pas été étendu pour éditer les résultats d'étapes individuels. À vérifier en QA (#62) si c'est bloquant pour l'usage réel ou si un ticket de suivi séparé suffit.