/spirit_root

灵根的管理入口。定义本身是数据包，授予、移除和开关则是实体身上的状态：这一页是操作这三件事的地方，也是「关闭但不失去」那个模块在灵根一侧的管理员侧入口（模块没有玩家界面）。

• /spirit_root ...

  • ... list [<target>]

    列出持有的灵根：名字、品质、绑定元素与是否生效；不填目标时看自己，查询不需要权限。

  • ... grant <targets> <root>

    授予灵根（gamemaster）。

  • ... remove <targets> <root>

    移除该灵根，连同它的元素与一切授予。

  • ... enable <targets> <root> / ... disable <targets> <root>

    「关闭但不失去」：关掉的灵根仍然持有，只是什么都不再提供。

「品质」那一栏读的是定义自己声明的 quality；定义没声明、或者那份定义当前包已经不提供时，这一栏写 -。信息面板里灵根那一行画的是「定义名 · 品质名」，没声明品质时那半段整个不画。

授予与移除走的是数据包行为 mxt:grant_spirit_root / mxt:remove_spirit_root 等同一套服务，所以冲突规则、持有条件与来源清理完全一致，命令不会绕过任何一条校验。失败按目标逐个报告，因为值得知道的失败都是逐个目标的——一个已经持有，另一个的元素与它相冲——原因写在后面正是这个命令值得再跑一次的地方。

已经不存在的定义

<root> 的补全只列出注册表里当前存在的定义。身体仍然持有、而当前包已经不提供的条目（文件被删，或被 neoforge:conditions 挡在注册表之外）要手打 ID：这几个参数不校验条目是否存在，手打的 ID 照常被接受，而 remove / enable / disable 都按身体持有的那条引用来找、不回查注册表，所以这条引用救得回来。附件里存的是那份 Holder 本身，它在两次世界加载之间不会自己消失——附件只在世界加载时解码（/reload 不重解），而那一刻找不到定义的引用会被容错列表丢掉，所以重新进一次世界之后这一条就没了。

顶层别名 /spirit_root 由服务端配置的**「命令别名」标签页**控制（条目名 spirit_root，默认开启）；关闭后 /mxt spirit_root 照旧可用。