feat: minimize PASS review comments via GraphQL - #83
Merged
Conversation
After the verdict check, when verdict is PASS, locate the just-posted claude-blocking-review comment for the current SHA and minimize it as RESOLVED. BLOCK comments stay un-minimized — humans need to see them. Why: downstream tooling (post-push-status.sh) scrapes bot comments to surface unresolved findings, but it has no way to distinguish PASS from BLOCK on its own. Minimizing PASS comments lets the scraper skip them via the GraphQL isMinimized field (coordinating PR in claude-config). The comment body is preserved in the PR thread under the standard "Resolved" disclosure, so the audit trail is intact. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
6 tasks
twistedmelonman
added a commit
to twistedmelonman/claude-config
that referenced
this pull request
May 2, 2026
…150) * feat: switch issue-comments fetch to GraphQL with isMinimized filter Coordinating change to smartwatermelon/github-workflows#83, which now minimizes PASS review comments via GraphQL minimizeComment(RESOLVED). The REST issues/comments endpoint does not return isMinimized, so the scraper still treated those minimized PASS comments as unresolved findings. Switch the issues/comments fetch to GraphQL with `isMinimized` and filter out minimized comments via jq before the existing python parser sees them. The jq projection reshapes GraphQL nodes into the REST- compatible JSON shape the parser already expects, so no parser changes are needed. Pulls/comments (inline review comments) stay on REST — they're typically real findings and don't have the minimization pollution issue. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test: update post-push-status test mock for GraphQL issue-comments fetch The previous commit switched issue-comments fetch from REST to GraphQL, but the test mock only routed REST `issues/<N>/comments` patterns. The new GraphQL call fell through to the UNEXPECTED-call fallback, causing `[]` to be returned and the existing SQL-injection assertion to fail. Update the mock to detect the GraphQL comments query (by the `comments(last:` selector in a `pullRequest(number:` operation), return raw GraphQL-shaped JSON for PRs 42, 43, and 99, and apply the actual `--jq` filter from the call's args to the raw response. Applying the real production projection in the mock means the test exercises the real Bot→`<login>[bot]` login reconstruction and the `isMinimized==false` filter, rather than baking that behavior into the mock fixtures. Add a new assertion that the minimized claude[bot] PASS comment in PR 42 is dropped — this is the headline behavior of the GraphQL switch and needs explicit coverage. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Code Bot <claude-code@smartwatermelon.github> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The CI-side
claude-blocking-reviewworkflow posts a PR comment for every review — PASS or BLOCK. The localpost-push-status.shtool scrapes bot comments to surface unresolved findings but has no way to distinguish PASS verdicts from BLOCK findings on its own. Result: every PASS comment gets surfaced as a phantom "finding" in the post-push loop, drowning out real signals.Fix
Add a new workflow step IMMEDIATELY AFTER "Check review verdict". When the verdict is PASS, the step locates the just-posted
claude-blocking-reviewcomment for the current SHA (matched via the<!-- claude-blocking-review sha=<HEAD_SHA> ... -->marker) and minimizes it via GraphQLminimizeComment(classifier: RESOLVED).BLOCK comments are NOT minimized — humans need to act on them. The audit trail is preserved either way: the comment body stays in the PR thread under the standard "Resolved" disclosure.
Design choices:
if: always()so the step runs even after the verdict-check step exits 0 normally.exit 0(non-fatal).[skip-claude-review]escape hatch is honored (no comment to minimize when the bot didn't run).classifier: RESOLVEDis the right semantics — the verdict is settled, not stale (which would beOUTDATED).gh api graphqlidiom, same-f/-Fflags, same--jqfilter style).Coordinating work
A separate PR in
claude-configwill teachpost-push-status.shto skip minimized comments via the GraphQLisMinimizedfield. That work is out of scope for this PR — this PR is purely the workflow-side change.CI behavior on this PR
The CI
claude-reviewwill SKIP automatically due to the workflow-self-modification protection (lines 154-175 in this same workflow file): theanthropics/claude-code-actionrefuses to run against a PR that modifies its own workflow file. That's by design and is documented in those lines. Local pre-commit and pre-push reviewers ran cleanly (code-reviewer + adversarial-reviewer + full-diff codebase review all PASS).Test plan
yamllint .github/workflows/claude-blocking-review.yml— only pre-existing line-length warnings on lines that mirror the existing pattern; no errors