[kyle-sexton]

No related issue: found by the GitHub Support session; fix-ci dispatched nothing since the check landed

Summary

fix-ci-dispatch.mjs trusted the head's ci-lanes commit status only when creator.login === "github-actions[bot]". That is the REST spelling. The GraphQL rollup the dispatcher reads reports the login as github-actions, so lanesFailed() was always false and every pull request was skipped as ci-lanes has not failed, silently, because the listing loop logged nothing for a skip.

Fix

• The query asks for creator { __typename ... on Bot { databaseId } }, and the status is trusted only when the creator is a Bot with the GitHub Actions bot id 41898282, the id this repository already uses for that bot (for example address-feedback.mjs MARKER_AUTHOR_ID). Any other actor, a User with the same login or id, a Bot with another id, or a missing creator is still refused.
• The listing loop logs skip fix-ci #N: <reason> for a skipped pull request whose ci-lanes is FAILURE or ERROR, whoever set it. Passing and pending heads stay quiet, so the log grows only for the case a silent skip would hide. A failed status the bot did not set is skipped as ci-lanes failed but the GitHub Actions bot did not set it, not ci-lanes has not failed.
• Local code and security reviews ran in place of the CI review lanes, which review-venue reported absent. The code review found three issues, all fixed: a second copy of the failed-state list, a misleading skip reason for an untrusted creator, and no ERROR case in the log test. The security review found no P1 to P4 issues.
• Test fixtures in fix-ci-dispatch.test.mjs, dispatch.test.mjs, callers.test.mjs and dispatch-limits.test.mjs now build the creator in the shape GraphQL returns.

Other github-actions[bot] comparisons under .github/scripts and .github/actions were checked. Each reads REST data, git commit data or a workflow context, where the [bot] spelling is correct, so none changed: work-unblock/label-unblocked.mjs (REST issue and comment user.login), pr-unblock/gate-source.mjs laneHold (REST comments and timeline user), pr-unblock/dependency-classify.mjs ACTIONS_AUTHOR (git author name and email from REST pull commits), intake-triage/apply-verdict.mjs and intake-triage/refine.mjs (REST comments), maintenance-audit-lane-runs/file-findings.mjs, post-merge-demotion-alert/report.mjs and maintenance-monitor-signals/collect.mjs (REST ?creator= query parameter), maintenance-audit-lane-runs/triage-sweep.mjs (REST comments and search), and check-trusted-trigger.mjs (the github.triggering_actor context).

Verification

• node --test .github/scripts/pr-unblock/*.test.mjs .github/actions/resolve-config/callers.test.mjs .github/actions/resolve-config/dispatch-limits.test.mjs: 844 tests, 844 pass.
• With the old login comparison restored, fix-ci-dispatch.test.mjs fails 26 of 38 tests, including every dispatch case and the new untrusted-creator case (a Bot with login github-actions[bot] and no id is no longer trusted).
• scripts/check-affected.sh: 9 passed, 4 skipped, none failed.
• The new LIST_QUERY run live against this repository: feat(planning): let supersede and restore handle register rows with more than an answer #9642's ci-lanes (FAILURE, creator {"__typename":"Bot","databaseId":41898282}) gets skip reason "" (a candidate) from skipReason, where the old check returned ci-lanes has not failed. The query cost 2 points.
• Left out: a live dispatcher run, which runs only on main after merge.

Related

• The live status on feat(planning): let supersede and restore handle register rows with more than an answer #9642, read through GraphQL: {"context":"ci-lanes","creator":{"__typename":"Bot","databaseId":41898282,"login":"github-actions"},"state":"FAILURE"}.
• Cause: feat(pr-pipeline): turn on review-lane holds and require both review lanes in ci-status #9361 (bfb5421), which keyed fix-ci on the ci-lanes status with the login check.
• The last fix-ci run before this fix: run 39915524982, 2026-10-23T07:05Z.

🤖 Generated with Claude Code

[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-24T12:43:03.505193Z	564d097	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-review reviewed 564d0970a8560d728a8736674718b374d762dab8: 0 finding(s), 0 as inline comments.

I found no issues in this change, so there are no inline comments. I read the full diff and the PR context. I did not run any tests.

What the change does.

• fix-ci-dispatch.mjs now trusts the ci-lanes status only when the creator is a Bot with databaseId 41898282. The old check compared the login to github-actions[bot], but GraphQL reports github-actions.
• The dispatcher now logs skip fix-ci #N: <reason> for skipped PRs whose ci-lanes is FAILURE or ERROR. A failed status set by someone else gets its own reason.

What I checked.

• Trust check: it still rejects a User with the same login or id, a Bot with another id, a Bot with no id, and a null or missing creator. The new test covers each of these.
• Failed-state list: it now lives in one place, failedState, which lanesFailed, the skip reason and the log condition share.
• Query and fixtures: the query matches the shape the code reads. The fixtures in the four test files now use the GraphQL shape. The query-string assertion was updated to match.
• Logging: it is limited to failed or errored heads, so passing and pending PRs stay quiet. The second new test checks that, including the ERROR case.
• Test coverage: the new tests would fail if the trust check were reverted.
• Manifests: the diff touches no plugin.json or marketplace.json, so no manifest <field> lines apply. The changelog fragment's bump: patch fits a bug fix.
• Path-scoped rules: no file in .claude/rules/ has a paths: glob that matches the changed files.
• Closing issues: the PR states "No related issue", so there are no acceptance criteria to check.
• Paved paths: I did not resolve the standards index, so I checked nothing about paved paths.
• Hold: no hold applies. The change adds no model spend and touches no trust-gate files.

Unverified. The PR body's test counts and its live query result against #9642 are the author's claims. I did not reproduce them.

[github-actions]

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

No security issues found in this pull request, so there are no inline comments and no hold.

What changed: fix-ci-dispatch.mjs now trusts the head's ci-lanes commit status only when its creator is a GraphQL Bot with databaseId === 41898282, the GitHub Actions bot. Before, it compared the login to github-actions[bot], which is REST's spelling. The listing loop also logs a skip reason when ci-lanes is FAILURE or ERROR. The other five files are test fixtures and a .changes entry.

Trust boundary:

• The check is no looser than before. It still requires the Bot type and the exact id.
• A User with the login github-actions, a Bot with another id, a Bot with no id, a null creator and a missing creator all fail the check. The new test covers each of these.
• A status set by anyone else cannot reach dispatch. skipReason and lanesState still refuse it, and the new log line only reports the skip.
• The id is a numeric identifier GitHub assigns, so it is stronger than a mutable login. The same id is already used elsewhere in the repository, per the PR description.
• Any workflow in this repository that uses GITHUB_TOKEN can still set a ci-lanes status as this bot. The old login check allowed the same, so the diff does not widen it. The dispatcher also requires a ready, same-repository PR, which keeps fork PRs out.

Logging:

• The new log line interpolates node.number (an integer from GraphQL) and a reason string chosen from constants. No attacker-controlled text reaches the log, so there is no injection or workflow-command risk.
• The extra skip logging is limited to heads whose lanes failed. It exposes no secrets.

Other checks:

• Instruction-surface deletions: none. No CLAUDE.md, rules file, skill or agent body, or hook allowlist is touched.
• Plugin manifests: no plugin.json or marketplace.json is in the diff, so there are no manifest <field> lines to report.
• Trust-gate paths: no trusted-actors, check-trusted-trigger, CODEOWNERS or .gitmodules file is touched.
• PR context: it holds no embedded instructions aimed at the review.

critical-findings: 0