fix(dispatch): resolve PR head SHA for issue_comment events

[ggallen]

Summary

• Fix issue_comment-triggered agents (/fs-review, /fs-code, /fs-fix) using the .fullsend config repo's checkout SHA instead of the target PR's head SHA
• Add a "Resolve PR head" step in dispatch.yml that fetches PR info from the API for issue_comment events and merges it into the event_payload
• Fix action.yml's reconcile step to extract the SHA from the dispatched event payload instead of using github.sha directly

Root cause

Comment-triggered agents (/fs-review, /fs-code, /fs-fix) build event_payload with a jq filter over $GITHUB_EVENT_PATH that only copies a top-level .pull_request object.

issue_comment events do not have that field — GitHub puts PR linkage under .issue.pull_request (URL-only) — so the payload gets "pull_request": null. Downstream steps then treat the config-repo checkout SHA (GITHUB_SHA) as the PR head: status comments show the wrong commit, and fullsend post-review submits reviews with a commit_id that does not exist in the target repo (GitHub 422).

Affects all comment-triggered classic-stage agents. See #5271 for a code-agent example.

Changes

File	Change
internal/scaffold/fullsend-repo/.github/workflows/dispatch.yml	Add "Resolve PR head" step that fetches PR info via API for issue_comment events; merge into event_payload
action.yml	Reconcile step now extracts SHA from the dispatched event payload, falling back to GITHUB_SHA
internal/cli/run_test.go	Add test cases for null pull_request and resolved PR in event payload

Test plan

• TestPRHeadSHAFromEventPath_NullPullRequest — documents the broken case (returns empty, doesn't panic)
• TestPRHeadSHAFromEventPath_IssueCommentWithResolvedPR — verifies SHA extraction after the dispatch fix
• All existing TestPRHeadSHAFromEventPath_* and TestSetupStatusNotifier_* tests pass
• After merge: verify /fs-review on a PR shows the correct commit SHA in the status comment and submits the review successfully

Closes fullsend-ai/.fullsend#126

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 10:30 PM UTC · Completed 10:44 PM UTC
Commit: d8bd4fc · View workflow run →

[qodo-code-review]

PR Summary by Qodo

Fix dispatch: resolve PR head SHA for issue_comment-triggered agents

🐞 Bug fix 🧪 Tests ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Fetch PR head SHA for issue_comment events and inject into dispatched event_payload.
• Fix reconcile logic to prefer PR head SHA from event payload over config-repo GITHUB_SHA.
• Add regression tests for null/missing pull_request and resolved issue_comment payloads.

Diagram

graph TD
A{{"issue_comment event"}} --> B["dispatch.yml"] --> C["Resolve PR head (gh api)"] --> D["event_payload w/ head.sha"] --> E["action.yml reconcile"] --> F["prHeadSHAFromEventPath()"]
T["run_test.go tests"] --> F

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Resolve PR head in CLI/runtime (not dispatch)

• ➕ Keeps dispatch workflow simpler (no API call + JSON merge).
• ➕ Centralizes event normalization in one code path (Go).
• ➖ Every agent entrypoint must handle issue_comment PR resolution correctly.
• ➖ Requires adding authenticated API calls to runtime paths (more failure modes during agent runs).

2. Use curl against github.event.issue.pull_request.url (no gh CLI)

• ➕ Avoids dependency on gh CLI availability/behavior in the runner.
• ➕ More explicit control over headers, retries, and timeouts.
• ➖ More verbose shell code and easier to get JSON parsing wrong.
• ➖ Must manage auth headers and error handling manually.

3. Always resolve PR info when pull_request is missing (broader condition)

• ➕ More robust to future events that provide only URL references.
• ➕ Reduces dependence on exact event payload shape.
• ➖ May introduce extra API calls for non-PR issue_comment events unless carefully gated.
• ➖ Needs careful conditional logic to avoid unnecessary work.

Recommendation: Current approach (resolve PR head during dispatch and enrich event_payload) is the best fit because it normalizes the event once, upstream of all agents, and fixes both status/review paths consistently. The only follow-up worth considering is switching gh api to a direct curl call if runner environments ever lack gh or if tighter control over retries/timeouts is needed.

Files changed (3) +80 / -2

Bug fix (1) +16 / -1

action.ymlReconcile step extracts PR head SHA from dispatched event payload +16/-1

Reconcile step extracts PR head SHA from dispatched event payload

• Adds logic to compute COMMIT_SHA by parsing inputs.event_payload.pull_request.head.sha from GITHUB_EVENT_PATH. Falls back to GITHUB_SHA when the dispatched payload doesn’t contain a PR head SHA, preventing cross-repo dispatch from using the config repo checkout SHA.

action.yml

Tests (1) +31 / -0

run_test.goAdd regression tests for issue_comment SHA resolution edge cases +31/-0

Add regression tests for issue_comment SHA resolution edge cases

• Introduces tests ensuring prHeadSHAFromEventPath returns empty (no panic) when pull_request is null and correctly extracts head.sha when dispatch injects a resolved pull_request object into inputs.event_payload.

internal/cli/run_test.go

Other (1) +33 / -1

dispatch.ymlResolve PR head SHA for issue_comment events and merge into event_payload +33/-1

Resolve PR head SHA for issue_comment events and merge into event_payload

• Adds a conditional step that calls the GitHub API to fetch PR head metadata for issue_comment events on PRs. Merges the fetched PR JSON into the computed EVENT_PAYLOAD so downstream workflows can reliably read pull_request.head.sha.

internal/scaffold/fullsend-repo/.github/workflows/dispatch.yml

[github-actions]

Site preview

Preview: https://01a693a4-site.fullsend-ai.workers.dev

Commit: f9af4d56717855775c97217eec7405ab92cfc1a7

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 📜 Skill insights (0)

Context used

✅ Tickets: 🎫 feat(repos): glob patterns in repos.yaml exclude private repositories 🎫 Story 3: Triage Agent

✅ Compliance rules (platform): 61 rules

✅ Skills: writing-user-docs, writing-adrs

1. Workflow size limit increased ✓ Resolved 📘 Rule violation ▣ Testability

Description

The PR increases the lint-workflow-size max-lines override from 475 to 510 in dispatch.yml,
which weakens an existing linter guardrail rather than addressing the underlying workflow growth.
This violates the requirement to not weaken linters to make checks pass without explicit, justified
necessity.

Code

internal/scaffold/fullsend-repo/.github/workflows/dispatch.yml[2]

+# lint-workflow-size: max-lines=510

Relevance

⭐⭐⭐ High

Team previously accepted raising workflow-size override caps when stale/needed (PR #791); also
accepted other lint relaxations (PR #1543).

PR-#791
PR-#1543

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 1062076 prohibits weakening linters to make failures pass. The changed override
comment increases the allowed workflow size, and the lint script explicitly treats this comment as a
per-file cap override.

Rule 1062076: Do not weaken tests or linters to make failures pass
internal/scaffold/fullsend-repo/.github/workflows/dispatch.yml[1-2]
hack/lint-workflow-size[13-18]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The workflow linter cap was raised (`max-lines=510`), which weakens the lint constraint intended to prevent accumulating logic in workflow YAML.

## Issue Context
The repository uses `hack/lint-workflow-size` to enforce a per-file line limit, with an override comment meant to be an intentional and rare exception. Increasing the cap makes the linter less strict for this workflow.

## Fix Focus Areas
- internal/scaffold/fullsend-repo/.github/workflows/dispatch.yml[1-5]
- hack/lint-workflow-size[13-18]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Dispatch payload logic out-of-sync ✓ Resolved 📘 Rule violation ⚙ Maintainability

Description

internal/scaffold/.../dispatch.yml now resolves PR head SHA for issue_comment events and injects
it into event_payload, but /.github/workflows/reusable-dispatch.yml still builds payloads from
the raw event only. This violates the requirement to keep jq payload/routing/secret-threading logic
in sync across both dispatch workflows and can leave per-repo dispatch behavior inconsistent/broken
for issue_comment PRs.

Code

internal/scaffold/fullsend-repo/.github/workflows/dispatch.yml[R389-416]

+      - name: Resolve PR head for issue_comment events
+        id: pr-head
+        if: steps.route.outputs.stage != '' && steps.role-check.outputs.skipped != 'true' && steps.pr-check.outputs.skipped != 'true' && github.event_name == 'issue_comment' && github.event.issue.pull_request
+        env:
+          GH_TOKEN: ${{ github.token }}
+          SOURCE_REPO: ${{ github.repository }}
+          PR_NUMBER: ${{ github.event.issue.number }}
+        run: |
+          set -euo pipefail
+          # issue_comment events have no top-level pull_request with head SHA.
+          # Fetch it from the API so downstream agents get the correct commit.
+          PR_JSON=$(gh api "repos/${SOURCE_REPO}/pulls/${PR_NUMBER}" \
+            --jq '{number, html_url,
+              head: {ref: .head.ref, sha: .head.sha, repo: {full_name: .head.repo.full_name}},
+              base: {ref: .base.ref, repo: {full_name: .base.repo.full_name}}}') || {
+            echo "::error::Failed to fetch PR #${PR_NUMBER} head info"
+            exit 1
+          }
+          DELIM="PR_$(openssl rand -hex 8)"
+          {
+            echo "pr_json<<${DELIM}"
+            echo "${PR_JSON}"
+            echo "${DELIM}"
+          } >> "${GITHUB_OUTPUT}"
+
      - name: Find and trigger agent workflows for stage
        if: steps.route.outputs.stage != '' && steps.role-check.outputs.skipped != 'true' && steps.pr-check.outputs.skipped != 'true'
        env:

Relevance

⭐ Low

Similar “keep scaffold dispatch in sync with reusable” suggestion explicitly rejected in PR #3820;
divergence tolerated.

PR-#3820

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 1062045 requires jq payload, routing, and secret threading logic to match between
dispatch.yml and reusable-dispatch.yml. The PR adds PR-head resolution and payload merging in
the scaffold workflow, but the reusable workflow still builds event_payload without any PR-head
resolution/merge, creating a divergence.

Rule 1062045: Keep jq payload, stage routing, and secret threading logic in dispatch workflows in sync
internal/scaffold/fullsend-repo/.github/workflows/dispatch.yml[389-442]
.github/workflows/reusable-dispatch.yml[419-443]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`dispatch.yml` (scaffold/per-org) now resolves PR head SHA for `issue_comment` events and merges it into `event_payload`, but `reusable-dispatch.yml` (per-repo) does not. This breaks the compliance requirement that jq payload construction and related routing/threading logic stay in sync.

## Issue Context
The PR adds a `Resolve PR head for issue_comment events` step and merges API-fetched PR data into `.pull_request` in the outgoing payload. The per-repo reusable workflow still extracts `.pull_request` solely from the raw event, which is typically missing for `issue_comment` events on PRs.

## Fix Focus Areas
- internal/scaffold/fullsend-repo/.github/workflows/dispatch.yml[389-442]
- .github/workflows/reusable-dispatch.yml[419-443]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[fullsend-ai-review]

Review

Findings

Medium

• [protected-path] .github/workflows/reusable-dispatch.yml — This PR modifies a file under the protected .github/ path. The PR links to Post-review script uses config repo SHA as commit_id for comment-triggered reviews .fullsend#126 and the description explains the rationale (fixing wrong commit SHA for issue_comment events). Human approval is always required for protected-path changes, regardless of context.

Low

• [fail-open] .github/workflows/reusable-dispatch.yml:415 — The "Resolve PR head for issue_comment events" step has differentiated failure behavior by stage: for fix and review stages, API failure exits 1 (fail-closed), but for other stages (triage, code, retro), it warns and continues with exit 0. This is by design — the PR head SHA is only functionally required for stages that push code or post reviews. The fallback to GITHUB_SHA for other stages affects only status comment display, not authorization or security.

Previous run

Review

Findings

Medium

• [test-adequacy] internal/scaffold/workflow_call_alignment_test.go — TestReusableDispatchPRHeadSHAPassthrough iterates over stages (triage, code, review, fix, retro) but runs the identical assertion assert.Contains(t, s, "pr-head-sha:") in every subtest without using the stage variable. Since s is the entire workflow file, the test passes if pr-head-sha: appears anywhere at least once — it would not detect if a specific stage's job was missing the input. Each subtest should scope its search to the relevant job section.
  Remediation: Use a section-aware assertion that verifies pr-head-sha: appears between each job header and the next, rather than searching the entire file.

• [protected-path] .github/workflows/reusable-dispatch.yml — This PR modifies a file under the protected .github/ path. The PR links to Post-review script uses config repo SHA as commit_id for comment-triggered reviews .fullsend#126 and the description explains the rationale (fixing wrong commit SHA for issue_comment events). Human approval is always required for protected-path changes, regardless of context.

Low

• [misleading-warning] action.yml — In the reconcile step's SHA resolution block, the warning event_payload present but pull_request.head.sha extraction failed fires whenever event_payload exists but pull_request is null or missing head.sha. This is expected for events on plain issues (not PRs). The warning text says extraction "failed" when the data simply isn't applicable.

• [dispatch-sync-incomplete] internal/scaffold/fullsend-repo/.github/workflows/dispatch.yml — The reusable-dispatch.yml has a separate "Build event payload" step (id: payload) while the scaffold dispatch.yml inlines the event_payload construction into "Find and trigger agent workflows." Both receive the same PR_HEAD_JSON merge, but the structural difference means the merge happens at different points in the flow. The behavior is equivalent, but the divergence increases maintenance burden over time.

Previous run (2)

Review

Findings

Medium

• [architectural-violation] .github/workflows/reusable-dispatch.yml:408 — The new "Resolve PR head for issue_comment events" step uses direct gh api calls to fetch PR metadata. AGENTS.md establishes that forge operations must go through the forge.Client interface. While existing gh api calls in workflow files are grandfathered, AGENTS.md states grandfathered calls "should be migrated when touched" — and this PR refactors the existing gh api call at this location.
  Remediation: Extract the PR head resolution logic into a new fullsend CLI subcommand (e.g., fullsend resolve-pr-head --repo REPO --number NUM) that uses forge.Client.GetPullRequest() or equivalent.

• [protected-path] .github/workflows/reusable-dispatch.yml — This PR modifies a file under the protected .github/ path. The PR links to issue Post-review script uses config repo SHA as commit_id for comment-triggered reviews .fullsend#126 and the description explains the rationale (fixing wrong commit SHA for issue_comment events). Human approval is always required for protected-path changes, regardless of context.

Low

• [pr-metadata] PR title uses fix(dispatch): but COMMITS.md prefers issue number as scope when fixing a specific issue. Since the linked issue is cross-repo (Post-review script uses config repo SHA as commit_id for comment-triggered reviews .fullsend#126), fix(dispatch): is a reasonable alternative — fix(#126) would reference the wrong repo's issue Story 3: Triage Agent #126.

• [dispatch-sync-incomplete] internal/scaffold/fullsend-repo/.github/workflows/dispatch.yml:412 — Both dispatch files receive equivalent changes, but the structural organization differs (reusable has a separate "Build event payload" step; scaffold inlines into "Find and trigger agent workflows"). Verify both produce identical event_payload output for issue_comment events.

Previous run

Review

Findings

High

• [dispatch workflow sync violation] .github/workflows/reusable-dispatch.yml — The PR adds a "Resolve PR head for issue_comment events" step and event_payload merging logic to the scaffold dispatch.yml but does not apply the same change to reusable-dispatch.yml. Per AGENTS.md: "The scaffold dispatch.yml and the repo's reusable-dispatch.yml share identical routing logic... When changing the jq payload construction, stage routing, or input/secret threading in one, apply the same change to the other." The reusable-dispatch.yml "Build event payload" step (line ~419) constructs the same jq payload but lacks the PR head resolution for issue_comment events. In per-repo mode, issue_comment-triggered agents will still receive an event_payload with pull_request: null, meaning the same wrong-SHA bug persists for per-repo installations.
  Remediation: Add an equivalent "Resolve PR head for issue_comment events" step before the "Build event payload" step in reusable-dispatch.yml, and add equivalent merging logic after the EVENT_PAYLOAD construction. The step should use the same gh api call and the same conditional (github.event_name == 'issue_comment' && github.event.issue.pull_request). The merge should inject the API-fetched pull_request object into the EVENT_PAYLOAD output.

Low

• [edge-case] action.yml — If event_payload is present but contains malformed JSON, the second jq invocation will fail and || true will swallow the error, leaving COMMIT_SHA empty, which then falls back to GITHUB_SHA. This is the desired behavior for robustness — the error suppression is intentional and safe.

Previous run (3)

Review

Findings

Medium

• [architectural-violation] .github/workflows/reusable-dispatch.yml:408 — The new "Resolve PR head for issue_comment events" step uses direct gh api calls to fetch PR metadata. AGENTS.md establishes that forge operations must go through the forge.Client interface. While existing gh api calls in workflow files are grandfathered, AGENTS.md states grandfathered calls "should be migrated when touched" — and this PR refactors the existing gh api call at this location.
  Remediation: Extract the PR head resolution logic into a new fullsend CLI subcommand (e.g., fullsend resolve-pr-head --repo REPO --number NUM) that uses forge.Client.GetPullRequest() or equivalent.

• [protected-path] .github/workflows/reusable-dispatch.yml — This PR modifies a file under the protected .github/ path. The PR links to issue Post-review script uses config repo SHA as commit_id for comment-triggered reviews .fullsend#126 and the description explains the rationale (fixing wrong commit SHA for issue_comment events). Human approval is always required for protected-path changes, regardless of context.

Low

• [pr-metadata] PR title uses fix(dispatch): but COMMITS.md prefers issue number as scope when fixing a specific issue. Since the linked issue is cross-repo (Post-review script uses config repo SHA as commit_id for comment-triggered reviews .fullsend#126), fix(dispatch): is a reasonable alternative — fix(#126) would reference the wrong repo's issue Story 3: Triage Agent #126.

• [dispatch-sync-incomplete] internal/scaffold/fullsend-repo/.github/workflows/dispatch.yml:412 — Both dispatch files receive equivalent changes, but the structural organization differs (reusable has a separate "Build event payload" step; scaffold inlines into "Find and trigger agent workflows"). Verify both produce identical event_payload output for issue_comment events.

Previous run (4)

Review

Findings

High

• [dispatch workflow sync violation] .github/workflows/reusable-dispatch.yml — The PR adds a "Resolve PR head for issue_comment events" step and event_payload merging logic to the scaffold dispatch.yml but does not apply the same change to reusable-dispatch.yml. Per AGENTS.md: "The scaffold dispatch.yml and the repo's reusable-dispatch.yml share identical routing logic... When changing the jq payload construction, stage routing, or input/secret threading in one, apply the same change to the other." The reusable-dispatch.yml "Build event payload" step (line ~419) constructs the same jq payload but lacks the PR head resolution for issue_comment events. In per-repo mode, issue_comment-triggered agents will still receive an event_payload with pull_request: null, meaning the same wrong-SHA bug persists for per-repo installations.
  Remediation: Add an equivalent "Resolve PR head for issue_comment events" step before the "Build event payload" step in reusable-dispatch.yml, and add equivalent merging logic after the EVENT_PAYLOAD construction. The step should use the same gh api call and the same conditional (github.event_name == 'issue_comment' && github.event.issue.pull_request). The merge should inject the API-fetched pull_request object into the EVENT_PAYLOAD output.

Low

• [edge-case] action.yml — If event_payload is present but contains malformed JSON, the second jq invocation will fail and || true will swallow the error, leaving COMMIT_SHA empty, which then falls back to GITHUB_SHA. This is the desired behavior for robustness — the error suppression is intentional and safe.

[ggallen]

/fs-fix fix all of the review issues uncovered, both by qodo and the fullsend-ai-bot. Squash the commit and rebase.

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 11:04 PM UTC · Completed 11:20 PM UTC
Commit: 750b81c · View workflow run →

Superseded by updated review

[waynesun09]

Multi-agent review squad (Claude, Grok, Codex — 4 agents, findings cross-verified against the head branch). Posting the deduplicated MEDIUM+ findings as inline comments below; low/info items omitted.

Also verified clean, for the record: the fork-block consolidation does not regress security — the fix-stage check runs in every case the old step ran, stays fail-closed on API errors, the GITHUB_OUTPUT heredoc delimiter is injection-safe, and untrusted comment input never reaches shell interpolation.

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 3:42 PM UTC · Completed 3:58 PM UTC
Commit: a6ca0c0 · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 4:02 PM UTC · Completed 4:18 PM UTC
Commit: f9af4d5 · View workflow run →

[fullsend-ai-review]

See the review comment for full details.

[waynesun09]

Ran 3 independent reviews (Claude x2, Grok) plus my own verification, focused on whether the current state (after 4 rounds of fixes) is genuinely correct rather than just re-litigating resolved threads. One new HIGH finding below, confirmed by tracing the actual code myself. Also two minor LOW notes: the PR body cites #5271 as a "code-agent example" of this bug, but #5271 is unrelated (a repos.yaml glob-pattern feature) — the actual documented repro is fullsend-ai/.fullsend#126, already cited correctly elsewhere in the body, likely a copy-paste slip. And TestReusableDispatchPRHeadSHAPassthrough/the scaffold-alignment test check the two dispatch YAML files' "Resolve PR head" step against a fixed checklist independently rather than diffing them against each other — currently identical, but nothing would catch future one-sided drift in this specific step. Everything else (stage-aware error handling, fork-PR safety, injection surface, token scope, the two new prHeadSHAFromEventPath tests) checks out clean across all three reviews. Not blocking this PR given the maintainer approval and green CI, but worth a fast follow-up.

[waynesun09]

Approve. Review-squad pass (3 agents) plus my own independent verification found one real HIGH gap (harness-run job doesn't receive the fix — filed as #5329, out of scope for this PR since it's a pre-existing bug in a different code path this PR doesn't touch) and two minor LOW notes (wrong issue reference in the PR body, missing cross-file test for the new step) — see inline review for details. Nothing here blocks this PR: the five stage jobs it targets are fixed correctly, verified end-to-end against the linked repro (fullsend-ai/.fullsend#126), and the fork-PR/security handling is sound.

[fullsend-ai-retro]

🤖 Retro · ❌ Terminated · Started 7:08 PM UTC · Ended 7:25 PM UTC
Commit: f9af4d5 · View workflow run →

[fullsend-ai-retro]

Retro: PR #5274 — fix(dispatch): resolve PR head SHA for issue_comment events

PR #5274 is a human-authored infrastructure fix by ggallen, discovered while observing the code agent working on issue #5271. It fixes issue_comment-triggered agents using the .fullsend config repo's checkout SHA instead of the target PR's head SHA.

Workflow overview

• Code agent (for feat(repos): glob patterns in repos.yaml exclude private repositories #5271): Produced PR feat(#5271): include private repos in repos.yaml glob expansion #5275 in a single iteration — clean, well-tested implementation. One successful fix iteration for stale docs, one failed fix iteration (DCO violation on autonomous commit).
• Review agent (on fix(dispatch): resolve PR head SHA for issue_comment events #5274): Ran 5 rounds across 4 commits. Found 4 substantive issues (1 HIGH dispatch-sync violation — high-value early catch — plus 1 MEDIUM and 2 LOW). Also produced 3–4 self-negating LOW findings that consumed reviewer attention without adding value.
• Human reviewer (waynesun09): Used a multi-agent review squad (4 independent agents) and found 6 additional findings (2 HIGH, 4 MEDIUM) that the review agent completely missed, including the most critical issue: the fix did not reach per-repo workflow_call mode.
• Fix agent (on fix(dispatch): resolve PR head SHA for issue_comment events #5274): The /fs-fix command was correctly blocked because the PR came from a fork — expected security behavior, not a bug. The author applied fixes manually.

Key quality gap

The review agent validated the fix for one deployment mode (workflow_dispatch) and missed the other (workflow_call), reviewed each file in relative isolation rather than tracing the SHA through all deployment paths, and accepted tests that exercise unchanged code while the actual fix had zero automated coverage.

Proposals filed

1. Review agent test-adequacy check should verify tests exercise code changed by the PR — The agent accepted tests for an unchanged function while the actual fix lacked coverage.
2. Counter-evidence for review autonomy on dispatch infrastructure PRs — Human reviewer found 6 findings (2 HIGH, 4 MEDIUM) that the agent missed entirely.
3. Review agent should validate fixes across all deployment modes for dispatch infrastructure changes — The agent checked only the workflow_dispatch path and missed that workflow_call and harness-run modes were uncovered.

Proposals filed

• Review agent test-adequacy check should verify tests exercise code changed by the PR, not just that tests exist (in fullsend-ai/fullsend)
• Counter-evidence for review autonomy: human reviewer found all critical findings on dispatch infrastructure PR #5274 (in fullsend-ai/fullsend)
• Review agent should validate fixes across all deployment modes when reviewing dispatch infrastructure changes (in fullsend-ai/fullsend)