Claude review comments lack commit SHA metadata; downstream tools can't filter stale reviews #37

Problem

claude-blocking-review.yml posts each review as a new top-level PR comment via gh pr comment (line 284). Those land in the issues/comments API, which — unlike pulls/{n}/comments (review comments) — returns no original_commit_id field.

Consequence: any downstream tool that enumerates bot feedback on a PR (e.g. post-push-status.sh → FINDING lines) cannot tell which comments belong to the current commit vs previous commits. Each push re-surfaces every prior review as if it were live feedback, including ones whose concerns were already addressed. The local post-push-loop skill explicitly warns about this case:

"Note on issues/comments staleness: Findings from the PR conversation thread (issues/comments) cannot be filtered by commit — that API provides no original_commit_id field. These findings may include bot comments from previous commits."

Concrete occurrence: during an autonomous post-push-loop iteration on smartwatermelon/dotfiles#59, the thread accumulated 4 review comments across 3 commits + 1 rebase. One of them was a VERDICT: BLOCK from an earlier commit whose underlying cause was already fixed, but the status script couldn't distinguish it from live findings and had to escalate for human judgment.

Suggested fixes (not mutually exclusive)

Option A (smallest change, recommended) — embed commit SHA as HTML-comment metadata.

In the prompt at line ~284, instruct Claude to prepend a machine-parseable line to /tmp/review.md:

<!-- claude-review commit=<SHA> run=<GITHUB_RUN_ID> -->

Downstream tools can then filter comments by matching the current HEAD SHA. The HTML comment is invisible in rendered markdown but preserved in the raw API payload.

Expose commit_sha as a workflow input (or derive from github.event.pull_request.head.sha) and inject it into the prompt.

Option B — update the previous review instead of appending.

Before posting, query existing PR comments from the bot (gh pr view --json comments), identify the prior claude-review comment (e.g. by a well-known header line), and gh api --method PATCH to edit it in place rather than creating a new one. Keeps the PR thread clean.

Tradeoff: loses per-commit history for humans scrolling the PR. Option A preserves that.

Option C — post as a formal review instead of an issue comment.

Switch from gh pr comment to gh api POST /repos/{owner}/{repo}/pulls/{n}/reviews. Formal reviews are attached to a commit SHA and appear in GET /pulls/{n}/reviews with commit_id populated. Downstream tools could use that API instead.

Tradeoff: bigger change; the review-events API has different comment formatting and UI placement.

Downstream consumer

The local tool that surfaces this: post-push-status.sh in smartwatermelon/claude-config, used by the post-push-loop skill in the ci-workflows plugin marketplace. Happy to coordinate a matching consumer change if you go with Option A (SHA filter) or Option C (API swap).

Priority

Low/medium. Human reviewers don't trip on this — the staleness only bites automation. But as more consumer repos adopt this workflow + the loop skill, the papercut multiplies.