refactor: migrate to Tencent Cloud backend

docs/planning/09-待确认决策清单.md

@@ -0,0 +1,111 @@
+# 待确认决策清单
+
+本清单汇总自所有规格文档中的"待确认问题"和"歧义点"，按主题归并去重。
+
+每条标注来源文档和阻塞范围，方便定位和分工。
+
+## 设备与 BLE
+
+| # | 问题 | 来源 | 阻塞 |
+| --- | --- | --- | --- |
+| D1 | "确认佩戴"由什么传感器或状态判断，是自动还是手动 | 01-BLE | BLE 命令定义、小程序 UI |
+| D2 | "自动扫描"具体扫描什么：肤质检测、佩戴检测、设备自检，还是其他 | 01-BLE, 需求缺口 | BLE 命令定义、治疗参数 |
+| D3 | 治疗模式、档位、时长是否由小程序下发 | 01-BLE | BLE payload 定义 |
+| D4 | 治疗记录由小程序组装上传，还是设备通过 MQTT 直接上报云端 | 01-BLE, 03-API | 护理记录接口、数据库写入链路 |
+| D5 | OTA 是否通过小程序中转升级包 | 01-BLE | OTA 命令流程 |
+| D6 | 是否需要设备端主动发起的连接认证或握手 | 01-BLE | BLE 连接时序 |
+| D7 | 设备绑定是否依赖 BLE 返回的设备唯一标识，还是依赖扫码 | 01-BLE | 绑定流程 |
+| D8 | 设备是否需要主动上报固件版本、硬件版本、电量、错误状态 | 05-IoT | telemetry payload 设计 |
+
+## 小程序业务
+
+| # | 问题 | 来源 | 阻塞 |
+| --- | --- | --- | --- |
+| M1 | 小程序是否直接使用 MQTT，还是仅通过 HTTPS API | 02-小程序, 需求缺口 | 通信架构、离线策略 |
+| M2 | 首页是否需要展示实时传感器数据 | 02-小程序 | 首页 UI、BLE 通知频率 |
+| M3 | 护理历史中的"统计"是本地统计还是云端聚合 | 02-小程序 | API 设计、前端逻辑 |
+| M4 | 发现页内容是否来自 CMS 或静态配置 | 02-小程序 | 后台功能范围 |
+| M5 | 我的页面是否包含售后、反馈、设置等附加入口 | 02-小程序 | 页面结构 |
+| M6 | 扫码内容是设备 SN、激活码、绑定码还是 URL | 02-小程序 | 绑定流程 |
+| M7 | 蓝牙授权是否还需要定位权限 | 02-小程序 | 小程序权限声明 |
+| M8 | 一人多设备/一设备多用户规则 | 02-小程序, 04-DB | 数据库关系、绑定逻辑 |
+| M9 | 试用按用户发还是按设备发，是否可重复领取 | 02-小程序, 03-API | 订阅模型、试用逻辑 |
+| M10 | 试用到期后是否自动降级为不可治疗 | 03-API | 订阅校验逻辑 |
+
+## 云端 API 与鉴权
+
+| # | 问题 | 来源 | 阻塞 |
+| --- | --- | --- | --- |
+| A1 | 小程序提交给云端的是 `code` 还是其他凭证 | 03-API | 登录接口实现 |
+| A2 | 云端返回自有 token 还是复用微信态 | 03-API | 认证架构 |
+| A3 | Token 7 天有效期是否支持续期 | 03-API, 07-安全 | Token 生命周期 |
+| A4 | 绑定是否必须基于扫码 | 03-API | 绑定接口参数 |
+| A5 | 绑定时是否校验设备在线状态 | 03-API | 绑定逻辑 |
+| A6 | 重复绑定、换绑、解绑是否有限制 | 03-API | 绑定逻辑 |
+| A7 | 试用发放时机是否严格绑定在首次绑定成功后 | 03-API | 试用发放触发条件 |
+| A8 | 护理记录同步是实时提交还是治疗结束后提交 | 03-API | 同步策略、UI 交互 |
+| A9 | 异步写入与接口返回成功的关系 | 03-API | 前端状态管理 |
+| A10 | 小程序 token 是否也影响设备绑定授权 | 07-安全 | 鉴权模型 |
+
+## IoT 与设备注册
+
+| # | 问题 | 来源 | 阻塞 |
+| --- | --- | --- | --- |
+| I1 | `DeviceSecret` 是否通过云函数动态返回给设备 | 05-IoT | 设备注册流程 |
+| I2 | 小程序在设备注册链路中扮演什么角色 | 05-IoT | 注册时序 |
+| I3 | 设备注册调用方是生产工具、设备首次上线，还是小程序触发 | 03-API, 05-IoT | 注册接口设计 |
+| I4 | `DeviceSecret` 是否只签发一次 | 03-API, 05-IoT | 密钥管理策略 |
+| I5 | `telemetry` 和 `event` 的边界如何划分 | 05-IoT | MQTT payload 设计 |
+| I6 | 后台是否需要通过云端下发控制指令 | 05-IoT | 下行 topic 设计 |
+
+## 管理后台
+
+| # | 问题 | 来源 | 阻塞 |
+| --- | --- | --- | --- |
+| B1 | 后台管理员如何登录 | 06-后台 | 认证实现 |
+| B2 | 是否存在超级管理员 | 06-后台 | 权限模型 |
+| B3 | 是否需要多组织或多租户隔离 | 06-后台 | 数据隔离设计 |
+| B4 | 仪表盘统计口径是实时聚合还是离线任务 | 06-后台 | 统计接口实现 |
+| B5 | 数据导出是否受角色限制 | 06-后台 | 权限细化 |
+| B6 | 系统设置是否只管理管理员与权限，还是还包含设备、订阅、公告等 | 06-后台, 需求缺口 | 后台功能范围 |
+
+## 安全
+
+| # | 问题 | 来源 | 阻塞 |
+| --- | --- | --- | --- |
+| S1 | 后台是否与小程序共用用户体系 | 07-安全 | 用户模型 |
+| S2 | 是否需要设备侧应用层签名或加密 | 07-安全 | BLE 协议安全层 |
+| S3 | 是否有合规或审计的特殊要求 | 07-安全 | 安全方案范围 |
+
+## 数据库
+
+| # | 问题 | 来源 | 阻塞 |
+| --- | --- | --- | --- |
+| DB1 | `users` 与 `devices` 绑定约束：一对一还是多对多 | 04-DB | bindings 表设计 |
+| DB2 | `subscriptions` 归属用户、设备还是同时关联两者 | 04-DB | subscriptions 表设计 |
+| DB3 | `sessions` 与 `treatment_records` 是一对一还是一对多 | 04-DB | 表关系设计 |
+| DB4 | `pd_data` 的含义、数据来源、是否高频时序数据 | 04-DB, 需求缺口 | 存储方案选择 |
+
+## 测试与验收
+
+| # | 问题 | 来源 | 阻塞 |
+| --- | --- | --- | --- |
+| T1 | 小程序是否有最低微信版本要求 | 08-测试 | 兼容性测试范围 |
+| T2 | 设备联调是否依赖特定手机机型 | 08-测试 | 测试设备准备 |
+| T3 | 护理记录异步写入的最终一致性验收口径 | 08-测试 | 验收标准 |
+| T4 | 后台导出是否属于第一阶段验收范围 | 08-测试 | MVP 范围 |
+
+## 建议对齐优先级
+
+以下问题同时阻塞多个模块，建议最先对齐：
+
+1. **D2** 自动扫描定义 — 阻塞 BLE 命令 + 治疗参数 + 小程序 UI
+2. **D4** 治疗记录上传主体 — 阻塞 API + 数据库 + MQTT + 小程序
+3. **M1** 小程序是否直接 MQTT — 阻塞整体通信架构
+4. **M9** 试用按用户还是按设备 — 阻塞订阅模型 + 数据库 + API
+5. **DB4** pd_data 含义 — 阻塞存储方案
+6. **I3** 设备注册调用方 — 阻塞注册流程 + API + 密钥管理
+7. **A2** token 方案 — 阻塞认证架构
+8. **D1** 佩戴确认判断方式 — 阻塞 BLE 命令 + UI
+
+建议按此顺序逐一确认，每确认一项就同步更新对应的规格文档。