# 交给独立评审AI：4C2拉杆收鱼与奖励保存最小方案

请独立审查 `C:\projects\ft` 的限定4C2完整方案。你本轮是方案评审者，不是实施者；只新增指定报告，不修改代码、配置、共享入口/TODO/日志/受审清单，不启动Unity或正式网络，不启用许可，不消费账号，不打包。

## 先读材料

1. `CodexOutput/upserver/阶段4C1实施复核裁决与关闭-2026-09-24.md`：4C1已正式关闭，不重复复审该期。
2. `CodexOutput/upserver/阶段4C2拉杆收鱼与奖励保存最小方案-待评审-2026-09-24.md`：主审对象，全读§1～10。
3. `CodexOutput/upserver/KVFishingRewardDesign/offline-event-and-save-baseline.json`：离线配置与历史档，只是设计依据，不是新的运行准入。
4. `CodexOutput/upserver/KVFishingRewardDesign/plan-review-hashes.json`：对全部items重算SHA256，对plannedAbsent确认不存在；写明数量、差异和受审manifest hash。若有漂移，先指出版本不一致，不将新版本默认为已审。
5. 按主方案表追踪FishingBehaviorB、FishingUpdateSys、FishingRewardPanel、PlayerData/PlayerFishData、CollectingData、Guide、活动和任务实际源码；不要只审文案。

## 必须逐条回答

1. 目标是否符合“真实游戏先跑、最少改动”？7个旧文件、两个新增Editor文件的边界是否必要；是否有更少改动且不漏掉原副作用的方案？不因看见奖励二字建议通用交易平台。
2. PiercingFish的PerfectStrikeCount、FishEnd的FishingEndEvent、OnShow中早于Success的SetBotCount是否都进入相应同步捕获？S1/S2/S3释放collecting后等待UI，能否避免异步期间混入其他业务？是否遗漏GuideNext或战斗异步继续？
3. 新鱼/破纪录/未破纪录：SetGetFishCount只改内存、SetWeight仅破纪录保存的源码判断是否准确？Editor最终SetFishData补保存是否恰好只加一次数量，并保持原Map_5_{AreaID}序列化、卡数据与普通PF路径？
4. 同步奖励与异步展示拆分是否能保持原金币/重量/倍率/次数公式及事件顺序？最后主档是否在所有成就事件之后？是否错误地把SetProficiency理解为发经验？0现金仍保存次数/鱼种是否覆盖？
5. v3完整动作与旧v1/v2边界是否清楚？C1 Continued仅代表可拉杆，取消时是否正确区分奖励Pending与Confirmed，避免首跑曾有的重复Quit？重复Panel/FishEnd是否可能重奖？
6. 跨同步段最终原票据、段外变值写、最后localOnly、外部替代、丢响应、401、部分提交是否处理诚实？是否存在已发生副作用却误宣称原子成功或无变化的情况？
7. §3准入是否具体可执行且足够保守：19条GetFishCount配置、3条基础解锁与16条过期活动、真实服务时间、引导完成状态、收集/巡游/挑战/礼包排除、活动Open/Close？是否有泛化错误、漏掉写链或根本无法运行的条件？若需新增业务分支，给出最小差异，不能直接放宽全部活动。
8. 数据变化矩阵和真实验收是否足以证明奖励保存？是否明确本期必须新消费一次，上次鱼不可恢复；自然失败不自动再扣、无作弊操作、不重导102原45键、新进程新缓存恢复、无打包？CLI退出的历史自动强杀问题是否如实设为未验证运行条件？
9. 判断完整方案是否可以批准按§9检查点实施；如有P1/P2，逐项给出源码位置、触发条件、实际影响、最小修订和所需验证。P3区分阻塞与非阻塞，避免只写建议未裁定。

## 输出

新增唯一报告：
`CodexOutput/upserver/阶段4C2拉杆收鱼与奖励保存方案独立审查-2026-09-24.md`

报告包含：独立性声明、受审hash、总判定（接受/有条件接受/退回）、九项逐条回答、问题清单、是否批准限定实施及边界。保留真实限制，不声称已运行Unity、测试或正式服务器。

主会话收到报告后负责重新核hash、逐条裁决、更新共享状态；通过后才编码。无需评审者再改共享文档，也不要求重审已关闭4C1。