feat: complete signature and drainage reporting workflows

docs/first-version-development-requirements.md

@@ -1182,10 +1182,14 @@
 8. 回执导入。
 9. 报备记录。
 10. 签名报备状态同步。
+11. 引流信息按通道报备任务、报备记录和回执。
+12. 企业签名、通道报备详情、报备任务三个入口共用同一报备状态事实源。
 
 验收标准：
 
 - 签名审核状态和通道报备状态分层。
+- 运营端提供真实签名审核列表、资料详情和通过/驳回操作；运营端直接新建的签名自动审核通过并写审核记录。
+- 引流信息按“报备字段库 → 通道配置引流字段 → 企业签名提交资料 → 通道报备任务”流转，不使用 JSON 中的静态三网状态代替任务状态。
 - 发送前必须校验签名在目标通道报备通过。
 - 报备任务导出、导入具备幂等和历史记录。
 

docs/system-functional-test-cases.md

@@ -233,6 +233,18 @@
   - 驳回原因保存并返回客户端。
   - 被驳回模板不能用于发送。
 
+### TC-ADMIN-001A 运营端新建签名自动通过
+
+- 优先级：P0
+- 前置条件：运营管理员已登录，目标企业和应用存在。
+- 步骤：
+  1. 在运营端企业签名页新建签名并保存。
+  2. 查询签名列表、签名审核页和审核记录。
+- 预期结果：
+  - `SmsSignature.auditStatus=approved`，不停留在 draft。
+  - 生成 `admin_create_approved` 审核记录。
+  - 客户端自行新建签名仍按 draft → pending → approved/rejected 流转。
+
 ### TC-ADMIN-003 通道创建与启停
 
 - 优先级：P0
@@ -308,6 +320,20 @@
   5. 查询 PostgreSQL 中签名、签名报备材料和引流报备材料记录；删除该引流项后再次查询。
 - 预期结果：
   - 营业执照按字段库 ID 合并为一个字段，且因任一目标通道必填而整体必填；签名弹窗展示营业执照，引流弹窗展示网站主体及两者共用字段。
+
+### TC-ADMIN-005B 引流信息按通道报备及三入口同步
+
+- 优先级：P0
+- 前置条件：企业应用已绑定通道组，至少一个目标通道配置 `drainage` 或 `both` 报备字段。
+- 步骤：
+  1. 在企业签名中新增引流信息，填写动态字段并保存。
+  2. 查询 `DrainageReportMaterial` 和 `ChannelSignatureReportTask(reportType=drainage)`。
+  3. 分别从企业签名、通道报备详情、报备任务页修改同一引流项在同一通道的状态。
+  4. 查看报备记录，导出任务并导入回执。
+- 预期结果：
+  - 每个“签名 + 引流项 + 通道”对应独立真实任务，初始为 pending。
+  - 三个入口的状态和通过数/总数一致，修改写入 `ChannelSignatureReportRecord`。
+  - 引流任务不参与 `SmsSignature.reportStatus` 聚合，也不能被短信发送选路误当为签名报备通过。
   - 字段库页面只提供字符串、图片、文件三种类型；API 对其他类型返回 400，历史其他类型迁移为字符串。
   - 缺少必填资料时前端禁止提交；直接调用 API 也返回 400，不能绕过页面保存不完整资料。
   - 文件通过真实对象存储上传；动态值随签名 JSON 保存，并按来源通道分别写入规范化报备材料表。

docs/testing-progress.md

@@ -1668,3 +1668,12 @@ git diff --check
 - 本地验证：API 全量 13 suites、137 项通过，API build、前端 build、`git diff --check` 通过；前端仅有既有 chunk size warning。Chrome 当前无已登录生产标签，部署前未绕过图形验证码或注入 mock 数据。
 - 已将功能提交 `19d47b45` push 到 `origin/main` 并部署生产。部署前备份 PostgreSQL 为 `/opt/cmpp-platform/backups/cmpp-20260713-103205.sql`（约 61MB），备份运行源码为 `/opt/cmpp-platform/backups/source-20260713-103205.tar.gz`（约 63MB）；发布快照本地/服务器 SHA-256 一致。生产无待执行 migration，`.deployed-commit=19d47b45`，`cmpp-api`、`cmpp-gateway`、Nginx、MinIO 均为 active，`12026/17890/8090/3000` 监听，API/Gateway health 和外部 HTTP 200。生产 `index.html` 已引用新资源 `index-HtuLnrXL.js/index-C5Tf8YiT.css`，源码已确认包含企业模板响应式行和签名操作区两列布局。
 - 生产浏览器确认路由可加载、标题为“聆界短信管理平台”、DOM 非空、无 console error/warn 和框架错误覆盖。由于浏览器没有已登录运营端会话，访问受保护页面按预期落到登录界面；未经用户确认不代解图形验证码，因此登录后真实数据截图和点击交互留待用户刷新生产页面验收。
+
+## 2026-07-13 签名审核与引流信息通道报备闭环
+
+- 生产只读核查确认：运营端新建的【安徽航天信息】仍为 `auditStatus=draft`；引流资料保存在 `SmsSignature.drainageInfo.links`，动态字段可写 `DrainageReportMaterial`，但缺少引流项维度的真实通道报备任务和记录。
+- 将 `/admin/signatures` 从占位页替换为真实签名审核页，支持状态查询、资质/动态资料详情、通过和带原因驳回，调用现有 NestJS 审核 API 并写 `AuditRecord`。运营端新建签名直接写 `auditStatus=approved`，同时写 `admin_create_approved` 审核记录；客户端提交审核流不变。
+- `ChannelSignatureReportTask` 增加 `reportType=signature/drainage` 和 `drainageItemId`。保存引流资料时，根据企业应用的真实路由通道及其 `drainage/both` 字段自动生成 pending 任务和 create 记录；删除引流项时同步清理对应材料和任务。
+- 企业签名引流列表、通道报备详情、报备任务页均按引流项和通道读取/修改同一任务，共享报备记录、导出和回执链路。企业签名三网状态改为引流任务真实汇总，不再使用 `drainageInfo.links.mobile/unicom/telecom` 静态值。
+- 短信发送选路和最终通道二次校验明确增加 `reportType=signature`，引流通过任务不会误放行未报备签名。Prisma migrations：`20260713153000_add_drainage_report_tasks`、`20260713154000_backfill_drainage_report_tasks`、`20260713155000_unique_report_task_scope`；后两者分别回填已有引流材料的 pending 任务/记录，并保证同一报备对象和通道仅一个任务。
+- 本地真实 PostgreSQL 已成功应用 3 条新 migration；API 全量 13 suites、139 项通过，Gateway 全量 Go 测试、Prisma validate、API build、前端 build 和 `git diff --check` 通过，前端仅有既有 chunk size warning。应用内浏览器确认本地运营端登录路由标题正确、DOM 非空、无框架错误覆盖且 console 无 error/warn；真实图形验证码阻止进入受保护页，未代解验证码、未绕过认证、未注入 mock。