fix(pr-pipeline): stop broker workflow-modified refusals failing work-resolve-issue runs

Problem

Broker workflow-modified refusals are the largest single cause of work-resolve-issue failures: 31 of 91 failures between 2026-10-16 and 2026-10-23 (GitHub Support count from failure annotations). Other causes: 23 broker github-unavailable, 17 max-turns, 10 installation rate limit, 10 other.

Investigate

Which workflow change trips the refusal on issue-lane runs: a real edit to a workflow file by the lane, or the broker comparing against a main that moved since the run started. #7895 covers reporting a superseded refusal as neutral on PR lanes; this is the issue lane.

Done when

The cause is named, and issue-lane runs no longer fail on it, or fail only for a real workflow edit.

Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.

Size: Medium
Complexity: Medium
Uncertainty: Knowable
Flags: none
Blocked by: none

Decision recorded.
The owner answered in the Refinement session (2026-10-25), deciding the open items below on the facts:

go with whatever the facts/data/metrics + /discovery:research says and ensure we're aligned with SOLID, DRY/SSOT principles

I should only ever be in the loop ONLY when necessary (intent/vision changed, something came up during implementation that impacts trajectory/alignment, OR a high security risk) - I've covered this all before

[quote truncated; the full decision is at the link]

#9498 (comment)

The decision settles the open questions. Name the cause from post-2.11.7 runs. Treat a moved main as a retry marker that work-unblock re-fires. A real workflow edit still fails. The broker exception is unchanged. Nothing further is asked.

_{Automated triage, applied by the lanes App.}

Not admitted to the issue lane: Uncertainty knowable is not one of known; it has no - [ ] task list to check. A recorded decision does not change these rules (.github/actions/resolve-config/admission-rules.json); a person who wants it worked adds agent-ready.

Refinement. A read-only run explored this repository, searched its issues and pull requests, and read the allowed docs to draft what follows. It is model text, to check, not instructions.

Intended outcome: Name the cause of issue-lane workflow-modified refusals, then make a main that moved during the run never fail an issue run, so only a real lane edit to a workflow file does.

Related work

fix(pr-pipeline): report a workflow-modified refusal that a re-fire supersedes as neutral, not failure #7895 (related): Same refusal on PR lanes: reports a superseded refusal as neutral. This issue is the issue-lane counterpart.
fix(pr-pipeline): stop a slot-queued issue run on stale workflow files before the mint #8078 (related): Merged: stops a slot-queued issue run on stale workflow files before the mint (workflow-stale). It covers one moved-main path already.
docs(pr-pipeline): note the broker's report-job exception to workflow-modified #8066 (related): Merged docs note on the broker's report-job exception to workflow-modified.
fix(pr-pipeline): the mint-failed re-fire for resolve-issue matches a step the read runner does not have #9102 (related): Open: the mint-failed re-fire for resolve-issue matches a step the read runner lacks. It may affect re-firing refused issue runs.
pr-pipeline: re-fire PR-lane runs lost to a broker 5xx or token 403 #8446 (related): Open: re-fire PR-lane runs lost to a broker 5xx or token 403.

Open questions

Do the 31 failures come from runs that started before the 2026-10-18 fixes (the workflow-stale pre-check and the report-job exception), or do they still happen after them?
RECOMMENDED: Count only failures after the 2026-10-18 release (2.11.7) and name the cause from those, since earlier ones are already addressed. Basis: .base/docs/conventions/pr-pipeline/CHANGELOG.md:1485
Is the cause a main that moved during the run, rather than a real lane edit to a workflow file?
RECOMMENDED: Yes, most likely. The docs say an issue run executes the default branch's files, so its refusal means main moved. The model job holds only read tokens and returns a patch, so a lane workflow edit looks unlikely. The failed runs' annotations should confirm which file the refusal named. Basis: .base/docs/conventions/pr-pipeline/pr-run-activity.md:1658
Which fix should the lane use when main moves after the workflow-current check but before the apply-issue-patch mint?
RECOMMENDED: Fail the run with a retry marker so work-unblock's sweep re-fires it on main's files, as it does for workflow-stale. The alternative, widening the broker's report-job exception to the apply job, is a broker trust change the owner should decide. Basis: .base/docs/conventions/pr-pipeline/pr-run-activity.md:1726
Should the failure count be rechecked by an unattended run, or does this issue need the maintainer to supply the annotation breakdown?
RECOMMENDED: Have the maintainer paste the annotation breakdown for the post-2026-10-18 failures, since an unattended run cannot read Actions annotations. Basis: judgment

Sources read

/home/runner/work/claude-code-plugins/claude-code-plugins/.base/docs/conventions/pr-pipeline/pr-run-activity.md:1653: a pull_request run executes the PR's own workflow files; a dispatched or issue run executes the default branch's files, so its refusal means the default branch moved and it stays red
/home/runner/work/claude-code-plugins/claude-code-plugins/.base/docs/conventions/pr-pipeline/pr-run-activity.md:1705: issue mode: a waiting run keeps its label event's workflow files; the workflow-current step fails red workflow-stale before any model turn, and work-unblock's sweep re-fires it
/home/runner/work/claude-code-plugins/claude-code-plugins/.base/docs/conventions/pr-pipeline/pr-run-activity.md:1634: broker 403 workflow-modified has a report-job exception for signed linear main commits landed after run start, at most 50 minutes ago
/home/runner/work/claude-code-plugins/claude-code-plugins/.base/docs/conventions/pr-pipeline/CHANGELOG.md:1485: 2.11.7 added the workflow-stale pre-check for slot-queued issue runs
/home/runner/work/claude-code-plugins/claude-code-plugins/.base/docs/conventions/pr-pipeline/CHANGELOG.md:1530: 2.11.2 added the report-job exception to workflow-modified
/home/runner/work/claude-code-plugins/claude-code-plugins/.base/.github/workflows/pr-run-activity-read.yml:782: workflow-current step, which fails red workflow-stale
/home/runner/work/claude-code-plugins/claude-code-plugins/.base/.github/scripts/pr-merge/refire-refused.mjs:80: pr-merge's re-fire matches only PR-lane refusals of the form 'differs from refs/heads/main'

_{Automated refinement by the lanes App. Answer with a comment whose first line is **Decision recorded.**.}

Decision recorded. The owner answered in the Refinement session (2026-10-25), deciding the open items below on the facts:

go with whatever the facts/data/metrics + /discovery:research says and ensure we're aligned with SOLID, DRY/SSOT principles

I should only ever be in the loop ONLY when necessary (intent/vision changed, something came up during implementation that impacts trajectory/alignment, OR a high security risk) - I've covered this all before

Question asked: Treat a main that moved before the apply mint as a retry (re-fired on main's files, like workflow-stale), not a broker exception change?

(intake Q1) Count only failures after the 2026-10-18 fixes?
Decided: Yes. Name the cause from runs after 2.11.7, which added the workflow-stale pre-check. Basis: kept; docs/conventions/pr-pipeline/CHANGELOG.md:1485.
(intake Q2) Is the cause a main that moved, not a real lane edit?
Decided: Most likely. An issue run executes the default branch's files, so its refusal means main moved; a waiting apply job keeps its label event's files. The refusal annotations should confirm the file named. Basis: kept; docs/conventions/pr-pipeline/pr-run-activity.md:1810-1813 and :1876-1885 on origin/main (moved from intake's :1658,:1705).
(intake Q3) Trust-boundary call. Which fix when main moves between workflow-current and the apply-issue-patch mint?
Decided: Fail the run with a retry marker so work-unblock's sweep re-fires it on main's files, as for workflow-stale. Widening the broker's report-job exception to the apply job is a broker trust change for the owner. Basis: kept; pr-run-activity.md:1789 (report-job exception scope) and :1882-1888.
(intake Q4) Who supplies the annotation breakdown?
Decided: The lane reads the failed runs' annotations itself if its token has actions: read; otherwise a person supplies the post-2026-10-18 breakdown. Basis: corrected from "maintainer pastes it", judgment; whether the lane token can read check-run annotations was not verified.

Acceptance criteria:

The cause is named on the issue from post-2.11.7 failures (body's Done when, first half).
An issue-lane run whose apply mint is refused workflow-modified because main moved ends with a retry marker that work-unblock's sweep re-fires, not a failure; a refusal for a real workflow edit still fails (body's Done when, second half, converted).
A test covers both refusal cases.

Refinement. A read-only run explored this repository, searched its issues and pull requests, and read the allowed docs to draft what follows. On an issue a listed human filed, it counts as the issue's spec once posted, while unedited; it is still model text, so check it.

Intended outcome: An issue-lane run whose apply mint is refused workflow-modified because main moved since the run's commit ends with a retry marker that work-unblock's sweep re-fires, while a refusal for a real lane edit of a workflow file still fails, and the cause is named on the issue.

Acceptance criteria

A comment on the issue names the cause of the workflow-modified refusals, counted from failed work-resolve-issue runs after 2.11.7 (2026-10-18), citing the file named in each refusal annotation or stating the lane token could not read them.
.github/workflows/pr-run-activity-write.yml: in issue mode (inputs.issue-number != ''), a workflow-modified refusal at the Request the lane token step whose named file differs between the run's workflow commit and main's tip ends the run with a retry marker, not a red failure.
The retry marker is one work-unblock's sweep already matches (the same re-fire path as the workflow-stale stop step in pr-run-activity-read.yml:867-869), so the issue is re-fired on main's files; a test shows the sweep selects such a run.
A workflow-modified refusal in issue mode where the lane itself changed a workflow file (the file differs from the run's own commit or from main for a reason other than main moving) still fails the run red.
The broker's report-job exception to workflow-modified stays scoped to pull_request runs (pr-pipeline README and pr-run-activity.md are unchanged on that point; pr-workflow-change-ok at pr-run-activity-write.yml:954 is not widened to the apply job).
A test covers both cases: a moved-main refusal ends with the retry marker, and a real workflow edit still fails.
docs/conventions/pr-pipeline/CHANGELOG.md has an entry for the change, and pr-run-activity.md describes the new moved-main retry for the apply mint.
The repository's existing workflow and script tests for pr-run-activity, work-unblock and request-lane-token pass.

Dependencies

Reading failed-run annotations needs a lane token with actions: read; if it lacks that, a person supplies the post-2026-10-18 breakdown for the first criterion, and the code change can proceed without it.
Related work that may touch the same files: #7895 (neutral report of a superseded refusal on PR lanes), #9102 (mint-failed re-fire matches a step the read runner lacks), #8446 (re-fire of lost PR-lane runs); keep this change off the PR-lane path.

Related work

fix(pr-pipeline): report a workflow-modified refusal that a re-fire supersedes as neutral, not failure #7895 (related): Same refusal on PR lanes; this issue is the issue lane, so it is not a duplicate.
fix(pr-pipeline): stop a slot-queued issue run on stale workflow files before the mint #8078 (related): Merged pre-check that stops a slot-queued issue run on stale workflow files (workflow-current); this issue covers main moving after that check, before the mint.
fix(pr-pipeline): the mint-failed re-fire for resolve-issue matches a step the read runner does not have #9102 (related): The mint-failed re-fire for resolve-issue matches a step the read runner does not have; it may affect how the retry marker is matched.
pr-pipeline: re-fire PR-lane runs lost to a broker 5xx or token 403 #8446 (related): Re-firing PR-lane runs lost to broker errors; a similar re-fire concern on another lane.
docs(pr-pipeline): note the broker's report-job exception to workflow-modified #8066 (related): Merged docs for the broker's report-job exception to workflow-modified; that exception stays unchanged.

Sources read

context.json: the owner's Decision recorded comment settles the four open items (post-2.11.7 count, moved main treated as a retry, broker exception unchanged, lane reads annotations if its token allows) and lists three acceptance criteria.
.github/workflows/pr-run-activity-read.yml:829-869: the workflow-current step compares the caller and write workflow blobs at the run's commit with main's tip, and the Stop on stale workflow files step is what work-unblock's sweep matches. The check runs only for kind == skill with an issue number.
.github/workflows/pr-run-activity-write.yml:939-954: the Request the lane token step; pr-workflow-change-ok is true only for pull_request runs without an issue number, so an issue-lane refusal fails red.
.github/workflows/work-unblock.yml:32: the sweep re-fires a run left without a report, including a rerun the token broker refused as workflow-modified.

_{Automated refinement by the lanes App. Intake triages the issue again with it.}

Decision recorded. The owner kept azure-iac#88 on 2026-10-28, answering in the Issue Triage session: "Q1 - keep it". The question was whether to ratify #88 or revert it. #88 widened the broker's superseded-workflow exception to apply-issue-patch, the trust change the 2026-10-26 decision here had reserved for the owner. Kept: an apply-issue-patch job that is already running may mint its mutate-branch token for up to 50 minutes after a GitHub-made, signed main commit changes its workflow, for the lane branch only. Since #88, a sample of 12 failed work-resolve-issue runs showed 0 workflow-modified failures. This issue's cause is "main moved mid-run", and #88 addresses it, so the retry-marker criteria are superseded. Closing as completed.

Navigation Menu

Repository navigation

fix(pr-pipeline): stop broker workflow-modified refusals failing work-resolve-issue runs #9498

Problem

Investigate

Done when

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

fix(pr-pipeline): stop broker workflow-modified refusals failing work-resolve-issue runs #9498

Description

Problem

Investigate

Done when

Activity

github-actions commented on Oct 23, 2026

melodic-automation-lanes commented on Oct 23, 2026

melodic-automation-lanes commented on Oct 23, 2026

kyle-sexton commented on Oct 26, 2026

melodic-automation-lanes commented on Oct 26, 2026

kyle-sexton commented on Oct 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions