add-pr-comment: render inline threads as applyable single/multi-line suggestions (fix ready on fork)

[YuliiaKovalova]

Proposed fix: render add-pr-comment inline threads as applyable single/multi-line suggestions

I have a fix ready on a fork branch but cannot open a PR directly (this repo limits PR creation to collaborators). The branch is rebased on current main and "Able to merge":

• Branch: YuliiaKovalova:fix/pr-comment-suggestion-anchor
• Compare: main...YuliiaKovalova:ado-aw:fix/pr-comment-suggestion-anchor

A maintainer can open the PR from that compare link, or pull/cherry-pick the three commits below. Happy to be added as a collaborator so I can open it myself.

---

Problem

The add-pr-comment safe output produces inline suggestion threads that Azure DevOps renders as broken, non-applyable comments. There are three distinct facets of the same problem, each demonstrated live against real ADO PRs.

1. Zero-width anchor → concatenated / duplicated line

The inline thread is anchored with rightFileEnd at offset 1, i.e. a zero-width range (L184:1 → L184:1). ADO treats a zero-width anchor as an insertion point, so applying a single-line suggestion prepends the suggested text to the original line instead of replacing it:

Mock.Of<IProgress>(MockBehavior.Loose), … Progress = Mock.Of<IProgress>(),

Fix: anchor rightFileEnd to (UTF-16 length of the last covered line) + 1 (CRLF-safe) so the range covers the whole line(s) and Apply performs a clean replace. Adds a pure inline_thread_context() helper plus line_end_offset(), with unit tests for the single- and multi-line cases.

2. Fenced suggestion body HTML-escaped

sanitize() → escape_html_tags escapes all </>, including the contents of the ```suggestion fence, so applying the suggestion writes literal </> into the file. Fix: escape_html_tags is now fence-aware — lines inside ```/~~~ fences pass through verbatim, matching how every Markdown renderer (including ADO) treats fenced code.

3. Inline `code` spans in prose HTML-escaped

The same escaper also mangles inline-code spans in the comment prose, e.g. `Mock.Of<IProgress>()` renders as Mock.Of<IProgress>(). Fix: escape_html_tags now also preserves backtick-delimited inline code. A run of k backticks is closed only by a run of exactly k backticks on the same line; an unmatched backtick is treated as a literal and the remainder of the line is still escaped, so HTML cannot evade neutralization.

Why skipping the escape is safe

Markdown renderers (including ADO) render fenced and inline code literally and never interpret HTML inside them, so leaving </> un-escaped there matches renderer behaviour — any smuggled HTML stays inert. Backtick-run matching slices only at backtick (ASCII 0x60) boundaries, so it is byte-safe for multi-byte UTF-8 content.

Validation

• cargo test --bins sanitize — 77 passed (5 new tests across the three fixes).
• cargo clippy --bins — clean.
• cargo fmt --check — clean.
• Demonstrated end-to-end by running the patched ado-aw execute against real ADO PRs:
  • Single + multi-line: anchors L1:1→L1:78 and L1:1→L2:49, literal <...>, one-click Apply.
  • Worst-case production repro (Moq1400, line 184): anchor L184:1→L184:45, clean whole-line replace, literal <...> in both the prose inline-code spans and the suggestion body, no <.

Commits

• 65268f2 feat(safe-outputs): render add-pr-comment inline threads as applyable suggestions
• 4764358 fix(safe-outputs): preserve fenced code blocks when escaping HTML
• 01a0096 fix(safe-outputs): preserve inline code spans when escaping HTML

Files touched

• src/safeoutputs/add_pr_comment.rs — anchor / inline_thread_context() / line_end_offset() + tests + agent-facing schema docs.
• src/sanitize.rs — fence-aware and inline-code-aware escape_html_tags + tests.
• docs/safe-outputs.md — "Inline applyable suggestions" section.

[jamesadevine]

Hey! I know the work has already been done here, but the reason why this repo is limited to PR contributors only is to safeguard downstream users and have the workload carried by agents. Sorry if that expectation was not made clear - if it was not clear let me know how to send a better signal!

Could you please run ado-aw init and get the generated agent to diagnose your issue (i.e. specifically direct it to look at the generated workitem)? Alternately, if you have the session used to generate the fix around, could you ask it to file an issue against this repo directly?

Thanks and sorry for the poor issue experience - and the break!

[YuliiaKovalova]

@jamesdevine — thanks, and no worries about the break! Quick clarification: this is the session that generated the fix, so I'm taking your "alternate" path and filing directly. To honor the agent-driven channel I also ran ado-aw init and followed the generated agent's debug prompt; below is the diagnostic report in your debug-ado-agentic-workflow.md template format. The ready fix (3 commits) is already linked above on YuliiaKovalova:fix/pr-comment-suggestion-anchor.

---

Diagnostic Summary

• Pipeline: AITestAgent Issue Fixer (an ado-aw agentic workflow, devdiv/DevDiv)
• Definition ID: Unknown
• Build ID: Unknown — the defect is in safe-output rendering, not a build failure; reproduced deterministically with ado-aw execute locally (v0.37.0 + patched build)
• Run URL (production artifact): PR #750251, thread #9557714 — https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_git/AITestAgent/pullRequest/750251?discussionId=9557714
• Result: Partially succeeded — the add-pr-comment POST returns HTTP 200, but the persisted thread renders as a non-applyable suggestion
• Failing stage/job/step: Stage 3 (SafeOutputs) → SafeOutputs → add-pr-comment
• First failed timeline record: N/A (no hard failure; defective output)
• Suspected root cause: add-pr-comment anchors the inline thread with a zero-width range and HTML-escapes </> inside fenced and inline code
• Confidence: High

Evidence

Relevant log excerpts

Read back from the ADO REST API for the production thread (threads/9557714):

• threadContext.rightFileStart = { line: 90, offset: 1 }, rightFileEnd = { line: 90, offset: 1 } — a zero-width anchor. ADO treats it as an insertion point, so "Apply" prepends the suggested line to the original (duplicated/concatenated line).
• The ```suggestion body and the prose inline-code spans contain </> instead of literal </>, so applying writes HTML entities into the file.

Timeline observations

• The safe output executed "successfully" (HTTP 200); there is no build-level failure. The defect is entirely in the rendered/persisted thread shape.

Changes since last successful build

• Not a user regression — latent in the runtime's anchor + escaping logic. Present across all add-pr-comment inline suggestions.

Environment

• Agent source file: AITestAgent Issue Fixer workflow .md (in the AITestAgent ADO repo) — path Unknown
• Compiled pipeline YAML: Unknown
• Compilation in sync: Unknown
• ado-aw version: v0.37.0 (reproduced locally; also on a patched build of main)
• AWF version: Unknown
• MCPG version: Unknown
• Agent pool: ubuntu-22.04
• Engine/model: copilot / claude-opus-4.7
• Relevant MCP servers: SafeOutputs

Analysis

• Stage classification: Stage 3 (SafeOutputs)
• Why this stage failed: add-pr-comment builds a threadContext whose right-side end anchor is offset 1 (zero-width), and runs the whole comment body — including the ```suggestion fence and inline `code` spans — through sanitize() → escape_html_tags, which escapes every </>. ADO renders fenced/inline code verbatim and never interprets HTML there, so the escaping is both unnecessary and corrupting; the zero-width anchor makes "Apply" non-idempotent.

Root Cause

• Root cause: three independent defects, all reproduced and fixed:
  1. src/safeoutputs/add_pr_comment.rs — inline thread anchored with a zero-width right-side range (offset 1) instead of spanning the whole target line(s). Fix: anchor rightFileEnd to (UTF-16 length of the last line) + 1.
  2. src/sanitize.rs — escape_html_tags escaped </> inside ```/~~~ fences. Fix: fence-aware skip.
  3. src/sanitize.rs — same escaper mangled inline `code` spans in prose. Fix: inline-code-aware skip with a security guard for unmatched backticks.
• Category: Runtime regression
• Ruled-out causes: network/AWF (HTTP 200), write-token/permissions (thread created), pool/image, threat-analysis block — none involved; defect reproduces deterministically offline.
• Related recent changes: fix prepared on YuliiaKovalova:fix/pr-comment-suggestion-anchor (65268f2, 4764358, 01a0096); 77 sanitize tests (5 new) + clippy + fmt green; demonstrated live (single + multi-line) on PRs #750246/#750251/#750260.

Issue

• Title: debug: add-pr-comment renders inline suggestions non-applyable (zero-width anchor + HTML-escaped code)
• Label: bug