阶段4最小真实玩法闭环方案独立审查（R1）

日期：2026-09-24。审查者：ZCode会话。

独立性声明：未参与R1方案、核查文档编写（均为主会话编制）与任何实施；此前参与为4B3A等审查。本轮只读＋hash计算，仅新增本报告。

受审版本核对

阶段4最小真实玩法闭环方案受审基线-2026-09-24.json共70项，逐项重算SHA256——全部一致。源码核查文档的关键断言本审查独立复核属实：SubBoostrap.cs:88 AddComponent（模式必须在其前锁定✓）；SavePlayerData先Publish<PlayerData>事件再全量序列化19槽＋vipL/ld/ad/bd/ct/rt（确为整档NewPlayerDataDic而非独立EquipRodID键✓）；SetEquipRodID→红点→SavePlayerData链；OnClickEquip入口；LoginCore仍PF先行的现状。

总结论

接受。 两项分别回答：范围调整合理；方案足以批准白名单编码（附两项P2裁决确认，均为裁决/澄清级，不需重报方案）。

一、范围调整是否合理：合理

用户已确认"真实游戏、单账号、重启式重登"优先——R1把原B/C中最小必要子集（facade统一路由、单装备可等待保存、生命周期关闭）合并为一次接线，以"一进程一次会话"的硬合同换取免建跨账号回调框架——这是正确的工程取舍：首轮唯一会话内固定handle使旧回调归属问题在该模式下不存在（进程内二次发布被拒），而非被掩盖。
复用而非重建：4A Bridge（session不拥有权合同天然支持借用apiSession）、4B2 Schema/Transaction/31绑定、4B3A四入口、原40秒调度位、原序列化单份——无重复实现、无第二套加载器/定时器/队列。
三条路线否决理由成立（全量B/C首跑晚；独立验证面板非用户选择）。
边界诚实：Editor专用模式、Player不开放、默认PF不变、PF仅身份不碰UserData、消费/4C不启用、P2-α/G4保持——未把"测试账号"当作放宽跨会话或正式数据风险的理由。

二、方案是否足以批准白名单编码：足以（附裁决确认）

逐项核查（§7提示词要求）：

启动先于PF Awake ✓：§2.1在AddComponent前读许可固定模式；核查文档证实:88位置；"已启动旧实例不允许热切"防域重载后二次进入。
apiSession直接借给4A Bridge ✓可行：Bridge不拥有/不Dispose session（4A合同）；与CustomServerMgr.UseAccountSession共享同一CookieContainer（两HttpClient并发共享线程安全容器，只读使用）；Logout顺序合同（§4先Bridge排水后session）与401禁自动重认证（§4）闭合了两处既有风险（核查文档点名的Logout直接Dispose与401后台重登）。
31真实对象绑定与M31准入 ✓：Bindings只做映射不复制算法；真实容器在FishingStage.InitData前尚未启动玩法Init——满足4B2事务"未启动容器"前提；M31运行时准入不放宽B2验证限制。
初始化自动写与PF分离 ✓（诚实迭代策略）：记录登录→装备全部KV变更key并与fixture允许范围核对，超范围停止run留差异裁决——不预设全部副作用已知；无PF回退/双写红线明确。
序列化单份复用 ✓：提取核心、旧void接口调用同核心——白名单行明确"字段/格式/经济算法不改"。
准确票据与装备UI ✓：首次内存变更前捕获handle、取该次真实票据、Superseded≠确认、防重入、失败不显示云端成功——合同正确（细化见P2-1）。
进程重载限制 ✓：CreateNew标记＋进程ID/启动时间命名、域重载/重复Play拒绝、新进程才可重占——机制可靠（崩溃残留标记不误伤新进程）。
Logout/401排水 ✓：同步撤销facade准入→generation失效→Bridge.Close排水→才Dispose session/清Cookie；ShutdownRegistry有界观察沿用；退出不发起Flush、不把未确认记作成功。
Editor模式数据授权与4C边界 ✓：专用fixture/备份/恢复前置声明、"正式老用户空KV不当新档"、消费路径不启用并遇即停——不构成4C通过或普通用户开放承诺。

白名单评估：14项文件与上述接线一一对应、无越界面；新增两个文件的职责清晰（GameplayLoop单次状态/拥有权、Bindings映射）；禁改清单保住全部已关闭底层。

发现清单

P2-1｜装备链多票据的等待规则需一句裁决级澄清。 SavePlayerData先Publish<PlayerData>事件（订阅者可能在事件中再触发保存产生额外票据/键），装备入口"取该次NewPlayerDataDic对应票据"在嵌套写下可能不是水位内全部写。最小澄清建议：装备成功判定＝该次票据Confirmed且本run键日志中装备链新增写集合与fixture允许范围一致（§2.3已有键核对，补一句"若装备链产生多张票据，等待该链全部票据或以水位Flush汇总为准"）。不需要重报方案，检查点2落实施说明即可。

P2-2｜真实运行的数据授权是显式前置，需在编码批准时同步确认归属。 §6已声明"无合适数据先交付fixture准备内容待用户确认"——建议主会话裁决时明确：专用测试账号选择、全档fixture的备份/恢复责任人、允许写入键范围清单，与P2-α真实数据专项的边界关系（专用可丢弃账号≠存量真实档迁移授权）。编码可先行，真实PlayMode验证待此确认。

P3-1：SavePlayerData核心提取时Publish<PlayerData>应保留在旧void接口原位置（核心不含Publish），避免改变订阅者读取时序——建议写入检查点2实施说明。

P3-2：run-control标记文件跨崩溃累积——建议Setup入口提供只读"历史标记列表"诊断（不提供删除旁路）。

P3-3：暂缓发布API成功事件期间，IsApiServerLogin/IsLogin依赖InternalId——实施时断言此窗口内无外部依赖这两个属性的路径被触发（若有则记录为差异）。

残余限制

首轮单账号硬合同牺牲进程内重试（用户已接受）；热换号、全B/C跨账号、消费语义（4C）、身份迁移、tickets长期历史、P2-α、4D/G4均保持未启用；PlayMode真实写待本方案裁决＋数据授权后执行。本报告仅方案结论，不构成实施完成或4B3/B/C/G4通过。

结论

接受R1方案。 范围调整合理、方案足以批准白名单编码；P2-1/P2-2随主会话裁决落实施说明/授权确认后即可按检查点0–3推进。建议交付后按既有模式做独立实施复核。

6.5 KiB Raw Blame History Unescape Escape