fix(source-control): ready phase waits on a fixed ci.yml workflow #8629

Activity

1. github-actions

   added

   needs-triageNot yet classified. Floor until a type and one priority tier are set.Not yet classified. Floor until a type and one priority tier are set.

   on Oct 20, 2026
2. github-actions commented on Oct 20, 2026

   

   github-actionsBot

   on Oct 20, 2026 – with GitHub Actions

   Last edited by melodic-automation-lanes

   Contributor

   More actions

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

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

   I understood this as a defect: the GitHub ready-for-review reference hardcodes CI_WORKFLOW=ci.yml. This repository has no such workflow, so the CI wait times out and the skill toggles the PR draft→ready again, cancelling runs that were already going. The proposed fix is to resolve the workflow per repository, either through a convention key or by detecting the workflow that runs on pull_request or posts ci-status. Nothing is missing. Picking between those two approaches is a design choice that reading the code should settle. I found no likely duplicates among the open issues.

   _{Automated triage, applied by the lanes App.}
3. github-actions

   added

   priority: mediumReal value, no hard deadline; normal backlog flow.Real value, no hard deadline; normal backlog flow.

   and removed

   needs-triageNot yet classified. Floor until a type and one priority tier are set.Not yet classified. Floor until a type and one priority tier are set.

   on Oct 20, 2026
4. github-actions

   added the

   Bug

   issue type on Oct 20, 2026
5. github-actions commented on Oct 26, 2026

   

   github-actionsBot

   on Oct 26, 2026 – with GitHub Actions

   Contributor

   More actions

   The triage sweep dispatched intake triage for this issue (attempt 1 of 2).
6. melodic-automation-lanes

   added

   status: readyTriaged, unblocked, and fully specified; eligible to pick up.Triaged, unblocked, and fully specified; eligible to pick up.

   work-class: scopedA briefed fix or small feature; blast radius bounded by the brief, tests exist.A briefed fix or small feature; blast radius bounded by the brief, tests exist.

   status: needs-decisionAwaiting a human or maintainer judgment call.Awaiting a human or maintainer judgment call.

   and removed

   status: readyTriaged, unblocked, and fully specified; eligible to pick up.Triaged, unblocked, and fully specified; eligible to pick up.

   on Oct 26, 2026
7. melodic-automation-lanes commented on Oct 26, 2026

   

   melodic-automation-lanesBot

   on Oct 26, 2026

   Contributor

   More actions

   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).
8. melodic-automation-lanes commented on Oct 26, 2026

   

   melodic-automation-lanesBot

   on Oct 26, 2026

   Contributor

   More actions

   The latest triage verdict holds nothing: admission moved the issue to status: needs-decision; its comment says why.
9. melodic-automation-lanes commented on Oct 26, 2026

   

   melodic-automation-lanesBot

   on Oct 26, 2026

   Contributor

   More actions

   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: Close as already fixed: the ready reference no longer names ci.yml and counts every pull_request run for the head SHA.

   Related work

   • perf(source-control): skip ready's local full-suite verify when the CI test lanes cover it #8753 (related): also changes ready's CI wait and verify behavior in the same reference
   • test(source-control): give the pull-request eval cases a gh fixture so ready runs reach the flip #6997 (related): eval fixture so ready runs reach the flip, which exercises this wait

   Open questions

   1. Is this issue already fixed, so it should be closed instead of worked? The checkout no longer has CI_WORKFLOW or ci.yml in the ready reference, and the changelog records the fix.
      RECOMMENDED: Yes: verify against the installed version in the report (1.12.1 predates the fix), then close as completed or re-file only if a current version still toggles draft/ready. Basis: plugins/source-control/reference/providers/github/pull-request/ready-for-review.md:116 says the run lists name no workflow and count every pull_request run for the head SHA; plugins/source-control/CHANGELOG.md:870 records removal of the hardcoded ci.yml; the checkout is at 3.4.3 (CHANGELOG.md:6).
   2. If the owner still wants a per-repository convention key for the CI workflow, should that be a new issue?
      RECOMMENDED: No: counting all pull_request runs for the head works without configuration, so no key is needed. Basis: judgment

   Sources read

   • plugins/source-control/reference/providers/github/pull-request/ready-for-review.md:116: the run lists name no workflow and count every pull_request run for the head SHA
   • plugins/source-control/reference/providers/github/pull-request/ready-for-review.md:118: the wait ends only when the run count holds steady across polls
   • plugins/source-control/CHANGELOG.md:870: ready waits for the push's CI runs and confirms the ready run without a hardcoded ci.yml
   • plugins/source-control/CHANGELOG.md:6: current plugin version 3.4.3, newer than the 1.12.1 the issue saw

   _{Automated refinement by the lanes App. Answer with a comment whose first line is **Decision recorded.**.}
10. kyle-sexton commented on Oct 26, 2026

    

    kyle-sexton

    on Oct 26, 2026

    MemberAuthor

    More actions

    Decision recorded. The owner answered in the Refinement and Issue Triage sessions (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

    No owner ledger (.work/*/interview-checklist.md, .work/gh-monitor-owner-decisions/) names this issue. Read against origin/main at a6ba1c4c18.

    1. Is this already fixed?
       Decided: Yes. The ready reference no longer names ci.yml or sets CI_WORKFLOW: git grep "CI_WORKFLOW\|ci\.yml" origin/main -- plugins/source-control finds only eval scaffolds that create their own ci.yml. The CI wait counts every pull_request run for the head SHA, "so they work in any repository without knowing its CI file name" (plugins/source-control/reference/providers/github/pull-request/ready-for-review.md:116-117), and ends only when the count is above zero and steady across two polls (:119-120, block :137-145). The ready-run check uses the same unfiltered list, both the snapshot (:162-163) and ready_run_seen (:203-211). The changelog records the fix under 1.13.0: "In a repository with no ci.yml the wait always timed out and the draft and ready toggle fired" (plugins/source-control/CHANGELOG.md:797, :901). The issue saw 1.12.1.
    2. Is a per-repository CI workflow key still needed?
       Decided: No. The unfiltered count works in any repository with no setting, so a key would be a second way to do the same thing (brief, "No added mechanisms").

    Closed as done. The fixed ci.yml wait and the draft-ready toggle it caused are gone from main, per the lines above. Nothing is left to build. This record closes the issue.
11. kyle-sexton

    closed this as completedon Oct 26, 2026