chore(ideai): synchronise etat tickets/agents/skills pour vague #179 #180 #182 #183 #184

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

.ideai/agents.json

@@ -41,7 +41,7 @@
       "agentId": "f3408f5d-469c-4f64-9485-d8b218f3ff26",
       "name": "UX",
       "mdPath": "agents/ux.md",
-      "profileId": "9dd61642-f10d-4fc2-a8f1-992d7e1c6940",
+      "profileId": "64be4281-545b-48d6-9b35-d8ae0fb3bb72",
       "templateId": "6d577198-b737-4ff5-aa93-ee20ae4d29ec",
       "synchronized": true,
       "syncedTemplateVersion": 1
@@ -68,21 +68,21 @@
       "agentId": "a5da242f-e5f4-49b5-a29f-e0d4b7b49169",
       "name": "Commercial",
       "mdPath": "agents/commercial.md",
-      "profileId": "98708986-0b01-4768-b44c-1974c7e2576e",
+      "profileId": "18173569-2d3b-4977-b800-b6219c479944",
       "synchronized": false
     },
     {
       "agentId": "aa1ae4f2-c78e-4481-8f96-64f77391d09a",
       "name": "Coach",
       "mdPath": "agents/coach.md",
-      "profileId": "98708986-0b01-4768-b44c-1974c7e2576e",
+      "profileId": "18173569-2d3b-4977-b800-b6219c479944",
       "synchronized": false
     },
     {
       "agentId": "4e440156-ae5d-466b-8cf0-62e41ccfb3a5",
       "name": "Context",
       "mdPath": "agents/context.md",
-      "profileId": "98708986-0b01-4768-b44c-1974c7e2576e",
+      "profileId": "18173569-2d3b-4977-b800-b6219c479944",
       "templateId": "9b854d15-de14-494f-a154-22ad06285d87",
       "synchronized": true,
       "syncedTemplateVersion": 1

.ideai/skills/index.json

@@ -6,6 +6,12 @@
       "name": "basketball-drill-authoring",
       "description": null,
       "contentHash": "aa07477fc1cf6685"
+    },
+    {
+      "id": "2f440186-3c02-403e-8ca1-ab91463e5fe2",
+      "name": "android-build-install",
+      "description": null,
+      "contentHash": "e2342866ece987df"
     }
   ]
 }

.ideai/skills/md/2f440186-3c02-403e-8ca1-ab91463e5fe2.md

@@ -0,0 +1,51 @@
+---
+name: android-build-install
+description: Build and install the GameTime Android phone and watch APKs from validated local code. Use when Codex needs to rebuild release APKs, free space in /tmp if needed, route Gradle/Kotlin/Flutter caches to writable directories, and install with adb on connected devices, uninstalling the previous app only if install -r fails.
+---
+# Android Build Install
+
+Build the phone and watch release APKs from the current validated codebase, using writable cache locations and a compatible JDK.
+
+## Workflow
+
+1. Check free space on `/tmp` and list `gametime-*` temporary folders.
+2. If `/tmp` is too full for a build copy, delete only stale `gametime-*` temporary folders created by prior build/archive attempts. Never mass-delete unrelated `/tmp` content.
+3. Detect the current git state and decide the build source.
+4. If the current worktree already contains the validated fixes to package, use it directly when possible.
+5. If integration must combine validated changes from multiple branches that are not merged yet, create a temporary build workspace under `/tmp/gametime-build-<timestamp>` from the chosen base branch or archive, then overlay the validated files or patch set needed for the target build.
+6. Copy Android signing files required by the repo into the build workspace when the build runs outside the project root.
+7. Force writable tool state before building:
+   - `HOME=/home/anthony/Documents/Projects/GameTime/.build-home`
+   - `PUB_CACHE=/home/anthony/Documents/Projects/GameTime/.build-home/.pub-cache`
+   - `XDG_CONFIG_HOME=/home/anthony/Documents/Projects/GameTime/.build-home/.config`
+   - `XDG_CACHE_HOME=/home/anthony/Documents/Projects/GameTime/.build-home/.cache`
+   - `XDG_DATA_HOME=/home/anthony/Documents/Projects/GameTime/.build-home/.local/share`
+   - `ANDROID_USER_HOME=/home/anthony/Documents/Projects/GameTime/.build-home/.android`
+   - `GRADLE_USER_HOME` to a phone- or watch-specific directory under `.build-home`
+   - `JAVA_HOME=/usr/lib/jvm/java-21-openjdk`
+   - prepend `$JAVA_HOME/bin` to `PATH`
+   - `_JAVA_OPTIONS=-Duser.home=/home/anthony/Documents/Projects/GameTime/.build-home -Djava.io.tmpdir=/home/anthony/Documents/Projects/GameTime/.build-home/.tmp -Dkotlin.daemon.enabled=false -Dkotlin.compiler.execution.strategy=in-process`
+   - `GRADLE_OPTS=-Dorg.gradle.jvmargs=-Xmx4g -Dkotlin.daemon.enabled=false -Dkotlin.compiler.execution.strategy=in-process -Duser.home=/home/anthony/Documents/Projects/GameTime/.build-home -Djava.io.tmpdir=/home/anthony/Documents/Projects/GameTime/.build-home/.tmp`
+   - `FLUTTER_SUPPRESS_ANALYTICS=true`
+8. Build the phone APK with `flutter build apk --release` from the app root.
+9. Build the watch APK with `flutter build apk --release` from `watch_app/`.
+10. Record the final APK paths.
+
+## Installation
+
+1. Run `adb devices -l`.
+2. Identify the phone and watch endpoints explicitly before installing.
+3. Install the phone APK with `adb -s <serial> install -r <apk>`.
+4. Install the watch APK with `adb -s <serial> install -r <apk>`.
+5. Only if `install -r` fails for a package upgrade reason, uninstall `com.gametime.app` on that device and retry a plain `adb install <apk>`.
+6. Report success or the exact adb error per device.
+
+## Guardrails
+
+- Never delete arbitrary `/tmp` content; only remove targeted `gametime-*` temporary folders that were created for build/archive work.
+- Prefer release APKs unless the user explicitly asks for debug builds.
+- Keep phone and watch builds on the same validated code snapshot.
+- If `adb` shows duplicate watch endpoints, probe them and choose one working endpoint before install.
+- If git writes are blocked, avoid forcing repository state changes; use a temporary integrated build workspace instead.
+- Report the exact APK output paths after a successful build.
+- If build or install fails, report the real failing command and error instead of paraphrasing.

.ideai/tickets/179/carnet.md

@@ -0,0 +1,57 @@
+---
+issueRef: "#179"
+version: 7
+updatedBy: {"kind":"agent","agent_id":"57695b92-24d0-4876-837c-76116e70a6ae"}
+updatedAt: 1785408937070
+---
+## Clarifications utilisateur — 30 juillet 2026
+
+### Portée fonctionnelle V1
+- Les graphes de statistiques sont **téléphone uniquement**.
+- Ils sont consultables **après la séance** et **dans l'historique**.
+- La navigation entre `étape`, `série`, `exercice`, `séance` se fera a priori via **un sélecteur de scope** ; UX devra confirmer la meilleure forme pour que cela tienne correctement sur un téléphone.
+
+### Statistiques V1
+- V1 limitée à :
+  - `FC`
+  - `distance`
+  - `calories`
+- Le système doit rester **hexagonal** et conçu pour permettre l'ajout simple d'autres métriques plus tard, sans recadrage structurel.
+
+### Règles d'affichage des graphes
+- `FC` : affichage normal + lignes horizontales `min` / `max` quand pertinent.
+- `distance` et `calories` : même logique générale de graphe, **sans** lignes horizontales `min` / `max`, car métriques cumulatives.
+- Pour les métriques cumulatives (`distance`, `calories`), la valeur affichée est **relative au scope affiché** :
+  - `étape` : départ visuel à `0` au début de l'étape
+  - `série` : départ visuel à `0` au début de la série
+  - `exercice` : départ visuel à `0` au début de l'exercice
+  - `séance` : départ visuel à `0` au début de la séance
+- Cette remise à zéro est **uniquement une règle d'affichage** ; on ne duplique pas les données en stockage.
+
+### Règles de stockage des données pour les graphes
+- On stocke une donnée **toutes les 15 secondes** pour alimenter les graphes.
+- Cela concerne **uniquement** les données historisées pour affichage/statistiques, pas le flux live complet.
+- Source unique : **uniquement les données envoyées par la montre**.
+- Aucune interpolation.
+- Pour une fenêtre de 15 secondes, on conserve **la dernière donnée montre non encore consommée** au moment de l'échantillonnage.
+- Les métriques calculées (ex. calories) ne sont calculées/enregistrées que si la montre a effectivement fourni les valeurs nécessaires.
+- Ordre de grandeur attendu : sur 2 heures, environ **480 valeurs maximum par statistique**.
+
+### Trous de données
+- Si aucune donnée n'est reçue pendant plus de **2 minutes**, le graphe relie la dernière valeur connue à la suivante via un **segment en pointillé**.
+- Ce segment pointillé est **purement visuel**.
+- On ne stocke **aucune fausse valeur intermédiaire**.
+
+### Marqueurs par scope
+- Vue `étape` : pas de marqueurs supplémentaires demandés.
+- Vue `série` : marqueurs de **début/fin d'étape**.
+- Vue `exercice` : marqueurs de **début/fin de série**.
+- Vue `séance` : marqueurs de **début/fin d'exercice**.
+
+### Contraintes transverses — 30 juillet 2026
+- Les modifications doivent être prises en compte sur **toutes les couches de l'application**, **serveur inclus**, pour que la **sauvegarde** et la **synchronisation** fonctionnent correctement.
+- Il ne faut donc pas livrer une solution limitée au stockage local/UI si les données du ticket doivent voyager ou survivre correctement via les mécanismes de sync/historique.
+
+### Hors périmètre V1
+- Aucun buffer/rejeu local côté montre pour compenser une déconnexion téléphone-montre.
+- Ce sujet pourra être réévalué plus tard, mais il est **hors périmètre V1**.

.ideai/tickets/179/issue.md

@@ -0,0 +1,23 @@
+---
+id: "9aa3e9b3-bf4c-480d-9003-82a02ce8f4a3"
+number: 179
+title: "[UI] Statistique par etape, serie, exercice et seance sur le par temps"
+status: "open"
+priority: "medium"
+sprint: "d5c18b44-0eec-46db-b8ab-506cfee0bfea"
+links: []
+agentRefs: [{"agentId":"57695b92-24d0-4876-837c-76116e70a6ae","role":"assigned"}]
+attachments: []
+createdBy: {"kind":"user"}
+updatedBy: {"kind":"agent","agent_id":"57695b92-24d0-4876-837c-76116e70a6ae"}
+createdAt: 1785404943786
+updatedAt: 1785408937070
+version: 7
+---
+J'aimerais qu'on améliore le detail des statistiques. J'aimerais qu'on les stock par etape, par série, par exercice et par seance ainsi que par temps. 
+
+Le but serait de pouvoir afficher des statistiques sous forme d'une courbe sur un graph à deux axes (en ordonnée l'unité de la statistique et en absisse le temps) sur une étape (simplement les datas de la statistique en fonction du temps avec une barre horiezontal pour le max et une autre pour le min), une série (sur laquelle on ajouterait des marqueur sur le début et la fin de chaque étape ainsi qu'une ligne horizontale en pointillé pour le max de la série, et une pour le min de la série), sur l'exercice (sur laquelle on ajouterait des marqueurs de début et de fin de chaque série ainsi qu'une ligne horizontale en pointillé pour le max de l'exercice, et une pour le min de l'exercice) et enfin de la séance (sur laquelle on ajouterait des marqueurs de début et de fin de chaque exercice ainsi qu'une ligne horizontale en pointillé pour le max de la séance, et une pour le min de la séance). On affichera les barres horizontales min et max seulement pour les statistiques pour lesquelles ça a du sens (La FC seuleemnt pour le moment je dirais). Pour ce qui est des statistiques cumulatives dans le temps (la distance et les calories), je veux que la quantité affichée soit relative à la scope. C'est a dire que les valeurs commencent à 0 à chaque fois sur notre affichage.
+
+Je pense qu'on peut se contenter de garder une donnée toutes les 15s et uniquement des données envoyée par la montre. Pour les données calculée (comme les calories) on ne fais le calcul et o ne l'enregistre que si la montre a donné les valeurs, on n'interpole rien. C'est a dire que quand la montre a l'écran éteint, elle n'envoie de toute façon qu'une donnée toutes les 30s, donc ça réduira grandement le nombre de données. On utilise a chauqe fois les dernieres données de la montre non consommée, c'est a dire que si la montre envoie une donnée toutes les 10sec et qu'on enregistre nos données pour notre graph toutes les 15s, alors chaque 15s, j'utilise le dernier bas de donnée récéptionné.
+
+Dans le cas ou il n'y a pas de données recus depuis plus de 2min, on se contentera de relier la derniere valeur à la nouvelle par des pointinllé pour faire comprendre a l'utilisateur qu'il n'y a pas eu de datas. La montre ne garde rien de son côté pour compenser les données non envoyées (si apr exemple la montre et le téléphone se sont déconnecté) sauf si ça ne lui coute rien en énergie et en température de chauffe, ça sera à Main de determiner ça.

.ideai/tickets/180/carnet.md

@@ -0,0 +1,6 @@
+---
+issueRef: "#180"
+version: 4
+updatedBy: {"kind":"user"}
+updatedAt: 1785407074718
+---

.ideai/tickets/180/issue.md

@@ -0,0 +1,17 @@
+---
+id: "6510ed42-2913-4101-98ad-e76d72608081"
+number: 180
+title: "Vibration montre pas assez forte"
+status: "open"
+priority: "medium"
+sprint: "abc4f969-b169-45f7-988c-daeeab762201"
+links: []
+agentRefs: [{"agentId":"57695b92-24d0-4876-837c-76116e70a6ae","role":"assigned"}]
+attachments: []
+createdBy: {"kind":"user"}
+updatedBy: {"kind":"user"}
+createdAt: 1785406934444
+updatedAt: 1785407074718
+version: 4
+---
+Les vibrations de la montre ne sont pas assez forte. Je veux que la derniere vibration d'un chrono soit plus longue et beaucoup plus puissante

.ideai/tickets/182/carnet.md

@@ -0,0 +1,10 @@
+---
+issueRef: "#182"
+version: 5
+updatedBy: {"kind":"agent","agent_id":"57695b92-24d0-4876-837c-76116e70a6ae"}
+updatedAt: 1785408937197
+---
+## Clarification transverse — 30 juillet 2026
+
+- Le correctif ne doit pas seulement supprimer le symptôme local ; il doit être cohérent sur **toutes les couches de l'application**, **serveur et synchronisation inclus** si la progression active concernée par ce bug participe aux mécanismes de sauvegarde/sync.
+- En particulier, le traitement de l'unicité et de l'idempotence sur `active_exercise_step_progress_states` ne doit pas casser les invariants de synchronisation ni produire d'effets de bord dans les sauvegardes/réhydratations de séance.

.ideai/tickets/182/issue.md

@@ -0,0 +1,17 @@
+---
+id: "e0b9df16-2a9a-4be4-97f2-bedc59778bbd"
+number: 182
+title: "[Bug] Erreur chargement de séquence"
+status: "open"
+priority: "medium"
+sprint: "abc4f969-b169-45f7-988c-daeeab762201"
+links: []
+agentRefs: [{"agentId":"57695b92-24d0-4876-837c-76116e70a6ae","role":"assigned"}]
+attachments: []
+createdBy: {"kind":"user"}
+updatedBy: {"kind":"agent","agent_id":"57695b92-24d0-4876-837c-76116e70a6ae"}
+createdAt: 1785407246662
+updatedAt: 1785408937197
+version: 5
+---
+A la fin de certains repos, j'ai cette erreur qui apparait: Impossible de charger la séquence SqliteException (2067): while executing statement UN IQUE contraint failed: active_exercise_id, [...] constraint failed (code 2067) Causing statement INSERT INTO "active_exercice_step_progress_states" [...]

.ideai/tickets/183/carnet.md

@@ -0,0 +1,10 @@
+---
+issueRef: "#183"
+version: 3
+updatedBy: {"kind":"agent","agent_id":"57695b92-24d0-4876-837c-76116e70a6ae"}
+updatedAt: 1785408937216
+---
+## Clarification transverse — 30 juillet 2026
+
+- Cette évolution doit être pensée sur **toutes les couches de l'application**, **serveur inclus**, pour que la **sauvegarde** et la **synchronisation** fonctionnent correctement.
+- Si un nouveau champ métier ou un nouveau mapping de type d'exercice est introduit, il ne devra pas rester cantonné au téléphone ou à la montre : il devra être propagé proprement dans les modèles, contrats et mécanismes de sync concernés.

.ideai/tickets/183/issue.md

@@ -0,0 +1,42 @@
+---
+id: "6bbb4a4d-7c42-4658-9212-e86f3ff65684"
+number: 183
+title: "[Produit][UX] Permettre le choix de types d'exercice métier mappés vers les types Health Services"
+status: "open"
+priority: "medium"
+sprint: "d5c18b44-0eec-46db-b8ab-506cfee0bfea"
+links: [{"target":"#179","kind":"relatesTo"}]
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"57695b92-24d0-4876-837c-76116e70a6ae"}
+updatedBy: {"kind":"agent","agent_id":"57695b92-24d0-4876-837c-76116e70a6ae"}
+createdAt: 1785407800593
+updatedAt: 1785408937216
+version: 3
+---
+Contexte au 30 juillet 2026 : sur certaines montres Wear OS, les métriques `distance` et `calories` ne semblent pas remonter selon le type d'exercice Health Services utilisé. Aujourd'hui, GameTime choisit en interne parmi `RUNNING`, `WALKING`, `HIGH_INTENSITY_INTERVAL_TRAINING`, `WORKOUT` sans que ce choix soit exposé à l'utilisateur métier. Or ce choix influence les métriques réellement fournies par la montre.
+
+Idée produit à étudier : lors de la création/configuration d'un exercice dans GameTime, permettre à l'utilisateur de choisir un ou plusieurs types d'exercice métier (exemples évoqués : `shoot`, `haute intensité`, `dribble`, etc.). Ces types métier seraient ensuite mappés en interne vers un ou plusieurs types `Health Services` (`RUNNING`, `WALKING`, `HIGH_INTENSITY_INTERVAL_TRAINING`, `WORKOUT`, ...).
+
+Objectifs :
+- ne plus laisser ce choix uniquement implicite côté technique ;
+- mieux refléter l'intention réelle de l'exercice côté utilisateur ;
+- améliorer les chances d'obtenir les bonnes métriques montre (`distance`, `calories`, `FC`) selon le contexte ;
+- préparer une architecture extensible si plusieurs types métier doivent se combiner.
+
+Questions de cadrage attendues dans ce ticket :
+- UX : comment exposer ce choix dans la création/édition d'exercice sans alourdir le flux ?
+- Produit : faut-il autoriser un seul type métier ou plusieurs tags combinables ?
+- Architecture : comment modéliser un mapping stable `type(s) métier -> stratégie Health Services` ?
+- Technique : faut-il choisir un seul type Health Services final, ou une stratégie de fallback ordonnée selon les capacités de la montre ?
+- Compatibilité : comment gérer les exercices existants qui n'ont encore aucun type métier explicite ?
+
+Hors périmètre immédiat :
+- ce ticket ne corrige pas directement le bug courant de distance/calories indisponibles ;
+- il sert à cadrer une évolution produit/UX/architecture qui pourrait améliorer durablement la sélection du type d'exercice côté montre.
+
+Proposition de premier périmètre :
+- cadrage UX + architecture ;
+- définition d'un premier vocabulaire métier ;
+- définition du mapping initial vers Health Services ;
+- stratégie par défaut pour les exercices existants.

.ideai/tickets/184/carnet.md

@@ -0,0 +1,6 @@
+---
+issueRef: "#184"
+version: 1
+updatedBy: {"kind":"agent","agent_id":"57695b92-24d0-4876-837c-76116e70a6ae"}
+updatedAt: 1785409810717
+---

.ideai/tickets/184/issue.md

@@ -0,0 +1,25 @@
+---
+id: "f3402801-7505-43d4-a011-30a8f9e9d6b2"
+number: 184
+title: "[Pilotage] Build APK consolidé de fin de vague pour les tickets de sprint traités"
+status: "open"
+priority: "low"
+sprint: null
+links: [{"target":"#179","kind":"relatesTo"},{"target":"#180","kind":"relatesTo"},{"target":"#182","kind":"relatesTo"},{"target":"#183","kind":"relatesTo"}]
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"57695b92-24d0-4876-837c-76116e70a6ae"}
+updatedBy: {"kind":"agent","agent_id":"57695b92-24d0-4876-837c-76116e70a6ae"}
+createdAt: 1785409810717
+updatedAt: 1785409810717
+version: 1
+---
+Règle de livraison ajoutée par l'utilisateur le 30 juillet 2026 : les APK buildés/livrés doivent **regrouper tous les tickets traités** dans la vague en cours, et pas produire un APK isolé par ticket.
+
+Conséquence de pilotage :
+- chaque ticket suit son cycle complet normal (UX -> Architect -> Git -> Dev -> QA) avec vérifications réelles ;
+- les lots validés sont intégrés sur `develop` ;
+- les APK finaux téléphone + montre sont rebuildés **une seule fois en fin de vague**, avec l'ensemble des tickets traités dans cette passe ;
+- si un ticket de la vague n'est pas vert, il ne doit pas être embarqué silencieusement dans un APK annoncé comme validé.
+
+Ce ticket sert de rappel de pilotage transverse pour la vague actuelle de tickets ouverts en sprint (#179, #180, #182, #183 et éventuels lots liés).

.ideai/tickets/counter.json

@@ -1,3 +1,3 @@
 {
-  "nextNumber": 179
+  "nextNumber": 185
 }

.ideai/tickets/index.json

@@ -2509,6 +2509,79 @@
         "kind": "user"
       },
       "updatedAt": 1785321673439
+    },
+    {
+      "issueRef": "#179",
+      "path": "179",
+      "title": "[UI] Statistique par etape, serie, exercice et seance sur le par temps",
+      "status": "open",
+      "priority": "medium",
+      "sprint": "d5c18b44-0eec-46db-b8ab-506cfee0bfea",
+      "assignedAgentIds": [
+        "57695b92-24d0-4876-837c-76116e70a6ae"
+      ],
+      "createdBy": {
+        "kind": "user"
+      },
+      "updatedAt": 1785408937070
+    },
+    {
+      "issueRef": "#180",
+      "path": "180",
+      "title": "Vibration montre pas assez forte",
+      "status": "open",
+      "priority": "medium",
+      "sprint": "abc4f969-b169-45f7-988c-daeeab762201",
+      "assignedAgentIds": [
+        "57695b92-24d0-4876-837c-76116e70a6ae"
+      ],
+      "createdBy": {
+        "kind": "user"
+      },
+      "updatedAt": 1785407074718
+    },
+    {
+      "issueRef": "#182",
+      "path": "182",
+      "title": "[Bug] Erreur chargement de séquence",
+      "status": "open",
+      "priority": "medium",
+      "sprint": "abc4f969-b169-45f7-988c-daeeab762201",
+      "assignedAgentIds": [
+        "57695b92-24d0-4876-837c-76116e70a6ae"
+      ],
+      "createdBy": {
+        "kind": "user"
+      },
+      "updatedAt": 1785408937197
+    },
+    {
+      "issueRef": "#183",
+      "path": "183",
+      "title": "[Produit][UX] Permettre le choix de types d'exercice métier mappés vers les types Health Services",
+      "status": "open",
+      "priority": "medium",
+      "sprint": "d5c18b44-0eec-46db-b8ab-506cfee0bfea",
+      "assignedAgentIds": [],
+      "createdBy": {
+        "kind": "agent",
+        "agent_id": "57695b92-24d0-4876-837c-76116e70a6ae"
+      },
+      "updatedAt": 1785408937216
+    },
+    {
+      "issueRef": "#184",
+      "path": "184",
+      "title": "[Pilotage] Build APK consolidé de fin de vague pour les tickets de sprint traités",
+      "status": "open",
+      "priority": "low",
+      "sprint": null,
+      "assignedAgentIds": [],
+      "createdBy": {
+        "kind": "agent",
+        "agent_id": "57695b92-24d0-4876-837c-76116e70a6ae"
+      },
+      "updatedAt": 1785409810717
     }
   ]
 }