feat: strengthen risk controls and review workflows
This commit is contained in:
hectorzhao
@@ -1677,6 +1677,13 @@
|
||||
1. 运营端“系统日志”必须将人员操作审计与协议通讯日志分成两个独立页签。通讯日志至少支持协议、交互方向、事件类型、结果、关键字和时间范围过滤，并展示平台消息号、上游消息号或HTTP请求号、脱敏对象、结果码、耗时和安全详情。
|
||||
2. CMPP应覆盖客户登录/Submit、供应商SubmitResp、状态报告Deliver、上行Deliver及平台下游投递；HTTP应覆盖客户发送请求和平台回执/上行Webhook。数据库中一条记录必须对应一个真实业务报文，不得把同一报文的“入口收到”和“处理成功”拆成两条记录；处理结果、结果码和耗时写在该报文同一条记录中，失败、重试等后续真实交互另行记录。
|
||||
3. Gateway收到状态报告或上行后，必须对解包/解码失败及转发NestJS失败输出结构化安全日志；NestJS入口把业务处理结果合并回同一报文记录，以便区分“上游未发”“Gateway未收到”“Gateway转发失败”和“API落库失败”。一条正常短短信的供应商侧完整成功闭环应依次展示四个真实报文：平台→通道 `CMPP_SUBMIT`、通道→平台 `CMPP_SUBMIT_RESP`、通道→平台 `CMPP_DELIVER`、平台→通道 `CMPP_DELIVER_RESP`；箭头只表达报文实际传输方向。
|
||||
4. 通讯日志不得保存短信正文、密码、密钥、Token、签名鉴权值或完整HTTP请求体；手机号只保存脱敏值。CMPP心跳不得逐包写入数据库，连接健康仍使用连接状态和聚合指标。
|
||||
5. 通讯日志写入不能阻塞短信主链路，默认批量异步写入，缓冲区应有上限和溢出告警；热数据默认保留30天，保留期允许通过环境变量配置。
|
||||
6. 通讯日志方向固定使用“企业应用 → 平台、平台 → 供应商通道、供应商通道 → 平台、平台 → 企业应用”。供应商长短信每个真实 `SUBMIT` 和 `SUBMIT_RESP` 分片各记一条，企业应用每个真实 `SUBMIT_RESP` 也必须记录；内部 `submit-result` 聚合回调不是协议报文，不得重复生成通讯日志。
|
||||
7. 供应商长短信回执必须先写入对应 `SmsMessageSegmentAudit`。仅当同一提交尝试的全部分片均为 `delivered` 时，主记录才转 `delivered` 并向企业应用投递一次最终回执；任一分片明确失败可进入最终失败/补发状态，分片尚未齐全时主记录保持 `submitted`，不得由首片成功提前聚合。
|
||||
8. 长短信任一分片返回非成功终态时，系统必须通过该分片审计关联的提交记录识别当前发送尝试，不得仅以主记录保存的首片上游消息号判断；确认属于当前尝试后，整条短信立即进入失败/补发或退款终态，无需等待其余分片回执。
|
||||
9. 回执和上行投递方式不得由运营人员选择。企业应用开通CMPP接口即按CMPP投递，开通HTTP接口且对应Webhook地址非空即按HTTP投递，两者同时满足时双投；任一地址为空时只跳过该类HTTP事件。运营端企业应用HTTP参数页必须始终可编辑回执和上行Webhook地址，不因HTTP接口开关关闭而隐藏。
|
||||
10. Gateway向企业应用发送真实 `CMPP_DELIVER` 以及收到企业应用真实 `CMPP_DELIVER_RESP` 时，都必须各写一条通讯交互日志，分别使用“平台→企业应用”和“企业应用→平台”方向；下游投递记录继续承担排队、重试和ACK业务状态，不得以通讯日志替代。
|
||||
|
||||
## 2026-07-26 依赖安全治理补充
|
||||
|
||||
@@ -1685,10 +1692,32 @@
|
||||
- PostCSS 必须固定到 `8.5.18` 或更高修复版本。平台不得接受用户 CSS 后交由构建链处理；如未来新增此能力，必须显式禁用不可信 previous source map 自动加载并重新开展威胁建模。
|
||||
- ExcelJS 的旧版 `minimatch` 调用接口与安全修复版 `brace-expansion` 5.x 不兼容时，允许使用受测试的本地 CommonJS 兼容适配层；适配层只能转发到官方有长度上限的实现，必须同时验证旧版 minimatch 花括号匹配、Excel 读写和干净 `npm ci`。
|
||||
- Prisma CLI 只用于生成、迁移和构建，不属于 API 请求运行路径。其无上游修复版本的中危工具链公告需记录接受条件并持续跟踪，不得为审计数字清零而把 Prisma 7 数据访问栈盲目降级到 6.x。
|
||||
4. 通讯日志不得保存短信正文、密码、密钥、Token、签名鉴权值或完整HTTP请求体；手机号只保存脱敏值。CMPP心跳不得逐包写入数据库，连接健康仍使用连接状态和聚合指标。
|
||||
5. 通讯日志写入不能阻塞短信主链路，默认批量异步写入，缓冲区应有上限和溢出告警；热数据默认保留30天，保留期允许通过环境变量配置。
|
||||
6. 通讯日志方向固定使用“企业应用 → 平台、平台 → 供应商通道、供应商通道 → 平台、平台 → 企业应用”。供应商长短信每个真实 `SUBMIT` 和 `SUBMIT_RESP` 分片各记一条，企业应用每个真实 `SUBMIT_RESP` 也必须记录；内部 `submit-result` 聚合回调不是协议报文，不得重复生成通讯日志。
|
||||
7. 供应商长短信回执必须先写入对应 `SmsMessageSegmentAudit`。仅当同一提交尝试的全部分片均为 `delivered` 时，主记录才转 `delivered` 并向企业应用投递一次最终回执；任一分片明确失败可进入最终失败/补发状态，分片尚未齐全时主记录保持 `submitted`，不得由首片成功提前聚合。
|
||||
8. 长短信任一分片返回非成功终态时，系统必须通过该分片审计关联的提交记录识别当前发送尝试，不得仅以主记录保存的首片上游消息号判断；确认属于当前尝试后，整条短信立即进入失败/补发或退款终态，无需等待其余分片回执。
|
||||
9. 回执和上行投递方式不得由运营人员选择。企业应用开通CMPP接口即按CMPP投递，开通HTTP接口且对应Webhook地址非空即按HTTP投递，两者同时满足时双投；任一地址为空时只跳过该类HTTP事件。运营端企业应用HTTP参数页必须始终可编辑回执和上行Webhook地址，不因HTTP接口开关关闭而隐藏。
|
||||
10. Gateway向企业应用发送真实 `CMPP_DELIVER` 以及收到企业应用真实 `CMPP_DELIVER_RESP` 时，都必须各写一条通讯交互日志，分别使用“平台→企业应用”和“企业应用→平台”方向；下游投递记录继续承担排队、重试和ACK业务状态，不得以通讯日志替代。
|
||||
|
||||
## 2026-07-26 用户登录标识复用、组合查询与管理员保护提示
|
||||
|
||||
1. 用户逻辑删除后，原用户记录、用户主键及历史审计关联必须继续保留；用户名、邮箱和手机号仅在未删除用户范围内唯一。新建用户可以复用逻辑删除记录曾使用的登录标识，但必须生成新的用户主键，不得继承旧用户的角色、企业归属、密码、会话或权限。
|
||||
2. 用户登录和按用户名查找必须显式排除逻辑删除记录。活动用户之间的登录标识并发冲突继续由PostgreSQL唯一索引保证，并返回HTTP 409、冲突字段及明确中文提示。
|
||||
3. 运营端用户管理将用户姓名、登录账号、所属企业、用户角色和状态拆分为独立条件；客户端将用户姓名、登录账号和状态拆分。点击查询或重置时调用真实后端组合查询，条件之间使用AND，登录账号内部对用户名、邮箱和手机号使用OR；不得加载全量数据后仅在浏览器过滤。
|
||||
4. 删除、禁用或降权最后一个平台管理员/企业管理员时，后端实时拦截继续作为权威判断。前端必须在当前确认弹窗内以`role=alert`显示失败原因和处理建议，保持弹窗打开，禁止只向浏览器控制台输出未处理Promise；请求期间确认按钮必须禁用。
|
||||
## 2026-07-26 企业应用停用与回执清算补充要求
|
||||
|
||||
- 删除企业前必须检查其企业应用；只要存在`active`或`disabling`应用就阻止删除，并提示先完成应用停用。
|
||||
- 点击停用应用时，系统必须统计尚未收到供应商回执的短信、待发送回执、等待`CMPP_DELIVER_RESP`的回执、仍可重试的失败投递及待投递上行。
|
||||
- 无待清算数据时，应用直接转为`disabled`并断开该账号的全部下游CMPP连接；存在待清算数据时，运营可选择“等待回执后停用”或“强制停用并断开连接”。
|
||||
- “等待回执后停用”将应用转为`disabling`：立即拒绝新短信Submit，但保留或允许下游账号重新连接以接收历史回执；待清算数据归零后自动停用。
|
||||
- `disabling`状态必须展示进入原因、各类待清算数量、当前连接数及自动停用时间；运营点击启用可清除停用计时并恢复为`active`。
|
||||
- “停用中”最长保留72小时，从`disablingAt`起算。到期仍未清算时自动转为`disabled`，剩余下游投递标记`abandoned`并停止重试，然后断开全部下游连接。
|
||||
- 应用停用后才到达的供应商回执仍更新短信主记录并保存原始证据，但下游投递记录直接标记`abandoned`，不得继续推送或形成重试告警。
|
||||
- Gateway读取已形成的待投递回执不能依赖企业或应用当前是否启用，避免“已生成回执但账户停用导致永远无法读取”的投递死锁。
|
||||
|
||||
## 2026-07-26 风控规则、逐号码拦截与短信人工审核补充要求
|
||||
|
||||
1. 风控规则只保留全局默认和企业应用级覆盖两层；应用级同编码规则优先于全局规则。企业级覆盖不再存在，企业应用表单和数据模型中的`maxPhonesPerTask`删除，单任务号码上限完全由`MAX_PHONES_PER_TASK`规则控制。本条取代2026-07-23“应用每任务最大号码数”旧要求，测试环境既有应用值无需迁移。
|
||||
2. 可配置规则仅包括单任务最大号码数、非工作时间大批量营销发送和10分钟客户端任务创建频控。重复号码比例、非法号码比例、黑名单命中比例、模板变量异常不再作为可配置风控规则；历史规则与命中记录保留审计但不再生效或展示。
|
||||
3. 10分钟任务频控只按同一企业应用、`SmsBatchTask.sourceType=client`统计真实客户端任务；CMPP、公开HTTP、运营通道测试和风控预检不得计入。配置上限N时，第N+1个客户端任务进入规则指定动作。
|
||||
4. 非工作时间规则支持`HH:mm`开始、结束时间并允许跨日，时区固定使用`Asia/Shanghai`；全局和企业应用级覆盖均可分别配置。
|
||||
5. 手机号码基础合法性只判断“1开头、总计11位、全部为数字”，不得依赖可能滞后的手机号段表。非法号码为确定性拦截，不进入人工审核；客户端/HTTP短信记录标记`submit_failed + submitStatus=rejected + INVALID_PHONE`，CMPP已受理的多号码提交对非法目的号码生成平台失败回执，其他合法号码继续处理。
|
||||
6. 黑名单按单号码确定性拦截，不再按命中比例拒绝整批。命中平台或企业应用黑名单的客户端/HTTP记录标记提交失败、金额为0且不提交通道；CMPP已受理记录生成`REJECTD`失败回执。混合批次中的非黑名单号码继续发送。
|
||||
7. 模板变量异常指本次发送缺少模板必填变量或传入模板未定义变量。该校验保留为不可配置的确定性拒绝，返回明确的缺失/多传变量原因，不进入人工审核；模板创建时的人工审核不能替代每次发送的变量完整性校验。
|
||||
8. 短信审核页面只展示待人工审核和人工审核记录；自动放行和自动拒绝不得混入“人工通过/人工驳回”。号码数量可点击查看真实号码明细，字段仅为手机号码、号码归属地、运营商和短信记录状态，并提供服务端搜索与分页。
|
||||
9. 创建待审核批次时，每条待审`SmsMessageRecord.reviewTaskId`必须同步保存。人工通过或驳回应同时兼容短信直连审核任务和`SmsBatchTask.riskTaskId`关联路径，保证审核任务、批次、短信状态及入队/拒绝动作一致；本次不修复或补发升级前历史异常数据。
|
||||
|
||||
@@ -3669,6 +3669,17 @@ npm run verify:phase8
|
||||
| TC-UIUX-P0-004 | 依次设置768×1024、1366×768、1440×900并复核同一用户。 | 平板四项操作全部可见且热区≥44px；1440首屏完整；1366即使存在内部横向滚动，滚动后删除必须完整可达，且页面级无横向溢出。 |
|
||||
| TC-UIUX-P0-005 | 完成五视口操作后检查浏览器控制台并执行前端/API构建与用户服务回归。 | 无新增console error/warn；前端与API build通过，用户服务测试通过，`git diff --check`通过。 |
|
||||
|
||||
### 17.17 用户登录标识复用、组合查询与管理员保护提示
|
||||
|
||||
| 用例编号 | 操作 | 预期结果 |
|
||||
| --- | --- | --- |
|
||||
| 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-002 | 在客户端分别及组合填写用户姓名、登录账号和状态。 | 请求真实`GET /api/client/users`；只返回当前企业管理员，无法通过查询参数跨租户或查询平台管理员。 |
|
||||
| TC-USER-CONTINUITY-UI-001 | 删除、禁用或降权最后一个平台管理员及某企业最后一个启用管理员。 | 后端返回权威冲突；确认弹窗保持打开并显示红色可访问错误及“先创建或启用另一名管理员”建议，按钮结束忙碌状态，浏览器无未处理Promise。 |
|
||||
| TC-USER-CONTINUITY-UI-002 | 为相同范围增加另一名启用管理员后重复删除或禁用。 | 操作成功、弹窗关闭、列表按当前已应用查询条件刷新，并写入对应OperationLog。 |
|
||||
|
||||
### 17.17 2026-07-21 下游连接恢复与历史回执回填
|
||||
|
||||
| 用例编号 | 操作 | 预期结果 |
|
||||
@@ -3815,3 +3826,30 @@ npm run verify:phase8
|
||||
- `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和重试状态。
|
||||
## 2026-07-26 企业应用停用与回执清算专项
|
||||
|
||||
- `APP-DISABLE-001`：应用无待清算数据时点击停用，直接进入已停用并断开该账号全部CMPP连接。
|
||||
- `APP-DISABLE-002`：存在等待供应商回执、待推送、待ACK或可重试失败记录时，停用弹窗展示真实分类数量，并提供等待与强制停用两个操作。
|
||||
- `APP-DISABLE-003`：选择等待后进入`disabling`；新Submit同步返回非成功响应且不创建短信记录，历史回执仍可通过原连接或重新连接推送。
|
||||
- `APP-DISABLE-004`：停用中状态悬停、聚焦时展示原因、分类数量、进入时间和72小时自动停用时间。
|
||||
- `APP-DISABLE-005`：停用中点击启用恢复`active`，清除`disablingAt/autoDisableAt`，旧扫描任务不得再次将其停用。
|
||||
- `APP-DISABLE-006`：选择强制停用后，未完成投递及尝试标记`abandoned`、停止重试，并断开同账号的所有CMPP连接。
|
||||
- `APP-DISABLE-007`：从进入停用中满72小时仍有待清算数据时，系统自动执行强制停用；API/Gateway重启不影响截止时间。
|
||||
- `APP-DISABLE-008`：停用后新到供应商回执仍更新短信终态和保存原始回执，但下游投递直接记为`abandoned`。
|
||||
- `APP-DISABLE-009`：企业存在`active/disabling`应用时删除失败；全部应用为`disabled/deleted`后允许删除。
|
||||
- `APP-DISABLE-010`：企业或应用已停用后，Gateway仍可读取此前已形成的pending回执，不再返回账户无效导致投递死锁。
|
||||
|
||||
## 2026-07-26 风控与短信人工审核专项
|
||||
|
||||
- `RISK-RULE-001`：规则页只展示单任务最大号码数、非工作时间营销批量和10分钟客户端任务频控；重复、非法号码比例、黑名单比例和模板变量规则不展示且不参与计算。
|
||||
- `RISK-RULE-002`：同编码同时存在全局和企业应用级规则时，目标应用使用应用级阈值，其他应用继承全局；停用应用级规则后回落到全局。
|
||||
- `RISK-RULE-003`：修改阈值、动作、状态、优先级和非工作开始/结束时间后重新查询与数据库一致；非法编码、负阈值、同范围重复规则和相同起止时间被后端拒绝。
|
||||
- `RISK-FREQ-004`：同一应用10分钟内已有N个客户端批次时，第N+1个客户端任务命中；同期CMPP、HTTP、运营通道测试及风险预检数量不影响结果，另一应用任务也不影响。
|
||||
- `PHONE-VALID-005`：`10000000000`视为合法基础格式并继续号段/路由处理；非1开头、非11位或包含非数字字符的号码被确定性拦截。
|
||||
- `PHONE-BLOCK-006`：客户端/HTTP混合提交合法、非法、平台黑名单和企业应用黑名单号码；合法号码入队，三类拦截号码均为`submit_failed/rejected`、金额0且没有上游提交。
|
||||
- `PHONE-BLOCK-007`：CMPP多目的提交混合合法、非法和黑名单号码；Submit被平台受理后，非法/黑名单号码各生成一条`REJECTD`失败回执并投递客户，合法号码继续发送。
|
||||
- `TEMPLATE-VAR-008`：已人工审核模板在本次发送缺少必填变量或多传未定义变量时直接拒绝并列出变量名，不生成待人工审核任务；变量完整时正常继续。
|
||||
- `SMS-REVIEW-009`：待审核列表只含`pending_review`；人工通过/驳回列表只含`reviewedById`非空记录，自动放行和自动拒绝均不出现。
|
||||
- `SMS-REVIEW-010`：点击号码数量后，通过真实后端分页查看手机号码、归属地、运营商和短信状态；号码搜索与10/20/50条分页正确，接口同时兼容`reviewTaskId`和批次`riskTaskId`关联。
|
||||
- `SMS-REVIEW-011`：客户端和CMPP待审核任务创建时短信记录保存`reviewTaskId`；人工通过后短信由`pending_review`转为`queued`并入队，人工驳回后转拒绝且执行既有资金释放，不能只更新审核任务。
|
||||
- `SMS-REVIEW-012`：升级前历史`pending_review`异常记录保持原样，不执行数据修复或短信补发；升级后新任务不再产生审核任务与短信状态不一致。
|
||||
|
||||
@@ -2460,3 +2460,32 @@ git diff --check
|
||||
- 独立 Linux 临时目录从锁文件执行两次全新 `npm ci --ignore-scripts` 成功：根项目 59 个包、API 726 个包；旧版 minimatch 三条真实依赖链花括号匹配和长度上限均通过。整改后根项目审计只剩同一条不适用 RSC 公告的 2 个依赖节点，API high 从 26 降为 0，仅剩 Prisma CLI→Valibot 的 3 个 moderate；该工具链不处理 API 请求且上游暂无修复版本，不降级 Prisma 7。
|
||||
- 功能门禁通过：报备 Excel 专项 1 suite / 7 tests，API 全量 26 suites / 325 tests，API TypeScript build，前端 TypeScript/Vite生产构建，Gateway `go test ./...`、`go vet ./...`，以及依赖安全门禁。标准部署脚本也会在干净安装后、Prisma migration 前强制执行该门禁，失败即停止发布。前端保留既有约 1.94 MB 单 chunk 提示；API 测试保留既有 Redis 容错告警和 `--forceExit` 异步句柄提示。
|
||||
- Windows 本地完整 `npm ci` 因另一进程占用两个原生 `.node` 文件而无法清理旧目录，未结束未知会话进程；随后非破坏性 `npm install` 修复本地依赖。锁文件可重建性以隔离 Linux 干净安装结果为准。提交、推送和预发布部署结果待发布后补记。
|
||||
|
||||
## 2026-07-26 用户登录标识复用、组合查询与管理员提示（本地未提交、未部署）
|
||||
|
||||
- 用户逻辑删除仍保留原记录、主键、角色关联及历史审计；用户名、邮箱和手机号改为仅对`deletedAt IS NULL`记录唯一。新增migration删除原全表唯一索引并创建三个PostgreSQL部分唯一索引，允许新用户以新主键复用已删除用户的登录标识，不继承旧账号身份或权限；登录和用户名查询显式排除已删除记录。
|
||||
- 运营端用户管理将用户姓名、登录账号、所属企业、用户角色和状态拆分；客户端拆分用户姓名、登录账号和状态。查询/重置调用真实用户列表API，后端按独立条件组合PostgreSQL查询，客户端条件由当前会话企业强制限域并固定企业管理员角色，不再下载全量用户后只在浏览器过滤。
|
||||
- 新增/编辑用户的校验和重复登录标识错误改在当前表单弹窗内显示。删除、禁用或降权最后一个管理员继续由后端实时计数拦截；运营端和客户端确认弹窗捕获HTTP错误、保持打开、显示可访问红色提示和“先创建或启用另一名管理员”建议，请求期间禁用按钮，不再产生未处理Promise。操作成功后才关闭弹窗，再按已应用筛选条件刷新列表；刷新失败不会误报为删除失败。
|
||||
- Prisma validate/generate通过；用户服务定向1 suite / 15 tests、API全量26 suites / 328 tests、API TypeScript build和前端TypeScript/Vite生产构建通过。全量测试只保留既有Redis不可用容错告警和`--forceExit`异步句柄提示，前端保留既有约1.94MB单chunk警告。
|
||||
- 本地静态预览访问运营端、客户端用户管理路由时均由真实认证守卫重定向至对应图形验证码登录页；页面标题、登录表单、无框架覆盖和控制台0条error/warn通过。没有绕过验证码，因此分离筛选和管理员拦截弹窗的登录后可见交互仍保留为人工登录复核项。
|
||||
- 本轮按用户要求保持未提交、未推送、未部署；未对预发布数据库执行migration或写入测试用户。`api/tsconfig.build.tsbuildinfo`、`outputs/`及未跟踪空文件`=`保持隔离，未纳入本次修改。
|
||||
|
||||
## 2026-07-26 企业应用停用回执清算与下游断连（本地未提交、未部署）
|
||||
|
||||
- 企业应用新增`disablingAt/autoDisableAt/disableReason`持久化字段和`disabling`状态；停用前统计等待供应商回执、等待推送、等待客户ACK、可重试失败、待推送上行和在线连接。
|
||||
- 无待清算数据直接停用；有数据时运营端弹窗可选择“等待回执后停用”或“强制停用并断开连接”。停用中状态支持悬停/聚焦查看原因和数量，并可点击启用恢复。
|
||||
- 停用中应用立即拒绝新Submit但允许回执清算连接；清算完成自动停用，进入停用中满72小时仍未完成时自动放弃剩余投递、标记`abandoned`并断开该账号全部下游CMPP连接。
|
||||
- Gateway新增按客户账号关闭全部下游会话的控制接口；历史pending回执读取移除企业/应用当前启用状态限制，修复企业删除后回执已生成但Gateway持续收到400的投递死锁。
|
||||
- 企业删除增加`active/disabling`应用拦截。应用停用后才到达的供应商回执继续更新真实短信终态，但下游投递直接留痕为`abandoned`且不再重试。
|
||||
- 已通过Prisma format/generate/validate、API定向3 suites / 155 tests、API全量26 suites / 333 tests、API TypeScript build、前端TypeScript及Vite生产构建、Gateway `go vet ./...`和`go test ./...`。API全量仅保留既有Redis不可用容错告警和`--forceExit`异步句柄提示；前端保留既有约1.94MB单chunk提示。
|
||||
- 应用内浏览器访问本地生产预览的企业应用管理路由，被真实认证守卫引导到运营登录页；页面标题和登录表单正常、无框架错误覆盖、控制台0条error/warn。当前没有已登录会话且存在图形验证码，未绕过认证，因此停用选择弹窗、停用中悬停详情和恢复启用的登录后视觉交互仍需持有有效会话后复核。
|
||||
- 本轮按要求不提交、不推送、不部署；工作区原有用户管理、依赖安全整改、构建产物及`outputs/`等其他会话修改保持原样。
|
||||
|
||||
## 2026-07-26 风控规则与短信人工审核整改（发布前）
|
||||
|
||||
- 风控规则收敛为单任务号码上限、可自定义非工作时间营销批量、10分钟客户端任务频控三项；新增全局/企业应用级规则页和真实后端编辑接口。应用级规则稳定覆盖全局，客户端频控直接统计同应用`sourceType=client`批次，排除CMPP、HTTP、通道测试和预检。
|
||||
- 删除企业应用`maxPhonesPerTask`字段和表单配置，不迁移测试应用旧值；重复号码、非法号码比例、黑名单比例和模板变量规则转`deleted`保留历史审计但不再生效。模板变量缺失/多传继续作为确定性提交拒绝。
|
||||
- 手机号码基础校验放宽为`^1\d{10}$`，不依赖号段更新。客户端/HTTP混合批次逐号码把非法号码、平台黑名单和企业应用黑名单记为`submit_failed/rejected`且金额0，合法号码照常冻结、入队；CMPP混合多目的提交对被拦截号码生成平台`REJECTD`失败回执，合法号码继续处理。
|
||||
- 短信审核页只返回待人工审核及人工处理记录，自动放行/拒绝不再混入；号码数量恢复设计基线的查看入口，真实接口仅返回手机号、归属地、运营商和短信状态并支持服务端搜索/分页。
|
||||
- 新待审核短信同步保存`reviewTaskId`，审核决定同时按短信直连和批次`riskTaskId`查找，修复审核任务已通过而短信仍`pending_review`。遵照要求不改写现存历史异常数据、不补发历史短信。
|
||||
- 发布前门禁阶段结果：Prisma format/generate/validate通过；风险审核+发送链定向2 suites / 108 tests通过，随后补充应用覆盖、号码分页与逐号码拦截用例；API全量26 suites / 338 tests、API TypeScript build、前端TypeScript/Vite生产构建、Gateway `go test ./...`/`go vet ./...`、依赖安全门禁通过。API保留既有Redis不可用容错告警与`--forceExit`提示，前端保留约1.95MB单chunk/584.70KB gzip提示。
|
||||
|
||||
Reference in New Issue
Block a user