feat: harden platform workflows and UI governance
This commit is contained in:
hectorzhao
@@ -2060,3 +2060,107 @@ git diff --check
|
||||
- 生产运行提交为`f02c33cbb7248410c189f75502d6e497fff7b355`。`cmpp-gateway`、`cmpp-api`、Nginx、PostgreSQL、Redis和MinIO均active，`12026/17890/8090/3000/9000`监听；API/Gateway health、Redis PONG、PostgreSQL readiness、外部首页、运营登录、客户端登录、API health和Swagger JSON均通过，公网CMPP `8.160.169.106:17890`可连接。根目录/API生产依赖audit均为0漏洞。
|
||||
- 两个active上游通道均为`connected/currentConnections=1`，权威TPS配置已恢复；Redis Stream `gateway.submit.commands` consumer group为`pending=0、lag=0`。部署后API/Gateway error级日志均为0。未发送或重投真实短信，未执行充值、审核、删除或生产业务数据修改。
|
||||
- 本地Browser五视口LG2-P0-01证据已通过；生产浏览器烟测被企业网络策略禁止访问该公网HTTP地址，未使用其他浏览器或自动化方式绕过。生产外部HTTP/TCP、真实服务、数据库、Redis和运行产物均已核验，但本次不把生产浏览器交互标记为通过。
|
||||
|
||||
## 2026-07-21 北向连接名额、历史回执与报表回填复查（未提交、未部署）
|
||||
|
||||
- 生产只读复查确认北向普通/长短信无 `SUBMIT_RESP` 的直接阻塞发生在企业应用下游接入侧：账号 `695829` 的旧连接登记为 `connected`，但 TCP 和 Redis 均无对应在线连接；`lastHeartbeatAt=NULL` 使既有 `lastHeartbeatAt < cutoff` 条件永远不成立，陈旧记录持续占用 `cmppMaxConnections`，新连接在业务层登记时被关闭，Submit 因而未被 Gateway 读取。经用户授权只清理该条已确认无真实连接的陈旧登记，未修改账号、应用或短信数据，连接名额恢复为 0；仍须部署本轮代码后重新做生产普通、长短信和多号码端到端验证。
|
||||
- `markTimedOutDownstreamConnections` 已增加安全的 NULL 心跳清理：仅当 `lastHeartbeatAt IS NULL` 且 `connectedAt` 也早于超时窗口时才删除，避免误清刚建立但首个心跳尚未到达的连接。回归测试先在旧实现上失败，修复后 `sms-config.service.spec.ts` 46 项全部通过。
|
||||
- 生产历史数据只读核对找到 3 条“已有唯一 DELIVRD、主记录仍 submitted”的旧记录，均为同一上游账号复用两个通道时历史回执 `channelId` 归属反转；2026-07-21 新回执已按唯一提交记录正确归属并聚合，说明当前实时匹配代码已生效，遗留缺口是旧数据回填而不是继续发生的实时抢占。
|
||||
- 新增 migration `20260721150000_backfill_misattributed_delivery_receipts`：仅在“同一内部消息、同一 Gateway Msg_Id、同一目的号码恰好只有一条提交记录”时修正回执通道并把 DELIVRD 聚合到短信主记录；零匹配或多匹配保持原样，避免猜测修复。迁移可重复执行；本地真实 PostgreSQL 构造同账号双通道错归属样本后应用及重放均通过，主记录变为 `delivered`，回执状态、原始码/文本、到达时间、通道和通道消息号一致。
|
||||
- 在上述真实样本上执行既有 T-4 至 T-1 报表重算，发送数/成功数/失败数为 `1/1/0`，利润成功数为 1，质量成功率为 100%，平均到达时长为 5000ms；证明 7 月 18、19 日历史报表缺口应按“先迁移回填主记录，再重算对应日期”处理。生产尚未应用 migration 或重算，历史页面当前仍会保持旧结果。
|
||||
- HTTP 正向发送旧结论经 2026-07-21 较新生产证据纠正：仅传 `mobile/content` 的合法请求已返回 202、自动关联正确签名和模板、返回 MessageId，并通过真实路由和计费；不能再归类为当前未修复。重复用户名生产接口也已返回 409。黑名单 P2002 映射代码原已存在，本轮补充全局/企业及逻辑删除占用的 `BLACKLIST_DUPLICATE` 409 回归测试。
|
||||
- 完整验证：API 21 suites/240 tests、Gateway `go test ./...`、API build、前端 TypeScript/Vite build、Prisma generate/validate/status（58 条 migration，schema 最新）均通过；前端仅有既有约 1.9MB chunk warning，Jest 仍需 `--forceExit` 结束既有异步句柄。`git diff --check` 在文档收尾后另行复核。
|
||||
- `npm run verify:phase8` 的契约和 Gateway 阶段通过，但共享 Redis 的 BullMQ 15,000 条/500 并发结果为 enqueue 3577.89 TPS、端到端 431.29 TPS，未达到 500 TPS，因此完整命令未通过；临时隔离 Redis 同参数端到端为 567.37 TPS 并通过。该项按共享环境性能阻塞记录，不把共享 Redis 结果标为通过。
|
||||
- 本地正式链路启动真实 NestJS API、PostgreSQL、Redis 和 Go Gateway：API `/api/health`、Gateway `/health` 均为 `ok`，Redis `PONG`，Gateway 监听 `127.0.0.1:7890` 且恢复候选数为 0；验收后精确停止本轮 3000/8090/7890 端口进程。未向生产号码发送短信，未部署、未提交、未 push。
|
||||
|
||||
## 2026-07-21 UI/UX A1双门户会话隔离与深链恢复（未提交、未部署）
|
||||
|
||||
- 修复`LG2-P1-01/02/03/05`：前端会话存储、DOM事件和BroadcastChannel按`admin/client`命名空间隔离；NestJS使用`cmpp_admin_session/cmpp_client_session`（安全Cookie环境使用对应`__Host-`名称），中间件按目标门户路径只读取对应Cookie；所有touch/lock/unlock/reauthenticate/logout/password接口改为门户专用路径。
|
||||
- 新增真实会话初始化边界和安全returnUrl：受保护路由先读取后端当前会话，未登录时保存同源、同门户白名单目标；登录后回原深链。当前会话接口只返回安全用户DTO和时序状态，不输出令牌。锁定刷新时暂停首次业务路由和运营看板请求，解锁后原URL重新挂载真实数据；当前标签已加载的路由不会被另一门户广播卸载。
|
||||
- 自动化：认证会话2 suites/10 tests、API TypeScript build、前端TypeScript/Vite build及`git diff --check`通过；项目没有前端lint/组件测试脚本，未虚报。前端仍有既有约1.90MB大chunk警告。本批无Prisma schema变更。
|
||||
- 真实链路：本地PostgreSQL建立隔离验收用户，Redis真实保存不透明会话；同一Cookie容器同时得到`cmpp_admin_session,cmpp_client_session`。锁定admin时client仍active，admin解锁轮换Cookie，client退出后admin当前会话仍返回`a1_admin`。
|
||||
- 浏览器：客户端13/13受保护路由逐条打开和刷新均保持目标URL及客户端身份，console error/warn为0；同浏览器双门户并存、客户端退出后运营端刷新继续有效。运营用户页在1440×900、1366×768、768×1024、390×844、375×667实际视口均显示真实用户且console为0；390×844锁定、刷新、解锁后仍在`/admin/users`且真实用户重新出现，锁定阶段console为0。证据在测试项目`平台LG_UIUX二轮走查证据/A1会话隔离-20260721/`。
|
||||
- 未修改生产业务数据，未发送短信、充值、审核、删除或报备；代码未提交、未push、未部署，生产仍运行旧会话实现。生产发布后旧共享Cookie需要重新登录，故台账暂记“待验证”。本地临时API由本会话启动，收尾时精确停止；PostgreSQL/Redis/既有前端进程不属于本会话，不停止。
|
||||
|
||||
## 2026-07-21 UI/UX A2客户端安全上传与日志导出（未提交、未部署）
|
||||
|
||||
- `LG2-P1-04`改为客户端专用上传/下载接口：租户从当前会话用户反查，不再信任`x-tenant-id`；企业认证、签名报备、引流报备用途和目录白名单由后端强制，跨企业下载返回404。前端客户端预览/下载也不再调用admin端点。
|
||||
- `LG2-P1-06`新增两端共用日志导出状态组件：提交中防重复、完成数量/截断提示/操作单号、CSV下载、失败原地重试，并按门户在`sessionStorage`仅保存瞬时恢复筛选。后端从PostgreSQL真实筛选导出；客户端租户由会话反查且CSV只保留时间、级别、模块、操作人、动作、资源ID，另有10000条上限和公式注入防护。
|
||||
- 自动化通过：文件/运营服务2 suites、24 tests，API TypeScript build，前端TypeScript/Vite build，Prisma validate/migrate status（本地58条、schema最新）和`git diff --check`。项目仍无前端lint/组件测试脚本；前端仍有既有约1.9MB chunk告警。
|
||||
- 真实链路：本地NestJS、PostgreSQL、Redis和MinIO在线；客户端真实验证码登录后，携带伪造租户头上传仍落当前企业`a2-local-tenant`，MinIO对象经客户端接口读回55字节。客户端日志导出真实返回安全6列表头、5条记录；Browser在1440×900点击导出显示3条和操作单号`2aa2521d-111d-48a6-87c2-27cdbcf680be`。本轮未完成console专项读取，不虚报console通过。
|
||||
- Browser上传因隐藏file input点击超时未完成页面级验收；1366×768、768×1024、390×844、375×667截图也尚未补齐，因此两项台账均保持“待验证”，不标记已通过。未改生产数据，未提交、未push、未部署；并行会话的短信配置、字典、回执migration及其文档未改动。
|
||||
|
||||
## 2026-07-21 UI/UX A3审核通过风险治理（未提交、未部署）
|
||||
|
||||
- 新增独立审核治理服务和`RiskAction`组件，签名/模板“通过”从直接终态调用改为“后端资格预检→对象/影响确认→提交中锁定→结构化结果”。签名预检覆盖应用绑定、公司/信用代码、法人、责任人/手机号和资质文件；模板覆盖内容、签名绑定及签名审核状态。
|
||||
- 后端从当前会话写审核人，使用`pending + updatedAt`条件更新和Serializable事务阻止并发覆盖；AuditRecord ID作为操作单号，幂等键随审计持久化，同键重试返回原结果。旧批准路由也统一进入治理服务。未修改并行会话占用的`sms-config.service.ts/spec.ts`。
|
||||
- 自动化通过：审核治理1 suite/5 tests、API TypeScript build、前端TypeScript/Vite build、Prisma validate及`git diff --check`。前端仍有既有约1.91MB chunk告警；Jest断言通过后仍需`--forceExit`结束既有异步句柄。
|
||||
- 真实本地API/PostgreSQL：完整签名预检为`approve,reject`且0阻断，首次批准写入操作单号`cmruefurl0002msyuftczvswt`并变为approved；相同幂等键重放返回同一单号和`replayed=true`。验收企业、应用、签名、审核记录、用户和日志已精确清理。
|
||||
- Browser实际打开运营登录页并读取验证码，但登录后受A1未提交会话链的“登录会话已失效”恢复提示阻断，未打开A3确认层；console专项返回空数组。未改生产数据。驳回统一协议、有限撤销/双人复核和五视口页面证据未完成，因此台账记“部分通过”，代码未提交、未push、未部署。
|
||||
|
||||
## 2026-07-21 定时短信自动派发与多实例幂等（未提交、未部署）
|
||||
|
||||
- 根因：到期任务此前只有 `POST /api/admin/send/scheduled/dispatch-due` 手工入口，API 启动后没有自动扫描；派发前也没有数据库条件更新认领，多实例同时扫描会重复冻结和入队。
|
||||
- API 启动后默认 1 秒首次扫描、每 5 秒继续扫描，可通过 `SMS_SCHEDULED_DISPATCH_SCAN_ENABLED` 和 `SMS_SCHEDULED_DISPATCH_SCAN_INTERVAL_MS` 配置；进程内重入保护避免同一实例扫描重叠。
|
||||
- 派发使用 `id + status (+ stale updatedAt)` 的 `updateMany` 条件更新原子认领。正常任务进入 `scheduled_dispatching`；超过默认 2 分钟的陈旧认领在 `scheduled_dispatching/scheduled_recovering` 间交替认领，保证多实例仅一个恢复者胜出。
|
||||
- 恢复时按 `tenantId + transactionType=frozen + relatedType=sms_batch_task + relatedId` 查询既有冻结流水，存在则不再冻结；BullMQ 继续使用消息记录 ID 作为 jobId。0 元任务在资源和余额检查通过后若 Redis 入队失败，也保留调度中状态等待恢复，不会被错误终结。
|
||||
- 回归测试先覆盖旧代码失败，再完成实现；`send-chain.service.spec.ts` 共 67/67 通过，新增自动启动扫描、并发扫描唯一认领、陈旧认领恢复不重复冻结和 0 元任务入队失败可恢复用例。API TypeScript build 通过。
|
||||
- 该 Jest 套件断言约 24 秒完成，但仍需 `--forceExit` 结束仓库既有 BullMQ/Redis 异步句柄；未把句柄问题标记为通过。本批没有 Prisma schema/migration 变化，尚未执行真实 PostgreSQL/Redis 双实例故障注入，留待本地链路总验收。
|
||||
- 代码和文档均未提交、未 push、未部署；生产仍需发布后验证无需手工接口即可自动派发到期任务。
|
||||
|
||||
## 2026-07-21 下游人工重投与Gateway提交异常恢复（未提交、未部署）
|
||||
|
||||
- 根因一：`requeueDownstreamDelivery` 原先先读取再普通 `update`，没有状态版本条件；并发请求可重复递增人工次数并多次调用 Gateway。若直接把认领结果写为 pending，Gateway 恢复扫描还可能与同步控制面调用形成双发窗口。
|
||||
- 下游人工重投改为 `id + status + updatedAt` 的 `updateMany` 原子认领，认领态为 `manual_requeueing`；Gateway pending 查询不会选中该状态。成功写出后进入 `awaiting_ack`，失败走既有明确状态机；超过默认 2 分钟的陈旧认领自动恢复为 pending，阈值可通过 `CMPP_DOWNSTREAM_MANUAL_REQUEUE_STALE_MS` 配置。
|
||||
- 根因二：Gateway提交异常虽然已有 pending→requeueing 抢占，但 Redis XADD 成功、数据库更新 requeued 失败时会永久停留 requeueing；直接重放又可能产生第二条 SubmitCommand。重复异常上报还会无条件把已解决记录重置为 pending。
|
||||
- 提交异常重入队现在使用 `gateway:submit:requeue:{deadLetterId}:{nextAttempt}` 稳定键和 Redis Lua，原子执行幂等检查、XADD 和 30 天 Stream ID 保存；陈旧 requeueing 由后台扫描抢占为 requeue_recovering，并复用同一键完成数据库落账。SubmitResult 可从 pending/requeueing/requeue_recovering/requeued 任一在途状态直接闭环 resolved，恢复不会覆盖 resolved；重复上报只更新失败详情，不回退处理状态。
|
||||
- 回归测试先在旧实现失败，修复后 `send-chain.service.spec.ts` 71/71 通过；新增重复异常上报不回退、陈旧提交重入队恢复、下游并发唯一认领和陈旧人工认领恢复用例。API TypeScript build 通过；Jest 仍需 `--forceExit` 结束仓库既有 BullMQ/Redis异步句柄。
|
||||
- 真实 Redis 验证：同一幂等键并发发布两次返回相同 Stream ID，Stream entry 数为 1，幂等键 TTL 为 2592000 秒；测试 Stream 和 key 已删除。
|
||||
- 真实 PostgreSQL 并发验证：两个请求在读取同一版本后同时重投，结果为 1 成功、1 冲突，Gateway 控制面仅调用 1 次，`manualRetryCount=1`，成功记录进入 awaiting_ack；陈旧 manual_requeueing 记录自动恢复为 pending。另以真实 PostgreSQL+Redis 验证陈旧提交异常恢复后 status=requeued、人工次数=1、重复幂等发布仍只有一条 Stream entry。所有本地临时企业、应用、投递、异常、日志、Stream 和 key 均已清理。
|
||||
- 本批无 Prisma schema 或 migration 变化，没有修改 Go Gateway。未发送短信，未修改生产数据；代码未提交、未 push、未部署。
|
||||
|
||||
## 2026-07-21 UI/UX A4报备生成资格、幂等与结果治理（未提交、未部署）
|
||||
|
||||
- `LG2-P1-15`后端新增`POST /api/admin/report-materials/batches/preflight`，逐资料/通道检查审核与待报备状态、应用启用、版本、路由、通道状态、字段配置和必填值；非法资料ID返回可读400，0可生成目标在创建批次前返回`REPORT_BATCH_NOT_ELIGIBLE`。
|
||||
- 生成接口要求幂等键，通过PostgreSQL advisory transaction lock认领操作；资料类型/ID/版本/应用/通道/运营商形成持久化业务键。相同请求重放返回原操作单和结果，不同范围复用键返回409；成功响应包含成功、跳过、失败分项及每项阻断原因。
|
||||
- 运营端列表由真实预检控制选择资格，明确显示“待补充”及首个阻断原因；生成前再次预检，确认层展示企业、应用、版本、预计通道、运营商和分项计数，提交中锁定，完成后显示批次与操作单号。
|
||||
- 自动化：`report-materials.service.spec.ts` 7/7、API TypeScript build、前端TypeScript/Vite build、Prisma validate及migrate status（本地58条、schema最新）均通过，`git diff --check`通过。API build首次被并行会话尚未完成的`send-chain.service.ts`变量错误阻断，未修改该文件；对方完成后收尾重试已通过。项目没有独立前端lint/组件测试脚本；前端仍有既有约1.91MB单chunk告警。
|
||||
- 真实API/PostgreSQL：临时已审核但未绑定应用的资料经真实管理员登录、待报备和预检接口返回`eligible=false`、0目标、“未绑定短信应用”；临时企业、用户、签名和日志清理后均为0。没有调用生成接口。
|
||||
- Browser只打开到确认层并取消：完整临时应用、路由、通道和字段显示1个可生成组合；1440×900、1366×768、768×1024、390×844、375×667均无横向溢出且弹窗在视口内，console error/warn为0。截图位于测试项目`平台LG_UIUX二轮走查证据/A4_LG2-P1-15_报备预检_*.png`；所有临时数据清理为0。
|
||||
- 未修改生产业务数据，未生成报备、发送短信、审核、充值或删除生产对象；代码未提交、未push、未部署，生产仍运行旧实现。
|
||||
|
||||
## 2026-07-21 UI/UX A5通道/签名/模板删除治理（未提交、未部署）
|
||||
|
||||
- `LG2-P1-20`新增统一`DeletionGovernanceService`、admin/client预检与删除接口及共享`DeleteRiskAction`。确认层展示对象名称/ID、活动依赖数量和对象摘要、阻断原因、影响范围、可恢复说明、原因、提交态及结构化操作结果；客户端查询由会话企业强制裁剪。
|
||||
- 后端对通道组/路由/活动连接/报备、签名关联模板/引流/报备、模板发送/批量任务做真实依赖检查。删除使用`updatedAt`乐观锁、Serializable事务、幂等键、逻辑删除和OperationLog操作单，旧通道删除及旧签名/模板删除状态入口统一委托治理服务。
|
||||
- 正向真实链路首次暴露`PrismaService.operationLog`代理属性不可配置导致事务客户端访问代理时报500；将属性改为可配置并新增`prisma.service.spec.ts`，修复后同一页面请求成功。真实PostgreSQL模板状态变为`deleted`并写入`governance.delete`日志、原因、依赖、影响和幂等键。
|
||||
- 自动化通过：`deletion-governance.service.spec.ts`与`prisma.service.spec.ts`共2 suites / 7 tests、API TypeScript build、前端TypeScript/Vite build、Prisma migrate status（本地58条、schema最新）和`git diff --check`。项目没有独立前端lint/组件测试脚本；前端仍有既有约1.91MB单chunk告警。
|
||||
- Browser真实页面：通道被活动组引用时，1440×900、1366×768、768×1024、390×844、375×667均展示1项引用和后端阻断原因，确认按钮断言disabled；无依赖模板填写原因后页面列表变空，数据库和审计同步落账。console error/warn为0。证据位于测试项目`平台LG_UIUX二轮走查证据/整改_A5_LG2-P1-20_20260721/`。
|
||||
- 本轮只写入并精确清理本地验收数据，未操作生产对象。代码未提交、未push、未部署；通用Dialog焦点/背景/dirty保护归A7，前端拆包与缓存归C阶段。
|
||||
|
||||
## 2026-07-21 UI/UX A6人工充值草稿、确认与幂等治理（未提交、未部署）
|
||||
|
||||
- `LG2-P1-21`将充值记录页和企业管理页两个入口收敛到共享`ManualRechargeDialog`。取消、右上角关闭和完成都会销毁金额、备注、预检、结果及幂等键；浏览器分别填写`123.45/88.88`和备注后取消/关闭，重开字段均为空。
|
||||
- 新增`POST /api/admin/billing/manual-recharges/preflight`，从真实企业账户返回版本、现金余额、授信、方向和预计余额。确认层显示企业名称/编码/ID、方向、当前余额、变动、预计余额及备注，提交期间防重复，成功显示订单号、余额、操作单和幂等重放状态。
|
||||
- 最终接口由当前会话注入操作者，要求8—128位幂等键和账户版本；advisory transaction lock串行同键请求，`updatedAt`条件更新阻止覆盖新余额。订单、余额增量、账户流水和OperationLog在Serializable事务中原子写入。
|
||||
- 真实API/PostgreSQL：本地临时账户10.0000元，经页面充值1.2345元后为11.2345元；订单、流水、审计各1条。相同幂等键再次调用真实API返回同订单、同操作单、`replayed=true`，三个计数仍各1。充值记录页和企业管理页均回读11.2345元。
|
||||
- Browser五视口1440×900、1366×768、768×1024、390×844、375×667通过；375短屏底部操作可达，console error/warn为0。截图和API日志位于测试项目`平台LG_UIUX二轮走查证据/整改_A6_LG2-P1-21_20260721/`。
|
||||
- 自动化通过：`billing.service.spec.ts` 1 suite / 11 tests、API TypeScript build、前端TypeScript/Vite build、Prisma migrate status（58条、schema最新）及`git diff --check`。项目没有独立前端lint/组件测试脚本；约1.92MB单chunk告警归C阶段性能项。
|
||||
- 仅修改并精确清理本地验收数据，未操作生产充值。代码未提交、未push、未部署；生产仍运行旧实现，通用Dialog焦点/背景隔离/dirty guard继续由A7处理。
|
||||
|
||||
## 2026-07-22 UI/UX A7公共Dialog整改（未提交、未部署）
|
||||
|
||||
- 修复`LG2-P1-23`：公共Modal新增初始焦点、顶层焦点栈、Tab/Shift+Tab约束、背景`inert`/`aria-hidden`、滚动锁、`aria-labelledby`和关闭后焦点恢复；遮罩由可聚焦button改为非交互div。
|
||||
- 新增dirty关闭协议：右上角、取消、Escape和遮罩统一进入具名`alertdialog`；父弹窗暂时inert，继续编辑保留草稿并恢复原字段焦点，明确放弃后才关闭并销毁。人工充值、删除风险动作和两端模板表单接入该协议。
|
||||
- 真实浏览器：本地NestJS/PostgreSQL/Redis会话分别登录运营与客户端；运营企业模板留存1440×900、1366×768、768×1024、390×844、375×667五张截图，客户端模板在1440×900和390×844完成DOM/键盘实测。五视口无横向溢出，主弹窗与确认层焦点循环、草稿保留、背景恢复、触发按钮焦点恢复均通过；两端console error/warn为空。
|
||||
- 验证：前端TypeScript/Vite build、API TypeScript build、Prisma validate/migrate status和`git diff --check`通过。项目无独立前端lint/组件/axe脚本，未虚报；构建仍有既有约1.92MB单chunk告警。
|
||||
- 未创建模板、未执行审核/删除/充值/发送或其他生产业务写入；本地临时用户、企业、日志和Redis会话已精确清理。代码未提交、未push、未部署，生产仍为旧Dialog实现。
|
||||
|
||||
## 2026-07-22 UI/UX A2/A3收口（未提交、未部署）
|
||||
|
||||
- `LG2-P1-04`通过真实Browser文件选择完成客户端企业认证材料上传；PostgreSQL FileObject归属当前会话企业，MinIO对象回读93字节。复验发现并修复手机端文件名、步骤条和省市选择的卡片内裁切，五视口重新截图后文件名完整且页面无横向溢出。
|
||||
- `LG2-P1-06`在客户端系统日志页真实点击导出，五视口均显示5条和操作单号；独立客户端会话API再次导出7条，表头严格为`时间,级别,模块,操作人,动作,资源ID`，测试注入的详情/IP/供应商内部字段均未泄露。
|
||||
- `LG2-P1-14`在运营签名和模板审核页分别打开通过确认层，仅取消时数据库状态仍为pending且审计为0。真实API随后首次批准签名并用相同幂等键重放，两次返回同一操作单`cmrvlgtrq000gakyumhm1iuiv`，重放标志为true且只写一次审核。
|
||||
- 浏览器证据覆盖上传页和日志导出页五视口、签名确认层五视口截图，以及模板确认层1440×900截图和390×844 DOM尺寸测量；两端console error/warn为空。证据位于测试项目`平台LG_UIUX二轮走查证据/整改_A2_A3收口_20260722/`。
|
||||
- 自动化通过：files、operations、review-governance 3 suites / 31 tests；前端build、API build、Prisma validate/status（58条、schema最新）和`git diff --check`。前端仍有约1.92MB单chunk告警，项目无独立前端lint/组件/axe脚本。
|
||||
- 客户端日志列表仍展示内部详情/IP，继续归`LG2-P1-07`，未因导出安全而标记完成。临时数据、MinIO对象和Redis会话已清理；未触碰生产，未提交、未push、未部署。
|
||||
|
||||
Reference in New Issue
Block a user