Initial import of IC.Rebuild

AGENTS.md

@@ -0,0 +1,43 @@
+# IC Rebuild 开发规范
+
+适用范围：本目录及子目录。依据用户于 2026 年 10 月 11 日明确提出的要求：避免过度防御开发、过度测试和零碎发布，以可用功能推进为主。
+
+## 功能与范围优先
+
+- 优先完成用户当前需要的功能或修复，不把测试数量、已识别 Opcode 数量或框架层数当作主要成果。
+- 当前优先推进编号 8 的可测试实现。核实入口、状态 ID 转换和本地角色范围后即可做针对性实现，不等待全部协议解析或统一网络框架完成。
+- 复用已经有效的代码和直接 Hook。仅当当前功能确实需要时提取共用接口，不为假设中的未来需求预建通用队列、事务系统或大规模分层。
+- 协议分析围绕实际功能、已出现的问题和必要样本进行；不以清空未知包或解析所有记录作为继续开发的前提。
+- 原有功能删减与分期继续遵守 IC/PLAN.md。主动发送和后续业务扩展明确列项，不通过重构或测试任务悄悄扩大范围。
+
+## 保留必要边界
+
+- 对原生内存保留有效的长度、指针、对象身份和生命周期检查；维护原函数调用语义，确认关闭与卸载清理。
+- 新版本的原生布局与入口未经确认时，不直接套用旧偏移或地址；使用现有适配机制处理实际兼容问题。
+- 检查和异常处理应对应具体失败模式。不要围绕每一个理论上的异常增加多层回退、冗余状态机或重复验证。
+- 已通过验证的实现优先保持稳定；出现新证据、功能需求或实际回归时再调整。
+
+## 测试按风险安排
+
+- 原生边界、包长度与数量、调用次数、对象范围、启停与资源释放等实质风险，应有对应验证。可复用已有测试与实际样本。
+- 文案、折叠、布局等低影响可逆改动，不额外堆自动化测试；按需要进行构建或一次界面检查。
+- 新测试应覆盖具体故障或容易回归的行为，不写仅重复实现逻辑、常量或显示文字的测试来增加数量。
+- 一组相关改动完成后，运行必要检查。通过后，没有新改动、失败或未解决的疑点，不重复跑同一套检查或无目的扩大测试范围。
+- 新改动或失败确实影响既有结论时，重跑相关检查；不要为了减少测试而跳过必要验证。
+- 游戏内验证一次聚焦明确行为，提前说明操作和预期。已有样本够用时直接回放，不反复要求用户重抓或重复已经通过的场景。
+
+## 合并发布与减少用户操作
+
+- 按完整功能或一组相关修复合并发布，不每补几个协议字段或改几处文案就增加版本并要求热载。
+- 崩溃、已验证功能回归或用户明确要求及时修复时，可以单独发布。
+- 沿用已经约定的部署和备份流程，不新增没有实际必要的确认步骤。
+- 提交给用户测试前完成当前能够独立完成的分析、实现和必要检查。只提出下一步确实需要用户提供的操作或信息。
+
+## 进度与计划
+
+- 进度首先说明新增了什么可用功能、解决了什么问题、还缺什么，以及用户是否需要做一步操作。
+- 测试总数、哈希和详细反汇编依据放入相应验证记录；关键失败或验证限制仍需明确告知，不用测试数量替代功能结果。
+- 网络与维护计划中的里程碑是能力分组，不是要求提前全部建成的关卡。版本诊断和管理器整理随实际需求逐步补充。
+- 维护目标是更新后快速定位并修复受影响模块，不为追求完全自动适配拖延当前功能。
+
+相关补充计划：NETWORK_AND_MAINTENANCE_PLAN.md。后续用户明确调整优先级时，以最新要求为准。