# 流程修正主会话意见（待审查会话裁决）

日期：2026-09-28。作者：主会话。用户要求：“你需要更新自己的意见到文档。然后审查会话会继续裁决”。

性质：对流程修正的反馈及待裁决清单，**不是新的实施批准，也不自行覆盖审查侧裁决原件**。本轮只落盘意见及交接记录，不编制代码补丁、不运行游戏、不访问正式接口、不打包。下一步在审查会话侧。

## 一、总体意见

**赞同搁置独立“连续普通钓鱼”开发包，主线转向4B3B/C批量迁移。** 继续采用完整批级方案评审→连续实施和检查点日志→批末独立实施复核，不按每个调用重复走完整流程。

主会话此前把临时测试路径的扩展排成独立业务包，并提出v4许可、次数预算等，优先级不合适。它能改善受控调试，但仍保留一次性测试接线，未直接推进正式默认KV路径。现建议不实施该v4方案；保留其中关于动作隔离、重复收下、迟到回调的分析，作为正式迁移及集成验收材料。

## 二、连续钓鱼为何曾被列出，哪些问题仍需覆盖

这不是原游戏缺少连续钓鱼功能，而是新增的Editor KV验证接线限定一次操作：

- `Client/Assets/Scripts/Services/UserService.KVGameplayLoop.cs` 的 `BeginFishing` 在 `fishingAction != null` 时拒绝再次创建动作。
- `Client/Assets/Scripts/Services/UserService.KVFishingReward.cs` 的 `PrepareFishingReward` 在已有 `rewardPlan` 时拒绝；`BeginRewardDrawing`也保留一次性奖励动作。
- 部分异步路径恢复后读取可变动作字段；如果直接清空状态并允许下一竿，原动作的取消或迟到回调可能影响下一动作。这是源码层面需要处理的风险，本轮未运行复现。

因此，**不再单独开发连续钓鱼测试模式，不等于无需处理连续操作的正确性**。正式4B3B/C方案要明确如何替代/退出一次性测试路径，并在代表性集成验收中包含同会话连续操作。单次成功链已经闭环，不需为重复证明同一次存储能力再收费；跨动作隔离则是不同的验收目标，应并入迁移批次。

## 三、逐项意见与建议裁决口径

| 编号 | 当前表述或安排 | 主会话意见 | 建议落盘口径 |
|---|---|---|---|
| F01 | 搁置连续钓鱼候选，转向批量迁移 | 赞同方向；停止继续扩展临时v4许可 | 原方案作为历史候选保留，分析可复用；不单独实施，不删除既有运行保护 |
| F02 | 批量模式减少逐调用方案/复审 | 赞同，但须区分开工前方案审查和批末实施复核 | 每批一份完整方案/白名单，完整审查裁决后编码；批末一次独立实施复核。不能只做批末审查而跳过方案门 |
| F03 | 第一批约30个简单Update调用 | 数量可用于控制工作量，不能作为选批或完成标准 | 按关联业务、相同数据归属和失败规则组批；20–40只是建议范围，不为凑数拆断业务链或扩大文件范围 |
| F04 | 223调用/81文件是剩余批量任务 | 这是2026-09-24语法候选盘点，不是已确认可机械替换的清单 | 复用台账核当前差异，分类迁移/已处理/保留PF/排除项并记录理由；不要以“替换完223处”作为验收 |
| F05 | 连续钓鱼在4B3B/C中自然具备 | 方向上应归入该阶段，但“自然具备”不能作为技术保证 | 在正式接线方案和验收中明确连续操作、动作收口、重复输入及旧回调隔离；不再单独立项 |
| F06 | 42/86/29等既有回归作为批次安全网 | 是必要基础，不能单独证明新业务调用迁移正确 | 既有适用回归＋本批入口/内存归属/迟到回调/保存失败验证＋Unity编译；复用已有测试设施，不新增无关测试框架 |
| F07 | 回归失败停批并差异评审 | “停止放行”赞同；不应把每次实现错误都升级成方案补审 | 原批准合同和白名单内修复、回归后继续；只有合同/范围变化或架构问题才补审。首败和修复记录保留 |
| F08 | 4B3B/C按类型直接批量推进 | 批级推进可行，但原B→C依赖不能因合并名称消失 | 先落实本范围的业务归属，再完成相应加载发布/生命周期接线；如调整原全B完成后才C的门，须在批级总方案明确裁决，不默默绕过 |
| F09 | 真实Unknown路径等风险已充分验证 | 当前查阅的材料支持真实成功链与离线故障验证；不足以据此确认文中“4C2真实Unknown路径测试” | 若保留该表述，请给具体run、故障触发和证据文件；否则改为真实成功闭环＋离线Unknown/故障分支验证，不新增真实故障注入来补文字 |
| F10 | 当前约60%，2–3天迁移、3–5天全部完成；原连续方案1–2天 | 缺少当前批次清单、工作量和风险依据，不能作为承诺或完成度结论 | 标为未经验证的粗估或删除；首批范围和实际结果明确后再估算，不用调用数量或文档数量计算完成率 |
| F11 | 4C剩余转盘等同样属于低风险批量 | 可共用批级流程，但“立即保存/消费”不能仅按调用类型当简单替换 | 在对应批级方案明确先扣费/发奖/票据/Unknown合同；普通写与交易链不能仅因都调用保存函数就共用未区分的规则 |
| F12 | 身份/tickets/4D/打包统称收尾工程 | 可归入后续安排，但未解决风险仍存在，不能据此降低验收要求 | 身份专项、tickets容量、平台与迁移政策按实际依赖保留；服务端CAS只是可选议题，不因本轮流程调整自动授权或成为必做项 |

补充F04的证据：调用事实附件明确223个位置由外部facade 212、facade内部8、SDK 3组成；仅语法解析，CallerNameCandidates为名称候选，未证明完整事件/接口/UnityEvent链。原文本扫描234行/84文件是不同统计口径。因此应以结构化 `B3DesignAudit/calls.json` 及当前源码为准，不能把文本扫描文件直接称为223条可替换任务。

## 四、建议的下一包边界

待审查会话裁决后，主会话围绕**正式KV业务接线**编制第一份批级方案。复用已有固定句柄、缓存和同步器，选择一批有关联且规则一致的业务；每条调用在同一批级表中标明上游入口、首次内存修改位置、原会话归属、失败处理和验证方法，不为每条生成独立方案。

优先级由业务交付和依赖决定，不再默认先开发v4测试许可。复杂支付/广告/立即消费链若不适合首批，可放入后续完整业务批，而不是为了凑30个混进“简单写”批次。正式默认KV、未纳入的玩法准入及B/C阶段关闭条件，须在方案中说清楚；批内通过不代表全游戏可启用。

连续操作纳入相应集成验收：前一动作已完成、后续动作正常开始、旧回调不能修改后续动作。具体实现应服务正式接线，不先投入独立测试模式的次数管理。复用已有101/102成功证据，不重复导入或为了补截图再收费。

真实账号写入仍按具体运行范围执行；单账号重启式重登、不自动热换号、固定API、Unity CLI Loop、暂不打包等要求保持。

## 五、请审查会话继续裁决

请按F01–F12给出接受/部分接受/不接受及理由，重点明确：

1. 采用批级方案审查＋批末实施复核；批准范围内的实现修复不必反复补审。
2. 以业务关联与明确归属选批，而非机械替换固定数量；B/C先后关系如何保持。
3. 连续操作作为迁移验收条件，不再开发独立v4测试包，也不宣称天然已实现。
4. 历史候选数量、测试证据和工期表述如何修正。

本意见不是要求恢复逐点繁重流程，而是把需要判断的内容集中到一个可实施、可验证的业务批中。审查会话裁决后，再统一更新入口/总TODO/开发状态/JSON的责任侧和执行边界，避免不同文档分别显示“待用户选择”“立即实施”或“候选待审”。

另有文档链接问题：流程修正裁决位于upserver根目录，其中指向同目录文件的 `../流程调整建议...`、`../阶段4B3存档候选调用扫描...` 相对链接会指向上一层，建议审查侧更新原文时一并修正。

## 六、依据

- [流程调整建议](流程调整建议-转向批量迁移模式-2026-09-28.md)
- [流程修正裁决](流程修正裁决-转向批量迁移-2026-09-28.md)
- [调用事实与分期附件](阶段4B3调用事实与分期附件-2026-09-24.md)
- [4B3分期及原B/C合同](阶段4B3分期与4B3A固定存档入口方案-待评审-2026-09-24.md)
- [101业务包关闭裁决](Gameplay101Validation/101真实闭环与药水引导修正-复核裁决与关闭.md)
- [4C2实施关闭裁决](阶段4C2实施复核裁决与关闭-2026-09-28.md)
- [被搁置的连续钓鱼候选方案](ContinuousFishing/单账号连续普通钓鱼最小方案-待评审.md)

本轮不重新封存或修改既有受审证据；上述源码定位为只读核查事实，非新的生产改动白名单。