- `cmd1`/`cmd2` juntos formam o **opcode** (ver §6). 🔎 confirmado no construtor de frames do app oficial (`C6117b.m30831g`).
- `chunkCount` = total de chunks para este comando; `chunkIndex` é **baseado em 1**.
- `chunkLen` = número de bytes de `chunk` neste frame.
- Uma única escrita BLE pode ser fragmentada pelo MTU do link; o receptor armazena os bytes brutos e re-extrai frames completos. Payloads grandes são divididos em múltiplos chunks (mesmo `cmd1/cmd2`, com `chunkIndex` crescente) e remontados em ordem.

### Convenção de opcode (✅ confirmado no wire)

- `cmd1 = 0xFFFF`: `cmd2` em `0x80xx`/`0x90xx` = telefone→relógio (requisição/definição); `0x00xx`/`0xa0xx` = relógio→telefone (resposta). Os pares correspondem pelo byte baixo (`0x9055`↔`0xa055`, `0x8051`↔`0x0051`).
- `cmd1` específico de funcionalidade: sufixo de `cmd2` = `0x0001` **SET**, `0x0002` **GET**, `0x0003` **ACK**.

### Corpo do chunk

Para cada chunk, o corpo é `payloadPiece ‖ CRC32_LE(payloadPiece)` (CRC de 4 bytes, little-endian, zlib/IEEE). Se o comando for **criptografado** (ver §3), todo o `payloadPiece ‖ CRC` é então criptografado com AES-128-CBC/PKCS7 e esse ciphertext torna-se o `chunk` do frame.

**Peculiaridade do plaintext:** para opcodes em plaintext, o relógio *conta* o CRC de 4 bytes em `chunkLen`, mas **não** o transmite. Portanto, ao decodificar um frame em plaintext, o comprimento real dos dados é `chunkLen − 4`. (Frames criptografados carregam o CRC dentro do ciphertext, como de costume.)

Dimensionamento do chunk (para que chunks criptografados caiam em limites de bloco AES), com `maxWrite = mtu − 3`:
- criptografado: `floor((maxWrite − 11) / 16) * 16 − 4 − 1`
- plaintext: `maxWrite − 11 − 4 − 1`

✅ Todos os valores de `chunkLen` observados em frames criptografados eram múltiplos de 16 (o alinhamento de bloco é mantido).

---

## 3. Primitivas criptográficas

- **AES-128-CBC** com preenchimento **PKCS7** e um **IV fixo** (do firmware `CmfCharacteristic.AES_IV`):
  `50 51 52 53 54 55 56 57 60 61 62 63 64 65 66 5A`.
- **CRC32** (zlib/IEEE), emitido como 4 bytes little-endian.
- **SHA-256** sobre a concatenação das partes.

Derivação de chave:```
authkey      = SHA256( rnd1 ‖ rnd2 ‖ secret )[0..16]      // persisted across sessions
sessionKey   = SHA256( nonce ‖ authkey )[0..16]           // per connection

Em `AUTH_FAILED (0xFFFF,0xA061)` ou incompatibilidade de assinatura, a autenticação falha.

### 4.2 Reconexão (authkey já conhecida)```
        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` = ativado e guardado; `0a` = guardado mas **não** ativado / rejeitado. No
Android, cada `DATA_CHUNK_WRITE` tem de sair como **uma escrita BLE por frame** — concatenar e
voltar a fatiar por MTU dessincroniza os cabeçalhos e o relógio fica em loop a pedir o offset 0.

- **`9063` (foto) = APPEND.** A lista de mostradores cresce (6→7); `watchfaceId = 0xFFFFFFFF` (sentinel
  personalizado) para nunca ser rejeitado como duplicado, e o relógio ativa-o automaticamente.
- **`9075` (estruturado) = SUBSTITUI** o slot `old_id`. O `old_id` **tem** de já estar na lista
  (caso contrário `0a`). Para reinstalar um id já presente, **apague-o primeiro** (9055 lista-menos-id)
  e depois carregue "de novo" — reutilizar um id no lugar dá `0a`.

### 11.3 Mostrador de foto / personalizado — ✅ totalmente validado de ponta a ponta

**Contentor** (round-trip verificado por byte; todos os campos 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` = comprimento exato do `.bin`; `FFFFFFFF` = `watchfaceId` personalizado; `styleId` 0–4 seleciona o layout
de relógio digital integrado (é sempre desenhado — não há opção "desligado"); `posX/posY` posicionam-no (valores
conhecidos como bons: 56 / 77); `color565` aplica-lhe uma tonalidade (ex.: `FFFF` = branco). ⚠️ A forma mais curta
`A5 ‖ size ‖ watchfaceId` é **rejeitada** com o finish `0a` — use o cabeçalho completo acima. (Implementação de
referência: `core-rust/engine.rs::build_wf_init2`, espelhando `C6135t.m31104u` na aplicação oficial.)

**Receita:** redimensionar a imagem para 466×466 (e uma miniatura de 270×270), converter para RGB565-LE de cima
para baixo, opcionalmente zerar os pixels fora do círculo, comprimir cada uma com LZ4, montar o contentor acima e
carregar através do pipeline `9063` com `watchfaceId = 0xFFFFFFFF`. (Codec de referência: `core-rust/watchface.rs`,
`work/codec_dfa.py`.)

### 11.4 Mostrador estruturado / de loja — contentor e codecs ✅

**Estrutura do ficheiro** — o cabeçalho de 36 bytes é repetido **byte a byte de forma idêntica como um rodapé de 36 bytes** no EOF
(✅ verificado em 15 mostradores; um analisador deve rejeitar um ficheiro onde estes difiram):```
[36-byte header][scene TLV (§11.7)][asset pool][36-byte header again]

> ⚠️ **Correção (substitui "não há checksum de bloqueio").** Revisões anteriores liam `@0x00` como um
> id/hash por dialeto e `@0x20` como "3× palavras u32 de id/hash \[não um CRC]", e afirmavam que CRC32/Adler32/
> soma de bytes falhavam todos na correspondência. Ambas as palavras **são** CRC32 — os testes anteriores não as detectaram porque a
> variante é não padronizada, e porque a leitura de "3 palavras em `0x20`" confundia a única palavra
> CRC com os primeiros bytes do contêiner de cena que começa em `0x24` (da mesma forma, "nome repetido em
> `0x2c`" é o nó de nome `0x86` da cena, §11.11). Descoberta de
> [freethinkel/fmc](https://github.com/freethinkel/fmc); reverificada aqui.

**CRC32-raw** = polinômio IEEE refletido `0xEDB88320`, **`init = 0`**, e **sem XOR final** — ou seja,
nem o `init=0xFFFFFFFF` nem o `^0xFFFFFFFF` do `crc32` padrão. Essa é exatamente a razão pela qual
o CRC32 pronto para uso nunca correspondeu. Observe a dependência de ordem: `crc_assets` fica dentro do intervalo
coberto por `crc_tree`, então **escreva `@0x20` primeiro, depois calcule `@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 ativo atual (de `9055`); `file_len` = tamanho real do `.bin`
(= `@0x18 + 36`). Instalar um `.bin` de loja como está é o caminho garantido (Ring Data id 359 +
102 outros confirmados). (Referência: `core-rust/engine.rs::build_dial_replace_init`.)

### 11.5 Gramática estruturada de diretório ✅ (decodificada e implementada — REVISADO 2026-07-02)

> **⚠️ Revisão (2026-07-02): o esquema de registro plano `61 01 00` abaixo estava sistematicamente
> OFF-BY-ONE.** O corpo da cena é um TLV limpo (§11.7); um **corpo de folha** desenhável (tags `0x30`/`0x38`
> estáticas, ponteiro `0x70`) é:
>
> ```
> 01 xx 00 [X u16][Y u16] …attrs… 61 [count u16][base u32][count×id u16] [05 05 00 01 pivX pivY]
> ```
>
> - o atributo `0x01` abre o corpo: **X,Y = canto superior esquerdo** na tela 466² (o `s16 x,y` do
>   `sty_picture_t` do SDK).
> - a **tabela de quadros `61 …` fecha o corpo** (`base` = ptr do asset; `count` 1 = imagem, 10/11 =
>   atlas de dígitos — o antigo "tipo de registro `0a/0b`" era na verdade essa contagem! — 7/13/2 =
>   folha de quadros de complicação).
> - extras de ponteiro: origem+escala `[src] 00 3c 00` dentro do atributo `0x01`; pivô no
>   **trailer** `05 05 00 01 [pivX][pivY]`. **Centro de rotação = `(X+pivX, Y+pivY)` por ponteiro** —
>   não um (233,233) fixo: existem subdials descentralizados (ex.: os ponteiros do dial 366 giram em torno de 150,150).
>
> A varredura linear por `61 01 00` estava costurando a tabela de quadros+pivô do elemento **N** ao X/Y
> (e byte de tag, o antigo "f3") do elemento **N+1** — só *parecia* correto em dials analógicos cujos
> ponteiros adjacentes compartilham geometria quase idêntica. A "parede de variante compacta" (spec 24 §24.4.5) era
> esse mesmo erro de leitura. Implementado como `scan_scene_drawables` em `core-rust/watchface_struct.rs`
> e `wfweb/src/codec/parse.ts` (cena = fonte primária para imagens/ponteiros; varredura plana mantida para
> texto + fallback sem envelope). Validado pelo oráculo `wfweb/compare.html` (render vs PNGs oficiais da loja, 99 dials): 64→72 bons, 8→5 ruins, diff média 9.3→7.4%.

Leitura histórica de registro plano (substituída, mantida para contexto):

- **Imagem estática** (`61 01 00`): `asset_ptr(u32) ‖ elemId(u16) ‖ 05 05 00 01 ‖ pivotX(u16) ‖
  pivotY(u16) ‖ 3B ‖ 01 ‖ 1b 00 ‖ X(u16) ‖ Y(u16)`. Canto superior esquerdo na tela 466² = `(X−pivotX, Y−pivotY)`.
- **Ponteiro/agulha** — mesmo registro de imagem, rotacionado em tempo de execução. **Centro de rotação = `(X+pivotX, Y+pivotY)`**
  (≈ 233,233 em dials analógicos). A **fonte de dados é um `u8` no offset `+36` do registro**, escala `u16` em
  `+38` (=60): `0x0a`/`0x70` = hora (`h·30°+m·0.5°`), `0x0e`/`0x71` = minuto (`m·6°+s·0.1°`),
  `0x12`/`0x72` = segundo (`s·6°`). ✅ confirmado por desmontagem dos getters (fallback RTC 10:10:30).
- **Widget de texto/número** (`61 0a 00`): `asset_ptr(u32) ‖ [10×u16 métricas de fonte] ‖ 40 01 00 ‖ flag ‖
  3B ‖ 01 ‖ u16 ‖ X(u16) ‖ Y(u16)`. `asset_ptr` aponta para o glifo "0"; dígito *d* = o asset em
  `index("0") + d` (10 sprites cf=5 consecutivos, ex.: `0123456789` e pontuação `,°`). ✅ renderizado.
- **Preenchimento de complicação = índice de quadro** (✅ confirmado para complicações de dígito/enum/medidor, count>1): o
  valor indexa uma **folha de quadros pré-renderizada** no `.bin` — `frame = (count−1)·val/100` (percentual) ou
  `frame = value` (dígito flip / enum). Tabela de quadros = sub-registro `61 ‖ count(u16) ‖ base(u32) ‖
  count×id(u16)`. Ex.: a hora grande do 327 Digit Max é uma folha de 13 quadros (números 0–12), `frame = hour`.
- **Anel/arco de progresso = recorte de setor em tempo de execução** (✅ 2026-07-02, **corrige a leitura "anéis são folhas de quadros"
  na spec 25 §2**): a tag de elemento **`0x81`** carrega um **único** disco completo (`61` tabela de quadros
  `count == 1`), e a cunha parcial é esse disco **recortado em um setor de pizza** (`frac = value/max`,
  no sentido horário a partir das 12 horas) — verificado pixel por pixel no 322 Glare 2 e confirmado `count==1` em
  **20 dials**. No disco: corpo `0x81` = sub `0x01` (geometria `x@+0 y@+2 w@+4 h@+6`, `61 1 base` inline
  = disco) + sub `0x5b` (spec de arco). Implementado no wfweb (`blendSector`).
  ⚠️ O sub-registro `0x5b` **não** é apenas "`max` u16 `@+4`" como documentado anteriormente — isso lia a
  metade baixa de um `max i32` e perdia os **ângulos de varredura inicial/final e a largura do traço** que ficam logo
  depois. Há também um irmão procedural `0x80`/`0x5a` (com raio explícito) que este
  documento nunca cobriu. Layout completo do registro, e o que a suposição anterior "sentido horário a partir das 12 horas"
  errou: **§11.15**.
- **Id da fonte de dados** — o bloco de atributos `82` do elemento fica em `delim+3` (após o último `40 01 00`),
  e o **id da fonte é um `u8` em `+0x14`** (também `relX@+0x07 s16`, `relY@+0x09 s16`, `anchor@+0x0C/0E`,
  `mode@+0x15`, `frame-count@+0x1A`). Anchor < 0 = alinhar à borda do pai. 🔎 O firmware resolve
  o id por meio de uma tabela de getters de 142 entradas em `0x101f371c` (cada uma chama `ux2sys_get(type)`).
  ⚠️ **Prefira ler o id como `meta[9]` da struct (§11.11)** — um campo fixo — em vez desta varredura
  de `82`-attr para frente, que é a fonte do off-by-one descrito em §11.8/§11.9. Tabela completa de ids em §16; observe
  que os rótulos de saúde/clima que esta seção listava inline anteriormente (`0x19` FC, `0x1b` bateria,
  `0x24` temperatura, `0x36` passos) são **contestados e provavelmente errados** — veja a caixa ⚠️ em §16.
  (O exemplo de grupo `0x07:0x0b:0x0f` = HH:MM:SS abaixo não é afetado.)
- **Nó de grupo** (`0x68`): aninha seus filhos dentro do próprio corpo TLV (`0x60` = valor/texto,
  `0x30` = estático); cada `0x60` carrega seu id de fonte em `data+16`. Ex.: um grupo `0x07:0x0b:0x0f` =
  relógio HH:MM:SS. Parser de elemento TLV = `0x100db55c` (tabela de salto indexada por `tag−0x70`).

### 11.6 Matriz de autoria

| Caminho | Status | Notas |
|---|---|---|
| Dial de foto a partir de qualquer imagem | ✅ **feito** | §11.3; validado no dispositivo |
| Instalar qualquer um dos 103 dials da loja | ✅ **feito** | §11.4; `9075`, `old_id`=ativo |
| Revestir o fundo cf=4 de um dial da loja | ✅ **funciona ao vivo** | trocar o payload COMPLETO no lugar, definir o `len` do asset para o **novo** tamanho de bloco (≤ antigo), manter a mesma pegada de arquivo, instalação limpa |
| Re-autorar por modelagem (trocar pixels de qualquer camada + mover geometria) | ✅ **renderiza via BLE** | dial 373: bg→ciano + um sprite cf=5→vermelho + X movido 224→100, tudo renderizado, agulhas ao vivo |
| Dial estruturado 100 %-sintético do zero | ✅ **builder feito, validado offline** | builder de envelope `0x20` em `watchface_struct.rs` (`build_container`/`serialize`/`validate_container`); round-trip de todos os 103 dials byte-exato + sintético passa no validador do firmware (§11.7). 🟡 render no dispositivo sobre `9075` ainda não filmado |
| Fontes do sistema (`.font`) | ✅ **decode/render (todas)** | bin LVGL (não proprietário); 32 fontes numéricas (`num*/nm*`, descomprimidas) + 24 fontes de texto (`font*`, LVGL RLE `comp=1`) todas decodificadas — 12208 glifos, 0 estouros, ASCII completo. RLE = LVGL v8.3 `lv_font_fmt_txt.c` (SINGLE/REPEATE/COUNTER de 3 estados + pré-filtro XOR por linha), portado 1:1, sem desmontagem |

⚠️ Armadilhas de revestimento/re-autoria que causam tela preta ou `0a`: deixar o **`len` antigo do asset** (o
relógio lê além do bloco → estouro → preto); **aumentar o arquivo** (rejeitado na instalação); reutilizar um
id **no lugar** em vez de uma instalação limpa; **reordenar assets** sem corrigir a cadeia de tamanho de bloco da cauda de referência
(§11.11). Não é fatal hoje, mas escreva corretamente de qualquer forma: qualquer mudança na cena ou no pool de assets
invalida as duas palavras **CRC32** do cabeçalho — recalcule ambas (§11.4), `@0x20` antes de `@0x00`.

### 11.7 O envelope de cena `0x20` — decodificado e builder implementado ✅

Um dial **real** re-autorado renderiza porque preserva o envelope de cena do arquivo. Um corpo puramente sintético
de registros planos `61 …` é **rejeitado** — o parser do firmware (`WFManager_Parser`, `0xdb35c`)
exige que o corpo (do offset `0x24`) comece com um contêiner de cena `0x20`. O arquivo completo é:```
[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

> ✅ Isto unifica os "offsets mágicos" das §11.5/§11.8/§11.9. Essas seções localizam campos *relativos
> ao byte `0x61` da tabela de frames* — que é simplesmente `+0x12` desta struct, portanto `−18`/`−16` = `x`/`y` e
> **`−5` = `meta[9]`, o id da fonte**. Mesmos bytes, um layout limpo. A heurística de varredura direta do atributo `82`
> que estava sistematicamente deslocada por um não é necessária: leia `meta[9]` da struct.
> O `max` de um campo numérico é igualmente apenas `meta[11..13]` (por exemplo, campos de dia do mês carregam `max = 99`).

**Cauda de ref** (`61`) — como um nó aponta para seus 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` é um id de fonte de dados (§16) — incluindo os **ids de slot sintéticos** do §11.13. Operadores, com
contagens de ocorrência medidas em 15 mostradores:

| op | significado | visto |
|---|---|---|
| `0x01` | desenhar se `value == val` | 99 |
| `0x81` | igual a `0x01` (bit `0x80` definido — aparece em variantes mutuamente exclusivas) | 48 |
| `0x02` | **ocultar** se `value == val` | 7 |
| `0x03` | desenhar se `value == val`, onde `val` é um marcador de **sem dados** (ex.: HR `1000`) | 13 |
| `0x05` | desenhar se `value >= val` | 58 |
| `0x06` | desenhar se `value <= val` | 50 |
| `0x04` | ⚠️ **desconhecido** — 15 ocorrências, sem semântica confirmada | 15 |

Regra de combinação (conforme implementada pelo renderizador de referência, máscara `op & 0x7f`): as entradas
de igualdade são combinadas com **OR**, e depois as entradas de ocultar/`>=`/`<=` devem **todas** ser válidas.

Este único mecanismo cobre a maior parte da variabilidade em tempo de execução do formato e explica estruturas que parecem
widgets duplicados:

- **Layouts 12h / 24h e métrico / imperial** — dois conjuntos de widgets empilhados no mesmo ponto, cada um vinculado a
  `id 0x73` (o sinalizador de unidades) com `val` 0 ou 1. O mostrador 275 tem seis desses pares (12 nós).
- **Espaços reservados de "sem dados"** — op `0x03` contra um sentinela, ex.: `id 0x5f, val 1000` (mostrador 275, duas vezes):
  desenha a arte de travessão em vez de uma temperatura quando a métrica não está disponível.
- **Destaques em intervalos** — um intervalo pareado `0x05`/`0x06`, ex.: a corrente do Metaball onde cada elo acende
  para sua própria janela de 5 minutos.
- **Alternativas de slots de complicação** — vinculadas aos ids de slot sintéticos do §11.13.

### 11.13 Slots de complicação configuráveis — `0x85` + `0x5f` ✅ (substitui §11.8)

O §11.8 concluiu que a métrica ativa de uma complicação configurável é estado de RAM do dispositivo e não poderia ser
recuperada do arquivo. **Isso estava errado** — tanto o menu de métricas do slot quanto sua seleção padrão
estão no `.bin`. Cada nó `0x85` carrega um irmão `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

O emparelhamento é rígido: `0x80` carrega sempre exatamente `0x01` + um **`0x5a` de 19 bytes**, `0x81` sempre exatamente
`0x01` + um **`0x5b` de 17 bytes** (✅ 26/26 anéis em 15 mostradores). ⚠️ Mas o **`0x81` recortado por imagem
domina** — 25 desses 26. A variante processual `0x80`/`0x5a` apareceu **uma vez** (mostrador 273), então seu
campo `radius` e layout de 19 bytes dependem de uma única amostra; trate com suspeita até ser visto novamente.

`frac = clamp((valor − min) / (max − min), 0, 1)`, e o arco preenchido vai de `start` em direção a `end`.
O ângulo zero está às **3 horas**, positivo no sentido horário. Exemplos medidos:

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

> ⚠️ **Isto corrige a suposição "sentido horário a partir das 12 horas"** na §11.5. Esse é apenas o caso
> especial `start = 0, end = 3600` (uma varredura completa, onde a convenção é inobservável). Mostradores reais usam
> **medidores parciais** (o leque de ±102,8° do 273, o anel de três quartos de 270° do 366) e **varreduras negativas**
> (60° → −120° do 276), então um renderizador que sempre varre um círculo completo a partir do topo desenha esses errado.
> 🟡 A convenção exata de ângulo zero e a regra de direção vêm do renderizador do fmc, verificadas de forma cruzada
> contra esses valores em disco — não verificadas de forma independente pixel por pixel no dispositivo por este repositório.
> Observe que `frac = valor/max` e o recorte de setor `0x81` na §11.5 **foram** validados (mostrador 322).

⚠️ **Não resolvido: o trailer de 3 bytes `01 00 kk`.** `kk` assume valores de aparência plausível (104, 152, 216,
232, 248) e a hipótese óbvia é um raio — **testada e refutada**: o mostrador 366 usa `kk = 104`
para um anel de 82×82 e um de 166×166, e o mostrador 273 usa `kk = 232` para um anel de 440×440 e um de 284×284.
Não é um raio, não é um diâmetro. Possivelmente opacidade/estilo. Faça o round-trip verbatim.

🟡 **Pegadinha relatada, não verificada aqui:** no renderizador do fmc, um número `0x60` cujo id de origem seja igual ao
id de **qualquer** anel na mesma tela renderiza `round(frac × 100)` em vez do valor bruto — então um
número de frequência cardíaca ao lado de um anel de frequência cardíaca mostra `36` em vez de `71 bpm`. A
solução documentada por eles é colocar o anel e o número em dois ids **alias** da mesma métrica (passos
`0x19`/`0x26`/`0x49`, calorias `0x1c`/`0x1e`/`0x48`). Se isso é comportamento do firmware ou específico
do renderizador deles **não está estabelecido** — vale uma verificação ao vivo antes de projetar em torno disso.

---

## 12. Detalhes de transferência em massa e OTA

A tabela de transferência está na §6. Pontos adicionais confirmados:

- **AGPS/EPO** ✅: o primeiro bloco gravado começa com o cabeçalho ASCII `000000010000…`. O loop completo
  init → `[A05F ↔ 905F]×N` → finish foi observado no fio (~892 blocos).
- **OTA de firmware** (`9040`–`9042`, finish `9041`) 🔎: estrutura mapeada; payload INIT2 = bytes de versão
  (ex.: `0b 00 00 39` = 11.0.0.57). **Não testado em campo** (o app desativa a atualização de FW aqui). As imagens
  de firmware parecem ser **não assinadas — a integridade é apenas CRC32** (nenhuma assinatura assimétrica observada na RE).
- ⚠️ Como OTA e `FACTORY_RESET (009A 0001)` compartilham a sessão autenticada, uma única autenticação BLE
  válida é suficiente para apagar ou (em princípio) brickar o relógio. Manuseie com cuidado.

---

## 13. Sensores

✅ Hardware exposto via BLE:

- **PPG óptico** — frequência cardíaca (manual/automático/treino/repouso), SpO₂ e estresse derivado de VFC.
- **Acelerômetro de 3 eixos** — passos, distância, calorias, estágios do sono, levantar o pulso, cadência.
- **GNSS/GPS** (assistido por AGPS) — trilha de treino (`WORKOUT_GPS`) e envio de localização (`GPS_PUSH`).

**Não há** barômetro/altímetro, bússola, giroscópio ou sensor de temperatura de pele/corpo. Um termistor
NTC interno (temperatura da placa/bateria) existe, mas é legível **apenas** pelo canal AT
(`AT GETNTCTEMP`, §14) — o fluxo de histórico de temperatura da pele `0155` está vazio neste SKU.

**Sequestros de widget de dados** (não há API real de complicação/vinculação de dados — veja §11.5): os
campos de texto existentes do relógio podem ser reaproveitados para mostrar dados externos de relance. Comprovado ✅: a string
de **cidade do clima** (`WEATHER_SET_1`, ex.: `"BRA 2x1 ARG"` apareceu no widget) e os campos de **faixa/artista**
de música; a lista de **contatos** (20 × nome[32]+número[25]) funciona como um painel de dados rolável. Todos são
envios, não complicações persistentes.

---

## 14. Canal AT de fábrica / shell (`77d4ff01` / `77d4ff02`)

Um canal de comandos AT em texto puro separado, independente do protocolo enquadrado. ✅ testado ao vivo:

- **Leitura:** `AT GETSECRET` (segredo de emparelhamento de 16 bytes), `GETVERSION`, `GETSN`, `GETNAME`, `GETPID`,
  `GETBATLV` (mV bruto, ex.: `3853mv`), `GETGSENSOR` (aceleração bruta em g, `X=… Y=… Z=…`),
  `GETNTCTEMP` (°C, NTC interno).
- **Escrita / atuação:** `AT SETMOTOR=1` (vibrar o motor), `SETHR/SETHRV/SETSPO2=…` (injeção de teste
  de sensor), `SETLCDSWITCH/SETGPSSWITCH/SETKEYSWITCH`.

As respostas terminam em `,OK`. Comandos `SET*` geralmente executam, mas podem não ecoar `,OK` via BLE — confirme
caso a caso.

---

## 15. Recursos bloqueados por firmware / indisponíveis (🔎 RE de firmware)

Alguns recursos estão presentes no firmware, mas desabilitados por SKU/região e **não são acessíveis pelo
telefone/BLE** — eles precisam de uma modificação de firmware, que está fora do escopo aqui:

- **Voz ChatGPT** — gate = id de recurso `ux2sys` `0x9e`, semeado de NVRAM/EFUSE/região na inicialização; neste
  SKU o flag de suporte `908b = 00`. Não influenciável por telefone, conta ou BLE (confirmado por
  experimento + RE). O app é apenas um relé; o áudio vai do telefone → nuvem da Nothing.
- **Pressão arterial** — um subsistema completo existe no firmware, desligado por SKU/região.
- **Alipay / pagamento NFC** — UI completa presente, apenas para SKU da China.
- **Ausente em hardware/firmware:** ECG, SOS/emergência, NFC genérico.

---

## 16. Ids de fonte de dados / getter de complicação

Não é necessário para construir um cliente BLE, mas **essencial para criar ou renderizar um mostrador**: este é o valor de
`meta[9]` (§11.11) que vincula um widget a dados ao vivo, o `id` de uma condição de visibilidade (§11.12) e
as entradas do menu de métricas de um slot (§11.13). O firmware o resolve por meio de uma **tabela de despacho de getter
com 142 entradas** em `0x101f371c`, cada entrada chamando `ux2sys_get(type)` (🔎 RE de firmware).

### Hora / data — ✅ bem estabelecido

| id | significado | id | significado |
|---|---|---|---|
| `0x01` | hora (12/24h conforme configuração do dispositivo) | `0x0f`, `0x12` | segundo (suave) |
| `0x04` | hora (24h) | `0x10`, `0x11` | dezenas / unidades de segundo |
| `0x07` | hora (24h forçado) | `0x71`, `0x72` | segundo (tique-taque / ângulo do ponteiro) |
| `0x02`, `0x03` | dezenas / unidades de hora-12h | `0x13` | flag AM/PM (0 = AM, 1 = PM) |
| `0x05`, `0x06`, `0x08`, `0x09` | dezenas / unidades de hora | `0x15`, `0x16` | mês |
| `0x0a`, `0x70` | ângulo do ponteiro de hora | `0x17` | dia do mês |
| `0x0b` | minuto | `0x18` | dia da semana (0 = segunda-feira ⚠️) |
| `0x0c`, `0x0d` | dezenas / unidades de minuto | `0x0e`, `0x71` | ângulo do ponteiro de minuto |

Ids de dezenas/unidades desenham um **único dígito** — um widget vinculado a um deles renderiza um glifo, não o valor
inteiro (mostrador 284 Square). Ids de ângulo de ponteiro (§11.5) são `0x0a`/`0x70` hora = `h·30° + m·0,5°`,
`0x0e`/`0x71` minuto = `m·6° + s·0,1°`, `0x12`/`0x72` segundo = `s·6°` (✅ confirmado pela desmontagem
dos getters, fallback RTC 10:10:30).

### Saúde / sensores / clima — ⚠️ contestado, leia a coluna de evidências

| id | significado (melhor leitura atual) | evidência |
|---|---|---|
| `0x19` | **passos** | no menu de slots do 368 junto com `0x1a`; corresponde ao `parse.ts` deste repositório |
| `0x1a` | **frequência cardíaca** | no menu de slots do 368 junto com `0x5f` e `0x19` |
| `0x1c` | calorias | menu de slots, ícone de chama no app complementar |
| `0x1e` | calorias (alias) | corpus |
| `0x22` / `0x23` | distância km / mi (parte inteira) | corpus |
| `0x74` / `0x75` | distância km / mi (parte fracionária) | corpus |
| `0x76` | distância (forma de slot) | menu de slots, ícone de estrada |
| `0x24` | **% de bateria** | menu de slots, ícone de raio |
| `0x30` | % de bateria | corpus |
| `0x36` / `0x5f` | temperatura | `0x5f` = menu de slots, ícone de nuvem-sol; 361 TempoG vincula um número simples |
| `0x48` | permanências (horas em pé) | menu de slots, ícone de figura em pé |
| `0x8b` | AQI | menu de slots |
| `0x73` | flag de 24h / unidades métricas | corpus |
| `0x25`–`0x27`, `0x49`, `0x6c`, `0x6f` | % de meta / aliases de slot de passos e calorias | corpus |
| `0x6a` | ⚠️ métrica de slot não identificada | aparece em 4 menus de slots |
| `0x79 + slotIndex` | **sintético** — não é uma métrica; o id de seleção de slot (§11.13) | ✅ §11.13 |

> ⚠️ **Três tabelas neste repositório discordavam; esta é a reconciliação.** Revisões anteriores da §16
> e da §11.5 liam `0x19` como frequência cardíaca, `0x1b` como bateria, `0x24` como temperatura e `0x36` como passos —
> e `wfweb/src/codec/mock.ts` ainda codifica essa leitura, enquanto `wfweb/src/codec/parse.ts` codifica uma
> diferente (`0x19` passos, `0x24` % de meta, `0x48` permanências, `0x1a` clima). A tabela acima segue
> a leitura com melhor evidência (rótulos calibrados pelo fmc contra os ícones do menu de slots de widget do próprio app
> complementar, veja §Fontes). **O código ainda não foi alterado — `mock.ts` e `parse.ts` ainda estão
> inconsistentes entre si e com esta tabela.** Trate os rótulos de ids de saúde como ⚠️ até que alguém vincule
> um campo a cada id e leia o relógio.
>
> A evidência individual mais forte é o **menu de slots do mostrador 368 Function** (§11.13), que oferece
> `0x5f 0x1c 0x19 0x48 0x24 0x76 0x1a 0x8b` como **oito métricas distintas selecionáveis pelo usuário** em um menu.
> Quaisquer que sejam os rótulos, nenhum par desses oito pode ser a mesma métrica — o que descarta
> `0x19` = `0x1a` = frequência cardíaca e `0x24` = `0x5f` = temperatura simultaneamente.

Complicações de anel/arco com uma **folha de quadros** indexam um quadro pré-renderizado (ex.: 50 % = quadro 50 de 100)
embutido no `.bin` que você envia (§11.5), então nenhum pacote RES externo é necessário; anéis sem imagem são desenhados
a partir da especificação de arco (§11.15).

---

### Quick-cards (tiles da tela inicial) — `QUICK_CARD (906D)` ✅

Os tiles da tela inicial do relógio. O telefone apenas escolhe **quais** tiles mostrar e em **qual ordem** — os tiles são
renderizados pelo firmware (sem canal de conteúdo). Primeiro byte do payload = sub-comando: `00` = GET, `01` =
SET; **ambos usam `0x906D`** (`0x906C` está listado, mas não é usado — consultá-lo dá timeout). Resposta = `A06D`.

> 🛑 Enviar um `assemblyId` inventado **apaga as telas do relógio** (ele aceita a lista, não consegue corresponder
> aos ids, não mostra nada). Envie apenas ids que você **leu de volta** via GET; recupere via o app oficial ou um
> reset de fábrica.

**Resposta GET** ✅: `status(1) ‖ 00 ‖ N(1) ‖ N × grupo`, grupo = `tag=01 ‖ K(1) ‖ K×(assemblyId, sportId)`.
Quadro real: `01 00 04  01 02 5d00 6100  01 03 1900 2e00 2300  01 03 5c00 0400 5a02  01 03 4800 5100 5300`
= 4 telas / 11 cartões (`5a02` = cartão Sport, sportId 2).

**Slots:** cada tela tem **4 slots**. O tipo de um cartão define seu tamanho — `circular`/`quadrado` = 1 slot,
`retângulo` = 2 slots. A validação é pura aritmética de slots (Σ ≤ 4 por tela); sem cartões mutuamente exclusivos.
`sportId` é `0` exceto em cartões Sport (87–91). Os ids `64` e `95` não existem.

**Catálogo de `assemblyId`** (cada tipo lógico = um intervalo contíguo de 6 variantes de estilo `_0`..`_5`;
`0` = slot vazio):

| dec | cartão | dec | cartão |
|----|----|----|----|
| 0 | slot vazio | 49–53,97–98 | Clima |
| 1–6 | Passos | 54–58 | Timer |
| 7–12 | Calorias | 59–62 | Respiração |
| 13–18 | Permanência | 63,65–67 | Cronômetro |
| 19–24 | Atividade moderada | 68–71 | Bateria |
| 25–30 | Frequência cardíaca | 72–76 | Recentes |
| 31–36 | SpO₂ | 77–81 | Contatos |
| 37–42 | Estresse | 82–86 | Mostrador / telefone |
| 43–48 | Sono | 87–91 | Sport (`sportId` ≠ 0) |
| 92 | Música | 93/94/96 | Registro de atividade / PAI / Ciclo |

---

## Apêndice A. Catálogo de mostradores de estoque (id → nome)

A §11 refere-se a mostradores por id numérico em todo o texto (275 SlopeTime, 322 Glare 2, 357 Silhouette, …). Os ids
`273`–`376` são as faces da loja/estoque; o id é o que `DIAL_COMMAND (9055/a055)` relata como ativo e
o que `9075` aceita como `old_id` (§11.4). 100 dos 103 ids conhecidos estão nomeados abaixo; os restantes são
stubs de ROM (§11.4). Nomes e agrupamento conforme mostrado pelo app complementar oficial.

- **Padrão** (6) — `273` Activity Mood · `274` Sun Circle · `275` SlopeTime · `276` Dichotomy · `277` Prismatic Time · `280` Multifunction
- **Analógico** (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
- **Digital** (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
- **Multifunção** (10) — `304` Elaborate 2 · `344` InfoMeter · `348` Tumbler · `354` Dual · `363` Vintage · `366` Combo · `367` Complex Figure · `368` Function · `374` Cirquary · `375` InfoHub
- **Criativo** (8) — `284` Square · `312` Disc · `317` Disc 2 · `318` Dominos · `332` Flux · `342` Perfect Match · `343` Progress Day · `358` Asteroid
- **Diwali** (1) — `295` Vortex

---

## Fontes

Os layouts de bytes acima foram reconstruídos a partir do firmware (1.0.0.73), do APK oficial (3.5.7) e de
capturas ao vivo descriptografadas contra um dispositivo real. A implementação de referência deste projeto vive em
`core-rust/src/{commands,frame,crypto,health,session}.rs` (Rust), no editor TypeScript `wfweb/` e nas
ferramentas Python `cmftool/` (`pair.py`, `session.py`, `wf_codec.py`, `upload_custom.py`, …).

**Trabalho independente incorporado aqui.** [freethinkel/fmc](https://github.com/freethinkel/fmc) — um
editor de mostradores SvelteKit + marketplace para o mesmo relógio — fez engenharia reversa de forma independente do
formato `.bin` a partir de um corpus de ~100 faces e alcançou vários resultados que este documento não tinha ou tinha
errado. Os `docs/cmf-protocol.md`, `src/lib/modules/editor/lib/{wf,render}.ts` e
`src/lib/modules/device/lib/ble.ts` deles valem a leitura direta. Descobertas adotadas, cada uma re-verificada
contra bytes de mostradores antes de ser escrita aqui:

| Descoberta | Onde | Status aqui |
|---|---|---|
| Ambas as palavras do cabeçalho são CRC32 (variante não padrão) | §11.4 | ✅ re-verificado 9/9 mostradores; **corrige** "sem checksum de bloqueio" |
| Condições de visibilidade, tag `0x02` | §11.12 | ✅ re-verificado; era não documentado |
| Lista de métricas de slot + `activeIdx` padrão, `0x79 + slotIndex` | §11.13 | ✅ re-verificado em 275/368/273/304; **substitui** §11.8 |
| Flag de capacidade de tint de destaque `meta[7] == 4` | §11.14 | ✅ prevalência re-verificada; era não documentado |
| Especificação completa de arco (ângulos de varredura, largura, raio) | §11.15 | ✅ re-verificado; **corrige** "`max` u16 `@+4`" |
| `u16`s da cauda de ref são tamanhos de bloco, não ids de glifo | §11.11 | ✅ re-verificado exato em um atlas de 10 glifos |
| Rodapé de 36 bytes; variante de byte mágico `0x02`; `0x86` = 64 B; pré-visualização embutida `0x28` | §11.4, §11.11 | ✅ re-verificado |
| Rótulos de ids de saúde/clima calibrados contra o menu de slots do app complementar | §16 | ⚠️ adotado como melhor leitura; conflitos sinalizados |
| UUID do serviço shell é `77d4e67c-…`, e escopo de `optionalServices` do Web Bluetooth | §1 | ⚠️ relato de unidade única, não re-verificado aqui |
| Número compartilhando id com anel renderiza uma porcentagem | §11.15 | 🟡 relatado, **não** verificado aqui |
| Catálogo de id → nome de mostradores de estoque | Apêndice A | ✅ adotado como está |