68 lines
9.9 KiB
Markdown
68 lines
9.9 KiB
Markdown
# 101真实玩法与迁移档恢复：完整业务包方案
|
||
|
||
2026-09-28，主会话；状态：待一次完整独立方案评审。**目标：101已导入的历史档能真实登录，完成一次普通抛竿、拉杆收鱼、收下奖励，保存并在新Unity进程恢复。** 本方案默认生产代码零改动，复用已关闭4C2的运行入口。不能把102已成功视为101也已通过。
|
||
|
||
## 1. 范围与执行方式
|
||
|
||
- 一个业务包包含准备、登录、玩法、保存、正常退出、重启恢复及对账；不再把备份、许可、运行准备各自拆成独立评审阶段。
|
||
- 完整方案评审后由主会话核相关hash、逐条裁决；取得本包一次运行授权后连续执行。一次授权覆盖下述备份、两个游戏进程和最多一次付费抛竿，不逐步重新申请。需用户手动操作或启动CLI时只请求必要协作。
|
||
- 内部检查点写开发日志。完成后一次汇总交付复核；发现明确超出本方案的业务改动，才提交针对性补充方案。
|
||
- 固定 `http://s101.local:18080/`，仅Unity CLI Loop，不用UnitySkills、不打包。游戏只用101，102仅现有备份工具附带登录/Get，不在游戏使用或写102。
|
||
- 不重导、不合并、不补发、不更改引导/活动/随机鱼/装备以绕过门。生产源码、配置、场景、预制体均不改；允许在本业务证据目录保存只读采样脚本、命令结果、许可归档和对账结果，不新增通用框架。
|
||
|
||
## 2. 已知事实和前提
|
||
|
||
导入已由 [D5裁决](P2AlphaImport101/D5-执行复核裁决与关闭.md) 限定关闭。历史参考是 `P2AlphaImport101/runs/20260928T073630Z-345b3ee1f47a419abf876bf5b5506d89/after.json`，55键逐值等于固定PF源。该文件只用于对比，不直接作为游戏permit的backupPath：现有许可要求备份位于 `KVGameplayLoopTests` 下。
|
||
|
||
同run/account.json证明NewlyCreated=false、InternalId=2、CreateTimeUtc=2026-09-16T12:58:05.860603Z；不能当成刚创建的新玩家。历史主档等级62、金币36550472、体力7275、装备20001、地图102、倍率索引3；实际倍率、活动和玩法资格必须在运行时读取，不能根据旧档推定。FishingChallengeData历史值为字符串null；两类历史空态兼容已经通过独立复核。
|
||
|
||
`KVGameplayLoopSetup`已有101/102许可支持；v3负责一次钓鱼，v1负责恢复登录。游戏登录仍先执行PF身份登录，再执行s101登录和KV加载，存在PF域名解析依赖；不能宣称本包游戏完全不访问PF。PF存档写入不在本包授权范围，发现即停止并调查。恢复登录可能产生既有登录保存/跨日写，不能称整个恢复进程只读。
|
||
|
||
## 3. 备份、许可与数据边界
|
||
|
||
复用锁定的 `P2AlphaImport101/D1-bin/Preflight.dll --backup-101-102`，从项目根运行。DLL SHA256=`AAA1276630E8633C131072DDF638639B92F60134A0425E17616A4A5A2A436607`，355328字节。禁止调用任何import分支。每轮备份为101/102各1登录+1Get，无KV Set/Delete；登录自身仍有账号元数据副作用。
|
||
|
||
计划四轮完整备份：S0游戏前、S1登录稳定且尚未抛竿、S2收下并正常退出后、S3新进程恢复并正常退出后。成功路径合计8登录+8Get用于备份，另计两次游戏登录、游戏加载Get和所有实际保存Set；分开记录，不能把工具计数当游戏总请求数。失败只补必要的一轮状态取证，不自动重复业务动作。
|
||
|
||
S0必须55键与D导入after原值一致，身份/关键档/配置匹配且解码有效；不一致则保留现状，说明差异后停止本次既定运行，不覆盖历史进度。保存S0原件、hash、键表。v3许可使用S0下101.json和它的55键集合；这是允许现有登录链访问/保存已备份键的上限，不是允许点击55种业务。新键写入保持原拒绝规则。
|
||
|
||
允许的游戏动作只有登录、一次普通付费钓鱼、收下、退出。钓鱼期间保留现有更严格写门：NewPlayerDataDic、实际地图鱼档Map_5_{area}、BattlePassRecordTask、MiniBPKeyNew、EventLuckGameRecord、EventLuckMagicPlayfabData，且必须在S0键集中。S0→S1的登录规范化/跨日差异单列来源，不混为钓鱼奖励；出现无法解释的键变化或写入则停止，不扩大白名单。未知/未消费键应原样保持。
|
||
|
||
用户运行确认时需保持101其他客户端停用直至本包结束；不沿用已结束的导入15分钟窗口。102不要求停用，其附带快照只报告观测值，不能把其他客户端可能产生的变化归于本次101游戏。
|
||
|
||
## 4. 连续执行步骤（内部检查点，不是五次评审）
|
||
|
||
| 检查点 | 连续执行内容 | 通过证据 |
|
||
|---|---|---|
|
||
| 0 开始 | 裁决方案、记录本包授权；核焦点hash、实际API、Unity空闲/无活动permit；保存旧claims清单；读取S0。使用无旧本包claim的新进程，必要时正常关闭旧进程再启动。 | 批准范围、S0、进程身份、原claims、CLI状态齐全。 |
|
||
| 1 首次登录 | PrepareFishingRewardPermit(101,S0,55键)；一次Play，等待登录/受控加载/首页稳定。禁止先操作签到或抛竿。采样游戏状态、准入环境、保存状态，读取S1并完成登录差异归因。 | Ready=true/Error为空、加载成功；登录保存确认；S1与运行时主档相符。 |
|
||
| 2 一次玩法 | 主会话完成动作前采样后才通知用户：手动抛竿→拉杆→收鱼，成功停在奖励界面；失败不重试。记录实际鱼/装备/地图/倍率、扣费和奖励票据、奖励画面/数据后，再协作点击收下返回首页。 | 仅一次付费动作；原扣费票据确认；fishing-reward-confirmed先于presented；收下回首页；原票据与最终值可关联。 |
|
||
| 3 保存退出 | 等既有保存确认，经QuitStage正常退出并确认closed/drained；归档v3许可，保留claim。取得S2并对账，再正常关闭Unity、确认旧进程已退出。 | 不靠强制Stop/杀进程模拟退出；未确认票据为0或有明确失败终态；S1→S2业务差异可解释。 |
|
||
| 4 重启恢复 | 新进程、S2的101备份建立v1许可，登录且不操作玩法/领奖/装备；核对恢复值，再正常退出，取得S3、归档许可和证据，汇总交付。 | 恢复金币/体力/鱼档/任务进度与S2一致；登录附带变化单独归因，最终无活动permit、旧新claims保留。 |
|
||
|
||
进程退出有场景保存对话框时请用户处理，不强杀；CLI未连接时请用户Start Server，不无限轮询。这些是执行协作，不追加方案轮次。游戏失败后的安全退出也走已有保存/drain；不能为了凑齐闭环重建许可重扣一次费用。
|
||
|
||
## 5. 必须保留的准入与失败处理
|
||
|
||
复用 `UserService.KVFishingReward.cs` 的全部实际门：普通付费鱼、非免费/重试/决斗/固定列表/活动类型，无特殊鱼技能；无冲突引导、巡游/收集目标/存钱罐/砍价/进行中挑战，频次与倍率/刺鱼解锁合格；事件配置和Guidance投影匹配。自然鱼只在动作中选择，事先不能保证抽中合格鱼；拦截照常停止，不能修改随机结果。
|
||
|
||
PF解析失败、账号不符、加载失败、配置漂移、准入拒绝、并发迹象、Set失败/Unknown或写门拒绝：保存现有日志和快照，停止后续玩法。扣费已确认而奖励失败则如实记账，不自动补发/重试。服务器结果不明不重放Set。快照也失败则明确证据缺口，不当作没写入。恢复失败不把S0重新导入。
|
||
|
||
本方案不授权任意故障修复代码。若查明必须改业务逻辑，集中记录实际阻塞及最小差异，完整评审补充后再改；一般CLI参数、证据采样或日志路径修正按原范围处理并记日志，不单独开方案。
|
||
|
||
## 6. 验收和交付
|
||
|
||
1. 101实际加载既有55键档，关键运行时数据与S1一致；历史null不再抛异常；未回退空档/PF旧进度。
|
||
2. S1是在动作前冻结；S1→S2核对体力/消费累计、金币、鱼数量/重量、钓鱼次数和实际任务变化，关联扣费/奖励票据与服务器结果。获取到公式输入才做独立重算；缺项如实列明，不能用同一结果自证公式正确。
|
||
3. 奖励确认后显示，收下真实回首页；S2保存成立，新进程恢复成立，S3差异有归因。登录跨日变化不能掩盖玩法未保存。
|
||
4. 无第二次付费、无导入/覆盖102、无放宽门/删claim/打包；所有非预期业务操作（如误点签到）记录，不能标成纯净单动作验证。
|
||
5. 一份交付记录汇总实际命令、进程、4快照、票据/日志/关键截图、逐键对账、授权与边界、缺口；一次独立执行复核后主会话关闭。本包最多证明101这条真实链，不代表26模块外键、全活动、热换号、完整4B3B/C或G4完成。
|
||
|
||
证据放在 `CodexOutput/upserver/Gameplay101Validation/`，运行产生的原有permit/run/backup沿用现有目录并在交付索引引用，不复制庞大历史材料。受审hash仅冻结本方案、直接依赖及历史参考，见同目录 `review-hashes.json`；共享状态/日志不纳入冻结清单，更新检查点无需滚动重封全部项目。
|
||
|
||
## 7. 交给评审AI的提示词
|
||
|
||
请独立审查本完整业务包，先核 `Gameplay101Validation/review-hashes.json`，再核对涉及源码与4C2既有闭环。重点检查：101既有账号与55键备份；v3/v1边界；PF身份依赖；登录写和钓鱼写的区别；动作前S1；一次扣费与奖励/退出确认；新进程恢复；备份工具附带102只读；失败后不重导/重放/绕过准入。
|
||
|
||
给出通过/有条件通过/不通过，逐条问题、严重级别、依据与最小修订。只将真实阻断项作为开工条件，不因文档样式或内部检查点另设实施前复核阶段。只读审查，不运行Unity或正式接口，不修改主会话共享文档。请只落盘 `Gameplay101Validation/完整业务包独立方案审查.md`。此次没有新生产代码，方案批准后直接连续运行并统一复核；不得假设未知运行结果已经成立。
|