# 内部公文模块数据表复用与新增建议

## 1. 结论

数据表不需要“全部重新建”，但也不建议“全部硬复用当前项目现有表”。

最合理的方式是：

- 复用当前项目已有的“平台公共表”
- 新建 `govdoc` 自己的“结果域表”
- 不要把公文模块的运行和结果强塞进现有 `leaudit` 专属结果表

一句话：

- 主档能复用
- 结果别乱复用

---

## 2. 建议直接复用的表

以下属于平台级公共能力，建议直接复用：

### 2.1 用户与权限相关

- `sso_users`
- `roles`
- `user_role`
- `permissions`
- `role_permissions`
- `sys_routes`
- `role_route`

这些负责：

- 用户身份
- JWT 登录态
- RBAC 授权
- 菜单显示
- 接口动作权限

### 2.2 文档主档相关

- `leaudit_documents`
- `leaudit_document_files`

这些负责：

- 文档主记录
- 文件版本
- 文件角色
- 所属地区
- 创建人
- OSS 路径关联

### 2.3 存储与任务基础设施

虽然不是数据表，但这些平台能力也必须复用：

- OSS / MinIO
- Celery
- 当前统一配置体系

---

## 3. 为什么文档主档可以复用

从平台视角看，公文本质上也是文档。

当前 `DocumentServiceImpl` 已经处理了很多平台公共问题：

- 上传
- 文档类型归属
- 地区归属
- 文件版本
- OSS 存储
- 创建人
- 列表查询
- 数据隔离

这说明：

- `leaudit_documents` 更像平台级文档主表
- 不只是某一个引擎专属表

所以公文模块完全可以这样接：

- 公文先入 `leaudit_documents`
- 文件入 `leaudit_document_files`
- 再通过模块标识或引擎标识决定后续执行链

---

## 4. 建议补充的主档字段

建议在 `leaudit_documents` 增加一个模块或引擎标识字段，例如：

- `engine_type`

可选值例如：

- `leaudit`
- `govdoc`
- `rag`

或者使用：

- `biz_module`

作用是让平台明确知道：

- 这份文档属于哪个处理模块
- 应走哪条执行链
- 应展示哪套结果详情页面

这个字段非常关键。

---

## 5. 不建议直接复用的现有结果表

不建议直接复用的主要是“运行结果型表”，例如：

- `leaudit_audit_runs`
- `leaudit_rule_results`
- 以及现有 `leaudit` 引擎专属的 metrics / extraction / rescue 一类结果表

原因如下。

### 5.1 字段语义会越来越脏

当前 `leaudit` 的运行结果表，天然围绕现有审查引擎设计，可能包含：

- phase
- OCR / extract / rescue 阶段
- ruleSetId / ruleVersionId
- resultStatus
- rescueApplied
- 当前引擎专属 timing / metrics

而 `govdoc` 运行时更关注：

- 公文结构解析
- 标题 / 发文字号 / 文种 / 附件识别
- 段落级 findings
- HTML / annotated docx / paragraph html 报告

表面上都叫 run，但含义并不完全相同。

### 5.2 结果明细模型不完全兼容

`govdoc-audit` 的单条 finding 更像：

- `rule_id`
- `rule_name`
- `severity`
- `category`
- `location.paragraph_index`
- `message`
- `suggestion`
- `actual`
- `expected`
- `evidence`

它非常强调：

- 段落定位
- 文档结构位置
- 格式问题

而当前 `leaudit_rule_results` 更可能偏：

- 评查点
- 提取字段
- 风险
- rescue 翻转
- 审核结果

两者不是一个结果语义世界。

### 5.3 后续统计口径容易混乱

如果共用结果表，后面做统计时会不断出现问题：

- 这个 `passed_count` 是公文规则通过数，还是合同规则通过数？
- 这个 `failed_count` 是格式错误项数，还是评查点失败数？
- 这个 `score` 的计算口径是否一致？

最终会逼着所有查询都加一层 `engine_type` 判断。

### 5.4 迁移与回滚成本更高

架构上：

- 从专属表改回公共表，容易
- 从硬复用公共表再拆出来，很痛苦

所以结果域隔离更稳。

---

## 6. 最推荐的折中方案

最佳折中不是“全新建”，也不是“全复用”，而是：

- 1 套平台主档
- 1 个模块标识字段
- 1 套 `govdoc` 结果域表

### 6.1 第一层：复用公共文档主档

继续使用：

- `leaudit_documents`
- `leaudit_document_files`

负责：

- 上传文档主记录
- 保存文件版本
- 地区归属
- 创建人
- OSS 路径

### 6.2 第二层：补充模块标识

在 `leaudit_documents` 增：

- `engine_type = 'govdoc'`

这样主档表知道：

- 这是一份由公文模块消费的文档

### 6.3 第三层：新增公文结果域表

建议新增：

- `govdoc_runs`
- `govdoc_rule_results`
- `govdoc_entities`
- `govdoc_report_artifacts`

好处：

- 上传、权限、地区、OSS 全复用
- 结果和运行态不污染原系统
- 前端查询和统计都清晰

---

## 7. 如果想极限少建表，最少也要新建哪几张

如果希望第一阶段尽量少建表，建议最少也要新建 3 张：

- `govdoc_runs`
- `govdoc_rule_results`
- `govdoc_report_artifacts`

可选第 4 张：

- `govdoc_entities`

如果想更快推进，`entities` 也可以先临时塞进 `govdoc_runs.result_json` 之类字段里，但长期仍建议拆表。

---

## 8. 什么情况下可以复用当前 `leaudit_audit_runs`

只有一种情况可以考虑：

先把 `leaudit_audit_runs` 正式重构为“平台通用引擎运行表”，明确它不再是 `leaudit` 私有运行表。

此时至少要补齐类似字段：

- `engine_type`
- `biz_module`
- `result_summary_json`
- `artifact_manifest_json`

然后让：

- `leaudit`
- `govdoc`

都成为这张“通用运行表”的消费者。

但要注意，这已经不是“直接复用原表”，而是：

- 先重构当前表
- 再让它变成通用表

这条路能走，但复杂度明显高于“新建 `govdoc_runs`”。

当前阶段，更推荐后者。

---

## 9. 明确建议

我的明确建议是：

- 不用全部重建
- 但也不要零成本硬复用全部现有结果表

最佳实践：

- 复用 `用户 / 权限 / 地区 / 文档主档 / 文件主档 / OSS / 任务系统`
- 新建 `govdoc` 的 `run + result + artifact` 结果域表

即：

**复用公共底座，新建领域结果。**

---

## 10. 推荐最终表划分

### 10.1 复用

- `sso_users`
- `roles`
- `user_role`
- `permissions`
- `role_permissions`
- `sys_routes`
- `role_route`
- `leaudit_documents`
- `leaudit_document_files`

### 10.2 建议补字段

- `leaudit_documents.engine_type`
- 或 `leaudit_documents.biz_module`

### 10.3 新增

- `govdoc_runs`
- `govdoc_rule_results`
- `govdoc_entities`
- `govdoc_report_artifacts`

后续规则平台化时再补：

- `govdoc_rule_sets`
- `govdoc_rule_versions`

---

## 11. 最终落地建议

如果现在立刻开始实施，建议按下面这版定：

1. `leaudit_documents` / `leaudit_document_files` 继续复用
2. 在 `leaudit_documents` 增加 `engine_type='govdoc'`
3. 新建 `govdoc_runs`
4. 新建 `govdoc_rule_results`
5. 新建 `govdoc_report_artifacts`
6. 后续视情况补 `govdoc_entities`

这是一版：

- 改动面适中
- 风险最小
- 迁移成本可控
- 长期仍可扩展

非常适合当前项目阶段。
