[bot] suggestion diffs silently remove correct code (recurring)

[worktrunk-bot]

Problem

Bot-generated GitHub suggestion blocks sometimes propose diffs that remove substantially more content than they add, meaning committing the suggestion would silently delete correct code. This is a recurring pattern across multiple PRs.

Known cases

1. pr-review: multi-line suggestion removes correct code along with the bug #1310 — PR Adds simplified install scripts #1309: suggestion to fix a PowerShell syntax error covered too many lines (start_line: 18, line: 22) and would have removed the legitimate git-wt fallback branch along with the duplicate.

2. pr-review: suggestion block eats code fence markers when target range includes backtick lines #1326 — PR fix(skill): add retry guard to prevent intra-run duplicate reviews #1322: suggestion anchored on lines 289–291 included a closing ``` fence marker, which GitHub's suggestion syntax consumed as its own delimiter — applying it would break the markdown.

3. fix: add confidence gates and evidence accumulation to review-reviewers #1598 (comment) — self-review suggestion to replace the "Reading historical evidence" + "Recording below-threshold findings" sections. The removed section was much larger than the added section, and committing the suggestion would have deleted the gh issue view code block and surrounding instructions.

Pattern

The common thread: the bot constructs a suggestion block whose line range covers more content than it intends to replace. The replacement text is shorter, so the net effect is silent deletion of correct code.

This may be caused by:

• Incorrect start_line / line range calculation when the target spans multiple sections
• Not accounting for GitHub's suggestion semantics (the suggestion replaces the entire range)
• Mixing "what to add" with "what to remove" without verifying the full replacement

Desired behavior

When proposing a suggestion, the bot should verify that the removed content and added content are semantically equivalent — i.e., the suggestion should not silently drop lines that aren't being intentionally replaced.

[max-sixty]

can you try to work out what's going on? fine to test on a test PR

we need to work out the underlying cause of why this is difficult or why our instructions are confusing, and then solve that. (we cannot have IMPORTANT: do not make mistakes etc)

[worktrunk-bot]

Investigated all three cases. The root cause is the same in each: the bot sets start_line/line to a range wider than the replacement text, so applying the suggestion silently deletes the surplus lines.

Case details:

Case	Range	Lines covered	Problem
#1310 (PR #1309)	18–22	5 lines	Replacement was shorter → deleted git-wt fallback
#1326 (PR #1322)	289–291	3 lines	Range included a ``` fence → GitHub consumed it as the suggestion delimiter
#1598	93–127	35 lines	Massive range replaced with shorter rewrite → deleted gh issue view block

Why the existing instruction failed: The skill said "minimize the range" but gave no way to verify correctness. The bot constructs the range by anchoring on section headings or landmarks, not by checking that every line in the range is accounted for in the replacement.

Fix: #1608 replaces the vague instruction with a concrete 4-step verification checklist — read the exact lines, verify no silent deletions, cap at ~10 lines, and avoid spanning markdown fences.

[max-sixty]

ok, let's see how this does