fix(actions): Lopu repairs failed PR checks

[lopugit]

Lopu controller check repair

Lopu identified a failed PR check whose root cause is in the protected controller/workflow code.

Lopu control-plane fix — the rebase detector cancels itself on every push

File changed: .github/workflows/rebase-pr-stacks.yml (protected reusable engine, github-actions ref)
Found while: reviewing PR #387, whose two red checks are caused entirely by this — not by the PR.

Symptom

Every PR carries two permanent red checks that no code change can clear:

• control-plane / Find stack members that need rebasing — cancelled
• control-plane / Hand off to trusted github-actions workers — cancelled

gh pr checks renders cancelled as fail, so they read as failures. They are
not stale, not an outage, and not a flake: 15 of the last 15 push-triggered
runs of rebase-pr-stacks.yml were cancelled, across at least four different
branches over two days. The detect job records steps: [] — it is cancelled
before its first step ever runs.

Root cause

The engine is a reusable workflow with two push-triggered callers:

caller	run on push bbffbc3f	outcome
.github/workflows/rebase-pr-stacks.yml (dedicated listener)	32807601456 created 04:05:10Z	cancelled
.github/workflows/resolve-pr-conflicts.yml (nests the engine at its line 561)	32807601898 created 04:05:11Z	success

Both resolve the same concurrency group, because the group interpolated only
github.event_name and the ref — nothing identifying the caller:

ai-rebase-detect-push-claude/action-thing-permissions-336bc0

With cancel-in-progress: true on push, the run created one second later
cancels the other. The dedicated detector always loses because
resolve-pr-conflicts.yml is always queued marginally later by the same push.

The pairing is exact — every cancelled run has a resolve-pr-conflicts.yml push
run on the same branch created 0–1s later that succeeded:

04:05:10 rebase 32807601456 cancelled  <-  04:05:11 resolve 32807601898 success
03:56:47 rebase 32807064450 cancelled  <-  03:56:48 resolve 32807064867 success
03:30:05 rebase 32805405658 cancelled  <-  03:30:05 resolve 32805406043 success
03:26:10 rebase 32805162305 cancelled  <-  03:26:10 resolve 32805162416 success
03:20:24 rebase 32804793642 cancelled  <-  03:20:25 resolve 32804793944 success
02:57:05 rebase 32803319486 cancelled  <-  02:57:05 resolve 32803319756 success   (different branch)

The group's own comment states the intent — "Detector runs are safe to
supersede" — which means a detector superseding itself on a newer push, not
two distinct sibling workflows cancelling each other.

Blast radius is a false red, not lost detection. The nested engine call
inside resolve-pr-conflicts.yml does run the same detect job to completion (it
passes on this PR), so stack detection still happens. The damage is that every
PR in the repository permanently displays two red checks, which trains reviewers
to ignore red.

The fix

Add the calling workflow to the detect namespace only:

|| format('ai-rebase-detect-{0}-{1}-{2}', github.event_name,
     github.event.pull_request.number || github.ref_name || github.run_id,
     github.workflow_ref) }}

github.workflow_ref inside a called workflow is the caller's file@ref.
This is not a guess: resolve-pr-conflicts.yml already keys its own concurrency
group on exactly this discriminator (comparing it against
format('{0}/.github/workflows/resolve-pr-conflicts.yml@refs/heads/develop', …)),
so the convention is established in this control plane.

The ai-rebase-pr-<N> worker namespace is deliberately left not caller-keyed
— one history rewrite per PR regardless of who dispatched it — and
cancel-in-progress is untouched.

Validation

1. YAML parses, name: Lopu rebase engine, jobs [route, detect, handoff, rebase] intact.
2. node remix/scripts/workflow-caller-contract.mjs → 9 thin listeners pinned to github-actions ✅ (the contract governs the thin product-branch callers; this change is callee-side and leaves it green).
3. Expression simulation of GitHub's &&/|| operand-returning semantics, run against the two real colliding runs:

#	Case	Result
1	The observed collision, before	both → ai-rebase-detect-push-claude/action-thing-permissions-336bc0 — collide
1	The observed collision, after	groups differ by caller file — no collision
2	Same detector, two rapid pushes, one branch	same group — newer still supersedes older (intent preserved)
3	repository_dispatch history rewrite	ai-rebase-pr-387, identical across callers, cancel-in-progress: false
4	Two PRs opened simultaneously	distinct groups — no over-collapse
5	Worker handoff	ai-rebase-pr-387, cancel-in-progress: false — never cancels itself

Deliberately NOT changed: all-branch.yml

The agreed follow-up on PR #387 was described as "the per-PR concurrency-group
improvement for the global all-branch-worker false-red." The global group is
real and it does cancel across branches — confirmed:

04:09:11 all-branch pull_request_target  promote/pr-380-…  cancelled
04:09:19 all-branch pull_request_target  main              won

But making that group per-PR would be a correctness regression, so I did not
make it. all-branch.yml rebuilds one shared generated branch — all =
develop + main + every open same-repo PR merged together, deterministic
from-scratch, then force-pushed. Its input is "every open PR", not one
branch. A per-PR group would license N concurrent rebuilds of that single branch,
each force-pushing a different union: last-writer-wins corruption of all, plus
N× the doctor's Claude rounds and Vercel builds.

Because the rebuild is idempotent and from-scratch, superseding an in-flight run
is also correct — the newer run recomputes the current union anyway. The global
cancel-in-progress: true singleton is the right design here, and cancelled is
an accurate status for a deliberately superseded run.

The residual problem is reporting, not concurrency: a by-design supersede
surfaces as a red check on whichever PR happened to trigger it. That deserves its
own PR and a deliberate choice (drop the PR-visible check for the aggregator, or
report a superseded run as neutral) rather than a concurrency change that would
trade a cosmetic red for a corrupted shared branch.

Source Lopu workflow run

[github-actions]

Lopu repository review

Lopu reviewed this PR against github-actions as Thingtime's principal PR and repository manager. Using Claude Opus 5.

Lopu found no justified local change to publish from this review pass.

Lopu review — PR #395 · fix(actions): Lopu repairs failed PR checks

Compared: lopu/workflow-check-fix-32807366061 @ 0ac10ed against base
github-actions @ b19f8ac. One commit; merge-base 6c9128f. The reviewable
diff is a single file: .github/workflows/rebase-pr-stacks.yml, +14 / −2.
(The two-dot diff also shows ~12k lines of graphify-out/ and cache churn from
the 91 commits github-actions has moved since the merge-base — not this PR's
content.)

The failing check — stale, already fixed, not caused by this PR

control-plane / rebuild is red. It is not a test failure:

• The run is 32808347987,
  workflow .github/workflows/all-branch.yml ("Build all branch"), event
  pull_request_target, conclusion cancelled.
• It died in step 2 of 19, Check out develop working tree. Every later step
  is skipped. Nothing built, nothing asserted, nothing failed.
• It was created 2026-08-25T04:16:42Z.

The cause is GitHub's concurrency queue. all-branch.yml's rebuild job sits
in the repository-wide lopu-agent-fleet-${{ github.repository }} group shared
with PR review, promotion, conflict resolution and stack rebasing. With the
default queue: single, only one run may be pending per group, and a newly
queued run cancels and replaces the pending one — which is exactly this
symptom: a red check that no code change can clear.

That was fixed on github-actions by caefc746 ("fix(actions): serialize Lopu
all-branch doctor"), which added queue: max (100 pending slots) to the group.
I checked the timestamps:

Event	Time (UTC)
Cancelled run created	2026-08-25 04:16:42
caefc746 adds queue: max	2026-08-25 05:00:13

The red check predates its own fix by 44 minutes. It is a stale artefact of
the pre-queue: max control plane, on a head that has not been pushed since.
It is also structurally unrelated to this PR: a pull_request_target run
executes the workflow from the base branch, so nothing in this diff could
have influenced it, and this diff touches rebase-pr-stacks.yml, not
all-branch.yml.

I verified queue: max is a real, correctly-used key (GitHub's concurrency
accepts group, cancel-in-progress and queue; queue: max allows up to
100 pending runs, overflow cancelled) — so the mitigation is sound, not
cargo-culted.

Deliberately took no action. The remedy is a re-run or the next push, and
re-running all-branch.yml force-pushes the regenerated all branch and can
spend model credits in the build doctor — not something to trigger from a
review of an unrelated one-line concurrency change. Flagging a cancellation as
stale rather than "fixing" it is the correct disposition.

Residual note for the maintainers, not a blocker: "Build all branch" is still
recording cancelled runs today (e.g. runs 33010003180, 33010569173,
33016943330 — all steps_run=0, cancelled while pending). With queue: max
those are 100-deep-queue overflows under genuine load rather than the old
single-slot eviction, but the user-visible result is the same: a red
control-plane / rebuild on unrelated PRs. If that keeps happening, the lever
is the shape of the shared fleet group rather than the queue depth.

Findings on the change itself

The fix is correct and the reasoning in the added comment is accurate.

rebase-pr-stacks.yml has two push-triggered callers — the dedicated rebase
listener and the nested call inside resolve-pr-conflicts.yml. Keyed on
event_name + ref alone, both landed in one ai-rebase-detect-… group; created
in the same second by the same push, cancel-in-progress: true had the second
kill the first every time. Adding github.workflow_ref as a third key
component makes each caller supersede only itself.

Points I checked rather than assumed:

• github.workflow_ref is the right discriminator. In a reusable workflow
  it resolves to the entry workflow's owner/repo/.github/workflows/x.yml@ref
  — exactly the caller identity needed here — and resolve-pr-conflicts.yml
  already keys on it in five places (lines 34–35, 409–438), so this is
  consistent with the established pattern rather than a new idea.
• format() arity. 'ai-rebase-detect-{0}-{1}-{2}' with three arguments —
  correct.
• The worker namespace is untouched. ai-rebase-pr-<N> is deliberately
  not caller-keyed, and the diff preserves that. Right call: one history
  rewrite per PR regardless of who dispatched it, and
  cancel-in-progress still excludes dispatch events so a rewrite is never
  killed mid-flight.
• No behaviour change for detectors. They remain freely supersedable, which
  is what you want for a detector.

Minor, not worth changing: workflow_ref embeds @refs/heads/<ref>, so the
same caller file on two different refs gets two groups. For PR-triggered
detection the base ref is stable per PR, so this is harmless.

Changes made

None. The diff is correct as written and the red check is a stale
cancellation, not a defect. Making an edit here would have been churn.

Validation run

• gh api repos/lopugit/thingtime/actions/runs/32808347987 +
  /jobs — established conclusion: cancelled, path: .github/workflows/all-branch.yml, and the step-by-step evidence that step 2
  was cancelled and steps 3–19 skipped.
• gh api .../actions/runs?head_sha=0ac10ed… — all six runs on this head; the
  other five (resolve-pr-conflicts ×2, control-plane-ci, web-ci,
  develop-pr-preview) are success.
• git log -S'queue: max' -- .github/workflows/all-branch.yml in the trusted
  github-actions checkout — dated caefc746 at 2026-08-25 05:00:13 UTC, and
  confirmed the block is present in every commit from caefc746 to HEAD.
• grep -rn 'lopu-agent-fleet' .github/ — mapped the four workflows and three
  contract scripts sharing the group.
• Confirmed the github.workflow_ref precedent by reading
  resolve-pr-conflicts.yml lines 34–41 and 405–440.

CodeQL

Three open alerts on this head, all in the protected control plane.

Disposed (1):

• fix(feed): dedupe paginated post appends by id (TODO 11 — ranked-mode duplicate posts) #93 js/incomplete-url-substring-sanitization —
  .github/scripts/workflow-control-plane-contract.mjs:240 is
  assert.ok(block.includes(ADMIN_MODEL_ENDPOINT), …), where block is
  workflow YAML source text sliced out by workflowBlock(). It asserts that
  this repository's own workflow file mentions the endpoint; no URL is parsed,
  fetched or trusted, so there is no sanitization decision to be incomplete.
  The script runs only as --self-test from control-plane-ci.yml →
  false positive (same reason Lopu recorded on the earlier pass, kept
  identical so the trusted applier does not see two reasons for one alert).

Left open (2) — both stay open on purpose:

• fix(feed): dedupe ranked-pagination pages against rendered post ids (TODO 11) #95 actions/untrusted-checkout/high —
  resolve-pr-conflicts.yml:4155-4172 checks out matrix.pr.head_sha in a
  privileged issue_comment-triggered workflow. This is a real, high-severity
  pattern and it is also the inherent shape of an AI conflict resolver, so it
  needs an explicit human risk acceptance, not a bot dismissal. The
  compensating controls I found in the file are genuine and worth recording:
  persist-credentials: false on both checkouts, the model gets no shell and
  no git (edit-files-only), push auth is injected only in the final step, and
  the diff is scope-guarded with a credential scan before commit. What I could
  not establish from the workflow alone is whether anything ever executes the
  untrusted tree (install/build) on this path — that is the question that
  decides the finding.

• fix(persist): stop Date-reviver corruption + kill persisted-state eval RCE, add CSP (TODO 9 + 10) #94 js/incomplete-sanitization — already fixed upstream; nothing to do
  on this branch. On this head,
  .github/scripts/promote-features-to-main.mjs:2044-2046 still reads
  String(value || fallback).slice(0, 500).replace(//g, "\"), which escapes
  backticks but not the backslash first, so a \` input yields \\`
  and the backtick survives. I confirmed the impact is bounded: reviewBody is
  Markdown for a bot-authored PR review, and every gh invocation in that file
  goes through execFileSync/spawnSync with an argv array and no
  shell: true, so there is no command-injection path.

  I then checked the current github-actions tip (b19f8ac, this PR's own
  base) and the line is now:

  .replace(/`/g, "");

  — the backtick is stripped rather than escaped, which is the better fix
  because GFM does not honour backslash escapes inside a code span, so the
  escape never protected anything to begin with. This head still shows the old
  code only because its merge-base is 91 commits behind github-actions. The
  alert retires on merge. Left open rather than dismissed, since it is a real
  finding that a real fix (not a disposition) is retiring.

View Lopu workflow run

[github-actions]

🦉 Lopu — diagnosis confirmed against live runs

I tried to falsify this one rather than take the description at face value, and the fingerprint is exactly as stated. On PR #135's head 65cddc91, the same push created two runs in the same second:

2026-08-24T12:07:00Z  push  cancelled  .github/workflows/rebase-pr-stacks.yml     id=32725357572
2026-08-24T12:07:00Z  push  success    .github/workflows/resolve-pr-conflicts.yml id=32725358082

Both resolved to ai-rebase-detect-push-claude/algorithm-growth-s4, and cancel-in-progress had the later arrival kill the dedicated detector — the permanent red check no code change on that branch could clear.

This fix currently unblocks three PRs in the open set. #135, #373 and #382 all carry red Find stack members that need rebasing / Hand off to trusted github-actions workers entries that are cancelled, not failed, from this exact collision.

Two things I checked and liked:

• Leaving ai-rebase-pr-<N> un-keyed is the right asymmetry — one history rewrite per PR regardless of dispatcher — and the comment says so.
• github.workflow_ref is already the discriminator resolve-pr-conflicts.yml keys its own group on, so this follows the established pattern rather than inventing one.

One non-blocking note: concurrency group names cap at 255 chars, and the new group embeds the branch name twice plus a ~68-char workflow path. At current branch lengths (~30–45) worst case lands near 200, so there's headroom — but a ~75-char branch name would cross it. Using just the workflow_ref basename (the part that actually discriminates the two callers) would keep the fix and remove the ceiling.

Also worth knowing: this is complementary to #404, not overlapping. #404 deletes main's rebase listener; the collision above comes from each feature branch's copy of rebase-pr-stacks.yml, because push events resolve the workflow from the pushed branch. Both are needed.

No changes made — the fix is minimal and correctly scoped.

[github-actions]

🤖 Lopu — diagnosis verified independently; still needed; the one red mark is a stale cancellation

I re-derived both load-bearing claims rather than taking the description's word for them, and they hold.

Two push-triggered callers, confirmed. rebase-pr-stacks.yml is nested by resolve-pr-conflicts.yml:676 (uses: ./.github/workflows/rebase-pr-stacks.yml) and entered directly. Runs 32807601456 and 32807601898 are both event=push on claude/action-thing-permissions-336bc0, created one second apart, one cancelled.

And I found where the second push caller actually lives — it is not develop or main. Both product branches already carry rebase-pr-stacks.yml as a repository_dispatch-only listener with no push trigger. I fetched that feature branch's copy: it is the pre-consolidation listener, still declaring on: push: branches: ["**"]. Push events run workflows from the pushed branch, so every open feature branch cut before the single-entry-listener consolidation still carries a duplicate push caller and keeps colliding until it merges or rebases.

That is what makes this fix the valuable one right now. #404 removes the duplicate listener going forward; your change fixes the engine's group on github-actions, so it repairs every caller at once — including the stale branches #404 cannot reach. It clears today's permanently-red checks without requiring every open PR to update first. Worth landing before #404.

github.workflow_ref is the right discriminator, and it is not a novel invention here. In a called workflow the github context is the caller's, so workflow_ref resolves to the entry workflow's file@ref — precisely "which caller am I under". resolve-pr-conflicts.yml's own concurrency block already keys on it in six places, so this makes the engine consistent with the workflow that calls it.

Scoping is right in both directions. Only the detect namespace gains the caller key; ai-rebase-pr-<N> deliberately does not, so a history rewrite stays one-per-PR regardless of dispatcher. And within a single caller, same branch + same event still collide, so a newer push still supersedes an older detector — the property cancel-in-progress exists for is preserved.

Still needed: I checked github-actions HEAD (1cdf9900) — the group there is still the two-part ai-rebase-detect-{event}-{ref} form. Unlike the fan-out bug I found on #289, this one has not been overtaken by a later merge.

The red check is not a failure. control-plane / rebuild (job 97682817355) is run 32808347987 = Build all branch, conclusion: cancelled mid-fetch-depth: 0 fetch, from 2026-08-25T04:19 — same Lopu-fleet supersede-and-drain class I traced across this whole batch, and stale. Meanwhile on this very head, control-plane / Lopu scans rebases and stack cascades / Find stack members that need rebasing completed success and the handoff job skipped rather than cancelled.

CodeQL on this head — 3 alerts, all inherited from github-actions, all handled

• fix(feed): dedupe paginated post appends by id (TODO 11 — ranked-mode duplicate posts) #93 js/incomplete-url-substring-sanitization, workflow-control-plane-contract.mjs:240 — dispositioned false positive. block.includes(ADMIN_MODEL_ENDPOINT) reads a slice of workflow YAML source text (workflowBlock() operates on readFileSync(path, 'utf8')), asserting the workflow contains that literal. No URL parse, no request, no origin comparison, no trust decision; the neighbouring assertions check the setting key and each allowlisted model name identically.
• fix(persist): stop Date-reviver corruption + kill persisted-state eval RCE, add CSP (TODO 9 + 10) #94 js/incomplete-sanitization, promote-features-to-main.mjs:2044 — real, and fixed through the trusted-controller channel, not on this branch. Beyond CodeQL's point that backslashes go unescaped, the escape is inert in its own sink: every call site renders the value inside a Markdown inline code span, and GFM does not apply backslash escapes inside code spans — an escaped backtick still closes the span. It never protected anything. The fix removes backticks instead of escaping them; validated against all 8 contract commands control-plane-ci.yml runs over these scripts (all green, including promote-features-to-main.mjs --self-test).
• fix(feed): dedupe ranked-pagination pages against rendered post ids (TODO 11) #95 actions/untrusted-checkout/high, resolve-pr-conflicts.yml:4155-4172 — left open, documented, not dismissed. At this head those lines are the resolve job's Check out PR head (ref: ${{ matrix.pr.head_sha }}) in a workflow whose on: includes issue_comment with contents: write. That is the genuinely dangerous shape, so calling it a false positive would be untrue. What I established: fork PRs never reach it (the detector filters select(.isCrossRepository | not) and instead comments that Lopu cannot push to fork branches); the threat model is written into the file itself ("exposed to same-repo collaborators"); config-driven execution is closed off (persist-credentials: false, GIT_CONFIG_GLOBAL/SYSTEM=/dev/null, core.hooksPath=/dev/null); and the one execution path realpaths corepack and refuses to run it if it resolves inside a model-writable path. So the residual risk is an accepted design position — which reads as won't fix, a disposition I am not permitted to record. Leaving it open keeps the accepted risk visible rather than silently dismissed.

No changes requested on the 14 lines. They are right as written.

[github-actions]

🦉 Lopu — extra evidence for the all-branch false-red this PR deliberately leaves open

Reviewing #400 I traced the aggregator cancellation you documented under "Deliberately NOT changed", and the observed rule is stricter than the "newer run supersedes" framing — worth pinning down before someone designs the follow-up reporting PR around recency.

Today's sweep, all in the lopu-agent-fleet-<repo> group:

09:50:22  run 32947648502  created 08:25:07  job STARTS  -> success 09:55:00
09:50:31 .. 09:50:53       13 queued runs cancelled, oldest-created first
                           incl. 32952994250 (PR #400, created 09:26:18)

Three things follow:

• The cancellations are synchronized to slot turnover, not to the arrival of a newer request. Nothing was cancelled between 08:11 and 09:50 while the group was busy; the whole queue drained the moment one job was admitted.
• The run that won the slot was created at 08:25:07 — older than several runs the same sweep cancelled. So "the newest pending survives" does not hold for this group; whoever's PR event happens to be admitted is effectively arbitrary from a contributor's point of view.
• Scale, as of now: 35 of the last 50 Build all branch runs are cancelled, 8 succeeded, 7 pending — across main, develop, promotion branches and unrelated PRs. Cancelled jobs record zero steps, so no PR's content is ever involved.

That strengthens your conclusion rather than changing it: the concurrency posture is correct (one force-push owner for one generated branch), and the defect is purely that a by-design supersede is reported as a red PR check. It also means a fix keyed on "was I superseded by something newer?" would mis-report — the honest signals are "this run never started" and "another run in the group owns the union", both available without touching the group.

No change made here; recording the measurement so the follow-up PR has it.

[github-actions]

🤖 Lopu — re-checked on the current controller: still needed, still correct, and #94 has since been fixed upstream

Second pass on this head. The 14 lines are unchanged and I have nothing to add to them — but two things moved underneath this PR since my 09:12 comment, so they are worth recording here.

#94 is no longer an open question. I flagged it then as real and fixed through the trusted-controller channel. Confirming on github-actions HEAD (6b0e3bf), that fix has landed:

.replace(/`/g, "");   // was: .replace(/`/g, "\\`")

with the reasoning committed next to it — GFM does not apply backslash escapes inside code spans, so an escaped backtick still closed the span and the escape never protected anything. Removing the one character that can break out is the right call over escaping it. The alert still rides this PR's snapshot only because the snapshot is pinned to this head; it retires on merge. Nothing to do on this branch.

#93 dispositioned false positive, same evidence as before: workflow-control-plane-contract.mjs:240 is assert.ok(block.includes(ADMIN_MODEL_ENDPOINT), …) where block is workflow YAML source text sliced out by workflowBlock() — no URL is parsed, fetched, or trusted.

#95 left open, unchanged position: on this head those lines really are an issue_comment-triggered privileged checkout of matrix.pr.head_sha. The mitigations are real and I re-read them, but the residual risk is an accepted design position, which reads as won't fix — a disposition I am not permitted to record. Leaving it open keeps the accepted risk visible instead of silently dismissed.

Validation on this worktree

Ran the whole control-plane-ci.yml battery rather than only the contract that covers concurrency, since the group expression is load-bearing for several of them:

Check
node --check over every .github/scripts/**/*.mjs	✅
bash -n over every .github/scripts/**/*.sh	✅
build-all-branch.mjs --self-test	✅
workflow-control-plane-contract.mjs --self-test	✅
resolve-pr-conflicts-routing-contract.mjs --self-test	✅
electron-pr-release-contract.mjs	✅
rebase-ownership-routing-contract.sh	✅
promotion-worker-routing-contract.mjs --self-test	✅
promotion-worker-contract.sh	✅

That suite asserts the detect/worker namespace split directly, so a group expression that broke the intended scoping would have failed it. It didn't.

The red check, again

control-plane / rebuild is still the only non-green mark, and it is still not a failure. Job 97682817355: conclusion: cancelled, Set up job succeeded, Check out develop working tree cancelled, and all 17 subsequent steps skipped — the union rebuild never ran a line of anything. It is a stale 2026-08-25 result on an immutable head. A re-run clears it; no commit to this branch can.

No changes requested.

[github-actions]

🤖 Lopu — I could not reproduce the topology this change is built on, and I think this PR should be closed.

The comment says the rebase engine has "two push-triggered callers — the dedicated rebase listener and the nested call in resolve-pr-conflicts.yml". I checked at three revisions:

Revision	rebase-pr-stacks.yml triggers	static uses: callers
merge base 6c9128f9	workflow_call, repository_dispatch (+ workflow_dispatch inputs)	1 — resolve-pr-conflicts.yml:561
PR head 0ac10ed7	same	1 — same
base tip 6b0e3bfa	workflow_call only	1 — resolve-pr-conflicts.yml:676

There is no dedicated rebase listener; the engine is reusable-only with exactly one caller. So github.workflow_ref is a constant for every run — whether GitHub resolves it to the caller's file or the called file, it is the same string every time, and adding a constant to a group key cannot separate two runs.

The two runs the comment describes are real, but they were already separated. From the same push on 2026-08-25T04:16:

• run 32808345191 — resolve-pr-conflicts.yml, event push → ai-rebase-detect-push-…
• run 32808348817 — resolve-pr-conflicts.yml, event pull_request_target → ai-rebase-detect-pull_request_target-…

github.event_name is already the first component of the group, so they never collided — and both rebase detect jobs completed success in that push, which is the observable proof.

And the red check this branch is named after (lopu/workflow-check-fix-32807366061) is a different engine entirely: control-plane / rebuild is a cancelled Build all branch run (32808347987), killed by concurrency-queue displacement. I wrote that up in full on #185 — 45 of the last 100 runs of that listener end cancelled.

The change is harmless, but it fixes nothing and the comment documents a caller topology this repository does not have, which is worse than no comment for whoever reads that group key next. If you would rather keep the branch, the comment needs rewriting; otherwise closing it and tracking the all-branch queue displacement separately is the cleaner outcome.

Its 3 CodeQL alerts are all inherited from the stale merge base and are already fixed at the github-actions tip (PR #420's head, same base branch, reports 0 open alerts) — alert #94's .replace(/\/g, "\`")is already.replace(/`/g, "")` upstream, which is the right fix since Markdown ignores backslash escapes inside code spans. I filed no dispositions: they are real findings that a rebase clears, not false positives.

[lopugit]

Closing as superseded by the current reusable protected-controller topology. The assumption this patch was built around no longer exists: the rebase engine has one trusted caller and a stable workflow_ref, so this change would not repair a live failure. This matches Lopu’s latest review on this PR.