⚠️ Potential issue | 🟠 Major

cancel-in-progress: false does not guarantee all events are processed — the effective queue depth is 1.

The PR description states workflows "queued instead of running in parallel" and "all events are processed in order", but this overstates the guarantee. When a concurrent workflow is queued and another using the same concurrency group is already in progress, the new run becomes pending — but any existing pending run in the same group is canceled and replaced by the new one. This is true regardless of the cancel-in-progress value.

The practical consequence: in a burst scenario where run A is in-progress and runs B and C arrive in quick succession, GitHub only queues the most recent pending build — you can have only one running and one pending build in a concurrency group irrespective of cancel-in-progress. So if A is still running and B is pending, a new push C causes B to be cancelled and C becomes the pending build.

Additionally, ordering is not guaranteed for jobs or workflow runs using concurrency groups; runs in the same concurrency group are handled in an arbitrary order.

The primary goal of the PR (preventing two runs for the same issue/PR from executing simultaneously and producing duplicate bot comments) is achieved and this is a meaningful improvement. But the team should be aware that under rapid-fire edits, intermediate events can be silently dropped rather than queued, and rely on the most-recent run to produce the correct final triage state.

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/triage.yml around lines 11 - 13, The workflow comment
and/or PR description overstates concurrency guarantees; update the text near
the concurrency block (the concurrency: group: simili-${{
github.event.issue.number || github.event.pull_request.number }} and
cancel-in-progress: false entries) to state that only one run can be running and
at most one pending run exists per group, that pending runs are replaced (not
queued) when new events arrive regardless of cancel-in-progress, and that
ordering is not guaranteed; ensure the updated wording explicitly says
intermediate events may be dropped and that the change only prevents
simultaneous runs for the same issue/PR.

⚠️ Potential issue | 🟠 Major

${{ }} expression inside the heredoc is eagerly evaluated in the e2e context — the generated triage.yml gets a hardcoded group name, not a dynamic expression.

GitHub Actions literally replaces ${{ }} before invoking any shell, and this applies even inside a single-quoted heredoc delimiter (<< 'WFEOF'), because the substitution happens at the workflow-runner level, before bash is started. When the e2e workflow runs for PR #83, line 244 evaluates as:

• github.event.issue.number → "" (not an issue event)
• github.event.pull_request.number → 83

So the generated triage.yml in the test repo will contain:

concurrency:
  group: simili-83   # hardcoded e2e PR number, not a dynamic expression
  cancel-in-progress: false

Every triage run in the test repo — regardless of which issue triggered it — will land in simili-83, rather than per-issue groups. The e2e test itself passes because only one trigger issue is created, but the deployed config diverges from the production triage.yml behavior.

The codebase already uses __PR_SHA__ + sed (lines 264, 279) for exactly this purpose — escaping a ${{ }} expression that must survive into the generated file. Apply the same pattern here:

-          concurrency:
-            group: simili-${{ github.event.issue.number || github.event.pull_request.number }}
-            cancel-in-progress: false
+          concurrency:
+            group: simili-__CONC_EXPR__
+            cancel-in-progress: false

          SHA="${{ github.event.pull_request.head.sha || inputs.sha }}"
          sed -i "s|__PR_SHA__|$SHA|g" .github/workflows/triage.yml
+         CONC_EXPR='${{ github.event.issue.number || github.event.pull_request.number }}'
+         sed -i "s/__CONC_EXPR__/${CONC_EXPR}/g" .github/workflows/triage.yml

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/e2e-test.yml around lines 243 - 245, The heredoc currently
embeds a `${{ }}` concurrency expression which GitHub evaluates eagerly,
producing a hardcoded group; instead mirror the existing placeholder pattern
used for `__PR_SHA__`: write a single-quoted literal expression into the heredoc
via a shell variable (e.g. `CONC_EXPR='simili-${{ github.event.issue.number ||
github.event.pull_request.number }}'`) and then use `sed` (like the `__PR_SHA__`
replacement) to substitute a `__CONC_EXPR__` placeholder in the generated
triage.yml with the expanded `${CONC_EXPR}` so the final file contains the
runtime `${{ }}` template rather than a baked-in number.