docs: 审计报告(8 份) + 讨论记录(4 份)

审计报告: 基线快照/功能清单/后端完整性/事件系统/参数配置/
差距模式/错误处理/测试覆盖/审计总结报告
讨论记录: 设备管线/端到端测试/三端审计/工作台重构

docs/discussions/2026-04-28-device-data-pipeline-brainstorm.md

@@ -0,0 +1,115 @@
+# 设备数据全链路发散式探讨
+
+> 日期: 2026-04-28 | 参与者: 用户 + Claude
+
+## 背景
+
+客户提出血压计、血糖仪需要支持自动上传数据。项目已有实时体征管线设计（`docs/superpowers/specs/2026-04-26-realtime-vital-signs-pipeline-design.md`），Phase 1（手环数据管线）和 Phase 2（告警引擎 + SSE）已基本实现，但血压计/血糖仪 BLE 适配器被设计规格明确放在了 Phase 3。
+
+本次探讨从客户需求出发，延伸到 AI 趋势分析、医生端仪表盘、告警通知渠道等方向。
+
+## 讨论要点
+
+### 1. 血压计/血糖仪 BLE 适配器设计
+
+客户接受蓝牙标准协议（Bluetooth SIG），不需要按品牌逐个对接。
+
+**已完成的底层管线：**
+- `device_readings` 分区表 + Entity（已实现）
+- `patient_devices` 设备绑定表（已实现）
+- `alert_rules` + `alerts` 告警表（已实现）
+- 批量上传 API、小时级降采样、告警引擎（3 种条件类型）、SSE 推送、EventBus 集成
+- 小程序 BLE 基础架构（BLEManager + DeviceAdapter 接口 + 小米手环适配器）
+- 集成测试（8 个）
+
+**6 个关键决策：**
+
+| 决策点 | 结论 | 理由 |
+|--------|------|------|
+| 设备协议 | Bluetooth SIG 标准协议（0x1810 血压 / 0x1808 血糖） | 一个适配器兼容所有标准设备 |
+| 数据模型 | 多行拆分 + `metric` 字段 | 一条血压测量 → 3 行（systolic/diastolic/map），告警引擎直接用 value 比较 |
+| BLE 读取 | Indicate（实时）+ RACP（历史读取）一起做 | 血糖仪患者一天测多次，批量上传是刚需 |
+| 数据路由 | 双写：`device_readings` + 自动写入 `vital_signs` | 设备数据自动成为正式体征记录，患者不需手动录入 |
+| 告警阈值 | 临床标准值，租户可自定义覆盖 | 医疗标准 + 灵活性 |
+| 患者体验 | 极简式：首页设备卡片，点击连接，测完自动上传 | 类似小米运动体验，降低操作门槛 |
+
+**已知管线缺陷（本次不修但需记录）：**
+- 批量插入缺少 ON CONFLICT 去重
+- SSE 告警是租户广播，未按主治医生过滤
+- 小程序无离线缓存（杀进程数据丢失）
+- 小米手环适配器只支持实时 notify，不支持历史读取
+- 无数据保留清理任务（90 天分区自动删除）
+
+### 2. AI 趋势分析
+
+设备数据 + AI = 可行动的临床洞察。从"数字"变成"建议"。
+
+**技术路线：混合方案**
+- 统计引擎（纯 Rust）：移动平均、变化率、Z-score 异常检测、基线比较 → 产出确定性结构化中间结果
+- LLM（Claude API）：基于统计结果 + 患者档案 + 用药信息 → 生成自然语言医生建议
+- 统计层作为 LLM 护栏，防止幻觉
+
+**架构愿景（通用管线）：**
+```
+设备数据 → 统计引擎（通用）→ 结构化中间结果 → LLM 上下文合成 → 自然语言洞察
+```
+
+适用于血压、血糖、心电图、体温连续监测、体重变化等所有体征数据。
+
+**erp-ai 模块现状：** 3 个 Entity 已创建（`ai_analysis`、`ai_report`、`ai_model_config`），但 Phase 1 化验单解读使用占位数据，需要真实化。
+
+### 3. 医生端告警仪表盘
+
+**核心模式：告警驱动**
+- 登录即看到按严重级排序的告警时间线
+- 80% 的告警通过侧滑抽屉（Drawer）处理，不需要跳转页面
+- 处理完后切换到"患者列表"视图（按风险等级排序）
+
+**三层信息架构：**
+1. 全局态势 — 统计卡片（新告警数/高危数/活跃患者/处理率）+ 告警时间线
+2. 患者快照 — 最新体征 + AI 摘要 + 用药清单 + 快捷操作
+3. 患者详情 — 完整趋势图 + 设备数据 + AI 分析报告 + 病历
+
+**告警处置：结构化处理**
+- 医生必须选择处置方式（已电话联系/已调整用药/已转诊/继续观察）+ 备注
+- 形成完整医疗记录和审计追溯
+- 告警生命周期：触发 → 通知 → 响应 → 处置 → 关闭 → 记录
+
+**与现有 UI/UX 重构的对接：** `2026-04-28-ui-ux-overhaul-design.md` 已有角色自适应仪表盘和表单抽屉策略，可以复用。
+
+### 4. 告警通知渠道
+
+SSE 只在医生浏览器打开时有效。critical/urgent 告警可能出现在凌晨。
+
+**通知链路：**
+```
+告警触发 (alert_engine)
+  → EventBus: alert.triggered
+    → SSE: 医生在线时即时推送
+    → 微信模板消息: 跳转到小程序告警详情页
+    → 短信: critical/urgent 级别兜底通知（需对接短信服务商）
+```
+
+## 结论 / 待定
+
+### 达成的共识
+
+1. **设备对接**使用 Bluetooth SIG 标准协议，一套适配器覆盖所有标准血压计/血糖仪
+2. **数据管线**复用已有基础设施（BLEManager、DeviceAdapter、批量上传 API、告警引擎）
+3. **AI 分析**采用统计引擎 + LLM 混合方案
+4. **医生端**采用告警驱动仪表盘 + 结构化处置
+5. **通知渠道**先做微信模板消息 + 短信
+
+### 3 个潜在设计规格方向
+
+1. **血压计/血糖仪 BLE 适配器** — 技术设计，可独立成 spec，实现范围最明确
+2. **医生端告警仪表盘** — UI/UX + 产品设计，对接现有 UI 重构
+3. **AI 趋势分析引擎** — 架构设计，连接 erp-ai + erp-health
+
+### 待定问题
+
+- 血糖采样类型（空腹/餐后/随机）在 `metric` 字段中的编码方式
+- 微信模板消息需要申请哪些模板 ID
+- 短信服务商选择（阿里云 vs 腾讯云）
+- 是否需要修复现有管线缺陷作为本次工作的前置任务
+- AI 趋势分析的触发频率和成本控制

docs/discussions/2026-04-30-e2e-cross-platform-testing.md

@@ -0,0 +1,119 @@
+# E2E 跨平台业务联调测试报告
+
+> 日期: 2026-04-30 | 参与者: Claude Code 自动化测试
+
+## 背景
+
+对 HMS 健康管理平台进行端到端业务联调，验证 Web 端（管理员/医生/护士）和小程序端（患者）四个角色的核心业务流程和数据一致性。
+
+## 测试环境
+
+| 组件 | 地址 | 状态 |
+|------|------|------|
+| 后端 API | `http://localhost:3000/api/v1` | 运行中 |
+| Web 前端 | `http://localhost:5174` | 运行中 |
+| PostgreSQL | `localhost:5432/erp` | 运行中 |
+| Redis | 云端 | 运行中 |
+
+### 测试账号
+
+| 角色 | 用户名 | 密码 |
+|------|--------|------|
+| 管理员 | admin | Admin@2026 |
+| 医生 | doctor1 | Doctor@2026 |
+| 护士 | nurse1 | Nurse@2026 |
+
+### 测试数据
+
+| 数据 | ID |
+|------|-----|
+| 联调测试患者 | `019ddf17-6c67-78b0-b3cc-c41512b76b12` |
+| 预约 (2026-05-05) | `019ddf1c-7dd6-7ee3-b012-ef1fd703ef15` |
+| 体征记录 1 (空值) | `019ddf2c-91ee-76e0-8fdf-c1a78ee45a5b` |
+| 体征记录 2 (血压135/88) | `019ddf2c-cdb3-7f00-9547-21e364720845` |
+
+## 测试结果总览
+
+| 测试项 | 结果 | 备注 |
+|--------|------|------|
+| Admin 登录 + 仪表盘 | ✅ 通过 | 显示统计概览 |
+| Admin 创建患者 | ✅ 通过 | "联调测试患者" 创建成功 |
+| Admin 创建预约 | ✅ 通过 | 需先创建排班，CAS 匹配 start_time |
+| Doctor 登录 + 仪表盘 | ✅ 通过 | 显示医生专属视图 |
+| Doctor 查看患者列表 | ✅ 通过 | 可看到 Admin 创建的患者 |
+| Nurse 登录 + 仪表盘 | ✅ 通过 | 显示"随访监控台" |
+| Nurse 查看告警 | ✅ 通过 | 权限正确限制 |
+| 跨角色数据一致性 | ✅ 通过 | 三角色查询同一患者数据一致 |
+| 小程序 API - 患者详情 | ✅ 通过 | |
+| 小程序 API - 预约列表 | ✅ 通过 | 返回 1 条预约 |
+| 小程序 API - 体征数据 | ✅ 通过 | 创建 + 查询链路正常 |
+| 小程序 API - 文章列表 | ✅ 通过 | 4 篇已发布文章 |
+| 小程序 API - 随访任务 | ✅ 通过 | 0 条（预期，未创建） |
+| 小程序 API - 告警列表 | ✅ 通过 | 0 条（预期，未触发） |
+| 小程序 API - 积分账户 | ✅ 通过 | 路径 `points/account`（单数） |
+
+## 发现的问题
+
+### 已确认非问题（之前误报）
+
+1. **预约查询返回 0 条** — 实际是 token 中 tenant_id 与数据不一致导致。使用正确角色的 token 查询正常返回数据。
+2. **文章列表返回 0 条** — 同上，token 问题。Admin/Doctor 角色查询正常返回 5 条（4 published + 1 draft）。
+
+### 已知设计限制
+
+1. **预约 CAS 精确匹配 start_time** — 预约只能预约排班的精确时段，不支持排班时段内的子时间段。例如排班 08:00-12:00，预约 start_time 必须是 08:00，不能是 09:00。
+2. **Nurse 角色文章 403** — 护士无 `health.articles.list` 权限，返回 403 是正确行为。
+3. **体征创建字段映射** — `systolic`/`diastolic` 请求参数不映射到 `systolic_bp_morning`/`diastolic_bp_morning`，需要使用精确字段名。
+
+### 路径注意事项
+
+| 资源 | 正确 API 路径 | 易错路径 |
+|------|---------------|----------|
+| 体征数据 | `/health/patients/{id}/vital-signs` | `/health/vital-signs` (404) |
+| 设备读数 | `/health/patients/{id}/device-readings` | `/health/device-readings` (404) |
+| 积分账户 | `/health/points/account` (单数) | `/health/points/accounts` (404) |
+| 积分交易 | `/health/points/transactions` | - |
+
+## 跨角色数据一致性矩阵
+
+| API 端点 | Admin | Doctor | Nurse |
+|----------|-------|--------|-------|
+| 患者预约 (total=1) | 1 ✅ | 1 ✅ | - |
+| 患者体征 (total=2) | 2 ✅ | 2 ✅ | 2 ✅ |
+| 已发布文章 (total=4) | 4 ✅ | 4 ✅ | 403 ✅ (无权限) |
+| 患者详情 | ✅ | ✅ | ✅ |
+
+**结论：同租户内跨角色数据完全一致，权限隔离正确。**
+
+## 小程序端测试详情
+
+通过 API 层模拟小程序患者视角的完整业务流：
+
+1. **查看个人信息** → `GET /health/patients/{id}` ✅
+2. **查看我的预约** → `GET /health/appointments?patient_id={id}` ✅
+3. **查看体征数据** → `GET /health/patients/{id}/vital-signs` ✅
+4. **查看健康文章** → `GET /health/articles?status=published` ✅
+5. **查看随访任务** → `GET /health/follow-up-tasks?patient_id={id}` ✅ (0 条)
+6. **查看告警** → `GET /health/alerts` ✅ (0 条)
+7. **查看积分** → `GET /health/points/account?patient_id={id}` ✅
+
+### 未覆盖项
+
+- MCP 连接微信开发者工具进行 UI 级测试（DevTools 未连接）
+- 小程序微信登录流程（需要 dev mode 环境）
+- 体征数据趋势图 API（`/health/vital-signs/trend` 返回 404，可能未注册路由）
+
+## 结论
+
+**HMS 平台核心业务链路功能正常：**
+
+- Web 端三角色（admin/doctor/nurse）登录、权限控制、数据访问全部通过
+- 跨角色数据一致性验证通过（同租户内数据共享正确）
+- 小程序端患者视角 API 全部可达且返回正确
+- 权限隔离按设计工作（nurse 无法访问文章管理等超出职责的功能）
+- 预约 CAS 并发控制工作正常
+
+**建议后续改进：**
+1. 体征 API 添加字段别名映射（`systolic` → `systolic_bp_morning`）降低调用门槛
+2. 体征趋势 API 路由确认（`/health/vital-signs/trend` 返回 404）
+3. 预约 CAS 支持更灵活的时段匹配

docs/discussions/2026-05-01-tri-platform-integration-audit.md

@@ -0,0 +1,351 @@
+# 三端联调深度审计报告
+
+> 日期: 2026-05-01 | 参与者: Claude + iven
+> 目标: 记录项目最真实的状况，从全局/用户/管理者三重角度审视系统
+
+---
+
+## 1. 基础设施状态
+
+### 1.1 编译与构建
+
+| 检查项 | 状态 | 详情 |
+|--------|------|------|
+| `cargo check` | 通过（修复后） | 修复了 2 个编译错误：`HealthError::DatabaseError` → `DbError`，`approval_status` move 问题 |
+| `cargo test --workspace` | **失败** | `erp-plugin` 测试编译失败：`parse_manifest` 未导入（`#[cfg(test)]` 缺少 `use crate::manifest::parse_manifest`） |
+| `pnpm build` (Web) | 通过 | 耗时 33.67s，antd chunk 1.5MB 过大 |
+| `pnpm build:weapp` (小程序) | 通过 | Sass @import deprecation 警告，pkg-health 分包 352KB 超限 |
+
+### 1.2 数据库数据分布
+
+| 表 | 记录数 | 评估 |
+|----|--------|------|
+| patient | 32 | 有测试数据 |
+| doctor_profile | 8 | 有测试数据 |
+| appointment | 12 | 有测试数据 |
+| doctor_schedule | 15 | 有测试数据 |
+| follow_up_task | 12 | 有测试数据 |
+| follow_up_record | 3 | 较少 |
+| consultation_session | 4 | 有测试数据 |
+| consultation_message | 7 | 有测试数据 |
+| article | 5 | 有测试数据 |
+| alert_rules | 10 | 有测试数据 |
+| ai_prompt | 4 | 有测试数据 |
+| offline_event | 7 | 有测试数据 |
+| health_record | 1 | 极少 |
+| lab_report | 2 | 较少 |
+| ai_analysis | 0 | **空表** |
+| ai_suggestion | 0 | **空表** |
+| alerts | 0 | **空表** |
+| daily_monitoring | 0 | **空表** |
+| device_readings | 0 | **空表** |
+| critical_alert | 0 | **空表** |
+| dialysis_prescription | 0 | **空表** |
+| patient_family_member | 0 | **空表** |
+| patient_tag_relation | 0 | **空表** |
+| medication_reminder | 0 | **空表** |
+| medication_record | 0 | **空表** |
+| domain_events | 1166 | 大量事件堆积 |
+
+**关键发现**: 32 个表中 12 个完全空表（37.5%），说明很多功能从未被端到端使用过。
+
+---
+
+## 2. 后端完整性
+
+### 2.1 API 路由统计
+
+| 模块 | 路由端点数 | CRUD 完整领域数 |
+|------|-----------|----------------|
+| erp-health | 98 | 15/15 全部完整 |
+| erp-ai | 13 | 管理类全覆盖 |
+| erp-dialysis | 8 | 2/2 完整 |
+| **总计** | **119** | — |
+
+### 2.2 后端已实现但无前端 UI 的端点（功能孤岛）
+
+| 分类 | 端点数 | 具体内容 |
+|------|--------|---------|
+| AI 分析 SSE 触发 | 4 | lab-report/trends/checkup-plan/report-summary，无管理界面入口 |
+| 危急值告警体系 | 4 | 列表/详情/确认/阈值配置，Web 端完全无页面 |
+| 行动收件箱 | 2 | 列表/线程查看，无前端消费 |
+| 统计数据 | 5 | dashboard/lab-reports/appointments/vital-signs-report-rate/health-data |
+| 趋势生成 | 1 | `POST /trends/generate` 无手动触发入口 |
+| **合计** | **16** | **约 13% 的后端路由为"死端点"** |
+
+### 2.3 Service 层健康度
+
+- Service → Handler → Router 映射链路: **100% 完整**
+- 内部 Service（定时任务/事件消费者/工具函数）: 均有合理调用方
+- 所有实体领域达到完整 CRUD 覆盖
+
+---
+
+## 3. Web 前端完整性
+
+### 3.1 路由与页面
+
+- 健康管理路由: **30 条**
+- 基础 ERP 路由: **17 条**
+- 健康模块共享组件: **11 个**
+- API 服务文件: **12 个 health + 4 个 AI**
+
+### 3.2 页面功能抽样评审
+
+| 页面 | 完整度 | 关键缺陷 |
+|------|--------|---------|
+| PatientList | 8/10 | 缺空状态、批量操作未实现 |
+| PatientDetail | 9/10 | 作为核心枢纽页表现优秀 |
+| AppointmentList | 8/10 | 无法编辑预约内容 |
+| AlertList | 7/10 | 搜索未传后端、resolve 无入口、权限码拼写错误已修 |
+| FollowUpTaskList | 7/10 | 负责人筛选器空、无法编辑任务 |
+| AiAnalysisList | 7/10 | 无患者关联导航、无法触发分析 |
+| DialysisManageList | 8/10 | 无 PatientDetail 入口 |
+| ConsultationList | 7/10 | 缺患者搜索 |
+
+### 3.3 跨页面导航（功能关联性）
+
+**当前关联度: 中等偏低（50%）**
+
+| 导航路径 | 状态 |
+|----------|------|
+| PatientList → PatientDetail | ✅ 行点击 |
+| ConsultationList → ConsultationDetail | ✅ 行点击 |
+| AlertList → PatientDetail | ✅ 单向 Link |
+| PatientDetail → AppointmentList | ❌ 无入口 |
+| PatientDetail → ConsultationList | ❌ 无入口 |
+| PatientDetail → DialysisManageList | ❌ 无入口 |
+| AiAnalysisList → PatientDetail | ❌ 只显示截断 ID |
+| PatientDetail → 全局随访任务 | ❌ 无跳转 |
+
+### 3.4 死 API（已定义但无页面使用）
+
+| API 方法 | 文件 |
+|----------|------|
+| `patientApi.manageTags` | patients.ts |
+| `patientApi.listFamilyMembers/createFamilyMember/updateFamilyMember/deleteFamilyMember` | patients.ts (4个) |
+| `alertApi.resolve` | alerts.ts |
+| `articleApi.view` | articles.ts |
+| `suggestionApi.getComparison` | suggestions.ts |
+
+---
+
+## 4. 微信小程序完整性
+
+### 4.1 规模
+
+- 主包页面: 15 个路由
+- 分包页面: 约 47 个路由
+- **页面总计: 约 62 个**
+- Service 文件: 17 个（患者端 14 + 医护端 7）
+- TabBar: 4 个（首页/健康/消息/我的）
+
+### 4.2 患者端核心流程覆盖
+
+| 核心流程 | 覆盖度 |
+|----------|--------|
+| 微信登录 → 手机号绑定 | 100% |
+| 建档（就诊人管理） | 100% |
+| 体征录入（8 种指标） | 95% |
+| 趋势图 | 80%（Web 有更丰富图表） |
+| 蓝牙设备同步（BLE） | 100%（**Web 端没有**） |
+| 预约挂号 | 100% |
+| 随访管理 | 100% |
+| 在线咨询 | 100% |
+| 积分系统 | 100% |
+| AI 分析 | 100% |
+| 健康资讯 | 100% |
+| 线下活动 | 100% |
+| 通知 Tab | **0%（空壳，数据写死空数组）** |
+
+### 4.3 小程序独有功能
+
+| 功能 | 说明 |
+|------|------|
+| BLE 蓝牙设备同步 | 血压计/血糖仪/小米手环 3 种适配器 |
+| 微信一键登录 | wx.login + getPhoneNumber |
+| 微信订阅消息 | 5 种模板消息推送 |
+
+---
+
+## 5. 系统统一性分析
+
+### 5.1 功能孤岛效应
+
+从全局角度审视，系统存在以下孤岛效应：
+
+**A. AI 分析 — "有脑无手"**
+- 后端 4 个 SSE 分析端点 + 建议审批 + 行动收件箱 全部就绪
+- 前端只有"查看历史"能力，无法触发分析
+- AI 分析 → 建议 → 审批 → 行动 的闭环在后端完整，前端断裂
+- **影响**: AI 模块的投资回报率极低，能力已实现但无法被用户触及
+
+**B. 危急值告警 — "有声无窗"**
+- 后端告警引擎 + 规则配置 + 阈值管理 + 危急值确认 全部就绪
+- Web 前端只有普通告警列表，危急值体系完全无 UI
+- 小程序有告警查看但无危急值专属页面
+- **影响**: 医疗安全相关功能缺口，危急值发现后可能无法及时处理
+
+**C. 统计仪表盘 — "有数无图"**
+- 后端 9 个统计端点就绪（患者/咨询/随访/化验/预约/体征上报率/透析等）
+- Web 前端只有 `StatisticsDashboard` 一个页面，仅消费了部分端点
+- 小程序只有医护仪表盘（6 指标卡片），无完整统计
+- **影响**: 管理者视角缺失，无法通过数据驱动决策
+
+**D. 患者详情 — "有门无路"**
+- PatientDetail 作为核心枢纽页有 8 个 Tab，数据展示完善
+- 但从 PatientDetail 无法跳转到预约、咨询、透析、全局随访等关联功能
+- AI 分析列表也不提供到 PatientDetail 的导航
+- **影响**: 用户需要在多个页面间手动切换，无法形成工作流闭环
+
+### 5.2 数据一致性
+
+| 问题 | 严重度 | 说明 |
+|------|--------|------|
+| domain_events 堆积 1166 条 | LOW | outbox 模式未清理已消费事件 |
+| 12 个空表 | MEDIUM | 大量功能未被端到端验证 |
+| 通知 Tab 空壳 | HIGH | 小程序消息页"通知"Tab 数据写死空数组 |
+| erp-plugin 测试编译失败 | MEDIUM | `parse_manifest` 在 `#[cfg(test)]` 中未导入 |
+
+### 5.3 过度开发 vs 欠开发
+
+**过度开发（后端就绪但无前端）：**
+- 危急值告警体系（4 端点）— 后端完整，前端零页面
+- AI SSE 分析（4 端点）— 后端完整，前端零触发
+- 行动收件箱（2 端点）— 后端完整，前端零消费
+- 统计数据（5 端点）— 后端完整，前端部分消费
+
+**欠开发（设计目标未达成）：**
+- 小程序通知系统 — 完全未实现（空壳）
+- 患者详情关联导航 — 跨功能跳转缺失
+- 家属管理 UI — 4 个 API 就绪但无页面
+
+---
+
+## 6. 三端覆盖度矩阵
+
+| 功能领域 | 后端 | Web 前端 | 小程序 | 完整度 |
+|----------|------|---------|--------|--------|
+| 患者 CRUD | 100% | 100% | 100% | ✅ 完整 |
+| 体征数据 | 100% | 90% | 95% | ✅ 基本完整 |
+| 化验报告 | 100% | 100% | 100% | ✅ 完整 |
+| 健康档案 | 100% | 100% | 100% | ✅ 完整 |
+| 预约排班 | 100% | 95% | 100% | ✅ 基本完整 |
+| 随访管理 | 100% | 90% | 100% | ✅ 基本完整 |
+| 咨询管理 | 100% | 95% | 100% | ✅ 基本完整 |
+| 健康资讯 | 100% | 100% | 100% | ✅ 完整 |
+| 积分商城 | 100% | 100% | 100% | ✅ 完整 |
+| 线下活动 | 100% | 100% | 100% | ✅ 完整 |
+| 告警系统 | 100% | 70% | 80% | ⚠️ Web 缺危急值/resolve |
+| AI 分析 | 100% | 40% | 60% | ❌ SSE 无触发入口 |
+| 危急值告警 | 100% | 0% | 0% | ❌ 完全无 UI |
+| 统计仪表盘 | 100% | 50% | 30% | ⚠️ 端点就绪但消费不足 |
+| 行动收件箱 | 100% | 0% | 0% | ❌ 完全无 UI |
+| 设备管理 | 100% | 60% | 100% | ⚠️ Web 端缺 BLE 能力 |
+| 透析管理 | 100% | 80% | 100% | ✅ 基本完整 |
+| 通知系统 | 80% | 50% | 0% | ❌ 小程序空壳 |
+| 家属管理 | 100% | 0% | 0% | ❌ API 就绪无 UI |
+
+---
+
+## 7. 优先行动建议
+
+### P0 — 功能断裂（影响核心用户体验）
+
+1. **AI 分析闭环打通** — 在患者详情或独立页面增加"发起 AI 分析"按钮，让 SSE 能力被触及
+2. **患者详情关联导航** — 增加"查看该患者预约/咨询/透析"快捷入口
+3. **小程序通知 Tab** — 对接后端通知 API，不再写死空数据
+
+### P1 — 医疗安全
+
+4. **危急值告警 Web UI** — 至少增加危急值列表页 + 确认操作
+5. **erp-plugin 测试修复** — 补充 `use crate::manifest::parse_manifest` 导入
+
+### P2 — 管理者视角
+
+6. **统计仪表盘完善** — 消费已就绪的 5 个统计端点
+7. **家属管理 UI** — 在 PatientDetail 增加"家庭成员"Tab
+8. **AI 建议前后对比** — 集成 `suggestionApi.getComparison`
+
+---
+
+## 8. 实际验证发现的修正（2026-05-01 浏览器 + 代码验证）
+
+### 8.1 报告修正
+
+| 原报告结论 | 实际验证结果 | 修正 |
+|-----------|-------------|------|
+| 登录页标题"HMS" | 登录页显示 **"HMR Platform"**，与侧边栏 "HMS 健康" 不一致 | 新增：品牌命名不统一 |
+| 患者数据 32 条 | 30 条是 E2E 自动化测试生成的 `E2E患者_*`，仅 2 条真实数据 | 修正：系统几乎没有被真实使用过 |
+| 统计端点"部分覆盖" | API 验证患者统计、化验报告统计、预约统计、体征上报率、仪表盘统计 **全部返回正常数据** | 修正：后端统计能力完整，仅前端消费不足 |
+| 危急值告警"后端完整" | `GET /health/critical-alerts` 返回 **500 Internal Server Error** | 修正：危急值端点有 bug，后端也不完整 |
+| 透析管理"完整 CRUD" | `GET /health/dialysis-records` 返回 405（只接受 POST），必须按患者查询 | 修正：透析记录没有全局列表，必须先选患者 |
+| 小程序咨询"100% 覆盖" | 首页/健康页/个人中心 **均无入口** 跳转到在线咨询页 | 修正：咨询功能是"页面孤岛"，用户无法发现 |
+| AI SSE "无触发入口" | `POST /ai/analyze/lab-report` 端点存在且返回验证错误（需真实数据） | 确认：端点可用但前端无调用入口 |
+| 行动收件箱"0 数据" | API 返回 total=0 ✅ | 确认 |
+
+### 8.2 新发现（验证前未识别）
+
+**A. 品牌一致性**
+- 登录页标题 "HMR Platform"，侧边栏 "HMS 健康"，版权 "HMR Platform · ©汕头市智界科技有限公司"
+- 产品名称在 HMR/HMS 之间摇摆
+
+**B. 数据质量 — 测试污染**
+- 32 个患者中 30 个是 E2E 自动化测试创建的 `E2E患者_*`
+- domain_events 表堆积 1166 条未清理
+- 建议清理测试数据或建立独立测试租户
+
+**C. 小程序 AI 建议跳转错误**
+- 健康页 AI 建议卡片识别出 `appointment`/`followup` 类型建议后
+- 点击统一跳转到 **设置页**（`/pages/pkg-profile/settings/index`）
+- 而非预期的预约创建页或随访详情页 — 设计缺陷
+
+**D. 小程序咨询功能完全孤立**
+- `/pages/consultation/index` 已注册，页面存在
+- 但首页/健康页/个人中心均无入口指向它
+- 唯一入口在消息 Tab 的"咨询"子 Tab
+- 用户极难发现这个功能
+
+**E. Web 告警页面已存在但侧边栏无入口**
+- `/health/alerts` 可直接 URL 访问，页面功能完整
+- 但侧边栏菜单中 **没有告警管理入口**（未出现在菜单配置中）
+- 同理 `/health/alert-dashboard` 和 `/health/alert-rules` 也无菜单入口
+
+**F. Web 侧边栏缺少多个页面入口**
+
+| 已注册路由 | 侧边栏入口 | 状态 |
+|-----------|-----------|------|
+| `/health/alerts` | 无 | 需手动输入 URL |
+| `/health/alert-dashboard` | 无 | 需手动输入 URL |
+| `/health/alert-rules` | 无 | 需手动输入 URL |
+| `/health/dialysis` | 有（"透析管理"） | ✅ |
+| `/health/devices` | 有（"设备管理"） | ✅ |
+| `/health/articles` | 有（"资讯管理"） | ✅ |
+
+---
+
+## 9. 总结
+
+**项目整体完成度评估: 75%（实际验证后从 78% 下调）**
+
+- **后端** (93%): 119 个路由、CRUD 全覆盖，但危急值告警端点有 500 错误
+- **Web 前端** (68%): 核心页面功能完整，但存在隐性问题：告警页面有路由无菜单入口、AI/统计孤岛、跨模块导航断裂
+- **小程序** (80%): 患者端覆盖度高，但咨询功能孤立（用户无法发现）、AI 建议跳转错误、通知空壳
+- **数据质量** (35%): 30/32 患者为 E2E 测试数据，12/32 表完全空，系统几乎未经真实使用
+
+**最突出的矛盾**: 后端能力远超前端消费速度，约 13% 的路由为"死端点"。而已经暴露给用户的功能中，又有多个存在导航断裂和入口缺失，形成了"有能力但不可达"的双重问题。
+
+**新发现的系统性问题**:
+1. **品牌不一致** — HMR/HMS 混用
+2. **菜单配置缺失** — 告警相关 3 个页面有路由无菜单
+3. **小程序导航断裂** — 咨询功能孤立、AI 建议跳转到设置页
+4. **测试数据污染** — E2E 测试未清理导致数据不可信
+
+---
+
+## 变更记录
+
+| 日期 | 变更 |
+|------|------|
+| 2026-05-01 | 初始版本 — 三端联调深度审计 |
+| 2026-05-01 | 实际验证修正 — 浏览器+API+代码分析，6 项报告修正 + 6 项新发现，完成度从 78% 下调至 75% |

docs/discussions/2026-05-01-workbench-redesign-brainstorm.md

@@ -0,0 +1,50 @@
+# 工作台体验重构 — 发散式探讨
+
+> 日期: 2026-05-01 ~ 2026-05-02 | 参与者: 用户 + Claude
+
+## 背景
+
+HMS 项目已完成全系统审计（83% 完成度），工作台原型已设计（医生 A/B/C + 主任 D/E/F 共 6 种方案），最近 5 个提交在推进工作台前端实现。但工作台的设计前提需要修正。
+
+## 讨论要点
+
+### 1. 产品定位重大认知更新
+
+- **首期用户是血透中心/一级综合医院**，不是泛化健康管理机构
+- **机构已有 HIS + 专用血透管理系统**，HMS 不碰临床透析流程
+- **HMS 的真正定位是「患者-机构枢纽」**：日常健康数据采集、随访干预、积分运营、健康科普、潜在患者转化
+- **三种角色并行**：健康管家/随访护士、医生（审核/咨询角色）、运营人员
+- **产品愿景是持续演化**：健康管理 → 运营引擎 → 血透管理（最终替代专用血透系统）
+- **MVP 先独立运行**，不依赖 HIS 对接
+
+### 2. 工作台方案选择
+
+提出三种方案：
+- **方案 A「今日全景」仪表盘** — 统计卡片 + 待办列表 + 侧边 AI 洞察
+- **方案 B「工作流驱动」流水线** — 任务队列 + 详情处理面板（选中）
+- **方案 C「AI 指挥中心」** — AI 助手主卡片主动推送
+
+用户选择**方案 B**，理由：健康管家每天处理 20+ 任务，一件一件处理是最自然的工作节奏。
+
+### 3. 角色与范围决策
+
+- 先只做**健康管家**角色，医生和运营后续再做
+- 分两期实施：Phase 1 基于现有 3 种数据源（告警、AI 建议、随访），Phase 2 扩展
+
+### 4. 设计规格评审
+
+规格评审发现 7 个 CRITICAL 问题，核心是设计规格与现有代码库对不上：
+- 数据源不匹配（7 种任务类型中 4 种没有现成数据源）
+- API 路径冲突（现有 action-inbox 路由未处理）
+- 表名错误（points_redemption → points_order 等）
+- "无需新建表"的声明不准确
+- 缺少验收标准
+
+v2 已全部修复，采用分两期实施策略。
+
+## 结论
+
+- 方案 B「工作流驱动」健康管家工作台作为本期实施目标
+- 设计规格 v2 已通过评审，保存到 docs/superpowers/specs/2026-05-02-health-manager-workbench-design.md
+- 原型保存到 _temp/workbench-health-manager-A/B/C.html
+- 下一步：编写实施计划并执行