# HMS 健康管理平台 — 全项目深度分析与多专家组头脑风暴

> 日期: 2026-05-03 | 类型: 分析报告 | 数据截止: commit 555 | 状态: 定稿
>
> **如何使用本文档：** §1-2 是全景扫描，所有人应读。§3-7 是专家组深度分析，按需阅读。§8-10 是行动矩阵和风险传导，执行时参考。每个专家组独立成章，可跳读。

**TL;DR:** HMS 项目整体健康度 B+。架构边界满分，安全基础扎实，文档体系完善。核心风险：前端测试 <5%、55% 事件孤立、审计整改率 8%、73 个未提交文件（截至文档编写时）。建议立即止血（P0）→ 本周补短板（P1）→ 本月治本（P2）。

---

## 1. 背景与目标

### 为什么做这次分析

HMS 项目经过 3 周密集开发（555 次提交，86 份设计规格），已进入功能基本完整的阶段。2026-04-30 完成的全系统审计发现 25 个问题（2 CRITICAL + 3 HIGH + 8 MEDIUM + 12 LOW），但审计后 3 天整改率仅 8%。此时需要一个全面的「体检」来：

1. 识别系统性风险而非单点问题
2. 从多维度（架构/安全/前端/质量/管理）交叉验证
3. 建立清晰的优先级行动矩阵

### 分析范围

| 维度 | 覆盖范围 |
|------|---------|
| 后端架构 | 17 Rust crates / ~87k 行 / 484 源文件 |
| 前端 Web | 151 文件（113 TSX + 38 TS） |
| 微信小程序 | 113 文件 / 38 页面 / 5 TabBar |
| 数据库 | 104 迁移 / 77+ 表 |
| 文档体系 | 12 页 wiki + 86 specs + 41 plans + 12 discussions |

### 方法论

- **静态分析：** 文件大小、代码模式搜索、依赖图梳理
- **模式识别：** 重复代码、缺失测试、不一致的命名
- **多专家视角：** 5 个虚拟专家组从不同角度审查同一代码库
- **数据来源：** Cargo.toml / git log / Grep 搜索 / Wiki 内容 / 审计报告

---

## 2. 项目全景扫描

### 2.1 规模与复杂度

| 维度 | 数据 | 评估 |
|------|------|------|
| Rust 代码 | ~87k 行 / 17 crates / 484 源文件 | 中大型单体，模块边界清晰 |
| Web 前端 | 151 文件 (113 TSX + 38 TS) | 中等规模，API 层完整 |
| 微信小程序 | 113 文件 / 38 页面 / 5 TabBar | 功能丰富，分包合理 |
| 数据库 | 104 迁移 / 77+ 表 | 高频 schema 迭代 |
| API 路由 | 328 (8 公开 + 320 受保护) | 全面的业务覆盖 |
| 测试 | 772 后端 + 11 前端 | 后端尚可，前端极低 |
| 事件系统 | 25 类型 / 44 发布 / 14 消费者 | 设计精良但有孤立事件 |
| 设计文档 | 86 specs / 41 plans | 文档驱动，管理有序 |
| Git 历史 | 555 次提交 | AI 辅助密集开发 |

### 2.2 架构评分矩阵

| 评估维度 | 得分 (1-5) | 说明 |
|----------|:---------:|------|
| 模块边界 | ⭐⭐⭐⭐⭐ | 零循环依赖，crates 间仅依赖 erp-core |
| 安全姿态 | ⭐⭐⭐⭐☆ | Argon2 + AES-256-GCM + RLS + 审计哈希链，限流失败模式待改进 |
| 错误处理 | ⭐⭐⭐⭐⭐ | 统一 AppError + 跨 crate 转换 + HTTP 映射 |
| 事件系统 | ⭐⭐⭐⭐☆ | Outbox + 死信 + 幂等，但 14 个孤立事件无消费者 |
| 前端架构 | ⭐⭐⭐⭐☆ | API/Store/Hook 三层分离，但零 i18n、低测试覆盖 |
| 代码质量 | ⭐⭐⭐⭐☆ | 4 个 TODO、无 FIXME/HACK，但存在 6 个千行文件 |
| 测试覆盖 | ⭐⭐⭐☆☆ | 后端 772 测试尚可，前端 <5%、小程序 0% |
| 文档完整性 | ⭐⭐⭐⭐☆ | 12 页 wiki + 86 specs，但 wiki 数据存在不一致 |
| 运维成熟度 | ⭐⭐⭐☆☆ | Docker + 原生双轨但不同步，单分支开发，大量未提交文件 |

---

## 3. 专家组 1：架构与基础设施

**成员画像：** Rust 系统架构师 + 数据库工程师 + DevOps 工程师

### 3.1 模块依赖分析

**依赖结构：** 所有 16 个 crate 形成以 `erp-core` 为底座的星型依赖图。`erp-server` 是唯一的组合根，依赖所有业务 crate。每个业务 crate（auth / config / workflow / message / health / ai / dialysis / plugin）**只依赖 erp-core**，不存在横向依赖。

**结论：** 依赖图干净，零循环依赖，具备未来拆分为微服务的前置条件。当前单体架构合理，无需急于拆分。

**关注点：** `erp-server` 依赖全部 crate，任何变更都触发完整重编译。`erp-health/module.rs`（1130 行路由注册）和 `erp-message/module.rs`（1054 行）是路由注册的单文件瓶颈。

### 3.2 数据库迁移治理

**现状：** 21 天内产生 100 个迁移（日均 5 个），其中单次健康表迁移达 1532 行（`m20260423_000042`）。

**风险：**
- 超大迁移在生产环境执行失败时，回滚成本极高
- 高频迭代表明 schema 尚未稳定
- `testing.md` 仍写着"迁移记录应为 50 条"（实际已 100 条）

**建议：**
1. 建立迁移文件大小上限（单文件 < 500 行）
2. 每个 Phase 结束后冻结 schema，后续走 ALTER 而非重建
3. 生产环境迁移前必须 dry-run 验证

**优先级：** P2

### 3.3 事件系统补全

**现状：** 25 个事件类型中 14 个无消费者（**55% 孤立率**）。`erp-health/event.rs` 828 行集中了所有事件处理器注册逻辑，且零测试覆盖。

**核心风险：** 事件孤立率超过 50% 意味着大量事件发布是无效操作 — 写入数据库、消耗存储、但无人消费。更危险的是可能掩盖业务流程断裂。

**建议：**
1. 对 14 个孤立事件逐一评估：删除无效事件 / 实现缺失消费者
2. 为 `erp-health/event.rs` 补充单元测试（至少覆盖每个消费者的核心路径）
3. 建立事件注册表：每个事件必须关联至少一个消费者（CLAUDE.md 铁律已在但未执行）

**优先级：** P1 — 事件是模块间通信的核心，孤立事件 = 功能缺失

> **交叉引用：** 安全组(§4.1)指出孤立事件会导致合规声明与实际行为不一致；质量组(§6.1)指出 event.rs 本身也是千行文件，重构时需要测试保障。

## 4. 专家组 2：安全与合规

**成员画像：** 安全工程师 + 医疗合规专家 + 隐私保护专家

### 4.1 生产安全配置审计

| 项目 | 状态 | 风险 |
|------|------|------|
| JWT 密钥 | 启动时强制检查 `__MUST_SET_VIA_ENV__` | ✅ 安全 |
| PII 加密 | AES-256-GCM + KEK 层级 + 开发模式拒绝生产 | ✅ 安全 |
| 密码哈希 | Argon2 + 随机 salt | ✅ 安全 |
| PostgreSQL RLS | 所有表启用 + 严格策略 | ✅ 安全 |
| 审计日志 | 哈希链防篡改 | ✅ 安全 |
| 限流失败模式 | Redis 不可用时默认 **fail-open** | ⚠️ 高风险 |
| SSE Token | 通过 query parameter 传递 JWT | ⚠️ 中风险 |
| AI API 密钥 | `api_key = ""` 空字符串（非强制占位符） | ⚠️ 中风险 |
| SQL 注入 | `sanitize_identifier()` + 参数化查询 | ✅ 安全 |

**关键建议：**

1. **P0 — 限流 fail-close：** 生产环境必须设置 `ERP__RATE_LIMIT__FAIL_CLOSE=true`，否则 Redis 宕机 = 无限流
2. **P1 — SSE Token 安全：** 改用短期一次性 ticket 替代 JWT query param，避免 token 出现在日志/历史记录
3. **P1 — AI 密钥统一：** 与 JWT 密钥一样使用 `__MUST_SET_VIA_ENV__` 占位符模式
4. **P2 — 审计日志写入：** fire-and-forget 模式可能导致静默丢失，改为带重试队列

> **交叉引用：** 质量组(§6.3)指出 `unwrap()` 调用中 PluginHost::db panic 是同一类问题 — 关键路径缺乏容错。

### 4.2 医疗数据合规性

**已有能力：**
- PII 加密体系完善（KEK → DEK → 数据加密 + HMAC 盲索引）
- PostgreSQL RLS 已在所有表启用
- 审计日志实现哈希链防篡改
- 多租户隔离通过 JWT 中间件 + `tenant_id` 列过滤

**缺口：**

| 缺口 | 影响 | 优先级 |
|------|------|--------|
| 小程序知情同意页面缺失 | 医疗合规底线，后端 consent 实体存在但前端完全空白 | P1 |
| 数据保留策略缺失 | 无自动化数据过期/匿名化机制 | P2 |
| 访问日志粒度不足 | `audit_logs` 记录 API 调用但不记录具体访问了哪些患者数据 | P3 |

## 5. 专家组 3：前端工程与用户体验

**成员画像：** 前端架构师 + UX 研究员 + 测试工程师

### 5.1 测试覆盖率分析

**前端测试现状（Web + 小程序）：**

| 层面 | 文件数 | 测试文件数 | 覆盖率 |
|------|--------|-----------|--------|
| Web 页面 | 40+ | 0 | 0% |
| Web Store | 6 | 0 | 0% |
| Web Hook | 9 | 2 | ~22% |
| Web API | 30+ | 1 | ~3% |
| Web 组件 | 10 | 1 | ~10% |
| 小程序页面 | 40 | 0 | 0% |
| 小程序服务 | 25+ | 0 | 0% |

**已有的 E2E 覆盖：**
- Web：13 个 Playwright spec（患者旅程、预约、随访、体征、告警等核心流程）
- 小程序：4 个 automator spec（商城、健康查看、积分、体征录入）

**核心判断：** 前端测试覆盖率 <5% 是项目最大的质量风险。后端有 772 个测试保障，但前端 151 个文件几乎裸跑。E2E 测试慢且脆弱，不能替代单元测试 — 任何重构都可能引入不可检测的回归。

> **交叉引用：** 4 个专家组独立得出「前端测试是最大短板」的结论 — 架构组(§3)、质量组(§6)、管理组(§7) 均标记。风险传导链(§10)说明低测试覆盖放大了所有其他重构风险。

**建议：**
1. **P1 — Store 测试：** 6 个 Zustand Store 是状态管理核心，每个至少 10 个测试
2. **P1 — API 契约测试：** 30+ API 模块验证 URL / Method / 参数序列化
3. **P2 — 关键 Hook 测试：** `usePaginatedData`、`usePermission`、`useApiRequest`
4. **P3 — 小程序测试：** 从 BLE 管理器和安全存储工具开始

### 5.2 国际化评估

**现状：** 整个项目零 i18n — 所有 UI 字符串硬编码中文，无 i18n 框架。

**影响评估：**
- 短期：不影响 — 目标用户就是中文用户
- 中期：如有国际医疗机构客户，改造成本巨大
- 长期：取决于商业策略

**建议：** 不急于实施，但提取 `antd.locale(zhCN)` 和 `dayjs.locale('zh-cn')` 为可配置入口，建立防腐层。优先级 P4。

### 5.3 组件质量与大文件

**Web 前端大文件（>500 行）：**

| 文件 | 行数 | 问题 | 建议 |
|------|------|------|------|
| Organizations.tsx | 622 | 组织树+部门树+岗位三合一 | 拆为 OrgTree + DeptTree + PositionPanel |
| ArticleEditor.tsx | 554 | 富文本+图片上传+表单 | 拆为 ArticleForm + ImageUploader |
| MainLayout.tsx | 554 | 菜单+侧边栏+头部+面包屑 | 拆为 Sidebar + Header + Breadcrumb |
| AppointmentList.tsx | 518 | 列表+筛选+创建弹窗 | 拆为 AppointmentFilter + AppointmentForm |
| VitalSignsChart.tsx | 485 | 多系列图表 | 拆为 ChartConfig + DataTransformer |

**正面发现：**
- 零 `console.log` 残留
- 零硬编码 mock 数据
- API 层与页面层分离良好
- Zustand Store 职责清晰，无 god store

## 6. 专家组 4：代码质量与技术债

**成员画像：** 资深工程师 + 代码审查专家

### 6.1 后端热点文件治理

**千行以上文件（按风险排序）：**

| 文件 | 行数 | 风险 | 说明 |
|------|------|------|------|
| `erp-health/service/points_service.rs` | 1863 | 🔴 | 积分业务核心，所有积分逻辑集中 |
| `erp-plugin/manifest.rs` | 1781 | 🟡 | 插件清单解析，变更频率低 |
| `erp-plugin/dynamic_table.rs` | 1768 | 🟡 | DDL 生成，含安全防护 |
| `erp-plugin/data_service.rs` | 1693 | 🟡 | 插件通用 CRUD |
| `erp-health/module.rs` | 1130 | 🟠 | 路由注册瓶颈 |
| `erp-health/service/stats_service.rs` | 1117 | 🟡 | 统计服务 |
| `erp-health/service/patient_service.rs` | 1111 | 🟠 | 患者核心业务，tracing 已补全（20 条） |
| `erp-health/service/health_data_service.rs` | 986 | 🟠 | 健康数据核心 |
| `erp-health/service/action_inbox_service.rs` | 930 | 🟡 | Action inbox |

**建议拆分策略：**
- `points_service.rs` → `points_account` + `points_rule` + `points_exchange` + `points_checkin`
- `patient_service.rs` → `patient_crud` + `patient_family` + `patient_tag` + `patient_export`
- `module.rs` (health) → 按子域拆路由组

**优先级：** P2 — 在下一次大改动时顺带重构

> **交叉引用：** 前端组(§5.3)独立发现 Web 侧同样存在 5 个 500+ 行大组件。架构组(§3.1)指出 module.rs 路由注册瓶颈。后端 + 前端共 11 个大文件需要拆分，是跨维度共识。

### 6.2 前端错误处理统一化

**重复模式（18+ 文件）：**

```typescript
// 被 18+ 个页面文件重复的内联错误提取
(err as { response?: { data?: { message?: string } } })?.response?.data?.message
```

**已有的正确方案：** `api/client.ts` 中的 `handleApiError()` 函数 — 但多数页面未使用。

**建议：**
1. 统一使用 `handleApiError()` 或 `useApiRequest` hook
2. 批量替换 18 个文件中的内联模式
3. 建立 ESLint 规则禁止该模式

**优先级：** P2 — 依赖 P1 Store 测试完成后再批量重构，避免无安全网的大规模替换

> **交叉引用：** 前端组(§5.1)指出前端测试 <5%，意味着这个 18 文件重构在没有测试保障下执行 = 高风险。应先完成 #7 Store 测试。

### 6.3 TypeScript 类型安全

**`any` 使用统计：**
- Web：10 处（3 个文件）— 集中在 `usePaginatedData`（5 处）和插件看板（4 处）
- 小程序：28 处（12 个文件）— 集中在 BLE API 类型缺失（11 处）和微信登录响应（5 处）

**根因分析：**
- `usePaginatedData`：Hook 重载签名问题，可通过泛型收窄解决
- 小程序 BLE：Taro 的 BLE 类型定义不完整，需补充类型声明文件

**优先级：** P3 — 不影响运行时，但影响类型安全性

**其他技术债：**

| 项目 | 数量 | 优先级 |
|------|------|--------|
| 编译器警告 | 40 个 | P3 |
| `unwrap()` 调用（service 层生产风险） | 2 处（PluginHost::db / semaphore acquire） | P2 |
| TODO 注释 | 4 个（全部合理） | P4 |
| 过时迁移注释（"应为 50 条"） | 1 处 | P2 |

## 7. 专家组 5：项目管理与交付效率

**成员画像：** 项目经理 + 产品负责人

### 7.1 未提交工作积压

**严重程度：** 🔴 CRITICAL

**现状：** 工作树中存在 24 个已修改未提交文件 + 48 个未跟踪新文件（共 73 个），包括：
- 8 个 wiki 文件（文档更新）
- 4 个小程序源文件
- 2 个 Web 前端文件
- 8 个 Rust 业务代码文件（跨 5 个 crate）
- 7 个新的小程序医生端服务文件
- 8 个审计报告文档
- 5 个讨论记录
- 临时文件（`_temp/`、`mp_error.png`、`tmp_chart.png` 等）

**风险：** 本地故障 = 大量工作丢失 + 无法回溯变更历史 + 违反 CLAUDE.md 闭环工作法。

**建议：** 立即执行分类提交 — 按功能 / 文档 / 配置分组，并清理临时文件。

> **交叉引用：** 架构组(§3.1)指出 wiki 文档未提交，质量组(§6.3)指出过时注释未更新 — 三组数据均指向「闭环工作法未执行」的系统性问题。风险传导链(§10.2)说明未提交文件是人员单点故障的放大器。

### 7.2 审计整改进度

**整改率：** 25 个审计发现中仅 1-2 个已处理（~8%，3 天后）

**CRITICAL 项状态：**

| ID | 问题 | 天数 | 状态 |
|----|------|------|------|
| C1 | 晚间血压数据丢失 | 3 | 已修复但 wiki 文档未更新 |
| C2 | 告警权限码拼写错误 (`alert` → `alerts`) | 3 | **未修复**（5 分钟改动） |

**HIGH 项状态：**

| ID | 问题 | 状态 |
|----|------|------|
| H1 | 小程序透析模块完全缺失 | 未开始 |
| H2 | 小程序知情同意页面完全缺失 | 未开始 |
| H3 | 健康服务运行时日志严重不足 | 部分修复（patient_service tracing 已补全，其他大文件待跟进） |

**建议：**
1. C2 立即修复 — 改 `health.alert.manage` → `health.alerts.manage`
2. 建立审计整改看板 — 每个 finding 分配责任人和截止日期
3. 严格按 CRITICAL → HIGH → MEDIUM 顺序处理

### 7.3 Wiki 一致性

**发现的不一致：**

| 位置 | 问题 |
|------|------|
| `architecture.md:28-29` | 重复的插件列表行（一行有 assessment，一行没有） |
| `architecture.md:25` | 权限码数量 22（实际 erp-health 有 39 个） |
| `testing.md:124` | 迁移数 "应为 50 条"（实际已 96 条） |
| `database.md` | 迁移文档仅覆盖到 m000091（实际 m000100） |
| `infrastructure.md` | 更新日期停留在 2026-04-23 |
| Docker compose | PostgreSQL 16 vs wiki 声称的 18 |
| entity 计数 | architecture.md 说 44，实际列表有 45 个 |

**建议：** 安排 wiki 刷新会话，逐一校对数据。优先级 P2。

> **交叉引用：** 本文档自身的数据已用代码库实际值校正（见 §1 头部注释）。但 wiki 中仍有 7 处不一致未修。架构组(§3.2)和本组均发现此问题 — 3 组独立验证，可信度高。

## 8. 优先级行动矩阵

### 🔴 P0 — 立即处理（今天）

| # | 行动 | 工作量 | 完成标准 | 阻塞 |
|---|------|--------|---------|------|
| 1 | 提交并推送 73 个未提交文件 | 30 min | `git status` 干净 + `git push` 成功 | 所有后续工作 |
| 2 | 修复 C2 告警权限码拼写 | 5 min | AlertList 页面按钮正常显示 + 无 403 | — |
| 3 | 确认 C1 晚间血压修复并更新 wiki | 15 min | 小程序录入晚间血压 → 数据库有记录 + wiki 症状导航已更新 | — |

### 🟠 P1 — 本周内

| # | 行动 | 工作量 | 完成 standard | 依赖 |
|---|------|--------|-------------|------|
| 4 | 生产限流 fail-close 配置 | 1h | `config/production.toml` 含 `fail_close = true` + 集成测试验证 | #1 |
| 5 | 补全 erp-health/event.rs 测试 | 4h | 每个消费者至少 1 个正向 + 1 个异常测试 | — |
| 6 | 孤立事件清理（14 个） | 8h | 每个事件有消费者或已删除，孤立率 <10% | #5 |
| 7 | 前端 Store 单元测试（6 个 store） | 8h | 每个 store ≥10 测试，覆盖核心 action 和 selector | #1 |
| 8 | 小程序透析模块（审计 HIGH H1） | 16h | 透析记录查看/新增/编辑页面可用 + 4 个 automator spec | #1 |
| 9 | 小程序知情同意模块（审计 HIGH H2） | 8h | 知情同意签署页面 + 签署后事件正常发布 | #1 |
| 10 | health_data_service / action_inbox 补充 tracing | 4h | 两个文件的关键路径均有 `tracing::info/error` | — |

### 🟡 P2 — 本月内

| # | 行动 | 工作量 | 完成 standard | 依赖 |
|---|------|--------|-------------|------|
| 11 | 前端错误处理统一化（18 个文件） | 4h | 0 处内联错误提取，全部用 `handleApiError` | #7 |
| 12 | 大文件拆分（后端 6 个千行文件） | 16h | 无 >1000 行的 service 文件 | — |
| 13 | 前端 API 契约测试 | 8h | 每个 API 模块 ≥3 测试（URL/Method/参数） | #7 |
| 14 | Wiki 数据一致性刷新 | 4h | wiki 中所有计数与代码库一致 | — |
| 15 | 数据库迁移治理策略 | 8h | 新迁移 <500 行 + 有 dry-run 脚本 | — |
| 16 | unwrap() 调用替换（2 处） | 2h | `grep -r "unwrap()" service/` 返回 0 结果 | — |

### 🟢 P3 — 季度规划

| # | 行动 | 工作量 | 完成 standard | 依赖 |
|---|------|--------|-------------|------|
| 17 | 编译器警告清理（40 个） | 8h | `cargo check 2>&1 | grep warning` 返回 0 | — |
| 18 | 前端大组件拆分（20 个文件） | 16h | 无 >500 行的 TSX 文件 | #12 |
| 19 | TypeScript any 消除 | 8h | `grep -r ": any"` Web 返回 0 / 小程序 <5 | — |
| 20 | 小程序测试基础设施 | 16h | BLE + secure-storage + 核心页面单元测试 | #8 |
| 21 | Docker 配置与文档对齐 | 4h | compose 版本号 = wiki 声明 | #14 |
| 22 | 数据保留策略设计 | 16h | 设计规格文档 + 至少 1 个实体的自动化过期 | — |

---

## 9. 交叉验证：多组共识与分歧

> 5 个专家组独立分析同一代码库。本节记录各组发现的交叉印证和矛盾，增强结论可信度。

### 9.1 多组共识（≥3 组独立发现同一问题）

| 共识问题 | 涉及专家组 | 核心引用 |
|----------|-----------|---------|
| **前端测试空白是最大风险** | 架构(§3) + 前端(§5.1) + 质量(§6) + 管理(§7) | 前端 151 文件仅 11 测试（<5%），4 组独立得出"不可接受"结论 |
| **大文件/大组件是可维护性瓶颈** | 架构(§3.1) + 前端(§5.3) + 质量(§6.1) | 后端 6 个千行文件 + 前端 5 个 500+ 行组件，3 组独立标记 |
| **Wiki 数据过时** | 架构(§3.2) + 质量(§6.3) + 管理(§7.3) | 迁移数/权限码/entity 计数多处不一致，3 组各自发现不同不一致 |
| **审计整改执行纪律缺失** | 管理(§7.2) + 安全(§4.1) + 质量(§6) | C2 五分钟改动 3 天未修，限流 fail-open 未配置，说明流程断裂 |

### 9.2 组间互补（A 组发现问题，B 组补充影响）

| 问题 | A 组发现 | B 组补充 |
|------|---------|---------|
| 孤立事件 | 架构组(§3.3): 55% 孤立率 | 安全组(§4.1): 事件无消费者 = 功能声明与实际不一致，合规审计时被发现 |
| 限流 fail-open | 安全组(§4.1): Redis 宕机无限流 | 架构组(§3.1): 单体架构下 Redis 是 SPOF，影响全局 |
| 前端错误处理重复 | 质量组(§6.2): 18 文件重复模式 | 前端组(§5.1): 无测试覆盖 = 重构时无法验证不破坏 |
| unwrap() 调用 | 质量组(§6.3): 2 处生产风险 | 安全组(§4.1): PluginHost::db panic = 整个插件子系统不可用 |
| 小程序页面空白 | 前端组(§5): 功能缺失 | 安全组(§4.2): 知情同意缺失 = 医疗合规底线问题 |

### 9.3 无重大分歧

5 组之间无结论性矛盾 — 所有发现方向一致，差异仅在优先级判断上：
- i18n：前端组判 P4，安全组未提及。共识：不阻塞
- 编译器警告：质量组判 P3，架构组未提及。共识：可延后

---

## 10. 风险传导链

> 风险不是孤立的。以下展示风险如何通过依赖关系互相放大，解释为什么某些 P0 看似小改动却必须立即处理。

### 10.1 核心传导路径

```
未提交文件积压 (#1)
  ├─→ 本地故障 = 工作丢失 → 阻塞所有后续工作
  └─→ 审计整改延迟 → C2 五分钟改动被搁置 3 天

孤立事件 55% (#6)
  ├─→ 功能声明 ≠ 实际行为 → 用户不可见的业务断裂
  └─→ 无消费者测试 → 重构 event.rs 时无法验证 (#5)

前端测试 <5% (#7)
  ├─→ 错误处理统一化 (#11) 无法验证 → 技术债固化
  ├─→ 大组件拆分 (#18) 风险极高 → 不敢重构
  └─→ API 契约测试 (#13) 无回归安全网 → 新功能也可能破坏旧功能

限流 fail-open (#4)
  └─→ Redis 宕机 → 无限流 → 恶意请求打垮服务 → 影响所有用户
```

### 10.2 风险放大效应

| 放大器 | 被放大的风险 | 机制 |
|--------|------------|------|
| 低测试覆盖 | 重构风险 | 任何代码变更都无法验证不引入回归 |
| 孤立事件 | 功能验证盲区 | 发布的事件无消费者 = 变更的影响无法观测 |
| 未提交文件 | 人员单点故障 | 唯一开发者本地故障 = 全部工作丢失 |
| Wiki 过时 | 决策误导 | 基于过时 wiki 的新决策可能建立在错误前提上 |

---

## 11. 总结与建议

### 整体评分：B+（良好，有明确的提升空间）

### 核心优势

1. **架构设计出色** — 分层清晰、模块边界严格、事件驱动解耦、零循环依赖
2. **安全基础扎实** — Argon2 + AES-256-GCM + PostgreSQL RLS + 审计哈希链
3. **文档驱动开发** — 86 份设计规格、12 份讨论记录、12 页 wiki，决策有据可查
4. **API 层完整** — 328 路由覆盖所有业务，前端 API 层与后端 1:1 对应
5. **前端架构清晰** — API / Store / Hook 三层分离，无 god store、无硬编码数据、无 console.log 残留

### 核心风险

1. **前端测试空白** — <5% 覆盖率，任何重构都是冒险
2. **审计整改缓慢** — 3 天仅处理 8% 的审计发现，CRITICAL C2（5 分钟改动）仍未修复
3. **工作积压** — 73 个文件未提交，违反闭环工作法
4. **孤立事件** — 55% 的事件无消费者，可能是功能断裂的信号
5. **可观测性不足** — 多个核心 service 文件仍缺 tracing 日志（patient_service 已补全）

### 成功度量

每个优先级阶段的验收标准：

| 阶段 | 时间窗口 | 核心指标 | 目标 |
|------|---------|---------|------|
| P0 止血 | 今天 | CRITICAL 项关闭率 | 100%（2/2） |
| P0 止血 | 今天 | 未提交文件数 | 0 |
| P1 补短板 | 本周 | 审计 HIGH 关闭率 | ≥66%（2/3） |
| P1 补短板 | 本周 | 前端 Store 测试数 | ≥60 |
| P1 补短板 | 本周 | 事件孤立率 | <10% |
| P2 治本 | 本月 | 千行 service 文件 | 0 |
| P2 治本 | 本月 | Wiki 数据准确率 | 100% |
| P3 持续 | 季度 | 前端测试覆盖率 | >30% |
| P3 持续 | 季度 | 编译器警告数 | 0 |

### 下一步方向

当前阶段应遵循 **「止血 → 补短板 → 治本」** 路径：

1. **止血（P0，今天）：** 提交积压文件 + 关闭审计 CRITICAL
2. **补短板（P1，本周）：** 事件系统 + 前端测试 + 小程序透析/知情同意 + 安全配置
3. **治本（P2，本月）：** 代码重构 + 文档刷新 + 迁移治理
4. **持续改善（P3，季度）：** 类型安全 + 警告清理 + 测试扩展

**一句话总结：** 架构扎实、文档丰富的项目，当前需要暂停新功能开发，用 1-2 周集中补强测试和运维纪律，为下一阶段的功能扩展建立可靠的基础。