diff --git a/COMPATIBILITY.md b/COMPATIBILITY.md
new file mode 100644
index 0000000..3019bf4
--- /dev/null
+++ b/COMPATIBILITY.md
@@ -0,0 +1,106 @@
+# 兼容性与版本策略
+
+本文件说明 `com.ultikits:UltiTools-API` 的版本号含义、废弃与移除策略,
+以及当前正在进行的移除动作。面向下游模块作者。
+
+## 版本号语义
+
+**本项目的版本号是产品阶段信号,不是严格的 semver 契约。**
+
+- **PATCH**(例如 6.2.4 → 6.2.5):小更新与紧急修复。不移除公开 API。
+- **MINOR**(例如 6.2.x → 6.3.0):功能演进。**可能包含公开 API 的移除**,分两种情形:
+ - **下游引用为零的类型**——直接移除,每一项记录在下方清单中并附实测依据。
+ - **仍有下游用户的类型**——仅在满足两个条件后移除:提供书面迁移指引,
+ 并至少提前一个 PATCH 版本发出移除预告。当前唯一属于此类的是
+ `AbstractCommandExecutor`,见下方专节。
+- **MAJOR**:保留给框架层面的方向性变更。不会仅仅为了清理废弃 API 而发布。
+
+如果你需要严格的二进制兼容保证,请锁定具体的 PATCH 版本。
+
+## 依赖声明
+
+Maven:
+
+```xml
+
+ com.ultikits
+ UltiTools-API
+
+ provided
+
+```
+
+Gradle:
+
+```groovy
+compileOnly 'com.ultikits:UltiTools-API:'
+```
+
+**务必使用 `provided` / `compileOnly`。** 发布到 Maven Central 的 POM 经
+flatten-maven-plugin 处理后不含依赖声明,因此把 UltiTools-API 放进编译期以外的范围
+(Maven `compile`、Gradle `implementation`)不会给你带来任何传递依赖,
+却会在你的构建带有 shade / shadow 步骤时,把整个 shaded 框架打进你的模块 JAR,
+在运行时与服务器上已有的 UltiTools 冲突。
+
+## 6.3.0 的移除清单
+
+以下类型将在 6.3.0 移除。每一项都附有移除依据——
+2026-08-10 对 UltiKits 组织下 17 个下游模块仓库的引用量实测(排除测试目录)。
+这 17 个中有 15 个是继承 `UltiToolsPlugin` 的插件模块,另两个分别是父 POM
+(`ultikits-module-parent`)与一个非插件项目;引用量统计覆盖全部 17 个。
+
+| 类型 | 下游引用 | 替代方案 |
+|---|---|---|
+| `AbstractCommendExecutor` | 0 | `abstracts.command.BaseCommandExecutor` |
+| `AbstractDataEntity` | 0 | `abstracts.data.BaseDataEntity` |
+| `abstracts.guis.PagingPage` | 0 | `abstracts.gui.BasePaginationPage` |
+| `abstracts.guis.OkCancelPage` | 0 | `abstracts.gui.BaseConfirmationPage` |
+| `interfaces.VersionWrapper` 的废弃方法 | 0 | `utils.XVersionUtils` |
+| `utils.SecurityPolicy`(重命名) | 0 | `PluginScanFilter`(不提供运行时约束) |
+
+若你的模块不在上述 17 个仓库中且引用了其中任何一项,
+请在 6.3.0 发布前提 issue,我们会重新评估。
+
+## `AbstractCommandExecutor` 的迁移
+
+`abstracts.AbstractCommandExecutor` 标记为 `@Deprecated(since = "6.2.0", forRemoval = true)`,
+是唯一有真实下游用户的废弃类型(实测 14 个文件)。
+它将在 6.3.0 移除,**下游迁移会与移除在同一个版本周期内协调完成**。
+
+迁移到 `abstracts.command.BaseCommandExecutor`:
+
+1. 改继承:`extends AbstractCommandExecutor` → `extends BaseCommandExecutor`。
+2. 实现新增的抽象方法 `protected void handleHelp(CommandSender sender)`。
+3. `@CmdMapping` / `@CmdParam` / `@CmdTarget` / `@CmdCD` / `@UsageLimit` 语义不变。
+4. 通过 `@CmdExecutor` 包扫描注册的命令需要改为显式注册——
+ 扫描路径会把新基类强转为旧基类。走 IoC 路由的主加载路径不受影响。
+
+新基类目前有两个已知缺口,修复排期**不同**:
+
+| 缺口 | 排期 |
+|---|---|
+| `@CmdMapping(format = "")` 的裸命令不可执行 | **6.2.5** |
+| 参数级 tab 补全尚未接线 | **6.3.0**(排在维护者对下述 17 个仓库的迁移之前) |
+
+迁移时机取决于你是谁:
+
+- **上述 17 个仓库内的模块**由维护者在 6.3.0 周期内统一迁移,你不需要自己动手。
+- **仓库外的第三方模块**应当在 **6.2.5 期间**就完成迁移。这样做要接受一个代价:
+ 参数级 tab 补全要到 6.3.0 才接线,在此之前迁移过去的命令只在第一个参数位补全字面量。
+ 但这是唯一能给你留出真实过渡期的做法——补齐 tab 补全的版本(6.3.0)
+ 同时也是移除旧基类的版本,等到那时再迁移就没有缓冲了。
+
+## 支持范围
+
+| 项 | 值 |
+|---|---|
+| 服务端 | Paper(不支持 plain Spigot——代码全面使用 Adventure `Component`) |
+| 构建 JDK | 21 |
+| 字节码目标 | Java 8(`-source`/`-target`,非 `--release`) |
+| `plugin.yml` 的 `api-version` | `1.19`(Bukkit API 层级,与上面两项无关) |
+| 模块 `plugin.yml` 的 `api-version` | `620`(UltiTools API 层级,与 Bukkit 的同名字段无关) |
+
+## 反馈
+
+对本策略有异议,或你的模块受到上述移除影响,
+请在 [GitHub Issues](https://github.com/UltiKits/UltiTools-Reborn/issues) 提出。