- `cmd1`/`cmd2` を合わせて **オペコード** とします（§6 参照）。🔎 公式アプリのフレームビルダー（`C6117b.m30831g`）に対して確認済みです。
- `chunkCount` = このコマンドの総チャンク数。`chunkIndex` は **1 始まり** です。
- `chunkLen` = このフレーム内の `chunk` のバイト数。
- 1 回の BLE 書き込みはリンク MTU によって断片化される場合があります。受信側は生バイトをバッファリングし、完全なフレームを再抽出します。大きなペイロードは複数のチャンク（同じ `cmd1/cmd2`、増加する `chunkIndex`）に分割され、順番に再組み立てされます。

### オペコードの規約（✅ ワイヤ上で確認済み）

- `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` になります。

**平文の癖：** 平文オペコードの場合、ウォッチは `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**、**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**。

鍵導出：```
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`は**フレームごとに1回のBLE書き込み**で送信する必要がある。連結して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 の上から下への形式に変換し、
必要に応じて円外のピクセルをゼロにし、それぞれを 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` レコードスキーマは体系的に
> 1 バイトずれていました。** シーン本体はクリーンな 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` = アセット ptr; `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` オラクル（レンダリング vs 公式
> ストア 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°`）。✅ ゲッターの逆アセンブルで確認済み（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 エントリのゲッターテーブルを通じて id を解決します（各エントリは `ux2sys_get(type)` を呼び出します）。
  ⚠️ **id はこの前方 `82`-attr スキャンではなく、構造体の `meta[9]`（§11.11）として読むことを推奨** —
  これは §11.8/§11.9 で説明されている 1 バイトずれの原因です。完全な 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: bg→シアン + 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 を再利用する; 参照テールブロックサイズチェーンを修正せずに
**アセットを並べ替える**（§11.11）。今日は致命的ではありませんが、正しく書いてください: シーンまたはアセットプールへの変更は
2 つのヘッダー **CRC32** ワードを無効にします — 両方を再計算してください（§11.4）、`@0x20` を `@0x00` の前に。

### 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 つのクリーンなレイアウトにまとまります。体系的に 1 バイトずれていた前方スキャンの `82` 属性ヒューリスティックは、まったく不要です。構造体の `meta[9]` を読み取るだけで済みます。数値フィールドの `max` も同様に、単に `meta[11..13]` です（例: 日フィールドは `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時間およびメートル法/ヤード・ポンド法のレイアウト** — 同じ場所に積み重ねられた2つのウィジェットセット。それぞれが `id 0x73`（単位フラグ）に `val` 0または1でバインドされています。ダイヤル275にはそのようなペアが6つあります（12ノード）。
- **「データなし」プレースホルダー** — センチネルに対する op `0x03`、例：`id 0x5f, val 1000`（ダイヤル275、2回）：メトリックが利用できない場合、温度の代わりにemダッシュのアートを描画します。
- **バケット化されたハイライト** — ペアになった `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` に向かって描画されます。
角度ゼロは **3時の位置**、正の方向は時計回りです。測定例:

| ダイヤル | タグ | min..max | start → end | 幅 | 半径 |
|---|---|---|---|---|---|
| 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°)を使用するため、常に上部から全円をスイープするレンダラーはこれらを誤って描画します。
> 🟡 正確な角度ゼロの規則と方向の規則はfmcのレンダラーに由来し、これらのディスク上の値と照合されています —
> このリポジトリによってデバイス上でピクセル単位で独立検証されたわけではありません。
> `frac = value/max` と§11.5の `0x81` セクタークリップの結果は**検証済み**であることに注意してください(ダイヤル322)。

⚠️ **未解決: 3バイトのトレーラー `01 00 kk`。** `kk` はもっともらしい値(104、152、216、
232、248)を取り、明白な仮説は半径です — **テストして反駁されました**: ダイヤル366は82×82と166×166の両方のリングで `kk = 104` を使用し、ダイヤル273は440×440と284×284の両方の
リングで `kk = 232` を使用します。半径でも直径でもありません。おそらく不透明度/スタイルです。そのまま忠実に往復させてください。

🟡 **報告された落とし穴(ここでは未検証):** fmcのレンダラーでは、ソースIDが同じ画面上の**任意の**リングのIDと等しい `0x60` 数値は、生の値の代わりに `round(frac × 100)` をレンダリングします。つまり、
心拍数リングの隣にある心拍数数値は `71 bpm` の代わりに `36` を表示します。彼らの文書化された
回避策は、リングと数値を同じメトリクスの**エイリアス**ID 2つ(歩数
`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 × name[32]+number[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. データソース/コンプリケーションゲッターID

BLEクライアントを構築するために必要ではありませんが、ダイヤルを**作成またはレンダリングするには不可欠**です: これは
ウィジェットをライブデータにバインドする `meta[9]`(§11.11)の値、可視性条件の `id`(§11.12)、
スロットのメトリクスメニューのエントリ(§11.13)です。ファームウェアはこれを`0x101f371c` の**142エントリのゲッター
ディスパッチテーブル**を通じて解決し、各エントリは `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は**1桁**を描画します — それらのいずれかにバインドされたウィジェットは、値全体ではなく1つのグリフをレンダリングします
(ダイヤル284 Square)。針の角度ID(§11.5)は `0x0a`/`0x70` 時 = `h·30° + m·0.5°`、
`0x0e`/`0x71` 分 = `m·6° + s·0.1°`、`0x12`/`0x72` 秒 = `s·6°`(✅ ゲッターの逆アセンブルで確認済み、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 |

> ⚠️ **このリポジトリの3つのテーブルが矛盾していました。これはその調整版です。** §16の以前のリビジョン
> と§11.5は `0x19` を心拍数、`0x1b` をバッテリー、`0x24` を温度、`0x36` を歩数として読んでいました —
> そして `wfweb/src/codec/mock.ts` は依然としてその読み方をエンコードしていますが、`wfweb/src/codec/parse.ts` は
> 別の読み方をエンコードしています(`0x19` 歩数、`0x24` 目標%、`0x48` スタンド、`0x1a` 天気)。上記のテーブルは
> より証拠の強い読み方に従っています(ラベルはfmcがコンパニオンアプリ自身のウィジェットスロット
> メニューアイコンに対して較正、§Sources参照)。**コードはまだ変更されていません — `mock.ts` と `parse.ts` は依然として
> 互いに、そしてこのテーブルと矛盾しています。** 誰かが各IDにフィールドをバインドしてウォッチを読むまで、健康IDのラベルを⚠️として扱ってください。
>
> 最も強力な単一の証拠は**ダイヤル368 Functionのスロットメニュー**(§11.13)で、1つのメニューで
> `0x5f 0x1c 0x19 0x48 0x24 0x76 0x1a 0x8b` を**8つの異なるユーザー選択可能なメトリクス**として提供します。
> ラベルが何であれ、これら8つのうちの2つが同じメトリクスになることはありません — つまり
> `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 × group`、group = `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` = スポーツカード、sportId 2)。

**スロット:** 各画面には**4つのスロット**があります。カードのタイプがサイズを決定します — `circular`/`square` = 1スロット、
`rectangle` = 2スロット。検証は純粋なスロット演算です(画面ごとにΣ ≤ 4)。相互排他的な
カードはありません。`sportId` はスポーツカード(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 | スポーツ(`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 | ✅ 普及率を再検証済み。文書化されていなかった |
| 完全な円弧仕様(スイープ角度、幅、半径) | §11.15 | ✅ 再検証済み。**「`max` u16 `@+4`」を修正** |
| 参照テール `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 | ✅ そのまま採用 |