[tend-agent]

A scheduled run parked in GitHub's pre-job waiting state never concludes, so it holds its concurrency group indefinitely. Under cancel-in-progress: false — which every generated scheduled workflow carries, paired with environment: tend — each later tick takes the one pending slot and is replaced by its successor, and the workflow stops running with nothing red to show for it. Step 1's census admits a row only on a non-null conclusion, so the parked run is absent by construction and the replacements it causes read as ordinary concurrency.

review-runs's Reconcile live work now lists it beside the red-default-branch and Dependabot checks, since a workflow whose queue is dead is live work in the same sense. The remedy is gh run cancel on the parked run, after pending_deployments confirms the gate has no timer and no reviewers to release it.

The wedge test covers event-driven runs too, not just cron ones: environment: tend comes from a shared template that every generated workflow but the secretless tend-mention-relay uses, and tend-review, tend-mention's handle job and tend-ci-fix pair it with cancel-in-progress: false, so a parked run there strands a PR's review queue the same way. Those have no scheduling interval to measure staleness against, so the bullet names the event that created the run as the bound instead.

The bullet also separates queued, which looks similar and needs the opposite handling. I reproduced that half here rather than taking it from the report: tend-notifications run 34748600612 has been queued since 2026-09-13, and gh run cancel on it answers Cannot cancel a workflow run that is completed while the runs API still reports status: queued, conclusion: null. Nothing is held — this repo's tend-notifications has run throughout — so the text says to leave it rather than fight it.

Text only, and deliberately one bullet: #1069 established that the recovery half of this class of finding belongs in a small report-or-remedy step, not a branching instruction table. uv run pytest -k skill passes.

Closes #1314

[tend-agent]

tend-mention-relay is the exception to "every generated workflow carries the tend environment" — mention-relay.yaml.j2 calls no environment() macro, and its header explains why: the review events it carries run on refs/pull/N/merge, which the operational secrets' environment does not admit, so the workflow holds no secret. A run with no environment has no deployment gate and cannot enter waiting at all, so the universal form is both false and slightly wider than the point it is making. The clause is load-bearing only to stop the check being read as cron-only, and the narrower form still does that — suggestion inline.