e6f8c0e596
## 新增两步（原五步 → 七步）
**[6/7] 反射名次表** —— 调 gen_names.py 生成
names.json（named 形态）与 names-intermediary.json（intermediary 形态）
**[7/7] remap named → intermediary** —— 三步：
7a. 复合出 named→intermediary 的 SRG（gen_intermediary_srg.py）
7b. 造一个 **intermediary 形态的 client jar** ← 继承查找的输入，缺它不行
7c. 从它生成继承映射（-H），再用 -h 把我们的 classes remap 过去
## 为什么必须 remap
实 mod（Iris/Sodium 等）的 mixin 注解写的是 **intermediary** 名且不带 refmap。
跑 named 时 42 个 mod 的 464 处 mixin 全部找不到目标（实测）。
⇒「mod 要 intermediary」与「我们的产物是 named」在同一 JVM 互斥，
解法是把**我们的产物** remap 过去（非通用数据由 extern 名次表解决）。
## gen_intermediary_srg.py 的两个实测坑（不处理会出错且症状误导）
① **描述符必须转**。mappings.srg 的 MD 行两侧 desc **都是 official 形式**：
MD: enn/Z ()Laki; net/.../Minecraft/getResourcePackRepository ()Laki;
左 desc 必须转成 named、右转成 intermediary。
只改类名不改 desc 的症状：**类改名成功了、方法却没改** → NoSuchMethodError。
② **必须生成继承映射**。SpecialSource 按 owner+name+desc 精确匹配、
**不查继承链**；而 MC 里大量方法继承自父类/接口
（如 ClientPacketCache.registryAccess 实际声明在 RegistryAccess）。
不带它漏 ~60 处（实测：60 → 12，且剩余 12 全是 JDK 继承方法、
record component、和我们自己那个不该改名的桥类）。
## 另修三处
- **SS_CP 提到全局**：原来在第 3 步的 if 里定义，而第 7 步也要用它 ——
若 client-named.jar 已是最新，第 3 步不进入 if ⇒ 变量为空。
- **LoaderBoot 纳入编译**：launcher_fabric 从没被 build.sh 编译过，
运行期报 ClassNotFoundException: LoaderBoot。
- **common/ 纳入编译**：mcfold/McfoldNames.java 在 common 下，
漏了它 ⇒ remap 后产物里没有这个类 ⇒ NoSuchFieldException（实测踩过）。
- **natives 平铺**（见上一批提交）：jar 内是 linux/x64/org/lwjgl/<mod>/lib*.so，
而 LWJGL 按**文件名**找库 ⇒ 保留包路径会 UnsatisfiedLinkError。
## 产物清单（落在内容根 .mcfold/）
classes/ 裸启动 / named
classes-intermediary.jar 加载器 / intermediary
client-named.jar · client-intermediary.jar
names.json · names-intermediary.json
named2intermediary.srg · inheritance.map
classpath.txt · natives/（平铺）· fabric/（8 库）
mcfold — Minecraft 折叠层（净室 Python 实现）
按用户 2026-09-25 定向：净室 Python 实现，替代 Node/mineflayer 栈， 使产物可打包分发（无 Node 运行时依赖）。
架构
底层 mcfold（本工程，Python）
├─ 按实例文件夹读版本 → 自动选协议（P1 已完成）
├─ 声明式 protocol.json 解释器（protodef）
├─ 世界模型（chunk/方块，含 mod 注册表）
└─ 触发截屏 → 调脚手架 → 官方渲染 jar
中间 可包装为不同 agent 的插件
上层 面向 homeagent 的 Go 包装（复用现有 plugin.go 形状）
关键实测事实（决定设计）
| 事实 | 证据 |
|---|---|
| 实例文件夹 = 完整 MC 客户端安装 | versions/<id>/<id>.json + .jar |
| 加载器 id 不是协议版本 | minecraft-data('1.20.1-forge-47.4.0') → FAIL，必须走 inheritsFrom |
| protocol.json 是声明式的 | varint/pstring/mapper/switch 全是数据，非代码 |
| 因此协议不需重写，只需解释器 | 111 个 play 包由同一份 JSON 驱动 |
| 1.20.1 不在网络上传递方块注册表 | codec 仅 6 类，无 block ⇒ mod 方块必须另寻途径 |
| 1.20.2+ 有 configuration 阶段 | 会发 registry_data ⇒ mod 方块可行的版本分界 |
进度
- P1 按文件夹解析版本（
mcfold/version.py，6 项回归全绿） - P2 声明式 protodef 解释器（
mcfold/protodef.py） 真实握手字节解码通过（proto=763 / login success / play 包路由） - P3 最小客户端 + 跨实现互操作（
mcfold/client.py） Python 客户端 ←→ Node 服务端握手成功（两边独立实现，最有说服力）
已证实的结论
| 结论 | 证据 |
|---|---|
| 协议不需重写，只需解释声明式 JSON | 111 个 play 包由同一份 protocol.json 驱动 |
| Python 客户端能真连真服 | Node 侧日志 SERVER_GOT_LOGIN username= PyProbe |
| 协议号由实例文件夹决定 | 1.20.1/version.json → 763 |
| 区块格式必须自己解（协议层是声明式，但 chunkData 是不透明 buffer） | protocol.json 里 chunkData 只声明为 buffer |
| Python 解码器能解独立实现产出的区块 | prismarine-chunk 产样本 → 4/4 方块命中 |
| mod 方块在本机注册表里显式 unknown，而非静默错配 | state 99999 -> unknown(99999) |
进度（续）
-
P4 区块解析（
mcfold/chunk.py，11 项回归全绿） 位打包 / 单值·本地·全局调色板 / 生物群系 section / 世界边界 关键行为：越界 state id ⇒unknown(id)（对照 mineflayer 的静默错配） -
P5 mod jar 解析（
mcfold/modjar.py，8 项回归全绿） 三种加载器真实样本验证（Forge / NeoForge / Fabric）+ 多加载器 jar 诊断 可提取：mod id / 名称 / 版本 / 方块名清单 / 物品名清单 诚实边界：拿不到 state id（已在摘要里明说，见附录 D） -
P6 世界模型（
mcfold/world.py，7 项回归全绿） 多区块聚合 / 负坐标定位 / 世界高度边界 关键语义：unloaded（没收到）与air（真是空气）必须可区分 mod 方块计入unknown_state_ids，世界摘要带告警 -
P7 实例层（
mcfold/instance.py，8 项回归全绿） 传入文件夹路径 → 拉起实例 → 读 mod 注册方块表 → 连服 含：加载器版本归一化、裸名展开、歧义处理、越界 state id 归因到 mod
累计测试
| 套件 | 项数 |
|---|---|
| 版本解析 | 6 |
| protodef | 6 |
| 区块解析 | 11 |
| mod jar | 8 |
| 世界模型 | 7 |
| mod jar | 8 |
| 实例层 | 8 |
| 跨实现互操作 | 2 |
| 合计 | 48 |
统一入口：./run_tests.sh