文睿 张 696e90893b fix: 主数据编辑的两类静默失败 ... UPDATE 漏列： - code_rules 的 SET 补上 category_id。此前改分类提示"保存成功"但不落库， 是唯一用户可达的活缺陷（同页的分类下拉没有 disabled，且规则只能改不能删， 没有"删了重建"这条退路） - code_rules 有 uk_code_rules_org_category，补列后改到已占用的分类会撞唯一键， 新建与更新统一翻成中文的 ErrDuplicateCodeRule - 分类/单位/仓库/库位/伙伴的编码定为不可变：分类编码是编码规则前缀的来源 （init.sql 的种子数据直接取 material_categories.code），伙伴编码是对外业务 编号，改掉会让历史数据脱节且查不回来。service 的 Update* 不再要求编码非空 ——原先是"必须传、传了却被丢弃"；新建侧的必填校验保留 - 顺带补齐两处同款漏网：organization.go 的 code 与 partner.go 的 partner_code （前者 service 本就不校验编码，自洽，无需改） 记录不存在时的静默成功： - DSN 开启 clientFoundRows，让 RowsAffected 返回"匹配"行数而非"实际改变"行数。 否则"编辑时一个字段都没改"和"记录不存在"都返回 0，无法区分，直接加检查会把 正常保存误判成记录不存在（真 MySQL 8.0 实测） - 新增 repository.execExpectingRow，7 个 Update* 影响 0 行时返回 ErrRecordNotFound； 伙伴走事务内的 SELECT ... FOR UPDATE，只需翻译 sql.ErrNoRows - 既有 4 处 RowsAffected 用法逐处核对过，均不受该 flag 影响 测试：补 6 个 Update* 的存在性检查、编码必填约束的两端、唯一键翻译、DSN 拼接； 全部做过变异验证（抽掉实现后对应测试确实变红）。		2026-09-21 17:26:53 +08:00
..
admin_master_test.go	fix: 主数据编辑的两类静默失败	2026-09-21 17:26:53 +08:00
admin_master.go	fix: 主数据编辑的两类静默失败	2026-09-21 17:26:53 +08:00
application.go	修改一致性问题	2026-09-21 14:13:30 +08:00
auth_test.go	拆分主数据和仓库数据	2026-09-16 16:29:04 +08:00
auth.go	restore lost frontend and backend changes	2026-09-16 23:30:25 +08:00
errors.go	完善库存流水	2026-09-20 14:29:41 +08:00
inbound_test.go	库存，入库，出库相关问题修改	2026-09-20 10:31:28 +08:00
inbound.go	完善库存流水	2026-09-20 14:29:41 +08:00
material_log_test.go	修改一致性问题	2026-09-21 14:13:30 +08:00
material_log.go	修改一致性问题	2026-09-21 14:13:30 +08:00
material_test.go	feat: 实现物料编码按分类规则自动生成、手工修改及并发安全的流水号管理	2026-09-20 16:48:06 +08:00
material.go	feat: 实现物料编码按分类规则自动生成、手工修改及并发安全的流水号管理	2026-09-20 16:48:06 +08:00
outbound.go	完善库存流水	2026-09-20 14:29:41 +08:00
stock_test.go	完善库存流水	2026-09-20 14:29:41 +08:00
stock.go	fix: 库存列表分类筛选失效，后端补上 category 参数	2026-09-21 16:19:18 +08:00