移位

要解决什么问题

框架主版本、语言运行时、API 版本或数据库 schema 一旦跨过「可补丁」边界，影响面往往横跨依赖图、模块边界和发布节奏。团队常见失误包括：靠手工批量改代码、在生产上先删旧再验新、把 Strangler Fig 做成堆满路由的「外观层」，或按技术分层拆服务导致每次需求都碰两套栈。Shift 面向的是有边界的、可验证的技术转换——从库升级到框架跃迁，目标是在可控停机与数据完整性约束下到达行为等效的新状态。

技能如何工作

Shift 按 ASSESS → PLAN → PREPARE → EXECUTE → VERIFY → COMPLETE 编排迁移，而不是一次性「大爆炸」除非范围明确且测试充分。

• 先量化再动手：迁移前梳理依赖、测试覆盖、API 表面与模块边界；结合 Ripple 的影响面、Lens 的触点、Atlas 的策略输入做范围与风险矩阵。
• 策略选型：在绞杀无花果（Strangler Fig）、抽象分支（Branch by Abstraction）、并行运行（Parallel Run）、扩展合约（expand-contract）等模式间按场景选择；数据库零停机、外部 API 消费者等走对应参考路径。
• Codemods 优先：重复转换用 ast-grep / jscodeshift（JS/TS）、OpenRewrite（Java 等）生成脚本，先空运行再批量执行；实施细节交给 Builder，回归契约交给 Radar，库表变更与 Launch/Gear 协调发布与流水线。
• 验证是合同：每阶段要求前后对比、回归与性能基线（文档中给出可度量成功标准方向，如数据完整性、延迟偏差、失败事务比例）；未证明等效前不拆兼容层。

子命令按首 token 路由：plan（默认规划）、codemod、strangler、verify、framework、lang、deprecate，以及从 horizon 吸收的 detect / modernize / radar 等配方。

适用边界与注意点

• 交给别的技能：只做影响分析用 Ripple；纯发布节奏用 Launch；非迁移型架构设计用 Atlas/Schema；一般重构（非版本跃迁）用 Zen；深度供应链取证用 Cull/Chain。
• Shift 不做的事：未经明确批准与回滚方案的大爆炸；生产验证前删除旧实现；跳过新旧行为等效检查；假设向后兼容而不验证；测试基础设施与业务代码同批硬迁。
• 分解原则：按业务域切边界，避免按控制器/服务/仓储技术层拆分；Strangler 路由要克制，防止外观成为新单体瓶颈。