# Phase A→F 独立核查报告（可交给修复模型）

> **核查者立场**：本报告由独立核查 AI 撰写，不采信执行者（下称"执行者"）的
> 总结/session_state/checklist 叙述，全部结论来自 ① git 提交内容
> ② 仓库内官方逆向产物 ③ 核查者亲自重跑的命令与亲自编写的独立工具
> ④ 明确标注"无法判定"的真机项。
>
> **核查范围**：`06c1f30..8e1312a`（7 个提交），基线 `087e15c`；
> 核查时 HEAD = `0919f5e`（含核查指南提交）。
> **本轮核查未修改任何源码、未提交、未 push**；本报告文件是唯一新增物
> （未提交，`git status` 会显示为 untracked）。
>
> **总体结论**：第一关硬门槛（git 完整性 / 禁改清单 / debug+release 构建 /
> 44 项单测）**全部通过**。逐阶段核查发现 **2 项证伪**（Phase F 命令写入
> 未串行化、Phase F busy 未实现）、**1 项 Phase Z 越界**（Manifest 改动）、
> **2 项低风险偏差**，其余声明证实；需真机/双设备的项一律"无法判定"。
> Phase C 最高风险项（索引 4/8/9 映射）经独立复核**证实**，且本次找到了比
> 执行者更强的决定性证据。

---

## 0. 修复任务清单（给修复模型）

按优先级排列。每条含：位置、现象、根因、建议改法、改完怎么验、不修的风险。
**修复时仍须遵守 `execution_plan.md` §0 的禁改清单**（竖屏锁定、命令字节序、
握手序列、LiveRenderer 构图、analysis/ 只读）。

### FIX-1（高）`RemoteSession.send()` 并发写同一 socket 导致命令乱序

- **位置**：`android/app/src/main/kotlin/com/mag160c/thermal/net/RemoteClient.kt:256-269`
- **现象（已复现）**：`hello()` 紧接 `startStream()` 时，主机可能先收到 `start`；
  主机随即回 `stream-start`，客户端 reader 切到帧模式
  （`RemoteClient.kt:194`），后到的 `welcome` 文本被 `FramePacketReader` 当垃圾丢弃。
- **实测数据**：裸 socket 抓字节，5 次运行中 1 次观测到 `hello`/`start` 顺序颠倒；
  面向真实 `RemoteHost` 的生产序列压测 **120 次中 8 次丢失 `welcome` 行（≈6.7%）**；
  帧本身始终正常（30/30 各轮均收到）。
- **根因**：`send()` 每条命令 `scope.launch(Dispatchers.IO)` 新协程写同一个
  `socket.getOutputStream()`。多协程竞争同一流，**顺序无法保证**。
- **建议改法**：**不要用 Mutex**（Mutex 只保证互斥，不保证"launch 顺序=写入顺序"，
  本缺陷是乱序而非字节交错，加锁修不掉）。改为单写协程 + 队列：

  ```kotlin
  // RemoteSession 内新增
  private val outQueue = kotlinx.coroutines.channels.Channel<String>(
      kotlinx.coroutines.channels.Channel.UNLIMITED,
  )
  private val writerStarted = java.util.concurrent.atomic.AtomicBoolean(false)

  private fun ensureWriter() {
      if (!writerStarted.compareAndSet(false, true)) return
      scope.launch(Dispatchers.IO) {
          val out = socket.getOutputStream()
          try {
              for (line in outQueue) {
                  out.write((line + "\n").toByteArray(Charsets.UTF_8))
                  out.flush()
              }
          } catch (e: Exception) {
              if (!closed.get()) DebugLog.log("remote", "writer ended: ${e.javaClass.simpleName}")
          }
      }
  }

  private fun send(cmd: String) {
      if (closed.get()) return
      ensureWriter()
      outQueue.trySend(cmd)      // 调用方（UI 协程）顺序入队 → 顺序落盘
  }

  fun close() {
      if (!closed.getAndSet(true)) {
          runCatching { outQueue.close() }
          runCatching { socket.close() }
      }
  }
  ```

  要点：`trySend` 在**调用方线程**顺序入队，写 socket 只发生在唯一协程里。
- **可选补充（不替代上面的修复）**：客户端在帧模式下遇到非帧数据时，
  可先尝试按 JSON 行解析再丢弃，作为对旧主机的兼容容错。属于加固，不解决根因。
- **验证方法**：复跑"高频命令"用例——`hello()`+`startStream()` 连续 3 对，
  再接 400 次 `requestFfc()`，断言收到的行数、内容与**顺序**完全一致、
  无嵌套花括号行。（核查者的独立 harness 已实现该用例，见 §6。）
- **不修的风险**：目前 `welcome` 只被打印（`RemoteViewerViewModel.kt:103`），
  用户可见影响小；但 `hello→welcome` 契约已被破坏。同类乱序也可能发生在
  快速 stop→start、连续 FFC 等序列上，属真实缺陷。**建议修**。

### FIX-2（中）"后来者拒绝写 busy" 未实现

- **位置**：`android/app/src/main/kotlin/com/mag160c/thermal/net/RemoteHost.kt:130-151`（acceptLoop/serve）
- **现象**：`serve(socket)` 在 accept 循环内**同步**执行，第二个客户端只会在内核
  backlog 里排队等待第一个断开；主机**从不写 `busy`**。
  `RemoteContract.isBusyLine()`（`RemoteContract.kt:147`）全仓库**无调用点**，是死代码。
- **与计划冲突**：`execution_plan.md` F2 明确要求"单客户端，后来者拒绝写 busy"。
- **建议改法（二选一）**：
  - **(a) 实现**：accept 循环不阻塞在 serve 上，用标志位拒绝后来者：

    ```kotlin
    private val serving = java.util.concurrent.atomic.AtomicBoolean(false)
    // acceptLoop 的 while(running) 内：
    val socket = server.accept()
    if (!serving.compareAndSet(false, true)) {
        runCatching {
            val o = socket.getOutputStream()
            o.write((RemoteContract.busyLine() + "\n").toByteArray(Charsets.UTF_8))
            o.flush()
        }
        runCatching { socket.close() }
        continue
    }
    scope?.launch { try { serve(socket) } finally { serving.set(false) } }
    ```

    需在 `RemoteContract` 补 `fun busyLine(): String = "{\"type\":\"busy\"}"`；
    客户端侧建议在 `lines` 收集处对 `busy` 记一条日志（否则用户只看到连不上）。
  - **(b) 如不实现**：同步修改 `execution_plan.md` F2 与相关文档，如实写明
    "第二客户端排队等待，不写 busy"，并把 `isBusyLine()` 删除或标注保留用途。
- **验证方法**：单测/回环：client1 连上后 client2 连接，断言 client2 在 1s 内
  收到 `{"type":"busy"}` 或被立即关闭，且 client1 的帧流不受影响。
- **不修的风险**：单客户端约束事实成立，风险低；但"计划声明了、代码没有、
  解析器留了死代码"三者不一致，会误导后续维护者。

### FIX-3（低）lifetime 负载接受两种布局（超出官方规格的对冲）

- **位置**：`android/app/src/main/kotlin/com/mag160c/thermal/usb/IrSession.kt:226-231`
- **现象**：实现同时接受 ①`[magic][magic][ms]`（12B，计划代码片段的字面写法，
  与计划自己的"共 8 字节"描述矛盾）②`[magic][ms]`（8B，官方 Java 唯一实现）。
- **官方权威**：`jadx_magcx/.../UsbCommunication.java:190-205` —
  `bb.getInt()==1538635105` 后再 `getInt()`，即 **8 字节 `[magic][ms]`**。
  另注意 `IrSession.readResp` 已剥掉前 4 字节 magic（`r.third` 是**去掉** magic 的负载），
  故官方布局下 `r.first==8`、`r.third.size==4`、ms = `u32(r.third,0)`。
- **建议改法**（收紧为官方唯一布局）：

  ```kotlin
  readResp(conn, epResp, "GetLifeTime")?.let { r ->
      // readResp 已剥离 4B magic；官方帧共 8B → 余 4B 即 i32 ms
      if (r.second == MagProtocol.RSP_SEND_LIFETIME && r.third.size >= 4) {
          deviceLifetimeMs = MagProtocol.u32(r.third, 0).toLong() and 0xFFFFFFFFL
      }
  }
  ```

- **验证方法**：真机清单第 3 步出现 `[session] device lifetime=<ms>ms` 且非 -1。
- **不修的风险**：不会误判为连接失败，仅接受一个官方不发送的布局；低。

### FIX-4（低）多余权限 `ACCESS_NETWORK_STATE`

- **位置**：`android/app/src/main/AndroidManifest.xml:15`
- **现象**：全仓库 grep 无 `ConnectivityManager`/`NetworkCapabilities`/权限检查，
  该权限从未被使用（计划 F9 只要求 INTERNET）。
- **建议改法**：删除该行；若保留，需在提交信息/文档中说明用途。
- **验证方法**：`aapt2 dump badging build-artifacts/mag160c-app-debug.apk` 不再列出。

### FIX-5（低）Phase Z 越界：`8e1312a` 含 Manifest 功能性改动

- **位置**：`8e1312a` 修改了 `android/app/src/main/AndroidManifest.xml`（+3 条
  `uses-feature`：`camera`、`camera.autofocus` 显式 `required=false`，并改写注释）。
- **性质**：改动本身**合理**（防止 CAMERA 权限隐式要求相机硬件，保证无相机
  设备仍可运行热像主功能），执行者已主动交底；但违反"Z 内容须仅为文档/清单/APK"。
- **建议**：不需要回滚功能，**只需在 `session_state.md` / `execution_plan.md`
  如实记录该改动发生在 Z 提交**（承认越界），避免后续核查再次对不上账。

### FIX-6（低）文档口径修正

1. `docs/android_app/real_device_checklist.md:29`（第 15 步）：预期"返回后 PIP 画面
   重新出现"是**推断而非实测**。代码里 `PipCameraEngine.released` 置位后不复位，
   只能依赖 `onSurfaceTextureAvailable` 再次触发。**先按真机实测结果决定改文档
   还是改代码**（指南 §3E 明确：若真机不符，应判定为清单预期有误）。
2. `analysis/sdk_re/android_app/palette_extraction_findings.md:71`：红热占位图的
   分母表述混用了两类像素。实测（ImageIO 逐像素）：
   **全部像素 11777/11914 相同**；**不透明像素 8536/8673 相同**（meanAbsDiff 2.18/765）。
   原文"11914 个**不透明**像素中 11777 个相同"应改为上述两种口径之一。
3. `session_state.md` / `execution_plan.md`：补记本报告 §3-F 的两项证伪
   （FIX-1 乱序、FIX-2 busy 未实现），使文档不再高于实现。

### FIX-7（可选，测试加固）

1. `MdtTest`：补一条**含 EXIF 缩略图（内部含 `FF D9`）的 JPEG** 往返用例。
   核查者已独立验证当前实现能正确取主图 EOI（不会被缩略图干扰），
   但仓库测试缺失该场景，属回归风险。
2. `VendorPalettes`：`PalettesTest.vendorTablesCoverIndicesZeroThroughTen`
   （`PalettesTest.kt:47-63`）只证明 `Palettes.buildAll()` 用了 `VendorPalettes`
   的对应槽位，**不能**证明 `VendorPalettes` 里 case N 的内容确实来自 case N
   （全库仅 case 2 有官方锚点）。建议为 11 张表各加一条"金标"断言
   （如 256 项 CRC32/采样点），把本次已外部验证过的映射冻结住。
3. `RemoteLoopbackTest`：在 FIX-1 完成后，补"高频命令顺序"用例（见 FIX-1 验证方法）。
4. 清理死代码：`Palettes.kt:77/89/98/110` 的 `rainbow()`/`highContrast()`/
   `hotMetal()`/`jet()` 已无调用点（Phase C 接入精确表后遗留）。

### 判定为"可接受、无需修改"的项

- **Phase B 温度条固定未缩放 fitRect**：与计划字面一致（`imageRect(size,1f,Offset.Zero)`），
  取舍合理。
- **Phase B 探针标签随缩放/平移**（`AnalyzeViewer.kt:266` 用 `imageRect(size,zoom,pan)`）：
  与计划"标签随 fitRect 走"字面不符，但**实现明显更正确**（标签须跟随像素），
  判定为实现优于字面规格，建议保留（可在文档注明）。
- **Phase B 分析页直接映射（无 90° 旋转）**：`AnalyzeViewer` 画布 `aspectRatio(4f/3f)`
  且 `drawImage` 无 `canvas.rotate`，位图 `Bitmap.createBitmap(160,120)` 为原始朝向，
  直接映射正确。

---

## 1. 第一关：硬门槛（全部通过，故继续逐阶段核查）

| 声明 | 核查方法 | 结论 |
|---|---|---|
| 工作树干净 | `git status --short` 无输出 | 证实 |
| 范围内恰 7 个提交、消息与计划逐字一致 | `git log --oneline 087e15c..HEAD`，逐条比对计划"提交信息" | 证实 |
| 未 push | `git log --oneline -1 origin/main` = `087e15c` | 证实 |
| 竖屏锁定未改 | 源码 diff 无 `orientation` 删改；`aapt2 dump xmltree` 得 `screenOrientation(0x0101001e)=1` | 证实 |
| `MagProtocolTest` 未变 | `git diff --stat` 为空 | 证实 |
| `MagProtocol.kt` 仅新增常量 | diff 仅 `RSP_SEND_LIFETIME` 三行 | 证实 |
| `LiveRenderer.kt` 未变 | `git diff` 为空 | 证实 |
| `analysis/` 既有文件未被改 | `--diff-filter=M` 为空；仅 8 个新增文件 | 证实 |
| `IrSession` 握手序列未改 | 人工读 diff：66b→66c→66f→[670]→673、800ms 超时、前半段失败即 abort 全部保留；删除行仅两处（cache 读后加 MD5、stats 行追加 lifetime） | 证实 |
| `assembleDebug + assembleRelease + test` 全绿 | 亲自重跑：`BUILD SUCCESSFUL`（release 走完 R8） | 证实 |
| 44 个单测、逐类分布 3/3/5/8/6/4/12/3 | `--rerun-tasks` 强制重跑，逐 XML 汇总 = 44/0/0；每类用例名与指南表格一一对应 | 证实 |
| `RenderPipelineTest.matchesCReferencePixelExact` 仍通过 | 重跑后该用例在列且失败数为 0 | 证实 |

---

## 2. 逐阶段核查明细

### Phase A（`06c1f30`）

| 声明 | 方法 | 结论 |
|---|---|---|
| `RSP_SEND_LIFETIME = 0x5BB5B561` = 官方 `D2P_SendLifeTime` | `jadx_magcx/.../D2PCmd.java:10` = 1538635105；手算 `0x5BB5B561` = 1538635105 | 证实 |
| `CMD_GET_LIFETIME` 未改 = 官方 `P2D_GetLifeTime` | `P2DCmd.java:8` = 1807136373 = `0x6BB6B675` | 证实 |
| lifetime 失败不阻断连接 | `IrSession.kt:219-235` 失败仅 log，无 return/abort；官方 `getDevLifeTime` 亦仅 `Logging.error` | 证实（仅静态审查，无运行时证据） |
| cali 缓存 MD5 对照不改变返回值 | cache-hit 分支先算 `cached`，log `identical/differ` 后仍 `return cached` | 证实 |
| 心跳 stats 追加 lifetime | `IrSession.kt:559` `" lifetime=${deviceLifetimeMs}"` | 证实 |
| checklist 日志串与代码一致 | 独立重跑 `CheckStrings.java`：exact=16/skeleton=30/review=7；并逐条人工追溯 7 条到模板与调用点（`"$name write=$n/${packet.size}"` 418 行、`"$name resp=0x%08X len=%d head=%s"` 433 行、`"BasePara1: serial=... @${fps}fps"` 292 行、`"ep 0x%02X fail#..."` 408 行；调用点 `"GetParameter1"` 185、`"GetParameter2"` 201）。另抽查 `hb: state=`、`first reads`、`first rendered frame`、`first run on this host`、`requesting permission`、`permission result`、`[crash]`（DebugLog 崩溃钩子）均存在 | 证实 |
| 唯一偏差 | lifetime 负载接受两种布局（见 FIX-3） | 偏差（低） |

### Phase B（`656d419`）

核查者用 Gradle 缓存内的 Kotlin 编译器（`kotlin-compiler-embeddable-2.2.0.jar`）
在仓库外搭建独立 harness，直接编译并驱动**仓库真实源码**
（`Mdt.kt`/`TempMath.kt`/`OfficialTables.kt`），不依赖执行者的任何测试代码。

| 声明 | 方法 | 结论 |
|---|---|---|
| `Mdt.parse` 与 `compose` 互逆 | 独立构造**含 EXIF 缩略图（内部含 `FF D9`）**、长度 1081（非 4 对齐）的 JPEG，往返比对各段 | 证实：jpg/info0/info1/frame/text 全部字节一致，裁剪点为主图 EOI |
| 坏尾/截断返回 null | 翻转尾部 1 字节、截断至 100B | 证实 |
| text 去 NUL 填充 | `Mdt.kt:123` `trimEnd('\u0000')`；独立用例短文本往返 | 证实 |
| 温度图 = u16LE → `countsToTempMc` | **独立复算**：从 `csdk/src/mag160c_official_t2e.h` 解析 646 项真表（非 Kotlin 表），照 `mag160c_render.c:64` 重写 C 版算法，对 19200 像素全量比对 | 证实：19200/19200 完全一致 |
| 探针为"直接映射" | `AnalyzeViewer.kt`：`aspectRatio(4f/3f)`、`drawImage` 无 `canvas.rotate`、`Bitmap.createBitmap(160,120)` | 证实（静态） |
| 温度条固定未缩放 fitRect | `drawTemperatureOsd` 传 `imageRect(size,1f,Offset.Zero)` | 证实 |
| 探针标签 | 用 `imageRect(size,zoom,pan)`，与计划字面"随 fitRect"不同 | 偏差（实现更优，建议保留，见 §0） |

### Phase C（`b7a928e`）—— 本轮最需深挖的一相

| 声明 | 方法 | 结论 |
|---|---|---|
| `libcxsdk.so` 无静态调色板表 | 独立重跑 `PalScan.java`：三种编码（`B,G,R,0`/`B,G,R,0xFF`/忽略第 4 字节）**全部 not found**；[A] 段自校准证明扫描非盲 | 证实 |
| 索引↔case 映射 0..10（case 标签即调色板序号） | ① `libcxsdk_decomp.txt:456-1180`：`switch(param_2)`，case 0..10 各一份生成体（另有 `case 0xc`/`case 0xd`）；② **核查者新找到的决定性证据**：`jadx_magcx/.../DialogFragmentPalette.java` 的 `mapIndex2Id_` 把 UI 索引 0..11 依次对应白热…红热，点击时 `DeviceController.setColorPalette(index)` 把 **UI 索引原样传给 native** → case 标签 = UI 索引；③ case 2 → `OfficialTables.PALETTE256_ARGB` 256/256（重跑生成链复现） | 证实 |
| 索引 4/8/9 映射成立（执行者交底的不一致项） | **自写独立工具**（JDK `ImageIO` 解码官方预览图，不用执行者的手写 PNG 解码器），从 `PalBody` 重算全部 case 颜色集合，对 12 张预览图做完整覆盖矩阵 | 证实：case 0..10 **各自都是自身预览图的最佳解释者**；红饱和 case9 26.7% vs case0 22.1%，其 meanChroma=9.7 解释了"像素加权最近色距离"为何误判 |
| 索引 11 未解决、`SOURCE_CASE[11]==-1`、保留近似曲线 | `VendorPalettes.kt:24`、`Palettes.kt:47` | 证实 |
| 铁虹仍是官方表 | `officialIronbow()` 直接返回 `OfficialTables.PALETTE256_ARGB`；`PalettesTest.ironbowMatchesOfficialTables` 通过 | 证实 |
| 生成物可复现 | 两文件一起编译 → 重新生成：锚点 `iron_bow vs OfficialTables anchor: 256/256`；`VendorPalettes.kt`、`palette_candidates.json`、`palette_match_report.txt` **diff 全空** | 证实 |
| 红热预览图为占位副本 | ImageIO 逐像素：全像素 11777/11914 相同；不透明像素 8536/8673 | 证实（文档分母表述需修正，见 FIX-6） |
| `extract_palettes.py` | 本机无 python3，无法运行 | 无法判定（弱旁证） |

### Phase D（`c34940e`）

| 声明 | 方法 | 结论 |
|---|---|---|
| Retrofit 2.11.0 已接入 | `libs.versions.toml:9,24,25`；`app/build.gradle.kts:52,53` | 证实 |
| 默认关闭 | `AppSettings.kt:29-38`；`CloudClientTest` 4 项全绿 | 证实 |
| 无生产路径静默联网 | `grep -rn CloudClient android/app/src/main` 仅命中声明与 `AppSettings.setEnabled`；main 无 `api()` 调用点；`api()` 未开启即 `check()` 抛异常 | 证实 |
| release 混淆不破 | 亲自跑 `assembleRelease`（R8）成功 | 证实 |
| PROGUARD 规则 | `proguard-rules.pro:5` `-keep class com.mag160c.thermal.cloud.** { *; }` | 证实 |

### Phase E（`f8b3200`）

| 声明 | 方法 | 结论 |
|---|---|---|
| CAMERA 权限 + 相机可选；usb.host 仍 required | `aapt2 dump badging`：camera/camera.any/autofocus 均 not-required，`usb.host`/`screen.portrait` required | 证实 |
| 顶栏第 5 项 + 图标 | `LiveScreen.kt` 5 个 `weight(1f)` 项，第 5 项 `ic_pip`+`画中画`；`ic_pip.xml` 双弧圆描边 + 右下实心矩形 | 证实 |
| 三档 96/128/160dp、高=宽×3/4 | `PIP_WIDTHS_DP`；`hDp = wDp * 3 / 4`（72/96/120，整除无误差） | 证实 |
| 右侧留色标条位 | `PIP_RIGHT_MARGIN_DP = 32`，初始 `pipXf=1f,pipYf=0f` | 证实 |
| 异常不崩溃 | `PipCameraView.kt` 全部回调 try/catch，失败路径收敛到 `release()` | 证实（静态） |
| 相机释放三处 | `PipOverlay` 的 `DisposableEffect onDispose`、离页同路径、`LiveScreen` 的 `LifecycleEventObserver(ON_STOP)` | 证实（静态） |
| ON_STOP 后能否自动重开 | 代码侧 `released` 置位后不复位，重开依赖 `onSurfaceTextureAvailable`；本机无设备 | **无法判定** |
| 双 `pointerInput` 手势并存 | Compose 运行时行为无法在本机验证 | 无法判定 |

### Phase F（`512508e`）—— 2 项证伪

核查者用独立 harness 在 JVM 上驱动**真实的** `RemoteHost`/`RemoteSession`
（仅对 `DebugLog` 做最小桩），不打桩网络层。

| 声明 | 方法 | 结论 |
|---|---|---|
| 端口/魔数/帧长/超时与计划一致 | `RemoteContract`：47510/47511/`0x1BB1B11B`/38400/38412/3000ms/10000ms 逐项比对 | 证实 |
| 封包格式小端 | 独立断言字段偏移、字节序（`pkt[0..3]={1B,B1,B1,1B}`）、payload 位于 12 | 证实 |
| 粘包/截断/坏长度/重同步 | 3 帧一次读入→3 payload；按 1000B 任意切分→恰好重组 1 次；截断 20000B→0 输出且 `pending()==20000`；坏 length→下一 magic 恢复 | 证实 |
| 端到端可用 | 真实回环：connect→welcome→stream-start→5 帧（payload 逐字节）→ffc 到达主机回调→stream-stop；`RemoteLoopbackTest` 3 项亦全绿 | 证实 |
| 渲染在客户端本地 | `RemoteViewerViewModel`：本地 `RenderPipeline(160,120)`+assets `mag160c.ddt`；`setPalette` 只调本地管线；`setZoom` 只改状态 | 证实 |
| 主机侧不拖慢相机 | `Channel(capacity=8, DROP_OLDEST)`+`trySend`（USB 读线程非阻塞）+单一 `serve()` 协程写 socket | 证实 |
| 默认不启动；开启需活跃 USB 会话 | `setRemoteHostEnabled` 先 `if (!session.isStreaming()) return false`，UI 弹"先连接热像仪" | 证实 |
| INTERNET 权限 | badging 已声明 | 证实 |
| 单客户端，后来者拒绝写 busy | `acceptLoop` 内同步 `serve()`，第二连接排队等待，从不写 busy；`isBusyLine` 死代码 | **证伪**（见 FIX-2） |
| 命令写入不交错 | 见 FIX-1：120 次生产序列中 8 次丢 `welcome`；裸 socket 抓到 `hello`/`start` 颠倒 | **证伪**（见 FIX-1） |
| UDP 广播真机可达性 | 仅回环证据 | **无法判定** |
| `ACCESS_NETWORK_STATE` | 全代码无使用点 | 偏差（见 FIX-4） |

### Phase Z（`8e1312a`）

| 声明 | 方法 | 结论 |
|---|---|---|
| 消息无强制格式 | `git log -1 --format=%B` | 证实 |
| 内容仅为文档/清单/APK | `git show --stat`：3 份文档 + APK，**外加 Manifest（+3 条 uses-feature）** | **证伪**（见 FIX-5） |
| 文档更新到位 | HANDOFF §3 含 `ui/remote/`、`net/`、`cloud/CloudApi.kt`；session_state 勾选 A–Z 并追加总结；execution_plan 顶部加执行状态 | 证实 |
| 全量构建 + 提交 APK，且不 push | 重跑 debug+release+test 成功；`origin/main` 仍 `087e15c` | 证实 |
| 提交的 APK 与 HEAD 一致 | 对已提交 APK 核验：`screenOrientation=1`、camera 系列 not-required、INTERNET/CAMERA 已声明、dex 内含 `画中画`/`正在扫描局域网主机`/`云同步`（E/D/F 代码确在包内）。APK 字节不可复现（时间戳），故以内容核验替代字节比对 | 证实（以内容为准） |

---

## 3. 核查边界：本机无法判定（须真机裁决，未默认通过）

本机（Windows）无模拟器、无连接设备、`adb devices` 为空。以下必须真机判定：

1. USB 出流与温度绝对值标定（清单 1–12 步）。
2. 可见光 PIP 全部运行时行为（13–15 步）：**含"返回后画面是否重新出现"**、
   单击换档/双击关闭/拖拽三种手势是否互不干扰。
3. 局域网远程预览双机行为（16–24 步）：**含 `255.255.255.255` 广播在真实
   Wi-Fi 上是否可达**（部分路由/AP 会过滤广播；息屏策略也可能影响收包）。
4. 分析页温度条/探针的实际显示与取温正确性（11 步）。
5. 任何"画面/像素"层面的确认。

清单本身已按指南机械核对：16 条字面命中、30 条骨架命中、7 条人工追溯全部
落实到真实模板与调用点，未发现凭空编造。清单可继续作为真机验证脚本。

---

## 4. 真机测试时请重点确认（与修复决策挂钩）

| 要确认的事 | 怎么看 | 影响哪个修复 |
|---|---|---|
| 远程预览：连上后是否每次都看到"welcome"日志 | B 端日志 `[remote] line: {"type":"welcome"...}` 是否出现；连续重连 10 次统计 | FIX-1（当前约 6.7% 丢失） |
| 快速 stop→start、连点 FFC 是否偶发失灵 | 反复操作，看 B 端画面是否与按钮状态不一致 | FIX-1 |
| PIP：Home 返回后小窗是否重新出现 | 清单 15 步 | FIX-6.1（决定改文档还是改代码） |
| PIP：单击换档 / 双击关闭 / 拖拽是否互不干扰 | 清单 14 步，各做 5 次 | 若互相干扰则需改手势实现（本机无法判定） |
| 分析页：点已知温度位置，读数是否合理 | 清单 11 步 | 探针直接映射的运行时确认 |
| 远程预览：局域网是否能在 10s 内发现主机 | 清单 19 步 | UDP 广播可达性 |
| lifetime 是否非 -1 | 清单第 3 步 `[session] device lifetime=<ms>ms` | FIX-3 |

---

## 5. 核查者使用的判据来源（可独立复核）

| 判据 | 路径 |
|---|---|
| 协议权威（官方 Java） | `analysis/sdk_re/android_app/jadx_magcx/cn/com/magnity/magnitycx/sdk/{D2PCmd,P2DCmd,UsbCommunication}.java` |
| 官方调色板 UI 顺序与 native 调用点（**本次新用**） | `analysis/sdk_re/android_app/jadx_magcx/cn/com/magnity/magnitycx/DialogFragmentPalette.java` |
| native 伪代码（12+2 个生成体） | `analysis/sdk_re/android_app/libcxsdk_decomp.txt`（`SetColorPalette @00026c70`，case 0..10、0xc、0xd） |
| 铁虹真表（真实内存布局 `B,G,R,0`） | `csdk/src/mag160c_official_palette256.h` |
| 温度 C 参考实现 + T2E 真表 | `csdk/src/mag160c_render.c:64`、`csdk/src/mag160c_official_t2e.h` |
| 帧布局权威 | `csdk/src/mag160c_frame.c:11-13`（像素自 `+0x1c`，总长 `0x38+len`） |
| 官方预览图 | `app/【普通版】MAG-Cx.apk` → `res/mipmap-hdpi-v4/palette_*.png`（12 张） |

---

## 6. 复现命令（修复模型可直接照跑）

### 6.1 构建 + 全量单测（Windows Git Bash）

```bash
cd /c/Project/MAG160C/android && export JAVA_HOME="C:\\Tools\\jdk-21" && \
  cmd //c "C:\Project\MAG160C\android\gradlew.bat :app:assembleDebug :app:assembleRelease test --no-daemon"
# 强制重跑（否则 UP-TO-DATE 不产生新结果）
cmd //c "C:\Project\MAG160C\android\gradlew.bat :app:testDebugUnitTest --rerun-tasks --no-daemon"
# 单测计数
grep -h -o 'tests="[0-9]*" skipped="[0-9]*" failures="[0-9]*" errors="[0-9]*"' \
  /c/Project/MAG160C/android/app/build/test-results/testDebugUnitTest/*.xml
```

### 6.2 Phase C 否证复核 + 生成物可复现

```bash
cd /c/Project/MAG160C
"C:\Tools\jdk-21\bin\java" analysis/tools/PalScan.java \
  analysis/sdk_re/android_app/bin/libcxsdk.so csdk/src/mag160c_official_palette256.h
# 期望：三种编码全部 not found；[A] 段自校准 detected 1 candidate

mkdir -p /c/Users/zxc/AppData/Local/Temp/regen_build && \
cd /c/Users/zxc/AppData/Local/Temp/regen_build && \
cp "C:\Project\MAG160C\analysis\tools\PalIdentify.java" . && \
cp "C:\Project\MAG160C\analysis\tools\PalExport2.java" . && \
"C:\Tools\jdk-21\bin\javac" -d out PalIdentify.java PalExport2.java && \
"C:\Tools\jdk-21\bin\java" -cp out PalExport2 \
  "C:\Project\MAG160C\android\app\src\main\kotlin\com\mag160c\thermal\core\OfficialTables.kt" \
  "C:\Users\zxc\AppData\Local\Temp\cxres\res\mipmap-hdpi-v4" \
  "C:\Users\zxc\AppData\Local\Temp\regen_core" \
  "C:\Users\zxc\AppData\Local\Temp\regen_out"
# 期望末行：iron_bow vs OfficialTables anchor: 256/256
diff "C:\Users\zxc\AppData\Local\Temp\regen_core\VendorPalettes.kt" \
     "C:\Project\MAG160C\android\app\src\main\kotlin\com\mag160c\thermal\core\VendorPalettes.kt"
diff "C:\Users\zxc\AppData\Local\Temp\regen_out\palette_candidates.json" \
     "C:\Project\MAG160C\analysis\sdk_re\android_app\palette_candidates.json"
# 期望：两条 diff 均为空
```

### 6.3 独立 Kotlin harness（仓库外编译仓库真实源码）

无 gcc / 无 kotlinc，用 Gradle 缓存内的编译器：

```bash
KC=/c/Users/zxc/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin
KX=/c/Users/zxc/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlinx
STDLIB=$KC/kotlin-stdlib/2.2.0/fdfc65fbc42fda253a26f61dac3c0aca335fae96/kotlin-stdlib-2.2.0.jar
COMPILER=$KC/kotlin-compiler-embeddable/2.2.0/8cfa2b049a4006d94474296df4abd9b50f288821/kotlin-compiler-embeddable-2.2.0.jar
SCRIPT=$KC/kotlin-script-runtime/2.2.0/87c92e866fcd68680966a3005a2992e1ab8ec6ad/kotlin-script-runtime-2.2.0.jar
CORO=$KX/kotlinx-coroutines-core-jvm/1.8.0/ac1dc37a30a93150b704022f8d895ee1bd3a36b3/kotlinx-coroutines-core-jvm-1.8.0.jar
ANNOT=/c/Users/zxc/.gradle/caches/modules-2/files-2.1/org.jetbrains/annotations/23.0.0/8cc20c07506ec18e0834947b84a864bfc094484e/annotations-23.0.0.jar

# 编译（示例：Phase F；Phase B 同理，只换成 core/media 源码 + 自己的断言）
java -cp "$COMPILER;$STDLIB;$SCRIPT;$CORO;$ANNOT" org.jetbrains.kotlin.cli.jvm.K2JVMCompiler \
  -no-stdlib -cp "$STDLIB;$CORO" -d out \
  <DebugLog 桩>.kt \
  android/app/src/main/kotlin/com/mag160c/thermal/net/RemoteContract.kt \
  android/app/src/main/kotlin/com/mag160c/thermal/net/RemoteClient.kt \
  android/app/src/main/kotlin/com/mag160c/thermal/net/RemoteHost.kt \
  <自己的断言>.kt
java -cp "out;$STDLIB;$CORO" <主类>Kt
```

要点：
- `DebugLog` 依赖 Android 类型，需自写同包同名的 JVM 桩
  （`package com.mag160c.thermal.media; object DebugLog { fun log(t: String, m: String) {} }`），
  网络类即可在纯 JVM 上运行。
- Windows 版 java **不认** Git Bash 的 `/tmp`，路径必须写 `C:\...`。

### 6.4 其它

```bash
# 清单日志串核对（期望 exact=16 skeleton=30 review=7）
"C:\Tools\jdk-21\bin\java" analysis/tools/CheckStrings.java \
  docs/android_app/real_device_checklist.md android/app/src/main

# APK 清单核验
"C:\Tools\android-sdk\build-tools\36.0.0\aapt2.exe" dump badging build-artifacts/mag160c-app-debug.apk
"C:\Tools\android-sdk\build-tools\36.0.0\aapt2.exe" dump xmltree build-artifacts/mag160c-app-debug.apk --file AndroidManifest.xml
```

---

## 7. 结论一句话

**Phase A/B/C/D/E 的声明全部证实（C 的索引 4/8/9 映射经独立复核成立；
B 的温度换算经独立 C 移植全量比对一致）；Phase F 有两处真实缺陷
（命令乱序导致约 6.7% 丢 welcome、busy 未实现），Phase Z 有一处越界
（Manifest 改动）；其余为低风险偏差。真机相关项无法判定，等实测。**