Skip to content

chore: disable automatic PR AI review - #120

Merged
byapparov merged 3 commits into
mainfrom
chore/remove-pr-ai-review
Sep 14, 2026
Merged

byapparov merged 3 commits into
mainfrom
chore/remove-pr-ai-review

Conversation

@byapparov

Copy link
Copy Markdown
Contributor

Summary

  • remove the pull_request trigger from the Aictrl Review workflow
  • retain workflow_dispatch so reviews can still be run manually when needed

Validation

  • git diff --check
  • normal pre-commit hooks passed

@@ -1,8 +1,6 @@
name: Aictrl Review

on:

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟠 Dispatch-only mode broken: empty PR_BASE_REF skips review.

🤖 Fix with your agent
Fix this code review finding (aictrl-dev/cli PR #120, .github/workflows/code-review.yml:3-4):

Problem: Dispatch-only mode broken: empty PR_BASE_REF skips review
Detail: Removing the `pull_request` trigger leaves `workflow_dispatch` as the only way to run this workflow, but the manual path is broken: `PR_BASE_REF: ${{ github.event.pull_request.base.ref }}` (line 21) is empty on dispatch (unlike PR_SHA and the concurrency group, it has no `||` fallback, and the script's empty-PR_NUMBER recovery branch recovers only PR_NUMBER, not the base ref). The changed-files gate then runs `git diff --name-only "origin/$PR_BASE_REF...$PR_SHA"` → invalid refspec `origin/...<sha>` → git diff fails → CODE_CHANGES empty → step outputs skip=true ("No actual code changes detected"). Net effect: after this PR the workflow can never complete a review — every run, automatic or manual, silently no-ops.
Suggested fix: Recover the base ref for dispatch runs alongside PR_NUMBER, e.g. inside the existing `if [ -z "$PR_NUMBER" ]` branch add: `PR_BASE_REF=$(gh pr view "$PR_NUMBER" --json baseRefName --jq '.baseRefName')` and `echo "PR_BASE_REF=$PR_BASE_REF" >> $GITHUB_ENV`; or give the env a fallback: `PR_BASE_REF: ${{ github.event.pull_request.base.ref || 'main' }}`. Then verify a manual dispatch on an open PR actually reaches the "Run Aictrl Review" step.

Implement the fix on the PR head branch and add a regression test that fails before the fix and passes after.
Why this matters

Removing the pull_request trigger leaves workflow_dispatch as the only way to run this workflow, but the manual path is broken: PR_BASE_REF: ${{ github.event.pull_request.base.ref }} (line 21) is empty on dispatch (unlike PR_SHA and the concurrency group, it has no || fallback, and the script's empty-PR_NUMBER recovery branch recovers only PR_NUMBER, not the base ref). The changed-files gate then runs git diff --name-only "origin/$PR_BASE_REF...$PR_SHA" → invalid refspec origin/...<sha> → git diff fails → CODE_CHANGES empty → step outputs skip=true ("No actual code changes detected"). Net effect: after this PR the workflow can never complete a review — every run, automatic or manual, silently no-ops.

@@ -1,8 +1,6 @@
name: Aictrl Review

on:

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Auto PR review disabled with no compensating gate.

🤖 Fix with your agent
Fix this code review finding (aictrl-dev/cli PR #120, .github/workflows/code-review.yml:3):

Problem: Auto PR review disabled with no compensating gate
Detail: After this change no PR to main/master gets an automated AI review unless someone with write access manually dispatches the workflow, and fork-based contributor PRs cannot be auto-reviewed at all. The PR title says the disabling is intentional, but no compensating control or re-enable tracking is visible: if this is temporary, reference the tracking issue in the commit/PR; if permanent, document the replacement gate (e.g. required status check, scheduled dispatch, or an org-level policy) so merges to main/master don't silently lose review coverage.

Implement the fix on the PR head branch and add a regression test that fails before the fix and passes after.
Why this matters

After this change no PR to main/master gets an automated AI review unless someone with write access manually dispatches the workflow, and fork-based contributor PRs cannot be auto-reviewed at all. The PR title says the disabling is intentional, but no compensating control or re-enable tracking is visible: if this is temporary, reference the tracking issue in the commit/PR; if permanent, document the replacement gate (e.g. required status check, scheduled dispatch, or an org-level policy) so merges to main/master don't silently lose review coverage.

@aictrl-dev

aictrl-dev Bot commented Sep 14, 2026

Copy link
Copy Markdown

Code review

Verdict: Address the major findings before merging. · 🔴 0 · 🟠 1 · 🟡 1 · ⚪ 0 · 0/2 resolved

  • 🟠 .github/workflows/code-review.yml:3-4 — Dispatch-only mode broken: empty PR_BASE_REF skips review
  • 🟡 .github/workflows/code-review.yml:3 — Auto PR review disabled with no compensating gate
🤖 Fix all 2 open findings with your agent
Fix the following code review findings on aictrl-dev/cli PR #120 (head branch).
Run the relevant tests/linters after each change.

1. .github/workflows/code-review.yml:3-4 — Dispatch-only mode broken: empty PR_BASE_REF skips review
   Detail: Removing the `pull_request` trigger leaves `workflow_dispatch` as the only way to run this workflow, but the manual path is broken: `PR_BASE_REF: ${{ github.event.pull_request.base.ref }}` (line 21) is empty on dispatch (unlike PR_SHA and the concurrency group, it has no `||` fallback, and the script's empty-PR_NUMBER recovery branch recovers only PR_NUMBER, not the base ref). The changed-files gate then runs `git diff --name-only "origin/$PR_BASE_REF...$PR_SHA"` → invalid refspec `origin/...<sha>` → git diff fails → CODE_CHANGES empty → step outputs skip=true ("No actual code changes detected"). Net effect: after this PR the workflow can never complete a review — every run, automatic or manual, silently no-ops.
   Suggested fix: Recover the base ref for dispatch runs alongside PR_NUMBER, e.g. inside the existing `if [ -z "$PR_NUMBER" ]` branch add: `PR_BASE_REF=$(gh pr view "$PR_NUMBER" --json baseRefName --jq '.baseRefName')` and `echo "PR_BASE_REF=$PR_BASE_REF" >> $GITHUB_ENV`; or give the env a fallback: `PR_BASE_REF: ${{ github.event.pull_request.base.ref || 'main' }}`. Then verify a manual dispatch on an open PR actually reaches the "Run Aictrl Review" step.
2. .github/workflows/code-review.yml:3 — Auto PR review disabled with no compensating gate
   Detail: After this change no PR to main/master gets an automated AI review unless someone with write access manually dispatches the workflow, and fork-based contributor PRs cannot be auto-reviewed at all. The PR title says the disabling is intentional, but no compensating control or re-enable tracking is visible: if this is temporary, reference the tracking issue in the commit/PR; if permanent, document the replacement gate (e.g. required status check, scheduled dispatch, or an org-level policy) so merges to main/master don't silently lose review coverage.
📋 Out-of-diff findings (2)
Sev Location Finding
🟠 .github/workflows/code-review.yml:3-4 Dispatch-only mode broken: empty PR_BASE_REF skips review
🟡 .github/workflows/code-review.yml:3 Auto PR review disabled with no compensating gate

Reviewed 1 files · 0 inline · view all 2 findings ↗


aictrl · AI code review for fast-moving teams · aictrl.dev

@byapparov byapparov self-assigned this Sep 14, 2026
@byapparov

Copy link
Copy Markdown
Contributor Author

Review response — PR #120

Verified and fixed both findings against review SHA 7363a19851; the workflow remains intentionally manual-only.

Issues addressed (pushed to this PR)

  • Dispatch-only mode broken: empty PR_BASE_REF skips review.github/workflows/code-review.yml: manual dispatch now resolves the selected PR's baseRefName, exports it for later steps, and fails visibly if resolution returns an empty value (commit 38210c5aa5).
  • Auto PR review disabled with no compensating gate.github/workflows/code-review.yml: documented that AI review is an opt-in advisory check dispatched by maintainers, while maintainer review and the standard CI and CodeQL checks remain the merge-quality controls (commit 38210c5aa5).

Review claims verified false (no change needed)

None.

Not addressed here

None.

Comment thread .github/workflows/code-review.yml Outdated
echo "Found PR #$PR_NUMBER for branch $BRANCH"
echo "PR_NUMBER=$PR_NUMBER" >> $GITHUB_ENV

PR_BASE_REF=$(gh pr view "$PR_NUMBER" --json baseRefName --jq '.baseRefName')

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Unvalidated base branch flows into agent prompt.

🤖 Fix with your agent
Fix this code review finding (aictrl-dev/cli PR #120, .github/workflows/code-review.yml:48-53):

Problem: Unvalidated base branch flows into agent prompt
Detail: baseRefName is chosen by the PR author (any existing repo branch; git allows `$`, backticks, `;` in ref names) and is exported verbatim to GITHUB_ENV, then interpolated into the review-agent prompt at line 153 (`base: ${PR_BASE_REF}`) that drives an agent allowed to run `gh *` with a GITHUB_TOKEN holding pull-requests/issues write. Later shell uses are quoted, so this is a prompt-injection channel rather than command injection, and the branch must already exist in the repo — but the agent-facing prompt is unvalidated input.
Suggested fix: Validate before export, e.g. `git rev-parse --verify "origin/$PR_BASE_REF" >/dev/null || exit 1` and/or an allowlist regex such as `^[A-Za-z0-9._/-]+$` before writing PR_BASE_REF to $GITHUB_ENV.

Implement the fix on the PR head branch and add a regression test that fails before the fix and passes after.
Why this matters

baseRefName is chosen by the PR author (any existing repo branch; git allows $, backticks, ; in ref names) and is exported verbatim to GITHUB_ENV, then interpolated into the review-agent prompt at line 153 (base: ${PR_BASE_REF}) that drives an agent allowed to run gh * with a GITHUB_TOKEN holding pull-requests/issues write. Later shell uses are quoted, so this is a prompt-injection channel rather than command injection, and the branch must already exist in the repo — but the agent-facing prompt is unvalidated input.

            PR_BASE_REF=$(gh pr view "$PR_NUMBER" --json baseRefName --jq '.baseRefName')
            if [ -z "$PR_BASE_REF" ]; then
              echo "Could not determine the base branch for PR #$PR_NUMBER."
              exit 1
            fi
            echo "PR_BASE_REF=$PR_BASE_REF" >> $GITHUB_ENV

on:
pull_request:
branches: [main, master]
workflow_dispatch:

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Fork PRs can no longer be AI-reviewed, even manually.

Suggested change
workflow_dispatch:
If fork coverage matters, accept a PR number/URL via workflow_dispatch inputs and resolve the head SHA with `gh pr view --json headRefOid` instead of relying on the dispatched ref; otherwise document the fork gap in the policy comment.
🤖 Fix with your agent
Fix this code review finding (aictrl-dev/cli PR #120, .github/workflows/code-review.yml:7):

Problem: Fork PRs can no longer be AI-reviewed, even manually
Detail: workflow_dispatch can only select refs that exist in the base repo, so PRs from forks (head branch lives only in the contributor's fork) cannot be dispatched against, and the resolve step's `gh pr list --head $GITHUB_REF_NAME` (line 39) can never match a fork head. External contributions therefore lose AI review entirely — contradicting the PR body's claim that "reviews can still be run manually when needed".
Suggested fix: If fork coverage matters, accept a PR number/URL via workflow_dispatch inputs and resolve the head SHA with `gh pr view --json headRefOid` instead of relying on the dispatched ref; otherwise document the fork gap in the policy comment.

Implement the fix on the PR head branch and add a regression test that fails before the fix and passes after.
Why this matters

workflow_dispatch can only select refs that exist in the base repo, so PRs from forks (head branch lives only in the contributor's fork) cannot be dispatched against, and the resolve step's gh pr list --head $GITHUB_REF_NAME (line 39) can never match a fork head. External contributions therefore lose AI review entirely — contradicting the PR body's claim that "reviews can still be run manually when needed".

# the merge-quality controls.
on:
  workflow_dispatch:

concurrency:
  group: aictrl-review-${{ github.event.pull_request.number || github.ref }}
  cancel-in-progress: true

Comment thread .github/workflows/code-review.yml Outdated
echo "Found PR #$PR_NUMBER for branch $BRANCH"
echo "PR_NUMBER=$PR_NUMBER" >> $GITHUB_ENV

PR_BASE_REF=$(gh pr view "$PR_NUMBER" --json baseRefName --jq '.baseRefName')

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 gh pr view failure bypasses base-ref guard under bash -e.

--- a/.github/workflows/code-review.yml
+++ b/.github/workflows/code-review.yml
@@ -45,7 +45,7 @@
             echo "Found PR #$PR_NUMBER for branch $BRANCH"
             echo "PR_NUMBER=$PR_NUMBER" >> $GITHUB_ENV
 
-            PR_BASE_REF=$(gh pr view "$PR_NUMBER" --json baseRefName --jq '.baseRefName')
+            PR_BASE_REF=$(gh pr view "$PR_NUMBER" --json baseRefName --jq '.baseRefName' 2>/dev/null || true)
             if [ -z "$PR_BASE_REF" ]; then
               echo "Could not determine the base branch for PR #$PR_NUMBER."
               exit 1
🤖 Fix with your agent
Fix this code review finding (aictrl-dev/cli PR #120, .github/workflows/code-review.yml:48):

Problem: gh pr view failure bypasses base-ref guard under bash -e
Detail: The step runs under GitHub Actions' default `bash -e`, so if `gh pr view` exits non-zero (rate limit, transient 5xx, token issue) the assignment at line 48 aborts the step immediately — the `[ -z "$PR_BASE_REF" ]` guard with its "Could not determine the base branch" message is unreachable for real gh failures and only fires if gh succeeds but prints empty output, which is near-impossible for baseRefName. Inconsistent with the sibling lookup at line 39 which uses `2>/dev/null || true`.
Suggested fix: Append `2>/dev/null || true` inside the command substitution so the existing `-z` guard handles both gh failure and empty output and exits with the intended message.

Suggested patch:
--- a/.github/workflows/code-review.yml
+++ b/.github/workflows/code-review.yml
@@ -45,7 +45,7 @@
             echo "Found PR #$PR_NUMBER for branch $BRANCH"
             echo "PR_NUMBER=$PR_NUMBER" >> $GITHUB_ENV
 
-            PR_BASE_REF=$(gh pr view "$PR_NUMBER" --json baseRefName --jq '.baseRefName')
+            PR_BASE_REF=$(gh pr view "$PR_NUMBER" --json baseRefName --jq '.baseRefName' 2>/dev/null || true)
             if [ -z "$PR_BASE_REF" ]; then
               echo "Could not determine the base branch for PR #$PR_NUMBER."
               exit 1

Implement the fix on the PR head branch and add a regression test that fails before the fix and passes after.
Why this matters

The step runs under GitHub Actions' default bash -e, so if gh pr view exits non-zero (rate limit, transient 5xx, token issue) the assignment at line 48 aborts the step immediately — the [ -z "$PR_BASE_REF" ] guard with its "Could not determine the base branch" message is unreachable for real gh failures and only fires if gh succeeds but prints empty output, which is near-impossible for baseRefName. Inconsistent with the sibling lookup at line 39 which uses 2>/dev/null || true.

            echo "Found PR #$PR_NUMBER for branch $BRANCH"
            echo "PR_NUMBER=$PR_NUMBER" >> $GITHUB_ENV

            PR_BASE_REF=$(gh pr view "$PR_NUMBER" --json baseRefName --jq '.baseRefName')
            if [ -z "$PR_BASE_REF" ]; then
              echo "Could not determine the base branch for PR #$PR_NUMBER."
              exit 1
            fi
            echo "PR_BASE_REF=$PR_BASE_REF" >> $GITHUB_ENV

@@ -1,8 +1,9 @@
name: Aictrl Review

# Policy: AI review is opt-in and advisory. Maintainers dispatch this workflow for

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Policy comment cites CodeQL checks absent from the repo.

Suggested change
# Policy: AI review is opt-in and advisory. Maintainers dispatch this workflow for
Drop "and CodeQL" ("maintainer review plus the standard CI checks remain the merge-quality controls") or verify and reference the org-level CodeQL default setup explicitly.
🤖 Fix with your agent
Fix this code review finding (aictrl-dev/cli PR #120, .github/workflows/code-review.yml:3-5):

Problem: Policy comment cites CodeQL checks absent from the repo
Detail: The new policy comment claims "maintainer review plus the standard CI and CodeQL checks remain the merge-quality controls", but no CodeQL workflow or config exists in the repository (.github/workflows contains only ci.yml, code-review.yml, publish.yml; ci.yml has no CodeQL job). Unless CodeQL runs via org-level default setup, the comment misleads contributors about the actual merge gates.
Suggested fix: Drop "and CodeQL" ("maintainer review plus the standard CI checks remain the merge-quality controls") or verify and reference the org-level CodeQL default setup explicitly.

Implement the fix on the PR head branch and add a regression test that fails before the fix and passes after.
Why this matters

The new policy comment claims "maintainer review plus the standard CI and CodeQL checks remain the merge-quality controls", but no CodeQL workflow or config exists in the repository (.github/workflows contains only ci.yml, code-review.yml, publish.yml; ci.yml has no CodeQL job). Unless CodeQL runs via org-level default setup, the comment misleads contributors about the actual merge gates.

name: Aictrl Review

# Policy: AI review is opt-in and advisory. Maintainers dispatch this workflow for
# PRs that need it; maintainer review plus the standard CI and CodeQL checks remain
# the merge-quality controls.
on:
  workflow_dispatch:

@aictrl-dev

aictrl-dev Bot commented Sep 14, 2026

Copy link
Copy Markdown

Code review

Verdict: Looks good — only minor / nit comments below. · 🔴 0 · 🟠 0 · 🟡 4 · ⚪ 2 · 0/6 resolved

  • .github/workflows/code-review.yml:3-5 — Policy comment cites CodeQL checks absent from the repo
  • 🟡 .github/workflows/code-review.yml:7 — Fork PRs can no longer be AI-reviewed, even manually
  • .github/workflows/code-review.yml:10 — Stale pull_request context in concurrency group expression
  • 🟡 .github/workflows/code-review.yml:48-53 — Unvalidated base branch flows into agent prompt
  • 🟡 .github/workflows/code-review.yml:48 — gh pr view failure bypasses base-ref guard under bash -e
  • 🟡 .github/workflows/code-review.yml:66 — 2-review safety cap is dead code now
🤖 Fix all 6 open findings with your agent
Fix the following code review findings on aictrl-dev/cli PR #120 (head branch).
Run the relevant tests/linters after each change.

1. .github/workflows/code-review.yml:3-5 — Policy comment cites CodeQL checks absent from the repo
   Detail: The new policy comment claims "maintainer review plus the standard CI and CodeQL checks remain the merge-quality controls", but no CodeQL workflow or config exists in the repository (.github/workflows contains only ci.yml, code-review.yml, publish.yml; ci.yml has no CodeQL job). Unless CodeQL runs via org-level default setup, the comment misleads contributors about the actual merge gates.
   Suggested fix: Drop "and CodeQL" ("maintainer review plus the standard CI checks remain the merge-quality controls") or verify and reference the org-level CodeQL default setup explicitly.
2. .github/workflows/code-review.yml:7 — Fork PRs can no longer be AI-reviewed, even manually
   Detail: workflow_dispatch can only select refs that exist in the base repo, so PRs from forks (head branch lives only in the contributor's fork) cannot be dispatched against, and the resolve step's `gh pr list --head $GITHUB_REF_NAME` (line 39) can never match a fork head. External contributions therefore lose AI review entirely — contradicting the PR body's claim that "reviews can still be run manually when needed".
   Suggested fix: If fork coverage matters, accept a PR number/URL via workflow_dispatch inputs and resolve the head SHA with `gh pr view --json headRefOid` instead of relying on the dispatched ref; otherwise document the fork gap in the policy comment.
3. .github/workflows/code-review.yml:10 — Stale pull_request context in concurrency group expression
   Detail: With the pull_request trigger removed, `github.event.pull_request.number` is always empty on workflow_dispatch, so the group always falls back to `github.ref`. The expression is dead, and two dispatches for the same PR from different refs (e.g. once from the PR branch, once from main) land in different concurrency groups, allowing duplicate concurrent review runs on the same PR.
   Suggested fix: Simplify to `group: aictrl-review-${{ github.ref }}`, or key the group on the resolved PR number so dispatches from any ref for the same PR share one group.
4. .github/workflows/code-review.yml:48-53 — Unvalidated base branch flows into agent prompt
   Detail: baseRefName is chosen by the PR author (any existing repo branch; git allows `$`, backticks, `;` in ref names) and is exported verbatim to GITHUB_ENV, then interpolated into the review-agent prompt at line 153 (`base: ${PR_BASE_REF}`) that drives an agent allowed to run `gh *` with a GITHUB_TOKEN holding pull-requests/issues write. Later shell uses are quoted, so this is a prompt-injection channel rather than command injection, and the branch must already exist in the repo — but the agent-facing prompt is unvalidated input.
   Suggested fix: Validate before export, e.g. `git rev-parse --verify "origin/$PR_BASE_REF" >/dev/null || exit 1` and/or an allowlist regex such as `^[A-Za-z0-9._/-]+$` before writing PR_BASE_REF to $GITHUB_ENV.
5. .github/workflows/code-review.yml:48 — gh pr view failure bypasses base-ref guard under bash -e
   Detail: The step runs under GitHub Actions' default `bash -e`, so if `gh pr view` exits non-zero (rate limit, transient 5xx, token issue) the assignment at line 48 aborts the step immediately — the `[ -z "$PR_BASE_REF" ]` guard with its "Could not determine the base branch" message is unreachable for real gh failures and only fires if gh succeeds but prints empty output, which is near-impossible for baseRefName. Inconsistent with the sibling lookup at line 39 which uses `2>/dev/null || true`.
   Suggested fix: Append `2>/dev/null || true` inside the command substitution so the existing `-z` guard handles both gh failure and empty output and exits with the intended message.
6. .github/workflows/code-review.yml:66 — 2-review safety cap is dead code now
   Detail: IS_MANUAL (line 25) is `${{ github.event_name == 'workflow_dispatch' }}`, and workflow_dispatch is now the only trigger, so `[ "$IS_MANUAL" != "true" ]` at line 66 is never true: the skip-after-2-AI-reviews safety cap is dead code, and its "use workflow_dispatch to force" message is stale. Since the job holds `pull-requests: write`, a repeatedly dispatched run can post unlimited AI comments on a PR with nothing left to cap it.
   Suggested fix: Either drop the `&& [ "$IS_MANUAL" != "true" ]` condition so the 2-review cap applies to manual runs too, or remove the dead branch together with the now-constant IS_MANUAL env (line 25) and the REVIEW_COMMENTS computation (line 57) that only feeds it.
📋 Out-of-diff findings (6)
Sev Location Finding
.github/workflows/code-review.yml:3-5 Policy comment cites CodeQL checks absent from the repo
🟡 .github/workflows/code-review.yml:7 Fork PRs can no longer be AI-reviewed, even manually
.github/workflows/code-review.yml:10 Stale pull_request context in concurrency group expression
🟡 .github/workflows/code-review.yml:48-53 Unvalidated base branch flows into agent prompt
🟡 .github/workflows/code-review.yml:48 gh pr view failure bypasses base-ref guard under bash -e
🟡 .github/workflows/code-review.yml:66 2-review safety cap is dead code now

Reviewed 1 files · 0 inline · view all 6 findings ↗


aictrl · AI code review for fast-moving teams · aictrl.dev

@byapparov

Copy link
Copy Markdown
Contributor Author

Review response — PR #120

Verified and fixed all six findings against review SHA 38210c5aa5; automatic pull-request review remains disabled.

Issues addressed (pushed to this PR)

  • Policy comment cites CodeQL checks absent from the repo.github/workflows/code-review.yml: removed the unsupported CodeQL claim from the manual-only policy (commit f8c294e49c).
  • Fork PRs can no longer be AI-reviewed, even manually.github/workflows/code-review.yml: added an optional pr_number dispatch input, resolve the PR base and head through gh pr view, and detect changes through gh pr diff --name-only, which works without a fork head commit in the checkout (commit f8c294e49c).
  • Stale pull-request context in concurrency group expression.github/workflows/code-review.yml: keyed concurrency on the PR input when supplied and the selected ref otherwise (commit f8c294e49c).
  • Unvalidated base branch flows into agent prompt.github/workflows/code-review.yml: validate the base name against a safe ref character set and require its origin ref to resolve before export or interpolation; the head SHA is also validated (commit f8c294e49c).
  • gh pr view failure bypasses base-ref guard under bash -e.github/workflows/code-review.yml: made the lookup safely return empty data on command failure so the explicit diagnostic guard handles it (commit f8c294e49c).
  • Two-review safety cap is dead code.github/workflows/code-review.yml: removed the constant IS_MANUAL condition and stale force-dispatch message so the cap applies to every manual run (commit f8c294e49c).

Review claims verified false (no change needed)

None.

Not addressed here

None.

@byapparov
byapparov merged commit b0b6cf4 into main Sep 14, 2026
4 checks passed
@byapparov
byapparov deleted the chore/remove-pr-ai-review branch September 14, 2026 18:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant