PRE-M8-T03: finalize WarmteLink hardware validation

docs/design/m8-warmtelink-energy.md

@@ -1,8 +1,8 @@
 # M8 — WarmteLink P1 与多数据源 Meter（Planning 占位）
 
-> **状态：Planning 占位；尚未拆解任务卡，尚未锁定架构。** Pre-M8 人工 bring-up 已确认
-> 两个累计量，但 M8 仍须等待 [Pre-M8 真机概念验证](./pre-m8-warmtelink-p1-poc.md)
-> 的正式 probe、测试和长时间复验完成后再进入正式设计。
+> **状态：Planning 已解锁；尚未拆解任务卡，尚未锁定架构。** [Pre-M8 真机概念验证](./pre-m8-warmtelink-p1-poc.md)
+> 已完成正式 probe、测试和 10 分钟复验；这只满足进入
+> Planning 的证据门，不授权 schema、API、worker 或前端实现。
 
 ## 1. 候选目标
 
@@ -20,11 +20,15 @@
 - 当前 electricity Meter 与 `dsmr_reading` 之间没有显式 source FK/binding；电费计算通过代码约定直接查询 DSMR 电力寄存器。
 - `Meter.commodity` 后端已为 `heating` 等品类预留，但“增加 commodity”本身不会自动获得相应数据源或解析能力。
 - 当前 Devices UI/模型是 Modbus 专用，不能直接假设 WarmteLink 应复用 `modbus_device`。
-- 真机实测一个 WarmteLink serial source 同时输出两个累计 channel：channel 1 为生活热水
-  `m³`，channel 2 为区域供暖 `GJ`；两者均已与物理表对照一致。
-- 当前 P1 telegram 约每 10 秒一帧，没有瞬时流量、热功率、供水温度或回水温度字段。
-- 当前线材/设备组合以 `115200 7N1` 才能稳定解析正文；header/CRC 仍不可验证，正式 ingestion
-  必须显式处理该数据质量状态。
+- 正式 CLI 复验中，一个 WarmteLink serial source 在 60/60 帧均输出两个累计 channel：channel 1
+  为生活热水 `m³`（device type `006`、`5.900 m³`），channel 2 为区域供暖 `GJ`（device type
+  `012`、基线 `0.017 GJ`）；同日与物理表复核一致。最终人工走查开启供暖后，channel 2 又从
+  `0.017 GJ` 增至 `0.018 GJ`，物理热量表同步显示 `0.018 GJ`。
+- 设备 timestamp 严格每 10 秒递进；frame 平均 256 bytes、范围 237–275，不能假定固定帧长。
+  当前 P1 telegram 没有瞬时流量、热功率、供水温度或回水温度字段。
+- 当前线材/设备组合以 `115200 7N1` 才能稳定解析正文。60/60 frame 缺少标准 `/`，故均为
+  `unverifiable`；即使部分 footer 恰为四位十六进制也不能验证 CRC。正式 ingestion 必须显式
+  处理该数据质量状态，不能将数值与表盘相符视为 CRC valid。
 
 ## 3. 下一轮 Planning 必须讨论的问题
 
@@ -41,11 +45,18 @@
 
 ## 4. Planning 入口条件
 
-正式编写 M8 目标架构、数据模型和原子任务卡前，至少需要：
+进入 M8 Planning 的证据门已满足：
+
+- [x] Pre-M8 通过并留下脱敏字段清单。
+- [x] 正式 probe 复验两个累计量、单位、channel、device type 与更新时间；equipment identifier
+  保持脱敏。
+- [x] 记录 parser 适配结论和异常 framing/CRC 状态；10 分钟样本的稳定累计值不构成消费更新、
+  reset/wrap 或长期稳定性的证明。
+- [x] 最终人工走查确认供暖消费时累计量按 `0.001 GJ` 更新并与物理表一致；精确更新延迟、
+  reset/wrap 和长期接纳策略仍留给 Planning。
+
+正式编写 M8 目标架构、数据模型和原子任务卡前，仍需：
 
-- Pre-M8 通过并留下脱敏字段清单。
-- 用正式 probe 复验两个累计量及其单位、equipment id/channel 和更新时间。
-- 确认原始 telegram 的长期稳定性、parser 适配方式和异常 CRC 的接纳策略。
 - 重新走查现有 DSMR ingest、Meter epoch、Modbus device、expose/HA 和 Energy 前端边界。
 - 与用户讨论并锁定 Meter ↔ source 的配置体验后，再决定 migration/API/UI 方案。