PRE-M8: add staged WarmteLink bring-up reference

docs/design/pre-m8-warmtelink-p1-poc.md

@@ -51,6 +51,36 @@ python -m scripts.p1_probe \
 - 可只显示发生变化的字段，便于观察更新频率。
 - 原始 telegram 默认只写到 `/tmp`；未经脱敏不提交到 Git。
 
+### 3.1 分两步 bring-up：Bash 冒烟验证 → Python probe
+
+Home Assistant Community 的一份 WarmteLink 实例提供了一个适合作为硬件
+bring-up 起点的[最小 Bash 读取方法](https://community.home-assistant.io/t/solved-dsmr-add-warmtelink-as-data-source/485255/2)：
+先把串口设为 115200 baud，逐行读取设备，并从带 `GJ` 的行中取出累计值。该帖展示的
+telegram 样例还给出了以下**候选事实**：
+
+- 设备头为 `/NWA-WARMTELINK`，版本字段为 `1-3:0.2.8(50)`。
+- M-Bus channel 1 的 device type 样例为 `004`。
+- 累计热量样例位于 `0-1:24.2.1(<capture timestamp>)(<value>*GJ)`。
+- telegram 以 `!` 加四位 CRC 结束。
+
+这些是其他用户在 2022 年记录的单机样本，只用于提出假设，不能替代本机 firmware、线材和
+实际 telegram 的验证。当前 Home Assistant 的
+[DSMR 文档](https://www.home-assistant.io/integrations/dsmr/)确认其 DSMR 集成支持 DSMR v5 与
+M-Bus subdevice；该集成底层使用
+[`dsmr_parser`](https://github.com/ndokter/dsmr_parser)。实现 probe 时可把它作为候选解析基线
+进行对照，但是否引入为本项目正式依赖留到 M8 Planning 决定。
+
+线到货后的执行顺序调整为：
+
+1. **Bash 冒烟验证**：用稳定的 `/dev/serial/by-id/...` 路径配置串口并短时读取；先保留完整
+   原始字节流，再确认是否能看到 `/NWA-WARMTELINK`、帧尾和带 `GJ` 的行。论坛脚本中的
+   `GJ` 文本提取只能用作快速可见性检查，不能算解析或验收通过。
+2. **Python probe**：在已确认物理链路工作的前提下，实现上面的 `scripts.p1_probe`，完成
+   完整 framing、CRC、全部字段枚举、结构化解析、连续多帧变化观察和人工面板对照。
+
+不复制论坛脚本的 MQTT 发布步骤：Pre-M8 仍只输出到终端和 `/tmp`，MQTT / Home Assistant
+集成属于 M8 设计范围。
+
 ## 4. 人工对照
 
 probe 运行期间，人工从热力表和相关水表面板记录同一时间附近的显示值，并与终端结果对照：