docs(requirements): 补充飞书接入与法规规则源口径

docs/需求分析/3.documents模块需求分析.md

@@ -18,6 +18,8 @@
 4. 为法规完整性核查和一致性核查提供可靠的文档底座。
 5. 为抽取、回填、审计和导出提供统一的文档主数据。
 
+结合新增公告材料，本模块还应承担“法规原文资料资产管理”的基础职责，即把上传的业务资料与平台内置的法规依据材料区分管理。
+
 ## 3. 为什么 Documents 模块是本题核心
 
 题面第一条就要求“自动汇总注册申报文件夹中的所有文件及页数”，第二条要求“对照 NMPA 法规要求核查文件完整性”。这两个要求都建立在一个前提上：
@@ -40,6 +42,13 @@
 
 必要时为后续 OCR 或图片扫描件预留扩展位。
 
+除用户上传的申报资料外，系统还需要支持管理平台内置法规资料，例如：
+
+- 注册申报资料要求及说明
+- 批准证明文件格式要求
+- 安全和性能基本原则清单
+- 注册证 / 变更注册（备案）文件格式
+
 ### 4.2 文件基础信息管理
 
 每份资料至少要记录：
@@ -53,6 +62,13 @@
 - 所属任务或场景
 - 当前处理状态
 
+对于法规资料，建议额外记录：
+
+- 法规类型
+- 法规流程类型
+- 版本来源
+- 是否为系统内置规则依据
+
 ### 4.3 页数统计与目录归属
 
 系统要能为每份文件识别：
@@ -79,6 +95,13 @@
 
 对适合检索的内容建立索引，供 `agent_core` 的 RAG 或规则定位使用。
 
+对法规原文资料，建议单独建立“法规知识索引”，切片时优先保留以下结构语义：
+
+- 所属法规文档
+- 适用流程类型
+- 章 / 条 / 清单项编号
+- 模板字段或格式要求类型
+
 ### 4.6 状态反馈与异常处理
 
 文件处理流程要有明确状态，例如：
@@ -145,6 +168,19 @@
 
 这些字段会直接影响后续审核可信度。
 
+#### 5.2.4 规则来源字段
+
+建议增加：
+
+- `source_role`
+  区分“业务申报资料”与“法规依据资料”。
+
+- `workflow_type`
+  区分 `registration`、`change`、`renewal` 等流程类型。
+
+- `format_template_type`
+  标记该文件是否属于批准证明文件格式模板。
+
 ## 6. 关键业务流程需求
 
 ### 6.1 文件上传流程
@@ -169,6 +205,13 @@
 
 如果自动识别不确定，应标记为“待人工确认”，而不是强行归类。
 
+对于法规资料，还应进一步识别其所属层级，例如：
+
+1. 资料要求说明
+2. 格式要求说明
+3. 安全和性能基本原则
+4. 批准证明文件格式
+
 ### 6.3 页数统计流程
 
 页数统计是本题显式要求，需支持：
@@ -230,6 +273,15 @@ Documents 模块应能直接输出一份“资料目录总览”，字段建议
 
 `CH1.9 产品申报前沟通的说明.doc` 体现出历史申报背景和监管沟通信息，这类文件在合规审查中重要性很高，应单独分类标记。
 
+### 7.4 要能区分业务资料与法规依据资料
+
+结合新增公告材料，Documents 模块应把以下两类材料明确分开管理：
+
+1. 待审核的业务申报资料
+2. 用于审核的法规依据与模板资料
+
+否则后续在索引、引用和一致性检查时，容易把法规模板错误混入业务资料集合。
+
 ## 8. 列表页与上传页需求
 
 ### 8.1 文档列表页需求
@@ -284,6 +336,8 @@ Documents 不负责审计结论，但应为审计提供文档 ID、处理过程
 
 第 6 点尤其重要，因为当前样例材料已经体现出不同产品信息混杂的问题。
 
+此外，还应避免把法规依据资料误当成业务申报资料写入同一业务索引集合。
+
 ## 11. 首版建议的可交付结果
 
 首版建议 Documents 模块至少能产出三类结果：
@@ -309,6 +363,7 @@ Documents 不负责审计结论，但应为审计提供文档 ID、处理过程
 3. 增加表格抽取和目录类文件识别。
 4. 增加文档归类与页数统计能力。
 5. 增加重复版本识别和疑似混档识别。
+6. 增加法规资料类型识别与业务资料 / 法规资料隔离管理。
 
 ## 13. 验收标准