用途：引导用户完成 Kestra 1.3 → 2.0 的完整迁移，包括审计、流程迁移、服务器升级和验证。整体立场是建议性的：大声警告、记录每个被接受的风险，仅在用户明确同意后才继续。权威知识来源是官方迁移指南 https://kestra.io/docs/migration-guide/v2.0.0/ ，随附的 references/ 文件为其离线提炼。
两个硬性事实：升级是单向门，Kestra 2.0 首次启动会不可逆地删除 JDBC 队列表，并将 BasicAuth 密码重新哈希为 bcrypt，回滚后 1.x 登录会失效，经过验证的升级前备份是唯一退路；迁移后的 2.0 语法无法在 1.3 上解析，未迁移的 1.3 模式也无法在 2.0 上解析，因此顺序不可省略。
主要能力与流程：Step 0 路由，根据是否存在就绪报告或迁移台账决定进入哪个阶段，单一模式问题可直接跳到对应参考文件。Phase 1 预检审计：先确认访问信息（实例 URL、认证方式、租户），再探测可机器获知的信息（二进制、kestractl 上下文、实例版本/版本类型、流程数量、kestra-migrate --check 分类），最后就拓扑、流程来源、安全、目标、集成、时间线进行访谈；每次运行一个实例，并分配复杂度等级（Low/Medium/High/Critical）。Phase 2 流程迁移：导出 1.3 流程，用 kestra-migrate --check <dir> 分类为 clean、auto-migratable 或需手动处理，并运行盲点 grep；创建 migration-ledger.md 台账；用 kestra-migrate -o v2-flows/ <dir> 自动迁移；对机械类模式批量处理，对结构类逐流程以 diff 形式确认；用 kestractl flows validate v2-flows/ --output json 验证，用 kestractl flows deploy v2-flows/ --override 部署。Phase 3 服务器升级：原地路径需验证版本、备份、停止实例、运行 kestra migrate plan 与 kestra migrate run、更新镜像/图表并启动；并行路径在新空数据库上部署全新 2.0 实例。Phase 4 验证：每个已部署台账行执行或标记 held(reason)，运行冒烟测试清单，EE 需验证 RBAC 角色与权限。
限制：升级不可逆，必须备份；迁移顺序不可省略；kestra-migrate 会漏掉 json( 和 pluginDefaults:；验证需要 2.0 端点；kestractl 没有 --context 标志，需显式指定目标；kestra-flow 技能早于 2.0，冲突时以本技能的模式参考为准。