/spirit_root

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

命令	作用
/spirit_root list [<目标>]（= /mxt spirit_root list）	列出持有的灵根：名字、品质、绑定元素与是否生效。不填目标时看自己，查询不需要权限。
/spirit_root grant <目标s> <灵根>	授予灵根（gamemaster）。被 conflicting_elements 挡住、已经持有或定义不存在时，逐个目标报出原因。
/spirit_root remove <目标s> <灵根>	移除该灵根，连同它的元素与一切授予。
/spirit_root enable / disable <目标s> <灵根>	「关闭但不失去」：关掉的灵根仍然持有，只是什么都不再提供。

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

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

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

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