feat: improve operations diagnostics and channel management

docs/system-functional-test-cases.md

@@ -3678,7 +3678,7 @@ npm run verify:phase8
 | TC-DEFECT-004 | 企业应用列表保持相同条件连续点击查询/重置，打开包含长 ID 的 CMPP 连接详情；短信记录同样操作。 | 每次均有真实 API 请求且数据更新；弹窗无水平滚动，长 ID 自动换行。 |
 | TC-DEFECT-005 | 通过/驳回一条待审短信并查看列表、更多信息及导航角标。 | 审核人/时间由当前会话写库，时间格式正确，列表不额外占列，角标不等待 30 秒轮询即更新。 |
 | TC-DEFECT-006 | 打开真实短信详情，再新增后删除一条运营商区分规则。 | 详情分别展示 `clientSrcId` 与通道 `srcId + applicationExtension`；运营商显示中文，DELETE API 真实删库并刷新。 |
-| TC-DEFECT-007 | 用登录运营用户修改企业应用及其他任一写操作，再查看系统日志；另构造失败请求。 | 成功写操作均有操作人、路径、资源和结果日志；失败请求不写伪成功日志，日志不含请求体、密码或密钥。 |
+| TC-DEFECT-007 | 用登录运营用户修改企业应用及其他任一写操作，再查看系统日志；另构造失败请求。 | 成功写操作均有操作人、路径、资源和结果日志；失败请求不写伪成功日志。普通HTTP业务操作日志不保存请求体、密码或密钥；仅`cmpp_connection.connect_requested`按连接诊断要求保存客户实际提交的认证参数，且不得写入平台保存的密钥。 |
 
 ### 17.16 2026-07-20 缺陷回归
 
@@ -3847,7 +3847,8 @@ npm run verify:phase8
 - `TC-PROTOCOL-LOG-001`：向Gateway客户认证入口提交不存在的CMPP账号；真实接口返回业务4xx，通讯日志分别出现`received`和`failed`事件，账号可检索、耗时和安全错误可见，数据库无短信业务记录。
 - `TC-PROTOCOL-LOG-002`：真实CMPP Submit获得供应商SubmitResp；通讯日志可按CMPP、通道到平台、SubmitResp及平台消息号筛选，展示上游消息号和结果码，不包含短信正文或通道密码；同一个SubmitResp只能落一条最终处理结果，不得同时出现`received`和`success`重复行。
 - `TC-PROTOCOL-LOG-003`：供应商发送DELIVER状态报告；Gateway结构化日志出现收到事件，NestJS通讯日志以一条记录展示该报文及最终处理结果。构造解包失败或API拒绝时必须出现对应失败证据，不能静默返回。
-- `TC-PROTOCOL-LOG-004`：通过公开HTTP API提交合法和非法请求；通讯日志展示客户到平台的受理或失败状态、请求号、脱敏手机号、业务码和耗时，鉴权头、密钥和正文不得入库。
+- `TC-PROTOCOL-LOG-004`：通过公开HTTP API提交合法和非法请求；通讯日志展示客户到平台的受理或失败状态、请求号、完整手机号、业务码和耗时，可使用完整号码查询，鉴权头、密钥和正文不得入库。
+- `TC-PROTOCOL-LOG-013`：分别产生CMPP Submit、供应商回执、上行和HTTP发送通讯日志；数据库新记录的`phoneNumber`、列表对象列、详情弹窗及完整号码关键字查询均显示/命中完整手机号，不写新的`phoneMasked`值，且短信正文、密码、密钥和鉴权头仍不入库。
 - `TC-PROTOCOL-LOG-005`：平台向客户投递回执或上行Webhook并触发成功、网络失败和重试；通讯日志展示事件ID、HTTP状态或网络错误、耗时、尝试次数及最终状态，真实`HttpWebhookAttempt`状态一致。
 - `TC-PROTOCOL-LOG-006`：连续运行CMPP心跳；`ProtocolInteractionLog`行数不随每个ACTIVE_TEST增长，连接状态中的最近心跳仍更新。超过配置保留期的数据被清理，业务表及操作审计不受影响。
 - `TC-PROTOCOL-LOG-007`：运营端真实登录后打开系统日志，键盘切换“系统与操作日志/通讯交互日志”，筛选、分页、详情及固定操作列可用；桌面和平板/手机不产生页面级横向溢出，宽表允许容器内滚动，控制台无error/warn。
@@ -4369,7 +4370,8 @@ npm run verify:phase8
 | --- | --- | --- |
 | TC-DRAINAGE-DETECT-001 | 在引流识别规则页新增、编辑、停用规则并刷新 | 所有操作调用真实后端并持久化到 PostgreSQL；版本递增、状态生效并留下操作日志，刷新后不丢失 |
 | TC-DRAINAGE-DETECT-002 | 分别测试协议 URL、裸域名、短链接、IP:端口/路径及中文标点相邻链接 | 均识别为含引流，命中类型为 URL，保存原始内容位置；检测不会改写短信原文 |
-| TC-DRAINAGE-DETECT-003 | 输入被空格、中文句号拆开的域名以及普通邮箱地址 | 规避域名仍命中；完整或带空格规避的邮箱不被当作引流 URL |
+| TC-DRAINAGE-DETECT-003 | 输入使用中文句号代替域名点号的URL以及普通邮箱地址 | 中文句号域名仍命中；完整或带空格规避的邮箱不被当作引流URL或手机号 |
+| TC-DRAINAGE-DETECT-010 | 分别在协议URL、裸域名或路径后加入空格、制表符、换行、全角空格及后续字符，并输入空格拆分域名 | URL命中原文和位置均在首个空白前结束，空白后字符不属于前一个链接；空格拆分域名不被拼接恢复，短信原文不被改写 |
 | TC-DRAINAGE-DETECT-004 | 测试`+86 138 0013 8000`、`138-0013-8000`及中文标点拆分手机号 | 均识别为手机号引流，原文片段可在短信记录中正确高亮 |
 | TC-DRAINAGE-DETECT-005 | 测试`（010）8888-8888 转 123`等固话 | 区号括号、分隔符和分机号均可识别为固定电话引流 |
 | TC-DRAINAGE-SEND-001 | 使用待审核、驳回或未报备的既有引流资料分别创建客户端批次和 CMPP 入站任务 | 不产生`DRAINAGE_NOT_APPROVED`，不因引流资料状态拒绝或转人工；其他发送校验仍正常执行，禁止用真实短信完成自动测试 |
@@ -4399,3 +4401,78 @@ npm run verify:phase8
 | TC-RECEIPT-CONFLICT-001 | 整条级成功已经形成`delivered`后，同一提交尝试又收到明确失败回执，并重复输入同一矛盾事件 | 原始失败回执和分片证据保留；主记录仍为`delivered`，不补发、不退款、不向客户推送失败；`SmsReceiptAnomaly`按稳定键只有一条记录并累加发生次数 |
 | TC-GATEWAY-EXCEPTION-UI-001 | 打开运营端“网关异常”，切换“提交异常”和“回执异常”Tab并刷新、筛选、翻页 | 菜单新名称和两个Tab正常展示且原路由可访问；两个Tab分别调用真实提交死信API和回执异常API，筛选、汇总、总数和分页与PostgreSQL一致，不使用mock、静态数据或localStorage |
 | TC-GATEWAY-EXCEPTION-UI-002 | 阅读两个Tab标题说明并打开两类详情 | “提交异常”明确说明死信不等于供应商拒绝/送达失败及重入队风险；“回执异常”明确说明其为终态冲突摘要，并指向真实回执记录和通讯交互日志，详情不泄露通道密码或鉴权信息 |
+
+## 2026-08-09 休眠唤醒与会话锁定恢复用例
+
+| 用例编号 | 操作 | 预期结果 |
+| --- | --- | --- |
+| TC-AUTH-014 | 在运营端短信记录页长时间无操作或让桌面进入锁定/休眠，超过运营端空闲期限后唤醒浏览器并观察网络请求，再输入当前密码解锁 | 锁定后短信记录路由暂停，全局`pending-audits`轮询停止，唤醒产生的焦点事件不继续请求受保护接口；解锁成功后返回短信记录路由并重新请求真实短信记录、企业和应用选项，页面无连续401 |
+| TC-AUTH-015 | 让旧会话活动时间超过空闲期限并进入完整登录页，在不刷新浏览器标签的情况下使用正确账号、密码和验证码重新登录 | 登录成功立即建立新的前端活动起点；新会话不会在1至2秒内调用`/auth/session/lock`，可正常打开短信记录并调用真实后端 |
+| TC-AUTH-016 | 分别由前端空闲计时、服务端`SESSION_LOCKED`响应和另一标签页锁定事件触发运营端锁屏，再由当前或另一标签页解锁 | 三种入口均同步锁屏、暂停业务路由和角标轮询；解锁后统一恢复，重复锁定/解锁事件幂等，不产生额外业务写入 |
+
+## 2026-08-09 签名删除预检与多通道报备汇总用例
+
+| 用例编号 | 操作 | 预期结果 |
+| --- | --- | --- |
+| TC-DELETE-SIGNATURE-004 | 对仅存在`approved`、`abandoned`等已结束报备任务，且无模板、引流信息或其他活动依赖的签名执行删除预检 | 已结束报备任务不出现在“未结束报备任务”中，删除预检允许继续；历史任务和记录仍保留 |
+| TC-DELETE-SIGNATURE-005 | 对仍存在`pending`、`waiting_material`、`reporting`或`exporting`任务的签名执行删除预检 | 预检列出真实未结束任务ID和状态并阻止删除 |
+
+## 2026-08-09 通道组删除风险展示与历史保留用例
+
+| 用例编号 | 场景 | 预期结果 |
+| --- | --- | --- |
+| TC-CHANNEL-GROUP-DELETE-001 | 打开同时关联正常应用、已删除应用、多个通道和`queued`提交记录的通道组删除弹窗 | 后端按不同应用ID去重并返回四项真实数量；弹窗标题、数量单位、说明和按钮文案与需求一致 |
+| TC-CHANNEL-GROUP-DELETE-002 | 同一正常企业应用存在多条通道组关联 | “关联正常企业应用”只计1个，不按关联规则条数重复累计 |
+| TC-CHANNEL-GROUP-DELETE-003 | 关联记录指向状态为`deleted`或已不存在的企业应用 | 两类均计入“关联已删除企业应用”，不计入正常应用 |
+| TC-CHANNEL-GROUP-DELETE-004 | 通道组存在正常/已删除应用关联、组内通道或等待供应商提交记录后确认删除 | 所有业务依赖只展示不阻止；后端将通道组状态置为`deleted`并写操作审计，不物理删除关联和历史记录 |
+| TC-CHANNEL-GROUP-DELETE-005 | 删除通道组后查询通道组列表并发送新短信 | 默认列表不再显示该组，新短信选路不再选择该组 |
+| TC-CHANNEL-GROUP-DELETE-006 | 删除通道组后查询历史发送/回执/审计，或按历史通道接入号处理上行 | 组内通道、应用关联、发送、回执和审计数据仍存在，历史链路可追溯 |
+| TC-CHANNEL-GROUP-DELETE-007 | 删除影响数据仍在加载或加载失败 | 加载期间不允许盲目提交；失败时明确展示接口错误，不使用静态数量或本地伪数据 |
+| TC-SIGNATURE-REPORT-AGG-001 | 同一签名两个目标通道分别为`approved`和`failed` | 签名整体及对应多目标汇总为“部分成功”，页面显示部分通道通过；失败通道及原因仍可查看，不显示整体报备失败 |
+| TC-SIGNATURE-REPORT-AGG-002 | 同一签名两个目标通道分别为`pending`和`failed` | 签名整体保持“报备中”，不因一个通道失败提前结束；失败通道明细继续展示 |
+| TC-SIGNATURE-REPORT-AGG-003 | 同一签名所有当前目标通道均为`failed/rejected` | 签名整体为“报备失败”；各通道失败事实和原因均保留 |
+
+## 2026-08-09 发送质量矩阵与成功率色阶用例
+
+| 用例编号 | 操作 | 预期结果 |
+| --- | --- | --- |
+| TC-ANALYTICS-SIGNATURE-004 | 打开签名通道发送质量明细并切换到“按引流切分”，检查多个通道及三网组合 | 每个通道固定依次展示“含引流、不含引流、未检测”三行，固定依次展示“移动、联通、电信”三列；缺少真实提交的组合显示`0`，其他组合与真实API数据一致 |
+| TC-ANALYTICS-SIGNATURE-005 | 分别构造或选择成功率为`0、0.1、25、25.1、50、50.1、75、75.1、95.9、96`的签名统计结果，检查列表、明细总览、运营商概览和矩阵 | 数字颜色依次落入红、橙、橙、黄、黄、蓝、蓝、绿、绿、深绿；所有签名质量展示位置使用同一边界函数，统计值不被前端改写 |
+| TC-CHANNEL-QUALITY-COLOR-001 | 在短信通道管理列表和通道报备详情检查上述成功率边界 | 送达成功率数字使用与签名质量相同的六档色阶；列表与详情对同一成功率显示一致 |
+| TC-CHANNEL-QUALITY-COLOR-002 | 选择提交失败、回执未知或送达失败比例与数量均非零的通道，检查通道管理列表和报备详情 | 三类非成功指标的比例与数量均为黑灰色，不显示红色、橙色或成功率色阶；真实比例、数量及后端数据保持不变 |
+
+## 2026-08-09 运营端菜单与查询控件细节用例
+
+| 用例编号 | 操作 | 预期结果 |
+| --- | --- | --- |
+| TC-ADMIN-NAV-006 | 展开“审核中心”和“安全控制”，再打开风控规则页面 | “审核中心”不再显示风控规则，“安全控制”显示且可正常进入；页面面包屑为“安全控制 / 风控规则”，路由和真实规则数据不变 |
+| TC-MONITOR-CARRIER-003 | 打开发送监控，检查移动、联通、电信、三网及未知运营商通道 | 已知运营商均显示中文；未知新增值保留后端原值，不显示空白，也不修改通道配置 |
+| TC-REPORT-BATCH-008 | 打开待生成报备批次并切换两个页签 | 页签标题仅显示“待生成资料”和“已生成批次”，不含括号及数量；列表分页总数、筛选和真实API请求保持正常 |
+| TC-SMS-RECORD-CHANNEL-003 | 打开短信记录通道下拉，输入通道名称或编码搜索并选择后查询、翻页和导出 | 下拉选项来自真实通道接口并支持搜索；查询和导出传递选中通道的精确`channelId`，结果、总数和CSV均只包含该通道记录；重置恢复全部通道 |
+
+## 2026-08-09 CMPP客户连接请求诊断日志用例
+
+| 用例编号 | 操作 | 预期结果 |
+| --- | --- | --- |
+| TC-CMPP-CONNECT-LOG-001 | 使用正确账号从允许IP发起CMPP 3.0连接，再查询系统与操作日志 | 认证成功；产生一条`cmpp_connection.connect_requested`，资源为`cmpp_downstream_connection`，日志`ipAddress`等于真实TCP来源IP，详情保存账号、AuthenticatorSource、时间戳、`cmpp30`、原始版本值、应用ID和authenticated结果 |
+| TC-CMPP-CONNECT-LOG-002 | 从不同IP分别使用未知账号、错误AuthenticatorSource、未在白名单的IP或已停用应用发起连接 | 每次连接均按原认证规则拒绝，同时各自持久化失败日志；未知账号日志仍保存来源IP和请求账号，失败原因与真实拒绝原因一致，不因没有企业ID而丢失 |
+| TC-CMPP-CONNECT-LOG-003 | 在系统与操作日志找到上述动作，核对IP列并点击“查看详情” | IP列有值；弹窗展示请求IP、Source_Addr、AuthenticatorSource、时间戳、协议版本、结果及失败原因。标准CMPP请求的密码字段明确显示“不传明文密码”，不得展示平台保存的密钥 |
+| TC-CMPP-CONNECT-LOG-004 | 通过兼容Gateway调用显式携带`password`字段进行认证测试 | 日志详情原样保存并展示该请求字段；该兼容行为不改变标准CMPP只传AuthenticatorSource的协议事实，也不把平台配置密钥写入日志 |
+
+## 2026-08-09 报表筛选结果全量汇总用例
+
+| 用例编号 | 操作 | 预期结果 |
+| --- | --- | --- |
+| TC-REPORT-SUMMARY-001 | 在对账单准备超过一页的多日、多企业应用数据，分别按日期、企业和应用搜索并翻页 | 顶部提交、发送、未知、成功、失败合计等于PostgreSQL中全部筛选结果；翻页不改变汇总，改变筛选条件后同步刷新 |
+| TC-REPORT-SUMMARY-002 | 在利润报表分别选择企业应用和通道维度，准备多行金额且至少一行收入为0 | 量类与金额类均按完整筛选结果求和；综合利润率=合计利润/合计净消费，不是行利润率求和或平均，合计收入为0时为0% |
+| TC-REPORT-SUMMARY-003 | 在发送质量报表的企业应用、通道、签名、引流信息四个Tab分别搜索和翻页 | 汇总条数来自真实后端全量聚合；综合成功率=合计成功/合计发送，不累加或平均各行成功率；汇总区不对平均到达时长求和 |
+| TC-REPORT-SUMMARY-004 | 调用三个报表列表API，对比`items`当前页、`total`、`summary`和相同条件CSV | `summary`与CSV完整结果口径一致且不受`page/pageSize`影响；无匹配数据时所有合计和综合率均为0 |
+
+## 2026-08-09 新建企业省市字典用例
+
+| 用例编号 | 操作 | 预期结果 |
+| --- | --- | --- |
+| TC-ENTERPRISE-REGION-001 | 在`PhoneSegment`中准备多省多地市且含重复行，调用`GET /api/admin/dictionaries/administrative-regions` | API从真实PostgreSQL查询`province/city`，返回去重、去空值并按中文排序的省份—地市数组，不返回前端静态数据 |
+| TC-ENTERPRISE-REGION-002 | 打开运营端新建企业，依次选择两个不同省份并查看地市下拉 | 省份选项来自真实字典API；地市只显示当前省的对应值，切换省份后旧地市立即清空；保存后省市真实写入企业档案 |
+| TC-ENTERPRISE-REGION-003 | 编辑一个已存省市值暂未出现在当前号段字典的历史企业 | 页面将档案原值补入当前选项并正常显示，未主动修改时不会被清空 |
+| TC-ENTERPRISE-REGION-004 | 断开字典API后打开新建企业 | 页面明确提示省市字典加载失败，不显示Mock、localStorage或旧的写死选项 |