- `cmd1`/`cmd2` bilden zusammen den **Opcode** (siehe §6). 🔎 bestätigt gegen den Frame-Builder der offiziellen App (`C6117b.m30831g`).
- `chunkCount` = Gesamtzahl der Chunks für diesen Befehl; `chunkIndex` ist **1-basiert**.
- `chunkLen` = Anzahl der Bytes von `chunk` in diesem Frame.
- Ein einzelner BLE-Write kann durch die Link-MTU fragmentiert werden; der Empfänger puffert die Rohbytes und extrahiert die vollständigen Frames erneut. Große Payloads werden in mehrere Chunks aufgeteilt (gleiches `cmd1/cmd2`, aufsteigender `chunkIndex`) und in der Reihenfolge wieder zusammengesetzt.

### Opcode-Konvention (✅ im Datenverkehr bestätigt)

- `cmd1 = 0xFFFF`: `cmd2` in `0x80xx`/`0x90xx` = Telefon→Uhr (Anfrage/Setzen); `0x00xx`/`0xa0xx` = Uhr→Telefon (Antwort). Paare stimmen im niederwertigen Byte überein (`0x9055`↔`0xa055`, `0x8051`↔`0x0051`).
- funktionsspezifisches `cmd1`: `cmd2`-Suffix = `0x0001` **SET**, `0x0002` **GET**, `0x0003` **ACK**.

### Chunk-Body

Für jeden Chunk ist der Body `payloadPiece ‖ CRC32_LE(payloadPiece)` (4-Byte-CRC, Little-Endian, zlib/IEEE). Wenn der Befehl **verschlüsselt** ist (siehe §3), wird das gesamte `payloadPiece ‖ CRC` anschließend mit AES-128-CBC/PKCS7 verschlüsselt, und dieser Chiffretext wird zum Frame-`chunk`.

**Klartext-Eigenheit:** Bei Klartext-Opcodes *zählt* die Uhr die 4-Byte-CRC in `chunkLen`, überträgt sie aber **nicht**. Beim Dekodieren eines Klartext-Frames beträgt die tatsächliche Datenlänge also `chunkLen − 4`. (Verschlüsselte Frames tragen die CRC wie üblich innerhalb des Chiffretexts.)

Chunk-Größe (damit verschlüsselte Chunks auf AES-Blockgrenzen landen), mit `maxWrite = mtu − 3`:
- verschlüsselt: `floor((maxWrite − 11) / 16) * 16 − 4 − 1`
- Klartext: `maxWrite − 11 − 4 − 1`

✅ Alle beobachteten `chunkLen`-Werte verschlüsselter Frames waren Vielfache von 16 (Blockausrichtung gilt).

---

## 3. Kryptografische Grundbausteine

- **AES-128-CBC** mit **PKCS7**-Padding und einem **festen IV** (aus der Firmware `CmfCharacteristic.AES_IV`):
  `50 51 52 53 54 55 56 57 60 61 62 63 64 65 66 5A`.
- **CRC32** (zlib/IEEE), ausgegeben als 4 Little-Endian-Bytes.
- **SHA-256** über die Verkettung der Teile.

Schlüsselableitung:```
authkey      = SHA256( rnd1 ‖ rnd2 ‖ secret )[0..16]      // persisted across sessions
sessionKey   = SHA256( nonce ‖ authkey )[0..16]           // per connection

Bei `AUTH_FAILED (0xFFFF,0xA061)` oder einer Signatur-Abweichung schlägt die Authentifizierung fehl.

### 4.2 Wiederverbinden (authkey bereits bekannt)```
        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` = aktiviert & gespeichert; `0a` = gespeichert, aber **nicht** aktiviert / abgelehnt. Unter
Android muss jedes `DATA_CHUNK_WRITE` als **ein BLE-Write pro Frame** rausgehen — das Verketten und
erneute Aufteilen nach MTU desynchronisiert die Header und die Uhr fragt in einer Schleife nach Offset 0.

- **`9063` (Foto) = APPEND.** Die Zifferblattliste wächst (6→7); `watchfaceId = 0xFFFFFFFF` (eigener
  Sentinel), sodass es nie als Duplikat abgelehnt wird, und die Uhr aktiviert es automatisch.
- **`9075` (strukturiert) = REPLACE** des `old_id`-Slots. `old_id` **muss** bereits in der Liste sein
  (sonst `0a`). Um eine bereits vorhandene ID erneut zu installieren, **zuerst löschen** (9055 Liste-minus-ID)
  und dann „frisch" hochladen — die Wiederverwendung einer ID an Ort und Stelle ergibt `0a`.

### 11.3 Foto / benutzerdefiniertes Zifferblatt — ✅ vollständig Ende-zu-Ende validiert

**Container** (byte-verifizierter Round-Trip; alle Felder 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` = exakte `.bin`-Länge; `FFFFFFFF` = benutzerdefinierte `watchfaceId`; `styleId` 0–4 wählt das eingebaute
Digitaluhr-Layout (es wird immer gezeichnet — es gibt kein „aus"); `posX/posY` positionieren es (bekannt gut
56 / 77); `color565` färbt es (z. B. `FFFF` = Weiß). ⚠️ Die kürzere Form `A5 ‖ size ‖ watchfaceId` wird
mit Finish `0a` **abgelehnt** — verwenden Sie den vollständigen Header oben. (Referenzimplementierung:
`core-rust/engine.rs::build_wf_init2`, spiegelt `C6135t.m31104u` in der offiziellen App wider.)

**Rezept:** Bild auf 466×466 skalieren (und ein 270×270-Thumbnail), in RGB565-LE von oben nach unten konvertieren,
optional die Pixel außerhalb des Kreises auf Null setzen, jeweils LZ4-komprimieren, den Container oben zusammenbauen und
über die `9063`-Pipeline mit `watchfaceId = 0xFFFFFFFF` hochladen. (Referenz-Codec: `core-rust/watchface.rs`,
`work/codec_dfa.py`.)

### 11.4 Strukturiertes / Store-Zifferblatt — Container & Codecs ✅

**Dateilayout** — der 36-Byte-Header wird **byte-identisch als 36-Byte-Footer** am Dateiende wiederholt
(✅ an 15 Zifferblättern verifiziert; ein Parser sollte eine Datei ablehnen, bei der sie sich unterscheiden):```
[36-byte header][scene TLV (§11.7)][asset pool][36-byte header again]

> ⚠️ **Korrektur (ersetzt „es gibt keine blockierende Prüfsumme“).** Frühere Revisionen lasen `@0x00` als
> eine Per-Dial-ID/Per-Dial-Hash und `@0x20` als „3× u32-ID/Hash-Wörter \[kein CRC]“ und stellten fest, dass CRC32/Adler32/
> Byte-Summe alle nicht übereinstimmen. Beide Wörter **sind** CRC32 — die früheren Tests übersahen sie, weil die
> Variante nicht standardkonform ist und weil die Lesart „3 Wörter bei `0x20`“ das einzelne CRC-Wort
> mit den ersten Bytes des Szenen-Containers vermischte, der bei `0x24` beginnt (ebenso ist „Name bei
> `0x2c` wiederholt“ der `0x86`-Namensknoten der Szene, §11.11). Erkenntnis aus
> [freethinkel/fmc](https://github.com/freethinkel/fmc); hier erneut verifiziert.

**CRC32-raw** = reflektiertes IEEE-Polynom `0xEDB88320`, **`init = 0`** und **kein finales XOR** — d. h.
weder das `init=0xFFFFFFFF` noch das `^0xFFFFFFFF` des Standard-`crc32`. Das ist der einzige Grund,
warum handelsübliches CRC32 nie übereinstimmte. Beachte die Reihenfolge-Abhängigkeit: `crc_assets` liegt innerhalb des Bereichs,
der von `crc_tree` abgedeckt wird, also **schreibe zuerst `@0x20`, dann berechne `@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` = aktive aktuelle Dial (von `9055`); `file_len` = echte `.bin`-Größe (= `@0x18 + 36`). Das Installieren eines Store-`.bin`-Files unverändert ist der garantierte Weg (Ring Data id 359 + 102 weitere bestätigt). (Referenz: `core-rust/engine.rs::build_dial_replace_init`.)

### 11.5 Strukturierte Verzeichnis-Grammatik ✅ (dekodiert & implementiert — ÜBERARBEITET 2026-07-02)

> **⚠️ Revision (2026-07-02): das flache `61 01 00`-Recordschema unten war systematisch
> OFF-BY-ONE.** Der Szenen-Body ist ein sauberes TLV (§11.7); ein zeichenbarer **Leaf-Body** (Tags `0x30`/`0x38`
> statisch, `0x70` Zeiger) ist:
>
> ```
> 01 xx 00 [X u16][Y u16] …attrs… 61 [count u16][base u32][count×id u16] [05 05 00 01 pivX pivY]
> ```
>
> - attr `0x01` öffnet den Body: **X,Y = oben links** auf der 466²-Leinwand (das `s16 x,y` des SDK-
>   `sty_picture_t`).
> - die **Frame-Tabelle `61 …` schließt den Body** (`base` = Asset-Ptr; `count` 1 = Bild, 10/11 =
>   Ziffern-Atlas — der alte „Record-Typ `0a/0b`“ war eigentlich dieser Count! — 7/13/2 = Complication-
>   Frame-Sheet).
> - Zeiger-Extras: Quelle+Skalierung `[src] 00 3c 00` innerhalb des `0x01`-attrs; Pivot im
>   `05 05 00 01 [pivX][pivY]` **Trailer**. **Rotationszentrum = `(X+pivX, Y+pivY)` pro Zeiger** —
>   nicht ein festes (233,233): es existieren außermittige Subdials (z. B. rotieren die Zeiger von Dial 366 um 150,150).
>
> Der lineare Scan nach `61 01 00` nähte die Frame-Tabelle+Pivot von Element **N** an die X/Y
> (und das Tag-Byte, das alte „f3“) von Element **N+1** — es sah nur auf analogen Dials *richtig* aus,
> deren benachbarte Zeiger nahezu identische Geometrie teilen. Die „Compact-Variant-Wand“ (Spec 24 §24.4.5)
> war dieselbe Fehllesung. Implementiert als `scan_scene_drawables` in `core-rust/watchface_struct.rs`
> und `wfweb/src/codec/parse.ts` (Szene = primäre Quelle für Bilder/Zeiger; flacher Scan beibehalten für
> Text + Nicht-Envelope-Fallback). Validiert durch das `wfweb/compare.html`-Orakel (Render vs. offizielle
> Store-PNGs, 99 Dials): 64→72 gut, 8→5 schlecht, mittlere Differenz 9.3→7.4%.

Historische Flach-Record-Lesart (ersetzt, zur Kontextwahrung beibehalten):

- **Statisches Bild** (`61 01 00`): `asset_ptr(u32) ‖ elemId(u16) ‖ 05 05 00 01 ‖ pivotX(u16) ‖
  pivotY(u16) ‖ 3B ‖ 01 ‖ 1b 00 ‖ X(u16) ‖ Y(u16)`. Oben links auf der 466²-Leinwand = `(X−pivotX, Y−pivotY)`.
- **Zeiger/Hand** — gleicher Bild-Record, zur Laufzeit rotiert. **Rotationszentrum = `(X+pivotX, Y+pivotY)`**
  (≈ 233,233 auf analogen Dials). Die **Datenquelle ist ein `u8` bei Record-Offset `+36`**, Skalierung `u16` bei
  `+38` (=60): `0x0a`/`0x70` = Stunde (`h·30°+m·0.5°`), `0x0e`/`0x71` = Minute (`m·6°+s·0.1°`),
  `0x12`/`0x72` = Sekunde (`s·6°`). ✅ bestätigt durch Disassemblieren der Getter (RTC-Fallback 10:10:30).
- **Text-/Zahlen-Widget** (`61 0a 00`): `asset_ptr(u32) ‖ [10×u16 Font-Metriken] ‖ 40 01 00 ‖ Flag ‖
  3B ‖ 01 ‖ u16 ‖ X(u16) ‖ Y(u16)`. `asset_ptr` zeigt auf das Glyph „0“; Ziffer *d* = das Asset bei
  `index("0") + d` (10 aufeinanderfolgende cf=5-Sprites, z. B. `0123456789` und `,°`-Interpunktion). ✅ gerendert.
- **Complication-Füllung = Frame-Index** (✅ bestätigt für Ziffern-/Enum-/Gauge-Complications, count>1): der
  Wert indiziert ein **vorgerendertes Frame-Sheet** im `.bin` — `frame = (count−1)·val/100` (Prozent) oder
  `frame = value` (Flip-Ziffer / Enum). Frame-Tabelle = Sub-Record `61 ‖ count(u16) ‖ base(u32) ‖
  count×id(u16)`. Z. B. ist die große Stunde von 327 Digit Max ein 13-Frame-Sheet (Zahlen 0–12), `frame = hour`.
- **Fortschrittsring / Bogen = Laufzeit-Sektor-Clip** (✅ 2026-07-02, **korrigiert die „Ringe sind Frame-Sheets“-Lesart
  in Spec 25 §2**): Element-Tag **`0x81`** trägt eine **einzelne** volle Scheibe (`61`-Frame-Tabelle
  `count == 1`), und der Teilkeil ist diese Scheibe **auf einen Torten-Sektor geclippt** (`frac = value/max`,
  im Uhrzeigersinn ab 12 Uhr) — pixelgenau auf 322 Glare 2 verifiziert und `count==1` über
  **20 Dials** bestätigt. Auf der Platte: `0x81`-Body = Sub `0x01` (Geometrie `x@+0 y@+2 w@+4 h@+6`, inline `61 1 base`
  = Scheibe) + Sub `0x5b` (Bogen-Spec). Implementiert in wfweb (`blendSector`).
  ⚠️ Das `0x5b`-Sub-Record ist **nicht** nur „`max` u16 `@+4`“ wie zuvor dokumentiert — das las die
  untere Hälfte eines `max i32` und übersah die **Start-/End-Sweep-Winkel und Strichbreite**, die direkt
  danach liegen. Es gibt auch ein prozedurales Geschwister `0x80`/`0x5a` (mit explizitem Radius), das dieses
  Dokument nie abdeckte. Vollständiges Record-Layout und was die bisherige „im Uhrzeigersinn ab 12 Uhr“-Annahme
  falsch machte: **§11.15**.
- **Datenquellen-ID** — der `82`-Attr-Block des Elements sitzt bei `delim+3` (nach dem letzten `40 01 00`),
  und die **Quellen-ID ist ein `u8` bei `+0x14`** (auch `relX@+0x07 s16`, `relY@+0x09 s16`, `anchor@+0x0C/0E`,
  `mode@+0x15`, `frame-count@+0x1A`). Anchor < 0 = Ausrichtung an der Kante des Elternteils. 🔎 Die Firmware löst
  die ID über eine 142-Einträge-Getter-Tabelle bei `0x101f371c` auf (jeder ruft `ux2sys_get(type)`).
  ⚠️ **Bevorzuge das Lesen der ID als `meta[9]` der Struktur (§11.11)** — ein festes Feld — gegenüber diesem
  vorwärts gerichteten `82`-Attr-Scan, der die in §11.8/§11.9 beschriebene Off-by-One-Quelle ist. Vollständige ID-Tabelle in §16; beachte,
  dass die Health-/Weather-Labels, die dieser Abschnitt zuvor inline auflistete (`0x19` HR, `0x1b` Akku,
  `0x24` Temperatur, `0x36` Schritte), **umstritten und wahrscheinlich falsch sind** — siehe das ⚠️-Kästchen in §16.
  (Das `0x07:0x0b:0x0f` = HH:MM:SS-Gruppenbeispiel unten ist davon unberührt.)
- **Gruppenknoten** (`0x68`): verschachtelt seine Kinder in seinem eigenen TLV-Body (`0x60` = Wert/Text,
  `0x30` = statisch); jedes `0x60` trägt seine Quellen-ID bei `data+16`. Z. B. eine Gruppe `0x07:0x0b:0x0f` =
  HH:MM:SS-Uhr. TLV-Element-Parser = `0x100db55c` (Sprungtabelle, indiziert durch `tag−0x70`).

### 11.6 Authoring-Matrix

| Pfad | Status | Notizen |
|---|---|---|
| Foto-Dial aus beliebigem Bild | ✅ **fertig** | §11.3; auf dem Gerät validiert |
| Installieren eines beliebigen von 103 Store-Dials | ✅ **fertig** | §11.4; `9075`, `old_id`=aktiv |
| Reskin des cf=4-Hintergrunds eines Store-Dials | ✅ **funktioniert live** | FULL-Payload an Ort und Stelle tauschen, die Asset-`len` auf die **neue** Blockgröße (≤ alt) setzen, denselben Datei-Fußabdruck behalten, frisch installieren |
| Neu-Authoring per Templating (Pixel jeder Ebene tauschen + Geometrie verschieben) | ✅ **rendert über BLE** | Dial 373: bg→cyan + ein cf=5-Sprite→rot + X 224→100 verschoben, alles gerendert, Zeiger live |
| 100 %-synthetischer strukturierter Dial von Grund auf | ✅ **Builder fertig, offline validiert** | `0x20`-Envelope-Builder in `watchface_struct.rs` (`build_container`/`serialize`/`validate_container`); round-tript alle 103 Dials byte-exakt + synthetisch besteht Firmware-Validator (§11.7). 🟡 On-Device-Render über `9075` noch nicht gefilmt |
| System-Fonts (`.font`) | ✅ **Dekodieren/Rendern (alle)** | LVGL-Bin (nicht proprietär); 32 Zahlen-Fonts (`num*/nm*`, unkomprimiert) + 24 Text-Fonts (`font*`, LVGL-RLE `comp=1`) alle dekodiert — 12208 Glyphen, 0 Überläufe, volles ASCII. RLE = LVGL v8.3 `lv_font_fmt_txt.c` (3-Zustand SINGLE/REPEATE/COUNTER + zeilenweiser XOR-Prefilter), 1:1 portiert, kein Disasm |

⚠️ Reskin-/Re-Author-Fallstricke, die einen schwarzen Bildschirm oder `0a` verursachen: die **alte Asset-`len`** belassen (die
Uhr liest über den Block hinaus → Überlauf → schwarz); **die Datei vergrößern** (bei der Installation abgelehnt); eine ID
**an Ort und Stelle** wiederverwenden statt einer frischen Installation; **Assets neu anordnen**, ohne die Ref-Tail-Blockgrößen-
Kette zu fixieren (§11.11). Heute nicht fatal, aber schreibe es trotzdem korrekt: jede Änderung an der Szene oder dem Asset-Pool
macht die beiden Header-**CRC32**-Wörter ungültig — beide neu berechnen (§11.4), `@0x20` vor `@0x00`.

### 11.7 Die `0x20`-Szenen-Envelope — dekodiert & Builder implementiert ✅

Ein neu authorter **echter** Dial rendert, weil er die Szenen-Envelope der Datei bewahrt. Ein rein synthetischer
Body aus flachen `61 …`-Records wird **abgelehnt** — der Firmware-Parser (`WFManager_Parser`, `0xdb35c`)
verlangt, dass der Body (ab Offset `0x24`) mit einem `0x20`-Szenen-Container beginnt. Die vollständige Datei ist:```
[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

> ✅ Dies vereinheitlicht die "magischen Offsets" von §11.5/§11.8/§11.9. Diese Abschnitte lokalisieren Felder *relativ
> zum `0x61`-Frame-Tabellen-Byte* — das ist einfach `+0x12` dieser Struktur, also `−18`/`−16` = `x`/`y` und
> **`−5` = `meta[9]`, die Quell-ID**. Gleiche Bytes, ein sauberes Layout. Die vorwärts scannende `82`-Attr-
> Heuristik, die systematisch um eins daneben lag, wird überhaupt nicht benötigt: lies `meta[9]` der Struktur.
> Das `max` eines Zahlenfelds ist ebenso einfach `meta[11..13]` (z. B. tragen Tagesfelder `max = 99`).

**Ref-Tail** (`61`) — wie ein Knoten auf seine Bitmaps zeigt:```
+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` ist eine Datenquellen-ID (§16) — einschließlich der **synthetischen Slot-IDs** aus §11.13. Operatoren, mit
Häufigkeiten gemessen über 15 Zifferblätter:

| op | Bedeutung | gesehen |
|---|---|---|
| `0x01` | zeichnen, wenn `value == val` | 99 |
| `0x81` | wie `0x01` (Bit `0x80` gesetzt — erscheint bei sich gegenseitig ausschließenden Varianten) | 48 |
| `0x02` | **ausblenden**, wenn `value == val` | 7 |
| `0x03` | zeichnen, wenn `value == val`, wobei `val` ein **Keine-Daten-Marker** ist (z. B. HR `1000`) | 13 |
| `0x05` | zeichnen, wenn `value >= val` | 58 |
| `0x06` | zeichnen, wenn `value <= val` | 50 |
| `0x04` | ⚠️ **unbekannt** — 15 Vorkommen, keine bestätigte Semantik | 15 |

Kombinationsregel (wie vom Referenz-Renderer implementiert, Maske `op & 0x7f`): die Gleichheits-Einträge
werden **ODER**-verknüpft, dann müssen die Ausblenden-/`>=`/`<=`-Einträge **alle** gelten.

Dieser eine Mechanismus deckt den Großteil der Laufzeit-Variabilität des Formats ab und erklärt Strukturen, die
wie duplizierte Widgets aussehen:

- **12h / 24h- und metrische / imperiale Layouts** — zwei Widget-Sätze am selben Punkt gestapelt, jeweils gebunden an
  `id 0x73` (das Einheiten-Flag) mit `val` 0 oder 1. Zifferblatt 275 hat sechs solcher Paare (12 Knoten).
- **„Keine Daten"-Platzhalter** — op `0x03` gegen einen Sentinel, z. B. `id 0x5f, val 1000` (Zifferblatt 275, zweimal):
  zeichnet die Gedankenstrich-Grafik statt einer Temperatur, wenn die Metrik nicht verfügbar ist.
- **Bucket-Hervorhebungen** — ein gepaarter `0x05`/`0x06`-Bereich, z. B. Metaballs Kette, bei der jedes Glied
  für sein eigenes 5-Minuten-Fenster aufleuchtet.
- **Alternativen für Komplikations-Slots** — gebunden an die synthetischen Slot-IDs aus §11.13.

### 11.13 Konfigurierbare Komplikations-Slots — `0x85` + `0x5f` ✅ (ersetzt §11.8)

§11.8 kam zu dem Schluss, dass die aktive Metrik einer konfigurierbaren Komplikation Geräte-RAM-Zustand ist und nicht
aus der Datei wiederhergestellt werden kann. **Das war falsch** — sowohl das Metrik-Menü des Slots als auch seine Standardauswahl
befinden sich in der `.bin`. Jeder `0x85`-Knoten trägt ein `0x5f`-Geschwister:```
+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

Pairing ist starr: `0x80` trägt immer genau `0x01` + ein **19-Byte** `0x5a`, `0x81` immer genau
`0x01` + ein **17-Byte** `0x5b` (✅ 26/26 Ringe über 15 Zifferblätter). ⚠️ Aber das **bildbeschnittene `0x81`
dominiert** — 25 dieser 26. Die prozedurale `0x80`/`0x5a`-Variante trat **einmal** auf (Zifferblatt 273), daher
beruhen ihr `radius`-Feld und das 19-Byte-Layout auf einer einzigen Stichprobe; mit Vorsicht behandeln, bis sie erneut gesehen wird.

`frac = clamp((value − min) / (max − min), 0, 1)`, und der gefüllte Bogen verläuft von `start` in Richtung `end`.
Winkel null ist bei **3 Uhr**, positiv im Uhrzeigersinn. Gemessene Beispiele:

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

> ⚠️ **Dies korrigiert die Annahme „im Uhrzeigersinn ab 12 Uhr"** in §11.5. Das ist nur der Sonderfall
> `start = 0, end = 3600` (ein voller Umlauf, bei dem die Konvention nicht beobachtbar ist). Echte Zifferblätter verwenden
> **Teilanzeigen** (273er ±102,8°-Fächer, 366er 270°-Dreiviertelring) und **negative Bögen**
> (276er 60° → −120°), daher zeichnet ein Renderer, der immer einen vollen Kreis von oben überstreicht, diese falsch.
> 🟡 Die genaue Winkel-null-Konvention und die Richtungsregel stammen aus fmcs Renderer, kreuzgeprüft
> gegen diese On-Disk-Werte — nicht unabhängig Pixel-für-Pixel auf dem Gerät von diesem Repo verifiziert.
> Beachte, dass `frac = value/max` und das `0x81`-Sektor-Clipping in §11.5 **validiert** wurden (Zifferblatt 322).

⚠️ **Ungelöst: der 3-Byte-Trailer `01 00 kk`.** `kk` nimmt plausibel aussehende Werte an (104, 152, 216,
232, 248), und die naheliegende Hypothese ist ein Radius — **getestet und widerlegt**: Zifferblatt 366 verwendet `kk = 104`
sowohl für einen 82×82- als auch einen 166×166-Ring, und Zifferblatt 273 verwendet `kk = 232` sowohl für einen 440×440- als auch einen 284×284-
Ring. Kein Radius, kein Durchmesser. Möglicherweise Deckkraft/Stil. Unverändert hin- und zurückschreiben.

🟡 **Gemeldete Stolperfalle, hier nicht verifiziert:** in fmcs Renderer rendert eine `0x60`-Zahl, deren Quell-ID der ID
**irgendeines** Rings auf demselben Bildschirm entspricht, `round(frac × 100)` statt des Rohwerts — daher
zeigt eine Herzfrequenzzahl neben einem Herzfrequenzring `36` statt `71 bpm`. Ihr dokumentierter
Workaround besteht darin, Ring und Zahl auf zwei **Alias**-IDs derselben Metrik zu platzieren (Schritte
`0x19`/`0x26`/`0x49`, Kalorien `0x1c`/`0x1e`/`0x48`). Ob dies Firmware-Verhalten ist oder spezifisch
für ihren Renderer, ist **nicht geklärt** — eine Live-Prüfung wert, bevor man das Design darauf aufbaut.

---

## 12. Massenübertragung & OTA-Details

Die Übertragungstabelle befindet sich in §6. Zusätzliche bestätigte Punkte:

- **AGPS/EPO** ✅: Der erste geschriebene Block beginnt mit dem ASCII-Header `000000010000…`. Die vollständige
  Init- → `[A05F ↔ 905F]×N`- → Finish-Schleife wurde auf der Leitung beobachtet (~892 Blöcke).
- **Firmware-OTA** (`9040`–`9042`, Finish `9041`) 🔎: Struktur kartiert; INIT2-Payload = Versionsbytes
  (z. B. `0b 00 00 39` = 11.0.0.57). **Nicht im Feld getestet** (die App deaktiviert hier das FW-Update). Firmware-
  Images scheinen **unsigniert zu sein — Integrität ist nur CRC32** (keine asymmetrische Signatur im RE beobachtet).
- ⚠️ Da OTA und `FACTORY_RESET (009A 0001)` die authentifizierte Sitzung teilen, reicht eine einzige gültige BLE-
  Authentifizierung aus, um die Uhr zu löschen oder (im Prinzip) zu zerstören. Vorsichtig behandeln.

---

## 13. Sensoren

✅ Hardware, die über BLE verfügbar ist:

- **Optischer PPG** — Herzfrequenz (manuell/automatisch/Training/Ruhe), SpO₂ und HRV-basierter Stress.
- **3-Achsen-Beschleunigungsmesser** — Schritte, Distanz, Kalorien, Schlafphasen, Handgelenkheben, Kadenz.
- **GNSS/GPS** (AGPS-unterstützt) — Trainingsstrecke (`WORKOUT_GPS`) und Standort-Push (`GPS_PUSH`).

Es gibt **keinen Barometer/Höhenmesser, Kompass, Gyroskop oder Haut-/Körpertemperatursensor**. Ein interner
NTC-Thermistor (Platinen-/Akkutemperatur) existiert, ist aber **nur** über den AT-Kanal lesbar
(`AT GETNTCTEMP`, §14) — der `0155`-Hauttemperatur-Verlaufsstream ist bei dieser SKU leer.

**Daten-Widget-Übernahmen** (es gibt keine echte Complication-/Datenbindungs-API — siehe §11.5): die
vorhandenen Textfelder der Uhr können zweckentfremdet werden, um auf einen Blick externe Daten anzuzeigen. Bewährt ✅: die Wetter-
**Stadtzeichenkette** (`WEATHER_SET_1`, z. B. `"BRA 2x1 ARG"` erschien auf dem Widget) und die Musik-
**Titel-/Künstlerfelder**; die **Kontaktliste** (20 × Name[32]+Nummer[25]) funktioniert als scrollbares Daten-
panel. Alles sind Push-Daten, keine persistenten Complications.

---

## 14. AT-Factory-/Shell-Kanal (`77d4ff01` / `77d4ff02`)

Ein separater Klartext-AT-Befehls kanal, unabhängig vom gerahmten Protokoll. ✅ live getestet:

- **Lesen:** `AT GETSECRET` (16-Byte-Pairing-Geheimnis), `GETVERSION`, `GETSN`, `GETNAME`, `GETPID`,
  `GETBATLV` (rohe mV, z. B. `3853mv`), `GETGSENSOR` (rohe Beschleunigung in g, `X=… Y=… Z=…`),
  `GETNTCTEMP` (°C, interner NTC).
- **Schreiben / Auslösen:** `AT SETMOTOR=1` (Motor vibrieren lassen), `SETHR/SETHRV/SETSPO2=…` (Sensor-Test-
  Injektion), `SETLCDSWITCH/SETGPSSWITCH/SETKEYSWITCH`.

Antworten enden mit `,OK`. `SET*`-Befehle werden im Allgemeinen ausgeführt, geben aber möglicherweise kein `,OK` über BLE zurück — Fall
für Fall bestätigen.

---

## 15. Firmware-gesteuerte / nicht verfügbare Funktionen (🔎 Firmware-RE)

Einige Funktionen sind in der Firmware vorhanden, aber durch SKU/Region deaktiviert und **vom Telefon/BLE aus nicht erreichbar** —
sie benötigen einen Firmware-Mod, der hier außerhalb des Rahmens liegt:

- **ChatGPT-Sprache** — Gate = `ux2sys`-Feature-ID `0x9e`, beim Boot aus NVRAM/EFUSE/Region gespeist; bei
  dieser SKU Unterstützungsflag `908b = 00`. Nicht durch Telefon, Konto oder BLE beeinflussbar (durch
  Experiment + RE bestätigt). Die App ist nur ein Relais; Audio geht Telefon → Nothing-Cloud.
- **Blutdruck** — ein vollständiges Subsystem existiert in der Firmware, durch SKU/Region abgeschaltet.
- **Alipay / NFC-Zahlung** — vollständige UI vorhanden, nur China-SKU.
- **In Hardware/Firmware nicht vorhanden:** EKG, SOS/Notfall, generisches NFC.

---

## 16. Datenquellen-/Complication-Getter-IDs

Nicht nötig, um einen BLE-Client zu bauen, aber **unerlässlich, um ein Zifferblatt zu erstellen oder zu rendern**: Dies ist der Wert von
`meta[9]` (§11.11), der ein Widget an Live-Daten bindet, die `id` einer Sichtbarkeitsbedingung (§11.12) und
die Einträge des Metrikmenüs eines Slots (§11.13). Die Firmware löst es über eine **142-Einträge-Getter-
Dispatch-Tabelle** bei `0x101f371c` auf, wobei jeder Eintrag `ux2sys_get(type)` aufruft (🔎 Firmware-RE).

### Zeit / Datum — ✅ gut etabliert

| id | Bedeutung | id | Bedeutung |
|---|---|---|---|
| `0x01` | Stunde (12/24h je nach Geräteeinstellung) | `0x0f`, `0x12` | Sekunde (weich) |
| `0x04` | Stunde (24h) | `0x10`, `0x11` | Sekunden Zehner / Einer |
| `0x07` | Stunde (erzwungen 24h) | `0x71`, `0x72` | Sekunde (tickend / Zeigerwinkel) |
| `0x02`, `0x03` | Stunde-12h Zehner / Einer | `0x13` | AM/PM-Flag (0 = AM, 1 = PM) |
| `0x05`, `0x06`, `0x08`, `0x09` | Stunde Zehner / Einer | `0x15`, `0x16` | Monat |
| `0x0a`, `0x70` | Stundenzeigerwinkel | `0x17` | Tag des Monats |
| `0x0b` | Minute | `0x18` | Wochentag (0 = Montag ⚠️) |
| `0x0c`, `0x0d` | Minute Zehner / Einer | `0x0e`, `0x71` | Minutenzeigerwinkel |

Zehner-/Einer-IDs zeichnen eine **einzelne Ziffer** — ein Widget, das an eine davon gebunden ist, rendert ein Glyph, nicht den gesamten
Wert (Zifferblatt 284 Square). Zeigerwinkel-IDs (§11.5) sind `0x0a`/`0x70` Stunde = `h·30° + m·0,5°`,
`0x0e`/`0x71` Minute = `m·6° + s·0,1°`, `0x12`/`0x72` Sekunde = `s·6°` (✅ durch Disassemblieren bestätigt
der Getter, RTC-Fallback 10:10:30).

### Gesundheit / Sensoren / Wetter — ⚠️ umstritten, Evidenzspalte lesen

| id | Bedeutung (beste aktuelle Lesart) | Evidenz |
|---|---|---|
| `0x19` | **Schritte** | in 368er-Slotmenü neben `0x1a`; stimmt mit `parse.ts` dieses Repos überein |
| `0x1a` | **Herzfrequenz** | in 368er-Slotmenü neben `0x5f` und `0x19` |
| `0x1c` | Kalorien | Slotmenü, Flammen-Symbol in der Begleit-App |
| `0x1e` | Kalorien (Alias) | Korpus |
| `0x22` / `0x23` | Distanz km / mi (Ganzzahlteil) | Korpus |
| `0x74` / `0x75` | Distanz km / mi (Nachkommateil) | Korpus |
| `0x76` | Distanz (Slot-Form) | Slotmenü, Straßen-Symbol |
| `0x24` | **Akku %** | Slotmenü, Blitz-Symbol |
| `0x30` | Akku % | Korpus |
| `0x36` / `0x5f` | Temperatur | `0x5f` = Slotmenü, Wolke-Sonne-Symbol; 361 TempoG bindet eine einfache Zahl |
| `0x48` | Stehen (gestandene Stunden) | Slotmenü, stehende-Figur-Symbol |
| `0x8b` | AQI | Slotmenü |
| `0x73` | 24h-/metrische-Einheiten-Flag | Korpus |
| `0x25`–`0x27`, `0x49`, `0x6c`, `0x6f` | Ziel % / Slot-Aliase von Schritten & Kalorien | Korpus |
| `0x6a` | ⚠️ nicht identifizierte Slot-Metrik | erscheint in 4 Slotmenüs |
| `0x79 + slotIndex` | **synthetisch** — keine Metrik; die Slot-Auswahl-ID (§11.13) | ✅ §11.13 |

> ⚠️ **Drei Tabellen in diesem Repo widersprachen sich; diese hier ist die Abstimmung.** Frühere Revisionen von §16
> und §11.5 lasen `0x19` als Herzfrequenz, `0x1b` als Akku, `0x24` als Temperatur und `0x36` als Schritte —
> und `wfweb/src/codec/mock.ts` kodiert diese Lesart weiterhin, während `wfweb/src/codec/parse.ts` eine
> andere kodiert (`0x19` Schritte, `0x24` Ziel %, `0x48` Stehen, `0x1a` Wetter). Die obige Tabelle folgt
> der besser belegten Lesart (Beschriftungen von fmc gegen die eigenen Widget-Slot-
> Menüsymbole der Begleit-App kalibriert, siehe §Quellen). **Der Code wurde noch nicht geändert — `mock.ts` und `parse.ts` sind weiterhin
> inkonsistent miteinander und mit dieser Tabelle.** Gesundheits-ID-Beschriftungen als ⚠️ behandeln, bis jemand
> ein Feld an jede ID bindet und die Uhr ausliest.
>
> Das stärkste einzelne Beweisstück ist **das Slotmenü von Zifferblatt 368 Function** (§11.13), das
> `0x5f 0x1c 0x19 0x48 0x24 0x76 0x1a 0x8b` als **acht verschiedene vom Benutzer wählbare Metriken** in einem Menü anbietet.
> Was auch immer die Beschriftungen sind, keine zwei dieser acht können dieselbe Metrik sein — was
> `0x19` = `0x1a` = Herzfrequenz und `0x24` = `0x5f` = Temperatur gleichzeitig ausschließt.

Ring-/Bogen-Complications mit einem **Frame-Sheet** indizieren einen vorgerenderten Frame (z. B. 50 % = Frame 50 von 100),
der in die `.bin` eingebacken ist, die du sendest (§11.5), daher ist kein externes RES-Paket nötig; bildlose Ringe werden
aus der Bogenspezifikation gezeichnet (§11.15).

---

### Schnellkarten (Startseiten-Kacheln) — `QUICK_CARD (906D)` ✅

Die Startseiten-Kacheln der Uhr. Das Telefon wählt nur **welche** Kacheln angezeigt werden und in **welcher Reihenfolge** — Kacheln werden
von der Firmware gerendert (kein Inhaltskanal). Erstes Payload-Byte = Unterbefehl: `00` = GET, `01` =
SET; **beide verwenden `0x906D`** (`0x906C` ist aufgeführt, wird aber nicht verwendet — eine Abfrage läuft in einen Timeout). Antwort = `A06D`.

> 🛑 Das Senden einer erfundenen `assemblyId` **löscht die Bildschirme der Uhr** (sie akzeptiert die Liste, kann die
> IDs nicht zuordnen, zeigt nichts). Nur IDs senden, die du über GET **zurückgelesen** hast; Wiederherstellung über die offizielle App oder einen
> Werksreset.

**GET-Antwort** ✅: `status(1) ‖ 00 ‖ N(1) ‖ N × Gruppe`, Gruppe = `tag=01 ‖ K(1) ‖ K×(assemblyId, sportId)`.
Echter Frame: `01 00 04  01 02 5d00 6100  01 03 1900 2e00 2300  01 03 5c00 0400 5a02  01 03 4800 5100 5300`
= 4 Bildschirme / 11 Karten (`5a02` = Sportkarte, sportId 2).

**Slots:** Jeder Bildschirm hat **4 Slots**. Der Kartentyp bestimmt seine Größe — `circular`/`square` = 1 Slot,
`rectangle` = 2 Slots. Validierung ist reine Slot-Arithmetik (Σ ≤ 4 pro Bildschirm); keine sich gegenseitig ausschließenden
Karten. `sportId` ist `0`, außer bei Sportkarten (87–91). IDs `64` und `95` existieren nicht.

**`assemblyId`-Katalog** (jeder logische Typ = ein zusammenhängender Bereich von 6 Stilvarianten `_0`..`_5`;
`0` = leerer Slot):

| dez | Karte | dez | Karte |
|----|----|----|----|
| 0 | leerer Slot | 49–53,97–98 | Wetter |
| 1–6 | Schritte | 54–58 | Timer |
| 7–12 | Kalorien | 59–62 | Atmung |
| 13–18 | Stehen | 63,65–67 | Stoppuhr |
| 19–24 | Moderate Aktivität | 68–71 | Akku |
| 25–30 | Herzfrequenz | 72–76 | Zuletzt |
| 31–36 | SpO₂ | 77–81 | Kontakte |
| 37–42 | Stress | 82–86 | Zifferblatt / Telefon |
| 43–48 | Schlaf | 87–91 | Sport (`sportId` ≠ 0) |
| 92 | Musik | 93/94/96 | Aktivitätsaufzeichnung / PAI / Zyklus |

---

## Anhang A. Werks-Zifferblattkatalog (id → Name)

§11 bezieht sich durchgehend auf Zifferblätter mit numerischer ID (275 SlopeTime, 322 Glare 2, 357 Silhouette, …). IDs
`273`–`376` sind die Store-/Werksgesichter; die ID ist das, was `DIAL_COMMAND (9055/a055)` als aktiv meldet und
was `9075` als `old_id` akzeptiert (§11.4). 100 der 103 bekannten IDs sind unten benannt; die restlichen sind
ROM-Stubs (§11.4). Namen und Gruppierung wie von der offiziellen Begleit-App angezeigt.

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

---

## Quellen

Die obigen Byte-Layouts wurden aus der Firmware (1.0.0.73), der offiziellen APK (3.5.7) und
entschlüsselten Live-Mitschnitten gegen ein echtes Gerät rekonstruiert. Die Referenzimplementierung für dieses Projekt befindet sich in
`core-rust/src/{commands,frame,crypto,health,session}.rs` (Rust), dem `wfweb/`-TypeScript-Editor und
den `cmftool/`-Python-Tools (`pair.py`, `session.py`, `wf_codec.py`, `upload_custom.py`, …).

**Hier eingearbeitete unabhängige Arbeit.** [freethinkel/fmc](https://github.com/freethinkel/fmc) — ein
SvelteKit-Zifferblatt-Editor + Marktplatz für dieselbe Uhr — hat unabhängig das
`.bin`-Format aus einem ~100-Gesichter-Korpus reverse-engineert und mehrere Ergebnisse erzielt, die dieses Dokument übersehen oder
falsch hatte. Ihre `docs/cmf-protocol.md`, `src/lib/modules/editor/lib/{wf,render}.ts` und
`src/lib/modules/device/lib/ble.ts` sind eine direkte Lektüre wert. Übernommene Erkenntnisse, jeweils vor der Niederschrift hier gegen Zifferblatt-Bytes erneut verifiziert:

| Erkenntnis | Wo | Status hier |
|---|---|---|
| Beide Header-Wörter sind CRC32 (nicht standardmäßige Variante) | §11.4 | ✅ 9/9 Zifferblätter erneut verifiziert; **korrigiert** „keine blockierende Prüfsumme" |
| Sichtbarkeitsbedingungen, Tag `0x02` | §11.12 | ✅ erneut verifiziert; war undokumentiert |
| Slot-Metrikliste + Standard-`activeIdx`, `0x79 + slotIndex` | §11.13 | ✅ auf 275/368/273/304 erneut verifiziert; **ersetzt** §11.8 |
| Akzent-Farbfähigkeitsflag `meta[7] == 4` | §11.14 | ✅ Prävalenz erneut verifiziert; war undokumentiert |
| Vollständige Bogenspezifikation (Schwenkwinkel, Breite, Radius) | §11.15 | ✅ erneut verifiziert; **korrigiert** „`max` u16 `@+4`" |
| Ref-Tail-`u16`s sind Blockgrößen, keine Glyph-IDs | §11.11 | ✅ exakt auf einem 10-Glyph-Atlas erneut verifiziert |
| 36-Byte-Fußzeile; Magic-Byte-Variante `0x02`; `0x86` = 64 B; `0x28` eingebettete Vorschau | §11.4, §11.11 | ✅ erneut verifiziert |
| Gesundheits-/Wetter-ID-Beschriftungen gegen das Slotmenü der Begleit-App kalibriert | §16 | ⚠️ als beste Lesart übernommen; Konflikte gekennzeichnet |
| Shell-Dienst-UUID ist `77d4e67c-…`, und Web-Bluetooth-`optionalServices`-Scoping | §1 | ⚠️ Einzelgeräte-Bericht, hier nicht erneut verifiziert |
| Zahl, die ID mit Ring teilt, rendert einen Prozentsatz | §11.15 | 🟡 gemeldet, hier **nicht** verifiziert |
| Werks-Zifferblatt-ID → Name-Katalog | Anhang A | ✅ unverändert übernommen |