fix(review): screen content filters before the probe tree's restore too (#9558) - #9566
fix(review): screen content filters before the probe tree's restore too (#9558)#9566wenshao wants to merge 11 commits into
Conversation
…oo (#9558) `scratch-tree` refuses to create or reset a tree while the repository's LOCAL config defines a content filter, because a checkout executes `filter.<name>.smudge` whenever it rewrites a file and disabling hooks does not cover that. `test-efficacy`'s per-run restore is the same checkout one directory over — it rewrites every tracked file in the probe tree, twice per probe run — and screened nothing. The screen moves to `lib/worktree.ts` so both callers share one implementation rather than one growing a corner the other lacks, which is how the `config.worktree` scoping bug got in. `filter.<name>.process` joins `smudge` and `clean`: it is the third executable key — a long-running filter git speaks a protocol to — and enumerating two of three is how the first cut read as complete. **Repo-local only, and that is the load-bearing part.** `git lfs install` writes `filter.lfs.clean` into the user's GLOBAL config, so a screen over merged config would put every contributor with git-lfs into permanent refusal — the same failure as a tripwire that fires on every healthy run, which this pipeline has already shipped once. Both halves are pinned: removing the screen turns the new test red, and widening it to merged config turns the same test red from the other side.
github-actions
Bot
added
the
review/self-reported
|
✅ Qwen Triage finished — CI landed green on ✅ Qwen Triage 已完成 —— |
|
Thanks for the PR! Template looks good ✓ Problem: observed and documented. Linked issue #9558 ( Direction: aligned. This is the review pipeline's own safety screening, following up a triaged issue that prescribes exactly this shape: scope the screen to repo-local config, apply it in Size: not applicable — all five files live under Approach: the scope feels right. This is a move-plus-two-fixes, not new machinery: one shared implementation instead of the two callers drifting, the screen applied before the probe restore, and the key regex completed ( Risk: no elevated risk signals — none of the changed files match the high-risk path patterns from the revert-history analysis. Moving on to code review. 🔍 中文说明感谢贡献！ 模板完整 ✓ 问题：已观测且有记录。关联 issue #9558（ 方向：对齐。这是 review 流水线自身的安全屏蔽，跟进的 issue 已给出明确形态：把屏蔽限定在仓库本地配置、在 规模：不适用——五个文件全部位于 方案：范围合理。这是"移动 + 两处修复"，不是新机制：两个调用方共用一份实现而不再各自漂移、屏蔽前置到探针恢复之前、键正则补全（ 风险：无升级风险信号——改动文件均未命中 revert 历史分析得出的高风险路径模式。 进入代码审查 🔍 — Qwen Code · qwen3.8-max Reviewed at |
Code reviewMy independent read of #9558 before looking at the diff: lift What I verified against the base tree:
No blockers found. Test evidenceUnattended CI run — PR code is never executed here; the evidence below is the PR's own CI, fetched once via the API at review time. No failures on the head commit at fetch time. Still in flight at fetch time: the Linux unit suite — the behavioural surface is pinned by the new tests above, CI confirms them, and the finalize job rewrites the table when it lands (approval is deferred to that point). The macOS/Windows test jobs report Final CI results for
One row per check name (latest run); skipped checks omitted; failures sort first. / 每个检查名一行（取最新一次运行），省略 skipped，失败项排在最前。 The change has no user-visible surface (internal to the review pipeline's probe phase), so no TUI capture applies to this run. 中文说明代码审查在看 diff 之前我对 #9558 的独立判断是：把 对照基线代码核实的内容：
未发现阻塞问题。 测试证据无人值守 CI 运行——此处从不执行 PR 代码；以下证据是 PR 自己的 CI，在审查时通过 API 一次性获取。获取时 head 提交上无失败。获取时仍在运行：Linux 单元测试套件——行为面已由上述新测试钉住，CI 负责确认，finalize 任务会在其结束后重写表格（批准也推迟到那一刻）。macOS/Windows 测试作业按 GitHub 自身元数据显示为 该改动无用户可见面（属于 review 流水线探针阶段内部），因此本次运行不适用 TUI 抓取。 — Qwen Code · qwen3.8-max Reviewed at |
|
Confidence: 5/5 — the diff is exactly the fix #9558 prescribed, the tests pin both directions of it, and I found nothing to push back on. Stepping back: this is the remaining half of a documented security finding, and it reads like the close-out it claims to be. The screen moves to the shared lib instead of growing a second copy, the probe tree's restore gets the same refusal the scratch tree already had, and the key enumeration is completed — each change is one of the three the PR names, nothing extra. The design choice I was most skeptical about going in — refusing on repo-local config only — is the right one, and the test carrying the global git-lfs fixture is what keeps a future "tightening" round from quietly breaking it. The tests run real git repositories through the production entry point rather than mocking the surface, which is what makes a green suite here evidence instead of ritual. My independent proposal before reading the diff matched what the PR does; I have no simpler path to offer. The only thing standing between this and an approval is the unit suite, which was still running at review time — approval deferred until CI lands green on 中文说明回头整体看：这是已记录安全发现的剩余一半，读起来正是它所声称的收尾工作。屏蔽移入共享 lib 而不是长出第二份拷贝，探针树的恢复获得了与 scratch 树相同的拒绝，键枚举被补全——每处改动都是 PR 所命名的三项之一，没有多余内容。我最初最有疑虑的设计选择——仅依据仓库本地配置拒绝——是正确的，而携带全局 git-lfs 夹具的测试正是保证未来某轮"收紧"不会悄悄破坏它的关键。测试通过生产入口在真实 git 仓库上运行，而不是 mock 该表面，这正是套件变绿在此处是证据而非仪式的原因。 我在看 diff 之前的独立方案与 PR 做法一致，没有更简路径可提供。唯一挡在批准之前的是单元测试套件——审查时仍在运行；批准推迟到 CI 在该提交上变绿，届时 finalize 任务会发布钉住该提交的批准。 — Qwen Code · qwen3.8-max Reviewed at |
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. |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
LGTM, looks ready to ship — CI landed green after the review. ✅
|
@qwen-code /takeover |
qwen-code-dev-bot
added
the
autofix/takeover
|
🤝 Takeover engaged: the autofix loop now manages this PR — it will address new review feedback and resolve base conflicts until the label is removed or the round cap is reached. Remove the 中文说明🤝 已接管：autofix 循环现在管理此 PR —— 将持续处理新的评审反馈与 base 冲突，直到移除标签或达到轮次上限。移除 |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Partially reviewed — gaps disclosed.
Not reviewed: reverse audit — stopped before round 4 by the review time budget.
Test Plan (not a blocker): 941 passed — this review observed 22434 passed.
中文说明
仅完成部分审查，审查缺口已披露。
未审查：反向审计——评审时间预算不足，未能开始第 4 轮。
Test Plan（非阻断）：941 passed — this review observed 22434 passed。
— qwen3.8-max via Qwen Code /review (v0.21.14)
| const filters = localFilterCommands(probeTree); | ||
| if (filters.length > 0) { |
There was a problem hiding this comment.
[Critical] This screen guards only restoreProbeTreeTracked's restore checkout, but the probe pipeline contains further filter-executing checkouts it never screens: the revert phase's git checkout base -- ...modified (line 2868), the probe tree's creation git worktree add (line 2541), and the base tree's creation (base-tree.ts:268). A planted filter can therefore still execute after this PR — even after the screen has detected the plant: runOneMutant maps a restore refusal to inconclusive and returns normally, and the mutation phase's catch (~line 2818) explicitly continues "so the revert probe below still runs", so the flow lands in the unscreened revert checkout. Issue #9558's stage-2 analysis names the revert checkout explicitly and prescribes a run-entry screen covering "the restore, the revert, and any other checkout the probe phase performs"; the doc comment this PR adds enumerates only the restore and reads as complete coverage.
Failure scenario: the PR's suite plants git config filter.evil.smudge CMD into the shared common config plus one info/attributes line during the baseline run. Every screened restore correctly refuses, but the revert phase's unscreened checkout rewrites files matching the attribute glob and EXECUTES the planted command as the reviewer. Persistence variant: a filter planted before the run also fires during the probe tree's worktree add, which precedes every screen call.
Witness (probe, git 2.43):
pathspec checkout of an identical file -> marker ABSENT
`git checkout HEAD -- a.ts` of a MODIFIED file
with planted smudge + `* filter=evil` attr -> MARKER-pathspec created
`git worktree add --detach <probe> <sha>` -> MARKER-wt created
Suggested fix: hoist the screen to probe-run entry (the way scratch-tree screens before its reset), or at minimum screen before the revert checkout, and make the added doc comment's enumeration true.
中文说明
该屏蔽只守护了 restoreProbeTreeTracked 的恢复 checkout，但探针流水线中还有多个会执行过滤器的 checkout 未被屏蔽：revert 阶段的 git checkout base -- ...modified（第 2868 行）、探针树创建时的 git worktree add（第 2541 行）、以及 base 树的创建（base-tree.ts:268）。因此在本 PR 之后，植入的过滤器依然可能被执行——甚至在屏蔽已经检测到植入之后：runOneMutant 把恢复拒绝映射为 inconclusive 并正常返回，突变阶段的 catch（约第 2818 行）明确注释"继续执行，让下面的 revert 探针仍然运行"，于是流程落入未屏蔽的 revert checkout。Issue #9558 的 stage-2 分析明确点名了 revert checkout，并开出"在运行入口做一次屏蔽，覆盖 restore、revert 以及探针阶段执行的任何其他 checkout"的处方；而本 PR 新增的文档注释只列举了 restore，读起来像是完整覆盖。
失败场景：PR 的测试套件在基线运行期间向共享 common 配置写入 git config filter.evil.smudge CMD，并向 info/attributes 追加一行。之后每次被屏蔽的恢复都正确拒绝，但 revert 阶段未屏蔽的 checkout 会重写匹配 attributes 通配的文件，并以审查者身份执行植入的命令。持久化变体：运行前植入的过滤器也会在探针树的 worktree add 时触发——而该操作先于所有屏蔽调用。
证据（探针实验，git 2.43）：对内容相同文件的 pathspec checkout → 标记文件未创建；对已修改文件执行 git checkout HEAD -- a.ts（植入 smudge + * filter=evil 属性）→ 标记文件被创建；git worktree add --detach → 标记文件被创建。
修复建议：把屏蔽提升到探针运行入口（如同 scratch-tree 在 reset 前做屏蔽那样），或至少在 revert checkout 前做一次屏蔽，并让新增文档注释的列举与实际一致。
— qwen3.8-max via Qwen Code /review (v0.21.14)
| 'config', | ||
| '--file', | ||
| file, | ||
| '--get-regexp', |
There was a problem hiding this comment.
[Critical] git config --file does NOT expand include.path/includeIf directives, while the checkouts this screen authorises read merged config, which does. A filter defined behind an include planted in the repo-local config is invisible to the screen and still EXECUTED — defeating both the scratch-tree screen and the probe-restore screen this PR installs. The include target lives outside the tree, so the restore's clean -ffdx never removes it.
Failure scenario: a probe makes the same class of write the doc comment names as the planting surface — git config include.path <abs> lands [include] path=... in the very <common>/config this code reads; the probe puts [filter "evil"] smudge = CMD in <abs> and one info/attributes line. The screen's exact read exits 1 with no output (reports clean) while the restore's force-checkout follows the include and executes CMD as the reviewer. includeIf.gitdir: plants behave identically.
Witness (probe):
git config --file .git/config --get-regexp '^filter\..*\.(smudge|clean|process)$'
-> exit 1, no output (screen reports clean)
merged read -> filter.evil.smudge touch .../MARKER
git checkout HEAD -- a.ts (modified file) -> MARKER created
includeIf.gitdir: arm -> identical
--includes fix arm -> plant surfaced, exit 0
中文说明
git config --file 不会展开 include.path/includeIf 指令，而该屏蔽所授权的 checkout 读取的是会展开这些指令的合并配置。通过植入到仓库本地配置中的 include 所定义的过滤器，对屏蔽不可见，却仍然会被执行——这使得 scratch-tree 的屏蔽和本 PR 新装的探针恢复屏蔽双双失效。include 目标文件位于树外，恢复时的 clean -ffdx 永远不会清除它。
失败场景：探针进行文档注释所点名的那类写入——git config include.path <绝对路径> 会把 [include] path=... 写进本代码所读取的那个 <common>/config；探针再把 [filter "evil"] smudge = CMD 写入该目标文件，并追加一行 info/attributes。屏蔽使用的这条精确读取命令以退出码 1 无输出结束（报告干净），而恢复的强制 checkout 会跟随 include 并以审查者身份执行 CMD。includeIf.gitdir: 植入手法的表现完全相同。
证据（探针实验）：--file 读取 → 退出码 1、无输出（屏蔽报告干净）；合并读取 → 能读到 filter.evil.smudge；对已修改文件执行 checkout → 标记文件被创建；--includes 修复分支 → 植入被读出（退出码 0）。
| 'config', | |
| '--file', | |
| file, | |
| '--get-regexp', | |
| 'config', | |
| '--file', | |
| file, | |
| '--includes', | |
| '--get-regexp', |
— qwen3.8-max via Qwen Code /review (v0.21.14)
| const filters = localFilterCommands(probeTree); | ||
| if (filters.length > 0) { |
There was a problem hiding this comment.
[Critical] The screen and the checkout it authorises are an unguarded check-then-use pair. runProbeSuite spawns the suite with plain spawnSync and nothing reaps detached descendants on normal completion (the group kills in run.ts fire only on timeout/SIGTERM of the outer wrapper group, and a setsid'd grandchild escapes them anyway), so a process spawned by the PR's own test code can toggle the filter config between the screen's read and the checkout's read. The sibling guard one function down already treats this adversary as live — "the threat this guard exists for has a shell inside these trees and picks its moment" (~lines 2025-2026, with re-checks at the write sites) — but the new screen has no second check.
Measured against the real runOneMutant path: a fast atomic toggler (cp+rename, sub-ms) executed the planted smudge in 18 of 600 trials (~8.4% of the trials whose screen passed) vs 0/40 for a static plant. A review performs a restore before every mutant, hunk, baseline and revert run — dozens of trials — so at ~3%/trial a review has a majority probability of at least one bypass; a triggered writer watching the screen's config reads would raise the rate further (not measured). Note the post-checkout re-screen a first-cut fix might reach for is detection, not prevention — the smudge executes inside the checkout itself; reaping the suite's process tree is the preventive half.
Witness (probe):
{"mode":"fast-writer","trials":150,"screenRefusals":103,
"restorePassedThenSuitePhase":47,"smudgeExecutionsDuringPassedScreens":4}
(4/4/4/6 across four runs)
{"mode":"static-set","trials":40,"screenRefusals":40,
"smudgeExecutionsDuringPassedScreens":0}
reap arm (writer killed mid-run): 0 executions in 125 post-reap trials
中文说明
屏蔽与它所授权的 checkout 构成一个无防护的"先检查后使用"对。runProbeSuite 用普通 spawnSync 启动测试套件，正常结束时没有任何机制回收分离（detached）的子孙进程（run.ts 里的进程组 kill 只在外层包装组超时/收到 SIGTERM 时触发，而 setsid 出来的孙进程本来就不在那个组里），因此 PR 自己的测试代码所 spawn 的进程，可以在屏蔽读取与 checkout 读取之间切换过滤器配置。下一个函数里的姊妹守卫已经把这一对手当作现实威胁——"这个守卫要防的威胁在这些树里有一个 shell，并且会挑时机"（约第 2025-2026 行，且在每个写入点复查）——但新增的屏蔽没有第二次检查。
在真实 runOneMutant 路径上实测：快速原子切换器（cp+rename，亚毫秒级）在 600 次试验中让植入的 smudge 执行了 18 次（约占屏蔽放行试验的 8.4%），而静态植入的对照组为 0/40。一次审查会在每个 mutant、hunk、基线和 revert 运行之前各做一次恢复——几十次试验——按每次约 3% 计算，一次审查至少被穿透一次的概率过半；一个监视屏蔽配置读取的触发式写入器会把成功率进一步抬高（未测量）。注意：事后补一次重新屏蔽只是"检测"而非"预防"——smudge 是在 checkout 内部执行的；真正起预防作用的是回收套件的进程树。
证据（探针实验）：fast-writer 模式 150 次试验中 4 次执行（四轮分别 4/4/4/6）；static-set 对照 40 次全部拒绝、0 次执行；回收分支（运行中杀掉写入器）之后 125 次试验 0 次执行。
— qwen3.8-max via Qwen Code /review (v0.21.14)
| const candidates = [ | ||
| join(common, 'config'), | ||
| join(resolve(worktree, gitDir), 'config.worktree'), | ||
| ]; |
There was a problem hiding this comment.
[Critical] When the screening worktree is a LINKED worktree (the pipeline's only shape — review worktree, scratch tree and probe tree are all siblings sharing the user's <common> dir), candidates covers <common>/config, the screening tree's own config.worktree, and every <common>/worktrees/*/config.worktree — but never <common>/config.worktree, the MAIN worktree's per-worktree config at the common root. A probe writes core.repositoryformatversion=1 + extensions.worktreeConfig=true into <common>/config (non-filter keys, invisible to the regex), [filter "evil"] smudge = CMD into <common>/config.worktree, and one attributes line; the screen reports clean through the whole review, and the plant fires on the user's own later main-worktree checkouts — the exact persistence outcome the doc comment this PR adds says the screen exists to refuse. On git 2.43.0 the harm is stronger: git worktree add copies that file into new worktrees and the initial checkout executes it, so the plant also fires DURING the review, after the screen reported clean.
Witness (probe):
same plant:
localFilterCommands(linkedReviewWt) -> [] (screen clean)
localFilterCommands(mainRepo) -> ['filter.evil.smudge'] (caught)
user's main worktree, dirty-then-restore checkout -> smudge FIRED
`git switch main` -> fired again
git 2.43.0 worktree-add arm -> fired inside the review worktree
fix arm: adding join(common, 'config.worktree') flips the probe
from [] to ['filter.evil.smudge']
Refusing on a key some git versions/flows would not honor is consistent with the screen's existing fail-safe posture (the readdir branch already refuses on inert config.worktree files).
中文说明
当执行屏蔽的工作树是链接工作树时（流水线的唯一形态——review 工作树、scratch 树和探针树都是共享用户 <common> 目录的兄弟工作树），candidates 覆盖 <common>/config、屏蔽树自己的 config.worktree、以及 <common>/worktrees/*/config.worktree 的遍历——但从不包含 <common>/config.worktree，即位于 common 根目录的主工作树 per-worktree 配置。探针把 core.repositoryformatversion=1 + extensions.worktreeConfig=true 写入 <common>/config（非 filter 键，即使在被扫描的文件里也对正则不可见），把 [filter "evil"] smudge = CMD 写入 <common>/config.worktree，再写一行 attributes；屏蔽在整个审查期间都报告干净，而植入会在用户之后于自己主工作树中的 checkout 上触发——这正是本 PR 新增文档注释声称该屏蔽存在的目的所要拒绝的持久化结果。在 git 2.43.0 上危害更大：git worktree add 会把该文件复制进新工作树，初始 checkout 就会执行它，因此植入还会在审查过程中、在屏蔽报告干净之后触发。
证据（探针实验）：同一植入下，localFilterCommands(linkedReviewWt) → []（屏蔽干净），而 localFilterCommands(mainRepo) → ['filter.evil.smudge']（能抓到）；用户主工作树中"弄脏后恢复"的 checkout 触发了 smudge；git switch main 再次触发；2.43.0 的 worktree-add 分支在 review 工作树内触发；修复分支（把 join(common, 'config.worktree') 加入 candidates）使探针结果由 [] 翻转为 ['filter.evil.smudge']。
对某些 git 版本/流程中并不生效的键采取拒绝姿态，与该屏蔽既有的保守兜底一致（readdir 分支本来就会拒绝在 extensions.worktreeConfig 关闭时并不生效的 config.worktree 文件）。
| const candidates = [ | |
| join(common, 'config'), | |
| join(resolve(worktree, gitDir), 'config.worktree'), | |
| ]; | |
| const candidates = [ | |
| join(common, 'config'), | |
| join(common, 'config.worktree'), | |
| join(resolve(worktree, gitDir), 'config.worktree'), | |
| ]; |
— qwen3.8-max via Qwen Code /review (v0.21.14)
| expect(r.verdict).toBe('inconclusive'); | ||
| expect(r.detail).toContain('filter.evil.smudge'); |
There was a problem hiding this comment.
[Suggestion] The test pins the refusal's verdict and message but never asserts the planted filter actually did NOT execute — and as written it cannot: the fixture sets no filter=evil attribute line and the tree is clean at restore time, so the smudge command is unfirable regardless of screening. Nothing discriminates a screen moved below the checkout it guards. The scratch-tree.test.ts block's expect(existsSync(pwned)).toBe(false) is vacuous for the same reason, and the hard-coded shared marker /tmp/qwen-should-never-run is also used at scratch-tree.test.ts:153.
Failure scenario: a future edit moves localFilterCommands(probeTree) below the checkout --force/clean spawns in restoreProbeTreeTracked; both tests stay green because they only check verdict/detail/marker-existence on an unfirable fixture.
Suggested fix: write *.ts filter=evil to .git/info/attributes in the fixture, dirty the file before the run (simulating prior-run residue), point smudge at a marker inside the test's own mkdtempSync dir, and assert the marker does not exist after the refusal; mirror in the scratch-tree block.
中文说明
该测试钉住了拒绝的 verdict 与消息，但从未断言植入的过滤器确实没有被执行——而且按现有写法也无法断言：夹具没有设置 filter=evil 属性行，且恢复时树是干净的，所以无论屏蔽与否，smudge 命令都不可能被触发。即便有人把屏蔽挪到它所守护的 checkout 之下，也不会有任何测试能分辨出来。scratch-tree.test.ts 里的 expect(existsSync(pwned)).toBe(false) 出于同样原因是空断言；硬编码的共享标记路径 /tmp/qwen-should-never-run 还在 scratch-tree.test.ts:153 被使用。
失败场景：未来某次修改把 localFilterCommands(probeTree) 挪到 restoreProbeTreeTracked 中 checkout --force/clean 启动之后；两个测试依然全绿，因为它们只检查一个不可能触发的夹具上的 verdict/detail/标记存在性。
修复建议：在夹具中向 .git/info/attributes 写入 *.ts filter=evil，在运行前把文件弄脏（模拟上一轮的残留），把 smudge 指向测试自身 mkdtempSync 目录内的标记文件，并在拒绝后断言该标记不存在；scratch-tree 的测试块做同样处理。
— qwen3.8-max via Qwen Code /review (v0.21.14)
| // `process` beside the pair: it is the third executable key (a | ||
| // long-running filter git speaks a protocol to), and enumerating two | ||
| // of three is how the first cut of this screen read as complete. | ||
| '^filter\\..*\\.(smudge|clean|process)$', |
There was a problem hiding this comment.
[Suggestion] The clean branch of this alternation is planted by no test anywhere — the scratch-tree tests pin smudge and (newly) process, and the only clean key in the suite is filter.lfs.clean in GLOBAL config, planted to prove the exemption. Deleting clean| is a surviving mutant: with the mutant applied, both test files run 174/174 green (measured). A future change narrowing the regex to the keys a checkout actually executes (smudge|process) would silently drop the refusal for a local filter.x.clean — the exact "enumerated N−1 of N keys and read as complete" failure this PR's own comment says it exists to prevent. (Exposure is narrower than smudge/process since checkouts do not execute clean filters — this is a missing guard over a defense-in-depth layer, not a shipping bug.)
Suggested fix: beside the process block this PR already adds, plant filter.evil.clean and assert run().available === false with the note naming filter.evil.clean.
中文说明
这个可选项的 clean 分支没有任何测试植入过——scratch-tree 测试钉住了 smudge 和（新增的）process，而整个测试套件中唯一的 clean 键是写在全局配置里、用于证明豁免的 filter.lfs.clean。删掉 clean| 是一个存活的突变体：应用该突变后，两个测试文件 174/174 全绿（已实测）。未来若有修改把正则收窄为 checkout 实际执行的键（smudge|process``），对本地 filter.x.clean` 的拒绝会被悄悄丢掉——而这正是本 PR 自己的注释声称要防止的"N 个键枚举了 N−1 个、读起来却像完整的"失败。（暴露面比 smudge/process 窄，因为 checkout 不执行 clean 过滤器——这是纵深防御层上缺失的一道守卫，而非会直接发布的 bug。）
修复建议：在本 PR 已添加的 process 测试块旁，植入 filter.evil.clean，断言 run().available === false 且 note 点名 filter.evil.clean。
— qwen3.8-max via Qwen Code /review (v0.21.14)
) Review feedback on the restore screen named four ways a planted content filter still executed: the probe tree's own `worktree add` preceded every screen, the revert phase's `git checkout base -- ...` was unscreened (the flow lands there after every restore refuses), the screen's `git config --file` read does not expand `include.path` while the checkout's merged config does, and a linked screening worktree never read the main worktree's `<common>/config.worktree`. Screen before the probe tree's creation and again at the revert checkout, follow includes, add the missing candidate, and give base-tree's `worktree add` the same screen. The screen and the checkout it authorises are also a check-then-use pair: nothing reaped the suite's detached descendants on normal completion, so a process the PR's test code spawned could toggle the filter config between the two. Run the suite in its own process group and kill the group before the next screen+checkout pair. Tests plant through each bypass with an executable attributes line and assert the planted command did not run; each fails on the pre-fix code.
|
🤖 Addressed the latest review feedback (round 1/100). What changed, and what I pushed back on: · 已处理最新评审反馈（第 1/100 轮）。改动内容与我反驳保留之处如下： All six findings are addressed in code — the four Criticals were each reproduced with a focused failing test on the pre-round code before fixing, and both Suggestions adopted. 1. Unscreened checkouts — the screen now covers the probe phase entry, the revert checkout, and base-tree (rc:3820695672). Before this round only the per-run restore was screened. A screen now runs before the probe tree's 2. The screen follows 3. Check-then-use race — the suite's process group is reaped (rc:3820695701). 4. 5. Test efficacy — the non-execution assertions now discriminate (rc:3820695728). All three filter-refusal tests plant the 6. The VerificationCommands actually run this round (git 2.39.5, Node v22.23.2):
中文说明全部六条评审意见均已在代码中处理——四个 Critical 在修复前都已先用聚焦的失败测试在修改前的代码上复现，两条 Suggestion 也已采纳。 1. 未筛查的 checkout —— 筛查现覆盖探针阶段入口、revert checkout 以及 base-tree（rc:3820695672）。 本轮之前只有每次运行前的 restore 被筛查。现在在探针树 2. 筛查跟随 3. check-then-use 竞态 —— 套件的进程组被收割（rc:3820695701）。 4. 5. 测试有效性 —— "未执行"断言现在具有区分力（rc:3820695728）。 三个 filter 拒绝测试都植入了 6. 验证本轮实际运行的命令（git 2.39.5，Node v22.23.2）：
Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 Re-review when you have a moment. After round 100 this bot stops and leaves the PR for a human. · 有空请复审；第 100 轮后本 bot 停止并将 PR 交给人工。 🧠 Handled by Qwen Code · model/模型 |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
[Critical] (relocated here: its root anchor, the screen's key regex at lib/worktree.ts:634, sits on the line occupied by the round-1 comment 3820695734, so it posts in the body instead of stacking on that thread) The shared screen every checkout-authorising guard now calls reads only filter.* keys, but the checkouts it authorises also EXECUTE a planted core.fsmonitor — a one-write command-execution surface (no attributes line needed) that none of the five screened checkout sites suppresses: the revert checkout (test-efficacy.ts:2920), the base-tree worktree add (base-tree.ts:284), the scratch tree's reset checkout --force --detach (scratch-tree.ts:272) and rebuild worktree add (scratch-tree.ts:476 — NO_HOOKS suppresses hooks only), and the probe tree's worktree add (test-efficacy.ts:2571). The codebase's own comment at worktree.ts:68 names core.fsmonitor and filter.* together as command execution, and the restore's spawns already pass -c core.fsmonitor= for exactly this reason. A mid-run git config core.fsmonitor CMD passes every screen (no filter.* key), executes on the revert checkout, and PERSISTS in the common config — nothing unsets it — firing at the base-tree add, the scratch reset/rebuild, and the probe add of the NEXT review, each immediately after its new screen reports clean, and on the user's own later index-refreshing git commands. Witness (probe, git 2.43, exact argv per site): SCREEN localFilterCommands(worktree) => [] then SITE1 base-tree add / SITE2 scratch reset / SITE3 scratch rebuild add / SITE4 probe add => exit 0 — FSMONITOR FIRED (marker created); revert shape git checkout <base> -- a.ts fired identically; FLIP arms with -c core.fsmonitor= => marker absent; PERSISTENCE: common config still carries the planted command afterwards. Suggested fix: extend the existing inert-args pattern — pass -c core.fsmonitor= (alongside -c core.hooksPath=/dev/null/no-hooks) on the revert checkout and on the base-tree/scratch-tree/probe-tree spawns, or extend localFilterCommands to refuse on ^core\.fsmonitor$ (local files only, matching its existing rationale). 中文说明：共享屏蔽如今被所有授权 checkout 的守卫调用，但它只读取 filter.* 键；而它所授权的 checkout 还会执行植入的 core.fsmonitor——一步写入即可实现的命令执行面（无需 attributes 行），且五个被屏蔽的 checkout 站点无一抑制它：revert checkout（test-efficacy.ts:2920）、base 树 worktree add（base-tree.ts:284）、scratch 树的重置 checkout --force --detach（scratch-tree.ts:272）与重建 worktree add（scratch-tree.ts:476——NO_HOOKS 只抑制钩子）、探针树 worktree add（test-efficacy.ts:2571）。worktree.ts:68 的代码注释本身就把 core.fsmonitor 与 filter.* 并列为命令执行，而恢复阶段的 spawn 早已正因如此传递 -c core.fsmonitor=。运行中写入 git config core.fsmonitor CMD 会通过所有屏蔽（没有 filter.* 键），在 revert checkout 上执行，并持久留在 common 配置中——没有任何地方 unset 它——在下一次审查的 base 树 add、scratch 重置/重建、探针 add 上触发，每次都紧随新屏蔽报告干净之后，也会在用户自己之后刷新索引的 git 命令上触发。修复：把既有的 inert 参数模式扩展——在 revert checkout 与 base/scratch/probe 树的 spawn 上同样传递 -c core.fsmonitor=（与 -c core.hooksPath=/dev/null/no-hooks 并列），或让 localFilterCommands 对 ^core\.fsmonitor$ 也拒绝（仅本地文件，与其既有理由一致）。
— qwen3.8-max via Qwen Code /review (v0.21.14)
| 'config', | ||
| '--file', | ||
| file, | ||
| '--includes', |
There was a problem hiding this comment.
[Critical] The screen's --file … --includes read evaluates includeIf conditions against the SCREENING worktree's gitdir/branch, while the checkouts it authorises evaluate them against the EXECUTING tree's context — a conditional include aimed at another tree or branch is invisible to the screen and still EXECUTES. This is the surviving half of round 1's include finding (R1-2): --includes closed unconditional include.path, but conditional includeIf stays open.
Two live-reproduced entrances (git 2.43): (a) [includeIf "gitdir:<common>/worktrees/<review-basename>-*"] targeting the probe/base/scratch sibling admin dirs — the entry/base/scratch screens report clean while the subsequent git worktree add initial checkout executes the planted smudge; labels are deterministic per lib/paths.ts, so the pattern is attacker-knowable. (b) [includeIf "onbranch:main"] targeting the user's own branch — every screen runs detached or on the PR ref, so the condition never matches the screen's read; nothing fires during the review, and the plant fires later on the user's own branched checkout in their main worktree — the exact persistence outcome the docstring says this screen exists to refuse.
Witness (probe):
includeIf.gitdir arm:
screen (review wt): [] (reports clean)
authorised `git worktree add`: marker CREATED
merged read from the probe tree: filter.evil.smudge visible
includeIf.onbranch arm:
screens (review/probe): [] / []
detached pipeline checkouts: no marker
user's own branched restore: marker CREATED
fix-direction flip (raw include-key read):
screen reports includeif.gitdir:…/worktrees/wt-*.path
and includeif.onbranch:main.path -> refusal
Suggested fix (fail closed, matching the screen's stated posture): don't rely on git's conditional evaluation — for each candidate also read the raw include.*.path / includeIf.*.path keys WITHOUT --includes and refuse on any directive (or screen the include targets recursively, cycle-guarded). Refusing on a benign conditional include is the same fail-safe trade the screen already makes elsewhere.
中文说明
屏蔽使用的 --file … --includes 读取会按屏蔽所在工作树的 gitdir/分支来求值 includeIf 条件，而它所授权的 checkout 是在执行树的上下文里求值这些条件——指向其他树或其他分支的条件 include 对屏蔽不可见，却仍会被执行。这是第 1 轮 include 发现（R1-2）未被覆盖的另一半：--includes 关闭了无条件的 include.path，但条件式 includeIf 仍然敞开。
两个实测复现的入口（git 2.43）：(a) 用 [includeIf "gitdir:<common>/worktrees/<review-basename>-*"] 指向 probe/base/scratch 兄弟管理目录——入口/base/scratch 屏蔽报告干净，而随后的 git worktree add 初始 checkout 执行了植入的 smudge；标签按 lib/paths.ts 是确定性的，攻击者可以预先知道该模式。(b) 用 [includeIf "onbranch:main"] 指向用户自己的分支——所有屏蔽都以 detached 或 PR ref 状态运行，条件永远不会命中屏蔽的读取；审查期间什么都不会触发，植入会在用户之后于自己主工作树的带分支 checkout 上触发——这正是文档注释声称该屏蔽所要拒绝的持久化结果。
修复建议（按屏蔽声明的保守姿态失败即关闭）：不要依赖 git 的条件求值——对每个候选文件额外不带 --includes 地读取原始 include.*.path / includeIf.*.path 键，只要存在任何指令即拒绝（或带环保护地递归屏蔽 include 目标）。对良性条件 include 的拒绝，与该屏蔽在其他地方已经采取的失败即安全权衡一致。
— qwen3.8-max via Qwen Code /review (v0.21.14)
| * Every checkout in this pipeline EXECUTES these — the scratch tree's reset | ||
| * and rebuild, the probe tree's creation, its per-run restores and the |
There was a problem hiding this comment.
[Critical] This docstring added by the diff enumerates "every checkout in this pipeline" as executing the screened filters, but the pipeline's FIRST checkout — git('worktree', 'add', wt, ref) in fetch-pr.ts:1080, which creates the review worktree — never calls localFilterCommands (grep finds no reference in fetch-pr.ts). The claim this diff adds is what makes the pre-existing unscreened site newly wrong.
Failure scenario: a malicious PR's suite plants filter.evil.smudge into <common>/config plus one info/attributes line during review N — the two-write surface this PR's own tests perform — and discard/cleanup never wipe the common dir (the docstring's own words). Review N+1 begins with fetch-pr's worktree add, whose initial checkout executes the planted smudge on every matching file with the user's privileges, BEFORE any screen this PR adds ever runs. The firing half was run live: a worktree add with the planted filter + attributes line created the marker.
Suggested fix: call localFilterCommands in fetch-pr before the review worktree's worktree add (it works from the main checkout as cwd) and refuse the fetch the way base-tree refuses — or narrow the "every checkout in this pipeline" claim to the checkouts actually screened.
中文说明
本 PR 新增的这段文档注释声称"流水线中的每一个 checkout"都会执行被屏蔽的过滤器，但流水线的第一个 checkout——fetch-pr.ts:1080 创建 review 工作树的 git('worktree', 'add', wt, ref)——从不调用 localFilterCommands（grep 确认 fetch-pr.ts 中无任何引用）。正是本 PR 新增的这一声明，使得这个先前就存在的未屏蔽站点成为新的错误。
失败场景：恶意 PR 的测试套件在审查 N 期间向 <common>/config 写入 filter.evil.smudge 并向 info/attributes 追加一行——即本 PR 自己的测试所演示的两步写入——而 discard/cleanup 从不清扫 common 目录（文档注释自己承认）。审查 N+1 以 fetch-pr 的 worktree add 开始，其初始 checkout 会在本 PR 新增的任何屏蔽运行之前，以用户权限对每个匹配文件执行植入的 smudge。触发半边已实测：带植入过滤器 + attributes 行的 worktree add 创建了标记文件。
修复建议：在 fetch-pr 创建 review 工作树的 worktree add 之前调用 localFilterCommands（从主检出目录作为 cwd 即可工作），并像 base-tree 一样拒绝 fetch——或者把"流水线中的每一个 checkout"这一声明收窄到实际被屏蔽的 checkout。
— qwen3.8-max via Qwen Code /review (v0.21.14)
| * revert phase's checkout, and the base tree's creation — hooks being | ||
| * disabled covers hooks and not filters. The planting surface is two plain |
There was a problem hiding this comment.
[Critical] The claim "hooks being disabled covers hooks" is false at the checkouts this diff's own screens guard: base-tree.ts's git() and test-efficacy.ts's git() do NOT prepend the -c core.hooksPath=/dev/null/no-hooks args that scratch-tree.ts's git() prepends, and lib/git.ts's git() (used by fetch-pr's add) does not either. A post-checkout hook planted as ONE executable file <common>/hooks/post-checkout — cheaper than the two-write filter plant this PR screens for — fires on the base-tree and probe-tree worktree add initial checkouts immediately after the new filter screens report clean, and on the revert phase's pathspec checkout (the probe logged post-checkout fired, contradicting the in-code comment "A pathspec checkout runs no hook"). The screen structurally cannot see a hook — it is a file under <common>/hooks/, not a config key — and the plant persists in the common dir for the user's own later checkouts.
Witness (probe, git 2.43):
RESULT-F1a: post-checkout hook FIRED on 'git worktree add'
(no -c core.hooksPath) — marker exists
RESULT-F1b: hook SUPPRESSED by -c core.hooksPath=/dev/null/no-hooks
pathspec arm: post-checkout fired (args: <sha> <sha> 0)
Suggested fix: prepend the same ['-c', 'core.hooksPath=/dev/null/no-hooks'] args scratch-tree.ts already uses to the git() helpers in base-tree.ts and test-efficacy.ts (and lib/git.ts, which covers fetch-pr's add), or correct the docstring claim if any add must stay unsuppressed.
中文说明
"禁用钩子即可覆盖钩子"这一说法，在本 PR 新增屏蔽所守护的 checkout 上并不成立：base-tree.ts 的 git() 与 test-efficacy.ts 的 git() 都没有像 scratch-tree.ts 的 git() 那样前置 -c core.hooksPath=/dev/null/no-hooks 参数，fetch-pr 的 add 所用的 lib/git.ts 的 git() 也没有。把一个可执行文件 <common>/hooks/post-checkout 植入 <common>/hooks/——比本 PR 所屏蔽的两步过滤器植入更廉价——就能在 base 树和探针树的 worktree add 初始 checkout 上触发钩子，而此刻新的过滤器屏蔽刚刚报告干净；revert 阶段的 pathspec checkout 同样会触发（探针记录了 post-checkout fired，与代码注释"pathspec checkout 不运行钩子"相矛盾）。屏蔽在结构上看不见钩子——钩子是 <common>/hooks/ 下的文件，不是配置键——且植入会留在 common 目录中，在用户之后自己的 checkout 上继续触发。
修复建议：把 scratch-tree.ts 已在使用的 ['-c', 'core.hooksPath=/dev/null/no-hooks'] 参数同样前置到 base-tree.ts 与 test-efficacy.ts 的 git() 辅助函数（以及覆盖 fetch-pr add 的 lib/git.ts），或者若某个 add 必须保持不禁用钩子，则修正文档注释中的说法。
— qwen3.8-max via Qwen Code /review (v0.21.14)
| join(common, 'config.worktree'), | ||
| join(resolve(worktree, gitDir), 'config.worktree'), |
There was a problem hiding this comment.
[Critical] The candidate list never reads submodule configs under the common dir (<common>/modules/*/config*, <common>/worktrees/*/modules/*/config*), yet every checkout the screen authorises EXECUTES filters defined there once submodule.recurse=true — a key the ^filter\. regex never matches — is also set. The reviewed repo has submodules (attacker-chosen: the attacker authors the PR), and scratch-tree.ts:297 documents probes initialising submodules "to build".
Failure scenario (four common-dir writes): git submodule update --init inside the probe tree (the submodule gitdir lands at <common>/worktrees/<probe-label>/modules/sub), the filter key into that submodule's config, one attributes line, and git config submodule.recurse true. The new restore screen reports clean — the plant sits in a file no candidate covers — and the restore checkout checkout --force HEAD -- . executes the planted command; the scratch reset verb fires identically (it runs before the hasSubmodules escape hatch at scratch-tree.ts:303-306). Only git worktree add does not recurse, so the restore/reset checkouts are the entrances; submodule.recurse=true persists in <common>/config, which no cleanup wipes.
Witness (probe, git 2.43, production sequence):
screen: review-wt: [] / probe-wt: []
(plant at <common>/worktrees/probe-wt/modules/sub/config)
restore verb (exact test-efficacy.ts:1618 argv): MARKER created
scratch reset verb (exact scratch-tree.ts:272 argv): MARKER created
controls: recurse unset -> no marker; re-enabled -> marker;
worktree add -> no marker (not an entrance)
Suggested fix: refuse on the presence of any gitlink (mode 160000 in ls-files -s — scratch-tree already detects this) at every filter-screened checkout; or extend the candidates to <common>/modules/*/config{,.worktree} and <common>/worktrees/*/modules/*/config{,.worktree}; or add -c submodule.recurse=false to the authorised checkouts (closes the pipeline shapes but leaves the coverage claim false for the user's own later checkouts).
中文说明
候选文件列表从不读取 common 目录下的子模块配置（<common>/modules/*/config*、<common>/worktrees/*/modules/*/config*），但一旦同时设置了 submodule.recurse=true——一个 ^filter\. 正则永远不会匹配的键——该屏蔽所授权的每一个 checkout 都会执行那里定义的过滤器。被审查的仓库含有子模块（由攻击者选择——攻击者就是 PR 的作者），且 scratch-tree.ts:297 记录了探针会"为了构建"而初始化子模块。
失败场景（四次 common 目录写入）：在探针树内执行 git submodule update --init（子模块 gitdir 落在 <common>/worktrees/<probe-label>/modules/sub），把过滤器键写入该子模块的配置，追加一行 attributes，再执行 git config submodule.recurse true。新的恢复屏蔽报告干净——植入位于任何候选都不覆盖的文件里——随后恢复 checkout checkout --force HEAD -- . 执行植入的命令；scratch 的重置 checkout 同样触发（它运行在 scratch-tree.ts:303-306 的 hasSubmodules 逃生门之前）。只有 git worktree add 不会递归，因此恢复/重置 checkout 是入口；submodule.recurse=true 持久留在 <common>/config 中，没有任何清理会抹掉它。
修复建议：在每一个被过滤器屏蔽守护的 checkout 上，对任何 gitlink（ls-files -s 中 mode 为 160000——scratch-tree 已有此检测）的存在采取拒绝；或把候选扩展到 <common>/modules/*/config{,.worktree} 与 <common>/worktrees/*/modules/*/config{,.worktree}；或在被授权的 checkout 上追加 -c submodule.recurse=false（关闭流水线内的形态，但对用户自己之后的 checkout，覆盖声明仍然是假的）。
— qwen3.8-max via Qwen Code /review (v0.21.14)
| // every healthy run. | ||
| const filters = localFilterCommands(probeTree); | ||
| if (filters.length > 0) { | ||
| return `the repository's local config defines content filter(s) ${filters.join(', ')}, which this tree's restore would EXECUTE`; |
There was a problem hiding this comment.
[Suggestion] This refusal interpolates the planter-controlled filter keys raw (filters.join(', ')), while the sibling sites this same PR adds/keeps — base-tree.ts:271 and scratch-tree.ts:392 — apply .map(inertPath) to the identical values. Git config subsection names legally carry control and bidi bytes (any byte except NUL and newline): a suite that plants filter.evil<ESC>[31m….smudge is correctly refused, but the refusal detail then carries the raw ESC into out.json, which review agents/orchestrator consume and quote into terminals and Markdown briefs — the exact sinks inertPath's docstring (lib/paths.ts) says it exists to protect. Measured live: git accepts such a key, --get-regexp emits the ESC byte raw, and inertPath flattens it. This is location 1 of 3 (the restore screen); the entry createDetail (~line 2566) and the revert throw (~line 2917) carry the same gap.
Add inertPath to the existing ./lib/paths.js import at line 64, then:
| return `the repository's local config defines content filter(s) ${filters.join(', ')}, which this tree's restore would EXECUTE`; | |
| return `the repository's local config defines content filter(s) ${filters.map(inertPath).join(', ')}, which this tree's restore would EXECUTE`; |
中文说明
该拒绝信息直接插值了植入者可控的过滤器键（filters.join(', ')），而本 PR 新增/保留的姊妹站点——base-tree.ts:271 与 scratch-tree.ts:392——对同样的值应用了 .map(inertPath)。git 配置的子节名合法地携带控制字符与 bidi 字符（除 NUL 与换行外的任意字节）：植入 filter.evil<ESC>[31m….smudge 的套件会被正确拒绝，但拒绝的 detail 会把原始 ESC 字节带进 out.json，而审查代理/编排器会消费它并引用到终端与 Markdown 简报中——正是 inertPath 文档注释（lib/paths.ts）声明其存在所要保护的汇聚点。实测：git 接受这样的键，--get-regexp 原样输出 ESC 字节，而 inertPath 会将其扁平化。这是三处中的第 1 处（恢复屏蔽）；入口 createDetail（约 2566 行）与 revert 的 throw（约 2917 行）有同样的缺口。在第 64 行已有的 ./lib/paths.js 导入中加入 inertPath 后即可按建议修改。
— qwen3.8-max via Qwen Code /review (v0.21.14)
| const filters = localFilterCommands(worktree); | ||
| if (filters.length > 0) { | ||
| return unavailable( |
There was a problem hiding this comment.
[Suggestion] The screen-then-refuse block with its planting-explanation message now exists in five hand-written copies — scratch-tree.ts:388-400, this block, and test-efficacy.ts:1606/2566/2917 — and they were born drifted inside this same PR: this copy silently drops the "(hooks are disabled, filters are config-driven)" clarification the scratch-tree original carries, and the three test-efficacy copies drop the inertPath sanitisation the other two apply. Any future correction to the planting explanation or remediation advice must be found and applied in five places across three files; miss one and the refusals for the same detected condition contradict each other.
Suggested fix: one helper beside localFilterCommands in lib/worktree.ts, e.g.
export function localFilterRefusal(
worktree: string,
context: string,
): string | null {
const filters = localFilterCommands(worktree);
if (filters.length === 0) return null;
return `the repository's local config defines content filter(s) ${filters.map(inertPath).join(', ')}, which ${context} would EXECUTE — …`;
}All five sites call it with their phase-specific context sentence; the refusal wording (and its remediation advice — see the separate finding on it) lives in one place.
中文说明
"先屏蔽后拒绝"的代码块及其植入说明信息如今存在五份手写副本——scratch-tree.ts:388-400、本块、以及 test-efficacy.ts:1606/2566/2917——而且它们在同一个 PR 里诞生时就已经漂移：本副本悄悄丢掉了 scratch-tree 原版所带的"（钩子已被禁用，过滤器由配置驱动）"澄清子句，而三份 test-efficacy 副本丢掉了另外两处都应用的 inertPath 净化。未来任何对植入说明或补救建议的修正，都必须在三个文件的五处逐一找到并应用；漏掉一处，同一检测条件下的拒绝信息就会互相矛盾。
修复建议：在 lib/worktree.ts 中 localFilterCommands 旁提供一个辅助函数（示意如上），五个站点各自带阶段上下文调用它；拒绝措辞（及其补救建议——另见针对该措辞的发现）集中在一处。
— qwen3.8-max via Qwen Code /review (v0.21.14)
| const pid = Number(readFileSync(pidFile, 'utf8')); | ||
| expect(() => process.kill(pid, 0)).toThrow(); |
There was a problem hiding this comment.
[Suggestion] This test pins the END STATE (descendant pid dead after the run returns), not the property the reap exists for — the group must be dead BEFORE the next screen+checkout pair. Executed mutation: moving killProcessGroup(r.pid, 'SIGKILL') from runProbeSuite's return path to the probe phase's final finally (after the revert screen+checkout) leaves this test green — the pid is still dead at assertion time — while reopening exactly the screen-to-checkout toggle window this PR closes; a future refactor that relocates the kill ships that regression with the test still passing.
Witness (probe):
moved-kill arm: ✓ reaps the suite's process group… Tests 1 passed | 32 skipped
pristine arm: same test 1 passed
Suggested fix (deterministic): have the fake vitest spawn a linger that sleeps ~50 ms then plants a filter + marker. With the kill where it is, the linger dies before planting (run scores inert, no marker); with the kill moved to the end, the linger plants during the restore/revert window and the run flips to inconclusive with a content filter detail — which the existing verdict: 'inert' assertion catches.
中文说明
该测试固化的是最终状态（运行返回后子孙进程已死），而不是 reap 存在的目的——进程组必须在下一次屏蔽+checkout 对之前死掉。已执行的突变实验：把 killProcessGroup(r.pid, 'SIGKILL') 从 runProbeSuite 的返回路径挪到探针阶段最后的 finally（在 revert 屏蔽+checkout 之后），本测试仍然通过——断言时 pid 确实已死——但恰好重新打开了本 PR 要关闭的"屏蔽到 checkout"切换窗口；未来某个把 kill 挪位置的 refactor 会带着这个回归一起上线，而测试依然绿灯。
修复建议（确定性）：让假 vitest 派生一个休眠约 50ms 后植入过滤器+标记的滞留进程。kill 在当前位置时，滞留进程在植入前被杀（运行记为 inert，无标记）；kill 被挪到末尾时，滞留进程在恢复/revert 窗口内完成植入，运行翻转为带 content filter detail 的 inconclusive——现有的 verdict: 'inert' 断言即可捕获。
— qwen3.8-max via Qwen Code /review (v0.21.14)
There was a problem hiding this comment.
Deferred to a later round. This is a test-strengthening Suggestion, not a Critical, and this round spends its budget on the five Critical fixes and their mutation-tested witnesses. The proposed change is sound — have the fake vitest spawn a linger that sleeps ~50 ms and then plants a filter + marker, so relocating the kill flips the run from inert to inconclusive and the existing verdict assertion catches the regression — and it is recorded so it is not silently dropped.
中文说明
缓至后续轮次。这是一条强化测试的 Suggestion 而非 Critical,本轮的预算用于五个 Critical 修复及其经突变验证的见证。所提改动是合理的——让假 vitest 派生一个休眠约 50ms 后再植入过滤器+标记的滞留进程,从而把 kill 挪位时运行会从 inert 翻转为 inconclusive,现有的 verdict 断言即可捕获该回归——已记录以免被遗漏。
| * contract, exactly like any git command they run — while a probe's planting | ||
| * surface is the repo-local files. `--includes` because the merged config a |
There was a problem hiding this comment.
[Suggestion] This comment states as fact that "a probe's planting surface is the repo-local files" — it isn't; that is the subset this screen polices. The suite spawn inherits the full environment (no env restriction in suiteSpawn), so a probe runs git config --global filter.evil.smudge CMD into the default ~/.gitconfig exactly as easily as the repo-local plant; sanitizedGitEnv strips only the GIT_CONFIG_GLOBAL/XDG redirects, not the default file, and no screen candidate covers global config. Every screen added by this diff reports clean and every checkout it authorises executes the plant — persisting across ALL repositories on the machine, one scope wider than the local plant the docstring describes. Global config is not on issue #9558's accepted-residual list — it was excluded by an ownership premise ("the user's own contract") the probe defeats; the git-lfs collision the issue documents is bounded (git lfs install writes exactly filter.lfs.clean|smudge|process).
Suggested fix: either extend the screen to global/system config with an allowlist of the three filter.lfs.* keys (refusing on anything else), or strip global/system scope from the pipeline's own checkout spawns (GIT_CONFIG_GLOBAL/GIT_CONFIG_SYSTEM pointed at /dev/null) accepting LFS pointer-file content in pipeline trees — and either way, correct the comment to name the residual scope as a disclosed limit rather than asserting the planting surface is repo-local.
中文说明
该注释把"探针的植入面是仓库本地文件"陈述为事实——其实不是；那只是本屏蔽所管辖的子集。套件进程继承完整环境（suiteSpawn 没有环境限制），因此探针把 git config --global filter.evil.smudge CMD 写进默认的 ~/.gitconfig 与写入仓库本地配置同样容易；sanitizedGitEnv 只剥离 GIT_CONFIG_GLOBAL/XDG 重定向，不剥离默认文件，而没有任何屏蔽候选覆盖全局配置。本 PR 新增的所有屏蔽都会报告干净，而它们授权的每一个 checkout 都会执行该植入——持久化到机器上所有仓库，比文档注释所描述的本地植入宽一个作用域。全局配置不在 issue #9558 的"已接受残留"清单里——它是被一个所有权前提（"用户自己的契约"）排除的，而探针恰恰能打破该前提；issue 记录的 git-lfs 冲突是有界的（git lfs install 恰好只写 filter.lfs.clean|smudge|process）。
修复建议：要么把屏蔽扩展到全局/系统配置并对三个 filter.lfs.* 键加白名单（其余一律拒绝），要么在流水线自己的 checkout 进程中剥离全局/系统作用域（GIT_CONFIG_GLOBAL/GIT_CONFIG_SYSTEM 指向 /dev/null），接受流水线树中 LFS 指针文件的内容——无论哪种，都把注释修正为把残留作用域命名为已披露的局限，而不是断言植入面只有仓库本地。
— qwen3.8-max via Qwen Code /review (v0.21.14)
There was a problem hiding this comment.
Partially addressed; the screening half is deferred. This round corrected the comment: it no longer asserts the planting surface is repo-local, and names the user's global config as a disclosed limit of the screen. Actually closing the gap still needs a design call between the two suggested directions — screening global/system config with a three-key filter.lfs.* allowlist, or stripping global/system scope from the pipeline's own checkout spawns — because refusing on a global filter.lfs.* would put every contributor with git-lfs into permanent refusal, while stripping global scope leaves LFS pointer-file content unsmudged in pipeline trees. Deferred so that choice is made deliberately.
中文说明
部分处理;屏蔽的一半予以缓办。本轮已更正注释:不再断言植入面只有仓库本地,并把用户的全局配置明确列为该屏蔽的一个已披露局限。真正关闭缺口仍需在两个建议方向之间做出设计决策——按三键 filter.lfs.* 白名单屏蔽全局/系统配置,或从流水线自身的 checkout spawn 剥离全局/系统作用域——因为对全局 filter.lfs.* 一律拒绝会让每个装了 git-lfs 的贡献者陷入永久拒绝,而剥离全局作用域又会让流水线树中的 LFS 指针文件内容得不到 smudge。缓办以便审慎做出该选择。
| if (r.pid > 0) { | ||
| killProcessGroup(r.pid, 'SIGKILL'); | ||
| } |
There was a problem hiding this comment.
[Suggestion] detached: true moves the probe suite out of the review's process group, so every pre-existing kill path that used to reach it now misses it, and this reap runs only when runProbeSuite returns NORMALLY. Before this diff the suite spawn had no detached, so the suite shared the wrapper's group and died with it: run.ts's --timeout-minutes handler (SIGTERM + 10s SIGKILL escalation via killProcessGroup) and its parent-signal forwarder (Ctrl+C / cancelled-CI SIGHUP/SIGINT/SIGTERM) both kill exactly that group. After the diff the suite is in its own group and the review process dying mid-spawnSync cannot run this reap (a blocked event loop runs no JS cleanup).
Witness (probe):
arm=detached: suite_pgid ≠ wrapper pgid
-> suite SURVIVED the wrapper group-kill (still running)
arm=nodetached: suite DIED with the wrapper group-kill
Outcome: on wrapper timeout or cancel mid-suite-run, the PR's own test code — documented by this very PR as able to plant persistent filters/hooks with plain writes — keeps running unbounded on the user's machine / self-hosted runner after the review is dead. Suggested fix: extend the reap to the abnormal path — record the suite's pgid (e.g. under the review tmp dir) before the spawn and remove it after the reap, and have run.ts's timeout/signal handlers also kill any recorded suite group; alternatively run the suite under a supervisor that self-terminates when its parent pid disappears.
中文说明
detached: true 把探针套件移出了审查的进程组，因此先前所有能触达它的 kill 路径现在都打不到它，而这个 reap 只在 runProbeSuite 正常返回时运行。本 PR 之前，套件进程没有 detached，与包装进程同组并随其一起死亡：run.ts 的 --timeout-minutes 处理器（SIGTERM + 10 秒后 SIGKILL 升级，经由 killProcessGroup）与父信号转发器（Ctrl+C / 被取消 CI 的 SIGHUP/SIGINT/SIGTERM）所 kill 的正是该组。本 PR 之后，套件在自己的组里，而审查进程死在 spawnSync 中间时无法运行这个 reap（被阻塞的事件循环不会执行任何 JS 清理）。
结果：包装超时或取消恰好落在套件运行期间时，本 PR 自己的测试代码——本 PR 的文档明确承认其能用普通写入植入持久过滤器/钩子——会在审查已死后继续在用户机器/自托管 runner 上不受限地运行。修复建议：把 reap 扩展到异常路径——spawn 前记录套件 pgid（例如写入审查临时目录），reap 后删除，并让 run.ts 的超时/信号处理器同时 kill 任何已记录的套件组；或者让套件在一个父 pid 消失即自终止的监管进程下运行。
— qwen3.8-max via Qwen Code /review (v0.21.14)
There was a problem hiding this comment.
Deferred to a later round. The concern is real — detached: true puts the suite in its own process group, and the reap only runs when runProbeSuite returns normally, so a wrapper timeout or cancel mid-suite leaves the PR's own test code running. The suggested fix (record the suite's pgid under the review tmp dir before the spawn, remove it after the reap, and have run.ts's timeout/signal handlers kill any recorded group) touches run.ts signal handling and the spawn path; it is a self-contained robustness change and is deferred so this round stays scoped to the five Critical fixes.
中文说明
缓至后续轮次。该担忧是真实的——detached: true 把套件放入它自己的进程组,而 reap 只在 runProbeSuite 正常返回时运行,因此包装进程在套件运行中超时或被取消时,PR 自身的测试代码会继续运行。所提修复(spawn 前把套件 pgid 记录到评审临时目录、reap 后移除,并让 run.ts 的超时/信号处理器 kill 任何已记录的组)会触及 run.ts 的信号处理与 spawn 路径;它是一个自包含的健壮性改动,为使本轮范围集中于五个 Critical 修复,予以缓办。
| 'both the filter and the attributes that select it. Remove the ' + | ||
| 'filter config — or the attributes file that uses it — if it is ' + | ||
| 'not yours; until then no base tree is safe to create.', |
There was a problem hiding this comment.
[Suggestion] This refusal offers removing the attributes file as an alternative remedy ("or the attributes file that uses it"), but the refusal condition reads only config keys — localFilterCommands(...).length > 0 never reads attributes — so removing only the attributes CANNOT clear the refusal. A user who follows the second option (which genuinely neutralises execution — a filter nothing selects never runs) re-runs into a byte-identical refusal with no hint why.
Witness (probe on runBaseTree):
first: available=false note=…Remove the filter config — or the attributes file…
after attrs removal: available=false note=…(byte-identical refusal)…
after config removal: available=true
The pre-existing scratch-tree copy carries the same text; this base-tree copy is added by this diff. Suggested fix: make config removal the sole stated unblocking remedy.
| 'both the filter and the attributes that select it. Remove the ' + | |
| 'filter config — or the attributes file that uses it — if it is ' + | |
| 'not yours; until then no base tree is safe to create.', | |
| 'both the filter and the attributes that select it. Remove the ' + | |
| 'filter config if it is not yours — removing only the attributes ' + | |
| 'that select it makes checkouts safe, but this screen refuses on ' + | |
| 'the filter definition itself; until then no base tree is safe to ' + | |
| 'create.', |
(A shared refusal helper — see the separate finding at line 267 — would state this once for all five sites.)
中文说明
该拒绝把删除 attributes 文件作为替代补救方案（"或者删掉使用它的 attributes 文件"），但拒绝条件只读取配置键——localFilterCommands(...).length > 0 从不读取 attributes——因此只删除 attributes 无法解除拒绝。照第二个选项操作的用户（该选项确实能消除执行——没有 attributes 选中的过滤器永远不会运行）再次运行时会得到逐字节相同的拒绝，却得不到任何解释。
先前已存在的 scratch-tree 副本带有相同措辞；这个 base-tree 副本由本 PR 新增。修复建议：把删除配置作为唯一声明的解除手段（建议块已给出改写）；若采用第 267 行评论建议的共享拒绝辅助函数，则五处一次性统一措辞。
— qwen3.8-max via Qwen Code /review (v0.21.14)
…9558) Refuse include/includeIf directives as keys instead of following --includes (the condition evaluates against the wrong tree), extend the screen to submodule configs under the common dir, screen fetch-pr's worktree add, and prepend a shared INERT_GIT_ARGS (core.hooksPath, core.fsmonitor) to every checkout-running git spawn. Consolidate the five drifted refusal copies into localFilterRefusal, which flattens keys via inertPath and names config removal as the only unblocking remedy. Each guard is witnessed by a mutation-tested test; all five Critical claims were reproduced live (git 2.39) before fixing.
|
🤖 Addressed the latest review feedback (round 2/100). What changed, and what I pushed back on: · 已处理最新评审反馈（第 2/100 轮）。改动内容与我反驳保留之处如下： Autofix round 2 — address review feedback on PR #9566Disposition of each findingAll five Critical findings were reproduced with live probes on this runner Critical — fixed
Suggestion — resolved
Suggestion — deferred to a later round (see
|
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Partially reviewed — gaps disclosed.
Not reviewed: build-and-test — Test (windows-latest, Node 22.x) and Test (macos-latest, Node 22.x) were skipped in CI and their platform-specific suites did not run locally (the Windows reap semantics R3-11 targets are unverified on that platform).
中文说明
仅完成部分审查，审查缺口已披露。
未审查：build-and-test — Test (windows-latest, Node 22.x) and Test (macos-latest, Node 22.x) were skipped in CI and their platform-specific suites did not run locally (the Windows reap semantics R3-11 targets are unverified on that platform)。
— qwen3.8-max via Qwen Code /review (v0.21.14)
| const filterRefusal = localFilterRefusal( | ||
| process.cwd(), | ||
| 'the review worktree add this command runs', | ||
| ); | ||
| if (filterRefusal !== null) throw new Error(filterRefusal); |
There was a problem hiding this comment.
[Critical] R3-1: The new pre-fetch screen refuses on ANY include.path/includeif.*.path directive key in repo-local config, but standard GitHub Actions checkouts — including this PR's own CI — carry benign includeif.gitdir: credential directives in .git/config whose included files hold only an http.extraheader authorization header, no filters. Every handler-level test in fetch-pr.test.ts executes with cwd inside such a real repo, so all 79 of them throw this refusal and fail, and any real qwen review fetch-pr/base-tree run against a checkout with these runner-managed entries is refused until someone hand-removes them — the exact false-positive failure class the PR description cites as the reason the screen stays repo-local (#9221 round 15: the tripwire that fired on every healthy run).
Witness:
local packages/cli suite on this PR: fetch-pr.test.ts 79 failed | 95 passed
(measured netNew against the merge base via base-tree + test-delta)
PR CI job 96513411902: Failed Tests 79 — Test Files 1 failed | 859 passed (860)
Direction: make the fetch-pr suite hermetic against ambient repo config the way this PR's own new test does (chdir into a fixture repo), and reconsider refusing include directives unconditionally — e.g. resolve the included files and refuse only when they transitively define filter.*.smudge|clean|process keys, so benign credential includes don't trip the screen.
中文说明
新的 fetch 前置屏蔽会拒绝仓库本地配置中任何 include.path/includeif.*.path 指令键，但标准 GitHub Actions 检出（包括本 PR 自己的 CI）的 .git/config 里都带有良性的 includeif.gitdir: 凭据指令，其目标文件只有 http.extraheader 授权头，没有任何过滤器。fetch-pr.test.ts 的所有 handler 级测试都以真实仓库为 cwd 运行，因此全部 79 个抛出该拒绝而失败；任何针对此类检出的真实 qwen review fetch-pr/base-tree 运行也会被拒绝，除非有人手工删除这些由 runner 管理的条目——这正是 PR 描述中引为"屏蔽只看仓库本地配置"理由的误报失败类别（#9221 第 15 轮：每次健康运行都触发的绊线）。
证据：本地 packages/cli 套件中 fetch-pr.test.ts 79 失败 | 95 通过（经 base-tree + test-delta 对照合并基线测得 netNew）；PR CI 作业 96513411902：Failed Tests 79 — Test Files 1 failed | 859 passed (860)。
修复方向：让 fetch-pr 测试套件对本机仓库配置保持密封（像本 PR 自己的新测试那样 chdir 进夹具仓库）；并重新考虑无条件拒绝 include 指令的做法——例如解析被 include 的文件，仅当其（传递地）定义了 filter.*.smudge|clean|process 键时才拒绝，使良性凭据 include 不会触发屏蔽。
— qwen3.8-max via Qwen Code /review (v0.21.14)
| const submoduleConfigs = (modulesDir: string): void => { | ||
| try { | ||
| for (const mod of readdirSync(modulesDir)) { | ||
| candidates.push(join(modulesDir, mod, 'config')); | ||
| candidates.push(join(modulesDir, mod, 'config.worktree')); | ||
| } |
There was a problem hiding this comment.
[Critical] R3-2: submoduleConfigs enumerates exactly one level, so filters defined in a NESTED (depth ≥ 2) submodule's config under the common dir are invisible to every screen while the checkouts it authorises execute them once submodule.recurse=true (a key the filter regex deliberately leaves legal) is also set. This is the depth-2 twin of the round-2 submodule fix this diff ships for depth 1.
Failure scenario, live-reproduced on the production verb: an attacker-authored PR ships super-repo → submodule A → submodule B; the probe suite runs submodule update --init --recursive in the probe tree (the nested gitdir lands at <common>/worktrees/<label>/modules/sub-a/modules/sub-b/), then writes submodule.recurse=true into <common>/config, filter.evil.smudge into the nested config, and one attributes line. Every screen reports clean, and the restore checkout executes the planted smudge. The plant persists in the common dir, which no cleanup wipes.
Witness (verifier probe, git 2.47.3):
SCREEN (unmodified PR code): []
RESTORE VERB (checkout --force HEAD -- .): marker exists: YES
CONTROL (submodule.recurse unset): marker: no
with the recursive fix below: screen reports ["filter.evil.smudge"]
| const submoduleConfigs = (modulesDir: string): void => { | |
| try { | |
| for (const mod of readdirSync(modulesDir)) { | |
| candidates.push(join(modulesDir, mod, 'config')); | |
| candidates.push(join(modulesDir, mod, 'config.worktree')); | |
| } | |
| const submoduleConfigs = (modulesDir: string): void => { | |
| try { | |
| for (const mod of readdirSync(modulesDir)) { | |
| candidates.push(join(modulesDir, mod, 'config')); | |
| candidates.push(join(modulesDir, mod, 'config.worktree')); | |
| submoduleConfigs(join(modulesDir, mod, 'modules')); | |
| } |
中文说明
submoduleConfigs 只枚举一层，因此 common 目录下嵌套（深度 ≥ 2）子模块配置中定义的过滤器对所有屏蔽不可见，而一旦同时设置了 submodule.recurse=true（一个 filter 正则刻意保持合法的键），该屏蔽所授权的 checkout 就会执行它们。这是本 diff 为深度 1 修复的第 2 轮子模块发现的深度 2 孪生体。
失败场景（按生产动词实测复现）：攻击者作者的 PR 携带 超仓库 → 子模块 A → 子模块 B；探针套件在探针树中执行 submodule update --init --recursive（嵌套 gitdir 落在 <common>/worktrees/<label>/modules/sub-a/modules/sub-b/），再向 <common>/config 写入 submodule.recurse=true、向嵌套配置写入 filter.evil.smudge、追加一行 attributes。所有屏蔽报告干净，恢复 checkout 执行植入的 smudge；植入持久留在 common 目录，没有任何清理会抹掉它。
证据（验证探针，git 2.47.3）：屏蔽（未改动 PR 代码）→ []；恢复动词（checkout --force HEAD -- .）→ 标记文件已创建；对照（未设 submodule.recurse）→ 无标记；应用下方的递归修复后 → 屏蔽报告 ["filter.evil.smudge"]。
— qwen3.8-max via Qwen Code /review (v0.21.14)
| '^filter\\..*\\.(smudge|clean|process)$', | ||
| // The directives themselves, NOT `--includes`: the filter read no |
There was a problem hiding this comment.
[Critical] R3-3: Class-level finding — the pattern list hand-enumerates git's command-executing config keys, and that entrance space is open-ended. Two more entrances were live-reproduced this round, each passing every screen, persisting through a completed review, and executing on the user's OWN later git commands — the exact persistence outcome the screen's docstring says it exists to refuse:
git config submodule.<name>.update '!CMD'in the common config — matches no pattern, INERT_GIT_ARGS does not cover it; the review completes clean and the user's nextgit submodule updateruns CMD.git config diff.external 'CMD'planted the same way — the pipeline's own diff spawns pin--no-ext-diff, so only the user's own plaingit diffexecutes it.core.fsmonitor/hook-file plants are neutralised at pipeline spawns by INERT_GIT_ARGS but never DETECTED — the INERT_GIT_ARGS docstring added by this diff claims "the plant persists, and the screen stays the half that detects and refuses it", which is false for those shapes.
Rounds 1–3 each found new entrances of this class (filters → includes → fsmonitor/hooks → submodule.update/diff.external), which is the recurrence signal that closing entrances one by one does not converge. The pipeline itself never executes these keys (verified: no pipeline spawn runs submodule update; diff spawns are pinned) — the harm is the persisted plant firing in the user's own repo, indefinitely.
Witness (verifier probe, unmodified PR code):
submodule.sm.update='!touch MARKER': screen [] → user `git submodule update sm`: marker CREATED
diff.external='touch MARKER': screen [] → user plain `git diff`: marker CREATED
(with --no-ext-diff: not created)
core.fsmonitor plant: screen []
core.hooksPath plant: screen []
Suggested fix — structural, not entrance-by-entrance: correct the docstring scope claim, and either maintain the pattern list as an explicitly curated, DISCLOSED sample of command-executing keys, or widen refusal to a curated set (submodule.*.update with ! values, diff.external, core.fsmonitor, core.hooksPath, …) acknowledging the list can never be complete.
中文说明
类级发现——模式列表是手工枚举的 git 可执行配置键，而该入口空间是无界的。本轮又实测复现两个入口，均通过所有屏蔽、在完成审查后持久留存，并在用户自己之后的 git 命令上执行——正是屏蔽文档注释声称其存在所要拒绝的持久化结果：
- 向 common 配置写入
git config submodule.<name>.update '!CMD'——不匹配任何模式，INERT_GIT_ARGS 也不覆盖；审查干净结束，用户下一次git submodule update即执行 CMD。 - 以同样方式植入
git config diff.external 'CMD'——流水线自身的 diff spawn 都钉死了--no-ext-diff，因此只有用户自己的普通git diff会执行它。 core.fsmonitor/钩子文件植入虽被 INERT_GIT_ARGS 在流水线 spawn 上中和，却从不被检测——本 diff 新增的 INERT_GIT_ARGS 文档注释声称"植入会留存，而屏蔽仍是检测并拒绝它的那一半"，对这些形态是假的。
第 1–3 轮各自发现了该类的新入口（filters → includes → fsmonitor/hooks → submodule.update/diff.external），这一反复出现的信号说明逐个封堵入口不会收敛。流水线自身从不执行这些键（已验证：无任何流水线 spawn 运行 submodule update；diff spawn 均已钉死）——危害是持久植入在用户自己的仓库中无限期触发。
证据（验证探针，未改动 PR 代码）：submodule.sm.update='!touch MARKER'：屏蔽 [] → 用户 git submodule update sm：标记已创建；diff.external='touch MARKER'：屏蔽 [] → 用户普通 git diff：标记已创建（带 --no-ext-diff 则不创建）；core.fsmonitor 植入：屏蔽 []；core.hooksPath 植入：屏蔽 []。
修复建议——结构性而非逐入口：修正文档注释的作用域声明；要么把模式列表明确维护为一份已披露的命令执行键精选样本，要么把拒绝面扩大到精选集合（带 ! 值的 submodule.*.update、diff.external、core.fsmonitor、core.hooksPath 等），并承认该清单永远不可能完整。
— qwen3.8-max via Qwen Code /review (v0.21.14)
| const r = spawnSync( | ||
| 'git', | ||
| ['config', '--file', file, '--get-regexp', pattern], | ||
| { cwd: worktree, encoding: 'utf8', env: sanitizedGitEnv() }, | ||
| ); | ||
| if (r.error || r.status !== 0 || typeof r.stdout !== 'string') continue; |
There was a problem hiding this comment.
[Critical] R3-4: These --get-regexp spawns run on spawnSync's DEFAULT 1 MiB maxBuffer. A plant whose matching output exceeds it gets the child killed (ENOBUFS), and the continue below reads that kill as "this file contains nothing" — so an armed filter screens clean and then executes on the very checkout the screen guards. The extracted screen is the one spawn that lost this codebase's own ENOBUFS lesson: six sibling spawns in this file and scratch-tree's gitOut all set maxBuffer: 64 * 1024 * 1024 with a comment describing exactly this child-kill.
Failure scenario, live-reproduced end-to-end (no concurrency needed): one attributes line *.ts filter=evil plus one write of <common>/config holding one armed filter.evil.smudge = touch MARKER beside ~50,000 junk [filter "jN"] smudge = junk sections (all matching the regex). The spawn overflows, Node kills git, the screen returns clean, and git worktree add (INERT_GIT_ARGS by design does not cover filters) executes the armed smudge. The overflow threshold was binary-searched to exactly the 1,048,576-byte default.
Witness (verifier probe, unmodified PR code):
raw spawn: {"errorCode":"ENOBUFS","status":null,"signal":"SIGTERM"}
localFilterCommands: [] (length 0)
localFilterRefusal: NULL — screen passed
guarded worktree add: marker created: YES
threshold: last clean 1,041,090 bytes; first ENOBUFS at the 1 MiB boundary
fix flip (maxBuffer 64 MiB): 50,001 keys incl. filter.evil.smudge;
pipeline REFUSED — checkout never ran, marker: false
Fix both halves: pass an explicit maxBuffer (the same 64 MiB), AND fail closed on spawn failure — keep status 1 (no match) as clean, but treat r.error / killed child / other statuses as "this file could not be cleared" and force a refusal (e.g. return a sentinel localFilterCommands callers must refuse on), since any fixed buffer is re-overflowable.
中文说明
这些 --get-regexp spawn 使用 spawnSync 的默认 1 MiB maxBuffer。若植入产生的匹配输出超过它，子进程会被杀死（ENOBUFS），而下方的 continue 把这次杀死读作"此文件没有任何匹配"——于是已武装的过滤器被屏蔽判为干净，随后在屏蔽所守护的那个 checkout 上执行。抽取后的屏蔽正是丢失了本代码库自己 ENOBUFS 教训的那个 spawn：同文件另外六个 spawn 与 scratch-tree 的 gitOut 都设置了 maxBuffer: 64 * 1024 * 1024，其注释描述的正是这种子进程被杀。
失败场景（端到端实测复现，无需并发）：一行 attributes *.ts filter=evil，加上向 <common>/config 一次写入——一个已武装的 filter.evil.smudge = touch MARKER 与约 50,000 个垃圾 [filter "jN"] smudge = junk 节（全部匹配该正则）。spawn 溢出、Node 杀死 git、屏蔽返回干净，git worktree add（INERT_GIT_ARGS 按设计不覆盖过滤器）执行了已武装的 smudge。溢出阈值经二分查找精确落在 1,048,576 字节默认值上。
证据（验证探针，未改动 PR 代码）：原始 spawn → {"errorCode":"ENOBUFS",...}；localFilterCommands → []；localFilterRefusal → NULL（屏蔽放行）；受守护的 worktree add → 标记已创建；阈值：1,041,090 字节仍干净，1 MiB 边界处首次 ENOBUFS；修复翻转（maxBuffer 64 MiB）→ 50,001 个键（含 filter.evil.smudge），流水线拒绝——checkout 未运行，标记为 false。
修复要补两半：显式传 maxBuffer（同样的 64 MiB），并且在 spawn 失败时失败即关闭——status 1（无匹配）仍视为干净，但 r.error/被杀子进程/其他状态码视为"此文件无法被清空"并强制拒绝（例如返回一个调用方必须拒绝的哨兵值），因为任何固定缓冲区都可以被再次溢出。
— qwen3.8-max via Qwen Code /review (v0.21.14)
| if (r.pid > 0) { | ||
| killProcessGroup(r.pid, 'SIGKILL'); | ||
| } |
There was a problem hiding this comment.
[Critical] R3-5: A descendant of the PR's own test code that calls setsid escapes this reap on the NORMAL path, all platforms — killProcessGroup(r.pid) kills one process group, and a setsid'd descendant is in its own session/pgid. A surviving toggler then races every subsequent restore screen→checkout pair (1600→1608) and the revert pair (2908→2910): the screen reads during the toggler's unset half-cycle and passes, the toggler plants before the checkout's config read, and the checkout executes the smudge. The comment above this code claims "the screens stay the detection half for whatever did [setsid away]" — that claim is false for a TOGGLING escapee: a point-in-time screen cannot detect a plant that is absent at the screen's read and present at the checkout's read.
Witness (verifier probe):
reap split: AFTER-REAP normal descendant alive: false | setsid escaper alive: true
race: 400 real screen→checkout pairs vs a setsid'd fast toggler:
fired=61 (15.3%), refused=298, clean=41
control (no toggler): fired=0, refused=0, clean=100
61 executions in 400 pairs is worse than the ~3% the comment block itself cites, and a review runs dozens of pairs — no concurrency or second review needed; the pipeline always runs the PR's code before these pairs. Minimal repair: strike/correct the false claim and detect-and-disclose (re-run localFilterRefusal immediately after each screened checkout and report the run as breached rather than clean). Full closure (a kill scope that survives setsid — Linux cgroup/systemd-run --scope + cgroup kill, or pidfd) is a design call for the maintainer.
中文说明
PR 自己的测试代码中任何调用 setsid 的子孙进程，都能在正常路径上逃脱这次回收（所有平台）——killProcessGroup(r.pid) 只杀一个进程组，而 setsid 的子孙位于自己的会话/进程组。存活的切换器会与之后每一次"恢复屏蔽→checkout"对（1600→1608）及 revert 对（2908→2910）竞速：屏蔽在切换器的 unset 半周期读取并通过，切换器在 checkout 读配置之前植入，checkout 执行 smudge。本代码上方的注释声称"屏蔽仍是那些 setsid 逃脱者的检测一半"——对切换型逃脱者该说法是假的：时间点式的屏蔽无法检测"屏蔽读取时不存在、checkout 读取时存在"的植入。
证据（验证探针）：回收切分——回收后普通子孙存活：false | setsid 逃脱者存活：true；竞速——400 次真实"屏蔽→checkout"对对阵 setsid 快速切换器：触发=61（15.3%），拒绝=298，干净=41；对照（无切换器）：触发=0，拒绝=0，干净=100。
400 对中 61 次执行比注释块自己引用的 ~3% 更糟，且一次审查要跑几十对——无需并发、无需第二个审查；流水线在这些对之前总会运行 PR 的代码。最小修复：删改这句不实声明，并改为"检测即披露"（在每个被屏蔽的 checkout 之后立即重跑 localFilterRefusal，若读到植入则把该次运行报告为被穿透而非干净）。彻底关闭（能跨越 setsid 的杀域——Linux cgroup/systemd-run --scope + cgroup kill，或 pidfd）属维护者的设计决策。
— qwen3.8-max via Qwen Code /review (v0.21.14)
| try { | ||
| for (const mod of readdirSync(modulesDir)) { | ||
| candidates.push(join(modulesDir, mod, 'config')); | ||
| candidates.push(join(modulesDir, mod, 'config.worktree')); |
There was a problem hiding this comment.
[Suggestion] R3-7: This submodule config.worktree candidate push has no paired test. Executed mutation: deleting this one line leaves 120/120 tests green across worktree.test.ts + scratch-tree.test.ts + base-tree.test.ts, and the evasion it ships was measured live — a probe sets extensions.worktreeConfig=true in a submodule's config and writes filter.evil.smudge into that submodule's config.worktree under the common dir, plus submodule.recurse=true; the checkout honours the per-worktree config and executes the plant while the screen reports clean. The sibling worktree-level config.worktree candidates ARE pinned by tests; only the submodule twin is not.
Witness (verifier probe):
suite under the deletion: Test Files 3 passed (3), Tests 120 passed (120)
baseline screen (line present): ["filter.evil.smudge"]
mutated screen: [] — mutated restore verb: marker exists: YES
Fix: extend the "reads submodule configs under the common dir" test in worktree.test.ts with one more plant — enable extensions.worktreeConfig in the submodule and plant into its config.worktree, expecting ['filter.evil.smudge'] — mirroring the existing linkedSub block.
中文说明
这条子模块 config.worktree 候选推送没有配套测试。执行突变：仅删除这一行，worktree.test.ts + scratch-tree.test.ts + base-tree.test.ts 合计 120/120 测试仍全绿；而它所放行的逃逸已实测——探针在子模块配置中设置 extensions.worktreeConfig=true，把 filter.evil.smudge 写入 common 目录下该子模块的 config.worktree，再设 submodule.recurse=true；checkout 会尊重该 per-worktree 配置并执行植入，而屏蔽报告干净。工作树级的兄弟 config.worktree 候选有测试钉住；只有子模块这对孪生没有。
证据（验证探针）：删除后套件 Test Files 3 passed (3)，Tests 120 passed (120)；基线屏蔽（该行在）→ ["filter.evil.smudge"]；突变后屏蔽 → []，突变后恢复动词 → 标记已创建。
修复：在 worktree.test.ts 的"读取 common 目录下子模块配置"测试中再增加一个植入——在子模块中启用 extensions.worktreeConfig 并向其 config.worktree 植入，期望 ['filter.evil.smudge']——与现有 linkedSub 块对称。
— qwen3.8-max via Qwen Code /review (v0.21.14)
| 'both a filter and the attributes that select it, and the state cannot be ' + | ||
| 'told apart from one you set deliberately, so remove those config entries ' + |
There was a problem hiding this comment.
[Suggestion] R3-8: The refusal names only the offending KEYS, never the files holding them — but this same PR widened the screen to detect keys in files that the remediation it implies, git config --unset <key>, cannot reach: <common>/modules/<sub>/config{,.worktree} and the sibling worktrees' admin config.worktree files (a scope-less --unset reads only <common>/config, or with extensions.worktreeConfig the screening tree's own config.worktree). Measured end-to-end: a plant in <common>/modules/sub/config is detected, the refusal names no path, git config --unset filter.evil.smudge exits 5 with the plant intact, and the refusal reappears verbatim on every retry — the repository stays wedged out of every review until someone hand-greps the module/admin dirs.
Witness (verifier probe):
plant in <common>/modules/sub/config: keys detected ["filter.evil.smudge"]
refusal names a file path: false
`git config --unset filter.evil.smudge`: exit 5; plant file intact; refusal repeats
same for a sibling admin config.worktree plant (unset exit 5)
control (plant in <common>/config): unset exit 0, screen clears
Fix: have localFilterCommands return keys paired with the file each was found in, and render the file plus the exact removal command in the refusal — e.g. filter.evil.smudge (defined in <inertPath(file)> — remove with: git config --file <path> --unset filter.evil.smudge).
中文说明
拒绝信息只点名出问题的键，从不点名承载它们的文件——但正是本 PR 把屏蔽扩大到能检测这些文件中的键，而它所暗示的补救 git config --unset <key> 却够不到：<common>/modules/<sub>/config{,.worktree} 与兄弟工作树管理目录的 config.worktree（不带作用域的 --unset 只读 <common>/config，开了 extensions.worktreeConfig 时则读屏蔽树自己的 config.worktree）。端到端实测：植入位于 <common>/modules/sub/config 时被检测到，拒绝信息不含任何路径，git config --unset filter.evil.smudge 以退出码 5 结束而植入完好，拒绝在每次重试时逐字重现——仓库被卡在每次审查之外，直到有人手工 grep module/admin 目录。
证据（验证探针）：植入 <common>/modules/sub/config → 检出键 ["filter.evil.smudge"]；拒绝信息是否包含文件路径：false；git config --unset filter.evil.smudge 退出码 5，植入文件完好，拒绝逐字重复；兄弟管理目录 config.worktree 植入同样（unset 退出码 5）；对照（植入 <common>/config）→ unset 退出码 0，屏蔽解除。
修复：让 localFilterCommands 返回键与所在文件的配对，并在拒绝信息中渲染文件及精确的删除命令——例如 filter.evil.smudge (defined in <inertPath(file)> — remove with: git config --file <path> --unset filter.evil.smudge)。
— qwen3.8-max via Qwen Code /review (v0.21.14)
| const r = spawnSync( | ||
| 'git', | ||
| ['config', '--file', file, '--get-regexp', pattern], | ||
| { cwd: worktree, encoding: 'utf8', env: sanitizedGitEnv() }, |
There was a problem hiding this comment.
[Suggestion] R3-9: These candidate-reading spawns have no timeout, and this PR widened the candidate set (<common>/config.worktree, submodule configs under <common>/modules/ and every <common>/worktrees/<label>/modules/, plus the new pre-fetch screen). A FIFO planted at any candidate path — one mkfifo syscall by a probe; existsSync is true for FIFOs and the screen reads every candidate unconditionally — wedges every later review of that repo indefinitely, now already at fetch-pr's pre-fetch screen before any worktree exists. Diagnosis is masked: git itself reads config.worktree only when the extension is on, so the repository looks healthy while qwen review hangs.
Witness (verifier probe):
FIFO at <common>/config.worktree:
real built localFilterCommands under `timeout 15`: exit 124 — never returned
fix flip (timeout: 5000 on the spawn): RETURNED after 10023 ms: []
Fix: give these spawns the deadline discipline lib/git.ts already applies (a timeout option on the spawnSync), and treat a timed-out/unreadable candidate as refusal-worthy rather than waiting indefinitely.
中文说明
这些读取候选文件的 spawn 没有超时，而本 PR 扩大了候选集合（<common>/config.worktree、<common>/modules/ 与每个 <common>/worktrees/<label>/modules/ 下的子模块配置，外加新的 fetch 前置屏蔽）。在任何候选路径上植入一个 FIFO——探针对 mkfifo 的一次系统调用；existsSync 对 FIFO 为 true，且屏蔽无条件读取每个候选——就会把该仓库之后每一次审查无限期卡住，而且现在在 fetch-pr 的前置屏蔽处就会卡住（此时任何工作树都还不存在）。诊断被掩盖：git 自己只在扩展开启时才读 config.worktree，所以仓库看起来健康，而 qwen review 挂死。
证据（验证探针）：在 <common>/config.worktree 放置 FIFO：真实构建的 localFilterCommands 在 timeout 15 下退出码 124——从未返回；修复翻转（spawn 加 timeout: 5000）→ 10023 ms 后返回 []。
修复：给这些 spawn 加上 lib/git.ts 已在使用的期限纪律（spawnSync 的 timeout 选项），并把超时/不可读的候选视为应当拒绝，而不是无限期等待。
— qwen3.8-max via Qwen Code /review (v0.21.14)
| const pid = Number(readFileSync(pidFile, 'utf8')); | ||
| expect(() => process.kill(pid, 0)).toThrow(); |
There was a problem hiding this comment.
[Suggestion] R2-9: Still stands (deferred in round 2, re-posted under the original id): this test pins the END STATE — the descendant pid is dead after the run returns — not the property the reap exists for: the group must be dead BEFORE the next screen+checkout pair. A mutation moving killProcessGroup(r.pid, …) to after the last screen+checkout pair (or making it async) would leave this assertion green while the protective property is lost. Strengthening proposed last round: have the fake vitest spawn observe group-dead relative to the NEXT screen+checkout pair (record the kill's sequence/timestamp vs the next restore) and assert the order, not just the end state.
中文说明
仍然成立（第 2 轮已缓办，按原 id 重新张贴）：该测试固化的是最终状态——运行返回后子孙 pid 已死——而非回收机制所要保证的性质：进程组必须在下一次"屏蔽+checkout"对之前死掉。把 killProcessGroup(r.pid, …) 移到最后一个"屏蔽+checkout"对之后（或改为异步）的突变，仍能让该断言保持绿色，而保护性质已丢失。上一轮提出的强化：让假 vitest spawn 相对下一次"屏蔽+checkout"对观察进程组已死（记录 kill 的时序/时间戳与下一次恢复的先后），断言顺序而非仅断言最终状态。
— qwen3.8-max via Qwen Code /review (v0.21.14)
| maxBuffer: 64 * 1024 * 1024, | ||
| detached: true, |
There was a problem hiding this comment.
[Suggestion] R2-11: Still stands (deferred in round 2, re-posted under the original id): detached: true moves the probe suite out of the review's process group, and the reap below runs only when runProbeSuite returns NORMALLY. A wrapper timeout/cancel mid-suite (run.ts signal path) kills the review's own group but not the detached suite's group — the PR's own test processes survive the review's death and can still write the shared common-dir config. Extending the reap to the abnormal path touches run.ts signal handling; proposed last round as a self-contained robustness change (record the suite pid somewhere the wrapper's teardown can reach, or extend the signal handler to kill the suite group too).
中文说明
仍然成立（第 2 轮已缓办，按原 id 重新张贴）：detached: true 把探针套件移出审查的进程组，而下方的回收只在 runProbeSuite 正常返回时运行。套件运行中途的包装层超时/取消（run.ts 信号路径）只会杀审查自己的进程组，杀不到 detached 套件的进程组——PR 自己的测试进程会在审查死后存活，仍可写入共享的 common 目录配置。把回收扩展到异常路径需要触及 run.ts 的信号处理；上一轮已作为自包含的健壮性改动提出（把套件 pid 记录到包装层拆除时能够到的地方，或让信号处理器同时杀套件进程组）。
— qwen3.8-max via Qwen Code /review (v0.21.14)
|
🔀 Base updated: red check(s) [Test (ubuntu-latest, Node 22.x)] pass on current main — merged current main via update-branch; CI will re-run. 中文说明🔀 已更新 base：红色检查 [Test (ubuntu-latest, Node 22.x)] 在当前 main 上通过 —— 已通过 update-branch 合入当前 main，CI 将重新运行。 |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Partially reviewed — gaps disclosed.
Not reviewed: build-and-test — Test (windows-latest, Node 22.x) and Test (macos-latest, Node 22.x) were skipped in CI and their platform-specific suites did not run locally (the process-reap semantics R3-5/R2-11 target are unverified on those platforms).
Not reviewed: reverse audit — did not converge within the reverse-audit round cap of 5.
Test Plan (not a blocker): 941 passed — this review observed 22598 passed.
Deferred under the convergence posture (round 4, not a blocker) — recorded, not requested in this round:
packages/cli/src/commands/review/test-efficacy.ts:1721 — [probe] no test exercises the reap after the suite's timeout fires or a non-zero suite exit (error-path reap exists but is unpinned; mutant r.status===0 guard stays green while probe …packages/cli/src/commands/review/test-efficacy.ts:2554 — [probe] probe-phase entry screen runs before discardWorktree and can refuse on stale state the very next statement removes — a self-perpetuating wedge until manual cleanuppackages/cli/src/commands/review/test-efficacy.integration.test.ts:2143 — [probe] reap test's liveness assertion keys on the environment's zombie reaper, not the reap (kill(pid,0) succeeds against a zombie; fails red under a non-reaping PID…
中文说明
仅完成部分审查，审查缺口已披露。
未审查：build-and-test — Test (windows-latest, Node 22.x) and Test (macos-latest, Node 22.x) were skipped in CI and their platform-specific suites did not run locally (the process-reap semantics R3-5/R2-11 target are unverified on those platforms)。
未审查：反向审计——在 5 轮的反审轮数上限内未收敛。
Test Plan（非阻断）：941 passed — this review observed 22598 passed。
收敛姿态下延后（第 4 轮，非阻断）——已记录，本轮不要求修改：共 3 条（原文未翻译，列表见上方英文部分）。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| // ones are refused by this pattern anyway. Section names normalise to | ||
| // lowercase in git's output (`includeIf` reads as `includeif`). | ||
| '^(include\\.path|includeif\\..*\\.path)$', |
There was a problem hiding this comment.
[Critical] R3-1: Still standing at HEAD — no fix landed since round 3 (the branch delta since the round-3 review is a main merge only). The screen refuses on ANY include.path/includeif.*.path directive key without resolving the include target, but standard GitHub Actions checkouts — including this PR's own CI — carry benign includeif.gitdir: credential directives whose included files hold only an http.extraheader authorization header and no filters. Every fetch-pr/base-tree/scratch-tree/test-efficacy run against such a checkout is refused until someone hand-removes runner-managed entries — the exact false-positive failure class the PR description cites as the reason the screen stays repo-local.
Witness at HEAD: fetch-pr.test.ts fails 80 tests net-new against the merge base (test-delta attribution), every failure throwing this refusal; the PR's own CI job Test (ubuntu-latest, Node 22.x) is red with the byte-identical refusal on a different runner, while this PR's own new screen test passes. Inspecting the ambient runner config: four benign includeIf.gitdir: directives, targets hold no filter keys.
Fix direction: resolve the included files (recursively, cycle-guarded) and refuse only when they transitively define filter.*.(smudge|clean|process) keys — benign credential includes pass, a planted-filter include still refuses; keep fail-closed refusal for unreadable targets. Also make the fetch-pr handler tests hermetic (chdir into the fixture repo) so the suite cannot read the machine's real .git/config.
中文说明
R3-1：在 HEAD 上仍然存在——第 3 轮之后没有任何修复落入分支（第 3 轮审查之后分支的增量只有 main 合并）。屏蔽对任何 include.path/includeif.*.path 指令键一律拒绝，却不解析 include 目标；而标准 GitHub Actions 检出（包括本 PR 自己的 CI）都带有良性的 includeif.gitdir: 凭据指令，其目标文件只有 http.extraheader 授权头，没有任何过滤器。针对此类检出的每一次 fetch-pr/base-tree/scratch-tree/test-efficacy 运行都会被拒绝，除非有人手工删除由 runner 管理的条目——这正是 PR 描述引为"屏蔽只看仓库本地配置"理由的误报失败类别。
HEAD 上的证据：fetch-pr.test.ts 相对合并基线 net-new 失败 80 个（test-delta 归因），每个失败都抛出该拒绝；PR 自己的 CI 作业 Test (ubuntu-latest, Node 22.x) 在另一台 runner 上以逐字节相同的拒绝文本变红，而本 PR 自己新增的屏蔽测试却通过。检查本机 runner 配置：四个良性 includeif.gitdir: 指令，目标文件均无任何过滤器键。
修复方向：解析被 include 的文件（递归、带环保护），仅当其（传递地）定义了 filter.*.(smudge|clean|process) 键时才拒绝——良性凭据 include 放行，指向植入过滤器的 include 仍被拒绝；对无法读取的目标保持失败即关闭。同时让 fetch-pr 的 handler 测试密封化（chdir 进夹具仓库），使测试套件不会读到机器真实的 .git/config。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| for (const mod of readdirSync(modulesDir)) { | ||
| candidates.push(join(modulesDir, mod, 'config')); | ||
| candidates.push(join(modulesDir, mod, 'config.worktree')); |
There was a problem hiding this comment.
[Critical] R3-2: Still standing at HEAD. submoduleConfigs enumerates exactly one readdirSync level, so filters defined in a NESTED (depth ≥ 2) submodule config under the common dir (<common>/modules/<a>/modules/<b>/config, and the <common>/worktrees/<label>/modules/… analogue) are invisible to every screen, while the checkouts it authorises execute them once submodule.recurse=true — a key the filter regex deliberately leaves legal — is also set.
Witness (verifier probe at HEAD, git 2.43): superproject → submodule A → submodule B; plant in B's config: SCREEN-NESTED-MAIN keys=[] and SCREEN-NESTED-TREE keys=[], while the same plant one level up IS detected (SCREEN-DEPTH1-CONTROL keys=["filter.evil.smudge"]); checkout --force HEAD with submodule.recurse=true then executed the nested plant (marker created at depth 1 AND depth 2). Fix-flip (recursion added) detects the nested plant. The plant lives in the common dir, which discard/cleanup never wipe — the persistence outcome this screen exists to refuse.
Fix direction: descend transitively — after the two pushes, call submoduleConfigs(join(modulesDir, mod, 'modules')) (terminates naturally where no modules/ dir exists); add a regression test planting into a nested submodule config.
中文说明
R3-2：在 HEAD 上仍然存在。submoduleConfigs 只枚举一层 readdirSync，因此定义在 common 目录下嵌套（深度 ≥ 2）子模块配置中的过滤器（<common>/modules/<a>/modules/<b>/config，以及 <common>/worktrees/<label>/modules/… 的对应形态）对所有屏蔽不可见，而一旦同时设置 submodule.recurse=true（一个过滤器正则刻意保持合法的键），屏蔽所授权的 checkout 就会执行它们。
证据（验证探针于 HEAD，git 2.43）：超级项目 → 子模块 A → 子模块 B；植入 B 的配置：SCREEN-NESTED-MAIN keys=[]、SCREEN-NESTED-TREE keys=[]，而同样的植入上移一层即可被检出（SCREEN-NESTED-DEPTH1-CONTROL keys=["filter.evil.smudge"]）；随后带 submodule.recurse=true 的 checkout --force HEAD 执行了嵌套植入（深度 1 与深度 2 均创建标记）。修复翻转（加入递归）后嵌套植入被检出。植入住在 common 目录中，discard/cleanup 从不清扫——正是该屏蔽存在所要拒绝的持久化结果。
修复方向：传递式下探——在两次 push 之后调用 submoduleConfigs(join(modulesDir, mod, 'modules'))（无 modules/ 目录处自然终止）；并新增回归测试：向嵌套子模块配置植入并断言拒绝。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| // `process` beside the pair: it is the third executable key (a | ||
| // long-running filter git speaks a protocol to), and enumerating two | ||
| // of three is how the first cut of this screen read as complete. | ||
| '^filter\\..*\\.(smudge|clean|process)$', |
There was a problem hiding this comment.
[Critical] R3-3: Still standing at HEAD — class-level finding. The pattern list hand-enumerates git's command-executing config keys, and that entrance space is open-ended. Re-verified this round by probe: git config submodule.<name>.update '!CMD' in the common config matches no pattern and INERT_GIT_ARGS does not cover it — the review completes clean and the user's own next git submodule update runs CMD; diff.external = CMD planted the same way fires on the user's own plain git diff (pipeline diff spawns pin --no-ext-diff, so only the user's later commands execute it). Additionally core.fsmonitor/hook-file plants are neutralised at pipeline spawns by INERT_GIT_ARGS but never DETECTED — the INERT_GIT_ARGS docstring claim "the plant persists, and the screen stays the half that detects and refuses it" is false for those shapes. Rounds 1–4 have each found new entrances of this class (filters → includes → fsmonitor/hooks → submodule.update/diff.external); closing entrances one by one has not converged.
Witness (probe at HEAD): SCREEN-SUBMODULE-UPDATE keys=[] then user git submodule update sm → marker created; SCREEN-DIFF-EXTERNAL keys=[] then user plain git diff → marker created (with --no-ext-diff: not created); SCREEN-FSMONITOR keys=[].
Fix direction — structural, not entrance-by-entrance: correct the docstring scope claim, and either maintain the pattern list as an explicitly curated, DISCLOSED sample of command-executing keys, or widen refusal to a curated set (submodule.*.update with ! values, diff.external, core.fsmonitor, core.hooksPath, …) acknowledging the list can never be complete.
中文说明
R3-3：在 HEAD 上仍然存在——类级发现。模式列表手工枚举 git 的可执行配置键，而该入口空间是无界的。本轮经探针重新验证：向 common 配置写入 git config submodule.<name>.update '!CMD' 不匹配任何模式，INERT_GIT_ARGS 也不覆盖它——审查干净结束，用户自己的下一次 git submodule update 即执行 CMD；以同样方式植入 diff.external = CMD，会在用户自己的普通 git diff 上触发（流水线自身的 diff spawn 都钉死了 --no-ext-diff，因此只有用户之后的命令会执行它）。此外 core.fsmonitor/钩子文件植入虽被 INERT_GIT_ARGS 在流水线 spawn 上中和，却从不被检测——INERT_GIT_ARGS 文档注释中"植入会留存，而屏蔽仍是检测并拒绝它的那一半"这一说法对这些形态是假的。第 1–4 轮每一轮都发现了该类的新入口（filters → includes → fsmonitor/hooks → submodule.update/diff.external）；逐个封堵入口并未收敛。
证据（HEAD 探针）：SCREEN-SUBMODULE-UPDATE keys=[]，随后用户 git submodule update sm → 标记创建；SCREEN-DIFF-EXTERNAL keys=[]，随后用户普通 git diff → 标记创建（带 --no-ext-diff 则不创建）；SCREEN-FSMONITOR keys=[]。
修复方向——结构性而非逐入口：修正文档注释的作用域声明；要么把模式列表明确维护为一份已披露的命令执行键精选样本，要么把拒绝面扩大到精选集合（带 ! 值的 submodule.*.update、diff.external、core.fsmonitor、core.hooksPath 等），并承认该清单永远不可能完整。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| ['config', '--file', file, '--get-regexp', pattern], | ||
| { cwd: worktree, encoding: 'utf8', env: sanitizedGitEnv() }, | ||
| ); | ||
| if (r.error || r.status !== 0 || typeof r.stdout !== 'string') continue; |
There was a problem hiding this comment.
[Critical] R3-4: Still standing at HEAD. These --get-regexp spawns run on spawnSync's DEFAULT 1 MiB maxBuffer. A plant whose matching output exceeds it gets the child killed (ENOBUFS), and the continue below reads that kill as "this file contains nothing" — so an armed filter screens clean and then executes on the very checkout the screen guards. The extracted screen is the one spawn that lost this codebase's own ENOBUFS lesson: six sibling spawns (including the suite spawn in test-efficacy.ts) set maxBuffer: 64 * 1024 * 1024 with a comment describing exactly this child-kill.
Witness (verifier probe at HEAD, no concurrency needed): one attributes line *.ts filter=evil plus one <common>/config write holding one armed filter.evil.smudge beside ~60,000 junk [filter "jN"] smudge sections → SPAWN-SHAPE error=ENOBUFS status=null signal=SIGTERM stdoutLen=1114112; SCREEN-OVERFLOWED keys=[] while SCREEN-CONTROL keys=["filter.evil.smudge"] (same file without junk); the guarded checkout ran: status=0 marker=true. Fix-flip (maxBuffer: 64 MiB): all 60,001 keys detected.
Fix both halves: pass an explicit maxBuffer (the same 64 MiB), AND fail closed on spawn failure — keep status 1 (no match) as clean, but treat r.error / killed child / other statuses as "this file could not be cleared" and force a refusal, since any fixed buffer is re-overflowable.
中文说明
R3-4：在 HEAD 上仍然存在。这些 --get-regexp spawn 使用 spawnSync 的默认 1 MiB maxBuffer。若植入产生的匹配输出超过它，子进程会被杀死（ENOBUFS），而下方的 continue 把这次杀死读作"此文件没有任何匹配"——于是已武装的过滤器被屏蔽判为干净，随后在屏蔽所守护的那个 checkout 上执行。抽取后的屏蔽正是丢失了本代码库自己 ENOBUFS 教训的那个 spawn：另外六个兄弟 spawn（包括 test-efficacy.ts 里的套件 spawn）都设置了 maxBuffer: 64 * 1024 * 1024，其注释描述的正是这种子进程被杀。
证据（验证探针于 HEAD，无需并发）：一行 attributes *.ts filter=evil，加上向 <common>/config 一次写入——一个已武装的 filter.evil.smudge 与约 60,000 个垃圾 [filter "jN"] smudge 节并存 → SPAWN-SHAPE error=ENOBUFS status=null signal=SIGTERM stdoutLen=1114112；SCREEN-OVERFLOWED keys=[]，而 SCREEN-CONTROL keys=["filter.evil.smudge"]（同一文件去掉垃圾键）；受守护的 checkout 照常执行：status=0 marker=true。修复翻转（maxBuffer: 64 MiB）：60,001 个键全部检出。
修复要补两半：显式传 maxBuffer（同样的 64 MiB），并且在 spawn 失败时失败即关闭——status 1（无匹配）仍视为干净，但 r.error/被杀子进程/其他状态码视为"此文件无法被清空"并强制拒绝，因为任何固定缓冲区都可以被再次溢出。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| if (r.pid > 0) { | ||
| killProcessGroup(r.pid, 'SIGKILL'); | ||
| } |
There was a problem hiding this comment.
[Critical] R3-5: Still standing at HEAD. A descendant of the PR's own test code that calls setsid escapes this reap on the NORMAL path, all platforms — killProcessGroup(r.pid) kills one process group, and a setsid'd descendant is in its own session/pgid. A surviving toggler then races every subsequent restore screen→checkout pair and the revert pair: the screen reads during the toggler's unset half-cycle and passes, the toggler plants before the checkout's config read, and the checkout executes the smudge. The comment above this code claims "the screens stay the detection half for whatever did [setsid away]" — false for a TOGGLING escapee: a point-in-time screen cannot detect a plant that is absent at the screen's read and present at the checkout's read.
Witness (verifier probe at HEAD): reap split — the exact reap killed the leader's group while the setsid'd descendant survived (leader-alive=false escapee-alive=true); race — 250 real screen→checkout pairs vs a setsid'd toggler: fired=119 refused=67 clean=64 rate=47.6%; control (no toggler) fired=0/30. No concurrency or second review needed; the pipeline always runs the PR's code before these pairs.
Minimal repair: strike/correct the false claim, and detect-and-disclose (re-run localFilterRefusal immediately after each screened checkout and report the run as breached rather than clean). Full closure (a kill scope that survives setsid — Linux cgroup/systemd-run --scope + cgroup kill, or pidfd) is a design call for the maintainer.
中文说明
R3-5：在 HEAD 上仍然存在。PR 自己的测试代码中任何调用 setsid 的子孙进程，都能在正常路径上逃脱这次回收（所有平台）——killProcessGroup(r.pid) 只杀一个进程组，而 setsid 的子孙位于自己的会话/进程组。存活的切换器会与之后每一次"恢复屏蔽→checkout"对及 revert 对竞速：屏蔽在切换器的 unset 半周期读取并放行，切换器在 checkout 读配置之前植入，checkout 执行 smudge。此代码上方的注释声称"屏蔽仍是那些 setsid 逃脱者的检测一半"——对切换型逃脱者该说法是假的：时间点式的屏蔽无法检测"屏蔽读取时不存在、checkout 读取时存在"的植入。
证据（验证探针于 HEAD）：回收切分——该精确回收杀死了组长所在组，而 setsid 子孙存活（leader-alive=false escapee-alive=true）；竞速——250 次真实"屏蔽→checkout"对对阵 setsid 切换器：fired=119 refused=67 clean=64 rate=47.6%；对照（无切换器）fired=0/30。无需并发，也无需第二次审查；流水线在这些对之前总会运行 PR 的代码。
最小修复：删改这句不实声明，并改为"检测即披露"（在每个被屏蔽的 checkout 之后立即重跑 localFilterRefusal，若读到植入则把该次运行报告为被穿透而非干净）。彻底关闭（能跨越 setsid 的杀域——Linux cgroup/systemd-run --scope + cgroup kill，或 pidfd）属维护者的设计决策。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| const keys = localFilterCommands(worktree); | ||
| if (keys.length === 0) return null; | ||
| return ( | ||
| `the repository's local config defines ${keys.map(inertPath).join(', ')} — ` + |
There was a problem hiding this comment.
[Suggestion] R3-8: Still standing at HEAD. The refusal names only the offending KEYS, never the files holding them — but this same PR widened the screen to detect keys in files the implied remediation (git config --unset <key>) cannot reach: <common>/config.worktree, per-worktree config.worktrees, and submodule configs under <common>/modules/ and <common>/worktrees/*/modules/.
Witness (verifier probe at HEAD): plant filter.evil.smudge into <common>/modules/sub/config → refusal names key=true names file=false; git config --unset filter.evil.smudge → status 5 (no such section in <common>/config); screen STILL-REFUSED keys=["filter.evil.smudge"] — the user cannot clear the refusal by following its own recipe.
Fix direction: include the holding file(s) in the refusal — group keys by the candidate file they were read from.
中文说明
R3-8：在 HEAD 上仍然存在。拒绝只点名出问题的键，从不说出持有这些键的文件——但同一个 PR 把屏蔽扩展到能检测这样一些文件里的键：其隐含补救（git config --unset <key>）根本够不到它们——<common>/config.worktree、各工作树的 config.worktree，以及 <common>/modules/ 与 <common>/worktrees/*/modules/ 下的子模块配置。
证据（验证探针于 HEAD）：向 <common>/modules/sub/config 植入 filter.evil.smudge → 拒绝点名键=是、点名文件=否；git config --unset filter.evil.smudge → status 5（<common>/config 中无此节）；屏蔽仍然拒绝 keys=["filter.evil.smudge"]——用户按照拒绝自带的配方无法解除拒绝。
修复方向：在拒绝中给出持有文件——按键被读出的候选文件分组。
— qwen3.8-max via Qwen Code /review (v0.21.15)
There was a problem hiding this comment.
Deferred to the next round (batch cap: the 8 Criticals came first). The return shape changed to LocalFilterScreen { keys, unclearable } this round, which is the seam this attribution work extends: pair each key with the file that defined it (for includes, the target file) and render grouped by candidate in the refusal. The unclearable entries already carry their file paths, so half the attribution is in place.
推迟到下一轮（批次上限：8 个 Critical 优先）。本轮已把返回结构改为 LocalFilterScreen { keys, unclearable }，这正是该归属信息工作要扩展的接缝：把每个 key 与定义它的文件配对（对 include 而言是目标文件），并在拒绝信息中按候选文件分组展示。unclearable 条目已经携带文件路径，归属信息已完成一半。
| const r = spawnSync( | ||
| 'git', | ||
| ['config', '--file', file, '--get-regexp', pattern], | ||
| { cwd: worktree, encoding: 'utf8', env: sanitizedGitEnv() }, |
There was a problem hiding this comment.
[Suggestion] R3-9: Still standing at HEAD. The candidate-reading spawns have no timeout, and this PR widened the candidate set (main config.worktree, every linked worktree's admin config.worktree, submodule configs under <common>/modules/ and every <common>/worktrees/<label>/modules/, plus include-directive patterns doubling the spawns per file). existsSync admits non-regular files, so a blocking candidate (a FIFO, a network-fs stall, a hostile file object) hangs localFilterCommands indefinitely — and the screen sits before every checkout in the pipeline, so qwen review fetch-pr hangs with no way to cancel short of killing the CLI. The codebase's own convention, gitOpts() in lib/git.ts, sets timeout: GIT_TIMEOUT_MS (120 s) on every git spawn it wraps.
Witness (demo at HEAD): timeout 5 git config --file <FIFO> --get-regexp '^filter\..*\.(smudge|clean|process)$' → EXIT=124 — ran the full budget and was killed; a spawnSync without timeout blocks indefinitely.
Fix direction: give both spawns a bounded timeout (the same GIT_TIMEOUT_MS) and treat timeout as fail-closed (refuse), like R3-4's error path.
中文说明
R3-9：在 HEAD 上仍然存在。读取候选文件的 spawn 没有 timeout，而本 PR 扩大了候选集合（主 config.worktree、每个链接工作树管理目录的 config.worktree、<common>/modules/ 与每个 <common>/worktrees/<label>/modules/ 下的子模块配置，外加 include 指令模式使每个文件的 spawn 数翻倍）。existsSync 允许非常规文件，因此一个阻塞型候选（FIFO、网络文件系统卡死、恶意文件对象）会让 localFilterCommands 无限期挂起——而屏蔽位于流水线每一个 checkout 之前，于是 qwen review fetch-pr 会挂死，除了杀掉 CLI 别无取消手段。代码库自己的惯例——lib/git.ts 的 gitOpts()——为它包装的每一个 git spawn 都设置了 timeout: GIT_TIMEOUT_MS（120 秒）。
证据（HEAD 演示）：timeout 5 git config --file <FIFO> --get-regexp '^filter\..*\.(smudge|clean|process)$' → EXIT=124——跑满时限被杀；不带 timeout 的 spawnSync 会无限期阻塞。
修复方向：给这两个 spawn 加上有限超时（同样的 GIT_TIMEOUT_MS），并把超时按失败即关闭处理（拒绝），与 R3-4 的错误路径一致。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| const pid = Number(readFileSync(pidFile, 'utf8')); | ||
| expect(() => process.kill(pid, 0)).toThrow(); |
There was a problem hiding this comment.
[Suggestion] R2-9: Still standing at HEAD (deferred in round 2, re-posted in round 3, re-verified this round). The reap test pins the END STATE — the descendant pid is dead after runHandler returns — not the property the reap exists for: the group must be dead BEFORE the next screen+checkout pair.
Witness (executed mutation at HEAD): mutant A — moving killProcessGroup(r.pid) from after-spawnSync to the end of runTestEfficacy — the reap test STILL PASSES while instrumentation inside restoreProbeTreeTracked shows the window wide open (restore: pending=2 alive=2 pids=[…] at each subsequent restore); mutant B — kill removed entirely — the test fails at this assertion. The probe flips between no-reap (red) and late-reap (green): the test distinguishes presence-at-end from timing, which is exactly the property it does not pin.
Fix direction: assert the lingerer dead BEFORE the next screen+checkout pair — e.g. instrument the restore to observe liveness at that moment — rather than only after the run returns.
中文说明
R2-9：在 HEAD 上仍然存在（第 2 轮缓办、第 3 轮重新提交、本轮重新验证）。reap 测试固化的是最终状态——runHandler 返回之后子孙 pid 已死——而不是 reap 存在所要保证的性质：进程组必须在下一次"屏蔽+checkout"对之前死掉。
证据（HEAD 上执行的突变）：突变体 A——把 killProcessGroup(r.pid) 从 spawnSync 之后移到 runTestEfficacy 末尾——reap 测试仍然通过，而 restoreProbeTreeTracked 内的插桩显示窗口完全敞开（每次后续 restore 时 restore: pending=2 alive=2 pids=[…]）；突变体 B——完全移除 kill——测试在该断言处失败。探针在"无回收（红）"与"迟回收（绿）"之间翻转：测试区分的是"最终是否存在"与"时机"，而时机正是它没有固化的性质。
修复方向：断言 lingerer 在下一次"屏蔽+checkout"对之前已死——例如在 restore 处插桩观察该时刻的存活状态——而不仅仅在运行返回之后。
— qwen3.8-max via Qwen Code /review (v0.21.15)
There was a problem hiding this comment.
Deferred to the next round (batch cap: the 8 Criticals came first). The reap now has a precise comment to assert against (setsid'd descendants survive; post-checkout re-reads disclose), which is also what makes the proposed ordering assertion sharper: assert the lingerer is dead BEFORE the next screen+checkout pair by having the fake suite's descendant write a file that the next restore's pre-screen would refuse on if it ran — dead reap means no write, live escapee means a refusal. Tracked so it is not dropped.
推迟到下一轮（批次上限：8 个 Critical 优先）。reap 现在有了一段可以对其做断言的精确注释（setsid 后代会幸存；checkout 后的重读会披露），这也让建议的顺序断言更明确：让假套件的子进程写一个文件来断言 lingerer 在下一次 screen+checkout 对之前已死 —— 如果它还能运行，下一次 restore 的 pre-screen 就会因该文件被拒；reap 生效意味着没有写入，逃逸意味着出现拒绝。已跟踪，不会遗漏。
| maxBuffer: 64 * 1024 * 1024, | ||
| detached: true, | ||
| }; |
There was a problem hiding this comment.
[Suggestion] R2-11: Still standing at HEAD (deferred in round 2, re-posted in round 3, re-verified this round). detached: true moves the probe suite out of the review's process group, and the reap below runs only when spawnSync RETURNS. Before this diff the non-detached spawn placed the suite in the review's group, which run.ts's two group kills consume (the timeout kill and the Ctrl+C/CI-SIGTERM forwarding). Now a wrapper timeout or operator/CI cancel landing mid-suite kills the review group; the suite's vitest plus every process the PR's test code spawned survive the explicit cancellation — and a dead parent can no longer enforce the spawnSync timeout either.
Witness (verifier probe at HEAD): pgid(suite) = suitePid ≠ reviewGroup; after kill(-reviewGroup, SIGTERM): review dead / suite alive / lingerer alive. FLIP arm (one-line revert detached: false): pgid(suite) = reviewGroup; same kill: suite dead / lingerer dead — flips on the one-line revert.
Fix direction (corrected this round — the round-3 suggestion as worded cannot work): a JS SIGTERM handler in this file will NOT run while spawnSync blocks the event loop, so "kill from a SIGTERM hook" cannot fire mid-suite. Workable directions: run.ts-side awareness of the live suite's pgid (mirroring its own signal forwarding), an async-spawn equivalent, or at minimum documenting the residual window beside the reap.
中文说明
R2-11：在 HEAD 上仍然存在（第 2 轮缓办、第 3 轮重新提交、本轮重新验证）。detached: true 把探针套件移出审查的进程组，而下面的回收只在 spawnSync 返回时运行。在本 diff 之前，非 detached 的 spawn 把套件放进审查的进程组，run.ts 的两次进程组 kill（超时 kill 与 Ctrl+C/CI-SIGTERM 转发）都会把它一并杀掉。现在，落在套件运行中途的包装层超时或操作者/CI 取消只会杀死审查进程组；套件的 vitest 以及 PR 测试代码 spawn 的所有进程都会在这次明确取消中存活——而且父进程已死，spawnSync 的 timeout 也不再可执行。
证据（验证探针于 HEAD）：pgid(suite) = suitePid ≠ reviewGroup；kill(-reviewGroup, SIGTERM) 之后：审查已死 / 套件存活 / lingerer 存活。翻转分支（单行还原 detached: false）：pgid(suite) = reviewGroup；同样的 kill：套件死 / lingerer 死——在单行还原上翻转。
修复方向（本轮更正——第 3 轮建议的原始措辞不可行）：在 spawnSync 阻塞事件循环期间，本文件里的 JS SIGTERM 处理器不会运行，因此"从 SIGTERM 钩子里杀"无法在套件运行中途触发。可行方向：让 run.ts 一侧感知存活套件的 pgid（仿照它自己的信号转发）、改用异步 spawn 的等价物，或至少在回收旁把这个残余窗口写入文档。
— qwen3.8-max via Qwen Code /review (v0.21.15)
There was a problem hiding this comment.
Partially addressed by documentation this round: the reap comment now names the residual window explicitly — detached puts the suite out of the review's process group, and a wrapper timeout or operator cancel landing mid-suite kills the review's group (run.ts signal forwarding) but not the suite's, because the reap runs only when the spawn returns. The run.ts half (pgid-aware cancel, or a note beside the spawn documenting the gap) is deferred to the next round — it touches run.ts's signal handling, which this round's Critical batch did not open.
本轮已通过文档部分处理：reap 注释现在明确写出了残留窗口 —— detached 使套件脱离 review 的进程组，而包装层的超时或操作者在套件运行中途取消时，杀掉的是 review 的进程组（run.ts 的信号转发）而不是套件的，因为 reap 只在 spawn 返回时运行。run.ts 那一半（感知 pgid 的取消，或在 spawn 旁注明该缺口）推迟到下一轮 —— 它涉及 run.ts 的信号处理，本轮的 Critical 批次没有打开这部分。
| // NO_HOOKS covered hooks here from the start; `core.fsmonitor` is the | ||
| // one-write command-execution surface both the rebuild's `worktree add` |
There was a problem hiding this comment.
[Suggestion] R4-4 (new this round): this comment, ADDED by the PR, names NO_HOOKS — a constant this same PR deletes from scratch-tree.ts (replaced by INERT_GIT_ARGS in lib/worktree.ts). Sweep at HEAD: NO_HOOKS appears exactly 2 times in the whole tree — here and at line 94, both comments, zero code references. The pre-existing line-94 comment dangles for the same reason: the PR's deletion orphans it.
Failure scenario: a maintainer chasing a future hooks/fsmonitor regression reads this test's rationale comment and greps NO_HOOKS for the mechanism it names — zero hits — and must rediscover by hand that the prefix is now INERT_GIT_ARGS; the comment written to carry the "why" loses its referent the moment it merges.
| // NO_HOOKS covered hooks here from the start; `core.fsmonitor` is the | |
| // one-write command-execution surface both the rebuild's `worktree add` | |
| // INERT_GIT_ARGS covered hooks here from the start; `core.fsmonitor` is the | |
| // one-write command-execution surface both the rebuild's `worktree add` |
(and update the orphaned line-94 comment alongside the deletion)
中文说明
R4-4（本轮新发现）：这条由本 PR 新增的注释点名了 NO_HOOKS——而同一个 PR 把该常量从 scratch-tree.ts 中删除了（由 lib/worktree.ts 的 INERT_GIT_ARGS 取代）。HEAD 全树检索：NO_HOOKS 恰好出现 2 次——此处与第 94 行，均为注释，代码引用为零。第 94 行的既有注释因同样原因悬空：本 PR 的删除使其失去所指。
失败场景：维护者追查未来的 hooks/fsmonitor 回归时，读到本测试的理据注释，按其点名的机制去 grep NO_HOOKS——零命中——只能手工重新发现前缀现在是 INERT_GIT_ARGS；承载"为什么"的注释在合并的那一刻就失去了所指。
（同时把第 94 行被孤立的注释一并更新）
— qwen3.8-max via Qwen Code /review (v0.21.15)
There was a problem hiding this comment.
Deferred to the next round (round-5 posture: Critical fixes only; this is a two-line comment rename). The fixture test comment at scratch-tree.test.ts:185 still says NO_HOOKS; the constant is INERT_GIT_ARGS. Tracked so it is not dropped.
推迟到下一轮（第 5 轮准则：仅落地 Critical 修复；这是一个两行的注释改名）。scratch-tree.test.ts:185 的 fixture 测试注释仍写作 NO_HOOKS；常量实际是 INERT_GIT_ARGS。已跟踪，不会遗漏。
…9566) The screen refused ANY include directive, wedging every checkout on a standard GitHub Actions runner whose ambient credential directives hold no filters; it now resolves targets recursively and refuses only when the closure defines filters (unreadable targets stay fail-closed). Nested submodule configs are walked transitively, oversized or failed config reads fail closed instead of reading as "no match", and the screens move below the stale sweeps they precede — a plant parked in the doomed tree's own admin dir used to wedge every retry. Each screened checkout in the probe phase also re-reads the screen after the checkout and reports a breach when a plant appeared during it, and the reap comment no longer claims the screens cover setsid'd escapees.
|
🤖 Addressed the latest review feedback (round 3/100). What changed, and what I pushed back on: · 已处理最新评审反馈（第 3/100 轮）。改动内容与我反驳保留之处如下： Autofix round summary — PR #9566Round 4 review posted 8 Criticals and 7 Suggestions (plus one red Critical findings — all addressed
Suggestions — subsumed by the rewrite (resolved)
Suggestions — deferred to the next round (recorded, replied on-thread)R3-7 (submodule VerificationCommands actually run this round (all in
Mutation probes (guard removed/negated → focused test must FAIL → guard restored → green again):
Not run: integration harness via 中文说明Autofix 本轮总结 — PR #9566第 4 轮 review 提出了 8 个 Critical 和 7 个 Suggestion（外加一个由第一个 Critical 导致的红色 Critical 问题 — 全部处理
Suggestion — 被重写顺带覆盖（已解决）
Suggestion — 推迟到下一轮（已记录，并在各自线程回复）R3-7（submodule 验证本轮实际运行的命令（如无特别说明均在
变异探针（移除/取反守卫 → 重点测试必须失败 → 恢复守卫 → 重新变绿）：
未运行：经 Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 Re-review when you have a moment. After round 100 this bot stops and leaves the PR for a human. · 有空请复审；第 100 轮后本 bot 停止并将 PR 交给人工。 🧠 Handled by Qwen Code · model/模型 |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Partially reviewed — gaps disclosed.
3 Suggestion-level finding(s) this review confirmed are already reported on this PR and are not repeated:
- R3-7 submodule config.worktree candidate push untested — already reported at lib/worktree.ts:721 (comment 3824952763)
- R2-9 reap test pins end state not property — already reported at test-efficacy.integration.test.ts:2144 (comment 3824952789)
- R2-11 detached:true orphans suite on wrapper timeout/cancel — already reported at test-efficacy.ts:1717 (comment 3824952796)
Not reviewed: build-and-test — Test (windows-latest, Node 22.x) was skipped in CI and its platform-specific suites did not run locally (the reap semantics R3-5/R2-11/R5-5 target and the Windows fixture parsing R5-7 names are unverified on that platform).
Not reviewed: build-and-test — Test (macos-latest, Node 22.x) was skipped in CI and its platform-specific suites did not run locally.
Not reviewed: reverse audit — stopped before round 5 by the review time budget.
Test Plan (not a blocker): 941 passed — this review observed 22693 passed.
中文说明
仅完成部分审查，审查缺口已披露。
本轮确认的 3 条建议级发现已在 PR 上报告过，不再重复发布（列表见上方英文部分）。
未审查：build-and-test — Test (windows-latest, Node 22.x) was skipped in CI and its platform-specific suites did not run locally (the reap semantics R3-5/R2-11/R5-5 target and the Windows fixture parsing R5-7 names are unverified on that platform)。
未审查：build-and-test — Test (macos-latest, Node 22.x) was skipped in CI and its platform-specific suites did not run locally。
未审查：反向审计——评审时间预算不足，未能开始第 5 轮。
Test Plan（非阻断）：941 passed — this review observed 22693 passed。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| // Bounds a planted symlink cycle (`modules/a` -> the dir above it); real | ||
| // submodule nesting is nowhere near the cap. | ||
| if (depth > 16) return; |
There was a problem hiding this comment.
[Critical] R5-1: The depth cap here bounds recursion DEPTH but not total work — with several symlinks in a modules/ dir that resolve back to the same directory, submoduleConfigs branches exponentially (≈ n^16 calls toward the cap of 16) and OOM-crashes the process, so the cap does not do what its comment claims. This PR's own threat model lets the reviewed PR's probe write into the common dir: plant five symlinks in .git/modules so modules/x0/modules resolves back to modules itself, and the next localFilterRefusal/localFilterBreach call — which guards every checkout in the pipeline — dies with a JavaScript-heap OOM before reaching the cap. The symlinks persist in the user's .git, so every retry crashes too: a denial of the whole review run planted by the very artifact the screen exists to police, instead of a refusal.
Witness (probe):
PR code: FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory (5 symlink loops, depth cap 16)
realpath-dedupe fix: COMPLETED in 13 ms {"keys":[],"unclearable":[]}
Dedupe visited directories by realpath (as the include scan already does) instead of bounding depth — a seenDirs Set of realpathSync(modulesDir) values makes the walk acyclic regardless of symlink branching.
中文说明
此处的深度上限只限制递归深度，不限制总工作量——若 modules/ 目录中有多个符号链接解析回同一目录，submoduleConfigs 会指数级分支（朝向深度上限 16 约 n^16 次调用），进程将 OOM 崩溃；该上限没有做到注释所声称的事。本 PR 自己的威胁模型允许被审查 PR 的探针写入 common 目录：在 .git/modules 中植入五个符号链接使 modules/x0/modules 解析回 modules 自身，下一次 localFilterRefusal/localFilterBreach 调用（守护流水线中的每一个 checkout）就会在到达上限前以 JavaScript 堆 OOM 死掉。符号链接持久留在用户的 .git 中，每次重试都会崩溃：这是由屏蔽本要防御的那个植入物造成的、对整个审查运行的拒绝，而不是一次拒绝。证据（探针）：PR 代码：FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory（5 个符号链接环）；按 realpath 去重修复后：COMPLETED in 13 ms {"keys":[],"unclearable":[]}。修复：像 include 扫描那样按 realpath 对已访问目录去重，而不是限制深度。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| const refusal = localFilterRefusal( | ||
| worktree, | ||
| 'the worktree add this command runs', | ||
| ); |
There was a problem hiding this comment.
[Critical] R5-2: This creation checkout is screened but has no paired post-checkout localFilterBreach re-read — the PR gives that re-read to the restore and revert pairs (they are the only two breach call sites), leaving four unpaired sites (this one; fetch-pr.ts:940; scratch reset :277; scratch rebuild :473). A concurrent writer the pipeline itself schedules (a sibling shard's suite, or a setsid'd descendant the reap cannot reach — both named in this PR's own comments) writes filter.evil.smudge into the shared common dir after the screen reads clean but before the add's own config read; the add's initial checkout executes the smudge on the reviewer's machine, the toggler unplants, and every later screen reads clean — the run completes certified clean with attacker code executed.
Witness (probe, this site): plantLanded 12/25, hits 12 — every landed plant fired and the report came back available: true ("base tree built at …"); candidate-fix arm (breach re-read after the add): plantLanded 22/25, hits 0, every landed plant reported available:false naming filter.evil.smudge.
Pair this checkout with localFilterBreach immediately after the add succeeds; on breach return unavailable(breach) (and roll back as the refusal path does).
中文说明
这个创建 checkout 有前置屏蔽，但没有配对的 checkout 后 localFilterBreach 复读——本 PR 只对 restore 与 revert 两对加了该复读（它们是仅有的两处 breach 调用点），留下四个未配对站点（此处；fetch-pr.ts:940；scratch reset :277；scratch rebuild :473）。流水线自己调度的并发写者（兄弟 shard 的套件，或回收够不到的 setsid 子孙——本 PR 自己的注释点名了这两类）在屏蔽读干净之后、add 自己读配置之前，把 filter.evil.smudge 写入共享 common 目录；add 的初始 checkout 就会在审查者机器上执行该 smudge，切换器随后撤除植入，之后每一次屏蔽都读到干净——运行以"干净"认证结束，而攻击者代码已经执行。证据（探针，本站点）：plantLanded 12/25, hits 12——每个落地的植入都触发，报告仍为 available: true；候选修复臂（add 后加 breach 复读）：plantLanded 22/25, hits 0，每个落地的植入都报告 available:false 并点名 filter.evil.smudge。修复：add 成功后立即配对 localFilterBreach，命中时返回 unavailable(breach)（并像拒绝路径一样回滚）。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| mkdirSync(dirname(wt), { recursive: true }); | ||
| git('worktree', 'add', wt, ref); |
There was a problem hiding this comment.
[Critical] R5-2 (location 2 of 4): this review-worktree worktree add is screened but has no paired post-checkout localFilterBreach re-read, like the restore/revert pairs — see the base-tree.ts thread for the full finding and witness. The realistic planter here is a surviving toggler from an EARLIER review's suite (rounds reuse one repository; the reap runs per-suite, not per-round), so this site needs no within-run concurrency at all. On breach, release the just-added worktree and fetched ref the way the refusal path does, then throw the breach text.
中文说明
R5-2（共 4 处，第 2 处）：这个 review 工作树的 worktree add 有前置屏蔽，但没有配对的 checkout 后 localFilterBreach 复读（restore/revert 两对都有）——完整发现与证据见 base-tree.ts 的评论串。此处现实的植入者是上一次审查套件幸存的切换器（各轮复用同一仓库，回收按套件而非按轮执行），因此本站点甚至不需要运行内的并发。命中 breach 时，像拒绝路径那样释放刚添加的工作树与 fetch ref，然后抛出 breach 文本。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| if (localFilterRefusal(worktree, 'the reset this command runs') !== null) { | ||
| return false; | ||
| } |
There was a problem hiding this comment.
[Critical] R5-2 (location 3 of 4): the reset's checkout --force is screened but has no paired post-checkout localFilterBreach re-read — see the base-tree.ts thread for the full finding. Witness at the scratch rebuild site (same file, :473): toggler probe plantLanded 18/25, hits 18 — every landed plant executed during worktree add and the report certified available: true, reused: false. The reset hunk's own comment names the live actor and defers only the LOCK ('closing it takes a lock … this round deliberately does not add'); it says nothing about forgoing the detection half this same PR attaches to the restore and revert pairs against the identical window. Pair the reset the same way (note resetScratchTree returns boolean, so a breach note needs threading out to runScratchTree).
中文说明
R5-2（共 4 处，第 3 处）：reset 的 checkout --force 有前置屏蔽，但没有配对的 checkout 后 localFilterBreach 复读——完整发现见 base-tree.ts 评论串。scratch rebuild 站点（同文件 :473）的证据：切换器探针 plantLanded 18/25, hits 18——每个落地的植入都在 worktree add 期间执行，报告仍认证 available: true, reused: false。reset 块自己的注释点名了活的对手，并只推迟了锁（"closing it takes a lock … this round deliberately does not add"）；它并没有说放弃本 PR 在相同窗口上给 restore/revert 两对加上的检测一半。给 reset 同样配上复读（注意 resetScratchTree 返回 boolean，breach 说明需要向外穿到 runScratchTree）。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| const refusal = localFilterRefusal( | ||
| worktree, | ||
| 'the rebuild this command runs', | ||
| ); |
There was a problem hiding this comment.
[Critical] R5-2 (location 4 of 4): the rebuild's worktree add is screened but has no paired post-checkout localFilterBreach re-read. Witness (probe, this site): plantLanded 18/25, hits 18 — every plant that landed in the screen→add window executed, and the report certified available: true, reused: false ("your scratch tree is at …") with no breach disclosure. See the base-tree.ts thread for the full finding; the fix here returns available: false with the breach note.
中文说明
R5-2（共 4 处，第 4 处）：rebuild 的 worktree add 有前置屏蔽，但没有配对的 checkout 后 localFilterBreach 复读。证据（探针，本站点）：plantLanded 18/25, hits 18——每个落入屏蔽→add 窗口的植入都执行了，报告仍认证 available: true, reused: false，且没有任何 breach 披露。完整发现见 base-tree.ts 评论串；此处的修复是返回带 breach 说明的 available: false。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| const filterRefusal = localFilterRefusal( | ||
| process.cwd(), | ||
| 'the review worktree add this command runs', | ||
| ); |
There was a problem hiding this comment.
[Suggestion] R5-23: This fresh-worktree add gate reuses localFilterRefusal, whose candidate set unconditionally includes every sibling linked worktree's <common>/worktrees/*/config.worktree — state a FRESH add's initial checkout cannot read (it reads system/global/<common>/config, the includeIf closure against its own new gitdir, and its own not-yet-existing config.worktree). Three sites: this one, base-tree.ts:281, and the scratch rebuild gate (scratch-tree.ts:473); the probe-creation gate is the same mechanism. Consequence: a user with extensions.worktreeConfig enabled and a worktree-local content filter in ANY linked worktree (or a plant confined to a sibling's admin dir, or an unreadable sibling config.worktree) gets every qwen review fetch refused with 'would EXECUTE filter.X.smudge' — although the guarded add provably never reads that file — until a config is manually removed that the checkout cannot read; per R3-8 the message names the key, not the carrying worktree, so the user cannot locate it. An actor who can write a sibling admin dir can also write <common>/config (same directory tree), which these gates already screen — so at fresh-add sites the sibling candidates add no protection, only the false positive. Correction verified by probe: the INVOKING tree's own config.worktree candidate IS real protection (the add reads it — a filter there fired on the add); the defect is confined to distant siblings.
Witness (probe): filter planted ONLY in a distant sibling's config.worktree — worktree add exit: 0, MARKER CREATED by add? false, yet localFilterRefusal returns non-null, asserting the checkout 'would EXECUTE' it. Comparators: a filter in <common>/config DID fire on the add; in the invoking tree's own config.worktree also fired.
Give the shared screen a per-gate candidate scope: at fresh-add gates read only <common>/config, the common-root config.worktree, and the include closure; drop the readdir of OTHER worktrees' config.worktree files the authorised checkout cannot honour.
中文说明
这个新建 worktree add 关口复用 localFilterRefusal，其候选集无条件包含每个兄弟链接工作树的 <common>/worktrees/*/config.worktree——而新建 add 的初始 checkout 读不到这些状态（它读 system/global/<common>/config、按其自身新 gitdir 求值的 includeIf 闭包、以及它自己尚不存在的 config.worktree）。共三处：此处、base-tree.ts:281、scratch rebuild 关口（scratch-tree.ts:473）；探针创建关口同一机制。后果：启用 extensions.worktreeConfig 且任一链接工作树带有工作树本地内容过滤器的用户（或只植入兄弟管理目录的植入、或不可读的兄弟 config.worktree），每次 qwen review fetch 都会被以 'would EXECUTE filter.X.smudge' 拒绝——尽管被守护的 add 可证明地从不读取该文件——直到手工移除一个 checkout 读不到的配置；按 R3-8 消息只点名键、不点名承载的工作树，用户无法定位。能写兄弟管理目录的行为者同样能写 <common>/config（同一目录树），而这些关口本就屏蔽它——所以在新建 add 站点，兄弟候选只带来误报、不带来保护。探针修正：调用树自己的 config.worktree 候选是真实保护（add 会读它——那里的过滤器在 add 上触发了）；缺陷局限于远端兄弟。证据（探针）：仅植入远端兄弟的 config.worktree——worktree add exit: 0, MARKER CREATED by add? false，而 localFilterRefusal 非空，声称 checkout 'would EXECUTE' 它。对照：<common>/config 中的过滤器在 add 上确实触发；调用树自身 config.worktree 中的也触发。修复：给共享屏蔽按关口划分候选范围：新建 add 关口只读 <common>/config、common 根的 config.worktree 与 include 闭包；去掉对其他工作树 config.worktree 的 readdir。
— qwen3.8-max via Qwen Code /review (v0.21.15)
There was a problem hiding this comment.
Deferred to the next round: batch capped at the Critical findings. Still valid — worktreeCreateFailureDetail should carry the residue note; queued with R5-22 and R5-23-2 as one residue-note sweep.
推迟到下一轮：本轮批次以 Critical 发现为上限。仍然有效——worktreeCreateFailureDetail 应携带残留物注记；与 R5-22、R5-23-2 一起作为一次残留物注记清理排队。
| const refusal = localFilterRefusal( | ||
| worktree, | ||
| 'the worktree add this command runs', | ||
| ); |
There was a problem hiding this comment.
[Suggestion] R5-23 (location 2 of 3): the base-tree worktree add gate carries the same fresh-add false-positive as the fetch-pr gate — see that thread for the full finding, witness, and fix direction (per-gate candidate scope: at fresh-add gates read only <common>/config, the common-root config.worktree, and the include closure). A worktree-local filter in any sibling worktree refuses every base-tree build although the add cannot read it.
中文说明
R5-23（共 3 处，第 2 处）：base-tree 的 worktree add 关口带有与 fetch-pr 关口相同的新建 add 误报——完整发现、证据与修复方向见该评论串（按关口划分候选范围：新建 add 关口只读 <common>/config、common 根的 config.worktree 与 include 闭包）。任一兄弟工作树中的工作树本地过滤器都会拒绝每一次 base-tree 构建，尽管 add 读不到它。
— qwen3.8-max via Qwen Code /review (v0.21.15)
There was a problem hiding this comment.
Deferred to the next round: batch capped at the Critical findings. Still valid — same residue-note gap in base-tree's build-gate failure path; queued with R5-22/R5-23.
推迟到下一轮：本轮批次以 Critical 发现为上限。仍然有效——base-tree 构建门失败路径存在同样的残留物注记缺口；与 R5-22/R5-23 一起排队。
| const refusal = localFilterRefusal( | ||
| worktree, | ||
| 'the rebuild this command runs', | ||
| ); |
There was a problem hiding this comment.
[Suggestion] R5-23 (location 3 of 3): the scratch rebuild gate is the third fresh-add site with the sibling-candidate false positive — see the fetch-pr.ts thread for the full finding and witness. The reset gate's checkout (which reads the scratch tree's OWN per-worktree config) is not affected; the rebuild's fresh worktree add is. The probe-creation gate in test-efficacy is the same mechanism (code-read).
中文说明
R5-23（共 3 处，第 3 处）：scratch rebuild 关口是第三个带有兄弟候选误报的新建 add 站点——完整发现与证据见 fetch-pr.ts 评论串。reset 关口的 checkout（读取 scratch 树自己的 per-worktree 配置）不受影响；rebuild 的新建 worktree add 受影响。test-efficacy 的探针创建关口同一机制（代码读取确认）。
— qwen3.8-max via Qwen Code /review (v0.21.15)
There was a problem hiding this comment.
Deferred to the next round: batch capped at the Critical findings. Still valid — same residue-note gap in the scratch rebuild failure path; queued with R5-22/R5-23.
推迟到下一轮：本轮批次以 Critical 发现为上限。仍然有效——scratch rebuild 失败路径存在同样的残留物注记缺口；与 R5-22/R5-23 一起排队。
| if (screen.keys.length > 0) { | ||
| parts.push( | ||
| `the repository's local config defines ` + | ||
| `${screen.keys.map(inertPath).join(', ')} — content filter ` + |
There was a problem hiding this comment.
[Suggestion] R3-8: Still standing at HEAD (re-posted under the original id). The refusal names only the offending KEYS, never the files holding them — localFilterFindingText joins screen.keys bare; only unclearable entries carry file attribution — while this same PR widened the screen to detect keys in files the implied remediation (git config --unset <key>) cannot reach: <common>/worktrees/*/config.worktree, submodule configs under <common>/modules/, and include targets anywhere. A user hitting a refusal from a key defined in a sibling worktree's config.worktree (or a module config, or an include target) is told to 'remove those config entries' without being told WHERE — the remediation as stated operates on the wrong file and the wedge persists; this compounds R5-23's false-positive wedge at fresh-add gates. The return shape changed to LocalFilterScreen { keys, unclearable } this round — that is the seam to extend: pair each key with the file that defined it, and render file: key pairs here.
中文说明
R3-8：在 HEAD 仍然成立（按原 id 重新张贴）。拒绝只点名违规的键，从不点名持有它们的文件——localFilterFindingText 裸接 screen.keys；只有 unclearable 条目带文件归属——而本 PR 又把屏蔽扩大到能检测这些文件中的键：<common>/worktrees/*/config.worktree、<common>/modules/ 下的子模块配置、以及任何位置的 include 目标——暗示的补救（git config --unset <key>）却够不到它们。用户因兄弟工作树 config.worktree（或模块配置、或 include 目标）中定义的键而遇到拒绝时，只被告知"移除这些配置条目"而不知道在哪里——照说的补救操作的是错误的文件，楔子持续；这与 R5-23 在新建 add 关口的误报楔子叠加。本轮返回形态已改为 LocalFilterScreen { keys, unclearable }——这正是可扩展的接缝：把每个键与定义它的文件配对，并在此渲染 文件: 键 对。
— qwen3.8-max via Qwen Code /review (v0.21.15)
There was a problem hiding this comment.
Deferred to the next round: batch capped at the Critical findings. Still valid — the cleanup audit should cover fetch-pr's failure paths; queued.
推迟到下一轮：本轮批次以 Critical 发现为上限。仍然有效——清理审计应覆盖 fetch-pr 的失败路径；已排队。
| }); | ||
|
|
||
| it('creates and resets the tree with a planted hook and fsmonitor inert', () => { | ||
| // NO_HOOKS covered hooks here from the start; `core.fsmonitor` is the |
There was a problem hiding this comment.
[Suggestion] R4-4: Still standing at HEAD (re-posted under the original id; deferred last round as a two-line comment rename). This comment — and the one at line 94 — still name NO_HOOKS, a constant this same PR deletes from scratch-tree.ts (replaced by INERT_GIT_ARGS in lib/worktree.ts). Sweep at HEAD: NO_HOOKS appears only in these two test comments; a maintainer grepping the old name lands on comments asserting coverage by a constant that no longer exists.
| // NO_HOOKS covered hooks here from the start; `core.fsmonitor` is the | |
| // INERT_GIT_ARGS covered hooks here from the start; `core.fsmonitor` is the |
(and the same rename at line 94)
中文说明
R4-4：在 HEAD 仍然成立（按原 id 重新张贴；上一轮作为两行注释改名被推迟）。本注释——以及第 94 行那条——仍然写着 NO_HOOKS，而本 PR 已从 scratch-tree.ts 删除该常量（由 lib/worktree.ts 的 INERT_GIT_ARGS 取代）。HEAD 扫描：NO_HOOKS 只出现在这两条测试注释中；维护者按旧名 grep 会落在声称由一个已不存在常量提供覆盖的注释上。
— qwen3.8-max via Qwen Code /review (v0.21.15)
There was a problem hiding this comment.
Deferred to the next round: batch capped at the Critical findings. Still valid — the cleanup audit should cover base-tree's build gate; queued.
推迟到下一轮：本轮批次以 Critical 发现为上限。仍然有效——清理审计应覆盖 base-tree 的构建门；已排队。
…#9566) The filter screens are point-in-time reads, and a writer the pipeline itself schedules can plant between a screen and the checkout it guards: the checkout executes the plant while both reads see nothing. Pair each guarded checkout with a breach re-read after it (base add, fetch add, scratch reset/rebuild, probe restore), reorder the scratch reset's leaf re-read below its screen and re-run the restore/revert swap reads after theirs, move the restore's re-read ahead of the clean that destroys include-target evidence, and fix the screen's own bypasses: exponential submodule-walk OOM, newline-path discovery mis-parse, and the shared include-depth budget git resets per source. Windows fixtures get forward-slash paths; the Windows reap gap is disclosed honestly.
|
🤖 Addressed the latest review feedback (round 4/100). What changed, and what I pushed back on: · 已处理最新评审反馈（第 4/100 轮）。改动内容与我反驳保留之处如下： Round summary — 13 of 14 Critical findings resolved, 1 Critical + 19 Suggestions deferredGrowth audit recorded first ( Resolved (code + witness test each; every witness verified to FAIL against the pre-round code by mutation probe)
Not resolved this round
Review Conflict notesNo base conflict ( Verification
中文说明本轮摘要 — 14 个 Critical 发现中已解决 13 个，1 个 Critical 与 19 个 Suggestion 推迟首先记录了增长审计（ 已解决（每项均有代码修复 + 见证测试；每个见证都已通过变异探针验证其在修复前代码上会失败）
本轮未解决
评审 冲突说明无 base 冲突（ 验证
Deferred non-Critical feedbackCritical-only mode is active: the PR's diff grew src 271 / test 494 net lines beyond this counting window's baseline (budgets: 400/400). The workflow excluded the non-Critical feedback below from this round's actionable sections; the items remain open for human follow-up. Maintainer feedback continues to flow unaffected during a growth-only engagement (the per-author batch budget applies only after 5 change-producing rounds). ( 中文说明已进入仅处理 Critical 的模式：本计数窗口内 diff 净增长已达 源码 271 / 测试 494 行（预算 400/400）。本轮可执行区域已排除下方非 Critical 反馈；这些条目保持开放，留待人工跟进。纯增长触发期间维护者反馈照常流动（按作者的批次预算仅在完成 5 个产生改动的轮次后生效）。（评论 Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 Re-review when you have a moment. After round 100 this bot stops and leaves the PR for a human. · 有空请复审；第 100 轮后本 bot 停止并将 PR 交给人工。 🧠 Handled by Qwen Code · model/模型 |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Partially reviewed — gaps disclosed.
Not reviewed: build-and-test — Test (windows-latest, Node 22.x) was skipped in CI and its platform-specific suites did not run locally (the Windows reap semantics and the Windows-red fixture findings R6-2/R6-11/R6-16 target are unverified on that platform).
Not reviewed: build-and-test — Test (macos-latest, Node 22.x) was skipped in CI and its platform-specific suites did not run locally.
Not explored to full depth (tool budget reached): chunk 6: running scratch-tree.test.ts under vitest — the shared review worktree has no node_modules and installing into it is invasive; the suite was verified by per….
Test Plan (not a blocker): 941 passed — this review observed 22704 passed.
Deferred under the convergence posture (round 6, not a blocker) — recorded, not requested in this round:
packages/cli/src/commands/review/scratch-tree.ts:525 (+2 locations) — [review] a throwing breach rollback lets the catch replace the breach note with a create-failure note (base-tree.ts:303 twin)packages/cli/src/commands/review/fetch-pr.ts:972 — [review] breach rollback discards releaseWorktree's verdict; a failed release leaves the breached worktree behind silentlypackages/cli/src/commands/review/fetch-pr.test.ts:624 — [probe] fixture runs real git against the un-isolated host global config with unchecked spawnSync resultspackages/cli/src/commands/review/test-efficacy.test.ts:607 — [probe] the global-filter arm's observation (findVitestBin throw) is commented but never asserted
[Critical] R6-5: the residue probe's check-ignore -z -v --stdin spawn (lib/worktree.ts ignoreSourcesOf, ~line 490) and pathspec'd ls-files -z -- <inside> spawn (trackedIgnoreSources, ~line 558) lack the -c core.fsmonitor= override their four sibling residue spawns carry. Both verbs refresh the index and fire a planted core.fsmonitor command, so the plant EXECUTES during the pipeline's own residue measurement — falsifying the INERT_GIT_ARGS guarantee this diff adds ("hooks and fsmonitor are neutralised by INERT_GIT_ARGS … the other keys never fire inside the pipeline"). The two spawn lines pre-date this PR; the claim they violate is new with it. Reachability: worktreeResidue runs on every scratch-tree call, and check-ignore fires whenever the measured tree carries ignored untracked paths — the norm for built trees (the code's own comment records 3,957 such paths on a healthy review worktree). Failure scenario: a probe makes the one-write plant (git config core.fsmonitor CMD — a key the screen deliberately does not read); any later scratch-tree call measuring a dirty tree runs both spawns without the override, and CMD executes mid-review on every shard, persisting for the whole review since nothing unsets the key. Witness (probe, git 2.43.0): MARKER AFTER check-ignore: FIRED / MARKER AFTER ls-files: FIRED against the HEAD spawns lacking the override; not fired with the -c core.fsmonitor= override. Fix: prepend '-c', 'core.fsmonitor=' (or spread INERT_GIT_ARGS) on both spawns, matching the four siblings. (Relocated here: both spawn sites sit outside this diff's hunks, so the finding cannot be anchored inline.) 中文说明：残留物探针的 check-ignore -z -v --stdin spawn（lib/worktree.ts ignoreSourcesOf，约 490 行）与带 pathspec 的 ls-files -z -- <inside> spawn（trackedIgnoreSources，约 558 行）缺少其余四个兄弟残留物 spawn 都携带的 -c core.fsmonitor= 覆盖。这两个动词都会刷新索引并触发植入的 core.fsmonitor 命令，因此植入会在流水线自己的残留物测量期间执行——证伪了本 diff 新增的 INERT_GIT_ARGS 担保（"hooks and fsmonitor are neutralised by INERT_GIT_ARGS … the other keys never fire inside the pipeline"）。这两行 spawn 早于本 PR；它们所违反的声明是本 PR 新增的。可达性：worktreeResidue 在每次 scratch-tree 调用时运行，只要被测量的树带有被忽略的未跟踪路径（构建树的常态，代码注释记录过一个健康 review 工作树上的 3,957 条）check-ignore 就会触发。失败场景：探针完成一步写入（git config core.fsmonitor CMD——屏蔽刻意不读的键）；之后任何测量脏树的 scratch-tree 调用都会不带覆盖地运行这两个 spawn，CMD 在每个 shard 的审查过程中执行，且由于没有任何地方 unset 该键而持续整个审查。证据（探针，git 2.43.0）：对 HEAD 上缺少覆盖的 spawn，MARKER AFTER check-ignore: FIRED / MARKER AFTER ls-files: FIRED；加上 -c core.fsmonitor= 覆盖后不触发。修复：在两个 spawn 上前置 '-c', 'core.fsmonitor='（或展开 INERT_GIT_ARGS），与四个兄弟保持一致。（ relocated 至此：两处 spawn 都在本 diff 的 hunk 之外，无法行内锚定。）
中文说明
仅完成部分审查，审查缺口已披露。
未审查：build-and-test — Test (windows-latest, Node 22.x) was skipped in CI and its platform-specific suites did not run locally (the Windows reap semantics and the Windows-red fixture findings R6-2/R6-11/R6-16 target are unverified on that platform)。
未审查：build-and-test — Test (macos-latest, Node 22.x) was skipped in CI and its platform-specific suites did not run locally。
未探索到全部深度（达到工具调用预算）：chunk 6：running scratch-tree.test.ts under vitest — the shared review worktree has no node_modules and installing into it is invasive; the suite was verified by per…。
Test Plan（非阻断）：941 passed — this review observed 22704 passed。
收敛姿态下延后（第 6 轮，非阻断）——已记录，本轮不要求修改：共 4 条（原文未翻译，列表见上方英文部分）。
[Critical] R6-5: the residue probe's check-ignore -z -v --stdin spawn (lib/worktree.ts ignoreSourcesOf, ~line 490) and pathspec'd ls-files -z -- <inside> spawn (trackedIgnoreSources, ~line 558) lack the -c core.fsmonitor= override their four sibling residue spawns carry. Both verbs refresh the index and fire a planted core.fsmonitor command, so the plant EXECUTES during the pipeline's own residue measurement — falsifying the INERT_GIT_ARGS guarantee this diff adds ("hooks and fsmonitor are neutralised by INERT_GIT_ARGS … the other keys never fire inside the pipeline"). The two spawn lines pre-date this PR; the claim they violate is new with it. Reachability: worktreeResidue runs on every scratch-tree call, and check-ignore fires whenever the measured tree carries ignored untracked paths — the norm for built trees (the code's own comment records 3,957 such paths on a healthy review worktree). Failure scenario: a probe makes the one-write plant (git config core.fsmonitor CMD — a key the screen deliberately does not read); any later scratch-tree call measuring a dirty tree runs both spawns without the override, and CMD executes mid-review on every shard, persisting for the whole review since nothing unsets the key. Witness (probe, git 2.43.0): MARKER AFTER check-ignore: FIRED / MARKER AFTER ls-files: FIRED against the HEAD spawns lacking the override; not fired with the -c core.fsmonitor= override. Fix: prepend '-c', 'core.fsmonitor=' (or spread INERT_GIT_ARGS) on both spawns, matching the four siblings. (Relocated here: both spawn sites sit outside this diff's hunks, so the finding cannot be anchored inline.) 中文说明：残留物探针的 check-ignore -z -v --stdin spawn（lib/worktree.ts ignoreSourcesOf，约 490 行）与带 pathspec 的 ls-files -z -- <inside> spawn（trackedIgnoreSources，约 558 行）缺少其余四个兄弟残留物 spawn 都携带的 -c core.fsmonitor= 覆盖。这两个动词都会刷新索引并触发植入的 core.fsmonitor 命令，因此植入会在流水线自己的残留物测量期间执行——证伪了本 diff 新增的 INERT_GIT_ARGS 担保（"hooks and fsmonitor are neutralised by INERT_GIT_ARGS … the other keys never fire inside the pipeline"）。这两行 spawn 早于本 PR；它们所违反的声明是本 PR 新增的。可达性：worktreeResidue 在每次 scratch-tree 调用时运行，只要被测量的树带有被忽略的未跟踪路径（构建树的常态，代码注释记录过一个健康 review 工作树上的 3,957 条）check-ignore 就会触发。失败场景：探针完成一步写入（git config core.fsmonitor CMD——屏蔽刻意不读的键）；之后任何测量脏树的 scratch-tree 调用都会不带覆盖地运行这两个 spawn，CMD 在每个 shard 的审查过程中执行，且由于没有任何地方 unset 该键而持续整个审查。证据（探针，git 2.43.0）：对 HEAD 上缺少覆盖的 spawn，MARKER AFTER check-ignore: FIRED / MARKER AFTER ls-files: FIRED；加上 -c core.fsmonitor= 覆盖后不触发。修复：在两个 spawn 上前置 '-c', 'core.fsmonitor='（或展开 INERT_GIT_ARGS），与四个兄弟保持一致。（ relocated 至此：两处 spawn 都在本 diff 的 hunk 之外，无法行内锚定。）
— qwen3.8-max via Qwen Code /review (v0.21.15)
| // post-checkout re-read below; closing the window itself takes a lock | ||
| // shared with every suite run, which this round deliberately does not | ||
| // add. |
There was a problem hiding this comment.
[Critical] R4-1 (carried over from round 5, still standing at HEAD — re-posted under the original id): the screens are one-shot config reads authorising checkouts against a concurrent writer the pipeline itself schedules (a sibling shard's suite, a toggler the reap did not reach), and nothing serialises the common dir. Round 6 closed the detection half — every guarded checkout now has its paired post-checkout localFilterBreach re-read — but the serialization half (a shared advisory lockfile held across each screen+checkout pair and around every suite spawn) is still absent: a plant landing between the screen's read and the checkout's config read still EXECUTES. This round's R6-10 probe further shows the detection half is itself evadable by a self-erasing plant, so "disclosed, not prevented" overstates what round 6 delivers.
Failure scenario: a leftover toggler writes filter.evil.smudge into the common config during the screen→checkout window this comment's own code names; the authorised checkout executes it. A persistent plant is now disclosed by the breach re-read; a self-erasing plant (R6-10) executes undetected and the run certifies clean.
Witness (round-4 probe at this site): 120 trials, 21 executions after a clean screen; advisory-lock arm fired 0/120; re-screen-only fallback fired=9. Round-6 probe: marker exists (payload EXECUTED): true / post-checkout breach re-read: null — UNDETECTED, run would be certified clean.
Fix direction: serialise the screen+checkout pairs against suite execution with a shared advisory lockfile under $(git rev-parse --git-common-dir), acquired at each guard and held around every spawn of the PR's suite.
中文说明
R4-1（自第 5 轮延续，在 HEAD 仍然成立——按原 id 重新张贴）：屏蔽是一次性的配置读取，却授权面对流水线自己调度的并发写者（兄弟 shard 的套件、回收够不到的切换器）的 checkout，而没有任何机制串行化 common 目录。第 6 轮闭合了检测一半——每个受守护的 checkout 现在都配对了 checkout 后的 localFilterBreach 复读——但串行化一半（一个在每个 屏蔽+checkout 对之间、并环绕 PR 套件每次 spawn 持有的共享咨询锁文件）仍然缺席：落在屏蔽读取与 checkout 配置读取之间的植入仍然会执行。本轮 R6-10 的探针进一步表明，检测一半本身可被自我擦除的植入绕过，因此"披露但不预防"高估了第 6 轮实际交付的内容。
失败场景：残留的切换器在这段代码自己的注释所点名的 屏蔽→checkout 窗口内把 filter.evil.smudge 写入 common 配置，被授权的 checkout 执行它。持久植入现在会被 breach 复读披露；自我擦除的植入（R6-10）则在未被检测的情况下执行，且运行被认证为干净。
证据（第 4 轮在本站点的探针）：120 次试验、干净屏蔽后 21 次执行；咨询锁臂 0/120 触发；仅重扫后备方案 fired=9。第 6 轮探针：marker exists (payload EXECUTED): true / post-checkout breach re-read: null — UNDETECTED, run would be certified clean。
修复方向：用 $(git rev-parse --git-common-dir) 下的共享咨询锁文件把 屏蔽+checkout 对与套件执行串行化——在每个守卫处获取，并环绕 PR 套件的每次 spawn 持有。
— qwen3.8-max via Qwen Code /review (v0.21.15)
There was a problem hiding this comment.
Deferred to the next round, not declined — this is the round's largest finding and the batch cap (~8 findings, Critical first) kept it out of this round so the eight implemented fixes each got a failing-then-passing test and a mutation probe. Scope of the deferral: the serialization half (a shared advisory lockfile held across each screen+checkout pair and around every suite spawn) touches every guarded site plus the suite runner, which is a larger change than the rest of this round combined. This round did narrow the window the lock must close: R6-8 paired the last unpaired checkout (the probe tree's creation) with its breach re-read, and R6-10 gave every paired re-read a baseline that catches a self-erasing plant — so the detection half no longer reads clean for the exact evasion shape this finding's probe names. The lock remains the one open half and is first in the next round's queue.
延后到下一轮处理，并非拒绝——这是本轮最大的一条发现，由于批次上限（每轮约 8 条、Critical 优先），本轮未纳入，以保证已实现的八项修复各自都有「先失败后通过」的测试和变异探针。延后范围：序列化的一半（在每个 screen+checkout 配对期间、以及每次套件 spawn 周围持有的共享咨询锁文件）会触及所有受守护的位点以及套件运行器，比本轮其余改动加起来更大。本轮确实收窄了锁需要关闭的窗口：R6-8 为最后一个未配对的 checkout（探针树的创建）补上了 breach 复读，R6-10 为每个成对复读加上了基线，能够捕获自我擦除的植入物——因此检测侧不再对本条发现的探针所指的那种规避形状报告为干净。锁仍是唯一未关闭的一半，排在下一轮队列首位。
| let v = value.trim(); | ||
| if (v.length === 0 || /^~[^/\\]/.test(v)) return null; |
There was a problem hiding this comment.
[Critical] R6-1: class-level finding — the screen hand-models how git resolves include directives, and the model diverges from the authority, so a STATIC plant (no race) screens clean and executes. Demonstrated entrances, each probe-witnessed against git 2.43: (a) quoted whitespace — path = "inc " is trimmed to a nonexistent file, screen clean, git resolves verbatim and executes; (b) %(prefix)/ interpolation unmodelled — resolved relative to the config dir and skipped, git expands to its install prefix and executes; (d) lossy utf8 decode — an include value carrying invalid bytes is mapped to U+FFFD by encoding: 'utf8', the mangled target skipped as nonexistent, git resolves the byte-exact path and executes — this same diff fails CLOSED for the identical decode in worktreeResidue ("the definition of unmeasured, not of clean"); (e) lexical .. — resolve() collapses .. without consulting the filesystem while git's kernel resolution resolves a symlinked component BEFORE applying .., so <wt>/L/../cfg beneath a symlink measures a different file than the checkout reads. Source-proven, lower-confidence entrance: (c) Windows slashless drive-relative C:inc. Rounds 1, 2, 3, 5 and 6 each found a new entrance in this surface — it is unbounded and will not converge entrance by entrance.
Failure scenario: a probe makes the documented two-write plant plus one include line (any shape above); localFilterCommands answers {keys:[], unclearable:[]}, localFilterRefusal returns null, every guarded checkout is authorised, and git's merged read executes the planted command as the reviewer. localFilterBreach shares the resolver, so the post-checkout re-reads miss it too.
Witness (probe, git 2.43): entrance (a): SCREEN {"keys":[],"unclearable":[]} with plant standing; GIT-MERGED-READ returns filter.evil.smudge; checkout created the marker; FLIP (trim removed) → refusal. Entrance (b): SCREEN-FOR-PREFIX-INTERPOLATION {"keys":[],"unclearable":[]}, raw-git checkout EXECUTED the reached filter; fix flipped to refusal. Entrance (d): screen spawn decodes inc<FF> to inc\uFFFD, existsSync false, SCREEN clean, marker exists (smudge EXECUTED): true; fail-closed-on-U+FFFD flip → refusal. Entrance (e): SCREEN {"keys":[],"unclearable":[]} vs CHECKOUT-EXECUTED-FILTER: true; kernel-resolve flip → refusal.
Fix direction: stop modelling the grammar entrance by entrance — fail closed on any include value shape the resolver cannot prove it handles identically to git (values containing U+FFFD, %(prefix), a .. segment, or a slashless drive prefix on Windows), mirroring the U+FFFD discipline this diff already applies in worktreeResidue; or let git itself resolve (e.g. read the merged config with --show-origin scoped to repo-local files).
中文说明
R6-1：类级发现——屏蔽手工建模 git 对 include 指令的解析方式，而该模型与权威（git 本身）存在偏差，因此静态植入（无需竞速）即可通过屏蔽并被执行。已实测的入口（均在 git 2.43 上用探针取证）：(a) 引号内空白——path = "inc " 被 trim 成不存在的文件，屏蔽判干净，git 却按原样解析并执行；(b) 未建模的 %(prefix)/ 插值——被相对解析到配置文件目录下并被跳过，git 却展开到其安装前缀并执行；(d) 有损 utf8 解码——携带非法字节的 include 值被 encoding: 'utf8' 映射为 U+FFFD，被破坏的目标按"不存在"跳过，git 却按字节精确路径解析并执行——同一份 diff 在 worktreeResidue 里对完全相同的解码却是失败即关闭的（"这是未测量的定义，不是干净的定义"）；(e) 词法式 ..——resolve() 不访问文件系统就折叠 ..，而 git 的内核路径解析会在应用 .. 之前先解析符号链接组件，因此符号链接之下的 <wt>/L/../cfg 测量的文件与 checkout 读取的文件并不相同。另有源码证明、置信度较低的入口：(c) Windows 无斜杠盘符相对路径 C:inc。第 1、2、3、5、6 轮每一轮都在这个面上找到新入口——它是无界的，逐个封堵不会收敛。
失败场景：探针完成文档所述的两步写入外加一行 include（上述任一形态）；localFilterCommands 返回 {keys:[], unclearable:[]}，localFilterRefusal 返回 null，每个受守护的 checkout 都被放行，git 的合并读取以审查者身份执行植入的命令。localFilterBreach 共享同一解析器，因此 checkout 后的复读同样看不见它。
证据（探针，git 2.43）：入口 (a)：植入在场时 SCREEN {"keys":[],"unclearable":[]}；GIT-MERGED-READ 返回 filter.evil.smudge；checkout 创建了标记文件；翻转（去掉 trim）→ 拒绝。入口 (b)：SCREEN-FOR-PREFIX-INTERPOLATION {"keys":[],"unclearable":[]}，裸 git 的 checkout 执行了可达的过滤器；修复后翻转为拒绝。入口 (d)：屏蔽 spawn 把 inc<FF> 解码为 inc\uFFFD，existsSync 为 false，屏蔽判干净，marker exists (smudge EXECUTED): true；按 U+FFFD 失败即关闭的翻转 → 拒绝。入口 (e)：SCREEN {"keys":[],"unclearable":[]} 对比 CHECKOUT-EXECUTED-FILTER: true；按内核解析翻转 → 拒绝。
修复方向：停止逐入口建模——对任何无法证明与 git 处理完全一致的 include 值形态失败即关闭（含 U+FFFD、%(prefix)、.. 段，或 Windows 上无斜杠盘符前缀的值），与本 diff 已在 worktreeResidue 中应用的 U+FFFD 纪律保持一致；或者让 git 自己解析（例如以 --show-origin 读取合并配置并限定在仓库本地文件范围）。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| expect(existsSync(join(markerDir, 'fsm'))).toBe(false); | ||
| }); | ||
|
|
||
| it("reaps the suite's process group, so nothing it spawned outlives the run", async () => { |
There was a problem hiding this comment.
[Critical] R6-2: this reap test asserts the suite's lingering descendant is DEAD after the run, but the reap it tests — killProcessGroup(r.pid) post-mortem in test-efficacy.ts — is a guaranteed no-op on Windows per the implementation's OWN comment: taskkill walks the tree of a LIVE pid, spawnSync returns only after the suite root exits, the catch swallows the error, and every descendant survives there. The test carries no platform gate (the same file gates another test with it.skipIf(win32) at line 1146), ci.yml's test_windows merge_group job runs npm run test:ci, and packages/cli's vitest config collects *.integration.test.ts — so the Windows merge gate is red when this PR enters the merge queue.
Failure scenario: on the Windows merge gate the 60-second lingerer survives the inert reap, process.kill(pid, 0) does not throw, expect(...).toThrow() fails, and test_windows is red.
Witness: not run — no Windows runner in this environment; settled by the conjunction of four facts quoted from HEAD: (a) the test is a plain it(...), no skipIf; (b) the reap comment: "the reap errors on the dead pid, the catch swallows it, and every descendant survives there … the Windows fix this round does not add"; (c) ci.yml test_windows (merge_group) runs npm run test:ci; (d) the vitest include glob collects this file. Node's spawnSync-returns-after-child-exit semantics are deterministic.
| it("reaps the suite's process group, so nothing it spawned outlives the run", async () => { | |
| it.skipIf(process.platform === 'win32')("reaps the suite's process group, so nothing it spawned outlives the run", async () => { |
Or implement the Windows half the comment defers — a Job Object assigned at spawn, or a descendant walk while the root is still alive — and keep the gate.
中文说明
R6-2：这个回收测试断言套件残留的子孙进程在运行结束后已死亡，但它所测试的回收——test-efficacy.ts 中事后执行的 killProcessGroup(r.pid)——按实现自己的注释在 Windows 上必然无效：taskkill 只能遍历活着的 pid 的进程树，spawnSync 只在套件根退出后才返回，catch 吞掉错误，每一个子孙都存活。该测试没有任何平台门（同一文件在 1146 行用 it.skipIf(win32) 给另一个测试加了门），ci.yml 的 test_windows merge_group 作业运行 npm run test:ci，而 packages/cli 的 vitest 配置会收集 *.integration.test.ts——因此本 PR 进入合并队列时 Windows 合并关口是红的。
失败场景：在 Windows 合并关口上，60 秒的残留进程在无效的回收后存活，process.kill(pid, 0) 不抛异常，expect(...).toThrow() 失败，test_windows 变红。
证据：未运行——本环境无 Windows runner；由引自 HEAD 的四个事实的合取判定：(a) 该测试是普通 it(...)，无 skipIf；(b) 回收注释："the reap errors on the dead pid, the catch swallows it, and every descendant survives there … the Windows fix this round does not add"；(c) ci.yml test_windows（merge_group）运行 npm run test:ci；(d) vitest 的 include 通配会收集本文件。Node 的 spawnSync 在子进程退出后才返回是确定性语义。
修复：按上方 suggestion 加平台门，或实现注释所推迟的 Windows 一半——spawn 时指派 Job Object，或在根进程存活时遍历子孙——并保留该测试。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| const relinkedDuringScreen = probeTreeRelinked(probeTree, commonDir); | ||
| if (relinkedDuringScreen !== null) return relinkedDuringScreen; |
There was a problem hiding this comment.
[Critical] R6-7: class-level finding — the post-screen re-checks added by this diff re-run only the SYMLINK form of a swap (probeTreeRelinked's leaf lstat + ancestor walk; probeTargetEscapes' root lstat), never the repository-identity gate the same function ran BEFORE the screen (toplevel/common-dir/git-dir comparison, admin gitdir backpointer round-trip), and probeTreeRelinked's ancestor walk is gated on .git being a FILE — a state read through the suspect path. Shapes, all against the shared review worktree or the probe verdicts: (a) a .git gitfile rewritten during the screen's spawns — the checkout writes the swapped repo's content while every remaining check passes (live-reproduced; an identity re-read after the screen flipped it to refusal); (b) a PRE-PLANTED standalone .git directory (rm .git && git init && commit — no timing window) skips the ancestor walk via the isFile gate and every identity re-check, so every restore materialises the attacker's commit and all baseline/mutant/revert verdicts score against attacker content; (c) the revert phase's root-only check (~2996) — a RENAME of the probe path (or an ancestor symlink) between the last suite run and the revert checkout redirects the revert checkout, the safeRmWithin deletes, and the phase's final discardWorktree rm -rf's the shared review worktree while every check in the phase passes; (d) the scratch reset's gate→checkout window, where the breach re-read is anchored at the screening (review) worktree and is blind to a redirected checkout. The restore's identity gate has no counterpart anywhere in the revert phase; scratch-tree's reset HAS exactly the common-dir comparison restore lacks.
Failure scenario: an escapee the reap cannot reach (or a pre-plant needing no window at all) swaps/renames/relinks as above; the screen, the post-screen re-check, the breach re-read and the bits check all resolve self-consistently through the swap — the diff's own comment concedes "the breach re-read and the bits check both resolve through the swap and answer clean" — and the run damages or scores against attacker-chosen content while certified pristine.
Witness (probe): SHAPE-B-RESTORED-CONTENT: "export const evil = 1;\n" (pre-planted standalone repo, no window — attacker's commit materialised); SHAPE-A-RESTORED-CONTENT: "SWAPPED-REPO-CONTENT;\n" (gitfile rewritten during the screen); FLIP (fresh identity re-read after the screen): refusal "admin entry does not point back at it" and restored PR content.
Fix direction: after the screen, re-run the IDENTITY gate, not just the symlink reads — fresh rev-parse --show-toplevel/--git-common-dir/--git-dir compared against the pre-screen strings plus the admin backpointer round-trip, refusing on any change; give the revert phase the same guard; fail closed in restoreProbeTreeTracked when .git is not a plain file (the pipeline always creates probe trees via worktree add).
中文说明
R6-7：类级发现——本 diff 新增的屏蔽后复查只重跑了符号链接形态的交换（probeTreeRelinked 的叶子 lstat + 祖先走查；probeTargetEscapes 的根 lstat），从不重跑同一函数在屏蔽之前运行过的仓库身份门（toplevel/common-dir/git-dir 比较、admin gitdir 回指往返），而且 probeTreeRelinked 的祖先走查以 .git 是文件为门——这是透过被怀疑路径本身读取的状态。各形态（均针对共享 review 工作树或探针裁决）：(a) 屏蔽 spawn 期间改写 .git gitfile——checkout 写入被换仓库的内容而其余所有检查都通过（已实测复现；屏蔽后补一次身份复读即翻转为拒绝）；(b) 预植的独立 .git 目录（rm .git && git init && commit——无需任何时序窗口）经 isFile 门跳过祖先走查、跳过所有身份复查，于是每次恢复都物化攻击者的提交，全部 baseline/mutant/revert 裁决都按攻击者内容打分；(c) revert 阶段仅查根（~2996）——在最后一次套件运行与 revert checkout 之间对探针路径做重命名（或放置祖先符号链接），即可重定向 revert checkout，safeRmWithin 随之删除，阶段末尾的 discardWorktree 把共享 review 工作树整个 rm -rf，而阶段内每个检查都通过；(d) scratch reset 的 门→checkout 窗口——breach 复读锚定在屏蔽所在的（review）工作树上，对被重定向的 checkout 视而不见。restore 的身份门在 revert 阶段没有任何对应物；而 scratch-tree 的 reset 恰恰拥有 restore 所缺的那个 common-dir 比较。
失败场景：回收够不到的逃脱者（或完全不需要窗口的预植）按上述方式交换/重命名/重链接；屏蔽、屏蔽后复查、breach 复读、位检查全部透过交换自洽地解析——diff 自己的注释也承认"the breach re-read and the bits check both resolve through the swap and answer clean"——运行在损坏或按攻击者内容打分的同时被认证为完好。
证据（探针）：SHAPE-B-RESTORED-CONTENT: "export const evil = 1;\n"（预植独立仓库、无窗口——攻击者的提交被物化）；SHAPE-A-RESTORED-CONTENT: "SWAPPED-REPO-CONTENT;\n"（屏蔽期间改写 gitfile）；翻转（屏蔽后补身份复读）：拒绝"admin entry does not point back at it"，且恢复出 PR 内容。
修复方向：屏蔽之后重跑身份门，而不仅是符号链接读取——重新 rev-parse --show-toplevel/--git-common-dir/--git-dir 并与屏蔽前的字符串比较，外加 admin 回指往返，任何变化即拒绝；给 revert 阶段同样的守卫；在 restoreProbeTreeTracked 中当 .git 不是普通文件时失败即关闭（流水线总是通过 worktree add 创建探针树）。
— qwen3.8-max via Qwen Code /review (v0.21.15)
There was a problem hiding this comment.
Deferred to the next round, not declined — the batch cap (~8 findings, Critical first) kept this class-level finding out of this round so the eight implemented fixes each got full failing-then-passing and mutation-probe verification. It stays in scope and is queued for the next round. One dependency worth naming: shape (a) of this finding (a .git gitfile rewritten during the screen) is now partially covered by R6-9 in this round — a rewritten-to-nowhere gitfile makes discovery fail, and the screen now fails CLOSED on discovery failure instead of answering "proceed" — but the full fix (re-running the identity gate after the screen and failing closed on a non-file .git) is the next round's work.
延后到下一轮处理，并非拒绝——批次上限（每轮约 8 条、Critical 优先）使这条类级发现未纳入本轮，以保证已实现的八项修复各自都完整经过「先失败后通过」与变异探针验证。它仍在范围内，已排入下一轮队列。值得说明一个依赖关系：本条发现的形状 (a)（screen 期间被改写的 .git gitfile）现已被本轮的 R6-9 部分覆盖——被改写到不存在位置的 gitfile 会让 discovery 失败，而 screen 现在对 discovery 失败是失败关闭（fail closed），而不是回答「继续」——但完整修复（在 screen 之后重新运行身份门、并对非常规文件的 .git 失败关闭）是下一轮的工作。
| git(worktree, 'worktree', 'add', '--detach', probeTree, headSha); | ||
| created = true; |
There was a problem hiding this comment.
[Critical] R6-8: the probe tree's creation git worktree add (guarded by the phase-entry screen at ~2638) has NO paired post-checkout localFilterBreach re-read — the only guarded checkout without one, contradicting this commit's own title ("pair every guarded checkout with a post-checkout re-read"). All six sibling pairs carry it: base add (base-tree.ts:282/296), fetch add (fetch-pr.ts:928/965), scratch reset (271/287), scratch rebuild (500/523), restore (1622/1672), revert (2989/3005).
Failure scenario: a transient toggler of the class this PR measured live (~3% of trials, named in the reap comment) plants filter.<name>.smudge between the entry screen's last read (2638) and the add's own config read; the initial checkout EXECUTES it; the toggler removes the key before the first restore's screen (2746), the next config read that could see it — the phase certifies healthy with no breach note anywhere.
Witness (probe, end to end at HEAD): R68-ARMED-MARKER: true (armer executed during the probe add's initial checkout); R68-UNPLANTED-MARKER: true (removed before the first restore's screen); R68-OUT-MENTIONS-BREACH: false; R68-OUT-PROBED: [{"verdict":"inert",…}] — certified healthy. Contrast: the PR's own base-tree breach test catches the identical arming shape where the pairing exists.
| git(worktree, 'worktree', 'add', '--detach', probeTree, headSha); | |
| created = true; | |
| git(worktree, 'worktree', 'add', '--detach', probeTree, headSha); | |
| created = true; | |
| const breach = localFilterBreach(worktree, "the probe tree's creation"); | |
| if (breach !== null) { | |
| discardWorktree(worktree, probeTree); | |
| createDetail = breach; | |
| created = false; | |
| } |
中文说明
R6-8：探针树创建时的 git worktree add（由 ~2638 的阶段入口屏蔽守护）没有配对的 checkout 后 localFilterBreach 复读——这是唯一没有配对的受守护 checkout，与本提交自己的标题（"pair every guarded checkout with a post-checkout re-read"）矛盾。其余六对都有：base add（base-tree.ts:282/296）、fetch add（fetch-pr.ts:928/965）、scratch reset（271/287）、scratch rebuild（500/523）、restore（1622/1672）、revert（2989/3005）。
失败场景：本 PR 实测过的类别（每次试验约 3%，回收注释点名）的瞬时切换器在入口屏蔽的最后一次读取（2638）与 add 自身的配置读取之间植入 filter.<name>.smudge；初始 checkout 执行它；切换器在第一次 restore 的屏蔽（2746，下一个能看见它的配置读取）之前移除该键——阶段被认证为健康，任何地方都没有 breach 注记。
证据（探针，在 HEAD 上端到端）：R68-ARMED-MARKER: true（armer 在探针 add 的初始 checkout 期间执行）；R68-UNPLANTED-MARKER: true（在第一次 restore 的屏蔽前移除）；R68-OUT-MENTIONS-BREACH: false；R68-OUT-PROBED: [{"verdict":"inert",…}]——认证为健康。对照：PR 自己的 base-tree breach 测试在配对存在的站点能抓住完全相同的武装形态。
修复：按上方 suggestion 在 add 成功后补上配对复读（镜像 base-tree.ts 的形态）。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| const commonDir = discover('--git-common-dir'); | ||
| const gitDir = discover('--git-dir'); | ||
| if (commonDir === null || gitDir === null) return screen; |
There was a problem hiding this comment.
[Critical] R6-9: the screen fails OPEN on discovery failure. When discover('--git-common-dir') or discover('--git-dir') returns null (any rev-parse error), localFilterCommands returns an EMPTY screen and both localFilterRefusal and localFilterBreach answer null — "proceed" — from a screen whose contract is fail-closed everywhere else ("a file the screen cannot clear cannot be vouched for").
Failure scenario, two triggers: (a) a toggler swaps the screened tree's .git pointer while the screen's two rev-parse spawns run and restores it before the guarded checkout — the scratch reset screens the REVIEW worktree but checks out in the SCRATCH tree, so the swap cannot break the checkout; the paired breach re-read is blinded identically (its first act is the same rev-parse), so a transient plant executes unreported; (b) a transient spawn failure (EMFILE/EAGAIN induced by a concurrent suite) yields r.error → null → clean screen on every guard.
Witness (probe at HEAD): SCREEN-BASELINE {"keys":["filter.evil.smudge"],"unclearable":[]}; REV-PARSE-STATUS-WITH-SWAP: 128; SCREEN-WHILE-DISCOVERY-FAILS: {"keys":[],"unclearable":[]} — clean with the plant standing; REFUSAL-WHILE-DISCOVERY-FAILS: null — the guarded checkout proceeds; SCREEN-AFTER-RESTORE names the plant again (control). FLIP (discovery failure → unclearable): refusal "repository discovery failed … no checkout in this pipeline is safe to run".
| const commonDir = discover('--git-common-dir'); | |
| const gitDir = discover('--git-dir'); | |
| if (commonDir === null || gitDir === null) return screen; | |
| const commonDir = discover('--git-common-dir'); | |
| const gitDir = discover('--git-dir'); | |
| if (commonDir === null || gitDir === null) { | |
| screen.unclearable.push( | |
| `${worktree}: cannot resolve the repository's common dir`, | |
| ); | |
| return screen; | |
| } |
中文说明
R6-9：屏蔽在发现（discovery）失败时失败即敞开。当 discover('--git-common-dir') 或 discover('--git-dir') 返回 null（任何 rev-parse 错误）时，localFilterCommands 返回空屏蔽，localFilterRefusal 与 localFilterBreach 双双返回 null——"放行"——而这个屏蔽在其他任何地方的契约都是失败即关闭（"屏蔽无法清空的文件不能被担保"）。
失败场景，两个触发：(a) 切换器在屏蔽的两次 rev-parse spawn 运行期间换掉被屏蔽树的 .git 指针，并在受守护的 checkout 之前复原——scratch reset 屏蔽的是 REVIEW 工作树，checkout 却跑在 SCRATCH 树里，因此交换不会破坏 checkout 本身；配对的 breach 复读以同样方式失明（它的第一步是同一次 rev-parse），于是瞬时植入在无人报告的情况下执行；(b) 瞬时 spawn 失败（并发套件诱发的 EMFILE/EAGAIN）产生 r.error → null → 每个守卫都得到干净屏蔽。
证据（在 HEAD 上的探针）：SCREEN-BASELINE {"keys":["filter.evil.smudge"],"unclearable":[]}；REV-PARSE-STATUS-WITH-SWAP: 128；SCREEN-WHILE-DISCOVERY-FAILS: {"keys":[],"unclearable":[]}——植入仍在场却判干净；REFUSAL-WHILE-DISCOVERY-FAILS: null——受守护的 checkout 放行；SCREEN-AFTER-RESTORE 再次点名植入（对照）。翻转（发现失败 → unclearable）：拒绝"repository discovery failed … no checkout in this pipeline is safe to run"。
修复：按上方 suggestion，把发现失败推入 unclearable 并返回，使其按拒绝处理。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| // A key that APPEARED is reported as a breach and the just-added | ||
| // tree rolled back: the run must be reported breached, never | ||
| // certified clean with a planted checkout behind it. | ||
| const breach = localFilterBreach( |
There was a problem hiding this comment.
[Critical] R6-10: the paired post-checkout breach re-read holds NO baseline — localFilterBreach is a fresh point read reporting only keys present at re-read time. A plant that removes its own key as part of the executed command (e.g. filter.evil.smudge = <payload>; git config --unset filter.evil.smudge), or a toggler that unplants the instant the smudge fires, EXECUTES and then reads clean: the unset lands in the common config before the re-read starts (the re-read begins only after the guarded spawn returns), so no timing skill beyond the known screen→checkout window (R4-1) is needed. The comment above this hunk guarantees "never certified clean with a planted checkout behind it" — the probe disproves it for exactly the concurrent writer it names. The class spans every paired re-read this PR adds (fetch-pr.ts ~965, scratch-tree.ts ~287/~523, test-efficacy.ts ~1672/~3005). Bounding: a PERSISTENT plant is caught.
Failure scenario: a malicious PR commits .gitattributes selecting *.txt filter=evil; a leftover toggler plants the self-unsetting smudge in the common config during the screen→add window; the add's initial checkout runs the payload and the unset lands before the re-read starts; localFilterBreach returns null; buildBaseTree proceeds and returns available: true — executed, undisclosed, certified clean.
Witness (probe): A1 pre-read refusal: null (clean); A4 marker exists (payload EXECUTED): true; A5 key still defined after the add: false; A6 post-checkout breach re-read: null — UNDETECTED, run would be certified clean. Bounding arm (persistent plant): B3 post-checkout breach re-read caught it: true.
Fix direction: track the candidate FILES across the pair, not just the key set — snapshot mtime+size/content-hash of every screened file at refusal time and treat ANY change at re-read (including one that restores the original content) as a breach. The advisory lock R4-1 names closes both this and the planting window itself.
中文说明
R6-10：配对的 checkout 后 breach 复读不持有任何基线——localFilterBreach 是一次全新的时间点读取，只报告复读时刻在场的键。把移除自身键作为执行命令一部分的植入（例如 filter.evil.smudge = <payload>; git config --unset filter.evil.smudge），或在 smudge 触发瞬间撤除的切换器，会先执行、再读到干净：unset 在复读开始之前就已落入 common 配置（复读只在受守护的 spawn 返回之后才开始），因此除了已知的 屏蔽→checkout 窗口（R4-1）之外不需要任何时序技巧。本块上方的注释担保"never certified clean with a planted checkout behind it"——探针对它点名的那个并发写者证伪了这句担保。该类覆盖本 PR 新增的每一处配对复读（fetch-pr.ts ~965、scratch-tree.ts ~287/~523、test-efficacy.ts ~1672/~3005）。边界：持久植入能被抓到。
失败场景：恶意 PR 提交选中 *.txt filter=evil 的 .gitattributes；残留切换器在 屏蔽→add 窗口内把自我 unset 的 smudge 植入 common 配置；add 的初始 checkout 执行载荷，且 unset 先于复读开始落盘；localFilterBreach 返回 null；buildBaseTree 继续并返回 available: true——已执行、未披露、认证为干净。
证据（探针）：A1 pre-read refusal: null (clean)；A4 marker exists (payload EXECUTED): true；A5 key still defined after the add: false；A6 post-checkout breach re-read: null — UNDETECTED, run would be certified clean。边界臂（持久植入）：B3 post-checkout breach re-read caught it: true。
修复方向：跨对跟踪候选文件本身，而不仅是键集合——在拒绝时刻对每个被屏蔽文件快照 mtime+大小/内容哈希，复读时任何变化（包括恢复原内容的变化）都视为 breach。R4-1 所点名的咨询锁能同时闭合本问题与植入窗口本身。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| gitRepo( | ||
| 'config', | ||
| 'include.path', | ||
| `~${userInfo().username}/qwen-never-resolved`, | ||
| ); |
There was a problem hiding this comment.
[Critical] R6-11: this 'fails closed on an include target it cannot resolve' test plants include.path = ~<real username>/… and is NOT Windows-gated, but its design depends on git successfully expanding ~<real user> via getpwnam. Git for Windows' compat layer defines getpwnam as a stub returning NULL for EVERY name, so the include is unexpandable for every user there — and an unexpandable include makes every git read of that config fatal (live-reproduced on git 2.43 with the same unexpandable class: rev-parse exits 128, "could not expand include path"). The screen's opening discover() spawns then return null and — per the fail-open at worktree.ts:699 (R6-9) — localFilterCommands returns the EMPTY screen, so expect(got.keys).toEqual(['include.path']) receives [] and the test is red on ci.yml's merge_group test_windows job. Sibling fixtures in this file are gated it.skipIf(win32); this one is not. Same class as R6-2 (red Windows merge gate), different test and mechanism.
Witness (probe, git 2.43; Linux legs run, Windows leg witness-by-conjunction): rev-parse exit=128 — error: could not expand include path '~no-such-user-xyz/q' / fatal: bad config line (screen's exact argv, poisoned arm) vs real-user arm exit 0 with the record returned verbatim (test green at HEAD on POSIX); discover() turns that 128 into the empty screen at HEAD; test_windows runs npm run test:ci which collects this file; git's mingw getpwnam stub returns NULL for every name.
| gitRepo( | |
| 'config', | |
| 'include.path', | |
| `~${userInfo().username}/qwen-never-resolved`, | |
| ); | |
| it.skipIf(process.platform === 'win32')( | |
| 'fails closed on an include target it cannot resolve', | |
| () => { |
(or rework the fixture to an unresolvable-but-parseable form that is platform-neutral — and note that on Windows the plant dies in discovery rather than reaching the screen, which is R6-9's fail-open answering).
中文说明
R6-11：这个"对无法解析的 include 目标失败即关闭"的测试植入 include.path = ~<真实用户名>/…，却没有 Windows 平台门，而它的设计依赖 git 通过 getpwnam 成功展开 ~<真实用户>。Git for Windows 的兼容层把 getpwnam 定义为对任何名字都返回 NULL 的桩，因此在那里该 include 对每个用户都不可展开——而不可展开的 include 会让对该配置的每一次 git 读取都致命（已在 git 2.43 上用同一不可展开类别实测复现：rev-parse 退出 128，"could not expand include path"）。屏蔽开头的 discover() spawn 于是返回 null，并按 worktree.ts:699 的失败即敞开（R6-9）使 localFilterCommands 返回空屏蔽，于是 expect(got.keys).toEqual(['include.path']) 得到 []，该测试在 ci.yml 的 merge_group test_windows 作业上变红。同文件的兄弟夹具都有 it.skipIf(win32) 门；这个没有。与 R6-2 同类（Windows 合并关口变红），但测试与机制不同。
证据（探针，git 2.43；Linux 部分已运行，Windows 部分为合取证据）：rev-parse exit=128 — error: could not expand include path '~no-such-user-xyz/q' / fatal: bad config line（屏蔽的原样 argv，投毒臂）对比真实用户臂 exit 0 且记录原样返回（POSIX 上 HEAD 处测试为绿）；discover() 在 HEAD 处把该 128 变成空屏蔽；test_windows 运行的 npm run test:ci 会收集本文件；git 的 mingw getpwnam 桩对任何名字都返回 NULL。
修复：按上方 suggestion 加平台门（或把夹具改成平台无关的"不可解析但可解析语法"形态——并注意在 Windows 上植入死于发现阶段而非到达屏蔽，那是 R6-9 失败即敞开在应答）。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| `cat > /dev/null; git config include.path ${evil}; ` + | ||
| `printf '[filter "evil"]\\n\\tsmudge = true\\n' > ${evil}; echo`, |
There was a problem hiding this comment.
[Critical] R6-16: this 'reports the restore breached when the plant is an INCLUDE the clean removes' fixture interpolates a raw tmpdir() path into a filter command git executes through a POSIX shell. On Windows the backslash path is shell-mangled (sh's lexer consumes unquoted backslashes — verified: sh -c 'echo C:\Users\x' prints C:Usersx), so the smudge stores a slashless drive-relative include.path value and its printf > redirect lands at a different mangled name; path.win32.isAbsolute('C:Users…') is false, so resolveIncludeTarget joins it under the fixture's .git/ directory, existsSync fails, scan() silently skips it, the breach never fires, and both assertions fail — red on the merge_group test_windows gate. The same file gates a Windows-sensitive test with it.skipIf(win32) at ~890; this one is ungated. The breach path itself is sound on Linux; only the fixture's shell encoding of the path is platform-wrong.
Witness (probe): sh -c 'echo C:\Users\x' → C:Usersx; path.win32.isAbsolute("C:UsersRUNNER~1…") = false; path.win32.join("C:\\repo\\.git","C:UsersRUNNER~1evil.txt") = "C:\repo\.git\C:UsersRUNNER~1evil.txt"; fixture ungated at :676; test_windows runs npm run test:ci (ci.yml:990); PR CI at HEAD: ubuntu Test pass / windows Test skipping (merge_group-only) — the Windows leg is witness-by-conjunction.
Fix: gate the test it.skipIf(process.platform === 'win32'), or make the command Windows-safe: const evilSh = evil.replaceAll('\\', '/'); then git config include.path '${evilSh}' and printf … > '${evilSh}'.
中文说明
R6-16：这个"当植入是被 clean 删除的 INCLUDE 时报告 restore 被穿透"的夹具把裸 tmpdir() 路径插值进一个由 git 通过 POSIX shell 执行的过滤器命令。在 Windows 上反斜杠路径会被 shell 破坏（sh 的词法器吞掉未加引号反斜杠——已验证：sh -c 'echo C:\Users\x' 输出 C:Usersx），于是 smudge 存下无斜杠的盘符相对 include.path 值，其 printf > 重定向落在另一个被破坏的名字上；path.win32.isAbsolute('C:Users…') 为 false，resolveIncludeTarget 把它拼到夹具的 .git/ 目录下，existsSync 失败，scan() 静默跳过，breach 永不触发，两个断言都失败——在 merge_group 的 test_windows 关口变红。同文件在 ~890 行用 it.skipIf(win32) 给一个 Windows 敏感测试加了门；这个没有。breach 路径本身在 Linux 上是健全的；只有夹具对路径的 shell 编码是平台错误的。
证据（探针）：sh -c 'echo C:\Users\x' → C:Usersx；path.win32.isAbsolute("C:UsersRUNNER~1…") = false；path.win32.join("C:\\repo\\.git","C:UsersRUNNER~1evil.txt") = "C:\repo\.git\C:UsersRUNNER~1evil.txt"；夹具在 :676 无门；test_windows 运行 npm run test:ci（ci.yml:990）；HEAD 处 PR CI：ubuntu Test 通过 / windows Test 跳过（仅 merge_group）——Windows 部分为合取证据。
修复：给测试加 it.skipIf(process.platform === 'win32') 门，或把命令改成 Windows 安全：const evilSh = evil.replaceAll('\\', '/'); 然后 git config include.path '${evilSh}' 与 printf … > '${evilSh}'。
— qwen3.8-max via Qwen Code /review (v0.21.15)
|
🤖 Addressed the latest review feedback (round 1/100). What changed, and what I pushed back on: · 已处理最新评审反馈（第 1/100 轮）。改动内容与我反驳保留之处如下： Autofix round summary — PR #9566 (round 7)Commit: Round 6 posted 10 Critical findings (9 inline + 1 in the review body). This round implements 8 — the batch cap, Critical-first — and defers the 2 largest (the advisory lock R4-1, the class-level identity re-check R6-7) to the next round with replies on their threads. No conflict resolution was needed ( Feedback dispositions
How each fix was verified before implementingEvery code-level claim was reproduced on HEAD first (source-blind verification):
The three Windows-gate findings (R6-2, R6-11, R6-16) are platform-specific: their defect is "red on the Windows merge gate", which cannot be reproduced on this Linux runner. Their fixes are the exact shapes the findings prescribed, verified by code inspection against the cited platform behavior; their changed tests pass pre-round here by construction. Verification
Environment-specific check not available on this runner: the Windows merge gate itself ( 中文说明Autofix 轮次总结 — PR #9566（第 7 轮）提交： 第 6 轮评审共提出 10 条 Critical 发现（9 条行内 + 1 条在评审正文中）。本轮实现了其中 8 条——按批次上限（Critical 优先）——并将最大的 2 条（咨询锁 R4-1、类级身份复查 R6-7）延后到下一轮，并在各自的主题串上回复。无需解决冲突（ 反馈处理结果
实现前对每项修复的验证方式每条代码级断言都先在 HEAD 上复现（来源无关验证）：
三条 Windows 门控发现（R6-2、R6-11、R6-16）是平台特定的：其缺陷是「在 Windows 合并门禁上变红」，无法在本 Linux 运行器上复现。其修复正是发现所规定的形状，通过对照所引用的平台行为做代码检查来验证；它们改动的测试在本运行器上按构造在轮前即为通过。 验证
本运行器上不可用的环境特定检查：Windows 合并门禁用例（ Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 Re-review when you have a moment. After round 100 this bot stops and leaves the PR for a human. · 有空请复审；第 100 轮后本 bot 停止并将 PR 交给人工。 🧠 Handled by Qwen Code · model/模型 |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Partially reviewed — gaps disclosed.
5 Suggestion-level finding(s) this review confirmed are already reported on this PR and are not repeated:
- DUP-1 throwing breach-rollback swaps the note (scratch-tree.ts:543 + base-tree.ts:303 twin) — already reported in round 6's deferral list (review 4993521106)
- breach rollback discards releaseWorktree's verdict (fetch-pr.ts:976) — already reported in round 6's deferral list (review 4993521106)
- discover rev-parse spawns carry no timeout — already reported as R5-16 (comment 3827907234)
- relative include-target resolution and the
~/arm unpinned — already reported as R5-10 (comment 3827907211) - GIT_TIMEOUT_MS duplicate constant unpinned (worktree.ts:49) — already reported as R5-17 (comment 3827907237)
Not reviewed: build-and-test — Test (windows-latest, Node 22.x) and Test (macos-latest, Node 22.x) were skipped in CI and their platform-specific suites did not run locally (the Windows-gated test fixes R6-2/R6-11/R6-16 and the win32 resolver branches named in D7-2 are unverified on those platforms).
Not explored to full depth (tool budget reached): chunk 3: live vitest run of the new test file (review worktree has no node_modules; npm ci + build exceeds the tool budget).
Not reviewed: reverse audit — an auditor ran and opened its brief, but no agent was launched with the prompt the CLI built — the launch was written by hand, and what the agent was actually asked is not what this skill certifies.
Deferred under the convergence posture (round 7, not a blocker) — recorded, not requested in this round:
packages/cli/src/commands/review/scratch-tree.test.ts:37 (+3 locations) — [review] three vi.mock seams drop localFilterRefusal's capture argument; baseline-plumbing regressions ship greenpackages/cli/src/commands/review/lib/worktree.ts:705 — [review] the two Windows-only fail-closed branches of resolveIncludeTarget have no pinning testpackages/cli/src/commands/review/lib/worktree.test.ts:115 — [review] fsmonitor fixture's git add -A commits the nested worktree as an embedded gitlink; the clean verdict rides on the absent-gitlink branchpackages/cli/src/commands/review/lib/worktree.ts:49 — [review] residue probe spawns carry no timeout; a planted FIFO at .gitignore/info-exclude wedges the pipeline indefinitelypackages/cli/src/commands/review/lib/worktree.test.ts:2042 — [review] newline-path fixture cannot distinguish trim() from replace(/\n$/) — the recorded regression ships greenpackages/cli/src/commands/review/test-efficacy.ts:1645 (+3 locations) — [review] runRestore checkout spawns and the local git()/gitOut() helpers carry no timeout; a blocking smudge wedges the guarded checkoutspackages/cli/src/commands/review/fetch-pr.test.ts:609 — [review] no fetch-pr breach test drives the changed-file half; captured.baseline wiring mutants ship green (148/148)
[Critical] R7-5: runOneHunkProbe's git apply --reverse (test-efficacy.ts:2135, a spawn line that pre-dates this diff's hunks — hence body, not inline) is a filter-executing git verb with no localFilterRefusal before it and no paired localFilterBreach after it — the one live filter-executing verb of the probe phase the screen/pair machinery this PR adds everywhere else does not cover, while the docstring claim this diff adds ("Every checkout this pipeline runs executes these …") and the new test titled "content-filter screens cover every checkout the probe phase runs" read as complete. Witness (raw git 2.43 fixture, *.txt filter=evil): git diff: clean=YES smudge=no / git apply --reverse: clean=YES smudge=YES / git apply (forward): clean=YES smudge=YES — apply executes BOTH clean and smudge, and is also where the deliberately-included filter.*.clean key becomes live. Failure scenario: a toggler the reap cannot reach plants filter.evil.smudge + attributes between the restore's post-checkout breach re-read and the hunk apply; the apply executes the plant; the plant erases itself before the next restore's screen; every later read is clean and the hunk scores killed/survived — a certified verdict over an executed plant. Reachability: hunk probes run LAST, after every mutant run the diff itself names as the planters. Fix: pair the apply — localFilterRefusal(probeTree, 'the hunk reverse-apply', captured) before the spawn and localFilterBreach(probeTree, 'the hunk reverse-apply', captured.baseline) after a successful apply, returning the breach as inconclusive. 中文说明：R7-5：runOneHunkProbe 的 git apply --reverse（test-efficacy.ts:2135，该 spawn 行早于本 diff 的 hunk，故在正文而非行内）是一个会执行过滤器的 git 动词，前面没有 localFilterRefusal、后面没有成对的 localFilterBreach——这是探针阶段里唯一一个本 PR 在别处处处添加的屏蔽/成对机制没有覆盖的、会执行过滤器的活动词，而本 diff 新增的文档声明（"Every checkout this pipeline runs executes these …"）与名为 "content-filter screens cover every checkout the probe phase runs" 的新测试读起来像是完备的。证据（裸 git 2.43 夹具）：git apply --reverse 同时执行 clean 与 smudge。失败场景：回收够不到的切换器在 restore 的 checkout 后复读与 hunk apply 之间植入过滤器 + attributes；apply 执行植入；植入在下次 restore 的屏蔽前自我擦除；之后每次读取都干净，hunk 照常评分——在已执行植入之上给出认证结论。可达性：hunk 探针最后运行，位于 diff 自己点名为植入者的每一次突变体运行之后。修复：给 apply 成对——spawn 前 localFilterRefusal(...)、成功 apply 后 localFilterBreach(...)，命中即按 inconclusive 返回。
中文说明
仅完成部分审查，审查缺口已披露。
本轮确认的 5 条建议级发现已在 PR 上报告过，不再重复发布（列表见上方英文部分）。
未审查：build-and-test — Test (windows-latest, Node 22.x) and Test (macos-latest, Node 22.x) were skipped in CI and their platform-specific suites did not run locally (the Windows-gated test fixes R6-2/R6-11/R6-16 and the win32 resolver branches named in D7-2 are unverified on those platforms)。
未探索到全部深度（达到工具调用预算）：chunk 3：live vitest run of the new test file (review worktree has no node_modules; npm ci + build exceeds the tool budget)。
未审查：反向审计——有审计 agent 运行并打开了自己的 brief，但没有 agent 是用 CLI 构建的 prompt 启动的——启动 prompt 是手写的，agent 实际被要求做的并不是本 skill 所认证的内容。
收敛姿态下延后（第 7 轮，非阻断）——已记录，本轮不要求修改：共 7 条（原文未翻译，列表见上方英文部分）。
[Critical] R7-5: runOneHunkProbe's git apply --reverse (test-efficacy.ts:2135, a spawn line that pre-dates this diff's hunks — hence body, not inline) is a filter-executing git verb with no localFilterRefusal before it and no paired localFilterBreach after it — the one live filter-executing verb of the probe phase the screen/pair machinery this PR adds everywhere else does not cover, while the docstring claim this diff adds ("Every checkout this pipeline runs executes these …") and the new test titled "content-filter screens cover every checkout the probe phase runs" read as complete. Witness (raw git 2.43 fixture, *.txt filter=evil): git diff: clean=YES smudge=no / git apply --reverse: clean=YES smudge=YES / git apply (forward): clean=YES smudge=YES — apply executes BOTH clean and smudge, and is also where the deliberately-included filter.*.clean key becomes live. Failure scenario: a toggler the reap cannot reach plants filter.evil.smudge + attributes between the restore's post-checkout breach re-read and the hunk apply; the apply executes the plant; the plant erases itself before the next restore's screen; every later read is clean and the hunk scores killed/survived — a certified verdict over an executed plant. Reachability: hunk probes run LAST, after every mutant run the diff itself names as the planters. Fix: pair the apply — localFilterRefusal(probeTree, 'the hunk reverse-apply', captured) before the spawn and localFilterBreach(probeTree, 'the hunk reverse-apply', captured.baseline) after a successful apply, returning the breach as inconclusive. 中文说明：R7-5：runOneHunkProbe 的 git apply --reverse（test-efficacy.ts:2135，该 spawn 行早于本 diff 的 hunk，故在正文而非行内）是一个会执行过滤器的 git 动词，前面没有 localFilterRefusal、后面没有成对的 localFilterBreach——这是探针阶段里唯一一个本 PR 在别处处处添加的屏蔽/成对机制没有覆盖的、会执行过滤器的活动词，而本 diff 新增的文档声明（"Every checkout this pipeline runs executes these …"）与名为 "content-filter screens cover every checkout the probe phase runs" 的新测试读起来像是完备的。证据（裸 git 2.43 夹具）：git apply --reverse 同时执行 clean 与 smudge。失败场景：回收够不到的切换器在 restore 的 checkout 后复读与 hunk apply 之间植入过滤器 + attributes；apply 执行植入；植入在下次 restore 的屏蔽前自我擦除；之后每次读取都干净，hunk 照常评分——在已执行植入之上给出认证结论。可达性：hunk 探针最后运行，位于 diff 自己点名为植入者的每一次突变体运行之后。修复：给 apply 成对——spawn 前 localFilterRefusal(...)、成功 apply 后 localFilterBreach(...)，命中即按 inconclusive 返回。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| baseline: null, | ||
| }; | ||
| if ( | ||
| localFilterRefusal(worktree, 'the reset this command runs', captured) !== |
There was a problem hiding this comment.
[Critical] R4-1: still standing (carried under the original id; deferred again by the round-7 fix round). The screens are one-shot config reads authorising checkouts against a concurrent writer the pipeline itself schedules (a sibling shard's suite, a toggler the reap did not reach), and nothing serialises the common dir — no shared advisory lock is held across the screen+checkout pairs or around the suite spawns. Round 7 narrowed the window (every guarded checkout now has its paired post-checkout re-read; the self-erasing evasion is detected for naive shapes), but the serialization half remains unimplemented, and this round's five new Criticals (R7-1, R7-2, R7-6, R7-7, RA4-LAUNDER) plus the R6-7 identity class each exploit exactly this unserialized window — a plant that lands between a screen's clean read and the authorised checkout's own config read executes, and detection afterwards is best-effort by construction. Witness: no lock acquisition exists anywhere in the screen/checkout paths at HEAD (grep); each confirmed round-7 probe drove its plant through this window.
Fix direction (on record since round 4): a shared advisory lockfile held across each screen+checkout pair and around every suite spawn, so no writer can plant between a screen's read and the checkout it authorises.
中文说明
R4-1：仍然成立（以原编号延续；第 7 轮修复轮再次推迟）。屏蔽是对配置的一次性读取，它所授权的 checkout 面对的是流水线自己调度的并发写者（兄弟 shard 的套件、回收够不到的切换器），而 common 目录没有任何串行化——没有一把共享咨询锁横跨「屏蔽+checkout」对、或包住套件 spawn。第 7 轮收窄了窗口（每个受守护的 checkout 都有了成对的 checkout 后复读；朴素形态的自我擦除植入可被检测），但串行化那一半仍未实现，而本轮新确认的 5 条 Critical（R7-1、R7-2、R7-6、R7-7、RA4-LAUNDER）与 R6-7 身份类正是各自利用了这个未串行化的窗口——在屏蔽读到干净与授权 checkout 自己读配置之间落地的植入会执行，事后的检测按构造只是尽力而为。证据：HEAD 上屏蔽/checkout 路径中不存在任何锁获取（grep）；每条已确认的第 7 轮探针都把植入穿过了这个窗口。修复方向（第 4 轮起已有记录）：用一把共享咨询锁文件横跨每个「屏蔽+checkout」对、并包住每次套件 spawn。
— qwen3.8-max via Qwen Code /review (v0.21.15)
There was a problem hiding this comment.
Disposition: escalated to a maintainer — left open deliberately.
The round reproduced every named exploit of this window, and the six individual gaps it lists were each closed and mutation-witnessed this round (readdir fail-open, rollback ordering, the unpaired git apply --reverse, the mtime-only comparison and -1 sentinel collision, the catch paths without re-reads, the unpinned identity). The serialization half itself is the part this loop cannot settle, for a reason worth stating plainly: an advisory lock only binds cooperative writers, and the toggler class this mechanism defends against — a setsid'd descendant of the suite deliberately planting config — ignores advisory locks entirely. The lock cannot close the window it is aimed at; it would serialize the pipeline's own screen+checkout pairs, each of which is already guarded, and (per the fix sketch's "around all suite spawns") potentially the suites themselves — a real concurrency/performance change for every review.
Question for the maintainer: do you still want the lock as defense-in-depth against pipeline-internal races once the non-cooperative-writer point is on the table, and if so, where — across each screen+checkout pair only, or also around suite spawns (which serializes shards' suites)? This round deliberately ships the detection closures rather than guessing that call.
中文说明
处置：升级给维护者 — 刻意保持打开。
本轮复现了该窗口被点名的每一种利用方式，其中列出的 6 个独立缺口本轮均已逐一关闭并配有变异见证（readdir fail-open、回滚顺序、未配对的 git apply --reverse、仅比较 mtime 与 -1 哨兵碰撞、无重读的 catch 路径、未钉定的身份）。串行化这一半是本循环无法定夺的部分，原因值得明说：咨询锁只能约束合作型写者，而本机制防御的 toggler 类 — suite 的 setsid 后代、蓄意植入配置 — 完全无视咨询锁。这把锁关不上它瞄准的窗口；它只会把管道自己的屏+checkout 对（每一对已有守卫）串行化，并且（按修复草案的"所有 suite spawn 外围"）可能把 suite 本身也串行化 — 对每次评审都是真实的并发/性能改变。
给维护者的问题：把非合作写者这一点摆上台面之后，是否仍要这把锁作为针对管道内部竞态的纵深防御？如果要，放在哪里 — 仅跨每个屏+checkout 对，还是连 suite spawn 外围一起（那会把各分片的 suite 串行化）？本轮刻意先交付检测侧的关闭，而不是替维护者猜这个决定。
| */ | ||
| export interface LocalFilterBaseline { | ||
| /** Each file the screen read, keyed by the path it was read at. */ | ||
| files: Map<string, { mtimeMs: number; size: number }>; |
There was a problem hiding this comment.
[Critical] R6-7: still standing (carried under the original id) — class-level: repository identity is never pinned across any screen→checkout→breach triple. Every guarded pair re-runs discovery through the swappable worktree/.git pointer at each step, and LocalFilterBaseline carries only file paths — no identity — so a gitfile swap redirects an authorised checkout into an armed repository while every read answers clean. This round probe-confirmed EIGHT locations: the reset gate (swap during the screen), the restore (swap during the screen), fetch-pr's add, the scratch rebuild, the revert checkout, the base-tree add, the reset pair's post-checkout re-read window, and the probe-tree creation.
Failure scenario: an escapee the reap cannot reach rewrites the review worktree's .git gitfile to an armed clone's admin entry (armed clone holds the needed sha + a filter definition + selecting attributes). The guarded checkout resolves through the swap and EXECUTES the filter; the paired breach re-read re-discovers through the swap (or a swap-back) — its key half screens the attacker's clean config and its changed-file half stats the original repo's untouched baselined files — so the run is certified clean over an executed plant, with the created trees left permanently registered under the armed repository (every later restore discovers through it too).
Witness (probes, git 2.43): fetch-pr add — marker fired? true, registered in attacker? true, registered in main? false, breach after swap-back: null; scratch rebuild — marker fired? true, breach after restore: null, scratch backpointer: gitdir: <armed>/.git/worktrees/scratch-wt; base-tree — existsSync(marker)=true, r.available=true, certified tree --git-common-dir ∈ armed-clone; reset re-read — plant-executed=true, discovery before=…/repo/.git after=…/clone/.git, breach=null; creation — addStatus:0, markerExists:true, breach:null, probeTreeUnderArmedClone:true. Every arm flips when an identity pin is applied (available=false / detected=true).
| files: Map<string, { mtimeMs: number; size: number }>; | |
| export interface LocalFilterBaseline { | |
| /** Each file the screen read, keyed by the path it was read at. */ | |
| files: Map<string, { mtimeMs: number; size: number }>; | |
| /** The repository the screen resolved, so the paired re-read can refuse | |
| * when it re-discovers a DIFFERENT one (a swapped .git pointer). */ | |
| commonDirRealpath: string; | |
| } |
Fix: record the resolved identity in the baseline (realpath of rev-parse --git-common-dir plus the admin backpointer), have localFilterBreach re-resolve and compare before reading — breach on mismatch — and re-run the identity comparison below the screen at the reset/restore/revert sites (covering the during-screen window too).
中文说明
R6-7：仍然成立（以原编号延续）——类级发现：任何「屏蔽→checkout→breach」三元组都从不钉住仓库身份。每个成对守卫在每一步都透过可被替换的 worktree/.git 指针重新发现仓库，而 LocalFilterBaseline 只携带文件路径、没有身份——因此一次 gitfile 替换就能把受授权的 checkout 重定向进一个武装仓库，而所有读取都回答干净。本轮以探针确认了8 处：reset 门（屏蔽期间替换）、restore（屏蔽期间替换）、fetch-pr 的 add、scratch 重建、revert checkout、base-tree 的 add、reset 对的 checkout 后复读窗口、探针树创建。失败场景：回收够不到的逃逸者把 review 工作树的 .git gitfile 改写为武装克隆的管理条目（武装克隆持有所需 sha + 过滤器定义 + 选中它的 attributes）。受守护的 checkout 透过替换解析并执行过滤器；成对复读也透过替换（或换回）重新发现——键半区读到攻击者的干净配置、变更文件半区 stat 的是原仓库未被触碰的基线文件——于是运行在已执行植入之上被认证为干净，且新建的树被永久注册在武装仓库之下（之后每次 restore 也都透过它发现）。证据（探针，git 2.43）见英文部分；每一臂在加入身份钉住后都翻转。修复：在基线中记录解析出的身份，localFilterBreach 复读前重新解析并比对，不一致即 breach；并在 reset/restore/revert 站点的屏蔽之下重跑身份比对。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| } catch { | ||
| // No linked worktrees registered: the candidates above are all of it. | ||
| } |
There was a problem hiding this comment.
[Critical] R7-1: the screen discovers candidate config files by listing directories, but this catch (and the twin submoduleConfigs readdir catch above) reads EVERY enumeration failure — EACCES included — as "nothing registered" = clean, while git executes config files it reaches BY PATH. An execute-only (--x) directory defeats readdirSync (needs read) while path-based reads through it still succeed (need only execute) — a fail-open inside a screen whose contract is fail-closed everywhere else.
Failure scenario: plant (1) core.repositoryformatversion=1 + extensions.worktreeConfig=true in <common>/config (neither matches the screen regex), (2) [filter "evil"] smudge = CMD in <common>/worktrees/<scratch-label>/config.worktree, (3) chmod 100 <common>/worktrees. Screening the review worktree answers {"keys":[],"unclearable":[]} — clean — while a checkout in the sibling tree EXECUTES the smudge; the paired breach re-read is blind the same way (the planted file never entered the baseline).
Witness (probe driving the real screen, git 2.43): CONTROL (mode 755): {"keys":["filter.evil.smudge"]} / HIDDEN (mode 100): {"keys":[],"unclearable":[]}, refusal: null, breach: null / EXECUTION (mode 100): checkout fired the marker / FLIP (ENOENT-only catch): HIDDEN arm answers unclearable.
| } catch { | |
| // No linked worktrees registered: the candidates above are all of it. | |
| } | |
| } catch (err) { | |
| // ENOENT genuinely means no linked worktrees are registered. Any other | |
| // failure is an enumeration this screen cannot clear — an execute-only | |
| // directory defeats readdirSync while path reads through it succeed. | |
| if ((err as NodeJS.ErrnoException).code !== 'ENOENT') { | |
| screen.unclearable.push( | |
| `${join(common, 'worktrees')}: cannot list (${(err as NodeJS.ErrnoException).code ?? 'unknown'})`, | |
| ); | |
| } | |
| } |
Apply the identical split to the submoduleConfigs readdir catch.
中文说明
R7-1：屏蔽通过列目录来发现候选配置文件，但这个 catch（以及上方 submoduleConfigs 的同型 readdir catch）把任何枚举失败——包括 EACCES——都读作「没有注册任何工作树」= 干净；而 git 执行的是它按路径够到的配置文件。仅可执行（--x）目录会让 readdirSync 失败（需要读权限），但穿过它的路径读取仍然成功（只需执行权限）——在一个契约处处失败关闭的屏蔽里，这是一处失败放行。失败场景与证据见英文部分（mode 100 时屏蔽回答干净、兄弟树 checkout 触发植入；改为仅 ENOENT 吞掉的 catch 后，隐藏臂回答 unclearable）。修复：把 catch 拆分——仅 ENOENT 视为「无工作树」，其余失败推入 screen.unclearable（拒绝）；submoduleConfigs 的 readdir catch 同样处理。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| if (breach !== null) { | ||
| discardWorktree(worktree, probeTree); | ||
| createDetail = breach; | ||
| created = false; | ||
| } |
There was a problem hiding this comment.
[Critical] R7-2: on a creation breach, the rollback calls discardWorktree(worktree, probeTree) BEFORE setting createDetail = breach; created = false;. discardWorktree's own docstring says its rmSync still can throw (force suppresses ENOENT but not EPERM/EBUSY), and this same diff's revert-phase finally wraps the identical call in try/catch for exactly that reason. If it throws here, created stays true, the outer catch overwrites createDetail, if (!created) pushes no inconclusive records, and if (created && probes.length > 0) proceeds to baseline/mutant scoring in the tree the breach re-read just condemned — and this creation re-read is the ONLY read that can see a self-erasing plant, so the tree scores as if certified and the breach never reaches the report.
Witness (probe, end-to-end through the real testEfficacyCommand handler with a self-erasing armer + a mode-555 lockdir making the rollback's rmSync throw): outJsonMentionsBreach: false; the phase proceeded (revert checkout ran, hunk probes ran); probeTreeStillExists: true; cleanupFailure: EACCES. FLIP (flags set before the discard): every probe inconclusive/not-run, no scoring.
| if (breach !== null) { | |
| discardWorktree(worktree, probeTree); | |
| createDetail = breach; | |
| created = false; | |
| } | |
| if (breach !== null) { | |
| created = false; | |
| createDetail = breach; | |
| try { | |
| discardWorktree(worktree, probeTree); | |
| } catch { | |
| // Rollback failed; the breach detail already records why the | |
| // phase stopped. The tree is re-screened on the next call. | |
| } | |
| } |
中文说明
R7-2：创建阶段命中 breach 时，回滚先调用 discardWorktree(worktree, probeTree)，之后才设置 createDetail = breach; created = false;。discardWorktree 自身的文档注释承认其 rmSync 仍可能抛出（force 只压住 ENOENT，压不住 EPERM/EBUSY），而同一 diff 的 revert 阶段 finally 正因如此把同样的调用包在 try/catch 里。若它在此抛出：created 保持 true，外层 catch 覆写 createDetail，if (!created) 不会推入任何 inconclusive 记录，if (created && probes.length > 0) 会继续对那棵刚被 breach 复读定罪的树做基线/突变打分——而创建复读是唯一能看到自我擦除植入的读取，于是该树像被认证一样参与评分，breach 永远进不了报告。证据（端到端探针）：breach 被静默丢弃、阶段继续、probeTreeStillExists: true；翻转（先设标志再 discard）后所有探针 inconclusive、不再打分。修复：先设 created = false; createDetail = breach;，并把 discardWorktree 包进 try/catch。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| if (!existsSync(file)) return; | ||
| if (scannedFiles !== undefined) { |
There was a problem hiding this comment.
[Critical] R7-6: class finding (4 independent auditors, probe-confirmed) — scan() skips candidates ABSENT at screen time before baseline recording, and changedScreenedFiles iterates only baselined files, so a config file CREATED after the screen, EXECUTED by the guarded checkout, and DELETED before the re-read is invisible to BOTH halves of localFilterBreach. Demonstrated vehicles: a tree's own <common>/worktrees/<label>/config.worktree (git never creates it retroactively, and the checkout reads it once extensions.worktreeConfig=true — a screen-invisible benign key — is set in the common config) and absent include targets.
Failure scenario: a toggler the reap cannot reach sets extensions.worktreeConfig=true (never matches the screen regex), creates the probe/scratch/review tree's own admin config.worktree holding [filter "evil"] smudge = CMD between the screen and the guarded checkout — which executes it — and deletes it before the re-read: scan() skips the absent file, changedScreenedFiles has no entry for it, the key re-read is clean → breach null, run certified over an executed plant. This falsifies the pairing comment's claim that the creation re-read is "the ONLY read that can see such a plant".
Witness (probe through the real localFilterRefusal/localFilterBreach, git 2.43): baseline has admin config.worktree entry? false / checkout status 0, marker fired? true / breach after delete-before-reread: null; the include-target variant is identical; control with the plant left standing → breach true. Note from verification: the existing -1 sentinel does NOT close this — the fix must detect appearance inside the window.
Fix: record absent candidates too (a sentinel whose definition is fixed per R7-7), and baseline the mtimes of the candidate-bearing directories (<common>/worktrees/<label>/ etc.) so an entry appearing and vanishing inside the window is a breach; allowlist the one entry worktree add is known to create in the creation pair.
中文说明
R7-6：类级发现（4 名独立审计者、探针确认）——scan() 在记录基线之前就跳过屏蔽时不存在的候选文件，而 changedScreenedFiles 只遍历有基线条目的文件——因此在屏蔽之后创建、被受守护 checkout 执行、复读之前又删除的配置文件，对 localFilterBreach 的两个半区都不可见。已演示的载体：树自己的 <common>/worktrees/<label>/config.worktree（git 从不事后创建它，而一旦 common 配置里设置了 extensions.worktreeConfig=true——一个屏蔽不可见的良性键——checkout 就会读取它），以及缺失的 include 目标。失败场景、证据与修复方向见英文部分。要点：既有的 -1 哨兵不能闭合本问题（哨兵语义把两侧皆无读作无事发生）——修复必须检测窗口内的「出现」。
— qwen3.8-max via Qwen Code /review (v0.21.15)
There was a problem hiding this comment.
Disposition: partially closed this round; the appear-and-vanish half is disclosed, not dropped — left open.
What landed:
- Absent candidates are recorded. The screen used to skip a candidate absent at screen time before recording the baseline; it now records it under an explicit
vanishedsentinel (the numeric-1sentinel is gone —utimesSync(file, new Date(-1))produces exactly-1, live-measured, and a real stat can carry any number). A candidate that APPEARS inside the window — a per-worktreeconfig.worktree, or an include target planted after the screen — is a breach at the paired re-read whatever it holds, because git reads it by path whenever it exists. Witnesses: appearance test and the-1-collision test, both failing on the pre-round code by mutation probe.
What did not land, and why:
- The directory-mtime half for appear-and-vanish was tried and removed after measurement. The fix sketch proposes baselining the directories holding candidates so entry churn betrays a plant that appears, executes, and vanishes. On this runner,
git checkoutitself advances its own admin-dir mtime viaHEAD.lock/index.lockrenames with the entry set unchanged — the signal a plant's churn would produce is indistinguishable from git's own atomic writes, and shipping the comparison wedged nine healthy reset tests live (every dirty reset writes those lockfiles). The creation-pair variant additionally needs an allowlist for the entryworktree addcreates, and git's own admin entries cannot be reliably told apart from a plant entry at re-read time either. The residual is documented onLocalFilterBaseline's docstring as a disclosed limit rather than a wedge-prone comparison, and the root closure for the whole window class is R4-1's serialization decision (escalated on its own thread).
中文说明
处置：本轮部分关闭；出现-消失的一半作披露而非放弃 — 保持打开。
已落地：
- 缺失的候选会被记录。 屏过去在记录基线之前会跳过屏时缺失的候选；现在用显式
vanished哨兵记录（数值-1哨兵已移除 —utimesSync(file, new Date(-1))恰好产生-1，实测如此，且真实 stat 可以携带任意数值）。窗口内出现的候选 — 每工作树的config.worktree，或屏后植入的 include 目标 — 在配对重读时即为 breach，无论其内容如何，因为只要它存在，git 就会按路径读取。见证：出现测试与-1碰撞测试，均经变异探针确认在轮前代码上失败。
未落地及原因：
- 针对出现-消失的目录 mtime 半区经测量后尝试并移除。 修复草案提议给承载候选的目录建基线，让条目变动暴露"出现、执行、消失"的植物。在本运行器上，
git checkout自身就会通过HEAD.lock/index.lock重命名推高自己 admin 目录的 mtime，而条目集合并未变化 — 植物变动本应产生的信号与 git 自己的原子写入无法区分，上线该比较现场卡死了 9 个健康的 reset 测试（每次脏重置都会写这些锁文件）。创建对的变体还需要为worktree add创建的条目加白名单，而重读时同样无法把 git 自己的 admin 条目与植物条目可靠区分。该残留已作为披露限制写进LocalFilterBaseline的文档，而不是留作易卡死的比较；整个窗口类的根关闭是 R4-1 的串行化决定（在其自己的线程上已升级）。
| if (st.mtimeMs !== was.mtimeMs || st.size !== was.size) { | ||
| changed.push(file); | ||
| } |
There was a problem hiding this comment.
[Critical] R7-7: class finding, two shapes (both probe-confirmed). (1) The changed-file half compares only mtimeMs + size: a fired plant that unsets its key and restores content + mtime from its own payload (truncate + touch -d — arbitrary shell by definition) leaves the file byte- and ns-mtime-exact, so both halves answer clean over an executed plant — falsifying the docstring claims "it cannot leave the file it wrote unchanged" / "never certified clean with a planted checkout behind it". (2) The -1 "vanished mid-scan" sentinel collides with a real stat: utimesSync(file, new Date(-1)) makes statSync().mtimeMs === -1 exactly (live-verified), and git reads a pre-epoch-mtime config normally — so a file baselined at mtime −1 and DELETED after the plant fires reads as the sentinel ("nothing happened") in the catch branch below.
Witness: shape 1 — size equal? true, mtimeMs equal? true (bit-equal after truncate+touch -d), ctimeMs forged back? false, breach after exact restore: null; shape 2 — utimesSync(new Date(-1)) → statSync().mtimeMs === -1; screen clean, baseline {mtimeMs:-1,size:S}; worktree add executed the smudge, config deleted; localFilterBreach === null — control (normal-mtime deletion) IS reported; fix arm (both-fields sentinel) reports the breach.
| if (st.mtimeMs !== was.mtimeMs || st.size !== was.size) { | |
| changed.push(file); | |
| } | |
| const st = statSync(file); | |
| if ( | |
| st.mtimeMs !== was.mtimeMs || | |
| st.size !== was.size || | |
| st.ctimeMs !== was.ctimeMs | |
| ) { | |
| changed.push(file); | |
| } |
Record ctimeMs in the baseline and compare it (every plant write advances ctime; utimensat cannot set it) — closes shape 1. Make the vanish sentinel unambiguous (both fields −1, or an explicit vanished flag) — closes shape 2. A content hash does NOT close shape 1 (a byte-exact restore matches the hash); downgrade the absolute docstring claims to the disclosed-limit form for any residual.
中文说明
R7-7：类级发现，两种形态（均经探针确认）。(1) 变更文件半区只比较 mtimeMs + size：已触发的植入把键 unset、再用自己的载荷恢复内容与 mtime（truncate + touch -d——按定义它拥有任意 shell），文件在字节与纳秒级 mtime 上都与原来完全一致，两个半区因此都回答干净——证伪了文档声明「它不可能让自己写过的文件保持不变／绝不在植入过的 checkout 背后认证干净」。(2) -1「扫描中途消失」哨兵与真实 stat 冲突：utimesSync(file, new Date(-1)) 恰好使 statSync().mtimeMs === -1（实测），而 git 正常读取 epoch 前 mtime 的配置——因此以 mtime −1 入基线的文件在植入触发后被删除时，会落入下方 catch 分支被读作哨兵（「无事发生」）。证据见英文部分。修复：在基线中记录 ctimeMs 并比较（任何植入写入都会推进 ctime，utimensat 无法设置它）——闭合形态 1；让消失哨兵不再含糊（两字段皆为 −1，或显式 vanished 标志）——闭合形态 2。内容哈希不能闭合形态 1（字节级精确恢复同样匹配哈希）。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| } catch { | ||
| // A tree too broken to reset is not a tree to probe in. The caller | ||
| // discards and rebuilds it rather than handing back a half-known state. | ||
| return false; | ||
| return { ok: false }; | ||
| } |
There was a problem hiding this comment.
[Critical] RA4-LAUNDER: the reset path's catch returns { ok: false } WITHOUT running the paired breach re-read when the guarded checkout throws — and runScratchTree then discards-and-rebuilds IN THE SAME CALL, laundering an executed plant into a clean certification. The finding's original trigger (a failing filter) is unreachable on probe git versions, but two reachable shapes were measured: (1) kill shape — the plant's smudge does its work then kills git mid-checkout (touch MARKER; …; kill -9 $PPID → exit 137 → gitOut throws AFTER the execution); (2) EACCES shape — the filter fires on the first file, then a dirty file under a mode-555 directory aborts the checkout.
Witness (probe, real runScratchTree, git 2.43): end-to-end PROBE-RESULT available=true reused=false note="your scratch tree is at …" with the marker assertion passing in the same run — a positive clean certification over an executed plant. FLIP (breach re-read inside the catch): available=false, note ⊃ "a plant the reset this command ran may have EXECUTED". One caveat: a payload that also restores the config mtime exactly defeats the catch-side baseline half too (R7-7) — this fix is necessary but not sufficient against the strongest plant; the current code, which never runs the re-read on this path, is strictly worse.
| } catch { | |
| // A tree too broken to reset is not a tree to probe in. The caller | |
| // discards and rebuilds it rather than handing back a half-known state. | |
| return false; | |
| return { ok: false }; | |
| } | |
| } catch { | |
| // A tree too broken to reset is not a tree to probe in. The caller | |
| // discards and rebuilds it rather than handing back a half-known state. | |
| // But a checkout that THREW may still have executed a plant first, so | |
| // attribute it before the caller's discard-and-rebuild launders it. | |
| if (captured.baseline !== null) { | |
| const breach = localFilterBreach( | |
| worktree, | |
| 'the reset this command ran', | |
| captured.baseline, | |
| ); | |
| if (breach !== null) return { ok: false, breach }; | |
| } | |
| return { ok: false }; | |
| } |
(captured needs hoisting above the try.) Apply the same to the base-tree catch twin.
中文说明
RA4-LAUNDER：reset 路径的 catch 在受守护的 checkout 抛出时不运行成对的 breach 复读就返回 { ok: false }——而 runScratchTree 接着在同一次调用里丢弃并重建，把一个已执行的植入洗白成干净的认证。原发现的触发器（失败的过滤器）在探针 git 版本上不可达，但实测到两种可达形态：(1) kill 形态——植入的 smudge 完成工作后在 checkout 中途杀掉 git（touch MARKER; …; kill -9 $PPID → exit 137 → gitOut 在执行之后才抛出）；(2) EACCES 形态——过滤器在第一个文件上触发，随后 mode-555 目录下的脏文件使 checkout 中止。证据（真实 runScratchTree 端到端探针，git 2.43）：available=true reused=false，同一次运行中 marker 断言通过——在已执行植入之上给出干净的认证。翻转（在 catch 内运行 breach 复读）：available=false，注记包含「may have EXECUTED」。注意：若载荷同时精确恢复配置 mtime，catch 侧的基线半区也会被绕过（见 R7-7）——本修复必要但非充分；当前代码在此路径根本不运行复读，严格更差。修复：把 captured 提升出 try，在 catch 中运行复读并按结果返回；base-tree 的同型 catch 同样处理。
— qwen3.8-max via Qwen Code /review (v0.21.15)
![qwen-code-autofix[bot]](https://github.githubassets.com/images/gravatars/gravatar-user-420.png){kind=avatar}
…n the filter screens (#9566) Round-8 criticals: the screen's readdir catches failed open on any enumeration error (EACCES read as "nothing registered"); the baseline sentinel collided with a real -1 mtime and skipped absent candidates; the changed-file half compared mtime+size only, so a byte-exact restore cleaned the trace; `git apply --reverse` ran filters unscreened; the reset/base catches and the creation rollback skipped the paired re-read or set the stop flags after a call that can throw; and no read pinned the repository identity the screen resolved. Each fix carries a witness that fails on the pre-round code, verified by mutation probe; a directory-mtime half for appearing-and-vanishing per-worktree plants was tried and removed after measurement showed the checkout's own atomic admin writes advance the same mtime.
|
🤖 Addressed the latest review feedback (round 2/100). What changed, and what I pushed back on: · 已处理最新评审反馈（第 2/100 轮）。改动内容与我反驳保留之处如下： Round 8 summary — filter screens: identity pinning and the catch/rollback holesAll eight Criticals were reproduced on this runner (git 2.39.5, non-root) before Resolved in code
Partially resolved
Escalated to a maintainer
Environment noteThe runner's VerificationCommands actually run this round, in order:
中文说明第 8 轮总结 — 过滤屏（filter screens）：身份钉定与 catch/回滚漏洞全部 8 个 Critical 在动手修改之前都已在本运行器上复现（git 2.39.5，非 root）。 已在代码中解决
部分解决
升级给维护者
环境说明运行器的 验证本轮实际执行的命令，按顺序：
Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 Re-review when you have a moment. After round 100 this bot stops and leaves the PR for a human. · 有空请复审；第 100 轮后本 bot 停止并将 PR 交给人工。 🧠 Handled by Qwen Code · model/模型 |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Partially reviewed — gaps disclosed.
4 Suggestion-level finding(s) this review confirmed are already reported on this PR and are not repeated:
- F7 fsmonitor fixture's git add -A commits the registered worktree as an embedded gitlink (worktree.test.ts:117) — already reported in round 7's deferral list
- F9 throwing breach rollback swaps the note (scratch-tree.ts:562 + base-tree.ts twin) — already reported as DUP-1 in round 6's deferral list and re-listed in round 7
- F10 test-efficacy.test.ts:51 vi.mock seam drops the capture argument — already reported in round 7's deferral list (scratch-tree.test.ts:37 +3 locations)
- F25 breach rollback discards releaseWorktree's verdict (fetch-pr.ts:1037) — already reported in round 6's deferral list and re-listed in round 7
Not reviewed: build-and-test — Test (windows-latest, Node 22.x) and Test (macos-latest, Node 22.x) were skipped in CI and their platform-specific suites did not run locally (the Windows/root-lane fixture findings R8-2 and R8-11 target are unverified on those platforms).
Not explored to full depth (tool budget reached): chunk 8: executing packages/cli/src/commands/review/scratch-tree.test.ts — neither the shared review worktree nor the parent checkout has node_modules or built works…; "agent 1c": none — no checks were cut short..
Not reviewed: reverse audit — stopped before round 5 by the review time budget.
Test Plan (not a blocker): 941 passed — this review observed 22951 passed.
Deferred under the convergence posture (round 8, not a blocker) — recorded, not requested in this round:
packages/cli/src/commands/review/fetch-pr.ts:991 — [review] PR description's Risk & Scope still describes the round-1 shape while the diff ships five refusal gates plus INERT_GIT_ARGS-on-all-git.ts-spawns and the suite reappackages/cli/src/commands/review/scratch-tree.test.ts:38 — [review] screenOverride.real is write-only dead code in a security-critical test seampackages/cli/src/commands/review/test-efficacy.ts:2699 — [probe] probe-phase worktree add lacks any post-screen re-check (the revert phase has identity + escape for the same window)packages/cli/src/commands/review/lib/worktree.test.ts:126 — [probe] POSIX-only unquoted fsmonitor marker fixture silently unpins the guard on Windows/space-tmpdir hostspackages/cli/src/commands/review/scratch-tree.ts:473 — [review] reset-breach return leaves the plant-executed tree standing without the discardWorktree rollback its rebuild twin performspackages/cli/src/commands/review/fetch-pr.test.ts:683 — [review] 'screens BELOW cleanStale' test plants into a worktree cleanStale never releases — proves ordering only, not the wedge-clearing propertypackages/cli/src/commands/review/lib/worktree.test.ts:1474 — [probe] the screen regex's process arm has zero coverage in the library suite (mutation green 83/83)packages/cli/src/commands/review/lib/worktree.ts:1150 — [probe] discovery-failure refusal is forced through the config-file template and misdirects incident responsepackages/cli/src/commands/review/scratch-tree.test.ts:376 — [probe] hook/fsmonitor inert test's absence-shaped assertions with unquoted POSIX-only markers pass vacuously on hostile hosts
中文说明
仅完成部分审查，审查缺口已披露。
本轮确认的 4 条建议级发现已在 PR 上报告过，不再重复发布（列表见上方英文部分）。
未审查：build-and-test — Test (windows-latest, Node 22.x) and Test (macos-latest, Node 22.x) were skipped in CI and their platform-specific suites did not run locally (the Windows/root-lane fixture findings R8-2 and R8-11 target are unverified on those platforms)。
未探索到全部深度（达到工具调用预算）：chunk 8：executing packages/cli/src/commands/review/scratch-tree.test.ts — neither the shared review worktree nor the parent checkout has node_modules or built works…；"agent 1c"：none — no checks were cut short.。
未审查：反向审计——评审时间预算不足，未能开始第 5 轮。
Test Plan（非阻断）：941 passed — this review observed 22951 passed。
收敛姿态下延后（第 8 轮，非阻断）——已记录，本轮不要求修改：共 9 条（原文未翻译，列表见上方英文部分）。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| if ( | ||
| localFilterRefusal(worktree, 'the reset this command runs', captured) !== | ||
| null | ||
| ) { |
There was a problem hiding this comment.
[Critical] R4-1 (round 8, carried under the original id): the screens remain one-shot config reads authorising checkouts against a concurrent writer the pipeline itself schedules, and nothing serialises the common dir — no shared advisory lock is held across the screen+checkout pairs or around the suite spawns. Every confirmed round-8 Critical (post-screen baseline capture poisoning at worktree.ts:1145, the never-baselined recreated admin config.worktree at the four add sites, the placement-swap class at five sites, the unbounded candidate scan at worktree.ts:991) is an exploit of exactly this window, each probe-witnessed this round: a plant that lands between a screen's clean read and the authorised checkout's own config read EXECUTES, and detection afterwards is best-effort by construction. Witness: no lock acquisition exists anywhere in the screen/checkout paths at HEAD (grep); each round-8 probe drove its plant through this window. The round-7 thread escalated this to a maintainer and the question stands there: an advisory lock only binds cooperative writers (a setsid'd toggler ignores it), so decide whether the lock is still wanted as defense-in-depth against pipeline-internal races, and if so whether it spans each screen+checkout pair only or also the suite spawns.
中文说明
R4-1（第 8 轮，以原编号延续）：屏蔽仍然是对配置的一次性读取，它所授权的 checkout 面对的是流水线自己调度的并发写者，而 common 目录没有任何串行化——没有共享咨询锁横跨「屏蔽+checkout」对，也没有包住套件 spawn。本轮确认的每一条 Critical（worktree.ts:1145 的 screen 后基线捕获投毒、四个 add 站点从未入基线的重建管理 config.worktree、五个站点的放置替换类、worktree.ts:991 的无界候选扫描）都是对这个窗口的利用，且本轮均有探针见证：在屏蔽读到干净与授权 checkout 自己读配置之间落地的植入会执行，事后检测按构造只是尽力而为。证据：HEAD 上屏蔽/checkout 路径不存在任何锁获取（grep）；本轮每条探针都把植入穿过了这个窗口。第 7 轮已把本条升级给维护者，问题仍然有效：咨询锁只约束合作型写者（setsid 切换器完全无视它），请决定是否仍要这把锁作为针对管道内部竞态的纵深防御，以及范围（仅跨屏蔽+checkout 对，还是连套件 spawn 一起）。
— qwen3.8-max via Qwen Code /review (v0.21.15)
There was a problem hiding this comment.
Still escalated to the maintainer — this is a maintainer decision, not a change to implement or decline unilaterally: the advisory lock binds only cooperative writers, and whether the reap's serialization is still needed (and what replaces it if not) changes the shape of every remaining fix in this class. The round-7 escalation thread stays open; no code change this round.
中文说明
继续升级给维护者 —— 这是需要维护者决策的事项，不能单方面实现或拒绝：advisory lock 只约束合作型写入者，reap 的串行化是否仍然必要（以及若不需要时用什么替代）会改变该类所有剩余修复的形态。第 7 轮的升级线程保持打开；本轮不做代码变更。
| // Vanished between existsSync and stat — record the absence so | ||
| // the baseline comparison reads a reappearance as the change it | ||
| // is. The `vanished` flag is the sentinel: a real stat can carry | ||
| // ANY numeric mtime — `utimesSync(file, new Date(-1))` produces | ||
| // exactly `-1` (live-measured) — so no numeric value is one. | ||
| scannedFiles.set(file, { | ||
| mtimeMs: 0, | ||
| size: 0, | ||
| ctimeMs: 0, | ||
| vanished: true, | ||
| }); |
There was a problem hiding this comment.
[Critical] R7-6 (round 8, carried under the original id; partially closed in round 7): absent candidates are now recorded under the vanished sentinel, but the APPEAR-AND-VANISH half remains open — a config file CREATED after the screen, EXECUTED by the guarded checkout, and DELETED before the re-read is invisible to BOTH halves of localFilterBreach (it was never baselined, so changedScreenedFiles has no entry for it, and the key re-read is clean). Round 7 measured and removed the directory-mtime closure (git's own HEAD.lock/index.lock renames wedged nine healthy reset tests), so the residual is disclosed on LocalFilterBaseline's docstring rather than closed; the root closure remains R4-1's serialization decision. Failure scenario: a toggler the reap cannot reach creates a per-worktree config.worktree (once extensions.worktreeConfig is set — a screen-invisible benign key) or an absent include target between the screen and the checkout, the checkout executes it, and it is deleted before the re-read — certified clean over an executed plant. Round-7 probe (comparison code unchanged for this shape): baseline has no entry, checkout fired the marker, breach after delete-before-reread: null; control with the plant standing: breach true.
中文说明
R7-6（第 8 轮，以原编号延续；第 7 轮已部分关闭）：缺失候选现在会以 vanished 哨兵记录，但出现-消失的一半仍然敞开——屏蔽之后创建、被受守护 checkout 执行、复读之前又删除的配置文件，对 localFilterBreach 的两个半区都不可见（它从未入基线，changedScreenedFiles 没有它的条目，键复读也干净）。第 7 轮实测后移除了目录 mtime 方案（git 自身的 HEAD.lock/index.lock 重命名会卡死 9 个健康的 reset 测试），因此该残留写进了 LocalFilterBaseline 的文档作为披露限制而非关闭；整个窗口的根关闭仍是 R4-1 的串行化决定。失败场景：回收够不到的切换器在屏蔽与 checkout 之间创建 per-worktree 的 config.worktree（需 extensions.worktreeConfig——一个屏蔽不可见的良性键）或缺失的 include 目标，checkout 执行后又删除——在已执行的植入之上认证干净。第 7 轮探针（该形态的比较代码未变）：基线无条目、checkout 触发标记、删除后复读为 null；对照（植入留存）为 breach true。
— qwen3.8-max via Qwen Code /review (v0.21.15)
There was a problem hiding this comment.
Deferred to the next round: the general appear-and-vanish hardening depends on the R4-1 serialization decision, which is still with the maintainer; the partial mitigation that does not depend on it (baseline seeding of the predicted admin entry) is queued with its R8-5/R9-1 twins. The residual stays disclosed in the function docstring.
中文说明
推迟到下一轮：通用的“出现又消失”加固依赖 R4-1 的串行化决策，该决策仍在维护者处；其中不依赖该决策的部分缓解（将预测的管理条目播种进基线）已与其 R8-5/R9-1 同族项一起排队。残余风险继续在该函数的 docstring 中披露。
| const filterBreach = localFilterBreach( | ||
| process.cwd(), | ||
| 'the review worktree add this command ran', | ||
| captured.baseline, | ||
| ); |
There was a problem hiding this comment.
[Critical] R8-1 (location 1 of 3): this add's CATCH path (above, ~1009-1021) has no paired breach re-read — the paired re-read quoted here runs only on the success path. A plant that FIRES during the add's initial checkout and then makes the add throw (a smudge that kills git mid-checkout, or stalls it past the spawn deadline) is reported as an ordinary add failure: the execution is never attributed as a breach, the plant erases itself, and the retry screens clean. base-tree's identical add catch carries exactly this re-read with a written rationale; fetch-pr's add catch, scratch-tree's rebuild catch, and test-efficacy's probe-creation catch do not. Witness (probe, real git, the PR's own killer-smudge shape on the scratch rebuild arm): BASE: F1-ATTRIBUTED: false — note "scratch worktree could not be created: … reset died of signal 9 …" over an executed plant; FLIP (hoist captured + paired re-read in the catch, mirroring base-tree.ts): F1-ATTRIBUTED: true, note names the changed config file. Fix: mirror base-tree.ts in the catch — run localFilterBreach(process.cwd(), …, captured.baseline) before throwing the creation failure; on breach release/roll back and report the breach text.
中文说明
R8-1（共 3 处，第 1 处）：这个 add 的 catch 路径（上方约 1009-1021）没有成对的 breach 复读——此处引用的复读只在成功路径运行。在 add 的初始 checkout 中触发、随后又让 add 抛出的植入（smudge 在 checkout 中途杀掉 git，或让它超过 spawn 期限卡死）会被报告为普通的 add 失败：执行永远不会被归因为 breach，植入自我擦除，重试时屏蔽读到干净。base-tree 的同型 add catch 恰恰带了这个复读并写明了理由；fetch-pr 的 add catch、scratch-tree 的 rebuild catch、test-efficacy 的 probe 创建 catch 都没有。证据（探针，真实 git，PR 自带的 killer-smudge 形态，scratch rebuild 臂）：BASE：F1-ATTRIBUTED: false——在已执行的植入之上报告 "scratch worktree could not be created: … reset died of signal 9 …"；FLIP（提升 captured + 在 catch 中成对复读，与 base-tree.ts 一致）：F1-ATTRIBUTED: true，注记点名被修改的配置文件。修复：在 catch 中与 base-tree.ts 一致——抛出创建失败之前运行 localFilterBreach(process.cwd(), …, captured.baseline)；命中即释放/回滚并报告 breach 文本。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| const breach = localFilterBreach( | ||
| worktree, | ||
| 'the rebuild this command ran', | ||
| captured.baseline, |
There was a problem hiding this comment.
[Critical] R8-1 (location 2 of 3): the rebuild's CATCH path (~586-592) returns the plain create-failure note without the paired breach re-read quoted here (which runs only on the success path). A plant that fires during the rebuild add's initial checkout and then kills/stalls git is laundered as an ordinary create failure — execution never attributed, plant self-erased, next call screens clean. base-tree's identical add catch carries this re-read with a written rationale; this catch does not. Witness: probe (real git, killer-smudge shape): BASE: F1-ATTRIBUTED: false — note "scratch worktree could not be created: … reset died of signal 9 …" over an executed plant; FLIP (paired re-read in the catch): F1-ATTRIBUTED: true. Fix: hoist captured above the try and run localFilterBreach(worktree, 'the rebuild this command ran', captured.baseline) in the catch before converting to the create-failure report; on breach roll back and report the breach text.
中文说明
R8-1（共 3 处，第 2 处）：rebuild 的 catch 路径（约 586-592）返回普通的创建失败注记，没有此处引用的成对 breach 复读（它只在成功路径运行）。在 rebuild add 的初始 checkout 中触发、随后杀掉/卡死 git 的植入会被洗白成普通的创建失败——执行从未被归因，植入自我擦除，下一次调用屏蔽读到干净。base-tree 的同型 add catch 带了这个复读并写明理由；这个 catch 没有。证据：探针（真实 git，killer-smudge 形态）：BASE：F1-ATTRIBUTED: false——在已执行的植入之上报告 "scratch worktree could not be created: … reset died of signal 9 …"；FLIP（catch 内成对复读）：F1-ATTRIBUTED: true。修复：把 captured 提升出 try，在 catch 中先运行 localFilterBreach(worktree, 'the rebuild this command ran', captured.baseline) 再转为创建失败报告；命中即回滚并报告 breach 文本。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| createDetail = worktreeCreateFailureDetail( | ||
| 'probe', | ||
| e, | ||
| String(sweep?.stderr ?? ''), | ||
| ); |
There was a problem hiding this comment.
[Critical] R8-1 (location 3 of 3): the probe-creation catch converts every failure — including a checkout that THREW after executing a plant — into worktreeCreateFailureDetail with no paired breach re-read, while the success path below pairs the add with one. Same laundering shape as the other two locations: kill/stall smudge fires during the creation checkout, the spawn throws, the catch reports an ordinary create failure, the plant erases itself, and every later screen reads clean. base-tree's add catch carries the re-read this catch lacks. Witness: probe on the sibling scratch rebuild arm (identical catch shape): executed plant reported as an ordinary create failure without the re-read; attributed as a breach with it (flip). Fix: hoist captured above the try; in the catch, when captured.baseline !== null, run localFilterBreach(worktree, "the probe tree's creation", captured.baseline) and use the breach text as createDetail before the failure detail.
中文说明
R8-1（共 3 处，第 3 处）：probe 创建的 catch 把任何失败——包括「执行了植入之后才抛出」的 checkout——都转成 worktreeCreateFailureDetail，没有成对的 breach 复读，而其下方的成功路径却为 add 配了复读。与另外两处相同的洗白形态：kill/stall 型 smudge 在创建 checkout 中触发、spawn 抛出、catch 报告普通的创建失败、植入自我擦除、之后每次屏蔽都读到干净。base-tree 的 add catch 带有本 catch 缺少的复读。证据：同型 scratch rebuild 臂上的探针（catch 形态相同）：无复读时已执行的植入被报告为普通创建失败；加复读后归因为 breach（翻转）。修复：把 captured 提升出 try；在 catch 中，当 captured.baseline !== null 时运行 localFilterBreach(worktree, "the probe tree's creation", captured.baseline)，并优先用 breach 文本作为 createDetail。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| '-c', | ||
| 'core.fsmonitor=', | ||
| 'check-ignore', |
There was a problem hiding this comment.
[Critical] R8-8 (deadline aggregate, location 2 of 5): this hardened residue spawn (and its pathspec'd ls-files twin at :574) gained -c core.fsmonitor= but still carries no timeout, although this same chunk introduces GIT_TIMEOUT_MS precisely so a blocking candidate cannot hang the pipeline. Probe: worktreeResidue with include.path = planted hangs until the watchdog kills it (rc=124); a fix scoped to ONLY the two named spawns STILL hangs — the residue phase's rev-parse --show-toplevel and status spawns block first, so ALL residue-phase spawns need the deadline. Reachability: a direct scratch-tree invocation against a repo carrying a blocking include hangs in residue measurement BEFORE any screen can refuse; and under the PR's own threat model a surviving toggler swaps a config to a FIFO after the last screened re-read. Fix: timeout: GIT_TIMEOUT_MS on every residue-phase spawn; the existing r.error handling already reads a killed child as unmeasured.
中文说明
R8-8（期限聚合，共 5 处，第 2 处）：这个被加固的残留物 spawn（以及 :574 的带 pathspec 的 ls-files 同型）获得了 -c core.fsmonitor=，但仍然没有 timeout——而同一代码块引入 GIT_TIMEOUT_MS 恰恰是为了阻塞型候选不能挂死流水线。探针：植入 include.path = 后 worktreeResidue 挂起直到看门狗杀掉（rc=124）；只给这两个被点名的 spawn 加超时的修复仍然挂起——残留物阶段的 rev-parse --show-toplevel 与 status spawn 会先阻塞，因此所有残留物阶段 spawn 都需要期限。可达性：对携带阻塞型 include 的仓库直接调用 scratch-tree，会在任何屏蔽来得及拒绝之前挂在残留物测量上；按本 PR 自己的威胁模型，幸存的切换器也能在最后一次屏蔽复读之后把某个配置换成 FIFO。修复：残留物阶段的每个 spawn 都加 timeout: GIT_TIMEOUT_MS；既有的 r.error 处理已把被杀的子进程读作「无法测量」。
— qwen3.8-max via Qwen Code /review (v0.21.15)
There was a problem hiding this comment.
Deferred to the next round — round cap. This round implemented an 8-finding batch within the round cap; this finding is queued for the next round rather than dropped. The GIT_TIMEOUT_MS deadline for the timeout-less spawns is queued as one batch (mechanical but each site needs its own FIFO witness) so the fixes and their witnesses land together.
中文说明
推迟到下一轮 —— 每轮数量上限。本轮在每轮上限内实现了 8 个 finding；该 finding 已排入下一轮队列，不会被丢弃。 为无超时的 spawn 添加 GIT_TIMEOUT_MS 截止时间已作为一个批次排队（改动是机械性的，但每个位置都需要自己的 FIFO 见证），使修复与见证一起落地。
| // to the screen's full runtime. This narrows it back to one syscall — | ||
| // the same trade the hunk probe's pre-write re-check makes. | ||
| if (lstatSync(tree).isSymbolicLink()) return { ok: false }; | ||
| git(tree, 'checkout', '--force', '--detach', headSha); |
There was a problem hiding this comment.
[Critical] R8-8 (deadline aggregate, location 3 of 5): every gitOut spawn in this file — this guarded checkout, the identity gate's rev-parses, the rebuild's worktree add — carries no timeout (zero GIT_TIMEOUT_MS references in scratch-tree.ts), while the PR applies the deadline to its sibling spawns in worktree.ts with an explicit stall/FIFO rationale. A STALLING smudge (filter.x.smudge = sleep infinity — plantable via the disclosed global-config surface) makes spawnSync block forever: no status, no error, no catch, and the new catch-path breach attribution this round added is unreachable (the kill shape throws and reaches it; the stall shape never does). Witness (probe, real runScratchTree with a global stall filter): the child never returned — killed by a 25s watchdog, status=143, stdout empty; FLIP (timeout on gitOut): returned in ~13s, available=false with ETIMEDOUT surfaced through the existing throw path. Second shape: a FIFO at the scratch tree's admin commondir blocks the identity gate's rev-parse identically (strace: openat blocks). Fix: timeout: GIT_TIMEOUT_MS on gitOut; note the FIFO-at-commondir shape additionally needs deadlines on discardWorktree's spawns.
中文说明
R8-8（期限聚合，共 5 处，第 3 处）：本文件的每个 gitOut spawn——这个受守护的 checkout、身份门的 rev-parse、rebuild 的 worktree add——都没有 timeout（scratch-tree.ts 中 GIT_TIMEOUT_MS 零引用），而 PR 在 worktree.ts 的兄弟 spawn 上以明确的 stall/FIFO 理由应用了期限。卡死型 smudge（filter.x.smudge = sleep infinity——可经披露的全局配置面植入）会让 spawnSync 永远阻塞：无状态、无错误、不进 catch，本轮新增的 catch 路径 breach 归因因此不可达（kill 形态会抛出并到达；stall 形态永远不会）。证据（探针，真实 runScratchTree + 全局卡死过滤器）：子进程永不返回——被 25 秒看门狗杀掉，status=143、stdout 为空；FLIP（gitOut 加超时）：约 13 秒返回，available=false，ETIMEDOUT 经既有抛出路径上浮。第二形态：scratch 树管理目录 commondir 处的 FIFO 同样阻塞身份门的 rev-parse（strace：openat 阻塞）。修复：gitOut 加 timeout: GIT_TIMEOUT_MS；注意 FIFO-at-commondir 形态还需要 discardWorktree 的 spawn 也有期限。
— qwen3.8-max via Qwen Code /review (v0.21.15)
There was a problem hiding this comment.
Deferred to the next round — round cap. This round implemented an 8-finding batch within the round cap; this finding is queued for the next round rather than dropped. The GIT_TIMEOUT_MS deadline for the timeout-less spawns is queued as one batch (mechanical but each site needs its own FIFO witness) so the fixes and their witnesses land together.
中文说明
推迟到下一轮 —— 每轮数量上限。本轮在每轮上限内实现了 8 个 finding；该 finding 已排入下一轮队列，不会被丢弃。 为无超时的 spawn 添加 GIT_TIMEOUT_MS 截止时间已作为一个批次排队（改动是机械性的，但每个位置都需要自己的 FIFO 见证），使修复与见证一起落地。
| function git(cwd: string, ...args: string[]): void { | ||
| const r = spawnSync('git', args, { | ||
| const r = spawnSync('git', [...INERT_GIT_ARGS, ...args], { |
There was a problem hiding this comment.
[Critical] R8-8 (deadline aggregate, location 4 of 5): both git helpers this diff retouches (INERT_GIT_ARGS prefix) spawn with no timeout — the guarded worktree add and the reuse fast-path rev-parse HEAD. Witness (probe, both arms): arm 1 — global-config stall filter (the screen's disclosed limit) + committed attributes: the screen clears, the add blocks the smudge's entire duration (elapsed_ms=30055 for a call that otherwise takes <1s; sleep infinity never returns — event loop stalled in spawnSync, the paired breach re-read never runs, no report at all); arm 2 — reuse fast path with include.path = : runBaseTree never returns; a mid-hang process sample caught the exact spawn git -c core.hooksPath=… -c core.fsmonitor= rev-parse HEAD in wchan=wait_for_partner (FIFO open wait); watchdog rc=124. Fix: timeout: GIT_TIMEOUT_MS on both helpers; a timeout kill then throws through the existing r.error path, so the catch's paired breach re-read still runs.
中文说明
R8-8（期限聚合，共 5 处，第 4 处）：本 diff 触碰过的两个 git 助手（加 INERT_GIT_ARGS 前缀）的 spawn 都没有 timeout——受守护的 worktree add 与复用快路径的 rev-parse HEAD。证据（探针，两臂）：臂 1——全局配置卡死过滤器（屏蔽的披露限制）+ 已提交的 attributes：屏蔽干净通过，add 阻塞整个 smudge 时长（一次本应 <1 秒的调用 elapsed_ms=30055；sleep infinity 则永不返回——事件循环卡在 spawnSync，成对 breach 复读永不运行，完全没有报告）；臂 2——复用快路径 + include.path = ：runBaseTree 永不返回；挂起中的进程采样恰好抓到 git -c core.hooksPath=… -c core.fsmonitor= rev-parse HEAD 处于 wchan=wait_for_partner（等待 FIFO 打开）；看门狗 rc=124。修复：两个助手都加 timeout: GIT_TIMEOUT_MS；超时杀掉会经既有 r.error 路径抛出，catch 中的成对 breach 复读因此仍能运行。
— qwen3.8-max via Qwen Code /review (v0.21.15)
There was a problem hiding this comment.
Deferred to the next round — round cap. This round implemented an 8-finding batch within the round cap; this finding is queued for the next round rather than dropped. The GIT_TIMEOUT_MS deadline for the timeout-less spawns is queued as one batch (mechanical but each site needs its own FIFO witness) so the fixes and their witnesses land together.
中文说明
推迟到下一轮 —— 每轮数量上限。本轮在每轮上限内实现了 8 个 finding；该 finding 已排入下一轮队列，不会被丢弃。 为无超时的 spawn 添加 GIT_TIMEOUT_MS 截止时间已作为一个批次排队（改动是机械性的，但每个位置都需要自己的 FIFO 见证），使修复与见证一起落地。
| function git(cwd: string, ...args: string[]): void { | ||
| const r = spawnSync('git', args, { | ||
| const r = spawnSync('git', [...INERT_GIT_ARGS, ...args], { |
There was a problem hiding this comment.
[Critical] R8-8 (deadline aggregate, location 5 of 5): this file's git()/gitOut() helpers (both retouched by the diff for INERT_GIT_ARGS) and the raw spawns they wrap — the probe worktree add, the restore's checkout --force HEAD -- . (:1661), the revert's pathspec checkout (:3101), the hunk apply (:2156) — carry no timeout. INERT_GIT_ARGS neutralises hooks and fsmonitor but NOT content filters, so a stalling smudge still runs and blocks spawnSync forever: the whole review hangs with no output, and the new catch-path attribution is unreachable (the kill shape throws; the stall shape never does). Failure scenario: a toggler plants filter.x.smudge = sleep infinity (plus selecting attributes) in the screen→checkout window, or the suite plants it via the disclosed global surface; the guarded checkout executes it and never returns. Fix: timeout: GIT_TIMEOUT_MS on both helpers; the existing r.error/status handling converts a timeout kill into the thrown failure the catch paths report. (The sibling sites — worktree.ts discover/residue, scratch-tree gitOut, base-tree helpers — are the other four locations of this aggregate, each probe-witnessed.)
中文说明
R8-8（期限聚合，共 5 处，第 5 处）：本文件的 git()/gitOut() 助手（两者都被 diff 为 INERT_GIT_ARGS 触碰过）及其包裹的裸 spawn——探针 worktree add、restore 的 checkout --force HEAD -- .（:1661）、revert 的 pathspec checkout（:3101）、hunk apply（:2156）——都没有 timeout。INERT_GIT_ARGS 中和钩子与 fsmonitor，但不中和内容过滤器，因此卡死型 smudge 仍会运行并让 spawnSync 永远阻塞：整个审查无输出挂起，新的 catch 路径归因不可达（kill 形态会抛出；stall 形态永远不会）。失败场景：切换器在屏蔽→checkout 窗口内植入 filter.x.smudge = sleep infinity（加选中的 attributes），或套件经披露的全局面植入；受守护的 checkout 执行它并永不返回。修复：两个助手都加 timeout: GIT_TIMEOUT_MS；既有的 r.error/状态处理会把超时杀掉转成 catch 路径所报告的抛出失败。（兄弟站点——worktree.ts 的 discover/残留物、scratch-tree 的 gitOut、base-tree 的助手——是本聚合的另外四处，均有探针见证。）
— qwen3.8-max via Qwen Code /review (v0.21.15)
There was a problem hiding this comment.
Deferred to the next round — round cap. This round implemented an 8-finding batch within the round cap; this finding is queued for the next round rather than dropped. The GIT_TIMEOUT_MS deadline for the timeout-less spawns is queued as one batch (mechanical but each site needs its own FIFO witness) so the fixes and their witnesses land together.
中文说明
推迟到下一轮 —— 每轮数量上限。本轮在每轮上限内实现了 8 个 finding；该 finding 已排入下一轮队列，不会被丢弃。 为无超时的 spawn 添加 GIT_TIMEOUT_MS 截止时间已作为一个批次排队（改动是机械性的，但每个位置都需要自己的 FIFO 见证），使修复与见证一起落地。
| } | ||
| } | ||
| }; | ||
| for (const file of candidates) scan(file, 0); |
There was a problem hiding this comment.
[Critical] R8-9: the candidate scan is unbounded over attacker-writable directories, each blocking-FIFO candidate costs the full GIT_TIMEOUT_MS (120s), and this loop never stops once the verdict is sealed — refusal fires on ANY unclearable entry, but the refusal is only assembled after the loop returns. N planted FIFOs therefore delay the refusal by N × 120s; N=180 exceeds a 6-hour CI budget on a single screen, and the plant persists across retries (unregistered /worktrees/e dirs are never swept — discard/cleanup only remove the command's own trees, and git worktree prune does not touch unregistered dirs). Every review of the repository then dies in the job-level timeout without ever producing the refusal that names the plant — the exact 'hang every checkout it guards' outcome this hunk's timeout comment says it prevents, moved from one spawn to the aggregate. Escalation of round-5 Suggestion R5-18. Witness (probe, unpatched): two FIFO candidates → elapsedMs=240183 with both unclearables reported and a real plant key still found (the loop pays the full timeout per blocking candidate and never early-exits); standalone: spawnSync kills a FIFO-blocked git config at exactly the timeout (ETIMEDOUT). FLIP (early-exit once unclearable is non-empty): elapsedMs=120012 — one timeout instead of two. Fix: stop scanning once screen.unclearable is non-empty (truncating after the first cannot turn a refusal into a pass), and/or cap candidates.length with an unclearable entry when exceeded.
中文说明
R8-9：候选扫描在攻击者可写的目录上是无界的，每个阻塞型 FIFO 候选都要付出完整的 GIT_TIMEOUT_MS（120 秒），而这个循环在结论已经注定之后从不停下——拒绝在任何一条 unclearable 上都成立，但拒绝文本要等循环返回后才组装。因此 N 个植入的 FIFO 会把拒绝延迟 N × 120 秒；N=180 就超过 6 小时 CI 预算（仅一次屏蔽）；且植入跨重试留存（未注册的 /worktrees/e> 目录永不被清扫——discard/cleanup 只删除本命令自己的树，git worktree prune 不碰未注册目录）。该仓库的每次审查都会死在作业级超时里，永远产生不了点名植入的那条拒绝——正是本代码块超时注释声称要防止的「挂死它所守护的每次 checkout」结局，只是从单个 spawn 搬到了总量上。此为第 5 轮 Suggestion R5-18 的升级。证据（探针，未修补代码）：两个 FIFO 候选 → elapsedMs=240183，两条 unclearable 均被报告、真实植入围仍被找到（循环为每个阻塞候选付满超时、从不提前退出）；独立验证：spawnSync 在恰好超时点杀掉被 FIFO 阻塞的 git config（ETIMEDOUT）。FLIP（unclearable 非空即提前退出）：elapsedMs=120012——一次超时而非两次。修复：screen.unclearable 非空即停止扫描（在第一条之后截断不可能把拒绝变成放行），和/或对超出上限的 candidates.length 推入 unclearable 条目。
— qwen3.8-max via Qwen Code /review (v0.21.15)
|
🔀 Base updated: red check(s) [Test (ubuntu-latest, Node 22.x)] pass on current main — merged current main via update-branch; CI will re-run. 中文说明🔀 已更新 base：红色检查 [Test (ubuntu-latest, Node 22.x)] 在当前 main 上通过 —— 已通过 update-branch 合入当前 main，CI 将重新运行。 |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Partially reviewed — gaps disclosed.
Not reviewed: build-and-test — Test (windows-latest, Node 22.x) and Test (macos-latest, Node 22.x) were skipped in CI and their platform-specific suites did not run locally.
Deferred under the convergence posture (round 9, not a blocker) — recorded, not requested in this round:
packages/cli/src/commands/review/test-efficacy.ts:2700 — [review] created=true set before the breach re-read — fail-open if the re-read ever throws (latent; no reachable throw today)packages/cli/src/commands/review/fetch-pr.ts:986 — [probe] comment 'nothing executes unscreened before it' is false for core.sshCommand/credential.helper on the pipeline's fetches (screen's declared scope boundary)packages/cli/src/commands/review/lib/worktree.test.ts:126 — [probe] fsmonitor tripwire embeds an unquoted platform path — negative assertion vacuous on Windows lanespackages/cli/src/commands/review/base-tree.ts:330 — [probe] catch-path breach branch skips the discardWorktree rollback; breached tree left registeredpackages/cli/src/commands/review/base-tree.test.ts:482 — [probe] inert fixture's marker commands embed unquoted backslash paths — vacuous negatives on Windowspackages/cli/src/commands/review/scratch-tree.test.ts:131 — [probe] negative-control markers unquoted (:131/:348/:375) — vacuous on Windows lanespackages/cli/src/commands/review/test-efficacy.integration.test.ts:1992 — [probe] three negative-control markers unquoted (:1992/:2041/:2090) — vacuous on Windows lanespackages/cli/src/commands/review/test-efficacy.test.ts:709 — [probe] INCLUDE armer embeds unquoted ${evilSh} — word-splits on space-bearing tmpdirs (loud red on that host profile)packages/cli/src/commands/review/lib/worktree.ts:823 — [probe] ENOTDIR treated as unclearable wedges every screen until a human deletes the stray plain filepackages/cli/src/commands/review/scratch-tree.test.ts:376 — [probe] hook/fsmonitor inert markers unquoted — vacuous negatives on Windows lanespackages/cli/src/commands/review/lib/worktree.ts:1275 — [review] ctime invariant false on coarse-granularity filesystems; the residual is undisclosed (sibling appear-and-vanish limit is)packages/cli/src/commands/review/test-efficacy.integration.test.ts:2427 — [review] relink test's override delegates to real with two args — drops the capture object the seam comment warns about
中文说明
仅完成部分审查，审查缺口已披露。
未审查：build-and-test — Test (windows-latest, Node 22.x) and Test (macos-latest, Node 22.x) were skipped in CI and their platform-specific suites did not run locally。
收敛姿态下延后（第 9 轮，非阻断）——已记录，本轮不要求修改：共 12 条（原文未翻译，列表见上方英文部分）。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| // shared with every suite run, which this round deliberately does not | ||
| // add. | ||
| if ( | ||
| localFilterRefusal(worktree, 'the reset this command runs', captured) !== |
There was a problem hiding this comment.
[Critical] R4-1 (round 9, re-posted under the original id): the screens remain one-shot config reads authorising checkouts against a concurrent writer the pipeline itself schedules, and nothing serialises the common dir — no shared advisory lock across the screen+checkout pairs or around the suite spawns. Round 9 independently re-derived the same window at five further sites (restore, apply, revert, creation — R9-3/R9-4/R9-8/R9-9), and every probe since round 4 has reproduced exploitation. Still escalated to a maintainer: closure is the execution-model decision, and per-site patches only narrow the window.
Witness: round-8 probe re-measured the exploit at this file's sites; the code is byte-identical since (delta after round 8 is a merge of main only).
中文说明
R4-1（第 9 轮，按原 id 重新发布）：屏蔽仍是一次性配置读取，为流水线自己调度的并发写者所授权的 checkout 放行，而 common 目录没有任何串行化——屏蔽+checkout 配对之间、套件 spawn 周围都没有共享咨询锁。第 9 轮在另外五个站点（restore、apply、revert、creation，见 R9-3/R9-4/R9-8/R9-9）独立重新推导出同一窗口；自第 4 轮以来每次探针都复现了利用。已升级给维护者：闭合需要执行模型决策，逐站点修补只能收窄窗口。
证据：第 8 轮探针在本文件站点重新实测了该利用；此时代码逐字节未变（第 8 轮之后的差异仅为合并 main）。
— qwen3.8-max via Qwen Code /review (v0.21.15)
There was a problem hiding this comment.
Still escalated to the maintainer — this is a maintainer decision, not a change to implement or decline unilaterally: the advisory lock binds only cooperative writers, and whether the reap's serialization is still needed (and what replaces it if not) changes the shape of every remaining fix in this class. The round-7 escalation thread stays open; no code change this round.
中文说明
继续升级给维护者 —— 这是需要维护者决策的事项，不能单方面实现或拒绝：advisory lock 只约束合作型写入者，reap 的串行化是否仍然必要（以及若不需要时用什么替代）会改变该类所有剩余修复的形态。第 7 轮的升级线程保持打开；本轮不做代码变更。
| const at = seen.get(dedupe); | ||
| if (at !== undefined && at <= depth) return; | ||
| seen.set(dedupe, depth); | ||
| if (!existsSync(file)) { |
There was a problem hiding this comment.
[Critical] R7-6 (round 9, re-posted under the original id): the appear-and-vanish half remains open — a config file CREATED after the screen, EXECUTED by the guarded checkout, and DELETED before the re-read is invisible to both halves of localFilterBreach (never baselined; changedScreenedFiles iterates only baselined files). The LocalFilterBaseline docstring discloses it as residual, but the detection gap stands: round 9's probes re-proved the adjacent un-baselined-new-admin variant end-to-end (R9-1: self-erasing plant in the new tree's own config.worktree → breach null; race won 60/60).
Witness: round-8 probe confirmed the shape; code byte-identical since.
中文说明
R7-6（第 9 轮，按原 id 重新发布）：出现-消失半区仍然开放——屏蔽之后创建、受守护 checkout 执行、复读之前删除的配置文件，对 localFilterBreach 的两个半区都不可见（从未入基线；changedScreenedFiles 只遍历已入基线的文件）。LocalFilterBaseline 的文档已将其披露为残留，但检测缺口仍在：第 9 轮探针端到端重新证明了相邻的"新管理目录未入基线"变体（R9-1：新树自身 config.worktree 中的自擦除植入 → breach 为 null；竞态 60/60 命中）。
证据：第 8 轮探针确认该形态；此时代码逐字节未变。
— qwen3.8-max via Qwen Code /review (v0.21.15)
There was a problem hiding this comment.
Deferred to the next round: the general appear-and-vanish hardening depends on the R4-1 serialization decision, which is still with the maintainer; the partial mitigation that does not depend on it (baseline seeding of the predicted admin entry) is queued with its R8-5/R9-1 twins. The residual stays disclosed in the function docstring.
中文说明
推迟到下一轮：通用的“出现又消失”加固依赖 R4-1 的串行化决策，该决策仍在维护者处；其中不依赖该决策的部分缓解（将预测的管理条目播种进基线）已与其 R8-5/R9-1 同族项一起排队。残余风险继续在该函数的 docstring 中披露。
| // read and the add's own config read, and the initial checkout executes | ||
| // the plant while both reads see nothing. A key that APPEARED is | ||
| // reported as a breach — the run is breached, never certified clean. | ||
| const filterBreach = localFilterBreach( |
There was a problem hiding this comment.
[Critical] R8-1 (round 9, re-posted under the original id): the worktree-add CATCH path still has no paired breach re-read — the quoted re-read runs only on the success path. A plant that FIRES during the add's initial checkout and then makes the add throw is reported as an ordinary add failure; the plant having erased itself, the next run screens clean. Round-9 verifier re-proved the identical catch-gap class end-to-end at the scratch rebuild catch: plant fired, spawn threw, the note stayed routine until the catch gained the paired re-read (then flips to 'may have EXECUTED').
Suggested fix: in the catch, before throwing the creation error — if (captured.baseline !== null) { const breach = localFilterBreach(process.cwd(), 'the review worktree add this command ran', captured.baseline); if (breach !== null) throw new Error(breach); }
中文说明
R8-1（第 9 轮，按原 id 重新发布）：worktree add 的 CATCH 路径仍没有配对的 breach 复读——所引用的复读只在成功路径运行。在 add 初始 checkout 期间触发、随后使 add 抛错的植入，会被报告为普通的 add 失败；植入自擦除后，下一次运行的屏蔽读到干净。第 9 轮验证者在 scratch rebuild 的 catch 处端到端重新证明了同一 catch 缺口类：植入触发、spawn 抛错、报告仍是例行创建失败，直到 catch 获得配对复读（随后翻转为 'may have EXECUTED'）。
建议修复：在 catch 中抛出创建错误之前——if (captured.baseline !== null) { const breach = localFilterBreach(process.cwd(), 'the review worktree add this command ran', captured.baseline); if (breach !== null) throw new Error(breach); }
— qwen3.8-max via Qwen Code /review (v0.21.15)
| const breach = localFilterBreach( | ||
| worktree, | ||
| 'the rebuild this command ran', |
There was a problem hiding this comment.
[Critical] R8-2 (round 9, re-posted under the original id): the rebuild's CATCH path still returns the plain create-failure note without a paired breach re-read (captured is declared inside the try, out of scope at the catch). A killer smudge that fires during the rebuild add's initial checkout is laundered as an ordinary create failure; the next call screens clean. Round-9 probe: plant fired, the add threw 'reset died of signal 9', note routine; with a hoisted baseline and the re-read in the catch, the note flips to 'may have EXECUTED'.
中文说明
R8-2（第 9 轮，按原 id 重新发布）：rebuild 的 CATCH 路径仍返回普通的创建失败注记，没有配对的 breach 复读（captured 声明在 try 内，catch 处不可见）。在 rebuild add 初始 checkout 期间触发的杀手 smudge 会被洗成普通创建失败；下一次调用屏蔽读到干净。第 9 轮探针：植入触发、add 抛出 'reset died of signal 9'、注记例行；将基线提升到 try 外并在 catch 中加入复读后，注记翻转为 'may have EXECUTED'。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| // shared tree. Probes are inconclusive; the unreachable findings, which | ||
| // need no probe, still ship. | ||
| const detail = worktreeCreateFailureDetail( | ||
| createDetail = worktreeCreateFailureDetail( |
There was a problem hiding this comment.
[Critical] R8-3 (round 9, re-posted under the original id): the probe-creation catch still converts every failure into worktreeCreateFailureDetail with no paired breach re-read (captured is out of scope at the catch). Same laundering shape: a killer smudge fired during the creation checkout is reported as an ordinary create failure; the plant having erased itself, the next run screens clean.
中文说明
R8-3（第 9 轮，按原 id 重新发布）：探针创建的 catch 仍将一切失败转换为 worktreeCreateFailureDetail，没有配对的 breach 复读（captured 在 catch 处不可见）。同样的洗白形态：创建 checkout 期间触发的杀手 smudge 被报告为普通创建失败；植入自擦除后，下一次运行屏蔽读到干净。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| // code is defending against, so it is emptied here the way every other | ||
| // checkout in this pipeline empties it. | ||
| const runRestore = (op: string, args: string[]): string | null => { | ||
| const r = spawnSync('git', args, { |
There was a problem hiding this comment.
[Critical] R9-10 (location 2 of 3; twins: fetch-pr.ts:999, base-tree.ts:314): runRestore's checkout/clean spawns carry no timeout — and the entry rev-parse (:1583), the bits ls-files (:1712), and the hunk git apply --reverse (~:2156) are the same shape. A FIFO include-target planted into the common config AFTER the screen returned clean hangs the guarded spawn forever: spawnSync never returns, the paired breach re-read never runs, and restoreProbeTreeTracked — called before the baseline, every mutant, every hunk probe and the positive control — wedges the whole review with no budget bounding it.
Witness: probe — FIFO include.path: git checkout --force HEAD -- . rc=124 (blocked until killed); plain target rc=0.
Suggested fix: timeout: GIT_TIMEOUT_MS on these spawns, with the same fail-closed reading the screen applies to a killed child.
中文说明
R9-10（共 3 处，第 2 处；孪生：fetch-pr.ts:999、base-tree.ts:314）：runRestore 的 checkout/clean spawn 没有 timeout——入口 rev-parse（约 :1583）、位图 ls-files（约 :1712）、hunk 的 git apply --reverse（约 :2156）同形。屏蔽返回干净之后植入 common 配置的 FIFO include 目标会让受守护 spawn 永久挂起：spawnSync 永不返回、配对的 breach 复读永不运行，而 restoreProbeTreeTracked——在基线、每个突变体、每个 hunk 探针与正向对照之前都被调用——会在没有任何预算约束的情况下楔住整个审查。
证据：探针——FIFO include.path：git checkout --force HEAD -- . rc=124（阻塞至被杀）；普通目标 rc=0。
建议修复：这些 spawn 加 timeout: GIT_TIMEOUT_MS，对被杀子进程按屏蔽的失败关闭方式读取。
— qwen3.8-max via Qwen Code /review (v0.21.15)
There was a problem hiding this comment.
Deferred to the next round — round cap. This round implemented an 8-finding batch within the round cap; this finding is queued for the next round rather than dropped. Queued with the R8-8 timeout batch (the rollback / runRestore / discardWorktree spawns).
中文说明
推迟到下一轮 —— 每轮数量上限。本轮在每轮上限内实现了 8 个 finding；该 finding 已排入下一轮队列，不会被丢弃。 已与 R8-8 超时批次一起排队（rollback / runRestore / discardWorktree 的 spawn）。
| captured.baseline, | ||
| ); | ||
| if (breach !== null) { | ||
| discardWorktree(worktree, tree); |
There was a problem hiding this comment.
[Critical] R9-10 (location 3 of 3; twins: fetch-pr.ts:999, test-efficacy.ts:1647): the breach-rollback call runs discardWorktree — whose git spawns (worktree remove --force, unlock, remove --force --force, plus dropWorktreeRegistration's rev-parse fallback) carry NO timeout — BEFORE returning the already-computed breach report. A FIFO planted where git's config read follows it blocks the rollback forever: the detected breach is never reported, the command hangs, and the finally rmSync(lock) never runs — the build lock leaks until the 30-minute stale sweep.
Witness: probe — with /config replaced by a FIFO, timeout 5 git worktree remove --force wt → exit=124.
Suggested fix: give discardWorktree's spawns timeout: GIT_TIMEOUT_MS, AND wrap the rollback so the breach note returns regardless (const note = breach; try { discardWorktree(worktree, tree); } catch {} return unavailable(note);).
中文说明
R9-10（共 3 处，第 3 处；孪生：fetch-pr.ts:999、test-efficacy.ts:1647）：breach 回滚调用在返回已经算好的 breach 报告之前运行 discardWorktree——其 git spawn（worktree remove --force、unlock、remove --force --force，外加 dropWorktreeRegistration 的 rev-parse 回退）都没有 timeout。植入在 git 配置读取会跟随之处的 FIFO 会永久阻塞回滚：已检测到的 breach 永不被报告、命令挂起、finally 的 rmSync(lock) 永不执行——构建锁泄漏直到 30 分钟的陈旧清扫。
证据：探针——/config 被换成 FIFO 时，timeout 5 git worktree remove --force wt → exit=124。
建议修复：给 discardWorktree 的 spawn 加 timeout: GIT_TIMEOUT_MS，并包裹回滚使 breach 注记无论如何都返回（const note = breach; try { discardWorktree(worktree, tree); } catch {} return unavailable(note);）。
— qwen3.8-max via Qwen Code /review (v0.21.15)
There was a problem hiding this comment.
Deferred to the next round — round cap. This round implemented an 8-finding batch within the round cap; this finding is queued for the next round rather than dropped. Queued with the R8-8 timeout batch (the rollback / runRestore / discardWorktree spawns).
中文说明
推迟到下一轮 —— 每轮数量上限。本轮在每轮上限内实现了 8 个 finding；该 finding 已排入下一轮队列，不会被丢弃。 已与 R8-8 超时批次一起排队（rollback / runRestore / discardWorktree 的 spawn）。
| if (!includeKey.test(key)) { | ||
| if (!screen.keys.includes(key)) screen.keys.push(key); | ||
| continue; | ||
| } |
There was a problem hiding this comment.
[Critical] R9-11: per-record key dedup is quadratic (Array.includes per record) — a padded plant of distinct filter.<name>.clean entries (up to ~3.7M records under the 64 MiB maxBuffer, via one include.path write) stalls the synchronous screen for HOURS: a one-write persistent DoS of every review of this repository, in the pure-JS loop no spawn timeout reaches. The plant persists in the common dir across every later review until edited by hand.
Witness: measurements on the unmodified function — 10k keys → 1.1s; 20k → 2.5s; 40k → 13.2s; 80k → 65s (each doubling ~5×); the ceiling extrapolates to ~17-38 hours. The suite's overflow test only covers output ABOVE 64 MiB (ENOBUFS → unclearable); the quadratic window sits just below it.
Suggested fix: track membership in a Set beside the array at all three includes sites (const seenKeys = new Set<string>(); if (!seenKeys.has(key)) { seenKeys.add(key); screen.keys.push(key); }).
中文说明
R9-11：逐记录键去重是平方复杂度（每条记录 Array.includes）——用互不相同的 filter.<name>.clean 条目填充的植入（64 MiB maxBuffer 之下最多约 370 万条，一次 include.path 写入）会把同步屏蔽卡住数小时：对本仓库每次审查的一次写入持久 DoS，且位于任何 spawn timeout 都够不到的纯 JS 循环。植入持久存在于 common 目录，跨越之后每次审查，直到人工编辑。
证据：对未修改函数的实测——1 万键 → 1.1 秒；2 万 → 2.5 秒；4 万 → 13.2 秒；8 万 → 65 秒（每次翻倍约 5 倍）；上限外推约 17-38 小时。套件的溢出测试只覆盖 64 MiB 以上（ENOBUFS → unclearable）；平方窗口恰在其下方。
建议修复：在三处 includes 站点用 Set 并行跟踪成员资格（const seenKeys = new Set<string>(); if (!seenKeys.has(key)) { seenKeys.add(key); screen.keys.push(key); }）。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| captured.baseline, | ||
| ); | ||
| if (breach !== null) { | ||
| discardWorktree(worktree, tree); |
There was a problem hiding this comment.
[Critical] R9-13: the rebuild's breach rollback runs INSIDE the same try whose catch converts everything to the ordinary create-failure note — a rollback that THROWS (rmSync EPERM/EBUSY — force suppresses ENOENT only) silently discards an already-DETECTED breach, and the breached tree stays for the next call to certify. Distinct from R8-2: there the add throws and no re-read runs; here the re-read ran and DETECTED, and the detection itself is what gets dropped. The rollback's timeout-less spawns are R9-10's class (a FIFO turns the throw into a hang).
Witness: probe with flip — mode-555 LOCK dir + self-erasing plant: unmodified code reports the routine create failure ('scratch worktree could not be created: EACCES…') and the next call returns available:true with a certified tree; wrapping the rollback (breach note returned regardless) flips the note to 'may have EXECUTED'.
Suggested fix: if (breach !== null) { try { discardWorktree(worktree, tree); } catch { /* breach note is the report */ } return { ...note: breach }; }
中文说明
R9-13：rebuild 的 breach 回滚运行在同一个 try 内，而其 catch 把一切转换为普通创建失败注记——回滚抛错（rmSync EPERM/EBUSY——force 只压制 ENOENT）会静默丢弃已检测到的 breach，被 breach 的树留下来等下一次调用认证。与 R8-2 不同：那里是 add 抛错、复读未运行；这里是复读运行且检测到了，被丢弃的正是检测结果本身。回滚那些无 timeout 的 spawn 属 R9-10 类（FIFO 会把抛错变成挂起）。
证据：带翻转的探针——555 模式 LOCK 目录 + 自擦除植入：未修改代码报告例行创建失败（'scratch worktree could not be created: EACCES…'），下一次调用返回 available:true 并带认证树；包裹回滚（无论如何返回 breach 注记）后注记翻转为 'may have EXECUTED'。
建议修复：if (breach !== null) { try { discardWorktree(worktree, tree); } catch { /* breach 注记即报告 */ } return { ...note: breach }; }
— qwen3.8-max via Qwen Code /review (v0.21.15)
| // the same reason the escape re-check sits there: a pointer | ||
| // swapped during the screen's spawns aims this checkout at | ||
| // whatever it names. | ||
| if (localFilterIdentityMoved(probeTree, captured.baseline)) { |
There was a problem hiding this comment.
[Critical] R9-14: the pinned identity is --git-common-dir ONLY — shared by every worktree of the repository — so a swap of probeTree/.git to a SIBLING worktree's gitdir is invisible to every half, and the revert checkout corrupts the sibling review worktree's INDEX while the phase certifies clean. No timing, no restore: the guest suite owns its cwd and writes the gitfile once (labels attacker-derivable); the revert site has no backpointer check — the check that catches exactly this shape exists in restoreProbeTreeTracked and scratch reset, not here.
Witness: probe (no race needed) — commondir seen through the swap == the original repo's; git checkout <BASE> -- f.ts in the swapped tree → probe tree got base content, review worktree's file kept head content, git status --porcelain → MM f.ts, index entry == BASE:f.ts blob.
Suggested fix: pin the per-worktree gitdir alongside the commondir (capture rev-parse --path-format=absolute --git-dir realpath into LocalFilterBaseline and compare it in localFilterIdentityMoved/localFilterBreach), or baseline the .git pointer file itself (content/ctime).
中文说明
R9-14：被钉住的身份只有 --git-common-dir——为仓库的每个工作树共享——因此把 probeTree/.git 换到兄弟工作树的 gitdir 对所有半区都不可见，而 revert checkout 会腐蚀兄弟 review 工作树的索引，阶段却认证干净。无需时序、无需恢复：客户套件拥有自己的 cwd，写一次 gitfile 即可（标签可被攻击者推导）；revert 站点没有反向指针检查——恰好能捕获该形态的检查存在于 restoreProbeTreeTracked 与 scratch reset，这里没有。
证据：探针（无需竞态）——透过交换看到的 commondir == 原仓库；在交换树中 git checkout <BASE> -- f.ts → 探针树得到 base 内容，review 工作树文件保持 head 内容，git status --porcelain → MM f.ts，索引条目 == BASE:f.ts 的 blob。
建议修复：把 per-worktree gitdir 与 commondir 一起钉住（把 rev-parse --path-format=absolute --git-dir 的 realpath 记入 LocalFilterBaseline，并在 localFilterIdentityMoved/localFilterBreach 中比较），或把 .git 指针文件本身（内容/ctime）入基线。
— qwen3.8-max via Qwen Code /review (v0.21.15)
There was a problem hiding this comment.
Deferred to the next round — round cap. This round implemented an 8-finding batch within the round cap; this finding is queued for the next round rather than dropped. The pinned-identity common-dir-only gap is queued.
中文说明
推迟到下一轮 —— 每轮数量上限。本轮在每轮上限内实现了 8 个 finding；该 finding 已排入下一轮队列，不会被丢弃。 固定身份仅覆盖 common-dir 的缺口已排队。
|
🤖 Addressed the latest review feedback (round 3/100). What changed, and what I pushed back on: · 已处理最新评审反馈（第 3/100 轮）。改动内容与我反驳保留之处如下： Round summary — PR #9566 (review filter-screen test efficacy)This round implemented an 8-finding batch within the per-round cap (~8 findings), choosing the Critical findings that were checkable, reproducible on this runner, and had deterministic witness shapes. The remaining 35 inline findings are deferred to the next round with a reply on each thread ( Commit: Resolved (17 inline comments across 8 findings)
Deferred (35 inline comments — replies posted on each thread)
VerificationAll commands actually run this round (results):
Mutation probes (each new guard temporarily removed/negated, its focused witness re-run, then restored):
Notes: the R8-3 witness needed two fixture repairs found during the mutation pass — the breach seam override must gate on the apply's context (the restore's earlier paired re-read consumes it otherwise), and a git-generated patch must keep its trailing newline ( No settings source changed, so 中文说明轮次总结 — PR #9566（review filter-screen 测试有效性）本轮在每轮上限（约 8 个 finding）内实现了一批 8 个 finding，选取的是可检验、可在本 runner 上复现、且具有确定性见证形态的 Critical finding。其余 35 条 inline finding 推迟到下一轮，并在各自线程下回复（ 提交： 已解决（8 个 finding，共 17 条 inline 评论）
推迟（35 条 inline 评论 — 每条线程下均已回复）
验证本轮实际运行的全部命令（结果）：
变异探针（将每个新守卫临时移除/取反，重跑其聚焦见证，再恢复）：
说明：R8-3 的见证在变异过程中需要修复两个 fixture 缺陷 — breach 缝隙覆盖必须按 apply 的上下文过滤（否则会被 restore 更早的成对再读取消耗），且 git 生成的补丁必须保留结尾换行（ 未改动任何配置源，因此无需运行 Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 Re-review when you have a moment. After round 100 this bot stops and leaves the PR for a human. · 有空请复审；第 100 轮后本 bot 停止并将 PR 交给人工。 🧠 Handled by Qwen Code · model/模型 |
wenshao
removed
the
autofix/takeover
|
👋 Takeover released: the autofix loop will no longer engage this PR (an in-flight round, if any, completes its bounded work). Re-apply 中文说明👋 已释放：autofix 循环不再介入此 PR（在飞的一轮如有，将完成其有界工作）。重新打上 |
|
Superseded by #9741, which is this PR's first commit and nothing else — 5 files, +160. This one grew to 13 files and +3 054, reaching into Closing rather than force-pushing, so the review history here stays readable. One finding from it is carried forward explicitly rather than dropped: 中文说明由 #9741 取代——那是本 PR 的第一个提交，别无其他：5 文件、+160。 本 PR 已涨到 13 文件、+3 054，伸进了 选择关闭而非 force-push，以保住这里的评审历史可读。其中一条发现被显式带走而不是丢弃： |
4 participants
What this PR does
scratch-treerefuses to create or reset a tree while the repository's local config defines a content filter: a checkout executesfilter.<name>.smudgewhenever it rewrites a file, and pointingcore.hooksPathat nothing covers hooks, not filters.test-efficacy's per-run restore is the same checkout one directory over —checkout --force HEAD -- .rewrites every tracked file in the probe tree, twice per probe run — and it screened nothing.Three changes:
inconclusiverather than executing the filter.lib/worktree.ts, so both callers share one implementation instead of one growing a corner the other lacks. That is not hypothetical: the screen used to read only the review worktree'sconfig.worktreewhile the checkout it authorised ran in the scratch tree, whose own per-worktree config it never opened.filter.<name>.processjoinssmudgeandclean— the third executable key, a long-running filter git speaks a protocol to. Enumerating two of three is how the first cut read as complete.Why it's needed
The planting surface is two plain writes into the common dir —
git config filter.evil.smudge CMDand one line ininfo/attributes— and nothing in this pipeline wipes the common dir, so a filter planted while reviewing one PR fires on every later matching checkout of the user's own repository.scratch-treerefuses that; the probe tree ran through it.Repo-local only, and that is the load-bearing part of the design.
git lfs installwritesfilter.lfs.cleaninto the user's GLOBAL config. A screen over merged config would put every contributor with git-lfs into permanent refusal — the same failure as a tripwire that fires on every healthy run, which this pipeline has already shipped once (#9221 round 15:git statusreported nothing while the tripwire reported 3 957 paths). A guard that fires on every healthy run is not read.Reviewer Test Plan
How to verify
cd packages/cli && npx vitest run src/commands/review→ 3 941 passed, 1 skipped, 0 failed.New coverage in
test-efficacy.test.ts: a repo-localfilter.evil.smudgemakes the mutant runinconclusivenaming the filter; the same fixture with the filter moved to the user's global config runs through without a filter refusal.scratch-tree.test.tsgains thefilter.evil.processarm.Evidence (Before & After)
Each half was verified by reverting it alone and watching the test go red:
test-efficacy--filedropped)processfrom the key regexfilter.evil.processno longer refusesThe middle row is the one worth reading: it is the false-positive direction, and without a test it is the change a later round would make while "tightening" the screen.
Tested on
macOS 26.6 (Darwin 25.6.0), Node 24,
packages/clivitest 3.2.4.Risk & Scope
Small and confined to
packages/cli/src/commands/review. The behavioural change is one new refusal path in the efficacy probe: a repository whose local config carries a content filter now reportsinconclusivefor that run instead of running the filter. No user-facing surface.Linked Issues
Closes #9558. Follow-up from #9221; the class it belongs to is #9556.
中文说明
这个 PR 做了什么
scratch-tree在仓库本地配置定义了内容过滤器时，拒绝创建或重置树：checkout 每次重写文件都会执行filter.<name>.smudge，而把core.hooksPath指向空处只覆盖钩子，覆盖不到过滤器。test-efficacy每次运行前的恢复，是同一种 checkout 挪了一个目录——checkout --force HEAD -- .会重写探针树里每一个已跟踪文件，每次探针运行两次——而它什么也没屏蔽。三处改动：
inconclusive，而不是去执行那个过滤器。lib/worktree.ts，让两个调用方共用一份实现，而不是其中一个长出另一个没有的角落。这不是假想：该屏蔽此前只读 review 工作树的config.worktree，而它所授权的 checkout 跑在 scratch 树里，那棵树自己的 per-worktree 配置从未被打开过。filter.<name>.process与smudge、clean并列——第三个可执行键（git 与之按协议通信的常驻过滤器）。三个里枚举两个，正是第一版读起来"像是完整的"的原因。为什么需要
投毒面是向 common 目录写两次普通写入——
git config filter.evil.smudge CMD与info/attributes里的一行——而本流水线不会清扫 common 目录，因此审查某个 PR 时植入的过滤器，会在用户自己仓库之后每一次匹配的 checkout 上触发。scratch-tree拒绝这一点；而探针树径直穿了过去。只看仓库本地配置，这是该设计的承重部分。
git lfs install会把filter.lfs.clean写进用户的全局配置。若屏蔽读取合并后的配置，就会让每一个装了 git-lfs 的贡献者永久处于拒绝态——与"每次健康运行都触发的绊线"是同一种失败，而本流水线已经犯过一次（#9221 第 15 轮：git status一条没有，绊线报 3 957 条路径）。每次健康运行都触发的守卫，没有人读。审查者验证方案
如何验证
cd packages/cli && npx vitest run src/commands/review→ 3 941 通过、1 跳过、0 失败。test-efficacy.test.ts新增覆盖：仓库本地的filter.evil.smudge让突变体运行判为inconclusive并点名该过滤器；同一夹具把过滤器改放到用户全局配置后，运行照常通过、不产生过滤器拒绝。scratch-tree.test.ts增加filter.evil.process一臂。证据（Before & After）
每一半都以"单独回退该项 → 对应测试变红"验证：
test-efficacy移除该屏蔽--file）processfilter.evil.process不再被拒绝中间那一行最值得看：它是误报方向；没有这条测试，它正是后来某一轮在"收紧"屏蔽时会做出的改动。
测试环境
macOS 26.6（Darwin 25.6.0）、Node 24、
packages/clivitest 3.2.4。风险与范围
小，且限于
packages/cli/src/commands/review。行为变化只有一条新的拒绝路径：本地配置带内容过滤器的仓库，该次运行报inconclusive而不是执行过滤器。无用户可见面。关联 Issue
Closes #9558。来自 #9221 的后续；其所属类别是 #9556。