Why this PR exists

The dispatch-28186780497 run (https://github.com/bfra-me/.github/actions/runs/28186780497) was tasked with fixing the bug that prevents @fro-bot mentions on PR conversation threads from reaching the agent. It successfully identified the bug, edited the file, wrote a changeset, validated YAML, and reported:

Next step | Caller workflow will commit, push, and open a PR

There is no caller workflow. fro-bot.yaml is a single-step agent — the run that writes a fix is the only run that ever will. The agent stopped at "written to disk" and the working tree was discarded with the runner. Two related issues:

1. Workflow bug: issue_comment on PRs was filtered out

if condition in .github/workflows/fro-bot.yaml:

(
  (
    github.event_name == 'issue_comment' &&
    github.event.issue.pull_request == null
  ) ||
  github.event_name == 'pull_request_review_comment' ||
  github.event_name == 'discussion_comment'
) && ...

The github.event.issue.pull_request == null clause was added during PR-fork hardening, but it also blocks every @fro-bot mention on a PR conversation thread: GitHub populates issue.pull_request (with the PR URL) for any comment on a PR, so the == null check always fails there. PR #2292, where marcusrbrown commented @fro-bot rebase and update this PR, is a concrete example that never reached the agent.

Safety after the fix:

• Top-level pull_request fork hardening is unchanged (only relevant for pull_request/pull_request_review_comment events, which do have a top-level pull_request field).
• The author_association gate (OWNER/MEMBER/COLLABORATOR) still blocks untrusted commenters.
• issue_comment events do not have a top-level pull_request, so the first outer if clause (github.event.pull_request == null || ...) is a no-op for them and remains unchanged.

2. Prompt bug: agent stopped at "the caller will push"

The AUTOHEAL_PROMPT had hard boundaries that said "Direct pushes are allowed only to an existing non-default PR branch you are repairing under category 1, 2, or 7." That clause covered repairs, not fresh fixes. The agent reasonably read it as "don't push" and waited for a caller that doesn't exist. New DELIVERY CONTRACT section makes it explicit that for every dispatched code change the agent itself must: create a non-default branch, commit, push, and gh pr create (or update an existing PR for the same root cause).

Files

• .github/workflows/fro-bot.yaml — remove the bad if clause; clarify the "direct push" boundary; add DELIVERY CONTRACT to the prompt
• .changeset/fix-fro-bot-issue-comment-on-pr.md — patch-level changeset per project conventions

Verification

• pnpm run type-check: clean
• pnpm run lint: clean
• pnpm test: 641 / 641 passing
• python3 -c "import yaml; yaml.safe_load(...)": parses cleanly
• Trace of the new if for @fro-bot mention on a PR comment by a MEMBER: outer github.event.pull_request == null is true (issue_comment has no top-level pull_request, so || short-circuits); inner github.event_name == 'issue_comment' true, body contains @fro-bot true, login != fro-bot true, association MEMBER ∈ [OWNER, MEMBER, COLLABORATOR] true → workflow runs.

Refs

• Run that produced this PR: https://github.com/bfra-me/.github/actions/runs/28186780497
• Original PR-fork hardening that introduced the bug: commits 78d0817 and f192ba2
• Concrete repro: PR fix(security): remediate esbuild vulnerability #2292 (marcusrbrown: @fro-bot rebase and update this PR)