v0.6.4 — mod entities and boss awareness

Mod bosses are no longer unknown.

• registry-dump 0.1.2 exports ENTITY_TYPE: name, numeric id, spawn group and hitbox. The bundled jar is at templates/registry-dump/modsmith-dump-0.1.2.jar (release: registry-dump-v0.1.2).
• import-dump writes ids.entities; entity ids in the vanilla 0–129 range are rejected as residue.
• inspect reads tags/entity_type/bosses.json (or c:bosses) and keeps entity.* display names.
• Hosts can inject mod entity names into the mineflayer registry and map monster to hostile; the Cortico host exposes mc_entities (name, display name, distance, direction, visibility, hostile, BOSS) and lists bosses in the mod prompt.

Verified on the production server (FD + More Delight + Supplementaries + Twilight Forest): dump had 227 entities (TF 80), all four packs imported with zero failures, and a summoned Naga reported as twilightforest:naga（娜迦） BOSS，敌对.

Tests: modsmith 168 passing; host Minecraft suite 2288 passing; typecheck clean.

modsmith-dump 0.1.2 — entities

Registry-dump now exports ENTITY_TYPE as well:

• entities: name -> { id, spawnGroup, width, height }
• lets a mineflayer bot name mod entities and recognise bosses (mod ids are always above the vanilla 0–129 range)
• modsmith import-dump writes ids.entities; ids in the vanilla range are rejected
• same read-only jar, still never auto-installed

Pairs with modsmith 0.6.4 (inspect reads entity_type / bosses tags).

v0.6.2 — P2 装饰接包

0.6.2 — P2 装饰接包

• npm：npm i -g modsmith@0.6.2（npmjs.com/package/modsmith）
• Supplementaries 4.0.2 + Moonlight 3.7.2 实测接入：237/271 方块、248/297 物品、306 条可用配方；未注册的兼容/技术方块已从清单裁剪。
• inspect 契约修复：自定义序列化器的字符串 result 统一收成 {id,count}；原版 tag 可从服务器 jar 展开并入 candidates。
• 类型：PlannedStep 补上 take。
• 预生成参考包：modsmith-0.6.2-reference-packs.zip — 两份 manifest + 对应 ids + 精确 mod 列表；ids 带指纹，只对压缩包内那套 mod 组合有效。
• 宿主侧（不在本仓库）：mc_modblocks、mc_scan、place.face；两间真实房间的装饰验收。

modsmith-dump 0.1.0 — registry dump

modsmith-dump 0.1.0

服务端 Fabric 1.21.1 只读模组：启动时把真实注册表写入 config/modsmith-dump.json（block stateId + item id），不注册任何方块/物品。

接包从 3 小时降到几秒：TF 523 方块 / 17255 状态、Supplementaries 14996 状态，不再逐个 setblock 回读。

jar 已随 modsmith 包内置（templates/registry-dump/modsmith-dump-0.1.0.jar，4KB）；modsmith dump-jar 打印路径。不会自动安装：装/删由人决定。

用法：装 jar → 重启 → 取 config/modsmith-dump.json → 停服删 jar → modsmith import-dump ... --server-mods mods。dump 只替代 id 测量，probe/verify/recipes 仍要跑。

SHA-256：c09f20ec5c8171f5e2541ca1593a44917042ef1aa341f2a50b726a959ee2e22f
源码：templates/registry-dump

v0.6.1 — 侧车认完整配方 id，GUI 机器可代做

这一版补上的

侧车能认完整配方 id 了

avaritia:amethyst_singularity 这种没有 / 的完整 id 以前被当成短名又拼了一层
（avaritia:compressor/amethyst_singularity），永远 no such recipe。现在先按原样在
RecipeManager 里找，找不到才走短名解析。

AvaritiaNeo 的压缩机实测通过：verify --stations 得到
compressor（材料 1 种）→ avaritia:amethyst_singularity，服务端日志
[compressor] cooking ... (200 ticks)。GUI 机器由侧车代做这条路走通了。

未知自定义类型保留常见字段

inspect 以前对未知类型只留 result，verify 会报"配方缺 ingredients"。
现在保留 ingredients / tool / container / 耗时（cost·cookingTime·time），不猜语义。

方向

README 与 ROADMAP.md 已改为 AI 陪伴优先：真玩家账号上的 AI + 任意模组的语义数据，
不做硬核科技/工业、流体/能量站点。

现状

• 155 个测试全绿
• 已知问题：inspect 会把模型变体当物品（infinity_bow_pull_0/1/2 等），
  verify 会报"服务端不认"；不影响站点，待修

v0.6.0 — 会自己排步骤：依赖图、make、箱子取料

这一版补上的

依赖图 + 目标规划（新 plan 模块）

清单里的配方和站点现在能变成"做一个东西要几步、缺什么"的答案：

• buildRecipeGraph(manifest)：物品 → 配方（原料分组、工具、站点类型、产出数量）
• planTarget(graph, {item, count, have, stock, stations})：目标 → 按执行顺序的步骤，
  只输出宿主已有的 craft / cut / pot / cook / smelt / take；按背包记账递归补原料，
  工具按"候选里有一把就行"，带循环/6 层/96 步上限
• 箱子里的料也算：背包不够先看够得着的箱子，够就排 take；工具、成品本身同理
• 容器（锅要碗）按真实原料算：每批一个，缺了先从箱子取，取不到如实报缺

宿主的 make 技能消费它：拿所有已加载包的配方和站点，调 planner 按序执行，失败就用
当前背包重排一次（重排出来还是同一串步骤就停）。真机验证：三碗牛肉炖（先从箱子拿一碗
现成的、再下锅做两碗），27 秒齐。

盲搜文法自动起语义字段名

--accept/待审落盘时把 f0/f1 按 kind 命名为 ingredient/ingredient2/result/results，
join 也认这种命名。Fromage 那 28 条 cheese_slicing/waxing/stracciattella 因此可消费，
不再被误标成 SimpleRecipeSerializer。

探针不再被自定义窗口打崩

Fromage 的压模是自定义窗口类型（25/26），prismarine-windows 不认识 → createWindow
返回 null → mineflayer 读 window.id 抛 TypeError，整个探针进程崩在第 40/63 个方块。
现在在 emit 层接住，记为"开窗但界面未知"——不能因为播不出来就当成不开窗。

一个反直觉的边界（写进文档）

fromage:cheddar 的物品是食物不是 BlockItem：拿它右键支撑块，服务端按"吃食物"处理，
物品被吃掉、方块没放下。所以"物品 id == 方块 id"推不出可放置性，方块交互类配方暂时
不会自动排 place；宿主保留了通用的 place 技能（vanilla 石头实测通过）。

现状

• 155 个测试全绿
• 已知边界：方块交互配方要"可放置性/方块形态"数据；gui/流体机制仍不支持

v0.5.1 — 推理模型、站点出处、发现诊断

这一版补上的

learn 能配推理模型了

用云端 deepseek-flash 实测：max_tokens=2000 时它把额度全花在 reasoning 上，content 是空的；放到 8000 也不稳（一次想 3.1 万字）。

• 默认回复上限提到 8000；正文为空且带思考内容时自动重试一次（预算×4、上限 32000，尽量把 reasoning_effort 压到 low，端点不认就退回）
• 两次都只有思考内容时，错误信息直接说明是预算问题，并给出 MODSMITH_MAX_TOKENS / MODSMITH_REASONING_EFFORT 两个旋钮
• 错误回喂链路真机验证：模型先给不在清单里的农夫乐事方块建站，被拒后第二轮改对

模型产出的站点有出处了

以前 LLM 写的命令不带标记，侧车会把它当成"人工核对过的命令"永久保留——模型编的 /brewinandchewin ferment {recipe} 会挡住真正注册的命令，机器人一直超时。

• LLM 站点一律 inferred: true / needsReview: true
• 侧车编译成功后可以覆盖推断站点的命令；人工命令永远保留
• learn 遇到已有非推断站点时只补新方块，不覆盖；要覆盖得 --force

文法发现的诊断不再甩锅

Brewin' And Chewin'（keg 用流体栈）实测：名字锚点其实 1754/1754 全对上了，旧诊断却一律说"名字清单可能不完整"，按它去补名字会白忙。

• 锚点全覆盖时直接说"payload 里有形状库没有的字段（流体/能量/嵌套结构）"
• 这种情况不再退回盲搜（以前会烧预算、刷一屏噪声）
• 名字真缺时仍然指向名字清单；两条合成包测试分别钉住两种诊断

文档

• 已知局限补了流体/能量类配方，以及"饮料/果冻那类上下文方块"（setblock 下去立刻变空气，probe/calibrate 如实记"放不下"）
• 141 个测试全绿

v0.5.0 — 三种站点机制上真机，多包共存

这一版补上的

站点验收补上三个真实缺陷

verify --stations 在真服上暴露的都不是"报告不好看"，是"机器人会白试"：

• 容器：配方 wire 里就有 container（锅要碗）。不给的话服务端拒绝产出，回执却像站点坏了。
• 热源：声明了 heatTag 的站点（厨锅）底下没热源会拒绝开工，同样没有像样的报错。
• 命令模板：以前只取命令第一个词再拼 cook，/fdchef cook {recipe} 之外的写法会被悄悄改错；现在整句代入 {recipe}。

FD 开发服上两条站点全过：砧板 4 种料 → leather，厨锅 + 碗 + 灶 → mushroom_stew。

人工站点不再被推理覆盖

learn --infer 以前整段替换 stations。生产清单的 /fdchef cook {recipe} 被覆盖成不存在的 /cooking_pot，机器人会静默重试到超时。

现在是合并：人工站点的命令、机制、verified 一个字不动，只补 recipeType/toolSuffix，追加没被占用的方块；同一方块但人工只声明了别的配方类型时不并入，只报告。整段重推要显式 --force。

多包共用一台服务器

捕获的 declare_recipes 是整服快照，装了第二个包之后：

• recipes --ids-all <dir> 合并各包 ids；指纹不一致或同名冲突直接拒绝——不同 jar 组合下的 id 会整体位移，合出来全是错名
• calibrate --fresh：换/加 jar 后旧 ids 作废的唯一入口
• recipes --accept 改为合并式：重跑时发现列表为空不再写空表，把人工核对过的文法抹掉
• 宿主侧按配方 id 跨包去重、累积安装；以前第一个包接上后一刀切，第二个包的配方永远合不出来

纯物品包不是失败

More Delight（38 件食物、0 方块）实测：推不出站点、没有方块校验，都是正确结果。以前 learn 和 verify 当成失败，onboard 永远停在中间。现在这个包全链通过（1631/1631 条配方翻译成功）。

真 AI 端到端

Linxi 在生存服里自己做出牛肉炖：取料 → 砧板把牛肉切成肉馅 → 厨锅出餐。

过程中量出 FD 砧板的一个边界：产物只在贴到约 2 格内才给玩家。2.5 格外右键会扣料、刀掉耐久、成品消失，服务端不报错。宿主 cut/cook 已改成先走到站点旁边再交互。

现状

• 138 个测试全绿；宿主（Cortico）5037 过，3 个既有环境性失败与本次无关
• 已知边界：learn 的真模型路径只有编排测试；带站点的第二个包还没接（Brewin' And Chewin' 依赖的 greenhouseconfig 不在 Modrinth）

v0.4.2 — L3 收口：三种站点机制全部实测

这一版补上的

place-and-wait 不再被静默跳过

verify --stations 之前只跑侧车型和两步式。推断成 place-and-wait 的站点（比如干燥架）会从报告里彻底消失——没有通过、没有失败、没有提示。这正是项目禁止的静默失败。

现在它真执行：放料 → 右键 → 等 → 产物进包或以掉落物出现都算成功（按数字 id 认实体，因为模组物品名可能是 unknown）。实测用原版营火：鲑鱼进，熟鲑鱼以掉落物出来。

另外，缺 recipeType 的、机制还没有执行器的站点，现在会显式报「已知但未验」，而不是被 filter 丢掉。

一个方块可以服务多种配方类型

第二种类型不再被当成「方块已被占用」整类丢弃；id 冲突时加类型后缀，侧车配置支持 recipeTypes[]（老的 recipeType 单值仍兼容）。

修掉 jar 形状工具标签的解析

minecraft:axes 被按 / 切分时整串留下，斧头家族永远推不出后缀。常见工具标签现在有内置映射，不再依赖 manifest.items（那只收模组物品）。

现状

L1 完成、L2 按定义完成、L3 三种机制全部真执行。121 个测试全绿。

v0.4.1 — 从 jar 到机器人能用

modsmith v0.4.1

把 Fabric 模组 jar 变成 mineflayer 机器人能用的语义清单 + 实测数字 id。

这一版能做什么

L1 —— 单个 mod 接入：inspect 提取方块/物品/配方/中文名，calibrate 上服务器量出 1.21.1 的静态注册表数字 id（带服务器 mods 指纹，换过 jar 就拒绝复用），verify 做合成冒烟。农夫乐事 3.3.6 在生产环境跑着。

L2 —— 换一个 mod 只要几条命令：recipes --discover 用配方名切段反推自定义序列化器文法，不需要 javap、不需要逐字节试。

• 暮色森林 4.8.629 实测：2134 条配方全解析、17 个自定义序列化器、40 秒出表
• 每个类型带出现次数、命中物品、首条样例值，以及线上同形的备选（i32/f32、ingredient/list[slot] 这类语义拆分由人对配方 JSON 拍板）
• --accept 采纳入正式 sidesheet；名字从清单里的配方 type 字段反填
• 名字清单不完整也能解（严格拟合优先，弱候选 + 整包校验换备选）

L3 —— 机器人真的能玩：

• learn --infer：从清单证据推工作站，不需要模型。自定义配方类型 + 显式 tool 字段 + 方块名词干匹配 → two-step-use / sidecar-recipe / place-and-wait
• probe --scan-blocks：把候选方块逐个右键一遍，记录开不开窗。实测到自定义界面就必须走侧车（原版客户端开不了私有菜单）
• verify --stations：真做一遍。侧车型发命令、两步式真放料换工具右键；多原料逐个放
• 侧车熟成任务持久化到 <world>/modsmith-sidecar-jobs.json，断线退回挂起、重启恢复、玩家回来接着算

农夫乐事端到端实测：

✓ cooking_pot：farmersdelight:cooking/mushroom_stew（2 种料）→ mushroom_stew
✓ cutting_board（两步，4 种料）：leather ×4 + shears → leather

onboard 现在是七步一条龙：inspect → calibrate → probe(+扫描) → recipes → learn(+证据) → verify(+站点) → sidecar。

已知限制

• 只支持 Fabric（Forge/NeoForge 的 FML 握手是另一套协议）
• 单个方块只能配置一种 recipeType
• learn 的 LLM 路径（非 --infer）本版未复验；规则路径已覆盖 FD/TF
• 两步式站点只在农夫乐事砧板上实测过
• 0.x 期间 manifest / sidesheet 格式可能破坏性变更

验证

121 个测试全绿（npm test，不连服务器）；暮色森林与农夫乐事均在真服务器上实测。