- `cmd1`/`cmd2`는 함께 **opcode**를 구성합니다(§6 참조). 🔎 공식 앱의 프레임 빌더(`C6117b.m30831g`)에서 확인됨.
- `chunkCount` = 이 명령의 총 청크 수; `chunkIndex`는 **1부터 시작**합니다.
- `chunkLen` = 이 프레임에서 `chunk`의 바이트 수.
- 단일 BLE 쓰기는 링크 MTU에 의해 분할될 수 있습니다. 수신기는 원시 바이트를 버퍼링하고 완전한 프레임을 다시 추출합니다. 대용량 페이로드는 여러 청크(동일한 `cmd1/cmd2`, 증가하는 `chunkIndex`)로 분할되어 순서대로 재조립됩니다.

### Opcode 규칙 (✅ 와이어에서 확인됨)

- `cmd1 = 0xFFFF`: `cmd2`가 `0x80xx`/`0x90xx` = 폰→워치(요청/설정); `0x00xx`/`0xa0xx` = 워치→폰(응답). 쌍은 하위 바이트로 매칭됩니다(`0x9055`↔`0xa055`, `0x8051`↔`0x0051`).
- 기능별 `cmd1`: `cmd2` 접미사 = `0x0001` **SET**, `0x0002` **GET**, `0x0003` **ACK**.

### 청크 본문

각 청크의 본문은 `payloadPiece ‖ CRC32_LE(payloadPiece)`(4바이트 CRC, 리틀엔디언, zlib/IEEE)입니다. 명령이 **암호화된** 경우(§3 참조), 전체 `payloadPiece ‖ CRC`가 AES-128-CBC/PKCS7로 암호화되고 해당 암호문이 프레임 `chunk`가 됩니다.

**평문 특이점:** 평문 opcode의 경우 워치가 `chunkLen`에 4바이트 CRC를 *포함하여 계산*하지만 이를 **전송하지는 않습니다**. 따라서 평문 프레임을 디코딩할 때 실제 데이터 길이는 `chunkLen − 4`입니다. (암호화된 프레임은 평소처럼 암호문 내부에 CRC를 포함합니다.)

청크 크기(암호화된 청크가 AES 블록 경계에 맞도록), `maxWrite = mtu − 3`:
- 암호화: `floor((maxWrite − 11) / 16) * 16 − 4 − 1`
- 평문: `maxWrite − 11 − 4 − 1`

✅ 관찰된 모든 암호화 프레임 `chunkLen` 값은 16의 배수였습니다(블록 정렬 유지됨).

---

## 3. 암호화 기본 요소

- **AES-128-CBC** with **PKCS7** 패딩 및 **고정 IV**(펌웨어 `CmfCharacteristic.AES_IV`에서):
  `50 51 52 53 54 55 56 57 60 61 62 63 64 65 66 5A`.
- **CRC32** (zlib/IEEE), 4바이트 리틀엔디언으로 출력.
- **SHA-256** over the concatenation of parts.

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

`AUTH_FAILED (0xFFFF,0xA061)` 또는 서명 불일치가 발생하면 인증이 실패합니다.

### 4.2 재연결 (authkey 이미 알려진 경우)```
        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` = 활성화 및 저장됨; `0a` = 저장되었지만 **활성화되지 않음** / 거부됨. Android에서는 각 `DATA_CHUNK_WRITE`가 **프레임당 BLE 쓰기 하나**로 전송되어야 합니다. 연결(concatenating) 후 MTU로 다시 분할하면 헤더가 어긋나고 워치가 오프셋 0을 반복 요청하게 됩니다.

- **`9063` (사진) = APPEND.** 다이얼 목록이 늘어납니다(6→7). `watchfaceId = 0xFFFFFFFF`(사용자 지정
  센티널)이므로 중복으로 거부되지 않으며, 워치가 자동으로 활성화합니다.
- **`9075` (구조화) = REPLACE** `old_id` 슬롯. `old_id`는 **반드시** 이미 목록에 있어야 합니다
  (그렇지 않으면 `0a`). 이미 존재하는 id를 다시 설치하려면 **먼저 삭제한 후**(9055 목록에서 id 제거)
  "새로" 업로드하세요. 제자리에서 id를 재사용하면 `0a`가 반환됩니다.

### 11.3 사진 / 사용자 지정 다이얼 — ✅ 엔드투엔드 완전 검증됨

**컨테이너**(바이트 검증 왕복; 모든 필드는 리틀엔디언):```
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` = 정확한 `.bin` 길이; `FFFFFFFF` = 사용자 정의 `watchfaceId`; `styleId` 0–4는 내장
디지털 시계 레이아웃을 선택합니다 (항상 그려집니다 — "끄기" 옵션은 없음); `posX/posY`는 위치를 지정합니다 (검증된 값
56 / 77); `color565`는 색조를 입힙니다 (예: `FFFF` = 흰색). ⚠️ 더 짧은 `A5 ‖ size ‖ watchfaceId` 형식은
finish `0a`로 **거부**됩니다 — 위의 전체 헤더를 사용하세요. (참조 구현:
`core-rust/engine.rs::build_wf_init2`, 공식 앱의 `C6135t.m31104u`를 미러링합니다.)

**레시피:** 이미지를 466×466 (및 270×270 썸네일)로 크기 조정하고, RGB565-LE 상하단 순서로 변환한 뒤,
선택적으로 원 밖의 픽셀을 0으로 설정하고, 각각 LZ4 압축한 다음, 위의 컨테이너를 조립하고,
`watchfaceId = 0xFFFFFFFF`로 `9063` 파이프라인을 통해 업로드합니다. (참조 코덱: `core-rust/watchface.rs`,
`work/codec_dfa.py`.)

### 11.4 구조화 / 스토어 다이얼 — 컨테이너 및 코덱 ✅

**파일 레이아웃** — 36바이트 헤더는 EOF에서 **36바이트 푸터로 바이트 단위로 동일하게** 반복됩니다
(✅ 15개 다이얼에서 검증됨; 파서는 이 둘이 다를 경우 파일을 거부해야 합니다):```
[36-byte header][scene TLV (§11.7)][asset pool][36-byte header again]

> ⚠️ **정정(이전의 "차단 체크섬 없음"을 대체함).** 이전 개정판에서는 `@0x00`을
> 다이얼별 id/해시로, `@0x20`을 "3× u32 id/해시 워드 \[CRC 아님]"로 읽었으며, CRC32/Adler32/
> 바이트 합계가 모두 일치하지 않는다고 명시했습니다. 두 워드 **모두 CRC32**입니다 — 이전 테스트에서
> 이를 놓친 이유는 변형이 비표준이고, "`0x20`의 3개 워드" 해석이 단일 CRC 워드를 `0x24`에서 시작하는
> 씬 컨테이너의 첫 바이트와 혼동했기 때문입니다(마찬가지로 "`0x2c`에 반복된 이름"은 씬의 `0x86`
> 이름 노드, §11.11). 출처:
> [freethinkel/fmc](https://github.com/freethinkel/fmc); 여기서 재검증됨.

**CRC32-raw** = 반사 IEEE 다항식 `0xEDB88320`, **`init = 0`**, **최종 XOR 없음** — 즉
표준 `crc32`의 `init=0xFFFFFFFF`도 `^0xFFFFFFFF`도 아닙니다. 이것이 바로 기성 CRC32가
일치하지 않았던 전적인 이유입니다. 순서 의존성에 유의하세요: `crc_assets`는 `crc_tree`가
포함하는 범위 안에 있으므로 **`@0x20`을 먼저 쓰고, 그런 다음 `@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` = 현재 활성 다이얼(`9055`에서); `file_len` = 실제 `.bin`
크기(`@0x18 + 36`). 스토어 `.bin`을 그대로 설치하는 것이 보장된 경로입니다(Ring Data id 359 +
다른 102개 확인됨). (참조: `core-rust/engine.rs::build_dial_replace_init`.)

### 11.5 구조화된 디렉터리 문법 ✅ (디코딩 및 구현 완료 — 2026-07-02 개정)

> **⚠️ 개정(2026-07-02): 아래의 평면 `61 01 00` 레코드 스키마는 체계적으로
> OFF-BY-ONE이었습니다.** 씬 본문은 깔끔한 TLV입니다(§11.7); 드로어블 **리프 본문**(태그 `0x30`/`0x38`
> 정적, `0x70` 포인터)은 다음과 같습니다:
>
> ```
> 01 xx 00 [X u16][Y u16] …attrs… 61 [count u16][base u32][count×id u16] [05 05 00 01 pivX pivY]
> ```
>
> - attr `0x01`이 본문을 엽니다: **X,Y = 466² 캔버스의 왼쪽 위**(SDK의 `sty_picture_t`의 `s16 x,y`).
> - **프레임 테이블 `61 …`이 본문을 닫습니다**(`base` = 에셋 포인터; `count` 1 = 이미지, 10/11 =
>   숫자 아틀라스 — 이전의 "레코드 유형 `0a/0b`"는 실제로 이 count였습니다! — 7/13/2 = 컴플리케이션
>   프레임 시트).
> - 포인터 추가 항목: `0x01` attr 내부의 소스+스케일 `[src] 00 3c 00`; 피벗은
>   `05 05 00 01 [pivX][pivY]` **트레일러**에 있습니다. **회전 중심 = 포인터별 `(X+pivX, Y+pivY)`** —
>   고정(233,233)이 아닙니다: 중심에서 벗어난 서브다이얼이 존재합니다(예: 다이얼 366의 시침/분침은 150,150을 중심으로 회전).
>
> `61 01 00`에 대한 선형 스캔은 요소 **N**의 프레임 테이블+피벗을 요소 **N+1**의 X/Y(및 태그 바이트,
> 이전의 "f3")에 꿰매고 있었습니다 — 인접한 시침/분침이 거의 동일한 지오메트리를 공유하는 아날로그
> 다이얼에서만 *올바르게 보였습니다*. "컴팩트 변형 벽"(사양 24 §24.4.5)도 이와 동일한 오독이었습니다.
> `core-rust/watchface_struct.rs`의 `scan_scene_drawables` 및 `wfweb/src/codec/parse.ts`로 구현됨
> (씬 = 이미지/포인터의 기본 소스; 평면 스캔은 텍스트 + 비-엔벨로프 폴백용으로 유지). `wfweb/compare.html`
> 오라클(공식 스토어 PNG 대비 렌더링, 99개 다이얼)로 검증됨: 64→72 양호, 8→5 불량, 평균 차이 9.3→7.4%.

이전의 평면 레코드 판독(대체됨, 맥락용으로 유지):

- **정적 이미지**(`61 01 00`): `asset_ptr(u32) ‖ elemId(u16) ‖ 05 05 00 01 ‖ pivotX(u16) ‖
  pivotY(u16) ‖ 3B ‖ 01 ‖ 1b 00 ‖ X(u16) ‖ Y(u16)`. 466² 캔버스의 왼쪽 위 = `(X−pivotX, Y−pivotY)`.
- **포인터/시침** — 동일한 이미지 레코드, 런타임에 회전. **회전 중심 = `(X+pivotX, Y+pivotY)`**
  (아날로그 다이얼에서 ≈ 233,233). **데이터 소스는 레코드 오프셋 `+36`의 `u8`**, 스케일 `u16`은
  `+38`(=60): `0x0a`/`0x70` = 시(`h·30°+m·0.5°`), `0x0e`/`0x71` = 분(`m·6°+s·0.1°`),
  `0x12`/`0x72` = 초(`s·6°`). ✅ getter 디스어셈블리로 확인됨(RTC 폴백 10:10:30).
- **텍스트 / 숫자 위젯**(`61 0a 00`): `asset_ptr(u32) ‖ [10×u16 글꼴 메트릭] ‖ 40 01 00 ‖ flag ‖
  3B ‖ 01 ‖ u16 ‖ X(u16) ‖ Y(u16)`. `asset_ptr`는 글리프 "0"을 가리킵니다; 숫자 *d* = `index("0") + d`의
  에셋(연속 10개의 cf=5 스프라이트, 예: `0123456789` 및 `,°` 구두점). ✅ 렌더링됨.
- **컴플리케이션 채우기 = 프레임 인덱스**(✅ 숫자/열거/게이지 컴플리케이션, count>1에 대해 확인됨): 값은
  `.bin`의 **사전 렌더링된 프레임 시트**를 인덱싱합니다 — `frame = (count−1)·val/100`(백분율) 또는
  `frame = value`(플립 숫자 / 열거). 프레임 테이블 = 하위 레코드 `61 ‖ count(u16) ‖ base(u32) ‖
  count×id(u16)`. 예: 327 Digit Max의 큰 시 숫자는 13프레임 시트(숫자 0–12), `frame = hour`.
- **진행 링 / 아크 = 런타임 섹터 클립**(✅ 2026-07-02, 사양 25 §2의 "링은 프레임 시트" 판독을
  **수정**): 요소 태그 **`0x81`**은 **단일** 전체 디스크(`61` 프레임 테이블 `count == 1`)를
  전달하며, 부분 쐐기는 해당 디스크를 **파이 섹터로 클리핑**한 것입니다(`frac = value/max`,
  12시 방향에서 시계 방향) — 322 Glare 2에서 픽셀 단위로 검증되었고 **20개 다이얼**에서 `count==1`이
  확인됨. 디스크 상: `0x81` 본문 = 하위 `0x01`(지오메트리 `x@+0 y@+2 w@+4 h@+6`, 인라인 `61 1 base`
  = 디스크) + 하위 `0x5b`(아크 사양). wfweb(`blendSector`)에서 구현됨.
  ⚠️ `0x5b` 하위 레코드는 이전에 문서화된 것처럼 단순히 "`max` u16 `@+4`"가 **아닙니다** — 이는
  `max i32`의 하위 절반을 읽었고 바로 뒤에 있는 **시작/끝 스윕 각도와 스트로크 너비**를 놓쳤습니다.
  또한 이 문서에서 다루지 않은 명시적 반지름이 있는 절차적 형제 `0x80`/`0x5a`도 있습니다. 전체 레코드
  레이아웃과 이전의 "12시 방향에서 시계 방향" 가정이 틀렸던 점: **§11.15**.
- **데이터 소스 id** — 요소의 `82` attr 블록은 `delim+3`(마지막 `40 01 00` 뒤)에 있으며,
  **소스 id는 `+0x14`의 `u8`**입니다(또한 `relX@+0x07 s16`, `relY@+0x09 s16`, `anchor@+0x0C/0E`,
  `mode@+0x15`, `frame-count@+0x1A`). Anchor < 0 = 부모의 가장자리에 정렬. 🔎 펌웨어는
  `0x101f371c`의 142개 항목 getter 테이블을 통해 id를 해석합니다(각각 `ux2sys_get(type)` 호출).
  ⚠️ **id를 이 전방 `82`-attr 스캔보다 구조체의 `meta[9]`(§11.11)로 읽는 것을 선호** — 이 스캔은
  §11.8/§11.9에 설명된 off-by-one 소스입니다. 전체 id 테이블은 §16; 이 섹션에서 이전에 인라인으로
  나열한 건강/날씨 레이블(`0x19` HR, `0x1b` 배터리, `0x24` 온도, `0x36` 걸음 수)은 **논쟁 중이며
  아마도 틀렸습니다** — §16의 ⚠️ 상자를 참조하세요. (아래의 `0x07:0x0b:0x0f` = HH:MM:SS 그룹 예는
  영향을 받지 않습니다.)
- **그룹 노드**(`0x68`): 자식을 자체 TLV 본문(`0x60` = 값/텍스트, `0x30` = 정적) 안에 중첩합니다;
  각 `0x60`은 `data+16`에 소스 id를 전달합니다. 예: 그룹 `0x07:0x0b:0x0f` = HH:MM:SS 시계.
  TLV 요소 파서 = `0x100db55c`(`tag−0x70`로 인덱싱된 점프 테이블).

### 11.6 제작 매트릭스

| 경로 | 상태 | 참고 |
|---|---|---|
| 모든 이미지에서 포토 다이얼 | ✅ **완료** | §11.3; 기기에서 검증됨 |
| 103개 스토어 다이얼 중 하나 설치 | ✅ **완료** | §11.4; `9075`, `old_id`=활성 |
| 스토어 다이얼의 cf=4 배경 리스킨 | ✅ **실시간 작동** | 전체 페이로드를 제자리에서 교체, 에셋 `len`을 **새** 블록 크기(≤ 이전)로 설정, 동일한 파일 풋프린트 유지, 새로 설치 |
| 템플릿으로 재작성(모든 레이어의 픽셀 교체 + 지오메트리 이동) | ✅ **BLE로 렌더링됨** | 다이얼 373: 배경→청록 + cf=5 스프라이트→빨강 + X 224→100 이동, 모두 렌더링, 시침/분침 실시간 |
| 처음부터 100% 합성 구조화 다이얼 | ✅ **빌더 완료, 오프라인 검증됨** | `watchface_struct.rs`의 `0x20` 엔벨로프 빌더(`build_container`/`serialize`/`validate_container`); 103개 다이얼 모두 바이트 정확히 왕복 + 합성이 펌웨어 검증기 통과(§11.7). 🟡 `9075` 위의 기기 렌더링은 아직 촬영되지 않음 |
| 시스템 글꼴(`.font`) | ✅ **디코드/렌더링(전체)** | LVGL bin(비독점); 32개 숫자 글꼴(`num*/nm*`, 비압축) + 24개 텍스트 글꼴(`font*`, LVGL RLE `comp=1`) 모두 디코드 — 12208 글리프, 0 오버런, 전체 ASCII. RLE = LVGL v8.3 `lv_font_fmt_txt.c`(3상태 SINGLE/REPEATE/COUNTER + 행별 XOR 프리필터), 1:1 포팅, 디스어셈블리 없음 |

⚠️ 검은 화면 또는 `0a`를 유발하는 리스킨/재작성 함정: **이전 에셋 `len`**을 남겨둠(워치가 블록을
넘어 읽음 → 오버런 → 검은 화면); **파일 크기 증가**(설치 시 거부됨); 새로 설치 대신 **제자리에서**
id 재사용; ref-tail 블록 크기 체인을 수정하지 않고 **에셋 재정렬**(§11.11). 오늘은 치명적이지 않지만
어쨌든 올바르게 작성하세요: 씬 또는 에셋 풀에 대한 변경은 두 헤더 **CRC32** 워드를 무효화합니다 —
둘 다 다시 계산하세요(§11.4), `@0x00` 전에 `@0x20`.

### 11.7 `0x20` 씬 엔벨로프 — 디코딩 및 빌더 구현 완료 ✅

재작성된 **실제** 다이얼이 렌더링되는 이유는 파일의 씬 엔벨로프를 보존하기 때문입니다. 순수 합성
본문의 평면 `61 …` 레코드는 **거부됩니다** — 펌웨어 파서(`WFManager_Parser`, `0xdb35c`)는 본문(오프셋
`0x24`부터)이 `0x20` 씬 컨테이너로 시작해야 합니다. 전체 파일은 다음과 같습니다:```
[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

> ✅ 이는 §11.5/§11.8/§11.9의 "매직 오프셋"을 통합합니다. 해당 섹션들은 필드를 `0x61` 프레임 테이블 바이트를 기준으로
> 찾는데, 이는 이 구조체의 `+0x12`에 해당하므로 `−18`/`−16` = `x`/`y`이고
> **`−5` = `meta[9]`, 즉 소스 ID**입니다. 동일한 바이트, 하나의 깔끔한 레이아웃입니다. 체계적으로 1만큼 어긋났던
> 순방향 스캔 `82`-속성 휴리스틱은 전혀 필요하지 않습니다. 구조체의 `meta[9]`를 읽으면 됩니다.
> 숫자 필드의 `max` 역시 단지 `meta[11..13]`입니다(예: 일(day-of-month) 필드는 `max = 99`를 가짐).

**Ref 꼬리** (`61`) — 노드가 비트맵을 가리키는 방식:```
+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`는 데이터 소스 id(§16)이며, §11.13의 **합성 슬롯 id**를 포함합니다. 연산자와 15개 다이얼에서 측정된 발생 횟수는 다음과 같습니다:

| op | 의미 | 발견 횟수 |
|---|---|---|
| `0x01` | `value == val`이면 표시 | 99 |
| `0x81` | `0x01`과 동일(`0x80` 비트 설정 — 상호 배타적 변형에 나타남) | 48 |
| `0x02` | `value == val`이면 **숨김** | 7 |
| `0x03` | `value == val`이면 표시, 여기서 `val`은 **데이터 없음 마커**(예: HR `1000`) | 13 |
| `0x05` | `value >= val`이면 표시 | 58 |
| `0x06` | `value <= val`이면 표시 | 50 |
| `0x04` | ⚠️ **알 수 없음** — 15회 발생, 확인된 의미 없음 | 15 |

결합 규칙(참조 렌더러가 구현한 방식, 마스크 `op & 0x7f`): 동등 항목들은 **OR**로 결합된 후, 숨김/`>=`/`<=` 항목들이 **모두** 충족되어야 합니다.

이 단일 메커니즘은 형식의 런타임 변동성 대부분을 설명하며, 중복된 위젯처럼 보이는 구조를 설명합니다:

- **12시간/24시간 및 미터법/야드파운드법 레이아웃** — 같은 위치에 두 개의 위젯 세트가 겹쳐 있으며, 각각 `id 0x73`(단위 플래그)에 `val` 0 또는 1로 바인딩됩니다. 다이얼 275에는 이러한 쌍이 6개 있습니다(12개 노드).
- **"데이터 없음" 자리 표시자** — 센티널 값에 대한 op `0x03`, 예: `id 0x5f, val 1000`(다이얼 275, 두 번): 측정값을 사용할 수 없을 때 온도 대신 em-dash 아트를 그립니다.
- **버킷 하이라이트** — 쌍을 이루는 `0x05`/`0x06` 범위, 예: Metaball의 체인에서 각 링크가 자체 5분 창 동안 켜집니다.
- **컴플리케이션 슬롯 대체 항목** — §11.13의 합성 슬롯 id에 바인딩됩니다.

### 11.13 구성 가능한 컴플리케이션 슬롯 — `0x85` + `0x5f` ✅ (§11.8 대체)

§11.8에서는 구성 가능한 컴플리케이션의 활성 측정값이 기기 RAM 상태이며 파일에서 복구할 수 없다고 결론지었습니다. **그것은 틀렸습니다** — 슬롯의 측정값 메뉴와 기본 선택 항목이 모두 `.bin`에 있습니다. 각 `0x85` 노드는 `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

페어링은 고정적이다: `0x80`은 항상 정확히 `0x01` + **19바이트** `0x5a`를, `0x81`은 항상 정확히
`0x01` + **17바이트** `0x5b`를 운반한다 (✅ 15개 다이얼에서 26/26개 링). ⚠️ 그러나 **이미지로 잘린 `0x81`
이 지배적**이다 — 그 26개 중 25개. 절차적 `0x80`/`0x5a` 변형은 **한 번만** 나타났으며 (다이얼 273), 따라서 그
`radius` 필드와 19바이트 레이아웃은 단일 샘플에 의존한다; 다시 보일 때까지 의심스럽게 취급하라.

`frac = clamp((value − min) / (max − min), 0, 1)`, 그리고 채워진 호는 `start`에서 `end` 방향으로 그려진다.
각도 0은 **3시 방향**, 양수는 시계 방향. 측정된 예시:

| 다이얼 | 태그 | min..max | start → end | 폭 | radius |
|---|---|---|---|---|---|
| 273 Activity Mood | `0x5a` | 0..100 | **−102.8° → 102.8°** | 42 | 222 |
| 273 Activity Mood | `0x5b` | 0..100 | 270.0° → 90.0° | 80 | (이미지) |
| 276 Dichotomy | `0x5b` | 0..100 | 60.0° → −120.0° | 23 | (이미지) |
| 304 Elaborate 2 | `0x5b` | 0..100 | −2.0° → 358.0° | 24 / 80 | (이미지) |
| 366 Combo | `0x5b` | 0..100 | 0.0° → 270.0° | 18 | (이미지) |
| 368 Function | `0x5b` | 0..100 | 0.0° → 360.0° | 20 | (이미지) |

> ⚠️ **이것은 §11.5의 "12시 방향에서 시계 방향" 가정을 수정한다.** 그것은 오직 특수한
> 경우 `start = 0, end = 3600` (전체 스윕, 관례를 관찰할 수 없는 경우)에만 해당한다. 실제 다이얼은
> **부분 게이지** (273의 ±102.8° 부채꼴, 366의 270° 3/4 링) 및 **음수 스윕**
> (276의 60° → −120°)을 사용하므로, 항상 위에서부터 전체 원을 스윕하는 렌더러는 그것들을 잘못 그린다.
> 🟡 정확한 각도 0 관례와 방향 규칙은 fmc의 렌더러에서 비롯되었으며, 디스크의 이 값들과 교차 검증되었다 —
> 이 저장소에서 기기에서 픽셀 단위로 독립 검증되지는 않았다.
> `frac = value/max` 및 §11.5의 `0x81` 섹터 클립 결과는 **검증되었다** (다이얼 322).

⚠️ **미해결: 3바이트 트레일러 `01 00 kk`.** `kk`는 그럴듯한 값 (104, 152, 216,
232, 248)을 취하며, 명백한 가설은 radius이다 — **테스트 및 반증됨**: 다이얼 366은 82×82 및 166×166 링
모두에 `kk = 104`를 사용하고, 다이얼 273은 440×440 및 284×284 링 모두에 `kk = 232`를 사용한다.
radius도, 지름도 아니다. 아마도 불투명도/스타일. 그대로 왕복 전송하라.

🟡 **보고된 함정, 여기서는 검증되지 않음:** fmc의 렌더러에서, 소스 id가 같은 화면의 **임의의** 링의 id와
같은 `0x60` 숫자는 원시 값 대신 `round(frac × 100)`을 렌더링한다 — 따라서
심박수 링 옆의 심박수 숫자는 `71 bpm` 대신 `36`을 표시한다. 그들의 문서화된
해결 방법은 링과 숫자를 동일한 메트릭의 두 **별칭** id에 배치하는 것이다 (걸음
`0x19`/`0x26`/`0x49`, 칼로리 `0x1c`/`0x1e`/`0x48`). 이것이 펌웨어 동작인지 아니면 그들의
렌더러에 특정한 것인지는 **확립되지 않았다** — 이를 기준으로 설계하기 전에 실기기 확인이 필요하다.

---

## 12. 대량 전송 및 OTA 세부 사항

전송 테이블은 §6에 있다. 추가 확인된 사항:

- **AGPS/EPO** ✅: 첫 번째 기록된 청크는 ASCII 헤더 `000000010000…`로 시작한다. 전체
  init → `[A05F ↔ 905F]×N` → finish 루프가 와이어에서 관찰되었다 (~892 청크).
- **펌웨어 OTA** (`9040`–`9042`, finish `9041`) 🔎: 구조 매핑됨; INIT2 페이로드 = 버전 바이트
  (예: `0b 00 00 39` = 11.0.0.57). **현장 테스트되지 않음** (앱이 여기서 FW 업데이트를 비활성화함). 펌웨어
  이미지는 **서명되지 않은 것으로 보인다 — 무결성은 CRC32뿐** (RE에서 비대칭 서명이 관찰되지 않음).
- ⚠️ OTA와 `FACTORY_RESET (009A 0001)`가 인증된 세션을 공유하므로, 단일 유효한 BLE
  인증만으로 시계를 초기화하거나 (원칙적으로) 벽돌로 만들 수 있다. 주의해서 다루어라.

---

## 13. 센서

✅ BLE를 통해 노출된 하드웨어:

- **광학 PPG** — 심박수 (수동/자동/운동/휴식), SpO₂, 및 HRV 기반 스트레스.
- **3축 가속도계** — 걸음, 거리, 칼로리, 수면 단계, 손목 들어올리기, 케이던스.
- **GNSS/GPS** (AGPS 지원) — 운동 트랙 (`WORKOUT_GPS`) 및 위치 푸시 (`GPS_PUSH`).

**기압계/고도계, 나침반, 자이로스코프, 또는 피부/체온 센서는 없다.** 내부
NTC 서미스터 (보드/배터리 온도)가 존재하지만 **AT 채널을 통해서만** 읽을 수 있다
(`AT GETNTCTEMP`, §14) — `0155` 피부 온도 기록 스트림은 이 SKU에서 비어 있다.

**데이터 위젯 하이재킹** (실제 컴플리케이션/데이터 바인딩 API는 없음 — §11.5 참조): 시계의
기존 텍스트 필드는 한눈에 보는 외부 데이터를 표시하도록 용도를 변경할 수 있다. 입증됨 ✅: 날씨
**도시 문자열** (`WEATHER_SET_1`, 예: `"BRA 2x1 ARG"`가 위젯에 나타남) 및 음악
**트랙/아티스트** 필드; **연락처** 목록 (20 × 이름[32]+번호[25])은 스크롤 가능한 데이터
패널로 작동한다. 모두 푸시이며, 영구 컴플리케이션이 아니다.

---

## 14. AT 팩토리 / 셸 채널 (`77d4ff01` / `77d4ff02`)

프레임 프로토콜과 독립적인 별도의 일반 텍스트 AT 명령 채널. ✅ 실기기 테스트됨:

- **읽기:** `AT GETSECRET` (16바이트 페어링 비밀), `GETVERSION`, `GETSN`, `GETNAME`, `GETPID`,
  `GETBATLV` (원시 mV, 예: `3853mv`), `GETGSENSOR` (원시 가속도 g 단위, `X=… Y=… Z=…`),
  `GETNTCTEMP` (°C, 내부 NTC).
- **쓰기 / 작동:** `AT SETMOTOR=1` (모터 진동), `SETHR/SETHRV/SETSPO2=…` (센서 테스트
  주입), `SETLCDSWITCH/SETGPSSWITCH/SETKEYSWITCH`.

응답은 `,OK`로 끝난다. `SET*` 명령은 일반적으로 실행되지만 BLE를 통해 `,OK`를 에코하지 않을 수 있다 —
경우에 따라 확인하라.

---

## 15. 펌웨어 게이트 / 사용 불가 기능 (🔎 펌웨어 RE)

일부 기능은 펌웨어에 존재하지만 SKU/지역에 의해 비활성화되어 있으며 **폰/BLE에서 접근할 수 없다** —
펌웨어 수정이 필요하며, 이는 여기서 범위를 벗어난다:

- **ChatGPT 음성** — 게이트 = `ux2sys` 기능 id `0x9e`, 부팅 시 NVRAM/EFUSE/지역에서 시드됨; 이
  SKU에서 지원 플래그 `908b = 00`. 폰, 계정 또는 BLE로 영향 불가 (실험 + RE로 확인됨). 앱은 단지
  릴레이일 뿐; 오디오는 폰 → Nothing 클라우드로 이동.
- **혈압** — 완전한 하위 시스템이 펌웨어에 존재하지만 SKU/지역에 의해 꺼져 있다.
- **Alipay / NFC 결제** — 전체 UI 존재, 중국 SKU 전용.
- **하드웨어/펌웨어에 없음:** ECG, SOS/비상, 일반 NFC.

---

## 16. 데이터 소스 / 컴플리케이션 getter id

BLE 클라이언트를 구축하는 데는 필요하지 않지만, 다이얼을 **작성하거나 렌더링하는 데 필수적**이다: 이것은
위젯을 실시간 데이터에 바인딩하는 `meta[9]` (§11.11)의 값, 가시성 조건의 `id` (§11.12), 그리고
슬롯의 메트릭 메뉴 항목 (§11.13)이다. 펌웨어는 `0x101f371c`의 **142개 항목 getter
디스패치 테이블**을 통해 이를 해석하며, 각 항목은 `ux2sys_get(type)`을 호출한다 (🔎 펌웨어 RE).

### 시간 / 날짜 — ✅ 잘 확립됨

| id | 의미 | id | 의미 |
|---|---|---|---|
| `0x01` | 시 (기기 설정에 따라 12/24시간) | `0x0f`, `0x12` | 초 (부드러운) |
| `0x04` | 시 (24시간) | `0x10`, `0x11` | 초 십의 자리 / 일의 자리 |
| `0x07` | 시 (강제 24시간) | `0x71`, `0x72` | 초 (틱 / 바늘 각도) |
| `0x02`, `0x03` | 시-12시간 십의 자리 / 일의 자리 | `0x13` | AM/PM 플래그 (0 = AM, 1 = PM) |
| `0x05`, `0x06`, `0x08`, `0x09` | 시 십의 자리 / 일의 자리 | `0x15`, `0x16` | 월 |
| `0x0a`, `0x70` | 시 바늘 각도 | `0x17` | 일 |
| `0x0b` | 분 | `0x18` | 요일 (0 = 월요일 ⚠️) |
| `0x0c`, `0x0d` | 분 십의 자리 / 일의 자리 | `0x0e`, `0x71` | 분 바늘 각도 |

십의 자리/일의 자리 id는 **단일 숫자**를 그린다 — 그 중 하나에 바인딩된 위젯은 전체 값이 아닌 하나의
글리프를 렌더링한다 (다이얼 284 Square). 바늘 각도 id (§11.5)는 `0x0a`/`0x70` 시 = `h·30° + m·0.5°`,
`0x0e`/`0x71` 분 = `m·6° + s·0.1°`, `0x12`/`0x72` 초 = `s·6°` (✅ getter 디스어셈블로 확인됨,
RTC 폴백 10:10:30).

### 건강 / 센서 / 날씨 — ⚠️ 논쟁 중, 증거 열을 읽으라

| id | 의미 (현재 최선의 해석) | 증거 |
|---|---|---|
| `0x19` | **걸음** | 368의 슬롯 메뉴에서 `0x1a`와 함께; 이 저장소의 `parse.ts`와 일치 |
| `0x1a` | **심박수** | 368의 슬롯 메뉴에서 `0x5f` 및 `0x19`와 함께 |
| `0x1c` | 칼로리 | 슬롯 메뉴, 동반 앱의 불꽃 아이콘 |
| `0x1e` | 칼로리 (별칭) | 코퍼스 |
| `0x22` / `0x23` | 거리 km / mi (정수 부분) | 코퍼스 |
| `0x74` / `0x75` | 거리 km / mi (소수 부분) | 코퍼스 |
| `0x76` | 거리 (슬롯 형식) | 슬롯 메뉴, 도로 아이콘 |
| `0x24` | **배터리 %** | 슬롯 메뉴, 번개 아이콘 |
| `0x30` | 배터리 % | 코퍼스 |
| `0x36` / `0x5f` | 온도 | `0x5f` = 슬롯 메뉴, 구름-태양 아이콘; 361 TempoG는 일반 숫자를 바인딩 |
| `0x48` | 스탠드 (서 있던 시간) | 슬롯 메뉴, 서 있는 인물 아이콘 |
| `0x8b` | AQI | 슬롯 메뉴 |
| `0x73` | 24시간 / 미터법 단위 플래그 | 코퍼스 |
| `0x25`–`0x27`, `0x49`, `0x6c`, `0x6f` | 목표 % / 걸음 및 칼로리의 슬롯 별칭 | 코퍼스 |
| `0x6a` | ⚠️ 미식별 슬롯 메트릭 | 4개의 슬롯 메뉴에 나타남 |
| `0x79 + slotIndex` | **합성** — 메트릭이 아님; 슬롯 선택 id (§11.13) | ✅ §11.13 |

> ⚠️ **이 저장소의 세 테이블이 불일치했다; 이것이 조정 결과다.** §16 및 §11.5의 이전 개정판은
> `0x19`를 심박수, `0x1b`를 배터리, `0x24`를 온도, `0x36`을 걸음으로 읽었으며 —
> `wfweb/src/codec/mock.ts`는 여전히 그 해석을 인코딩하는 반면, `wfweb/src/codec/parse.ts`는
> 다른 해석 (`0x19` 걸음, `0x24` 목표 %, `0x48` 스탠드, `0x1a` 날씨)을 인코딩한다. 위 테이블은
> 더 나은 증거를 가진 해석을 따른다 (라벨은 fmc가 동반 앱의 자체 위젯 슬롯 메뉴 아이콘에 대해 보정함,
> §출처 참조). **코드는 아직 변경되지 않았다 — `mock.ts`와 `parse.ts`는 여전히 서로 및 이 테이블과
> 불일치한다.** 누군가 각 id에 필드를 바인딩하고 시계를 읽을 때까지 건강 id 라벨을 ⚠️로 취급하라.
>
> 가장 강력한 단일 증거는 **다이얼 368 Function의 슬롯 메뉴** (§11.13)로, 하나의 메뉴에서
> `0x5f 0x1c 0x19 0x48 0x24 0x76 0x1a 0x8b`를 **8개의 서로 다른 사용자 선택 가능 메트릭**으로 제공한다.
> 라벨이 무엇이든, 그 8개 중 두 개는 동일한 메트릭일 수 없다 — 이는
> `0x19` = `0x1a` = 심박수 및 `0x24` = `0x5f` = 온도가 동시에 성립하는 것을 배제한다.

**프레임 시트**가 있는 링/아크 컴플리케이션은 보내는 `.bin`에 구워진 사전 렌더링된 프레임 (예: 50 % = 100개 중 프레임 50)을
인덱싱하므로 (§11.5), 외부 RES 팩이 필요 없다; 이미지 없는 링은 대신 아크 사양에서 그려진다 (§11.15).

---

### 퀵 카드 (홈 타일) — `QUICK_CARD (906D)` ✅

시계의 홈 타일. 폰은 **어떤** 타일을 표시할지와 **어떤 순서로** 표시할지만 선택한다 — 타일은
펌웨어에 의해 렌더링된다 (콘텐츠 채널 없음). 첫 번째 페이로드 바이트 = 하위 명령: `00` = GET, `01` =
SET; **둘 다 `0x906D`를 사용한다** (`0x906C`는 나열되지만 사용되지 않음 — 쿼리 시 시간 초과). 응답 = `A06D`.

> 🛑 임의의 `assemblyId`를 보내면 **시계의 화면이 지워진다** (목록을 수락하지만 id를
> 일치시킬 수 없어 아무것도 표시하지 않음). GET을 통해 **읽어온** id만 보내라; 공식 앱 또는
> 공장 초기화로 복구하라.

**GET 응답** ✅: `status(1) ‖ 00 ‖ N(1) ‖ N × 그룹`, 그룹 = `tag=01 ‖ K(1) ‖ K×(assemblyId, sportId)`.
실제 프레임: `01 00 04  01 02 5d00 6100  01 03 1900 2e00 2300  01 03 5c00 0400 5a02  01 03 4800 5100 5300`
= 4개 화면 / 11개 카드 (`5a02` = Sport 카드, sportId 2).

**슬롯:** 각 화면에는 **4개의 슬롯**이 있다. 카드의 유형이 크기를 결정한다 — `circular`/`square` = 1 슬롯,
`rectangle` = 2 슬롯. 검증은 순수 슬롯 산술이다 (화면당 Σ ≤ 4); 상호 배타적 카드는 없다.
`sportId`는 Sport 카드 (87–91)를 제외하고 `0`이다. Id `64` 및 `95`는 존재하지 않는다.

**`assemblyId` 카탈로그** (각 논리 유형 = 6개 스타일 변형 `_0`..`_5`의 연속 범위;
`0` = 빈 슬롯):

| dec | 카드 | dec | 카드 |
|----|----|----|----|
| 0 | 빈 슬롯 | 49–53,97–98 | 날씨 |
| 1–6 | 걸음 | 54–58 | 타이머 |
| 7–12 | 칼로리 | 59–62 | 호흡 |
| 13–18 | 스탠드 | 63,65–67 | 스톱워치 |
| 19–24 | 중간 활동 | 68–71 | 배터리 |
| 25–30 | 심박수 | 72–76 | 최근 항목 |
| 31–36 | SpO₂ | 77–81 | 연락처 |
| 37–42 | 스트레스 | 82–86 | 다이얼 / 폰 |
| 43–48 | 수면 | 87–91 | Sport (`sportId` ≠ 0) |
| 92 | 음악 | 93/94/96 | 활동 기록 / PAI / 사이클 |

---

## 부록 A. 기본 다이얼 카탈로그 (id → 이름)

§11은 전체에서 숫자 id로 다이얼을 참조한다 (275 SlopeTime, 322 Glare 2, 357 Silhouette, …). Id
`273`–`376`은 스토어/기본 페이스이다; id는 `DIAL_COMMAND (9055/a055)`가 활성으로 보고하고
`9075`가 `old_id`로 받는 값이다 (§11.4). 알려진 103개 id 중 100개가 아래에 이름이 지정되어 있다; 나머지는
ROM 스텁이다 (§11.4). 이름과 그룹은 공식 동반 앱에 표시된 대로이다.

- **기본** (6) — `273` Activity Mood · `274` Sun Circle · `275` SlopeTime · `276` Dichotomy · `277` Prismatic Time · `280` Multifunction
- **아날로그** (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
- **디지털** (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
- **멀티펑션** (10) — `304` Elaborate 2 · `344` InfoMeter · `348` Tumbler · `354` Dual · `363` Vintage · `366` Combo · `367` Complex Figure · `368` Function · `374` Cirquary · `375` InfoHub
- **크리에이티브** (8) — `284` Square · `312` Disc · `317` Disc 2 · `318` Dominos · `332` Flux · `342` Perfect Match · `343` Progress Day · `358` Asteroid
- **디왈리** (1) — `295` Vortex

---

## 출처

위의 바이트 레이아웃은 펌웨어 (1.0.0.73), 공식 APK (3.5.7), 및 실제 기기에 대한 복호화된 실시간
캡처에서 재구성되었다. 이 프로젝트의 참조 구현은 `core-rust/src/{commands,frame,crypto,health,session}.rs` (Rust),
`wfweb/` TypeScript 편집기, 및 `cmftool/` Python 도구 (`pair.py`, `session.py`, `wf_codec.py`,
`upload_custom.py`, …)에 있다.

**여기에 통합된 독립 작업.** [freethinkel/fmc](https://github.com/freethinkel/fmc) — 동일한 시계를 위한
SvelteKit 워치페이스 편집기 + 마켓플레이스 — 는 ~100개 페이스 코퍼스에서 `.bin` 형식을 독립적으로
리버스 엔지니어링했으며 이 문서가 누락했거나 잘못 알고 있던 여러 결과에 도달했다. 그들의
`docs/cmf-protocol.md`, `src/lib/modules/editor/lib/{wf,render}.ts` 및
`src/lib/modules/device/lib/ble.ts`는 직접 읽을 가치가 있다. 채택된 발견 사항은 각각 여기에 기록되기 전에
다이얼 바이트에 대해 재검증되었다:

| 발견 사항 | 위치 | 여기서의 상태 |
|---|---|---|
| 두 헤더 워드 모두 CRC32 (비표준 변형) | §11.4 | ✅ 9/9 다이얼 재검증됨; **"차단 체크섬 없음" 수정** |
| 가시성 조건, 태그 `0x02` | §11.12 | ✅ 재검증됨; 문서화되지 않았었음 |
| 슬롯 메트릭 목록 + 기본 `activeIdx`, `0x79 + slotIndex` | §11.13 | ✅ 275/368/273/304에서 재검증됨; **§11.8 대체** |
| 액센트 틴트 기능 플래그 `meta[7] == 4` | §11.14 | ✅ 보급률 재검증됨; 문서화되지 않았었음 |
| 전체 아크 사양 (스윕 각도, 폭, radius) | §11.15 | ✅ 재검증됨; **"`max` u16 `@+4`" 수정** |
| Ref-꼬리 `u16`는 글리프 id가 아닌 블록 크기 | §11.11 | ✅ 10글리프 아틀라스에서 정확히 재검증됨 |
| 36바이트 푸터; 매직 바이트 변형 `0x02`; `0x86` = 64 B; `0x28` 포함된 미리보기 | §11.4, §11.11 | ✅ 재검증됨 |
| 동반 앱의 슬롯 메뉴에 대해 보정된 건강/날씨 id 라벨 | §16 | ⚠️ 최선의 해석으로 채택됨; 충돌 표시됨 |
| 셸 서비스 UUID는 `77d4e67c-…`, 및 Web Bluetooth `optionalServices` 범위 지정 | §1 | ⚠️ 단일 유닛 보고, 여기서 재검증되지 않음 |
| 링과 id를 공유하는 숫자가 백분율을 렌더링 | §11.15 | 🟡 보고됨, 여기서 **검증되지 않음** |
| 기본 다이얼 id → 이름 카탈로그 | 부록 A | ✅ 그대로 채택됨 |