feat: inherit channel report requirements

docs/first-version-development-requirements.md

@@ -180,15 +180,16 @@
 
 ### 4.7 通道签名报备
 
-1. 运营端在通道配置中维护签名报备字段。
-2. 客户端上传签名资料。
-3. 运营端审核企业签名资料。
-4. 运营端在通道资料更新后生成通道签名报备任务。
-5. 运营端在报备任务中导出通道报备资料。
-6. 运营端在报备任务或通道报备详情页导入通道回执。
-7. 系统根据回执同步签名在各通道的报备状态。
-8. 报备记录保留每次导出、导入、状态变更和操作人。
-9. 发送前必须校验最终选中通道上的签名报备任务为 approved；补发切换到新通道时必须重新按新通道校验报备状态，未通过则该次发送失败。
+1. 运营端先在“报备字段库”维护字段编码、名称、类型、是否必填等标准定义；通道报备详情只能从字段库选择字段，并指定用途为签名报备、引流信息报备或两者共用，不得在通道内另建同名孤立字段。
+2. 通道组配置通道，企业应用通过路由规则选择通道组。企业签名和引流信息编辑时，系统必须沿“企业应用 -> 生效路由规则 -> 通道组 -> 组内通道 -> 通道报备字段”实时解析字段合集。
+3. 同一字段被多个通道引用时按字段库记录去重；任一通道将该字段配置为必填，则企业资料中按必填处理，并保留该字段来源的全部通道用于后续分别报备。
+4. 企业签名弹窗只展示签名报备/两者共用字段；每条引流信息只展示引流信息报备/两者共用字段。文件字段走真实对象存储上传，其他字段保存真实值，必填校验同时在前端和 NestJS API 执行。
+5. 企业资料保存后，原始动态值随签名 JSON 保存，同时按实际目标通道分别写入签名报备材料和引流报备材料表，供通道报备任务导出使用；删除引流项时同步清理其规范化材料记录。
+6. 客户端上传签名资料，运营端审核企业签名资料。
+7. 运营端在通道资料更新后生成通道签名报备任务，并在报备任务中导出通道报备资料。
+8. 运营端在报备任务或通道报备详情页导入通道回执，系统根据回执同步签名在各通道的报备状态。
+9. 报备记录保留每次导出、导入、状态变更和操作人。
+10. 发送前必须校验最终选中通道上的签名报备任务为 approved；补发切换到新通道时必须重新按新通道校验报备状态，未通过则该次发送失败。
 
 ### 4.8 CMPP Gateway 与外部接入
 

docs/system-functional-test-cases.md

@@ -296,6 +296,22 @@
   - 生成导出文件记录。
   - 报备记录包含 create/export 两个动作。
 
+### TC-ADMIN-005A 报备字段库到企业资料动态继承
+
+- 优先级：P0
+- 前置条件：存在两个 active 通道、一个包含这两个通道的通道组，以及绑定该通道组的企业应用。
+- 步骤：
+  1. 在报备字段库创建文件字段“营业执照”和文本字段“网站主体”。
+  2. 在通道一将营业执照配置为签名报备必填，在通道二将同一字段配置为两者共用非必填，并将网站主体配置为引流信息报备必填。
+  3. 打开该企业应用下的企业签名编辑弹窗和引流信息编辑弹窗。
+  4. 分别尝试缺少必填值保存，再补齐文件和值后保存。
+  5. 查询 PostgreSQL 中签名、签名报备材料和引流报备材料记录；删除该引流项后再次查询。
+- 预期结果：
+  - 营业执照按字段库 ID 合并为一个字段，且因任一目标通道必填而整体必填；签名弹窗展示营业执照，引流弹窗展示网站主体及两者共用字段。
+  - 缺少必填资料时前端禁止提交；直接调用 API 也返回 400，不能绕过页面保存不完整资料。
+  - 文件通过真实对象存储上传；动态值随签名 JSON 保存，并按来源通道分别写入规范化报备材料表。
+  - 删除引流项后，对应引流报备材料记录被同步删除，不保留可被后续导出误用的孤立资料。
+
 ### TC-ADMIN-006 报备回执导入通过
 
 - 优先级：P0

docs/testing-progress.md

@@ -1618,3 +1618,13 @@ git diff --check
 - 聚合窗口关闭前，任务不返回到待审列表且审核接口拒绝提前操作，避免窗口内后到短信加入已完成任务。
 - Prisma migration：`20260712113000_add_cmpp_review_aggregation`。已执行 API 全量测试（13 suites、129 项通过）、API build、前端 build、Prisma validate 和 `git diff --check`。
 - 已将 `8b6ec92f` 部署生产，部署前完成 PostgreSQL 和发布源码备份，migration 已成功应用。`SmsSendTask` 5 个聚合字段、`SmsMessageRecord.reviewTaskId/signatureId` 均已存在；生产应用中 `manual_review` 3 个、`reject` 201 个。审核 API 返回 200，当前无待审样本，未为验收人工注入短信或修改业务数据。`cmpp-api`、`cmpp-gateway`、Nginx、MinIO 均为 active，`12026/17890/8090/3000` 监听、API/Gateway health 和外部 `12026` HTTP 均通过。
+
+## 2026-07-12 报备字段库到企业签名/引流资料完整链路
+
+- `ChannelReportField` 通过 `drainageFieldId` 真实关联报备字段库，并增加 `reportType=signature/drainage/both`；通道报备配置页改为选择字段库字段和报备用途，不再在通道内手工复制字段编码、名称和类型。
+- 新增企业应用报备字段解析 API，按生效的应用路由规则遍历通道组及组内通道，以字段库 ID 求合集；同字段任一通道必填即整体必填，并返回全部来源通道。
+- 企业签名与引流信息弹窗根据所选企业应用动态加载字段合集。签名只展示签名/共用字段，引流项只展示引流/共用字段；文件字段继续走真实 MinIO/对象存储上传，文本值和文件对象 ID 均提交 NestJS API。
+- API 在写签名前执行必填校验，防止绕过前端；保存后同步写入各目标通道的 `SignatureReportMaterial` 和新增的 `DrainageReportMaterial`，删除引流项时同步清理旧材料。
+- 为避免运营人员面对动态资料时无法理解来源，签名和引流编辑页增加“通道组数/通道数/字段数/必填数”摘要、字段级来源说明和“为什么需要这些资料”解释弹窗；弹窗按企业应用、通道组、通道逐级展示字段用途及必填口径。每次保存同时在签名 JSON 中固化 `reportRequirementSnapshot`，记录当时的字段与来源通道，供配置变化后的历史追溯。
+- Prisma migration：`20260712150000_link_report_field_library`。已执行 Prisma generate/validate、`channels.service.spec.ts + sms-config.service.spec.ts`（2 suites、44 项通过）、API build 和前端 build；前端仅有既有 chunk size warning。
+- 本轮按用户要求仅完成本地代码与验证，尚未提交、push 或部署生产。