Files
ft/CodexOutput/upserver/流程修正裁决-转向批量迁移-2026-09-28.md

4.1 KiB
Raw Blame History

流程修正裁决:下一阶段从"连续钓鱼"改为"4B3B/C批量迁移"

2026-09-28主会话按审查侧F01–F12裁决同步修正;该裁决是统一流程依据,本文不批准具体生产白名单。原工期/完成度百分比仅为未经验证的历史粗估,不作为当前承诺。B→C依赖保持;真实数据写入授权与暂不打包要求保持。

日期:2026-09-28。裁决人:用户指示独立评审侧执行(用户原话:"根据之前的内容,决定整个流程是否应该修正,然后更新文档")。性质:方向性裁决,覆盖此前候选方案排序。

一、裁决

不采纳《单账号连续普通钓鱼最小方案》作为下一阶段。该方案制备质量高(逐竿隔离合同完整),但方向错误——详见第二节。

下一阶段直接进入 4B3B/C 批量迁移,按流程调整建议的 B 级批量模式执行。

二、依据

已充分验证的能力(不需要再钓更多鱼来证明)

能力 已有证据
一次收费抛竿→扣费→原票据确认 4C1 关闭(102 首次+101 迁移档)
拉杆→收鱼→奖励保存→服务器确认 4C2 关闭(四次真实运行)
收下→返回主页→正常退出 4C2 第四次+101 闭环
新进程→新缓存→服务器恢复 4C2+101 双账号验证
迁移档完整走通 101 从 PF 导入→登录→收鱼→恢复全链
引导/面板/退出缺陷已修复 药水引导修正+点击穿透修复均已关闭

结论:单次成功链已闭环,不需重复收费证明同一次存储能力;连续操作还涉及跨动作隔离,须并入正式迁移验收,不能视为已由单次证据覆盖。

连续钓鱼方案的机会成本

该方案需要:7 个运行文件修改+v4 许可扩展+逐竿隔离合同;原1–2天估算未经验证,不作为排期依据。产出:证明"同一会话可以钓两条鱼"——这在 4B3B/C 批量迁移完成后必须明确实现并纳入集成验收,不能由定时器/生命周期接线自然推出。

真正的剩余风险不在钓鱼细节

  • 4B3B/C(以calls.json结构化候选清单为准,先分类后迁移):唯一未启动的大块,阻塞正式启用
  • P2-α 全体用户策略:产品决策,不是技术验证
  • 身份/tickets/4D/打包:各自风险、依赖和验收仍保留;暂不打包

三、指示开发侧(主会话)

  1. 搁置《单账号连续普通钓鱼最小方案》(不删除,保留为后续回归材料;4B3B/C 完成后若仍需专项验证可复用其合同设计)
  2. 立即编制 4B3B/C 第一批白名单与批级方案:
    • 以B3DesignAudit/calls.json为历史结构化基线,核当前变化、分类后按业务关联选第一批;20–40个仅为工作量参考,不凑数
    • 一份批级方案文档(不逐调用出方案)
    • 交一次独立审查(批级)
  3. 执行节奏:每批=完整批级方案→一次方案审查与裁决→连续实施→既有适用回归+本批专项验证+Unity编译→一次批末实施复核→关闭
  4. 安全门保持:回归失败先停止放行、合同内修复后继续;白名单外生产漂移停;合同/范围/架构变化补审

四、更新接手入口

以下内容应替换接手入口顶部"当前唯一有效状态":

当前有效状态(2026-09-28,流程修正裁决生效):101/102 两条真实链全部关闭。经用户确认,搁置《单账号连续普通钓鱼》候选方案,下一阶段为 4B3B/C 批量迁移(B 级模式)。开发侧应立即编制第一批白名单(按业务关联选批,20–40仅为参考)与批级方案,交一次批级独立审查后实施。流程按流程调整建议与本裁决执行。连续操作/动作收口/重复输入/旧回调隔离须列为4B3B/C迁移批集成验收条件,不再开发独立v4测试包。