diff --git a/docs/superpowers/specs/2026-04-28-technical-debt-cleanup-design.md b/docs/superpowers/specs/2026-04-28-technical-debt-cleanup-design.md
new file mode 100644
index 0000000..deb7c3e
--- /dev/null
+++ b/docs/superpowers/specs/2026-04-28-technical-debt-cleanup-design.md
@@ -0,0 +1,556 @@
+# 技术债清理设计规格
+
+> 日期: 2026-04-28 | 状态: DRAFT | 来源: 发散式技术债讨论
+
+## 1. 概述
+
+### 1.1 背景
+
+HMS 健康管理平台经过 17 天密集开发，功能层面已建成完整的医疗 SaaS 骨架：
+
+| 维度 | 数据 |
+|------|------|
+| Rust crate | 15 个 |
+| 数据库表 | 67 张（30 基础 + 34 健康 + 3 AI） |
+| 后端代码 | ~63k 行 Rust |
+| Web 前端 | 133 个源文件（77 TSX + 56 TS） |
+| 微信小程序 | 40 个页面，Taro 4.2 + React 18 |
+| Git 提交 | 301+ 次 |
+
+但安全合规、测试质量、事件消费闭环三个维度存在系统性欠账，是当前最大的技术风险。
+
+### 1.2 问题全景
+
+**安全（6 个 Critical）：**
+- SQL 注入风险（需排查动态 SQL 使用场景）
+- SSE 连接有效性需验证（键名一致但端点未确认可用）
+- AES 加密密钥硬编码到小程序 bundle（`secure-storage.ts` 使用环境变量，但 dev 默认密钥不安全）
+- PII 数据明文传输/展示
+- 密钥轮换端点未持久化、DEK 内存未 zeroize
+
+**事件（13 个事件仅 3 个被消费）：**
+- 危急体征告警（`health_data.critical_alert`）无人响应
+- 患者创建、预约确认/取消、随访逾期等业务事件无消费者
+- 缺少 dead-letter 和重试机制
+
+**测试（覆盖率 < 5%）：**
+- 后端 36 个测试因并行化问题全部失败
+- 前端仅 3 个单元测试
+- 无安全测试、无多租户隔离测试
+
+**代码质量：**
+- `points_service.rs` 膨胀至 1805 行（超 800 行上限 2 倍+）
+- 积分系统（6 实体）与 health 模块耦合过重
+- 密文缺版本标识，未来算法迁移困难
+- 前端 chunk 过大（antd 1.5MB）
+
+### 1.3 还债策略
+
+**按类型分批，批内 Critical 优先：**
+
+```
+批次 A（安全与合规）→ 批次 B（事件与架构）→ 批次 C（测试与质量）
+```
+
+每个批次的修复都伴随对应测试（批次 C 随批次 A/B 同步推进）。
+
+### 1.4 预估总工作量
+
+| 批次 | 项目数 | 预估 |
+|------|--------|------|
+| A 安全与合规 | 9 | 3-4 天 |
+| B 事件与架构 | 5 | 3-5 天 |
+| C 测试与质量 | 5 | 2-3 天（持续） |
+| **合计** | **19** | **8-12 天** |
+
+## 2. 批次 A：安全与合规
+
+### 2.1 A1+A2：SQL 注入风险排查与修复
+
+**现状：** 审计报告标记 `tenant_rls.rs` 和 `follow_up_service.rs` 存在 SQL 拼接。
+
+**实际代码验证：**
+- `follow_up_service.rs:73-84`：使用 `$N` 占位符 + `Statement::from_sql_and_values`，为参数化查询，**非注入风险**
+- `tenant_rls.rs`：文件不存在于当前代码库，可能已被修复或移除
+- 代码库中存在 29 处 `Statement::from_string` 使用，需逐个审计
+
+**需审计的高风险文件（非 migration）：**
+- `crates/erp-plugin/src/` — dynamic_table 相关动态 SQL
+- `crates/erp-health/src/service/` — 各 service 中的原生 SQL
+- `crates/erp-auth/src/` — 用户查询相关
+
+**修复方案：**
+1. 逐文件审计 29 处 `Statement::from_string`，区分 migration（安全）和业务代码（需参数化）
+2. 如发现裸拼接，统一改为 `Statement::from_sql_and_values` + `$N` 占位符
+3. 引入 Clippy lint 或 CI 检查禁止 `Statement::from_string` 用于含用户输入的场景
+
+### 2.2 A3：SSE 连接有效性验证
+
+**现状：** `apps/web/src/stores/message.ts:75` 使用 `localStorage.getItem('access_token')` 获取 token，`apps/web/src/stores/auth.ts:6` 同样使用 `access_token` 键名。**键名一致**，但 SSE 端点 `/api/v1/messages/stream` 是否实际工作尚未验证。
+
+**修复方案：**
+1. 验证 SSE 端点是否正常响应（后端 handler 是否正确注册）
+2. 统一使用 auth store 导出的获取方法而非直接 `localStorage.getItem`
+3. 添加 token 有效性检查，避免无效连接
+
+**涉及文件：**
+- `apps/web/src/stores/message.ts`
+- `apps/web/src/stores/auth.ts`（确认 token 键名）
+
+### 2.3 A4+A5+A8+A9：PII 后端加解密 + Blind Index
+
+这是批次 A 中工作量最大、架构影响最深的修复项。四个 Critical 问题合并为一个实施任务。
+
+#### 2.3.1 架构决策：方案 D — 后端加解密 + Blind Index
+
+**核心原则：前端（含小程序）不接触加密密钥。**
+
+| 层 | 职责 |
+|----|------|
+| 后端 Service 层 | PII 字段透明加解密（写入前加密，读取后解密） |
+| 后端 API 层 | 按角色/场景返回不同脱敏级别 |
+| Blind Index 层 | HMAC-SHA256 盲索引支持精确搜索 |
+| 前端 | 只展示后端返回的数据，不参与加密 |
+
+#### 2.3.2 现有加密基础设施
+
+当前已实现（`crates/erp-health/src/crypto.rs`）：
+- `HealthCrypto`：AES-256-GCM 加密 + HMAC-SHA256 盲索引
+- `encrypt()`：UUID v7 nonce + 密文 → Base64 编码
+- `decrypt()`：Base64 解码 → nonce 分离 → 解密
+- `hmac_hash()`：确定性 HMAC 哈希（盲索引）
+- `dev_default()`：开发环境硬编码密钥（**需移除**）
+- 已有 7 个单元测试验证加解密正确性
+
+#### 2.3.3 Blind Index 方案
+
+**新增数据库表：**
+
+```sql
+CREATE TABLE blind_indexes (
+    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+    tenant_id UUID NOT NULL,
+    entity_type VARCHAR(64) NOT NULL,   -- 如 "patient", "doctor"
+    entity_id UUID NOT NULL,
+    field_name VARCHAR(64) NOT NULL,     -- 如 "id_card", "phone"
+    blind_hash VARCHAR(64) NOT NULL,     -- HMAC-SHA256 hex
+    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
+    updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
+    UNIQUE(tenant_id, entity_type, field_name, blind_hash)
+);
+CREATE INDEX idx_blind_hashes ON blind_indexes (tenant_id, entity_type, field_name, blind_hash);
+```
+
+**搜索流程：**
+1. 前端传入搜索条件（如手机号 `13812345678`）
+2. 后端计算 HMAC 哈希
+3. 在 `blind_indexes` 表精确匹配
+4. 返回匹配的 entity_id 列表
+5. 模糊搜索（如姓张的所有患者）：后端解密后内存过滤
+
+**密钥轮换流程：**
+1. 生成新 DEK
+2. 批量重新加密所有 PII 字段
+3. 重算所有 blind_hash
+4. 更新 KEK 加密的新 DEK
+5. 旧 DEK 标记过期，保留 7 天过渡期
+
+#### 2.3.4 API 脱敏级别
+
+| 场景 | 返回策略 |
+|------|---------|
+| 列表页 | 脱敏展示（`张**`、`138****5678`） |
+| 详情页（有权限） | 完整明文 |
+| 导出 | 按权限级别，默认脱敏 |
+| API 内部调用 | 明文（服务间信任） |
+
+**新增脱敏工具函数：**
+- `mask_name("张三丰")` → `"张**"`
+- `mask_phone("13812345678")` → `"138****5678"`
+- `mask_id_card("110101199001011234")` → `"1101**********1234"`
+
+#### 2.3.5 小程序侧改造
+
+- **审计** `apps/miniprogram/src/utils/secure-storage.ts` — 当前使用环境变量 `TARO_APP_ENCRYPTION_KEY` + CryptoJS.AES 做本地存储加密
+- **区分用途**：
+  - PII 端到端加密 → 移除（后端全面接管）
+  - 本地 token 安全存储 → 保留（非 PII 用途）
+- API 返回的 PII 数据由后端控制脱敏级别
+- 列表页展示脱敏数据，详情页请求完整数据（需权限）
+
+#### 2.3.6 DEK 内存 zeroize
+
+- 引入 `zeroize` crate
+- `HealthCrypto` 的 `aes_key` 和 `hmac_key` 字段使用 `Zeroizing<[u8; 32]>`
+- Drop 时自动覆写内存
+
+#### 2.3.7 密文版本标识
+
+- 加密输出格式：`v1|Base64(nonce + ciphertext)`
+- 未来算法升级时新增 `v2|...`
+- 解密时根据版本前缀选择对应算法
+
+**涉及文件：**
+- `crates/erp-health/src/crypto.rs` — 主要修改
+- `crates/erp-health/src/state.rs` — HealthState.crypto 使用
+- `crates/erp-health/src/service/` — 所有涉及 PII 的 service
+- `crates/erp-health/entity/` — 新增 blind_indexes entity
+- `apps/miniprogram/src/utils/secure-storage.ts` — 审计并移除 PII 加密逻辑（保留本地存储加密）
+
+### 2.4 A6：清缓存破坏认证状态
+
+**现状：** 小程序设置页已实现 preserve-and-restore 模式（`apps/miniprogram/src/pages/profile/settings/index.tsx:16-27`）：清除缓存前保存 `access_token`、`refresh_token` 等 8 个关键 key，清除后重新写入。
+
+**结论：** 此问题 **已修复**，改为验证任务 — 确认 preserve-and-restore 逻辑覆盖所有必要 key 且工作正常。
+
+**涉及文件：**
+- `apps/miniprogram/src/pages/profile/settings/index.tsx`
+
+### 2.5 A7：PostgreSQL RLS Policy 兜底
+
+**现状：** 多租户隔离完全依赖应用层中间件注入 `tenant_id` 过滤。应用层 bug 可直接导致跨租户数据泄露。
+
+**修复方案：**
+1. 为所有含 `tenant_id` 的表创建 RLS policy
+2. 使用 PostgreSQL session variable（`SET app.current_tenant_id`）传递当前租户
+3. 中间件在每次请求开始时设置 session variable
+4. RLS policy 作为应用层过滤的兜底，而非替代
+
+```sql
+-- 示例
+ALTER TABLE patients ENABLE ROW LEVEL SECURITY;
+CREATE POLICY tenant_isolation ON patients
+    USING (tenant_id::text = current_setting('app.current_tenant_id', true));
+```
+
+**注意：** RLS policy 不影响超级用户（SUPERUSER），仅对应用数据库用户生效。
+
+**涉及文件：**
+- `crates/erp-core/src/middleware/` — 注入 session variable
+- 新增 SeaORM migration 文件（RLS policy 通过迁移实施，遵循 CLAUDE.md 规范）
+
+## 3. 批次 B：事件与架构
+
+### 3.1 B1：危急值告警消费者（最高优先）
+
+**现状：** `health_data.critical_alert` 事件已定义（`crates/erp-health/src/event.rs:43`），`alert_engine` 已实现评估逻辑，但 **无消费者响应此事件**。这意味着当患者体征超过危急值阈值时，系统仅发布事件但不通知任何医生。
+
+**这是真实的医疗安全风险。**
+
+#### 3.1.1 消费链路设计
+
+```
+健康数据录入 → critical_value_threshold 对比 → 超阈值
+    ↓
+EventBus.publish("health_data.critical_alert", payload)
+    ↓
+┌──────────────────────────┐
+│  危急值消费者 (consumer)  │
+├──────────────────────────┤
+│ 1. 创建 critical_alert   │ ← 新表，记录告警实例
+│ 2. 通知主治医生           │ ← 站内消息
+│ 3. 微信订阅消息推送       │ ← 患者端/医护端通知
+│ 4. 启动响应计时           │ ← 30min 未确认升级
+│ 5. 记录事件已处理         │ ← 幂等去重
+└──────────────────────────┘
+```
+
+#### 3.1.2 告警升级策略
+
+| 级别 | 触发条件 | 动作 |
+|------|---------|------|
+| Level 1 | 告警产生 | 通知主治医生（站内 + 微信） |
+| Level 2 | 30min 未确认 | 通知科室主任 |
+| Level 3 | 60min 未确认 | 通知院领导 + 标记为严重事件 |
+
+升级检查使用 `tokio::spawn` 定时任务，每分钟扫描未确认的告警。
+
+#### 3.1.3 新增数据库表
+
+```sql
+CREATE TABLE critical_alerts (
+    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+    tenant_id UUID NOT NULL,
+    patient_id UUID NOT NULL,
+    alert_type VARCHAR(64) NOT NULL,     -- vital_sign / lab_result
+    metric_name VARCHAR(64) NOT NULL,     -- blood_pressure / heart_rate ...
+    metric_value TEXT NOT NULL,
+    threshold_value TEXT NOT NULL,
+    severity VARCHAR(16) NOT NULL DEFAULT 'critical',
+    status VARCHAR(16) NOT NULL DEFAULT 'pending',  -- pending/acknowledged/resolved/escalated
+    acknowledged_by UUID,
+    acknowledged_at TIMESTAMPTZ,
+    escalation_level SMALLINT NOT NULL DEFAULT 0,
+    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
+    updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
+    created_by UUID,
+    updated_by UUID,
+    deleted_at TIMESTAMPTZ,
+    version BIGINT NOT NULL DEFAULT 1
+);
+
+CREATE TABLE critical_alert_responses (
+    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+    tenant_id UUID NOT NULL,
+    alert_id UUID NOT NULL REFERENCES critical_alerts(id),
+    responder_id UUID NOT NULL,           -- 确认人
+    response_type VARCHAR(16) NOT NULL,   -- acknowledge/escalate/resolve
+    notes TEXT,
+    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
+    updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
+    created_by UUID,
+    updated_by UUID,
+    deleted_at TIMESTAMPTZ,
+    version BIGINT NOT NULL DEFAULT 1
+);
+
+CREATE INDEX idx_critical_alerts_pending ON critical_alerts (tenant_id, status, created_at)
+    WHERE status IN ('pending', 'escalated');
+```
+
+#### 3.1.4 幂等处理
+
+利用 EventBus 已有的幂等基础设施：
+- `is_event_processed(db, event_id, "critical_alert_consumer")` 检查
+- `mark_event_processed(db, event_id, "critical_alert_consumer")` 标记
+- `processed_events` 表的 event_id + consumer_id 唯一约束兜底
+
+#### 3.1.5 实现位置
+
+- 消费者注册：`crates/erp-health/src/event.rs` → `register_handlers_with_state()`
+- 告警 service：`crates/erp-health/src/service/critical_alert_service.rs`（新增）
+- 告警 handler：`crates/erp-health/src/handler/critical_alert_handler.rs`（新增）
+- Entity：`crates/erp-health/src/entity/critical_alert.rs`（新增）
+
+### 3.2 B2：EventBus 可靠性增强
+
+**现状：** EventBus（`crates/erp-core/src/events.rs`）已实现：
+- 事件持久化到 `domain_events` 表（pending → published 状态机）
+- 内存 broadcast channel
+- PostgreSQL NOTIFY outbox relay
+- 过滤订阅（`subscribe_filtered`）
+- 幂等去重（`is_event_processed` / `mark_event_processed`）
+
+**缺少：**
+- 消费失败的重试机制
+- dead-letter 存储
+- 消费者健康监控
+
+**修复方案：**
+1. `domain_events` 表增加 `attempts` 计数器（已有）和 `last_error` 字段（已有）
+2. 新增 `dead_letter_events` 表：超过最大重试次数的事件转入
+3. 消费者返回 `Result` 时，失败则 `attempts++`，达到阈值转入 dead-letter
+4. 提供 `GET /api/v1/admin/dead-letter-events` 端点查看失败事件
+5. 提供 `POST /api/v1/admin/dead-letter-events/{id}/retry` 手动重试
+
+### 3.3 B3：积分系统拆分为独立 erp-points crate
+
+**现状：** 积分商城 6 个实体全在 `erp-health` 内（`points_account`、`points_checkin`、`points_order`、`points_product`、`points_rule`、`points_transaction`），`points_service.rs` 膨胀至 1805 行。
+
+#### 3.3.1 新 crate 结构
+
+```
+crates/erp-points/
+├── Cargo.toml
+├── src/
+│   ├── lib.rs
+│   ├── module.rs          — ErpModule trait 实现
+│   ├── state.rs           — PointsState { db, event_bus }
+│   ├── event.rs           — 事件常量 + 消费者注册
+│   ├── entity/
+│   │   ├── mod.rs
+│   │   ├── points_account.rs
+│   │   ├── points_transaction.rs
+│   │   ├── points_product.rs
+│   │   ├── points_order.rs
+│   │   ├── points_checkin.rs
+│   │   └── points_rule.rs
+│   ├── service/
+│   │   ├── mod.rs
+│   │   ├── account_service.rs
+│   │   ├── product_service.rs
+│   │   ├── order_service.rs
+│   │   ├── check_in_service.rs
+│   │   ├── exchange_service.rs
+│   │   └── rule_engine.rs
+│   ├── handler/
+│   │   ├── mod.rs
+│   │   └── points_handler.rs
+│   ├── dto/
+│   │   ├── mod.rs
+│   │   └── points_dto.rs
+│   └── error.rs
+```
+
+#### 3.3.2 事件契约
+
+**erp-points 订阅的事件：**
+| 事件 | 来源 | 动作 |
+|------|------|------|
+| `lab_report.uploaded` | erp-health | 化验上传奖励（已有事件常量） |
+| `patient.verified` | erp-health | 实名认证奖励（已有事件常量） |
+| `daily_monitoring.created` | erp-health | 日常监测奖励（已有事件常量） |
+
+> **注意：** 原讨论中设想的 `health.checkup.completed` 和 `health.appointment.completed` 事件在当前代码库中不存在，需在 erp-health 中新增定义并发布后才能订阅。建议作为后续迭代，Phase 1 先订阅已有事件。
+
+**erp-points 发布的事件：**
+| 事件 | 动作 |
+|------|------|
+| `points.earned` | 通知消息模块 |
+| `points.exchanged` | 通知消息模块 |
+| `points.expired` | 积分过期通知（已有事件常量） |
+| `points.balance.changed` | 余额变动，供前端 SSE 推送（**新增事件常量**） |
+
+#### 3.3.3 迁移策略
+
+1. 创建 `erp-points` crate，搭建标准基础设施（module/state/error）
+2. 从 `erp-health` 迁移 6 个 Entity + 对应 Migration 文件
+3. 迁移 service 逻辑，`points_service.rs` 拆分为 6 个子模块
+4. 迁移 handler
+5. `erp-server` 注册新模块
+6. 前端路由不变（API 路径保持 `/api/v1/points/*`）
+7. 删除 `erp-health` 中的积分相关代码
+
+### 3.4 B4+B5：代码质量修复
+
+**B4 — points_service.rs 拆分：**
+- 随 B3 拆 crate 时一并处理
+- 按 domain 拆为 account/product/order/check_in/exchange/rule_engine 6 个子模块
+- 每个模块 < 400 行
+
+**B5 — 密文版本标识：**
+- 已在 §2.3.7 描述，加密输出格式改为 `v1|Base64(nonce + ciphertext)`
+- 解密时根据版本前缀路由到对应算法
+
+## 4. 批次 C：测试与质量
+
+### 4.1 C0：测试并行化基础设施修复
+
+**现状：** `cargo test --workspace` 因 PostgreSQL 连接数不足导致 101 个测试全部失败（非代码 bug）。
+
+**修复方案：事务回滚模式**
+
+1. 每个测试开始时开事务
+2. 测试内的所有数据库操作在此事务中执行
+3. 测试结束（无论成功失败）回滚事务
+4. 多个测试共享同一个数据库连接池，无连接竞争
+
+```rust
+#[cfg(test)]
+async fn test_db() -> DatabaseTransaction {
+    let db = DatabaseConnection::connect(&database_url).await.unwrap();
+    db.begin().await.unwrap()
+}
+// 测试结束自动 drop DatabaseTransaction → 回滚
+```
+
+**替代方案：** `--test-threads=4` 限制并行度（临时方案，不推荐长期使用）。
+
+### 4.2 C1：安全测试（与批次 A 联动）
+
+每个批次 A 的修复对应一个安全测试：
+
+| 测试 | 验证目标 | 实现方式 |
+|------|---------|---------|
+| `test_sql_injection_prevention` | 动态 SQL 均参数化 | 注入 `'; DROP TABLE --` 断言不执行 |
+| `test_cross_tenant_isolation` | 租户 A 看不到租户 B 数据 | 不同 tenant_id 查询断言为空 |
+| `test_pii_round_trip_encryption` | 加密→解密一致 | HealthCrypto encrypt→decrypt→比对 |
+| `test_blind_index_exact_match` | 盲索引精确搜索 | 插入→HMAC 搜索→断言找到 |
+| `test_blind_index_no_false_positive` | 盲索引无误匹配 | 搜索不存在的值→断言为空 |
+| `test_key_rotation_re_encrypt` | 密钥轮换后数据可解密 | 轮换→重加密→新密钥解密→比对 |
+| `test_sse_token_key_correct` | SSE 用正确 token 键名 | 对比 auth store 和 message store 的 key |
+| `test_rls_policy_enforcement` | RLS policy 兜底 | 设置不同 tenant_id session variable 断言隔离 |
+| `test_cache_clear_preserves_auth` | 清缓存不破坏认证 | 模拟清缓存→断言 token 存在 |
+
+**测试实现原则：**
+- 安全测试独立于业务测试，放在 `tests/security/` 目录
+- 每个测试可独立运行，不依赖其他测试的执行顺序
+- 使用事务回滚，测试间互不干扰
+
+### 4.3 C2：事件消费者测试
+
+| 测试 | 验证目标 |
+|------|---------|
+| `test_vital_critical_alert_created` | 危急值事件→创建 alert 记录 |
+| `test_vital_critical_acknowledge` | 医生确认→状态更新 |
+| `test_vital_critical_escalation` | 30min 未确认→升级 |
+| `test_event_idempotency` | 同一事件消费两次→只创建一条 alert |
+| `test_dead_letter_on_failure` | 消费失败→转入 dead-letter |
+
+### 4.4 C3：API 集成测试骨架
+
+为关键 API 端点建立集成测试模式：
+
+```rust
+// tests/integration/api_test.rs
+#[tokio::test]
+async fn test_patient_crud() {
+    let app = TestApp::new().await;
+    let auth = app.login_as_doctor().await;
+
+    // Create
+    let resp = app.post("/api/v1/health/patients")
+        .set_auth(&auth)
+        .json(json!({ "name": "测试患者", ... }))
+        .send().await;
+    assert_eq!(resp.status(), 201);
+
+    // Read
+    let patient = app.get(&format!("/api/v1/health/patients/{}", id))
+        .set_auth(&auth)
+        .send().await;
+    assert_eq!(patient.status(), 200);
+}
+```
+
+优先覆盖的 API：
+- 患者管理 CRUD
+- 预约创建/取消
+- 健康数据录入
+- 积分账户操作
+
+### 4.5 C4：前端 chunk 拆分优化
+
+**现状：** Vite 构建产生超大 chunk — antd 1.5MB、charts 1.4MB。
+
+**修复方案：**
+1. 配置 `manualChunks` 将 antd/antd-icons 拆为独立 vendor chunk
+2. echarts 按需引入（只导入使用的图表类型）
+3. 路由级 code splitting（React.lazy + Suspense）
+4. 目标：首屏 JS < 500KB（gzip 后）
+
+## 5. 核心决策记录
+
+| 编号 | 决策 | 理由 | 影响 |
+|------|------|------|------|
+| D1 | PII 密钥管理 → 方案 D（后端加解密 + Blind Index） | 前端不接触密钥，安全性最高；Blind Index 支持搜索 | crypto.rs 重构、新增 blind_indexes 表、小程序移除加解密 |
+| D2 | 积分系统 → 独立 erp-points crate | 清晰模块边界，积分可跨业务复用 | 新 crate + 6 实体迁移 + 事件契约 |
+| D3 | 事件消费者 → vital.critical 最先 | 医疗安全底线，30min 未确认分级升级 | 新增 critical_alerts/responses 表 + 升级定时任务 |
+| D4 | 测试入口 → 安全测试驱动 | 与批次 A 联动，修一个写一个 | 事务回滚模式 + 9 个安全测试 |
+| D5 | 还债策略 → 按类型分批（安全→事件→测试） | 避免上下文切换，每批有清晰完成标准 | 3 批次串行执行 |
+
+## 6. 实施顺序与依赖关系
+
+```
+批次 A（安全）                    批次 B（事件）               批次 C（测试）
+─────────────────────            ─────────────────           ────────────────
+A1+A2 SQL 注入排查    ──测试──→   B1 vital.critical 消费者    C0 事务回滚模式
+A3 SSE Token 修复      ──测试──→   B2 EventBus dead-letter    C1 安全测试
+A6 清缓存修复          ──测试──→   B3 积分拆 erp-points       C2 事件测试
+A4+A5+A8+A9 PII 方案 D ──测试──→   B4+B5 代码质量             C3 集成测试
+A7 RLS policy 兜底     ──测试──→                              C4 chunk 优化
+```
+
+**关键依赖：**
+- C0（测试基础设施）**必须在批次 B 开始前完成**，作为批次 A 实施的前置条件
+- B1 依赖 C0（测试基础设施就绪）
+- B3 可与 A4 并行（无交叉文件）
+- C1 随 A1-A7 逐步推进（修一个写一个）
+- C4 独立于所有其他任务，可随时执行
+
+**每个任务的产出：**
+- 代码修改 + 对应测试
+- 编译通过（`cargo check`）
+- 测试通过（`cargo test --test-threads=4`）
+- Git 提交
+