Files
hms/docs/discussions/2026-04-28-technical-debt-cleanup-strategy.md
iven 80b99dba46
Some checks failed
CI / frontend-build (push) Has been cancelled
CI / security-audit (push) Has been cancelled
CI / rust-check (push) Has been cancelled
CI / rust-test (push) Has been cancelled
docs: 技术债清理策略讨论记录 — 三批次还债策略 + 5 项核心决策
2026-04-28 11:35:23 +08:00

3.9 KiB
Raw Blame History

技术债清理策略讨论

日期: 2026-04-28 | 参与者: 用户 + Claude

背景

HMS 健康管理平台经过 17 天密集开发301+ 次提交),功能层面已建成完整的医疗 SaaS 骨架。但安全合规、测试质量、事件消费闭环三个维度存在系统性欠账——6 个 Critical 安全问题、测试覆盖率 < 5%、13 个事件仅 3 个被消费。需要确定技术债清理策略。

讨论要点

1. 还债策略选择

选项:

  • A: Critical 优先,集中清理
  • B: 按类型分批还债(安全→事件→测试)
  • C: 随功能开发顺带还
  • D: 重新排列优先级

结论:选择 B按类型分批还债,批内 Critical 优先。

2. 小程序 PII 密钥管理

选项:

  • A: 密钥由后端下发
  • B: 密钥协商ECDH
  • C: 后端加解密
  • D: 后端加解密 + Blind Index

结论:选择 D后端加解密 + Blind Index

  • 前端不接触加密密钥
  • 盲索引支持精确搜索HMAC-SHA256
  • API 按角色/场景返回不同脱敏级别
  • A4+A5+A8+A9 四个 Critical 合并为一个实施任务

3. 事件消费者补全策略

选项:

  • A: vital.critical 最先
  • B: 先建框架再接业务
  • C: 全部一起补

结论:选择 Avital.critical 最先)

  • 危急体征告警无人响应是真实医疗安全风险
  • 30min 未确认分级升级(主治→科室主任→院领导)
  • 微信订阅消息推送
  • 新增 critical_alerts + critical_alert_responses 表

4. 积分系统处理方式

选项:

  • A: 拆为独立 crate erp-points
  • B: health 子模块先拆出来
  • C: 跳过,后续再聊

结论:选择 A拆为独立 crate erp-points

  • 清晰模块边界,积分可跨业务复用
  • points_service.rs1805 行)拆为 6 个子模块
  • 事件契约:订阅 lab_report.uploaded / patient.verified / daily_monitoring.created

5. 批次 B/C 顺序

结论B 先事件优先C 后(测试)

6. 测试入口选择

选项:

  • A: 修基础设施让现有测试跑通
  • B: 从安全测试开始写
  • C: 跳过测试

结论:选择 B从安全测试开始写

  • 与批次 A 联动,修一个写一个
  • 事务回滚模式解决并行化问题

7. 代码审计发现

讨论过程中对代码进行了实际验证,发现:

  • follow_up_service.rs 的 SQL 实际已参数化($N 占位符),不是注入风险
  • tenant_rls.rs 不在 erp-health 中,而在 crates/erp-server/src/middleware/tenant_rls.rs
  • SSE Token 键名实际一致auth store 和 message store 都用 access_token
  • 清缓存问题已在 apps/miniprogram/src/pages/profile/settings/index.tsx 中修复preserve-and-restore 模式)
  • 积分系统实际有 6 个 Entity非 8 个),points_exchangepoints_sign_record 不存在
  • EventBus 已有完善基础设施持久化、幂等去重、filtered subscription、NOTIFY outbox

结论

还债策略:三批次串行 — 安全(A) → 事件(B) → 测试(C)

产出文档:

  • 设计规格:docs/superpowers/specs/2026-04-28-technical-debt-cleanup-design.md
  • 实施计划:docs/superpowers/plans/2026-04-28-technical-debt-cleanup-plan.md14 个 Task / 4 个 Chunk

核心决策记录:

# 决策 理由
D1 PII → 后端加解密 + Blind Index 前端不接触密钥,安全性最高
D2 积分 → 独立 erp-points crate 清晰模块边界,可跨业务复用
D3 事件 → vital.critical 最先 医疗安全底线30min 分级升级
D4 测试 → 安全测试驱动 与批次 A 联动,修一个写一个
D5 策略 → 按类型分批 避免上下文切换,每批有清晰完成标准

待定

  • 小程序 secure-storage.ts 中非 PII 的本地存储加密是否保留
  • health.checkup.completedhealth.appointment.completed 事件需在后续迭代中新增
  • 前端路由级 code splitting 的具体组件边界