# 新平台评查点与评查组真实模型梳理

## 1. 先给结论

前面把“新平台评查点”理解成老库 `evaluation_points` 主表，这是错误的。

当前代码里实际上并存两套链路：

1. 新平台主链路
   `入口模块 -> 一级业务大类分组 -> 二级业务子类型分组 -> 规则集 -> 规则版本(YAML) -> 文档评查结果`

2. 旧兼容链路
   `/api/v3/evaluation-points` -> `docauditai.evaluation_points`

也就是说：

- 新平台“评查组/评查点分组”是真正的主配置骨架。
- 新平台运行时真正承载评查规则内容的，不是 `evaluation_points` 行数据，而是 `leaudit_rule_sets + leaudit_rule_versions` 中的 YAML 规则。
- 旧的“评查点管理”页面和 `/v3/evaluation-points` 目前仍然挂在老库兼容链路上，还没有完全切到新平台主模型。

## 2. 新平台真实对象关系

### 2.1 一级分组不是老地区分组

新平台一级分组已经不是“梅州/揭阳/省级”这种地区概念，而是业务大类根：

- 合同
- 行政卷宗
- 后续新增业务大类

对应证据：

- `scripts/创建sql/migrate_rule_groups_to_business_roots.sql`
- `fastapi_modules/fastapi_leaudit/services/impl/documentServiceImpl.py`
- `fastapi_modules/fastapi_leaudit/services/impl/evaluationPointGroupServiceImpl.py`

其中迁移脚本已经把目标写得很清楚：

- 一级分组 = 业务大类
- 二级分组 = 具体业务类型
- 规则集 = 挂在二级分组下
- 入口模块 = 绑定一级分组

### 2.2 二级分组才是运行时的“业务子类型”

二级分组必须绑定具体 `document_type_id`，用于表达：

- 建设工程合同
- 买卖合同
- 行政许可-新办
- 行政许可-延续

上传文档时，后端校验 `group_id` 是否属于当前 `document_type_id`，见：

- `documentServiceImpl.py` 中 `_resolveDocumentGroupId`

说明当前系统真实运行时，文档已经开始依赖：

- 文档类型
- 二级分组
- 一级根分组

而不是依赖老 `evaluation_points` 主表。

### 2.3 真正承载“评查点内容”的是规则集与规则版本

新平台分组页不是在维护老式点表，而是在维护：

- `leaudit_rule_group_bindings`
- `leaudit_rule_sets`
- `leaudit_rule_versions`

并且“新建规则集/YAML”动作会：

1. 根据二级分组推导 `rule_type`
2. 调用 `RuleService.CreateVersion(...)`
3. 生成规则版本 YAML
4. 反查对应 `rule_set_id`
5. 自动把规则集绑定到当前二级分组

对应代码：

- `evaluationPointGroupServiceImpl.py` 中 `CreateRuleDraft`
- `ruleServiceImpl.py` 中 `CreateVersion` / `ListSets` / `GetContent`

这说明新平台里的“评查点”更接近：

- 规则 YAML 中的一条条规则项
- 或某个规则集里的规则集合

而不是老系统那种独立的 `evaluation_points` 业务主表记录。

## 3. 前端页面语义已经分叉

### 3.1 `rule-groups` 页面是新平台主入口

前端 `RuleGroupsClient.tsx` 的语义已经非常明确：

- 展示一级业务大类
- 展示二级子类型
- 给二级子类型绑定规则集
- 直接创建规则 YAML 草稿
- 查看规则集可用版本和可用规则数

这页对应的是新平台主模型，不是老分组页换皮。

### 3.2 `rules/list`、`rules/new` 仍然是旧评查点页面

前端这两页仍在调用：

- `/api/v3/evaluation-points`

后端服务 `EvaluationPointServiceImpl` 明确连接：

- `LEGACY_RULE_DB_NAME`
- 默认库 `docauditai`

说明这两页还是旧兼容页面，并没有真正迁到新平台主链路。

## 4. 文档评查运行链路怎么命中分组

当前文档链路已经和新分组模型发生真实耦合：

1. 文档上传时可带 `group_id`
2. 后端校验该 `group_id` 必须是有效二级分组
3. 系统再反解一级根分组，用于归档和版本链路
4. 文档列表、详情、统计也会回查 `leaudit_evaluation_point_groups`

对应代码集中在：

- `documentServiceImpl.py`

这意味着：

- 分组模型已经进入实际业务运行面
- 它不是“还没启用的设计稿”

## 5. 为什么我前面会判断错

因为仓库里仍保留了“评查点管理”老接口与老页面：

- `EvaluationPointController`
- `EvaluationPointServiceImpl`
- `legal-platform-frontend/app/(audit)/rules/*`

它们让表面上看起来仍像“评查点主表驱动”。

但继续往下看新分组页、规则集页、文档上传与文档评查链路，就会发现当前新平台实际已经是：

- 分组承接业务结构
- 规则集承接规则内容
- 文档按分组与规则集运行

所以真正的问题不是“给老 `evaluation_points` 补 tenant_code 就完了”，而是：

- 哪些页面仍停留在旧兼容链路
- 哪些运行链路已经切到新分组模型
- 租户边界应该落在新分组/文档/规则集哪一层

## 6. 当前最重要的纠偏结论

### 6.1 不应再把旧 `evaluation_points` 当成新平台主模型

旧链路只能视为：

- 兼容管理页
- 过渡接口
- 待迁移遗留

不能再把它作为后续“租户化/权限化/评查模块改造”的主战场。

### 6.2 新平台真正要分析的核心表

后续围绕评查点/评查组，应优先分析这些对象：

- `leaudit_evaluation_point_groups`
- `leaudit_rule_group_bindings`
- `leaudit_rule_sets`
- `leaudit_rule_versions`
- `leaudit_documents.group_id`
- `leaudit_review_point_audits`

### 6.3 “评查点”一词在当前系统里有双重含义

当前仓库里“评查点”至少有两层语义：

1. 旧语义
   老库 `evaluation_points` 里的单条配置记录

2. 新语义
   规则集/YAML 里的具体规则项，以及文档评查结果里的单个 review point

后续文档和代码改造必须把这两个概念拆开命名，否则一定继续误判。

建议统一命名：

- 旧链路：`legacy_evaluation_point`
- 新链路配置骨架：`rule_group / subtype_group`
- 新链路规则内容：`rule_set / rule_version / yaml_rule`
- 运行结果：`review_point_result`

## 7. 对后续改造的直接影响

### 7.1 评查模块后续工作应拆成两条线

第一条：新平台主链路

- 分组
- 文档类型
- 入口模块
- 文档上传
- 规则集绑定
- 评查运行结果

第二条：旧兼容链路

- `/v3/evaluation-points`
- 旧评查点列表/新增/编辑页面
- 老库 `docauditai.evaluation_points`

### 7.2 现在优先级更高的不是“继续补旧点评租户字段”

而是先回答这几个问题：

1. 新平台二级分组是否需要直接租户化
2. 规则集绑定是否需要租户边界
3. 文档上传时的 `group_id` 选择是否需要按租户过滤
4. 文档评查结果是否需要按租户隔离回查
5. 旧 `rules/list` 与 `rules/new` 是否继续保留，还是迁入新规则集页

## 8. 下一步建议

建议后续按下面顺序继续：

1. 先梳理“新平台主链路的租户边界设计”
   重点看：入口模块、文档类型、一级分组、二级分组、文档上传、文档列表、规则集绑定

2. 再单独梳理“旧评查点兼容链路去留方案”
   明确：
   - 继续兼容多久
   - 是否只读
   - 是否要做迁移映射

3. 最后才决定是否还要继续改 `/v3/evaluation-points`

否则会继续在“旧兼容页”和“新运行主链路”之间来回误伤。