- `cmd1`/`cmd2` forment ensemble l'**opcode** (voir §6). 🔎 confirmé par rapport au constructeur de trames
  de l'application officielle (`C6117b.m30831g`).
- `chunkCount` = nombre total de morceaux pour cette commande ; `chunkIndex` est **basé sur 1**.
- `chunkLen` = nombre d'octets de `chunk` dans cette trame.
- Une seule écriture BLE peut être fragmentée par le MTU de la liaison ; le récepteur met en mémoire
  tampon les octets bruts et ré-extrait les trames complètes. Les grandes charges utiles sont divisées
  en plusieurs morceaux (même `cmd1/cmd2`, `chunkIndex` croissant) et réassemblées dans l'ordre.

### Convention d'opcode (✅ confirmé sur le fil)

- `cmd1 = 0xFFFF` : `cmd2` dans `0x80xx`/`0x90xx` = téléphone→montre (requête/définition) ; `0x00xx`/`0xa0xx` =
  montre→téléphone (réponse). Les paires correspondent par l'octet de poids faible (`0x9055`↔`0xa055`, `0x8051`↔`0x0051`).
- `cmd1` spécifique à une fonctionnalité : suffixe `cmd2` = `0x0001` **SET**, `0x0002` **GET**, `0x0003` **ACK**.

### Corps du morceau

Pour chaque morceau, le corps est `payloadPiece ‖ CRC32_LE(payloadPiece)` (CRC 4 octets, petit-boutiste,
zlib/IEEE). Si la commande est **chiffrée** (voir §3), l'ensemble `payloadPiece ‖ CRC` est ensuite
chiffré en AES-128-CBC/PKCS7 et ce texte chiffré devient le `chunk` de la trame.

**Particularité du texte clair :** pour les opcodes en texte clair, la montre *compte* le CRC de 4 octets
dans `chunkLen` mais ne le **transmet** pas. Ainsi, lors du décodage d'une trame en texte clair, la longueur
réelle des données est `chunkLen − 4`. (Les trames chiffrées transportent le CRC à l'intérieur du texte
chiffré comme d'habitude.)

Dimensionnement des morceaux (pour que les morceaux chiffrés tombent sur les limites de blocs AES), avec
`maxWrite = mtu − 3` :
- chiffré : `floor((maxWrite − 11) / 16) * 16 − 4 − 1`
- texte clair : `maxWrite − 11 − 4 − 1`

✅ Toutes les valeurs `chunkLen` observées pour les trames chiffrées étaient des multiples de 16
(l'alignement des blocs est respecté).

---

## 3. Primitives cryptographiques

- **AES-128-CBC** avec remplissage **PKCS7** et un **IV fixe** (issu du firmware
  `CmfCharacteristic.AES_IV`) :
  `50 51 52 53 54 55 56 57 60 61 62 63 64 65 66 5A`.
- **CRC32** (zlib/IEEE), émis sous forme de 4 octets petit-boutistes.
- **SHA-256** sur la concaténation des parties.

Dérivation de clé :```
authkey      = SHA256( rnd1 ‖ rnd2 ‖ secret )[0..16]      // persisted across sessions
sessionKey   = SHA256( nonce ‖ authkey )[0..16]           // per connection

En cas de `AUTH_FAILED (0xFFFF,0xA061)` ou de non-correspondance de signature, l'authentification échoue.

### 4.2 Reconnexion (authkey déjà connu)```
        set crypto key = authkey (persisted)
phone → AUTH_PHONE_NAME      (encrypted)  payload = 0xA5 ‖ model
watch → AUTH_WATCH_MAC       (encrypted)
phone → AUTH_NONCE_REQUEST   (encrypted)  payload = 0xA5
watch → AUTH_NONCE_REPLY     (encrypted)  payload = nonce
        sessionKey = SHA256(nonce ‖ authkey)[0..16]   → set crypto key = sessionKey
phone → AUTHENTICATED_CONFIRM_REQUEST (encrypted)  payload = 0xA5
watch → AUTHENTICATED_CONFIRM_REPLY   (encrypted)  → Initialized

Finish reply byte : `01` = activé et enregistré ; `0a` = stocké mais **non** activé / rejeté. Sur
Android, chaque `DATA_CHUNK_WRITE` doit partir en **un seul write BLE par frame** — concaténer puis
re-découper selon le MTU désynchronise les en-têtes et la montre boucle en demandant l'offset 0.

- **`9063` (photo) = AJOUT.** La liste des cadrans s'agrandit (6→7) ; `watchfaceId = 0xFFFFFFFF` (sentinel
  personnalisé) pour ne jamais être rejeté comme doublon, et la montre l'active automatiquement.
- **`9075` (structuré) = REMPLACE** l'emplacement `old_id`. `old_id` **doit** déjà figurer dans la liste
  (sinon `0a`). Pour réinstaller un id déjà présent, **supprimez-le d'abord** (9055 liste-moins-id)
  puis téléversez « à neuf » — réutiliser un id en place donne `0a`.

### 11.3 Cadran photo / personnalisé — ✅ entièrement validé de bout en bout

**Conteneur** (aller-retour vérifié octet par octet ; tous les champs en little-endian) :```
0x00  magic     6c 8d c4 a5
0x04  count     12 00 00 00   (=18)  [constant, NOT an element count]
0x08  00 × 8
0x10  lenFull   u32 LE        (length of the whole FULL block: tag+len+payload)
0x14  FULL  tag 04 48 47 3a ‖ payloadLen(u32 LE) ‖ LZ4(RGB565-LE)   → 466×466  [raw 434312 B]
      THUMB tag 04 38 c4 21 ‖ payloadLen(u32 LE) ‖ LZ4(RGB565-LE)   → 270×270  [raw 145800 B]
EOF-4 magic     6c 8d c4 a5   [trailer = magic repeated]

`size` = longueur exacte du `.bin` ; `FFFFFFFF` = `watchfaceId` personnalisé ; `styleId` 0–4 sélectionne la disposition
d'horloge numérique intégrée (elle est toujours dessinée — il n'y a pas de mode « off ») ; `posX/posY` la positionnent (valeurs
connues 56 / 77) ; `color565` lui applique une teinte (par ex. `FFFF` = blanc). ⚠️ La forme plus courte `A5 ‖ size ‖ watchfaceId` est
**rejetée** avec le code de fin `0a` — utilisez l'en-tête complet ci-dessus. (Implémentation de référence :
`core-rust/engine.rs::build_wf_init2`, reflétant `C6135t.m31104u` dans l'application officielle.)

**Recette :** redimensionnez l'image à 466×466 (et une vignette 270×270), convertissez-la en RGB565-LE de haut en bas,
mettez éventuellement à zéro les pixels hors du cercle, compressez chaque partie en LZ4, assemblez le conteneur ci-dessus, puis téléversez
via le pipeline `9063` avec `watchfaceId = 0xFFFFFFFF`. (Codec de référence : `core-rust/watchface.rs`,
`work/codec_dfa.py`.)

### 11.4 Cadran structuré / de boutique — conteneur et codecs ✅

**Disposition du fichier** — l'en-tête de 36 octets est répété **octet pour octet comme un pied de page de 36 octets** à la fin du fichier
(✅ vérifié sur 15 cadrans ; un analyseur doit rejeter un fichier où ils diffèrent) :```
[36-byte header][scene TLV (§11.7)][asset pool][36-byte header again]

> ⚠️ **Correction (remplace « il n'y a pas de somme de contrôle bloquante »).** Les révisions précédentes lisaient `@0x00` comme un
> identifiant/hash par dialecte et `@0x20` comme « 3× mots u32 d'identifiant/hash \[pas un CRC] », et affirmaient que CRC32/Adler32/
> la somme d'octets ne correspondaient pas. Les deux mots **sont** des CRC32 — les tests précédents les ont manqués parce que la
> variante est non standard, et parce que la lecture « 3 mots à `0x20` » confondait le mot CRC unique
> avec les premiers octets du conteneur de scène qui commence à `0x24` (de même, « nom répété à
> `0x2c` » est le nœud de nom `0x86` de la scène, §11.11). Découverte issue de
> [freethinkel/fmc](https://github.com/freethinkel/fmc) ; re-vérifiée ici.

**CRC32-raw** = polynôme IEEE réfléchi `0xEDB88320`, **`init = 0`**, et **aucun XOR final** — c'est-à-dire
ni le `init=0xFFFFFFFF` ni le `^0xFFFFFFFF` du `crc32` standard. C'est exactement la raison pour laquelle
le CRC32 standard n'a jamais correspondu. Notez la dépendance d'ordre : `crc_assets` se trouve dans la plage
couverte par `crc_tree`, donc **écrivez `@0x20` d'abord, puis calculez `@0x00`**.```python
def crc32_raw(data: bytes) -> int:          # tab = standard 0xEDB88320 reflected table
    c = 0                                    # init 0, no final inversion
    for b in data: c = tab[(c ^ b) & 0xFF] ^ (c >> 8)
    return c & 0xFFFFFFFF

crc_tree   = crc32_raw(f[0x04:0x24] + f[0x24:first_asset])
crc_assets = crc32_raw(f[first_asset:len(f)-36])

`kind` = `0x02`/`0x03` ; `old_id` = dial actif courant (depuis `9055`) ; `file_len` = taille réelle du `.bin`
(= `@0x18 + 36`). Installer un `.bin` de store tel quel est le chemin garanti (Ring Data id 359 +
102 autres confirmés). (Référence : `core-rust/engine.rs::build_dial_replace_init`.)

### 11.5 Grammaire structurée du répertoire ✅ (décodée et implémentée — RÉVISÉ 2026-07-02)

> **⚠️ Révision (2026-07-02) : le schéma d'enregistrement plat `61 01 00` ci-dessous était
> systématiquement DÉCALÉ D'UN OCTET.** Le corps de scène est un TLV propre (§11.7) ; un **corps de feuille**
> dessinable (tags `0x30`/`0x38` statiques, `0x70` pointeur) est :
>
> ```
> 01 xx 00 [X u16][Y u16] …attrs… 61 [count u16][base u32][count×id u16] [05 05 00 01 pivX pivY]
> ```
>
> - l'attribut `0x01` ouvre le corps : **X,Y = coin supérieur gauche** sur le canevas 466² (le `s16 x,y` du
>   `sty_picture_t` du SDK).
> - la **table de trames `61 …` ferme le corps** (`base` = pointeur d'asset ; `count` 1 = image, 10/11 =
>   atlas de chiffres — l'ancien « type d'enregistrement `0a/0b` » était en fait ce count ! — 7/13/2 =
>   feuille de trames de complication).
> - extras de pointeur : source+échelle `[src] 00 3c 00` dans l'attribut `0x01` ; pivot dans la
>   **remorque** `05 05 00 01 [pivX][pivY]`. **Centre de rotation = `(X+pivX, Y+pivY)` par pointeur** —
>   pas un (233,233) fixe : des sous-cadrans excentrés existent (ex. les aiguilles du dial 366 tournent
>   autour de 150,150).
>
> Le balayage linéaire pour `61 01 00` cousait la table de trames+pivot de l'élément **N** au X/Y
> (et octet de tag, l'ancien « f3 ») de l'élément **N+1** — cela ne semblait correct que sur les cadrans
> analogiques dont les aiguilles adjacentes partagent une géométrie quasi identique. Le « mur des variantes
> compactes » (spec 24 §24.4.5) était cette même erreur de lecture. Implémenté comme `scan_scene_drawables`
> dans `core-rust/watchface_struct.rs` et `wfweb/src/codec/parse.ts` (scène = source principale pour
> images/pointeurs ; balayage plat conservé pour texte + repli non-enveloppe). Validé par l'oracle
> `wfweb/compare.html` (rendu vs PNG officiels du store, 99 cadrans) : 64→72 bons, 8→5 mauvais, diff
> moyenne 9,3→7,4 %.

Lecture historique d'enregistrement plat (remplacée, conservée pour contexte) :

- **Image statique** (`61 01 00`) : `asset_ptr(u32) ‖ elemId(u16) ‖ 05 05 00 01 ‖ pivotX(u16) ‖
  pivotY(u16) ‖ 3B ‖ 01 ‖ 1b 00 ‖ X(u16) ‖ Y(u16)`. Coin supérieur gauche sur le canevas 466² =
  `(X−pivotX, Y−pivotY)`.
- **Pointeur/aiguille** — même enregistrement d'image, pivoté à l'exécution. **Centre de rotation =
  `(X+pivotX, Y+pivotY)`** (≈ 233,233 sur les cadrans analogiques). La **source de données est un `u8`
  au décalage d'enregistrement `+36`**, échelle `u16` à `+38` (=60) : `0x0a`/`0x70` = heure
  (`h·30°+m·0,5°`), `0x0e`/`0x71` = minute (`m·6°+s·0,1°`), `0x12`/`0x72` = seconde (`s·6°`). ✅ confirmé
  par désassemblage des getters (repli RTC 10:10:30).
- **Widget texte / nombre** (`61 0a 00`) : `asset_ptr(u32) ‖ [10×u16 métriques de police] ‖ 40 01 00 ‖
  drapeau ‖ 3B ‖ 01 ‖ u16 ‖ X(u16) ‖ Y(u16)`. `asset_ptr` pointe sur le glyphe « 0 » ; le chiffre *d* =
  l'asset à `index("0") + d` (10 sprites cf=5 consécutifs, ex. `0123456789` et ponctuation `,°`). ✅ rendu.
- **Remplissage de complication = index de trame** (✅ confirmé pour les complications chiffre/énumération/
  jauge, count>1) : la valeur indexe une **feuille de trames pré-rendues** dans le `.bin` — `frame =
  (count−1)·val/100` (pourcentage) ou `frame = value` (chiffre à bascule / énumération). Table de trames =
  sous-enregistrement `61 ‖ count(u16) ‖ base(u32) ‖ count×id(u16)`. Ex. la grande heure du 327 Digit Max
  est une feuille de 13 trames (chiffres 0–12), `frame = hour`.
- **Anneau de progression / arc = clip sectoriel à l'exécution** (✅ 2026-07-02, **corrige la lecture
  « les anneaux sont des feuilles de trames » de la spec 25 §2**) : le tag d'élément **`0x81`** porte un
  **disque complet unique** (`61` table de trames `count == 1`), et le coin partiel est ce disque **clippé
  en secteur de camembert** (`frac = value/max`, dans le sens horaire depuis 12 h) — vérifié pixel par
  pixel sur 322 Glare 2 et `count==1` confirmé sur **20 cadrans**. Sur disque : corps `0x81` = sous `0x01`
  (géométrie `x@+0 y@+2 w@+4 h@+6`, `61 1 base` inline = disque) + sous `0x5b` (spec d'arc). Implémenté
  dans wfweb (`blendSector`).
  ⚠️ Le sous-enregistrement `0x5b` n'est **pas** juste « `max` u16 `@+4` » comme documenté précédemment —
  cela lisait la moitié basse d'un `max i32` et manquait les **angles de balayage début/fin et la largeur
  de trait** qui se trouvent juste après. Il existe aussi un frère procédural `0x80`/`0x5a` (avec un rayon
  explicite) que ce document n'a jamais couvert. Disposition complète de l'enregistrement, et ce que
  l'hypothèse précédente « dans le sens horaire depuis 12 h » a mal compris : **§11.15**.
- **Id de source de données** — le bloc d'attributs `82` de l'élément se trouve à `delim+3` (après le
  dernier `40 01 00`), et **l'id de source est un `u8` à `+0x14`** (aussi `relX@+0x07 s16`,
  `relY@+0x09 s16`, `anchor@+0x0C/0E`, `mode@+0x15`, `frame-count@+0x1A`). Anchor < 0 = aligner sur le
  bord du parent. 🔎 Le firmware résout l'id via une table de getters à 142 entrées à `0x101f371c`
  (chacune appelle `ux2sys_get(type)`).
  ⚠️ **Préférez lire l'id comme `meta[9]` de la structure (§11.11)** — un champ fixe — plutôt que ce
  balayage avant d'attribut `82`, qui est la source du décalage d'un octet décrit en §11.8/§11.9. Table
  complète des ids en §16 ; notez que les étiquettes santé/météo que cette section listait précédemment
  en ligne (`0x19` FC, `0x1b` batterie, `0x24` température, `0x36` pas) sont **contestées et probablement
  fausses** — voir l'encadré ⚠️ en §16. (L'exemple de groupe `0x07:0x0b:0x0f` = HH:MM:SS ci-dessous n'est
  pas affecté.)
- **Nœud de groupe** (`0x68`) : imbrique ses enfants dans son propre corps TLV (`0x60` = valeur/texte,
  `0x30` = statique) ; chaque `0x60` porte son id de source à `data+16`. Ex. un groupe `0x07:0x0b:0x0f` =
  horloge HH:MM:SS. Analyseur d'élément TLV = `0x100db55c` (table de sauts indexée par `tag−0x70`).

### 11.6 Matrice de création

| Chemin | Statut | Notes |
|---|---|---|
| Cadran photo depuis n'importe quelle image | ✅ **fait** | §11.3 ; validé sur appareil |
| Installer l'un des 103 cadrans du store | ✅ **fait** | §11.4 ; `9075`, `old_id`=actif |
| Reskinner le fond cf=4 d'un cadran du store | ✅ **fonctionne en direct** | échanger la charge utile COMPLÈTE en place, définir le `len` de l'asset à la **nouvelle** taille de bloc (≤ ancienne), conserver la même empreinte de fichier, réinstallation propre |
| Ré-écrire par gabarit (échanger les pixels de n'importe quelle couche + déplacer la géométrie) | ✅ **rendu via BLE** | dial 373 : fond→cyan + un sprite cf=5→rouge + X déplacé 224→100, tout rendu, aiguilles en direct |
| Cadran structuré 100 % synthétique de zéro | ✅ **builder fait, validé hors ligne** | builder d'enveloppe `0x20` dans `watchface_struct.rs` (`build_container`/`serialize`/`validate_container`) ; aller-retour sur les 103 cadrans octet-exact + synthétique passe le validateur du firmware (§11.7). 🟡 rendu sur appareil via `9075` pas encore filmé |
| Polices système (`.font`) | ✅ **décodage/rendu (toutes)** | binaire LVGL (non propriétaire) ; 32 polices de chiffres (`num*/nm*`, non compressées) + 24 polices de texte (`font*`, LVGL RLE `comp=1`) toutes décodées — 12208 glyphes, 0 dépassements, ASCII complet. RLE = LVGL v8.3 `lv_font_fmt_txt.c` (SINGLE/REPEATE/COUNTER à 3 états + préfiltre XOR par ligne), porté 1:1, sans désassemblage |

⚠️ Pièges de reskin/ré-écriture qui causent un écran noir ou `0a` : laisser l'**ancien `len` d'asset**
(la montre lit au-delà du bloc → dépassement → noir) ; **agrandir le fichier** (rejeté à l'installation) ;
réutiliser un id **en place** au lieu d'une installation propre ; **réordonner les assets** sans corriger
la chaîne de tailles de blocs de la queue de références (§11.11). Pas fatal aujourd'hui mais écrivez-le
correctement quand même : tout changement de la scène ou du pool d'assets invalide les deux mots **CRC32**
d'en-tête — recalculez les deux (§11.4), `@0x20` avant `@0x00`.

### 11.7 L'enveloppe de scène `0x20` — décodée et builder implémenté ✅

Un cadran **réel** ré-écrit rend parce qu'il préserve l'enveloppe de scène du fichier. Un corps purement
synthétique d'enregistrements plats `61 …` est **rejeté** — l'analyseur du firmware (`WFManager_Parser`,
`0xdb35c`) exige que le corps (depuis le décalage `0x24`) commence par un conteneur de scène `0x20`.
Le fichier complet est :```
[0x00,0x24)  header:  perDialId@0 · version=1@4 · name[16]@8 · size_a@0x18 · size_b@0x1c · idWord0@0x20
[0x24, fa)   scene:   20 <u16 L0> ( 21 <u16 L1> ( 86 <len>=name , 30/70/80/81… drawables ) [ 22 … AOD ] )
[fa, EOF)    assets:  [dimsWord u32][len u32][payload = 1f 00 01 00 + LZ4] …
   size_a = filesize−36 · size_b = filesize−36−first_asset · 0x27+L0 == first_asset

> ✅ Cela unifie les « décalages magiques » des §11.5/§11.8/§11.9. Ces sections localisent les champs *relativement
> à l'octet de la table de trames `0x61`* — qui est simplement `+0x12` de cette structure, donc `−18`/`−16` = `x`/`y` et
> **`−5` = `meta[9]`, l'identifiant source**. Mêmes octets, une seule disposition propre. L'heuristique d'attribut `82`
> à balayage avant qui était systématiquement décalée d'un octet n'est pas du tout nécessaire : lisez `meta[9]` de la structure.
> Le `max` d'un champ numérique est de même simplement `meta[11..13]` (par exemple, les champs de jour du mois portent `max = 99`).

**Queue de réf** (`61`) — comment un nœud pointe vers ses bitmaps :```
+0x00  0x61      [tail type]
+0x01  count u16 [1 = single image · 10/11 = digit atlas · N = pick-list / frame sheet]
+0x03  base  u32 [ABSOLUTE FILE OFFSET of the first asset block]
+0x07  count × u16  = the BLOCK SIZE (8 + payload len) of each referenced asset, in order

`id` est un identifiant de source de données (§16) — y compris les **identifiants de slot synthétiques** du §11.13. Opérateurs, avec
comptages d'occurrences mesurés sur 15 cadrans :

| op | signification | vu |
|---|---|---|
| `0x01` | dessiner si `value == val` | 99 |
| `0x81` | identique à `0x01` (bit `0x80` défini — apparaît sur les variantes mutuellement exclusives) | 48 |
| `0x02` | **masquer** si `value == val` | 7 |
| `0x03` | dessiner si `value == val`, où `val` est un **marqueur de non-données** (ex. HR `1000`) | 13 |
| `0x05` | dessiner si `value >= val` | 58 |
| `0x06` | dessiner si `value <= val` | 50 |
| `0x04` | ⚠️ **inconnu** — 15 occurrences, aucune sémantique confirmée | 15 |

Règle de combinaison (telle qu'implémentée par le moteur de rendu de référence, masque `op & 0x7f`) : les entrées d'égalité
sont combinées en **OU**, puis les entrées masquer/`>=`/`<=` doivent **toutes** être vérifiées.

Ce mécanisme unique couvre la majeure partie de la variabilité d'exécution du format et explique les structures qui ressemblent
à des widgets dupliqués :

- **Dispositions 12h / 24h et métrique / impériale** — deux ensembles de widgets empilés au même endroit, chacun lié à
  `id 0x73` (le drapeau d'unités) avec `val` 0 ou 1. Le cadran 275 possède six de ces paires (12 nœuds).
- **Espaces réservés « Pas de données »** — op `0x03` contre une sentinelle, ex. `id 0x5f, val 1000` (cadran 275, deux fois) :
  dessiner l'art du tiret cadratin au lieu d'une température lorsque la métrique est indisponible.
- **Mises en évidence par compartiments** — une plage `0x05`/`0x06` appariée, ex. la chaîne de Metaball où chaque maillon s'allume
  pour sa propre fenêtre de 5 minutes.
- **Alternatives de slots de complications** — liées aux identifiants de slot synthétiques du §11.13.

### 11.13 Slots de complications configurables — `0x85` + `0x5f` ✅ (remplace le §11.8)

Le §11.8 concluait que la métrique active d'une complication configurable est un état RAM de l'appareil et ne pouvait pas être
récupérée depuis le fichier. **C'était faux** — à la fois le menu de métriques du slot et sa sélection par défaut
se trouvent dans le `.bin`. Chaque nœud `0x85` porte un frère `0x5f` :```
+0x00  slotIndex u8   [0-based position among sibling 0x85 nodes]
+0x01  count     u8   [how many metrics this slot offers]
+0x02  activeIdx u8   [index into the list below = the DEFAULT SHOWN METRIC]
+0x03  count × u8     [the metric ids themselves (§16)]           … NUL padding

L'appariement est rigide : `0x80` transporte toujours exactement `0x01` + un `0x5a` de **19 octets**, `0x81` toujours exactement
`0x01` + un `0x5b` de **17 octets** (✅ 26/26 anneaux sur 15 cadrans). ⚠️ Mais le **`0x81` rogné par l'image
domine** — 25 de ces 26. La variante procédurale `0x80`/`0x5a` n'est apparue **qu'une fois** (cadran 273), donc son
champ `radius` et sa disposition de 19 octets reposent sur un seul échantillon ; à traiter avec suspicion jusqu'à nouvel ordre.

`frac = clamp((valeur − min) / (max − min), 0, 1)`, et l'arc rempli va de `start` vers `end`.
L'angle zéro est à **3 heures**, positif dans le sens horaire. Exemples mesurés :

| cadran | tag | min..max | start → end | largeur | rayon |
|---|---|---|---|---|---|
| 273 Activity Mood | `0x5a` | 0..100 | **−102,8° → 102,8°** | 42 | 222 |
| 273 Activity Mood | `0x5b` | 0..100 | 270,0° → 90,0° | 80 | (image) |
| 276 Dichotomy | `0x5b` | 0..100 | 60,0° → −120,0° | 23 | (image) |
| 304 Elaborate 2 | `0x5b` | 0..100 | −2,0° → 358,0° | 24 / 80 | (image) |
| 366 Combo | `0x5b` | 0..100 | 0,0° → 270,0° | 18 | (image) |
| 368 Function | `0x5b` | 0..100 | 0,0° → 360,0° | 20 | (image) |

> ⚠️ **Ceci corrige l'hypothèse « sens horaire à partir de 12 heures »** du §11.5. Ce n'est que le cas
> particulier `start = 0, end = 3600` (un balayage complet, où la convention est inobservable). Les vrais cadrans utilisent
> des **jauges partielles** (l'éventail ±102,8° du 273, l'anneau aux trois quarts de 270° du 366) et des **balayages négatifs**
> (60° → −120° du 276), donc un moteur de rendu qui balaie toujours un cercle complet depuis le haut les dessine mal.
> 🟡 La convention exacte de l'angle zéro et la règle de direction proviennent du moteur de rendu de fmc, recoupées
> avec ces valeurs sur disque — non vérifiées indépendamment pixel par pixel sur l'appareil par ce dépôt.
> Notez que `frac = valeur/max` et le résultat du découpage de secteur `0x81` du §11.5 **ont** été validés (cadran 322).

⚠️ **Non résolu : la fin de 3 octets `01 00 kk`.** `kk` prend des valeurs plausibles (104, 152, 216,
232, 248) et l'hypothèse évidente est un rayon — **testée et réfutée** : le cadran 366 utilise `kk = 104`
pour un anneau de 82×82 et un de 166×166, et le cadran 273 utilise `kk = 232` pour un anneau de 440×440 et un de 284×284.
Pas un rayon, pas un diamètre. Peut-être opacité/style. À faire un aller-retour tel quel.

🟡 **Piège signalé, non vérifié ici :** dans le moteur de rendu de fmc, un nombre `0x60` dont l'id de source est égal à l'id de
**n'importe quel** anneau sur le même écran affiche `round(frac × 100)` au lieu de la valeur brute — donc un
nombre de fréquence cardiaque à côté d'un anneau de fréquence cardiaque affiche `36` au lieu de `71 bpm`. Leur
solution documentée est de placer l'anneau et le nombre sur deux ids **alias** de la même métrique (pas
`0x19`/`0x26`/`0x49`, calories `0x1c`/`0x1e`/`0x48`). Que ce soit un comportement du firmware ou spécifique
à leur moteur de rendu n'est **pas établi** — à vérifier en direct avant de concevoir autour.

---

## 12. Détails du transfert en masse et de l'OTA

La table de transfert est au §6. Points supplémentaires confirmés :

- **AGPS/EPO** ✅ : le premier bloc écrit commence par l'en-tête ASCII `000000010000…`. La boucle complète
  init → `[A05F ↔ 905F]×N` → fin a été observée sur le fil (~892 blocs).
- **OTA du firmware** (`9040`–`9042`, fin `9041`) 🔎 : structure cartographiée ; charge utile INIT2 = octets de version
  (par ex. `0b 00 00 39` = 11.0.0.57). **Non testé sur le terrain** (l'application désactive la mise à jour du firmware ici). Les images
  du firmware semblent être **non signées — l'intégrité n'est que CRC32** (aucune signature asymétrique observée en rétro-ingénierie).
- ⚠️ Parce que l'OTA et `FACTORY_RESET (009A 0001)` partagent la session authentifiée, une seule authentification BLE
  valide suffit pour effacer ou (en principe) briquer la montre. À manipuler avec précaution.

---

## 13. Capteurs

✅ Matériel exposé via BLE :

- **PPG optique** — fréquence cardiaque (manuelle/auto/entraînement/repos), SpO₂ et stress dérivé de la VRC.
- **Accéléromètre 3 axes** — pas, distance, calories, phases de sommeil, lever de poignet, cadence.
- **GNSS/GPS** (assisté AGPS) — trace d'entraînement (`WORKOUT_GPS`) et envoi de position (`GPS_PUSH`).

Il n'y a **pas de baromètre/altimètre, boussole, gyroscope ou capteur de température cutanée/corporelle**. Une thermistance
NTC interne (température de la carte/batterie) existe mais n'est lisible **que** via le canal AT
(`AT GETNTCTEMP`, §14) — le flux d'historique de température cutanée `0155` est vide sur ce SKU.

**Détournements de widgets de données** (il n'y a pas de vraie API de complications/liaison de données — voir §11.5) : les
champs de texte existants de la montre peuvent être réutilisés pour afficher des données externes en un coup d'œil. Prouvé ✅ : la
**chaîne de ville** météo (`WEATHER_SET_1`, par ex. `"BRA 2x1 ARG"` est apparue sur le widget) et les champs musique
**titre/artiste** ; la liste **contacts** (20 × nom[32]+numéro[25]) fonctionne comme un panneau de données défilant. Tout
est des envois, pas des complications persistantes.

---

## 14. Canal AT d'usine / shell (`77d4ff01` / `77d4ff02`)

Un canal de commandes AT en texte brut séparé, indépendant du protocole tramé. ✅ testé en direct :

- **Lecture :** `AT GETSECRET` (secret d'appariement de 16 octets), `GETVERSION`, `GETSN`, `GETNAME`, `GETPID`,
  `GETBATLV` (mV bruts, par ex. `3853mv`), `GETGSENSOR` (accélération brute en g, `X=… Y=… Z=…`),
  `GETNTCTEMP` (°C, NTC interne).
- **Écriture / action :** `AT SETMOTOR=1` (faire vibrer le moteur), `SETHR/SETHRV/SETSPO2=…` (injection de test
  capteur), `SETLCDSWITCH/SETGPSSWITCH/SETKEYSWITCH`.

Les réponses se terminent par `,OK`. Les commandes `SET*` s'exécutent généralement mais peuvent ne pas renvoyer `,OK` sur BLE — à confirmer
au cas par cas.

---

## 15. Fonctionnalités verrouillées par le firmware / indisponibles (🔎 rétro-ingénierie du firmware)

Certaines fonctionnalités sont présentes dans le firmware mais désactivées par SKU/région et **ne sont pas accessibles depuis le
téléphone/BLE** — elles nécessitent une modification du firmware, hors de portée ici :

- **Voix ChatGPT** — porte = id de fonctionnalité `ux2sys` `0x9e`, initialisée depuis NVRAM/EFUSE/région au démarrage ; sur
  ce SKU, le drapeau de support `908b = 00`. Non influençable par le téléphone, le compte ou le BLE (confirmé par
  expérience + rétro-ingénierie). L'application n'est qu'un relais ; l'audio va du téléphone au cloud Nothing.
- **Tension artérielle** — un sous-système complet existe dans le firmware, désactivé par SKU/région.
- **Alipay / paiement NFC** — interface complète présente, SKU Chine uniquement.
- **Absent du matériel/firmware :** ECG, SOS/urgence, NFC générique.

---

## 16. Ids de source de données / getter de complication

Pas nécessaire pour construire un client BLE, mais **essentiel pour créer ou rendre un cadran** : c'est la valeur de
`meta[9]` (§11.11) qui lie un widget à des données en direct, l'`id` d'une condition de visibilité (§11.12), et
les entrées du menu de métriques d'un emplacement (§11.13). Le firmware le résout via une **table de dispatch de getters à 142 entrées**
à `0x101f371c`, chaque entrée appelant `ux2sys_get(type)` (🔎 rétro-ingénierie du firmware).

### Heure / date — ✅ bien établi

| id | signification | id | signification |
|---|---|---|---|
| `0x01` | heure (12/24h selon le réglage de l'appareil) | `0x0f`, `0x12` | seconde (lisse) |
| `0x04` | heure (24h) | `0x10`, `0x11` | dizaines / unités de seconde |
| `0x07` | heure (24h forcé) | `0x71`, `0x72` | seconde (tic-tac / angle d'aiguille) |
| `0x02`, `0x03` | dizaines / unités d'heure-12h | `0x13` | drapeau AM/PM (0 = AM, 1 = PM) |
| `0x05`, `0x06`, `0x08`, `0x09` | dizaines / unités d'heure | `0x15`, `0x16` | mois |
| `0x0a`, `0x70` | angle d'aiguille des heures | `0x17` | jour du mois |
| `0x0b` | minute | `0x18` | jour de la semaine (0 = lundi ⚠️) |
| `0x0c`, `0x0d` | dizaines / unités de minute | `0x0e`, `0x71` | angle d'aiguille des minutes |

Les ids de dizaines/unités dessinent un **chiffre unique** — un widget lié à l'un d'eux affiche un glyphe, pas la
valeur entière (cadran 284 Square). Les ids d'angle d'aiguille (§11.5) sont `0x0a`/`0x70` heure = `h·30° + m·0,5°`,
`0x0e`/`0x71` minute = `m·6° + s·0,1°`, `0x12`/`0x72` seconde = `s·6°` (✅ confirmé par désassemblage
des getters, repli RTC 10:10:30).

### Santé / capteurs / météo — ⚠️ contesté, lisez la colonne de preuves

| id | signification (meilleure lecture actuelle) | preuves |
|---|---|---|
| `0x19` | **pas** | dans le menu d'emplacement du 368 aux côtés de `0x1a` ; correspond au `parse.ts` de ce dépôt |
| `0x1a` | **fréquence cardiaque** | dans le menu d'emplacement du 368 aux côtés de `0x5f` et `0x19` |
| `0x1c` | calories | menu d'emplacement, icône de flamme dans l'application compagnon |
| `0x1e` | calories (alias) | corpus |
| `0x22` / `0x23` | distance km / mi (partie entière) | corpus |
| `0x74` / `0x75` | distance km / mi (partie fractionnaire) | corpus |
| `0x76` | distance (forme d'emplacement) | menu d'emplacement, icône de route |
| `0x24` | **% de batterie** | menu d'emplacement, icône d'éclair |
| `0x30` | % de batterie | corpus |
| `0x36` / `0x5f` | température | `0x5f` = menu d'emplacement, icône nuage-soleil ; 361 TempoG lie un nombre simple |
| `0x48` | stations debout (heures debout) | menu d'emplacement, icône de figure debout |
| `0x8b` | IQA | menu d'emplacement |
| `0x73` | drapeau 24h / unités métriques | corpus |
| `0x25`–`0x27`, `0x49`, `0x6c`, `0x6f` | % d'objectif / alias d'emplacement des pas et calories | corpus |
| `0x6a` | ⚠️ métrique d'emplacement non identifiée | apparaît dans 4 menus d'emplacement |
| `0x79 + slotIndex` | **synthétique** — pas une métrique ; l'id de sélection d'emplacement (§11.13) | ✅ §11.13 |

> ⚠️ **Trois tables de ce dépôt étaient en désaccord ; celle-ci est la réconciliation.** Les révisions antérieures du §16
> et du §11.5 lisaient `0x19` comme fréquence cardiaque, `0x1b` comme batterie, `0x24` comme température et `0x36` comme pas —
> et `wfweb/src/codec/mock.ts` encode encore cette lecture, tandis que `wfweb/src/codec/parse.ts` encode une
> lecture différente (`0x19` pas, `0x24` % d'objectif, `0x48` stations debout, `0x1a` météo). Le tableau ci-dessus suit
> la lecture la mieux étayée (étiquettes calibrées par fmc contre les icônes du menu d'emplacement de widgets de l'application compagnon, voir §Sources). **Le code n'a pas encore été modifié — `mock.ts` et `parse.ts` sont toujours
> incohérents entre eux et avec ce tableau.** Traitez les étiquettes d'ids de santé comme ⚠️ jusqu'à ce que quelqu'un lie
> un champ à chaque id et lise la montre.
>
> La preuve unique la plus solide est **le menu d'emplacement du cadran 368 Function** (§11.13), qui propose
> `0x5f 0x1c 0x19 0x48 0x24 0x76 0x1a 0x8b` comme **huit métriques distinctes sélectionnables par l'utilisateur** dans un seul menu.
> Quelles que soient les étiquettes, deux de ces huit ne peuvent pas être la même métrique — ce qui exclut
> `0x19` = `0x1a` = fréquence cardiaque et `0x24` = `0x5f` = température simultanément.

Les complications d'anneau/arc avec une **feuille de cadres** indexent un cadre pré-rendu (par ex. 50 % = cadre 50 sur 100)
intégré dans le `.bin` que vous envoyez (§11.5), donc aucun pack RES externe n'est nécessaire ; les anneaux sans image sont dessinés
à partir de la spécification d'arc à la place (§11.15).

---

### Cartes rapides (tuiles d'accueil) — `QUICK_CARD (906D)` ✅

Les tuiles d'accueil de la montre. Le téléphone choisit seulement **quelles** tuiles afficher et dans **quel ordre** — les tuiles sont
rendues par le firmware (pas de canal de contenu). Premier octet de charge utile = sous-commande : `00` = GET, `01` =
SET ; **les deux utilisent `0x906D`** (`0x906C` est listé mais non utilisé — l'interroger expire). Réponse = `A06D`.

> 🛑 Envoyer un `assemblyId` inventé **efface les écrans de la montre** (elle accepte la liste, ne peut pas faire correspondre
> les ids, n'affiche rien). N'envoyez que des ids que vous **relisez** via GET ; récupérez via l'application officielle ou une
> réinitialisation d'usine.

**Réponse GET** ✅ : `statut(1) ‖ 00 ‖ N(1) ‖ N × groupe`, groupe = `tag=01 ‖ K(1) ‖ K×(assemblyId, sportId)`.
Trame réelle : `01 00 04  01 02 5d00 6100  01 03 1900 2e00 2300  01 03 5c00 0400 5a02  01 03 4800 5100 5300`
= 4 écrans / 11 cartes (`5a02` = carte Sport, sportId 2).

**Emplacements :** chaque écran a **4 emplacements**. Le type d'une carte définit sa taille — `circulaire`/`carré` = 1 emplacement,
`rectangle` = 2 emplacements. La validation est une simple arithmétique d'emplacements (Σ ≤ 4 par écran) ; aucune carte
mutuellement exclusive. `sportId` est `0` sauf sur les cartes Sport (87–91). Les ids `64` et `95` n'existent pas.

**Catalogue `assemblyId`** (chaque type logique = une plage contiguë de 6 variantes de style `_0`..`_5` ;
`0` = emplacement vide) :

| déc | carte | déc | carte |
|----|----|----|----|
| 0 | emplacement vide | 49–53,97–98 | Météo |
| 1–6 | Pas | 54–58 | Minuteur |
| 7–12 | Calories | 59–62 | Respiration |
| 13–18 | Station debout | 63,65–67 | Chronomètre |
| 19–24 | Activité modérée | 68–71 | Batterie |
| 25–30 | Fréquence cardiaque | 72–76 | Récents |
| 31–36 | SpO₂ | 77–81 | Contacts |
| 37–42 | Stress | 82–86 | Cadran / téléphone |
| 43–48 | Sommeil | 87–91 | Sport (`sportId` ≠ 0) |
| 92 | Musique | 93/94/96 | Enregistrement d'activité / PAI / Cycle |

---

## Annexe A. Catalogue des cadrans de série (id → nom)

Le §11 fait référence aux cadrans par id numérique tout au long (275 SlopeTime, 322 Glare 2, 357 Silhouette, …). Les ids
`273`–`376` sont les faces du magasin/de série ; l'id est ce que `DIAL_COMMAND (9055/a055)` signale comme actif et
ce que `9075` prend comme `old_id` (§11.4). 100 des 103 ids connus sont nommés ci-dessous ; les restants sont des
stubs ROM (§11.4). Noms et regroupement tels qu'affichés par l'application compagnon officielle.

- **Par défaut** (6) — `273` Activity Mood · `274` Sun Circle · `275` SlopeTime · `276` Dichotomy · `277` Prismatic Time · `280` Multifunction
- **Analogique** (34) — `286` Sundial · `287` Simple Dial · `292` City · `294` Sudoku · `305` Dots · `306` Large Number · `309` Gradient · `310` Glare · `311` Bold · `313` Classical · `314` Fragment · `315` Infinite · `316` Trailing · `322` Glare 2 · `326` Chrono Master · `327` Digit Max · `328` Coherent · `329` Wheel · `330` Zenith · `331` Intersection · `335` Time Phase · `336` Energetic · `338` Chronos · `341` Dual View · `346` Time Windmill · `347` Large Panel · `349` Theatre · `352` Elegant Sweep · `360` Explorer · `364` SportPulse · `370` Hemisphere · `371` ActiveTrio · `372` Time Wheel · `373` Traditional Pointer
- **Numérique** (41) — `281` Metaball · `282` Radar Sweep · `283` Radio · `285` Widgets · `288` Type · `289` Rotate · `290` Gradual · `291` Vertical · `293` Stairs · `296` Ladder · `297` Ray · `298` Eclectic · `299` Echo · `300` Mono Dial · `301` Orbit · `302` Calendar · `303` Space · `307` Sprung · `308` Sundial 2 · `319` One Line · `320` Orienteer · `321` Revolution · `323` Dash · `324` Finesse · `325` Metric · `333` Circularity · `334` Globe of Time · `337` Time Finder · `339` Suprematism · `340` Sport Mode · `345` Time Dot · `350` Timeline · `351` Cyclopes · `353` Dual phase · `357` Silhouette · `359` Ring data · `361` TempoG · `362` Steady · `365` Elegance · `369` Solar System · `376` Digits time
- **Multifonction** (10) — `304` Elaborate 2 · `344` InfoMeter · `348` Tumbler · `354` Dual · `363` Vintage · `366` Combo · `367` Complex Figure · `368` Function · `374` Cirquary · `375` InfoHub
- **Créatif** (8) — `284` Square · `312` Disc · `317` Disc 2 · `318` Dominos · `332` Flux · `342` Perfect Match · `343` Progress Day · `358` Asteroid
- **Diwali** (1) — `295` Vortex

---

## Sources

Les dispositions d'octets ci-dessus ont été reconstruites à partir du firmware (1.0.0.73), de l'APK officiel (3.5.7) et de
captures en direct déchiffrées contre un appareil réel. L'implémentation de référence de ce projet vit dans
`core-rust/src/{commands,frame,crypto,health,session}.rs` (Rust), l'éditeur TypeScript `wfweb/`, et
les outils Python `cmftool/` (`pair.py`, `session.py`, `wf_codec.py`, `upload_custom.py`, …).

**Travail indépendant incorporé ici.** [freethinkel/fmc](https://github.com/freethinkel/fmc) — un
éditeur de cadrans SvelteKit + marché pour la même montre — a indépendamment rétro-ingénié le
format `.bin` à partir d'un corpus d'environ 100 faces et a atteint plusieurs résultats que ce document manquait ou avait
faux. Leurs `docs/cmf-protocol.md`, `src/lib/modules/editor/lib/{wf,render}.ts` et
`src/lib/modules/device/lib/ble.ts` valent la peine d'être lus directement. Résultats adoptés, chacun re-vérifié
contre les octets de cadran avant d'être rédigé ici :

| Résultat | Où | Statut ici |
|---|---|---|
| Les deux mots d'en-tête sont CRC32 (variante non standard) | §11.4 | ✅ re-vérifié 9/9 cadrans ; **corrige** « pas de somme de contrôle bloquante » |
| Conditions de visibilité, tag `0x02` | §11.12 | ✅ re-vérifié ; était non documenté |
| Liste de métriques d'emplacement + `activeIdx` par défaut, `0x79 + slotIndex` | §11.13 | ✅ re-vérifié sur 275/368/273/304 ; **remplace** §11.8 |
| Drapeau de capacité de teinte d'accent `meta[7] == 4` | §11.14 | ✅ prévalence re-vérifiée ; était non documenté |
| Spécification complète d'arc (angles de balayage, largeur, rayon) | §11.15 | ✅ re-vérifié ; **corrige** « `max` u16 `@+4` » |
| Les `u16` de fin de réf sont des tailles de blocs, pas des ids de glyphes | §11.11 | ✅ re-vérifié exactement sur un atlas de 10 glyphes |
| Pied de page de 36 octets ; variante d'octet magique `0x02` ; `0x86` = 64 B ; aperçu intégré `0x28` | §11.4, §11.11 | ✅ re-vérifié |
| Étiquettes d'ids santé/météo calibrées contre le menu d'emplacement de l'application compagnon | §16 | ⚠️ adopté comme meilleure lecture ; conflits signalés |
| L'UUID du service shell est `77d4e67c-…`, et la portée `optionalServices` de Web Bluetooth | §1 | ⚠️ rapport mono-unité, non re-vérifié ici |
| L'id de nombre partagé avec un anneau affiche un pourcentage | §11.15 | 🟡 signalé, **non** vérifié ici |
| Catalogue id → nom des cadrans de série | Annexe A | ✅ adopté tel quel |