القائمة
在 SlimefunHelper 中兼容多个 Baritone 发行形态，尤其是“全混淆”版本。用于区分无混淆、仅方法混淆、类与方法全混淆三种形态，并决定 MixinPlugin、目标类定位、成员定位、反射桥接和 hooks 访问层该如何拆分。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Analyze server-side block interaction flow around ServerPlayerInteractionManager.interactBlock, BlockState.onUseWithItem/onUse, ItemStack.useOnBlock, and BlockItem.useOnBlock in this merged Yarn Minecraft tree. Use when tracing whether right-clicking a block can fall through into item use or block placement, when classifying PASS vs PASS_TO_DEFAULT_BLOCK_ACTION behavior, or when summarizing special interactable block families.
理解并维护 SlimefunHelper 中 `ElytraExtra.applyAxisLimit2` 的 Elytra 烟花容错盒、两帧 look 叠加、目标逼近与爬升策略选择。用于分析 `currentMotion = currentRotation * 1.7` 一类上推方案，判断斜向追点、竖直拉升、前后折返等 rotation 序列的收益与约束。
Grim 中 Elytra 预测、烟花容错、offset 判定与 setback 回滚的结果逻辑。用于直接回答滑翔检测、fireworksBox、1.7 来源与拉回后高速原因。
在 SlimefunHelper 中新增或改造模块配置屏幕时，统一复用 `WidgetUtils` 的配置屏幕组装链，而不是在模块里重复手写 `DynamicListWidget + RefKeyValueInputWidget`。用于把 `BaseModule` 的 `editableConfig`、显示条件、模块标题、主题色和自定义 widget 接到同一条打开链路上。
理解并维护 SlimefunHelper 中 `NBTType`、`NBTParsable`、`NBTRef`、`AttrKeyValue` 的自动配置链。用于分析或新增 NBT 配置类型时，追踪它如何在字符串、原始对象、NBT、Ref、可编辑 GUI 之间自动转换，并据此实现新的 `NBTParsable` / 组合型配置结构。
为 SlimefunHelper 新模块补全 BaseModule 基础注册骨架。用于创建或改造模块时，统一完成模块名、ModulePath、Flag 绑定、不同类别 Ref、监听器、常用监听器、热键和命令注册。
استنادا إلى تصنيف SOC المهني
| name | baritone-mixin-compatibility |
| description | 在 SlimefunHelper 中兼容多个 Baritone 发行形态，尤其是“全混淆”版本。用于区分无混淆、仅方法混淆、类与方法全混淆三种形态，并决定 MixinPlugin、目标类定位、成员定位、反射桥接和 hooks 访问层该如何拆分。 |
| disable-model-invocation | true |
让当前 Baritone 注入链兼容三种运行时形态：
当前项目里，第 1、2 种已经部分兼容，第 3 种还没有打通。
这类兼容问题不能只看单个 mixin，要把链路拆成两层：
优先阅读：
src/main/java/me/matl114/hooks/HooksMixinPlugin.javasrc/main/resources/slimefunhelper.mixins.hooks.jsonsrc/main/java/me/matl114/hooks/BaritoneHooks.javasrc/main/java/me/matl114/hooks/mixin/baritone/*.javamapping/Mappings/mappings-standalone.txtmapping/Mappings/mappings-*.txtHooksMixinPlugin 当前没有任何版本探测、mixin 分发或 mapping 解析逻辑。
它现在只是：
shouldApplyMixin(...) -> truegetMixins() -> List.of()preApply/postApply 空实现所以它目前没有承担任何兼容职责。
当前 Baritone mixin 已经在一些点上做了双写兼容，例如：
method = {"a(...)V", "tickUseFireworks(...)V"}method = {"a()Z", "shouldLandForSafety()Z"}@Shadow(aliases = {"a", "setPath"})这能覆盖：
a/b/c...但它仍然默认目标类名是未混淆名，比如：
baritone.process.elytra.ElytraBehaviorbaritone.process.ElytraProcessbaritone.behavior.InventoryBehaviorbaritone.command.defaults.ElytraCommandbaritone.cache.ChunkPacker所以一旦类名也被改掉，这一套就失效。
从 mapping/Mappings/mappings-standalone.txt 可以直接看到：
baritone.process.elytra.ElytraBehavior -> baritone.kibaritone.process.elytra.ElytraBehavior$PathManager -> baritone.ki$dbaritone.process.ElytraProcess -> baritone.jubaritone.behavior.InventoryBehavior -> baritone.exbaritone.command.defaults.ElytraCommand -> baritone.gdbaritone.cache.ChunkPacker -> baritone.fjbaritone.process.elytra.UnpackedSegment -> baritone.knbaritone.api.utils.IPlayerController -> baritone.efbaritone.api.process.PathingCommand -> baritone.cxbaritone.api.process.PathingCommandType -> baritone.cy这说明问题不只是 @Mixin 的类目标变了，很多 handler 方法签名里用到的 Baritone 类型本身也变了。
BaritoneHooks.java 当前直接 import 并调用：
baritone.api.BaritoneAPIbaritone.api.IBaritonebaritone.api.Settingsbaritone.api.event.events.ChatEvent而 mapping 显示这些 API 类在全混淆版里也被改名了。
也就是说：
BaritoneHooks.Impl 也会因为找不到 baritone.api.* 而退回 Default所以必须把“mixin 注入兼容”和“Baritone API 访问兼容”一起做。
如果你的意思是：
MixinPlugin 里读 mapping file@Mixin/@At/@Shadow/@Inject/@WrapOperation 全部动态改写成全混淆版那这条路不适合当前项目。
原因是：
IMixinConfigPlugin 没有一个直接、稳定的入口，让你在应用前把 mixin 类本身的注解和方法描述整包重写baritone.api.* 都改名了，所以仅靠 target remap 不够，调用层也得改结论：
把兼容拆成三层。
放在 HooksMixinPlugin。
职责：
建议探测顺序：
baritone.process.elytra.ElytraBehavior
tickUseFireworks / pathTo / shouldLandForSafety
a/b/c：方法混淆分支baritone.process.elytra.ElytraBehavior 不存在，但存在 mapping 中的目标，如 baritone.ki
不要让同一批 mixin 同时承担三种形态。
建议分成：
baritone/clear/*：无混淆 / 类名未混淆的版本baritone/fullobf/*：全混淆版本其中：
HooksMixinPlugin 负责只返回当前版本需要的那一组 mixin。
BaritoneHooks 不应该继续直接绑死在 baritone.api.* 上。
建议拆成：
BaritoneHooks.ClearImpl
BaritoneAPIBaritoneHooks.ObfImpl
实例选择顺序与 HooksMixinPlugin 的版本探测保持一致。
不要再写：
@Mixin(ElytraBehavior.class)@Mixin(ElytraProcess.class)改成面向运行时类名的字符串目标，例如：
@Pseudo@Mixin(targets = "baritone.ki")@Mixin(targets = "baritone.ki$d")@Mixin(targets = "baritone.ju")@Mixin(targets = "baritone.ex")@Mixin(targets = "baritone.gd")@Mixin(targets = "baritone.fj")这样 Mixin 至少能命中正确的类。
因为全混淆版里这些类型名也变了。
优先级：
Object / @Coerce 就改MethodHandle当前最典型的高风险点：
ElytraBehaviourPathManagerMixin 里直接用 UnpackedSegmentElytraBehaviourMixin 里直接用 ElytraBehavior / InventoryBehavior / IPlayerControllerElytraProcessMixin 里直接 new PathingCommand / 用 PathingCommandType这些在全混淆版里都不能继续假设类名稳定。
建议新建一个全混淆专用 helper 层，例如：
BaritoneObfMappingsBaritoneObfReflectionBaritoneObfHandles职责：
mapping/Mappings/*.txtdeobf class -> runtime class 查询deobf method(signature) -> runtime name 查询这样 full obf mixin 里不直接写硬编码反射逻辑，只调 helper。
至少要构建三张表：
baritone.process.elytra.ElytraBehavior -> baritone.kiowner + deobfName + deobfDesc -> obfNameowner + deobfName + deobfDesc -> obfName因为全混淆版里大量方法都压缩成了 a/b/c，只靠名字无法区分，必须带 descriptor。
你现在目录里有：
mappings-api.txtmappings-fabric-api.txtmappings-fabric-standalone.txtmappings-forge-api.txtmappings-forge-standalone.txtmappings-neoforge-api.txtmappings-neoforge-standalone.txtmappings-standalone.txt不要一开始就把所有文件一起混用。
先基于当前你实际想兼容的发行包类型，锁定一份主 mapping。
如果当前目标是 Fabric 客户端常见整包，优先确认：
fabric-standalone 还是 standalone确认后再决定默认读哪一份。
优先用法：
不推荐一开始就尝试：
先把 HooksMixinPlugin 做成真正的版本探测器。
交付目标：
把 BaritoneHooks 从“直接编译期绑定 API”改成“按 variant 选实现”。
交付目标：
isElytraProcessingresetStatepathTocancelEverything新增 full obf 专用 mixin 组，不要直接动现有 clear 组逻辑。
交付目标：
ElytraBehaviorElytraBehavior$PathManagerElytraProcessInventoryBehaviorElytraCommandChunkPacker逐个补齐。
顺序建议：
ChunkPacker
InventoryBehavior
ElytraCommand
ElytraProcess
ElytraBehavior
PathManager
UnpackedSegment 构造与调用，最后做你们可以用 MixinPlugin 来支持全混淆版，但它更适合承担的是：
而不适合承担的是：
真正可落地的方案是：
MixinPlugin 负责探测和分流BaritoneHooks 同时新增 full obf 访问实现