feat: integrate analytics and fragment receipt improvements

2026-08-03 15:34:41 +08:00
parent 3357ace7e1
commit 530a65de80
89 changed files with 1964 additions and 324 deletions
@@ -1,7 +1,7 @@
 {
  "version": "r1",
  "baselineCommit": "0af671b4ed4713912e703defd08791f164d4eb25",
-  "generatedAt": "2026-07-31",
+  "generatedAt": "2026-08-03",
  "coreFunctions": {
    "readErrorBody": "a12b96623f266784d928784ab83fe172fea7470f14b8e2be6684f776119b50dd",
    "requestPortal": "0b19b95d4ece5b775f2b62951368b1a8b19d7e74f4c2644b40b02866783b49ea",
@@ -311,7 +311,7 @@
      },
      {
        "name": "listTemplateAudits",
-        "implementationSha256": "cd52a1a4ce1d7a64468089f5cb7597904c246963665b1174e01ec6fce673760d"
+        "implementationSha256": "2d1a9f1441b5ab75fd464f29673e4534b8bc8737ac5b92425094af82d2489531"
      },
      {
        "name": "approveTemplate",
@@ -339,7 +339,7 @@
      },
      {
        "name": "listEnterpriseSignatures",
-        "implementationSha256": "e60e04452f022052a5aa21159b1b69828c7a0c7de731ce723c7d5742751ecb74"
+        "implementationSha256": "132c04125b1d2ae39fa21f8a71ecfe0d3e12e64cce3c8fab9d089e2423e329ee"
      },
      {
        "name": "listEnterpriseSignaturesPage",
@@ -363,7 +363,7 @@
      },
      {
        "name": "listDrainageInfos",
-        "implementationSha256": "e75bafd3e0bb991f853f9cb195b8043c2ab180383e14ae0bd195cba441c70dbe"
+        "implementationSha256": "9ff26a607e03786eaefd96f8e138509d01f14be71258c75c063b1555b1947960"
      },
      {
        "name": "listAuditRecords",
@@ -411,7 +411,7 @@
      },
      {
        "name": "listEnterpriseCertifications",
-        "implementationSha256": "dde64635239c428de705e832356bcf39195ae5ce3af93bccd08d0be0ca436d23"
+        "implementationSha256": "a02638b588d6c53d3b51df33336c012f1d9f3d0d4bb5ed9f7b550dd114d4e96c"
      },
      {
        "name": "getEnterpriseCertification",
@@ -571,11 +571,11 @@
      },
      {
        "name": "listOperationMessages",
-        "implementationSha256": "d89407edcb6942fe8bc5fd618c2fcc17abb151a1d395d76c512a1b8412a0cb71"
+        "implementationSha256": "ca21bae1df2e2df8d51ee8b3bc0e5d0cddf056cfa3e00dbb839ec0382b01b821"
      },
      {
        "name": "exportOperationMessages",
-        "implementationSha256": "01c49d9ca8e071c085244a9a2dd66e5f27d271ef9a746f18769956647a62cbd2"
+        "implementationSha256": "e42feb6aa6eacc571a2bc52315f24f4cdd54d673ce71ac49902893fc816ab62f"
      },
      {
        "name": "listAdminUplinkMessages",
@@ -635,7 +635,7 @@
      },
      {
        "name": "listRiskReviewTasks",
-        "implementationSha256": "1040e5775f210a00a26df88b3aac01523ca61c29409edd5f30e6e1c98fb3e5cc"
+        "implementationSha256": "8be7604b795105e51d3301a0e9c2f3a7a4b83a65981070fd64aafed27df67125"
      },
      {
        "name": "listRiskRules",
@@ -773,6 +773,26 @@
        "name": "deleteCommonReportField",
        "implementationSha256": "e305aff8b3eabaa020c2044d1993bbd8e5556d2b5b74451c2d97df44a91a96a9"
      },
+      {
+        "name": "listDrainageDetectionRules",
+        "implementationSha256": "f64be5ee02acc626a6cae581604a9a8400cfb6f4110913ab7a5d30e0518f8001"
+      },
+      {
+        "name": "createDrainageDetectionRule",
+        "implementationSha256": "165e44de881102c91f04076d3c5a34fc81fa5ac9d1dc55d5c5167d30f43f4944"
+      },
+      {
+        "name": "updateDrainageDetectionRule",
+        "implementationSha256": "6e7c079dd3511acedac00b7aa530c9568c7c066538667e253d685ba202af28de"
+      },
+      {
+        "name": "changeDrainageDetectionRuleStatus",
+        "implementationSha256": "950d2bfcf817375996d3160e96f48f89de15cee07b6545cbb1fe4c013b9fbb92"
+      },
+      {
+        "name": "testDrainageDetectionRule",
+        "implementationSha256": "908309fed077f6fa165715a8ee90ae1bcf1132b470fc4af013784aaae61a38a7"
+      },
      {
        "name": "uploadFileObject",
        "implementationSha256": "e4e12f112fdb40274b08c8109dc0bb585cd23ab62dfed0ce9e8e11ca7e508482"
@@ -1,7 +1,7 @@
 {
  "version": "R5",
  "source": "api/src/channels/channels.service.ts",
-  "generatedAt": "2026-07-31T02:40:10.189Z",
+  "generatedAt": "2026-08-03T15:27:00+08:00",
  "publicMethods": [
    {
      "name": "onModuleInit",
@@ -96,7 +96,7 @@
    {
      "name": "testChannel",
      "signature": "async testChannel(channelId: string, data: TestChannelDto = {})",
-      "canonicalBodySha256": "e01b10f3981c66c5fab6cfd6d1b886abbb45e1fe53852b57c0903fcd826815d3",
+      "canonicalBodySha256": "6336a3d1ecfb3c9fb838a9a198c35ab20009677e34b6cf23e7ac21f7d4b09f97",
      "originalLines": [
        536,
        636
@@ -32,6 +32,9 @@
    "--sidebar-width",
    "--topbar-height",
    "--control-height-md",
+    "--query-control-width",
+    "--query-date-range-width",
+    "--query-action-width",
    "--z-modal"
  ],
  "resetFile": "src/styles/reset.css",
@@ -1,9 +1,9 @@
 {
  "version": "r2",
  "baselineCommit": "0af671b4ed4713912e703defd08791f164d4eb25",
-  "generatedAt": "2026-07-31",
+  "generatedAt": "2026-08-03",
  "contracts": {
-    "MessageQuery": "07530ba61641758c96b5cd91dcdaba8692d5da4d9657d66e71009e7abf338f13",
+    "MessageQuery": "b2713cdb6dedf7d6d9c3aa23235b595a15a8f0c82c045a0bd9b39151a40cf00c",
    "TraceQuery": "636138d9593d61b2936eb32231d071b4682ca1d36cbf6a2b07d3b71b4f5d8453",
    "OperationLogQuery": "084d60f6487a2b38264211bf030950baacd2bc9b218e992867fb0e429dae7ece",
    "GatewaySubmitDeadLetterQuery": "d40dea1cc7d5ee369ab16a49cada5c6bcfae2b21fc66459c49d9377374aa1445",
@@ -47,7 +47,7 @@
      "group": "messages",
      "isPrivate": false,
      "signatureSha256": "37075fd6448d81f6acc25efe9a3670c8d6ec962add6a0b1e3115a31c05f8d7a6",
-      "bodySha256": "649439bf58c411100dcc24d634c7f2c87c6323c74cfc76539f853485c3c59461"
+      "bodySha256": "44fb733c7f072fb69a85eba97a9b896e0fc93b6daf240870ce595611725e26b9"
    },
    {
      "name": "listClientMessages",
@@ -117,14 +117,14 @@
      "group": "quality",
      "isPrivate": false,
      "signatureSha256": "7fa4cd6bcee4092390a38d693aa30c7980781ca1baa73dd07a3a61f097774e9c",
-      "bodySha256": "730b291f2fa96a9bcb054589a1341bc21f8ade161d232141d74f77eb426c4522"
+      "bodySha256": "e1334241997093de755a8e31ca8655694635b014d9016d6180dfd42ee283c231"
    },
    {
      "name": "signatureQuality",
      "group": "quality",
      "isPrivate": false,
      "signatureSha256": "6b9c3761674cb0d01000caca5e12cf91a6e526757592ffb783fc673c178b204c",
-      "bodySha256": "c85644b03f607339c2eae5390b01fb520264e87f16d0439c81a0c101b4277fa2"
+      "bodySha256": "a7203deb5a8c7c3b6f6afaf83a55bb1ff45a0bf198f86a2158868c4b8c759b2d"
    },
    {
      "name": "auditLogs",
@@ -240,7 +240,7 @@
    }
  ],
  "helpers": {
-    "messageWhere": "8d73104a7035970fceee92d95f2f76960c64aa5e1862be3441879d666d57a947",
+    "messageWhere": "072069862f457a9ed100e76fefe664c6c7b9a977ca21cd51eb6bfcf548dcb2a5",
    "recognizedCarrierValues": "d60957621e921bf9f5df8fdef616f4e2a0b16be78623c85316a65bae83025bdb",
    "carrierWhere": "1c7947c02a1a5cd3aaeda4a586421f6d7d63ae2f912cb11292831af2ffa4c379",
    "startOfShanghaiDay": "12eb964ff5ab3680837cf50bccabe5e8e7af733c248d06cb57f20c0c65ce0b4e",
@@ -1,6 +1,6 @@
 {
  "version": "R10",
-  "generatedAt": "2026-07-31",
+  "generatedAt": "2026-08-03",
  "source": "api/src/send-chain/send-chain.service.ts at R9 local baseline",
  "facade": "api/src/send-chain/send-completion.service.ts",
  "methods": [
@@ -67,7 +67,7 @@
    {
      "name": "handleReceipt",
      "file": "send-receipt.service.ts",
-      "bodySha256": "e3b63dc74af50db96d899c805124c7974067ca729e44a1ec8a558569e81fbd6c"
+      "bodySha256": "7302c72f2f3f3e374f38c365234f1a9705e80150de750d6fee73c22856efee46"
    },
    {
      "name": "recordReceiptSegment",
@@ -77,7 +77,7 @@
    {
      "name": "aggregateReceiptSegments",
      "file": "send-receipt.service.ts",
-      "bodySha256": "7dc565bd0847462bd0e23b5f072a4f82fd6daa88f164485138ce653d8cf936b8"
+      "bodySha256": "865a66025c8320096fac36c827b34bd612ccb34a11d523fd8590cdd4491da523"
    },
    {
      "name": "resolveReceiptMessage",
@@ -177,7 +177,7 @@
    {
      "name": "queueAndTryDownstreamDelivery",
      "file": "send-downstream-delivery.service.ts",
-      "bodySha256": "0b5f6f5e9ffebad5ddda003962efdabb0daeb2ec5942a246bdf9d922f274d4ac"
+      "bodySha256": "190b4c332e5913ef5ec44a25694270ef6320b3203df347bd25ef40f22cc0d7d9"
    },
    {
      "name": "resolveUplinkMatch",
@@ -187,7 +187,7 @@
    {
      "name": "recordCmppFailureReceipt",
      "file": "send-downstream-delivery.service.ts",
-      "bodySha256": "d48ecabfcce62787668486a8f14b3ea7afc935d5d5d910651fc1ddf8d8ac3952"
+      "bodySha256": "030175c6265820e62350a1527270627f90404df343ace9faf42e929fc00db790"
    },
    {
      "name": "postGatewayControl",
@@ -197,7 +197,7 @@
    {
      "name": "markUnknownTimeout",
      "file": "send-timeout.service.ts",
-      "bodySha256": "6f254ffbf05067483801cdd2c131f32cb9aaaf755d19f3aff065fe99b8d7753b"
+      "bodySha256": "21a83514324e383e11c0c3c369f0478d3d09dba7c52e479685141a4d9a1fd9d2"
    },
    {
      "name": "markExpiredDownstreamDeliveries",
@@ -20,7 +20,7 @@
    {
      "name": "GatewayInboundSubmitDto",
      "kind": "interface",
-      "sha256": "28f99a1e29385b64c3a6b4eab2e5befa3fc6cd8a6995090e0865f5af6871246a"
+      "sha256": "9662a33869bb44dacf7a56d1b907e31a7f6c1b9129e536cae2f234f1087074e3"
    },
    {
      "name": "GatewayInboundSingleSubmitResult",
@@ -257,7 +257,7 @@
    {
      "name": "drainageRejectionReason",
      "kind": "function",
-      "sha256": "4bc0aa5e5c7f96549cd8bad93d3b25fd5e65e6b017ae9bf83baa5c47cab08c02"
+      "sha256": "98308cc1e9cb4d8979da0484992d0ba272046e122912b68cfc13b33ac80bf7f2"
    },
    {
      "name": "statusFromRisk",
@@ -1,12 +1,12 @@
 {
  "version": "R9",
-  "generatedAt": "2026-07-31",
+  "generatedAt": "2026-08-03",
  "source": "api/src/send-chain/send-chain.service.ts at R8 local baseline",
  "target": "api/src/send-chain/send-*.service.ts via send-submission.service.ts compatibility facade",
  "methods": [
    {
      "name": "createBatchTask",
-      "bodySha256": "c7baccb2b49a95ef4b36a97f6f56c987f0ac60c45ed634cd050201f2a9bce8b5",
+      "bodySha256": "7ba5573e99f0616a7e57f53c242c60f3ec96d66a5164bbb170f177805ddfe9b0",
      "file": "send-batch-entry.service.ts"
    },
    {
@@ -66,7 +66,7 @@
    },
    {
      "name": "submitInboundMessage",
-      "bodySha256": "281e33a732f80e4ede6cc9d04a5b206a9348e17e66dee33d53f2d8d1d9bb9472",
+      "bodySha256": "dfe4a7516f9472870957e40acbe74fb7c8f76dd2113dda9ce06ea338241d1dba",
      "file": "send-inbound-entry.service.ts"
    },
    {
@@ -81,7 +81,7 @@
    },
    {
      "name": "collectInboundLongMessageFragment",
-      "bodySha256": "5b4e7f795966462fccb8c4c7a2cfae649ef19ee1b8176e7356eb2d621526ba41",
+      "bodySha256": "ac157c4848e12d46b98d46a8fbb13b65c6f18ae6dd2de3340d68f8bfa6908f63",
      "file": "send-inbound-entry.service.ts"
    },
    {
@@ -91,7 +91,7 @@
    },
    {
      "name": "submitInboundSingleMessage",
-      "bodySha256": "df97548b1710b217f118cc297104d6c5cc845acc40947df4180036b8d284d847",
+      "bodySha256": "6fa4c577848eb06f635a8f186d1e1510b1213f0ba6d439d032ea08c593725d14",
      "file": "send-inbound-entry.service.ts"
    },
    {
@@ -156,7 +156,7 @@
    },
    {
      "name": "resolveTemplateMessageClassification",
-      "bodySha256": "f2b99e2e9d7fa00172b3cca72f080493fbf6f090f378784611388320254575f7",
+      "bodySha256": "33c02992cc542862382456ffc4674cf0359e3b3e9271cabb23bd4d6f041f17a9",
      "file": "send-batch-entry.service.ts"
    },
    {
@@ -52,6 +52,9 @@
      "ui-modal__header",
      "ui-modal__body",
      "ui-modal__footer"
+    ],
+    "src/components/ui/DateRangeInput.tsx": [
+      "ui-date-range-field"
    ]
  },
  "requiredRuleFragments": [
@@ -105,6 +108,19 @@
        "gap:var(--space-6)"
      ]
    },
+    {
+      "selector": ".ui-filter-row",
+      "includes": [
+        "display:flex",
+        "flex-wrap:wrap"
+      ]
+    },
+    {
+      "selector": ".ui-filter-actions .ui-button",
+      "includes": [
+        "width:var(--query-action-width)"
+      ]
+    },
    {
      "selector": ".form-grid--two",
      "media": "(max-width: 780px)",
@@ -112,6 +128,21 @@
        "grid-template-columns:1fr"
      ]
    },
+    {
+      "selector": ".ui-filter-actions",
+      "media": "(max-width: 780px)",
+      "includes": [
+        "grid-template-columns:repeat(2, minmax(0, 1fr))",
+        "width:100%"
+      ]
+    },
+    {
+      "selector": ".ui-filter-actions",
+      "media": "(max-width: 360px)",
+      "includes": [
+        "grid-template-columns:minmax(0, 1fr)"
+      ]
+    },
    {
      "selector": ".table-actions",
      "media": "(max-width: 780px)",
@@ -1,7 +1,7 @@
 {
  "version": "R3",
  "source": "api/src/sms-config/sms-config.service.ts",
-  "generatedAt": "2026-07-31T01:56:36.226Z",
+  "generatedAt": "2026-08-03T15:32:00+08:00",
  "publicMethods": [
    {
      "name": "onModuleInit",
@@ -204,8 +204,8 @@
    {
      "name": "listSignatures",
      "signature": "async listSignatures(queryOrTenantId?: string | SignatureListQuery)",
-      "bodySha256": "9e8d363c2ee1022f429a9fa16e5e933f334a528e640f49ccd83e0cfc7686aea6",
-      "canonicalBodySha256": "91e26f503140018b00afe5563a4f86d22117c2805ac86532559ac44f1360d8a2",
+      "bodySha256": "bb4d8d983ed5cda59235b39396d09a568a554ad72c564ef4daab2d92dac6633a",
+      "canonicalBodySha256": "bb4d8d983ed5cda59235b39396d09a568a554ad72c564ef4daab2d92dac6633a",
      "originalLines": [
        915,
        1025
@@ -215,8 +215,8 @@
    {
      "name": "listSignaturesPage",
      "signature": "async listSignaturesPage(query: SignatureListQuery)",
-      "bodySha256": "24e161ae5049af0689d3a9d0e4ab802964b87b1f2d407d8309b8e6cbe8afdd56",
-      "canonicalBodySha256": "34ee94d016bdc986d98b01612f4c64fdc03b0e921abedeff8fe84bd64dec958c",
+      "bodySha256": "b3554a30debe1457938985f211c9107a4ca26b28581509b523810a45bb6f432a",
+      "canonicalBodySha256": "b3554a30debe1457938985f211c9107a4ca26b28581509b523810a45bb6f432a",
      "originalLines": [
        1027,
        1058
@@ -325,8 +325,8 @@
    {
      "name": "listDrainageInfos",
      "signature": "listDrainageInfos(query: DrainageInfoListQuery = {})",
-      "bodySha256": "2841e83c70180cdce83943d9d6ae212a9d29c6eae701ecf928bdbaedbdc93457",
-      "canonicalBodySha256": "0de53393ca5f91da7a521c13a96813b1f8211ded00f0fa797b752b6a87b73148",
+      "bodySha256": "99f53b52b01b3f75fe85886a1b62c98d1ae7fa72afb11eae98bbdc88103616c8",
+      "canonicalBodySha256": "99f53b52b01b3f75fe85886a1b62c98d1ae7fa72afb11eae98bbdc88103616c8",
      "originalLines": [
        1302,
        1319
@@ -413,8 +413,8 @@
    {
      "name": "listTemplates",
      "signature": "listTemplates(queryOrTenantId?: string | TemplateListQuery)",
-      "bodySha256": "c7c9b9b6f03c046c94459d021604dcce3b5d9d2ce192d547bce9d31310b27a7f",
-      "canonicalBodySha256": "e276e9f029b2cb5d5cf9551959f0525a9c501fefc97bf7a9300ba9d6554aa714",
+      "bodySha256": "0cd3e2ab2856057243722f323915cc4e905e3af888f8f70d8a9f164a07ebb234",
+      "canonicalBodySha256": "0cd3e2ab2856057243722f323915cc4e905e3af888f8f70d8a9f164a07ebb234",
      "originalLines": [
        1558,
        1583
@@ -424,8 +424,8 @@
    {
      "name": "listTemplatesPage",
      "signature": "async listTemplatesPage(query: TemplateListQuery)",
-      "bodySha256": "a0a7baafc68189e2daf93b970826f7d60ee60aa35662f48eeb7b4cb4e119b021",
-      "canonicalBodySha256": "2e836e44a397557b95cb0d978745df82c9c86cf77360157e78382ca71c0156a0",
+      "bodySha256": "c4b8553dd957e8471cd6ccb970162694f2db62141c66b5b3014220e0eeb866cc",
+      "canonicalBodySha256": "c4b8553dd957e8471cd6ccb970162694f2db62141c66b5b3014220e0eeb866cc",
      "originalLines": [
        1585,
        1608
@@ -833,7 +833,7 @@
    },
    {
      "name": "DrainageInfoListQuery",
-      "sha256": "9cd9cfe5af9422ed64d5d00071c9b4c58b0ae820c43eeb7dad604b67fd5f6fc1"
+      "sha256": "40708e60bfa39481897d00a8b2e99583effdffdd588efd99ee9b73687eae82ae"
    },
    {
      "name": "CreateSignatureMaterialDto",
@@ -861,7 +861,7 @@
    },
    {
      "name": "TemplateListQuery",
-      "sha256": "06c34488ffaa2d870d781fc2f666e294c408eefce1acb1ece11727f6aabc76c2"
+      "sha256": "9d38ad4689f0cda80c3d921a3a05e93cdf0b8a7696c782d5d9541966347bf78a"
    },
    {
      "name": "ApplicationListQuery",
@@ -869,7 +869,7 @@
    },
    {
      "name": "SignatureListQuery",
-      "sha256": "619cbff41cf63f18e5732ebfc8f899c5fd5c3394f7c54d9788e0561bc25eb027"
+      "sha256": "04cd16b62df3c381cd6c0ef873fb192e56fb745dd1adf1bdf550a8800aad2256"
    },
    {
      "name": "GatewayDownstreamConnectionEventDto",
@@ -16,6 +16,7 @@
 - 企业应用连接详情只展示当前已连接会话；断开或心跳超时会话从活跃连接表删除，不保留为连接历史。
 - 短信审核批量通过必须基于明确勾选，只处理已选待审核任务；不得默认通过当前筛选结果或全部数据。
 - 下游投递记录支持创建日期范围筛选，并将日期条件下推 PostgreSQL 列表与 Dashboard 聚合。
+- 下游投递记录和恢复状态管理的多条件筛选区必须遵循共享查询控件规范：普通条件、日期范围和操作按钮使用统一宽度，空间不足时按完整控件自动换行，不允许为维持单行而压缩、重叠或截断控件；移动端条件整行展示，查询与重置按钮保持清晰的独立操作区。
 - 短信模板变量插入到文本框当前选区或光标位置，插入后光标移动到变量之后。
 - 运营端短信记录使用自适应信息卡片，发送详情按概览、短信内容、通道回执、状态和分片审计分组，失败原因使用独立警示区域突出；该项只调整前端展示，不改变短信记录后端语义。
 - 人工充值弹窗不要求填写操作人，操作身份从当前登录会话和后端操作日志取得。
@@ -1691,7 +1692,7 @@
 4. 通讯日志不得保存短信正文、密码、密钥、Token、签名鉴权值或完整HTTP请求体；手机号只保存脱敏值。CMPP心跳不得逐包写入数据库，连接健康仍使用连接状态和聚合指标。
 5. 通讯日志写入不能阻塞短信主链路，默认批量异步写入，缓冲区应有上限和溢出告警；热数据默认保留30天，保留期允许通过环境变量配置。
 6. 通讯日志方向固定使用“企业应用 → 平台、平台 → 供应商通道、供应商通道 → 平台、平台 → 企业应用”。供应商长短信每个真实 `SUBMIT` 和 `SUBMIT_RESP` 分片各记一条，企业应用每个真实 `SUBMIT_RESP` 也必须记录；内部 `submit-result` 聚合回调不是协议报文，不得重复生成通讯日志。
-7. 供应商长短信回执必须先写入对应 `SmsMessageSegmentAudit`。仅当同一提交尝试的全部分片均为 `delivered` 时，主记录才转 `delivered` 并向企业应用投递一次最终回执；任一分片明确失败可进入最终失败/补发状态，分片尚未齐全时主记录保持 `submitted`，不得由首片成功提前聚合。
+7. 供应商长短信回执必须先写入对应 `SmsMessageSegmentAudit`。仅当同一提交尝试的全部分片均为 `delivered` 时，主记录才转 `delivered`；任一分片明确失败可进入最终失败/补发状态，分片尚未齐全时主记录保持 `submitted`，不得由首片成功提前聚合。内部业务终态只聚合一次，但对企业应用的CMPP状态报告必须按其原始Submit分片逐片投递，并分别使用平台当初为该分片返回的`CMPP_SUBMIT_RESP.Msg_Id`；HTTP Webhook仍按原HTTP消息投递一个最终事件。
 8. 长短信任一分片返回非成功终态时，系统必须通过该分片审计关联的提交记录识别当前发送尝试，不得仅以主记录保存的首片上游消息号判断；确认属于当前尝试后，整条短信立即进入失败/补发或退款终态，无需等待其余分片回执。
 9. 回执和上行投递方式不得由运营人员选择。企业应用开通CMPP接口即按CMPP投递，开通HTTP接口且对应Webhook地址非空即按HTTP投递，两者同时满足时双投；任一地址为空时只跳过该类HTTP事件。运营端企业应用HTTP参数页必须始终可编辑回执和上行Webhook地址，不因HTTP接口开关关闭而隐藏。
 10. Gateway向企业应用发送真实 `CMPP_DELIVER` 以及收到企业应用真实 `CMPP_DELIVER_RESP` 时，都必须各写一条通讯交互日志，分别使用“平台→企业应用”和“企业应用→平台”方向；下游投递记录继续承担排队、重试和ACK业务状态，不得以通讯日志替代。
@@ -1709,7 +1710,8 @@
 1. 用户逻辑删除后，原用户记录、用户主键及历史审计关联必须继续保留；用户名、邮箱和手机号仅在未删除用户范围内唯一。新建用户可以复用逻辑删除记录曾使用的登录标识，但必须生成新的用户主键，不得继承旧用户的角色、企业归属、密码、会话或权限。
 2. 用户登录和按用户名查找必须显式排除逻辑删除记录。活动用户之间的登录标识并发冲突继续由PostgreSQL唯一索引保证，并返回HTTP 409、冲突字段及明确中文提示。
 3. 运营端用户管理将用户姓名、登录账号、所属企业、用户角色和状态拆分为独立条件；客户端将用户姓名、登录账号和状态拆分。点击查询或重置时调用真实后端组合查询，条件之间使用AND，登录账号内部对用户名、邮箱和手机号使用OR；不得加载全量数据后仅在浏览器过滤。
-4. 删除、禁用或降权最后一个平台管理员时，后端实时拦截继续作为权威判断；企业管理员不设“最后一名”保护，可删除或停用至零人。前端必须在当前确认弹窗内以`role=alert`显示平台管理员保护失败原因和处理建议，保持弹窗打开，禁止只向浏览器控制台输出未处理Promise；请求期间确认按钮必须禁用。
+4. 运营端用户管理的五组查询条件与查询/重置操作必须使用共享查询控件宽度并允许按完整控件自然换行；不得通过缩窄字段把所有条件强塞在一行。“新增用户”作为业务操作与查询操作保持独立，在窄屏下不得挤入查询字段之间。
+5. 删除、禁用或降权最后一个平台管理员时，后端实时拦截继续作为权威判断；企业管理员不设“最后一名”保护，可删除或停用至零人。前端必须在当前确认弹窗内以`role=alert`显示平台管理员保护失败原因和处理建议，保持弹窗打开，禁止只向浏览器控制台输出未处理Promise；请求期间确认按钮必须禁用。
 ## 2026-07-26 企业应用停用与回执清算补充要求

 - 删除企业前必须检查其企业应用；只要存在`active`或`disabling`应用就阻止删除，并提示先完成应用停用。
@@ -1768,7 +1770,7 @@
 1. 同一`SmsSubmitRecord`无论收到多少个分片失败回执、重复聚合结果或并发工作线程，只允许创建一个下一跳补发记录。数据库必须以来源提交记录建立唯一补发关系，不能只依靠进程内锁、先查后建或短信主记录当前状态判断。
 2. 任一分片明确失败仍可及时判定本次长短信尝试失败，不要求等待其余失败回执；后续分片回执继续完整落库和写通讯日志，但只能复用已取得的补发决定，不得再次向Gateway发布提交命令。
 3. 短信扣费、冻结释放和最终失败退款必须使用稳定业务幂等键。企业账户余额变更在数据库事务内按企业串行并使用原子增量，禁止读取旧余额后覆盖写入；相同幂等键重复调用必须返回原交易，不得再次改变余额。
-4. 同一短信记录只允许生成一条最终回执投递。CMPP下游投递使用数据库唯一去重键，HTTP Webhook使用稳定事件号和事件/端点唯一关系；重复终态处理返回原投递，不得再次向客户发送。
+4. 同一短信记录只允许形成一个内部最终业务结论、一笔最终退款和一个HTTP最终回执事件。CMPP下游必须按原始客户Submit分片分别生成最终状态报告，使用“短信记录+原始客户分片序号”数据库唯一键；同一分片重复终态处理返回原投递，不得再次发送。HTTP Webhook继续使用短信记录级稳定事件号和事件/端点唯一关系。
 5. 补发抢占成功、并发复用及下游投递去重必须写结构化日志，至少包含平台消息号、短信记录、来源提交记录、下一跳`submitId`、通道和复用的投递记录。
 6. 历史重复提交、通讯报文、回执、退款及客户ACK属于事故审计证据，不得在功能migration中删除或覆盖。历史余额修正必须先完成账户与流水专项对账，再通过可审计冲正处理。

@@ -1873,3 +1875,32 @@
 - 短信发送页的字数和预计条数必须随编辑后的实际短信内容即时重新计算；单条短信不超过70个Unicode字符计1条，长短信按每67个字符计费，预计条数为单号码计费条数乘有效号码数。单价单位显示为“元/条”。
 - 提交发送任务失败时使用页面中央弹窗展示真实后端错误；定时发送控件提供按北京时间计算的“今天”按钮，并以浅色背景标出北京时间当天。提交给后端的定时时间必须显式携带`+08:00`时区。
 - 提交任务成功后弹窗展示真实任务编号和发送号码数。“继续发送短信”清空当前发送表单和导入内容；“查看任务进度”进入批量任务页面并按任务编号定位本次任务。
+
+## 工作台金额与审核查询控件统一（2026-08-03）
+
+- 客户端短信服务工作台在“今日返还金额”前展示“今日消费金额”，金额取当前企业 Dashboard API 按北京时间当天汇总的真实消费值，与运营端账务口径一致，不在浏览器重新估算。
+- 审核中心的企业认证、短信、短信模板、短信签名和引流信息审核页面均提供“提交时间”日期区间筛选；短信签名和引流信息的“导入批次审核”页签也按导入批次提交时间筛选。
+- 提交时间筛选必须传入真实后端并由 PostgreSQL 执行。日期边界按 `Asia/Shanghai` 自然日解释，开始日包含 `00:00:00`，结束日包含 `23:59:59.999`；格式非法、日历日期不存在或开始日晚于结束日时，API 返回受控参数错误。
+- 运营端查询区建立全局统一尺寸：普通输入框/下拉框使用统一标准宽度，日期区间控件使用更宽的统一宽度，查询/重置按钮使用统一固定宽度；窄屏下控件和按钮自适应整行，不产生页面级横向溢出。
+- 风控规则页的规则范围、平台白名单和号码频次触发记录三组查询条件均使用上述统一布局。白名单和触发记录提供查询、重置，重置后以明确的默认条件重新请求真实后端。
+
+## 短信内容引流信息识别与统计（2026-08-03）
+
+- 本期只识别、记录、查询和统计短信内容是否含引流信息。引流资料是否已报备、审核状态及报备进度均不得拦截或转人工审核；所有发送入口移除`DRAINAGE_NOT_APPROVED`决策，既有模板、签名、余额、黑名单和其他风控规则保持不变。
+- 运营端“系统管理”新增“引流识别规则”页面，规则存储在真实数据库，支持 URL、手机号码、固定电话三类表达式的新增、编辑、启停、优先级和测试。变更保留版本并写操作日志，发送入口按当前启用规则生成识别快照和规则版本。
+- URL 识别覆盖带协议链接、无`http://`的裸域名、短链接、IP 地址及端口/路径，并支持中文标点相邻、空格或中文句号拆分等规避写法；手机号码支持`+86`、空格、短横线和中文标点拆分；固定电话支持区号括号、分隔符和分机号。邮箱地址不属于引流信息。
+- 识别规范化只作用于检测副本，不得修改真实短信发送内容。消息记录持久化是否含引流、命中类型、原文位置、规则版本和检测时间；历史未检测数据保留为“未检测”，不得伪造为不含引流。
+- 运营端短信记录提供“是否含引流信息”筛选，支持含引流、不含引流和未检测；含引流记录使用提示色底色并高亮原文命中片段，CSV 同步导出该维度。
+- 数据统计的签名发送质量明细保留原“通道 × 运营商”整体矩阵，并提供按含引流、不含引流、未检测切分的矩阵视图；整体统计必须直接反映全部提交，不得用分组平均值替代。
+- 运营看板“今日签名发送统计”按签名统计全部短信，不区分是否含引流；“今日签名发送统计 - 含引流”只统计内容识别结果为含引流的消息。
+- 未来可在识别结果之上增加发送、拒绝或人工审核决策，但必须作为独立迭代启用，不能在本期以隐式状态或既有报备审核逻辑提前拦截。
+
+## CMPP逐分片最终回执与72小时超时回执（2026-08-03）
+
+- CMPP协议状态值中的`ACCEPTD`、`UNKNOWN`不得在产品和代码中扩展解释为协议规定的“临时状态生命周期”；平台只依据明确业务规则判断是否继续等待，不能臆造协议阶段。
+- Gateway接收每个客户`CMPP_SUBMIT`时必须保存该包的`Registered_Delivery`和`Sequence_Id`。长短信每个原始分片的身份独立保存，不得只保留第一片；历史未保存`Registered_Delivery`的CMPP记录按原有“请求回执”行为兼容。
+- 内部仍以一条`SmsMessageRecord`聚合长短信业务终态、重投、计费和退款；对外CMPP状态报告按原始客户分片逐片建立。每片使用`SubmitGroupMessageId + 原Sequence_Id`重建平台当初返回的`SUBMIT_RESP.Msg_Id`，并以“短信记录+客户分片序号”独立幂等。
+- 已取得真实分片回执时，下游对应分片必须使用该片自己的状态、原始状态码、错误码和到达时间，不得把另一片的结果复制过来；整条短信明确最终失败而部分片仍无结果时，缺失片使用整条短信的明确最终失败状态，已成功片不得改写为失败。
+- `Registered_Delivery=0`的客户分片不生成CMPP状态报告；同一HTTP提交仍只生成一个消息级最终Webhook，不因供应商内部计费分片数而重复回调。
+- 提交或未知状态满72小时仍无明确最终回执时，主记录转为`timeout`并写入`undelivered/EXPIRED/RECEIPT_TIMEOUT`。CMPP对每个请求状态报告的原始分片建立失败回执，HTTP建立一个明确失败Webhook；退款保持消息级一次。
+- 超时状态变更与下游回执建单之间必须可恢复：仅在HTTP事件及全部应建CMPP分片投递均成功持久化后写`timeoutReceiptQueuedAt`；中途失败保留空标记，由后续定时扫描按稳定幂等键补齐，禁止出现“已转超时但永久没有下游回执”。
@@ -1447,6 +1447,7 @@
  - `awaiting_ack` 记录在前端不可选且后端拒绝并发重投，不能仅依赖按钮禁用。
  - 确认弹窗明确展示投递类型、消息 ID 和重复处理风险；取消时不得请求后端，确认提交期间操作按钮禁用并显示处理中状态。
  - 单条成功弹窗展示真实返回的当前状态和 `manualRetryCount`；接口失败时弹窗展示错误，并提醒先刷新核对人工次数再决定是否重试，不能静默失败或诱导重复提交。
+  - 筛选区使用平台共享查询控件宽度；桌面端空间不足时条件按完整控件自然换行，不得把关键字、日期、状态、类型、应用和操作按钮挤压在同一行；移动端条件整行展示，查询与重置按钮清晰可操作。

 ### TC-GW-015 下游投递指数退避

@@ -1598,6 +1599,7 @@
  - 页面刷新后恢复状态仍然存在，可继续用于生产排查。
  - 页面解释恢复状态与逐条下游投递记录的用途差异；恢复状态和下游投递记录默认均选择近 7 天。
  - 恢复状态按更新时间区间筛选，摘要、失败分类、列表和 CSV 导出使用同一时间口径；列表标题与外框保持正常内边距，最后错误/跳过原因列具备可读宽度。
+  - 筛选区复用平台共享查询控件宽度；关键字、日期、状态、失败分类、应用和操作按钮在桌面端按可用空间自然换行，移动端条件整行展示，不出现控件压缩、重叠、截断或按钮混入字段的问题。

 ### TC-GW-025 多 Gateway 恢复抢占协调

@@ -3445,7 +3447,7 @@ npm run verify:phase8
 | TC-BILLING-010 | 余额不足发送失败，人工充值后重试发送并模拟 delivered。 | 充值前不扣费；充值后发送成功；冻结、扣费、短信计费记录完整；reconciliation diff 为 0。 |
 | TC-BILLING-011 | 分别准备 `余额+授信` 为正数、0 和负数的账户，使用相同短信费用发起发送。 | 和为正数时允许发送；和为 0 或负数时提示余额不足。判断公式为 `balanceCents + creditCents > 0`，与本次费用和套餐无关。 |
 | TC-BILLING-012 | 已扣费短信收到最终失败回执；另一个消息在提交前失败并释放冻结；另准备一笔任务冻结转扣费时的批次级释放。 | 最终失败只生成一条 `refunded` 并计入“今日返还”，重复回执不重复退款；提交前失败生成 `released + relatedType=sms_message_record` 并计入“今日返还”；冻结转扣费的 `released + relatedType=sms_batch_task` 属于内部转换，不计入“今日返还”；客户端和运营端当日金额一致且保留三位小数。 |
-| TC-BILLING-013 | 准备已提交扣费但 72 小时完全无回执的 `submitted` 短信，以及有 `UNKNOWN` 回执且超过 72 小时的短信；启动 API 定时扫描并模拟重复扫描。 | 两类短信都转为 timeout 并退款；任务进度刷新；同一短信只退款一次；定时扫描默认启用且每 5 分钟执行。 |
+| TC-BILLING-013 | 准备已提交扣费但 72 小时完全无回执的 `submitted` 短信，以及有 `UNKNOWN` 回执且超过 72 小时的短信；分别覆盖HTTP提交、CMPP短短信和多分片长短信，启动 API 定时扫描并模拟投递建单失败后重复扫描。 | 两类短信都转为 timeout、写入`undelivered/EXPIRED/RECEIPT_TIMEOUT`并只退款一次；HTTP产生一个明确失败Webhook，CMPP对每个请求回执的原始分片产生失败状态报告且使用各自SubmitResp Msg_Id；建单未完成时`timeoutReceiptQueuedAt`保持空并由后续扫描补齐，成功建单后不重复；任务进度刷新。 |
 | TC-BILLING-014 | 在运营端充值记录中分别打开整数金额、含1至4位有效小数、负数冲正以及缺少可追溯余额的真实订单回执。 | 每行提供“查看回执”；弹窗左上只使用系统真实Logo；企业、订单号、时间、备注与数据库订单一致；可追溯订单的入账前余额等于入账后余额减本次变动；无快照时前后余额不得伪造；主金额整数不显示小数，非整数仅显示有效小数，余额仍显示四位精度；正数显示已入账，负数显示已冲正。 |
 | TC-SEC-006 | 安装 API 生产依赖并执行 `npm audit`；使用缺文件、多文件、超大文件、超量字段和正常单文件调用认证后的 multipart 上传接口。 | NestJS/Multer/Hono 已升级或锁定到修复版本，生产依赖 audit 为 0；接口只接受一个不超过 20MB 的文件，并限制字段、part、字段名、字段值和 header pair 数量；异常请求返回受控 4xx，正常文件仍写入真实 MinIO 和 `FileObject`。 |

@@ -3706,7 +3708,7 @@ npm run verify:phase8
 | --- | --- | --- |
 | TC-USER-REUSE-001 | 新建用户名`zhaohui`，逻辑删除后再次使用同一用户名、邮箱或手机号新建用户。 | 新用户创建成功且主键与旧用户不同；旧用户及其OperationLog、审核关联保持原用户主键；登录只命中新用户。 |
 | TC-USER-REUSE-002 | 两个未删除用户并发提交相同用户名、邮箱或手机号。 | PostgreSQL仅允许一个请求成功，另一个返回HTTP 409、`USER_DUPLICATE`、冲突字段和中文提示，不产生两个活动账号。 |
-| TC-USER-FILTER-001 | 在运营端分别及组合填写用户姓名、登录账号、所属企业、用户角色和状态，点击查询，再点击重置。 | 每次操作请求真实`GET /api/admin/users`；条件分别生效，组合使用AND，登录账号匹配用户名/邮箱/手机号；重置返回全部未删除用户。 |
+| TC-USER-FILTER-001 | 在运营端分别及组合填写用户姓名、登录账号、所属企业、用户角色和状态，点击查询，再点击重置；分别使用桌面和移动视口检查筛选布局。 | 每次操作请求真实`GET /api/admin/users`；条件分别生效，组合使用AND，登录账号匹配用户名/邮箱/手机号；重置返回全部未删除用户。五组条件按共享宽度自然换行，不被压缩或截断；移动端条件整行展示，查询/重置与“新增用户”分区清晰且均可操作。 |
 | TC-USER-FILTER-002 | 在客户端分别及组合填写用户姓名、登录账号和状态。 | 请求真实`GET /api/client/users`；只返回当前企业管理员，无法通过查询参数跨租户或查询平台管理员。 |
 | TC-USER-CONTINUITY-UI-001 | 删除、禁用或降权最后一个平台管理员，再删除或停用某企业最后一个启用管理员。 | 平台管理员操作由后端权威拦截并在确认弹窗显示建议；企业管理员操作成功且可归零；按钮结束忙碌状态，浏览器无未处理Promise。 |
 | TC-USER-CONTINUITY-UI-002 | 为相同范围增加另一名启用管理员后重复删除或禁用。 | 操作成功、弹窗关闭、列表按当前已应用查询条件刷新，并写入对应OperationLog。 |
@@ -3851,9 +3853,9 @@ npm run verify:phase8
 - `TC-PROTOCOL-LOG-008`：一条真实短短信取得成功状态报告后，按同一平台消息号查询应恰好看到四个供应商侧真实业务报文：`平台→通道/CMPP_SUBMIT`、`通道→平台/CMPP_SUBMIT_RESP`、`通道→平台/CMPP_DELIVER`、`平台→通道/CMPP_DELIVER_RESP`；每个报文只出现一条，箭头与抓包传输方向一致，长短信则按实际分片分别记录Submit/SubmitResp。
 - `TC-PROTOCOL-LOG-009`：企业应用提交短信时，入站Submit显示“企业应用→平台”，每个实际返回的SubmitResp显示“平台→企业应用”；供应商侧统一显示“平台→供应商通道/供应商通道→平台”，不得再使用含义模糊的客户/通道箭头。
 - `TC-RECEIPT-SHARED-010`：供应商账号、Gateway主机、端口、协议和CMPP版本均相同的两个物理通道连接中，回执从副连接进入、原连接存在唯一`gatewayMessageId + DestTerminalId`分片候选时，应写入原提交逻辑通道；账号或端点任一不同、或候选超过一条时不得自动匹配。
- `TC-RECEIPT-LONG-011`：两分片长短信仅收到第一片`DELIVRD`时，`SmsMessageRecord`保持`submitted`且不创建企业应用最终回执；第二片到达后两条分片审计均为`delivered`，主记录只聚合一次为`delivered`，重复回执不得重复投递、扣费或退款。
+- `TC-RECEIPT-LONG-011`：两分片长短信仅收到第一片`DELIVRD`时，`SmsMessageRecord`保持`submitted`且不创建企业应用最终回执；第二片到达后两条分片审计均为`delivered`，主记录只聚合一次为`delivered`，CMPP按两个原始分片各创建一条`DELIVRD`且分别使用两个SubmitResp Msg_Id，HTTP只创建一个最终事件；重复回执不得重复投递、扣费或退款。
 - `TC-PROTOCOL-LOG-012`：供应商长短信每个真实分片分别产生一条`平台→供应商通道/CMPP_SUBMIT`和一条`供应商通道→平台/CMPP_SUBMIT_RESP`；内部`submit-result`聚合回调不得额外落协议日志。
- `TC-RECEIPT-LONG-013`：两分片长短信主记录保存首片上游消息号，第二片返回`YL:1014`等任意非成功状态且首片未回执；系统通过第二片审计识别当前提交尝试，整条短信进入失败/补发或退款终态并只投递一次最终失败回执，不再卡在`submitted`。
+- `TC-RECEIPT-LONG-013`：两分片长短信主记录保存首片上游消息号，第二片返回`YL:1014`等任意非成功状态且首片未回执；系统通过第二片审计识别当前提交尝试，整条短信进入失败/补发或退款终态，不再卡在`submitted`；最终不再补发时，对两个请求回执的原始客户分片分别投递失败状态报告，Msg_Id与各自SubmitResp一致。
 - `TC-DELIVERY-AUTO-014`：分别配置仅CMPP、仅HTTP、CMPP+HTTP、两者均关闭四种应用状态；回执与上行分别只产生CMPP下游记录、HTTP Webhook事件、两者各一条、均不产生。修改历史手工投递模式不得改变自动计算结果。
 - `TC-HTTP-WEBHOOK-015`：运营端关闭HTTP接口后，回执和上行Webhook地址输入框仍显示且可保存；任一地址保存为空时删除对应有效端点，后续不推送该类HTTP事件，另一非空地址不受影响。
 - `TC-PROTOCOL-LOG-016`：在线企业应用收到回执或上行 `CMPP_DELIVER` 并返回 `CMPP_DELIVER_RESP`；通讯日志各出现一条“平台→企业应用/DELIVER”和“企业应用→平台/DELIVER_RESP”，结果、消息号、序列号和投递记录一致，下游投递记录仍独立展示发送、ACK和重试状态。
@@ -3934,10 +3936,10 @@ npm run verify:phase8
 |---|---|---|
 | TC-RETRY-RACE-001 | 三分片长短信的三个失败回执并发进入API，备用通道可用 | 三个回执和通讯报文全部保存；来源提交记录只关联一个补发记录，只发布一个Gateway命令、三个补发分片 |
 | TC-RETRY-RACE-002 | 三个线程在唯一补发记录提交前后交错执行 | 只有一个线程取得`retryOfSubmitRecordId`唯一关系；其他线程返回同一下一跳`submitId`并写复用日志，不退款、不生成最终回执 |
-| TC-RETRY-RACE-003 | 三个失败回执并发处理且没有可用备用通道 | 主记录最终失败；只产生一笔退款交易和一次余额增量，只生成一个CMPP最终失败回执及一个HTTP回调事件 |
+| TC-RETRY-RACE-003 | 三个失败回执并发处理且没有可用备用通道 | 主记录最终失败；只产生一笔退款交易和一次余额增量；HTTP只生成一个最终失败事件，CMPP对三个原始客户分片各生成一条失败回执且每片只生成一次 |
 | TC-BILLING-IDEM-004 | 三个线程使用同一短信退款幂等键并发退款 | 三次调用返回同一交易ID，`AccountTransaction`只有一条，账户余额只增加一次 |
 | TC-BILLING-ATOMIC-005 | 同一企业同时发生扣费、退款和充值 | 账户级事务锁串行化余额变更，使用数据库原子增量；每条流水`balanceAfter`连续且最终余额与流水一致 |
-| TC-DOWNSTREAM-IDEM-006 | 同一短信终态被重复处理，企业同时启用CMPP和HTTP | CMPP只有一条`CmppDownstreamDelivery`且只发送一次；HTTP只有一个稳定事件和一条端点投递 |
+| TC-DOWNSTREAM-IDEM-006 | 同一长短信终态被重复处理，企业同时启用CMPP和HTTP | CMPP每个请求回执的原始客户分片各有一条稳定`CmppDownstreamDelivery`且各只发送一次；HTTP只有一个稳定事件和一条端点投递 |
 | TC-MIGRATION-IDEM-007 | 在含历史重复最终回执的预生产数据上执行migration | 历史行全部保留；每个短信只给最早一条历史回执设置唯一键，其余保持空键；新数据开始强制唯一 |

 ## 2026-07-27 通道报备发送统计用例
@@ -4251,9 +4253,9 @@ npm run verify:phase8
 | TC-REFACTOR-R10-005 | 分片未收齐、全部成功、明确失败或全部未知 | 未收齐不提前成功；全部成功才最终成功；明确失败优先；未知按既有超时和失败口径处理 |
 | TC-REFACTOR-R10-006 | 两个执行者并发抢占同一失败短信补发 | 来源提交唯一关系、事务条件更新和P2002唯一冲突处理保证最多创建一个新提交尝试 |
 | TC-REFACTOR-R10-007 | 重复执行成功扣费、失败退款或预占释放 | 账务使用原稳定幂等键，同一业务事件只产生一次账户流水，余额和预占不重复变化 |
-| TC-REFACTOR-R10-008 | 创建、认领、发送并ACK最终CMPP/HTTP回执 | 每短信只有一条最终回执语义；下游去重、attempt记录、ACK确认、超时恢复和失败分类保持 |
+| TC-REFACTOR-R10-008 | 创建、认领、发送并ACK最终CMPP/HTTP回执 | 内部每短信只有一个最终业务结论；CMPP按原始客户分片投递并逐片去重，HTTP按消息投递并去重；attempt记录、ACK确认、超时恢复和失败分类保持 |
 | TC-REFACTOR-R10-009 | 人工重排失败下游投递或恢复陈旧认领 | 使用稳定重排键和原状态条件，已完成或正由其他执行者处理的记录不得重复投递 |
-| TC-REFACTOR-R10-010 | 执行回执超时扫描 | 仅处理满足既有时间和状态条件的当前记录；扫描并发保护和终态聚合保持 |
+| TC-REFACTOR-R10-010 | 执行回执超时扫描 | 仅处理满足既有时间和状态条件的当前记录；转为明确`EXPIRED`失败并为CMPP逐分片、HTTP逐消息建立可重试下游回执，建单标记未完成时后续扫描可恢复；扫描并发保护和内部终态聚合保持 |
 | TC-REFACTOR-R10-011 | 检查七个完成链领域的持久化操作 | 不存在删除历史事故记录的`deleteMany`路径；提交、回执、attempt、死信和账务历史继续保留 |
 | TC-REFACTOR-R10-012 | 对真实本地PostgreSQL查询R10八类表 | 查询前后计数完全一致；无分片或attempt样本时如实记为0，不造数、不发短信、不触发补发或重投 |
 | TC-REFACTOR-R10-013 | 执行SendChain定向、API全量、前后端构建、Gateway及R0～R10门禁 | 112项定向和389项API测试通过；schema、migration、事务语义、Redis契约、CMPP协议及其他业务不因R10改变 |
@@ -4348,3 +4350,40 @@ npm run verify:phase8
 | TC-REFACTOR-R11-084 | 打开签名、发送、企业认证、发送详情和模板代表页面 | 各单页面样式仍由原global规则托管，页面结构、真实接口和交互不因第九步改变 |
 | TC-REFACTOR-R11-085 | 在375×812视口检查首页、账单及一个单页面代表 | 标题、卡片、表格和操作区无新增横向溢出，控制台无相关warning/error |
 | TC-REFACTOR-R11-086 | 执行前端生产构建、API/Gateway全量、Prisma、安全门禁、全部R0～R11结构门禁和`git diff --check` | 29个API套件/389项测试、API构建、Gateway测试/vet及全部门禁通过；R11九步完成且业务行为不因client共享CSS迁移改变 |
+
+## 2026-08-03 工作台金额与审核筛选回归用例
+
+| 用例编号 | 操作 | 预期结果 |
+| --- | --- | --- |
+| TC-CLIENT-DASHBOARD-012 | 使用客户端企业登录短信服务工作台，对比 Dashboard API、数据库当天消费聚合和页面金额卡 | “今日消费金额”位于“今日返还金额”之前，展示当前企业北京时间当天真实消费金额；刷新后与 API/数据库一致，不使用静态值或浏览器缓存计算 |
+| TC-AUDIT-FILTER-014 | 依次打开企业认证、短信、模板、签名、引流信息五个审核页面，选择同一提交日期区间并查询 | 五页均显示日期区间控件；请求携带开始/结束日期，列表只返回 PostgreSQL 中提交时间位于北京时间闭区间内的记录 |
+| TC-AUDIT-FILTER-015 | 在签名和引流信息审核页切换到“导入批次审核”，按提交时间查询并翻页 | 导入批次真实分页 API 同时携带日期条件，当前页和总数均受日期范围约束，不在前端仅过滤当前页 |
+| TC-AUDIT-FILTER-016 | 分别只选择开始日、只选择结束日、选择跨日范围，再输入非法日期或开始日晚于结束日直接调用 API | 单边范围可正确查询；完整范围包含开始日 00:00:00 和结束日 23:59:59.999；非法或倒置范围返回受控 400，不执行无界误查询 |
+| TC-QUERY-LAYOUT-009 | 在风控规则页检查规则范围、平台白名单和号码频次触发记录查询区，并执行查询与重置 | 普通控件使用统一标准宽度，条件可换行但不占满整行；查询/重置按钮等宽；重置后白名单恢复全部有效记录，触发记录恢复“拦截中”并重新请求真实后端 |
+| TC-QUERY-LAYOUT-010 | 在五个审核页面及导入审核页签检查普通控件、日期区间和查询/重置按钮，并切换桌面与375×812视口 | 普通控件宽度一致，日期区间明显更宽，查询/重置按钮宽度一致；窄屏转为整行且无横向溢出、遮挡或弹层裁切 |
+
+## 2026-08-03 引流信息识别与统计用例
+
+| 用例编号 | 操作 | 预期结果 |
+| --- | --- | --- |
+| TC-DRAINAGE-DETECT-001 | 在引流识别规则页新增、编辑、停用规则并刷新 | 所有操作调用真实后端并持久化到 PostgreSQL；版本递增、状态生效并留下操作日志，刷新后不丢失 |
+| TC-DRAINAGE-DETECT-002 | 分别测试协议 URL、裸域名、短链接、IP:端口/路径及中文标点相邻链接 | 均识别为含引流，命中类型为 URL，保存原始内容位置；检测不会改写短信原文 |
+| TC-DRAINAGE-DETECT-003 | 输入被空格、中文句号拆开的域名以及普通邮箱地址 | 规避域名仍命中；完整或带空格规避的邮箱不被当作引流 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`，不因引流资料状态拒绝或转人工；其他发送校验仍正常执行，禁止用真实短信完成自动测试 |
+| TC-DRAINAGE-RECORD-001 | 查询含引流、不含引流和未检测三类短信记录并导出 CSV | PostgreSQL 分页和总数按筛选值返回；含引流原文使用提示色和片段高亮；CSV“是否含引流”与数据库一致 |
+| TC-DRAINAGE-STATS-001 | 打开签名发送质量明细并切换“整体统计/按引流切分” | 整体矩阵显示全部通道×运营商真实提交；切分矩阵分别显示含引流、不含引流、未检测，分组计数之和等于整体计数 |
+| TC-DRAINAGE-DASHBOARD-001 | 对比运营看板两个签名统计表与数据库当天数据 | “今日签名发送统计”包含全部短信；“含引流”表只包含`hasDrainageContent=true`，历史 null 不计入含引流 |
+| TC-DRAINAGE-SAFETY-001 | 保存超长、非法标志、后行断言、反向引用或嵌套量词规则 | API 返回受控参数错误，不保存可能在发送入口造成灾难性回溯的规则 |
+
+## 2026-08-03 CMPP逐分片回执与超时失败回执用例
+
+| 用例编号 | 操作 | 预期结果 |
+| --- | --- | --- |
+| TC-RECEIPT-FRAGMENT-001 | 客户提交三分片长短信，每片`Registered_Delivery=1`，供应商三片分别返回成功、成功、失败 | 内部主记录只形成一个最终业务结论；下游产生3条CMPP状态报告，各自Msg_Id等于对应SubmitResp Msg_Id，状态/原始码/时间来自对应上游分片；HTTP只产生1个消息级最终事件 |
+| TC-RECEIPT-FRAGMENT-002 | 三分片中第二片`Registered_Delivery=0`，其余两片为1 | 数据库保留三片的真实请求值；下游只为第一、三片建立CMPP状态报告，第二片不生成；不影响内部整条短信状态和HTTP最终事件 |
+| TC-RECEIPT-FRAGMENT-003 | 对同一长短信终态并发处理三次并重放重复上游回执 | 每个原始客户分片最多一条`CmppDownstreamDelivery`，唯一键分别含分片序号；已建立分片不重复发，HTTP稳定事件不重复，退款和补发仍只有一次 |
+| TC-RECEIPT-FRAGMENT-004 | 客户在线时分别向同一长短信的两个分片推送回执 | Gateway发送的两个`CMPP_DELIVER`回执内容分别携带两个不同的原SubmitResp Msg_Id，不因在线会话按业务消息查找而都复用第一片Msg_Id |
+| TC-RECEIPT-TIMEOUT-005 | HTTP消息超过72小时无明确回执，首次Webhook建单失败，下一轮扫描恢复 | 主记录只转一次`timeout`并只退款一次；失败时`timeoutReceiptQueuedAt`为空，后续扫描补建`undelivered/EXPIRED/RECEIPT_TIMEOUT`事件后写入标记，HTTP最终事件只有一个 |
+| TC-RECEIPT-TIMEOUT-006 | CMPP长短信超过72小时无明确回执，其中部分片已有真实回执，其余片缺失 | 已有结果的分片保留自己的最终状态；缺失片收到明确`EXPIRED`失败回执；每片使用各自原SubmitResp Msg_Id并可分别ACK，重复扫描不重复发送 |
@@ -3110,3 +3110,52 @@ git diff --check
 - Redis返回`PONG`；`gateway.submit.commands`消费者组为`cmpp-gateway`，消费者1、pending=0、lag=0、entries-read=3047。部署后约95秒内API/Gateway error级journal均为0，关键字检查无`panic/fatal/unhandled/exception/error`；120秒内活跃下游客户连接为0。
 - 4条active供应商通道中3条稳定connected 1/1：`会员营销-铁布衫`、`赛邮行业-王斯评中转`、`赛邮行业-王斯评中转副本`。`会员营销-富泷`在部署前为connected 1/1，Gateway重启后持续约95秒为failed 0/1，数据库原因为`authentication / connect response status: auth failed`；保留系统自动重连，没有修改其账号、密码或启停状态。
 - 依赖缓解安全门禁通过。npm audit仍报告既有前端2项high（未使用的React Router RSC路径）和API 3项moderate（Prisma工具链）告警，未执行可能引入破坏性升级的`audit fix --force`。本次没有发送、重投或补发真实短信，没有修改企业余额、客户连接或真实通道配置。
+
+## 2026-08-03 客户端今日消费金额、审核提交时间与查询控件统一（本地未提交）
+
+- 客户端短信服务工作台在“今日返还金额”前增加“今日消费金额”，直接展示当前企业真实 Dashboard API 的`today.spendCents`；该字段由后端按当前租户及北京时间当天`SmsMessageRecord`汇总，不新增浏览器估算、静态数据或本地缓存。四张金额/发送指标卡在桌面端四列、1180px以下两列、780px以下单列展示。
+- 新增全局查询尺寸令牌：普通条件220px、日期区间320px、查询/重置按钮88px；新增共享`.ui-filter-row/.ui-filter-actions`布局并保留R11既有页面类兼容。风控规则页的规则范围、平台白名单和号码频次触发记录不再整行拉伸，白名单与触发记录增加等宽重置按钮并按明确默认值重新请求真实接口。
+- 企业认证、短信、模板、签名、引流信息五个审核页面均增加“提交时间”日期区间；签名和引流的导入批次审核Tab也使用已有真实分页日期参数。前端分别传递`submittedAtFrom/submittedAtTo`或导入批次`startAt/endAt`，不是仅过滤当前页面数组。
+- 后端新增共享北京时间日期边界解析，校验`YYYY-MM-DD`、真实日历日期和范围顺序，并生成包含开始日00:00:00及结束日23:59:59.999的闭区间。数据库查询分别落到企业认证`submittedAt`、短信审核任务`createdAt`、模板`createdAt`、签名当前提交口径`updatedAt`和引流信息`submittedAt`；没有新增schema或migration。
+- 新增/补充日期筛选单元测试。定向结果为日期边界与企业认证2 suites / 6 tests、风控审核1 suite / 16 tests、短信配置1 suite / 63 tests全部通过；本地Redis和PostgreSQL端口均监听时，API全量30 suites / 394 tests全部通过，保留既有`--forceExit`提示及测试场景内预期的错误/告警日志。
+- API TypeScript正式构建、前端TypeScript与Vite v8.1.5生产构建通过（2532 modules，CSS 239.86kB/gzip 35.11kB，JS 2007.30kB/gzip 597.78kB），仅保留既有大chunk提示。R11 foundation/shared components/admin/client四项样式门禁和`git diff --check`通过；契约同步锁定3个查询尺寸令牌、共享筛选布局和DateRangeInput绑定。
+- 应用内浏览器访问本地客户端工作台和运营端风控路由时，均被真实鉴权守卫正确重定向到对应图形验证码登录页；页面身份正确、无框架错误覆盖，控制台0条warning/error。没有可复用登录态，未解验证码或伪造会话，因此登录后金额卡、审核筛选和风控布局的真实交互视觉验收保留为人工登录复核项。
+- 已同步首版需求、系统功能测试用例和本进度文档。本轮按用户要求保持全部业务代码未提交、未推送、未部署；既有`api/tsconfig.build.tsbuildinfo`、根目录`tsconfig.tsbuildinfo`、`outputs/`和空文件`=`继续保留且不纳入本轮归因，未发送短信、修改余额、通道配置或客户连接。
+
+## 2026-08-03 引流信息识别与统计（本地开发中，未提交）
+
+- 本期范围确定为只识别、记录、查询和统计是否含引流信息；不根据报备/审核状态做发送、拒绝或人工审核。客户端批量发送和 CMPP 入站中的`DRAINAGE_NOT_APPROVED`分支已移除，既有引流资料匹配只保留关联信息，不参与发送决策。
+- 新增`DrainageDetectionRule`真实数据库模型、消息记录识别快照字段及 migration；检测器按规则类型对副本规范化，覆盖裸域名/短链/IP、中文标点和空格拆分 URL、`+86`/空格/短横线手机号、括号区号/分机固话，并排除邮箱。批量发送、CMPP 入站和通道测试记录写入同一识别快照。
+- 运营端新增“系统管理 → 引流识别规则”页面及真实 CRUD、启停、测试接口；短信记录新增含引流/不含引流/未检测筛选、命中片段提示色高亮和 CSV 列。
+- 发送质量明细的通道×运营商矩阵保留整体聚合，并新增含引流、不含引流、未检测切分结果；运营看板第一张签名表改为全部短信，第二张只取识别为含引流的短信。
+- 当前验证：Prisma Client 已基于新 schema 生成且 schema validate 通过；API TypeScript 构建、前端 TypeScript检查和 Vite v8.1.5 生产构建通过（2533 modules，CSS 241.13kB/gzip 35.30kB，JS 2016.72kB/gzip 600.04kB），仅保留既有大 chunk 提示。识别器及发送链路/通道/运营统计定向回归 4 suites / 180 tests 通过，API 全量 31 suites / 403 tests 通过；Jest 仍保留既有开放句柄`--forceExit`提示。未在本地或预生产执行 migration，未执行 Gateway 回归或登录后浏览器验收。
+- 全部修改仅保留本地，未提交、未推送、未部署；未发送、补发、重投真实短信，未修改真实通道账号、密码、启停状态、企业余额或客户连接。工作区中原有认证、风控、审核样式、日期筛选、构建缓存和临时文件继续保留，不归因于本需求。
+- 本地页面联调时发现3000端口仍由2026-08-02启动的旧API进程占用，当前源码进程因`EADDRINUSE`未实际接管，导致登录后访问新接口返回`Cannot GET /api/admin/dictionaries/drainage-detection-rules`。已仅重启本工作区本地API，确认新路由完成挂载、API health与4173前端预览均为HTTP 200。
+- 初始migration中的默认正则使用了JavaScript字符串式双反斜杠，而PostgreSQL标准字符串会原样保存，导致数据库内3条默认规则无法命中。初始种子已改用美元引用的单反斜杠表达式，并新增`20260803140000_fix_default_drainage_detection_rule_patterns`向前修复migration；本地库已应用至80条migration。真实本地数据库现有URL/裸域名、手机号、固话3条active默认规则；组合样例正确命中中文句号裸域名、`+86`短横线手机号和括号区号带分机固话，同时排除邮箱。
+
+## 2026-08-03 下游投递与恢复状态筛选布局优化（本地未提交）
+
+- 设计规范核对确认R11已有共享`.ui-filter-row/.ui-filter-actions`：普通查询控件使用`--query-control-width: 220px`，日期范围使用`--query-date-range-width: 320px`，查询/重置按钮使用`--query-action-width: 88px`；容器允许按完整控件换行，780px以下条件整行、按钮两列。下游投递记录和恢复状态管理仍使用旧`admin-task-filter`自适应网格，5组条件及按钮会为维持单行而被压缩。
+- 两页筛选区已改为直接复用共享R11布局和操作区，不新增页面私有宽度、不改变筛选状态、查询接口、日期口径、导出或重投行为。已同步首版需求和`TC-GW-014/TC-GW-024`的桌面换行、移动端整行及无压缩/重叠验收要求。
+- 同轮纳入运营端用户管理：原页面在外层工具栏内再用`repeat(auto-fit, minmax(160px, 1fr))`压缩五组查询条件，现改为与查询/重置共同使用共享筛选流式布局；“新增用户”继续作为独立业务操作。查询参数、真实`GET /api/admin/users`组合查询及新增用户行为均未改变，并同步`TC-USER-FILTER-001`布局验收。
+- Node.js v24.16.0下前端TypeScript检查和Vite v8.1.5生产构建通过（2533 modules，CSS 241.00kB/gzip 35.28kB，JS 2016.78kB/gzip 600.05kB），仅保留既有大chunk提示；R11 foundation/shared components两项样式门禁及`git diff --check`通过。系统PATH旧Node首次执行Vite时因不支持`??=`产生未处理Promise警告但错误返回0，已明确判定无效并用Node.js v24重新完成全部门禁。
+- 本地深链访问下游投递页被真实鉴权守卫正确重定向至运营端登录页，页面身份正常、无框架覆盖、控制台0条warning/error；没有可复用登录态且未解图形验证码或伪造会话，因此三页登录后桌面/移动实际截图与查询交互仍需人工登录复核。修改仅保留本地，未提交、未推送、未部署，也未触发任何下游重投或真实短信操作。
+
+## 2026-08-03 CMPP逐分片回执与72小时超时失败回执（本地未提交）
+
+- 协议和历史代码复核纠正了“临时状态”和“长短信聚合回执”两项不严谨结论：CMPP只有状态值，没有规定临时状态生命周期，也没有长短信聚合回执报文。历史版本曾按上游分片产生多条下游投递，但全部复用第一片客户Msg_Id；后续为修复并发重复补发/退款改成每条业务短信一条回执，两种实现都不满足逐个原始客户分片精确关联。
+- Gateway入站契约现传递每包真实`Registered_Delivery`；短短信写入`SmsMessageRecord.cmppRegisteredDelivery`，长短信逐片写入`CmppInboundLongMessageSegment.registeredDelivery/sequenceId`。migration`20260803190000_downstream_fragment_receipts`同时增加`timeoutReceiptQueuedAt`，历史已有CMPP记录按原行为回填为请求回执；本地PostgreSQL已成功应用至81条migration。
+- 内部长短信仍只形成一个业务终态、一次重投决定、一次退款和一个HTTP最终事件。CMPP下游改用`receipt:{messageRecordId}:segment:{segmentIndex}`逐片幂等；Gateway根据每片原始`SubmitGroupMessageId + Sequence_Id`重建对应SubmitResp Msg_Id，在线会话不再导致所有分片回执复用第一片Msg_Id。`Registered_Delivery=0`分片不建CMPP回执。
+- 下游逐片payload优先使用对应`SmsMessageSegmentAudit`的真实状态、原始码、错误码和到达时间；已成功分片不会因另一片失败被改写。业务已明确最终失败而个别片尚无状态时，缺失片使用整条短信的明确失败结果，保证每个请求回执的原始分片都有最终答复。
+- 72小时扫描将`submitted/unknown`明确改为`timeout + undelivered + EXPIRED + RECEIPT_TIMEOUT`，HTTP建立一个失败Webhook，CMPP为每个请求回执的原始分片建立失败状态报告。只有全部应建投递持久化后才写`timeoutReceiptQueuedAt`；建单中断时下一轮扫描继续补齐，退款仍由原消息级幂等键保证一次。
+- 验证结果：Prisma format、validate、generate和API TypeScript正式构建通过；新增逐片目标/Registered_Delivery/HTTP超时及中断恢复测试后，定向3 suites / 117 tests、API全量32 suites / 407 tests通过，保留既有Jest开放句柄`--forceExit`提示及预期场景日志。Gateway`go test ./... -count=1`与`go vet ./...`通过，并新增不同原Sequence_Id生成不同回执Msg_Id的专项测试。
+- 本轮没有修改或清理工作区中既有的引流识别、审核筛选、查询布局和其他会话修改；构建缓存、`outputs/`和空文件`=`继续保留。代码按用户要求未提交、未推送、未部署；没有发送、补发或重投短信，没有修改预生产数据库、企业余额、通道配置或客户连接。
+
+## 2026-08-03 跨会话工作区整合与提交前完整回归
+
+- 汇总当前工作区全部有效修改后，组合范围确认为四组：客户端今日消费与运营统计、审核日期和共享查询布局、引流信息识别与统计、CMPP逐分片回执及72小时超时失败回执。3条新增migration按`20260803113000`、`20260803140000`、`20260803190000`顺序衔接；本地真实PostgreSQL共81条migration且schema up to date。
+- 完整回归发现拆分阶段的结构契约未同步业务演进：R1新增5个引流识别规则API且7个查询实现更新，R5通道测试加入引流识别，R2短信导出/质量统计查询变化，R8/R9/R10的引流识别、Registered_Delivery、逐片回执及超时回执实现变化，R3审核提交时间查询变化。已按实际组合实现更新对应契约哈希；R0将已失效的“单条聚合最终回执”特征替换为“同一分片幂等一次”和“HTTP单事件+CMPP逐请求分片”两项真实特征，没有恢复错误的聚合回执行为。
+- Node.js v24.16.0下Prisma format、validate、generate、migrate status通过；API全量32 suites / 407 tests全部通过，API TypeScript正式构建通过；前端TypeScript与Vite v8.1.5生产构建通过（2533 modules），仅保留既有约2.02MB单chunk和插件耗时提示。
+- Gateway`go test ./... -count=1`和`go vet ./...`通过；19个R0-R11结构门禁全部通过；依赖缓解安全门禁通过；`git diff --check`和合并冲突标记扫描通过。Jest仍保留既有`--forceExit`开放句柄提示及测试场景内预期日志。
+- 依赖审计仍有已知告警：前端2项high来自项目未启用的React Router RSC路径，专用门禁已验证RSC未使用；API 3项moderate来自Prisma开发工具链的Valibot间接依赖。未执行可能改变依赖或引入破坏性升级的自动修复。
+- `api/tsconfig.build.tsbuildinfo`、根目录`tsconfig.tsbuildinfo`、`outputs/`和空文件`=`继续作为构建缓存或临时产物排除，不提交、不删除、不错误归因。本轮未部署、未发送/补发/重投短信，也未修改预生产数据库、企业余额、通道配置或客户连接。