fix(runtime): end Grep options before the pattern in the sandboxed worker

[udsy19]

fix(runtime): end Grep options before the pattern in the sandboxed worker

Summary

The filesystem worker appended the model-supplied Grep pattern as a bare
positional, so ripgrep parsed a pattern starting with - as flags.
-webkit-box exits 1, and packages/runtime/src/filesystem-worker/operations.ts:425
maps exit 1 to { kind: 'grep', matches: [] } — the model is told the string is
absent from a file that contains it, silently.

The host-local sibling already passes -- first
(packages/runtime/src/workspace-executor.ts:455). That separator arrived in
#2961, which edited this worker's grep case in the same commit but left its argv
unchanged, so the two search paths have disagreed since. This propagates it.

Fixes#3733

Verification

Ran locally on macOS 26.5.1 (25F80), Node v26.7.0, ripgrep 15.1.0:

• npm --workspace @maka/runtime run test:dist — 3090 tests, 0 failures
  (baseline on main was 3089/0; the delta is the new case).
• Negative control: restored operations.ts from origin/main and rebuilt — the
  new test fails (actual [… '--max-count=50', '-webkit-box', …] vs expected
  ['--', '-webkit-box', …]) while the other 20 cases in the file still pass.
• npm run lint, npm run format:check, npm run typecheck,
  npm run check:asf-headers — all clean.

Not run: Windows and Linux sandbox surfaces.

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Claude Code — located the divergence, drafted the one-line fix
and the regression test. Reviewed, reproduced and verified by me before submitting.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[M4n5ter]

Relationship note: PRs #3734, #3735, and #3903 all close #3733, touch the same two runtime files, and apply the same -- separator fix to the sandboxed Grep invocation. I could not find a canonical/supersede statement in these PR bodies or comments. At the current snapshot, #3903 is the latest-created candidate, but the owner should decide the canonical PR. Please document that relationship and mark the other attempts as superseded/close them, or explain the distinct scope, so the issue is not merged three times.

This comment records the relationship only; it is not a merge decision.

---

Automated review note posted by @未开智选手. This is not an independent human review; a human should verify the conclusion.

[M4n5ter]

Thank you for working on this fix. I compared this implementation with #3735 and #3903. All three correctly address the same root cause by placing the user-controlled pattern after ripgrep's -- option terminator.

#3903 was selected because its regression pins both the exact terminal argv order (['--', pattern, path]) and the full worker response with the smallest production patch. It has now been merged as 07e40feed27e748870b8144b3e37bf96c2748c52, so this equivalent implementation is superseded and I am closing it to keep one canonical fix.

---

Posted by an automated review agent operated by @M4n5ter. This is not an
independent human review and does not satisfy the committer review required by
CONTRIBUTING.md. A human is accountable for this comment — please push back if
anything here is wrong.

简体中文

本条评论由 @M4n5ter 运行的自动化审查程序发出。它不构成 CONTRIBUTING.md
所要求的独立人类审查，也不能替代人类审查。有人类对本条评论负责，如有错误请直接指出。

[udsy19]

fix(runtime): end Grep options before the pattern in the sandboxed worker

Summary

The filesystem worker appended the model-supplied Grep pattern as a bare
positional, so ripgrep parsed a pattern starting with - as flags.
-webkit-box exits 1, and packages/runtime/src/filesystem-worker/operations.ts:425
maps exit 1 to { kind: 'grep', matches: [] } — the model is told the string is
absent from a file that contains it, silently.

The host-local sibling already passes -- first
(packages/runtime/src/workspace-executor.ts:455). That separator arrived in
#2961, which edited this worker's grep case in the same commit but left its argv
unchanged, so the two search paths have disagreed since. This propagates it.

Fixes#3733

Verification

Ran locally on macOS 26.5.1 (25F80), Node v26.7.0, ripgrep 15.1.0:

• npm --workspace @maka/runtime run test:dist — 3090 tests, 0 failures
  (baseline on main was 3089/0; the delta is the new case).
• Negative control: restored operations.ts from origin/main and rebuilt — the
  new test fails (actual [… '--max-count=50', '-webkit-box', …] vs expected
  ['--', '-webkit-box', …]) while the other 20 cases in the file still pass.
• npm run lint, npm run format:check, npm run typecheck,
  npm run check:asf-headers — all clean.

Not run: Windows and Linux sandbox surfaces.

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Claude Code — located the divergence, drafted the one-line fix
and the regression test. Reviewed, reproduced and verified by me before submitting.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[M4n5ter]

Relationship note: PRs #3734, #3735, and #3903 all close #3733, touch the same two runtime files, and apply the same -- separator fix to the sandboxed Grep invocation. I could not find a canonical/supersede statement in these PR bodies or comments. At the current snapshot, #3903 is the latest-created candidate, but the owner should decide the canonical PR. Please document that relationship and mark the other attempts as superseded/close them, or explain the distinct scope, so the issue is not merged three times.

This comment records the relationship only; it is not a merge decision.

---

Automated review note posted by @未开智选手. This is not an independent human review; a human should verify the conclusion.

[M4n5ter]

Thank you for working on this fix. I compared this implementation with #3735 and #3903. All three correctly address the same root cause by placing the user-controlled pattern after ripgrep's -- option terminator.

#3903 was selected because its regression pins both the exact terminal argv order (['--', pattern, path]) and the full worker response with the smallest production patch. It has now been merged as 07e40feed27e748870b8144b3e37bf96c2748c52, so this equivalent implementation is superseded and I am closing it to keep one canonical fix.

---

Posted by an automated review agent operated by @M4n5ter. This is not an
independent human review and does not satisfy the committer review required by
CONTRIBUTING.md. A human is accountable for this comment — please push back if
anything here is wrong.

简体中文

本条评论由 @M4n5ter 运行的自动化审查程序发出。它不构成 CONTRIBUTING.md
所要求的独立人类审查，也不能替代人类审查。有人类对本条评论负责，如有错误请直接指出。

[udsy19]

fix(runtime): end Grep options before the pattern in the sandboxed worker

Summary

The filesystem worker appended the model-supplied Grep pattern as a bare
positional, so ripgrep parsed a pattern starting with - as flags.
-webkit-box exits 1, and packages/runtime/src/filesystem-worker/operations.ts:425
maps exit 1 to { kind: 'grep', matches: [] } — the model is told the string is
absent from a file that contains it, silently.

The host-local sibling already passes -- first
(packages/runtime/src/workspace-executor.ts:455). That separator arrived in
#2961, which edited this worker's grep case in the same commit but left its argv
unchanged, so the two search paths have disagreed since. This propagates it.

Fixes#3733

Verification

Ran locally on macOS 26.5.1 (25F80), Node v26.7.0, ripgrep 15.1.0:

• npm --workspace @maka/runtime run test:dist — 3090 tests, 0 failures
  (baseline on main was 3089/0; the delta is the new case).
• Negative control: restored operations.ts from origin/main and rebuilt — the
  new test fails (actual [… '--max-count=50', '-webkit-box', …] vs expected
  ['--', '-webkit-box', …]) while the other 20 cases in the file still pass.
• npm run lint, npm run format:check, npm run typecheck,
  npm run check:asf-headers — all clean.

Not run: Windows and Linux sandbox surfaces.

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Claude Code — located the divergence, drafted the one-line fix
and the regression test. Reviewed, reproduced and verified by me before submitting.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[M4n5ter]

Relationship note: PRs #3734, #3735, and #3903 all close #3733, touch the same two runtime files, and apply the same -- separator fix to the sandboxed Grep invocation. I could not find a canonical/supersede statement in these PR bodies or comments. At the current snapshot, #3903 is the latest-created candidate, but the owner should decide the canonical PR. Please document that relationship and mark the other attempts as superseded/close them, or explain the distinct scope, so the issue is not merged three times.

This comment records the relationship only; it is not a merge decision.

---

Automated review note posted by @未开智选手. This is not an independent human review; a human should verify the conclusion.

[M4n5ter]

Thank you for working on this fix. I compared this implementation with #3735 and #3903. All three correctly address the same root cause by placing the user-controlled pattern after ripgrep's -- option terminator.

#3903 was selected because its regression pins both the exact terminal argv order (['--', pattern, path]) and the full worker response with the smallest production patch. It has now been merged as 07e40feed27e748870b8144b3e37bf96c2748c52, so this equivalent implementation is superseded and I am closing it to keep one canonical fix.

---

Posted by an automated review agent operated by @M4n5ter. This is not an
independent human review and does not satisfy the committer review required by
CONTRIBUTING.md. A human is accountable for this comment — please push back if
anything here is wrong.

简体中文

本条评论由 @M4n5ter 运行的自动化审查程序发出。它不构成 CONTRIBUTING.md
所要求的独立人类审查，也不能替代人类审查。有人类对本条评论负责，如有错误请直接指出。

[udsy19]

fix(runtime): end Grep options before the pattern in the sandboxed worker

Summary

The filesystem worker appended the model-supplied Grep pattern as a bare
positional, so ripgrep parsed a pattern starting with - as flags.
-webkit-box exits 1, and packages/runtime/src/filesystem-worker/operations.ts:425
maps exit 1 to { kind: 'grep', matches: [] } — the model is told the string is
absent from a file that contains it, silently.

The host-local sibling already passes -- first
(packages/runtime/src/workspace-executor.ts:455). That separator arrived in
#2961, which edited this worker's grep case in the same commit but left its argv
unchanged, so the two search paths have disagreed since. This propagates it.

Fixes#3733

Verification

Ran locally on macOS 26.5.1 (25F80), Node v26.7.0, ripgrep 15.1.0:

• npm --workspace @maka/runtime run test:dist — 3090 tests, 0 failures
  (baseline on main was 3089/0; the delta is the new case).
• Negative control: restored operations.ts from origin/main and rebuilt — the
  new test fails (actual [… '--max-count=50', '-webkit-box', …] vs expected
  ['--', '-webkit-box', …]) while the other 20 cases in the file still pass.
• npm run lint, npm run format:check, npm run typecheck,
  npm run check:asf-headers — all clean.

Not run: Windows and Linux sandbox surfaces.

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Claude Code — located the divergence, drafted the one-line fix
and the regression test. Reviewed, reproduced and verified by me before submitting.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[M4n5ter]

Relationship note: PRs #3734, #3735, and #3903 all close #3733, touch the same two runtime files, and apply the same -- separator fix to the sandboxed Grep invocation. I could not find a canonical/supersede statement in these PR bodies or comments. At the current snapshot, #3903 is the latest-created candidate, but the owner should decide the canonical PR. Please document that relationship and mark the other attempts as superseded/close them, or explain the distinct scope, so the issue is not merged three times.

This comment records the relationship only; it is not a merge decision.

---

Automated review note posted by @未开智选手. This is not an independent human review; a human should verify the conclusion.

[M4n5ter]

Thank you for working on this fix. I compared this implementation with #3735 and #3903. All three correctly address the same root cause by placing the user-controlled pattern after ripgrep's -- option terminator.

#3903 was selected because its regression pins both the exact terminal argv order (['--', pattern, path]) and the full worker response with the smallest production patch. It has now been merged as 07e40feed27e748870b8144b3e37bf96c2748c52, so this equivalent implementation is superseded and I am closing it to keep one canonical fix.

---

Posted by an automated review agent operated by @M4n5ter. This is not an
independent human review and does not satisfy the committer review required by
CONTRIBUTING.md. A human is accountable for this comment — please push back if
anything here is wrong.

简体中文

本条评论由 @M4n5ter 运行的自动化审查程序发出。它不构成 CONTRIBUTING.md
所要求的独立人类审查，也不能替代人类审查。有人类对本条评论负责，如有错误请直接指出。

[udsy19]

fix(runtime): end Grep options before the pattern in the sandboxed worker

Summary

The filesystem worker appended the model-supplied Grep pattern as a bare
positional, so ripgrep parsed a pattern starting with - as flags.
-webkit-box exits 1, and packages/runtime/src/filesystem-worker/operations.ts:425
maps exit 1 to { kind: 'grep', matches: [] } — the model is told the string is
absent from a file that contains it, silently.

The host-local sibling already passes -- first
(packages/runtime/src/workspace-executor.ts:455). That separator arrived in
#2961, which edited this worker's grep case in the same commit but left its argv
unchanged, so the two search paths have disagreed since. This propagates it.

Fixes#3733

Verification

Ran locally on macOS 26.5.1 (25F80), Node v26.7.0, ripgrep 15.1.0:

• npm --workspace @maka/runtime run test:dist — 3090 tests, 0 failures
  (baseline on main was 3089/0; the delta is the new case).
• Negative control: restored operations.ts from origin/main and rebuilt — the
  new test fails (actual [… '--max-count=50', '-webkit-box', …] vs expected
  ['--', '-webkit-box', …]) while the other 20 cases in the file still pass.
• npm run lint, npm run format:check, npm run typecheck,
  npm run check:asf-headers — all clean.

Not run: Windows and Linux sandbox surfaces.

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Claude Code — located the divergence, drafted the one-line fix
and the regression test. Reviewed, reproduced and verified by me before submitting.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[M4n5ter]

Relationship note: PRs #3734, #3735, and #3903 all close #3733, touch the same two runtime files, and apply the same -- separator fix to the sandboxed Grep invocation. I could not find a canonical/supersede statement in these PR bodies or comments. At the current snapshot, #3903 is the latest-created candidate, but the owner should decide the canonical PR. Please document that relationship and mark the other attempts as superseded/close them, or explain the distinct scope, so the issue is not merged three times.

This comment records the relationship only; it is not a merge decision.

---

Automated review note posted by @未开智选手. This is not an independent human review; a human should verify the conclusion.

[M4n5ter]

Thank you for working on this fix. I compared this implementation with #3735 and #3903. All three correctly address the same root cause by placing the user-controlled pattern after ripgrep's -- option terminator.

#3903 was selected because its regression pins both the exact terminal argv order (['--', pattern, path]) and the full worker response with the smallest production patch. It has now been merged as 07e40feed27e748870b8144b3e37bf96c2748c52, so this equivalent implementation is superseded and I am closing it to keep one canonical fix.

---

Posted by an automated review agent operated by @M4n5ter. This is not an
independent human review and does not satisfy the committer review required by
CONTRIBUTING.md. A human is accountable for this comment — please push back if
anything here is wrong.

简体中文

本条评论由 @M4n5ter 运行的自动化审查程序发出。它不构成 CONTRIBUTING.md
所要求的独立人类审查，也不能替代人类审查。有人类对本条评论负责，如有错误请直接指出。

[udsy19]

fix(runtime): end Grep options before the pattern in the sandboxed worker

Summary

The filesystem worker appended the model-supplied Grep pattern as a bare
positional, so ripgrep parsed a pattern starting with - as flags.
-webkit-box exits 1, and packages/runtime/src/filesystem-worker/operations.ts:425
maps exit 1 to { kind: 'grep', matches: [] } — the model is told the string is
absent from a file that contains it, silently.

The host-local sibling already passes -- first
(packages/runtime/src/workspace-executor.ts:455). That separator arrived in
#2961, which edited this worker's grep case in the same commit but left its argv
unchanged, so the two search paths have disagreed since. This propagates it.

Fixes#3733

Verification

Ran locally on macOS 26.5.1 (25F80), Node v26.7.0, ripgrep 15.1.0:

• npm --workspace @maka/runtime run test:dist — 3090 tests, 0 failures
  (baseline on main was 3089/0; the delta is the new case).
• Negative control: restored operations.ts from origin/main and rebuilt — the
  new test fails (actual [… '--max-count=50', '-webkit-box', …] vs expected
  ['--', '-webkit-box', …]) while the other 20 cases in the file still pass.
• npm run lint, npm run format:check, npm run typecheck,
  npm run check:asf-headers — all clean.

Not run: Windows and Linux sandbox surfaces.

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Claude Code — located the divergence, drafted the one-line fix
and the regression test. Reviewed, reproduced and verified by me before submitting.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[M4n5ter]

Relationship note: PRs #3734, #3735, and #3903 all close #3733, touch the same two runtime files, and apply the same -- separator fix to the sandboxed Grep invocation. I could not find a canonical/supersede statement in these PR bodies or comments. At the current snapshot, #3903 is the latest-created candidate, but the owner should decide the canonical PR. Please document that relationship and mark the other attempts as superseded/close them, or explain the distinct scope, so the issue is not merged three times.

This comment records the relationship only; it is not a merge decision.

---

Automated review note posted by @未开智选手. This is not an independent human review; a human should verify the conclusion.

[M4n5ter]

Thank you for working on this fix. I compared this implementation with #3735 and #3903. All three correctly address the same root cause by placing the user-controlled pattern after ripgrep's -- option terminator.

#3903 was selected because its regression pins both the exact terminal argv order (['--', pattern, path]) and the full worker response with the smallest production patch. It has now been merged as 07e40feed27e748870b8144b3e37bf96c2748c52, so this equivalent implementation is superseded and I am closing it to keep one canonical fix.

---

Posted by an automated review agent operated by @M4n5ter. This is not an
independent human review and does not satisfy the committer review required by
CONTRIBUTING.md. A human is accountable for this comment — please push back if
anything here is wrong.

简体中文

本条评论由 @M4n5ter 运行的自动化审查程序发出。它不构成 CONTRIBUTING.md
所要求的独立人类审查，也不能替代人类审查。有人类对本条评论负责，如有错误请直接指出。

[udsy19]

fix(runtime): end Grep options before the pattern in the sandboxed worker

Summary

The filesystem worker appended the model-supplied Grep pattern as a bare
positional, so ripgrep parsed a pattern starting with - as flags.
-webkit-box exits 1, and packages/runtime/src/filesystem-worker/operations.ts:425
maps exit 1 to { kind: 'grep', matches: [] } — the model is told the string is
absent from a file that contains it, silently.

The host-local sibling already passes -- first
(packages/runtime/src/workspace-executor.ts:455). That separator arrived in
#2961, which edited this worker's grep case in the same commit but left its argv
unchanged, so the two search paths have disagreed since. This propagates it.

Fixes#3733

Verification

Ran locally on macOS 26.5.1 (25F80), Node v26.7.0, ripgrep 15.1.0:

• npm --workspace @maka/runtime run test:dist — 3090 tests, 0 failures
  (baseline on main was 3089/0; the delta is the new case).
• Negative control: restored operations.ts from origin/main and rebuilt — the
  new test fails (actual [… '--max-count=50', '-webkit-box', …] vs expected
  ['--', '-webkit-box', …]) while the other 20 cases in the file still pass.
• npm run lint, npm run format:check, npm run typecheck,
  npm run check:asf-headers — all clean.

Not run: Windows and Linux sandbox surfaces.

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Claude Code — located the divergence, drafted the one-line fix
and the regression test. Reviewed, reproduced and verified by me before submitting.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[M4n5ter]

Relationship note: PRs #3734, #3735, and #3903 all close #3733, touch the same two runtime files, and apply the same -- separator fix to the sandboxed Grep invocation. I could not find a canonical/supersede statement in these PR bodies or comments. At the current snapshot, #3903 is the latest-created candidate, but the owner should decide the canonical PR. Please document that relationship and mark the other attempts as superseded/close them, or explain the distinct scope, so the issue is not merged three times.

This comment records the relationship only; it is not a merge decision.

---

Automated review note posted by @未开智选手. This is not an independent human review; a human should verify the conclusion.

[M4n5ter]

Thank you for working on this fix. I compared this implementation with #3735 and #3903. All three correctly address the same root cause by placing the user-controlled pattern after ripgrep's -- option terminator.

#3903 was selected because its regression pins both the exact terminal argv order (['--', pattern, path]) and the full worker response with the smallest production patch. It has now been merged as 07e40feed27e748870b8144b3e37bf96c2748c52, so this equivalent implementation is superseded and I am closing it to keep one canonical fix.

---

Posted by an automated review agent operated by @M4n5ter. This is not an
independent human review and does not satisfy the committer review required by
CONTRIBUTING.md. A human is accountable for this comment — please push back if
anything here is wrong.

简体中文

本条评论由 @M4n5ter 运行的自动化审查程序发出。它不构成 CONTRIBUTING.md
所要求的独立人类审查，也不能替代人类审查。有人类对本条评论负责，如有错误请直接指出。

[udsy19]

fix(runtime): end Grep options before the pattern in the sandboxed worker

Summary

The filesystem worker appended the model-supplied Grep pattern as a bare
positional, so ripgrep parsed a pattern starting with - as flags.
-webkit-box exits 1, and packages/runtime/src/filesystem-worker/operations.ts:425
maps exit 1 to { kind: 'grep', matches: [] } — the model is told the string is
absent from a file that contains it, silently.

The host-local sibling already passes -- first
(packages/runtime/src/workspace-executor.ts:455). That separator arrived in
#2961, which edited this worker's grep case in the same commit but left its argv
unchanged, so the two search paths have disagreed since. This propagates it.

Fixes#3733

Verification

Ran locally on macOS 26.5.1 (25F80), Node v26.7.0, ripgrep 15.1.0:

• npm --workspace @maka/runtime run test:dist — 3090 tests, 0 failures
  (baseline on main was 3089/0; the delta is the new case).
• Negative control: restored operations.ts from origin/main and rebuilt — the
  new test fails (actual [… '--max-count=50', '-webkit-box', …] vs expected
  ['--', '-webkit-box', …]) while the other 20 cases in the file still pass.
• npm run lint, npm run format:check, npm run typecheck,
  npm run check:asf-headers — all clean.

Not run: Windows and Linux sandbox surfaces.

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Claude Code — located the divergence, drafted the one-line fix
and the regression test. Reviewed, reproduced and verified by me before submitting.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[M4n5ter]

Relationship note: PRs #3734, #3735, and #3903 all close #3733, touch the same two runtime files, and apply the same -- separator fix to the sandboxed Grep invocation. I could not find a canonical/supersede statement in these PR bodies or comments. At the current snapshot, #3903 is the latest-created candidate, but the owner should decide the canonical PR. Please document that relationship and mark the other attempts as superseded/close them, or explain the distinct scope, so the issue is not merged three times.

This comment records the relationship only; it is not a merge decision.

---

Automated review note posted by @未开智选手. This is not an independent human review; a human should verify the conclusion.

[M4n5ter]

Thank you for working on this fix. I compared this implementation with #3735 and #3903. All three correctly address the same root cause by placing the user-controlled pattern after ripgrep's -- option terminator.

#3903 was selected because its regression pins both the exact terminal argv order (['--', pattern, path]) and the full worker response with the smallest production patch. It has now been merged as 07e40feed27e748870b8144b3e37bf96c2748c52, so this equivalent implementation is superseded and I am closing it to keep one canonical fix.

---

Posted by an automated review agent operated by @M4n5ter. This is not an
independent human review and does not satisfy the committer review required by
CONTRIBUTING.md. A human is accountable for this comment — please push back if
anything here is wrong.

简体中文

本条评论由 @M4n5ter 运行的自动化审查程序发出。它不构成 CONTRIBUTING.md
所要求的独立人类审查，也不能替代人类审查。有人类对本条评论负责，如有错误请直接指出。