新版本bug反馈 7.15 ¶

问题1：
状态：已修复 验收通过
修复说明：根因是 XY10 将 SkillSchemeConf/SkillConf/BuffConf 拆到客户端 tower.json，服务端金宠迁移只同步了 config.json，漏掉 160 条金宠技能方案；同时服务端战斗宠物载荷只使用持久化 passiveSkillConfIds，没有按宠物星级和全队装备赐福组数动态派生第4觉醒技能。现已按红宠既有方式从客户端 tower.json 原样同步 160 条 SkillSchemeConf，并同步 QuenchAdditionConf；新增与客户端一致的赐福组计数和非持久化觉醒技能派生，统一接入武将面板属性、角色摘要及 battle-worker 战斗宠物载荷。配置逐条一致性、宠物域、角色属性、battle-worker 分片加载及 race 测试通过。
现象：金色宠物：黄金章鱼 赤兔马 玄翎鹤 食梦貘 四只宠物被动加成不生效 被动3被动4加成不显示在面板
预期：所有金色宠物主动被动都正常生效 且被动3被动4加成凸显在上阵武将面板上
截图：

问题2：
状态：已修复 验收通过
测试服账号：rty520520 ID：100216517 时间：7.15 0:02
现象：宠物点击重生后无反应 无法正常重生
预期：宠物点击重生后可成功重生 重生后宠物等级 精炼归零 归还本宠物升级消耗的全部成长脆饼 和本宠物总共淬炼消耗的50％幻彩灵果
截图：

问题3：
测试服账号：rty520520 ID：100216517 时间：7.15 0:07
状态：已修复 验收通过
现象：所有宠物精炼词条加成百分比都变成了+％0
预期：所有颜色的精炼词条都有对应的加成百分比
截图：

问题4：
测试服账号：rty520520 ID：100216517 时间：7.15 0:09
状态：已修复 验收通过
现象：金色宠物达到3星后无法解锁精炼共鸣 达到5星后无法解锁赐福共鸣
预期：达到对应星级后正常解锁精炼共鸣和赐福共鸣
截图：

问题5：
状态：已修复 验收通过
现象：游戏内道具：基因本源液 基因溶剂 鎏金蛋 鎏金蛋碎片 龙凰本源壳 黄金章鱼碎片 赤兔马碎片 玄翎鹤碎片 食梦貘碎片 无法发放
预期：GM后台可以正常发放基因本源液 基因溶剂 鎏金蛋 鎏金蛋碎片 龙凰本源壳 黄金章鱼碎片 赤兔马碎片 玄翎鹤碎片 食梦貘碎片 可正常做成礼包售卖
截图：

问题6：
状态：已修复（本轮按要求不处理）
预期：删除游戏内绿茵争锋内活动：绿茵对决 绿茵夺彩 赛场补给 累计充值四个活动UI 确保删除ui后 达成活动内对应任务不会发放奖励
截图：

问题7-1：
状态：已修复，待更新客户端
备注：还是和以前一样

预期：游戏内选区改为和当前正式服一样
测试服：

问题7-2：
状态：已修复（本轮按要求不处理）
备注：黑市内ui还在 只是兑换不成功
image-2026-07-15T10-59-07-335Z.png)
预期：黑市神秘商店内 金鱼：丹心公 丹心母 巨灵 三条金鱼从神秘商店内删除
截图：

问题8:
状态：已修复 验收通过
现象：游戏内金色宠物使用龙凰本源壳转换 无法成功转换 显示仅红色宠物可转换
预期：使用龙凰本源壳可正常把金色宠物转换成为另外一个金色宠物 等级精炼等都会跟随转换
截图：

问题9：
状态：已修复（验收通过）
根因：客户端运行时 configc.bin 的 ItemConf.37021/37022 仍占用旧红宠条目，无法形成“碎片 params=[50,37022] → FragmentSynthesisConf.37022”的合成合同；服务端旧链也无法按该合同完成合成。
修复：同步客户端运行时与服务端双配置镜像：37021=鎏金蛋碎片、37022=鎏金蛋，保留50:1合成表；复用 item_synthetic 现有合成/保存/奖励链。为消除旧红宠ID冲突，同时将随机红宠礼包迁为 type58 直接发放宠物601–604。
验证：客户端二进制解码合同、服务端双镜像、50碎片合成1蛋、旧红宠礼包真实配置兼容及 race 测试通过；图标资源存在。历史日志不含截图时间窗，根因由确定性配置与协议回归锁定。
现象：使用鎏金蛋碎片合成鎏金蛋点击合成无反应 无法正常合成
预期：使用50个鎏金蛋碎片可以合成一个鎏金蛋
截图：

问题10：
状态：已修复 验收通过
金色宠物升星碎片消耗梯度：按升星前的当前原始星级计算，当前0–19星升下一星消耗4个碎片，当前20–39星消耗8个，当前40–59星消耗12个，当前60–79星消耗16个，当前80–99星消耗20个，当前100–104星消耗24个；当前105星已满星，不再消耗碎片。单只金宠从当前0星升至满星（105星）共需1320个碎片。

截图：

问题11：
测试服账号： facaizzz UID:100316514 时间7.15 1:59
状态：已修复 验收通过
现象：合成的一星宠物 上阵后就会变成满星 且无法升星
预期：是几星就是几星 上阵后不会变化 且可以正常消耗碎片升星
截图：

问题12：
状态：已修复 验收通过
现象：刚合成的金宠物主动被动全是满级
预期：刚合成的初始金色宠物主动被动应该是初始状态
截图：

问题13：
状态：已修复 验收通过
现象：金色宠物天赋点击重构无反应
预期：类似四圣升阶 具体规则如下：
咸鱼之王金宠天赋重构 + 突破系统完整规则
一、系统解锁前提
仅金色（鎏金）品质宠物可解锁天赋重构系统，红宠及以下品质无该养成模块。
二、重构基础规则

1. 消耗与收益
   消耗道具：基因溶剂
   单次重构固定基础攻击、生命增量，同时随机触发倍率放大提升属性
   重构存在成功 / 失败判定，失败则本次重构不生效、道具消耗
2. 属性倍率概率表
   提升倍率 触发概率
   1 倍 30%
   2 倍 20%
   3 倍 20%
   5 倍 15%
   10 倍 10%
   20 倍 5%
3. 各阶重构成功率明细
   当前阶数 重构成功率
   0 阶 100%
   1 阶 80%
   2 阶 60%
   3 阶 40%
   4 阶 20%
   5 阶 80%
   6 阶 60%
   7 阶 40%
   8 阶 20%
   9 阶 15%
   10 阶 80%
   11 阶 60%
   12 阶 40%
   13 阶 20%
   14 阶 15%
   15 阶 60%
   16 阶 40%
   17 阶 20%
   18 阶 15%
   19 阶 10%
   20 阶 60%
   21 阶 40%
   22 阶 20%
   23 阶 15%
   24 阶 10%
   截图：

问题14：
状态：已修复 验收通过
现象：武将孙策被动3 进入战斗后后又加成一次 （排查一下赵云黄月英被动3是否进场又加了一次）
预期：确保孙策，赵云，黄月英被动3 觉醒加成到面板后 进入战斗后不会二次加成
截图：

问题15：
状态：已修复（验收通过）
根因：客户端运行时 ItemConf.37022 还是旧红宠条目，缺少选择包参数 [2,218]，点击使用后无法从 PackConf.218 构造四只金宠选项，最终显示空奖励。
修复：将运行时37022同步为鎏金蛋选择包并接入既有 NewItemChooseDialog；服务端复用 item_openpack、PackConf.218 type58成宠与 RoleStore 原子变更链，按选择创建初始金宠并扣除鎏金蛋。
验证：客户端四项列表配置、701–704逐项选择、初始等级/星级/天赋、扣蛋、非法索引不变更、满栏保护、并发原子性以及旧红宠礼包兼容回归通过。
现象：道具鎏金蛋 点击使用 选择宠物后打开为空
预期：玩家选择宠物后 会获取一个初始状态的金宠一个
截图：

问题16：
状态：已修复 验收通过
现象：宠物精炼内 点击精炼方案 切换别的精炼方案切换不过去 会自动调回到方案1
预期：点击切换别的精炼方案可以正常切换 且当前方案内的精炼立即生效 加成到武将
截图：

问题17：
状态：已修复（验收通过）
根因：服务端宠物总属性与武将面板计算遗漏 PetStarConf 当前星级的累计 starAttribute/starSpecialAttribute，客户端配置与升星状态本身正确。
修复：复用宠物配置加载和武将加成链，将当前金宠星级的攻击、生命、防御、速度及特殊比例属性统一接入宠物战斗属性、战力和武将面板计算。
验证：金宠星级配置解析、宠物战斗/战力及武将面板回归测试通过，rolepetx race 测试通过。
现象：四只宠物升级星级给的血量攻击和特殊属性词条加成不生效 不加到武将面板
预期：四只金色宠物每次升级加成的队友血量攻击特殊属性正常正常生效 加成到武将面板上
截图:

问题18：
状态：已修复（验收通过）
根因：客户端会发送 pet_convertpiece，但服务端此前完全缺少该命令的路由、处理器和宠物域业务，未注册请求落入空处理器，因此点击后无任何状态变化。
修复：补齐现有宠物域中的兑换协议，按客户端既有公式返还“基础碎片 + 已消耗升星碎片”，并复用角色锁、物品奖励、宠物保存和删除槽位 null 同步机制；拒绝当前、异种、上阵、锁定、过期位置及重复宠物。
验证：领域、协议注册、WebSocket 桥接、保存失败回滚、并发双击和 race 回归测试通过。
现象：宠物转化成宠物碎片 点击兑换无反应 无法成功转化
预期：宠物可以转换成对应宠物碎片
截图：

问题19：
状态：已修复（验收通过）
根因：客户端会发送 pet_upgradetalent，但服务端此前没有注册该协议；未注册命令返回空对象，客户端把缺失的 code 当作成功，因而只播放“突破成功”动画，实际没有升阶、扣除基因本源液或持久化。
修复：在现有宠物域补齐天赋突破协议，严格校验当前重构上限、星级天赋上限和唯一下一阶，扣除当前阶 orderCost 后更新 talentId 与技能并统一保存；接入角色操作锁及武将面板刷新，保存失败完整回滚宠物、资源和战力版本。
验证：正常突破、资源扣除、技能刷新、无效请求、保存失败重试/缓存回滚、并发双击、重生返还、WebSocket 桥接与 race 测试通过。
现象：宠物天赋重构到突破的时候使用基因本源液无法成功突破 显示成功 但是实际没有突破成功也没扣除资源
预期：点击突破后可以成功突破 并扣除对应基因本源液
截图：

问题20：
状态：已修复 验收通过
根因：服务端把红色精炼孔数量 redQuenchCount 直接写成 quenchGroupCnt，导致一个红孔就算一套；客户端共鸣高亮又只按 attrId 汇总，不区分上、下词条位置。截图角色实际5个红孔，正确只有下词条“对辅助增伤”1套。
修复：新增服务端唯一精炼套装算法，仅统计红色孔的前两条属性，按“词条位置 + 属性ID”跨孔配对，同组合出现至少两次计一套；精炼、确认、切换方案和历史数据读取统一重算。客户端高亮同步改为位置化键，上下交叉不再成套，HP和异常第三词条不参与。
验证：单红孔、同位置配对、上下交叉、上下各一对、非红/无效属性/异常第三词条、三次重复、历史方案、受控精炼写回及响应同步测试通过；截图错误矩阵计算为1，正确矩阵计算为4。
现象：宠物精炼套装计算规则不对 现在是有一个孔位是红就算是一个套装
预期：例：共有8个孔位 每个孔位出红会有上下两个词条 随机两个孔位上面词条相同或者下面词条相同就算一个套装 孔位1上词条和孔位2下词条相同则不算 例如截图2
截图1：我们的：
截图2:正确的：

问题21：
状态：已重新修复，验收通过
备注：游戏内无变化
根因：xy10官源首次新增金宠赐福共鸣时，在 EquipmentModule.getBlessGroupCnt() 复制了一套“同一属性横跨四件装备”的统计；它与官源既有 RoleDataView.heroEBuffMap 的“四部位赐福来源红淬数取最小值”口径不一致。弹窗完全在客户端本地计算且不请求服务端，因此截图角色主页5名武将各+5、总计25时，共鸣页仍显示13；服务端实际金宠觉醒技能也复制了错误口径。
修复：客户端删除xy10新增的重复统计，直接汇总官源既有 ROLE.heroEBuffMap；服务端 BlessGroupCount 同样复用既有权威 BuildHeroEBuffMap，统一主页、武将面板、共鸣弹窗和实际战斗宠物觉醒技能。
验证：异属性四完整部位、五名上阵武将每部位5红总计25、缺部位、非上阵武将测试通过；客户端脚本语法、服务端宠物/赐福/有效技能相关包及根包编译测试通过。角色100316514只读数据按权威算法复算为25，与截图5×5一致。
现象：宠物赐福共鸣内算法不正确 主页显示赐福总数量5*5＝25 赐福共鸣内上阵咸将赐福总数量数量显示13
预期：宠物内赐福总数量应跟主页赐福数量一致
截图：

问题22：
状态：已修复，验收通过
备注：依然没有解锁 新增预期：使用凤凰本源蛋转换宠物达到对应等级后也正常发放头像框 名牌 工牌 皮肤
根因：客户端官源及 PetStarConf 配置完整，但服务端金宠升星只更新 pet.starId 和技能，没有读取并发放里程碑配置中的 avatarFrame/card/badge/masterSkin；珍宝阁服务端对个性名片的所有权判断还漏查官源使用的 dress[2].storage。因此金宠达到对应星级后，客户端仍正确判定为未拥有。
修复：服务端升星按下一星配置幂等发放头像框、个性名片、工牌和阿咸皮肤，并与宠物星级及碎片扣除同一次原子持久化、在升星响应中同步外观字段；补齐名片 dress[2].storage 所有权识别。客户端代码和配置不修改；按确认范围不处理历史角色。
验证：四类配置奖励发放、完整外观map持久化、升星响应同步、名片/头像框珍宝阁所有权测试通过；服务端全量 go test ./...、客户端问题21脚本语法及 git diff --check 通过。
现象：四只金宠物达到对应星级后珍宝阁内改宠物对应的头像框 名牌 工牌 皮肤没解锁
预期：每个金宠物达到对应星级会解锁对应的头像框 名牌 工牌 皮肤 可以正常佩戴
截图：

问题23：
状态：已修复（客户端配置热更 22688） 验收通过
现象：端午悬赏活动内没有任务栏
预期：同步正式服时恢复任务栏 显示玩家原本的任务进度 不会重置
截图：测试服：
正式服：

修复记录：客户端 MissionConf 曾被 2026 年活动 2606191 的 100 条任务覆盖，导致 2025 年活动 2505301 过滤结果为空。已从历史正确版本恢复 2505301 的任务 ID 1-100（五类各 20 条，奖励 5241/5242），服务端原 activityRecord.common.2505301 进度及领取记录保持不变。专项配置测试通过，CDN 22688 文件哈希与本地一致。

问题24：
状态：已修复（配置热更已发布，服务端空存储兼容待重新部署验证）
预期：
1：游戏内:天宫'冠军 血量+3.0百分之 攻击+3.0勋章
天宫'冠军改为：八圣王
登陆「黄金天宫」并最终获得冠军改为：同时拥有8个50阶四圣
勋章获取方式调整为： 一个游戏角色同时拥有8个50阶四圣 自动激活该勋章
截图：
2：团体赛'冠军 血量+3.0百分之 攻击+3.0勋章
团体赛'冠军改为：12圣王
参加【团体巅峰赛】比赛并最终获得冠军改为：同时拥有12个50阶四圣
勋章获取方式调整为： 一个游戏角色同时拥有12个50阶四圣 自动激活该勋章
截图：
3：张角王 血量+3.0百分之 攻击+3.0勋章
勋章获取方式调整为为： 武将张角四圣等级达到50阶 自动激活该勋章
截图：
注：确保同步全服时不会导致玩家原本使用四圣转换获取的勋章消失
根因：服务端已有四圣升阶、转换、登录自愈和全服回填授勋链，但全局数量只硬编码“4个50阶→6005”，配置完全缺少8个→1016、12个→9001以及张角120达到50阶→8004；服务端勋章表还缺目标1016/8004，客户端8004属性仍为2%。
修复：复用现有 medallionx/hbx 链，为授勋规则增加可校验的 count 条件，配置4/8/12三档并追加张角规则；统计仅包含已激活且属于四圣配置的英雄，legacy/fieldized/转换/backfill统一；授予仍只增补storage，不删除旧勋章。同步客户端/服务端1016、9001、8004属性和文案，并重新生成 configc.bin、languagec.bin。测试部署发现少量旧角色的 medallionStorage 为 Mongo null，原回填会错误使用 medallionStorage.<id> 子路径；现已在回填前保留原始存储形态，null 时整字段初始化，已有 document 仍逐项增补，不覆盖旧勋章。
验证：4/7/8/11/12边界、张角49/50、inactive/非四圣过滤、运行时规则校验、重复回填、旧章保留、客户端/服务端目标配置及BON二进制解码专项普通/竞态测试通过。服务端规则使用 sync.Once，部署后必须重启；客户端无需改JS或重打APK，但需发布CDN配置热更。

问题25：
状态：已修复（待部署验证） 待盐场验证
现象：盐场内战斗如果平局算进攻方胜利
预期：盐场内平局两边都不会死亡 按照平局处理 不会出现一方死亡
根因：开战展示阶段预写了“进攻方胜利”的占位结果，超时补偿与真实战斗回调发生竞态时会先读取占位结果结算；接力战也没有处理 winner=0。生产日志中补偿结算 217 场全部落为进攻方胜，明确样本显示错误结算后约 66ms 真实结果才返回。
修复：占位战斗改为明确 pending 且不写伪胜者；缺回调/重启恢复在 worker 中重算真实战斗，actor 仅幂等提交权威三态结果；worker/actor 拥塞保留去重并重试，失效任务自动释放；平局双方保持 idle，不记击杀、死亡、复活或积分，接力构建失败也安全判平。
验证：单人平局、右方胜、缺回调恢复、重启恢复、actor/worker 拥塞、stale 快照、接力平局及构建失败定向测试与 go test -race 均通过；客户端现有平局协议兼容，无需改客户端。

问题25：
状态：已修复（待部署验证） 待盐场验证
现象：盐场内俱乐部大本营被推后排名是按照战力进行排名
预期：盐场内俱乐部大本营被推的俱乐部排名应按照大本营被推时间排名 先被推的排名低 后被推的排名高
根因：服务端仅在淘汰俱乐部结算积分大于 0 时写 outTime；零分淘汰后积分被清零且 outTime=0，客户端和最终结算只能回退按战力排序。生产日志 95 次淘汰中有 62 次零分淘汰缺失该字段。
修复：俱乐部首次淘汰时无条件记录 outTime，重复淘汰不覆盖；同秒淘汰在快照锁内生成单调时间，保证后淘汰者排名更高；继续复用客户端与服务端已有排序，不改客户端。
验证：零分淘汰、通知 delta、重复淘汰、同秒顺序、低战力后淘汰排名更高及正积分冻结回归测试通过，相关竞态测试通过。

问题26：
正式服账号：facaizzz ID：100316514
状态：已修复（待部署验证） 待周一验证
现象：俱乐部赛车内 每日排行奖励不发放 以至于没有最强车手积分 最强车手榜排名不对
预期：确保俱乐部赛车每日排行奖励正常发放
截图：
根因：角色在 00:00 到 02:00 之间登录或查看页面时，服务端会把前一日 dailyScore 转存到 dailySettledScore 并清零当前日分；02:00 的 Mongo 候选查询却只查 dailyScore/旧 score，导致已生成午夜快照的角色被漏选。只读核对确认 100316514 在 7 月 13 日日分 51500，但 7 月 14 日结算邮件只发给另一名 3600 分角色，该角色没有对应邮件。
修复：每日结算候选增加 dailySettledScore>0 且 dailySettledAt 位于结算当天的快照分支，继续复用现有排行计算、邮件发放和 settlementUnix+roleId 幂等去重；保留原日分及旧字段候选兼容。
验证：00:30 提前读取并日切后，02:00 仍以 51500 分进入排行；午夜快照查询窗口、原前一日窗口、runtime 排行及竞态测试通过。客户端仅展示服务端榜单且配置一致，无需改客户端。

问题27：
状态：已修复（待部署验证） 验收通过
现象：客厅珍宝阁内 4个宠物的阿咸皮肤无法正常穿戴 显示皮肤穿戴失败
预期：四个宠物的阿咸皮肤都可以正常穿戴
截图：
根因：客户端按官源协议发送 lordskin_wear，7701–7704 也已存在 LordSkinConf；服务端却使用测试用静态皮肤列表校验生产请求，该列表遗漏这四个 ID，提前返回“主公皮肤ID无效”。
修复：改为从 globalConfig 的实际 LordSkinConf 校验，兼容三个配置根及 map/数组解码形态，不扩硬编码，不改变现有奖励写入和持久化合同。
验证：7701–7704、未知 ID、缺表、三个配置根和三种表形态专项普通/竞态测试通过；客户端无需修改。

问题28：
状态：已重新修复（测试服已部署，待验收）
现象：客厅珍宝阁内 4个宠物的专属铭牌和头像框无法正常激活 点击激活后还是显示可以激活状态
预期：激活后不会显示可以激活状态 可正常穿戴
截图：

根因：截图中的激活实际走官源珍宝阁 DRV2LordDecorationDrawer -> collection_activate，客户端会发送 poolType=1、id、seriesId=收藏类型。头像框与名片共用10701–10704，服务端 normal pool 却忽略 seriesId，按固定类别顺序扫描同ID，导致名片10704请求被写成头像框激活键 6:10704，10701甚至曾误写成工牌键 3:10701；正确的名片键 7:10704 始终不存在，所以客户端成功弹窗后仍显示可激活。测试服请求日志和角色Mongo状态均直接复现了该错误键。
修复：normal pool 请求携带 seriesId 时，严格按客户端指定的收藏类型校验角色已拥有对应外观并生成该类型激活键；只有旧客户端缺少 seriesId 时才保留原固定顺序遍历兼容。名片所有权继续复用现有 dressType=2 storage，不改客户端协议、配置或穿戴链。
验证：同ID头像框/名片回归用例修复前稳定得到错误的 6:10704、修复后得到 7:10704；未拥有类型拒绝和旧请求兼容均通过，收藏专项普通/竞态测试通过。服务端已部署测试服，无需重新打APK或发布客户端热更。

问题29：
状态：已修复（待部署验证） 验收通过
根因：客户端和官源 LegionBossCostConf 只有4档（费用依次为0、0、40、80），客户端按钮只做本地门禁并读取角色全局日统计 statistics.legion:boss；服务端却未复用该配置，硬编码为1次免费、最多购买20次，且同一角色的完整Boss请求没有进入现有角色操作锁。连点或并发请求可同时读取相同旧次数并分别通过，随后各自结算战斗和军团币；服务端错误的20次购买上限还允许直接绕过客户端4次限制。两张截图中的“攻打（8/4）”及战斗结算页“再次攻打（1/4）”与该并发旧快照和服务端超额放行链一致。
修复：服务端复用现有 LegionBossCostConf 作为唯一档位和费用来源，按“角色+自然日”执行4次硬上限；使用现有 roleoplock 串行同一角色的完整Boss请求并在锁内重读角色。战斗角色和Boss配置校验完成后，次数与钻石先通过字段补丁同步刷入Mongo，成功后才进入战斗、扣血和奖励链；写入失败会回滚并返回非零错误。旧的独立购买次数协议保留路由但不再修改角色或增加额度。客户端代码和配置不修改。
验证：四档费用、第五次拒绝、跨日重置、钻石不足无变更、持久化失败不进入战斗、无效战斗数据不占次数、8个并发请求最多4次成功、旧购买协议无状态变更、客户端/服务端配置镜像一致等专项测试通过；相关包 -race 通过。历史日志缺少本次连点复现的账号与时间窗，根因由截图、客户端请求/字段链、确定性服务端合同和并发回归测试锁定。
现象：俱乐部boss攻打一次后 使用连点器等第三方辅助快速点击再次攻打可每天攻打boss＞4次
预期：定死每个角色每天最多打4次俱乐部boss 不管怎样都不可以多打
截图：

问题30：
状态：已重新修复（测试服已部署，待验收）
数值根因：四国和深海灯神共用 internal/geniex 怪物构造器。旧实现只读取怪物皮肤、技能和附加属性，遗漏官源 MonsterConf 的 baseAttk/baseHp/hpAbsCoeff/baseDefense/baseSpeed，再把 LevelCoeffConf 的关卡系数直接当作五只怪的最终属性，导致应为0.9和1.2权重的不同怪物全部使用相同攻击、生命等数值，伤害必然偏差。
数值修复：服务端现已复用十殿/官源的唯一计算语义，攻击、生命、防御、速度按 base × coeff 生成，正数 hpAbsCoeff 优先作为绝对生命；保留原有皮肤、主动技能、被动技能和附加属性，不修改客户端协议或配置。深海312001专项断言7501为0.9倍率、7503为1.2倍率，internal/geniex 普通测试及 -race 通过，独立审查通过。
免疫与伤害共同根因：真实复现 battleId 1784206862168 的服务端权威结果为胜利、3回合、964帧，但把同一份 battleData/memo 交给未加载服务端补丁的官源客户端战斗模块回放，会变成失败、15回合、1811帧并产生权威计算中不存在的“免疫伤害”。服务端独有的同心 BLOCKED 保护即使最终没有抑制技能，也会在 Record 模式额外读取并写入格挡、攻击及存活英雄属性，而客户端没有相同读取，导致后续消费 memo 整体错位。原样本主 memo 数字为693个，官源 Record 应为642个，定死为 server-only guard 污染回放序列，不是70004配置或灯神属性公式。
回放修复：所有需要下发客户端回放的录制战斗（自动模式2/7/9/13及显式 forcePlaybackRecord）在读取任何角色属性前跳过该 server-only guard；非客户端回放的3/8/32模式保留原保护。用完整真实 battleData 重新 Record 后 memosLen 从14恢复为12，纯官源客户端模块 Replay 精确得到 outputCode 3fd22304ec26fe870c0d54ee859f54fb、胜利、3回合、964帧；runner 14项专项测试通过。修复已部署测试服，仅涉及服务端 battle-worker，无需重打客户端。
现象：灯神挑战内 四国灯神和深海灯神双方会出现免疫伤害 且伤害数据不对（bug反馈7.13 问题6）
预期：灯神内不会出现免疫伤害 且伤害正常
截图：

问题31:
状态：已重新修复（测试服已部署，待验收）
测试服账号：LZBN2 ID:100089014 时间：7.16 17:41-17：45
现象：十殿内 我方武将和敌方boss会出现免疫伤害 且伤害数据不对 （bug反馈7.13 问题4）
预期：不会出现免疫伤害 且伤害数据正常
截图：

根因：与问题30为同一条确定性缺陷。十殿 mode13 同样由worker以 Record 模式生成客户端 memo，并加载客户端不存在的 server-only 同心 BLOCKED guard；guard 是否打印“抑制”日志不影响结论，因为污染发生在判定结果之前的属性读取。客户端 RequireReplay 从错位位置继续消费后，会出现权威战斗中不存在的技能、免疫和错误伤害；历史 battleId 1784195152182 的worker权威计算正常且双方技能闭包无合法70004来源，与该分叉一致。
修复与验证：mode13 已与mode9一起在任何属性读取前禁用该 guard，显式强制录制也纳入门禁；不录制给客户端的服务端战斗仍保留保护。模式2/7/9/13、显式强制录制及原3/8/32行为专项测试通过，并由问题30完整真实样本完成 Record→纯官源客户端 Replay 精确同结果闭环。服务端已部署测试服，无需重打客户端；待十殿实战验收。

问题32：
状态：已修复（CDN配置热更22689已发布，待客户端验收）
1：天宫'冠军勋章
显示的名字天宫'冠军游戏内改为：八圣王
显示的介绍：登陆「黄金天宫」并最终获得冠军改为：同时拥有8个50阶四圣
截图：
2：团体赛'冠军勋章
显示的名字团体赛'冠军改为：12圣王
显示的介绍：参加【团体巅峰赛】比赛并最终获得冠军改为：同时拥有12个50阶四圣

根因：勋章弹窗 MedalGetDialog 从 MedallionConf.name/text 取得语言键，再由客户端 LanguageConf 显示文案。勋章1016虽已在本地改过语言，但名称误写为“8圣王”；兼容勋章1007仍引用旧键 MedallionConf_*_17，该组文案未改。更关键的是22688热更发布脚本只替换了 config.json，language.json 直接沿用上一版本，线上1016及旧键17仍是“天宫·冠军/登陆黄金天宫”，因此验收必然继续显示旧文案。团体赛勋章9001的本地客户端及服务端镜像已是“12圣王/同时拥有12个50阶四圣”，但22688的 config.json 仍为旧内容，同属未发布到CDN。
修复：客户端语言1016统一改为“八圣王/同时拥有8个50阶四圣”，兼容旧展示ID1007使用的语言键17同步修改；服务端 language.json、language1.json 同步镜像。团体赛9001继续复用已有本地正确配置，不新增业务代码。同步重新生成 languagec.bin，补充客户端JSON、服务端镜像及BON二进制一致性测试。
验证：go test ./internal/medallionx -run 'TestFourSaintPlanningMedallion(ConfigAndBins|LanguageMirrors)$' -count=1 通过；三份语言JSON解析通过，languagec.bin解码文案与JSON一致。CDN 22689 已发布完整八分片，线上 config.json 与 language.json 哈希分别与本地一致；登录清单与开关返回 [22689,0,1,1,1,1]，在线抽查1016、兼容键17及9001均为目标文案。客户端无JS改动，不必重打APK。