[kyle-sexton]

Closes #7535

Summary

When a full pr-require-checks run on main fails, the alert job already files a needs-human demotion record. It now also files one fix issue per newly failing check and dispatches intake triage for each, so a red main reaches the intake lane instead of waiting on a person to open issues. Built to the owner's answers on #7535 (relayed 2026-10-21): D12 (a), Q1-Q6, with Q6 changed to reopen. Owner decision 2026-10-21: a reopened fix issue keeps agent-ready and is not re-triaged, so a repeat goes straight back to agents; first failures still wait for approval per D12 (a); the record wording stays "failure record #N".

Fix

• One fix issue per newly failing job, after the record POST (which now returns the record number), named for the job only (job names come from the workflow file on main; annotation titles, which any step can print, never reach a fix issue). Title Fix main: <check> fails since <sha12>, first line <!-- post-merge-fix check=<check> -->, fixed text only: check name, SHA, run link, merge range (<base12>..<sha12> or "unknown"), and the record's number. No label, no closing keyword, no commit subject or annotation text (Q1, D12 (a)).
• Validator for the only free-text input, the check name: ^[A-Za-z0-9][- A-Za-z0-9._:,/()]{0,99}$ and no babysit-merge-demotion / post-merge-failure substring; every other input is already hex or numeric-checked (Q2: bot-authored intake approved, gated on Security & Cost passing this template and validator).
• At most 5 per run, with an overflow line on the record (Q3); post-merge-failure records file too, worded "failure record #N" since that record demotes nothing (Q4); filing only alongside a new record (Q5).
• A check whose fix issue was closed reopens that issue: comment with the new range, then reopen, keeping agent-ready and dispatching no intake, mirroring fix(ci): reopen a monitor's closed issue for its key instead of filing a recurrence #8786's one-issue-per-key monitors; closed as not planned or duplicate mutes the check; an open one stands (Q6).
• Each fix issue is locked before intake triage is dispatched (first filing; a reopen dispatches nothing), so no outsider comment reaches the triage prompt; a failed lock sends nothing.
• Any fix issue that could not be filed, locked, reopened or dispatched is named in one comment on the needs-human record, since a re-run takes the existing-record path and cannot retry; then ::error and exit 1 after every check is handled. Canary runs file nothing. No permissions:, on: or token change.
• README: one paragraph on the fix issues beside the demotion record.

Verification

• bash scripts/post-merge-demotion-alert.test.sh: 100 pass, 0 fail; the new or extended cases fail against the old workflow (including the lock, job-name and undelivered-record cases against c760e24); 8 mutants (charset check removed, cap 5 to 9, open-skip, mute regex, needs-human label dropped, marker injected, 404 branch, newly gate) were each killed before the reopen change removed the 404 branch. The reopen case (comment then reopen, no DELETE, no lock, no intake dispatch) fails against c58da79 and passes at da2a392.
• Report-job node tests: 43 pass. scripts/check-affected.sh --base origin/main: passed; actionlint passed.
• Intake dispatch gate checks only the sender's actor id, and github-actions[bot] (41898282) is listed (ci-workflows intake-triage.yml at the pinned sha, :104-117, :250-271).
• Left out: a live red-main run, and what intake returns for a bot-authored issue in this template. work-resolve-issue.yml triggers on issues: labeled only, so a reopen that keeps agent-ready starts no hosted run by itself.

Related

• fix(ci): reopen a monitor's closed issue for its key instead of filing a recurrence #8786: the one-issue-per-key reopen pattern this mirrors.

🤖 Generated with Claude Code

https://claude.ai/code/session_01B4THuN6Tafisi3H5ndrim8

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-21T03:57:27.291510Z	c760e24	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[github-actions]

claude-security-review reviewed da2a392613a5f8c952f1e2c325c64c21b5774349: 0 finding(s), 0 as inline comments.

No security issues found in PR #8805 (head da2a392). I reviewed the four changed files by reading the diff and the surrounding workflow; I did not run the test script.

• Injection into the fix issues: The check name is the only variable text. It comes from the job name in a completed run on main, cut at the first ": ", so annotation titles never get in. It is then checked against ^[A-Za-z0-9][- A-Za-z0-9._:,/()]{0,99}$, which rules out >, backslash, quotes, $, backticks and newlines. The marker comment therefore can't be closed early, awk -v can't mangle the match, and the title and body can't carry markup or a closing keyword. Names containing either record marker are rejected, so a fix issue can't be taken for a demotion record. The run id, run attempt and record number are checked as numbers before they build the run link or an API path.
• Spoofing the marker match: Fix issues are looked up only in github-actions[bot]'s own issues, so a user-planted marker can't mute or hijack a check. The not_planned/duplicate mute relies on the triage permission of whoever closed the issue. That is deliberate and documented.
• Intake ordering: The issue is locked before the intake-triage dispatch, and a failed lock sends nothing, so outsider comments can't reach the triage prompt. The body holds only fixed text and the issue has no label, so the first filing waits for the owner's ratification.
• Reopen path: A reopened issue keeps agent-ready and gets no second dispatch. The reopen comment is fixed text built from the SHA, the merge range and the run link. The only trigger is a failure on main's scheduled or dispatched full run, which an outsider can't cause without merge access. Returning a ratified issue to agents without a new ratification is the intended, documented behavior, so it is not a finding.
• Permissions and triggers: The diff doesn't widen permissions: or change triggers, and the workflow's action pins are unchanged. That area is zizmor's, so I did not re-report it.

The diff touches no standing instruction file, so the instruction-surface deletion check did not apply and the exception register was not needed.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c760e249f3

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[github-actions]

claude-review reviewed da2a392613a5f8c952f1e2c325c64c21b5774349: 0 finding(s), 0 as inline comments.

Code review: no findings

I read the full diff (4 files) and the PR context. I did not run scripts/post-merge-demotion-alert.test.sh, so its pass counts are the author's claims and I have not confirmed them.

Closing issue #7535. The change meets its criteria, based on reading the diff:

• A separate fix issue is filed per newly failing check and sent to intake triage.
• The demotion record keeps needs-human and its marker.
• Closing a fix issue changes nothing on the record, which is the "separate fix item" constraint.
• The new test cases cover each of these.

Checked and found sound:

• Job permissions. issues: write covers lock, create, comment and reopen. actions: write covers the intake-triage.yml dispatch. The issue-number input exists in intake-triage.yml.
• Untrusted text. The check name is the only free text reaching a fix issue. It is validated against the charset and the two record-marker substrings. The charset excludes backtick, >, [, @ and #, so it cannot close the HTML-comment marker or add mentions or links. Annotation text is cut off by ${check%%: *}.
• Reading and filtering the issue list.
  • The extra state_reason // "none" column keeps read from collapsing tab-separated fields.
  • The awk lookup on the fourth column picks an open issue first, then the newest closed one.
  • A fix issue closed as not_planned or duplicate stays muted.
• Failure handling. Failed lock, dispatch, reopen and file steps are collected, named in one comment on the record, and fail the job only after every check has been handled. dispatch runs in the main shell, so its fix_failed and undelivered updates persist.
• Test stub. The numbering (900 plus the log line) matches what record_number and fix_number assume in the tests.

I considered whether ${check%%: *} would cut a job name that itself contains : . No job in pr-require-checks.yml has one, so I did not report it.