Skip empty lines when computing partial-line similarity

The partial-match branch treats blank oldText lines as a match for every content line because oldLine.trim() can be "" and contentLine.includes("") is always true. With trailing newlines or intentional blank lines in oldText, each window gets artificial score credit, so unrelated regions can exceed the 20% threshold and suppress the Current file contents fallback. This makes mismatch hints point to arbitrary locations instead of useful context.

Useful? React with 👍 / 👎.

Cap best-match snippet length to prevent oversized errors

The new best-match path no longer enforces EDIT_MISMATCH_HINT_LIMIT, and the snippet size scales with oldText line count (windowSize). If oldText is large (for example, a big multi-line replacement), the thrown error can include hundreds or thousands of lines, which can bloat tool responses and exceed practical model/context limits. The fallback path still caps output to 800 chars, so this is a regression in mismatch-error size control.

Useful? React with 👍 / 👎.

Single-line path ignores sliding window result and reports misleading score

The single-line substring block runs unconditionally after the sliding window loop and returns early — completely discarding bestScore/bestStart — even when the window found a more similar position. Consider this scenario:

• oldText = "baz"
• File line 1: "foo bar baz qux" (contains "baz" as substring — poor match)
• File line 5: " baz" (trimmed exact match, sliding window score 0.5)

The substring scan hits line 1 first and returns lineStart: 1, score: 0.9, while the sliding window correctly ranked line 5 higher. The model is shown the wrong region with an inflated confidence percentage.

Additionally, the hardcoded score: 0.9 bears no relationship to actual line similarity; a file that contains "bazaar" would be reported as "90% similar" to oldText = "baz" even though the line content is unrelated.

A minimal fix is to only enter the substring path when the sliding window produced a weak or no result:

if (windowSize === 1 && bestScore < 0.5) {
  const trimmedOld = oldLines[0].trim();
  if (trimmedOld.length > 0) {
    for (let i = 0; i < contentLines.length; i++) {
      if (contentLines[i].includes(trimmedOld)) {
        return {
          lineStart: i + 1,
          snippet: contentLines
            .slice(Math.max(0, i - 1), i + 2)
            .map((l, idx) => `${Math.max(1, i) + idx}| ${l}`)
            .join("\n"),
          score: 0.9,
        };
      }
    }
  }
}

This lets an exact-trimmed window match (score 0.5) take priority over a mere substring hit anywhere in the file.

This is a comment left during a code review.
Path: src/agents/pi-tools.host-edit.ts
Line: 151-166

Comment:
**Single-line path ignores sliding window result and reports misleading score**

The single-line substring block runs unconditionally after the sliding window loop and returns early — completely discarding `bestScore`/`bestStart` — even when the window found a more similar position. Consider this scenario:

- `oldText = "baz"`
- File line 1: `"foo bar baz qux"` (contains "baz" as substring — poor match)
- File line 5: `"  baz"` (trimmed exact match, sliding window score 0.5)

The substring scan hits line 1 first and returns `lineStart: 1, score: 0.9`, while the sliding window correctly ranked line 5 higher. The model is shown the wrong region with an inflated confidence percentage.

Additionally, the hardcoded `score: 0.9` bears no relationship to actual line similarity; a file that contains `"bazaar"` would be reported as "90% similar" to `oldText = "baz"` even though the line content is unrelated.

A minimal fix is to only enter the substring path when the sliding window produced a weak or no result:

```typescript
if (windowSize === 1 && bestScore < 0.5) {
  const trimmedOld = oldLines[0].trim();
  if (trimmedOld.length > 0) {
    for (let i = 0; i < contentLines.length; i++) {
      if (contentLines[i].includes(trimmedOld)) {
        return {
          lineStart: i + 1,
          snippet: contentLines
            .slice(Math.max(0, i - 1), i + 2)
            .map((l, idx) => `${Math.max(1, i) + idx}| ${l}`)
            .join("\n"),
          score: 0.9,
        };
      }
    }
  }
}
```

This lets an exact-trimmed window match (score 0.5) take priority over a mere substring hit anywhere in the file.

How can I resolve this? If you propose a fix, please make it concise.