SunYF
1cc93795ce
- 在main.go中添加定时任务每10分钟同步可生产数量到WMS系统 - 为BomItem实体添加relatedStandard字段及相关CRUD方法 - 为InspectionRecord实体添加reportNo、materialCode、materialName等字段 - 更新ent schema确保新字段的验证和默认值设置 - 添加必要的数据库迁移和字段映射逻辑
13 KiB
13 KiB
bj_power 四视角综合审计（业务 / 行业规范 / 性能稳健 / 闭环复审）
- 日期：2026-09-17
- 方法：3 个只读审计 agent 分头核查 WMS(8890) / MES(8888) / 工位终端(8892) / 大屏，结论均对照磁盘真实代码（含行号）。最高严重度项（U1 静默吞错、U2 退库单）已在上轮由主代理亲自读代码核实，本轮 agent 独立复验一致。
- 说明：P0-1
P0-5、P1-6P1-10 已知项已交另一 AI 修复，本审计聚焦"其余问题 + 已知项是否真闭环"的复验。带 * 项为需向业务确认、agent 可能误读的点，不要直接当缺陷。
一、业务视角（反直觉 / 不贴合现场）
| 编号 | 文件:行 | 严重度 | 问题 |
|---|---|---|---|
| A1 | outbound.go:102/119/162 | P1 | 备料出库硬编码 ManageMode=1 且只查批次库存，电气件（模式2）备料出库走不通或模式错。通用出库(:388)按 len(SnList) 自动切 1/2、入库按 m.ManageMode 切——此处未对齐。 |
| A2 | （核查通过） | — | 入库/通用出库"结构件批次↔电气件SN"自动切换已实现；半成品/成品靠 association_trace 落"用了哪些批次/哪些SN"；工位拍照(InspectPanel.vue+PhotoField.vue→MES station_ops.go base64 落盘)有落库路径；检验三分(category INCOMING/PROCESS/FINAL + inspectionNo 贯穿)已落地。基本贴合现场。 |
| A3 | return_order.go:124 | P2 | 退库电气件即便新建行也被强制 mode1（与 U2 同源）。 |
业务视角结论：主线（配置→库存→排产→报工→追溯→流程卡）自洽；缺口集中在"备料出库的物料模式切换"与"退库单对电气件的处理"。
二、MES/WMS 行业规范（领域专家视角）
| 编号 | 文件:行 | 严重度 | 违反规范 / 问题 |
|---|---|---|---|
| S1 | outbound.go:439(批次)/:476(SN) | P0 行业硬伤 | 通用出库"发货"分支不校验 quality_status，而备料出库已用 QualityStatusNotIn("不合格","待退") 拦截(:131/163)。→ 不合格/待退品可经通用出库流向客户。 |
| S2 | outbound.go:32-34 | P1 | 职责分离未落实：operator/reviewer 为自由文本，无"审核人≠录入人"及独立审批流强制。 |
| S3 | event_log.go:27-37 | P2 | 审计留痕弱：仅 operator/time/desc/payload，无操作前后值快照；且 event_log 为普通可变表，无防篡改/追加锁。 |
| S4 | （全仓无对账命中） | P2 | 三端无对账/真源机制：WMS 库存为事实主源，但无 MES↔WMS 一致性校验任务。 |
| S5 | material.go:28 | P2 | 双单位缺失：仅单 unit 字段，无基本单位+辅助单位+换算率。 |
| S6* | inbound.go:239-243 | P2(待确认) | "电气件 SN 必手填，缺录报错"——需确认是否业务要求：供应商 SN 不可系统编造，自动生成会破坏追溯；记忆中的"成品SN兜底"针对成品而非入库电气件，二者不同，agent 可能误并。 |
| S7* | inventory.go:66-70 / stock.go:769 | P2(待确认) | 库位唯一约束待确认：zones 表已是货位主数据，但 shelf/layer/position 全 Optional 手填、无 DB 唯一约束；stock.go:769 注释"不引入货位"与 inventory.go"四级贯通"矛盾，需对齐口径。 |
| S8 | workpiece.go:313 | P2 | 完工降级绕过齐套：WMS 不可达时仅记日志不阻塞完工，可能未校验齐套即回流。 |
| S9 | outbound 扣减逻辑 | P2 | FIFO 未强制：按请求 batchNo 扣减，无先进先出规则（仅不违反）。 |
| S10 | 工位端 bind.go | P2 | 条码校验弱：扫入层无长度/格式/Checksum/重复扫码去抖。 |
| S11 | （WIP 跨系统） | P2 | 0/13 虚拟工位 WIP 依赖 MES workpiece 状态基本合规，建议补跨系统 WIP 对账。 |
明确合规项（给信心）：负库存原子拦截(:126/452 + WHERE quantity>=qty)；SN 全局唯一(入库查重+部分唯一索引)；RBAC 显式父子无 startsWith 推断；admin 锁死；齐套强校验(workpiece_bind.go:187/236)；过程检 needCheck 服务端强校验；不良品隔离与处置(inspection.go:543-586)；入库检必填检测单号;拧紧记录审核签字+留痕。
三、性能 / 并发 / 稳健性（工程质量视角）
| 编号 | 文件:行 | 严重度 | 问题 |
|---|---|---|---|
| R1 | wmsclient/client.go:149,152 | P0(会丢数据) | post/putJSON 只判 StatusCode>=300、不解析 body.code；而 get(:122) 判了。→ FinishedInbound/CreateReturnOrder 即便 WMS 业务拒绝也返回 nil，库存未入却误标完成（与 U1 同源）。 |
| R2 | return_order.go:96-135 | P0(会丢数据) | 退库收货确认多步写无事务 + 无幂等/重复确认防护：中间失败留孤儿记录；重复调用会重复加库存（超加）。 |
| R3 | workpiece.go:133-206 | P0(会丢数据) | ReportProcess 无事务：applyBinds→Create→循环 writeStepData→Update，任一中间失败留脏数据；:198-199 _, _ = ...Save(ctx) 吞错。 |
| R4 | inspection.go（多步写） | P0(会丢数据) | 质检多步写未发现事务包裹（仅 line.go 用 Tx），同理脏数据风险。 |
| R5 | outbound.go:324 / 导出581 | P1 | 出库列表 N+1：循环内 OutboundDetail.Query() 逐单查，大列表放大延迟。 |
| R6 | inbound.go:247 | P1 | SN 查重吞错 exists, _ := ...Exist：DB 异常时跳过去重，可能重复入库。 |
| R7 | auth.go:74 | P1 | 工位登出 go func(){ _,_,_ = ctx.Mes.Post(logout) } 错误丢弃 + 无 ctx 超时。 |
| R8 | outbound.go:254-255 等多处 | P1 | 分页参数未 clamp：atoi 仅给默认 20、无上限，超大 pageSize 有 OOM 风险。 |
| R9 | sse.go:19 | P2 | closed map 声明未用（死代码）。 |
| R10 | dashboardService.ts:188 / return_order.go:47 | P2 | 错误吞没：单条 SSE 事件解析失败静默；dup, _ := 丢弃。 |
| R11 | jwt.go:116 | P2 | 注释误导"写死 token"，实为 ctx.Config.Internal.Token（配置项，合规）。 |
| R12 | sse.go / dashboardService.ts:193/199 | P2 | SSE 无服务端心跳(:comment)，代理 60s 空闲会断；客户端掉线只降级轮询、不再重连 SSE。 |
明确干净项（给信心）：WMS 入库/出库/质检/盘点/物料均用 committed+defer Rollback 正确事务；出库扣减 Update().Where(ID,QuantityGTE(qty)).AddQuantity(-qty) 原子防超卖，设计良好；WS SQLite busy_timeout(10000)+WAL+SetMaxOpenConns(1) 规避 BUSY；所有 HTTP 客户端(agv 15s/mesclient 5-6s/ws mes 10s)均设 Timeout 并复用连接；Redis 走 go-zero 池；前端 fetch 用 query.Encode()/url.QueryEscape 编码；WMS embed 无 0 字节文件；WS store 启动 migrateUsersRole/migrateTorqueStep 自检补列缓解 ent 陷阱。
四、业务闭环复审查（对照《问题记录.md》《临时.md》）
- B1（U1 同源）P0：跨服务错误静默吞没 → MES→WMS 回流闭环静默断链，工件误标完成（workpiece.go:328 FinishedInbound）。
- B2 P0：工位终端
mes.Client.do(:71) 只查 HTTP 状态，非 JS 客户端调用会裸漏（report.go:111/168、workpiece.go:130/174 已用mesRespCode兜底，但do本身不解析）。 - B3（U2 同源）P0：退库单
return_order.goManageMode 硬编码1、QualityStatus 硬编码"合格"、无order_material_ledger回写 → 电气件错存批次、质量态造假、台账不回减。 - B4 P1：看板
dashboard.go:443-445Result=="NG"仍v.Status="alarm"→ 违反 D4"报喜不报忧"（前端已中性化，但 SSE 数据源仍下发 alarm 语义，根因未清）。 - C1 P0(陷阱)：ent
Schema.Create只建新表、不给存量表加列；现有applyColumnPatches幂等补列存在，但任何新增 schema 字段若漏登记 → 运行 500。建议加启动自检（schema 字段数 vs 实际列数）。 - 未落地方案项：2026-09-16《临时.md》第十四节 A–O 中"出库整块/图号全链路/检验跳转入库带检测单号/批次号规则/四级联动+推荐/备料完成时间/半成品成品字段/过程完工检验/MES BOM/步骤附件/自动排产/跨天WIP/工单绩效/拧紧清理/三端help"在日志里仍是"方案"态，需确认另一 AI 是否已落地。
五、统一问题清单（去重 + 优先级）
去重后共 23 项（U 编号）。P0=业务断链/数据错乱/丢数据；P1=口径/显示/性能/稳健；P2=增强/卫生。
| U | 视角 | 文件:行 | 严重度 | 一句话问题 | 修复方向 |
|---|---|---|---|---|---|
| U1 | 闭环/稳健 | wmsclient/client.go:149,152 | P0 | 跨服务错误只判HTTP状态不解析 body.code → 静默吞错、库存未入误标完成 | post/putJSON 解析 body.code≠0 即返错 |
| U2 | 业务/稳健 | return_order.go:96-135,116-129 | P0 | 退库单无事务+无幂等+ManageMode/质量态硬编码+无台账回写 → 超加/错存/造假 | Tx包裹+状态校验+按物料模式分支+回写 ledger |
| U3 | 稳健 | workpiece.go:133-206 | P0 | 报工无事务+_,_=Save吞错 → 脏数据/丢数据 |
Tx 包裹+判错 |
| U4 | 稳健 | inspection.go | P0 | 质检多步写无事务 → 脏数据 | 确认并加 Tx |
| U5 | 行业 | outbound.go:439/476 | P0 | 通用出库"发货"不校验质量态 → 不合格品流向客户 | deliver 复用备料同等的 quality_status 拦截 |
| U6 | 业务 | outbound.go:102/119/162 | P1 | 备料出库硬编码 ManageMode=1 只查批次 → 电气件走不通 | 按物料 manage_mode 切 SN/批次分支 |
| U7 | 闭环 | dashboard.go:443-445 | P1 | 看板 NG 仍下发 alarm → 违反报喜不报忧 | SSE 不再下发 alarm，预警中心单独承载 |
| U8 | 稳健 | outbound.go:324/581 | P1 | 出库列表 N+1 → 大列表慢 | 一次性 WithDetails / 批量 IN |
| U9 | 稳健 | inbound.go:247 | P1 | SN 查重吞错 → 可能重复入库 | 判 err |
| U10 | 稳健 | auth.go:74 | P1 | 工位登出吞错+无超时 | 带 ctx 超时+记日志 |
| U11 | 稳健 | outbound.go:254-255 | P1 | 分页未 clamp → OOM 风险 | clamp(pageSize,1,200) |
| U12 | 行业 | outbound.go:32-34 | P1 | 职责分离未落实（reviewer 自由文本） | 服务端强制 reviewer≠operator 且具审核权限 |
| U13 | 陷阱 | applyColumnPatches | P0(陷阱) | 新增 schema 字段漏登记补列 → 500 | 加列必登记 + 启动自检字段/列数 |
| U14* | 行业 | inbound.go:239-243 | P2(待确认) | 电气件 SN 必手填——需确认是否业务要求（供应商SN不可编造） | 成品SN兜底已存在，勿误改电气件 |
| U15 | 行业 | material.go:28 | P2 | 双单位缺失 | 增 base_unit/aux_unit+换算率 |
| U16 | 行业 | event_log.go:27-37 | P2 | 审计留痕无前后值、可改 | 记 before/after + 不可改删策略 |
| U17 | 行业 | （无对账） | P2 | 三端无对账机制 | 明确 WMS 为主源 + 定期对账接口 |
| U18* | 行业 | inventory.go:66-70/stock.go:769 | P2(待确认) | 库位唯一约束/注释矛盾 | zones 已是货位主数据，补 DB 唯一约束并统一口径 |
| U19 | 行业 | workpiece.go:313 | P2 | 完工降级绕过齐套 | 降级置工单"待复核"挂起 |
| U20 | 行业 | outbound 扣减 | P2 | FIFO 未强制 | 默认按 production_date/批升序选批 |
| U21 | 行业 | 工位 bind.go | P2 | 条码校验弱 | 扫入层加正则+重复去抖 |
| U22 | 稳健 | sse.go/dashboardService.ts | P2 | SSE 无心跳/客户端不重连 | 服务端心跳+客户端退避重连 |
| U23 | 卫生 | sse.go:19/return_order.go:47/dashboardService.ts:188 | P2 | 死代码/吞错/注释误导 | 清理 |
| U24 | 稳健(遗留) | MES go:embed | P1(遗留待重验) | 此前 flagged：MES 116 资源 28 个 0 字节内嵌 → 页面空白风险；本轮 WMS embed 已确认干净，MES 端需重验当前构建产物 | 重新构建覆盖校验 0 字节 |
| U25 | 协调风险 | inbound_order 四级字段 | P1(协调) | 我此前已加 shelf/layer/position 并重生成 ent、改 inbound.go 落库，但前端联动未接 + 存量库未补列；若另一 AI 也在改同一处会冲突 | 与另一 AI 对齐归属，避免重复改动 |
六、已验证合规（信心项）
负库存原子拦截、SN 全局唯一、RBAC 显式父子+admin 锁死、齐套强校验、过程检 needCheck、不良品隔离、入库检必填检测单号、拧紧审核留痕、WMS 核心事务正确、出库扣减原子防超卖、WS SQLite WAL 抗 BUSY、HTTP 客户端均设超时、前端参数编码、WMS embed 无 0 字节。
七、建议执行顺序（按"会丢数据 > 业务断链 > 行业硬伤 > 性能稳健"）
- U1 + U2 + U3 + U4（4 个 P0，都"会丢数据/静默断链"）→ 最高优先，且彼此独立可并行。
- U5（不合格品流向客户，行业硬伤）+ U13（ent 补列自检，防上线 500）。
- U6/U7/U12（业务口径+看板语义+职责分离）。
- U8~U11/U22（性能稳健 N+1/分页/超时/SSE）。
- U14~U21/U23（行业增强 + 待确认项先向业务对齐再动手）。
- U24/U25（遗留构建风险 + 与另一 AI 的改动协调）。
结论：客户的需求仍未全部改完。最危险的是 U1（跨服务错误静默吞没）——系统显示成功、实际数据断链，客户验不出但账迟早对不上；其次是 U2（退库单错存/造假/超加）、U5（不合格品流向客户）、U3/U4（报工/质检无事务丢数据）。