6.0 KiB
阶段4C1普通钓鱼消费确认方案独立审查
日期：2026-09-24。审查者：ZCode会话。独立性声明：未参与4C1方案编写与实施；此前参与为R1全链审查。本轮只读＋hash计算＋源码抽查，仅新增本报告。
受审hash核对
KVFishingConsumeDesign/plan-review-hashes.json共34项，逐项重算——全部一致。
总结论
接受。 范围以最小改动推进真实玩法（一次收费抛竿的扣费→原票据确认→可拉杆→重启恢复），无多余抽象；三项重点合同（§5/§6/§9）正确、可实施、证据要求充分。附P3四条，均不阻塞编码。
逐项回答（按提示词）
1. 范围：最小且真实——只加"可等待确认支路"，复用现有Owner/Write/Flush/Ticket/整档序列化/扣费与任务算法；路线比较中"全B/C先行"与"全局SyncDataImmidiate"的否决理由成立（后者会连带开放转盘且保留旧体力副本冲突——本审查源码核实该冲突真实存在，见下）。无需缩小/扩大。
2. 动作身份与生命周期：完整。源码核实FishingUpdateSys.Start进入即自动抛竿链属实（方案如实要求"不通过CLI直接调用消费伪装UI验收"）；§3的准入点设计正确——CastLine首次入口捕获（早于扣费）、ConsumeBait前二次全条件检验（鱼种流程中确定的事实被§3.4覆盖）、每个await/Tween回调/继续点复查、OnDisable/OnDestroy仅撤销本对象继续资格不撤销已准入写、重复入口duplicate-suppressed——"旧回调二次消费"与"断网弹窗重复回调"均有对应拒绝。
3. 双表示冲突：属实。ConsumeBaitOnPlayfab实证：复制PlayerDataDic后只改"energy"别名（副本内），旧NewPlayerDataDic仍带扣前体力——两套表示并存确为真实缺陷；新支路完全弃用该副本与旧立即接口、复用唯一序列化（SerializeAndSavePlayerData(true)于:1164已存在，R1期提取）——不改算法、不放宽Schema ✓。
4. 写入矩阵：与源码实际订阅者集合完全吻合。本审查独立枚举ConditionTypeEvent订阅文件（8个）与方案矩阵逐一对应：BattlePassData/AchievementDataManager（独立保存已注释:175属实）/FishingEventData/TriggerPackData/HomeBtnRecharge（仅RechargeAmount过滤✓）/FishingBehaviorB/LuckyTaskData（两实现两键✓）/MiniBattlePassDataProvider；PlayerData通知→ActivityManager链单列正确。恢复计时三分支（跨阈值RecoveryEnergy(0)/等待期定时写/后续写非本动作票据）与C1-03对应。矩阵诚实声明"不冒称枚举反射/动态注册全部事件"并以真实run日志为新链停止条件 ✓。
5. §5多写合同（重点）：正确。 核心区分成立——R1装备逐张Confirmed不动的语义下，消费因同一同步调用合法地重复序列化同key，**按"每key最终原票据Confirmed＋中间票据可追溯Superseded（同批次/同Owner/同key/更后remote票据解释，与3B的Superseded=派发前替换语义一致）"**是正确的放宽且边界严格：localOnly终态拒绝（主档已转remote）、Unknown/Blocked/StorageError不被后票掩盖、最后票据必须Confirmed、晚到异步写不进封存集且若Superseded本动作终票即停run、部分key部分失败=run失败不称原子性、票据不掩盖后续真实覆盖（最终对账要求）。WriteBatch仅附加记录不拦截/重排底层 ✓可实现。
6. §6失败边界（重点）：正确。 不重扣/不补偿写/不重登重放/Unknown不改false；"已确认扣费但本地对象失效、多键部分提交→可能扣体力但不继续，如实记录供对账"——作为专用测试模式停止策略明确可接受，方案自身已声明这不是普通用户消费恢复方案、本期通过不开放普通用户/连续钓鱼/奖励/最终包。诚实。
7. §9真实运行门（重点）：具体可实施。 只读备份/配置摘要/费用与体力快照→"预计写键→存在→订阅→允许字段"矩阵→SetEvent预拒绝（存在ConsumeEnergy触发的活动配置即扣费前停止）→活动Open/Close观察不记通过→自然恢复按原公式解释→独立CLI请求退出（吸收R1跨Stop超时教训）→新进程新缓存恢复对账→无第二次消费。102配置不满足时明确安全停止、不造档不扩权 ✓。预计键集合（8个任务/活动键＋主档）与矩阵吻合。
8. 白名单/测试/回归：白名单6项与需求对应、底层与转盘/活动只读；固定合成host沿用R1模式且"不得实例化假通用网络工厂"；红测先行（C1-01证明旧代码两缺陷）；C1-09覆盖4B2/B3A三条件/R1/Unity回归与PF/SERVICE_HOST编译保持。充分。
P3清单（不阻塞）
- P3-1｜恢复计时与派发的窄竞态：30秒等待窗口内若CoRecoveryEnergy的定时写在主档终票派发前落笔，按§5合同本run失败（终票被Superseded）——数据无损但真实run需以新进程重跑（成本：一次进程重启＋一次新消费）。建议实施记录预告该重跑可能，避免届时误判为缺陷。
- P3-2｜Tween/Kill边界：§3.4的继续点检查覆盖Tween完成回调；建议实现时对Tween被Kill（而非完成）的路径同样走撤销（OnDisable已覆盖大部分，补一条用例断言Kill不触发继续）。
- P3-3｜
ReduceEnergy(cost,false)的内部保存路径：实施时以C1-02红测确认该方法在remote=false下产生的中间写（若有）被WriteBatch完整捕获且其localOnly中间票符合§5"中间可解释"规则——方案矩阵已列，落为断言即可。 - P3-4｜§2矩阵建议附实现版行号快照：方案引用"受审清单行号，实施前重核hash"已声明；建议检查点0的源码快照包含这8个订阅文件，便于实施后diff审查。
结论
接受4C1方案。 三项重点合同全部确认正确；无P1/P2。建议主会话逐条裁决（P3四条随裁决采纳为实施说明）后按检查点0–4推进，交付后交独立实施复核。