# M06-C 协议适配器和消息幂等

- 日期：2026-06-22
- 起始 commit：`c96045f`
- 工程 commit：`e795cdb`
- ENGINEERING_DELTA=YES
- 子阶段状态：M06-C-R1 DONE；实物行为仍为 M06-G 外部阻塞

## 工程增量

- 实现 `MqttTransport`、`JilianControlBoxAdapter`、`JilianSub1GLockAdapter`、`JilianSmartSocketAdapter`。
- 严格保留 `ConctolPower`、`Crldoor`、`CrlLED`、`PlayTTS`、`CtrlDevice` 等厂商拼写。
- Zod 校验控制箱读取/控电/门锁/TTS/LED/任务、Sub-1G 配对控制、插座读取/开关/本地任务。
- 建立 13 位命令 ID、命令持久化、发布状态、ACK/失败/超时状态推进。
- MQTT 消费校验 Topic、DeviceID 和 JSON；原始/标准化 payload 分开保存。
- QoS 1 重复消息只增加接收次数，不重复推进命令或设备状态。
- 非法 Topic、未知设备、非法 JSON/字段进入可去重死信表，消费循环不崩溃。

## 验证

- Windows `npm test` 与 `scripts/dev/windows/test-all.ps1`：退出码 0。
- WSL MySQL 8.4.9 原生临时副本：`up → verify → down → up → verify` 通过。
- 迁移语句：up 102、verify 74、down 96。
- 实测同一 ACK 投递两次：事件行 1 条、`receive_count=2`、命令只推进一次至 `ACKED`。
- 非法 Topic 实测进入 `qipai_iot_dead_letters`。
- 工程 commit 已 push，`HEAD == origin/main == e795cdb6935568611a5d27d78991bf9e7ee2f7df`。

## M06-C-R1 协议纠偏（2026-08-10）

- 工程 commit：`dabc656`
- `PlayTTS` 由友好 DTO 生成精确 `vol/firstPlay/loop/speaker/style/speed/intona/id`，并按原件范围校验。
- `AddDevice` 只发送 `time`；首个无 `subtype/subID` 的 ACK 不提前结束配对，最终包才 ACK 并固化父子拓扑。
- `CtrlDevice` 强制 `subtype=14/15`，凭据使用 `value`；密码为连续 6 位分组、卡号为连续 8 位十六进制分组，清空全部和恢复出厂均有平台超管二次确认。
- 上行按命令判别结果；未知结果落 `UNKNOWN_VENDOR_RESULT`、失败命令、协议告警和死信，不崩溃、不误 ACK。
- `record` 与命令凭据在命令、事件、死信持久化前哈希/脱敏；`magstate/taskfinish/Poweron/connected` 保持事件语义。
- `/devicewill/{DeviceID}` 接受原始 `close` 并更新离线，不进入 JSON 解析死信。
- Windows 后端全量 `npm test` 通过；WSL MySQL 8.4.10 原生副本完成 144 up、124 verify、140 down 的 `up → verify → down → up → verify`，并实测上述命令状态、配对、脱敏、事件和遗嘱落库。
- 工程提交已 push，`HEAD == origin/main == dabc656f6319235f1f35106da493d24ced37d19a`。

## 资料边界

V5.6 已记录并固化两份厂商协议原件的审计差异，资料缺失不再构成外部阻塞。当前未具备的是实物、生产 DeviceID、MQTT 账号/ACL 和现场配线，继续登记在 M06-G。

## 后续

执行游标进入 M06-E-R1：智慧插座 Wire schema、标准化状态、保护事件和数据库告警纠偏。