add grep tool result formatter

[LasmarKhalifa]

No description provided.

[LasmarKhalifa]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• add task tool result formatter #963
• add agent tool result formatter #962
• add taskoutput tool result formatter backed by nokogiri #960
• add taskcreate tool result formatter #959
• add taskupdate tool result formatter #958
• add todowrite tool result formatter #957
• add skill tool result formatter #956
• add edit tool result formatter #955
• add write tool result formatter #954
• add grep tool result formatter #953 👈 (View in Graphite)
• add glob tool result formatter #952
• add read tool result formatter #951
• add bash tool result formatter #949
• Centralize tool result error handling in format with error_line helper #948
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[juniper-shopify]

The overall structure is great — mirroring the GLOB formatter's partition + NOTE + ok_line pattern keeps the stack consistent and readable. The doc comment is thorough with clear examples.

One change needed: the match-detection heuristic is too loose and will misclassify some status messages as grep matches. Details in the inline comment.

[juniper-shopify]

The match-detection heuristic here needs tightening. The current logic:

line.include?("/") || line.match?(/\d:/)

…is broad enough to misclassify several types of non-match lines as matches:

• line.include?("/") would match: "Found 0/100 files", "N/A", "true/false"
• line.match?(/\d:/) would match: "Step 2: install deps", "Completed in 1:23", "Error at 3:00pm"

Real grep output follows a consistent structure: either path/to/file:42:matched content (with file path) or 42:matched content (line-number-only, single-file mode). Is this what you're seeing from the grep tool message output as well, or does it look different?

A tighter heuristic that anchors to the start of the line:

line.match?(/\A\S+:\d+:/) || line.match?(/\A\d+:/)

This matches path:line:content and line:content formats while rejecting status messages that happen to contain / or digit: in the middle. You could also combine them:

line.match?(/\A(?:\S+:)?\d+:/)

[juniper-shopify]

The happy-path tests are solid — good coverage of the format variations. To go with the heuristic tightening above, it'd be valuable to add a test that verifies a status message containing / or digit: is correctly classified as a note rather than a match. For example:

test "format_grep does not misclassify a status message containing a slash as a match" do
  tool_use_message = Claude::Messages::ToolUseMessage.new(
    type: :tool_use,
    hash: { name: "grep", input: {} },
  )
  tool_result = Claude::ToolResult.new(
    tool_use: tool_use_message,
    content: "lib/a.rb:1:foo\nFound 0/100 files",
    is_error: false,
  )

  output = tool_result.format

  assert_equal "GREP OK 1 match · NOTE Found 0/100 files", output
end

This kind of "adversarial" test is a good general practice for heuristic-based parsing — it documents the boundary between what the code considers data vs. metadata.