57 lines
6.5 KiB
Markdown
57 lines
6.5 KiB
Markdown
# 阶段4最小真实玩法闭环方案独立审查（R1）
|
||
|
||
日期：2026-09-24。审查者：ZCode会话。
|
||
|
||
**独立性声明**：未参与R1方案、核查文档编写（均为主会话编制）与任何实施；此前参与为4B3A等审查。本轮只读＋hash计算，仅新增本报告。
|
||
|
||
## 受审版本核对
|
||
|
||
`阶段4最小真实玩法闭环方案受审基线-2026-09-24.json`共70项，逐项重算SHA256——**全部一致**。源码核查文档的关键断言本审查独立复核属实：`SubBoostrap.cs:88` AddComponent<PlayFabMgr>（模式必须在其前锁定✓）；`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提示词要求）：
|
||
|
||
1. **启动先于PF Awake** ✓：§2.1在AddComponent前读许可固定模式；核查文档证实:88位置；"已启动旧实例不允许热切"防域重载后二次进入。
|
||
2. **apiSession直接借给4A Bridge** ✓可行：Bridge不拥有/不Dispose session（4A合同）；与CustomServerMgr.UseAccountSession共享同一CookieContainer（两HttpClient并发共享线程安全容器，只读使用）；Logout顺序合同（§4先Bridge排水后session）与401禁自动重认证（§4）闭合了两处既有风险（核查文档点名的Logout直接Dispose与401后台重登）。
|
||
3. **31真实对象绑定与M31准入** ✓：Bindings只做映射不复制算法；真实容器在FishingStage.InitData前尚未启动玩法Init——满足4B2事务"未启动容器"前提；M31运行时准入不放宽B2验证限制。
|
||
4. **初始化自动写与PF分离** ✓（诚实迭代策略）：记录登录→装备全部KV变更key并与fixture允许范围核对，超范围停止run留差异裁决——不预设全部副作用已知；无PF回退/双写红线明确。
|
||
5. **序列化单份复用** ✓：提取核心、旧void接口调用同核心——白名单行明确"字段/格式/经济算法不改"。
|
||
6. **准确票据与装备UI** ✓：首次内存变更前捕获handle、取该次真实票据、Superseded≠确认、防重入、失败不显示云端成功——合同正确（细化见P2-1）。
|
||
7. **进程重载限制** ✓：CreateNew标记＋进程ID/启动时间命名、域重载/重复Play拒绝、新进程才可重占——机制可靠（崩溃残留标记不误伤新进程）。
|
||
8. **Logout/401排水** ✓：同步撤销facade准入→generation失效→Bridge.Close排水→才Dispose session/清Cookie；ShutdownRegistry有界观察沿用；退出不发起Flush、不把未确认记作成功。
|
||
9. **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推进。建议交付后按既有模式做独立实施复核。
|