用途：指导两类迁移——tRPC 到 oRPC，以及 oRPC v1 到 v2。核心原则是拆成小的机械步骤，每步后运行项目的类型检查与测试，让失败定位到上一步；不要凭记忆写 oRPC v2 的导入路径、构建器方法和选项名，应从官方文档推导。重写核心 v2 概念（os 构建器、路由、中间件、客户端）时可加载 orpc 技能。v2 目前发布在 npm 的 beta dist-tag 下，普通安装得到 v1；当 npm view @orpc/server dist-tags 显示 latest 为 2.x 后可去掉 @beta。
tRPC 到 oRPC：两条路径。应用需持续发布或 tRPC 路由很大时选增量：安装 @orpc/trpc@beta，用 toORPCRouter(trpcRouter) 包装现有 tRPC 路由，得到常规 oRPC 路由，可通过 RPC 或 OpenAPI handler 暴露，或用服务端客户端调用，tRPC 代码保持不动。注意不支持 tRPC 错误格式化：tRPC 错误会包在 ORPCError 中，TRPCError 作为 cause，验证失败时其下还有 ZodError，需要结构化错误时在 handler 拦截器中重塑。toTRPCMeta 可把 oRPC openapi() 元数据桥接到 tRPC .meta()，链式 .meta() 是浅合并，应把 oRPC 元数据放在单个 toTRPCMeta 调用内。之后逐个把叶子路由重写为原生 oRPC，与转换后的路由挂在同一普通对象中。路由小到可一次转换时选整体重写，按概念映射替换：t.router 变普通对象、t.procedure 变 os、initTRPC.context 变 os.$context、.query/.mutation/.subscription 统一为 .handler、TRPCError 变 ORPCError、移除 superjson。步骤依次为换包、移植 context 工厂并重建共享 procedure（ctx 变 context）、替换方法、删除 createTRPCRouter 包装、用 oRPC handler 替换 tRPC 适配器、客户端改用 RPCLink 与 createORPCClient、TanStack Query 用 createTanstackQueryUtils 替换 provider 和 useTRPC。
oRPC v1 到 v2：多数 v1 名称仍可通过废弃别名编译，可分轮迁移。先更新所有 @orpc/* 包到 beta，并替换改名包（如各框架 query 包合并为 @orpc/tanstack-query，@orpc/openapi-client 并入 @orpc/openapi 等）。再修硬性破坏：.route/.prefix/.tag/$route 移除，改用 .meta(openapi(...)) 或导入扩展恢复；.callable/.actionable 改用 call/createRouterClient 等；RPCLink 的 url 拆为 origin 加仅路径 url；ORPCError 移除 status，用 errorStatusMap 映射；safe() 元组元素变化；若干选项重命名；adapterInterceptors 移除。随后审计静默行为变化：v1 与 v2 线格式不兼容，需服务端与客户端一起部署；中间件自动去重移除，可能重复执行；Batch Plugin 的 exclude 变为语义相反的 filter；RPCHandler 默认拒绝 GET；handler filter 改为位置参数；.input/.output 变为叠加。最后清理废弃别名。验证：步骤 1、2、4 后跑类型检查与单元测试，步骤 3 需集成或 e2e 测试，收尾前 grep 旧包名与废弃提示。文档以 https://orpc.dev（v2）和 https://v1.orpc.dev（v1）为准，注意区分主机；https://orpc.dev/llms.txt 为索引，页面 URL 加 .md 可得源 markdown。