CI: Jules workflow_run subscribes to every workflow completion — 44 of the last 100 repo runs are skipped no-ops, and they share the concurrency group that can drop a real ci-failure-fix run #304

Problem

.github/workflows/jules.yml subscribes to every workflow completion in the repository:

on:
  workflow_run:
    workflows: ["*"]
    types: [completed]

The only workflow_run job, ci-failure-fix, runs only when the completed run failed on a non-main branch:

ci-failure-fix:
  if: >-
    github.event_name == 'workflow_run' &&
    github.event.workflow_run.conclusion == 'failure' &&
    github.event.workflow_run.head_branch != 'main'

Every other completion — every success, every main-branch run, every nightly — still creates a Jules run whose jobs are all skipped.

Evidence (verified this run via gh run list)

Of the 100 most recent runs in this repository (2026-10-18):

• 54 are Jules runs — more than any other workflow (nix ci 11, mcpx 8, id 5, mcpx conformance 4, mcpx nix build 2, Auto Assign 16).
• 44 of those 54 are workflow_run runs with conclusion skipped — created only to evaluate the if: above and do nothing.
• Recent examples fire minutes apart (18:54, 18:56, 18:57, 18:59 UTC) as unrelated workflows complete.

There is also a correctness edge, not just noise: jules.yml sets one workflow-level concurrency group, ${{ github.workflow }}-${{ github.ref }} with cancel-in-progress: false. For workflow_run events github.ref is the default branch, so all Jules runs — the weekly cron, label runs, dispatches, and every workflow_run run — share a single group with the default queue: single semantics: at most one running and one pending, and a new arrival cancels the pending run. A genuine ci-failure-fix run queued behind a long run can therefore be silently displaced by the next noise completion, and Jules never looks at that failure. (Same failure mode as #302, which fixed this for auto-assign.)

Why it matters

• The Actions list is majority-noise: real failures and real Jules invocations are buried under dozens of skipped runs per day, which trains everyone to ignore the list.
• The shared concurrency group turns that noise into a (small but real) chance of dropping the one run the trigger exists for.
• Distinct from CI: consolidate the three Jules workflows into one #287 (consolidating the three Jules workflow files into one): this is about the workflow_run subscription breadth and its interaction with the concurrency group, and it applies to jules.yml whether or not the files are consolidated.

Suggested fix

• Replace workflows: ["*"] with the explicit list of CI workflows Jules should actually auto-fix (today: mcpx, mcpx conformance, mcpx nix build, nix ci, id), or otherwise narrow the trigger so non-actionable completions create no run.
• Give the ci-failure-fix path a concurrency group that noise runs cannot displace (e.g. key the group per triggering workflow/branch for workflow_run, or move the job's group to job level), while keeping same-target supersede behaviour for the other jobs.

Acceptance criteria

• A successful (or main-branch) completion of a watched CI workflow no longer creates a Jules run at all, or creates one only when it is actionable.
• A failing non-main run of each watched CI workflow still triggers ci-failure-fix with the correct starting_branch.
• Two workflow_run completions in quick succession cannot cause a queued ci-failure-fix run to be cancelled by a run that will skip all its jobs.
• The schedule (weekly cleanup), issues: [labeled] (jules label), and workflow_dispatch triggers behave exactly as before.
• jules.yml still parses as valid YAML / passes the repo's workflow lint if any.

Found by the new-issue-creator job; run counts sampled from gh run list --limit 100 on 2026-10-18.