Files
ft/CodexOutput/upserver/Gameplay101Validation/不可用药水引导恢复最小修正方案-待评审.md

87 lines
10 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 不可用药水引导恢复:最小修正方案
2026-09-28,主会话。状态:待完整独立方案评审;未修改源码。补充原《101真实玩法与迁移档恢复业务包》,本次评审覆盖修正、回归及剩余真实闭环,内部检查点不另开评审。
## 1. 问题和目标
101已成功登录KV,账号和存档均正确。用户看到的是普通主页,没有药水引导。只读证据 `no-visible-guide-check.json` 显示:curDefine/curGroupDefine指向EventPotion01/EventPotionPanel,CurPanelName为空,实际GetEvent(4,5)=-1。源存档 `GuideSaveDataNew` 中保留 `EventPotion01|4|0`。
原因链:GuideDataCenter.Init不检查活动可用性就恢复未完成引导指针;药水入口HomeBtnPotion在无活动时隐藏;CheckRewardGuide因指针非空拦截。因此不能要求用户去完成当前没有入口的引导,也不能把它解释成登录失败。
目标:在本次Editor KV运行中,没有可用药水活动时,历史EventPotion01继续保持未完成存档,但不恢复为“当前活动引导”;已有普通钓鱼准入规则保持,用户可以在通过真实预检后完成一次普通收鱼和重启恢复。
## 2. 方案选择
| 选项 | 影响 | 裁定建议 |
|---|---|---|
| 在GuideDataCenter.Init延后恢复这一个不可用引导 | 源头不产生活动指针;保留旧进度,正常钓鱼回调无需绕门 | **推荐**,限定Editor KV和EventPotion01 |
| 放宽CheckRewardGuide接受非空药水指针 | 鱼死亡、奖励ApplySuccess会直接AddIndex(true),可能将药水引导误标完成并写档 | 不采用,不能只凭界面不可见放行 |
| 改存档为完成、清除存档、开启过期活动 | 改变玩家历史进度或活动配置,掩盖恢复语义问题 | 不采用 |
关键源码依据:FishingUpdateSys鱼血量归零处直接AddIndex(true),FishingRewardPanel.ApplySuccess同样调用;GuideDataCenter.AddIndex(true)会把curSaveData.isFinish改true并Save。只改测试门会把现在的前置拦截变成收鱼时的错误写档。
## 3. 精确改动合同
生产改动仅 `Client/Assets/Scripts/DataCenter/DataCenter.GuideData.cs`,位置为Init遍历引导组、取得现有_saveData之后、执行原恢复循环之前。新增一个限定条件分支,必要时在本类内用一个私有判断函数容纳活动查询与异常处理;不抽取/重排整个恢复循环,不新增文件或通用引导框架。
所有条件同时满足才延后恢复:
1. 编译条件 `UNITY_EDITOR && !SERVICE_HOST`,并且PlayerKVGameplayLoop.Enabled与Ready均为true。
2. 当前组恰为GroupName.EventPotion01,已有存档且isFinish=false,guideSubIndex>0且在当前定义数组范围内;对应节点属于EventPotionPanel。空定义/越界不由这个例外消化,仍走原诊断与检查。
3. 通过现有FishingEventData.GetEvent(4,5)查询,结果严格等于-1。这是当前玩家实际活动可用性,**不**根据本地配置最后日期、硬编码活动ID或仅比较存档日期判断。不得调用GetEventAndInit、SetEvent、FixPotionData等有初始化/清理效果的接口。
满足时:把同一_saveData按原键加入本次keyValuePairs,然后continue;不进入该组的原恢复/JumpIndex逻辑,不修改isUpdate,不设置curSaveData/curDefine/curGroupDefine,不发布CompleteGuide或AddIndex事件,不额外调用Save。原字典中的该组数据保留;最终替换字典的既有逻辑照常执行。
必须保留的行为:
- 本分支不清空任何已存在的引导指针;它只阻止这一个不可用组在本次Init中被挂载,不覆盖其他组已经恢复的状态。
- 活动查询异常/依赖不可用时不延后:记录具体查询失败的警告并继续原恢复路径,由未变的钓鱼准入拒绝。不能把异常当成GetEvent=-1。
- 活动可用、其他组(含EventPotion02)、已完成组、索引0均保持原路径。本修正不把全部过期活动、全部不可见引导都放行。
- 默认PF路径、非Editor、SERVICE_HOST不启用此分支。全平台/全部活动的引导恢复政策仍为后续范围,不借此扩大正式启用。
- 如果将来药水活动重新可用,下次正常登录仍能按保留的进度走原恢复逻辑。本轮不新增定时恢复、跨日热切换或自动完成政策。
测试改动仅 `Client/Assets/Scripts/Services/UserService.KVFishingRewardValidation.cs`,在既有fishing-reward固定验证入口增加隔离案例。不改CheckRewardGuide、钓鱼/奖励/费用代码、许可规则、配置/场景/资源,不改101/102服务器数据作为测试准备。
## 4. 必须验证的行为
复用既有Unity隔离容器、mock KV、真实GuidanceConfig和当前101参考值。验证实际GuideDataCenter.Init恢复路径;不能只写一个与新if相同的真假表来冒充集成验证。Init是async void:固定测试须在无Play/无活动许可时启动,在已配置mock依赖的隔离容器内调用,按guidanceGroupDefines初始化完成和下一Unity调度帧观察结果,设有限超时,收集异步异常;每例Dispose引导订阅并恢复容器,不让未结束的异步继续到下一例。
| 验证 | 应有结果 |
|---|---|
| 修复前红测:101真实EventPotion01残留+无活动 | 实际Init恢复指针,证明当前阻塞可重现;不能使用手工把指针清空的替身 |
| 修复后同输入 | 三个当前指针不因该组赋值;该组全部存档字段不变,不新增CompleteGuide/该组保存副作用 |
| 相同存档+隔离配置构造可用药水活动 | 通过实际GetEvent(4,5)返回有效ID,原恢复成功,不丢旧进度;不修改真实cfg文件/时间 |
| 活动查询失败 | 保留原恢复及门拒绝,不误判可用性;异常信息可追溯 |
| 其他未完成组/其他已恢复指针 | 继续原恢复,或保留其他指针;CheckRewardGuide仍拒绝真实活动引导 |
| 已完成、索引0、无存档、边界索引 | 新例外不改变旧行为;异常数据不被“延期”藏起 |
| 延后后调用实际AddIndex(true)与GuideNextEvent | 没有当前引导时不得改变药水完成标记、索引、产生药水GuideSaveDataNew改值或CompleteGuide通知 |
| 原普通鱼完整奖励路径 | 通过真实CheckRewardGuide/原31模块加载与奖励通知,原费用/奖励确认先后、普通引导未完成/特殊鱼等负例不变 |
测试中若原Init因其他合法引导需要Save,使用mock记录并逐字段比较,区别既有副作用与本修正产生的副作用;不能笼统要求整个Init在所有输入下零写。101实际样本则必须验证其GuideSaveDataNew原值保持。
验证范围:现有fishing-reward全组加新案例、既有4C1固定消费回归、M10/31模块加载原回归,以及Editor与SERVICE_HOST编译。非Editor既有_cheatingScore历史错误、StorageError/L7问题按原状态保留,不用修复本问题为由扩大改动。出现新失败才扩大针对性测试;不重跑101导入或全项目千项hash。
## 5. 连续实施与真实验收
完整独立评审后主会话核本方案焦点hash并逐条裁决。当前68504仍在Play且有活动v3许可:实施前必须正常QuitStage、确认drain/closed、保存最终快照并归档许可,保留全部claim;不能在用户运行中改源码触发域重载。此退出与后续新进程登录是同一业务包内部执行步骤,不新增评审。
随后连续完成:红测→上述两文件最小修改→固定回归和编译→新进程/新备份/既有v3许可→101实际登录→动作前核验及快照→用户手动一次普通抛竿/拉杆/收鱼→奖励确认后收下→正常退出→新进程v1恢复→统一交付复核。
新的运行基线为最新已验证的合法KV进度。目前参考 `KVGameplayLoopTests/backups/20260928T082052Z/101.json` 55键,与081406Z全等;后续以正常退出时新的全量快照补接证据,不能回滚原D导入after。任何用户实际操作差异均先归因,不能覆盖。
动作前必须满足:101/kv-loop/固定API、Ready且无错误、无未确认保存;实际GetEvent(4,5)=-1时当前引导指针为空,GuideSaveDataNew保留原值;其余原普通鱼/引导/活动准入仍检查。若药水活动变为可用,则保留正常引导,不能为了赶进度用例外放行。
操作仍由用户完成。第一次抛竿前先冻结完整服务器/运行时基线;奖励成功先停奖励面板采样,再收下;失败不自动再付费,不补发、不重导、不删除claim。本修正不保证自然随机鱼必然符合已有门。
验收除原金币/体力/鱼档/任务票据与新进程恢复外,必须新增:普通收鱼过程中EventPotion01没有被AddIndex误完成,GuideSaveDataNew保持;修正不需要用户完成一个不存在入口的药水活动。全部完成再统一交付复核,不把“已不拦截”当作闭环完成。
固定http://s101.local:18080/;Unity CLI Loop;不使用UnitySkills;不打包。
## 6. 评审提示词与交付边界
请独立审查本最小补充方案,并核同目录 `stale-guide-review-hashes.json`。重点:Init处延期是否避免恢复错误指针;save数据和isUpdate是否保持;GetEvent只读语义与异常分支;其他组/PF/非Editor不回归;AddIndex(true)/GuideNextEvent/奖励通知是否可能误改存档;实际Init的红绿验证是否充分;当前活动会话退出后才能编码;剩余真实闭环是否完整覆盖。
给出通过/有条件通过/不通过,逐条列问题严重级别、依据和最小修改。不要把原失败现场再拆成独立实施复核;不要要求改档完成引导或删除钓鱼门。只读审查,不运行Unity/正式接口,不修改共享状态或业务代码,仅落盘 `Gameplay101Validation/不可用药水引导恢复独立方案审查.md`。
作者自查:根因、三选一取舍、两文件范围、精确分支、状态/持久化边界、失败分支、红绿与原回归、实际运行、统一验收均已明确。尚无实施批准或代码修改;下一步交审核侧。原31项方案受审清单不回写,本补充清单只冻结相关源码/输入/证据,不冻结共享日志与活动run文件。