---
name: gametime-watch-companion-implementation
description: memory note gametime-watch-companion-implementation
metadata:
  type: project
---
# GameTime — Implémentation companion watch (#91) et contraintes sandbox

## État (2026-07-25)
Feature #91 « Interface montre synchronisée » entièrement codée, validée verte en sandbox, committée sur `feature/ticket91-wear-os-watch-sync`.

Sous-tickets : #91-A contrats (`packages/watch_bridge_contract/`), #91-B projection téléphone, #91-C routing commandes, #91-D adapter Android Wear Data Layer + foreground service, #91-E app Wear OS (`watch_app/`), #91-F client montre + latence/haptiques.

Commits : cf68a72 (#91-A), d1c6076 (#91-B), 6c177de (#91-C), 68a87d1 (#91-D), c65a5a7 (#91-E/#91-F). + 40a2d5e `feat(android): local server networking (INTERNET + cleartext)` isolé du watch (pré-existant au serveur, séparé à la demande utilisateur).

## Validation sandbox (verte, par Main)
- Contrat A : 8 `dart test`.
- Projection B (12), command handler C (11), adapter D (6) : `flutter test` all passed. Cas clés : idempotence (retry/doublon n'avance pas deux fois), rejets stale/non-applicable/missing/mismatch, resync reconnexion, heartbeat, ordre séquentiel.
- `flutter analyze` app téléphone : 0 problème watch (24 `info` pré-existants hors #91). `flutter analyze` watch_app : No issues found.
- Revue code Main : invariant source-de-vérité respecté (la montre n'applique JAMAIS une commande localement, recalage sur projection confirmée) ; haptiques sans focus audio (#92) ; démarrage commun exercice+étape via use cases existants (pas de logique montre).

## NON validé en sandbox → on-device utilisateur
- Build gradle app téléphone (`flutter build apk`) avec D (plugin Kotlin, `play-services-wearable`, services watch).
- Build watch_app (`cd watch_app && flutter build apk`).
- Pairing Wearable téléphone↔montre ; commande/projection réelles ; foreground service (verrouillé/background) ; latence/interpolation/resync réelles.

## Contraintes sandbox IdeA (durable, important pour les futures sessions)
Les **agents** (Git, DevBackend, DevFrontend, QA) ne peuvent **pas** écrire `.git` (read-only), ni lancer `flutter` (cache engine read-only), ni accéder au réseau (build hook sqlite3 → SocketException). **Main (orchestrateur) le peut** : `.git` inscriptible, Flutter 3.44.6 OK, réseau OK.

Conséquences pratiques :
- Validation exécutable (`flutter test`/`analyze`) = **Main**, pas les agents.
- Commits/branches = **Main** (agents bloqués).
- Build natif gradle + on-device = **utilisateur** (hors sandbox).
- Messagerie inter-agent instable (« no final text » / « Tool execution aborted ») : le travail atterrit souvent dans le working tree même si la réponse est perdue → vérifier le working tree directement après chaque délégation.
- Identité git repo-local : `Blomios <blomios@gmail.com>` (réutilisée de l'historique).

## Décisions de cadrage #85 / #86 (report Main)
- #85 (packs partageables) : reporté — gâté sur retour d'usage du partage ciblé (encore en QA).
- #86 (analytics basket avancées) : reporté, périmètre v1 gelé (réussite par exercice de tir + charge hebdo estimée), à reprendre après #91 si usage justifie.