leaudit-platform-backend/docs/权限与地区隔离/新平台评查点与评查组真实模型梳理.md

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

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

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