claude-code-review.yml: add a claude-debug label to skip the cost gate

[jnasbyupgrade]

Debugging why the paid review isn't behaving as expected (e.g. the missing --comment flag that silently swallowed every review before #57, or the missing inline-comment --allowedTools flag before #62) previously meant either waiting 5-20+ min per iteration for the cost gate to clear, or hand-editing the workflow just to see the raw transcript.

Adding the claude-debug label to a PR now (a) skips the cost gate entirely, and (b) sets show_full_output: true so the full raw Claude Code JSON transcript, including tool results, lands in the job log. The label is checked live via gh pr view rather than the static event payload, so adding it and clicking "Re-run jobs" on an existing run picks it up without a new push.

labeled is added as a trigger type so applying the label alone kicks off a fresh run with no push/re-run needed; the job's if: scopes that to only the claude-debug label itself, so tagging a PR with anything else doesn't trigger another paid review.

Created the claude-debug label on the repo as part of this.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: e3a0cb26-6060-4f6f-ac4f-cf41cb77fd03

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Bug: adding labeled here can silently cancel an in-progress review with nothing replacing it.

The workflow-level concurrency block just below (group: claude-review-${{ github.event.pull_request.number }}, cancel-in-progress: true on the next line) is unchanged by this PR and is keyed only on the PR number. on.pull_request_target.types has no way to filter by which label was added — that filtering only happens in the job's if: (line 42). So labeled fires a new workflow run for any label, not just claude-debug.

Concurrency cancellation is resolved at run-creation time, before job-level if: conditions are evaluated. So the sequence: a review is running (triggered by synchronize) → a maintainer adds an unrelated label (e.g. documentation) → GitHub creates a new run in the same concurrency group → the in-progress review is cancelled → the new run's claude-review job is then skipped by the if: (since the label isn't claude-debug) → no review ever posts for that push, and nothing automatically retriggers it.

Before this PR, labeled wasn't a trigger at all, so this failure mode didn't exist. A fix would need to keep non-claude-debug labeled events out of the shared concurrency group (e.g. fold github.event.label.name into the group key for labeled events), rather than relying solely on the job-level if: to no-op them.

cat_tools/.github/workflows/claude-code-review.yml

Lines 18 to 24 in 59581e0

	# push/re-run needed. Scoped in the job's `if:` below to only actually
	# proceed when the label added IS claude-debug -- otherwise every
	# unrelated label added to a PR would trigger another paid review.
	types: [opened, synchronize, reopened, ready_for_review, labeled]
	concurrency:
	group: claude-review-${{ github.event.pull_request.number }}