[eventrelay-ci-investigator] blocked run 30152612300: missing source workflow_run payload

[github-actions]

Focused execution contract

Agent login

google-labs-jules[bot]

Agent run ID

17777940839649608045

Objective

Allow the actual internal MCP gateway hostname awmg-mcpg through the network firewall in the three existing agentic workflows and keep their generated lock files synchronized.

Acceptance criteria

• The three workflow Markdown sources allow exact hostname awmg-mcpg.
• The three matching lock files contain the same hostname and current frontmatter hashes.
• The patch changes only those six workflow source/lock files.
• The hostname review finding is resolved on exact head 522e46d6a312f35d180d36d45fa39056c2bc4a3e.
• Exact-head completion checks accept the corrected receipt and implementation.

Declared file scope

• .github/workflows/canonical-pr-remediator.md
• .github/workflows/canonical-pr-remediator.lock.yml
• .github/workflows/eventrelay-ci-investigator.md
• .github/workflows/eventrelay-ci-investigator.lock.yml
• .github/workflows/focused-coverage-controller.md
• .github/workflows/focused-coverage-controller.lock.yml

Allowed extra files

None.

Focused test paths

• Exact-head compare from ca132ab6eb670ea08f1619be4701ee52ec667998.
• Source/lock token scan: zero AWMGMCPG, expected awmg-mcpg entries present.
• Frontmatter hash validation for all three generated locks.
• Agent Completion Truth Gate.

Pre-dispatch confirmation

• Objective, acceptance criteria, scope, and focused-test expectations are complete.

Execution receipt

• Canonical branch / PR: jules-17777940839649608045-490ff2bd / fix: allow awmg-mcpg gateway in workflow firewalls #1052
• Claimed: 2026-07-27T21:50:35Z
• Latest heartbeat: 2026-07-27T22:22:26Z
• Exact head: 522e46d6a312f35d180d36d45fa39056c2bc4a3e

---

agent id: eventrelay-ci-investigator
workflow run id: 30152612300
workflow version / lock hash: .github/workflows/eventrelay-ci-investigator.lock.yml@b24f3aa9202926849a3f9e8f8a026e47eec85f68, frontmatter_hash=29e87b80b30f697a95953ee333814f783eb950bf33a815c3861ff2454700213c, body_hash=db86ab41ca32e4ef5905d00ea66edbc4f150a3776b3a87011795bbf5997ed92b
exact head SHA: b24f3aa9202926849a3f9e8f8a026e47eec85f68
heartbeat timestamp: 2026-07-25T09:23:59Z
conclusion class: blocked
estimated run cost: low (local repo checks plus targeted GitHub metadata reads)

What Was Checked

• Verified the investigator workflow checkout is on main and matches origin/main at b24f3aa9202926849a3f9e8f8a026e47eec85f68.
• Verified the active workflow file and embedded lock metadata in .github/workflows/eventrelay-ci-investigator.lock.yml.
• Queried GitHub for canonical issue #898, commit b24f3aa9202926849a3f9e8f8a026e47eec85f68, PR search by SHA, PR #989, and existing blocker records for this run id.
• Checked the advertised event payload path and runner temp tree for a serialized workflow_run payload.

What Changed Since Previous State

• main is now at merge commit b24f3aa9202926849a3f9e8f8a026e47eec85f68, which GitHub attributes to merged PR #989.
• No prior blocker record was found for run 30152612300, so this record is the first deduplicated report for the current blocked state.

Exact Blockers

• Required workflow-run datum is missing: GITHUB_EVENT_PATH points to /home/runner/work/_temp/_github_workflow/event.json, but that file does not exist in the runner. A recursive search of /home/runner/work/_temp found no substitute event payload containing the source workflow_run object.
• Because the source workflow_run payload is absent and the available GitHub read surface here does not expose workflow-run reads, the investigator cannot verify the upstream source run id, source workflow file version, source pull_requests[], or whether the failing signal was authoritative for the same SHA. This prevents SHA-bound classification under the workflow contract.
• Governance failure found while reconciling repository truth: merged PR #989 resolves to canonical issue #898 directly (linked:pr 989), not to a focused child issue under #898, so canonical issue linkage is fail-closed.

Recommended Next Bounded Action

1. Restore an accessible workflow_run payload for investigator runs, or expose a read-only workflow-run GitHub surface to this workflow.
2. Re-run the investigator against the exact upstream source run once its workflow_run.id, pull_requests[], and head_sha are observable.
3. Correct governance by routing future implementation PRs through focused child issues under #898 instead of linking implementation PRs directly to #898.

Evidence

• Investigator run: https://github.com/groupthinking/EventRelay/actions/runs/30152612300
• Workflow source: https://github.com/groupthinking/EventRelay/blob/b24f3aa9202926849a3f9e8f8a026e47eec85f68/.github/workflows/eventrelay-ci-investigator.lock.yml
• Current main commit: b24f3aa
• Merged PR: fix: keep API v1 router loading when google-genai is absent #989
• Canonical issue: [PROGRAM][OWNER:Codex] Autonomous EventRelay delivery control plane #898

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• awmgmcpg

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "awmgmcpg"

See Network Configuration for more information.

Generated by EventRelay CI Investigator (report-first) · 12.3 AIC · ⌖ 1.61 AIC · ⊞ 13K · ◷

[linear-code]

GRV-116

[coderabbitai]

🔗 Related PRs

#222 - docs: branch-cleanup assessment + reproducible fail-test harness [merged]
#277 - Vercel remediation complete: waitUntil adoption + active middleware + @vercel/functions package (resolves three user-defined outcomes; 16-agent verification-gate consolidated PASS on full matrix) [closed]
#404 - fix(web): sync package-lock with @vercel/functions (unblocks #277 auto-merge) [merged]
#411 - ci: add agentic verification loop workflow and refactor state log [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[google-labs-jules]

Jules is on it. When finished, you will see another comment and be able to review a PR.

[coderabbitai]

Coding Plan

Summary

• Fix the root-cause bug in the .md source, not the generated lock file: enable the actions MCP toolset, inject a pre-agent-steps: step that serializes workflow_run into the sandbox-mounted ${RUNNER_TEMP}/gh-aw/ path, and allow the awmgmcpg MCP gateway host through the firewall — then recompile with pinned gh aw v0.82.14 and commit both files so the CI sync check passes.
• Update the prompt contract so the agent reads the serialized payload and Actions API instead of treating the absent GITHUB_EVENT_PATH as a fatal blocker.
• Close the governance gap by adding a merged-PR remediation clause to the SOP and enforcing "link a focused child issue, not epic #898" in pr-governance.yml and the PR template.

Design Choices

Design Choice 1: How should the investigator obtain the source workflow_run data?

Options Considered:

1. Enable only the actions MCP toolset and rely on API calls (get_workflow_run, list_workflow_jobs) to reconstruct run metadata from github.run_id-adjacent data.
2. Add only a pre-agent-steps: block that serializes the raw github.event.workflow_run payload into a sandbox-mounted path for the agent to read.
3. Do both: serialize the event payload into a mounted file via pre-agent-steps: AND enable the actions toolset for follow-up API verification (logs, job status, authoritativeness for the SHA).

Chosen Option: 3

Rationale: The event file behind GITHUB_EVENT_PATH is not mounted into the sandboxed agent, and the GitHub MCP actions toolset is not enabled, so today the agent has neither the local payload nor an API surface for workflow-run reads. Doing both wins because the pre-agent step guarantees the canonical workflow_run.id/head_sha/pull_requests[] are available regardless of sandbox mount behavior, while the actions toolset provides the read APIs the contract requires for SHA-bound verification — the ticket explicitly asks for both a restored payload and a workflow-run read surface.

Design Choice 2: Should the focused-child-issue rule be machine-enforced, or documented only?

Options Considered:

1. Documentation-only: add a retroactive-remediation clause to the SOP.
2. Documentation plus a lightweight enforcement guard in pr-governance.yml that fails a PR whose sole closing reference is the epic (#898).

Chosen Option: 2

Rationale: The rule exists only in prose today; pr-governance.yml treats #898 like any other issue. The ticket's recommended action is to "route future implementation PRs through focused child issues," which is only durable if enforced; the guard is a small, bounded extension at an existing decision point.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Restore investigator access to source workflow_run data

This phase fixes the actual production bug that fail-closes every workflow_run-triggered run. The goal is to make the upstream run's identity and status observable to the agent through two complementary channels (a mounted payload file and the Actions read API), unblock the MCP gateway at the firewall, and keep the prompt contract honest about where that data now comes from. All edits are made to the .md source; the .lock.yml is regenerated, never hand-edited.

Task 1: Enable the GitHub actions MCP toolset

Give the agent the tool calls it needs to read workflow-run metadata, jobs, and logs.

• Update .github/workflows/eventrelay-ci-investigator.md frontmatter to add a tools.github.toolsets block containing [context, repos, issues, pull_requests, actions], mirroring focused-coverage-controller.md.
• Rationale: permissions: actions: read alone does not expand the GitHub MCP server's toolset; without the explicit actions toolset the compiled lock file sets GITHUB_TOOLSETS without actions, so get_workflow_run/list_workflow_jobs/get_job_logs are simply unavailable — the direct cause of "the available GitHub read surface here does not expose workflow-run reads."

Task 2: Serialize the workflow_run payload into a sandbox-mounted path

Guarantee the agent can read the upstream run payload even though the raw GITHUB_EVENT_PATH file is never mounted into the sandbox.

• Add a pre-agent-steps: block to .github/workflows/eventrelay-ci-investigator.md frontmatter (pattern proven in focused-coverage-controller.md) that runs unsandboxed on the runner with full ${{ github.event.workflow_run.* }} context.
• The step must write the relevant fields — at minimum id, head_sha, head_branch, conclusion, html_url, workflow_id/name, and pull_requests[] — into a file under ${RUNNER_TEMP}/gh-aw/ (e.g. ${RUNNER_TEMP}/gh-aw/workflow-run-context.json), because only that directory is bind-mounted (read-only) into the agent sandbox; the default _github_workflow/event.json location is not.
• Guard the step for github.event_name == 'workflow_run' so workflow_dispatch invocations don't fail.

Task 3: Allow the MCP gateway host through the firewall

Stop the firewall from silently breaking MCP tool calls.

• Update the network: frontmatter in .github/workflows/eventrelay-ci-investigator.md to allow the blocked awmgmcpg host alongside defaults, per the firewall warning in the run report.
• Rationale: the reported block of awmgmcpg (the gh-aw MCP gateway host) can sever the agent's tool channel entirely; leaving it blocked would make Task 1.1's toolset addition ineffective at runtime.

Task 4: Update the prompt body to consume the serialized payload

Tell the agent where the authoritative source-run data now lives so it stops treating a missing GITHUB_EVENT_PATH as a hard blocker.

• Edit the prompt body of .github/workflows/eventrelay-ci-investigator.md so the "Required verification before classification" instructions direct the agent to read ${RUNNER_TEMP}/gh-aw/workflow-run-context.json for source workflow_run.id, head_sha, and pull_requests[], then confirm/enrich via the actions toolset APIs.
• Clarify that absence of the legacy GITHUB_EVENT_PATH file is expected and is no longer a blocker condition on its own.
• Keep the existing report-first / single-deduplicated-blocker output contract and safe-outputs caps unchanged.

Task 5: Recompile and verify lock-file sync

Produce the compiled artifact the way CI expects.

• Run gh aw compile eventrelay-ci-investigator --validate --approve using the pinned gh aw v0.82.14, then the --actionlint --zizmor --poutine --approve pass, mirroring gh-aw-validation.yml.
• Commit .github/workflows/eventrelay-ci-investigator.md and the regenerated .github/workflows/eventrelay-ci-investigator.lock.yml together so the CI git diff --exit-code sync check passes.
• Confirm the compiled lock file shows GITHUB_TOOLSETS including actions, the injected pre-agent-steps step, and the updated allowDomains list.

🤖 Prompt for AI agents

Implement the fix for the eventrelay-ci-investigator gh-aw workflow so it no
longer fail-closes on workflow_run triggers. All edits target the `.md` source
file only — never hand-edit the compiled `.lock.yml`.

1. In `.github/workflows/eventrelay-ci-investigator.md` frontmatter, add a
`tools.github.toolsets` block listing `[context, repos, issues, pull_requests,
actions]`, mirroring the pattern already used in
`focused-coverage-controller.md`. This is required because `permissions:
actions: read` alone does not expand the GitHub MCP server's toolset — without
the explicit `actions` entry, `get_workflow_run`, `list_workflow_jobs`, and
`get_job_logs` remain unavailable.

2. Add a `pre-agent-steps:` block to the same frontmatter (pattern proven in
`focused-coverage-controller.md`) that runs unsandboxed on the runner with full
`${{ github.event.workflow_run.* }}` context, guarded by `github.event_name ==
'workflow_run'` so `workflow_dispatch` runs don't fail. This step must write at
minimum `id`, `head_sha`, `head_branch`, `conclusion`, `html_url`,
`workflow_id`/name, and `pull_requests[]` into a file under
`${RUNNER_TEMP}/gh-aw/` (e.g. `${RUNNER_TEMP}/gh-aw/workflow-run-context.json`),
since only that directory is bind-mounted read-only into the agent sandbox — the
default `_github_workflow/event.json` path is not mounted.

3. Update the `network:` frontmatter to allow the `awmgmcpg` host (the gh-aw MCP
gateway) alongside `defaults`, so the firewall stops silently breaking MCP tool
calls and the new `actions` toolset actually works at runtime.

4. Edit the prompt body so the "Required verification before classification"
section instructs the agent to read
`${RUNNER_TEMP}/gh-aw/workflow-run-context.json` for the source
`workflow_run.id`, `head_sha`, and `pull_requests[]`, then confirm/enrich that
data via the `actions` toolset APIs. Clarify that a missing legacy
`GITHUB_EVENT_PATH` file is expected and no longer a blocker on its own. Do not
change the existing report-first / single-deduplicated-blocker output contract
or the `safe-outputs` caps.

5. Recompile using the pinned `gh aw` v0.82.14: run `gh aw compile
eventrelay-ci-investigator --validate --approve`, then the `--actionlint
--zizmor --poutine --approve` pass, mirroring `gh-aw-validation.yml`. Commit the
`.md` source together with the regenerated `.lock.yml` so CI's `git diff
--exit-code` sync check passes. Verify the compiled lock file shows
`GITHUB_TOOLSETS` including `actions`, the injected `pre-agent-steps` step, and
the updated `allowDomains` list.

Phase 2: Close the focused-child-issue governance gap

This phase addresses the secondary finding: PR #989 closed the canonical epic #898 directly. The goal is to document a concrete remediation procedure for already-merged violations and to prevent recurrence with a minimal automated guard.

Task 1: Add a retroactive-remediation clause to the SOP

Fill the documented gap: the SOP defines the forward rule but has no procedure for a merged PR that violated it.

• Extend .jules/agent_orchestration_sop.md (near the "Canonical execution unit" / "Current-state lookup" sections) with an explicit remediation procedure for merged PRs that closed #898 directly: (a) open a focused child issue capturing the merged work, (b) reconcile the linkage via a follow-up comment/edit on the merged PR pointing at the child issue (since a merged PR's closing keyword can't be rewritten), and (c) update #898 to reference the child issue rather than the PR — consistent with the existing "repair #898 from live evidence" principle.
• Reference PR #989 as the triggering instance so the remediation is actionable.

Task 2: Enforce "no direct epic linkage" in PR governance

Make the child-issue rule durable rather than convention-only.

• Extend .github/workflows/pr-governance.yml at the point where the single canonical issue is resolved via github.rest.issues.get() to fail the check when the sole closing reference is the epic itself (#898), or when the resolved issue carries an epic marker (e.g., an epic label).
• Keep the change narrow: reuse the existing issue object already fetched; do not restructure the existing regex/single-issue logic.
• Update .github/pull_request_template.md guidance to state that Closes # must target a focused child issue, never the canonical epic.

🤖 Prompt for AI agents

Close the governance gap exposed by PR `#989` linking directly to canonical epic
`#898` instead of a focused child issue. This has two parts: a documentation fix
and a lightweight enforcement guard.

1. Extend `.jules/agent_orchestration_sop.md`, near the "Canonical execution
unit" / "Current-state lookup" sections, with an explicit
retroactive-remediation procedure for merged PRs that closed `#898` directly: (a)
open a focused child issue capturing the merged work, (b) reconcile the linkage
via a follow-up comment/edit on the merged PR pointing at the child issue (since
a merged PR's closing keyword can't be rewritten), and (c) update `#898` to
reference the child issue rather than the PR — consistent with the existing
"repair `#898` from live evidence" principle. Reference PR `#989` explicitly as the
triggering instance so the remediation is actionable.

2. Extend `.github/workflows/pr-governance.yml` at the point where the single
canonical issue is resolved via `github.rest.issues.get()`. Add a check that
fails when the sole closing reference is the epic itself (`#898`), or when the
resolved issue carries an epic marker (e.g., an `epic` label). Keep this change
narrow — reuse the existing `issue` object already fetched, and do not
restructure the existing regex/single-issue logic.

3. Update `.github/pull_request_template.md` guidance to explicitly state that
`Closes #` must target a focused child issue, never the canonical epic.

Research

This is the groupthinking/EventRelay repo. The relevant assets are GitHub Agentic Workflows (gh-aw): human-authored *.md frontmatter+prompt sources under .github/workflows/, compiled 1:1 into *.lock.yml artifacts by the pinned gh aw CLI (v0.82.14). gh-aw-validation.yml compiles the three custom workflows and fails CI if the committed .lock.yml drifts from a fresh compile (git diff --exit-code), so lock files must never be hand-edited.

focused-coverage-controller.md is the working reference: it enables the actions MCP toolset and uses a pre-agent-steps: block to run unsandboxed runner steps with full GitHub Actions context.

Governance conventions ("canonical epic #898 → focused child issue") live in prose in .jules/agent_orchestration_sop.md and the agent .md prompts; the only machine-enforced check is pr-governance.yml, which validates "exactly one open canonical issue" but does not distinguish the epic from a child issue.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement the fix for the eventrelay-ci-investigator gh-aw workflow so it no
longer fail-closes on workflow_run triggers. All edits target the `.md` source
file only — never hand-edit the compiled `.lock.yml`.

1. In `.github/workflows/eventrelay-ci-investigator.md` frontmatter, add a
`tools.github.toolsets` block listing `[context, repos, issues, pull_requests,
actions]`, mirroring the pattern already used in
`focused-coverage-controller.md`. This is required because `permissions:
actions: read` alone does not expand the GitHub MCP server's toolset — without
the explicit `actions` entry, `get_workflow_run`, `list_workflow_jobs`, and
`get_job_logs` remain unavailable.

2. Add a `pre-agent-steps:` block to the same frontmatter (pattern proven in
`focused-coverage-controller.md`) that runs unsandboxed on the runner with full
`${{ github.event.workflow_run.* }}` context, guarded by `github.event_name ==
'workflow_run'` so `workflow_dispatch` runs don't fail. This step must write at
minimum `id`, `head_sha`, `head_branch`, `conclusion`, `html_url`,
`workflow_id`/name, and `pull_requests[]` into a file under
`${RUNNER_TEMP}/gh-aw/` (e.g. `${RUNNER_TEMP}/gh-aw/workflow-run-context.json`),
since only that directory is bind-mounted read-only into the agent sandbox — the
default `_github_workflow/event.json` path is not mounted.

3. Update the `network:` frontmatter to allow the `awmgmcpg` host (the gh-aw MCP
gateway) alongside `defaults`, so the firewall stops silently breaking MCP tool
calls and the new `actions` toolset actually works at runtime.

4. Edit the prompt body so the "Required verification before classification"
section instructs the agent to read
`${RUNNER_TEMP}/gh-aw/workflow-run-context.json` for the source
`workflow_run.id`, `head_sha`, and `pull_requests[]`, then confirm/enrich that
data via the `actions` toolset APIs. Clarify that a missing legacy
`GITHUB_EVENT_PATH` file is expected and no longer a blocker on its own. Do not
change the existing report-first / single-deduplicated-blocker output contract
or the `safe-outputs` caps.

5. Recompile using the pinned `gh aw` v0.82.14: run `gh aw compile
eventrelay-ci-investigator --validate --approve`, then the `--actionlint
--zizmor --poutine --approve` pass, mirroring `gh-aw-validation.yml`. Commit the
`.md` source together with the regenerated `.lock.yml` so CI's `git diff
--exit-code` sync check passes. Verify the compiled lock file shows
`GITHUB_TOOLSETS` including `actions`, the injected `pre-agent-steps` step, and
the updated `allowDomains` list.
===============================================================================

Task: 2

Close the governance gap exposed by PR `#989` linking directly to canonical epic
`#898` instead of a focused child issue. This has two parts: a documentation fix
and a lightweight enforcement guard.

1. Extend `.jules/agent_orchestration_sop.md`, near the "Canonical execution
unit" / "Current-state lookup" sections, with an explicit
retroactive-remediation procedure for merged PRs that closed `#898` directly: (a)
open a focused child issue capturing the merged work, (b) reconcile the linkage
via a follow-up comment/edit on the merged PR pointing at the child issue (since
a merged PR's closing keyword can't be rewritten), and (c) update `#898` to
reference the child issue rather than the PR — consistent with the existing
"repair `#898` from live evidence" principle. Reference PR `#989` explicitly as the
triggering instance so the remediation is actionable.

2. Extend `.github/workflows/pr-governance.yml` at the point where the single
canonical issue is resolved via `github.rest.issues.get()`. Add a check that
fails when the sole closing reference is the epic itself (`#898`), or when the
resolved issue carries an epic marker (e.g., an `epic` label). Keep this change
narrow — reuse the existing `issue` object already fetched, and do not
restructure the existing regex/single-issue logic.

3. Update `.github/pull_request_template.md` guidance to explicitly state that
`Closes #` must target a focused child issue, never the canonical epic.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[google-labs-jules]

Ready for a review! A PR has been created.