docs: T40 UI 审计报告 + wiki 更新 + Docker 配置

- T40 UI 审计计划和结果文档（docs/qa/）
- wiki 更新：miniprogram 设计系统合规审计记录 + index 关键数字更新
- 审计 V2 完整报告（docs/audits/v2/）
- 讨论记录文档（docs/discussions/）
- 设计规格和实施计划（docs/superpowers/）
- 角色测试计划和结果（docs/qa/role-test-*）
- Docker 生产部署配置

docs/discussions/2026-05-04-phase2-handoff.md

@@ -0,0 +1,244 @@
+# Phase 2 交接文档 — 患者体验（2026 年 8-9 月）
+
+> 日期: 2026-05-04 | 类型: 交接文档 | Phase: Phase 2
+
+## 背景
+
+Phase 0（基础加固）和 Phase 1（关怀引擎 MVP）已全部完成。Phase 2 的目标是将患者和家庭体验从"健康数据查看器"转变为"被关怀的体验"。
+
+## Phase 0 + Phase 1 完成状态
+
+### Phase 0（全部完成）
+- AI 自动分析管道修复（建议生成 + 事件发布）
+- `ai.analysis.requested` 事件消费连接
+- 建议状态生命周期
+- 4 个千行 service 文件拆分
+- 事件测试补全
+- 核心健康管理页面测试
+- 护士工作台 Phase 1
+
+### Phase 1（全部完成，8/8 项）
+| # | 功能 | 提交 |
+|---|------|------|
+| 1 | 每日关怀工作台（Plan B 工作流驱动） | 已完成 |
+| 2 | 护理计划（Care Plan）实体和服务层 | 已完成 |
+| 3 | 透析专用风险评分（KDIGO 规则） | 已完成 |
+| 4 | 班次管理与护士分配 | `7b17f94` |
+| 5 | BLE 网关后端接入端点（API Key + 批量上传） | `7e57565` |
+| 6 | "关怀已送达"通知管道 | 已完成 |
+| 7 | 透析会话工作流（BPMN 集成） | `0a9272b` |
+| 8 | 家庭成员健康代理（同意 + 查看） | `95fa09c` |
+
+---
+
+## Phase 2 任务清单
+
+### P2-1: 老年患者小程序重设计（年龄适配 UI）— XL
+
+**目标**: 65+ 患者可无障碍使用（大字体、高对比度、≤3 步操作）
+
+**当前状态**: 小程序 182 源文件 / 40+ 页面，使用 Taro 4.2 + React 18。无年龄适配设计。
+
+**实施方向**:
+1. 在小程序样式层增加 `--elderly-*` CSS 变量/token：
+   - 基础字号 18-22px（标准 14px）
+   - 触摸目标 ≥ 48px
+   - 对比度 7:1（WCAG AAA）
+   - 导航最多 4-5 项
+2. 新建 `pages/elderly/` 区块，着陆页设计：
+   - 温暖问候 + 护士照片名字
+   - "您的护理团队 X 小时前查看了您的健康数据，一切稳定"
+   - 一个大号"呼叫护士"按钮
+   - 用药提醒（大复选框）
+3. 简化导航：从当前 TabBar 5 项减少到 3-4 项
+4. 后端已有 `health.family-proxy` API 支持家庭成员查看健康摘要
+
+**关键文件**:
+- `apps/miniprogram/src/app.config.ts` — 路由和 TabBar 配置
+- `apps/miniprogram/src/styles/` — 全局样式
+- `apps/miniprogram/src/pages/` — 页面目录
+- 后端 API: `GET /health/family/patients/{id}/health-summary`
+
+**验收标准**: 65+ 患者可在 3 步内完成核心操作（查看今日关怀 / 确认用药 / 呼叫护士）
+
+---
+
+### P2-2: 透析专属健康教育内容管道 — M
+
+**目标**: 基于患者当前风险指标智能推送肾病教育内容
+
+**当前状态**: 已有完整 CMS（`erp-health` 文章模块：article/article_category/article_tag + 审核工作流 + 阅读统计）
+
+**实施方向**:
+1. 利用现有 CMS 策展透析患者专属内容库：
+   - "认识你的透析指标"
+   - "透析间期如何控制水分"
+   - "高磷食物避坑指南"
+   - "什么时候该联系护理团队"
+2. 基于患者 KDIGO 风险评分自动推送相关文章
+   - 血磷高风险 → 推送高磷食物指南
+   - 体重增长过快 → 推送水分控制指南
+   - Kt/V 不达标 → 推送透析充分性科普
+3. 后端新增"智能推送"服务：读取患者风险评分 → 匹配文章标签 → 创建推送记录
+
+**关键文件**:
+- `crates/erp-health/src/service/article_service.rs` — 已有文章 CRUD
+- `crates/erp-health/src/entity/article.rs` — 文章实体
+- `crates/erp-health/src/entity/article_tag.rs` — 标签实体
+- Phase 1 新增的 KDIGO 评分服务 — 风险评分来源
+- `crates/erp-health/src/service/ai_action_dispatcher.rs` — 可扩展推送逻辑
+
+**验收标准**: 高风险透析患者自动收到与当前风险相关的教育文章
+
+---
+
+### P2-3: BLE 网关试点部署（10 位患者） — L
+
+**目标**: 10 位透析患者居家使用 BLE 网关，体征数据自动流入系统
+
+**当前状态**: 后端 BLE 网关接入已完成（Phase 1 #5）：
+- `ble_gateways` 表 + `gateway_patient_bindings` 表
+- API Key SHA-256 认证中间件
+- 批量上传端点 `POST /health/gateway/upload`（多患者批量）
+- 心跳端点 `POST /health/gateway/heartbeat`
+- 复用 `device_reading_service::batch_create_readings` 管道
+- 迁移 `m20260505_000113_create_ble_gateways.rs`
+
+**剩余工作**:
+1. 采购/选型商用 BLE 网关（如 Teltonika、Quectel）
+2. 网关固件配置：连接 BLE 设备（血压计/血糖仪/体重秤）→ HTTPS POST 到 HMS
+3. 10 位患者试点部署 + 数据验证
+4. 前端管理页面（网关状态监控，已有后端 CRUD）
+
+**关键文件**:
+- `crates/erp-health/src/service/ble_gateway_service.rs` — 网关管理 + 上传处理
+- `crates/erp-health/src/gateway_auth.rs` — API Key 认证
+- `crates/erp-health/src/dto/ble_gateway_dto.rs` — GatewayUploadReq（多患者批量格式）
+- `crates/erp-server/src/main.rs` — 网关路由注册（gateway_auth 中间件层）
+
+**验收标准**: 10 位患者居家体征数据每日自动上传，网关在线率 > 95%
+
+---
+
+### P2-4: 多 Provider AI + 成本感知路由 — M
+
+**目标**: 简单分析走本地规则，复杂分析走 LLM，Provider 不可用时自动回退
+
+**当前状态**: 仅 Claude 单 Provider，`LocalRulesEngine` 已存在但未集成到路由层
+
+**实施方向**:
+1. 扩展 `AiConfig` 使用当前死字段（model/max_tokens/temperature/cache_ttl/rate_limit）
+2. 实现路由策略：
+   - 阈值检查 → 本地规则引擎（零成本）
+   - 趋势解读/化验单分析 → Claude（高成本）
+   - Provider 不可用 → 回退本地规则 + 标记"降级分析"
+3. 添加 token 用量追踪（每次分析记录 input_tokens/output_tokens/cost_usd）
+4. 缓存生效：`find_cached` 已存在但从未被调用，接入分析管道
+
+**关键文件**:
+- `crates/erp-ai/src/service/auto_analysis.rs` — 自动分析批处理
+- `crates/erp-ai/src/service/local_rules_engine.rs` — 本地规则引擎
+- `crates/erp-ai/src/entity/ai_config.rs` — AI 配置实体（有死字段待激活）
+- `crates/erp-ai/src/entity/ai_suggestion.rs` — 建议实体（Phase 0 新增）
+- `crates/erp-ai/src/module.rs` — 模块注册
+
+**验收标准**: Provider 不可用时系统自动降级到本地规则，用户无感知中断
+
+---
+
+### P2-5: 关怀结果测量（干预前后对比） — M
+
+**目标**: 干预后 7/14/30 天体征对比可量化
+
+**当前状态**: Phase 1 已有 `care_plan_outcomes` 表（metric, baseline, target, current, measured_at）
+
+**实施方向**:
+1. 扩展 `care_plan_outcomes` 服务：自动从 `vital_signs` / `device_readings` 聚合测量值
+2. 实现干预前后对比 API：
+   - 输入：care_plan_item_id + 干预日期
+   - 输出：baseline（干预前 7 天均值）vs current（干预后 7/14/30 天均值）
+3. 前端趋势图展示干预效果
+4. 接入事件流：`care.action.performed` 事件触发测量开始
+
+**关键文件**:
+- `crates/erp-health/src/entity/care_plan_outcome.rs` — 预后测量实体
+- `crates/erp-health/src/service/care_plan_service.rs` — 护理计划服务
+- `crates/erp-health/src/service/vital_signs_daily_service.rs` — 日聚合服务
+- `crates/erp-health/src/service/trend_service.rs` — 趋势分析服务
+
+**验收标准**: 护士可在护理计划详情中查看干预前后的体征对比图表
+
+---
+
+### P2-6: 读副本 + 分区用于分析查询 — M
+
+**目标**: PostgreSQL 按月分区 `device_readings`，添加读副本连接用于分析查询
+
+**实施方向**:
+1. `device_readings` 表按月分区（当前 ~100万行/年，BLE 部署后快速增长）
+2. SeaORM 配置读副本连接（`DatabaseConnection` 支持多连接）
+3. 分析查询（趋势/统计/FHIR）路由到读副本
+4. 超过 2 年的读数归档冷存储
+
+**关键文件**:
+- `crates/erp-server/migration/src/` — 新增分区迁移
+- `crates/erp-health/src/state.rs` — HealthState 可扩展为双连接
+- `crates/erp-health/src/service/stats_service.rs` — 统计查询
+- `crates/erp-health/src/service/trend_service.rs` — 趋势查询
+
+---
+
+### P2-7: 机构运营仪表盘 — L
+
+**目标**: 管理层可查看关怀质量指标
+
+**当前状态**: 已有基础统计端点（`/health/admin/statistics/dashboard`、`personal-stats`、`system-health`）
+
+**实施方向**:
+1. 扩展统计 API：
+   - 关怀动作完成率（护士执行 / AI 建议）
+   - 患者留存率（月度）
+   - AI 建议准确率（护士采纳 / AI 总建议）
+   - 平均关怀响应时间（AI 发现风险 → 护士执行关怀）
+   - 北极星指标：每位患者每周收到的关怀动作数
+2. 前端仪表盘页面（Ant Design Charts）
+3. 数据来源：action_inbox + ai_suggestion + care_plan + 告警记录
+
+**关键文件**:
+- `crates/erp-health/src/service/stats_service.rs` — 已有统计服务
+- `crates/erp-health/src/handler/stats_handler.rs` — 已有统计 Handler
+- `apps/web/src/pages/` — 前端页面
+
+---
+
+## 实施建议
+
+### 优先顺序
+
+1. **P2-4 多 Provider AI**（M）— 降级能力是后续所有 AI 相关工作的基础
+2. **P2-5 关怀结果测量**（M）— 需要积累数据，越早启动越好
+3. **P2-2 透析教育内容**（M）— 后端改动小，可快速交付
+4. **P2-3 BLE 网关试点**（L）— 需要硬件采购，后端已就绪
+5. **P2-1 老年患者 UI**（XL）— 工作量最大，但依赖后端 API 已完成
+6. **P2-6 读副本+分区**（M）— 数据量增长后才有必要
+7. **P2-7 机构仪表盘**（L）— 需要前面各项数据积累
+
+### 技术注意事项
+
+1. **星型依赖架构不变** — 所有 crate 仅依赖 erp-core，跨模块走 EventBus
+2. **迁移编号从 `m20260505_000116` 开始** — 当前最后迁移是 `000115_family_member_health_proxy`
+3. **Handler 模式** — `State(state): State<HealthState>`, `Extension(ctx): Extension<TenantContext>`, `require_permission(&ctx, "health.xxx.list")?`, 返回 `Result<Json<ApiResponse<T>>, AppError>`
+4. **ctx.user_id 是 Uuid 不是 Option** — 直接使用，不需要 `ok_or_else`
+5. **前端小程序在 `apps/miniprogram/`** — Taro 4.2 + React 18
+6. **前端 Web 在 `apps/web/`** — React 19 + Ant Design + Vite
+7. **编译命令**: `cargo check`（编译检查）/ `cargo test -p erp-health`（单 crate 测试）/ `cargo test --workspace`（全量测试）
+8. **数据库连接信息**: 见 `wiki/infrastructure.md` §2
+
+### Phase 2 验收标准（总体）
+
+| 指标 | 目标 |
+|------|------|
+| 10 位患者 BLE 网关试点 | 居家体征数据自动流入系统 |
+| 老年患者 UI | 65+ 患者可无障碍使用（大字体、高对比度、≤3 步操作） |
+| 关怀结果测量 | 干预后 7/14/30 天体征对比可量化 |
+| 机构仪表盘 | 管理层可查看关怀运营指标 |

docs/discussions/2026-05-04-product-vision-brainstorming.md

@@ -0,0 +1,106 @@
+# HMS 产品愿景与方向发散式讨论
+
+> 日期: 2026-05-04 | 参与者: 产品负责人 + AI 协作
+
+## 背景
+
+系统已完成主体功能开发（18 crate / 59 小程序页面 / ~210 API 路由 / 48 health 实体），审计完成度 83%，P0/P1 大部分已修复。在准备交付第一个客户（血液透析中心）之前，进行产品方向和愿景的发散式讨论。
+
+## 讨论要点
+
+### 1. 产品定位演进
+
+**初始定位（CLAUDE.md）**: 面向体检中心/医疗机构的综合健康管理平台
+
+**讨论后明确**:
+- 以**自有体检中心为流量入口**，体检报告作为健康管理的起点
+- 体检后根据客户情况**分流**到：健康管理（亚健康）、慢病管理、综合医院、专科医院（眼科、牙科、月子中心等）
+- 形成完整的**健康管理闭环**（体检 → 分流 → 管理 → 复查 → 回到体检）
+- HMS 作为患者端门户（小程序为主），是患者与医疗机构之间的枢纽
+
+**核心定位**: HMS 是**AI 驱动的主动关怀引擎**，不是传统的医疗管理系统。
+
+### 2. 商业模型
+
+收入来源（已确认）:
+- **管理服务订阅费**: 患者为长期健康管理服务付费（月费/年费）
+- **转介佣金**: 向合作专科机构导流，按成交或人次收取佣金
+- **自有医疗机构收入**: 自有专科机构（如透析中心）的医疗服务收入
+
+商业飞轮:
+```
+体检中心（自有，流量入口）
+  → 体检报告 + 风险评估
+  → HMS 患者端小程序（转化 + 留存）
+    ├── 自有专科机构 → 医疗服务收入
+    ├── 合作专科机构 → 转介佣金
+    └── 患者管理服务订阅 → 订阅收入
+  → 定期复查 → 回到体检中心（闭环）
+```
+
+### 3. 第一个客户：血液透析中心枢纽系统
+
+#### 3.1 核心价值主张
+
+**"增进已有以及潜在患者的羁绊，提高他们对血透机构的信任度"**
+
+不是让患者自己管自己，而是:
+1. 系统被动采集健康数据（BLE + 透析时采集 + 外部系统）
+2. AI 持续分析所有患者数据
+3. 自动生成"今日关怀清单"给护士
+4. 护士根据 AI 建议主动关怀患者
+5. 患者感受到"时时刻刻有人在关心我" → 信任
+
+#### 3.2 用户群体
+
+四端全覆盖:
+- **老年患者本人**（60+）: 极简界面，关怀推送，健康科普
+- **患者子女**: 监控父母健康数据，异常告警，与医护沟通
+- **医护端**: 每日关怀工作台，患者管理，数据录入
+- **机构管理端**: 统计看板，内容管理，运营管理
+
+#### 3.3 数据策略
+
+**被动采集为主，不依赖患者手动录入**:
+- BLE 设备自动采集（血压计、血糖仪、体重秤等）
+- 透析时机构采集（体重、血压、超滤量、化验指标等）
+- 外部系统对接（HIS/LIS，通过已实现的 FHIR R4 + OAuth）
+
+### 4. 部署模式
+
+**私有化部署产品，卖给不同机构**:
+- 每个企业客户一套独立部署
+- 企业下属多个机构（如 A 企业有 B/C/D 血透中心）
+- 系统内多租户隔离（tenant_id），企业一套系统多机构使用
+- 与现有架构设计一致
+
+### 5. 对现有系统的影响
+
+| 已有能力 | 需要演进的方向 |
+|---------|--------------|
+| 告警系统（阈值触发） | AI 趋势分析（连续变化识别，不只是阈值） |
+| Action Inbox（工作流收件箱） | 每日关怀清单（护士专用工作台） |
+| 随访任务（手动创建） | AI 自动生成的关怀建议 + 话术推荐 |
+| AI 分析（被动触发 SSE） | AI 每日批处理（主动关怀引擎） |
+| 微信订阅消息（业务提醒） | "护士今天关注了您的健康"关怀类通知 |
+| BLE 设备适配（3 类） | 更丰富的家庭设备生态（体重秤等） |
+| FHIR R4 + OAuth（已实现） | HIS/LIS 数据对接管道 |
+
+## 结论 / 待定
+
+### 达成共识
+
+1. **HMS 的灵魂是"AI 驱动的主动关怀引擎"** — 护士从"凭经验记忆关心谁"变成"AI 告诉我今天该关心谁"
+2. **第一个客户的核心场景是透析中心的信任建设** — 不是功能堆砌，而是让患者感受到被关注
+3. **数据采集走被动路线** — BLE + 机构采集 + 外部对接，不依赖老年患者手动录入
+4. **私有化部署 + 多租户** — 与现有架构一致，每个企业一套系统
+5. **商业飞轮以体检中心为入口** — 自有流量 + 分流转化 + 持续管理
+
+### 待后续探索
+
+1. **AI 关怀引擎的具体分析模型** — 透析患者的关键风险指标和分析逻辑
+2. **护士每日关怀工作台的 UX 设计** — 什么信息、怎么展示、怎么操作
+3. **体检→管理转化路径设计** — 体检后如何引导患者进入健康管理
+4. **定价策略** — 私有化部署的定价模式
+5. **竞争格局** — 透析管理领域的主要竞品和差异化策略
+6. **BLE 设备选型与合作** — 面向老年患者的家庭设备方案

docs/discussions/2026-05-05-foundation-solidification.md

@@ -0,0 +1,53 @@
+# 夯实基础方向讨论
+
+> 日期: 2026-05-05 | 参与者: 产品负责人 + 多专家组
+
+## 背景
+
+系统已完成主体功能开发（18 crate / 328 路由 / 46 health 实体），但存在安全漏洞、功能膨胀、UX 不统一三个结构性问题。在继续开发新功能之前，需要夯实基础。
+
+## 讨论要点
+
+### 1. 核心痛点确认
+
+用户明确四大痛点：安全漏洞、UX 不统一、测试空白、功能半成品。补充观点：小程序功能过度开发，老年用户可能不需要。
+
+### 2. 小程序定位
+
+确认多角色混合模式：老年患者大字版、家属标准版、医护专业版，分层设计。
+
+### 3. 完成标准
+
+选择"精简收撤"策略：先做安全修复和核心流程打磨，不成熟的模块先冻结。
+
+### 4. 实施策略
+
+选择方案 A"安全优先逐层推进"：安全清零 → 冻结模块 → 设计系统 → 核心打磨 → 小程序精简。
+
+### 5. 安全审查（多专家组）
+
+三位安全专家并行审查（应用安全 + 数据/多租户 + 前端/基础设施），发现：
+- CRITICAL 5 个：FHIR 越权、AI 队列绕过隔离、.env.bak 泄露、Docker 硬编码密码
+- HIGH 10 个：审计日志泄露密文、Token 无租户校验、JWT localStorage、Prompt Injection 等
+- MEDIUM 8 个、LOW 5 个
+- 积极发现：PII 加密体系、RLS 双层隔离、Argon2 密码哈希等基础架构扎实
+
+### 6. 功能价值评估（多专家组）
+
+产品经理 + 医疗主任 + UX 研究员三位专家评估。关键纠偏：
+- HMS 是综合健康管理平台，不是血透管理系统
+- 透析只是业务子域之一，不应作为核心定位
+- 用户确认冻结 7 个模块：护理计划、班次管理、家庭代理、药物记录、透析管理、医生排班、预约管理
+
+### 7. 最终功能筛选
+
+保留并完善 12 个功能域：患者管理、健康数据、告警系统、行动收件箱、AI 分析、随访管理、咨询管理、内容管理、积分商城、线下活动、统计仪表盘、设备与数据采集。
+
+## 结论
+
+制定 5-Phase 夯实基础计划，总工期 6-8 周：
+1. 安全清零（2-3 周）
+2. 冻结推迟模块（2-3 天）
+3. 设计系统统一（1 周）
+4. 核心流程打磨（1-2 周）
+5. 小程序精简与分层（2 周）

docs/discussions/2026-05-06-plugin-system-evolution.md

@@ -0,0 +1,74 @@
+# 插件系统定位讨论
+
+> 日期: 2026-05-06 | 参与者: 产品负责人 + AI 协作
+> 上下文: 夯实基础讨论中引申出的架构问题
+
+## 背景
+
+在讨论"冻结推迟模块"策略时，发现一个根本性问题：如果插件系统足够成熟，冻结功能 = 卸载插件，无需代码改动。当前 7 个模块需要通过菜单迁移和路由守卫来"冻结"，这本质上是架构不够灵活的症状。
+
+## 战略方向
+
+**通用基座 + 行业插件。** 一套底座代码维护，不同行业通过不同插件覆盖。医疗只是第一个行业，未来会有其他行业。
+
+## 核心结论
+
+**交付质量第一，插件化是理想状态。**
+
+- 插件化是长期战略方向，但不是当前优先级
+- 当插件开发能提供与原生同等的性能和体验时，才选择插件
+- 当前阶段：用原生开发保证医疗功能的交付质量，同时积累"插件系统还缺什么"的实际数据
+
+## 当初选择原生开发的原因及现状
+
+| 原始限制 | 现在还是硬墙？ | 判断 |
+|---------|--------------|------|
+| JSONB 动态存储，不够强类型 | Generated Column 有类型约束，但 CHECK/FK/NOT NULL 仍缺失 | 半解决，医疗数据仍有风险 |
+| 无自定义 API | 仍无，模板 API 覆盖不了趋势分析等 | ❌ 硬墙 |
+| 无文件上传 | 仍无 | ❌ 硬墙 |
+| 沙箱限制（加密、AI、外部调用） | 仍无 | ❌ 硬墙 |
+| 实体上限 20 个 | 软限制，可调 | ✅ 已解决 |
+
+**结论：医疗核心功能继续用原生开发是正确的选择。** 插件系统尚未准备好承载复杂医疗业务。
+
+## 插件系统当前能力
+
+11 个 Host API（全部实现）：CRUD + 事件 + 权限 + 多租户 + 配置 + 编号 + 日志
+
+前端 7 种页面类型：crud, tree, tabs, graph, dashboard, kanban, detail
+
+5 个已有插件：assessment, CRM, inventory, freelance, itops
+
+## 插件系统 4 面硬墙及拆除评估
+
+| 硬墙 | 工期 | 拆除方案 | 解锁能力 |
+|------|------|---------|---------|
+| 无自定义 API | 1-2 周 | `register-route` Host API，插件声明路由+handler，宿主注册到 Axum router | 趋势分析、报表、非 CRUD 端点 |
+| 无文件上传 | 1 周 | `file-upload/download` Host API，宿主负责存储（本地/S3），返回文件 ID | 化验单、体检报告、头像 |
+| 沙箱限制 | 2-3 周 | `encrypt-field` / `ai-analyze` / `http-request` 三个 Host API | 加密、AI 集成、外部系统对接 |
+| 类型约束不足 | 1 周 | plugin.toml 增加 `required` / `constraints` / `ref_entity`，建表时生成 CHECK/NOT NULL/FK | 医疗级数据完整性 |
+
+**合计：5-7 周**
+
+### 各硬墙关键难点
+
+- **自定义 API** — WASM 入参出参通过线性内存传递有开销；SSE 流式需宿主代理；路由冲突检测
+- **文件上传** — 大文件需分块传输（WASM 线性内存有限）；文件与实体关联；权限控制
+- **沙箱扩展** — `http-request` 需域名白名单防 SSRF；`ai-analyze` 需抽象多 provider；加密密钥插件不应接触 KEK
+- **类型约束** — Generated Column 加 NOT NULL 后历史数据需补值；跨插件 FK 需特殊处理；约束变更迁移策略
+
+## 投资时机
+
+**当前决策：等医疗行业功能稳定后再投入。**
+
+触发条件（满足任一即可启动）：
+- 第二个行业确定要对接
+- 医疗功能已稳定交付，团队有余力投入基础设施建设
+- 特定能力（如文件上传）成为多个客户的共同痛点
+
+## 行动路径
+
+1. **现在** — 核心医疗功能继续原生开发，保证交付质量
+2. **同时** — 在原生开发中记录"哪些需求插件系统无法满足"
+3. **医疗功能稳定后** — 按触发条件评估是否启动硬墙拆除
+4. **最终** — 插件能力足够时，新行业直接用插件开发，无需维护多套系统

docs/discussions/2026-05-07-expert-brainstorm-session.md

@@ -0,0 +1,198 @@
+# HMS 多专家组头脑风暴 — 系统成熟度评审
+
+> 日期: 2026-05-07 | 数据截止: commit 786f57c | 参与者: 架构/安全/质量/产品/运维 五位虚拟专家
+> 关联: [三维度分析主文档](2026-05-07-three-dimension-analysis.md)
+
+## 背景
+
+基于三维度深度分析（后端 579 Rust 文件 / 前端 283 Web + 118 小程序 / 文档 47 规格 + 49 计划），召集五位虚拟专家从不同视角对 HMS 系统进行独立评审。每位专家给出评分、优劣势分析和"如果只能做一件事"的建议。
+
+---
+
+## 专家 A：架构专家
+
+**评分：7.5 / 10（B+）**
+
+### Top 3 优势
+
+1. **模块边界设计优秀** — 18 个 crate 间零直接业务依赖，ErpModule trait 统一生命周期管理（注册/启动/关闭/健康检查），天然支持未来微服务拆分。这是教科书级的模块化单体架构。
+2. **事件驱动架构成熟** — 31 个事件类型 + 23 个幂等消费者 + PostgreSQL Outbox + LISTEN/NOTIFY + 死信队列，保证了事件不丢失、不重复处理。
+3. **多租户从第一天内置** — `tenant_id` 列过滤 + JWT 中间件注入 + PostgreSQL RLS 策略三层纵深，非事后补丁。
+
+### Top 3 风险
+
+1. **erp-health 巨石模块失控** — 179 文件 / 35,750 行，占全部代码 38%。搭载 12 个业务子域，4 个 service 文件超过 1,000 行。如果继续堆叠功能，维护成本将指数级增长。
+2. **事件系统治理不足** — 事件类型从初始设计到现在持续膨胀，但缺乏版本管理、schema 注册、消费者健康监控。care_plan 等模块的事件存在悬空消费者。
+3. **冻结策略增加架构复杂度** — 7 个模块冻结但代码仍存在，路由仍注册，数据库表仍占用。每次查询、权限检查、菜单渲染都需要考虑"是否冻结"逻辑。
+
+### "如果只能做一件事"
+
+将 erp-health 按业务子域拆分为 3-4 个 crate（patient-core、health-data、appointment-scheduling、care-management），先从最大的 service 文件开始拆分。
+
+---
+
+## 专家 B：安全专家
+
+**评分：7.0 / 10（B）**
+
+### Top 3 优势
+
+1. **PII 加密体系完善** — AES-256-GCM 加密 + KEK/DEK 分层密钥管理 + HMAC 盲索引搜索，949 行 patient_service 全链路加密。在同类医疗 SaaS 中属于领先水平。
+2. **审计响应速度快** — V1 的 2 个 CRITICAL 和 V2 的 CRITICAL（SQL 注入、FHIR 越权）均已快速修复。
+3. **多租户隔离纵深防御** — JWT 中间件注入 → SeaORM 自动过滤 → PostgreSQL RLS 策略三层隔离。
+
+### Top 3 风险
+
+1. **安全漏洞绕过代码审查** — V2 仍发现 SQL 注入（`format!` 拼接 SQL）和 FHIR 越权（`allowed_patient_ids` 未强制执行）。CRITICAL 级别漏洞不应在事后审计才发现，说明 code review 流程存在安全盲区。
+2. **安全测试套件缺失** — 772 个后端测试中没有专门的安全测试。SQL 注入 fuzzing、多租户隔离破坏、FHIR 访问控制等均无系统性测试。当前是"发现一个修一个"的被动模式。
+3. **514 个 unwrap() 调用** — erp-plugin 113 个、erp-ai 77 个。生产环境中 panic 意味着服务中断，医疗系统的服务中断可能影响患者及时获取告警。
+
+### "如果只能做一件事"
+
+建立安全测试套件（`crates/erp-security-tests/`），包含 SQL 注入 fuzzing、多租户隔离破坏测试、FHIR 访问控制测试、PII 加密边界测试。每个安全修复必须附带回归测试。
+
+---
+
+## 专家 C：质量专家
+
+**评分：6.0 / 10（C+）**
+
+### Top 3 优势
+
+1. **后端测试基础扎实** — 772 个测试函数（611 单元 + 153 集成 + 8 多模块），97.5% 通过率。erp-health 的 303 个测试覆盖了完整业务链路。
+2. **CI/CD 双平台** — GitHub Actions + Gitea Actions 双保险，覆盖编译/测试/clippy/fmt/TypeScript/安全审计。
+3. **Web 测试基础设施完善** — MSW mock + 测试工厂模式 + Page Object + Playwright E2E，质量工具链齐全。
+
+### Top 3 风险
+
+1. **前端/小程序测试覆盖极差** — Web 283 文件对 62 测试（1:4.5），小程序 118 文件对 4 测试（1:30）。小程序几乎无测试覆盖，任何改动都是高风险回归。
+2. **pre-commit hooks 缺失** — ESLint 配置了但无本地强制执行，代码可以不经检查就提交。514 个 unwrap() 和硬编码中文就是明证。
+3. **代码质量债务累积** — 514 个 unwrap()、TypeScript `any` 类型残留（Web 10 / 小程序 28）、前端文本全量硬编码中文无国际化准备。
+
+### "如果只能做一件事"
+
+配置 pre-commit hooks（husky + lint-staged），每次提交前自动运行 cargo fmt/clippy + eslint + vitest --related。这是成本最低、收益最高的质量门禁。
+
+---
+
+## 专家 D：产品专家
+
+**评分：6.5 / 10（B-）**
+
+### Top 3 优势
+
+1. **医疗业务功能覆盖全面** — 12 个活跃功能域覆盖患者全生命周期：建档 → 体征 → 预约 → 随访 → 咨询 → AI 分析 → 告警 → 积分激励 → 内容教育。
+2. **多角色工作台设计** — 5 角色定制化工作台（admin/doctor/nurse/health_manager/operator），独立仪表盘和操作流程，面向 B 端医疗市场的正确策略。
+3. **双端覆盖** — Web 管理端覆盖医护管理场景，小程序覆盖患者和医护移动端。BLE 设备集成为未来 IoT 场景打下基础。
+
+### Top 3 风险
+
+1. **7 个冻结模块造成产品残缺感** — 护理计划、班次管理、透析管理等在 UI 有入口但被守卫拦截，用户会困惑"为什么存在但不能用"。
+2. **AI 分析无前端入口** — 4 个 SSE 分析端点完整实现但无 UI 触发入口。AI 智能分析是核心差异化卖点，但用户无法使用。
+3. **国际化完全缺失** — 所有前端文本硬编码中文，限制市场范围。虽然当前目标是国内体检中心，但中长期多语言是刚需。
+
+### "如果只能做一件事"
+
+补全 AI 分析前端 UI 入口。后端 4 个 SSE 端点已完整实现（缓存/队列/预校验），只需前端接入层 + 结果展示页。完成后核心差异化功能完整呈现给用户。
+
+---
+
+## 专家 E：运维专家
+
+**评分：5.0 / 10（C）**
+
+### Top 3 优势
+
+1. **Docker Compose 配置存在** — PostgreSQL 16 + Redis 7 容器化配置完整，带健康检查和资源限制。
+2. **一键启动脚本** — dev.ps1 管理前后端生命周期，自动清理端口残留进程，开发者体验良好。
+3. **配置外部化到位** — 敏感配置通过 `ERP__` 环境变量覆盖 TOML，8 个必设变量标记为 `__MUST_SET_VIA_ENV__`。
+
+### Top 3 风险
+
+1. **零生产部署方案** — Docker 仅覆盖数据库层，无应用镜像（Rust 后端 + React 前端）。无 Kubernetes/Docker Swarm 配置。692 次提交、85% 完成度，但无法部署到任何服务器。
+2. **可观测性几乎为零** — 无 Prometheus metrics 端点、无 Grafana 仪表盘、无分布式追踪、无结构化日志聚合。医疗系统的告警延迟、AI 响应时间、预约并发冲突都需要实时监控。
+3. **根目录污染严重** — 日志文件、测试令牌、截图、OCR 数据（3.4MB）、Python 遗留脚本散落在根目录，反映运维规范缺失。
+
+### "如果只能做一件事"
+
+创建生产级 Dockerfile（多阶段构建：Rust 编译 → 精简运行时镜像 + Nginx 托管 React 静态文件），配合 docker-compose.production.yml。从"能跑"到"能部署"的关键一步。
+
+---
+
+## 综合评审
+
+### 评分雷达
+
+| 维度 | 评分 | 等级 |
+|------|------|------|
+| 架构 | 7.5 | B+ |
+| 安全 | 7.0 | B |
+| 产品 | 6.5 | B- |
+| 质量 | 6.0 | C+ |
+| 运维 | 5.0 | C |
+| **综合** | **6.4** | **B-** |
+
+### 风险矩阵
+
+| 风险 | 概率 | 影响 | 等级 | 缓解措施 |
+|------|------|------|------|---------|
+| 无生产部署能力 | 高 | 阻塞 | **CRITICAL** | Dockerfile + 部署文档 |
+| 安全漏洞绕过 code review | 高 | 高 | **HIGH** | 安全测试套件 + review checklist |
+| erp-health 维护失控 | 中 | 高 | **HIGH** | 子域拆分 |
+| 小程序回归风险 | 高 | 中 | **HIGH** | 测试框架搭建 |
+| 事件系统治理缺失 | 中 | 中 | **MEDIUM** | 事件注册表 + 版本化 |
+| 文档过时降低效率 | 高 | 低 | **MEDIUM** | wiki 数字刷新 |
+
+### 优先级行动清单
+
+**P0 — 止血（本周）：**
+
+| 行动 | 领域 | 工作量 | 预期收益 |
+|------|------|--------|---------|
+| 生产级 Dockerfile | 运维 | 8h | 从"能跑"到"能部署" |
+| pre-commit hooks | 质量 | 4h | 最低成本质量门禁 |
+| AI 分析前端 UI | 产品 | 16h | 核心差异化功能完整呈现 |
+
+**P1 — 加固（两周内）：**
+
+| 行动 | 领域 | 工作量 | 预期收益 |
+|------|------|--------|---------|
+| 安全测试套件 | 安全 | 24h | 从被动修复到主动防御 |
+| erp-health 子域拆分 Phase 1 | 架构 | 40h | 控制巨石模块膨胀 |
+| 可观测性基础设施 | 运维 | 16h | metrics 端点 + 结构化日志 |
+
+**P2 — 提升（一个月内）：**
+
+| 行动 | 领域 | 工作量 | 预期收益 |
+|------|------|--------|---------|
+| 小程序测试框架 | 质量 | 16h | 消除 1:30 的回归风险 |
+| 事件注册表与版本化 | 架构 | 16h | 事件治理体系化 |
+| 冻结模块 UI 优化 | 产品 | 8h | 消除产品残缺感 |
+| 根目录清理 | 运维 | 4h | 基础卫生 |
+
+### 路线图建议
+
+**Phase 0：部署就绪（2 周）**
+- 生产级 Dockerfile + docker-compose.production.yml
+- Nginx 反向代理 + 环境变量模板
+- 基本 Prometheus metrics 端点
+
+**Phase 1：质量门禁（2 周）**
+- pre-commit hooks 配置
+- 安全测试套件建立
+- 千行 service 文件拆分
+- P0 文档更新
+
+**Phase 2：产品闭环（4 周）**
+- AI 分析前端 UI 补全
+- 工作台 v2 优化（AI 洞察面板）
+- 冻结模块 UI 优雅处理
+- 前端测试覆盖率提升到 50%+
+
+---
+
+## 结论
+
+HMS 系统在**架构设计和业务建模**上表现出色（B+），但在**运维能力和测试覆盖**上存在明显短板（C/C+）。项目功能完整度已达 85%，但生产就绪度仅约 55%。最关键的差距不是功能缺失，而是**从开发环境到生产环境的跨越能力**。
+
+建议立即启动 Phase 0（部署就绪），同步推进文档更新（wiki 数字刷新），在系统可部署的基础上再进行质量加固和产品闭环。

docs/discussions/2026-05-07-three-dimension-analysis.md

@@ -0,0 +1,237 @@
+# HMS 健康管理平台 — 三维度深度分析报告
+
+> 日期: 2026-05-07 | 数据截止: commit 786f57c (第 692 次提交) | 分析范围: 全系统
+
+## 背景
+
+HMS 健康管理平台经过 692 次提交的密集开发，从近 30 次提交（全为 fix 类型）来看已进入**上线前质量加固阶段**。本报告从后端架构、前端体验、文档质量三个维度对系统进行全面梳理，识别过时数据、关键风险和改进机会。
+
+## 1. 执行摘要
+
+| 维度 | 评分 | 关键发现 |
+|------|------|---------|
+| 后端架构 | 7.5/10 | 模块化优秀，erp-health 巨石化（38%占比），514 个 unwrap() |
+| 前端体验 | 6.5/10 | Web 质量好，小程序测试极差，AI 入口缺失，国际化缺失 |
+| 文档质量 | 6.0/10 | 体系完善但数据严重过时（12+ 指标与实际不符） |
+| **综合** | **6.4/10** | 功能完整度 85%，生产就绪度约 55% |
+
+**最高优先级行动：**
+1. CRITICAL — 创建生产级 Dockerfile（从"能跑"到"能部署"）
+2. HIGH — 补全 AI 分析前端 UI 入口（核心差异化功能完整呈现）
+3. HIGH — 配置 pre-commit hooks（阻止问题继续累积）
+
+---
+
+## 2. 后端架构分析
+
+### 2.1 Crate 结构概览
+
+系统共 18 个 Rust crate，579 个 .rs 源文件：
+
+| Crate | 文件数 | 代码量(约) | 职责 |
+|-------|--------|-----------|------|
+| erp-health | 179 | 35,750 | 核心医疗模块（38% 占比） |
+| erp-server | 18 | 23,481 | HTTP 入口 + 路由组装 |
+| erp-plugin | 24 | 10,945 | 插件引擎 |
+| erp-ai | 45 | 7,039 | AI 分析 |
+| erp-auth | 38 | 6,889 | 认证/权限 |
+| erp-workflow | 26 | 5,327 | 工作流引擎 |
+| erp-config | 24 | 4,974 | 配置/字典/菜单 |
+| erp-message | 18 | 3,699 | 消息通知 |
+| erp-core | 23 | 2,513 | 基础框架 |
+| erp-dialysis | 20 | 1,779 | 透析管理 |
+| 插件骨架 ×7 | 7 | ~430 | 各类插件原型 |
+
+**依赖关系：** `erp-core` → 8 个业务模块 → `erp-server` 组装。模块间零直接业务依赖，通过 EventBus + trait 通信。
+
+### 2.2 erp-health 巨石模块风险
+
+**规模：** 179 文件 / 35,750 行，占全部 Rust 代码的 38%。
+
+**内部结构：**
+- entity/: 55 个实体文件
+- handler/: 29 个 HTTP handler
+- service/: 37 个服务文件（含 5 个子目录）
+- dto/: 20 个 DTO 文件
+- fhir/: 4 个 FHIR R4 兼容层文件
+- oauth/: 6 个 OAuth 文件
+- event.rs: 2,327 行（含 1,300+ 行测试）
+
+**风险点：**
+- 4 个 service 文件超过 1,000 行（points_service 1,863 行、patient_service 1,118 行）
+- 单个 crate 搭载 12 个业务子域（患者/预约/随访/咨询/告警/积分/设备/内容/护理/透析/班次/知情同意）
+- 建议：按子域拆分为 3-4 个独立 crate
+
+### 2.3 erp-ai 模块
+
+**规模：** 45 文件 / 7,039 行，22 条 API 路由。
+
+- 4 个 AI Provider：Claude、OpenAI、Ollama、Registry
+- 11 个实体（分析记录/队列/知识库/Prompt/风险阈值/建议/配额等）
+- 支持 SSE 流式分析，每日自动扫描高风险患者
+- 事件驱动：`lab_report.uploaded` → 自动入队 → 化验单解读
+
+### 2.4 事件系统
+
+- **31 个事件类型**（health 模块内）+ 跨模块事件
+- **23 个幂等消费者**，每个有 `is_event_processed()` 检查
+- 基于 `tokio::sync::broadcast` + PostgreSQL Outbox + LISTEN/NOTIFY
+- 死信队列兜底：消费失败写入 `dead_letter_events` 表
+- 治理风险：事件类型已从 25 暴增，但缺乏版本管理和 schema 注册
+
+### 2.5 代码质量信号
+
+| 信号 | 数量 | 严重程度 |
+|------|------|---------|
+| TODO/FIXME | 5 处 | 低 |
+| unwrap() 调用 | 514 个（含测试） | 高（erp-plugin 113、erp-ai 77） |
+| 注释掉的代码 | 0 行 | 优秀 |
+| pub 函数 | ~1,201 个 | 公共 API 面积较大 |
+
+### 2.6 数据库迁移
+
+共 128 个迁移文件（最早 2026-04-10，最新 2026-05-07），覆盖：
+- 基础设施（001-031）、插件系统（033-041）、核心医疗（042-058）
+- 安全加密（062-072）、告警设备（073-095）、扩展功能（096-128）
+- 亮点：RLS 全面启用、审计日志哈希链、pgvector 扩展
+
+### 2.7 API 路由统计
+
+约 250+ 条路由，分布：
+- erp-health: ~137 条（public 1 + FHIR 14 + gateway 2 + protected ~120）
+- erp-ai: 22 条
+- 其他模块: ~90 条（auth/config/workflow/message/plugin/dialysis）
+
+---
+
+## 3. 前端分析
+
+### 3.1 Web 前端
+
+| 维度 | 数据 |
+|------|------|
+| 框架 | React 19 + Ant Design 6 + Zustand 5 + Tailwind CSS v4 |
+| 源文件 | 283 个 TS/TSX |
+| 路由 | 55 条（8 系统 + 6 插件 + 38 健康 + 6 冻结） |
+| API 模块 | 50 个（含完整 TypeScript 类型定义） |
+| Store | 6 个 Zustand Store（均有测试） |
+| 主题 | 4 套（信任蓝/温润东方/深邃夜色/翡翠清雅） |
+
+**亮点：**
+- API 层封装质量高：自动 token 刷新 + 并发请求队列去重 + 5 秒内存缓存
+- 三层权限控制：路由级（PrivateRoute）+ 组件级（AuthButton）+ 菜单级
+- 测试工厂模式：`listPageTests.tsx` 自动生成列表页标准测试
+- 6 个 Store 全部有请求去重和错误处理
+
+**问题：**
+- **国际化缺失**：无 i18n 框架，所有文本硬编码中文
+- **6 条路由冻结**：护理计划/班次/家庭代理/药物/透析/排班显示"功能暂未开放"
+- **AI 分析无 UI 入口**：4 个 SSE 端点完整实现但无前端页面触发
+
+### 3.2 微信小程序
+
+| 维度 | 数据 |
+|------|------|
+| 框架 | Taro 4.2 + React 18 + Zustand 5 |
+| 源文件 | 118 个 TS/TSX |
+| 页面 | ~54 个（主包 12 + 分包 42） |
+| TabBar | 4 个（首页/健康/消息/我的） |
+| 医生端 | 独立分包（16 个页面） |
+| API 服务 | 37 个模块 |
+
+**亮点：**
+- AES 加密安全存储，生产环境强制密钥
+- BLE 蓝牙设备集成（小米手环）
+- 请求层并发去重 + 60 秒缓存 + 切换患者自动隔离
+
+**问题：**
+- 测试极差：仅 BLE 模块 4 个单元测试 + 4 个 E2E
+- 118 个源文件几乎无测试覆盖
+
+### 3.3 测试覆盖对比
+
+| 层级 | 源文件 | 测试文件 | 覆盖比 |
+|------|--------|---------|--------|
+| Rust 后端 | 579 | 101（含测试）+ 25 集成 | 1:4.5 |
+| Web 前端 | 283 | 62 单元 + 13 E2E | 1:3.8 |
+| 小程序 | 118 | 4 单元 + 4 E2E | 1:14.8 |
+| **后端测试函数** | **772 个**（611 单元 + 153 集成 + 8 多模块） | 97.5% 通过率 |
+
+---
+
+## 4. 文档与质量分析
+
+### 4.1 文档体系
+
+| 类型 | 数量 | 状态 |
+|------|------|------|
+| 设计规格 | 47 份 | 覆盖全面 |
+| 实施计划 | 49 份 | 覆盖全面 |
+| 讨论记录 | 26 份 | 遵循命名规范 |
+| 审计报告 | 25 份（V1×8 + V2×13 + 截图） | 双轮完整审计 |
+| Wiki 页面 | 12 个 | 数据过时 |
+| plans/ 目录 | 87 个文件 | 膨胀需归档 |
+
+### 4.2 wiki 数据过时（已验证）
+
+| 指标 | wiki 值 | 实际值 | 偏差 |
+|------|--------|--------|------|
+| Git 提交 | 577 | 692 | +115 |
+| 数据库迁移 | 123 | 128 | +5 |
+| Rust 源文件 | 484 | 579 | +95 |
+| Web 前端文件 | 225 | 283 | +58 |
+| 前端测试文件 | 36 | 62 | +26 |
+| E2E spec | 5 | 13 | +8 |
+| 设计规格 | 41 | 47 | +6 |
+| 实施计划 | 38 | 49 | +11 |
+| 讨论记录 | 18 | 26 | +8 |
+
+### 4.3 CI/CD 与工程质量
+
+| 项 | 状态 | 说明 |
+|----|------|------|
+| GitHub Actions | ✅ 配置 | Rust check/test/clippy + 前端 tsc/test/build |
+| Gitea Actions | ✅ 配置 | Rust fmt/check/test + 前端 build + 安全审计 |
+| ESLint | ✅ 配置 | TypeScript 严格模式 + React Hooks 规则 |
+| Prettier | ❌ 未配置 | 无代码格式化工具 |
+| Pre-commit hooks | ❌ 未配置 | 质量门禁形同虚设 |
+| Docker | ⚠️ 仅数据库 | PostgreSQL + Redis，无应用镜像 |
+| 生产部署 | ❌ 无方案 | 无法部署到任何服务器 |
+
+### 4.4 根目录污染
+
+遗留文件散落在项目根目录：
+- 日志文件：`crash.log`、`server-output.log`、`server-stderr.log` 等
+- 测试令牌：`.test_token`、`.test_token_fresh.txt`
+- 截图：`current-page.png`、`home-full.png`、`home-improved.png`
+- 快照：`snapshot_*.txt`（4 个）
+- OCR 数据：`chi_sim.traineddata`（3.4MB）
+- Python 脚本：`test_api_auth.py`、`test_users.py`
+
+---
+
+## 5. 项目阶段判断
+
+**阶段：上线前质量加固**
+
+证据：
+1. 近 30 次提交全为 `fix` 类型（feat:fix 比约 2.3:1 的历史值已逆转）
+2. 工作重心是 5 角色深度测试修复 + 安全加固 + AI 模块修复
+3. V2 审计完成（85%），CRITICAL 安全问题已修复
+4. 6 个模块主动冻结（护理/班次/家庭代理/药物/透析/排班）
+
+**定位：**
+- 功能完整度：85%（12 个活跃功能域基本完整）
+- 代码质量：75%（Rust 后端优秀，前端质量待提升）
+- 安全合规：70%（PII 加密优秀，但仍有 CRITICAL 漏洞发现）
+- 可部署性：40%（无生产部署方案）
+- 可维护性：65%（文档完善但过时，代码膨胀需治理）
+
+---
+
+## 6. 关联文档
+
+- [多专家组头脑风暴记录](2026-05-07-expert-brainstorm-session.md) — 5 位专家独立评审 + 行动清单
+- [wiki/index.md](../../wiki/index.md) — 待更新的知识库入口
+- [V2 审计最终报告](../audits/v2/13-final-report.md) — 85% 完成度审计
+- [夯实基础设计规格](../superpowers/specs/2026-05-05-foundation-solidification-design.md) — 冻结策略和后续路线图

docs/discussions/2026-05-11-copilot-brainstorm.md

@@ -0,0 +1,93 @@
+# AI Copilot 基因化发散式探讨
+
+> 日期: 2026-05-11 | 参与者: 用户 + Claude
+> 产出物: `docs/superpowers/specs/2026-05-11-copilot-gene-design.md`
+
+## 背景
+
+HMS 健康管理平台当前处于功能完善阶段（系统评分 6.9/10 B），erp-ai 模块已完成 Phase 1 MVP（4 AI Provider，3 个分析场景）。本次探讨目标是无主题发散式讨论项目的未来方向。
+
+## 探索路径
+
+### 第一阶段：方向选择
+
+从 4 个方向中选择：产品演进 & 商业化、技术架构 & 工程质量、AI 深度集成、开放无主题。
+
+**选择：** 开放无主题 → 被"AI 不是功能而是基因"这个概念吸引。
+
+### 第二阶段：AI Copilot 基因化（核心讨论）
+
+#### 决策 1：AI 范式
+- 选项：Copilot 模式 / Agent 模式 / 先聊痛点 / 先聊安全
+- **结论：Copilot 模式 — AI 始终在场辅助**
+- 理由：医疗场景容错低，AI 提建议、医护做决策更安全
+
+#### 决策 2：触发机制
+- 选项：全量事件订阅 / 按需触发 / 混合模式
+- **结论：混合模式 — 预计算 + 实时补充**
+- 理由：预计算保证响应速度，实时补充保证上下文相关性
+
+#### 决策 3：核心触点
+- 选项：患者风险画像 / 异常检测 / 随访推荐 / 咨询辅助
+- **结论：四个全选**，它们形成一个闭环
+- 理由：风险画像 → 异常检测 → 随访推荐 → 咨询辅助 → 回到异常检测，每个触点的输出是下一个的输入
+
+#### 决策 4：实施策略
+- 选项：自下而上 / 垂直切片 / 混合
+- **结论：自下而上**
+- 理由：先建基础（评分引擎、洞察存储），再逐层叠加功能，每一步扎实
+
+#### 决策 5：风险评分方法
+- 选项：规则引擎 / 混合 / 其他
+- **结论：混合 — 规则打底 + LLM 补充**
+- 理由：规则保证可解释性（每一条规则可追溯），LLM 拓展规则覆盖不到的模式
+
+#### 决策 6：反馈飞轮
+- 选项：显式反馈 / 隐式学习 / 透明隐式 / 先不做
+- **结论：先不做反馈，先跑起来再说**
+- 理由：V1 需要快速验证价值，反馈机制等有真实使用数据后再设计
+
+### 第三阶段：患者端 Copilot 范式转换
+
+**关键洞察：血透机构没有互联网医院资质，医生不能在线与患者对话产生诊断行为。**
+
+这个业务约束彻底改变了患者端 Copilot 的定位：
+- 不是"医护 Copilot 的缩小版"
+- 而是合规的医患沟通桥梁 — AI 客服/管家
+- 功能：意图识别 → 安全应答 → 引导到院
+- 形态：对话式，嵌入小程序消息体系
+
+#### 决策 7：合规边界
+- 选项：极简安全 / 分级应答 / 智能审查
+- **结论：智能审查 — AI 输出自动合规检查**
+- 理由：双层审查（关键词 + 语义）既保证安全又不过度限制 AI 能力
+
+### 第四阶段：小程序日活引擎
+
+探讨了如何让患者每天都想打开小程序。
+
+#### 决策 8：日活驱动力
+- **结论：AI 伙伴每日问候 + 积分游戏化**
+- 理由：两者形成飞轮 — AI 推送触发打开，积分奖励完成行为
+
+#### 决策 9：积分经济模型
+- **结论：分层兑换 — 服务特权（零成本）+ 实物商品（高门槛）**
+- 理由：低成本特权拉新促活，高门槛实物给长期目标
+
+## 关键决策汇总
+
+| # | 决策点 | 结论 |
+|---|--------|------|
+| 1 | AI 范式 | Copilot（始终在场辅助） |
+| 2 | 触发机制 | 混合：后台预计算 + 实时补充 |
+| 3 | 核心触点 | 4 触点闭环（风险→异常→随访→咨询） |
+| 4 | 实施策略 | 自下而上 |
+| 5 | 评分引擎 | 规则打底 + LLM 补充 |
+| 6 | 反馈学习 | V1 不做 |
+| 7 | 患者端定位 | 合规 AI 客服/管家（非医护端缩小版） |
+| 8 | 合规策略 | 双层审查 + 自动修正 |
+| 9 | 积分体系 | 分层兑换（服务特权 + 实物） |
+
+## 产出物
+
+设计文档：`docs/superpowers/specs/2026-05-11-copilot-gene-design.md`（852 行，7 章）