bug反馈 06.02 ¶

问题1：
状态：验收通过
现象:安卓和ios上传完头像后 头像只显示在右下角 不会铺满整个头像
预期：上传的图片正常铺满整个头像
截图：

问题2：
状态：已修复，验收通过
备注：和问题3一样 应该是宠物加成掉了
根因补充：一区日志里 11223311/roleId=467000 多次 hero_useskin 的 oldPower/newPower 均相等，皮肤协议本身未复现战力下降；但全服日志发现 Huang7758521/roleId=548996 在 collection_exchange 兑换并激活 11904 皮肤后，服务端未立即刷新 collectionActivated 相关加成，下一次 hero_useskin 才触发权威加成视图重算，表现成“切换皮肤导致战力变化”。
修复：collection_exchange 成功且 activatedKeys 非空时，立即按 LoadRoleViewForBonus + updateBonusCacheForSingleHeroFromView + canonicalPowerOrFallback 刷新出战英雄面板与 role.power，并合并进本次 role/roleInfo 返回。
验证：一区日志 11223311 的 hero_useskin delta 均为 0；Huang7758521 非零样本前置操作为 collection_exchange；本地 go build . 通过；go test -count=1 ./internal/activityx -run 'Test.*Collection|TestExchangeCollection'、go test -count=1 ./internal/bonusviewx ./internal/gameplay/herox 通过。
复核结论：5.31 同类问题确实由在线加成视图缺少 petData 引起，退出重登能恢复也符合“在线增量重算缺字段、完整 Getrole 正常”的特征；当前源码的 LoadRoleViewForBonusWithBattleTeam 已加载 petData，并有回归测试覆盖，所以现在线上仍复现时需要优先确认环境是否已部署该版本。06.02 截图所在皮肤页还会触发收藏/三件套皮肤加成链路，不能只归因为宠物；如果某环境 collection_exchange success 后看不到 collection_exchange power refresh 日志，该环境仍可能保留旧逻辑，后续切皮肤会成为第一次权威重算点，从而看起来像“宠物/皮肤加成掉了”。
现象：切换皮肤后 当前武将战力会下降 面板数值会变化（应该是哪里的加成掉了）退出游戏再进后会恢复
预期：更换皮肤不影响战力和武将面板数值 （截图一为更换前 截图2为更换后）
截图1：
截图2：

问题3：
状态：已修复 验收通过
根因：和 5.31 问题3同源，artifact_unload/artifact_load 在线重算武将面板时使用的轻量 role view 曾缺少 petData，已穿戴宠物及宠物淬炼加成没有进入 equippedPetHeroBonus；卸下/穿回鱼灵时只刷新了部分面板，攻击、血量、战力低于原值，退出重登走完整 Getrole 后恢复。
修复：当前代码的 LoadRoleViewForBonusWithBattleTeam 已加载 petData；artifact_load/artifact_unload 现在优先用完整 Getrole 构建返回面板，并同时返回 role/roleInfo，避免客户端只刷新其中一份数据导致面板继续显示旧值。
复核验证：已重新执行 GOCACHE=/tmp/xianyu-go-build go test -count=1 ./internal/bonusviewx ./internal/gameplay/herox、GOCACHE=/tmp/xianyu-go-build go test -count=1 . -run 'TestBuildArtifactLoadResp|TestHeroUseSkin' 通过。若某环境仍复现，先查 artifact_load_diag/artifact_unload_diag 是否存在；没有这些日志或返回中缺 roleInfo，说明该环境不是当前修复版本。
现象：如截图 原本武将攻击为12.25亿 下掉鱼灵后为9.38亿 在佩戴上攻击力却是11.64亿 佩戴前后攻击力不血量战力等一致 （应该是卸载鱼灵导致某个地方加成不生效） 退出游戏再进后会恢复
预期：同样加成属性的鱼灵 卸载佩戴后战力 攻击力血量等应该还是恢复原本的状态
截图：

问题4：
状态：已修复 验收通过
现象：灯神挑战挑战后显示的战力不是当前阵容战力 而是外部主线战力
预期:布阵上场的阵容战力是多少战斗时显示的战力就是多少
截图：

根因：客户端布阵页通过 hero_calcpowerbyteam 按本次 battleTeam/lordWeaponId/petUId 计算阵容战力；战斗页直接显示 fight_startgenie 返回的 battleData.leftTeam.power。服务端 fight_startgenie 之前构造 leftTeam.team 时使用了请求里的灯神阵容，但 leftTeam.power 仍通过 GetMergedBattleRole/zhandouli 走整角色/主线 BattleTeam 口径，导致战斗页显示主线战力。
修复记录：服务端 internal/geniex/startfight.go 新增本次灯神阵容合并角色选择，优先使用 GetroleWithBonusForBattleTeamAndPet 生成的 battleTeam/武器/宠物口径角色；leftTeam.power 计算时使用请求阵容视图，不污染原始角色主线 BattleTeam。compat_ws_bridge.go 的 fight_startgenie 注入 GetMergedBattleTeamRole，和 hero_calcpowerbyteam 对齐。
验证：2026-06-04 测试服日志 roleId=151830/account=fafa 复现：布阵预览最后一次 hero_calcpowerbyteam 战力 148911195，随后 fight_startgenie battleId=1780563391823；测试库主线 power=1633272000，genieBattleTeam.1={0:102,1:101}。新增回归测试覆盖 leftTeam.power 使用请求阵容战力及 startGenie 优先使用请求阵容合并角色；GOCACHE=/tmp/xianyu-go-build go test -count=1 ./internal/geniex 通过，GOCACHE=/tmp/xianyu-go-build go test -run '^$' . 通过。
人工回归建议：部署后使用同一账号或任一主线战力明显高于灯神小阵容的账号，灯神布阵只上 1-2 个武将，记录布阵页左侧战力；点击挑战进入战斗后，战斗页左侧战力应与布阵页一致或仅有同口径刷新差异，不应跳回主线整角色战力。建议同时回归主公武器、宠物选择不为空的灯神布阵，确认布阵页战力和战斗页左侧战力仍保持同一口径。

问题5：
状态：已修复，验收通过
根因：客户端爬塔之路普通通行证领取发送 activity_battlepassrewardclaim(battlePassId)，服务端只注册了 activity_recyclewarorderrewardclaim，普通领取命令落到默认空响应，导致领取弹窗没有 reward 内容。
修复：服务端补注册 activity_battlepassrewardclaim，复用现有 BattlePassConf 领奖结算，返回 reward 和 activity.warOrderActivityInfo，并增加 roleId/battlePassId/code/rewardCount 窄日志。
验证：go test -count=1 ./entry/account/wsentry；go test -count=1 ./domains/activity/battlepass -run 'TestClaimRecycleWarOrder|TestNormalizeWarOrderActivityInfo'；go build .；git diff --check。
现象：通行证内爬塔之路奖励领取后显示为空白
预期：可以正常领取奖励 正常发放
截图：

问题6:
状态:已修复
现象:新号上线后
1:主线关卡从现在的8001
2:主公等级为4001
3:邮箱内邮件有资源
预期:1:关卡调整为从第一关开始
2:主公等级调整为1级
3:上线资源邮件删除
位置截图:

根因：上线配置 config/testing.json 仍开启 testing，总开关、autoSetLevelOnLogin、firstLoginMail 都为 true。新角色创建时 buildAuthRole -> applyTestingInitialProgress 会按测试配置把主线调到 8111、主公调到 4001；创建成功后 sendTestingFirstLoginMail 会发放测试首登资源邮件。测试服 Docker 日志 2026-06-03 08:05:49 也记录了 测试开关: 新角色初始化进度 roleId=400149584 levelId=8111 chapter=1 lordLevel=4001 hangUpStayId=811。
修复：关闭 config/testing.json 的 testing 总开关、登录自动调级和首登资源邮件；目标关卡/主公等级回到 1。首登资源奖励清单保留为以后开新区参考，但 firstLoginMail.enabled=false，不会上线自动发放。
验证：新增 TestTestingConfigFile_DisablesLaunchTestBonuses 防止上线配置再次带测试开关，并要求奖励清单保留为关闭状态下的参考列表；已执行 GOCACHE=/tmp/go-build go test ./config ./domains/account/login 与 GOCACHE=/tmp/go-build go test . -run 'TestApplyTestingInitialProgress|TestTestingTargetHangUpStayID' 通过。

问题7：
状态：已修复，待人工回归
根因：端午悬赏 2505301 客户端读取 activity.commonActivityInfo[2505301].task，服务端活动读取层映射的 5 个进度字段分别是招募 statistics.week:act:cr:cnt:1、宝箱积分 statistics.activity:open:box:point、高级捕获 statistics.artifact:advanced:lottery、盐罐领取 statistics.bottle:claim、金砖消耗 statistics.week:act:cr:cnt:12。旧逻辑里招募和金砖只更新普通统计/周活动记录，未写端午悬赏字段；高级捕获、宝箱、盐罐缺少或不完整返回 activity.commonActivityInfo，客户端只能等重新 activity_get/重登后刷新，表现为不计入或不立即刷新。
修复：服务端在招募、宝箱、金砖消耗、高级捕获、盐罐领取成功后统一写入对应端午悬赏统计字段，并在主响应中返回 activity.commonActivityInfo[2505301].task 增量，触发客户端 SyncCommonFestival 即时刷新。
验证：已补招募、宝箱、金砖、高级捕获、盐罐回归测试；已执行 GOCACHE=/tmp/xianyu-go-build go test -count=1 -run 'TestBuildConfigured(OpenPackRewards|ChoosePackRewards)|TestApplyDragonBoatBottleClaimProgress|TestRecordDiamondWeekActivitySpend' .、GOCACHE=/tmp/xianyu-go-build go test -count=1 ./internal/gameplay/herox ./internal/systemx ./internal/artifactx ./internal/planconfig ./domains/activity/read 通过。
人工回归建议：使用测试号分别执行招募、消耗金砖、金鱼竿高级捕获、领取盐罐、开宝箱；每次操作后不重登，直接切回端午悬赏页确认对应进度立即增加且达标奖励可领取。再重登一次确认进度不回退。
现象：端午消耗活动内 招募 金砖 捕获 领取罐子不计入活动 切宝箱消耗后 不会立即刷新 需要退出游戏再进才会刷新
预期：消耗金砖 招募 金鱼竿捕获正常计入活动 并可以立即刷新进度领取奖励
截图：

问题8：
状态：已修复，待人工回归
根因：普通艾草 ItemConf.5242 是随机包，params[0]=1、params[1]=90。客户端普通使用弹窗仍会调用 item_openpack 并携带默认 index=0；服务端旧 item_openpack 只要看到 index 就先走 buildConfiguredChoosePackRewards，从 PackConf.90.packShow[0] 固定取金艾草 5243，把随机包误当自选包，导致普通艾草百分百开出金艾草。
修复：服务端 buildConfiguredChoosePackRewards 增加 ItemConf.params[0] 判定，只有 2/4 自选包允许按 index 固定取奖励；0/1/3 随机包即使请求带 index=0 也走 diamondPackRewardWeight 权重池。
验证：已补 TestBuildConfiguredChoosePackRewards_RejectsRandomPackIndex，确认普通艾草随机包不会再按 packShow[0] 固定出金艾草；相关 openpack 回归测试通过。
人工回归建议：发放普通艾草 20 个，连续单开/批量开启，确认不再每次都出金艾草；抽查奖励落在配置权重池内。再用 3506/3509/3510 等自选包确认 index 选择仍正常。
现象：获取的普通艾草百分百开出金艾草
预期：按照概率开出物品
截图：

问题9：
状态：已修复，待人工回归
根因：端午兑换 ExchangeActConf.250530201~250530205 曾配置到五星鱼灵或旧兑换数量，截图中显示为 5 星鱼；普通兑换道具数量也未按策划预期放大。
修复：当前服务端和客户端配置已对齐：端午兑换鱼灵奖励 ID 为一星鱼 11151/11131/11141/11111/11121，珍珠/万能红将碎片/随机红将碎片/白玉/精铁福袋数量分别为 10/10/20/5000/60。
验证：internal/planconfig.TestPlan13DragonBoatFestivalConfigMirrors 同时校验服务端与客户端 ExchangeActConf、ArtifactConf.fishStar=1 和 10 倍数量，已执行通过。
人工回归建议：打开端午兑换页，确认 5 条鱼显示为 1 星；兑换珍珠、万能红将碎片、随机红将碎片、白玉、精铁福袋各一次，确认到账数量分别为 10、10、20、5000、60。
现象：现在兑换的所有金鱼为5星
预期：兑换的金鱼全部改为一星金鱼 珍珠 万能红将碎片 随机红将碎片 白玉 精铁福袋现有乘10倍
截图：

问题10：
状态：已修复验收通过
验证：当前服务端已注册 activity_battlepassrewardclaim，BattlePassBaseConf 存在 1/1003/1004，BattlePassConf 对应 actId 配置存在；已执行 GOCACHE=/tmp/xianyu-go-build go test -count=1 ./domains/activity/battlepass ./entry/account/wsentry 通过。
现象：通行证爬塔之路 领取奖励显示配置不存在
预期：可以正常领取奖励
截图：

问题11：
状态：已修复，待人工回归
修复：充值到账时已按功法配置阈值尺度（元*100）同步写入 statistics.legacy:charge 和 statisticsTime.legacy:charge；并补齐 legacy_claimchargereward 领取协议，按 LegacyChargeReward.privilegeReward 发放功法残卷并记录 roleLegacy.chargeClaimedMap，功法特权可按当前赛季充值额激活并领取。
人工回归建议：

1. 使用测试充值分别覆盖未达标、刚好达标、超过多档阈值三种金额，确认功法残卷特权状态即时激活。
2. 激活后领取每一档功法残卷奖励，确认背包道具到账、领取按钮变为已领取，重登后状态不回退。
3. 同一档重复点击领取，确认不会重复发奖；再补一笔充值跨到下一档，确认新档位可领取。
4. 对照 VIP 积分/累计充值显示，确认功法读取的累计充值金额和充值到账记录一致。
   现象：充值后 功法残卷特权不激活
   预期：达到对应充值要求 可以正常激活功法特权 并且可以正常领取奖励
   截图：

问题12：
状态：验收通过
现象：黑市购买物品不扣除金砖 而是珍珠
预期：正常扣除金砖
截图：

问题13：
状态：验收通过
现象：黑室内购买东西优先扣除珍珠 珍珠扣完后才扣除金砖
预期：黑市购买物品全部扣除金砖 只有神秘商店里物品才会扣除珍珠
截图：态：未处理
现象：

问题14：
状态：已修复 验收通过
修复：2026-06-03 服务端修正背包鱼灵升星扣除“选中的鱼灵+材料”，并且 heroId=-1 有背包同 ID 时不再误推断到装备位；补月华升星/分解回归测试。
现象：琴心公 琴心母 回响 惊雷 月华5条金鱼在客厅鱼缸内升级后 一级升二星 不扣除鱼灵 可以无限卡鱼
预期：升级一星就扣除一星金鱼
截图：

问题15：
状态：验收通过
现象：点击咸将塔游戏就会卡死 进不去咸将塔
预期：点击后可正常进入
截图：

问题16：
备注：测试服无问题 正式服有问题
状态：无问题，待测试环境复现
备注：当前暂按无问题处理；如测试环境可稳定复现，再按复现账号、时间点、抽奖协议和背包刷新链路继续排查。
现象：宠物扭蛋抽奖内获取的奖励 不会立即显现在背包内 需要退出再进游戏才会显示
预期：奖励抽到后会实时出现在背包内
截图：

问题17：
状态：已修复，验收通过
现象：俱乐部未开启无需审核 别人申请俱乐部也可以直接进入 无需团长副团审核
预期：俱乐部未开启无需审核 别人加入俱乐部需要通知副团长同意后才可以进入俱乐部
修复：服务端 legion_applyjoin 在俱乐部 NoApply=false 时改为写入申请队列 QueueJoinApply，不再直接加入成员；只有团长/副团通过 legion_agree 同意后才调用 ApplyJoin 加入俱乐部。
回归测试建议：关闭“无需审核”后用小号申请俱乐部，确认小号不会立即入会，团长/副团申请列表可见该申请，同意后小号才加入俱乐部。
截图：

问题18：
状态：已修复，测试服已验证，待人工回归 验收通过
现象：所有武将佩戴贾诩专属鱼龙鱼蚀骨后对战时专属加成都生效
预期：所有专属鱼只有对应专属武将佩戴 专属加成才会生效 其他武将佩戴不生效
根因：服务端战斗组包 passiveSkillLimit 只按鱼灵 ID 追加，未按 attrsLimitHero 校验佩戴武将；部分面板/战力刷新入口也沿用旧的 yujiacheng* 鱼灵取值函数，只按鱼灵 ID 计算专属属性，导致非专属武将也可能吃到专属技能或专属属性。
修复：2026-06-04 服务端统一改为 heroId + artifactId 判断专属鱼灵：战斗被动技能只在 attrsLimitHero 匹配时追加，getroleinfo、单英雄战力、队伍总战力、英雄模拟刷新优先使用 YubyidWithHero 计算专属属性；补充贾诩蚀骨专属技能、专属属性、排行面板、战力、英雄模拟回归测试。
验证：已覆盖 19 个专属属性鱼灵矩阵和 2 个专属技能鱼灵矩阵；真实测试服冒烟 artifact_exclusive_attr_matrix、artifact_exclusive_skill_matrix 通过。新增 power_consistency 冒烟用例，覆盖同一角色在个人信息、排行详情、战斗快照三处战斗力一致；修复前抓到排行详情旧战力 5000000，修复部署后真实冒烟通过，三处战力均为 830528。
人工回归建议：

1. 用贾诩佩戴龙鱼蚀骨进入战斗，确认战斗技能列表有专属技能；换成非贾诩武将佩戴同一鱼灵，确认专属技能不出现。
2. 抽查已梳理的所有专属属性鱼灵：专属武将佩戴时属性/面板生效，非专属武将佩戴时只生效通用属性，不生效专属加成。
3. 对每个抽查角色分别查看武将详情、排行详情、开战快照，确认总战力一致；切换鱼灵、重登后再次确认不回退。
4. 使用英雄模拟/升星/上下阵后再打开详情和战斗，确认专属加成仍只对目标武将生效，且战力不会因为排行缓存或战斗快照出现差异。
   截图：

问题19：
状态：已修复，验收通过
现象：使用代金卷购买礼包不计入游戏里积天好礼
预期：玩家使用代金卷购买的礼包也正常计入积天好礼
修复：2026-06-04 服务端支付发货拆分“真实充值统计”和“积天好礼计天”，chargeType=1000 仍只作为真实充值统计，非 1000 代金券订单发货成功后计入 chargeDayStreak/chargeDayLast，但不增加 VIP、累计充值、账号真实充值统计。
回归测试建议：使用代金券购买礼包后重新打开福利活动-积天好礼，确认当天 totalChargeDay 增加 1 且同日重复购买不重复加天，同时 VIP/累计充值数值不变化。
截图：

问题20：
状态：已修复，待客户端更新或热更
现象：五星专属鱼灵礼包内没有:龙鱼远见 龙鱼天公 龙鱼国色 龙鱼龙胆
预期：补齐所有专属鱼灵
根因：五星专属鱼灵自选盒相关 PackConf 只配置了旧的 16 种五星专属鱼灵，新增的 4 种专属鱼灵未进入自选列表；客户端展示同样读取本地配置，所以需要客户端配置更新或热更后才能在包内看到完整列表。
修复：已补齐服务端 config/config.json 和客户端 client/assets/config/config.json 中 PackConf.37、PackConf.59 的 diamondPackRewardWeight/packShow，现包含 20 种五星专属鱼灵：12015、12025、12035、12045、12055、12065、12075、12085、12095、12105、12115、12125、12135、12145、12155、12165、12175、12185、12195、12205；同时将 3506/3509/3510 相关道具描述更新为“20种五星专属鱼灵”。
验证：新增并执行 GOCACHE=/tmp/xianyu-go-build go test -count=1 ./internal/planconfig -run TestFiveStarExclusiveFishChoosePacksIncludeAllTwenty 通过；结构化核对服务端和客户端 PackConf.37 均为 20/20 条，PackConf.59 均为 21/21 条（珍珠 + 20 种鱼灵）。
截图：

问题21：
状态：已修复，验收通过
现象：个人头像更换后所有聊天内和俱乐部内不显示头像
预期：所有带个人头像的地方都正常显示玩家设置的头像
根因：聊天发送响应里 message.headImg 使用了固定第三方头像地址，没有读取角色当前 role.HeadImg；更换个人头像时只更新角色自身头像字段和客户端同步，未同步更新俱乐部成员缓存里的 HeadImg，导致俱乐部成员列表仍显示旧头像或空头像。
修复：聊天消息组包改为使用 role.HeadImg；role_changeheadimg 保存头像后同步更新所在俱乐部成员 HeadImg 并保存俱乐部记录，同时继续推送 role/roleInfo 头像增量。
验证：已补聊天头像响应测试和俱乐部成员头像更新测试；已执行 GOMODCACHE=/tmp/xianyu-go-mod-cache GOCACHE=/tmp/xianyu-go-build-cache go test ./domains/core/chat ./domains/legion/member ./internal/payment -run 'HeadImg|BuildSendChatResponse|ChangeHead|Voucher|Special|ChargeType|DayBuy|Card|WarOrder' -count=1 通过。
人工回归建议：

1. 上传/更换个人头像后，立刻在世界聊天、俱乐部聊天各发一条消息，确认显示新头像。
2. 打开俱乐部成员列表、申请列表、成员详情，确认自己的头像同步为新头像。
3. 退出重登后再次查看聊天和俱乐部成员头像，确认不会回退。
4. 团长/副团/普通成员各抽一个账号测试，确认权限身份不影响头像显示。
   截图：
   
   

问题22：
状态：已修复，待人工回归
现象：玩家充值代金卷后 使用代金卷买了礼包 游戏内还没解锁开口
根因：代金券购买周卡/月卡/通行证等特殊礼包时属于非 1000 真实充值类型，旧支付发货链路没有完整按特殊订单类型解析并推进对应开通/计天状态，导致礼包奖励可能到账但活动/开通状态没有按购买行为刷新。
修复：支付订单解析补齐特殊订单类型：周卡/月卡走卡类订单，通行证/回收通行证走 BattlePass 订单；发货成功后非 1000 类型会推进积天/开通相关购买日状态，但不增加 VIP、累计充值、账号真实充值统计。
验证：已补代金券周卡、通行证同日购买只计一天、跨天连续计天、断档重置领取状态等测试；已执行 GOMODCACHE=/tmp/xianyu-go-mod-cache GOCACHE=/tmp/xianyu-go-build-cache go test ./internal/payment -run 'Voucher|Special|ChargeType|DayBuy|Card|WarOrder' -count=1 通过。
人工回归建议：

1. 使用代金券购买周卡/月卡，确认对应卡权益立即开通，奖励到账，重登后仍保持开通。
2. 使用代金券购买通行证/回收通行证，确认通行证入口显示已开通且可领取付费档奖励。
3. 同一天连续使用代金券购买多个礼包，确认开通状态正确，但积天类只按一天计算。
4. 确认 VIP、真实累计充值、功法充值累计不会因为代金券订单增加。

问题23：
状态：已修复，验收通过
现象：玩具无损转换后 只转换后主动等级被动等级不跟着转换
预期：玩具使用无损转换 主动等级被动等级都会跟随一起转换
历史根因：lordweapon_exchange 原先只交换玩具等级/强化等级，未按被动技能槽位同步迁移被动技能等级；不同玩具的被动技能 ID 不同，按相同 skillId 查找会漏掉目标玩具的被动技能，表现为主动等级随转换变化、被动等级仍停留在原玩具。
本次验收不通过根因：历史修复只覆盖“当前上阵星数已解锁目标槽位”的场景。fafa1/14639 当前上阵总星数只有 30，9 号玩具已有历史被动槽 33/34 Lv11，但 1 号玩具没有对应 1/2 槽；swapLordWeaponPassiveSkillLevelsBySlot 因目标槽 nil 直接跳过，导致主动等级交换成功、被动等级仍留在 9 号玩具。当前测试服容器日志未包含本次 lordweapon_exchange 请求，但生产一区 DB 状态、截图和代码路径一致指向该根因。
修复：服务端 LordweaponExchangeFieldized 继续先补齐/归一化已解锁和历史 key 槽位；新增“按已有进度槽位补另一侧同槽位 Lv1 占位后再交换”的逻辑。只对任意一侧已存在的槽位创建对应槽位，不会因为低星数转换额外解锁第 3/4 个未存在被动槽。
验证：已补 TestLordweaponExchangeFieldized_SwapsPassiveSkillLevelsBySlot、TestLordweaponExchangeFieldized_CreatesMissingPassiveSlotsBeforeSwap、TestLordweaponExchangeFieldized_NormalizesLegacyPassiveSlotKeysBeforeSwap、TestLordweaponExchangeFieldized_CreatesCounterpartPassiveSlotsForExistingProgressBelowUnlockStars；新测试先复现失败 target passive slot1 missing，修复后已执行 GOCACHE=/tmp/go-build-cache go test ./internal/gameplay/lordweaponx -count=1 通过。
人工回归建议：

1. 准备两个玩具：A 主动/被动等级高，B 主动/被动等级低，执行无损转换后确认 B 获得 A 的主动等级和各被动槽位等级，A 变为 B 的等级。
2. 选择已解锁多个被动槽位的玩具测试，确认每个被动槽位都转换，不只转换第一个被动。
3. 对历史老号测试一次，确认被动技能 key 为旧槽位编号时也能正确转换到目标玩具对应技能 ID。
4. 对低星数老号测试：一侧玩具有历史被动槽、另一侧缺槽时，转换后已有被动等级迁移到目标玩具，但未存在的第 3/4 被动槽不会凭空创建。
5. 转换后重登，再打开玩具界面和战力相关界面，确认等级与战力不回退。
   截图：
   

问题24：
状态：已修复 验收通过
现象：关羽未佩戴灵珠冥想 但是缺显示了佩戴冥想的效果
预期：佩戴什么灵珠就生效什么灵珠 未佩戴不存在会无中生有
根因：服务端战斗队伍构造里存在关羽皮肤 10308（青龙·关羽）的历史硬编码，主战斗/竞技场/地牢入口在检测到 hero.UseSkin == 10308 时会直接把灵珠技能 1033008（冥想）加入 battleData.team[*].skill，并设置 recordFlag，绕过了“武将实际佩戴灵珠 -> pearlMap 同 ID -> skillId”的校验链。
修复：已移除 10308 皮肤自动注入 1033008 的逻辑；PK 房间战斗队伍也不再透传存档里的 hero.RecordFlag 到战斗表现，避免未佩戴灵珠时显示残留状态。当前灵珠技能只会通过 getPearlSkillID 生效：武将 pearlId > 0，且 role.pearlMap[pearlId].pearlId == hero.pearlId，且该灵珠存在正数 skillId。
全盘检查：已反查 PearlSkillPoolConf 全部技能 ID 1033007-1033017，生产 Go 代码里没有剩余硬编码引用；主要玩家战斗入口均走统一技能提取链路，怪物/首领配置技能不属于玩家灵珠佩戴规则。
验证：已补回归测试 TestBuildLeftTeam_Skin10308DoesNotGrantPearlMeditation、TestPKFightRole_BattleTeamDoesNotSurfaceUnequippedPearlState；已执行 GOCACHE=/tmp/xianyu-go-build go test -count=1 ./domains/core/competitive ./internal/gameplay/dungeonx ./internal/geniex、GOCACHE=/tmp/xianyu-go-build go test -count=1 . -run 'TestGetPearlSkillID|TestBuildLeftTeam|TestPKFightRole_BattleTeam|TestYubyidWithHero' 通过；git diff --check 通过；生产代码复扫 1033008|UseSkin == 10308|useSkin == 10308 只剩测试命中。
人工回归建议：

1. 关羽穿戴 10308 青龙·关羽皮肤，不佩戴任何灵珠，进入主线/爬塔/竞技场/地牢/PK 类战斗，确认战斗内不显示冥想效果，战斗数据技能列表不包含 1033008。
2. 同一关羽佩戴带冥想技能的灵珠，确认冥想正常显示并生效；卸下后再次进入战斗，确认冥想消失。
3. 关羽佩戴其它灵珠技能，确认只显示并生效对应灵珠技能，不出现冥想。
4. 非关羽武将分别测试未佩戴、佩戴冥想、佩戴其它灵珠，确认规则一致。
5. 切换皮肤、保存阵容、重登后重复一次，确认没有 recordFlag 或历史阵容缓存导致的残留显示。
   截图：

问题25：
状态：已修复，待验收
现象：单周活动累计开宝箱活动 任务完成后自选大奖内奖励领取无反应
预期：可以正常领取到账奖励
截图：

修复记录：
根因：累计开宝箱达标后，服务端只通过异步 activity_totalrewardnotify 推送周活动进度，item_openboxresp 主响应没有携带 activity.myTotalInfo。客户端自选大奖弹窗打开时会用 ActivityTimeModule.getWeekActRoundInfo() 计算并缓存 unclaimedRounds，+ 按钮再通过 _changeSelectionCount() 校验该缓存；如果玩家开箱达标后立刻进入弹窗，缓存仍是旧进度，导致可领取轮数为 0，点击 + 无反应。
修复：服务端 internal/activityx.UpdateWeekActivityProgressFieldized 返回本次更新后的 myTotalInfo，internal/systemx.ItemOpenBoxFieldized 在开箱主响应中同步返回 activity.myTotalInfo，并保留原有 activity_totalrewardnotify 推送。这样客户端处理 item_openboxresp 时即可同步刷新活动缓存和面板状态。
验证：测试服日志已确认 item_openboxresp 返回字段包含 activity；角色 151830 开铂金箱时活动积分正常增加，未满 6000 时可领取轮数为 0，满一整轮后可领取次数刷新正常。已执行 GOCACHE=/tmp/go-build go test ./internal/systemx、GOCACHE=/tmp/go-build go test ./internal/activityx -run TestUpdateWeekActivityProgressFieldized_ReturnsPushedTotalInfo、GOCACHE=/tmp/go-build go test . -run 'TestWeekActCompletedRounds|TestItemOpenBox'。
回归建议：使用测试角色发放足量铂金宝箱，单次开 10 个、100 个分别覆盖未满 6000、刚好/超过 6000、超过 12000 三种场景；确认累计开宝箱面板进度即时刷新，自选大奖弹窗剩余领取次数正确，+/- 可操作，领取后道具到账且 week:act:cr:cnt:2 增加；重新登录后再次确认面板轮数、剩余次数和已领取状态一致。

问题26：
状态：已修复，待部署后人工回归
现象：灯神挑战时 布阵界面和战斗界面出出现多个同一个武将 并且可以正常战斗
预期：任何战斗一个武将只能存在一个 不会出现一个武将出现多个
根因：灯神挑战按国家保存上次布阵 genieBattleTeam，客户端会直接读取该历史阵容并提交 fight_startgenie；服务端旧逻辑在 saveGenieBattlePreset 保存阵容和 buildGenieLeftTeam 构造战斗数据时，都没有按 heroId 去重，导致同一个武将 ID 可以保存在多个槽位并进入战斗。生产一区只读核查确认已有历史脏数据：13483 个带灯神记忆阵容角色中，21 个角色存在重复武将，其中黄月英 heroId=110 有 1 条重复记录。
协商修复记录：本次只做服务端代码修复，不修改客户端，不清理生产数据。服务端新增灯神阵容归一逻辑：只接受 0-4 槽位，同一 heroId 只保留第一次出现的槽位；保存 genieBattleTeam 前去重，构造 battleData.leftTeam.team 前也去重；空 battleTeam 回退主阵容时复用现有主阵容去重逻辑。这样旧客户端继续提交重复阵容时，服务端不会再保存重复，也不会让重复武将进入战斗。
验证：新增回归测试 TestSaveGenieBattlePreset_DedupesRepeatedHeroIDs 和 TestBuildGenieLeftTeam_DedupesRepeatedRequestHeroIDs，已执行 GOCACHE=/tmp/xianyu-go-build go test -count=1 ./internal/geniex 通过。
边界说明：由于本次按约定不清生产数据、不改客户端，已有生产历史脏数据在玩家部署前或登录后首次打开布阵页时仍可能先显示旧重复阵容；部署后发起灯神挑战会由服务端清洗并回包修正当前国家阵容。若要彻底消除首次布阵页旧显示，需要后续单独做生产数据清理或服务端登录下发兜底。
人工回归建议：

1. 使用存在黄月英重复历史阵容的账号，部署后直接发起灯神挑战，确认战斗界面同一 heroId 只出现一次，重复槽位被移除。
2. 挑战返回后重新打开灯神布阵页，确认当前国家 genieBattleTeam 已被服务端回包修正，同一武将不会再占多个槽位。
3. 手动构造/复现重复提交场景，例如 2=110、4=110，确认服务端日志出现 fight_startgenie: duplicate hero removed，且战斗数据只保留第一次出现的黄月英。
4. 回归正常灯神布阵：不同武将 ID 可同时上阵，例如诸葛亮 104 与黄月英 110 同队合法；同一武将不同颜色/星级/皮肤仍按同一 heroId 只允许一个。
5. 回归空阵容/默认主阵容进入灯神战斗，确认不会因为主阵容历史重复导致灯神战斗重复武将。
   截图：