pr-merge: GITHUB_TOKEN-dispatched post-merge runs file no demotion issue

Problem

pr-merge.yml's dispatch-full-run job starts the post-merge pr-require-checks run with the job's own GITHUB_TOKEN. GitHub does not fire workflow_run listeners for a run started that way, so when that per-merge run fails, post-merge-demotion-alert.yml files no babysit-merge-demotion issue, and the demotion marker babysit_merge_policy.py reads is never set for it.

Probe in pr-pipeline-sandbox (2026-10-15): run 38758975202 (dispatched by a job's GITHUB_TOKEN, failed) fired no workflow_run run; control run 38758988404 (dispatched by a user, failed) fired one 5 s after it completed. Live in this repo: dispatched run 4578 (actor github-actions[bot], 2026-10-14T19:23Z) has no alert run.

Upstream: https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#triggering-a-workflow-from-a-workflow

Impact

Inline promotion evidence still sees the red run (the publisher reads the runs directly, and a missing run fails the 6 h dispatch deadline), so promotion stays fail-closed. What is lost is the human-facing demotion issue and the marker for that path.

Options

Dispatch with an App installation token that holds actions: write (the lanes App does not, by design).
Have the alert workflow also poll recent dispatched runs on a schedule.
Accept it and rely on inline evidence alone.

Owner of pr-merge: the Automation Lanes session.

Refs: #4588, #7526, #6202

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

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

#7528 (comment)

The decision settles the open questions. #8897's workflow_dispatch send replaces the scheduled filer, so no poller is filed. The issue stays open for the remaining acceptance item: a revert of an agent-merged PR stops that lane's unattended merges through the babysit-merge-demotion record, with no parallel mechanism. #8898 holds the live check that a red per-merge run reaches the alert.

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

Decision recorded.

Question: When pr-merge dispatches the per-merge full CI run with GITHUB_TOKEN and that run fails, no demotion record is filed. Options: (a) dispatch with an App token that has actions: write; (b) a scheduled path files the record; (c) accept it.

Owner's answer: defer under #7719 #7719 puts it first, "Revert breaker with the #7528 fix", with a reviewed plan whose filer job holds issues: write only. That matches (b). Basis: #7719 body; pr-merge.yml:326 (post-merge check already runs each cycle).

The owner accepted this recommendation as item D9 of a 21-decision batch in an attended backlog-shaping session on 2026-10-18. The batch question: "Accept all 21 batch 7 decisions, with my change to D13 (#6008 goes to the lane, but you merge its PR because it edits AGENTS.md)? I post a 'Decision recorded.' comment on each issue." The owner answered: "Accept, with my D13 change (Recommended)".

Posted by AI from the owner's answer in that session.

Released for re-triage under the owner's 2026-10-24 rule: an issue stops for a person only for an intent or vision question, a security call, a host or attended run, or spend outside prepaid credit. The hold label came off and intake triage runs again now; it re-applies a hold, with a numbered question, when one of those applies.

To hold this issue again, add needs-human (or status: needs-decision) and say why in a comment.

Not admitted to the issue lane: no trusted-human acceptance criteria: a listed human must put the confirmed - [ ] criteria in the body or post them as their own comment (owner Q9, #8999). 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: Close as fixed by #8897: pr-merge's dispatch-full-run job now sends a red per-merge run to post-merge-demotion-alert.yml by workflow_dispatch, so the demotion issue and marker are filed.

Dependencies

#8898 verifies the red send after #8897 merges; it is open and holds the live check

Related work

fix(pr-pipeline): report red per-merge full runs to the red-main alert #8897 (fixed-by): Titled 'report red per-merge full runs to the red-main alert'; closed 2026-10-21. The code it describes is in pr-merge.yml. The context does not say whether it was merged.
chore(pr-pipeline): verify the per-merge red send to the alert after #8897 merges #8898 (related): Open chore to verify the per-merge red send reaches the alert after #8897 merges; it would show the fix works in practice.
pr-merge lane: dispatch proof artifacts expire while the post-merge floor still counts older merges #7479 (related): Open pr-merge issue about dispatch proof artifacts expiring; it touches the same dispatch-full-run path.
chore(pr-pipeline): pr-merge dispatch and read-token review follow-ups #9355 (related): Open follow-ups on pr-merge dispatch and read-token review.

Open questions

Was #8897 merged (not just closed), and does it fully cover the demotion issue and marker for a GITHUB_TOKEN-dispatched run?
RECOMMENDED: Yes. Close #7528 as completed by #8897 and let #8898 confirm it live. Basis: .base/.github/workflows/pr-merge.yml:1721-1747
The owner's decision chose option (b), a scheduled filer job holding issues: write only, tracked under #7719. Does the #8897 workflow_dispatch send replace that, or is a separate scheduled poller still wanted?
RECOMMENDED: The dispatch send meets the goal of filing the demotion issue. A scheduled poller would only be a backstop, so file it separately if wanted. Basis: judgment

Sources read

context.json: the owner's Decision recorded comment picks option (b), a scheduled path that files the record, tracked under #7719
.base/.github/workflows/pr-merge.yml:1611: dispatch-full-run holds actions: write to start the run, read its status and send a red one to post-merge-demotion-alert.yml
.base/.github/workflows/pr-merge.yml:1721-1747: the wait step dispatches post-merge-demotion-alert.yml with run-id and head-sha when the run's conclusion is failure, timed_out, cancelled, startup_failure or action_required
.base/.github/workflows/pr-merge.yml:42-50: the header comment says pr-merge sends red runs to the alert by workflow_dispatch, which files the post-merge record
.base/.github/workflows/post-merge-demotion-alert.yml:115: the alert's concurrency group accepts head-sha from workflow_dispatch inputs

_{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: Does #8897's workflow_dispatch send replace the scheduled filer path you chose under #7719, so this issue closes with no poller?

Already decided: #7528 (comment) (2026-10-18: option (b), a path that files the demotion record, under #7719)

Your 2026-10-18 answer picked (b), a scheduled filer job holding issues: write only. fix(pr-pipeline): report red per-merge full runs to the red-main alert #8897 (merged as 81d3f7f) instead has pr-merge's dispatch-full-run job send a red per-merge run to post-merge-demotion-alert.yml by workflow_dispatch. Does that replace the scheduled path, or is a poller still wanted?
Decided: It replaces the scheduled filer: fix(pr-pipeline): report red per-merge full runs to the red-main alert #8897's dispatch files the demotion record, so no poller is filed now. The issue does not close yet: the owner's Q604 and Q608 (poteto-review ledger) build the revert breaker "with the pr-merge: GITHUB_TOKEN-dispatched post-merge runs file no demotion issue #7528 fix", and main has no proof of it (the pr-pipeline README only names it; post-merge-detect-silent-revert is a canary, not a stop). The 39-minute wait gap (13 reads, 3 minutes apart) is filed separately only if a red run that slow is seen. Basis: fix(pr-pipeline): report red per-merge full runs to the red-main alert #8897 (81d3f7f); .work/poteto-review/interview-checklist.md:649 (Q604), :653 (Q608).

Acceptance criteria:

pr-merge's dispatch-full-run job sends a red per-merge full run (failure, timed_out, cancelled, startup_failure or action_required) to post-merge-demotion-alert.yml by workflow_dispatch with its run id and head SHA.
post-merge-demotion-alert.yml accepts that dispatch and files the babysit-merge-demotion issue and the demotion marker for the run.
A revert of an agent-merged PR stops that lane's unattended merges until the owner re-enables them, through the babysit-merge-demotion record (Q604/Q608), with no parallel mechanism.

Checks a person runs:

chore(pr-pipeline): verify the per-merge red send to the alert after #8897 merges #8898's live check that a red per-merge run reaches the alert.

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: A revert of an agent-merged PR files a babysit-merge-demotion record that stops that lane's unattended merges until the owner re-enables them, reusing the existing record and marker.

Related work

fix(pr-pipeline): report red per-merge full runs to the red-main alert #8897 (fixed-by): Merged; already delivers the first two acceptance items: pr-merge.yml:1840 dispatches a red per-merge run to post-merge-demotion-alert.yml, which accepts workflow_dispatch at post-merge-demotion-alert.yml:83.
chore(pr-pipeline): verify the per-merge red send to the alert after #8897 merges #8898 (related): Holds the person-run live check that a red per-merge run reaches the alert.
chore(pr-pipeline): pr-merge dispatch and read-token review follow-ups #9355 (related): Open follow-ups for pr-merge dispatch and read-token review.

Open questions

Are the first two criteria done by #8897, leaving only the revert breaker, so the issue is retitled to that one item?
RECOMMENDED: Yes: retitle to the revert breaker and keep a single acceptance item. Basis: pr-merge.yml:1840; post-merge-demotion-alert.yml:42,83
What detects a revert of an agent-merged PR? post-merge-detect-silent-revert.yml is only a canary now.
RECOMMENDED: Extend post-merge-detect-silent-revert.yml to dispatch post-merge-demotion-alert.yml, or file the same marker, when it finds a revert of a lane-merged PR, with no new mechanism. Basis: judgment; .github/workflows/post-merge-detect-silent-revert.yml; babysit_postmerge.py:84
Which signal value and lane scope does a revert demotion use in the marker?
RECOMMENDED: Reuse the babysit-merge-demotion marker with a new signal value such as revert, scoped to the lane that merged the reverted PR. Basis: post-merge-demotion-alert.yml:532; babysit_merge_policy.py:121,1441
How does the owner re-enable the lane after a revert demotion?
RECOMMENDED: Use the existing human-cleared demotion path that read_demotion already honors, with no new switch. Basis: babysit_merge_policy.py:1390,1441

Sources read

pr-merge.yml:1840: dispatches a red per-merge run to post-merge-demotion-alert.yml by workflow_dispatch
post-merge-demotion-alert.yml:83: accepts workflow_dispatch
post-merge-demotion-alert.yml:532: writes the babysit-merge-demotion marker with sha and signal
babysit_merge_policy.py:1441: read_demotion reads the demotion record
babysit_postmerge.py:84: post-merge-detect-silent-revert.yml is the canary workflow

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

Navigation Menu

Repository navigation

pr-merge: GITHUB_TOKEN-dispatched post-merge runs file no demotion issue #7528

Problem

Impact

Options

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

pr-merge: GITHUB_TOKEN-dispatched post-merge runs file no demotion issue #7528

Description

Problem

Impact

Options

Activity

github-actions commented on Oct 15, 2026

kyle-sexton commented on Oct 18, 2026

kyle-sexton commented on Oct 24, 2026

melodic-automation-lanes commented on Oct 24, 2026

melodic-automation-lanes commented on Oct 24, 2026

kyle-sexton commented on Oct 26, 2026

melodic-automation-lanes commented on Oct 26, 2026

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions