CI: Jules dispatch concurrency groups ignore their inputs — a third dispatch silently drops a pending run (jules.yml manual + daily Jules workflows in code, opencode, openchamber) #359

Finding

PR #357 (#357, commit 55efb43, merged in 238adf4) split jules.yml's shared workflow-level concurrency group into per-job groups "keyed by its target" (its words) — but the new manual job's group is a constant, and it is the one job whose target varies on every run: the dispatch prompt. The same constant-group-over-varying-inputs pattern also sits in four sibling Jules workflows across three repos (listed below); none of them sets queue:, so GitHub's default queue: single semantics apply.

With cancel-in-progress: false and the default single queue, each group holds one running run plus one pending run. A third arrival in the group silently cancels the pending one — it shows as "cancelled", produces no failure, and its Jules task never starts. This is the exact failure mode already fixed for other workflows in code #302 (auto-assign), openchamber #77 (queue: max), and dezren39/nix #413/#425 — the Jules dispatch paths were left out.

Evidence (all verified against current main, 2026-10-19)

developing-today/code (main 238adf4):

• .github/workflows/jules.yml:120-122 — manual job: group: ${{ github.workflow }}-manual, cancel-in-progress: false, no queue:. The job's only payload is the free-text dispatch input (prompt: defined at :39, consumed at :129 as prompt: ${{ inputs.prompt }}), so two dispatches with different prompts are different tasks sharing one group. Contrast the same PR's other jobs, which are keyed correctly: issue-${{ github.event.issue.number }} (:78-80) and ci-failure-fix-<workflow>-<branch> (:98-103); weekly-cleanup (:57-59) is also constant but has no varying inputs, so it is fine.
• .github/workflows/jules-daily-codebase-ideation.yml:21-23 — workflow-level group: ${{ github.workflow }}-${{ github.ref }}; workflow_dispatch inputs focus_app and allow_direct_prs vary per dispatch, and on dispatch github.ref is the dispatched branch (normally refs/heads/main), identical for every dispatch.
• .github/workflows/jules-daily-flake-sync.yml:21-23 — same group shape; dispatch inputs update_forks_only and auto_merge vary. A pending dispatch made with auto_merge: false can be silently replaced by a later default dispatch that will auto-merge.

developing-today/opencode (same finding, one issue per the cross-repo rule):

• .github/workflows/jules-daily-upstream-sync.yml:3-5 — workflow-level group: ${{ github.workflow }}-${{ github.ref }}, cancel-in-progress: false, no queue:; workflow_dispatch at :14 with inputs auto_merge and create_feature_issues.

developing-today/openchamber (same finding):

• .github/workflows/jules-daily-upstream-sync.yml:26-28 — same group shape; workflow_dispatch at :10 with inputs auto_merge and create_feature_issues.

dezren39/nix has no Jules workflow (checked .github/workflows/), so it is not affected.

Dedup: code #302/#304 (both closed) cover auto-assign and jules.yml's old workflow-level group, not these dispatch groups; opencode #74 and openchamber #72/#77 (all closed) fixed the same pattern for issue/bot workflows but do not name the Jules workflows. Code #287 (open, consolidate the three Jules workflows in code) is related — if it lands first, apply this fix in the consolidated file; consolidation alone does not change queue semantics.

Why it matters

A manually dispatched Jules run is an explicit human request carrying a specific task (the prompt) or specific safety flags (auto_merge: false). Losing the pending one silently — no failure, no notification, the task simply never happens — is worse than a loud failure, and in the auto_merge case the surviving run can do the thing the dropped run was dispatched to avoid.

Acceptance criteria

• For each group listed above, a pending run can no longer be silently displaced by a later run carrying different dispatch inputs: add queue: max to the group, or key the group by the distinguishing inputs / run identity.
• cancel-in-progress stays the literal false in every touched block (a queue: max + non-literal cancel-in-progress combination failed workflow validation in openchamber chore(deps): bump prettier-plugin-toml from 1.0.0 to 2.0.1 #84).
• Schedule-triggered behaviour is unchanged; same-target supersede semantics that PR ci(jules): watch only CI workflows, split concurrency group (#304) #357 deliberately kept for ci-failure-fix are untouched.
• If code CI: consolidate the three Jules workflows into one #287's consolidation lands first, the code-repo part of this fix is applied in the consolidated jules.yml instead of the three separate files.