From 4e91a534aa071a0bfa4edabc3f3b2a3e6f730f60 Mon Sep 17 00:00:00 2001
From: stu2not <stu2not@stu2notdeMac-mini.local>
Date: Sun, 20 Sep 2026 11:59:51 +0800
Subject: [PATCH] =?UTF-8?q?docs:=20=E4=BB=A5MQTT=20V2=E5=8D=8F=E8=AE=AE?=
 =?UTF-8?q?=E6=A0=A1=E6=AD=A3=E6=B3=A8=E5=86=8C=E7=BB=91=E5=AE=9A=E8=AF=B4?=
 =?UTF-8?q?=E6=98=8E?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 docs/architecture/02-device-bootstrap.md |  8 +++--
 docs/architecture/03-binding-flow.md     | 39 ++++++++++++++++--------
 2 files changed, 32 insertions(+), 15 deletions(-)

diff --git a/docs/architecture/02-device-bootstrap.md b/docs/architecture/02-device-bootstrap.md
index b1d06fa..04495d3 100644
--- a/docs/architecture/02-device-bootstrap.md
+++ b/docs/architecture/02-device-bootstrap.md
@@ -60,9 +60,10 @@ response on `msg_id=012`:
 }
 ```
 
-The ICCID belongs to the later `msg_id=006` device-binding success receipt,
-not to this registration response. The registration response only establishes
-the device identity needed by the binding flow.
+The current V2.0 registration response does not carry an ICCID. Any ICCID
+addition belongs to the separate `msg_id=006` binding-response extension; the
+registration response only establishes the device identity needed by the
+binding flow.
 
 ## Data Model
 
@@ -101,6 +102,7 @@ serial_number: TQ_ZHWK000000002001
 
 ## Source Anchors
 
+- MQTT protocol V2.0: `talkingq-url/docs/mqtt协议_V2.0.txt`
 - Bootstrap handler: `talkingq-url/handlers/mqtt_handler.py`
 - Identity initializer: `talkingq-url/services/device_identity_initializer.py`
 - Import script: `talkingq-url/scripts/import_device_imei_mapping.py`
diff --git a/docs/architecture/03-binding-flow.md b/docs/architecture/03-binding-flow.md
index 1a5b1be..2edc8a2 100644
--- a/docs/architecture/03-binding-flow.md
+++ b/docs/architecture/03-binding-flow.md
@@ -10,8 +10,8 @@ This is the `msg_id=006` device-binding flow and is separate from the device
 registration handshake documented in `02-device-bootstrap.md`. `msg_id=012`
 only registers the device identity. `msg_id=006` starts and completes binding
 the device to a mini-program user and optional child through the NFC card
-exchange; its successful receipt carries the ICCID needed by the downstream
-SIM/traffic service.
+exchange. The current V2.0 receipt contains the NFC card UUID; carrying an
+ICCID is a proposed extension described below.
 
 ```mermaid
 sequenceDiagram
@@ -43,7 +43,7 @@ sequenceDiagram
     API-->>Mini: bind_token, expires_at
   end
 
-  Device->>MQTT: msg_id=006 binding success / card UUID / ICCID
+  Device->>MQTT: device/{imei}/response msg_id=006 status/data.uuid
   MQTT->>Binding: finalize_nfc_bind(device_id, card_uuid)
   Binding->>DAO: load latest pending bind session
   Binding->>Card: activate_card(card_uuid, device_id)
@@ -52,26 +52,40 @@ sequenceDiagram
   Binding->>DAO: mark session completed
 ```
 
-## Binding Success Receipt
+## Binding Response (V2.0)
 
-The successful device-binding receipt uses `msg_id=006` and includes the
-authoritative ICCID:
+The current V2.0 protocol defines the successful `msg_id=006` response as:
 
 ```json
 {
   "msg_id": "006",
-  "params": {
-    "device_id": "TalkingQ_ZHWK00002110",
-    "device_sn": "TQ_ZHWK000000002110",
+  "status": "success",
+  "data": {
+    "uuid": "53D22B6DA20001"
+  }
+}
+```
+
+The V2.0 response does not define an `iccid` field. Adding ICCID to the
+binding receipt is therefore a protocol extension that requires coordinated
+firmware and backend changes. A compatible proposal is to add it under
+`data`, while preserving the existing `status` and `data.uuid` fields:
+
+```json
+{
+  "msg_id": "006",
+  "status": "success",
+  "data": {
+    "uuid": "53D22B6DA20001",
     "iccid": "898604E91123D1334901"
   }
 }
 ```
 
 The ICCID must come from the authoritative IMEI-to-ICCID provisioning record
-or a validated device report. It must not be derived from the IMEI. If the
-binding response cannot provide a valid ICCID, the binding result must not be
-reported as a complete success.
+or a validated device report; it must not be derived from the IMEI. This
+proposed field is not part of the current V2.0 contract until both sides
+accept and implement the extension.
 
 ## Related Tables
 
@@ -112,6 +126,7 @@ erDiagram
 
 ## Source Anchors
 
+- MQTT protocol V2.0: `talkingq-url/docs/mqtt协议_V2.0.txt`
 - Mini-program bind page: `banban-mini/src/pages/bind/index.tsx`
 - Binding service: `talkingq-url/banban/service/binding.py`
 - Binding DAO: `talkingq-url/banban/dao/binding.py`