From 80b99dba46aaf740f5f4f8ab4499e8fe9e38ed12 Mon Sep 17 00:00:00 2001
From: iven <iven_h@qq.com>
Date: Tue, 28 Apr 2026 11:35:23 +0800
Subject: [PATCH] =?UTF-8?q?docs:=20=E6=8A=80=E6=9C=AF=E5=80=BA=E6=B8=85?=
 =?UTF-8?q?=E7=90=86=E7=AD=96=E7=95=A5=E8=AE=A8=E8=AE=BA=E8=AE=B0=E5=BD=95?=
 =?UTF-8?q?=20=E2=80=94=20=E4=B8=89=E6=89=B9=E6=AC=A1=E8=BF=98=E5=80=BA?=
 =?UTF-8?q?=E7=AD=96=E7=95=A5=20+=205=20=E9=A1=B9=E6=A0=B8=E5=BF=83?=
 =?UTF-8?q?=E5=86=B3=E7=AD=96?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...6-04-28-technical-debt-cleanup-strategy.md | 106 ++++++++++++++++++
 1 file changed, 106 insertions(+)
 create mode 100644 docs/discussions/2026-04-28-technical-debt-cleanup-strategy.md

diff --git a/docs/discussions/2026-04-28-technical-debt-cleanup-strategy.md b/docs/discussions/2026-04-28-technical-debt-cleanup-strategy.md
new file mode 100644
index 0000000..378a7af
--- /dev/null
+++ b/docs/discussions/2026-04-28-technical-debt-cleanup-strategy.md
@@ -0,0 +1,106 @@
+# 技术债清理策略讨论
+
+> 日期: 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: 全部一起补
+
+**结论：选择 A（vital.critical 最先）**
+- 危急体征告警无人响应是真实医疗安全风险
+- 30min 未确认分级升级（主治→科室主任→院领导）
+- 微信订阅消息推送
+- 新增 critical_alerts + critical_alert_responses 表
+
+### 4. 积分系统处理方式
+
+**选项：**
+- A: 拆为独立 crate erp-points
+- B: health 子模块先拆出来
+- C: 跳过，后续再聊
+
+**结论：选择 A（拆为独立 crate erp-points）**
+- 清晰模块边界，积分可跨业务复用
+- points_service.rs（1805 行）拆为 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_exchange` 和 `points_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.md`（14 个 Task / 4 个 Chunk）
+
+**核心决策记录：**
+| # | 决策 | 理由 |
+|---|------|------|
+| D1 | PII → 后端加解密 + Blind Index | 前端不接触密钥，安全性最高 |
+| D2 | 积分 → 独立 erp-points crate | 清晰模块边界，可跨业务复用 |
+| D3 | 事件 → vital.critical 最先 | 医疗安全底线，30min 分级升级 |
+| D4 | 测试 → 安全测试驱动 | 与批次 A 联动，修一个写一个 |
+| D5 | 策略 → 按类型分批 | 避免上下文切换，每批有清晰完成标准 |
+
+## 待定
+
+- 小程序 `secure-storage.ts` 中非 PII 的本地存储加密是否保留
+- `health.checkup.completed` 和 `health.appointment.completed` 事件需在后续迭代中新增
+- 前端路由级 code splitting 的具体组件边界