docs(wiki): 新增上线后待办清单（6 必须项 + 4 建议项 + 数据修复 SQL）

wiki/index.md

@@ -4,7 +4,7 @@
 
 ## 关键数字
 
-> 最后更新: 2026-06-05 | 数据截止: feat/media-library-banner 分支（用户管理过滤 + 患者摘要 user_id 过滤）
+> 最后更新: 2026-06-05 | 数据截止: feat/media-library-banner 分支（用户管理过滤 + 患者摘要过滤 + 微信限流修复）
 
 | 指标 | 值 |
 |------|-----|
@@ -205,6 +205,42 @@
 
 **患者/医护与 erp-auth 的关系？** 账号走 `users` 表，erp-health 通过 `user_id` 外键关联扩展字段（科室、职称、档案等）。患者可先建档后绑定账号。
 
+## 上线后待办
+
+> 2026-06-05 会议讨论确定，合并到 main 前后需要逐项处理。
+
+### 必须项（上线前/上线时）
+
+| # | 待办 | 关联提交 | 说明 |
+|---|------|---------|------|
+| 1 | **重启后端** | `01a0fffc` | 用户管理过滤 + 患者摘要过滤 + 微信限流修复，三项都需要重启生效 |
+| 2 | **重新构建小程序** | `1982698b` | `getPatientSummaries` 新增 `userId` 参数，需 `pnpm dev:weapp` 或 `build:weapp` |
+| 3 | **Nginx 配置 X-Real-IP** | `01a0fffc` | `extract_client_ip` 无代理头时 fallback 为 `"unknown"`，所有真机共享限流 key。Nginx 必须添加 `proxy_set_header X-Real-IP $remote_addr;`，否则限流形同虚设 |
+| 4 | **真机验证微信登录** | — | 用 7141 真机登录，确认不再触发"请求过于频繁" |
+| 5 | **真机验证数据上传** | `1982698b` | 7141 登录后连接 M2 手环上传数据，确认数据关联到正确的 patient |
+| 6 | **用户管理页面验证** | `201a9158` | 确认 `wx_*` 患者不再出现在用户管理列表，内部员工正常显示 |
+
+### 建议项（上线后尽快）
+
+| # | 待办 | 说明 |
+|---|------|------|
+| 7 | **清理 `wx__cod` 脏数据** | 用户名 `wx__cod` / 手机号 `1380000_cod` 是早期测试遗留，`users` 表有记录但无 `patient`，也无 `user_credentials`。建议软删除 |
+| 8 | **统一早期 patient 命名** | `wx_7141` 的 patient 名叫 "MP User 7141"（早期测试命名），其他都是 "微信用户XXXX"。建议 SQL 统一为 `微信用户XXXX` 格式 |
+| 9 | **检查其他 wx_* 用户数据归属** | `device_readings` 中有 73 条数据属于 `wx_6897`(69条) 和 `wx_6391`(4条)。旧代码可能将数据写到了错误的 patient 下，需核实这些用户是否真的上传了自己的数据 |
+| 10 | **`extract_client_ip` 改进** | 当前无代理头时返回 `"unknown"`，所有客户端共享限流配额。生产环境依赖 Nginx 头即可，但开发环境应考虑从 Axum `ConnectInfo` 获取真实 IP |
+
+### 数据修复 SQL（上线后按需执行）
+
+```sql
+-- #7: 软删除 wx__cod 脏数据
+UPDATE users SET deleted_at = NOW(), status = 'disabled'
+WHERE username = 'wx__cod' AND deleted_at IS NULL;
+
+-- #8: 统一 7141 的 patient 名称
+UPDATE patient SET name = '微信用户7141'
+WHERE id = '14f34cc3-7a16-48c0-bafc-9bb0989d5fbd' AND name = 'MP User 7141';
+```
+
 ## 文档索引
 
 | 类型 | 位置 |