feat: complete reporting and filing workflows

docs/first-version-development-requirements.md

@@ -303,7 +303,7 @@
 - 已实现下游恢复控制第一版：Gateway 对恢复候选账号增加账号级恢复锁、失败/等待连接退避和恢复状态持久化，避免同一账号被并发重复恢复或每轮高频空转；控制面新增 `GET /downstream/recovery-statuses` 可查看最近一次恢复状态、重试次数、下一次可恢复时间和错误原因。
 - 已实现下游恢复观测第一版：控制面新增 `GET /downstream/recovery-overview`，一次性返回恢复候选账号与恢复状态，便于联调和生产排查。
 - 已实现下游恢复状态回流第一版：Gateway 在每次恢复状态变化后，调用 NestJS `/api/gateway/events/downstream/recovery-status` 真实回传账号恢复状态；NestJS 将状态写入 Prisma/PostgreSQL `GatewayDownstreamRecoveryStatus`。
-- 已实现下游恢复状态运营化第一版：运营端新增独立“恢复状态管理”页面，支持真实列表、分页、详情查看和当前筛选结果 CSV 导出；原“下游投递记录”页面只保留投递记录本身，不再混放恢复状态区块。
+- 已实现下游恢复状态运营化第一版：运营端新增独立“恢复状态管理”页面，明确说明该页用于观察客户重连或 Gateway 重启后的未完成下游投递恢复，每个账号展示当前或最近一次恢复状态；支持按最近更新时间筛选（默认近 7 天）、真实列表、分页、详情查看和当前筛选结果 CSV 导出。原“下游投递记录”页面只保留逐条投递记录并默认查询近 7 天，不再混放恢复状态区块。
 - 已实现下游恢复失败分类第一版：Gateway/NestJS 共同维护 `failureCategory`，覆盖 `client_disconnected`、`backoff`、`lock_contended`、`lock_lost`、`flush_failed`、`partial_delivery_failed`、`unknown`；运营端“恢复状态管理”页面支持失败分类筛选、分类分布统计、详情展示和导出字段。
 - 已实现多 Gateway 恢复抢占协调第一版：恢复锁从单纯实例名升级为 Redis token 租约，状态记录 `lockOwner/lockExpiresAt`；恢复完成时必须通过 Lua 原子校验锁 token，只有持锁实例才能写入最终恢复状态并释放锁，避免旧实例超时后误删新实例锁或覆盖新实例恢复结果；运营端详情/列表可查看锁持有实例。
 - 已实现长短信分片审计第一版：Gateway `SubmitResult` 回传真实 `segments[]`，包含 `segmentTotal/segmentIndex/sequenceId/gatewayMessageId/submitStatus/submittedAt`；NestJS 写入 Prisma/PostgreSQL `SmsMessageSegmentAudit`，回执按 `gatewayMessageId` 回填分片回执状态，补偿归因可记录 `compensationType`；运营端短信记录详情可查看真实分片提交、回执和补偿审计。
@@ -555,8 +555,8 @@
 - 在“数据详单”之后增加“报表对账”一级菜单，包含“对账单”和“利润报表”两个二级菜单；页面必须读取真实 NestJS API 与 PostgreSQL 报表表，不得在前端按明细临时拼接或使用静态数据。
 - 对账单按发送日期、企业、企业应用汇总日发送条数和成功条数。发送条数、成功条数均按短信计费条数 `billingUnits` 统计，成功以最终 `delivered` 状态为准。
 - 利润报表按发送日期汇总日发送条数、成功条数、消费金额、成本金额、利润和利润率，支持在“企业应用”和“通道”两个统计维度间切换。
-- 企业应用维度的消费金额只统计仍为 `charged` 的客户账单，最终失败并退款的短信不再形成收入；成本金额统计该应用短信所有上游 `accepted` 提交的通道成本，包括补发产生的真实额外成本。
-- 通道维度按实际上游 `accepted` 提交统计发送量和成本，按同一 Gateway 消息回执统计成功量；客户收入只归属最终有效提交，避免补发时重复计算收入。通道成本单价和成本金额必须在提交记录创建时快照，后续修改通道单价不得改写历史成本。
+- 企业应用维度的消费金额只统计仍为 `charged` 的客户账单，最终失败并退款的短信不再形成收入；成本金额按每次真实提交的通道成本单价快照乘以该次提交最终成功的短信分片数计算。补发只有产生成功分片时才增加对应通道成本，失败、未知或尚未收到成功回执的分片不计成本。
+- 通道维度按实际上游 `accepted` 提交统计发送量，按分片回执统计成功量和成本；客户收入只归属最终有效提交，避免补发时重复计算收入。通道成本单价必须在提交记录创建时快照，后续修改通道单价不得改写历史成本；历史缺少分片审计但存在明确成功回执时，才按该次短信计费分片数兼容计算。
 - 利润等于消费金额减成本金额；利润率等于利润除以消费金额，消费金额为 0 时利润率按 0 展示。所有金额使用 `0.0001 元`整数金额单位持久化并按四位小数展示。
 - 报表按北京时间 T+1 生成，不生成当天未完整数据；每日刷新时必须在同一事务内重新生成 T-4 至 T-1 四个完整自然日，使 72 小时内到达或变化的回执能够修正发送成功和利润结果。
 - API 启动后自动补生成最近四个完整自然日，并按日执行滚动刷新；报表查询支持服务端日期、企业、应用、通道和维度过滤及分页。
@@ -1506,6 +1506,12 @@
 4. 创建批次时按每条资料所属企业应用的当前生效路由规则展开所有通道；一个签名走多个通道时，必须为每个通道创建或重置独立报备任务并生成一份该通道的 `.xlsx`。无生效路由、通道未配置字段或缺少通道必填资料时，该资料继续保留在待报备池，任务进入“资料待补充”，不得伪装为已完成。
 5. 通道“配置签名报备字段”和“配置引流信息字段”弹窗使用字段池，按资料类型分别配置。每列包含标准字段、通道导出表头、列顺序、必填、说明、列宽、文本转换、缺省值以及图片宽高；导出表头和列顺序必须严格使用通道配置，不受导入表格原始名称和顺序影响。
 6. 通道导出文件必须为 WPS/Excel 可打开的 `.xlsx`，图片直接内嵌到对应单元格区域，而不是仅写 MinIO URL 或本地路径。批次保留所选材料版本快照、通道文件、行号和通道任务关联，可从最近批次直接下载每个通道文件。
+7. 2026-07-28 起，导入“确认”只把每一行保存为待审核明细，不得立即创建、修改或自动审核通过签名/引流信息。签名和引流审核中心分别提供“导入批次审核”页签，可查看整批行明细，一次通过全部、通过勾选项或驳回勾选项；审核通过后才将该行应用到真实业务对象并进入正常待报备流程，行校验失败不得阻断同批其他行。
+8. 导入审核必须同时支持新增和修改：页面明确展示每行操作类型、原对象、目标资料、错误原因和审核结果。驳回原因可选，不得因未填写原因阻止常用批量操作；审核人、审核时间和实际处理结果必须落 PostgreSQL。
+9. “待生成报备批次”页面由“待生成资料”和“已生成批次”两个页签组成。两个页签均使用后端分页，并可按关键字和时间范围查询；待生成资料可继续按签名/引流类型筛选。
+10. 已生成批次展示报备总数、成功数和成功率。报备总数以批次导出文件中的通道报备明细数为准，成功数以对应通道报备任务当前为通过的明细数为准；不展示“已导入回执”“等待回执”等当前无明确业务需求的字段。
+11. 报备明细是一条签名或引流信息在一个具体通道上的当前报备状态。常用操作为逐条人工修改状态，弹窗只要求选择目标状态，修改原因可选；详情展示所属企业/应用、来源批次、导出文件行号和时间顺序的状态轨迹。
+12. 本阶段不提供新的回执导入入口，不实现批量回执文件规范、解析或自动状态覆盖。已有历史数据和后端兼容代码保留以便追溯，后续只有在回执文件格式、匹配键、批量结果语义和异常处理规则明确后再立项。
 ## HTTP 客户接口第一版
 
 ### 管理端企业应用配置
@@ -1703,6 +1709,7 @@
 ## 2026-07-26 企业应用停用与回执清算补充要求
 
 - 删除企业前必须检查其企业应用；只要存在`active`或`disabling`应用就阻止删除，并提示先完成应用停用。
+- 删除企业前还必须在企业账户事务锁内检查真实余额；余额大于或小于 0 均禁止删除，并提示“完成余额清算后方可删除，请给企业充值到金额为0”。只有余额恰好为 0 且不存在启用或停用中的企业应用时才允许逻辑删除，避免删除检查与并发充值、扣费或退款竞争。
 - 点击停用应用时，系统必须统计尚未收到供应商回执的短信、待发送回执、等待`CMPP_DELIVER_RESP`的回执、仍可重试的失败投递及待投递上行。
 - 无待清算数据时，应用直接转为`disabled`并断开该账号的全部下游CMPP连接；存在待清算数据时，运营可选择“等待回执后停用”或“强制停用并断开连接”。
 - “等待回执后停用”将应用转为`disabling`：立即拒绝新短信Submit，但保留或允许下游账号重新连接以接收历史回执；待清算数据归零后自动停用。
@@ -1770,3 +1777,24 @@
 5. 通道测试短信处于回执等待状态时与普通短信使用相同状态样式，不得因“测试短信”说明显示红色失败；发送测试弹窗的接入号和网关密码必须使用独立表单名称及自动填充语义，避免密码管理器串填。
 6. 企业应用的通道组选择控件不得突破卡片宽度；通用输入控件在有无提示文案时控制区顶部对齐。
 7. 分片补偿审计按`createdAt`从早到晚展示，并显示审计时间；同一时刻按分片序号和主键稳定排序。
+
+## 2026-07-28 运营端列表与审核详情补充要求
+
+1. 报备字段库的“被通道引用”只统计仍未删除的通道，并按不同通道去重；已删除通道的历史映射不再阻止字段删除。
+2. 通道报备详情只展示仍未删除的企业签名；已删除签名的历史报备记录继续保留在数据库审计链路中，但不进入当前业务列表。
+3. 运营看板“今日企业消费”只排行仍未删除的企业；消费金额继续按北京时间当天真实已计费短信聚合。
+4. 短信审核列表展示发送企业和企业应用，不展示审核任务号和审核原因；任务号、原因及号码明细保留在详情和查询能力中。
+5. 短信任务进度的号码数量提供“查看列表”入口，号码弹窗必须从真实短信记录服务端分页和搜索，并展示手机号、归属地、运营商和短信状态。
+6. 运营端企业签名的引流资料只保留“引流url或号码”业务字段，不再要求填写独立“引流信息”；新增和编辑均以该字段作为真实保存与检索值。
+7. 审核中心各审核页面的查看入口统一命名为“详情”；详情必须展示审核时间和审核人员用户名。运营自动通过显示“系统自动”，无法追溯审核人的历史记录显示“-”，不得伪造人员。
+8. 企业管理列表不展示实现来源类注释，不向运营人员暴露“数据来自真实接口”等研发说明。
+## 数据统计：签名在通道与运营商维度的发送质量
+
+- 数据统计页默认查询北京时间当天，并允许选择任意一个不晚于今天的自然日。
+- 仅统计短信记录已关联平台签名的记录；正文中出现但企业未在平台登记、未形成`signatureId`关联的签名不纳入本统计。
+- 签名总览按业务短信记录统计发送量、送达成功、送达失败、提交失败、成功率和平均到达时间；同一业务短信在总览中只计算一次。
+- 签名通道明细按真实`SmsSubmitRecord`提交尝试统计。短信发生切换通道补发时，各次提交分别归入实际通道，因此通道提交次数允许大于业务短信数。
+- 运营商取短信发送时识别并持久化的真实号码运营商；通道与运营商是实际发送组合，不假设一个通道只支持一个运营商，也不把通道永久挂在某一个运营商下。
+- 查看签名明细时使用“通道行 × 运营商列”矩阵，每个有数据的单元格展示提交次数、成功率、平均到达时间及提交失败数量；所选日期无真实提交显示`—`，不据此推断通道不支持该运营商。
+- 平均到达时间只统计成功送达的提交尝试，从该通道提交受理时间开始，到该通道成功回执完成为止；长短信以全部成功分片完成时间为准。
+- 签名列表提供签名、企业或应用关键字查询和后端分页；查看详情不应依赖前端模拟数据或浏览器本地存储。

docs/system-functional-test-cases.md

@@ -1591,6 +1591,8 @@
   - 失败分类分布来自后端聚合，筛选后列表与统计同步变化。
   - 导出文件来自真实后端接口，包含失败分类字段，内容与当前筛选结果一致。
   - 页面刷新后恢复状态仍然存在，可继续用于生产排查。
+  - 页面解释恢复状态与逐条下游投递记录的用途差异；恢复状态和下游投递记录默认均选择近 7 天。
+  - 恢复状态按更新时间区间筛选，摘要、失败分类、列表和 CSV 导出使用同一时间口径；列表标题与外框保持正常内边距，最后错误/跳过原因列具备可读宽度。
 
 ### TC-GW-025 多 Gateway 恢复抢占协调
 
@@ -3443,7 +3445,7 @@ npm run verify:phase8
 | 用例 | 细化执行点 | 必查断言 |
 | --- | --- | --- |
 | TC-REPORT-001 | 在同一发送日准备多个企业和应用的单条、长短信，覆盖 delivered、failed、unknown；次日执行报表刷新并按日期、企业、应用查询对账单。 | 只生成 T-1 及更早完整日期；发送和成功均按 `billingUnits` 汇总；成功只包含最终 delivered；企业与应用隔离正确；API 使用 PostgreSQL 报表表和服务端分页。 |
-| TC-REPORT-002 | 准备已扣费成功、最终失败退款、同通道成功和跨通道补发成功短信，分别按企业应用和通道查看利润报表。 | 企业应用消费只包含 charged；退款不算收入；所有 accepted 尝试均按成本快照计入成本；通道维度收入只归属最终提交且不重复；利润=消费-成本，利润率计算正确，收入为 0 时显示 0%。 |
+| TC-REPORT-002 | 准备短短信成功、三分片长短信仅两片成功、最终失败退款、同通道成功和跨通道补发成功短信，分别按企业应用和通道查看利润报表。 | 企业应用消费只包含 charged；退款不算收入；成本严格等于各次提交的通道成本单价快照乘以该次成功分片数，失败和未知分片成本为0；通道维度收入只归属最终提交且不重复；利润=消费-成本，利润率计算正确，收入为0时显示0%。 |
 | TC-REPORT-003 | 首次生成后，在 T-3 短信上补录 delivered 回执并将另一条 T-2 短信最终失败退款，再执行次日定时刷新。 | 每次刷新准确覆盖 T-4、T-3、T-2、T-1；对应日期旧行在事务内重建，成功数、消费、利润同步修正；T-5 及更早报表不被本次任务改写。 |
 | TC-REPORT-004 | 先按成本价发送并 accepted，再修改通道单价，随后生成和重复刷新报表。 | `SmsSubmitRecord.costUnitPrice/costAmountCents` 保存提交时快照；历史成本不随通道当前单价变化；新提交使用新单价。 |
 | TC-REPORT-005 | 打开运营端菜单和两张报表，切换日期、企业、应用及通道维度并翻页。 | “报表对账”位于“数据详单”之后且包含两个二级菜单；筛选和分页调用真实 `/admin/reports/*` API；页面展示生成时间及 T+1/T-4～T-1 口径，不使用 mock、静态数组或 localStorage 数据。 |
@@ -3593,14 +3595,19 @@ npm run verify:phase8
 
 | 用例编号 | 操作 | 预期结果 |
 | --- | --- | --- |
-| TC-REPORT-MATERIAL-IMPORT-001 | 将含两行表头、文本列和营业执照/身份证等内嵌图片的 WPS 在线表格另存为 `.xlsx`，选择企业、应用和签名资料后解析。 | NestJS 读取真实工作表及图片锚点，返回列、组合表头、前十行和图片数预览；原文件写 MinIO，导入批次写 PostgreSQL；未确认前不改签名、不建通道任务。 |
-| TC-REPORT-MATERIAL-IMPORT-002 | 将源列分别映射到短信签名、签名用途和动态报备字段，调整数据类型/必填/转换规则，保存映射方案后确认导入；再用列顺序不同但表头相同的文件复用方案。 | 新签名或已存在签名的资料真实入库，内嵌图片拆出并写 MinIO 引用，材料版本递增且进入待报备池；映射方案持久化并可再次选择，源列顺序不影响目标字段。 |
-| TC-REPORT-MATERIAL-IMPORT-003 | 导入引流资料，将所属签名、站点、URL、备注和动态图片映射后确认；其中一行引用不存在或未审核签名。 | 合法行创建/更新真实 `SmsDrainageInfo` 并进入待报备池；非法行记录行号和原因，批次为部分失败，不因单行错误回滚其他合法行，也不自动创建报备任务。 |
+| TC-REPORT-MATERIAL-IMPORT-001 | 将含两行表头、文本列和营业执照/身份证等内嵌图片的 WPS 在线表格另存为 `.xlsx`，选择企业、应用和签名资料后解析。 | NestJS 读取真实工作表及图片锚点，返回列、组合表头、前十行和图片数预览；原文件写 MinIO，导入批次写 PostgreSQL；解析和提交审核均不直接修改签名、不建通道任务。 |
+| TC-REPORT-MATERIAL-IMPORT-002 | 将源列映射到签名及动态报备字段后提交导入，再进入短信签名审核的“导入批次审核”页签查看100行数据并一次通过其中勾选的多行。 | 每行先以新增/修改/无效状态落待审核明细；只有通过行才创建或修改真实签名并写审核人、审核时间，随后进入待生成资料池；未选行保持待审核，页面不要求逐行打开确认。 |
+| TC-REPORT-MATERIAL-IMPORT-003 | 导入引流资料，其中一行引用不存在或未审核签名；在引流审核页批量通过合法行并驳回部分行，不填写驳回原因。 | 合法行审核通过后创建/更新真实 `SmsDrainageInfo` 并进入待生成池；非法行保留行号和原因；空驳回原因可正常提交，同批其他行不受影响，也不自动创建通道报备任务。 |
+| TC-REPORT-MATERIAL-IMPORT-004 | 导入文件中同时包含已存在对象的修改和不存在对象的新增，提交审核前后分别读取业务表。 | 提交审核前业务表完全不变；审核页展示新增/修改及原数据快照；通过后才应用变更，重复点击已处理行不会再次递增材料版本或重复创建对象。 |
+| TC-REPORT-MATERIAL-IMPORT-005 | 分别在签名和引流审核页面按文件名、状态、时间筛选导入批次，翻页后选择整批或部分明细审核。 | 查询、总数和分页来自真实后端；批次汇总待审、通过、驳回、无效数量，刷新后保持一致。 |
 | TC-REPORT-CHANNEL-FIELD-001 | 在同一通道分别打开签名和引流字段配置，添加字段、修改通道表头、上下排序、设置必填/列宽/图片宽高后保存并刷新。 | 两类配置相互独立且完整持久化；刷新后字段池、映射表头和顺序一致；重复字段、停用字段和非法尺寸由 API 拒绝或归一化。 |
 | TC-REPORT-BATCH-001 | 一个应用配置两个生效通道，选择一个待报备签名创建统一批次。 | 系统从真实应用路由展开两个通道，生成两个独立通道任务和两个 `.xlsx`；每个文件表头名称、列顺序和列宽均来自对应通道配置，批次可下载两份文件。 |
 | TC-REPORT-BATCH-002 | 两个通道对同一标准字段配置不同表头和顺序，并包含图片列，生成批次后分别用 WPS 打开。 | 两份工作簿各自使用对应通道映射，图片直接显示在数据行内且尺寸按通道配置；文件不是 URL 清单，文本与图片属于同一材料快照。 |
 | TC-REPORT-BATCH-003 | 分别制造无生效路由、通道未配置字段、缺少通道必填图片，再创建批次。 | 对应资料不会清除待报备标记；有通道但资料不全时任务为 `waiting_material` 并记录原因；批次为部分失败，无任何假成功任务。 |
 | TC-REPORT-BATCH-004 | 同一签名修改资料后再次选择生成批次。 | 材料版本递增；复用同一签名/通道任务并重置到新一轮状态，批次项目保留当次版本和快照，历史导出文件仍可追溯。 |
+| TC-REPORT-BATCH-005 | 打开“待生成报备批次”，分别切换“待生成资料”和“已生成批次”，按时间范围和关键字查询并翻页。 | 两个页签均使用后端分页与时间查询；切换、重置筛选后查询条件正确，不读取上一页签的旧条件。 |
+| TC-REPORT-BATCH-006 | 生成包含3条通道报备明细的批次，将其中2条任务人工改为通过后刷新已生成批次。 | 批次显示报备总数3、成功数2、成功率66.67%；不显示已导入回执或等待回执。 |
+| TC-REPORT-TASK-STATUS-001 | 在报备明细页逐条修改签名或引流信息的通道状态，分别填写和不填写修改原因。 | 两种操作均成功；状态和时间轨迹写真实任务/记录，原因空时不阻断提交；页面无生成同范围任务和导入回执入口。 |
 
 ### 17.13 Gateway 提交异常与通道级 TPS 限速
 
@@ -3881,6 +3888,7 @@ npm run verify:phase8
 | 用例编号 | 场景 | 预期结果 |
 |---|---|---|
 | TC-TENANT-DELETE-001 | 删除仍有启用或停用中应用的企业 | 后端拒绝删除，确认弹窗保持打开，并在弹窗内显示应用数量及先停用应用的原因 |
+| TC-TENANT-DELETE-001A | 分别删除账户余额为正数、负数和0的企业，并在删除检查期间并发发起充值 | 正数和负数均被后端拒绝，弹窗提示“完成余额清算后方可删除，请给企业充值到金额为0”；余额为0且无活动应用时才允许删除；账户事务锁保证删除检查与余额变更不发生竞态 |
 | TC-TENANT-DELETE-002 | 删除请求处理中重复点击或关闭弹窗 | 确认、取消和关闭均被禁用，不产生重复请求 |
 | TC-TENANT-DELETE-003 | 删除无阻塞依赖的企业 | 删除成功后才关闭弹窗，并刷新企业列表 |
 
@@ -3947,3 +3955,33 @@ npm run verify:phase8
 | TC-APP-ROUTE-WIDTH-010 | 企业应用通道组名称很长，分别使用桌面和窄屏 | 选择框及下拉选项不超出通道组卡片，长文本省略且可正常选择 |
 | TC-USER-ADMIN-011 | 删除/停用企业最后一个管理员，再删除/停用平台最后一个管理员 | 企业管理员操作成功并写日志；平台管理员操作仍返回`LAST_PLATFORM_ADMIN` |
 | TC-INPUT-ALIGN-012 | 打开新增用户弹窗，对比有提示和无提示的文本输入框 | 标签和输入控制区顶部对齐，提示文本仅占自身下方空间 |
+
+## 2026-07-28 运营端列表与审核详情回归用例
+
+| 用例编号 | 场景 | 预期结果 |
+|---|---|---|
+| TC-REPORT-FIELD-ACTIVE-001 | 同一报备字段被一个有效通道重复配置，并被一个已删除通道引用 | 引用数按有效通道去重后为1；删除通道不计数 |
+| TC-REPORT-FIELD-ACTIVE-002 | 报备字段只剩已删除通道的历史映射 | 引用数为0，字段可删除，同时清理失效映射，不影响历史通道审计数据 |
+| TC-CHANNEL-REPORT-SIGNATURE-003 | 通道同时存在有效签名和已删除签名的报备任务 | 报备详情只展示有效签名，已删除签名不再进入当前列表 |
+| TC-DASHBOARD-SPEND-009 | 已删除企业和有效企业当日均有charged计费记录 | 今日企业消费只显示有效企业，金额与真实计费聚合一致 |
+| TC-SMS-AUDIT-LIST-010 | 打开短信审核列表及任意详情 | 列表展示企业和企业应用，不展示审核任务号、审核原因；详情仍可查看任务号、原因和号码 |
+| TC-SMS-TASK-PHONES-011 | 在短信任务进度点击号码数量，搜索号码并切换页码、每页条数 | 打开真实号码列表；手机号、归属地、运营商、状态来自服务端，搜索和分页总数准确 |
+| TC-DRAINAGE-FIELD-012 | 运营端新增和编辑企业签名引流资料 | 弹窗仅显示“引流url或号码”，不显示“引流信息”；保存、刷新和搜索均使用真实后端值 |
+| TC-AUDIT-DETAIL-013 | 依次打开企业认证、短信、模板、签名、引流信息审核 | 查看按钮统一为“详情”；所有详情展示审核时间和审核人员用户名，自动审核与历史缺失值展示准确 |
+| TC-CUSTOMER-NOTE-014 | 打开运营端企业管理 | “企业列表”下不出现“数据来自租户、账户真实接口。”研发说明 |
+## 数据统计：签名通道与运营商发送质量
+
+| 用例编号 | 场景 | 预期结果 |
+| --- | --- | --- |
+| TC-ANALYTICS-SIGNATURE-001 | 不传日期进入数据统计页 | 默认使用北京时间当天，签名列表与页面顶部统计日期一致 |
+| TC-ANALYTICS-SIGNATURE-002 | 选择历史自然日后查询 | 总览、签名列表和矩阵全部切换至所选日期 |
+| TC-ANALYTICS-SIGNATURE-003 | 短信正文有签名但`signatureId`为空 | 该记录不进入已登记签名统计 |
+| TC-ANALYTICS-SIGNATURE-004 | 同一签名分别通过移动、联通、电信发送 | 明细按实际运营商分别形成矩阵列 |
+| TC-ANALYTICS-SIGNATURE-005 | 同一通道实际发送多个运营商号码 | 同一通道行的多个运营商单元格分别展示真实数据 |
+| TC-ANALYTICS-SIGNATURE-006 | 同一短信首通道失败并切换下一通道 | 业务短信只计1条，两个通道各计1次提交，通道提交总数为2 |
+| TC-ANALYTICS-SIGNATURE-007 | 供应商提交拒绝或超时 | 计入提交失败，不混入已受理短信的送达失败率分母 |
+| TC-ANALYTICS-SIGNATURE-008 | 已受理短信收到失败回执 | 计入该通道与运营商组合的送达失败 |
+| TC-ANALYTICS-SIGNATURE-009 | 长短信全部分片成功 | 以最后成功分片时间计算该提交的到达耗时 |
+| TC-ANALYTICS-SIGNATURE-010 | 关键字查询签名、企业或应用 | 后端返回匹配签名并保持总数和分页正确 |
+| TC-ANALYTICS-SIGNATURE-011 | 点击“查看明细” | 打开右侧详情抽屉，展示运营商概览及通道×运营商矩阵；Esc、关闭按钮和遮罩均可关闭 |
+| TC-ANALYTICS-SIGNATURE-012 | 所选日期没有已登记签名发送 | 返回真实空状态，不显示演示或历史日期数据 |

docs/testing-progress.md

@@ -2579,3 +2579,65 @@ git diff --check
 - 部署后真实数据库直接验证待审核签名`【安徽航天信息】`返回`allowedActions=["approve","reject"]`、`blockedReasons=[]`且配置必填字段数为0，证明不再套用旧固定资格项。`SmsSubmitRecord`共530条，其中512条已回填通道组ID及名称；剩余18条无法唯一归因的测试或历史提交保持空值，未伪造归因。真实`OperationsService`可返回当天charged计费企业消费排行（首位“启瑞中转企业”77220内部计费单位）及包含`acceptedCount/submitFailureCount`的签名统计。
 - `.deployed-commit=7c1a0287a0b68e6f3ecdbd16243dd05bb8a263e1`；API、Gateway、Nginx、PostgreSQL、MinIO均active，Redis`PONG`，`12026/17890/8090/3000/6379/5432/9000`均监听。Gateway重启后3个客户CMPP账号因旧进程连接行尚在90秒心跳期限内首次重连收到连接数限制，超时清理后均由客户端自动重连成功，最终4个客户CMPP应用均有实时心跳；4个启用供应商通道也全部恢复`connected/currentConnections=1/desiredConnections=1`。Redis Stream消费者1、`pending=0`、`lag=0`。
 - 公网首页、运营端、客户端和API health均HTTP 200，公网CMPP 17890 TCP可连接。应用内浏览器验证运营登录页标题为“聆界短信管理平台”，1280px视口`scrollWidth=clientWidth=1280`且控制台0条error/warn；当前无可接管的已登录会话且页面存在图形验证码，未绕过认证，因此十项登录后交互的最终可见验收保留为持有有效运营会话后的人工复核项。本轮未发送真实测试短信。
+
+## 2026-07-28 运营端有效数据口径与审核详情补齐（本地未提交）
+
+- 报备字段库引用数改为只统计未删除通道并按通道去重；字段只剩已删除通道历史映射时可正常删除，并同步清理失效映射。通道报备详情同时排除已删除签名。
+- 运营看板今日企业消费在原有北京时间当日真实charged计费口径上排除已删除企业。
+- 短信审核列表改为展示发送企业和企业应用，移除审核任务号与审核原因列；详情仍保留任务、原因和真实号码明细。
+- 短信任务进度号码数量新增真实列表入口，后端按批次提供手机号搜索、分页及手机号、归属地、运营商、短信状态字段，不在浏览器内截断或拼装。
+- 企业签名引流资料新增/编辑统一为“引流url或号码”，移除独立“引流信息”输入；企业管理移除“数据来自租户、账户真实接口。”研发注释。
+- 企业认证、短信、模板、签名、引流信息审核入口统一为“详情”，缺失详情入口的页面已补齐；所有详情展示审核时间和审核人员用户名。新审核动作保存真实审核用户，历史缺失审核人不伪造。
+- Node.js v24.14.0下前端TypeScript、API TypeScript和Vite生产构建通过；字典、通道、运营统计、风控审核、企业认证5 suites / 94 tests及发送链1 suite / 101 tests定向通过，临时本地Redis下API全量26 suites / 358 tests通过，测试结束后已停止临时Redis；`git diff --check`通过。应用内浏览器访问本地生产构建的短信审核路由时，真实鉴权守卫跳转运营登录页；本地预览未连接API而返回502，且图形验证码阻止登录后页面验收，未绕过认证或将登录页冒充目标页面。
+- 本轮按用户要求保持未提交、未推送、未部署；既有构建缓存、`outputs/`及空文件`=`继续作为其他会话/历史临时产物保留。
+
+## 2026-07-28 签名/引流导入审核与报备批次页面重构（本地未提交）
+
+- Excel 导入从“确认后直接写业务对象”改为真实待审核明细：新增 `ReportMaterialImportItem` 保存行号、新增/修改类型、目标对象、资料载荷、原快照、校验错误、审核人及审核时间。提交导入只进入 `pending_review`，不会创建、修改或自动审核通过签名/引流信息。
+- 短信签名审核和引流信息审核分别增加“导入批次审核”页签，支持按批次查看行明细、勾选多行或整批通过、批量驳回；驳回原因可选。审核通过后才复用真实短信配置服务应用新增/修改并进入正常待报备流程，非法行独立记录错误。
+- 企业签名管理新增“批量导入签名及引流资料”入口；导入弹窗文案明确为提交审核，不再从待生成资料页混入导入操作。
+- “待生成报备批次”改为“待生成资料/已生成批次”两个页签，两个页签均提供后端分页、关键字和时间查询；筛选重置使用显式空条件重新查询，避免 React 状态异步导致旧条件残留。
+- 已生成批次按真实导出文件明细统计报备总数，按关联通道任务当前通过状态统计成功数和成功率；移除已导入回执、等待回执等无明确当前需求的展示。
+- 原“报备任务”页面收敛为逐通道“报备明细”，移除无真实产物的“生成同范围任务”和回执导入入口。人工状态弹窗只选择目标状态，原因可选；详情展示企业、应用、来源批次/文件行号和按时间顺序排列的状态轨迹。历史回执表及后端兼容接口暂不删除，避免破坏既有数据追溯。
+- 新增 migration `20260728153000_stage_report_material_import_reviews`。Node.js v24.14.0 下报备资料与通道服务定向 2 suites / 51 tests 通过，覆盖导入仅暂存不改业务对象、无原因驳回、批次总数/成功数/成功率及通道报备关联读取；临时本地 Redis 下 API 全量 26 suites / 361 tests 通过，测试结束后已停止临时 Redis。前端/API TypeScript、Prisma validate、Vite 生产构建及 `git diff --check` 通过，Vite 只保留既有大 chunk 提示。
+- 应用内浏览器连接失败后按浏览器控制技能切换到可用 Chrome，在本地生产构建访问 `/admin/report-materials`；前端路由和登录守卫正常，但本地未启动 NestJS API，认证请求返回 502 并跳转登录页，且没有可接管的已登录运营会话。未绕过验证码，因此双页签、批次审核和人工状态弹窗的登录后视觉验收仍需有效会话复核，不能以登录页冒充完成。
+- 本轮按用户要求保持未提交、未推送、未部署；工作区其他会话及历史未提交修改继续原样保留。
+
+## 2026-07-28 企业营业执照、利润成本与删除余额门禁（本地未提交）
+
+- 新建/编辑企业共用页面将“企业照片”统一改为“企业营业执照”，同步调整已上传占位、上传按钮、默认文件名和失败提示；对象存储既有 purpose/prefix 保持兼容，不迁移历史文件。
+- 利润报表成本改为“提交时通道成本单价快照 × 该次提交成功短信分片数”。新数据优先按 `SmsMessageSegmentAudit` 中 `receiptStatus=delivered` 的分片数统计；历史缺少分片审计但存在明确成功回执时按短信计费分片数兼容，失败、未知和未收到成功回执的分片不计成本。企业应用和通道两个利润维度使用同一口径，利润及利润率随成本同步重算。
+- 企业删除在与充值、扣费、退款相同的 `tenant-account:<tenantId>` PostgreSQL 事务锁内读取真实账户余额；余额非0时拒绝删除并提示“完成余额清算后方可删除，请给企业充值到金额为0”，余额为0后仍继续执行活动企业应用门禁。
+- Node.js v24.14.0 下报表和企业服务定向 2 suites / 14 tests、API 全量 26 suites / 364 tests、前端与 API TypeScript、Vite 生产构建及 `git diff --check` 通过；Vite 仅保留既有大 chunk 提示。
+- 本地 PostgreSQL 启动后确认目标为 `localhost:5432/cmpp_platform`，应用至75条 migration；本地 API 在3000端口、前端生产预览在4173端口、Redis在6379端口运行，健康接口和页面均返回 HTTP 200。真实 PostgreSQL 已使用新成本 SQL 成功重算 2026-07-24 至 2026-07-27，未出现 SQL 语法或字段关联错误。
+- 本地未启动 Gateway，API 启动时本地库两个历史 active 通道的恢复连接请求按预期失败；发送 worker 和回执超时扫描已关闭，不连接供应商、不发送短信，不影响运营页面查看。
+- 本轮继续保留为未提交、未推送、未部署状态；本地服务按用户要求保持运行。
+
+## 2026-07-28 恢复状态与下游投递近七天筛选（本地未提交）
+
+- “恢复状态管理”补充用途说明：该页按客户账号展示 Gateway 在客户重连或实例重启后，对未完成状态回执和上行短信续投的当前/最近一次恢复状态；逐条消息的投递、重试与客户端 ACK 仍在“下游投递记录”查看。
+- 恢复状态增加按最近更新时间的真实后端时间区间筛选，默认今天在内的近 7 个自然日；摘要、失败分类、分页列表和 CSV 导出统一使用同一筛选条件，重置后恢复默认近 7 天。
+- 恢复状态列表标题区补充卡片内边距，避免标题紧贴外框；“最后错误/跳过原因”列固定为 320px 可读宽度。下游投递记录创建日期默认及重置均改为近 7 天。
+- Operations 专项 1 suite / 22 tests 通过，覆盖恢复状态列表和 CSV 导出的北京时间起止边界；前端 TypeScript、API 正式构建配置 TypeScript、Vite 生产构建及 `git diff --check` 通过，Vite 仅保留既有大 chunk 提示。真实本地 PostgreSQL 使用 2026-07-22 至 2026-07-28 条件执行恢复状态查询成功，本地库当前返回 0 条。
+- API 全量 Jest 在本轮等待 120 秒后仍未结束且未输出最终汇总，确认遗留测试进程仍在运行后已只停止该本轮测试进程；不把它记录为通过或失败。专项测试及正式构建结果不受影响。
+- 本地 API 已重启并在 3000 端口健康运行，前端生产预览继续在 4173 端口运行；Gateway 未启动，发送 worker 与回执超时扫描保持关闭。本地浏览器已打开运营登录页，受图形验证码保护，未绕过认证。
+- 本轮保持未提交、未推送、未部署，工作区其他会话及历史未提交修改继续原样保留。
+
+## 2026-07-28 签名通道与运营商发送质量（本地未提交）
+
+- 数据统计页新增已登记签名发送质量区域，默认北京时间当天并跟随现有日期查询；支持按签名、企业或应用关键字查询及后端分页。未关联`signatureId`的正文签名按用户最新决定不纳入统计。
+- 签名主表按业务短信记录展示业务短信、送达成功、送达失败、提交失败、最终成功率和平均到达时间；通道提交数按真实`SmsSubmitRecord`尝试统计，明确允许补发时大于业务短信数。
+- “查看明细”使用右侧大尺寸抽屉，先按移动、联通、电信汇总，再以通道为行、运营商为列展示提交次数、成功率、平均到达时间和提交失败；同一通道可同时出现多个运营商，不建立错误的一对一归属关系。
+- 新增独立真实后端接口`GET /admin/operations/signature-quality`，签名汇总只连接平台`SmsSignature`，通道质量复用分片审计及供应商回执完成口径；平均到达时间仅统计成功送达尝试，长短信以全部成功分片完成为准。
+- Operations定向1 suite / 24 tests通过，新增覆盖分页签名矩阵合并和真实空状态；API TypeScript正式构建、前端TypeScript检查及Vite生产构建通过，Vite仅保留既有约1.98MB单chunk提示。
+- 新SQL已对本地PostgreSQL真实执行。为便于本地视觉验收，新增必须显式设置`ALLOW_LOCAL_SIGNATURE_QUALITY_DEMO=true`、只允许localhost数据库且在`NODE_ENV=production`下无条件拒绝执行的演示数据脚本，并写入明确标记的“本地统计演示企业/应用”、3个已登记签名、54条业务短信、61次通道提交和51条回执；演示通道均为inactive，Gateway未启动，不连接供应商、不发送短信。
+- 本地API和前端生产预览分别运行于3000、4173端口，健康检查及数据统计页均HTTP 200。应用内浏览器以真实本地运营会话验证签名列表、运营商概览和通道×运营商矩阵；窄窗口下矩阵横向滚动已限制在矩阵内部，不再撑宽整个详情抽屉。
+- 本轮按用户要求只运行在本地，保持未提交、未推送、未部署；工作区其他会话已有未提交修改继续保留。
+
+## 2026-07-28 工作区汇总发布门禁
+
+- 本次汇总范围包含：报备字段和有效通道引用口径、审核详情与号码列表、签名/引流资料导入审核、待生成资料与已生成批次双页签、报备明细人工状态、企业营业执照文案、利润成功分片成本、企业余额删除门禁、恢复状态和下游投递近7天筛选，以及签名通道×运营商发送质量统计。
+- 演示数据脚本仅作为本地视觉验收工具纳入源码，不属于部署初始化或migration；脚本必须显式设置`ALLOW_LOCAL_SIGNATURE_QUALITY_DEMO=true`、数据库主机必须为localhost，并在`NODE_ENV=production`时无条件拒绝执行，预发布部署不会写入演示数据。
+- 发布前重新确认`HEAD`与`origin/main`均为`352a6293b47f95653fbb079f2cf528fba4d59818`，工作区修改来自前序多个会话，按用户明确要求统一归入本次发布；`outputs/`、空文件`=`、`api/tsconfig.build.tsbuildinfo`和`tsconfig.tsbuildinfo`继续作为构建或临时产物排除。
+- 首次API全量测试因本地Redis未运行导致3个发送链用例连接等待超时；恢复本地Redis后重跑，API全量26 suites / 366 tests全部通过。Prisma format/validate/generate、API TypeScript正式构建、前端TypeScript/Vite生产构建、Gateway `go test ./...`与`go vet ./...`、依赖安全门禁和`git diff --check`均通过；Vite仅保留既有大chunk提示，Jest保留既有`--forceExit`异步句柄提示。
+- 本节为提交和部署前门禁记录；提交、推送、备份、migration、服务重启和预发布验收结果在发布完成后补记。