Cline VS Code 扩展发布实践：A/B 组合 VSIX、灰度放量与紧急回滚全链路

本文以 Cline 仓库中的扩展发布技能文档 SKILL.md 为主体，完整讲解 Cline VS Code 扩展在“legacy（npm 老架构）→ SDK（bun 新架构）”迁移期的发布体系：如何选择一个安全的版本号、如何用 PostHog 标志位控制灰度比例、如何分发 stable / nightly / legacy hotfix 三类构建，以及出问题时的降级与回滚手段。读完后，你将掌握一个“一个 VSIX 里装两个完整扩展、按机器灰度选择其一”的真实灰度发布方案的设计原理、操作命令与源码级实现细节。

背景：为什么是“组合 A/B VSIX”

Cline 正处于从 legacy 扩展（npm 工具链、预 SDK 时代）向 next 扩展（基于 SDK 的 bun 工具链，位于 main 分支的 apps/vscode/）的迁移中途。VS Code Marketplace 没有分阶段发布能力——发布一个版本会立即推送给所有用户。为了在不过夜“一刀切”的情况下把 SDK 版扩展放到一部分用户手里，Cline 在 main 与 legacy-extension 两个分支上各构建一个完整扩展，再叠加一个约 40 KB 的加载器（loader）打成单个组合 VSIX，由加载器按 PostHog 标志 ext-sdk-bundle-rollout 的百分比，为每台机器在每个窗口中二选一。

组合 VSIX 的内部结构（见 apps/vscode-rollout/README.md）：

extension.js          ← loader（入口）
package.json          ← 两份 bundle 清单的 UNION（构建时生成）
assets/, walkthrough/ ← 清单引用的资源
next/                 ← SDK 扩展（构建自 main）
legacy/               ← legacy 扩展（构建自 legacy-extension 分支）

最终目标（Endgame）：当 next 束以 100% 灰度稳定运行足够久之后，stable 通道回到对 main 的普通构建（走 ext-vscode-publish-stable.yml），退役全部 legacy/rollout 机制。

四个发布通道与工作流矩阵

通道	Marketplace ID	工作流	触发方式	版本号来源
Stable（组合）	saoudrizwan.claude-dev	ext-vscode-ab-package.yml	仅手动 dispatch；publish 输入默认 false	手动输入 semver（如 4.1.0）
Nightly（组合）	saoudrizwan.cline-nightly	ext-vscode-publish-nightly.yml	手动 dispatch	自动 <major>.<minor>.<unix 时间戳>，基于 main 的 apps/vscode/package.json
Legacy hotfix（独立）	saoudrizwan.claude-dev	ext-vscode-publish-legacy.yml	手动 dispatch	legacy-extension 分支上 apps/vscode/package.json 的版本
Stable standalone（切换后）	saoudrizwan.claude-dev	ext-vscode-publish-stable.yml	手动 dispatch	main 上 apps/vscode/package.json 的版本

所有分发工作流都从 main 触发（GitHub 要求工作流文件存在于默认分支；各工作流再各自 checkout 真正要构建的 ref）。所有发布路径在发布前都有测试门禁：nightly 与 ab-package 运行可复用的 bun 测试套件 ext-vscode-test.yml（测 main），ab-package 额外内联运行 legacy 分支的 npm 套件；legacy 工作流则内联整条 npm 套件。

环境门禁（environment gate）方面：stable 路径挂 publish 环境，需要必需审核人在 Actions 界面批准；nightly 挂 PublishNightly 环境。需要注意当前仓库的一个最新变化：nightly 工作流的 cron 触发已被刻意移除——因为 PublishNightly 环境后来加了必需审核人，无人值守的 cron 会一直卡在 waiting 审批上、占住并发组，连续吞掉后续排程（工作流文件头注释记录了 2026-07-31 至 2026-08-21 间 20 次 nightly 被连坐取消的事故）。因此现在 nightly 只能手动 dispatch（详见工作流 on: 段注释）。

黄金法则：任何发布前必读的五条规则

1. 一个 listing，一条单调递增的版本线

claude-dev 这个 Marketplace listing 被多个工作流、多个分支共同发布。版本在 Marketplace 上单调递增且不可下架（只能被新版本顶掉，不能删除）。因此每次 stable 发布的版本必须严格大于该 listing 历史上从任何分支发布过的最高版本。选择版本前先查线上现值：

curl -s -X POST "https://marketplace.visualstudio.com/_apis/public/gallery/extensionquery" \
  -H "Content-Type: application/json" -H "Accept: application/json;api-version=3.0-preview.1" \
  -d '{"filters":[{"criteria":[{"filterType":7,"value":"saoudrizwan.claude-dev"}]}],"flags":16}' \
  | python3 -c "import json,sys; v=json.load(sys.stdin)['results'][0]['extensions'][0]['versions'][0]; print(v['version'], v['lastUpdated'])"

这条规则在 ext-vscode-ab-package.yml 中被自动化了两遍：preflight 作业先校验版本格式（纯 X.Y.Z，不带 v 前缀和后缀）并硬失败于“不大于线上版本”；publish 作业在真正发布前再查一次——因为环境审批可能等待数天，期间若有 legacy hotfix 落地，第二次检查能拦住“旧代码线顶掉新代码线”的事故（工作流中两处检查的注释明确提醒“Keep both copies of this check in sync”）。但选版本时仍要自己跑一次上面的查询。

2. 任何 stable 组合发布前，先查灰度标志

ext-sdk-bundle-rollout 标志在 nightly 与 stable 之间共享：加载器向 /decide 只发送机器 id，不带通道属性，因此不存在按通道的定向投放。如果标志当前为高值（nightly 团队在吃狗粮），你此时发布 stable，stable 用户也会在同样比例上直接拿到 next 束。有效比例可以不加 PostHog 管理权限就实测——用任意已发布 loader 里内联的 PostHog key 采样 /decide：

node -e '
const KEY = process.argv[1]; // phc_... 从已发布的 VSIX loader 中提取
(async () => {
  let t = 0, n = 200;
  for (let i = 0; i < n; i += 20) {
    const rs = await Promise.all(Array.from({length: 20}, (_, j) =>
      fetch("https://data.cline.bot/decide?v=3", { method: "POST",
        headers: {"Content-Type": "application/json"},
        body: JSON.stringify({api_key: KEY, distinct_id: `probe-${i+j}-${Math.random()}`})
      }).then(r => r.json())));
    for (const r of rs) if ((r.featureFlags||{})["ext-sdk-bundle-rollout"] === true) t++;
  }
  console.log(`~${(100*t/n).toFixed(1)}% (${t}/${n})`);
})()' "$KEY"

标志的修改在 PostHog 界面（Cline 项目）进行。0% 就是 kill switch——该标志是双向的，没有单独的 killswitch 标志；把比例调低后，受影响机器在下次窗口重载时退回 legacy。

3. 推送前先问人

commit 和 tag 的推送、环境审批，权限归维护者所有，操作前必须先征得同意。

4. Changelog 在仓库根目录

Changelog 位于仓库根的 CHANGELOG.md，且必须落在被发布的那个分支上——不是 apps/vscode/CHANGELOG.md（该文件不存在）。legacy 与 stable 工作流都硬失败于“第一个标题不是 ## [<version>]”的情况。

5. 卡住的并发组要手动清理

ext-vscode-ab-package 以版本号为并发组键（ext-vscode-ab-package-${version}，cancel-in-progress: false）。只有 publish=true 的运行需要等环境审批（publish=false 的纯构建演练无门禁地跑完），但一次停留在 waiting 状态的发布运行仍然会阻塞同版本之后的一切 dispatch——重新分发前先用 gh run cancel <id> 取消。

Stable 发布（组合 A/B VSIX）：当前主路径

发布前检查（Pre-flight）

# 1. 线上现值与下一版本（必须大于现值——法则 1）
# 2. 标志比例（法则 2）——决定本次发布时它应该停在什么位置
# 3. legacy 分支尖端 = 未晋升队列实际运行的代码；确认它是已发布的 hotfix 线
git fetch origin main legacy-extension
git log --oneline -3 origin/legacy-extension

# 4. 最廉价地预演最可能的构建失败：union manifest
#    若 views/viewsContainers/configuration 在两分支间漂移，会硬失败
git show origin/main:apps/vscode/package.json > /tmp/next.json
git show origin/legacy-extension:apps/vscode/package.json > /tmp/legacy.json
node apps/vscode-rollout/scripts/gen-manifest.mjs --next /tmp/next.json --legacy /tmp/legacy.json --version <VERSION>
# 预期只有两条警告：engines 取并集（取较新值）+ walkthrough 文案漂移

在 main 上的发布准备要走 PR（不要直接 push）：

• 在根 CHANGELOG.md 顶部添加 ## [<VERSION>] 条目；
• 把 apps/vscode/package.json 提升到 <VERSION>，让仓库反映已发布线。副作用：nightly 版本号会以新基准生成 <major>.<minor>.<unix-ts>——无害（独立 listing，依然单调）。

分发（Dispatch）

gh workflow run ext-vscode-ab-package.yml --ref main \
  -f version=<VERSION> -f next-ref=main -f publish=true
# legacy 束始终从受保护的 legacy-extension 分支构建（刻意不作为输入）
# publish=false 只构建可安装的 .vsix 工件，不发布、也无需任何环境审批

gh run list --workflow=ext-vscode-ab-package.yml --limit 1

从 ext-vscode-ab-package.yml 的作业编排看，整条流水线的顺序是：

1. preflight：校验版本格式（纯 X.Y.Z）、拒绝 publish=true 且 next-ref != main 的组合（bun 测试门禁只覆盖 main，非 main 的 next-ref 只允许纯构建演练）、校验版本大于线上版本；
2. test-next：复用 ext-vscode-test.yml 跑 bun 套件，测的是 dispatch 时的 main 尖端；
3. test-legacy：checkout 硬编码的 legacy-extension 分支，内联 npm 套件（lint + typecheck → ci:build → test:unit → 扩展集成测试 → webview 测试），并输出 tested-sha——构建作业会钉死到这个精确 revision，绝不重解析分支名，保证“测过什么就构建什么”；
4. build：无环境门禁的打包作业。它先验证 changelog 首条（仅 publish=true 时）、用 bun install --frozen-lockfile 安装 next 依赖、bun run build:sdk 构建 @cline/* 工作区包、断言 better-sqlite3 原生二进制存在、用 set-version.mjs 把组合版本戳进两个 bundle 的 package.json（About 页和遥测都读 bundle 自己的清单）、以 CLINE_ROLLOUT_VARIANT: next|legacy 环境变量分别构建两束（该变量被 esbuild 内联，给所有遥测事件打上 extension_variant）、构建 loader 并跑 smoke-loader.mjs 冒烟测试、stitch.mjs 拼装 staging 目录、断言 manifest 身份（saoudrizwan.claude-dev@<VERSION>，两个子清单版本一致），最后 vsce package 出 .vsix 工件；
5. publish（仅 publish=true）：挂 publish 环境等待审批，然后再次核对版本单调性，先发 Marketplace（vsce publish，两个 PAT 在任何不可逆发布前都先被校验，避免“发了一半”）、再发 Open VSX（ovsx publish）。

查看某个运行在等什么：

gh api repos/cline/cline/actions/runs/<run-id>/pending_deployments

发布后（Post-publish）

1. 验证 Marketplace 已提供新版本（法则 1 的查询）——“Published”出现在日志后，Marketplace 校验可能滞后几分钟到一小时。同时验证 Open VSX：

   curl -s "https://open-vsx.org/api/saoudrizwan/claude-dev" | python3 -c "import json,sys; d=json.load(sys.stdin); print(d['version'], d['timestamp'])"
   

2. Tag、GitHub Release（附 .vsix）、Slack release-bot 帖子都是自动的，且全部 continue-on-error——因为发布本身已成功，记账失败不影响运行变绿（这些步骤以 Marketplace 发布结果为门控而非步骤顺序）。但已知一个会失败的点：当被构建的 commit 触碰了 .github/workflows/** 时，默认 token 无法创建 refs/tags/v* 这类 ref（无权限可授予能修复它），tag 推送会失败。手动兜底：

   git tag v<VERSION> <main-sha-built>   # 推送前先问
   git push origin v<VERSION>
   gh release create v<VERSION> --title "v<VERSION>" --notes "<changelog 对应段落>" <path-to.vsix>
   

   另外，若被构建的 main revision 上根 CHANGELOG.md 不以 ## [<VERSION>] 开头，真实发布会在 build 阶段早失败——发布准备 PR 必须先合入再分发。

3. 工件深度体检（gh run download <run-id>）：

   • union package.json 是 saoudrizwan.claude-dev@<VERSION>；
   • next/package.json 与 legacy/package.json 携带相同版本；
   • grep -c 'phc_' extension/extension.js ≥ 1（loader 的 PostHog key 已内联）；
   • 两束 dist 中都不允许残留 process.env.TELEMETRY_SERVICE_API_KEY / process.env.CLINE_ROLLOUT_VARIANT 字面量（残留意味着该次构建缺了对应环境变量，遥测会静默失效）。

4. 监控：在 otel.otel_logs 中过滤 extension_version = '<VERSION>' 看 extension.rollout.bundle_activated（stable 队列可干净切分——nightly 版本是时间戳）；关注 next/legacy 比例与崩溃回退率（Metabase 仪表盘 17：rollout + 任务错误率；19：错误深潜）。extension.rollout.loader_decision（含 double_failure）只在 PostHog，不在 ClickHouse。

5. 按放量计划调标志（例如 0% 发布 → 1% → 逐步上调），每次改动后用法则 2 的探针复核。提前宣布降档——调低比例也会把 nightly 狗粮用户降级，除非他们设置了 "cline-nightly.rollout.bundleOverride": "next"。

该路径的已知局限

• engines.vscode 取并集向上取（main 的地板生效，例如 ^1.101.0 对 legacy 的 ^1.84.0）：老版本 VS Code 用户根本不会被提供组合 VSIX。这是 rollout 期间的安全失败（fail-safe），但必须在 100% 之前解决；
• 红（红叉）运行不等于发布失败：任何会推 tag 的路径上，tag-push 步骤失败会让整条运行变红，但发布可能早已成功——看日志里有没有 “Published”。

Nightly 发布

当前仓库中的 nightly 是手动 dispatch（cron 已移除，见上文说明）：

gh workflow run ext-vscode-publish-nightly.yml --ref main                 # 真实发布
gh workflow run ext-vscode-publish-nightly.yml --ref main -f dry-run=true # 只出工件
gh run watch <run-id> --exit-status --interval 60

nightly 不需要 changelog/版本准备——版本是算出来的：<major>.<minor>.<unix-seconds>，基于 dispatch 时 next 的 package.json 基准版本（工作流中的 “Compute nightly version” 步骤），因此天然持续压过先前所有 nightly。构建前 nightlify.mjs 会把两束清单改写成 nightly 身份——与独立 nightly 历来应用的改写完全相同（两分支的 apps/vscode/scripts/publish-nightly.mjs 是源头真相）：

	stable	nightly
清单 name	claude-dev	cline-nightly
贡献 ID / context key / 设置前缀	cline.*	cline-nightly.*
版本	操作者提供（4.1.0+）	<major>.<minor>.<unix-seconds>

由于身份不同，nightly 可以与 stable 同时安装。nightly 构建还会在状态栏显示 Cline: Next / Cline: Legacy 指示器，stable 构建从不显示（见 extension.ts 的 showNightlyBundleIndicator）。发布作业被工作流自身与 PublishNightly 环境的部署分支策略双重限定为只接受 main。

验证方式：用 Marketplace 查询对 saoudrizwan.cline-nightly 执行同样的版本核对。红运行 ≠ 发布失败：终末 tag-push 步骤在 main 尖端触碰 .github/workflows/** 时必然失败；若日志出现 “Published” 即发布成功，此时用你自己的凭据手动推 nightly-main-<UTC ts>-<sha12> tag。

Legacy hotfix 与紧急回滚

这条路径有两个用途：在 legacy-extension 分支上发布修复；以及作为结构性回滚——从有问题的组合 stable VSIX 全身撤退：一个更高版本的独立 legacy 发布会整体顶掉组合 VSIX（连同 loader）对所有用户生效。注意：“next 束行为异常”不需要走这条路——把标志调到 0% 即可。

# 在 legacy-extension 分支上：提交修复，把 apps/vscode/package.json 提升到
# 该 listing 历史上发布过的最高版本之上（法则 1——包括组合版本，
# 例如线上组合版 4.1.0 → hotfix 应为 4.1.1，而不是 4.0.13），
# 在根 CHANGELOG.md 加对应的 ## [x.y.z] 条目，推送。
gh workflow run ext-vscode-publish-legacy.yml --ref main \
  -f release-type=release
# 分支在 workflow 中硬编码为 legacy-extension，刻意不作为输入

从 ext-vscode-publish-legacy.yml 看：npm 测试套件在无门禁阶段运行（绝不带着 write token 执行被 checkout 的代码），publish 作业才升到 contents: write 并挂 publish 环境；该工作流自行推导并推送 v<version> tag、创建 GitHub Release——无需手动打 tag；同时发布 Marketplace 与 Open VSX。注意该分支是 npm 代码库（3.89.x 代码按 4.0.x 版本前滚）：用 npm，永远不要用 bun，且预期的是老单体布局（apps/vscode/src/core/...）。

Cutover：退役 A/B 机制的终局

当 next 束在 100% 下稳定运行足够久后：

1. 解决 engines 地板：决定让 VS Code 低于 main 的 engines.vscode 的用户停留在最后一个组合版本是否可接受，或先把 main 的地板降下来；
2. 把 main 的 apps/vscode/package.json 提升到高于一切已发布版本，根 CHANGELOG.md 条目匹配（两者都被工作流强制）；
3. 从 main 发独立版本：gh workflow run ext-vscode-publish-stable.yml --ref main——它测 main、自行打 v<version> tag、创建 GitHub Release、发布 Marketplace + Open VSX；
4. 过渡期继续盯同样的 rollout 遥测——extension_variant 随用户离开组合构建而从事件中消失，这本身就是采纳信号；
5. 只有当独立版本成为主流之后：退役 legacy-extension 分支（保留作历史）、删除 ext-vscode-publish-legacy.yml 与 ext-vscode-ab-package.yml、把 nightly 工作流改回 main 的普通构建、删除 apps/vscode-rollout/ 目录，并在 PostHog 归档 ext-sdk-bundle-rollout 标志。注意归档时机：loader 把被删除的标志当作 legacy，所以标志要保持在 100%，直到组合 VSIX 的激活量归零再归档（对仍跑着组合 VSIX 的机器无害——标志缺失只是让它们维持现状，直到更新）；
6. 更新技能文档：删除组合时代章节，保留独立发布流程。

源码级深潜：loader 是怎么做的

以下实现细节可在 apps/vscode-rollout/ 包中逐行核对，它们解释了上文操作规则背后的工程原因。

决策逻辑：同步、离线、可强制

cohort.ts 中的 decideBundle 是整个加载器的核心，优先级链为：

CLINE_BUNDLE_OVERRIDE 环境变量 > <prefix>.rollout.bundleOverride 设置
> 本 VSIX 版本曾崩溃（FAILED_VERSION_STATE_KEY）> legacy
> 上一窗口后台刷新缓存的分配（COHORT_STATE_KEY）> legacy

它被要求同步执行、绝不阻塞网络——只消费上一窗口后台刷新缓存的状态，因此百分比变更在下次窗口重载时才生效（刻意模仿 VS Code 自身实验的语义）。parseRolloutAssignment 的解析刻意严格：只有字面布尔 true 才晋升到 next——多变量变体字符串、数字、payload、缺失/已删除的标志，全部安全失败到 legacy。这就是“标志必须保持布尔发布标志”这条操作纪律的源码依据。

后台刷新与身份一致性

rollout.ts 的 refreshCohort 在选定的 bundle 成功激活后，以 10 秒超时向 https://data.cline.bot/decide?v=3 发一次探测，只缓存下一窗口的分配，永远不翻转已激活的窗口；任何失败（网络错误、无 key 的本地构建）都让缓存保持不动（sticky on transient failures）。distinct id 的推导镜像了扩展遥测的实现（优先读共享的 ~/.cline/data/globalState.json 中的 cline.generatedMachineId，否则 machine-id，再退回 vscode.env.machineId），保证灰度队列成员可以与遥测行为在仪表盘上关联——这正是“loader 只发机器 id、无通道属性”的由来。

崩溃自愈与路径代理

extension.ts 的 activateBundle：如果 next 束激活时抛异常，loader 会 dispose 掉半注册的 subscriptions、把本 VSIX 版本钉回 legacy（cline.rollout.nextActivationFailedVersion）、上报 fallback 遥测，然后激活 legacy——一次崩溃的 rollout 无需 Marketplace 重新发布即可自愈，而下一个新版本又可以再试一次 next。fallback 路径跳过后台刷新，防止它把刚钉死的机器重新晋升回去；若 legacy 也失败（double_failure），loader 直报事件是仅存的记录。

scoped-context.ts 用一个 Proxy 包裹 ExtensionContext：只重定向 extensionUri / extensionPath / asAbsolutePath 到 <vsix 根>/<next|legacy>/ 子目录，让每束从自己的子树解析 webview 构建和资源；存储相关属性（globalState、secrets 等）原样穿透——两束继续共享独立扩展时代用过的同一份 ~/.cline/data 与 VS Code 存储，用户状态在队列切换和 VSIX 升级中存活。这就是“降级不丢数据、SDK 会话在重新晋升后重现”的实现基础。

Union manifest 的生成规则

VS Code 在任何代码运行前就静态读取 package.json 贡献，因此 shipped 清单必须同时服务两个队列。gen-manifest.mjs 在 stitch 时从两分支的真实清单重新生成它：两侧都声明的贡献原样通过；只在一侧声明的菜单项/键绑定被 AND 上 cline.sdkBundle / !cline.sdkBundle 的 when 条件；views / viewsContainers / configuration / walkthroughs 必须逐字相同（无法在运行时安全门控，漂移即构建失败）——这就是 pre-flight 那步本地预演存在的理由。engines 允许漂移：并集取较新要求。

易错点索引（Gotchas）

• inputs.* 在 schedule 事件上是空字符串——编辑 nightly 工作流时保留 || 'default' 兜底（当前文件里 legacy-ref 就带着这个兜底，注释解释是为未来可能恢复非 dispatch 触发时保持正确）；
• 在 apps/vscode 里直接 bun run package 不会构建 @cline/* 工作区依赖——全新 checkout 需要先 bun run build:sdk（工作流已处理）；
• workflow YAML 里 job 级 if: 分支检查只是建议性的（dispatch 的分支运行的是它自己那份文件副本）；真正强制的边界是仓库设置里每个环境的部署分支策略；
• Marketplace PAT（VSCE_PAT / OVSX_PAT）只挂载到发布步骤；两个发布工作流都没有不可信触发面；
• 等待环境审批的运行不会很快超时——可以挂着好几天，并且（对 ab-package 的发布运行）会阻塞其版本号的并发组；
• 本地手动测试的强制开关：CLINE_BUNDLE_OVERRIDE=next|legacy 环境变量（从终端全新启动 VS Code）或 <prefix>.rollout.bundleOverride 设置 + 重载窗口；两者在遥测中都上报为 override，不会污染队列数据。

关键文件索引

内容	路径
发布技能文档（本文主体）	.cline/skills/publish-extension/SKILL.md
loader 设计与 rollout runbook	apps/vscode-rollout/README.md
组合 stable 打包工作流	.github/workflows/ext-vscode-ab-package.yml
nightly 工作流	.github/workflows/ext-vscode-publish-nightly.yml
legacy hotfix 工作流	.github/workflows/ext-vscode-publish-legacy.yml
独立 stable 工作流（cutover 后）	.github/workflows/ext-vscode-publish-stable.yml
决策/常量/解析逻辑	apps/vscode-rollout/src/cohort.ts
后台刷新与 loader 遥测	apps/vscode-rollout/src/rollout.ts
loader 入口与崩溃回退	apps/vscode-rollout/src/extension.ts
路径代理	apps/vscode-rollout/src/scoped-context.ts
union manifest / nightly 改写 / 拼装 / 冒烟脚本	apps/vscode-rollout/scripts
根 changelog	CHANGELOG.md

本地复现整条打包链路（摘自 apps/vscode-rollout/README.md）：

# 1. 用各自工具链构建两束
cd apps/vscode && bun run package                          # next
cd <legacy worktree>/apps/vscode && npm run package         # legacy（先 npm ci）

# 2. 构建 loader、拼装、打包
cd apps/vscode-rollout
bun run build    # 开发构建；CI 用 build:production 注入 PostHog key
node scripts/stitch.mjs \
  --next ../vscode --legacy <legacy worktree>/apps/vscode \
  --loader dist/extension.js --version 4.1.0 --out /tmp/cline-ab-staging
node scripts/smoke-loader.mjs /tmp/cline-ab-staging
cd /tmp/cline-ab-staging && vsce package --no-dependencies --allow-package-secrets sendgrid

本地构建没有 TELEMETRY_SERVICE_API_KEY，loader 会完全跳过 PostHog，所有人留在 legacy（除非设置 CLINE_BUNDLE_OVERRIDE）——这也是“遥测键必须内联进 loader”这一体检项存在的意义。