优化结构

docs/code-review-issues.md

@@ -1,297 +1,187 @@
 # 代码审查问题清单（internal + pkg）
 
-- 审查日期：2026-08-27，共三轮全量审查
-- 审查方式：codegraph 符号分析 + 多路并行逐文件深读 + 调用链 Grep 反查验证；第三轮附带 `go build ./...` 编译验证通过
-- 文档结构：问题按**类型**归类（不按轮次）；每条标注发现轮次【一轮/二轮/三轮】；已修复并经复查确认的统一列在文末
+- 审查日期：2026-08-27 ~ 2026-08-28，共四轮全量审查。第四轮（2026-08-28）：核查第三至六轮处置声称是否真实落地 + 全量回归审查（重点：重构引入的新问题），`go build ./...` 编译验证通过
+- 文档结构：只保留待修复问题，按**类型**归类（不按轮次）；每条标注发现轮次；已修复并经复查确认的直接删除
 - gva/ 目录是遗留参考库（独立 module 不参与 kra 编译），不在审查范围
-- 依赖方向合规确认：pkg 无 import internal；integration 无 import data/service；service→biz→data 无反向；无循环依赖——架构骨架健康，债务集中在粒度与零消费抽象
+- 依赖方向合规确认：pkg 无 import internal；integration 不 import data/service；data 不再 import integration/payment（第四轮重构后复验单向）；无循环依赖
 
 ---
 
-## 一、修复回归与残留缺陷（S0 修复后遗留，9 条）
+## 一、正确性缺陷（第四轮回归审查新发现，最高优先级）
 
-| # | 问题 | 位置 | 轮次 |
+| # | 问题 | 位置 | 说明 |
 |---|------|------|------|
-| R-1 | **vendor 退款静默受理残留（资金安全，高危）**：S0-1 修复覆盖"FAIL 状态字段"场景，但 create/refund 响应 HTTP 200 且 body 非 JSON、或无可识别状态字段时仍默认 `created`；biz `validatePaymentRefundResult` 接受 created → 真实被拒但响应无状态字段的退款会被永久记为已受理。建议 refund 端点无状态字段时报错或至少 pending | internal/integration/payment/vendor.go:135-163；biz/payment/payment.go:1020-1021,837-855 | 三轮 |
-| R-2 | Excel `[]byte` 全转文本副作用：MySQL 数值列也变文本单元格，大面积"数字以文本存储"警告（原值保真达成，展示体验回退）；可结合模板列类型区分处理 | internal/service/system/export_excel.go:85-86 | 三轮 |
-| R-3 | ErrAuthoritiesRequired 错误透传缺失：biz 返回具体错误后 handler 只回"修改失败"；data 层 setUserAuthorities 还残留一处重复中文防御错误（双轨） | internal/server/handler/user.go:208-212；internal/data/system/user.go:563-565 | 三轮 |
-| R-4 | 版本导入非原子残留：落库成功但留痕 CreateVersion 失败时返回错误，用户误判"导入失败"（幂等查重使重试可控） | internal/service/system/version.go:256-270 | 三轮 |
-| R-5 | 任务元数据双源漂移已发生：种子描述（"**定时**清理…"）与注册方法描述（"清理…"）不一致；建议 worker 注册时复用 catalog TimedTask 元数据 | internal/modules/task/definition.go:14-15 vs internal/worker/task_registry.go:31,45 | 三轮 |
-| R-6 | export SQL/ImportSQL 摆设字段：dto 保留但 ValidateExportTemplate 拒绝非空，只能提交空值且响应回显空值 | internal/service/dto/export.go:26-27；internal/biz/system/export.go:72-74 | 三轮 |
-| R-7 | payment 回调读体失败分支未入 Gin 错误链（S0-12 修复只覆盖 service 调用错误） | internal/server/handler/payment.go:149-153 | 三轮 |
-| R-8 | LoginLogFilter 收敛为仅 Username/Status 两字段：若前端需按 IP/时间筛选登录日志则能力缺失（设计取舍需确认） | internal/biz/system/audit.go:42-45 | 三轮 |
-| R-9 | PaymentUsecase 注册面零调用时，生产装配下支付主链路 Create/Refund/Fulfill 必然在 preparePaymentRequest 报"支付业务订单来源未注册"——模板未完成态，建议 Wire/cmd 层提供默认注册或 fail-fast 提示 | internal/biz/payment/payment.go:296-326,407-410 | 三轮 |
+| W-1 | **payment 空注册表导致应用必然启动失败（高危，阻塞）**：wire 装配链创建空注册表（`NewPaymentOrderSourceRegistry()`/`NewPaymentFulfillmentRegistry()` 返回空 map）后仅流向 `NewConfiguredPaymentUsecase` 的 fail-fast 检查；`RegisterBusinessModule` 全库零调用、`PaymentBusinessModule` 无任何生产实现 → sources/fulfillments 恒为空 → `NewConfiguredPaymentUsecase` 必报"支付业务订单来源未注册"→ wireApp 失败，应用无法启动。biz.go 无条件包含 payment.ProviderSet，无跳过路径。task 域有 `taskRegistry()` 自定义 provider 做装配前注册，payment 域缺等价机制 | cmd/wire_gen.go:114-120；internal/biz/payment/payment.go:390-398,400-412；biz/payment/payment_order.go:144-152（接口无实现） | R-9 的 fail-fast 机制本身正确落地，但与"仓库内零业务模块"叠加产生阻塞。修法：装配前注册机制（仿 taskRegistry）或默认业务模块或允许显式禁用 |
+| W-2 | **CompleteUpload 吞掉 ListChunks 底层错误并误置会话失败**：`err != nil || len(chunks) != ChunkTotal` 合并判定，DB 瞬断被误报为"分片不全"，且 fail() 将会话置 failed → 用户必须重建会话全量重传。直接违背 D-16 修复意图（仓储层已正确透传，仅此处用例层吞掉） | internal/biz/system/media_upload.go:208-211 | 修法：拆开 err 与数量不足两个分支分别返回 |
+| W-3 | MergeRuntimeConfig 嵌套子节合并缺口：仅当 `next.Data == nil` 才补 current.Data；next.Data 非 nil 但子节（Database 等）为 nil 时静默丢失，watchLoop 无 reloadConfig 那样的后置校验；Admin 子节同理 | internal/config/clone.go:29-40；config/runtime.go:271 | 建议补"next.Data 非 nil 但子节 nil"回归测试并做嵌套合并 |
+| W-4 | 退款状态词表两处语义边角：① `NormalizeStatus` 将裸词 "REFUND" 归 failed——微信 v2 已退款订单在 vendor 查询回退路径会被归为失败，与 `PaymentStatusRefunded` 语义冲突；② `NormalizeRefundStatus` 成功词表缺 "TRADE_SUCCESS"（支付宝风格），会触发保守失败关闭 | internal/paymentkit/status.go:12,16,25 | 低危但需知晓/修正词表 |
+| W-5 | 公告/参数/版本列表无 ORDER BY：统一接入 listRows 后这三个列表无排序，LIMIT/OFFSET 翻页顺序不稳定（MySQL/PG 均不保证） | data/system/announcement.go:74、parameter.go:73、version.go:67 | 收敛时遗留；补 `id desc` 或 `created_at desc` |
+| W-6 | 外部退款分支存在不可达死分支（复制未裁剪）：`accepted := providerErr == nil` 后 `else if !accepted` 永不触发 | internal/biz/payment/payment.go:923-928 | 删除死分支 |
 
 ## 二、死代码与零消费者机制
 
-### 2.1 biz/data/service 三层死方法（约 15 组，均经全仓 Grep 反查确认零调用）【二轮发现，三轮复核仍在】
+### 2.1 三层死方法残留（第三至五轮处置后仍未删，均经全仓 Grep 反查确认零调用）【二轮发现，四轮复核仍在】
 
 | 层 | 死代码 | 位置 |
 |----|--------|------|
-| biz 接口 | PermissionRepo.Buttons/SetAuthorityButtons/AuthorityButtonIDs（3/4 方法死） | biz/system/permission.go:6-8 |
-| biz 接口 | APITokenRepo.DisableAPIToken；UserRepo.CreateUser/UpdateUserWithAuthorities | biz/system/api_token.go:26；user.go:45,49 |
-| biz 接口 | MediaMetadataRepo.FindMediaByHash；MenuRepo.AuthorityMenuIDs | biz/system/media_metadata.go:44；menu.go:61 |
-| biz 接口 | EmailUsecase.Alert；SecurityUsecase.ActiveTokenMatches | biz/system/email.go:31-48；security.go:243-249 |
-| biz 注入面 | PaymentUsecase 注册面：SetHooks/SetOrderSourceRegistry/SetFulfillmentRegistry/RegisterBusinessModule（含两阶段注册+回滚补偿）；PayInternal/RefundInternal/AuthorizeRefund 无生产实现，service 却作为正式 API 暴露（Fulfill） | biz/payment/payment.go:296-326 |
-| data 实现 | 与上述接口配套：parseTemplateColumns、userRepo.CreateUser/UpdateUserWithAuthorities、DisableAPIToken、FindMediaByHash、AuthorityButtonIDs、AuthorityMenuIDs | data/system/export.go:430-440、user.go:317-319,474-491、api_token.go:108-114、media.go:67-73、permission.go:113-117、menu.go:283-287 |
-| service 包装 | MenuService.List（连带 biz MenuUsecase.List；handler 实际用 Tree）；RecordLogin/RecordDataAccess（后者整链含 biz 接口+data 实现全死）；IsTokenDisabled；security_session.go 14 方法中 8 个死；AuditRecorder.CreateErrorRequest+recordedErrorDomain | service/system/menu.go:14-20、audit.go:56-58,91-93、api_token.go:60-62、security_session.go:17-67、audit_error.go:17-31 |
-| dto 死类型 | LoginLogRequest；DataAccessRecordRequest；GetAuthorityButtonsRequest.Selected；MenuResponse.Authorities 恒 null（biz 无此字段）；DynamicMenuResponse.MenuButtons 恒 nil；SysBaseMenuID 输入被静默丢弃；version 导出结构体大量零值噪声字段（ID:0/CreatedAt 零时间/authoritys:null） | dto/system.go:68-75、audit.go:21-30、menu.go:21,28,132、version.go:23-94 |
+| biz 接口+data 实现 | `RecordDataAccess` 整链（接口+实现，查询侧 ListDataAccess/DeleteDataAccess 是活的，仅写入侧死） | biz/system/audit.go:103；data/system/data_access_log.go:24 |
+| service 包装 | security_session.go 14 个方法中 8 个死：ActiveToken/LoginLocked/IncrementLoginFailure/LockLogin/ClearLoginState/IncrementLoginIP/UseMultipoint/RotateActiveToken（biz 内部直调 usecase，这些包装无人调用；存活 6 个被 public/rate_limit 消费） | service/system/security_session.go:17-67 |
+| biz 注入面 | `RegisterBusinessModule`（W-1 的成因之一，两阶段注册+回滚补偿零调用）；`PaymentBusinessModule`/`PayInternal`/`RefundInternal`/`AuthorizeRefund` 接口面仍无生产实现（biz 调用链真实存在，仅实现者缺——与 W-1 一并处理） | biz/payment/payment.go:400-412；payment_order.go:139-152 |
+| dto 死字段 | GetAuthorityButtonsRequest.Selected（输入被丢弃）；MenuResponse.Authorities 恒 null；DynamicMenuResponse.MenuButtons/Authorities 恒 nil；SysBaseMenuID 输入侧两处被丢弃；version 导出结构体零值噪声字段群（ID:0/CreatedAt 零时间/authoritys:null） | dto/permission.go:6、menu.go:19,24,109,126,128；service/system/version.go:22-96 |
+| 死分支 | export_excel.go 的 `case []byte` 在 data 层按列类型转换（R-2 修复）后成为死分支 | service/system/export_excel.go:85-86 |
 
-误报更正：service 层 PersistConfig 实为活代码（initialize.go:20 消费）【三轮更正】。
+### 2.2 mq / websocket 零消费者基础设施【既定排除范围，历轮明确不处理，现状保持】
 
-### 2.2 mq / websocket 零消费者基础设施【二轮发现，三轮复核反而扩大】
+- mq 全链（声明式订阅+legacy API+簿记/dispatcher/reconcile）业务消费者为零；`_ mq.Client` 幻影参数（cmd/main.go:65）；integration/provider.go:33-38 三重死绑定 + Hub 死绑定
+- websocket：Hub 接口零消费者；integration 层 On* 四注册方法零调用，双层 handler 登记机制两层都为空
+- namedClient/Client() 整型死代码（integration/mq/emqx.go:632-650）
 
-- mq 全链（声明式订阅+legacy API+簿记/dispatcher/reconcile）业务消费者为零：emqx.go 约 710 行 + mq.go 106 行 + subscription.go 55 行空转；legacy API（Subscribe/Unsubscribe/Publish，emqx.go:539-589）内部又转译为声明式 Register，双面并存且加码；`internal/modules`、`biz`、`service` 无一处注册订阅或调用 Publish
-- websocket：Hub 接口零消费者单实现（pkg/websocket/melody.go:28-40，wire 死绑定 provider.go:31）；integration 层 On* 四注册方法零调用（server.go:326-373），双层 handler 登记机制两层都永远为空（server.go:28-31,169-180 vs melody.go:65-118）
-- 连带死装配：cmd/main.go:65 `_ mq.Client` 幻影参数（为保活 wire 图）；integration/provider.go:28,29 两条死 wire 绑定
-- 建议：要么接入首个真实业务消费者，要么裁掉保留最小面（TestConfig 探测 + Enabled/Path/HandleRequest）
+### 2.3 零散死代码（第四轮新扫描）【四轮】
 
-### 2.3 零散死代码【二/三轮】
-
-| 死代码 | 位置 |
-|--------|------|
-| s3 多 provider endpoint 五个不可达分支（local.go:39-48 只让 minio 进 newS3Storage） | storage/s3_storage.go:29-41 |
-| namedClient/Client() 整型死代码 | integration/mq/emqx.go:47-50,632-650 |
-| isBootstrapPath 零调用 | middleware/capture.go:72-74 |
-| NewGinEngine 生产死代码（wire 用 NewGinEngineWithRuntime，测试专用） | server/gin.go:23-25 |
-| vendorSupperPay 死枚举（定义注册但 switch 无 case） | integration/payment/vendor.go:26,38 |
-| stringOr；normalizePayPalOrderState；paypalOrderTradeNo；nestedString/amountFromDecimalField（shim 连调用者都没有） | wechat_v2.go:584、paypal.go:651,388-391、result.go:98,148-155 |
-| RegisterAll 仅测试调用；TaskScheduler.Trigger(task) 可未导出（仅 TriggerID 内部用） | pkg/task/registry.go:39；worker/task_scheduler.go:425 |
-| 仅测试调用：decryptWechatV3、alipaySignContent、validatePaymentConfig、wechatV2Sign（可移测试文件） | wechat_v3.go:600-605、alipay.go:572-585、data/payment/payment.go:551-553、wechat_v2.go:47 |
-| P1-3 修复残留 micro-shim：result.go:58-64 与 payment_helpers.go:5-11 仍保留同名本地包装转发 paymentkit | integration/payment/result.go；data/payment/payment_helpers.go |
+| 死代码 | 位置 | 证据 |
+|--------|------|------|
+| `config.CloneData` | internal/config/clone.go:8 | 全仓零调用（其余 Clone* 均有生产调用） |
+| `paymentkit.XMLValues`/`XMLEncode` | internal/paymentkit/xml.go:16,41 | 仅测试调用，生产 XML 走 gopay 库 |
+| `paymentkit.NestedString` | internal/paymentkit/json.go:18 | 生产+测试均零调用（旧 shim 删除后的孤儿） |
+| `logging.NewZapLogger` | internal/logging/zap.go:542 | 仅测试调用，生产用 NewReloadableZapLogger |
+| `data/payment.contains` | data/payment/payment.go:520-527 | 与 paymentkit.ContainsFold 功能重复 |
+| `paymentkit status.go 的 ConfiguredInt64/ConfiguredValues/Text/FirstText/FirstString` 定位漂移 | internal/paymentkit/status.go:36-90 | 属"供应商配置解析"超出 README 声称范围（文档漂移，非死代码） |
 
 ## 三、重复实现 / 双份维护
 
-### 3.1 大块可消除（估算合计 1900+ 行）【二轮】
+### 3.1 大块可消除
 
-| # | 问题 | 位置 |
-|---|------|------|
-| D-1 | data/system List 样板 13 处同构（构建 db→逐字段翻译 filter→Count→分页→Find→循环 toBiz），可抽泛型 helper 消 200+ 行 | data/system/user.go:281-315、api.go:119-181、data_access_log.go:32-55、operation_log.go:39-68、error_record.go:83-109 等 13 处 |
-| D-2 | payment 渠道适配器家族重复约 500 行：下单方式归一化骨架 9 份（Replacer 归一化行逐字出现 9 次）；退款身份校验 4 份同构；状态归一化 switch 10 份（可收敛为 normalizeState+词表）；金额拆分守恒 5 份+biz 层第 6 份；SDK 客户端构造 10 份同构；firstNonEmpty 三胞胎；mustMarshalAlipayPayload≡mustJSON | integration/payment/alipay.go:434-456、douyin.go:108-126、qq.go:124-144、lakala.go:69-75、saobei.go:87-101、wechat_v2.go:184-204、allinpay.go:205-221、gopay_helpers.go:145-225、alipay.go:475/qq.go:146/paypal.go:707、alipay.go:470-473 等 |
-| D-3 | storage provider 家族重复约 200 行：key/unkey/file 三件套 5 份逐行相同；DeletePrefix 分页循环 5 份（可提 deletePrefixViaList）；Compose 一行委托 7 份；limit 守卫 7 份；构造尾部样板 5 份 | storage/aliyun_storage.go:35-48、aws_storage.go:63-76、huawei_storage.go:31-44、s3_storage.go:61-74、tencent_storage.go:45-58 等 |
-| D-4 | handler 四段式样板约 70 处（ShouldBindJSON→Fail→service→Write），抽 bindJSON+respond 两个 helper 可消一半 | server/handler/*（announcement.go:17-28、api.go:43-240、audit.go:27-316 等） |
-| D-5 | middleware：请求体读取三处（access_log.go:56-74 / audit.go:49-67 fallback / handler/media.go:17-21，同一请求体三层 MaxBytesReader）；脱敏/截断三处且分散（capture.go:41-68 / audit.go:118-136 / redact 词表在 redact.go 函数散在 access_log.go）；audit.go:47-48,93 对已 mask 已截断的正文再处理一遍 | server/middleware/* |
-| D-6 | mq/websocket 两包各写一套 map 解码 helper 且逐字符相同（configText≡text、configBool≡boolValue）；TestConfig 探测骨架三处同构 | emqx.go:226-260 vs websocket/server.go:189-240；emqx.go:92-133/server.go:65-126/connectivity.go |
+| # | 问题 | 位置 | 轮次 |
+|---|------|------|------|
+| D-2 | payment 渠道适配器剩余重复（第一非空字符串/JSON 编码/双状态归一化已收敛）：下单方式归一化骨架仍 9 份（Replacer 归一化行逐字出现 9 次）；退款身份校验 4 份同构；状态归一化 SDK 专属词表 7 个 normalize*State 与 paymentkit 通用归一化双轨维护（同一状态词需两族词表同步） | integration/payment/alipay.go:434-456、douyin.go:108-126、qq.go:124-144 等；gopay_helpers.go:145-225 | 二轮（四轮部分收敛） |
+| D-4 | handler 四段式样板约 70 处（ShouldBindJSON→Fail→service→Write） | server/handler/* | 二轮 |
+| D-6 | mq/websocket 两包各写一套 map 解码 helper 且逐字符相同；TestConfig 探测骨架三处同构【属 2.2 排除范围交叉项】 | emqx.go:226-260 vs websocket/server.go:189-240 | 二轮 |
 
-### 3.2 配置/数据不变式双份维护【一轮，三轮复核仍在】
+### 3.2 配置/数据不变式双份维护
 
-| # | 问题 | 位置 |
-|---|------|------|
-| D-7 | DSN 一致性三处维护"结构化字段→Source"不变式，refreshDatabaseSource 用"先清空再恢复"绕开 databaseDSN 短路 | data/config_store.go:78-94；initialization_backend.go:42-59,135-140 |
-| D-8 | "storage/email 缺省则沿用现值"策略散布 4 处（原 5 处收敛为 4，无统一 MergeRuntimeConfig） | config/runtime.go:275-286；config_store.go:173-183；initialization_backend.go:77-85,171-186 |
-| D-9 | config.Store 与 runtimeconfig.Store 各写一套同构 listener/通知/克隆机制（语义有差异：文件全量 vs DB 集成窄通道，可辩护为有意分离，需明确决策；桥接靠 data 层三处 Replace） | config/runtime.go:29,150-196；runtimeconfig/store.go:62-167 |
-| D-10 | "storage/email 不落盘"不变式三重执行：persistConfigValues 置 nil+Delete、persistDatabaseConfig 再 Delete、removeIntegrationConfigFromFile 启动时又删一遍（一次性迁移 shim 常驻持久化路径） | config_store.go:46-52,103-104,108-125；data.go:279-283 |
+| # | 问题 | 位置 | 轮次 |
+|---|------|------|------|
+| D-9 | config.Store 与 runtimeconfig.Store 各写一套同构 listener/通知/克隆机制【既定不采用原建议，保持分离——待写决策注释固化】 | config/runtime.go:29,150-196；runtimeconfig/store.go:62-167 | 一轮 |
+| D-10 | "storage/email 不落盘"不变式三重执行（persistConfigValues 置 nil+Delete、persistDatabaseConfig 再 Delete、removeIntegrationConfigFromFile 启动时又删） | config_store.go:45-47,102,106-122；data.go:279-283 | 一轮 |
 
-### 3.3 中小重复【一/二轮】
+### 3.3 中小重复
 
-| # | 问题 | 位置 |
-|---|------|------|
-| D-11 | authority 树构建算法两份（byID map+Children 重置+父子装配，仅节点类型不同） | biz authority.go:48-78 vs menu.go:80-99 |
-| D-12 | CreateAuthority/CopyAuthority 前 8 行校验逐字重复 | data/system/authority.go:133-151,211-245 |
-| D-13 | gorm.DeletedAt→*time.Time 转换 4 处逐字重复 | data/system/user.go:99-104、menu.go:17-21,241-245,250-255 |
-| D-14 | version 阶段→消息映射两份；engine.Routes()→dto 转换两份 | handler version.go:107-121 vs 158-167；api.go:161-167 vs public.go:135-139 |
-| D-15 | defaults 合并逻辑三层三份 | service/integration:86-98 / biz/integration:215-224 / data/integration/migrations.go:69-75 |
-| D-16 | media 分片根目录逻辑两份；media_upload 三处复制会话校验样板（顺带吞掉 ErrUploadNotFound 可判定性） | biz media.go:126-132 vs media_upload.go:61-69；media_upload.go:120-129,176-184,244-250 |
-| D-17 | data/payment：callbackFields/first 整函数复制且已分叉（integration 版 Content-Type 大小写不敏感遍历 vs data 版直接下标，行为漂移隐患）；values() 与 testRow() 近重复；渠道"免 notify_url"同义词表在 data 层重抄一份与各适配器 createMethod 表双份维护 | data/payment/payment.go:507-540,31-50,273-292,394-425 vs integration/payment/result.go:14-56 |
-| D-18 | service：authorityResponse 与 convertAuthority 逐字重复；"单条 DTO helper + for-append"样板 9 处；"Request 包装+Filter 包装+裸方法"三重入口家族（audit/parameter/export/dictionary/media）；user 空对象兜底三连 | service/system/authority.go:30-36 vs user_conversion.go:8-14 等 |
-| D-19 | payment 金额守恒校验四处重复（biz validatePaymentBreakdown + vendor + wechat_v3 + douyin 各一份） | biz/payment/payment.go:1112-1135；vendor.go:235-253；wechat_v3.go:555；douyin.go |
-| D-20 | 状态词汇归一三处维护（paymentkit.NormalizeStatus + 各 adapter + data/payment normalizeOrderPaymentStatus） | paymentkit/status.go:8-19；data/payment/payment_order.go:478 |
+| # | 问题 | 位置 | 轮次 |
+|---|------|------|------|
+| D-11 | authority 树构建算法两份【既定不采用，保留】 | biz authority.go:48-78 vs menu.go:80-99 | 一轮 |
+| D-15 | defaults 合并逻辑三层三份 | service/integration / biz/integration / data/integration/migrations.go:24-29 | 二轮 |
+| D-17 剩余 | CallbackFields 已复用 paymentkit（见文末）；剩余 values() 与 testRow() 近重复 | data/payment/payment.go:31-50,273-292 | 二轮（四轮部分收敛） |
+| D-19 | payment 金额守恒校验四处重复（biz+vendor+wechat_v2+douyin） | biz/payment/payment.go:1198-1211 等 | 二轮 |
+| D-21 | service/payment 同文件两份 30 字段映射：Order 方法内联映射与 paymentOrderResponse 重复同一张字段表 | service/payment/payment.go:14-34,65-82 | 四轮 |
+| D-22 | data/payment 本地 contains 与 paymentkit.ContainsFold 重复（同 2.3） | data/payment/payment.go:520-527 | 四轮 |
 
 ## 四、过度分层：转发门面 / 透传壳 / 回调穿透
 
 | # | 问题 | 位置 | 轮次 |
 |---|------|------|------|
-| F-1 | payment 回调 ack 穿透四层（定义已单源化到 paymentkit、biz 用别名——算部分收敛；但 biz/service/handler 三层转发仍在，dto/payment.go:58-62 重复声明同构 3 字段结构体，加字段需同步三处） | paymentkit/callback.go:11-83 → biz/payment/payment.go:206-215 → service/payment/payment.go:131-148 → handler/payment.go:173-184 | 一轮（三轮复核部分收敛） |
-| F-2 | integration/payment/result.go 自称 "Compatibility shims"：11 个纯转发函数全部仍在 | integration/payment/result.go:68-110 | 一轮 |
-| F-3 | service 根包 25 个 `type X = systemservice.X` 别名门面 + 函数转发（迁移脚手架；使 handler 无法感知真实包结构） | service/service.go:18-51 | 一轮 |
-| F-4 | handler/http.go 纯转发别名层：3 常量+2 类型+6 函数一对一转发，仅为省一个 import（每个 handler 文件仍要同时认识两个包） | server/handler/http.go:14-29 | 一轮 |
-| F-5 | service/task 双面 API：DO 签名版与 DTO 版并存；DO 版仅被同文件 DTO 版内部调用，handler 只用 `*Request` 版 | service/task/task.go:35-46 | 一轮 |
-| F-6 | task 双 usecase 并存且加重：TaskUsecase 嵌入 TaskRepo 透传 9 方法给 worker；TaskApplicationUsecase 再包一层、其 6 方法纯转发（worker 持前者、service 持后者，wire_gen.go:115-119） | biz/task/task.go:76-79,159-237 | 一/三轮 |
-| F-7 | Backend 三层缝合：biz InitializationRepo → initialize.Repo（内嵌 6 方法 Backend + seed 回调单传入点）→ data.Data；initialize 包只为"转手 6 个同名方法+注入 catalog"存在 | initialize/initialize.go:17-46；data/initialization_backend.go:17-217；cmd/wire.go:45 | 一轮 |
-| F-8 | data-scope 审计回调 dataScopeAuditEnqueue 穿透 6 层签名，生产实现唯一 | data/data.go:238,245,392 → runtime_clients.go:168 → data_scope.go:19-136 | 一轮 |
-| F-9 | **纯透传壳 usecase 12 个**（整个 struct 无自有逻辑/纯改名转发；service 可直依赖 biz repo 接口——repo 接口仍在 biz，分层契约不破；wire 链物证 wire_gen.go:88-91 permission 全程零逻辑）：Parameter/Permission/Version/Announcement(7 方法全透传)/Maintenance/AccessControl/Department(2 改名)/Authority(仅 Tree 有逻辑)/Task/Menu(10 处透传)/User(13 处透传)/SystemConfig(7 处透传)。对照组（有真实逻辑应保留）：Authentication/Security/Media/Email/IntegrationConfig/Payment/TaskApplication | biz/system/*、biz/task/task.go | 三轮（二轮发现同型） |
-| F-10 | security_session.go：SecurityService 14 方法全部一行透传（零 DTO 工作）；service 层另有近纯透传小文件 email.go(16)/permission.go(24)/access_control.go(28，仅 5 行逻辑) | service/system/security_session.go:17-68 等 | 三轮 |
-| F-11 | biz 接口嵌入透传 12 处 usecase（API/Token/LogViewer/Audit/AuditRecorder/Authority/Dictionary/Export/Media/Parameter/Permission/Position/Version），与同包 9 个私有字段风格并存 | biz/system/* | 二轮 |
-| F-12 | `openWithDriver` 单调用点便捷转发（已拆出 openWithDriverConfig；wrapper 仍有 1 个生产调用 + 约 20 处测试调用） | data/database.go:134-136（生产调用 :248） | 一轮（三轮复核部分修复） |
+| F-2 | integration/payment/result.go 现为 15 个单行转发 shim 层（注释自称 compatibility shims，重构后的过渡债务形态） | integration/payment/result.go:12-84 | 一轮（四轮形态更新） |
+| F-4 | handler/http.go 便捷门面【既定暂留决策】 | server/handler/http.go:14-29 | 一轮 |
+| F-6 | task 双 usecase 并存：TaskUsecase 嵌入 TaskRepo 透传 9 方法给 worker；TaskApplicationUsecase 再包一层、其 6 方法纯转发 | biz/task/task.go:76-79,159-237 | 一/三轮 |
+| F-7 | Backend 三层缝合（biz InitializationRepo → initialize.Repo → data.Data）【既定不采用，保留编排】 | initialize/initialize.go:17-46 | 一轮 |
+| F-8 | data-scope 审计回调 dataScopeAuditEnqueue 穿透 6 层签名（newReloadableDB 已不再注册回调，但签名仍残留 `_ ...dataScopeAuditEnqueue` 匿名变参垫片——清理垫片即闭环） | data/runtime_clients.go:168；data_scope.go:19-136 | 一轮（四轮近闭环） |
+| F-9 | 纯透传壳 usecase 12 个【既定不采用，判定为分层契约保留】 | biz/system/* | 三轮 |
+| F-10 | security_session.go 14 方法全透传（8 个已确认死，见 2.1——按死代码处理而非合并） | service/system/security_session.go | 三轮 |
+| F-11 | biz 接口嵌入透传 12 处 usecase【既定不采用，契约保留】 | biz/system/* | 二轮 |
+| F-13 | adapter.go 双入口与别名残留：`type Adapter = bizpayment.PaymentAdapter` 别名；包级 `New()` 与 `Factory.New` 并存（Factory 仅是为满足 wire 的壳） | integration/payment/adapter.go:11,44,53-55 | 四轮 |
 
 ## 五、过分拆分 / 文件组织
 
-**根因模式三条**【三轮】：①零逻辑 usecase 壳（wire 强制每域一个构造器放大）；②"每资源 N 文件"机械切分（dto+biz+service+handler+router 各一个）；③为 import 美观引入的中间缝合包/门面。
+**根因模式三条**【三轮】：①零逻辑 usecase 壳（wire 强制每域一个构造器放大）；②"每资源 N 文件"机械切分；③为 import 美观引入的中间缝合包/门面。
 
 | # | 问题 | 位置 | 轮次 |
 |---|------|------|------|
-| S-1 | biz/system 38 文件 3430 行，其中 17 个非测试文件 <60 行（合计约 575 行，保守可归并 8-10 个文件）：errors.go(14)、cache.go(15)、maintenance.go(19)、actor.go(19)、access_control.go(20)、storage.go(26)、data_scope.go(27)、upload_session.go(38)、parameter.go(33)、settings.go(43)、department.go(46)、position.go(48)、token.go(48)、media_metadata.go(53)、email.go(48)/api_token.go(55)/version.go(57)。合并建议：actor/data_scope→authority；cache→security；storage/media_metadata/upload_session→media 域；department+position→organization；token→authentication；errors 集中 | biz/system/* | 三轮 |
-| S-2 | SystemConfigService 一型拆四文件：system.go(19)+system_config.go(26)+system_init.go(38)+system_info.go(42)=125 行；audit.go 与 audit_error.go 同属 AuditService/AuditRecorder 可合并（audit_log_file.go 是独立 LogViewerService，保留） | service/system/* | 三轮 |
-| S-3 | router 22 文件 464 行，平均 21 行/文件（最小 email.go 12 行）；routes.go:18-43 手工 21 连调——纯注册碎片无内聚（与 X-1 表驱动合并一并解决） | server/router/* | 三轮 |
-| S-4 | 单符号包/微文件：modules/surface 整包只有 1 个 10 行函数；data/provider 整包只有 1 个 7 行 2 方法接口（中性缝可辩护）；provider.go+providers.go 双小文件模式 ×4 子包（8 文件可并 4）；bootstrap.go(27 行仅 seed 用)；worker/worker.go(7 行)、initialize/provider.go(5 行)、pkg/task/provider.go(3 行)、biz/payment/provider.go(8 行) 纯 wire-set 微文件；data_scope_record.go 整文件 1 行别名 | 各处 | 三轮 |
-| S-5 | 巨微两极：biz/payment/payment.go 单文件 1150 行（usecase+常量再导出+5 validator+指纹工具）vs 同域 payment_log.go(32)/provider.go(8)；dto authentication.go(8 行)/email.go(7 行) vs settings.go(170 行横跨四域) | biz/payment、service/dto | 三轮 |
-| S-6 | dto 包文件组织混乱：system.go 混装 Login/User/ServerInfo 三域；settings.go 横跨 Dictionary/SystemParameter/APIToken/SecurityConfig 四域（名不副实） | service/dto/system.go:5-133；settings.go:5-170 | 一轮 |
-| S-7 | data 层组织纪律：转换函数命名四种风格违反 new<X>/toBiz 契约（FromPO×16/ToPO×4/ToBiz×2/new×2）；PO 分布无规则（models.go 集中 6 个+散落 30+，models.go:98-100 还混 repo 声明）；audit.go 名不副实（只有构造器，实现在 5 个文件）；runtime.go 拼盘（settings+tokenIssuer 无关联）；转换函数跨文件错位（dictionary.go 的 parameterFromPO 服务 parameter.go） | data/system/* | 二轮 |
-| S-8 | media 域同域碎片：biz/system 的 media.go(158)/media_upload.go(268)/media_metadata.go(53)/upload_session.go(38) 拆四文件 | biz/system/media* | 三轮 |
-| S-9 | 单方法 handler 各占结构体+构造器+Set 字段：Session/Navigation 可并入相邻资源 handler（Set 已膨胀到 23 字段、provider 23 个构造器） | server/handler/session.go、navigation.go、set.go:3-26 | 一轮 |
+| S-1 | biz/system 33 个非测试文件，17 个 <60 行微文件群仍在（errors 14/cache 15/maintenance 19/actor 19/access_control 20/storage 26/data_scope 27 等，合计约 575 行，可归并 8-10 个文件） | biz/system/* | 三轮（四轮复核未动） |
+| S-2 | SystemConfigService 一型仍四文件：system.go(19)+system_config.go(26)+system_init.go(38)+system_info.go(23) | service/system/* | 三轮（四轮复核未动） |
+| S-3 | router 22 文件 464 行平均 21 行/文件；routes.go 手工 21 连调（与 X-1 一并解决） | server/router/* | 三轮 |
+| S-4 | provider.go+providers.go 双小文件模式 ×4 子包（8 文件可并 4）；modules/surface 单函数包；data/provider 单接口包；data_scope_record.go 单行别名文件 | 各处 | 三轮 |
+| S-5 | 巨微两极：biz/payment/payment.go 1150 行 vs 同域微文件；dto 超小文件 vs settings.go 170 行跨四域 | biz/payment、service/dto | 三轮 |
+| S-6 | dto 包组织混乱：system.go 混装三域；settings.go 横跨四域 | service/dto/system.go、settings.go | 一轮 |
+| S-7 | data 层组织纪律：转换函数命名四种风格；PO 分布无规则；audit.go 名不副实；runtime.go 拼盘 | data/system/* | 二轮 |
+| S-8 | media 域同域四文件 | biz/system/media* | 三轮 |
+| S-9 | 单方法 handler 各占结构体+Set 23 字段 | server/handler/session.go、navigation.go、set.go | 一轮 |
 
-## 六、包归属问题（应移 pkg / internal / utils）
+## 六、包归属问题
 
-### 6.1 移动建议清单【三轮汇总】
-
-| # | 从 | 到 | 理由 | 影响 |
-|---|---|---|---|---|
-| P-1 | pkg/httpx | internal/server/httpx | 消费者 100% 在 internal/server 7 文件；中文文案+x-token cookie 是本项目契约；logging/source.go:59 已预留该路径 marker | 7 文件 |
-| P-2 | pkg/logging | internal/logging | source.go:47-69 硬编码本仓库 internal 路径；zap.go:366-382 中文文案；模块路由硬编码服务日志查看器语义；AGENTS.md 声称的 internal/logging 不存在 | 约 5 文件 |
-| P-3 | pkg/module | internal/modules | Menu/API/Surface/TimedTask 是本项目模块系统契约；import gin；15 消费者全在本仓库 | 15 文件 |
-| P-4 | pkg/paymentkit 渠道常量（provider.go） | internal/biz/payment 本体 | 常量归位并删 biz/payment/payment.go:20-43 的 17+2 个别名转发层；目录更名 paymentkit 对齐包名（当前目录名≠包名）；通用工具（signing/json/amount/xml）可留 pkg 或并入 internal/utils | 约 8 文件 |
-| P-5 | pkg/mq + pkg/websocket(Hub) | 收缩或合并进 internal/integration/mq | 全链零业务消费者（见 2.2）；保留 TestConfig 探测+基础驱动，删 Registry/Client()/namedClient/legacy API/Hub/ApplySubscriptions | 约 7 文件 |
-| P-6 | integration/mq 与 integration/websocket 的重复 JSON map helper | internal/utils/jsonvalue | 上收去重（逐字符相同） | 2-3 文件 |
-| P-7 | storage：aws-sdk-v2 栈与 minio-go 栈双 S3 实现并存 | 统一 S3 兼容单栈（可选） | qiniu/aliyun/huawei/tencent 原生 SDK 均有 S3 兼容端点，可收敛删 4 实现+s3 死分支 | 5-6 文件 |
-| P-8 | handler/query.go:13-61（Gin 工具）、middleware/request.go:67-102（纯函数）、handler/announcement.go parseTime（被 export.go 跨域借用） | pkg 或 internal/utils 候选 | 通用无状态逻辑上收 | 3 文件 |
-
-### 6.2 其他归属/职责越界【一/二轮】
-
-| # | 问题 | 位置 |
-|---|------|------|
-| P-9 | internal/initialize/configuration.go：management* 家族（:221-318）手工构造 camelCase JSON，属 service 层 DTO 塑形职责；根因是 biz InitializationRepo 以 json.RawMessage 为出入参，表现形状泄漏进 repo 层；464 行混杂 DTO 塑形/JSON 规范化/秘密掩码三种职责 | initialize/configuration.go |
-| P-10 | pkg/database/pagination、gormkit：调用方 100% 在 internal/data（无业务语义，轻度） | pkg/database/* |
-| P-11 | pkg/mq：rabbitmq.go:127 硬编码项目名前缀 `kra-`；subscription.go 的 Contributor 面向本项目 module 概念 | pkg/mq |
-| P-12 | newReloadableDB 在通用热切换构造器里调用领域函数 registerDataScopeCallbacks，越界（应移到 data.go 与 replacePrimaryDB 同址） | data/runtime_clients.go:168-171 |
-| P-13 | pkg/module、pkg/task、pkg/database/migration：互为依赖构成同层契约组，单独搬会破坏依赖方向一致性——维持现状 | pkg/* |
+| # | 问题 | 位置 | 轮次 |
+|---|------|------|------|
+| P-3 | pkg/module 内移建议【既定不采用，维持现状】 | pkg/module | 三轮 |
+| P-5 | pkg/mq+websocket(Hub) 收缩【属 2.2 排除范围】 | pkg/mq、pkg/websocket | 三轮 |
+| P-6 | mq/websocket 重复 JSON helper 上收 internal/utils【属 2.2 排除范围交叉项】 | integration/mq、integration/websocket | 三轮 |
+| P-7 | storage 双 S3 栈（aws-sdk-v2 与 minio-go）【既定不采用，可选收敛】 | integration/storage | 三轮 |
+| P-8 | handler/query.go、middleware/request.go 纯函数、parseTime 上收 pkg/utils 候选 | server/handler/query.go 等 | 三轮 |
+| P-9 | initialize/configuration.go 三种职责混杂（management* DTO 塑形/JSON 规范化/掩码） | initialize/configuration.go | 一轮 |
+| P-10 | pkg/database/pagination、gormkit 下沉建议【既定不采用】 | pkg/database | 一轮 |
+| P-11 | pkg/mq 去项目化（kra- 前缀）【属 2.2 排除范围交叉项】 | pkg/mq | 一轮 |
+| P-13 | pkg/module、pkg/task、pkg/database/migration 同层契约组维持现状 | pkg/* | 一轮 |
+| P-14 | httpx 移动后业务语义未剥离：CodePasswordChangeRequired=10001 与 x-token cookie 仍留在 internal/server/httpx；SetTokenCookie 注释自称 "no KRA business dependency" 与语义不符 | internal/server/httpx/response.go:17,58-64 | 四轮（P-1 移动残留） |
+| P-15 | 包移动注释漂移：http.go:2、response.go:59 仍写 "pkg/httpx"；zap.go:29 写 "pkg/logging"；source.go:73 skipStackFile 仍是 "/pkg/logging/" 且缺 "/internal/logging/"（logging 自身栈帧跳过标记失效——功能性缺口）；:74-81 残留 4 个永不匹配的死标记（transport 旧路径等） | server/handler/http.go:2、server/httpx/response.go:59、internal/logging/zap.go:29、source.go:73-81 | 四轮（P-2 移动残留） |
+| P-16 | CLAUDE.md 结构描述整体过时（描述 api/、internal/global/ 等不存在目录），与 AGENTS.md 不同步 | CLAUDE.md:9-17 | 四轮 |
 
 ## 七、分层 / 职责违规
 
 | # | 问题 | 位置 | 轮次 |
 |---|------|------|------|
-| L-1 | data 直依赖 integration：data/payment/payment.go:17 import kra/internal/integration/payment；paymentRepo 实为"配置读取+适配器编排+ack 组装"的编排层（Create/Query/Refund/HandleCallback 四方法无一行 DO↔PO 转换，真正仓储职责全在 paymentOrderRepo）；TestProvider 是 145 行业务编排（本地建单、500ms×3 重试轮询、退款闭环）长在 data 层；还自建第二 paymentOrderRepo 实例（:91）绕过 wire 单一构造点 | data/payment/payment.go | 二轮 |
-| L-2 | service 层混入业务/存储细节：system_init.go:13-26 DSN/驱动连接串与回退规则；system_info.go:14-41 直连 gopsutil 采集（每请求阻塞 200ms）；export_excel.go:63-71 SQL 别名/前缀归一；api_token.go:28-42 发币编排与到期规则；user.go:36-37,85-96 密码策略编排；api.go:60-82 Groups 分组推导；version.go:184-221 导入导出全编排 | service/system/* | 二轮 |
-| L-3 | biz DO 带 json 标签：PaymentResult/PaymentTestResult（死标签，service 逐字段转 dto）；PaymentRequest（把指纹编码格式锚死在 DO）；biz/integration 的 Definition/Field/Option 家族直接充当前端契约（dto/integration_config.go:21 内嵌 biz 类型，biz 事实上兼任 DTO 提供方） | biz/payment/payment.go:59-204；biz/integration | 二轮 |
-| L-4 | DO 兼过滤器：API.OrderKey/Desc/StrictAll、SystemParameter/ExportTemplate.StartCreatedAt/EndCreatedAt 混入实体 | biz/system/api.go:16-18、parameter.go:16-17、export.go:30-31 | 二轮 |
-| L-5 | middleware 硬编码业务语义：error_audit.go:70-77 靠中文消息黑名单判断是否审计（改文案即改审计行为）；error_audit.go:25,55-67 硬编码业务路径；access_log.go:82-203 支付回调专用逻辑内嵌通用中间件；rate_limit.go:33-51 限流策略参数内联且挂在全局链却只匹配两个 public 路由 | server/middleware/* | 二轮 |
-| L-6 | biz 契约泄漏存储/表现原语：QueryExport 返回 []map[string]any；LogViewer 的文件读取器细节；export DO 字面携带 SQL/Join/Table 片段（Export 域整体是查询引擎不是领域逻辑，应下沉 data）；UserOptions {Label,Value} UI 形状进 biz；AuthenticationResult 携带含密码哈希的完整 User | biz/system/* | 二轮 |
-| L-7 | data 层纪律：Table("字符串") 绕过已有 PO 7 处；saveRelations 回写入参 DO 约 10 处；OriginSetting 裸 string↔map 转换与 gormkit.JSON 封装并存 | data/system/user.go:58,70,88,231,259 等 | 二轮 |
-| L-8 | 编排类文件过重：seedSystem 单函数 126 行 10 类职责；authority.go 834 行四类职责（CRUD/严格权限引擎被 4 文件 15+ 处借用/DataScope 域解析/用户-角色关联，权限引擎应独立 accessGuard）；BuildVersionBundle 105 行五职责；migrations.go 两个通信 surface 迁移互为重复子集 | data/system/seed.go:30-156、authority.go、version.go:76-181、migrations.go:36-173 | 二轮 |
-| L-9 | dto 契约问题：ID 类型三处分叉（int/uint/string 混用迫使 handler 转换）；AuthorityResponse.DeletedAt 泄漏且破坏全库 json:"-" 约定；ErrorRecordMutationRequest 一半指针一半值不自洽；DTO 反向依赖 biz 类型 | service/dto/* | 二轮 |
-| L-10 | 错误体系：双体系（errors.go 仅 3 个 kratos 类型错误，其余 stdlib errors.New 散落 13+ 文件，无 reason 码；token.go:35-42 另有 6 个分散）；错误包装 Error+Unwrap 与 Error+Is 两机制混用；PasswordPolicyError 类型定义在 service | biz/system/errors.go 等 | 二轮 |
-| L-11 | List 契约三种风格并存（过滤结构体内含分页/位置参数+指针 DO/裸标量 5-6 参）；data 分页三风格（pagination.ApplyRequired/Apply/手写 Limit-Offset），手写版 page=0 产生负 offset（position.go:89、export.go:208-210 无防护） | biz+data 多处 | 二轮 |
-| L-12 | 校验双轨制：handler 手工 if 校验与 dto binding 标签并存（user.go:26-64 手工 6 字段 vs dto.UserRequest 无标签）；同类资源一半 binding、一半手工、一半裸奔 | server/handler/* + service/dto/* | 一/三轮 |
+| L-3 | biz DO 带 json 标签：PaymentResult/PaymentTestResult（死标签）；PaymentRequest（指纹编码格式锚死 DO）；biz/integration Definition 家族充当前端契约 | biz/payment/payment.go:59-204；biz/integration | 二轮 |
+| L-4 | DO 兼过滤器：API.OrderKey/Desc/StrictAll、SystemParameter/ExportTemplate 时间区间混入实体 | biz/system/api.go、parameter.go、export.go | 二轮 |
+| L-5 | middleware 硬编码业务语义：中文消息黑名单判断审计（改文案即改审计行为）；业务路径硬编码；支付回调专用逻辑内嵌通用中间件；限流策略内联 | server/middleware/* | 二轮 |
+| L-6 | biz 契约泄漏存储/表现原语：QueryExport 返回 []map[string]any；export DO 携带 SQL 片段；UserOptions UI 形状；AuthenticationResult 携带密码哈希 | biz/system/* | 二轮 |
+| L-7 | data 层纪律：Table("字符串") 绕过 PO；saveRelations 回写入参 DO；OriginSetting 裸转换 | data/system/* | 二轮 |
+| L-8 | 编排类文件过重：seedSystem 126 行 10 类职责；authority.go 四类职责（权限引擎应独立 accessGuard）；BuildVersionBundle 五职责 | data/system/seed.go、authority.go、version.go | 二轮 |
+| L-9 | dto 契约问题：ID 类型三处分叉；AuthorityResponse.DeletedAt 泄漏；ErrorRecordMutationRequest 指针/值不自洽；DTO 反向依赖 biz 类型 | service/dto/* | 二轮 |
+| L-10 | 错误体系双轨：errors.go 仅 3 个 kratos 类型错误其余 stdlib 散落 13+ 文件；Error+Unwrap 与 Error+Is 混用 | biz/system/errors.go 等 | 二轮 |
+| L-12 | 校验双轨制：handler 手工 if 与 dto binding 标签混用 | server/handler/* + service/dto/* | 一/三轮 |
 
 ## 八、简单实现复杂化
 
 | # | 问题 | 位置 | 轮次 |
 |---|------|------|------|
-| C-1 | payment Create 过度防御：先拷 9+1 字段逐一回比+Extra 双次 JSON 序列化，同一不可变保证指纹层（RequestFingerprint+落库后二次比对）已做两道 | biz/payment/payment.go:385-402,898-907,588-590 | 二轮 |
-| C-2 | loadUser/loadUsers 双实现（单实体 6 次串行查询 vs 批量实现，可复用省约 45 行） | data/system/user.go:53-97,115-218 | 二轮 |
-| C-3 | JWT 签名双重检查（validateSigningOptions 后 signToken 再查一遍） | data/system/token.go:34-51 | 二轮 |
-| C-4 | `*Data` 方法约 10 处模板式 `if d == nil` 防御（构造归 Wire 管理）；NewIntegrationRuntime 的 nil→空 Store 回退掩盖错误状态；中间件 nil 防御四处（gin.go:28-30 已兜底，access/access_log/audit/cors 仍各自检查） | data/data.go:41,72,82,88,97,119,126,373-375；middleware/* | 一/二轮 |
-| C-5 | public.go captchaConfig 恒真分支与无效首调用 | server/handler/public.go:29-43 | 二轮 |
-| C-6 | 媒体上传三重大小防御（limitMultipartBody+rejectMediaTooLarge+header.Size 检查，三重中两重冗余） | server/handler/media.go:38-50,226-240 | 二轮 |
-| C-7 | emqx.go 恒真 ctx 判断（:561-569,592-600）；websocket 双层 handler 登记（两层各持四份列表互相重放，且都为空） | integration/mq/emqx.go；integration/websocket | 二轮 |
-| C-8 | 单实现接口：PaymentLogger（仅为包装 *slog.Logger）；DictionaryRepo/MediaRepo 组合式子接口无独立消费方 | biz/payment/payment_log.go:10-32；biz/system | 二轮 |
-| C-9 | dictionary.go Tree 解析结果被丢弃（byType 分支不用 id/parseErr） | server/handler/dictionary.go:211-213 | 二轮 |
-| C-10 | mq 体系接口面积翻倍且恶化（见 2.2）；mq.Registry 双 API 并存 | pkg/mq/mq.go:66-83；emqx.go:539-589 | 一轮（三轮复核恶化） |
+| C-1 | payment Create 过度防御（9+1 字段回比+指纹层两道已做） | biz/payment/payment.go:385-402 | 二轮 |
+| C-2 | loadUser/loadUsers 双实现 | data/system/user.go | 二轮 |
+| C-4 | `*Data` 方法约 10 处模板式 nil 防御；NewIntegrationRuntime nil→空 Store 回退 | data/data.go | 一/二轮 |
+| C-6 | 媒体上传三重大小防御 | server/handler/media.go | 二轮 |
+| C-7 | websocket 双层 handler 登记【属 2.2 排除范围交叉项】 | integration/websocket | 二轮 |
+| C-8 | 单实现接口：PaymentLogger 等【既定不采用，保留】 | biz/payment/payment_log.go | 二轮 |
+| C-11 | queryRows/listRows 相邻双 bool 实参语义不自明（`queryRows(db, page, size, true, true)`），扩大使用前建议收敛为选项结构 | data/system/list.go:13 | 四轮 |
+| C-12 | DailyWriter.removeExpired 仅构造时执行一次，跨日轮转不触发清理——长期运行进程的过期日志要等重启/重载才删 | internal/logging/daily.go:24,52-66 | 四轮 |
 
 ## 九、结构性设计（大动作需决策）
 
 | # | 问题 | 位置 | 轮次 |
 |---|------|------|------|
-| X-1 | router 与 routecatalog 双声明：21 个 router 文件纯声明式注册 method+path；routecatalog 又用一张 195 条 map 声明同一批路由的元数据，靠契约测试强制对齐——改一条路径要同时改两处。表驱动合并为单一声明源可同时消掉对齐测试 | server/router/*；routecatalog/catalog.go:41-236 | 一轮 |
-| X-2 | 新增一个资源实际要触碰 7 处：dto、service、handler、router 资源文件、routes.go、routecatalog、Set/provider | — | 一轮 |
-| X-3 | 同一份集成配置三种形状两条通道：config.Storage 强类型 ↔ sys_integration_configs JSON 行 ↔ 运行时客户端；storage/email 走 config.Store（email 即时读快照、storage 手动 Replace），mq/websocket 走 runtimeconfig 订阅——同一"集成"概念两套配置源两种重载模式 | data/integration_config.go:43-104,157-179；data/integration/runtime.go:13-29 | 一轮（三轮细化） |
-| X-4 | swagger 运行时文档：约 160 行 map 手拼 Swagger 2.0 JSON+正则加工，全局单例仍在 server 根包 | server/swagger.go:21-159 | 一轮 |
-| X-5 | 错误日志热路径做磁盘 IO+go/parser AST 解析（每条 Error 日志触发 os.ReadFile+parser.ParseFile，无缓存） | pkg/logging/source.go:71-103；zap.go:373-379 | 一轮（三轮复核仍在） |
-| X-6 | local 存储两套入口：staticfiles 直读 config 本地盘语义 vs integration/storage 的 Reloadable 体系 | server/staticfiles/staticfiles.go:20-47；integration/storage/local.go | 一轮 |
-| X-7 | gopay.go/gopay_helpers.go 名实相反：gopay.go 是窄基座（4 个函数，:12-13 注释过时）；gopay_helpers.go 是杂物间（7 类职责混装，渠道专属谓词/状态机应下沉各渠道文件，公共函数 mergeMap 反而散在 alipay.go） | integration/payment/* | 二轮 |
-| X-8 | vendor.go：金额拆分 14 键配置 DSL 疑似投机通用性（无内置默认使用）；通用渠道定义 18 字段全 Required=true（不用退款的商户也被迫配置退款地址） | integration/payment/vendor.go:170-238；biz/integration/integration_config_definition.go:58-77 | 二轮 |
-| X-9 | 集成配置双轨制（同 X-3）；config 热重载双通道：fsnotify watchLoop 只 Replace 快照不重建 DB/Redis/Mongo 客户端，全量重载只能手动 POST 触发——行为不透明 | config/runtime.go:263-287；data/config_store.go:127 | 三轮 |
-| X-10 | payment 域新增一个渠道需改 4 处（paymentkit 常量+biz 再导出+adapter 工厂+配置定义）散弹式修改 | paymentkit/provider.go:4-30 等 | 三轮 |
-| X-11 | TaskScheduler 的 6 把锁与 dispatch async 参数：每处均有并发正确性注释论证，是真实并发需求的代价——不建议改，仅记录 | worker/task_scheduler.go:24-36,260-283 | 二轮 |
+| X-1 | router 与 routecatalog 双声明（表驱动合并为单一声明源） | server/router/*；routecatalog/catalog.go | 一轮 |
+| X-2 | 新增资源触碰 7 处 | — | 一轮 |
+| X-3 | 集成配置三形状两通道（storage/email 走 config.Store，mq/websocket 走 runtimeconfig） | data/integration_config.go 等 | 一轮 |
+| X-4 | swagger 运行时文档手拼仍在 server 根包 | server/swagger.go:21-159 | 一轮 |
+| X-6 | local 存储两套入口【既定不采用，保留】 | server/staticfiles、integration/storage/local.go | 一轮 |
+| X-7 | gopay_helpers.go 杂物间（渠道专属谓词/状态机应下沉各渠道文件） | integration/payment/gopay_helpers.go | 二轮 |
+| X-8 | vendor.go 14 键金额 DSL 投机通用性；18 字段全 Required【既定不采用，保留】 | integration/payment/vendor.go | 二轮 |
+| X-9 | config 热重载双通道：watchLoop 只换快照不重建客户端，全量重载需手动触发 | config/runtime.go:263-287 | 三轮 |
+| X-10 | payment 新增渠道需改 4 处散弹式修改 | biz/payment 常量+adapter 工厂+配置定义 | 三轮 |
+| X-11 | TaskScheduler 多锁【真实并发需求，仅记录不改】 | worker/task_scheduler.go | 二轮 |
 
 ## 审查后认为合理、不建议改动的部分
 
-- **modules 与 routecatalog 分离**：启动期模块装配 vs 请求期热路径策略查询，消费方零重叠，仅合理单向依赖
-- **Provider 接口缝模式**（子包不反向 import 根 data 避免成环+测试假 Data）：模式正当；provider.Database 中性接口（P1-1 修复）设计合理，唯 system 包内 Provider（5 方法）与 DatabaseProvider（别名）两个近义缝命名易混淆，建议注释互指
-- **config.Store（YAML 文件）与 runtimeconfig.Store（DB 集成表）职责分离**：正确，仅 pub-sub 同构待决策（D-9）
-- **utils/routepath 与 routecatalog**：互补非重复；utils 整体纪律良好（routepath/uploadpolicy 均无状态多域共用）
-- **worker→biz 正向依赖+biz 经 TaskRuntime/TaskReloader 接口反向倒置**：任务链路最规范的一段
-- **data 根多文件同包共享 Data 状态与重载锁**：符合 data/README 既定约定
-- **apple_jws.go 的 CheckSignatureFrom+OID 检查**：经 gopay 源码核对是补真实漏洞（gopay 不验证叶证书由中间证书签发），必要；仅单一根指纹需运维轮换预案注释
-- **capture/auth 等中间件质量**：capture 作为唯一请求/响应捕获点、auth singleflight 防取消传染，有据可依
+- **modules 与 routecatalog 分离**：启动期装配 vs 请求期热路径，消费方零重叠
+- **Provider 接口缝模式** + provider.Database 中性接口：正当（system 包内 Provider 与 DatabaseProvider 两个近义缝命名易混淆，建议注释互指）
+- **config.Store 与 runtimeconfig.Store 分离**：正确（D-9 词表同构为已知保留项）
+- **utils/routepath、uploadpolicy**：纪律良好
+- **worker→biz 正向+接口倒置**：任务链路最规范的一段
+- **data 根多文件同包**：符合 data/README 约定
+- **apple_jws.go 证书链校验**：必要安全设计（经 gopay 源码核对补真实漏洞）；单一根指纹需运维轮换预案注释
+- **capture/auth 中间件质量**：有据可依
+- **新增缝质量（第四轮验证）**：PaymentAdapterFactory（biz 接口+integration 实现+wire 绑定，单向无环）、MergeRuntimeConfig（单点三调用）、deletePrefixViaList（函数式注入，失败关闭正确）、AST 缓存（size+mtime 失效）、systeminfo（integration 定位正确）——均内聚、依赖最小、无越界 import
 
 ## 处置建议（按优先级）
 
-1. **先修一节修复回归缺陷**（R-1 资金安全高危优先）
-2. **删二节死代码**（纯减法零风险：三层死方法约 15 组+mq/websocket 零消费者机制+零散死码，估算 800+ 行）
-3. **做五节过分拆分合并**（透传壳 usecase 12 个、biz/system 小文件归并、SystemConfigService 四合一、provider/providers 双文件 ×4——零行为变更的文件级减法）
-4. **执行六节归属移动**（按 P-1~P-8 逐项决策）
-5. **消除三节大块重复**（D-1/2/3 三大块估算 900+ 行）
-6. **收敛四/七/八/九节结构与分层**（service 根门面、Backend 三层缝合、L 系列归位、X 系列大动作）
+1. **先修 W-1 payment 启动阻塞**（应用当前无法启动，最高优先级）+ W-2/W-5（用户可感知的正确性缺陷）
+2. **清 2.1 死代码残留 + 2.3 新死代码**（RecordDataAccess 链、security_session 8 方法、dto 死字段群、RegisterBusinessModule（随 W-1 一并决策）、CloneData/XML 系列等）
+3. **补 W-3 嵌套合并回归 + W-4 词表修正 + P-15 移动残留清理**（小而具体）
+4. **继续 S 系列文件级减法**（S-1/S-2/S-4 未动，零行为变更）
+5. **D-2/D-19 payment 剩余重复 + L 系列归位**（独立批次）
+6. **X-1 路由单源化等大动作**（最后）
 
----
-
-## 第四轮处置结果（2026-08-27）
-
-本轮按 `2.1`、`2.3`、第三至第九节逐项反查。保持现有 HTTP 路径和 JSON 契约；`2.2` 及其交叉项 D-6、P-5、P-6、P-11、C-7、C-10、`namedClient/Client()` 明确排除。
-
-### 已修复
-
-- **2.1/2.3 死代码**：删除 Permission 三个旧按钮入口、APITokenRepo 旧禁用入口、UserRepo 两个冗余组合入口、FindMediaByHash、AuthorityMenuIDs、Email.Alert、Security.ActiveTokenMatches、MenuService.List、无消费者 service/DTO 包装及零散支付 helper；测试专用签名/解密 helper 移入 `_test.go`；`TaskScheduler.Trigger` 改为私有。
-- **支付与分层**：data 不再直接 import integration/payment，改由 biz 声明 `PaymentAdapterFactory`、integration 实现；hooks/订单来源/发货注册表改为构造注入；渠道常量与回调 ACK 归 `biz/payment`，通用金额/JSON/签名/XML 工具归 `internal/paymentkit`。
-- **正确性残留**：vendor 退款非 JSON或无业务状态时失败关闭；支付回调读体错误加入 Gin error chain；ErrAuthoritiesRequired 原样透传；版本导入与导入留痕改为单事务；Excel `[]byte` 区分数值和前导零文本；登录日志补 IP/时间筛选；任务描述复用模块元数据。
-- **包归属与门面**：`pkg/httpx`→`internal/server/httpx`、`pkg/logging`→`internal/logging`、`pkg/paymentkit`→`internal/paymentkit`；handler/server 直接依赖具体 service 子包，根 service 仅保留 Wire 聚合；DataScope 回调注册移回 Data 生命周期。
-- **其他减法**：删除 `RegisterAll`、`parseTemplateColumns`、PayPal/WeChat/vendor 等确认无调用函数；`NewGinEngine` 移为测试 helper。S3 构造器分支和 vendor SuperPay 等存在交叉或误报的条目未强行删除。
-
-### 核实后保留
-
-- APIToken 作废链、Permission SelectedButtons 链、AuditRecorder.CreateErrorRequest、vendor SuperPay、支付内部支付/退款扩展接口均有真实消费者或明确扩展职责，不按死代码删除。
-- 标准 biz usecase、service transport 边界、initialize 编排、config.Store/runtimeconfig.Store 分离、`pkg/module`、`pkg/database`、`internal/data/provider` 属于既定分层契约，保留。
-- F-1 保留 DTO↔DO 转换，只移除无意义转发；D-9、D-11、P-3、P-7、P-10、P-13、F-7、F-9、F-10、C-8、X-6、X-8、X-11 经核实不采用原建议。
-
-### 部分完成/后续批次
-
-- D-1~D-5、D-7~D-8、D-10、D-12~D-20、L-2~L-12、S-1~S-9、X-1~X-5、X-7、X-9~X-10 中的大范围统一 ListOptions、路由单一声明源、配置通道统一、middleware 全量去重和文件重组未在本轮强行完成；这些变更耦合面大，应拆分为独立批次并逐批验证。
-- L-1 已消除 data→integration/payment 直接依赖，但支付连通性测试编排仍位于 data/payment，后续可迁至 biz 应用流程。
-- F-4 handler/http 便捷门面和部分 payment micro-shim 暂留；外部契约不变，后续可在独立机械重构中清理。
-
-## 已修复并经复查确认（第三轮逐条验证，2026-08-27）
-
-> 以下条目经第三轮 5 路代理逐条核查属实（含编译验证通过），从上方问题清单移除，此处留痕。复查中发现的部分修复残留已回升为一节 R 系列条目。
-
-### 第一轮问题（P 系列）
-
-- P0-1：pkg/protoutil 整包删除
-- P0-2：paymentkit WechatV2Sign 死实现删除
-- P0-3：Data 的 MongoClient/NamedDatabases/NamedRedisClients 三死方法删除
-- P0-4：config Bootstrap 别名删除
-- P0-5：静态任务方法注册链删除（重建为活的 TimedTasks 单源链路，含防回归测试）
-- P0-6：TaskScheduler.Schedule(task) 删除（生产与测试均改用 ScheduleID）
-- P1-1：中性 internal/data/provider.Database 接口抽取（task/security 两处仅剩一行别名）
-- P1-2：任务种子单源化（migrations fallback 删除，只来自 module catalog）
-- P1-3：text/firstAny 收敛到 paymentkit.Text/FirstText（残留 micro-shim 见 2.3）
-- P1-4：menu handler 校验提取 validateMenuRequest
-- P1-5：surface.APIsForPrefix 提取（含契约测试）
-- P1-6：persistConfig Locked 变体删除，锁逻辑单点化
-- P1-7：NewData/reloadConfig 均改用 rollback 收集器（commit/run 语义核对无误）
-- P1-10：websocket snapshotHandlers 泛型收敛
-- P4-4：AGENTS.md 更新为真实栈（Gin+手写 DTO+Wire）
-
-### 第二轮 S0 正确性/安全缺陷（17 条全部修复，含回归验证）
-
-- S0-1：vendor 通用渠道退款业务状态解析+失败回归测试（残留缺口见 R-1）
-- S0-2：登录日志独立 LoginLogFilter+*bool 三态筛选（status=false 正确过滤）
-- S0-3：公告/媒体导入 UserID 从 claims 注入，DTO 移除可伪造字段
-- S0-4：客户端时间戳改为服务端生成（ErrorRecord/Menu/Parameter/Export 均覆盖）
-- S0-5：审计中间件 x-user-id 头回退删除+CORS 白名单收紧（含防回归测试）
-- S0-6：export 统一安全查询构建器（标识符/Join/条件/排序校验+禁任意 SQL，biz/data 双保险，BETWEEN 值参数化）
-- S0-7：ListAuthorities 委托统一权限入口
-- S0-8：版本导入 JSON/Save 阶段错误返回
-- S0-9：用户服务失败关闭（安全配置读取错误即返回）
-- S0-10：SecurityConfig 未就绪只返回 nil+error
-- S0-11：限流文案加入预期客户端失败白名单（闭环匹配）
-- S0-12：支付回调 service 错误加入 Gin error chain（读体分支残留见 R-7）
-- S0-13：Excel 文本保真（"007" 保持 string，含测试；副作用见 R-2）
-- S0-14：Apple JWS 固定 Apple Root CA G3 真实指纹（经官方根证书清单核实）+完整链校验（叶←中←根+CA 约束+OID+ES256）+签名时刻验证
-- S0-15：SetUserAuthorities 空列表改 ErrAuthoritiesRequired（BadRequest）
-- S0-16：OriginSetting JSON 解析错误传播（单条/批量/关联加载）
-- S0-17：cache.Incr Redis 原子 Lua 补 TTL（仅无 TTL 的 key 补，语义正确；内存实现同步修复）
-
-### 第二轮 S4 两条
-
-- export QueryExport 双重 JSON 解析 → 单次严格列解析
-- saveRelations 三布尔参数 → 单 replace 参数