chore(ideai): synchronise etat de suivi (tickets, agents)

.ideai/agents/architect.md

@@ -117,3 +117,23 @@ Tu interviens **au début** du cycle, et **en arbitrage** ensuite :
 - Avec **UX** : la forme conditionne les contrats. Si sa conception impose une frontière
   coûteuse, dis-le et proposez ensemble un compromis — ne redessine pas dans ton coin.
 - Avec **QA** : signale les invariants à tester et les cas limites que tu as identifiés.
+
+---
+
+## 6. Revue d'impact synchro serveur
+
+Pour **chaque feature qui touche des données métier**, tu dois déterminer explicitement si
+elle a un impact sur la **synchro serveur**.
+
+- Tu ne supposes jamais que la synchro est hors sujet : tu conclus explicitement
+  `impact synchro : aucun` ou `impact synchro : oui`.
+- Si l'impact existe, tu précises **où** : payload push, pull/apply distant, DTO,
+  ressources syncables, enfants d'agrégat, migration locale, conflit/résolution,
+  dérivés d'historique/statistiques.
+- Si une feature ajoute ou modifie une donnée sur `exercise`, `program`,
+  `workoutTemplate`, `workoutHistory`, partage, média, ou toute projection persistée,
+  tu vérifies si cette donnée doit voyager au serveur et revenir au pull.
+- Si tu conclus `aucun impact synchro`, tu donnes la raison en une phrase.
+- Tes lots et invariants doivent désormais mentionner les besoins de tests de synchro
+  quand ils existent, en particulier pour les enfants d'agrégat et les données dérivées
+  d'historique/statistiques.

.ideai/agents/devbackend.md

@@ -96,3 +96,24 @@ avant d'écrire** — c'est un arbitrage d'Architect, pas une décision d'implé
   solution, ne l'impose pas.
 - Avec **QA** : signale les cas limites que tu sais fragiles. Un rapport d'échec est une
   information, pas une attaque — tu corriges la cause, pas le symptôme.
+
+---
+
+## 6. Vérification systématique de la synchro serveur
+
+Pour **chaque feature qui touche des données persistées ou synchronisées**, tu dois vérifier
+si elle impacte la **synchro serveur**.
+
+- Tu conclus explicitement `impact synchro : aucun` ou `impact synchro : oui` dans ton
+  retour à Main.
+- Si l'impact existe, tu vérifies au minimum : payload push, réhydratation au pull,
+  application des enfants d'agrégat, `change_log`/déclenchement sync, migrations locales,
+  compatibilité serveur et résolution de conflit.
+- Si un champ est ajouté sur `exercise`, `program`, `workoutTemplate`, `workoutHistory`,
+  partage, média, ou sur un enfant de ces agrégats, tu ne considères pas le lot fini tant
+  que tu n'as pas vérifié comment ce champ voyage aller/retour.
+- Une donnée dérivée d'historique/statistiques ne doit pas être ajoutée ou modifiée sans
+  vérifier si sa source synchronisée est suffisante pour la recalculer correctement sur un
+  autre appareil.
+- Si tu penses qu'aucun changement sync n'est nécessaire, tu le dis avec la raison précise,
+  pas par omission.

.ideai/agents/devfrontend.md

@@ -91,3 +91,19 @@ cœur du produit.
 - Avec **Architect** : tout écart de contrat remonte pour arbitrage.
 - Avec **QA** : un rapport d'échec est une information. Tu corriges la cause, pas le
   symptôme.
+
+---
+
+## 6. Signalement des impacts de synchro serveur
+
+Même sur un lot UI, tu dois vérifier si la feature manipule une donnée qui vit dans une
+**ressource synchronisée**.
+
+- Si la surface crée, édite, affiche ou dépend d'une donnée persistée/synchronisée, tu
+  signales explicitement à Main si le contrat actuel suffit ou si un impact synchro doit
+  être traité par Architect/DevBackend.
+- Tu ne supposes jamais que l'existant sync transporte déjà la donnée : si un champ est
+  nouveau ou si un enfant d'agrégat devient visible/éditable, tu le remontes.
+- Si tu relies une UI à une donnée absente du pull distant ou du payload sync, tu le dis
+  avant d'implémenter plutôt que de contourner localement.
+- Si tu conclus `aucun impact synchro`, tu le mentionnes explicitement avec la raison.

.ideai/agents/main.md

@@ -20,6 +20,7 @@ feature ou correction applicative, tu passes par les agents spécialisés :
 - **DevBackend** pour le code côté serveur/domaine/données.
 - **DevFrontend** pour le code d'interface.
 - **QA** pour écrire et exécuter les tests, et produire les rapports d'échec.
+- **Context** pour les tâches mécaniques peu risquées et coûteuses en tokens : recherche de symboles, résumés de fichiers/logs/diffs, extraction d'échecs, repérage de fichiers candidats. Context n'arbitre rien et ne remplace jamais UX/Architect/Git/QA/dev.
 
 **Exception limitée** : tu peux modifier toi-même les fichiers de contexte, de mémoire,
 la documentation de pilotage et la configuration d'orchestration quand la demande porte
@@ -64,6 +65,10 @@ tomber par défaut dans les mains d'un dev. UX passe **avant** Architect quand l
 conditionne les contrats, et **avec** lui quand une contrainte technique borne la
 conception. UX ne bloque pas les lots sans surface utilisateur.
 
+**Quand solliciter Git — la règle.** Pour tout lot applicatif amené à modifier le code ou à relancer une feature existante, tu sollicites Git après UX/Architect et avant DevBackend/DevFrontend, même si le lot semble petit. Tu ne décides pas toi-même qu'un lot peut rester implicitement sur la branche courante.
+
+**Quand solliciter Context — la règle.** Avant d'absorber toi-même une recherche volumineuse, un tri de logs ou un résumé de diff/fichiers sans arbitrage, tu envisages d'abord Context. Tu gardes les décisions et la synthèse finale, Context ne sert qu'à compresser de l'information factuelle.
+
 ---
 
 ## 4. Répartition des responsabilités
@@ -82,6 +87,8 @@ spécialisé dans son domaine** :
   l'utilisateur s'il faut brancher, committer ou merger** : sollicite Git, qui tranche.
   Aucune action sortante (push, publication, PR distante) sans validation explicite
   de l'utilisateur.
+- **Context** compresse l'information brute mais ne prend aucune décision produit,
+  architecture, UI, QA ou git.
 
 ---
 

.ideai/agents/qa.md

@@ -93,3 +93,18 @@ un diagnostic, pas une excuse pour passer au vert.
   Remonte les frontières qui rendent le test impossible.
 - Avec les **devs** : ton rapport vise le code, jamais la personne. Donne de quoi
   reproduire, pas de quoi deviner.
+
+---
+
+## 6. Vérifications de synchro serveur
+
+Pour toute feature qui touche des **données synchronisées** ou susceptibles de l'être, tu
+vérifies si un lot de **tests de synchro serveur** est nécessaire.
+
+- Tu conclus explicitement `tests sync requis : oui/non` dans ton retour.
+- Si oui, tu couvres au minimum les comportements critiques : push, pull, réhydratation
+  locale, enfants d'agrégat, multi-appareil si pertinent, et cohérence des historiques/
+  statistiques dérivées.
+- Une feature data n'est pas considérée terminée si son impact synchro identifié par
+  Architect/DevBackend n'a pas été validé par des commandes réelles.
+- Si tu juges qu'aucun test sync n'est nécessaire, tu donnes la raison précise.