数据包边界

本文档基于 Aiyatsbus 官方技能包 v0.0.2，以当前服务器源码和配置为准。

数据包附魔和 Aiyatsbus 附魔可以显示相似名称，但它们不是同一个实现层。复刻前先决定谁是该效果的唯一所有者；“两边都开，观察哪边更像”会造成叠加伤害、重复触发、残留属性或难以解释的客户端表现。

先做归属表

每次迁移先为一个附魔填写这张表：

项目	要回答的问题
原始所有者	当前由原版、数据包还是 Aiyatsbus 实现？
标识	数据包 ID、Aiyatsbus basic.id、展示名是否会冲突？
触发	原生附魔效果、数据包条件还是 Bukkit 事件？
状态	是否依赖 item component、属性 modifier、投射物数据或存档状态？
目标	保留原实现、完全迁移，还是只新增一个独立效果？
验收	数据包开/关和插件开/关四种组合下，预期分别是什么？

没有这张表时，不要把附魔“复刻完成”写入正式包。

不默认等价的机制

以下机制不能仅凭效果描述就认为可以用 Aiyatsbus 等价复刻：

数据包或原版机制	为什么不能直接等价	建议
属性 modifier	叠加顺序、UUID、装备切换和其他插件修改可能不同	优先保留原实现；需要近似时限定测试范围和持续时间
原版特殊状态	由原版内部生命周期管理，不一定暴露为 Bukkit 事件	先确认 API 和实服表现，再决定是否迁移
投射物自定义数据	数据包可能把状态写进投射物或物品 component	不能只靠命中事件推断全部状态
物品组件和自定义数据	数据包读取的 component 与 Aiyatsbus 变量存储不是同一存储	不要假定两者互相可见
原版附魔 ID	原版注册、数据包注册和插件替代的优先级不同	只在明确的替代方案中使用 alternative.is-vanilla

尤其不要通过“保存玩家原 base attribute，ticker 期间改全局值，停止时再恢复”的方式模拟数据包属性。该做法会覆盖玩家同时获得的其他装备、药水、插件或数据包 modifier，无法作为通用迁移模板。

三种可接受的迁移策略

保留数据包

适合依赖原版组件、属性 modifier 或复杂持久状态的效果。Aiyatsbus 只负责独立的展示或完全不同的附加玩法，不使用同一 ID 和同一触发结果。

完全迁移到 Aiyatsbus

适合能明确映射到 Bukkit 事件、且不依赖原版内部状态的效果。迁移时先在测试服关闭或移除对应数据包附魔，再逐项确认目标、槽位、触发、数值和持续状态。

并存但功能分离

名称可以相关，但触发条件、ID 和效果必须不同。例如数据包保留原生属性效果，Aiyatsbus 实现一个独立的右击技能。任何共享同一伤害、同一冷却或同一状态的设计都应视为高风险。

四组合回归

对每个迁移过的附魔至少检查：

数据包	Aiyatsbus	预期
关	关	没有该效果
开	关	只有数据包效果
关	开	只有插件效果
开	开	仅在明确设计为并存时允许；否则必须阻止或报出冲突

这项测试要在目标服务器完成。YAML 校验、源码阅读和 /aiyatsbus reload 都不能证明数据包、资源包、反作弊和客户端最终组合表现。

上线门槛

1. 明确一项效果的唯一所有者。
2. 确认旧实现已在生产配置中禁用或移除，而不是只在工作区删除。
3. 验证重新登录、换手、换甲、死亡、掉落和拾取后的状态。
4. 验证区域保护、PVP、反作弊和日志插件不会绕过或重复结算。
5. 完成四组合回归后，才允许将“复刻”改为“实服验收通过”。