跟随 pi 升级

ASM 以扩展方式使用 pi，维护目标是保持 pi 核心与选定的上游版本一致。升级时调整 ASM 的适配层和宿主配置，避免把业务逻辑加入核心。

同步节奏

在 minor 版本发生变化时同步，例如 1.5 → 1.6。选取升级当时新 minor 下最新的 patch tag，一次验证并更新所用 pi 包的精确版本；之后不持续追逐该 minor 的普通 patch。

例如开始升级时已有 1.6.2，则以它作为目标；之后发布 1.6.3，不再追随。开发期不 cherry-pick，包括安全修复和直接影响 ASM 的缺陷。

一次升级要验证什么

1. 阅读目标版本的发布说明，核对 Storage、Context、Registry、任务恢复、MCP 和 CLI 扩展接口变化。
2. 同步所用 pi 包的精确版本，按仓库实际构建流程准备依赖。库之间使用同一组版本，避免把两个不同版本的注册对象混用。
3. 运行相关包检查与测试，重点覆盖租户隔离、会话恢复、Routine 重投、事件去重以及 CLI 扩展加载。
4. 验证 ASM 适配层可以通过公开接口完成工作，核对 pi 核心与目标上游版本的差异。
5. 根据实际 API 变化更新站点示例和 reviewed 日期，再执行文档 check 与 build。

本文描述维护策略和验收范围，不表示这些步骤已经有自动升级服务。

等待下一个 minor 时

先保存可复现问题的测试，再通过 ASM 内的组合、包装或宿主配置适配公开接口。所有适配都保留在 asm/，不得修改 pi 核心或提前引入上游 patch。

若现有公开接口无法支持所需行为，记录缺口并等待下一个 minor。node scripts/sync-pi-version.mjs X.Y.Z 在 ASM 工作区统一更新 pi 版本；更新后刷新独立 lockfile，并通过静态检查、单测、真实 CLI 和 Magpie 验收。bash asm/scripts/check-fork-bounds.sh 使用与上游的 merge-base 校验目录边界，不要求追随远端 main 游标。

了解各接口的使用位置：架构总览、durable-pg、durable-trigger、asm-mcp。