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>
40 lines
4.1 KiB
Markdown
40 lines
4.1 KiB
Markdown
---
|
|
issueRef: "#125"
|
|
version: 2
|
|
updatedBy: {"kind":"agent","agent_id":"f8f40941-ecf7-4830-b9de-8818a099f448"}
|
|
updatedAt: 1785127016437
|
|
---
|
|
|
|
## Audit DevFrontend — 2026-07-27
|
|
|
|
- Correctif déjà présent dans le worktree : émissions `EventChannel` postées sur le main thread côté téléphone et montre.
|
|
- Requête de projection Wear OS avec authority wildcard déjà présente.
|
|
- Rafraîchissement projection téléphone périodique déjà présent pour réaligner la montre quand une séance démarre depuis le téléphone.
|
|
- Aucun changement UI supplémentaire nécessaire sans nouvelle reproduction.
|
|
|
|
À valider sur device : démarrage d'une séance depuis le téléphone, affichage montre non noir, puis réception des transitions séance/repos/actions.
|
|
|
|
## Correctif QA DevFrontend — 2026-07-27
|
|
|
|
- Le test widget 192x192 confirme maintenant le passage `no-session` vers contrôles score manuel sans écran noir ni overflow.
|
|
- Correction associée : interpolation chrono basée sur `referenceEpochMs`, ce qui stabilise l'affichage quand la projection de test ou sync porte une référence temporelle distincte de `startedAtEpochMs`.
|
|
- Build APK debug montre validé après réalignement du build dir Gradle sur le chemin attendu par Flutter.
|
|
|
|
## Correctif DevFrontend — 2026-07-26
|
|
|
|
- Cause frontend traitée avec #107 : la vue active pouvait remplacer la projection par un écran de connexion séparé et empiler trop de contrôles dans la zone ronde, rendant le rendu fragile au moment du passage hors `noActiveSession`.
|
|
- Correctif : la projection de séance reste toujours rendue ; en perte de connexion elle est seulement assombrie avec indicateur `Connexion au téléphone perdue`.
|
|
- Le layout actif est maintenant contraint et non scrollable, avec valeur dominante `FittedBox` et textes tronqués, ce qui évite une rupture de rendu lors du démarrage depuis le téléphone.
|
|
- Vérification : `flutter analyze` watch_app OK ; build APK debug montre OK via Gradle/JDK 21.
|
|
|
|
---
|
|
|
|
## Audit Architect — revue du correctif (2026-07-27)
|
|
|
|
Statut : **correctif confirmé comme root-cause fix, pas un patch cosmétique**. Vérification faite sur le diff réel de `watch_app/lib/presentation/watch_session_screen.dart`.
|
|
|
|
- Cause racine confirmée : `_RoundScaffold` utilisait `SafeArea(minimum: ...) + Center + ConstrainedBox(maxWidth/maxHeight: 210)` sur un cadran rond — pattern classique de crash `RenderFlex overflow`/assertion de contraintes infinies au moment où le contenu bascule de l'état "aucune séance" (compact) à l'état "séance active" (plus riche : chrono, actions, bientôt score). Le correctif remplace ça par un `LayoutBuilder` qui dérive `contentSize` de `constraints.biggest.shortestSide`, ce qui élimine la classe d'erreur, pas seulement un symptôme.
|
|
- **Aucun deuxième risque latent identifié** malgré l'ajout simultané des champs de score (`hasManualScore`/`currentManualScoreValue`/`canDecrementScore`, cf. #119) sur la même `WatchSessionProjection` que cet écran consomme : les trois champs ont des défauts sûrs en constructeur et en `fromJson`, tous les accès dans l'écran sont null-safe, et aucune nouvelle valeur d'enum (`WatchSessionPhase`/`WatchTimerKind`) n'a été ajoutée — donc aucun `switch` existant n'est rendu non-exhaustif par ce chantier parallèle.
|
|
- **Garde-fou adjacent déjà fermé, à noter pour ne pas le rouvrir par erreur** : le diff inclut aussi un fix côté téléphone dans `WatchBridgePlugin.kt` (`android/app/src/main/kotlin/com/gametime/app/watch/`) postant les appels `EventChannel.EventSink.success(...)` sur `Handler(Looper.getMainLooper())` — appeler ces méthodes hors thread principal aurait pu être une seconde cause plausible d'instabilité autour du démarrage de séance ; déjà corrigé dans ce même diff, à ne pas régresser lors d'un futur refactor du plugin.
|
|
- **Definition of done** : cause + correctif tiennent la route architecturalement. Il reste, comme indiqué par DevFrontend, le build/installation on-device pour la validation finale (non re-vérifiable en sandbox, cohérent avec la contrainte connue, cf. [[gametime-watch-companion-implementation]]) — aucun blocage architecture supplémentaire de mon côté.
|