You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(ci): re-run ci-status on open lanes App pull requests when the kill switch is lifted #9522
While CLAUDE_LANES_DISABLED or CLAUDE_LANES_REPO_DISABLED is on, ci-status fails every lanes App pull request (pr-require-checks.yml lanes App step, added in #9508). Nothing re-runs ci-status when the switch is lifted, so open lane PRs stay red until a push or a manual re-run. Raised by poteto's review of #9508.
Done when
Lifting the kill switch leads to a ci-status re-run on each open lanes App pull request within one scheduled interval (for example from the scheduled reconciler), with no per-PR polling while the switch is on.
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
Understood: while the lanes kill switch is on, ci-status fails every lanes App PR. Nothing re-runs it once the switch is lifted, so those PRs stay red until a push or manual re-run. The goal is a ci-status re-run on each open lanes App PR within one scheduled interval, with no per-PR polling while the switch is on. The approach (for example hooking into the scheduled reconciler) is clear enough to start. A reader would first need to check how the reconciler tracks the switch state. No likely duplicates found among the open issues.
Builder: the Automation Lanes session builds this from the owner's machine. The fix edits .github/workflows, which the lanes App cannot push (patch-rules.json:3); that boundary stays. Its PR closes this issue. needs-human came off under the owner's 2026-10-26 rule (a person only for an intent or vision change, an implementation finding that alters intent or the primary design, or a HIGH/CRITICAL security issue); none applies. agent-ready stays off so the issue lane does not race the build.
Released for re-triage under the owner's 2026-10-26 rule: a person is involved only for "1. A change in original intent/vision 2. Something comes up during implementation ... that alters intent/vision or the primary design 3. If there is a HIGH/CRITICAL security issue". None applies here, so the hold label came off and intake triage runs again now.
To hold this issue again, add needs-human (or status: needs-decision) and name which of the three applies.
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, or, on an issue a listed human filed, intake's newest refinement comment must hold them unedited. Admission takes the issue once each of those is met, when intake triages it again (.github/actions/resolve-config/admission-rules.json).
melodic-automation-lanes commented on Oct 26, 2026
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: The scheduled reconciler re-runs pr-require-checks (so ci-status) once on each open lanes App pull request whose ci-status failed on the kill-switch step, on its first run after both switches read 'false'.
Acceptance criteria
maintenance-reconcile-lost-runs/reconcile.mjs plans a re-run of the newest pr-require-checks run on the head of each open, non-draft lanes App pull request into main whose ci-status failed on the 'Fail a lanes App pull request its body or a member holds' step with the kill-switch error
The plan only runs when KILL_SWITCH is 'proceed' (reconcile.mjs:749), so no PR is read or re-run while either switch is on, and the added code makes no per-PR API call on that path
A pull request not authored by the lanes App (numeric id and type Bot), or one whose ci-status did not fail on that kill-switch error, is never re-run by this rule
The re-run is made once per head: a run already at attempt 2 is not re-run, and the existing cap of 3 in-flight re-runs and one-second write spacing still apply
The attempt-2 re-run of pr-require-checks gets its reconcile-rerun record artifact, as the existing RECORDED_UPSTREAMS path does, so pr-verify trusts it
A node test in the reconcile script's existing test file covers: switch lifted re-runs a kill-switch-failed lanes App PR, switch on re-runs nothing, a non-lanes PR and a run already at attempt 2 are skipped
The header comment of maintenance-reconcile-lost-runs.yml and the comment on the lanes kill-switch step in pr-require-checks.yml (about line 4678) say the reconciler re-runs ci-status once the switch is lifted
Any workflow edit keeps the repository's existing lint and workflow tests (including scripts/ci-lanes-pr-hold.test.sh) passing
Dependencies
The change edits .github/workflows, which the lanes App cannot push (patch-rules.json:3); the Automation Lanes session builds it from the owner's machine, as kyle-sexton's first comment says
.github/workflows/maintenance-reconcile-lost-runs.yml:3-63: runs every 30 minutes (cron 4,34), re-runs lost runs once at attempt 1, and stops when the kill switch is on
.github/workflows/maintenance-reconcile-lost-runs.yml:104-119: the kill-switch step feeds KILL_SWITCH=proceed to the plan step
.github/scripts/maintenance-reconcile-lost-runs/reconcile.mjs:749: the plan stops unless KILL_SWITCH is 'proceed'
.github/scripts/maintenance-reconcile-lost-runs/reconcile.mjs:107: RECORDED_UPSTREAMS lists pr-require-checks.yml, so its attempt-2 re-run gets a record
.github/workflows/pr-require-checks.yml:4602-4606: the lanes App step fails while a kill switch is on
.github/workflows/pr-require-checks.yml:4677-4679: the failing check and its error text, which says to re-run ci-status once both read 'false'
Automated refinement by the lanes App. Intake triages the issue again with it.
Activity
github-actions commentedon Oct 23, 2026
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
Understood: while the lanes kill switch is on, ci-status fails every lanes App PR. Nothing re-runs it once the switch is lifted, so those PRs stay red until a push or manual re-run. The goal is a ci-status re-run on each open lanes App PR within one scheduled interval, with no per-PR polling while the switch is on. The approach (for example hooking into the scheduled reconciler) is clear enough to start. A reader would first need to check how the reconciler tracks the switch state. No likely duplicates found among the open issues.
Automated triage, applied by the lanes App.
kyle-sexton commentedon Oct 26, 2026
Builder: the Automation Lanes session builds this from the owner's machine. The fix edits
.github/workflows, which the lanes App cannot push (patch-rules.json:3); that boundary stays. Its PR closes this issue.needs-humancame off under the owner's 2026-10-26 rule (a person only for an intent or vision change, an implementation finding that alters intent or the primary design, or a HIGH/CRITICAL security issue); none applies.agent-readystays off so the issue lane does not race the build.kyle-sexton commentedon Oct 26, 2026
Released for re-triage under the owner's 2026-10-26 rule: a person is involved only for "1. A change in original intent/vision 2. Something comes up during implementation ... that alters intent/vision or the primary design 3. If there is a HIGH/CRITICAL security issue". None applies here, so the hold label came off and intake triage runs again now.
To hold this issue again, add
needs-human(orstatus: needs-decision) and name which of the three applies.melodic-automation-lanes commentedon Oct 26, 2026
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, or, on an issue a listed human filed, intake's newest refinement comment must hold them unedited. Admission takes the issue once each of those is met, when intake triages it again (.github/actions/resolve-config/admission-rules.json).melodic-automation-lanes commentedon Oct 26, 2026
The latest triage verdict holds nothing: the issue is at
status: ready.melodic-automation-lanes commentedon Oct 26, 2026
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: The scheduled reconciler re-runs pr-require-checks (so ci-status) once on each open lanes App pull request whose ci-status failed on the kill-switch step, on its first run after both switches read 'false'.
Acceptance criteria
Dependencies
Related work
Sources read
Automated refinement by the lanes App. Intake triages the issue again with it.
fix(ci): say the reconciler re-runs ci-status once the kill switch lifts