预览包
pkg.pr.new 是包分发通道。 每次 CI 的 package-preview 运行都会把全部四个可发布的工作区包 以真实、可安装的 tarball 形式发布到一个按 commit SHA 与 pull request 索引的免费持续发布注册表。消费者按 commit URL 固定版本；不需要也不应配置 npm 注册表凭据。
安装命令与 runtime 配对规则在安装中。本页讲的是通道本身：预览包从哪里来、 你能信任它到什么程度，以及固定版本究竟保证了什么。
预览包从哪里来
.github/workflows/package-preview.yml 在一次完整构建之后运行 pnpm preview:publish。pull request
直接调用它；.github/workflows/release.yml 在每次推送到 main 时复用它。它以
--previewVersion --peerDeps --no-compact --no-template 发布 packages/agent-bundle、
packages/rsc-runtime、packages/rsc-markdown-stream（@agent-bundle/runtime 所依赖的 Markdown
渲染器）与 packages/create-agent-bundle。
pull request 运行按 PR 分组并启用 cancel-in-progress，因此更新的推送会取消被取代的 PR 构建。
在 main 上，串行的 Release packages 工作流会等待可复用的 preview job，且不会取消较早的 release
运行。
PR 或提交上的「Publish pkg.pr.new preview」检查会链接到该次构建的确切 URL。预览包由发布门禁所校验的
同一份 pnpm build 输出构建而来，但它们不是 npm 正式版本，并且携带预览版本号。
固定版本，以及一条历史遗留注意事项
配对规则与安装命令在安装中；有两个细节属于通道本身。
PR 引用会解析到该 PR 最近一次发布的预览，因此 @1 表示「PR #1 最新一次构建」，而不是某个固定
提交。短 SHA 永远不会移动，这正是 lockfile 应当携带它的原因。
在 peer 改写落地（PR #46）之前发布的预览包仍携带原始的 agent-bundle@^0.1.0 peer 范围，因此用 npm
配对安装那些较早的 SHA 仍然需要 --legacy-peer-deps。更新的预览包用原生 npm 即可安装。
原生 pnpm 11 是例外。@agent-bundle/runtime 的预览包会把它的 rsc-markdown-stream 依赖指向渲染器同一
SHA 的预览 tarball，而 pnpm 11 的 blockExoticSubdeps（默认 true）会拒绝从 tarball URL 解析的传递依赖，
报 ERR_PNPM_EXOTIC_SUBDEP。请在消费项目的 pnpm-workspace.yaml 中设置 blockExoticSubdeps: false，
或改用 npm 安装预览包。
脚手架发布在同一条通道上，其设计意图是直接运行而不是安装：
脚手架生成的项目会把 agent-bundle 固定到脚手架自身所来自的那个提交的预览版本，因此上述配对规则的
两侧会自动成立。
合并 Version Packages
Release packages 工作流会记录 version-maintenance-only、preview-release 或 failed 之一，
并列出已执行与已跳过的阶段。成功刷新 Version Packages PR 时结果为 version-maintenance-only。
合并该 PR 时，Release packages 会先调用可复用的 Package preview 工作流，发布并解析全部四个
https://pkg.pr.new/ScriptedAlchemy/agent-bundle/<package>@<sha> URL。release job 依赖这项证明，
并对完全相同的 merge SHA 执行资格认定，所以绿色表示打包门禁已经通过，且每个按 commit 固定的包都可安装。
pnpm check:release 会运行 pnpm pack:dry-run、pnpm lint:release 与
pnpm test:packed:release。lint:release 先对打包后的 agent-bundle、@agent-bundle/runtime、rsc-markdown-stream 与
create-agent-bundle tarball 以 esm-only profile 运行 attw，再用
scripts/check-declaration-imports.mjs 检查同一份文件清单：消费者能从 exports 触达的每个 .d.ts
只能导入包内文件、包自身通过 exports 公开的子路径、能被 imports 映射解析的 # 导入、Node 内建模块，以及在 dependencies、
peerDependencies 或 optionalDependencies 中声明的包，绝对路径和 URL 在消费者的安装中永远无法解析，
任何打包声明里出现 zod 这类 devDependency 都会让门禁失败，lint:release 以 --strict
运行该检查，因此没有任何入口触达的内部声明与可触达声明一样会失败（不带该参数时只报告为 warning）。可触达性从
exports 下的每个 types 目标以及旧式 types 字段出发；/// <reference types> 按裸导入同样检查；相对导入、
/// <reference path> 或 exports 目标指向压缩包中不存在的文件时也会失败。publint 不是单独的门禁：每个可发布包的
rslib build 都会通过 rsbuild-plugin-publint 运行它，并在出现 warning 时让构建失败。该门禁仅用于
发布，并不替代日常的 pnpm check 交付门禁。