fix(ci): regenerate VS Code companion notices after the fast-uri bump - #10867
fix(ci): regenerate VS Code companion notices after the fast-uri bump#10867qwen-code-dev-bot wants to merge 1 commit into
Conversation
) The fast-uri bump in 2a42805 updated package-lock.json but not the committed NOTICES.txt, which pins the resolved version of every bundled transitive dependency. The "Check VS Code companion notices are up-to-date" gate regenerates the file and fails on any drift, so main has been red since that commit. Regenerating pins fast-uri@3.1.7; the license text itself is unchanged.
Autofix E2E report — issue #10864 (main CI failure on
|
| State | Command | Result |
|---|---|---|
| Stale artifact committed (pre-fix) | generate + CI check snippet | exit 1 — "Error: NOTICES.txt is out of date." |
| Regenerated artifact committed (post-fix) | generate + CI check snippet | exit 0 — "NOTICES.txt is up-to-date", git status --porcelain --untracked-files=all empty |
Determinism was also checked: the generator's output is byte-identical to the copy the package prepare hook produced during the runner's npm ci (diff -q → identical), and re-running the generator on the committed tree produces no change at all.
Other gates in the same job (so main is not left red behind this fix)
Because the failing job is the full-profile lint job and the trigger was a lockfile bump, every other gate in that job that a dependency change could plausibly affect was run locally, not assumed:
- Settings-schema freshness guard (the sibling generated-artifact check, immediately before the notices check):
settings.schema.json up-to-date. This is the only other dirty-tree guard inci.yml—grepforgit status --porcelain/git diff --exit-codein that file returns just these two. npm run check-i18n: "✅ All checks passed!".npm run check:serve-fast-path-bundle: "Startup bundle closure checks passed." (a lockfile bump changes what lands in the bundle, so this was worth running rather than assuming).- The job's "Run Prettier" step is
prettier --write .(seerunPrettier()inscripts/lint.js), which exits 0 whether or not it rewrites anything and has no follow-up dirty-tree guard — so it cannot be the failing step.
Incidental observation, deliberately not fixed
Running that CI prettier step locally reformatted 38 unrelated tracked files (859 insertions / 690 deletions), including README.md markdown tables and files under .github/. Those rewrites were side effects of my verification command, not part of the fix, so every one of them was restored with git restore --source=HEAD --worktree -- <paths> (excluding the notices artifact), and the final tree was confirmed clean before committing. The formatting drift is real but out of scope here: it does not fail CI (the step is write-only), most of it sits in .github/ which this workflow may not modify, and folding 38 reformatted files into a one-line CI repair would bury the change. It is worth a separate hygiene issue.
Verification
Commands actually run in this round, with results:
git checkout -b autofix/issue-10864— created fromHEAD=2a428054c4(the commit the failing run built).npm run generate:notices --workspace=qwen-code-vscode-ide-companion(pre-fix, on the clean committed tree) — produced a 1-line drift; reproduced the failure.- CI check snippet from
.github/workflows/ci.yml"Check VS Code companion notices are up-to-date" (pre-fix) — exit 1, "Error: NOTICES.txt is out of date." npm run generate:notices --workspace=qwen-code-vscode-ide-companion(the fix) — regenerated,Total dependencies: 656.diff -qregenerated output vs. theprepare-hook output — identical (generator is deterministic).cd packages/vscode-ide-companion && npx vitest run scripts/generate-notices.test.js— 23 passed (1 file).npm run build— passed (exit 0).npm run typecheck— passed (exit 0).npm run lint— passed (exit 0).npm run generate:settings-schema+ the CI schema-freshness snippet — settings.schema.json up-to-date (no drift, nothing to stage).node scripts/lint.js --prettier(the CI "Run Prettier" step) — exit 0, but it rewrote 38 unrelated tracked files; all restored viagit restore --source=HEAD, tree confirmed clean afterwards.npm run check-i18n— passed ("✅ All checks passed!").npm run check:serve-fast-path-bundle— passed ("Startup bundle closure checks passed.").- CI check snippet (post-commit, on the committed tree) — exit 0, "NOTICES.txt is up-to-date";
git status --porcelain --untracked-files=allempty. git show --stat HEAD—fbc9851251, 1 file changed, 1 insertion(+), 1 deletion(-): onlypackages/vscode-ide-companion/NOTICES.txt.
Not run, with reasons:
- Integration tests (
npm run test:integration:*) — the change is a text artifact that no runtime code path reads at startup; nothing in the bundled CLI behavior changes. - The failing run's logs on GitHub — this runner has no
ghcredentials, so the diagnosis rests on exact local reproduction of the guard at the exact commit instead. The workflow's own independent CI remains the final gate. - macOS/Windows — the notices guard runs only in the Linux lint job, and the generator normalizes CRLF and resolves license files case-insensitively precisely so its output is platform-independent; the regenerated file matched the committed one byte-for-byte apart from the version string.
中文说明
Autofix E2E 报告 — issue #10864（main 在 2a428054c4 上 CI 失败）
概述
main 变红的原因是一个已提交的生成产物过期了。提交 2a428054c4（"chore(deps): bump fast-uri to 3.1.7 to clear the high-severity audit gate (#10862)"）只改动了 package-lock.json——把 fast-uri 从 3.1.5 升到 3.1.7——但没有重新生成 packages/vscode-ide-companion/NOTICES.txt。该文件会为打进 VS Code 伴生扩展的每一个依赖固定记录其解析后的版本号。Qwen Code CI 的 lint 作业会重新生成这个文件，然后对任何差异直接判失败，因此该作业在报告任何测试结果之前就死在这个"新鲜度守卫"上——这与 issue 的描述完全一致。
修复就是把生成产物重新生成：一行改动，fast-uri@3.1.5 → fast-uri@3.1.7。许可证正文本身没有变化（3.1.7 仍然是同样的 MIT 条款），所以这是对已提交生成文件中版本字符串的修正，而不是许可证变更。
根因链条
packages/vscode-ide-companion/NOTICES.txt由scripts/generate-notices.js生成，该脚本读取package.json、package-lock.json以及磁盘上的许可证文件，为每个依赖输出一个name@version头部。它被挂在该包的prepare脚本上，所以任何一次npm ci都会重新生成它。fast-uri是通过@modelcontextprotocol/sdk→ajv→fast-uri进入该产物的；发生变动的 lockfile 条目是提升后的node_modules/fast-uri。.github/workflows/ci.yml中有一个两步守卫："Generate VS Code companion notices"，随后是 "Check VS Code companion notices are up-to-date"；当git status --porcelain packages/vscode-ide-companion/NOTICES.txt非空时以 exit 1 失败。这两步都以fullCI profile 为条件，而只改 lockfile 的变更会被归类为full（.github/scripts/ci/classify-profile.mjs只对纯文档变更和一组固定的github_ci_only文件降级）。- 结果：在
main的2a428054c4上，该守卫必然失败。
复现（修复前，在失败运行所用的确切提交上）
该 runner 没有 GitHub 凭据（gh auth status → "You are not logged into any GitHub hosts"），因此无法读取运行 33703006312 的日志。诊断依据改为在失败运行所构建的确切提交上本地复现该守卫（2a428054c4，即本轮开始时的 HEAD）：
--- pre-check (committed state) ---
(clean)
--- CI step: Generate VS Code companion notices ---
NOTICES.txt generated at .../packages/vscode-ide-companion/NOTICES.txt
Total dependencies: 656
--- CI step: Check notices are up-to-date ---
Error: NOTICES.txt is out of date.
Please run: npm run generate:notices --workspace=qwen-code-vscode-ide-companion
packages/vscode-ide-companion/NOTICES.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
CI_CHECK_EXIT=1
差异恰好就是被升级的那个依赖：
-fast-uri@3.1.5
+fast-uri@3.1.7
(git+https://github.com/fastify/fast-uri.git)修复
一个追加式提交 fbc9851251，只包含重新生成的 packages/vscode-ide-companion/NOTICES.txt（1 file changed, 1 insertion, 1 deletion）。没有触碰任何源码、配置、CI 或 workflow 文件。
有意不新增测试：该行为已经由 CI 的新鲜度守卫本身固定，而且生成器已有覆盖（packages/vscode-ide-companion/scripts/generate-notices.test.js，23 个测试全部通过）。再加一个断言"已提交文件与生成器输出一致"的单元测试只会重复该守卫并放大 diff。
变异探针（反向执行，因为本轮没有新增守卫或分支）
本轮没有新增代码路径，所以见证者就是 CI 守卫本身，并在同一棵树上做了双向探测：
| 状态 | 命令 | 结果 |
|---|---|---|
| 提交了过期产物（修复前） | 生成 + CI 检查片段 | exit 1 — "Error: NOTICES.txt is out of date." |
| 提交了重新生成的产物（修复后） | 生成 + CI 检查片段 | exit 0 — "NOTICES.txt is up-to-date"，git status --porcelain --untracked-files=all 为空 |
同时也验证了确定性：生成器的输出与 runner 执行 npm ci 时该包 prepare 钩子产出的副本逐字节一致（diff -q → identical），并且在已提交的树上再次运行生成器完全不产生变化。
同一作业中的其他门禁（避免修完这一处后 main 仍然是红的）
由于失败作业是 full profile 的 lint 作业、触发原因是一次 lockfile 升级，该作业中所有可能被依赖变更影响的其他门禁都做了本地实际运行，而不是靠假设：
- settings schema 新鲜度守卫（紧邻 notices 检查之前的同类生成产物检查）：
settings.schema.json up-to-date。这也是ci.yml中唯一的另一个"脏树"守卫——在该文件里grepgit status --porcelain/git diff --exit-code只返回这两处。 npm run check-i18n："✅ All checks passed!"。npm run check:serve-fast-path-bundle："Startup bundle closure checks passed."（lockfile 升级会改变进入 bundle 的内容，所以这一步值得实跑而不是假设）。- 该作业的 "Run Prettier" 步骤执行的是
prettier --write .（见scripts/lint.js的runPrettier()），无论是否改写文件都返回 exit 0，且后面没有跟随任何脏树守卫——所以它不可能是失败步骤。
附带发现，有意不修
在本地运行那个 CI prettier 步骤会重新格式化 38 个无关的受版本控制文件（859 insertions / 690 deletions），其中包括 README.md 的 markdown 表格以及 .github/ 下的文件。这些改写是我的验证命令带来的副作用，而不是修复的一部分，因此全部用 git restore --source=HEAD --worktree -- <paths> 恢复（排除 notices 产物），并在提交前确认最终树是干净的。这种格式化漂移确实存在，但不在本次范围内：它不会让 CI 失败（该步骤只写不校验），其中大部分位于本 workflow 不允许修改的 .github/，而且把 38 个被重新格式化的文件塞进一个一行改动的 CI 修复里会掩盖真正的变更。它值得单独立一个整洁性 issue。
验证（Verification）
本轮实际执行的命令及结果：
git checkout -b autofix/issue-10864— 从HEAD=2a428054c4（失败运行所构建的提交）创建。npm run generate:notices --workspace=qwen-code-vscode-ide-companion（修复前，在干净的已提交树上）— 产生 1 行差异；成功复现故障。.github/workflows/ci.yml中 "Check VS Code companion notices are up-to-date" 的检查片段（修复前）— exit 1，"Error: NOTICES.txt is out of date."。npm run generate:notices --workspace=qwen-code-vscode-ide-companion（即修复本身）— 重新生成，Total dependencies: 656。diff -q比较生成器输出与prepare钩子输出 — 完全一致（生成器是确定性的）。cd packages/vscode-ide-companion && npx vitest run scripts/generate-notices.test.js— 23 passed（1 个文件）。npm run build— 通过（exit 0）。npm run typecheck— 通过（exit 0）。npm run lint— 通过（exit 0）。npm run generate:settings-schema+ CI 的 schema 新鲜度检查片段 — settings.schema.json up-to-date（无差异，无需暂存）。node scripts/lint.js --prettier（CI 的 "Run Prettier" 步骤）— exit 0，但它改写了 38 个无关的受控文件；已全部用git restore --source=HEAD恢复，之后确认树干净。npm run check-i18n— 通过（"✅ All checks passed!"）。npm run check:serve-fast-path-bundle— 通过（"Startup bundle closure checks passed."）。- CI 检查片段（提交后，在已提交的树上）— exit 0，"NOTICES.txt is up-to-date"；
git status --porcelain --untracked-files=all为空。 git show --stat HEAD—fbc9851251，1 file changed, 1 insertion(+), 1 deletion(-)：只有packages/vscode-ide-companion/NOTICES.txt。
未运行的命令及原因：
- 集成测试（
npm run test:integration:*）— 本次改动是一个文本产物，启动时没有任何运行时代码路径读取它；打包后 CLI 的行为没有任何变化。 - GitHub 上失败运行的日志 — 该 runner 没有
gh凭据，因此诊断改为依据在确切提交上对该守卫的本地精确复现。workflow 自身的独立 CI 仍是最终验证门禁。 - macOS/Windows — notices 守卫只在 Linux 的 lint 作业中运行，而且生成器会规范化 CRLF、并以大小写不敏感方式解析许可证文件，正是为了让其输出与平台无关；重新生成的文件除版本字符串外与已提交文件逐字节一致。
🧠 Handled by Qwen Code · model/模型 qwen3.8-max-2026-09-02
github-actions
Bot
added
the
review/self-reported
|
Thanks for the repair — but it turns out the same fix already landed on
One procedural note: the linked issue #10864 is still open, and that is what keeps this gate from closing the PR autonomously as a duplicate — the duplicate-close path only fires once the linked issue is closed by the merged fix. Rather than guess, I'm handing it over. ⏸️ Deferring to @yiliang114 — you merged the identical fix in #10863; please close this PR as a duplicate (and #10864 too, since the notices guard on 中文说明感谢这个修复——不过同样的修补已经合入
一个流程上的说明：关联 issue #10864 仍处于 open 状态，这正是本门禁没有直接按重复项关闭该 PR 的原因——duplicate-close 路径只在关联 issue 被已合并的修复关闭时才触发。与其擅自猜测，不如转交人工处理。 ⏸️ 转交 @yiliang114——相同的修复已由你在 #10863 合入；请将本 PR 作为重复项关闭（ — Qwen Code · qwen3.8-max Reviewed at |
Independent verification — built the real environment and reproduced every stepI ran this on a standalone clone with a clean Verdict: the bug this PR fixes is real, the fix is correct — and it was already on
1. The bug is real, and it reproduces byte-for-byte
Arm B's local output matches the real failing job — I pulled the log of run The diff really is only the version line: 2. …but it was already fixed on
|
| 装置 | |
|---|---|
| 树 | QwenLM/qwen-code 独立 clone，main @ fa5f7a11a0，外加 2a428054c4 与 PR head fbc9851251 |
| 安装 | 干净 npm ci，3 分 13 秒，exit 0——三个臂 lockfile 完全一致（git diff 2a428054c4 main -- package-lock.json 为空），因此一次安装可忠实服务全部三臂 |
| 运行时 | macOS arm64，Node v22.23.2 / npm 10.9.8——与失败 CI 作业所用 Node 完全相同 |
| 守卫 | .github/workflows/ci.yml:348-363 两个 step 逐字转录，按 Actions 的方式在 bash -e -o pipefail 下执行 |
| 规模 | 656 条依赖条目，NOTICES.txt 共 27 628 行 |
1. Bug 是真的，且逐字节复现
| 臂 | HEAD | 已提交 sha256 | 重新生成 sha256 | CI_CHECK_EXIT |
|---|---|---|---|---|
| B 修复前 main | 2a428054c4 |
644bd6d57263221a… |
4575b46a393b2d89… |
1 ✗ |
| A 当前 main | fa5f7a11a0 |
4575b46a393b2d89… |
4575b46a393b2d89… |
0 ✓ |
| C PR #10867 head | fbc9851251 |
4575b46a393b2d89… |
4575b46a393b2d89… |
0 ✓ |
臂 B 的本地输出与真实失败作业一致——我拉取了 run
33703006312 的日志（PR 作者说他们的 runner
读不到）。step Check VS Code companion notices are up-to-date 打印了 Error: NOTICES.txt is out of date.，
后面跟着同样的 1 file changed, 1 insertion(+), 1 deletion(-)。
也就是说 PR 正文的诊断是对着该 run 自身的输出核实过的，不只是重新推导。
差异确实只有版本号那一行：修复前 blob 与 PR head blob 的 diff 恰好只有
4359c4359 / < fast-uri@3.1.5 / > fast-uri@3.1.7，两侧都是 27 628 行，许可证正文未被触碰。
2. ……但 main 上早已修好——三条独立证据
- 两个 blob 逐字节相同。
main:NOTICES.txt与pr10867-head:NOTICES.txt的哈希都是
4575b46a393b2d89dd79abf00ca0673cbf93b0aa711822e63898b4ed5b34a1f9。 - 合并不会改动任何文件。
git merge-tree --write-tree main pr10867-head→eece06ee9fef484d…，
这正是main自己的 tree 对象。在这里做 squash-merge 只会产生一个空 commit 和一次完整的 main CI。 - 真实 CI 已经认可。
055e831556（即已合入的 chore(vscode): refresh NOTICES for the fast-uri bump #10863）的 push run
33706578154 中，
Generate VS Code companion notices与Check VS Code companion notices are up-to-date均为 success。
根因是时间差，而不是修复本身有错：PR 分支切自 2a428054c4（git merge-base 可证），
因此它的 diff 是对着一个已经不再代表 main 的基线算出来的。
01:16 UTC main CI run 33703006312 在 2a428054c4 上失败 —— NOTICES.txt 过期
02:06 UTC main-CI-failure 机器人开出 issue #10864
02:09 UTC PR #10863 以 055e831556 合入 —— 同样的一行重新生成
02:44 UTC PR #10867 开出，分支切自 2a428054c4，比修复落地晚 34 分钟
02:57 UTC PR #10867 以 superseded 关闭 03:01 UTC issue #10864 关闭
3. 可选步骤 4 和 5 都通过，并且 macOS 可以从 ⚠️ 升为 ✅
- 步骤 4——确定性。 连续三次运行生成器得到相同 sha256 且树保持干净，
且该哈希与npm ci的prepare生命周期在安装期间已写入的内容相同。不是碰巧一致。 - 步骤 5——兄弟守卫。
npm run generate:settings-schemaexit 0，
schemas/settings.schema.json保持干净，没有过期。 - 跨平台。 PR 把 macOS 标为
⚠️ （未测）。我在 macOS 上重新生成得到4575b46a…，
正是 Linux CI 重新生成并接受的那份 blob。656 条条目在两个平台上完全一致，
说明生成器刻意做的 CRLF 规范化与大小写不敏感许可证查找确实成立。macOS 那一行可以改成 ✅。
4. 一条遗留发现——不是本 PR 的锅，但它的「未验证」说明是对的
PR 提到 CI 的 prettier 步骤会改写无关的受控文件。已确认，而且比「表面问题」更严重：
ci.yml → node scripts/lint.js --prettier → scripts/lint.js:201 执行的是 prettier --write .。
它只写不校验，所以格式漂移永远不可能让 CI 变红。在干净的 fa5f7a11a0 检出上，
它会在 81 秒内改写 36 个受控文件，分布在 .github/workflows/、packages/web-shell/、
packages/cli/、.github/scripts/ 和 scripts/。NOTICES.txt 不在其中，因此与本守卫没有相互影响。
值得单开一个整洁性 issue——想把 --write 换成 --check，得先把这 36 个文件修掉。
5. 范围与边界
- 只在 macOS 上验证；Linux 一侧是通过 CI 在相同字节上的 step 成功间接覆盖的，我没有自建 Linux 容器。
- 没有跑仓库测试套件——本 PR 不改任何运行时代码路径，我实测的这个守卫就是它的全部影响面。
- 已关闭的 Main CI failed: Qwen Code CI on 2a428054c4ee #10864 上仍挂着
autofix/in-progress标签；无害，但如果有清扫逻辑依赖它，就是一个陈旧标签。
Code Coverage Summary
CLI Package - Full Text ReportCore Package - Full Text ReportFor detailed HTML reports, please see the 'coverage-reports-22.x-ubuntu-latest' artifact from the main CI run. |
4 participants
What this PR does
Regenerates the third-party notices file that ships with the VS Code companion extension, so that it agrees with the dependency versions the lockfile now resolves. The only content change is the version pinned in the
fast-urientry, which moves from3.1.5to3.1.7; the license text under that entry is byte-for-byte what it was, because the newer release carries the same MIT terms.No source, configuration, CI, or workflow file is touched. This is a committed generated artifact being brought back in sync with its generator.
Why it's needed
mainis currently red. The recent dependency bump that raisedfast-urito 3.1.7 changed the lockfile alone and did not regenerate the notices artifact, which pins the resolved version of every dependency bundled into the companion extension. Continuous integration regenerates that artifact and then fails the build on any difference, so the lint job aborted on this freshness guard before a single test result was reported — which is what issue #10864 tracks.Because the generator is wired into the package's install lifecycle, the drift is not cosmetic: every clean install rewrites the file locally, and every full-profile CI run fails on it. The guard is deterministic, so
mainstays red until the artifact is regenerated.Reviewer Test Plan
How to verify
Check out
mainat2a428054c4(the commit the failing run built) with a cleannpm ciinstall, then run the two CI steps in order:Expected on unpatched
main: the status line is non-empty — the CI guard printsError: NOTICES.txt is out of date.and exits 1. The diff is a single line,-fast-uri@3.1.5/+fast-uri@3.1.7.Apply this PR (or just re-run the generator and keep the result) and repeat step 1. Expected:
git status --porcelain packages/vscode-ide-companion/NOTICES.txtprints nothing, i.e. the CI guard reportsNOTICES.txt is up-to-dateand exits 0.Confirm the diff this PR introduces is only that version line:
git show --stat HEADreports one file changed, one insertion, one deletion, andgit diff HEAD~1 -- packages/vscode-ide-companion/NOTICES.txtshows no change to any license text.Optional — confirm the generator is deterministic rather than incidentally matching: run it twice in a row and verify the second run leaves the tree clean, and that the output equals what the package's install lifecycle already produced during
npm ci.Optional — confirm the sibling generated-artifact guard is not also stale:
npm run generate:settings-schemafollowed bygit status --porcelain packages/vscode-ide-companion/schemas/settings.schema.jsonshould print nothing.Evidence (Before & After)
N/A — non-UI change. The relevant before/after is the CI guard's exit status on the same tree, recorded in the autofix report:
Tested on
Linux-only is sufficient here: the notices guard runs solely in the Linux lint job, and the generator deliberately normalizes CRLF and resolves license files case-insensitively so its output does not depend on the host platform. The regenerated file matched the committed one byte-for-byte apart from the version string.
Environment (optional)
Clean
npm ciinstall in the CI sandbox container, Node v22.23.2. No model calls, no CLI runtime, no network access beyond the install itself — the generator reads onlypackage.json,package-lock.json, and license files already on disk.Risk & Scope
ghcredentials), so the diagnosis rests on reproducing the guard locally at the exact commit the run built rather than on the run's own output; the workflow's independent CI is the final gate. Integration tests were not run — no runtime code path changes. Separately, running the repository's CI prettier step locally reformatted 38 unrelated tracked files, includingREADME.mdtables and files under.github/; those rewrites were restored and are deliberately excluded. That formatting drift does not fail CI (the step writes and never verifies), most of it lives in an area this change must not touch, and folding it in would bury a one-line repair — it deserves its own hygiene issue.Linked Issues
Fixes #10864
中文说明
这个 PR 做了什么
重新生成随 VS Code 伴生扩展一起发布的第三方声明文件，使其与 lockfile 当前解析出的依赖版本保持一致。唯一的内容变化是
fast-uri条目中固定的版本号，从3.1.5变为3.1.7；该条目下的许可证正文与之前逐字节相同，因为新版本沿用的是同样的 MIT 条款。没有触碰任何源码、配置、CI 或 workflow 文件。这只是把一个已提交的生成产物重新与它的生成器同步。
为什么需要
main目前是红的。最近那次把fast-uri提升到 3.1.7 的依赖升级只改了 lockfile，没有重新生成声明产物，而该产物会固定记录打进伴生扩展的每一个依赖的解析版本。持续集成会重新生成该产物，然后对任何差异直接判失败，因此 lint 作业在报告任何测试结果之前就中止在这个新鲜度守卫上——这正是 issue #10864 所跟踪的问题。由于生成器挂在该包的安装生命周期上，这种漂移并不只是表面问题：每一次干净安装都会在本地改写该文件，而每一次 full profile 的 CI 运行都会因此失败。该守卫是确定性的，所以在产物被重新生成之前，
main会一直是红的。审阅者测试计划
如何验证
在干净的
npm ci安装下检出main的2a428054c4（失败运行所构建的提交），然后按顺序执行这两个 CI 步骤：在未打补丁的
main上预期：该 status 行非空——CI 守卫会打印Error: NOTICES.txt is out of date.并以 exit 1 结束。差异只有一行，-fast-uri@3.1.5/+fast-uri@3.1.7。应用本 PR（或者只是重新运行生成器并保留结果），重复第 1 步。预期：
git status --porcelain packages/vscode-ide-companion/NOTICES.txt不输出任何内容，即 CI 守卫报告NOTICES.txt is up-to-date并以 exit 0 结束。确认本 PR 引入的差异只有那一行版本号：
git show --stat HEAD报告 1 file changed、1 insertion、1 deletion，且git diff HEAD~1 -- packages/vscode-ide-companion/NOTICES.txt显示任何许可证正文都没有变化。可选——确认生成器是确定性的，而不是碰巧一致：连续运行两次，验证第二次运行后树仍然是干净的，并且其输出与
npm ci期间该包安装生命周期已经产出的内容相同。可选——确认同类的另一个生成产物守卫也没有过期：执行
npm run generate:settings-schema，随后git status --porcelain packages/vscode-ide-companion/schemas/settings.schema.json应当不输出任何内容。证据（修改前与修改后）
N/A —— 非 UI 改动。相关的前后对比是同一棵树上 CI 守卫的退出状态，已记录在 autofix 报告中：
测试平台
这里只在 Linux 上验证是足够的：notices 守卫仅在 Linux 的 lint 作业中运行，而且生成器会有意规范化 CRLF、并以大小写不敏感方式解析许可证文件，正是为了让其输出不依赖宿主平台。重新生成的文件除版本字符串外与已提交文件逐字节一致。
环境（可选）
在 CI 沙箱容器中执行干净的
npm ci安装，Node v22.23.2。没有模型调用、没有 CLI 运行时、除安装本身外没有网络访问——生成器只读取package.json、package-lock.json以及磁盘上已有的许可证文件。风险与范围
gh凭据），因此诊断依据是在该运行所构建的确切提交上本地复现该守卫，而不是该运行自身的输出；workflow 的独立 CI 是最终门禁。未运行集成测试——没有任何运行时代码路径发生变化。另外，在本地运行仓库的 CI prettier 步骤会重新格式化 38 个无关的受控文件，包括README.md的表格和.github/下的文件；这些改写已被恢复并被有意排除。那种格式化漂移不会让 CI 失败（该步骤只写不校验），其中大部分位于本次改动不应触碰的区域，而且把它并进来会掩盖一个一行改动的修复——它应当单独立一个整洁性 issue。关联 Issue
Fixes #10864