From a794323314cc7d1d973d6c316e492c5a05e46c72 Mon Sep 17 00:00:00 2001 From: Sylvain Bettinelli Date: Thu, 24 Sep 2026 08:20:52 +0000 Subject: [PATCH] =?UTF-8?q?Le=20snapshot=20arrive=20=C3=A0=20la=20montre,?= =?UTF-8?q?=20et=20on=20peut=20enfin=20le=20dire?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Vérifié sur l'iPhone de Sylvain le 24/09, après build : Montre : snapshot reçu Zones envoyées : version frozen du 2026-08-12 Les quatre causes d'échec silencieux du § 1.2 sont écartées — session activée, montre appairée, app Watch installée, updateApplicationContext sans erreur — et la date de version arrive au poignet, elle qui se perdait au transport. C'est la première fois que ce chemin peut être affirmé plutôt que supposé : il était muet depuis son écriture. ⚠️ Ce que ça ne prouve pas, et c'est écrit dans le document : `updateApplicationContext` est asynchrone. iOS a ACCEPTÉ le contexte, il le livre quand il peut. Ce qui est établi, c'est que l'iPhone a réussi à le transmettre au système — pas que la montre affiche les bonnes bornes. Seul le poignet le dira, pendant une séance. Co-Authored-By: Claude Opus 5 (1M context) --- docs/DIAGNOSTIC-NATIF-2026-09-24.md | 29 ++++++++++++++++++++++------- 1 file changed, 22 insertions(+), 7 deletions(-) diff --git a/docs/DIAGNOSTIC-NATIF-2026-09-24.md b/docs/DIAGNOSTIC-NATIF-2026-09-24.md index 5340038..0e4a827 100644 --- a/docs/DIAGNOSTIC-NATIF-2026-09-24.md +++ b/docs/DIAGNOSTIC-NATIF-2026-09-24.md @@ -6,10 +6,22 @@ > est décrit en fin de document, § « Ce qui a été corrigé ». **Les quatre autres > constats restent ouverts, et le gel tient pour eux.** > -> ⛔ **Rien n'est réel tant que le build Mac n'a pas tourné.** Syntaxe vérifiée -> (`swiftc -parse`) et 91 tests du banc Linux verts — mais ni `CoachWidgetBridge` -> ni `HeartRateZones` ne se compilent hors Xcode : Capacitor, WatchConnectivity -> et SwiftUI sont absents de Swift pour Linux. +> ✅ **BUILD FAIT ET VÉRIFIÉ SUR L'APPAREIL, le 24/09.** Le diagnostic de +> `/settings` (« Diagnostiquer et pousser ») affiche sur l'iPhone de Sylvain : +> +> ``` +> Montre : snapshot reçu +> Zones envoyées : version frozen du 2026-08-12 +> ``` +> +> Les quatre causes d'échec silencieux sont donc écartées : session activée, +> montre appairée, app Watch installée, `updateApplicationContext` sans erreur. +> Et la date de version arrive au poignet — elle se perdait au transport. +> +> ⚠️ **Ce que cela ne prouve pas** : `updateApplicationContext` est asynchrone. +> iOS a *accepté* le contexte, il le livre quand il peut. Ce qui est établi, +> c'est que l'iPhone a réussi à le transmettre au système — pas que la montre +> affiche les bonnes bornes. Seul le poignet le dira, pendant une séance. **24/09/2026. Diagnostic mené en lecture seule** — aucune ligne de Swift n'avait été modifiée à sa rédaction. @@ -310,6 +322,9 @@ zones sans date. La doublure `HeartRateZonesStub.swift` est tenue à l'identique affichable est un choix produit, pas une correction de défaut. - **Il ne touche pas au flux course à pied** (WorkoutKit, live workout FC, app Exercice), conformément à la consigne du 22/09. -- **Il n'a pas été compilé.** Le geste qui vaut preuve, au prochain build : - ouvrir la Console sur la catégorie `widget` et vérifier qu'une ligne - `snapshot poussé vers la Watch · zones=oui depuis=…` apparaît au lancement. +- ✅ **Compilé et vérifié le 24/09** — sans Console : le diagnostic de + `/settings` rend le statut en clair (`Montre : snapshot reçu` · `Zones + envoyées : version frozen du 2026-08-12`), parce que le plugin remonte + désormais `watchPushed` / `watchReason` jusqu'au JS. + ⏳ **Reste à voir au poignet** : que la montre affiche ces bornes pendant une + séance. L'envoi est accepté par iOS ; la livraison est asynchrone.