IC.Rebuild/NETWORK_AND_MAINTENANCE_PLAN.md

IC 收发包管理器与版本维护开发计划

日期：2026 年 10 月 13 日。基线：IC Rebuild 0.1.16，国际服客户端 2026.10.06.0000.0000（向后兼容 2026.09.15.0000.0000）。

目标是依据用户提供的原版源码、作者说明和现有重建成果，完善统一收发包管理器，并建立游戏更新后的检测、适配和验收流程。本文件是后续开发补充计划；任务勾选表示对应交付物完成，不代表已经通过游戏内验收。

执行方式遵循本目录 AGENTS.md：功能优先，避免过度防御开发、过度测试和零碎发布。

2026-10-13 / 0.1.16 客户端补丁维护进展：国际服维护更新至 2026.10.06.0000.0000。备份旧可执行文件后完成新二进制全量扫描，全部 23 处特征码在新二进制中 100% 匹配成功，修正 ForcedWalkHook 签名笔误。反汇编核实 M4 主动发送通道（ReceiverSendPacket 0x1CFD120、ZoneClientSendPacket 0x1D03020、ZoneUp 0x1D72B00）、模块 36 收包（ZoneDown 0x1D72680）、模块 8 状态屏蔽（StatusSetter 0x8A6A30）及模块 2 最大加速度内部偏移完全一致。完成双版本向后兼容抽象及本地 opcodes.json 补丁配置（PingReq 137 / PingRsp 338）。详见 diagnostics/2026-10-13-patch-2026.10.06-adaptation.md。

2026-10-12 / 0.1.15 阶段 3 进展：完成 M0 统一版本适配与诊断（Core/AdaptationManifest.cs）及 M4 主动发送与请求响应事务（Core/ActivePacketSender.cs、Runtime/NetworkManager.cs）。弃用恒返回 1 的旧包装 0x4810E0，直接绑定 ReceiverSendPacket → ZoneClient.SendPacket → ZoneUp，保留真实 byte 返回码；实现 ActiveSendScope 来源标注（PluginActiveSend）、已审计业务包编码器、主线程限速队列、会话/区域门控、网络回调重入拦截与请求响应事务状态机。详见 diagnostics/2026-10-12-stage3-m0-m4.md。

范围与当前进度

原首批范围保持为 1—11、13—20、27—29、36—37，共 24 项。12 移动咏唱独立研究；38—43 保留为网络基础之后的业务扩展；21—26、30—35 继续排除。主动发送管理单列里程碑，不把它或业务自动化隐含加入原首批 36、37 的验收条件。

以本次核对到的 0.1.11 文件为基线：

部分	已有成果	尚待完成
首批功能	用户确认 1、2、3、9、10、11、13、14、15、16、17、19、27、28、29 有效	4、5、6、7、18、20 的效果确认及各模块组合、切图、卸载验收
8 状态屏蔽	已核对一种网络列表为 30 个 12 字节条目，并找到消费入口及条件性 ID 转换	转换后处理、本地对象门控、其他列表路径、标志更新与实测
36 完整采集	首轮导出 891 条：上行 534、下行 357，均有完整载荷；有过滤、暂停、缓冲、导出	性能、反复启停、切图及卸载验收
37 协议分析	该样本全部 Opcode 已具名，679 条可解析已核实字段，8 组 Ping 已配对	212 条已命名记录尚无解析器；已支持包也未必解释全部字段
主动发送	原 NetRe 提供入口和接口雏形	新工程尚无经过完整验证的通用发送封装与事务管理
自动维护	已有部分版本门控、本地与在线映射校验	统一适配清单、更新差异检查、模块失效报告与恢复流程

本份样本全部具名不代表所有协议已识别。66 项离线测试通过不替代原生调用和游戏效果验收。后续实施时先读取最新 STATUS.md、VERIFICATION.md，保留主线程在本计划之后取得的成果。

原始资料如何复用

资料	可复用的设计或证据	实施要求
IC/NetManager.cs	NetRe、发送入口 Hook、SendPackt、IGamePacket、PreSend/PostSend 委托声明	恢复接口意图，补齐实际订阅调用；逐项核对发送对象头、长度、参数和有效期
IC/OnlieOpcode.cs	按客户端版本加载在线映射，并结合本地识别	沿用版本隔离，补充来源、证据、冲突和失效状态
IC/UpPacketStructs.cs 与 DownPacketStructs.cs	消息名称与历史字段布局	以当前原生读写和样本修正，不直接按旧 Size 分配或复制
IC/新建 文本文档.txt	收发时间轴、交互流程分析、后续业务扩展；结构体和 Opcode 维护提示	先证明流程与结果，再实现自动化；维护成本作为模块设计约束
两份 I-Ching-GL DLL	已可靠读取的类型、接口、依赖差异	受保护的方法体不作为已还原算法的依据
IC.Rebuild 当前实现	完整采集、只读副本、过滤、解析、版本映射、离线回放与资源清理	在现有代码上逐步整理，保持已有功能行为和已验证直接 Hook

原 NetManager.cs 中的发送前后委托尚未形成完整事件调用流程，泛型发送也不能证明所有上下行结构体都已具备正确发送封装。原作者列出的扩展方向需要各自的业务状态、请求响应和结果验证。

管理器职责与数据流

建议形成以下协作关系，具体类名可结合现有工程调整：

部分	主要职责	验收关注点
版本适配层	根据客户端、API、依赖和签名证据选择适配配置	未匹配配置不能静默使用旧指针、偏移或 Opcode
原生接入层	管理收发 Hook、原函数调用和资源释放	每条原生路径的参数、返回值、调用次数与有效期明确
消息分发层	向观察者发布自持有数据，管理订阅和取消	单个订阅异常不破坏原生调用；业务订阅不受日志筛选影响
协议层	按版本、方向、消息类型解析与编码	载荷、IPC 头、原生发送对象分开；未知字段不补猜测值
发送调度层	排队、过期、取消、限速、连接与场景检查	在核实的线程和会话中调用；切区后不发送过期请求
请求响应层	用有依据的标识关联响应并报告结果	发送入口成功不等于服务端确认；无依据时不强行关联
记录与诊断层	时间轴、来源、过滤、失败原因、统计及导出	区分游戏自身发送、插件发送、原始载荷与已还原字段

收包流程：原生接入取得有效数据 → 在有效期内复制 → 标注版本和处理阶段 → 分发给订阅者与记录器 → 按需解析。日志的方向与 Opcode 过滤仅控制记录和显示，业务订阅使用自己的条件。

发包流程：业务请求 → 版本与场景检查 → 对应消息编码器 → 构造原生发送对象 → 在合适线程调度 → 记录调用结果 → 在有协议依据时等待响应确认。

收包观察与收包修改分开。8 如需在状态 ID 转换后处理，应使用对应原生阶段的专用适配；不能让普通日志订阅者取得可长期保存、任意修改的原生指针。

实施里程碑

M0 统一版本适配与诊断

• 为现有原生模块和协议建立适配清单，列明已核对版本、依赖、签名、字段与证据。
• 对接现有模块管理器，区分缺实现、版本不符、签名未匹配、多重匹配、运行失败和待验收。
• 明确未知版本的行为：未证明兼容的原生模块保持不可用；配置、文件导出和离线分析尽可能保留。
• 增加只读检查结果，显示哪个模块受哪项变化影响。

验收：模拟版本不符、签名缺失和多重匹配，受影响模块无法错误启用；其他独立模块不因单项失败被误标为失效。签名唯一匹配仍需函数语义核验。

M1 整理统一收包与发送观察接口

• 将 NetworkCapture 的原生接入、协议读取和日志写入职责分开，保持当前完整采集结果。
• 建立可取消的收包、发送前观察和发送后观察订阅，规定顺序、线程及异常处理。
• 分离日志过滤与业务订阅，避免筛选窗口记录导致后续模块漏收消息。
• 为消息标注方向、客户端版本、记录来源、原始或已还原阶段、完整性及失败原因。
• 初始仅开放只读观察和取消订阅。没有开放取消或替换原生包；该能力若后续需要，另行核实返回语义、有效期和重入。

实现与接口约束见 diagnostics/2026-10-11-network-manager.md。891 条离线回放逐条载荷一致，不等于新管理器已完成游戏内验收。

验收：原 891 条样本回放不回退；切换日志过滤不影响业务订阅；反复订阅、取消和卸载不残留回调；订阅异常不改变原函数应有行为。

M2 完成状态处理依据并推进编号 8

• 核对单列表、双列表、其他列表变体及录像回放的调用差异（0.1.14 进一步核实 DOWN_StatusEffectList 30×12B 与 DOWN_EffectResult 4×16B 状态项均汇入 StatusManager.SetStatus 0x8A6BF0）。
• 明确状态 ID 转换发生的阶段，选择转换后且仍有边界依据的处理入口。0.1.12 采用 SetStatus，槽位 0—59，不访问原始网络列表。
• 用当前有效快照确认本地角色及其 StatusManager，覆盖对象消失、切区、重登和指针复用（离线已验证，待游戏内验收）。
• 核对状态条目更新与相关标志重新计算，明确屏蔽的实际效果范围。保留原 setter 的通知、返回值和批量/单次刷新；只保证经过该入口的本地后续更新，实际效果仍待下项验收。
• 从一个可复现的目标状态开始实测，再逐项扩展已审计名单。

验收：目标状态效果有记录；未选状态与其他角色不受影响；关闭后恢复正常处理；切图与卸载无残留。此模块不以主动发包能力完成为前提，也不把本地状态处理表述成服务器状态已删除。

M3 扩展协议覆盖并收尾首批验收

• 按消息类型整理 212 条尚未解析记录的清单，优先处理首批功能及后续选定业务实际需要的类型。
• 补动作结果、状态和事件消息的已核实字段，注明字段来源与未解释部分（0.1.14 完成 capture-018.jsonl 全部 891 条解析及 27 组动作请求响应配对）。
• 需要新增样本时列明缺失场景、采集动作和期待消息，避免反复要求泛化抓包。
• 完成 4、5、6、7、18、20 的效果验收，以及首批模块组合、切图、退出登录和卸载检查。

验收：支持类型对正常、截断、错误计数和版本不符有明确结果；未知包保留原始记录。建立可重现流程的证据，不以本份样本的未知数为零宣称协议全部完成。

M4 恢复主动发送与请求响应管理

• 对照原 NetRe 核实当前发送入口、真实参数及返回含义（0.1.15 弃用恒返回 1 的 0x4810E0，改用 ReceiverSendPacket 0x1CFD140 → ZoneClient.SendPacket 0x1D03040 → ZoneUp 0x1D718C0）。
• 为首个选定消息编写独立编码器，明确业务载荷、原生发送对象、长度和缓冲区所有权（UP_ActionSend、UP_ClientTrigger、UP_EventStart、UP_EventFinish* 8 档、UP_EventAction* 8 档）。
• 优先从已核实的游戏接口调用方式接入，统一版本检查、诊断和发送来源标记（PacketOrigin.PluginActiveSend）。
• 加入有界队列、取消、会话标识、过期时间及调度线程约束，避免从接收回调中直接递归发送。
• 区分排队、已调用原生发送、原生拒绝、收到确认、超时和取消；取消排队不等于撤销已发送请求。
• 仅在消息关联依据和重复操作语义明确时加入重试，不统一重放所有捕获包（当前不自动重发任何原生调用）。

验收：编码与原生对象构造有边界测试；实际场景能确认预期结果；断线、切区、重复操作、取消和卸载行为明确。发送接口不能以单个 bool 冒充整个交互流程成功。

M4 是单列的恢复里程碑。其接口设计可以与 M1 并行，但真实调用依赖 M0 和相应消息契约核实；它不阻塞原首批记录、解析和状态处理的独立交付。

M5 进入选定业务扩展

38—43 继续作为候选，不自动全部开工。每次选定一项后，再明确业务状态、请求响应链、成功依据、超时、取消和异常恢复。作者提到过某项能力，只说明存在参考方向，不等于当前客户端与服务器已经验证可用。

游戏更新维护流程

目标是更新后自动发现问题、辅助定位、按模块适配。不能承诺客户端每次更新后无需核验即可恢复全部功能。

每版本保存的适配信息

信息	保存内容
客户端	区服、完整版本、核对过的可执行文件标识或哈希
运行依赖	Dalamud API 与程序集版本、FFXIVClientStructs 版本、关键委托及字段布局
原生入口	签名、匹配数量、函数参数、用途、支持的模块和核对记录
协议	版本、方向、Opcode、名称、长度规则、字段和 ID 转换阶段
映射来源	远程、本地文件、原生核对或样本证据，以及冲突处理结果
验证状态	构建、离线回归、具体游戏场景、限制及结果日期
发布与回退	包版本、校验值、配置迁移说明和前一版本备份

现有 CurrentProtocolEvidence 中按版本补充且不覆盖显式映射的原则继续保留。发现显式映射与新证据矛盾时记录冲突，不能静默改名后伪装没有差异。

更新后的执行顺序

1. 记录新的游戏与依赖版本，保留上一份适配清单、发行包和必要配置备份。
2. 检查插件能否在新 API 中加载；若 API 不兼容，先由外部构建和程序集检查定位问题，不能依赖插件内面板完成诊断。
3. 只读检查签名是否缺失或多重匹配、委托及结构是否变化，生成受影响模块清单。
4. 检查新版本 Opcode 映射。没有匹配映射时不套用旧名称；采集本身也须通过对应原生布局检查后才可启用。
5. 对长度异常、计数异常、解析失败率增加及 ID 转换变化做差异分析，按需要安排少量针对性样本。
6. 修复对应模块，跑相关离线回归，并记录新的原生和协议依据。
7. 在游戏内按模块验证，再检查组合、切图和卸载；逐项恢复适配状态。
8. 构建发布并核对部署文件，保留变更说明与待验收项。

游戏版本没变但 Dalamud 或 FFXIVClientStructs 更新时，也要检查相关依赖差异。版本门控不能只看 API 主版本。

可自动完成与必须核验的边界

可自动完成	不能仅凭自动检查断言
版本与哈希差异、编译结果、程序集元数据差异	原生函数的行为仍与旧版相同
签名匹配数量和候选定位	匹配唯一就代表参数和语义正确
映射冲突、长度、数量和解析失败统计	包名称及未知字段的业务含义正确
已有脱敏样本回放、错误输入与生命周期测试	新客户端现场表现与服务器结果正确
打包校验、备份和变更报告	旧 DLL 能在新游戏上正常使用

发生更新不应重写已验证的所有功能。继续保留便于维护的直接 Hook；通过依赖关系只处理受到变化影响的部分。

开发交付与主线程衔接

• 当前按用户最新要求推进收发包管理器：M1 已交付只读实现，下一步沿 M4 核对实际发送封装与首个消息契约，按具体需求再接入主动发送。编号 8 继续待实测，M3 围绕具体功能安排解析，M5 按后续选择进入。不得为了先建成全部基础框架而阻塞可用功能交付。
• 不预设新版本号或日历工期。每个里程碑以证据、实现、相关测试和游戏验收状态作为交付依据。
• 诊断报告保存必要的长度、计数、类型和结果；共享测试使用合成或脱敏数据，不复制无关聊天、角色身份和完整会话数据。
• 每次交付更新实施状态和验证记录，明确已实现、待实测、受限及未实现内容。
• 相关改动合并发布，必要检查通过后无新问题不重复验证；现有样本够用时不要求用户重新采样。进度优先报告功能结果，详细测试数量留在验证记录。
• 该文件独立保存旁支方案；现有 IC/PLAN.md、源码、配置和部署未因创建本文件而改变。

相关依据：IC/PLAN.md、IC.Rebuild/STATUS.md、IC.Rebuild/VERIFICATION.md，以及 diagnostics 中的双 DLL 对比、完整采集、capture-018 回放、Opcode 核对和状态处理记录。