# 文档类型与评查组关联 — 老项目分析 & 新方案

## 一、老项目模型（docauditai）

### 三层间接绑定

```
DocumentType → TopLevelGroup(s) → ChildGroups → EvaluationPoints
     │                │               │               │
     │    evaluation_  │   pid=0       │   pid={top}   │   evaluation_
     │    point_groups │               │               │   point_groups_id
     │    _ids (JSONB) │               │               │
```

- `document_types.evaluation_point_groups_ids` — JSONB 数组，存顶层组 ID，如 `[3]` 或 `[1,5]`
- `evaluation_point_groups` — 两级树：`pid=0` 是顶层组，"pid>0" 是子组
- `evaluation_points` — 属于子组，含 `extraction_config`（提取规则）和 `evaluation_config`（评查规则），按 `area` + `document_attribute_type` 过滤

### 运行时解析流程

```
doc_type_code
  → 查 document_types.evaluation_point_groups_ids[0]
    → 查 evaluation_point_groups WHERE pid = {top_group_id}
      → 查 evaluation_points WHERE evaluation_point_groups_id = {child_id}
        → 按 area + attribute_type 过滤
          → 返回最终评查点列表
```

---

## 二、新平台模型（leaudit-platform）

### 直接绑定

```
DocumentType ──→ RuleTypeBinding ──→ RuleSet ──→ RuleVersions
```

**`leaudit_rule_type_bindings`**:
| 字段 | 说明 |
|------|------|
| `doc_type_id` | FK → leaudit_document_types.id |
| `rule_set_id` | FK → leaudit_rule_sets.id |
| `binding_mode` | "explicit"（一对一）/ "inherit"（继承） |
| `region` | 地区隔离 |
| `priority` | 同一 doc_type 多个 rule_set 时的优先级 |

**运行时**（已在 auditServiceImpl.py 实现）:
```sql
SELECT b.rule_set_id, rs.current_version_id
FROM leaudit_rule_type_bindings b
JOIN leaudit_rule_sets rs ON rs.id = b.rule_set_id
WHERE b.doc_type_id = :doc_type_id
  AND b.region = :region
  AND b.is_active = true
ORDER BY b.priority DESC
```

### 与老模型的关键差异

| | 老 | 新 |
|---|---|---|
| 绑定粒度 | 文档类型 → 顶层组（间接） | 文档类型 → 规则集（直接） |
| 评查点层级 | 三级（类型→组→子组→点） | 两级（类型→规则集→版本） |
| 地区隔离 | evaluation_points.area | rule_type_bindings.region |
| 规则版本 | 无版本概念 | 规则集 + 版本管理 |

实际上新模型更简洁：老系统里的"顶层组"≈新系统的"规则集"，老系统里的"子组+评查点"≈新系统的"规则版本内容"。新系统去掉了中间的子组层级。

---

## 三、已落地 vs 待落地

### ✅ 已落地

| 项 | 说明 |
|----|------|
| `leaudit_document_types` 表 | 有 20 条种子数据，含 code/name/entry_module_id/prompt_config |
| `leaudit_rule_sets` 表 | 规则集 + 版本管理 |
| `leaudit_rule_type_bindings` 表 | 20 条绑定记录，已全部配对 |
| 运行时绑定解析 | auditServiceImpl.Run() 中查 bindings → 找 rule_set + version |
| `GET /api/document-types` | 刚加的，返回 id/name/code |

### ❌ 待落地

| 优先 | 项 | 说明 |
|------|----|------|
| 高 | 文档类型 CRUD 后端 | POST/PUT/DELETE /api/document-types |
| 高 | 规则绑定 CRUD 后端 | 在文档类型编辑中配 rule_set_id(s) |
| 高 | 前端文档类型管理页 | 对应旧 `document-types._index.tsx` |
| 中 | 规则绑定前端 UI | 文档类型编辑页中选规则集的控件 |
| 中 | 前端规则集选择器 | 对接 `/api/rule-sets` 或现有规则接口 |
| 低 | prompt_config 编辑 | 每个文档类型的提示词模板配置 |

---

## 四、推荐接入方案

### 第 1 步：文档类型 CRUD 后端

```
GET    /api/document-types          ← 已实现
POST   /api/document-types          ← 新增
PUT    /api/document-types/{id}     ← 新增
DELETE /api/document-types/{id}     ← 新增
```

字段：`code`, `name`, `description`, `entry_module_id`, `prompt_config`, `rule_set_ids`（一次性处理绑定）

### 第 2 步：规则绑定 CRUD

两种方案：
- **方案 A**（推荐）：绑定内嵌到文档类型接口。创建/更新文档类型时传 `rule_set_ids: [21, 31]`，后端自动维护 `leaudit_rule_type_bindings`。
- **方案 B**：独立绑定接口 `POST/DELETE /api/rule-type-bindings`。

推荐方案 A，因为绑定是文档类型的属性，一起管理更自然。

### 第 3 步：前端文档类型管理页

参考旧前端 `document-types._index.tsx` / `document-types.new.tsx`，用新 API 重写：
- 列表页：表格展示 code/name/entry_module/规则集数量
- 新建/编辑页：表单填 code/name/entry_module，多选规则集

### 第 4 步：上传页关联

上传时将 `typeCode` 写入 `leaudit_documents.type_id` → 运行时自动找绑定 → 加载规则集 → 执行评查。整个链路已通，只需确保文档类型数据存在。