deep-review: PR-comment renderer — verdict-first summary plus inline anchored blockers

Part of the deep-review: delivery rework milestone. Design context: #217 (§3, §5A/B/C/D).

Problem

When a deep-review lands on someone else's PR today, the author gets one comment containing an unbounded flat list — style nits, naming suggestions, and merge blockers in the same undifferentiated run — with the actionable synthesis (⚡ Bottom Line) at the bottom, after the wall. The ordering is correct for a terminal, where the reader's eye lands at the tail; it is wrong for a PR page, which is read top-down.

The result: the two findings that actually block merge are buried, and the author is doing triage the reviewer should have done.

Proposal

A PR-delivery rendering, separate from the terminal rendering:

Top-level comment (short):

• ⚖️ Verdict
• The bottom-line paragraph, moved to the top — counts and the single most important thing.
• Blocking findings as a compact list with links to the inline threads.
• Everything non-blocking inside a collapsed <details> block.

Inline review comments: each blocking finding anchored to the changed line it concerns, posted as a proper GitHub review (pending review → comments → submit) so the author receives one notification rather than N.

Machine payload: the structured finding set in an HTML comment (see the structured-findings issue in this milestone), so a later run or another skill can pick up state without re-parsing prose.

Constraints

• Anchoring is a hard constraint, not a detail. standards/CLAUDE.md → PR Review Comment Anchoring: anchor on a line the PR actually changed, never on the unchanged symptom site. GitHub rejects off-diff positions outright; ADO accepts them and then renders them only in the Overview tab where the author never sees them. Verify each target file is in git diff --name-only origin/<base>...HEAD before posting.
• The review itself does not get shorter. #217 §6.5 — exhaustiveness stays; only what reaches the author is gated.
• Never cast a vote. Suggest one; the human running the review decides (#217 §6.4).

Open questions

• What's the gate — severity or blocking? 💡 suppressed entirely, or collapsed in <details>? #217 §6.3.
• How many inline comments is too many? 30 inline comments is still 30 notifications. Is there a cap, and what happens past it — roll the rest into the summary?
• One skill or two? Does /deep-review grow a post mode, or does a separate /post-review consume the structured findings? #217 §6.1. The second composes better with #163 and #164.
• ADO parity. The skill already supports ADO PRs (#173, #143). Does the renderer need to work on both hosts from day one, or is GitHub first acceptable?
• Idempotency: re-running against the same PR should update the existing comment/threads, not stack duplicates. Interacts with the delta re-review issue in this milestone.

Depends on

The structured-findings issue in this milestone (the renderer should render from the finding set, not re-parse prose), and the delivery-model decision in #217 §6.1/§6.3.

Acceptance criteria (provisional — pending #217)

1. The top-level comment leads with the verdict and the bottom line; no finding list precedes them.
2. Blocking findings appear as inline comments anchored to changed lines only; a run against a PR whose findings sit in unchanged files degrades gracefully instead of erroring or silently burying them.
3. Non-blocking findings remain reachable but collapsed.
4. Posting is a single review submission, not N separate comments.
5. Re-running does not duplicate previously posted threads.

Start by reading standards/CLAUDE.md, especially PR Review Comment Anchoring, then review #217 §§3, 5A/B/C/D and 6.1/6.3/6.4/6.5 alongside the structured-findings issue. Resolve the pending delivery, gating, host-parity, and idempotency decisions before implementing; done means the provisional acceptance criteria pass without duplicate review threads or off-diff anchors.