174 lines
26 KiB
Markdown
174 lines
26 KiB
Markdown
# 阶段4C2：拉杆收鱼与奖励保存最小方案（待独立评审）
|
||
|
||
日期：2026-09-24。前置：限定4C1已正式关闭。用户要求：准备最小方案，完整评审后实施。**本文是设计申请，未批准编码、未启动真实消费。**
|
||
|
||
## 1. 目标、已有授权与路线选择
|
||
|
||
在现有Editor专用KV模式中，用102现有存档，通过真实UI完成**新的一次普通收费抛竿→4C1扣费确认→真实拉杆/搏鱼→成功收鱼→原奖励数据保存确认→显示奖励结果→正常游戏退出→新进程新缓存恢复**。上次4C1的鱼已随进程退出，不能假装接着收取那条鱼；本期真实验收需新的一次费用，沿用用户101/102专用账号授权，运行前必须有新备份及具体允许变化矩阵。
|
||
|
||
| 路线 | 代价/问题 | 选择 |
|
||
|---|---|---|
|
||
| 沿用原奖励计算，增加动作去重、有限同步段记录、最终票据等待，并补普通鱼数量保存 | 改动集中在现有钓鱼/结算入口及Editor适配；不改变经济公式 | **推荐** |
|
||
| 所有奖励都抽成新交易服务，并同时覆盖转盘/连续操作/热换号 | 范围远大于一次普通钓鱼；需要改活动和业务边界 | 本期不选 |
|
||
| 不改结算，显示后全局Flush并检查服务器 | 不能防止重复发奖；无法证明哪一笔保存属于动作；普通鱼未破纪录可能漏存数量 | 不接受 |
|
||
|
||
保持原扣费、现金、重量、倍率、随机和任务算法；不新增通用事务框架、网络队列、缓存或服务端接口。成功终点为**结算结果已确认并可见**，随后走正常QuitStage；不点击返回首页/再来一次/广告/空投/任务领奖，不开放普通用户。
|
||
|
||
首轮范围：普通收费鱼，非免费、非重试、非对战、非礼包鱼、非小游戏鱼；不改随机结果或战斗难度。允许新鱼/破纪录/未破纪录三种正常鱼种记录结果；不许用强制成功、改HP、按Editor作弊S键、直接调用奖励方法代替真实玩法。自然失败仅记失败排水与证据，不计本期成功、不自动复活/退款/第二次抛竿。
|
||
|
||
## 2. 已核实的源码链及问题
|
||
|
||
行号参考当前源码，受审版本由 `KVFishingRewardDesign/plan-review-hashes.json` 锁定。
|
||
|
||
| 入口/调用 | 行为、写入与风险 | 本期处理 |
|
||
|---|---|---|
|
||
| FishingPanel_Advanced.PiercingInfo→FishingUpdateSys.PiercingFish（524） | 真正拉杆入口；waitingZone=3发PerfectStrikeCount，任务可能立即保存 | 从这里开始奖励动作身份及第一段同步捕获，不能到奖励面板才开始记录 |
|
||
| FishingUpdateSys.FullCombo（1747） | GuideNextEvent；其余RodPerkTriggerEvent当前直接订阅是UI展示 | 本期要求相关引导已完成/无活动引导；保留战斗算法及事件，不屏蔽引导订阅伪造可用状态 |
|
||
| FishingBehaviorB.ControlFishOutWater（2014）→IsCaughtFish→FishingUpdateSys.Update→FishEnd（1221） | 帧驱动结算；FishEnd还可能先写巡游鱼数据，再发FishingEndEvent，异步创建奖励UI | 入口一次性占用、失败分支先停止；收尾同步段捕获后立即释放，不跨ShowUI资源等待持有全局collecting |
|
||
| FishingEndEvent→Event1v1BattleSlapManager.OnFishingEnd（57） | 非对应菠菜Item早退；符合特殊Item时会改变对战数据 | 真实鱼Item不得匹配TbEventSlapSpinach，不改订阅；前后该数据不变 |
|
||
| FishingRewardPanel.OnShow（311）→SetBotCount（365） | 成功判断之前已更新幸运值并SavePlayerData | 奖励捕获必须早于SetBotCount，不能只包住Success |
|
||
| Success（488）→SaveFishingFrequency | _fishingFrequency+1、_allFishingFrequency+倍率、GetFishCount事件、主档保存 | 保留原顺序/事件一次；计数变化和任务写入纳入确认 |
|
||
| Success→收集材料/EndCollectionTargetWeight/AddProgress/Guide.AddIndex | 可能材料奖励、Buff结束、储蓄/砍价礼包进度、引导保存或活动新初始化 | 本期用明确准入条件收窄为无这些额外结算；不删除调用或改算法来绕过 |
|
||
| Success→SetProficiency（805） | 计算原倍率并可能调用FishingChallengeManager.AddScoreByQuality保存FishingChallengeData；并非通用经验升级 | 限定挑战积分当前不生效；保留原计算，不新增经验或等级奖励 |
|
||
| Success→CashFromFishing/MaxCashFromFishing→AddGold→TargetAddData | 成就/任务及主档；TargetAddData当前FishingStage订阅仅记展示队列 | 事件和AddGold各一次，金额完全使用旧表达式，最终主档序列化在所有事件之后 |
|
||
| SetFishWeight（760）→SetGetFishCount/SetWeight | TotalNum增加倍率只改内存；仅新最大重量时SetFishData→Map_5_{AreaID}；GetFishWeight/GetFishID及高品质两事件 | **已确认缺口：未破纪录收鱼也必须保存TotalNum**。只增加一次Editor最终鱼种保存，复用原SetFishData/序列化，不再加数量 |
|
||
| Success中的首次await在显示倍率动画附近（595） | 奖励修改已发生但不等待服务器；OnShow之后还有引导触发事件 | 将同步奖励计算与异步展示分开，收齐同步事件后再封存并确认；禁止async void异常脱离动作观察 |
|
||
| OnClickInHome/OnClosePanel/OnSucceed等 | 可能自动重抛、触发空投、广告或其他UI，突破一次配额 | 专用模式本期不注册/开放这些操作；结算确认后截图并正常QuitStage，无额外产品UI设计 |
|
||
|
||
## 3. 范围准入：先证明当前档可跑，再扣费
|
||
|
||
以下检查在v3动作扣费前完成；拉杆、FishEnd、OnShow同步写段前再次检查会话/动作/鱼种上下文与相关动态状态。任一失败停止run，不补数据、不选鱼、不改配置。离线依据见 `offline-event-and-save-baseline.json`，历史档13次/393体力不是新run保证。
|
||
|
||
1. 继承4C1全部普通收费条件；要求fishItem.SubType==1、fixedFishList==null、当前配置/Map/鱼竿/倍率/费用有效，冻结对应对象引用、ID及配置摘要；后续任何替换或倍率变化均拒绝继续。只捕获原随机值和最终鱼重用于对账，不重掷。
|
||
2. 所需 `NewPlayerDataDic` 和 `Map_5_{curFishData.AreaID}` 已存在新备份，AreaID与业务鱼种一致（不能用当前场景MapID猜存档键）。允许鱼ID在该Map键内首次出现，不允许新建整个Map键。巡游鱼GetFishSwimToMap(map)==0；否则本期停止，避免引入现档不存在的FishSwimToMap/Count键。
|
||
3. 收集额外奖励GetAddCollecting()==0、collectingTargetInit==null、无有效CollectionTargetWeight结束分支；PiggyBankPackData/BargainPackData均未激活；FishingChallengeData不存在，或ChallengeState为0/3，或原IsTimeAllow()==false。只读检查使用已有无副作用数据/方法，不通过执行奖励“试一下”。无法可靠读取任一条件则不准入。
|
||
4. 无活动引导：Guide.curDefine/curGroupDefine为空；配置中包含FishingPanel、FishingPanel_Advanced、FishingRewardPanel任一步骤的引导组均已GetIsFinish，缺失数据按未完成拒绝。不调用有副作用的InspectTriggerGuide做预检。拉杆和结算期间发现引导开启则终止，不自动完成或修改引导档。
|
||
5. 当前离线配置：本期事件集合为ConsumeEnergy、PerfectStrikeCount、GetFishCount、CashFromFishing、MaxCashFromFishing、GetFishWeight、GetFishID、GetBoosFish、GetBiggerThanHugeFishCount。除GetFishCount以外，没有匹配的旧FishingEvent或TriggerPack记录；集合内TriggerPack当前全部为空。运行Tables须重核相同事实，否则先提交具体差异评审。
|
||
6. GetFishCount的19条不能全禁：只允许已核实的10100000/10200000/11300000（Type1、SubType1/2/13，阈值2/2/3），扣费前频次已≥3且对应解锁标记已就绪；其余30200350～30200365必须仍为受审LimitedTime配置且**以真实服务时间确认全部已过EndTime至少120秒**。在现源码中这些过期Type3/SubType2的Condition先返回false；不调用可能有副作用的Condition作泛化探测。不接受新增或改变的事件配置，仅校验ID不够，须校验条件、时段及分支字段。
|
||
7. 新ActivityManager仍可能因PlayerData发布重评估活动。运行前留存sentry/scope/相关数据摘要，确认加载已稳定；频次13→14的历史例不会跨当前GetFishCount阈值。观察到活动Open/Close、异步初始化、新键或无法归因的写入，本run不计通过并正常关闭；不能因此宣称全活动安全。任务进度的正常同步保存允许，活动启停不允许。
|
||
8. 自动钓鱼保持关闭，界面用正常手动输入。相邻操作不改变鱼种/地图/倍率/装备；不进入其他玩法。原时间及恢复计时保持运行，跨日/活动边界应在预检拒绝；等待中出现的外部写入依§5处理，不暂停时间造稳定场景。
|
||
|
||
这些是本期可执行边界，不是对当前运行已通过的声明。若新102状态不满足，先输出具体拒绝原因及最小差异方案；不自动扩大到全活动结算，也不额外询问已授权账号。
|
||
|
||
## 4. 动作、许可与同步段设计
|
||
|
||
### 4.1 许可和身份
|
||
|
||
新增许可 **Version=3，Operation固定fishing-reward-once**；v1及v2枚举/语义原样保留。v3包含一次原4C1消费及其后一次收鱼结算，不允许装备、第二次抛竿或脱离消费的领奖。旧v1/v2不能进入PiercingFish/FishEnd/奖励写入；v2仍可显示“可拉杆”供4C1验收，实际拉杆无新放行。沿用备份摘要、账号/API、已有键、进程claim验证；不删除或重用claimed。
|
||
|
||
复用4C1的FishingAction及Owner/组件身份；新增**仅Editor内部**FishingRewardAction，引用同一消费动作、FishingUpdateSys和绑定的RewardPanel、鱼Item/配置/区域/倍率及阶段标记。不支持重置配额、持久恢复动作、跨进程补领奖。消费Confirmed且Continued之后才可一次占用奖励动作。
|
||
|
||
状态：未拉杆→Drawing→Ending→Applying→Waiting→Confirmed→Closed；失败进入Stopped，不回前态。C1的Continued只表示可拉杆，**不能代表C2奖励已完成**。v3的取消须检查RewardConfirmed：奖励等待中Disable/Destroy仍Fault；完成后正常销毁只撤销继续资格，不能重现4C1首跑重复Quit。
|
||
|
||
### 4.2 有限同步捕获，不跨帧占住collecting
|
||
|
||
不从拉杆到结算全程设置静态collecting。只在以下现有同步调用内使用WriteBatch，并在finally Dispose，段内没有await；分段原记录在动作内按实际顺序追加，最终封存后只读。
|
||
|
||
| 段 | 边界 | 说明 |
|
||
|---|---|---|
|
||
| S1 拉杆事件段 | 第一次PiercingFish正常入口、原PerfectStrikeCount发布及其同步订阅 | 非完美刺鱼也占用一次Drawing状态，但允许该段0条写入；不修改战斗参数、不等待网络再计算伤害 |
|
||
| S2 收鱼收尾段 | 第一次成功FishEnd的同步业务部分，到原FishingEndEvent发布结束 | 无巡游鱼写入；原事件仍执行，禁止重复FishEnd；ShowUI调用放在捕获释放以后，由可观察Task持有 |
|
||
| S3 奖励段 | OnShow里SetBotCount之前开始，包含原普通Success全部数据修改/同步事件，以及OnShow原引导通知，至最终鱼种/主档保存 | 拆开原Success同步修改与异步展示，不跨任一await/coroutine启动持有collecting；原计算/顺序保持，UI显示推迟到确认后 |
|
||
|
||
每段只能登记一次，重入/嵌套批次拒绝。S1/S2的原写允许按已有定时器发送；合并只是保留原票据的动作记录，不是新延迟发送缓冲。写入准入在调用底层WriteKV之前检查许可，S1～S3还须属于具体预计奖励键；不能先发送再发现越界。
|
||
|
||
S3顺序：原SetBotCount→SaveFishingFrequency及同步任务→原Buff/礼包/Guide调用（准入保证本期无额外奖励分支）→SetProficiency及现金计算→现金事件→原AddGold→原TargetAddData→原SetFishWeight及重量/鱼ID/品质事件→原OnEventTriggerGuide通知→一次最终鱼种保存→一次最终主档序列化→封存。禁止再次发布PlayerData来补主档，避免重复活动检查。
|
||
|
||
原异步视觉包括音频、评级Addressables、AddCash/倍率Tween/震动等，移到确认后仅展示已有计算结果，不再调用AddGold/SetFishWeight/SaveFishingFrequency。旧PF模式保留原入口与时序；可提取共同同步语句块，但不能维护两份奖励公式。实施若需要超出§7拆分范围，先回到差异评审。
|
||
|
||
### 4.3 补齐鱼种保存及最终主档
|
||
|
||
PlayerFishData新增Editor窄方法 `SaveCaughtFishForKVLoop(int fishId)`，要求当前S3/原鱼ID且数据已存在，直接调用既有私有SetFishData(fishId,fishData[fishId])。它不增加TotalNum，不更新重量或事件，不自行拼装地图档。这样即使本次重量≤旧MaxG也能保存原SetGetFishCount的数量变化。原PF逻辑不顺带修复。
|
||
|
||
PlayerData新增Editor窄方法 `SaveFishingRewardForKVLoop()`，仅在原动作S3末尾调用既有SerializeAndSavePlayerData(true)，返回原PlayerKVEditResult。必须晚于重量/品质等成就事件，保证主档ad最新。鱼种最终保存产生的Map键记录、最后主档primary和S1～S3所有同步任务的最终原记录一起确认。
|
||
|
||
## 5. 最终确认、失败与生命周期合同
|
||
|
||
沿用4C1每key最终原票据规则，但奖励动作有自己封存的S1～S3记录；**不把已完成的消费票据混入待确认奖励集合**，也不覆写消费Confirmed/Continued来重新准入。
|
||
|
||
- 最终Map记录须为§4.3本次追加的原保存，最终NewPlayerDataDic须是返回的primary；均remote且有ticket。所有其他变更key最终记录也必须remote；最后localOnly直接失败，不偷偷补写提升语义。
|
||
- 校验原OwnerInstanceId/Epoch/key/sequence。中间票据只接受Confirmed，或同一奖励动作中同Owner/key、更后remote原票据解释的Superseded；最后原票据必须Confirmed。同一key可以跨S1与S3发生这种合法替代。
|
||
- 30秒仅是最终确认的观察超时；底层已准入提交继续按现有Registry排水。Unknown/401/Blocked/StorageError/部分提交/最后Superseded保留原因并停止，不退款、不补发、不重领奖、不寻找外部新票据冒充原票据。
|
||
- 在S1/S2之间或等待UI资源期间的异步写，不归入本动作。它使原最终票据Superseded则失败；同key的外部写即便后来又被S3覆盖，也不得拿“最终对了”掩盖：v3从Drawing到完成的Write采样要记录outside-segment写，发生实际变值写即拒绝验收/停止。消费后恢复计时或正常后台写可引起此停止，不暂停原计时；不将全局记录冒充动作归属。
|
||
- 重复Piercing/FishEnd/OnShow/Success不得二次改内存、发事件或奖励；重复UI实例不能仅靠各自bool放行，必须原进程动作绑定。过期的ShowUI Task即使完成，也只能清理刚创建的对应对象，不销毁另一个Owner的当前UI。
|
||
- FishingBehaviorB、FishingUpdateSys、奖励Panel任一相关对象Disable/Destroy或退出/401，都撤销当前阶段继续资格；待确认时停run、已完成后不再次发Fault/Exit。资源回调与显示Tween只可操作仍匹配的对象。Update停推进、过期ControlFishOutWater不再设置IsCaughtFish；不可只在最终await之后加一个检查。
|
||
- 自然失败在FishEnd业务变更前终止本期：不进入原免费恢复/广告重试/失败奖励面板分支；已发生扣费或完美刺鱼任务写仍排水并对账，不能称失败没有副作用。
|
||
- 确认前奖励根节点不可见且不响应操作；确认后只展示本次结果，后续按钮仍不开放。本期用正常QuitStage结束，由独立CLI调用取状态/日志，不以Stop Play强行结束在途写。
|
||
|
||
这是专用账号的一次性试运行，允许记录“已扣费或部分写成功但未呈现奖励”的失败，**不承诺跨key原子性或断线后自动补领奖**，因此不能由本期通过推出普通用户上线。
|
||
|
||
## 6. 预计数据变化与对账
|
||
|
||
| 键/字段 | 本期允许变化 | 不允许/检查 |
|
||
|---|---|---|
|
||
| NewPlayerDataDic.newData | 消费energy/energyRM/必要恢复时间；奖励gold、_fishingFrequency+1、_allFishingFrequency+原倍率 | 19槽其他项保持；金币按原表达式及Mathf.RoundToInt复算，goldRM不因奖励增加 |
|
||
| 主档ld/ad | 原SetBotCount幸运值；消费、现金、次数、鱼重/ID/品质/刺鱼等实际事件的成就 | 保存不得早于最后事件；不把GetFishCount=1错误改成倍率 |
|
||
| Map_5_{AreaID} | 目标鱼TotalNum+原倍率，MaxG=max(旧值,本次重量)；首次鱼的原NewFish默认 | 其他鱼、卡等级/卡数量保持；fishID来自原固定鱼处理规则，若fixedFishList参与本期拒绝，避免ID不一致 |
|
||
| BattlePassRecordTask、MiniBPKeyNew、EventLuckGameRecord、EventLuckMagicPlayfabData | 实际激活任务对本期事件的原同步进度 | 仅实际变更者要求记录；不领取任务奖励，不强制写所有候选键 |
|
||
| 其他原45键 | 正常登录既有准入按原R1合同；动作之外变更逐项归因 | 本期结算不新增键；TargetBuffDataList/PiggyBankPackData/GuideSaveDataNew/Event1v1BattleSlapData等预期不变 |
|
||
|
||
独立备份读取的Login/Get计数与游戏事件分开；本期保留write-attempt/accepted、action/stage/segment/key/valueHash和原ticket记录，不为P3扩大网络层计数改造，不声称游戏Set=0。
|
||
|
||
## 7. 精确实施白名单（待审后生效）
|
||
|
||
以下均 `UNITY_EDITOR && !SERVICE_HOST` 限定接线；默认PF和SERVICE_HOST路径不得引入对新Editor类型的引用。
|
||
|
||
| 文件（Client/Assets/下） | 允许改动 |
|
||
|---|---|
|
||
| Scripts/GampPlay/FishingB/FishingBehaviorB.cs | ConsumeBaitOnKVAsync增加v3预检和冻结上下文；窄动作引用读取；ControlFishOutWater继续检查；CancelKVFishing关联奖励生命周期。C1扣费算法保持 |
|
||
| Scripts/GampPlay/FishingB/FishingUpdateSys.cs | PiercingFish的v3资格/一次动作/S1事件段，FishEnd一次入口/S2和可观察ShowUI；Update停止推进及OnDisable/OnDestroy取消；FullCombo相关引导状态及await后检查，PiercingToComboB/EternalDeath的await后资格检查；不改伤害、随机、HP和手动输入算法 |
|
||
| Scripts/UI/FishingReward/FishingRewardPanel.cs | OnShow/Success同步计算与展示分离、去重、S3/确认Task；Awake用现有CanvasGroup隐藏未确认结果，Start的专用输入限制及资源关闭事件限制；OnDestroy/新增OnDisable撤销；异步显示回调有效性与资源清理；OnGUI在KV模式不执行调试改鱼。不修改奖励公式和普通PF分支算法 |
|
||
| Scripts/DataCenter/DataCenter.PlayerFishData.cs | 只加SaveCaughtFishForKVLoop调用原SetFishData；不修改原SetGetFishCount/SetWeight/序列化 |
|
||
| Scripts/DataCenter/DataCenter.PlayerData.cs | 只加SaveFishingRewardForKVLoop调用原SerializeAndSavePlayerData；不重写SaveFishingFrequency或AddGold |
|
||
| Scripts/Services/UserService.KVGameplayLoop.cs | v3许可、v3纳入AllowsFishing及装备拒绝；Write增加限定动作段/键审计和段外写检查；既有消费/装备确认规则保持 |
|
||
| Editor/KVGameplayLoopSetup.cs | 固定PrepareFishingRewardPermit及固定fishing-reward验证case；无任意方法/URL入口 |
|
||
| Scripts/Services/UserService.KVFishingReward.cs及meta（新增） | partial内部动作/预检/同步段记录/封存与确认，复用现有WriteBatch/Owner；不另建通用业务框架 |
|
||
| Scripts/Services/UserService.KVFishingRewardValidation.cs及meta（新增） | 固定.invalid合成host，真实对象/原方法测试，finally恢复并排水；不含正式许可 |
|
||
| CodexOutput/upserver/KVFishingRewardTests/（实施期新增） | 离线真实方法提取宿主、固定CLI脚本、证据；生成.cs不得污染既有csproj glob |
|
||
|
||
总计上限为7个旧源码文件及2个新增源码（各meta）；这是文件范围上限，不是要求都必须改。辅助方法仅服务本期；如果预检或测试需要改活动、Guide、Challenge、Schema、Owner/Registry、PlayFabMgr、服务器、UI资源或配置，必须先提交具体差异方案，不能借“跑通”扩大。现共享未提交改动保持，禁止全仓格式化、重置或自动提交其他人的文件。
|
||
|
||
## 8. 验收矩阵
|
||
|
||
| 编号 | 必须证明的结果 |
|
||
|---|---|
|
||
| C2-01 | 原实现红测：未破重量纪录时TotalNum未获新的Map保存；原奖励展示不等待原票据。编译/调用真实旧方法，不复制缺陷模型 |
|
||
| C2-02 | 新鱼/破纪录/未破纪录三分支，真实SetGetFishCount/SetWeight/SetFishData、Map序列化和Schema读回；数量只增加一次倍率，卡片和其他鱼不变 |
|
||
| C2-03 | 真实SaveFishingFrequency/AddGold/原奖励计算及事件；主档最终包含全部ad和ld；金币/重量/倍率来自原公式，正常/0现金边界均不重复发奖 |
|
||
| C2-04 | 完美刺鱼S1任务原写收进同一奖励动作；S1/S2/S3重入、跨段同key、S3最终Map/main身份；捕获期间无await，段外实际变值写不能被后来覆盖掩盖 |
|
||
| C2-05 | Pending时无奖励动画/结果，Confirmed后一次呈现；重复拉杆/FishEnd/OnShow/重复Panel不产生第二次次数、金币、Map或事件 |
|
||
| C2-06 | 最后localOnly、最后票据外部替代、写后丢响应、401、StorageError、超时、部分成功；无自动退款/重放，原结果和排水保持 |
|
||
| C2-07 | 战斗中/收鱼动画后/UI资源加载中/奖励等待中/确认后Disable、Destroy、正常Quit；前四类阻止旧继续，确认后正常退出不Fault、不二次Exit；实际入口测试 |
|
||
| C2-08 | v1/v2不能拉杆领奖，v3恰一费用+一奖励；未知版本/枚举/缺少Map键/错误AreaID拒绝；禁止fixedFishList、免费、重试、特殊Item、自动钓鱼/广告/空投/再来一次 |
|
||
| C2-09 | 真实Achievement/BattlePass/MiniBP/LuckyGame/LuckMagic订阅及原Save覆盖全部相关Condition；限定19条活动规则、Guide/巡游/挑战/额外收集准入及动态变化拒绝；不能只测常量假订阅 |
|
||
| C2-10 | 自然失败不伪造成成功；扣费和可能的刺鱼任务写可解释，无奖励或二次抛竿；不自动运行第二次付费尝试 |
|
||
| C2-11 | 4C1固定19组81+原方法27、R1装备/许可/退出、4B2 75组及B3A 13组、Unity加载M01/B2-20；Editor/SERVICE_HOST编译。默认非Editor历史_cheatingScore错误仍单列，不顺手修或冒称通过 |
|
||
| C2-12 | 真实UI一次新抛竿及自然战斗成功，Confirmed在奖励呈现之前；新鲜服务器45键逐值/字段矩阵；新进程新缓存读回金币/频次/总频次/目标鱼数量最大重量/相关任务，正常退出无新错 |
|
||
|
||
测试分层：窄动作/票据用.invalid注入；数据用真实PlayerData/PlayerFishData及真实订阅；控制流编译原方法片段可用视觉spy但须标注；原奖励公式拆分前后同输入对照，不能只测新helper；最终以真实UI运行独立验收。固定host需空闲、隔离、Enabled前置满足，不能强行改静态标志绕过。未覆盖所有动画资源时如实记录，不泛化为完整捕鱼系统。
|
||
|
||
## 9. 实施检查点与真实运行顺序
|
||
|
||
评审通过后由本主会话按检查点推进，每个检查点更新开发日志/入口/TODO；不自动生成其他任务或派生代理。
|
||
|
||
- [ ] C0：核独立方案报告与受审hash，逐条裁决（尤其§3、§4分段、鱼数量保存、取消语义）；批准精确白名单，保存7旧源码快照。
|
||
- [ ] C1：先C2-01红测和数据/许可/生命周期失败用例；实现最少动作记录及两个最终保存入口，再接UI/结算，固定host验证C2-02～10。任何范围扩张先评审。
|
||
- [ ] C2：C2-11回归与编译；默认PF公式/事件顺序、C1单条件退出修复和原文对照；实际UI资源只通过CLI检查。测试通过不等于真实run已授权条件满足。
|
||
- [ ] C3a：新的只读101/102备份、真实服务时间、配置及相关引导资源hash、活动稳定状态、体力/费用/地图/当前鱼条件；输出预计键/字段/目标鱼Map键存在性矩阵，所有§3准入通过才生成v3许可。不得重导45键，保留全部claimed。
|
||
- [ ] C3b：新Unity进程，真实UI短按用已验证LongPress 0.15秒（custom UIButton适配），其余拉杆/收线按实际交互，不调用奖励入口或S作弊键。一次收费、真实成功、等待奖励确认后截图。若失败停止本run并记账，不自动多次付费直到通过。
|
||
- [ ] C3c：独立CLI正常QuitStage请求，另取closed/排水/playing=false和错误日志；备份服务器逐字段对账。旧Editor不使用已知会超时自动强杀的uloop launch --quit；在无在途写/已closed前提下使用已核实无强杀降级的关闭路径，不能用仍存缓存冒充新进程。无法完成新进程条件就保持验收未完成。
|
||
- [ ] C3d：新进程确认新缓存不存在，使用原equipment恢复许可；不抛竿，不重领奖，比较数据，正常退出并最终服务器对账。允许正常登录同值保存受理，不能叫游戏全程只读。自然时间变化须按旧公式解释，否则不放行。
|
||
- [ ] C4：归档许可、源码差异/证据/受审hash、自审、独立实施复核提示词；独立实施复核后主会话核hash/裁决关闭限定4C2。完整4C/G4/热换号仍不自动关闭。
|
||
|
||
任何失败都保留原存档和日志，不用旧备份覆盖新状态。若需要人工恢复，另列当前态和精确恢复范围。本期不新增业务补偿机制。
|
||
|
||
## 10. 作者自审与交审要求
|
||
|
||
自审已补入容易遗漏的四点：PerfectStrikeCount早于FishEnd；OnShow的SetBotCount早于Success；未破纪录鱼数量缺保存；C1 Continued不等于C2奖励完成。GetFishCount配置不是零条，已实查19条并给出可执行的限定条件。主档最终序列化晚于全部成就事件；Map键取鱼AreaID；0现金仍须保存次数和鱼种。
|
||
|
||
本设计使用brainstorming整理选择与边界；按用户既定流程直接输出完整中文方案交独立评审，不进行零碎重复确认、不自动commit共享工作区。实施检查点是供本次完整审查的顺序合同，不是已批准的实施指令。评审通过后按writing-plans/执行计划要求细化具体测试命令与方法拆分，再编码；若细化改变合同或白名单，需补充审查。
|
||
|
||
评审必须回答：范围是否够小且可执行；事件/异步边界是否遗漏；原奖励顺序与PF行为是否能保持；最终Map+主档+任务票据及部分提交是否诚实；v3取消与旧v2边界是否完整；真实失败/重启方式是否可验收。不得只回“方案合理”。提示词见《其他AI审查提示词-4C2拉杆收鱼与奖励保存方案-2026-09-24.md》。
|
||
|
||
**当前状态：可提交独立方案评审，未编码、未运行测试、未启用许可、未发生新消费。**
|