docs: V1 测试版本全面端到端测试报告 + 专家评估 + wiki 更新

- 测试报告: 157 端点测试, Health 63% / AI+Dialysis+Plugin 92.4%
- 专家评估: 产品7.3/架构7.6/安全7.0/测试4.1/UX7.6, 综合6.2 B-
- CRITICAL×2: 空标签名500 + 媒体库路由冲突
- CONDITIONAL GO: 修复 P0 问题后可发布

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

CLAUDE.md

@@ -247,6 +247,21 @@
 - [ ] 枚举值变更 → 前端类型定义和 UI 映射同步更新
 - [ ] 后端新增端点 → 前端 API 模块同步添加调用函数，不允许留空
 
+#### DTO 输入校验检查（强制）
+
+> 历史数据：2026-05-19 全系统审计发现 44 处校验缺失。
+> 新增/修改 DTO 时**必须**逐项确认：
+
+- [ ] 所有请求结构体已 `derive(Validate)`（包括 Update\*Req、查询参数）
+- [ ] Update\*Req 与 Create\*Req 校验对称（不允许 Update 降级）
+- [ ] 字符串字段有 `#[validate(length(min, max))]`
+- [ ] 枚举/类型字段有 `#[validate(custom)]` 限制合法值
+- [ ] 集合字段有 `#[validate(length(min = 1))]` 非空检查
+- [ ] 数值范围字段有 `#[validate(range(min, max))]`
+- [ ] URL 字段有 SSRF 防护（禁止 localhost/内网地址，仅 http/https）
+- [ ] 密码字段有 `max = 128` 防止 DoS
+- [ ] handler 层已调用 `req.validate().map_err(|e| AppError::Validation(e.to_string()))?`
+
 ### 3.4 事件总线
 
 - 模块间通信**只能**通过 `EventBus`
@@ -402,6 +417,9 @@ chore(docker): 添加 PostgreSQL 健康检查
 - ❌ **不要**跳过 Feature DoD — 每个功能标记"完成"前必须通过 §2.6 检查清单，不全面验证就提交 = 后续 5 次 fix（媒体库教训）
 - ❌ **不要**新增端点时默认放行 — 所有端点默认拒绝访问，必须显式声明权限（安全教训：25 次 fix 源于默认放行）
 - ❌ **不要**后端 DTO 变更不同步前端 — 字段名/路径/类型变更时必须同步更新前端 TypeScript 接口（35 次 fix 教训）
+- ❌ **不要**写 Update DTO 时省略校验 — Update*Req 必须与 Create*Req 校验对称（44 处缺失教训：Update 无 Validate derive / 枚举字段无 custom 校验 / Vec 无 min=1 / 密码无 max）
+- ❌ **不要**URL 字段不做 SSRF 防护 — 禁止 localhost/127.0.0.1/内网地址，仅允许 http/https 协议
+- ❌ **不要**handler 层跳过 `.validate()` — 所有 `Json<T>` handler 函数体第一行必须调 `req.validate().map_err(\|e\| AppError::Validation(e.to_string()))?`
 
 ### 场景化指令
 
@@ -412,6 +430,7 @@ chore(docker): 添加 PostgreSQL 健康检查
 - 当遇到**新增表** → 创建 SeaORM migration + Entity，包含所有标准字段
 - 当遇到**新增页面** → 使用 Ant Design 组件，i18n key 引用文案
 - 当遇到**新增业务模块插件** → 参考 `wiki/wasm-plugin.md` 的插件制作完整流程和 `.claude/skills/plugin-development/SKILL.md`，创建 cdylib crate + 实现 Guest trait + 编译为 WASM Component。**权限码必须与实体名一致（每个实体声明 `.list` + `.manage`）**
+- 当遇到**新增/修改 DTO** → 参考 `wiki/architecture.md` §4 DTO 输入校验规范：`derive(Validate)` + 字段级校验 + handler 层 `validate()` 调用 + 单元测试
 
 ---
 

docs/qa/2026-05-19-ai-health-butler-v2-test-plan.md

@@ -0,0 +1,540 @@
+# AI 健康管家 V2 — 前端验证测试方案
+
+> 日期: 2026-05-19 | 分支: feat/media-library-banner | 验证范围: Phase 1 + Phase 2A + Phase 2B
+
+## 大纲
+
+### 1. 环境准备与前置检查
+
+#### 1.1 服务启动确认
+
+| 步骤 | 操作 | 预期结果 |
+|------|------|----------|
+| 1 | 启动 PostgreSQL | `psql -U postgres -c "SELECT 1"` 返回 1 |
+| 2 | 启动后端 `cargo run -p erp-server` | 终端输出 `listening on 0.0.0.0:3000`，无 panic |
+| 3 | 启动前端 `pnpm dev` (apps/web) | `http://localhost:5174` 可访问，返回登录页 |
+| 4 | 启动 Ollama `ollama serve`（或 start-ollama.ps1） | `curl http://127.0.0.1:11434/api/tags` 返回模型列表，含 `qwen3:4b` |
+| 5 | 登录 admin/Admin@2026 | 成功进入管理后台首页 |
+
+**关键检查点：**
+- 后端启动日志中应出现 `Migration applied` 或 `All migrations applied`
+- 后端日志中应出现 `erp-ai module registered` 字样
+- 如有 migration 失败，先执行 `cargo run -p erp-server` 让迁移自动执行
+
+#### 1.2 数据库迁移状态验证
+
+```sql
+-- 检查 AI 相关表是否全部创建
+SELECT table_name FROM information_schema.tables
+WHERE table_schema = 'public' AND table_name LIKE 'ai_%'
+ORDER BY table_name;
+
+-- 预期 13+ 张表：
+-- ai_analysis, ai_analysis_queue, ai_chat_message, ai_chat_session,
+-- ai_feature_flags, ai_knowledge_guides, ai_knowledge_references,
+-- ai_knowledge_rules, ai_prompt, ai_risk_threshold, ai_suggestion,
+-- ai_suggestion_feedback, ai_tenant_configs, ai_tool_call_log,
+-- ai_usage, ai_usage_daily
+-- copilot_insights, copilot_risk_snapshots, copilot_rules, copilot_chat_logs
+```
+
+```sql
+-- 检查 seed 数据：权限码
+SELECT code FROM permissions WHERE code LIKE 'ai.%' OR code LIKE 'copilot.%'
+ORDER BY code;
+
+-- 预期包含：
+-- ai.analysis.list, ai.analysis.manage, ai.prompt.list, ai.prompt.manage,
+-- ai.usage.list, ai.suggestion.list, ai.suggestion.manage,
+-- ai.chat.send, ai.chat.session.list, ai.chat.session.manage, ai.chat.session.history,
+-- ai.config.read, ai.config.manage, ai.knowledge.list, ai.knowledge.manage,
+-- ai.admin.dashboard, ai.admin.flags
+-- copilot.insights.list, copilot.insights.manage, copilot.risk.view,
+-- copilot.rules.list, copilot.rules.manage
+```
+
+```sql
+-- 检查 seed 数据：AI Provider 配置
+SELECT id, name, provider_type, is_active FROM ai_providers WHERE deleted_at IS NULL;
+
+-- 预期至少 1 个活跃 Provider（ollama）
+```
+
+#### 1.3 菜单注册验证
+
+登录 admin 后，检查左侧菜单是否包含以下入口：
+
+| 菜单路径 | 预期可见 | 对应路由 |
+|----------|----------|----------|
+| 健康管理 > AI 配置 | 是 | `/health/ai-config` |
+| 健康管理 > AI Prompt 模板 | 是 | `/health/ai-prompts` |
+| 健康管理 > AI 分析记录 | 是 | `/health/ai-analysis` |
+| 健康管理 > AI 用量统计 | 是 | `/health/ai-usage` |
+| 健康管理 > AI 知识库 | 是 | `/health/ai-knowledge` |
+| AI 客服 | 是 | `/ai/chat` |
+
+#### 1.4 测试数据准备
+
+```sql
+-- 确认有测试患者
+SELECT id, name FROM patient WHERE deleted_at IS NULL LIMIT 5;
+
+-- 确认有体征数据（用于趋势分析）
+SELECT patient_id, COUNT(*) FROM vital_signs_record
+WHERE deleted_at IS NULL GROUP BY patient_id LIMIT 5;
+
+-- 确认有化验报告（用于化验解读）
+SELECT id, patient_id, status FROM lab_report
+WHERE deleted_at IS NULL LIMIT 5;
+
+-- 记录一个有体征+化验数据的患者 ID，后续测试使用
+-- patient_id = <记录备用>
+```
+
+如测试数据不足，通过 Web 管理后台先录入：
+1. 创建患者 → 录入体征数据（血压/血糖/心率各 5+ 条）
+2. 创建化验报告 → 添加检查项目（至少 3 项含正常/异常值）
+
+### 2. Phase 1A — AI 分析触点验证
+
+> 前置：已准备一个有体征数据+化验报告的测试患者
+
+#### 2.1 体征页 AI 趋势分析
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 1 | 导航到 健康管理 > 患者列表 > 选择测试患者 | 患者详情页打开 |
+| 2 | 切换到「体征」Tab | VitalSignsTab 展示体征图表 |
+| 3 | 点击「AI 趋势分析」按钮 | 按钮变为 loading 状态（旋转图标） |
+| 4 | 等待 AI 响应 | 显示 Card 卡片，标题含「AI 趋势分析结果」 |
+| 5 | 验证分析内容 | 内容为中文、包含对体征数据的描述、有建议性语句 |
+| 6 | 点击「关闭」按钮 | 分析卡片消失，恢复为「AI 趋势分析」按钮 |
+| 7 | 再次点击按钮（缓存回放） | 秒出结果（不重新调用 LLM），内容与之前一致 |
+
+**异常场景：**
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 8 | 选择一个无体征数据的患者 | 按钮点击后提示「患者在选定时间段内无体征监测数据」 |
+| 9 | Ollama 未启动时点击 | 显示错误提示卡片，有「重试」按钮 |
+
+#### 2.2 化验报告 AI 解读
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 1 | 导航到 健康管理 > 化验报告（或患者详情 > 化验 Tab） | 化验报告列表可见 |
+| 2 | 选择一条有检查项目的报告 | 报告详情展开 |
+| 3 | 点击「AI 解读」按钮 | loading 状态 → SSE 流式输出分析内容 |
+| 4 | 等待完成 | Card 显示完整分析结果 |
+| 5 | 验证内容 | 包含对各项指标的解读、异常项标注、健康建议 |
+
+**异常场景：**
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 6 | 选择一条无检查项目的报告 | 提示「化验报告缺少检查项目数据」 |
+| 7 | 化验报告 AI 解读过程中关闭页面 | 后端日志记录分析失败事件 |
+
+#### 2.3 体检方案 & 报告摘要
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 1 | 患者详情页体检方案区域，点击「AI 体检方案」 | SSE 流式输出个性化体检建议 |
+| 2 | 健康报告详情页，点击「AI 报告摘要」 | SSE 流式输出报告摘要 |
+| 3 | 两项均验证：内容为中文、与患者数据相关、有实际建议 |
+
+#### 2.4 健康摘要端点（后端 API 直接验证）
+
+```bash
+# 获取 admin token
+TOKEN=$(curl -s http://localhost:3000/api/v1/auth/login \
+  -H "Content-Type: application/json" \
+  -d '{"username":"admin","password":"Admin@2026"}' | jq -r '.data.token')
+
+# 调用健康摘要（替换 PATIENT_ID）
+curl -s http://localhost:3000/api/v1/ai/health-summary?patient_id=PATIENT_ID \
+  -H "Authorization: Bearer $TOKEN" | jq .
+```
+
+**预期响应结构：**
+```json
+{
+  "success": true,
+  "data": {
+    "patient_id": "...",
+    "risk_level": "low|medium|high|critical",
+    "active_insights_count": 0,
+    "recent_analyses_count": 1,
+    "latest_insight_title": null,
+    "latest_analysis_type": "trends",
+    "summary_items": [...]
+  }
+}
+```
+
+### 3. Phase 1B — 角色沙箱验证
+
+> 沙箱验证需要通过 AI 聊天（/ai/chat 或侧边栏）触发 Agent，观察 LLM 调用哪些 Tool 和输出风格差异。
+> 由于无法直接创建不同角色的 JWT，这里用 admin 角色模拟——admin 的沙箱配置 allowed_tools 最少（只有 query_patient_vitals），验证沙箱确实在限制。
+
+#### 3.1 沙箱 Tool 限制验证
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 1 | 打开 AI 聊天页（/ai/chat）或侧边栏 | 聊天界面可用 |
+| 2 | 发送「查询我的血压数据」（携带 patient_id） | 后端日志显示沙箱解析: `role=Admin, allowed_tools={"query_patient_vitals"}` |
+| 3 | 验证 Tool 调用 | 只有 `query_patient_vitals` 被调用（或无 Tool 调用直接文本回复） |
+| 4 | 发送「帮我分析化验报告」 | 后端日志显示 `Tool 'analyze_lab_report' 在当前角色下不可用`（admin 沙箱不允许） |
+
+**后端日志关键字：**
+```
+Sandbox resolved  tenant_id=... role=Admin allowed_tools=...
+Tool 'xxx' 在当前角色下不可用
+```
+
+#### 3.2 角色差异对比（理论验证）
+
+> 通过直接查看 `sandbox.rs` 确认配置正确性：
+
+| 角色 | allowed_tools 数量 | 免责声明 | Prompt 风格 |
+|------|-------------------|----------|-------------|
+| Patient | 6 | 追加 | 通俗温和，不做诊断建议 |
+| MedicalStaff | 9（全部） | 无 | 专业简洁，引用数据来源 |
+| Admin | 1 | 无 | 运营统计导向，无个体数据 |
+
+**验证方法：** 用 psql 查询一个医护角色的用户，以其身份登录后发送消息，对比：
+- 回复是否更专业、引用数据来源
+- 是否无免责声明尾部
+- 是否能调用 analyze_lab_report 等医护专用 Tool
+
+#### 3.3 输出过滤验证
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 1 | 用患者角色发送消息 | 回复末尾含 `*以上内容由 AI 生成，仅供参考...*` 免责声明 |
+| 2 | 用医护角色发送相同消息 | 无免责声明 |
+| 3 | 患者角色回复中不应出现具体诊断术语 | 如出现「高血压 II 期」应被泛化为「血压偏高」 |
+
+### 4. Phase 1C — 管理看板验证
+
+> 导航到 健康管理 > AI 用量统计（/health/ai-usage）
+
+#### 4.1 用量概览 Tab
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 1 | 页面加载 | 默认展示「用量概览」Tab |
+| 2 | 查看统计卡片 | 显示「总分析次数」「分析类型数」「本月分析」三个数字卡片 |
+| 3 | 数字与实际一致 | 总分析次数 >= 第 2 章测试中执行的分析次数 |
+| 4 | 查看类型分布 | 每个分析类型显示为带颜色的数字卡片，含百分比 |
+| 5 | 无数据时 | 显示 Empty 组件「暂无分析数据」 |
+
+#### 4.2 成本分析 Tab
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 1 | 切换到「成本分析」Tab | 触发 `/ai/admin/daily-usage` 请求 |
+| 2 | 查看统计卡片 | 显示「30 天总调用」「30 天总 Token」「30 天成本」 |
+| 3 | 查看日用量明细表 | Table 展示日期、功能、调用次数、Token、成本列 |
+| 4 | 如果无日聚合数据 | 所有值为 0（因为 aggregate_daily 需要定时任务触发或手动调用） |
+
+**注意：** 日聚合数据来源于 `ai_usage_daily` 表，该表由定时任务（每日 02:00）填充。如果当日无数据，属于正常。
+
+#### 4.3 功能开关 Tab
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 1 | 切换到「功能开关」Tab | 触发 `/ai/admin/flags` 请求 |
+| 2 | 查看开关列表 | 显示 12 个功能项：AI 分析、AI 聊天、趋势分析等 |
+| 3 | 默认值验证 | `ai.alert.push` 和 `ai.voice` 默认 OFF，其余 ON |
+| 4 | 点击某个开关关闭 | Switch 变为「禁用」状态，提示 `xxx 已禁用` |
+| 5 | 刷新页面 | 该开关状态保持禁用（持久化到数据库） |
+| 6 | 再次开启 | 恢复为「启用」状态 |
+
+**异常场景：**
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 7 | 无 `ai.admin.flags` 权限的用户访问 | 开关显示为只读 Tag（不可切换） |
+
+### 5. Phase 2A — 医护端 AI 助手验证
+
+#### 5.1 AI 侧边栏骨架
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 1 | 在管理后台任意页面观察右下角 | 显示 AI 浮动按钮（机器人图标） |
+| 2 | 点击浮动按钮 | 右侧弹出 Drawer，标题含「AI 健康助手」 |
+| 3 | Drawer 中有输入框和发送按钮 | 输入框为 TextArea，发送按钮有 SendOutlined 图标 |
+| 4 | 输入消息点击发送 | 消息出现在对话区，AI 回复流式显示 |
+| 5 | 再次点击浮动按钮 | Drawer 关闭 |
+| 6 | 在不同页面打开侧边栏 | Drawer 内容保持（不因页面切换重置） |
+
+#### 5.2 患者档案 AI 自动摘要
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 1 | 导航到 健康管理 > 患者列表 > 选择测试患者 | 患者详情页打开（URL 含 `/health/patients/{id}`） |
+| 2 | 点击 AI 浮动按钮打开侧边栏 | 侧边栏顶部显示「健康摘要」卡片 |
+| 3 | 摘要卡片内容 | 显示风险等级（低/中/高）+ 活跃洞察数 + 最近分析数 |
+| 4 | 导航到非患者页面 | 摘要卡片消失（无 patientId 上下文） |
+
+#### 5.3 随访页 AI 辅助生成小结
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 1 | 导航到 健康管理 > 随访管理 > 选择一条随访记录 | 随访详情页打开 |
+| 2 | 找到「AI 随访小结」按钮 | 按钮存在且可点击 |
+| 3 | 点击按钮 | loading 状态 → SSE 流式输出随访分析 |
+| 4 | 等待完成 | Card 显示完整随访小结内容 |
+
+#### 5.4 Agent Tool 扩展验证（9 个 Tool）
+
+> 通过 AI 聊天（侧边栏或 /ai/chat）发送特定指令，验证各 Tool 被正确调用。
+> 需要 admin 角色或医护角色，且在沙箱白名单内的 Tool。
+
+| # | 发送消息 | 预期调用的 Tool | 预期行为 |
+|---|---------|----------------|----------|
+| 1 | 「查询患者最近的血压数据」（带 patient_id） | `query_patient_vitals` | 返回血压数值 |
+| 2 | 「查看这个患者的化验报告」 | `query_patient_lab_reports` | 返回化验报告摘要 |
+| 3 | 「患者有哪些预约记录」 | `query_patient_appointments` | 返回预约列表（医护角色） |
+| 4 | 「患者在吃什么药」 | `query_patient_medications` | 返回用药记录 |
+| 5 | 「查看患者基本信息」 | `query_patient_profile` | 返回患者档案信息 |
+| 6 | 「搜索高血压相关知识」 | `search_medical_knowledge` | RAG 语义检索返回知识条目 |
+| 7 | 「分析一下这张化验报告」（医护角色） | `analyze_lab_report` | 调用分析 Tool |
+| 8 | 「分析患者最近的健康趋势」（医护角色） | `analyze_health_trends` | 调用趋势分析 Tool |
+| 9 | 「获取患者的健康洞察」 | `get_health_insights` | 返回 Copilot 洞察信息 |
+
+**验证方法：** 每次发送后检查后端日志中是否出现对应的 Tool 调用记录：
+```
+tool_call_log: tool=query_patient_vitals tenant_id=... user_id=...
+```
+
+**注意：** admin 角色只能调用 Tool #1（query_patient_vitals），其余 Tool 会返回「在当前角色下不可用」。
+
+### 6. Phase 2B — 洞察→推送→反馈闭环验证
+
+#### 6.1 Copilot 洞察列表/详情/忽略
+
+> 通过后端 API 验证（Web 前端可能在 Copilot 菜单下或管理看板中）
+
+```bash
+# 列出洞察
+curl -s http://localhost:3000/api/v1/copilot/insights \
+  -H "Authorization: Bearer $TOKEN" | jq .
+
+# 查看详情（替换 INSIGHT_ID）
+curl -s http://localhost:3000/api/v1/copilot/insights/INSIGHT_ID \
+  -H "Authorization: Bearer $TOKEN" | jq .
+
+# 忽略洞察
+curl -s -X POST http://localhost:3000/api/v1/copilot/insights/INSIGHT_ID/dismiss \
+  -H "Authorization: Bearer $TOKEN" | jq .
+```
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 1 | GET /copilot/insights | 返回洞察列表，含分页信息 |
+| 2 | GET /copilot/insights/{id} | 返回洞察详情 |
+| 3 | POST /copilot/insights/{id}/dismiss | 返回 `{dismissed: true}` |
+| 4 | 再次 GET 该洞察 | 其 `is_read` 或类似标记应已变更 |
+
+#### 6.2 风险评分与洞察自动创建
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 1 | 查询患者风险评分 | `GET /copilot/patients/{id}/risk` 返回风险快照 |
+| 2 | 手动触发风险刷新（重启后端等定时任务） | 后端日志出现 `refresh_all_patients` 执行记录 |
+| 3 | 检查高风险患者是否自动创建洞察 | `SELECT * FROM copilot_insights WHERE patient_id=... AND deleted_at IS NULL ORDER BY created_at DESC LIMIT 5` |
+| 4 | 检查消息中心是否有对应通知 | `SELECT * FROM messages WHERE tenant_id=... AND type='system' ORDER BY created_at DESC LIMIT 5` |
+
+#### 6.3 AI 建议审批/执行/对比
+
+```bash
+# 列出建议
+curl -s http://localhost:3000/api/v1/ai/suggestions?status=pending \
+  -H "Authorization: Bearer $TOKEN" | jq .
+
+# 审批建议（替换 SUGGESTION_ID）
+curl -s -X POST http://localhost:3000/api/v1/ai/suggestions/SUGGESTION_ID/approve \
+  -H "Authorization: Bearer $TOKEN" | jq .
+
+# 执行建议
+curl -s -X POST http://localhost:3000/api/v1/ai/suggestions/SUGGESTION_ID/execute \
+  -H "Authorization: Bearer $TOKEN" | jq .
+
+# 查看对比
+curl -s http://localhost:3000/api/v1/ai/suggestions/SUGGESTION_ID/comparison \
+  -H "Authorization: Bearer $TOKEN" | jq .
+```
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 1 | 列出 pending 建议 | 返回建议列表 |
+| 2 | 审批建议 | 状态变为 approved |
+| 3 | 执行建议 | 状态变为 executed，返回执行结果 |
+| 4 | 查看对比 | 返回 before/after 数据对比 |
+
+#### 6.4 建议反馈（采纳/忽略/咨询医生）
+
+```bash
+# 提交反馈（替换 SUGGESTION_ID）
+curl -s -X POST http://localhost:3000/api/v1/ai/suggestions/SUGGESTION_ID/feedback \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '{"action":"adopted","feedback_text":"建议很好，已采纳"}' | jq .
+```
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 1 | POST feedback action=adopted | 返回成功，`ai_suggestion_feedback` 表有新记录 |
+| 2 | POST feedback action=ignored | 返回成功 |
+| 3 | POST feedback action=consult | 返回成功 |
+| 4 | 验证事件发布 | `SELECT * FROM domain_events WHERE event_type='ai.suggestion.feedback' ORDER BY created_at DESC LIMIT 1` |
+
+### 7. 会话系统验证
+
+> 导航到 AI 客服页面（/ai/chat）
+
+#### 7.1 会话创建/列表/重命名/关闭
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 1 | 打开 /ai/chat | 显示聊天界面，左侧有会话列表（或自动创建新会话） |
+| 2 | 发送第一条消息 | 自动创建新会话，左侧列表出现会话条目 |
+| 3 | 刷新页面 | 会话列表保留，可点击切换 |
+| 4 | 点击会话重命名按钮 | 输入框出现，可修改会话标题 |
+| 5 | 输入新标题后确认 | 会话标题更新 |
+| 6 | 点击关闭会话 | 会话标记为 closed，不再出现在活跃列表 |
+
+#### 7.2 多轮对话上下文保持
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 1 | 发送「我最近血压怎么样」（带 patient_id） | AI 调用 query_patient_vitals，回复含血压数据 |
+| 2 | 发送「跟上周比呢？」 | AI 理解上下文，继续讨论血压趋势 |
+| 3 | 发送「有什么建议？」 | AI 基于前两轮对话内容给出建议 |
+
+**验证点：** 后端 `ai_chat_message` 表应有 3 条 user 消息 + 3 条 assistant 消息，session_id 相同。
+
+#### 7.3 RichMessage + DisplayHint 渲染
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 1 | 发送触发 Tool Call 的消息（如「查看血压」） | AI 回复中含 RichMessage 卡片 |
+| 2 | 验证 VitalCard 渲染 | 体征数据以卡片形式展示（非纯文本） |
+| 3 | 验证 LabReportCard 渲染 | 化验数据以结构化卡片展示 |
+| 4 | 验证纯文本回退 | 无 DisplayHint 时显示普通文本消息 |
+
+### 8. RAG 知识库验证
+
+> 导航到 健康管理 > AI 知识库（/health/ai-knowledge）
+
+#### 8.1 知识条目 CRUD
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 1 | 打开知识库页面 | 显示 References 和 Guides 两个 Tab 或区域 |
+| 2 | 点击「新建 Reference」 | 弹出表单（标题、内容、标签等） |
+| 3 | 填写并提交 | 创建成功，列表刷新 |
+| 4 | 点击编辑 | 表单回填已有内容 |
+| 5 | 修改后提交 | 更新成功 |
+| 6 | 点击删除 | 确认后删除，列表移除 |
+| 7 | 重复 2-6 for Guides | 同样 CRUD 流程正常 |
+
+#### 8.2 语义搜索 Tool（search_medical_knowledge）
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 1 | 先创建 1-2 条知识条目（如「高血压日常管理指南」） | 数据入库 + 向量嵌入完成 |
+| 2 | 在 AI 聊天中发送「高血压应该注意什么」 | Agent 调用 `search_medical_knowledge` Tool |
+| 3 | 验证返回内容 | AI 回复中包含知识库中的相关内容 |
+
+**后端日志验证：**
+```
+tool_call_log: tool=search_medical_knowledge query="高血压应该注意什么" results=2
+```
+
+#### 8.3 向量嵌入与重嵌入
+
+```bash
+# 手动触发重嵌入（替换 REFERENCE_ID）
+curl -s -X POST http://localhost:3000/api/v1/ai/knowledge/references/REFERENCE_ID/re-embed \
+  -H "Authorization: Bearer $TOKEN" | jq .
+```
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 1 | 触发 re-embed | 后端调用 Embedding 服务，返回成功 |
+| 2 | 检查数据库 | `ai_knowledge_references` 表中该条目的 `embedding` 字段非空 |
+| 3 | 无 pgvector 扩展时 | 应有明确的错误提示（而非 panic） |
+
+### 9. 边界条件与安全验证
+
+#### 9.1 权限拦截
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 1 | 用无 `ai.analysis.manage` 权限的用户点击「AI 分析」 | 返回 403 或前端按钮不显示 |
+| 2 | 用无 `ai.admin.flags` 权限的用户访问功能开关 | Switch 显示为只读 Tag |
+| 3 | 用无 `ai.chat.send` 权限的用户发送聊天消息 | 返回 403 |
+| 4 | 用无 `ai.knowledge.manage` 权限的用户创建知识条目 | 返回 403 |
+| 5 | 用无 `copilot.insights.manage` 权限的用户忽略洞察 | 返回 403 |
+
+#### 9.2 输入校验
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 1 | 发送空消息 | 返回 400「消息不能为空」 |
+| 2 | 发送 2001 字消息 | 返回 400「消息长度不能超过 2000 字」 |
+| 3 | 调用 /ai/health-summary?patient_id=invalid-uuid | 返回 400 |
+| 4 | 调用 /ai/admin/daily-usage?start_date=invalid | 返回 400「start_date 格式错误」 |
+
+#### 9.3 并发与性能
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 1 | 同时发送 2 个 SSE 分析请求 | 两个流均正常完成，不互相阻塞 |
+| 2 | 发送超长对话（10 轮以上） | Agent 仍能正常响应，不超时 |
+| 3 | Ollama 响应慢时（>30s） | SSE 流保持 alive（KeepAlive 生效） |
+
+#### 9.4 配额与预算拦截
+
+```bash
+# 查看配额状态
+curl -s http://localhost:3000/api/v1/ai/quota/summary \
+  -H "Authorization: Bearer $TOKEN" | jq .
+
+# 查看预算状态
+curl -s http://localhost:3000/api/v1/ai/budget/status \
+  -H "Authorization: Bearer $TOKEN" | jq .
+```
+
+| # | 操作 | 预期结果 |
+|---|------|----------|
+| 1 | 查看配额汇总 | 返回各 Provider 的 quota_used/quota_remaining |
+| 2 | 查看预算状态 | 返回 total_budget/spent/remaining |
+| 3 | 如 Token 预算已耗尽 | 后续聊天请求应返回明确的预算超限错误 |
+
+---
+
+## 测试结果记录模板
+
+| 章节 | 测试项 | 结果 | 备注 |
+|------|--------|------|------|
+| 1.1 | 服务启动 | PASS/FAIL | |
+| 1.2 | 数据库迁移 | PASS/FAIL | |
+| 2.1 | 体征趋势分析 | PASS/FAIL | |
+| 2.2 | 化验报告解读 | PASS/FAIL | |
+| 2.4 | 健康摘要端点 | PASS/FAIL | |
+| 3.1 | 沙箱 Tool 限制 | PASS/FAIL | |
+| 4.1 | 用量概览 | PASS/FAIL | |
+| 4.3 | 功能开关 | PASS/FAIL | |
+| 5.1 | AI 侧边栏 | PASS/FAIL | |
+| 5.2 | 患者自动摘要 | PASS/FAIL | |
+| 5.4 | 9 Tool 验证 | PASS/FAIL | |
+| 6.1 | 洞察 CRUD | PASS/FAIL | |
+| 6.4 | 建议反馈 | PASS/FAIL | |
+| 7.2 | 多轮对话 | PASS/FAIL | |
+| 8.2 | 语义搜索 | PASS/FAIL | |
+| 9.1 | 权限拦截 | PASS/FAIL | |

docs/qa/expert-brainstorming-v1-release-final.md

@@ -0,0 +1,263 @@
+# HMS V1 测试版本 — 专家头脑风暴综合评估报告
+
+> **评估日期**: 2026-05-20 | **评估方式**: 5 个并行 Agent 专家独立评估 | **评估基准**: 代码审查 + API 测试结果 + 架构文档
+
+---
+
+## 1. 综合评分
+
+### 1.1 六维度雷达图数据
+
+| 维度 | 评分 | 等级 | 专家 |
+|------|------|------|------|
+| 架构 | **7.6/10** | B+ | 架构专家 |
+| 产品 | **7.3/10** | B+ | 产品专家 |
+| 安全 | **7.0/10** | B | 安全专家 |
+| UX | **7.6/10** | B+ | UX 专家 |
+| 测试 | **4.1/10** | D+ | 测试专家 |
+| DevOps | **3.8/10** | D | 依据 wiki 系统分析数据 |
+| **综合** | **6.2/10** | **B-** | 加权平均 |
+
+### 1.2 综合评估结论
+
+HMS V1 测试版本在**架构设计**和**产品功能**方面表现优秀（均超 7.0），**安全基线**达到医疗系统基本要求（7.0），**UX 设计**成熟度高（7.6）。主要短板在**测试充分性**（4.1）和**DevOps 成熟度**（3.8）。
+
+**一句话总结：** 产品功能和架构设计扎实，安全和 UX 达标，但测试覆盖率和 DevOps 能力是短板，需要在中期迭代中重点投入。
+
+---
+
+## 2. 产品专家评估 — 7.3/10 (B+)
+
+**评估人**: 产品专家 Agent | **详细维度评分**: 功能完整性 7.5 / 用户价值 8.0 / MVP 边界 7.0 / 数据完整性 7.5 / 产品成熟度 6.5
+
+### 2.1 核心优势
+
+- **医疗业务闭环完整**：患者建档 → 体征录入 → 化验报告 → 医生查看 → AI 分析 → 咨询回复 → 随访管理，全链路覆盖
+- **AI 能力差异化**：化验单解读、趋势分析、报告摘要、智能对话，超越传统 HIS 的被动管理
+- **多角色支持到位**：Admin/Doctor/Nurse/Health Manager/Operator/患者 6 角色各有独立工作视角
+- **积分商城+线下活动**：运营工具完整，提高患者粘性
+
+### 2.2 主要问题
+
+- **积分商城路由缺失**：前端页面存在但后端 5 个 API 返回 404，用户看到空页面
+- **小程序功能残缺**：部分页面功能未连通，BLE 设备同步体验差
+- **AI 分析结果展示粗糙**：纯文本输出，缺少结构化卡片、图表联动
+- **报表能力不足**：缺少自定义报表、数据导出、PDF 生成
+
+### 2.3 行动建议
+
+| 优先级 | 建议 | 预期收益 |
+|--------|------|----------|
+| P0 | 修复积分商城路由或冻结模块 | 避免用户看到空页面 |
+| P1 | AI 分析结果结构化展示 | 提升分析结果可读性 |
+| P2 | 报表导出（PDF/Excel） | 满足医疗合规要求 |
+| P2 | 小程序功能连通性优化 | 提升患者端体验 |
+
+---
+
+## 3. 架构专家评估 — 7.6/10 (B+)
+
+**评估人**: 架构专家 Agent | **详细维度评分**: 模块化 8.5 / 可扩展性 8.0 / 数据架构 7.5 / 错误处理 8.0 / 技术债 7.0 / 生产就绪度 6.5
+
+### 3.1 三大架构亮点
+
+**1. ErpModule trait + ModuleRegistry 模块化体系（8.5/10）**
+- `ErpModule` trait 定义了 name / dependencies / on_startup / on_shutdown / permissions 等生命周期钩子
+- `ModuleRegistry` 使用 Kahn 算法拓扑排序，支持循环依赖检测
+- 17 个 crate 之间零直接依赖，仅通过 erp-core trait 和事件通信
+- 添加新模块成本极低：创建 crate → 实现 ErpModule → 注册
+
+**2. Outbox + Dead Letter + 幂等消费的事件可靠性链**
+- `EventBus::publish` 两阶段提交：先持久化 pending → 内存广播 → 更新 published
+- `consume_with_retry` 幂等检查 + dead-letter 兜底
+- outbox relay LISTEN/NOTIFY + 30s 兜底轮询 + 自动重连
+
+**3. 多租户双重隔离（应用层 + PostgreSQL RLS）**
+- 应用层所有查询强制带 `tenant_id` 过滤
+- PostgreSQL RLS 策略 `SET app.current_tenant_id` 做数据库层兜底
+- 即使应用层遗漏，数据库层也能防止跨租户数据泄漏
+
+### 3.2 三大架构风险
+
+**1. EventBus 单进程限制（可扩展性瓶颈）**
+`broadcast::channel(1024)` 纯内存广播。多实例部署时只有持有 outbox relay 连接的实例会处理 pending 事件。需引入 Redis Pub/Sub 做跨实例事件分发。
+
+**2. main.rs God File（维护性风险）**
+1021 行集中了模块初始化、AI Provider 构建、路由组装、安全检查、定时任务启动等。应将各模块初始化逻辑下沉到 `on_startup` 钩子。
+
+**3. 生产监控深度不足（运维风险）**
+缺少 OpenTelemetry 分布式追踪、数据库自动备份、结构化健康检查端点。Prometheus 指标有基础覆盖但缺少 SLO/SLI 定义。
+
+### 3.3 行动建议
+
+| 优先级 | 建议 | 预期收益 |
+|--------|------|----------|
+| P1 | 拆分 main.rs 到各模块 on_startup | 可维护性提升 |
+| P1 | EventBus 扩展支持 Redis Pub/Sub | 水平扩展前置条件 |
+| P2 | 补充 OpenTelemetry 追踪 | 生产可观测性 |
+| P2 | 健康检查端点深入探测 DB/Redis | 运维可靠性 |
+
+---
+
+## 4. 安全专家评估 — 7.0/10 (B)
+
+**评估人**: 安全专家 Agent | **详细维度评分**: 认证与授权 7.5 / 数据保护 8.0 / 输入验证 7.0 / 网络安全 5.5 / 多租户安全 8.0 / 生产安全 5.0
+
+### 4.1 安全亮点
+
+- **PII 加密成熟**：AES-256-GCM + KEK/DEK 双层密钥管理，敏感字段（身份证、手机号、地址）自动加密存储
+- **多租户双重隔离**：应用层 + PostgreSQL RLS 策略双重保障，即使代码遗漏也不会泄漏
+- **速率限制完善**：IP 级 5/min 登录 + 账户锁定 + 用户级 300/min API + 网关 60/min
+- **安全响应头全量覆盖**：X-Frame-Options / X-Content-Type-Options / X-XSS-Protection / Referrer-Policy
+- **默认密钥拒绝启动**：JWT/DB/Redis/Wechat 默认密钥在生产环境直接拒绝
+
+### 4.2 安全风险
+
+- **网络安全（5.5/10）**：缺少 HSTS header、CSP 策略不严格、无 WAF 前置
+- **生产安全（5.0/10）**：无数据库自动备份、无密钥轮换机制、无安全审计日志导出
+- **输入验证（7.0/10）**：空标签名导致 500、未来出生日期未拒绝、page_size 无上限
+
+### 4.3 行动建议
+
+| 优先级 | 建议 | 预期收益 |
+|--------|------|----------|
+| P0 | 修复空标签名 500 错误 | 输入验证完整性 |
+| P1 | 添加 HSTS header | 传输安全 |
+| P1 | 数据库自动备份策略 | 数据安全兜底 |
+| P2 | 密钥自动轮换机制 | 降低密钥泄漏风险 |
+| P2 | CSP 策略加固 | XSS 防护深化 |
+
+---
+
+## 5. 测试专家评估 — 4.1/10 (D+)
+
+**评估人**: 测试专家 Agent | **详细维度评分**: 覆盖广度 4.5 / 测试深度 4.0 / 自动化水平 3.5 / 测试质量 5.0 / 风险覆盖 3.0 / 可维护性 5.5
+
+### 5.1 当前测试状态
+
+| 指标 | 值 | 评价 |
+|------|-----|------|
+| 后端测试函数 | 943 个 | 中等 — 但多为单元测试，集成测试少 |
+| 前端单元测试 | 62 文件/~693 断言 | 中等 |
+| E2E 测试 | 17 spec/~64 断言 | 不足 — 覆盖率约 30% |
+| 小程序测试 | 0 | 严重缺失 |
+| API 集成测试 | 少量 | 不足 — 大量端点未覆盖 |
+| 负载/性能测试 | 无 | 缺失 |
+
+### 5.2 关键问题
+
+- **测试覆盖率不足**：943 个后端测试多为 Service 层单元测试，Handler 层和端到端 API 集成测试严重不足
+- **自动化水平低**：E2E 测试仅 17 个 spec，无法形成有效的回归保护网
+- **小程序零测试**：161 个文件 / 60 页面无任何自动化测试
+- **性能测试缺失**：无负载测试、无压力测试、无性能基准线
+- **测试数据管理差**：测试数据硬编码在测试文件中，无独立的 fixture/seed 管理
+
+### 5.3 行动建议
+
+| 优先级 | 建议 | 预期收益 |
+|--------|------|----------|
+| P0 | API 集成测试覆盖核心链路 | 关键业务回归保护 |
+| P1 | E2E 测试扩展到 30+ spec | 前端回归保护 |
+| P1 | 小程序核心流程 E2E 测试 | 患者端质量保障 |
+| P2 | 性能基准测试框架搭建 | 性能回归检测 |
+| P2 | 测试数据 fixture 管理 | 测试可维护性 |
+
+---
+
+## 6. UX 专家评估 — 7.6/10 (B+)
+
+**评估人**: UX 专家 Agent | **详细维度评分**: 设计一致性 8.0 / 信息架构 7.5 / 交互可用性 7.5 / 响应式适配 6.5 / 可访问性 8.0 / 视觉品质 8.0
+
+### 6.1 UX 亮点
+
+- **设计系统成熟**：11 级字号 Token + 12 结构 Token，75 页面 SCSS 全量接入 `var(--tk-*)`
+- **长者模式 100% 覆盖**：58/58 页面字号 ≥ 22px，CSS 变量级联覆盖
+- **UI 合规审计 95/100**：T40 审计 60 页面全覆盖，HIGH×2 + MEDIUM×6 全部修复
+- **Ant Design 6 统一风格**：组件库使用一致，无自定义组件与 antd 风格冲突
+- **权限引导清晰**：无权限页面有友好提示，非白屏
+
+### 6.2 UX 问题
+
+- **响应式适配不足（6.5/10）**：部分页面窄屏下布局错乱，表格横向滚动体验差
+- **空状态处理不一致**：部分列表空时显示空白，部分有 Empty 组件
+- **加载状态不统一**：部分页面有 Skeleton，部分直接 Spinner，部分无加载态
+- **移动端体验缺失**：Web 端未做移动端适配，仅依赖小程序覆盖移动场景
+
+### 6.3 行动建议
+
+| 优先级 | 建议 | 预期收益 |
+|--------|------|----------|
+| P1 | 统一空状态/加载状态组件 | 体验一致性 |
+| P1 | 表格窄屏响应式优化 | 桌面端体验提升 |
+| P2 | 骨架屏统一应用 | 加载感知优化 |
+| P2 | 错误页面设计系统化 | 异常场景体验 |
+
+---
+
+## 7. 六维度交叉分析与 TOP 10 行动清单
+
+### 7.1 维度交叉分析
+
+| 维度 | 架构 | 产品 | 安全 | 测试 | UX | DevOps |
+|------|------|------|------|------|-----|--------|
+| **架构** | - | 模块化支撑快速迭代 | 双重隔离是安全基石 | 模块化降低测试范围 | 组件架构支撑设计系统 | 需改进部署模型 |
+| **产品** | 模块化支持扩展 | - | 安全是医疗产品硬门槛 | 测试保障产品质量 | UX 决定用户留存 | CI/CD 影响交付速度 |
+| **安全** | RLS 是架构优势 | 安全增强产品信任 | - | 安全测试不足 | 安全提示需UX优化 | 安全运维缺失 |
+| **测试** | 架构清晰利于测试 | 测试验证产品需求 | 安全需专项测试 | - | UI 测试自动化弱 | 自动化测试需CI集成 |
+| **UX** | 组件架构支撑UI | 设计服务产品目标 | 安全与体验需平衡 | 无障碍测试缺失 | - | 性能影响体验 |
+| **DevOps** | 部署架构需优化 | 交付效率影响产品 | 安全运维是短板 | CI/CD 保障测试执行 | CDN 影响加载体验 | - |
+
+### 7.2 TOP 10 行动清单
+
+| # | 行动项 | 维度 | 优先级 | 预估工作量 |
+|---|--------|------|--------|-----------|
+| 1 | 修复空标签名 500（DTO 校验） | 安全 | P0 | 0.5h |
+| 2 | 修复媒体库路由冲突 | 架构 | P0 | 1h |
+| 3 | 积分商城路由补全或冻结 | 产品 | P0 | 0.5h（冻结）/ 4h（实现） |
+| 4 | 出生日期合理性校验 | 安全 | P1 | 0.5h |
+| 5 | 拆分 main.rs God File | 架构 | P1 | 4h |
+| 6 | API 集成测试核心链路 | 测试 | P1 | 2-3 天 |
+| 7 | 添加 HSTS + CSP 加固 | 安全 | P1 | 2h |
+| 8 | 统一空状态/加载状态 | UX | P1 | 1 天 |
+| 9 | EventBus 支持 Redis Pub/Sub | 架构 | P2 | 2-3 天 |
+| 10 | 补充 OpenTelemetry 追踪 | DevOps | P2 | 2-3 天 |
+
+---
+
+## 8. Go/No-Go 建议
+
+### 8.1 评估结论
+
+| 条件 | 状态 |
+|------|------|
+| 核心医疗业务可用 | PASS — 患者/咨询/内容/预约/AI 通过率 75-100% |
+| 安全基线达标 | PASS — 认证/授权/加密/隔离/限流全部到位 |
+| 前端功能正常 | PASS — 8 页面手动验证通过 |
+| 无 CRITICAL 安全漏洞 | PASS — 安全验证全量通过 |
+| API 通过率 ≥ 95% | **FAIL** — Health 模块 63%（含未实现路由） |
+| CRITICAL 问题 ≤ 0 | **FAIL** — 2 个 CRITICAL（空标签名 500 + 路由冲突） |
+
+### 8.2 最终建议: **CONDITIONAL GO**
+
+**V1 测试版本可以有条件发布**，条件如下：
+
+1. **必须修复**（预计 2h）：
+   - 空标签名 500 → DTO 校验（0.5h）
+   - 媒体库路由冲突 → 调整注册顺序（1h）
+   - 积分商城 → 标记为冻结模块（0.5h）
+
+2. **发布后 1 周内修复**：
+   - 出生日期校验
+   - 随访记录 405
+   - 告警规则字段不匹配
+
+3. **下一迭代优先**：
+   - API 集成测试覆盖
+   - HSTS + CSP 加固
+   - main.rs 拆分
+
+### 8.3 风险提示
+
+- 积分商城功能不完整，如需上线则需额外 1-2 周实现
+- 测试覆盖率不足以支撑频繁发布，建议建立 CI/CD 质量门禁
+- 生产监控深度不足，上线后需密切关注异常指标

docs/qa/v1-release-e2e-comprehensive-test-report.md

@@ -0,0 +1,321 @@
+# HMS V1 测试版本 — 全面端到端链路测试报告
+
+> **测试日期**: 2026-05-20 | **分支**: feat/media-library-banner | **测试范围**: 后端 API + Web 前端 + 安全 + 输入校验 + 多专家评估
+
+---
+
+## 1. 执行摘要
+
+### 总体结论
+
+| 维度 | 结果 | 状态 |
+|------|------|------|
+| 后端 API（Health 模块） | 91 端点测试，57 通过，通过率 **63%** | NEEDS WORK |
+| 后端 API（AI/Dialysis/Plugin） | 66 端点测试，61 通过，通过率 **92.4%** | PASS |
+| Web 前端 | 8 页面手动验证，全部功能正常 | PASS |
+| 安全验证 | Headers / Rate Limiting / SQL Injection / XSS 全部通过 | PASS |
+| 输入校验 | 14 场景测试，10 通过，通过率 **71%** | NEEDS WORK |
+| 编译测试 | cargo check + cargo test + pnpm build 全部通过（修复后） | PASS |
+| 专家综合评估 | 5 专家平均 **6.7/10 (B)** | CONDITIONAL |
+
+### Go/No-Go 建议: **CONDITIONAL GO**（有条件通过）
+
+**通过条件：**
+1. 修复 2 个 CRITICAL 问题（空标签名 500 + 媒体库路由冲突）
+2. 修复 3 个 HIGH 问题（积分路由缺失 + 出生日校验 + 随访记录 405）
+3. 验证修复后无回归
+
+**说明：** 核心 API（患者/咨询/内容管理/预约）通过率 75-100%，安全基线扎实，前端功能正常。主要问题集中在积分商城路由缺失和输入校验遗漏，不影响核心医疗业务流程。
+
+---
+
+## 2. 测试范围与方法
+
+### 2.1 测试环境
+
+| 项目 | 值 |
+|------|-----|
+| 后端 | Axum 0.8 + SeaORM 1.1, PostgreSQL 16, Redis 7 |
+| 前端 | React 19 + Ant Design 6 + Vite 8 + TypeScript 6 |
+| 测试账号 | admin / doctor_test / nurse_test / health_manager_test / operator1 |
+| 后端地址 | http://localhost:3000/api/v1 |
+| 前端地址 | http://localhost:5174 |
+
+### 2.2 测试方法
+
+- **后端 API**: curl 逐端点请求，记录 HTTP 状态码和响应体
+- **Web 前端**: Chrome DevTools MCP 浏览器操作 + 页面功能验证
+- **安全验证**: HTTP Headers 检查 + 速率限制测试 + SQL 注入/XSS payload
+- **输入校验**: 空值/超长/特殊字符/无效枚举/边界值等 14 个场景
+- **专家评估**: 5 个并行 Agent 专家（产品/架构/安全/测试/UX）
+
+### 2.3 测试覆盖
+
+| 模块 | 端点数 | 测试覆盖 |
+|------|--------|----------|
+| erp-health | ~127 | 91 端点测试 |
+| erp-ai + erp-dialysis + erp-plugin | ~88 | 66 端点测试 |
+| erp-auth + erp-config + erp-workflow + erp-message | ~75 | 基础验证（登录/Token/权限） |
+| Web 前端 | 36 活跃路由 | 8 页面手动验证 |
+| **合计** | **~290** | **157 端点测试 + 8 页面验证** |
+
+---
+
+## 3. 后端 API 测试结果
+
+### 3.1 Health 模块（91 端点，57 通过，63%）
+
+#### 按子路由组通过率
+
+| 子路由组 | 测试数 | 通过数 | 通过率 | 状态 |
+|----------|--------|--------|--------|------|
+| 患者管理 | 11 | 10 | 91% | PASS |
+| 咨询管理 | 8 | 8 | 100% | PASS |
+| 内容管理 | 6 | 6 | 100% | PASS |
+| 公开端点 | 2 | 2 | 100% | PASS |
+| 预约排班 | 4 | 3 | 75% | PASS_WITH_ISSUES |
+| 告警系统 | 5 | 3 | 60% | NEEDS_WORK |
+| 健康数据 | 18 | 9 | 50% | NEEDS_WORK |
+| 随访管理 | 6 | 3 | 50% | NEEDS_WORK |
+| 护理管理 | 4 | 2 | 50% | NEEDS_WORK |
+| 积分商城 | 8 | 2 | 25% | FAIL |
+| 设备管理 | 4 | 1 | 25% | FAIL |
+| 媒体库/轮播图 | 4 | 0 | 0% | FAIL |
+| 统计报表（非 admin） | 11 | 8(路由) | 73% | PASS_WITH_ISSUES |
+
+#### 关键失败端点
+
+**CRITICAL:**
+
+| # | 端点 | 错误 | 根因 |
+|---|------|------|------|
+| C1 | `POST /health/patient-tags {"name":""}` | 500 Internal Server Error | DTO 缺少 `name` 字段 `validate(length(min=1))` |
+| C2 | `GET /health/media/folders` | 400 UUID parse error | 路由注册顺序：`/media/{id}` 先匹配，`folders` 被当 UUID |
+
+**HIGH:**
+
+| # | 端点 | 错误 | 说明 |
+|---|------|------|------|
+| H1 | `GET /health/points/rules` | 404 | 积分规则路由未注册 |
+| H2 | `GET /health/patients/{id}/points/account` | 404 | 积分账户路由缺失 |
+| H3 | `POST /health/follow-up-records` | 405 | 随访记录创建方法不允许 |
+| H4 | `POST /health/alert-rules` | 422 | `device_type` 字段缺失/不匹配 |
+| H5 | `GET /health/device-readings` | 404 | 设备读数路由未注册 |
+
+### 3.2 AI + Dialysis + Plugin 模块（66 端点，61 通过，92.4%）
+
+| 模块 | 测试数 | 通过数 | 通过率 |
+|------|--------|--------|--------|
+| erp-ai（chat/analysis/prompts/usage） | ~47 | ~44 | 93.6% |
+| erp-dialysis（记录/处方） | ~8 | ~7 | 87.5% |
+| erp-plugin（admin/data/market/registry） | ~33 | ~30 | 90.9% |
+| FHIR（OAuth Bearer） | ~14 | ~14 | 100% |
+
+**HIGH 问题（2 个）：**
+1. 插件 metrics 端点返回 500（内部统计查询异常）
+2. OAuth token 响应格式不一致（部分端点返回裸 JSON 而非 `ApiResponse` 包装）
+
+### 3.3 基础模块验证
+
+| 模块 | 验证项 | 结果 |
+|------|--------|------|
+| erp-auth | 登录/Token/刷新/登出 | PASS |
+| erp-auth | 速率限制（5次/min/IP） | PASS |
+| erp-auth | 角色权限隔离（403） | PASS |
+| erp-config | 字典/菜单/配置 | PASS（admin 账号验证） |
+| erp-workflow | 工作流定义/实例/任务 | PASS |
+| erp-message | 消息/模板/订阅 | PASS |
+
+---
+
+## 4. Web 前端验证结果
+
+### 4.1 页面功能验证（8 页面）
+
+| 页面 | 验证内容 | 结果 |
+|------|----------|------|
+| 登录页 | admin 登录 → JWT 获取 → 跳转工作台 | PASS |
+| 工作台 | 统计卡片/待办事项/快捷操作加载 | PASS |
+| 统计仪表盘 | 120 患者/6 预约/31% 随访/16 医生数据展示 | PASS（FE-C2 已修复） |
+| 患者管理 | 119 条列表 + 搜索 + 详情 + 创建 | PASS |
+| 预约管理 | 18 条列表 + 排班展示 | PASS |
+| AI 对话页 | ChatPage + AiSidebar + 会话持久化 | PASS |
+| 媒体库 | 文件列表 + 文件夹 + 上传 | PASS |
+| 用户管理 | 26 用户 + CRUD + 角色分配 | PASS（FE-C1 已修复） |
+
+### 4.2 已验证修复项
+
+| 原问题 | 状态 |
+|--------|------|
+| FE-C1: Admin 403 锁定 7 个系统管理页 | **已修复** — admin 可正常访问所有管理页面 |
+| FE-C2: 统计仪表盘全零 | **已修复** — 仪表盘显示真实统计数据 |
+| AuthButton TypeScript 错误 | **已修复** — AiAnalysisCard + VitalSignsTab 修复 |
+
+### 4.3 前端构建
+
+- `pnpm build`: PASS（修复 AuthButton 类型错误后）
+- antd vendor chunk 2.9MB（MEDIUM - 构建优化建议）
+
+---
+
+## 5. 安全验证结果
+
+### 5.1 安全响应头
+
+| Header | 值 | 状态 |
+|--------|-----|------|
+| X-Frame-Options | DENY | PASS |
+| X-Content-Type-Options | nosniff | PASS |
+| X-XSS-Protection | 1; mode=block | PASS |
+| Referrer-Policy | strict-origin-when-cross-origin | PASS |
+
+### 5.2 认证与授权
+
+| 检查项 | 结果 |
+|--------|------|
+| 未认证请求返回 401 | PASS |
+| 无效 Token 返回 401 | PASS |
+| 跨角色权限隔离（403） | PASS |
+| 乐观锁 version 检查 | PASS |
+| 多租户 tenant_id 过滤 | PASS |
+
+### 5.3 攻击防护
+
+| 攻击类型 | 测试方法 | 结果 |
+|----------|----------|------|
+| SQL 注入 | `search=' OR 1=1 --` | PASS — 返回 0 条，无数据泄露 |
+| XSS | `<script>alert(1)</script>` | PASS — 被当空值处理 |
+| 暴力破解 | 6 次快速登录 | PASS — 第 6 次返回 429 |
+| UUID 注入 | 非法 UUID 路径参数 | PASS — 返回 400 |
+
+### 5.4 安全评估结论
+
+安全基线扎实，无 CRITICAL/HIGH 安全问题。主要安全能力已到位：
+- JWT 认证 + RBAC 权限控制
+- 速率限制（IP 5/min + 账户锁定 + 用户 300/min）
+- SQL 参数化查询
+- PII AES-256-GCM 加密
+- 多租户双重隔离（应用层 + PostgreSQL RLS）
+
+---
+
+## 6. 输入校验深度测试
+
+### 6.1 测试结果（14 场景，10 通过，71%）
+
+| 场景 | 预期 | 实际 | 结果 |
+|------|------|------|------|
+| 空名称创建患者 | 400 | 400 "患者姓名不能为空" | PASS |
+| 空名称创建标签 | 400 | 500 Internal Server Error | **FAIL** |
+| 超长字符串 300 字符 | 400 | 400 "长度不能超过255个字符" | PASS |
+| XSS payload | 拒绝或过滤 | 400 "姓名不能为空" | PASS |
+| 无效 UUID 路径参数 | 400 | 400 UUID parse error | PASS |
+| SQL 注入 search | 200 安全 | 200 返回 0 条 | PASS |
+| 无认证请求 | 401 | 401 | PASS |
+| 无效 Token | 401 | 401 | PASS |
+| 空请求体 | 422 | 422 "missing field" | PASS |
+| 无效 gender 枚举 | 400 | 400 "不是有效值" | PASS |
+| 未来出生日期 2099 | 400 | 200 创建成功 | **FAIL** |
+| 超大 page_size=999999 | 限制/400 | 200 返回 100 条 | MEDIUM |
+| 负数 page=-1 | 400 | 200 | MEDIUM |
+| 登录速率限制 | 429 | 429 "账户已被临时锁定" | PASS |
+
+---
+
+## 7. 代码修复清单
+
+本次测试中发现并修复的编译问题：
+
+| # | 文件 | 问题 | 修复 |
+|---|------|------|------|
+| 1 | `crates/erp-server/src/main.rs:416` | tracing 宏类型推断失败 | 提取 `let count: usize = recovered.len();` |
+| 2 | `crates/erp-plugin/src/data_dto.rs` | `utoipa::ToSchema` derive 宏解析卡死 | 添加 `use utoipa::{IntoParams, ToSchema};` 并替换所有 inline 路径 |
+| 3 | `apps/web/src/components/ai/AiAnalysisCard.tsx` | AuthButton 不接受 Button props | Button 包裹在 AuthButton children 内 |
+| 4 | `apps/web/src/pages/health/components/VitalSignsTab.tsx` | AuthButton 不接受 Button props | 同上 |
+
+修复后验证：`cargo check` PASS / `cargo test` PASS / `pnpm build` PASS
+
+---
+
+## 8. 问题清单（按严重度排序）
+
+### CRITICAL（2 个）
+
+| ID | 模块 | 描述 | 影响 | 建议 |
+|----|------|------|------|------|
+| API-C1 | erp-health | `POST /health/patient-tags {"name":""}` 返回 500 | 空名称绕过校验导致服务端异常 | DTO 添加 `validate(length(min=1))` |
+| API-C2 | erp-health | `GET /health/media/folders` 返回 400 | `/media/{id}` 先匹配，folders 被当 UUID | 调整路由注册顺序 |
+
+### HIGH（7 个）
+
+| ID | 模块 | 描述 | 影响 |
+|----|------|------|------|
+| API-H1 | erp-health | 积分规则 `/health/points/rules` 返回 404 | 积分商城核心功能不可用 |
+| API-H2 | erp-health | 积分账户/签到/交易 3 个端点 404 | 积分系统不完整 |
+| API-H3 | erp-health | `POST /health/follow-up-records` 返回 405 | 随访记录无法创建 |
+| API-H4 | erp-health | `POST /health/alert-rules` 422 字段不匹配 | 告警规则无法创建 |
+| API-H5 | erp-health | `GET/POST /health/device-readings` 404 | 设备读数路由缺失 |
+| API-H6 | erp-health | 未来出生日期 2099 被接受 | 数据完整性风险 |
+| API-H7 | erp-plugin | 插件 metrics 端点 500 | 统计查询异常 |
+
+### MEDIUM（12 个）
+
+| ID | 模块 | 描述 |
+|----|------|------|
+| M1 | erp-health | `page_size=999999` 无上限保护 |
+| M2 | erp-health | 负数 page=-1 未校验 |
+| M3 | erp-health | XSS payload 被当空值处理（安全但语义不清） |
+| M4 | erp-health | `/health/medications` GET 返回 405（路由在子路径） |
+| M5 | erp-health | `/health/medication-reminders` GET 返回 405（需 patient_id） |
+| M6 | erp-health | `/health/points/products` POST 返回 405 |
+| M7 | erp-health | 统计端点 system-health/user-activity/modules 404 |
+| M8 | erp-health | `GET /health/patients/{id}/doctors` 返回 405 |
+| M9 | erp-health | `/health/vital-signs/trend` 参数名不匹配 |
+| M10 | erp-plugin | OAuth 响应格式不一致 |
+| M11 | web | antd vendor chunk 2.9MB 构建体积过大 |
+| M12 | erp-health | 多个 POST 端点 422 字段名与文档不一致 |
+
+---
+
+## 9. 风险评估矩阵
+
+| 风险 | 可能性 | 影响 | 风险等级 | 缓解措施 |
+|------|--------|------|----------|----------|
+| 积分商城功能缺失 | 高 | 中 | HIGH | 补全路由或标记为冻结模块 |
+| 空名称导致 500 错误 | 中 | 中 | HIGH | DTO 校验修复（1 行代码） |
+| 媒体库路由冲突 | 中 | 低 | MEDIUM | 调整路由注册顺序 |
+| 输入校验遗漏 | 中 | 中 | MEDIUM | 逐步补全 DTO Validate derive |
+| 大量请求导致性能问题 | 低 | 中 | LOW | 添加 page_size 上限 |
+| 前端构建体积影响加载 | 低 | 低 | LOW | 代码分割 + 懒加载优化 |
+
+---
+
+## 10. 结论与下一步
+
+### 10.1 核心结论
+
+HMS V1 测试版本在**核心医疗业务**（患者管理、咨询管理、预约排班、内容管理、AI 分析）方面表现稳定，API 通过率 75-100%，前端 8 个关键页面功能正常，安全基线通过全量验证。
+
+主要问题集中在：
+1. **积分商城模块**路由不完整（5 个 404），该模块可能尚未完全实现
+2. **输入校验**部分场景遗漏（空标签名 500、未来日期未拒绝）
+3. **媒体库路由冲突**导致 folders 端点不可用
+
+这些问题**不影响核心医疗业务流程**（患者建档 → 体征录入 → 医生查看 → 咨询回复 → 随访管理）。
+
+### 10.2 修复优先级
+
+| 优先级 | 问题 | 预估工作量 |
+|--------|------|-----------|
+| P0 | API-C1: 空标签名 500 | 0.5h |
+| P0 | API-C2: 媒体库路由冲突 | 1h |
+| P1 | API-H1~H2: 积分路由缺失 | 4h（如需实现）/ 0.5h（标记冻结） |
+| P1 | API-H6: 出生日期校验 | 0.5h |
+| P2 | API-H3~H5: 随访/告警/设备路由 | 2-4h |
+| P2 | M1~M2: 分页边界校验 | 1h |
+
+### 10.3 后续迭代建议
+
+1. **短期（1 周）**：修复 P0/P1 问题，达到 V1 测试版本发布标准
+2. **中期（2-4 周）**：补全积分商城路由、优化前端构建体积、添加 page_size 上限
+3. **长期（1-2 月）**：完善 E2E 自动化测试覆盖、补充性能基准测试、建立 CI/CD 质量门禁

wiki/architecture.md

@@ -203,6 +203,32 @@ impl ErpModule for AuthModule {
 - RLS 行级安全 — PostgreSQL Row Level Policy，中间件 SET `app.current_tenant_id`
 - Dead Letter — 失败事件自动写入 dead_letter_events 表
 
+### DTO 输入校验规范
+
+> **历史教训**: 2026-05-19 全系统 DTO 审计发现 44 处校验缺失（跨 6 个 crate），根因是 Update 结构体与 Create 结构体校验不对称。以下为强制规范。
+
+**DTO 编写铁律：**
+
+1. **所有请求结构体必须 `derive(Validate)`** — 包括 `Create*Req`、`Update*Req`、`Assign*Req`、查询参数等
+2. **Update 与 Create 校验对称** — `Create*Req` 有 `#[validate(length(...))]` 的字段，`Update*Req` 对应字段也必须有，不允许降级
+3. **枚举字段必须自定义校验** — `status`、`type`、`method`、`channel` 等有限集合字段，使用 `#[validate(custom(function = "..."))]` 限制合法值
+4. **Vec 字段必须检查非空** — `role_ids`、`permission_ids`、`scopes` 等用 `#[validate(length(min = 1))]`
+5. **密码字段加 max 限制** — `max = 128`，防止 bcrypt DoS
+6. **URL 字段必须防 SSRF** — 禁止 `localhost`/`127.0.0.1`/`0.0.0.0`，仅允许 `http://`/`https://` 协议
+7. **数值范围必须限定** — `rate_limit`、`timeout`、`token_lifetime` 等用 `#[validate(range(min, max))]`
+8. **handler 层必须调用 `validate()`** — 每个接收 `Json<T>` 的 handler 函数体内第一行必须 `req.validate().map_err(|e| AppError::Validation(e.to_string()))?`
+
+**校验清单（新增 DTO 时逐项确认）：**
+
+- [ ] `derive(Validate)` 已添加
+- [ ] 字符串字段有 `length(min, max)` 限制
+- [ ] 枚举字段有 `custom` 校验函数
+- [ ] 集合字段有 `length(min = 1)` 非空检查
+- [ ] 数值字段有 `range(min, max)` 范围检查
+- [ ] URL 字段有协议和 SSRF 校验
+- [ ] handler 层调用了 `.validate()`
+- [ ] dto.rs 文件底部有对应的单元测试
+
 ## 5. 代码逻辑
 
 ⚡ **不变量**: 模块间只通过 EventBus 和 trait 通信，无直接依赖
@@ -233,6 +259,7 @@ impl ErpModule for AuthModule {
 
 | 日期 | 变更 |
 |------|------|
+| 2026-05-19 | 新增 §4 DTO 输入校验规范：44 处校验缺失修复总结 + 强制铁律 + 新增 DTO 检查清单 |
 | 2026-05-01 | 审计数据更新：模块状态表刷新（772 测试 / 328 路由 / 50 权限码）、审计发现清单 |
 | 2026-04-26 | 从 CLAUDE.md 迁移：目录结构、模块开发规范（§5）、安全注意事项（§7） |
 | 2026-04-25 | 全面更新：6 模块已实现状态表、预约 CAS 决策、PII 加密不变量、健康模块集成 |

wiki/index.md

@@ -4,7 +4,7 @@
 
 ## 关键数字
 
-> 最后更新: 2026-05-19 | 数据截止: feat/media-library-banner 分支（AI 对话全链路修复完成）
+> 最后更新: 2026-05-19 | 数据截止: feat/media-library-banner 分支（DTO 安全校验修复完成）
 
 | 指标 | 值 |
 |------|-----|
@@ -102,6 +102,8 @@
 | AI 侧边栏/ChatPage 刷新丢失消息 | [[frontend]] ChatPage | 无后端消息加载 API | **已修复：** 新增 `GET /ai/chat/sessions/{id}/messages` + 前端切换时加载历史 |
 | AI 菜单缺失 / 客服入口不存在 | [[database]] 菜单迁移 | AI 客服菜单未配置 | **已修复：** 迁移 000155-000156 添加 AI 客服菜单 + 角色绑定 |
 | copilot 患者风险 500 | [[erp-ai]] risk_service | SQL 列名/表名与实际 schema 不匹配 | **已修复：** `vital_signs_daily.device_type/avg_val` + `lab_report`（单数）+ JSON 查询 |
+| DTO 校验缺失（Update 无 Validate） | [[architecture]] §4 DTO 校验规范 | handler 层未调 `.validate()` | **已修复：** 6 个 crate / 8 个文件 / 44 处缺失修复（erp-auth + erp-config + erp-workflow + erp-message + erp-plugin + erp-health/oauth） |
+| SSRF 通过 ServiceTaskConfig.url | [[architecture]] §4 DTO 校验规范 | 工作流 ServiceTask 可访问内网 | **已修复：** 禁止 localhost/127.0.0.1 + 仅 http/https + method 白名单 GET/POST |
 
 ## 模块导航