[Bug] PR review findings are posted as one conversation comment instead of inline review comments

[jiangkuaixue123]

Summary

pr.post_review reports success as “posted PR review comment”, but it publishes the entire rendered review as one top-level PR Conversation comment. The individual findings are not submitted as GitHub review comments attached to their file and line.

This is confusing because the review step reports, for example, review produced (5 comments), while GitHub shows one large unstructured comment.

Environment

• InferMatrixCopilot revision: 57081cb939a9
• Playbook: pr-review@6
• Target: feat(npu): token-balanced async MoE microbatch split for DP+TP/SP vllm-project/afd-plugin#152
• Run: run-20260725-092043-bee56f
• ALLOW_POST=1
• Task resolved with post=True

Reproduction

Run:

./infermatrix-copilot -p "review https://github.com/vllm-project/afd-plugin/pull/152 and post the review to GitHub"

The CLI reports:

→ task: pr_review PR #152 on afd-plugin (tier L2) [post]
...
✓ review: review produced (5 comments; depth=full via rules)
✓ post: posted PR review comment

Actual published artifact:

vllm-project/afd-plugin#152 (comment)

GitHub displays one long Conversation comment containing the scan table, validation notes, five findings, evidence, and verdict.

Expected behavior

Each actionable finding with a valid file and line should be posted as an inline GitHub review comment on the changed line. A concise summary/scan/verdict can be used as the review body.

For a review containing blocking major or blocker findings, the GitHub review event should be REQUEST_CHANGES. Reviews with only non-blocking findings should use COMMENT; empty findings may use APPROVE, subject to the product's safety policy.

The CLI summary should distinguish between:

• a GitHub review with N inline comments; and
• a single top-level PR Conversation comment fallback.

Actual behavior

All findings are flattened into one Markdown string and posted as a single issue comment. No inline review threads are created, and the rendered **Verdict:** REQUEST CHANGES is only text—it does not set GitHub's review state.

Root cause

The review pipeline already produces structured findings:

{
  "file": "path/to/file.py",
  "line": 123,
  "severity": "major",
  "comment": "...",
  "evidence": "..."
}

The run's ensemble_agent.review_diff.json contains candidates with file, line, severity, comment, and evidence.

However, agent.review_diff renders them into review_text, and pr.post_review only consumes that flattened string:

_post_step(
    "review_text",
    lambda spec, body: [
        "pr", "comment", str(spec.get("pr")),
        "--body", body,
    ],
    "PR review comment",
)

gh pr comment creates a top-level issue/Conversation comment. It cannot create an inline pull-request review.

Suggested fix

1. Persist the capped structured review_comments list from agent.review_diff into shared step state, alongside review_text.
2. Add a dedicated GitHub review publisher using the Pull Request Reviews API (or equivalent gh api call):
   • review body: concise scan, validated summary, and verdict;
   • review event: REQUEST_CHANGES, COMMENT, or policy-approved APPROVE;
   • inline comments: map each finding to path, line, and side=RIGHT (or a verified diff position).
3. Validate that every file/line belongs to the PR diff before posting.
4. Define partial-failure behavior:
   • invalid/outdated line mappings should fall back to a clearly labeled summary section;
   • valid inline comments should still be posted;
   • report how many were posted inline versus downgraded.
5. Keep the existing two write gates: explicit post=True and ALLOW_POST=1.
6. Rename the existing implementation/summary to “posted PR conversation comment” if it remains as a fallback.

Acceptance criteria

• A review with five valid structured findings creates one GitHub review containing five inline comment threads.
• The GitHub review state matches the computed verdict.
• Invalid line mappings are reported and safely downgraded without losing findings.
• No outward write occurs unless both post=True and ALLOW_POST=1.
• Tests cover inline payload construction, diff-line validation, verdict-to-event mapping, partial fallback, dry-run behavior, and API failure handling.

Impact

The current behavior reduces review usability: authors cannot resolve findings as independent threads, comments are not anchored to code, and GitHub does not reflect the intended request-changes state. It also makes the CLI's “5 comments” and “posted PR review comment” wording misleading.