search_files can substitute the wrong line when matched text contains :number:

search_files 関数と、grep 出力の正規表現解析を確認してください。問題は、一致したテキスト内の :number: シーケンスを誤って解釈するアダプターにあります。まず、grep の結果が処理される場所を見つけ、正規表現パターンを特定します。提供されたサンプルファイルでテストし、置換エラーを確認します。正しい行番号とテキストが保持されていることを確認して修正を検証します。

What happened?

search_files can return the wrong source text when a matched line itself contains another :<number>: sequence.

For example, if line 1 is:

src/example.ts:42: build failed

the native grep tool correctly returns:

many.log:1: src/example.ts:42: build failed

but the Step-facing search_files result can become:

many.log:1: src/example.ts:42: UNRELATED_LINE_42

The adapter reparses rendered grep output with a greedy path:line:text regex, mistakes the later :42: for the real line number, then reloads line 42 from the file. Timestamp-shaped text such as 12:34: reproduces the same problem; if the false line number is past EOF, the visible result can become (no matches) while the details still report one match.

I reproduced this on clean main @ f113768 with the built-in tool profile and project-native Vitest, without external extensions.

Steps to reproduce

1. Create a 42-line file where line 1 is src/example.ts:42: build failed and line 42 is UNRELATED_LINE_42.
2. Run search_files for build failed on that file.
3. The native grep result contains the correct line-1 text.
4. The Step-facing result substitutes the contents of line 42.

Expected behavior

search_files should preserve the native match path, line number, and matched text without reinterpreting delimiter-like text inside the match.

Version

main @ f113768 / @step-harness/coding-agent 0.84.4