feat: add carrier-aware signature retirement alerts

docs/first-version-development-requirements.md

@@ -1982,16 +1982,36 @@
 - 上述连接请求日志必须在认证响应返回前持久化，日志写入失败时不得把未经审计的连接当作认证成功。系统与操作日志列表继续直接显示`ipAddress`，并为`cmpp_connection.connect_requested`提供“查看详情”按钮，展示上述结构化参数。
 - 供应商通道的既有连接操作日志仍保留；客户入站连接使用`cmpp_downstream_connection`资源区分方向。本功能不改变CMPP认证算法、IP白名单、最大连接数或客户连接状态。
 
-## 暂缓需求：通道支持运营商多选（2026-08-09）
+## 通道运营商多选与运营商级签名报备（2026-08-10，本地实现完成、待验收与分阶段发布）
 
-- 本需求当前只记录、不实施，不改变现行`SmsChannel.carrier`单值模型、通道创建/编辑交互、通道组校验、发送选路、报备或生产数据；后续重新启动时必须另行完成影响评估、生产数据迁移方案和兼容发布计划。
+- 2026-08-09暂缓需求已重新纳入“签名清退预警”的前置设计，并已在本地完成兼容实现：`SmsChannel.carriers`保存运营商能力集合，通道管理、通道组校验、发送选路和签名报备均兼容运营商维度。当前修改仍未提交、未推送、未部署，生产数据和生产行为未改变；完整实施步骤和发布门禁见`docs/signature-retirement-alert-design.md`。
 - 目标交互为取消“移动、联通、电信、三网”四选一，将通道能力改为“移动、联通、电信”三个复选项，至少选择一个；同时勾选三个运营商等价于现行“三网”，允许只勾选其中两个运营商。
 - 该变化只作用于通道本体的运营商能力集合。`SmsChannelGroup.carrier`、`SmsChannelGroupItem.carrier`、`ChannelRouteRule.carrier`及短信号码实际运营商仍保持移动/联通/电信单值；一个通道只有在能力集合包含对应运营商时，才允许加入该运营商通道组并参与选路。
 - 同一通道勾选多个运营商时继续共用一个通道单价，不增加分运营商单价；如未来出现分运营商计价需求，必须另立需求并升级为通道运营商明细模型，不能在本需求中隐式扩展。
-- 完整、理想的报备模型为“签名 × 通道 × 运营商”，用于分别记录同一通道在不同运营商下的报备状态；该模型本期明确暂不设计、不实施，现有“签名 × 通道”报备任务及历史记录保持不变。未来启动运营商多选实施前，必须再次确认是否同步升级报备粒度，不得把一个运营商的报备结果无依据地复制为其他运营商结果。
-- 未来生产数据迁移原则为：`mobile→[mobile]`、`unicom→[unicom]`、`telecom→[telecom]`、`all→[mobile,unicom,telecom]`，已删除通道也要保留并迁移历史能力；不得根据当前通道组关联、通道名称或近期流量自动缩减旧`all`通道的能力范围。
-- 未来取消某个已勾选运营商时，如果该通道仍被对应运营商的活动通道组引用，后端必须返回真实影响并阻止保存，不得自动删除通道组成员、路由、报备任务或历史发送记录；新增运营商能力也不得自动加入通道组或自动视为报备通过。
-- 未来迁移必须采用向前兼容的分阶段发布：先增加新能力集合、回填并让后端兼容读取，再开放多选写入。出现两个运营商组合后，旧单值代码无法无损解释该数据，回滚下限必须是已经支持新集合的兼容版本，不能直接回滚到仅识别`mobile/unicom/telecom/all`的旧版本。
+- 签名报备模型同步从“签名 × 通道”升级为“签名 × 通道 × 运营商”。继续以`ChannelSignatureReportTask`保存当前事实、以`ChannelSignatureReportRecord`保存状态轨迹，不另建重复事实表；任务进入`approved`时记录当前连续通过时间，离开通过状态时结束该连续周期。`reportType`和`drainageItemId`只是共享表技术字段，不属于本需求维度；本需求不改造引流信息报备。
+- 历史通道级任务进入人工拆分弹窗时，三个运营商状态必须默认未选择，不得继承原通道级状态；操作人必须逐项选择真实状态，选择“已通过”时必须填写该运营商真实通过时间，前后端都要阻止缺失或非法时间提交。
+- 生产数据迁移原则为：`mobile→[mobile]`、`unicom→[unicom]`、`telecom→[telecom]`、`all→[mobile,unicom,telecom]`，已删除通道也要保留并迁移历史能力；不得根据当前通道组关联、通道名称或近期流量自动缩减旧`all`通道的能力范围。对历史空值使用旧系统实际兼容口径回填为移动，禁止回填为空集合或伪造为三网。
+- 取消某个已勾选运营商时，如果该通道仍被对应运营商的活动通道组引用，后端必须返回真实影响并阻止保存，不得自动删除通道组成员、路由、报备任务或历史发送记录；新增运营商能力也不得自动加入通道组或自动视为报备通过。
+- 发布迁移必须采用向前兼容的分阶段顺序：先增加新能力集合、回填并让后端兼容读取，再开放多选写入。出现两个运营商组合后，旧单值代码无法无损解释该数据，回滚下限必须是已经支持新集合的兼容版本，不能直接回滚到仅识别`mobile/unicom/telecom/all`的旧版本。
+
+## 签名清退预警（2026-08-10，本地实现完成、待验收与分阶段发布）
+
+- 企业预警按“企业签名 × 运营商”每天检测，通道预警按“签名 × 通道 × 运营商”每天检测。运营商只要存在当前真实报备通过任务就进入对应监控名单，不等待三网全部成功；历史通道级结果未按运营商确认前不得伪造运营商通过事实。
+- 企业预警支持移动、联通、电信通用X天/Y条规则和企业应用特殊规则，特殊规则优先；通道预警支持通用规则和通道特殊规则，特殊规则优先。规则修改从下一检测日生效，预警快照保存命中的规则版本和阈值。
+- 清退活跃量按至少有一次上游接受的业务短信去重统计。企业维度同一业务短信只计一次；通道维度按`messageRecordId + channelId`去重，同一通道断连、超时或重试产生多次提交只计一次，切换到不同通道后各通道分别计一次。提交尝试、上游接受和最终送达必须分开展示，不把`SubmitResp status=0`称为最终送达成功。
+- 每天按北京时间完整自然日检测`T-X`至`T-1`。当前连续报备通过时间不足X个完整日时不预警；恢复达标后关闭当前预警周期，以后再次低于阈值形成新周期。每日检测必须以数据库唯一维度保证幂等，多实例或重启不得重复生成消息或Webhook。
+- 自动任务每天北京时间04:00生成检测快照并冻结当日规则版本、标题和消息正文，北京时间08:00才生成站内消息并进入Webhook投递。服务在04:00或08:00之后启动时必须按当前时点补偿对应阶段，仍由数据库唯一键保证幂等；运营页面不提供“执行今日检测”按钮，管理API也不暴露手动检测入口，避免人为提前发消息或混淆自动任务口径。
+- 临时抑制支持常用天数和自定义天数；永久抑制可在“抑制管理”中取消，取消必须二次确认、填写原因并写操作日志。抑制只停止站内提醒和Webhook，不停止每日检测快照；取消后从下一检测日恢复，不补发历史通知。
+- 右上角新增预警铃铛，数字只统计今日未读且未抑制消息；原待审核铃铛更换为任务图标，但原有计数、弹层和跳转不得丢失。安全控制新增“签名清退预警”，展示规则、今日企业/通道预警数量、分页消息列表、日期范围和抑制管理。
+- “今日预警”页签和区块统一更名为“预警消息”。消息列表包含历史消息，默认日期区间的开始、结束均为北京时间今日并只查询今日；支持修改日期区间，并分别按企业、企业应用、签名名称和通道查询。所有条件由真实后端共同作用于分页结果和总数，默认及筛选变化后回到第1页，每页10条，不得前端全量截取伪分页。
+- 预警消息“抑制”必须使用平台自研弹窗，在同一弹窗中选择临时或永久抑制：临时抑制直接选择截止日期，永久抑制不显示日期；两种方式都必须填写原因。抑制管理的“取消抑制”也必须使用自研确认弹窗并填写取消原因，禁止调用浏览器`confirm`或`prompt`。
+- 企业微信和飞书可配置多个Webhook。地址必须加密保存、脱敏显示并经过安全目标校验；投递使用异步队列、幂等键、有限重试和投递日志，企业预警按企业汇总，通道预警按检测批次汇总，不逐条轰炸。
+- “签名质量检测”增加企业“企业签名 × 运营商”和通道“签名 × 通道 × 运营商”近30日方格。页面日期为T，展示`T-1`至`T-30`的提交尝试数、上游接受业务短信数、最终成功数和成功率；尚未报备或早于当前连续通过时间显示“不适用”，无真实提交显示灰色，其余复用现有六档色阶。
+- 页面模块顺序固定为“签名通道发送质量”在最上方，其后依次为企业、通道热力图。两张热力图按维度行各自独立分页，每页10行；翻动其中一张不得改变另一张页码，30日日期列继续在各自表格内横向滚动。
+- 两张热力图的日期列从左到右按日期由大到小展示，即从`T-1`依次到`T-30`。行首主信息只展示签名名称；通道热力图保留识别维度所必需的通道名称和运营商标签，企业名称与企业应用名称不在行内常驻，鼠标悬停签名时再展示。每张热力图内部提供独立搜索框，可按企业名称、企业应用名称或签名名称筛选，并在筛选后回到第一页，不影响另一张热力图。
+- 热力图有真实检测快照的发送量格子悬停文案必须明确区分“提交条数”和“发送成功条数”，同时可补充上游接受条数、成功率和阈值；不得把上游接受或`SubmitResp status=0`写成发送成功。报备前仍显示“不适用”，没有检测快照仍显示当日无快照。
+- 页面最下方增加“未报备签名”模块，按所选北京时间自然日统计已提交到平台且有签名的真实`SmsMessageRecord`。当短信号码运营商没有匹配到该签名当前可用的运营商级报备成功事实，且也没有仍处于通过状态的历史通道级兼容报备事实时，计入未报备短信；运营商级事实可位于任一未删除通道，历史兼容事实仅用于避免把旧系统真实通过误报为未报备。结果按“签名 × 实际企业应用”聚合业务短信条数，展示签名、企业、企业应用，支持按三者搜索和每页10行独立分页；无签名的异常消息不在该模块伪造成签名。
+- 数据统计菜单改名为“签名质量检测”，并删除企业应用发送排行、通道占比、当天发送量和当天成功率模块。本项删除已确认，不作为后续可选项保留。
 
 ## 通道组按通道筛选（2026-08-09）
 

docs/signature-retirement-alert-design.md

@@ -0,0 +1,190 @@
+# 签名清退预警与运营商级报备改造设计（本地实现稿）
+
+> 状态：2026-08-10已按确认口径完成本地兼容实现、迁移演练和自动化验证，修改仍未提交、未推送、未部署。严格运营商级发送门禁保持默认关闭；预生产迁移、历史确认、门禁切换和预警启用仍必须分阶段执行。
+
+## 0. 实施状态（2026-08-10）
+
+- 第1至15步已完成本地代码和文档实现；第16步已完成本地PostgreSQL迁移、专项与全量测试、真实聚合SQL、TypeScript、生产构建及授权后的真实验证码登录浏览器验收。
+- 本地迁移保留旧报备任务为`legacy_channel`，不自动复制为三个运营商通过；发送链优先使用精确运营商任务，并由`SIGNATURE_REPORT_STRICT_CARRIER`控制从兼容双读切换到严格门禁。
+- 本地实现未发送真实短信，未修改生产通道、账号、密码、启停状态、企业余额或客户连接；也未提交、推送或部署。
+
+## 1. 目标与范围
+
+本项目解决运营商因签名长期无真实发送而清退的问题，并将通道能力和签名报备状态细化到真实运营商。最终形成以下闭环：
+
+1. 通道支持移动、联通、电信多选，三个全选等价于现行“三网”。
+2. 签名报备事实由“签名 × 通道”升级为“签名 × 通道 × 运营商”。
+3. 发送选路只使用支持目标运营商且该签名在该运营商报备通过的通道。
+4. 每日按“企业签名 × 运营商”和“签名 × 通道 × 运营商”检测清退风险。
+5. 提供站内消息、临时/永久抑制、企业微信/飞书 Webhook 和近30日检测数据。
+
+本项目不改造引流信息报备。引流信息任务、任务详情、状态汇总和历史记录继续保持现有“签名 × 引流信息 × 通道”口径，不新增运营商维度。
+
+## 2. 已确认业务口径
+
+- 多运营商通道继续共用一个通道单价，不增加分运营商价格。
+- 一个签名最多关联一个企业应用；未绑定应用的签名只使用通用规则。
+- “部分成功”按运营商分别判断：任一运营商存在报备通过，就只将该运营商纳入监控，不等待三网全部成功。
+- 清退活跃量使用“至少有一次上游接受的去重业务短信数”。企业维度按业务短信去重；通道维度按`messageRecordId + channelId`去重。同一通道因断连、超时或重试产生多次提交只计一个活跃量；切换到另一个通道后，两个通道各计一次。
+- 提交尝试数、上游接受业务短信数和最终送达成功数分别展示，不把`SubmitResp status=0`描述为最终送达成功。
+- 每天按北京时间完整自然日检测`T-X`至`T-1`，当天数据不参与。当前连续报备通过时间未满X个完整日时不预警。
+- 规则修改从下一检测日生效；恢复正常后再次低于阈值形成新的预警周期。
+- 临时抑制天数可配置；永久抑制可以在“抑制管理”中取消。取消后从下一检测日恢复提醒，不补发历史通知。
+- 右上角预警数字为“今日未读且未抑制数”。抑制只影响提醒和Webhook，不停止检测快照生成。
+- 到达率颜色复用现有统一六档色阶。
+- “签名质量检测”页面删除企业应用发送排行、通道占比、当天发送量和当天成功率模块。
+
+## 3. 数据模型与事实来源
+
+### 3.1 通道运营商能力
+
+通道能力从旧单值`mobile/unicom/telecom/all`升级为非空运营商集合。通道组、通道组成员、路由规则和短信号码识别结果继续保持单运营商；只有通道能力集合包含目标运营商时，才能加入对应通道组并参与选路。
+
+### 3.2 签名报备任务
+
+继续以`ChannelSignatureReportTask`作为当前报备事实，以`ChannelSignatureReportRecord`作为不可变状态轨迹，不另建与任务重复的报备事实表。签名任务的业务唯一维度升级为：
+
+```text
+签名 × 通道 × 运营商
+```
+
+签名任务增加运营商、当前连续通过时间和历史兼容范围。任务每次从非通过状态进入`approved`时写入新的`approvedAt`；离开`approved`时清空。记录表继续保存每次状态变化、操作人、时间、来源和原因。
+
+`reportType`和`drainageItemId`只是现有共享表的技术字段，不属于本需求业务维度；引流信息任务不增加运营商。
+
+### 3.3 企业运营商报备汇总
+
+“企业签名 × 运营商”不是另一套可编辑事实，而是运营商级签名任务的只读汇总：
+
+- 至少一个当前运营商级任务为`approved`时，该签名的该运营商进入监控。
+- 监控起点取当前仍有效的通过任务中最早的`approvedAt`。
+- 当前有效任务全部退出通过时，该运营商退出监控；后续重新通过形成新的连续周期。
+
+## 4. 现有生产数据兼容
+
+旧单运营商通道能力可无损迁移为单元素集合；旧`all`只表示通道能力覆盖三网，不能证明该签名已在三个运营商分别报备通过。
+
+历史签名任务先保留为“历史通道级结果”，不得自动复制为三条运营商级`approved`：
+
+```text
+carrier = null
+approvalScope = legacy_channel
+页面状态 = 历史通道级通过（运营商未拆分）
+```
+
+运营端提供“拆分并确认运营商报备结果”，由操作员依据供应商真实信息分别确认移动、联通、电信的状态和通过时间，并记录操作人、依据和备注。供应商明确一次报备三网同时生效时，可以人工批量确认三个运营商并使用相同时间，但系统不得自动推断。
+
+兼容期内旧历史任务继续维持现有发送资格，避免上线新字段后中断真实发送；只有全部活动签名和活动通道完成运营商确认并通过数据门禁后，发送链才切换为严格运营商级校验。
+
+## 5. 预警规则与生命周期
+
+### 5.1 规则优先级
+
+- 企业预警：企业应用特殊规则优先于通用规则。
+- 通道预警：通道特殊规则优先于通用规则。
+- 每个规则分别配置移动、联通、电信的X天和Y条，并可启停或继承通用规则。
+- 规则修改保存后记录版本，下一检测日读取新版本；预警快照保存命中的规则版本和阈值，历史结果不随规则变化漂移。
+
+### 5.2 预警周期
+
+同一检测维度在连续低于阈值期间属于同一个预警周期；每天保存检测快照，但不创建重复周期。恢复达标后关闭当前周期；以后再次低于阈值创建新周期。
+
+每日快照必须使用唯一检测日和唯一维度保证幂等。多实例或任务重启不得重复生成预警、未读消息或Webhook。
+
+### 5.3 抑制与已读
+
+- 临时抑制支持常用天数和自定义天数，到期后的下一检测日自动恢复。
+- 永久抑制在“抑制管理”集中展示，取消时必须二次确认、填写原因并写操作日志。
+- 取消抑制不补发历史站内消息或Webhook。
+- 旧预警只读；最新预警可以进入抑制操作。抑制管理始终可以取消当前抑制。
+- 未读状态与抑制状态独立；右上角只统计今日未读且未抑制的消息。
+
+## 6. 30日检测数据
+
+- 企业区按“企业签名 × 运营商”展示。
+- 通道区按“签名 × 通道 × 运营商”展示。
+- 日期T由页面日期控件决定，展示`T-1`至`T-30`。
+- 每日展示提交尝试数、上游接受业务短信数、最终送达成功数和最终成功率。
+- 无真实提交显示灰色；尚未报备通过或早于当前连续通过时间显示“不适用”，不得伪装成零发送。
+- 其他非零数据复用现有红、橙、黄、蓝、绿、深绿六档色阶。
+
+## 7. 全部实施步骤（共16步）
+
+### 第1步：设计、需求与测试文档
+
+先完成本文、需求文档、规划测试用例和测试进度同步并交由用户评审；用户确认后才进入代码和数据库实现。本步骤已完成。
+
+### 第2步：用户评审与口径冻结
+
+由用户评审字段、交互、统计、历史兼容、抑制和发布顺序。用户已确认按步骤实施，本步骤已完成。
+
+### 第3步：发布基线与真实数据盘点
+
+重新核对Git、运行提交、migration、活动通道、通道组、路由、签名任务、历史记录和近30日业务短信数据；制作数据库与代码恢复方案。只读盘点，不发送短信、不修改通道。
+
+### 第4步：兼容数据库底座
+
+新增通道运营商能力集合；为签名报备任务增加`carrier/approvedAt/approvalScope`等兼容字段和条件唯一约束。旧字段继续可读，迁移只增加能力，不切换发送行为。
+
+### 第5步：通道历史能力回填
+
+将旧单运营商值回填为单元素集合，将`all`回填为三元素能力集合；已删除通道同样保留并迁移。核对记录数和所有外键关联，不改变账号、密码、状态或单价。
+
+### 第6步：通道运营商多选管理
+
+改造通道创建、编辑、复制、详情、列表筛选和审计；后端强制至少选择一个运营商。取消仍被活动通道组使用的能力时返回真实影响并阻止保存。
+
+### 第7步：运营商级签名报备后端
+
+升级签名任务创建、批量生成、状态修改、查询、删除治理和汇总逻辑。运营商必须属于通道能力集合；同一签名、通道、运营商只存在一个当前任务。
+
+### 第8步：报备任务与签名状态页面
+
+在签名页、报备任务页和通道报备详情页展示运营商级状态；同一通道可按三行或可展开三运营商展示。三网摘要只汇总真实运营商任务，不从通道级状态推断。
+
+### 第9步：历史报备拆分确认
+
+上线“历史通道级通过（运营商未拆分）”清单和人工拆分流程。完成活动数据确认，保留原任务和全部操作轨迹，禁止自动伪造三网通过。
+
+### 第10步：发送链兼容双读
+
+发送链优先读取运营商级任务；未完成拆分的历史任务暂时使用受控旧资格。记录每次使用旧资格的可观测指标，为严格切换提供清零门禁。
+
+### 第11步：严格运营商级发送门禁
+
+只有当活动历史未拆分数、旧资格命中数和异常数据全部为零后，才切换为“签名 × 通道 × 运营商”严格校验。专项验证断连、超时、补发和通道切换，避免误阻断真实业务。
+
+### 第12步：预警规则与通知配置
+
+实现通用规则、企业应用特殊规则、通道特殊规则、规则版本和多Webhook配置。Webhook地址加密保存、脱敏显示，并限制安全目标。
+
+### 第13步：每日检测、预警周期与快照
+
+实现北京时间每日幂等任务、企业和通道两类检测、连续周期、恢复关闭、规则快照和近30日聚合。不得以Mock、静态数据或前端计算代替真实数据库结果。
+
+调度固定拆为两个阶段：北京时间04:00只完成检测、周期推进和快照落库，同时冻结预警标题与正文；北京时间08:00再按快照创建站内消息、聚合Webhook并开始投递。服务晚启动时按所处时点顺序补偿，04:00前不检测、08:00前不发消息。由于自动调度、启动补偿和数据库幂等已覆盖日常及故障恢复，运营端不再保留手动检测按钮和对外管理接口。
+
+### 第14步：抑制、已读和Webhook投递
+
+实现临时/永久抑制、抑制管理、取消审计、未读状态、异步Webhook、幂等、失败重试和投递日志。抑制期间继续生成检测快照。
+
+### 第15步：预警页面和签名质量检测改版
+
+在安全控制增加“签名清退预警”，增加消息列表、今日企业/通道数量和顶部预警铃铛；原待审核铃铛更换为任务图标但保留全部功能。签名质量检测页先展示“签名通道发送质量”，其后增加企业、通道两类30日热力图；两张热力图按维度行各自独立分页、每页10行，日期列仍横向滚动。删除已确认不保留的四个统计模块。
+
+预警页签命名为“预警消息”，后端按消息创建时间的北京时间日期区间查询历史消息，并在同一查询中关联检测维度、企业、企业应用、签名和通道完成筛选、计数及每页10条分页；默认区间为今日至今日。抑制和取消抑制复用平台`Modal`，临时抑制以截止日期换算为后端天数，永久抑制不传天数，两者均要求原因；取消也要求原因，不使用浏览器原生弹窗。
+
+热力图日期列按`T-1`至`T-30`由新到旧排列；行首只常驻签名以及通道维度必要的通道/运营商标识，企业和企业应用通过签名悬停提示查看。企业、通道模块分别在前端对后端返回的真实维度按企业、企业应用、签名过滤并独立分页。格子悬停明确展示提交条数和最终发送成功条数，不混淆上游接受。
+
+页面底部增加独立的未报备签名查询。后端按所选北京时间自然日，以`SmsMessageRecord`为业务短信事实，按短信运营商检查该签名是否存在任一未删除通道上的当前运营商级`approved`任务；仍处于`approved`的历史通道级兼容任务视为已有真实旧报备，避免迁移期误报。其余按签名和消息实际企业应用聚合，后端完成关键字过滤、总数和分页，前端不使用静态数据或全量拉取伪分页。
+
+### 第16步：完整验证与分阶段预生产发布
+
+依次执行migration演练、真实PostgreSQL聚合、API专项、发送链、长短信、重试/补发、权限、Webhook安全、TypeScript、构建、结构契约和`git diff --check`。发布必须分别设置“兼容底座”“历史确认”“严格发送”“预警启用”门禁，不在一次发布中同时迁移、切换发送和启用预警。
+
+## 8. 暂停与回滚门禁
+
+- 第2步用户未确认：停止，不实施。
+- 第4至10步可回滚到能够读取运营商集合和历史任务的兼容版本；出现双运营商通道后不得回滚到只识别旧单值的版本。
+- 第11步严格门禁启用后，如出现真实发送资格异常，优先切回兼容双读版本，不回滚或覆盖已经产生的新业务数据。
+- 任一阶段不得为验收发送、补发或重投真实短信，不修改真实通道账号、密码、启停状态、企业余额或客户连接，除非另获明确授权。

docs/system-functional-test-cases.md

@@ -4488,9 +4488,9 @@ npm run verify:phase8
 | TC-ENTERPRISE-REGION-003 | 编辑一个已存省市值暂未出现在当前号段字典的历史企业 | 页面将档案原值补入当前选项并正常显示，未主动修改时不会被清空 |
 | TC-ENTERPRISE-REGION-004 | 断开字典API后打开新建企业 | 页面明确提示省市字典加载失败，不显示Mock、localStorage或旧的写死选项 |
 
-## 2026-08-09 通道支持运营商多选规划用例（需求暂缓、未执行）
+## 2026-08-10 通道运营商多选验收用例（本地自动化与浏览器验收完成）
 
-> 本节仅保存未来验收口径。当前版本不实现运营商多选，以下用例状态均为“暂缓、未执行”，不得据此判定现有系统缺陷或功能已完成。
+> 2026-08-09暂缓需求已重新纳入签名清退预警前置设计并完成本地兼容实现。以下仍是完整验收口径；自动化、真实本地数据库、构建和授权后的本地浏览器结果见本节末尾，未发送真实短信或向外部Webhook投递验收消息。
 
 | 用例编号 | 操作 | 未来预期结果 |
 | --- | --- | --- |
@@ -4499,9 +4499,64 @@ npm run verify:phase8
 | TC-CHANNEL-CARRIER-MULTI-003 | 将支持移动和联通但不支持电信的通道分别加入三类通道组并发送对应运营商短信 | 仅允许加入移动、联通通道组；电信组前后端均拒绝；发送链不会把电信短信选到该通道，通道组、路由规则和短信实际运营商仍为单值 |
 | TC-CHANNEL-CARRIER-MULTI-004 | 取消通道已被活动通道组引用的运营商，再尝试保存 | 后端返回对应真实通道组及影响并阻止保存，不自动删除成员、路由、报备任务或历史数据；解除活动引用后才允许取消 |
 | TC-CHANNEL-CARRIER-MULTI-005 | 多运营商通道参与移动、联通、电信发送及成本统计 | 三个运营商继续共用通道唯一单价，客户计费和平台成本不因多选被重复计算；本需求不产生分运营商价格 |
-| TC-CHANNEL-CARRIER-MULTI-006 | 检查签名报备任务、报备记录和三网汇总 | 当前暂缓方案不得伪造“签名 × 通道 × 运营商”结果；未来实施前必须重新确定报备升级范围，现有“签名 × 通道”历史记录不得删除或复制成多个虚假运营商结果 |
+| TC-CHANNEL-CARRIER-MULTI-006 | 检查签名报备任务、报备记录和三网汇总 | 签名任务按“签名 × 通道 × 运营商”保存和汇总；现有“签名 × 通道”历史记录保留为`legacy_channel`范围，不删除、不自动复制为多个运营商通过结果；引流信息报备维度和页面保持不变 |
 | TC-CHANNEL-CARRIER-MULTI-007 | 分阶段部署兼容底座后写入仅支持两个运营商的通道，再执行回滚演练 | 只能回滚到能够读取运营商集合的兼容版本；仅识别旧单值的代码不得重新上线并将双运营商数据误判为三网或单网 |
 
+## 2026-08-10 运营商级签名报备验收用例（本地自动化与浏览器验收完成）
+
+| 用例编号 | 操作 | 未来预期结果 |
+| --- | --- | --- |
+| TC-SIGNATURE-CARRIER-REPORT-001 | 为支持移动和联通的同一通道创建同一签名的报备任务 | 分别产生移动、联通两个独立任务；不产生电信任务；同一签名、通道、运营商不能重复创建当前任务 |
+| TC-SIGNATURE-CARRIER-REPORT-002 | 分别修改三个运营商任务状态 | 只改变目标运营商状态并写对应任务记录；签名三网摘要按真实任务分别汇总，不由通道级状态复制 |
+| TC-SIGNATURE-CARRIER-REPORT-003 | 任务首次通过、退出通过、再次通过 | `approvedAt`分别记录每次连续通过周期的开始时间；退出通过时旧时间不再作为当前监控起点，全部历史变化保留在记录表 |
+| TC-SIGNATURE-CARRIER-REPORT-004 | 打开签名页、任务页和通道报备详情 | 三个入口展示并操作同一份运营商级任务；运营商、状态、当前通过时间、操作轨迹一致 |
+| TC-SIGNATURE-CARRIER-REPORT-005 | 查看旧三网通道的历史通过任务 | 显示“历史通道级通过（运营商未拆分）”，不显示为移动/联通/电信分别通过，不进入运营商级清退监控 |
+| TC-SIGNATURE-CARRIER-REPORT-006 | 使用“拆分并确认运营商报备结果”分别确认三网状态和时间 | 只按人工确认创建或更新运营商任务，记录操作人、依据和备注；原历史任务及轨迹不删除 |
+| TC-SIGNATURE-CARRIER-REPORT-006A | 打开历史通道级已通过任务的“按运营商确认”弹窗，不进行选择 | 三个运营商均默认“请选择”，不得继承为“已通过”；逐项选择前“确认拆分”不可用，选择“已通过”但未填写有效通过时间时前端不可提交且后端直接拒绝 |
+| TC-SIGNATURE-CARRIER-REPORT-007 | 兼容期发送一条目标运营商短信 | 优先使用运营商级通过任务；只有未拆分历史任务才走受控兼容资格并留下可统计命中记录 |
+| TC-SIGNATURE-CARRIER-REPORT-008 | 历史未拆分数和兼容资格命中数不为0时尝试启用严格门禁 | 后端或发布门禁阻止切换；清零后才允许严格按“签名 × 通道 × 运营商”选路 |
+| TC-SIGNATURE-CARRIER-REPORT-009 | 通道断连、提交超时、补发并切换通道 | 每次重新选路都校验目标运营商报备；不选择未报备通道，也不因其他运营商已通过而放行 |
+| TC-SIGNATURE-CARRIER-REPORT-010 | 回归引流信息报备创建、状态修改、详情和历史 | 继续按“签名 × 引流信息 × 通道”工作，不出现运营商字段或新增运营商任务，历史数据不变 |
+
+## 2026-08-10 签名清退预警验收用例（本地自动化与浏览器验收完成）
+
+| 用例编号 | 操作 | 未来预期结果 |
+| --- | --- | --- |
+| TC-SIGNATURE-RETIREMENT-001 | 配置三网通用X/Y规则，并为一个企业应用或通道配置特殊规则 | 特殊规则优先于通用规则；保存规则版本，修改后的规则从下一检测日生效 |
+| TC-SIGNATURE-RETIREMENT-002 | 同一签名只有移动运营商报备通过 | 只生成移动监控维度；联通、电信不进入名单，不要求三网全部通过 |
+| TC-SIGNATURE-RETIREMENT-003 | 报备通过不足X个完整自然日后执行检测 | 不预警；达到X个北京时间完整自然日后才按`T-X`至`T-1`判断 |
+| TC-SIGNATURE-RETIREMENT-004 | 同一业务短信在同一通道因断连或超时产生多次提交 | 提交尝试如实展示多次，通道清退活跃量按`messageRecordId + channelId`只计一次，企业活跃量也只计一次 |
+| TC-SIGNATURE-RETIREMENT-005 | 同一业务短信从通道A补发到通道B | 企业活跃量只计一次；A、B各自通道活跃量分别计一次；最终成功仍按真实最终回执展示 |
+| TC-SIGNATURE-RETIREMENT-006 | 同一检测维度连续多日低于阈值，随后恢复，再次低于阈值 | 连续低量属于同一预警周期并保存每日快照；恢复后关闭周期；再次低量创建新周期 |
+| TC-SIGNATURE-RETIREMENT-007 | 重复执行同一检测日任务或两个实例并发执行 | 数据库唯一约束保证快照、周期、未读消息和Webhook均不重复 |
+| TC-SIGNATURE-RETIREMENT-008 | 设置自定义临时抑制并跨越到期日 | 抑制期间继续生成检测快照但不产生未抑制提醒或Webhook；到期后的下一检测日自动恢复 |
+| TC-SIGNATURE-RETIREMENT-009 | 设置永久抑制后从“抑制管理”取消 | 二次确认、原因和操作日志完整；下一检测日恢复，不补发被抑制期间的历史通知 |
+| TC-SIGNATURE-RETIREMENT-010 | 检查右上角计数并将消息标记已读 | 数字只等于今日未读且未抑制数；已读、已抑制及历史日期消息不计入 |
+| TC-SIGNATURE-RETIREMENT-011 | 配置多个企业微信和飞书Webhook并触发企业、通道预警 | 企业预警按企业汇总，通道预警按检测批次汇总；地址加密、脱敏，投递异步、幂等、有限重试并保留投递日志 |
+| TC-SIGNATURE-RETIREMENT-012 | 配置非法协议、内网地址或不可达Webhook | 非安全目标被阻止；合法但不可达目标按上限重试并终结失败，不阻塞检测事务，也不伪造成功 |
+| TC-SIGNATURE-RETIREMENT-013 | 切换页面日期并检查两类30日方格 | T随日期变化，展示`T-1`至`T-30`；企业按签名×运营商，通道按签名×通道×运营商，数据来自真实后端 |
+| TC-SIGNATURE-RETIREMENT-014 | 查看尚未报备、报备前、零提交和非零成功率日期 | 尚未报备或报备前显示“不适用”，零提交显示灰色，其他数据按现有六档色阶，悬停数量和成功率与真实聚合一致 |
+| TC-SIGNATURE-RETIREMENT-015 | 打开改版后的签名质量检测页面 | 企业应用排行、通道占比、当天发送量和当天成功率已删除，其余保留模块和真实查询不回归 |
+| TC-SIGNATURE-RETIREMENT-016 | 检查顶部任务入口和预警入口 | 原待审核入口改为任务图标但计数、弹层和跳转完整；新增预警铃铛进入预警列表，两个计数互不混用 |
+| TC-SIGNATURE-RETIREMENT-017 | 分别在北京时间04:00前后、08:00前后运行自动任务，并模拟服务跨过两个时点后重启 | 04:00只生成幂等检测快照且冻结规则版本和消息正文，不产生站内消息/Webhook；08:00才幂等创建站内消息并生成Webhook投递；晚启动按时点顺序补偿且不重复；页面和管理API均不存在手动检测入口 |
+| TC-SIGNATURE-RETIREMENT-018 | 打开签名质量检测页，并分别翻动企业、通道热力图 | “签名通道发送质量”位于两张热力图之前；两张热力图各按10个维度分页，页码相互独立，翻页不改变另一张页码，30日列仍可横向滚动且数据与真实API一致 |
+| TC-SIGNATURE-RETIREMENT-019 | 检查两张热力图日期、行首和悬停信息 | 日期从左到右为`T-1`至`T-30`；行首不常驻企业和企业应用，悬停签名可看到企业、企业应用；通道维度仍能识别通道和运营商 |
+| TC-SIGNATURE-RETIREMENT-020 | 分别在企业、通道热力图搜索企业、企业应用、签名并清空 | 每张热力图只过滤自身真实维度并回到第一页；三类关键字均可命中，清空恢复，另一张热力图的关键字和页码不变 |
+| TC-SIGNATURE-RETIREMENT-021 | 悬停报备前、无快照、零量和非零量格子 | 报备前显示不适用；无快照说明当日无检测；真实快照明确显示提交条数、上游接受条数、发送成功条数和成功率，发送成功等于真实最终送达而非受理成功 |
+| TC-SIGNATURE-RETIREMENT-022 | 所选日期构造有签名短信：运营商级已通过、历史通道级已通过、无通过任务、仅其他运营商通过、无签名 | 前两类不进入未报备模块；无通过任务和仅其他运营商通过按签名×实际应用计入；无签名记录不伪造成签名行；总条数与真实`SmsMessageRecord`一致 |
+| TC-SIGNATURE-RETIREMENT-023 | 在未报备签名模块按企业、企业应用、签名搜索并翻页 | 后端搜索、总数、每页10行和分页结果一致；列表展示签名、企业、实际企业应用和未报备短信条数，修改主统计日期后按新的北京时间自然日重新查询 |
+| TC-SIGNATURE-RETIREMENT-024 | 首次打开预警页面，随后选择历史日期区间 | 页签和区块标题均为“预警消息”；默认开始、结束均为今日且只返回今日消息，历史区间返回对应历史消息，每页10条并显示真实总数 |
+| TC-SIGNATURE-RETIREMENT-025 | 分别或组合选择企业、企业应用、签名关键字、通道及日期区间并翻页 | 后端同时应用全部条件，列表、总数和页码一致；条件变化查询后回到第1页，企业应用选项受企业筛选约束 |
+| TC-SIGNATURE-RETIREMENT-026 | 点击消息“抑制”，分别选择临时截止日期和永久抑制并填写原因 | 只出现平台自研弹窗；临时模式要求未来截止日期，永久模式不显示日期，两种模式原因必填，保存调用真实抑制接口且刷新当前筛选页 |
+| TC-SIGNATURE-RETIREMENT-027 | 在抑制管理点击“取消抑制”，填写或不填写原因 | 只出现平台自研弹窗；未填原因不能确认，填写后调用真实取消接口并刷新消息及抑制列表，不出现浏览器`prompt/confirm` |
+| TC-REPORT-RECORD-LAYOUT-001 | 在报备记录页面查看长备注和短备注 | 备注列桌面宽度不小于320px，使用统一长文本换行样式；宽表允许内部横向滚动，备注不被其他固定列挤成窄竖列，详情仍展示全文 |
+
+### 2026-08-10 本地执行状态
+
+- 已通过真实本地PostgreSQL迁移和数据约束检查、Prisma校验及84条迁移状态、API全量35个suite/444项测试、发送链112项测试、专项服务测试、API TypeScript构建、前端生产构建、4份Gateway队列结构契约、Gateway全量Go测试和`git diff --check`；检测统计SQL已对真实本地数据库执行，不使用Mock、静态数据或localStorage。
+- 通道能力集合、通道组兼容、运营商级报备、历史任务人工确认、发送资格兼容双读、每日检测幂等、规则版本、预警周期、抑制和Webhook安全边界已有自动化或数据库证据；严格运营商级发送门禁默认不启用，必须在历史未拆分和兼容命中清零后另行切换。
+- 未向外部Webhook投递验收消息，未发送、补发或重投真实短信。经用户授权使用本地专用平台管理员和真实算术验证码登录：预警5个页签、规则及Webhook弹窗、历史拆分、顶部独立计数、通道三运营商复选及零选拦截、运营商级报备文案、两类热力图与已删除统计模块均完成可见验收，控制台日志为0。页面已显示04:00自动检测、08:00发消息口径且不存在手动检测按钮。浏览器发现的历史三网默认全通过问题已修复并复验为三个“请选择”、确认按钮禁用。
+
 ## 2026-08-09 通道组按通道筛选用例
 
 | 用例编号 | 操作 | 预期结果 |

docs/testing-progress.md

@@ -3382,3 +3382,56 @@ git diff --check
 - Git使用`git revert --no-commit`反向撤销上述两个提交，不使用`reset`或`checkout`覆盖工作区。恢复后的业务源码、需求文档、测试用例和结构契约与`608662a`（即`78b839f4`功能版本加其部署记录）一致，仅追加本回滚记录。
 - 回滚后运营统计专项1 suite / 28 tests通过，API正式TypeScript构建、前端TypeScript和Vite v8.1.5生产构建通过（2535 modules，仅既有约2.04MB单chunk提示），依赖安全缓解门禁及`git diff --check`通过。`operations-r2`字节哈希门禁在完全恢复上一版本内容后仍受该文件历史混合CRLF/LF行尾影响而误报，Git归一化内容与`608662a`无差异；未为通过门禁改写上一版结构契约哈希。
 - 回滚没有发送、补发或重投真实短信，没有修改数据库记录、企业余额、通道账号、密码、启停状态或客户连接；受保护的构建缓存、`outputs/`和空文件`=`继续不提交、不删除。
+
+## 2026-08-10 签名清退预警与运营商级报备设计（待评审、未实施）
+
+- 已完整阅读用户提供的`C:\Users\hectorzhao\Downloads\签名清退预警.md`，并结合当前真实代码模型和预生产只读聚合重新评估。当前`ChannelSignatureReportTask`事实粒度为“签名 × 通道”，任务和记录均没有运营商字段；现有69条报备任务涉及28个签名、13个通道，38条当前通过任务都能找到通过轨迹，但不能据此自动拆成三网分别通过。
+- 新增评审稿`docs/signature-retirement-alert-design.md`，将完整实施拆为16步，固定先完成设计、需求和规划用例，再经用户评审后进入兼容数据底座。后续必须依次经过通道能力回填、运营商级签名任务、历史人工确认、发送链兼容双读、严格门禁、预警规则、检测快照、抑制/Webhook、页面改版和分阶段发布；不得在一次发布中同时迁移、切换发送和启用预警。
+- 原“通道运营商多选”暂缓需求重新纳入清退预警前置设计，但当前仍为“方案评审中、未实施”。通道目标能力为移动、联通、电信多选且共用一个单价；签名报备计划升级为“签名 × 通道 × 运营商”，继续复用`ChannelSignatureReportTask/Record`，不另建重复事实表。本需求明确不改造引流信息报备，`reportType/drainageItemId`不属于本需求业务维度。
+- 历史`all`通道只迁移为三网能力集合，旧报备任务保留为`legacy_channel`范围并显示“历史通道级通过（运营商未拆分）”；必须由运营人员依据供应商真实结果人工拆分确认，系统不得自动复制为三条运营商通过。严格运营商级发送门禁只能在活动历史未拆分数和兼容资格命中数清零后启用。
+- 已确认清退活跃量口径：企业按上游至少接受一次的业务短信去重，通道按`messageRecordId + channelId`去重；同一通道断连、超时或重试只计一个活跃量，切换到其他通道后各通道分别计一次。提交尝试、上游接受和最终送达分开展示，不把`SubmitResp status=0`称为最终送达成功。
+- 已确认规则下一检测日生效，恢复后再次低量形成新预警周期；临时抑制天数可配置，永久抑制从“抑制管理”取消且不补发历史通知；右上角只展示今日未读且未抑制数；颜色复用现有六档色阶；签名质量检测页面删除企业应用排行、通道占比、当天发送量和当天成功率。
+- `docs/system-functional-test-cases.md`已将原7条运营商多选用例调整为“规划、未执行”，并新增`TC-SIGNATURE-CARRIER-REPORT-001`至`010`、`TC-SIGNATURE-RETIREMENT-001`至`016`。这些用例当前不计入现版本通过率，也不得被解释为代码已完成或当前系统Bug。
+- 本步骤只修改设计、需求、规划测试用例和测试进度文档；未修改源码、Prisma schema或migration，未连接或修改预生产数据，未发送、补发或重投真实短信，未修改通道账号、密码、启停状态、企业余额或客户连接。文件保持未提交、未推送、未部署，等待用户先行评审。
+
+## 2026-08-10 签名清退预警与运营商级报备本地实现（未提交、未发布）
+
+- 用户确认设计后已按16步顺序完成本地最小充分实现：通道运营商多选、通道组及选路能力校验、运营商级签名报备、历史通道级任务人工拆分确认、兼容双读发送资格、清退规则/周期/检测快照、临时与永久抑制、已读消息、Webhook安全投递、顶部独立预警入口和两类30日热力图。引流信息报备保持原维度，未纳入本需求。
+- 修改继续复用`ChannelSignatureReportTask/Record`作为报备事实与轨迹；历史任务保持`legacy_channel`，不得自动伪造三网通过。严格运营商级门禁由`SIGNATURE_REPORT_STRICT_CARRIER=true`显式启用，当前默认关闭，后续必须等活动历史未拆分数和兼容资格命中数清零再分阶段切换。
+- 本地PostgreSQL迁移前已备份到`C:\cmpp-platform-local\backups\cmpp-platform-before-signature-retirement-20260810-165721.dump`（435753字节）。本地已完成84条migration；5条通道中3条历史空运营商按旧系统实际兼容口径回填为`mobile`，迁移后空集合0条、非法集合0条，并增加非空且只允许移动/联通/电信的数据库约束。历史报备任务1条，运营商级任务0条，未自动拆分；检测和开放周期唯一索引已核对。
+- 本地真实PostgreSQL上的清退统计SQL执行成功，返回提交尝试0、上游接受业务短信0、最终送达业务短信0，证明查询可由真实表执行；最终送达按真实分片审计和回执表归属目标通道，不把其他通道补发成功记到原通道，也不把`SubmitResp status=0`当作最终送达。
+- API全量测试35个suite/444项通过；真实Redis启动后发送链112/112通过；通道与清退专项、报备/发送配置/删除治理及发送链相关专项均通过。Prisma schema校验及84条迁移状态、API TypeScript构建、前端Vite生产构建、4份Gateway队列结构契约、Gateway全量Go测试和`git diff --check`通过；前端仅保留既有约2.05MB单chunk提示，差异检查仅输出既有LF/CRLF提示。
+- 本地PostgreSQL 5432、Redis 6379、API 3000和前端4173已启动供验收。API启动时尝试恢复本地活动通道，因未启动Gateway而记录连接失败；未修改任何生产配置，也未发送、补发或重投真实短信。经用户授权重置既有本地专用`codex_local_admin`临时密码、读取真实算术验证码并登录，未新建重复账号。
+- 全部代码、migration和文档均保持未提交、未推送、未部署；受保护的`api/tsconfig.build.tsbuildinfo`、`tsconfig.tsbuildinfo`、`outputs/`和空文件`=`不删除、不提交、不归因于本需求。
+- 登录后浏览器验收发现并修复历史三网任务弹窗默认把移动、联通、电信全部设为“已通过”的问题。修复后所有运营商默认“请选择”，必须逐项确认，且“已通过”必须填写真实有效通过时间；前端禁用不完整提交，后端不再回退使用历史通道级时间或当前时间伪造运营商通过事实。同步新增`TC-SIGNATURE-CARRIER-REPORT-006A`。
+- 修复后重新完成API专项3项、API TypeScript和前端生产构建，并精确重启本轮API/前端进程。浏览器复验历史拆分三项均为“请选择”且确认按钮禁用；通道编辑展示移动/联通/电信三个复选框，三项清空后显示“至少选择一个运营商”且未写入；报备明细显示“历史通道级（未拆分）”；清退预警5个页签、规则/Webhook弹窗、今日检测、顶部独立0条计数和两类30日热力图均正常，已确认删除的四个统计模块未出现，控制台日志为0。没有保存规则、Webhook或历史拆分，没有发送短信。
+
+## 2026-08-10 签名清退自动调度与本地验收数据（未提交、未发布）
+
+- 用户确认改为每天北京时间04:00自动检测、08:00发消息。检测阶段现只推进周期、写幂等快照并冻结规则版本、预警标题和正文；08:00通知阶段才创建站内消息、聚合Webhook并立即触发投递。服务晚启动时按04:00、08:00两个时点顺序补偿，两个阶段均依赖数据库唯一键防重。运营页面“执行今日检测”按钮和`POST /api/admin/signature-retirement/detect`管理接口已删除，内部`runDetection`仅供调度和测试。
+- 本地真实造数新增2家验收企业、2个应用、3条停用验收通道（华东三网、移动联通、电信专线）、4个审核通过签名、6条运营商级报备通过任务和42条历史消息记录，覆盖稳定活跃、低量、零量及跨通道失败后补发四类场景。数据脚本为`tools/local/seed-signature-retirement.mjs`，使用固定`qa-retirement-*`标识，重跑前只清理自身数据，不进入发送队列、不连接真实通道。
+- 真实造数首次暴露旧`ChannelSignatureReportTask_target_key`仍按“签名×通道”唯一、会阻止同通道多运营商事实。migration现明确删除旧索引，并分别建立运营商级签名、历史通道级签名和引流任务三个条件唯一索引；本地数据库已同步调整，成功保存同一签名/通道的移动和联通两条任务。
+- 使用正式`SignatureRetirementService`按时间顺序回放`T-30`至T共31个检测日，生成341条真实检测快照；今天11个维度中9个预警、2个正常，08:00通知阶段幂等生成9条未读站内消息。浏览器真实API显示右上角9条、今日预警9条，列表包含4/8/0等活动量；企业和通道热力图均展示07-11至08-09共30列的真实渐进数据，页面文案明确“04:00自动检测，08:00生成站内消息并发送Webhook”，手动按钮已消失。
+- 分阶段真实数据库复核先删除今天9条验收消息，再重复运行04:00检测，消息数保持0；随后运行08:00通知阶段才恢复9条。最终API全量35个suite/444项、Prisma validate及84条migration状态、前后端生产构建和`git diff --check`通过；三个新条件唯一索引均存在、旧`ChannelSignatureReportTask_target_key`已不存在，同一签名/通道的移动与联通任务可同时保存。造数后浏览器控制台日志为0。
+
+## 2026-08-10 签名质量检测模块顺序与热力图分页（未提交、未发布）
+
+- 按验收反馈将“签名通道发送质量”调整到页面最上方，企业、通道两张30日热力图依次下移；统计接口和真实数据口径不变。
+- 两张热力图分别增加独立的维度行分页，每页10行；各自页码互不影响，30日日期列继续保留表格内横向滚动。同步新增`TC-SIGNATURE-RETIREMENT-018`。
+- 使用Node.js 24.14.0完成前端TypeScript与Vite 8.1.5生产构建（2538 modules，仅既有大chunk提示），`git diff --check`通过且只有既有行尾提示。精确重启本轮本地Vite预览后，以已登录运营账号和真实本地API验收：页面模块顺序为发送质量、企业热力图、通道热力图；两张热力图各自显示一套上一页/下一页和页码输入控件，当前真实造数分别为5、6个维度，均为第1/1页，控制台日志为0。
+
+## 2026-08-10 热力图交互优化与未报备签名（未提交、未发布）
+
+- 企业、通道热力图日期列已调整为从左到右`T-1`至`T-30`；行首只常驻签名、运营商及通道维度必要的通道名称，企业和企业应用改为签名悬停文案。两张热力图分别增加企业、企业应用、签名即时搜索，筛选后各自回到第一页且互不影响；格子悬停明确展示提交、上游接受、发送成功、成功率和阈值。
+- 新增真实后端`GET /api/admin/signature-retirement/unreported-signatures`，按所选北京时间自然日和`SmsMessageRecord`统计。短信实际运营商在任一未删除通道存在当前运营商级通过事实，或仍存在历史通道级通过事实时不计入；其余按签名×消息实际企业应用聚合，后端完成关键字、总数和分页。
+- 本地自清理造数扩展为2家企业、2个应用、3条停用通道、6个签名、7条运营商级报备通过任务和52条消息，新增“完全未报备”和“仅移动报备但提交电信”两类场景；未进入发送队列且未连接真实通道。正式服务回放31个检测日后生成403条检测快照，今天13个维度中11个预警、2个正常，重复通知阶段新增0条，幂等保持。
+- 真实PostgreSQL聚合返回“完全未报备”6条、“仅移动已报备但提交电信”4条；浏览器按企业B搜索后只显示后者4条。企业热力图按企业B搜索只保留3个相关维度，通道热力图仍保留全部7个维度；签名悬停属性显示真实企业和应用，格子悬停属性显示五项明确口径，日期首列为08-09、末列为07-11，控制台error/warn为0。
+- 清退专项7/7、API全量35个suite/446项通过，API与前端TypeScript、API正式构建、Vite 8.1.5生产构建通过（2538 modules，仅既有大chunk提示）。API全量用例本身12.573秒完成，但既有异步句柄使Jest不自行退出，本次使用`--forceExit`收尾并保留该提示；两次外层超时遗留的本轮Jest进程已按精确命令行确认后停止，未影响API、前端、PostgreSQL或Redis。
+
+## 2026-08-10 预警消息检索分页、抑制弹窗与备注列宽（未提交、未发布）
+
+- “今日预警”已调整为“预警消息”，后端按预警日期、企业、企业应用、签名和通道执行真实PostgreSQL筛选及分页；页面默认选中北京时间今日，仅查询今日，支持历史日期区间并固定每页10条。本地回放最近5个检测日后，今日共11条：浏览器验收第1页10条、第2页1条；选择近7天并按“跨通道”签名查询返回15条、2页，可见`2026/8/9 08:00:00`历史消息及真实企业应用名称。
+- 抑制操作已改为自研弹窗，在同一弹窗内选择临时抑制截止日期或永久抑制并填写必填原因；切换永久抑制后截止日期隐藏。取消抑制也使用自研弹窗并要求填写取消原因。浏览器只验证弹窗打开、模式切换和未填原因时确认按钮禁用，没有确认保存或取消任何抑制。
+- 报备记录“备注”列统一使用长文本列规范，桌面端设置为320px并允许表格内部横向滚动；`docs/ui-design-guidelines.md`新增全局约束：长文本列最小240px、建议280–360px并使用`.ui-table__long-text`。浏览器读取“备注”表头计算宽度及最小宽度均为320px。
+- 清退专项9/9、API全量35个suite/448项通过；API与前端TypeScript、API正式构建、Vite 8.1.5生产构建通过（2538 modules，仅既有约2.06MB单chunk提示），`git diff --check`通过且仅输出既有LF/CRLF提示。真实查询回放脚本重复执行新增0条，证明QA消息生成幂等；未发送短信、Webhook，未保存抑制，未修改生产或预生产数据。
+- 本轮代码、测试和文档继续保持未提交、未推送、未部署；受保护的`api/tsconfig.build.tsbuildinfo`、`tsconfig.tsbuildinfo`、`outputs/`和空文件`=`不删除、不提交、不归因于本需求。

docs/ui-design-guidelines.md

@@ -63,6 +63,7 @@
 - 表头使用浅灰背景，字号 13-14px，字体 600。
 - 行高常规 64-86px，复杂两行信息可增加，但避免超过 110px。
 - 操作按钮采用文字或图标加文字，危险操作使用红色。
+- 备注、原因、说明、失败信息等不可预测长度的业务文本列必须显式设置列宽：桌面端最小240px，常规建议280-360px；不得省略`TableColumn.width`后任由其被固定信息列挤窄。长文本使用全局`.ui-table__long-text`样式正常换行并允许在任意长单词处断行，完整内容仍应可通过详情查看。宽表因此超过容器时使用表格内部横向滚动，不压缩长文本列到不可读宽度。
 
 ## 表单和弹窗