chore: update tend workflows (0.1.20 → 0.1.22)

[prql-bot]

Nightly regeneration of the tend-* workflow files via uvx tend@latest init. Beyond the action-ref bumps, this release reworks the tend-notifications pre-check and removes the tend-review HEAD gate — both are inlined shell in the generated workflows, so they show up as real diff rather than a version stamp.

tend version: 0.1.20 → 0.1.22

Notable changes

• tend-notifications: the pre-check is rewritten around a repository-level recovery queue — it enables repo watching idempotently each cycle, pages the whole unread list at a 10-minute cutoff, and passes that cutoff to the agent, replacing the old layered mark-read sweep (fix(notifications): recover missed work from unread queue max-sixty/tend#1074). The job also gains a serial concurrency group.
• tend-review: the "Skip when the live HEAD is already examined" gate step is gone. A push mid-review now re-targets the running review instead of letting the queued run exit, and the concurrency group gains queue: max so a push can't evict a pending ready_for_review event (Re-target a review when HEAD moves, instead of discarding it max-sixty/tend#1082, Make Tend review runs less visible max-sixty/tend#1078).
• Skills now check the default branch for an already-landed fix before opening a PR (skills: check the default branch for a landed fix before opening a PR max-sixty/tend#1070), and review-runs adds a run census as a second input when draining stranded triggers (skills(review-runs): add the run census as a second stranded-trigger drain input max-sixty/tend#1073).
• Generator: watched_workflows and branches are validated as string lists (fix(generator): validate watched_workflows and branches as string lists max-sixty/tend#1076), and block prompts no longer get padded blank lines (fix(generator): stop padding blank lines inside block prompts max-sixty/tend#1090).
• Bundled scripts: fail fast when a commit can't be resolved (fix(scripts): fail fast when a commit cannot be resolved max-sixty/tend#1055), and tend-review no longer gates the check poll (fix(scripts): don't let tend-review gate the poll max-sixty/tend#1053).

Full upstream diff: max-sixty/tend@0.1.20...0.1.22

---

Also in this PR: an .github/actionlint.yaml entry for the concurrency.queue key.

0.1.22's tend-review.yaml uses queue: max, a real GitHub concurrency key that actionlint does not recognise — it fails with unexpected key "queue" for "concurrency" section, turning both MegaLinter and the pre-commit actionlint hook red. Upstream tracks this in rhysd/actionlint#654 and #657; the PR adding support (#661) was closed unmerged, and v1.7.12 — the latest release, and the version pinned in .pre-commit-config.yaml — still rejects it. Without the suppression every future nightly regen lands red, so it ships here rather than as a separate PR that this one would have to wait on.

The ignore is scoped to .github/workflows/tend-*.yaml and to that one message. Verified locally with actionlint v1.7.12: the whole workflow directory lints clean with the entry, and adding an unrelated bogus key to the same concurrency: block still errors, so the suppression isn't swallowing real problems.

[prql-bot]

pre-commit.ci is red on this head, and it won't clear on its own.

actionlint rejects queue: max. The new concurrency.queue key in tend-review.yaml is valid GitHub syntax (docs), but actionlint's schema doesn't know it yet, so the pinned v1.7.12 hook fails the run:

.github/workflows/tend-review.yaml:22:7: unexpected key "queue" for "concurrency" section. expected one of "cancel-in-progress", "group" [syntax-check]

Waiting for an autoupdate won't help: v1.7.12 (2026-03-30) is the latest release, rhysd/actionlint#657 and #654 are both open, and the PR that added support (#661) was closed unmerged.

Fix — tend's own repo already hit this and carries the remedy in its .pre-commit-config.yaml; mirroring it here is enough:

 - repo: https://github.com/rhysd/actionlintrev: v1.7.12hooks:
- id: actionlint# GitHub accepts concurrency.queue, but this pin does not yet know it.# Ignore only that schema false positive.args:
- -ignore
- 'unexpected key "queue" for "concurrency" section'

I verified this against actionlint v1.7.12 on the merged tree: the whole .github/workflows/ set exits 0 with the flag and reports only the queue diagnostic without it, so nothing else is being suppressed. .pre-commit-config.yaml is outside this diff, so it needs a commit rather than a suggestion.

Separately, this looks like an upstream gap rather than a PRQL one — the generator emits queue: max into every adopter's workflows, but the -ignore arg only exists in tend's own pre-commit config, so any adopter running the actionlint hook goes red on the next regen. Worth an issue on max-sixty/tend.

Overlaps with #6251. That PR regenerates the same eight tend-*.yaml files to add sandbox_setup: blocks, and those blocks sit in the with: mapping directly under the uses: max-sixty/tend/claude@… line this PR bumps — so the two will conflict. Whichever lands second should be regenerated with uvx tend init rather than hand-merged, particularly since 0.1.22 changes how block prompts are padded (max-sixty/tend#1090), which is exactly the rendering #6251 depends on.

[prql-bot]

Fixed in 8a41d64, and the remedy is broader than the one my review proposed. Two checks were red on this head, not one — pre-commit.ci - pr and lint-megalinter / MegaLinter — on the same diagnostic. MegaLinter runs actionlint through its own ACTION_ACTIONLINT descriptor, so the -ignore hook arg I suggested for .pre-commit-config.yaml would have cleared pre-commit.ci and left MegaLinter red. The paths/ignore block in .github/actionlint.yaml that landed instead is read by the binary itself, so it covers both runners and any direct CLI call, and it's scoped to .github/workflows/tend-*.yaml so a schema typo in a hand-written workflow still fails.

The upstream gap is filed as max-sixty/tend#1094 — the generator emits queue: max for every adopter, but the suppression only exists in tend's own pre-commit config, so each adopter hits this on their next regen.

Verification and sources

Against the actionlint v1.7.12 release binary (linux_amd64) on this branch:

• no config change → .github/workflows/tend-review.yaml:22:7: unexpected key "queue" for "concurrency" section. expected one of "cancel-in-progress", "group" [syntax-check]
• with the block in 8a41d64 → exits 0 over .github/workflows/*.yaml
• negative control: an injected bogus-top-level-key: true in tend-review.yaml still fails with the block in place, so the ignore isn't swallowing other diagnostics

MegaLinter's failure was the same single blocking diagnostic — run 33297574559 reports Linted [ACTION] files with [actionlint]: Found 1 error(s); everything else it flagged (jscpd, shellcheck, cpplint) is already under DISABLE_ERRORS_LINTERS in .mega-linter.yaml. check-ok-to-merge was red as a consequence of those two.

Upstream state, rechecked: v1.7.12 (2026-03-30) is still the latest release; rhysd/actionlint#657 (issue) and #654 (PR) are open; #661 was closed unmerged. My review called #654 an issue — it's a PR.

[prql-bot]

Nightly regeneration of the tend-* workflow files via uvx tend@latest init. Beyond the action-ref bumps, this release reworks the tend-notifications pre-check and removes the tend-review HEAD gate — both are inlined shell in the generated workflows, so they show up as real diff rather than a version stamp.

tend version: 0.1.20 → 0.1.22

Notable changes

• tend-notifications: the pre-check is rewritten around a repository-level recovery queue — it enables repo watching idempotently each cycle, pages the whole unread list at a 10-minute cutoff, and passes that cutoff to the agent, replacing the old layered mark-read sweep (fix(notifications): recover missed work from unread queue max-sixty/tend#1074). The job also gains a serial concurrency group.
• tend-review: the "Skip when the live HEAD is already examined" gate step is gone. A push mid-review now re-targets the running review instead of letting the queued run exit, and the concurrency group gains queue: max so a push can't evict a pending ready_for_review event (Re-target a review when HEAD moves, instead of discarding it max-sixty/tend#1082, Make Tend review runs less visible max-sixty/tend#1078).
• Skills now check the default branch for an already-landed fix before opening a PR (skills: check the default branch for a landed fix before opening a PR max-sixty/tend#1070), and review-runs adds a run census as a second input when draining stranded triggers (skills(review-runs): add the run census as a second stranded-trigger drain input max-sixty/tend#1073).
• Generator: watched_workflows and branches are validated as string lists (fix(generator): validate watched_workflows and branches as string lists max-sixty/tend#1076), and block prompts no longer get padded blank lines (fix(generator): stop padding blank lines inside block prompts max-sixty/tend#1090).
• Bundled scripts: fail fast when a commit can't be resolved (fix(scripts): fail fast when a commit cannot be resolved max-sixty/tend#1055), and tend-review no longer gates the check poll (fix(scripts): don't let tend-review gate the poll max-sixty/tend#1053).

Full upstream diff: max-sixty/tend@0.1.20...0.1.22

---

Also in this PR: an .github/actionlint.yaml entry for the concurrency.queue key.

0.1.22's tend-review.yaml uses queue: max, a real GitHub concurrency key that actionlint does not recognise — it fails with unexpected key "queue" for "concurrency" section, turning both MegaLinter and the pre-commit actionlint hook red. Upstream tracks this in rhysd/actionlint#654 and #657; the PR adding support (#661) was closed unmerged, and v1.7.12 — the latest release, and the version pinned in .pre-commit-config.yaml — still rejects it. Without the suppression every future nightly regen lands red, so it ships here rather than as a separate PR that this one would have to wait on.

The ignore is scoped to .github/workflows/tend-*.yaml and to that one message. Verified locally with actionlint v1.7.12: the whole workflow directory lints clean with the entry, and adding an unrelated bogus key to the same concurrency: block still errors, so the suppression isn't swallowing real problems.

[prql-bot]

pre-commit.ci is red on this head, and it won't clear on its own.

actionlint rejects queue: max. The new concurrency.queue key in tend-review.yaml is valid GitHub syntax (docs), but actionlint's schema doesn't know it yet, so the pinned v1.7.12 hook fails the run:

.github/workflows/tend-review.yaml:22:7: unexpected key "queue" for "concurrency" section. expected one of "cancel-in-progress", "group" [syntax-check]

Waiting for an autoupdate won't help: v1.7.12 (2026-03-30) is the latest release, rhysd/actionlint#657 and #654 are both open, and the PR that added support (#661) was closed unmerged.

Fix — tend's own repo already hit this and carries the remedy in its .pre-commit-config.yaml; mirroring it here is enough:

 - repo: https://github.com/rhysd/actionlintrev: v1.7.12hooks:
- id: actionlint# GitHub accepts concurrency.queue, but this pin does not yet know it.# Ignore only that schema false positive.args:
- -ignore
- 'unexpected key "queue" for "concurrency" section'

I verified this against actionlint v1.7.12 on the merged tree: the whole .github/workflows/ set exits 0 with the flag and reports only the queue diagnostic without it, so nothing else is being suppressed. .pre-commit-config.yaml is outside this diff, so it needs a commit rather than a suggestion.

Separately, this looks like an upstream gap rather than a PRQL one — the generator emits queue: max into every adopter's workflows, but the -ignore arg only exists in tend's own pre-commit config, so any adopter running the actionlint hook goes red on the next regen. Worth an issue on max-sixty/tend.

Overlaps with #6251. That PR regenerates the same eight tend-*.yaml files to add sandbox_setup: blocks, and those blocks sit in the with: mapping directly under the uses: max-sixty/tend/claude@… line this PR bumps — so the two will conflict. Whichever lands second should be regenerated with uvx tend init rather than hand-merged, particularly since 0.1.22 changes how block prompts are padded (max-sixty/tend#1090), which is exactly the rendering #6251 depends on.

[prql-bot]

Fixed in 8a41d64, and the remedy is broader than the one my review proposed. Two checks were red on this head, not one — pre-commit.ci - pr and lint-megalinter / MegaLinter — on the same diagnostic. MegaLinter runs actionlint through its own ACTION_ACTIONLINT descriptor, so the -ignore hook arg I suggested for .pre-commit-config.yaml would have cleared pre-commit.ci and left MegaLinter red. The paths/ignore block in .github/actionlint.yaml that landed instead is read by the binary itself, so it covers both runners and any direct CLI call, and it's scoped to .github/workflows/tend-*.yaml so a schema typo in a hand-written workflow still fails.

The upstream gap is filed as max-sixty/tend#1094 — the generator emits queue: max for every adopter, but the suppression only exists in tend's own pre-commit config, so each adopter hits this on their next regen.

Verification and sources

Against the actionlint v1.7.12 release binary (linux_amd64) on this branch:

• no config change → .github/workflows/tend-review.yaml:22:7: unexpected key "queue" for "concurrency" section. expected one of "cancel-in-progress", "group" [syntax-check]
• with the block in 8a41d64 → exits 0 over .github/workflows/*.yaml
• negative control: an injected bogus-top-level-key: true in tend-review.yaml still fails with the block in place, so the ignore isn't swallowing other diagnostics

MegaLinter's failure was the same single blocking diagnostic — run 33297574559 reports Linted [ACTION] files with [actionlint]: Found 1 error(s); everything else it flagged (jscpd, shellcheck, cpplint) is already under DISABLE_ERRORS_LINTERS in .mega-linter.yaml. check-ok-to-merge was red as a consequence of those two.

Upstream state, rechecked: v1.7.12 (2026-03-30) is still the latest release; rhysd/actionlint#657 (issue) and #654 (PR) are open; #661 was closed unmerged. My review called #654 an issue — it's a PR.

[prql-bot]

Nightly regeneration of the tend-* workflow files via uvx tend@latest init. Beyond the action-ref bumps, this release reworks the tend-notifications pre-check and removes the tend-review HEAD gate — both are inlined shell in the generated workflows, so they show up as real diff rather than a version stamp.

tend version: 0.1.20 → 0.1.22

Notable changes

• tend-notifications: the pre-check is rewritten around a repository-level recovery queue — it enables repo watching idempotently each cycle, pages the whole unread list at a 10-minute cutoff, and passes that cutoff to the agent, replacing the old layered mark-read sweep (fix(notifications): recover missed work from unread queue max-sixty/tend#1074). The job also gains a serial concurrency group.
• tend-review: the "Skip when the live HEAD is already examined" gate step is gone. A push mid-review now re-targets the running review instead of letting the queued run exit, and the concurrency group gains queue: max so a push can't evict a pending ready_for_review event (Re-target a review when HEAD moves, instead of discarding it max-sixty/tend#1082, Make Tend review runs less visible max-sixty/tend#1078).
• Skills now check the default branch for an already-landed fix before opening a PR (skills: check the default branch for a landed fix before opening a PR max-sixty/tend#1070), and review-runs adds a run census as a second input when draining stranded triggers (skills(review-runs): add the run census as a second stranded-trigger drain input max-sixty/tend#1073).
• Generator: watched_workflows and branches are validated as string lists (fix(generator): validate watched_workflows and branches as string lists max-sixty/tend#1076), and block prompts no longer get padded blank lines (fix(generator): stop padding blank lines inside block prompts max-sixty/tend#1090).
• Bundled scripts: fail fast when a commit can't be resolved (fix(scripts): fail fast when a commit cannot be resolved max-sixty/tend#1055), and tend-review no longer gates the check poll (fix(scripts): don't let tend-review gate the poll max-sixty/tend#1053).

Full upstream diff: max-sixty/tend@0.1.20...0.1.22

---

Also in this PR: an .github/actionlint.yaml entry for the concurrency.queue key.

0.1.22's tend-review.yaml uses queue: max, a real GitHub concurrency key that actionlint does not recognise — it fails with unexpected key "queue" for "concurrency" section, turning both MegaLinter and the pre-commit actionlint hook red. Upstream tracks this in rhysd/actionlint#654 and #657; the PR adding support (#661) was closed unmerged, and v1.7.12 — the latest release, and the version pinned in .pre-commit-config.yaml — still rejects it. Without the suppression every future nightly regen lands red, so it ships here rather than as a separate PR that this one would have to wait on.

The ignore is scoped to .github/workflows/tend-*.yaml and to that one message. Verified locally with actionlint v1.7.12: the whole workflow directory lints clean with the entry, and adding an unrelated bogus key to the same concurrency: block still errors, so the suppression isn't swallowing real problems.

[prql-bot]

pre-commit.ci is red on this head, and it won't clear on its own.

actionlint rejects queue: max. The new concurrency.queue key in tend-review.yaml is valid GitHub syntax (docs), but actionlint's schema doesn't know it yet, so the pinned v1.7.12 hook fails the run:

.github/workflows/tend-review.yaml:22:7: unexpected key "queue" for "concurrency" section. expected one of "cancel-in-progress", "group" [syntax-check]

Waiting for an autoupdate won't help: v1.7.12 (2026-03-30) is the latest release, rhysd/actionlint#657 and #654 are both open, and the PR that added support (#661) was closed unmerged.

Fix — tend's own repo already hit this and carries the remedy in its .pre-commit-config.yaml; mirroring it here is enough:

 - repo: https://github.com/rhysd/actionlintrev: v1.7.12hooks:
- id: actionlint# GitHub accepts concurrency.queue, but this pin does not yet know it.# Ignore only that schema false positive.args:
- -ignore
- 'unexpected key "queue" for "concurrency" section'

I verified this against actionlint v1.7.12 on the merged tree: the whole .github/workflows/ set exits 0 with the flag and reports only the queue diagnostic without it, so nothing else is being suppressed. .pre-commit-config.yaml is outside this diff, so it needs a commit rather than a suggestion.

Separately, this looks like an upstream gap rather than a PRQL one — the generator emits queue: max into every adopter's workflows, but the -ignore arg only exists in tend's own pre-commit config, so any adopter running the actionlint hook goes red on the next regen. Worth an issue on max-sixty/tend.

Overlaps with #6251. That PR regenerates the same eight tend-*.yaml files to add sandbox_setup: blocks, and those blocks sit in the with: mapping directly under the uses: max-sixty/tend/claude@… line this PR bumps — so the two will conflict. Whichever lands second should be regenerated with uvx tend init rather than hand-merged, particularly since 0.1.22 changes how block prompts are padded (max-sixty/tend#1090), which is exactly the rendering #6251 depends on.

[prql-bot]

Fixed in 8a41d64, and the remedy is broader than the one my review proposed. Two checks were red on this head, not one — pre-commit.ci - pr and lint-megalinter / MegaLinter — on the same diagnostic. MegaLinter runs actionlint through its own ACTION_ACTIONLINT descriptor, so the -ignore hook arg I suggested for .pre-commit-config.yaml would have cleared pre-commit.ci and left MegaLinter red. The paths/ignore block in .github/actionlint.yaml that landed instead is read by the binary itself, so it covers both runners and any direct CLI call, and it's scoped to .github/workflows/tend-*.yaml so a schema typo in a hand-written workflow still fails.

The upstream gap is filed as max-sixty/tend#1094 — the generator emits queue: max for every adopter, but the suppression only exists in tend's own pre-commit config, so each adopter hits this on their next regen.

Verification and sources

Against the actionlint v1.7.12 release binary (linux_amd64) on this branch:

• no config change → .github/workflows/tend-review.yaml:22:7: unexpected key "queue" for "concurrency" section. expected one of "cancel-in-progress", "group" [syntax-check]
• with the block in 8a41d64 → exits 0 over .github/workflows/*.yaml
• negative control: an injected bogus-top-level-key: true in tend-review.yaml still fails with the block in place, so the ignore isn't swallowing other diagnostics

MegaLinter's failure was the same single blocking diagnostic — run 33297574559 reports Linted [ACTION] files with [actionlint]: Found 1 error(s); everything else it flagged (jscpd, shellcheck, cpplint) is already under DISABLE_ERRORS_LINTERS in .mega-linter.yaml. check-ok-to-merge was red as a consequence of those two.

Upstream state, rechecked: v1.7.12 (2026-03-30) is still the latest release; rhysd/actionlint#657 (issue) and #654 (PR) are open; #661 was closed unmerged. My review called #654 an issue — it's a PR.

[prql-bot]

Nightly regeneration of the tend-* workflow files via uvx tend@latest init. Beyond the action-ref bumps, this release reworks the tend-notifications pre-check and removes the tend-review HEAD gate — both are inlined shell in the generated workflows, so they show up as real diff rather than a version stamp.

tend version: 0.1.20 → 0.1.22

Notable changes

• tend-notifications: the pre-check is rewritten around a repository-level recovery queue — it enables repo watching idempotently each cycle, pages the whole unread list at a 10-minute cutoff, and passes that cutoff to the agent, replacing the old layered mark-read sweep (fix(notifications): recover missed work from unread queue max-sixty/tend#1074). The job also gains a serial concurrency group.
• tend-review: the "Skip when the live HEAD is already examined" gate step is gone. A push mid-review now re-targets the running review instead of letting the queued run exit, and the concurrency group gains queue: max so a push can't evict a pending ready_for_review event (Re-target a review when HEAD moves, instead of discarding it max-sixty/tend#1082, Make Tend review runs less visible max-sixty/tend#1078).
• Skills now check the default branch for an already-landed fix before opening a PR (skills: check the default branch for a landed fix before opening a PR max-sixty/tend#1070), and review-runs adds a run census as a second input when draining stranded triggers (skills(review-runs): add the run census as a second stranded-trigger drain input max-sixty/tend#1073).
• Generator: watched_workflows and branches are validated as string lists (fix(generator): validate watched_workflows and branches as string lists max-sixty/tend#1076), and block prompts no longer get padded blank lines (fix(generator): stop padding blank lines inside block prompts max-sixty/tend#1090).
• Bundled scripts: fail fast when a commit can't be resolved (fix(scripts): fail fast when a commit cannot be resolved max-sixty/tend#1055), and tend-review no longer gates the check poll (fix(scripts): don't let tend-review gate the poll max-sixty/tend#1053).

Full upstream diff: max-sixty/tend@0.1.20...0.1.22

---

Also in this PR: an .github/actionlint.yaml entry for the concurrency.queue key.

0.1.22's tend-review.yaml uses queue: max, a real GitHub concurrency key that actionlint does not recognise — it fails with unexpected key "queue" for "concurrency" section, turning both MegaLinter and the pre-commit actionlint hook red. Upstream tracks this in rhysd/actionlint#654 and #657; the PR adding support (#661) was closed unmerged, and v1.7.12 — the latest release, and the version pinned in .pre-commit-config.yaml — still rejects it. Without the suppression every future nightly regen lands red, so it ships here rather than as a separate PR that this one would have to wait on.

The ignore is scoped to .github/workflows/tend-*.yaml and to that one message. Verified locally with actionlint v1.7.12: the whole workflow directory lints clean with the entry, and adding an unrelated bogus key to the same concurrency: block still errors, so the suppression isn't swallowing real problems.

[prql-bot]

pre-commit.ci is red on this head, and it won't clear on its own.

actionlint rejects queue: max. The new concurrency.queue key in tend-review.yaml is valid GitHub syntax (docs), but actionlint's schema doesn't know it yet, so the pinned v1.7.12 hook fails the run:

.github/workflows/tend-review.yaml:22:7: unexpected key "queue" for "concurrency" section. expected one of "cancel-in-progress", "group" [syntax-check]

Waiting for an autoupdate won't help: v1.7.12 (2026-03-30) is the latest release, rhysd/actionlint#657 and #654 are both open, and the PR that added support (#661) was closed unmerged.

Fix — tend's own repo already hit this and carries the remedy in its .pre-commit-config.yaml; mirroring it here is enough:

 - repo: https://github.com/rhysd/actionlintrev: v1.7.12hooks:
- id: actionlint# GitHub accepts concurrency.queue, but this pin does not yet know it.# Ignore only that schema false positive.args:
- -ignore
- 'unexpected key "queue" for "concurrency" section'

I verified this against actionlint v1.7.12 on the merged tree: the whole .github/workflows/ set exits 0 with the flag and reports only the queue diagnostic without it, so nothing else is being suppressed. .pre-commit-config.yaml is outside this diff, so it needs a commit rather than a suggestion.

Separately, this looks like an upstream gap rather than a PRQL one — the generator emits queue: max into every adopter's workflows, but the -ignore arg only exists in tend's own pre-commit config, so any adopter running the actionlint hook goes red on the next regen. Worth an issue on max-sixty/tend.

Overlaps with #6251. That PR regenerates the same eight tend-*.yaml files to add sandbox_setup: blocks, and those blocks sit in the with: mapping directly under the uses: max-sixty/tend/claude@… line this PR bumps — so the two will conflict. Whichever lands second should be regenerated with uvx tend init rather than hand-merged, particularly since 0.1.22 changes how block prompts are padded (max-sixty/tend#1090), which is exactly the rendering #6251 depends on.

[prql-bot]

Fixed in 8a41d64, and the remedy is broader than the one my review proposed. Two checks were red on this head, not one — pre-commit.ci - pr and lint-megalinter / MegaLinter — on the same diagnostic. MegaLinter runs actionlint through its own ACTION_ACTIONLINT descriptor, so the -ignore hook arg I suggested for .pre-commit-config.yaml would have cleared pre-commit.ci and left MegaLinter red. The paths/ignore block in .github/actionlint.yaml that landed instead is read by the binary itself, so it covers both runners and any direct CLI call, and it's scoped to .github/workflows/tend-*.yaml so a schema typo in a hand-written workflow still fails.

The upstream gap is filed as max-sixty/tend#1094 — the generator emits queue: max for every adopter, but the suppression only exists in tend's own pre-commit config, so each adopter hits this on their next regen.

Verification and sources

Against the actionlint v1.7.12 release binary (linux_amd64) on this branch:

• no config change → .github/workflows/tend-review.yaml:22:7: unexpected key "queue" for "concurrency" section. expected one of "cancel-in-progress", "group" [syntax-check]
• with the block in 8a41d64 → exits 0 over .github/workflows/*.yaml
• negative control: an injected bogus-top-level-key: true in tend-review.yaml still fails with the block in place, so the ignore isn't swallowing other diagnostics

MegaLinter's failure was the same single blocking diagnostic — run 33297574559 reports Linted [ACTION] files with [actionlint]: Found 1 error(s); everything else it flagged (jscpd, shellcheck, cpplint) is already under DISABLE_ERRORS_LINTERS in .mega-linter.yaml. check-ok-to-merge was red as a consequence of those two.

Upstream state, rechecked: v1.7.12 (2026-03-30) is still the latest release; rhysd/actionlint#657 (issue) and #654 (PR) are open; #661 was closed unmerged. My review called #654 an issue — it's a PR.

[prql-bot]

Nightly regeneration of the tend-* workflow files via uvx tend@latest init. Beyond the action-ref bumps, this release reworks the tend-notifications pre-check and removes the tend-review HEAD gate — both are inlined shell in the generated workflows, so they show up as real diff rather than a version stamp.

tend version: 0.1.20 → 0.1.22

Notable changes

• tend-notifications: the pre-check is rewritten around a repository-level recovery queue — it enables repo watching idempotently each cycle, pages the whole unread list at a 10-minute cutoff, and passes that cutoff to the agent, replacing the old layered mark-read sweep (fix(notifications): recover missed work from unread queue max-sixty/tend#1074). The job also gains a serial concurrency group.
• tend-review: the "Skip when the live HEAD is already examined" gate step is gone. A push mid-review now re-targets the running review instead of letting the queued run exit, and the concurrency group gains queue: max so a push can't evict a pending ready_for_review event (Re-target a review when HEAD moves, instead of discarding it max-sixty/tend#1082, Make Tend review runs less visible max-sixty/tend#1078).
• Skills now check the default branch for an already-landed fix before opening a PR (skills: check the default branch for a landed fix before opening a PR max-sixty/tend#1070), and review-runs adds a run census as a second input when draining stranded triggers (skills(review-runs): add the run census as a second stranded-trigger drain input max-sixty/tend#1073).
• Generator: watched_workflows and branches are validated as string lists (fix(generator): validate watched_workflows and branches as string lists max-sixty/tend#1076), and block prompts no longer get padded blank lines (fix(generator): stop padding blank lines inside block prompts max-sixty/tend#1090).
• Bundled scripts: fail fast when a commit can't be resolved (fix(scripts): fail fast when a commit cannot be resolved max-sixty/tend#1055), and tend-review no longer gates the check poll (fix(scripts): don't let tend-review gate the poll max-sixty/tend#1053).

Full upstream diff: max-sixty/tend@0.1.20...0.1.22

---

Also in this PR: an .github/actionlint.yaml entry for the concurrency.queue key.

0.1.22's tend-review.yaml uses queue: max, a real GitHub concurrency key that actionlint does not recognise — it fails with unexpected key "queue" for "concurrency" section, turning both MegaLinter and the pre-commit actionlint hook red. Upstream tracks this in rhysd/actionlint#654 and #657; the PR adding support (#661) was closed unmerged, and v1.7.12 — the latest release, and the version pinned in .pre-commit-config.yaml — still rejects it. Without the suppression every future nightly regen lands red, so it ships here rather than as a separate PR that this one would have to wait on.

The ignore is scoped to .github/workflows/tend-*.yaml and to that one message. Verified locally with actionlint v1.7.12: the whole workflow directory lints clean with the entry, and adding an unrelated bogus key to the same concurrency: block still errors, so the suppression isn't swallowing real problems.

[prql-bot]

pre-commit.ci is red on this head, and it won't clear on its own.

actionlint rejects queue: max. The new concurrency.queue key in tend-review.yaml is valid GitHub syntax (docs), but actionlint's schema doesn't know it yet, so the pinned v1.7.12 hook fails the run:

.github/workflows/tend-review.yaml:22:7: unexpected key "queue" for "concurrency" section. expected one of "cancel-in-progress", "group" [syntax-check]

Waiting for an autoupdate won't help: v1.7.12 (2026-03-30) is the latest release, rhysd/actionlint#657 and #654 are both open, and the PR that added support (#661) was closed unmerged.

Fix — tend's own repo already hit this and carries the remedy in its .pre-commit-config.yaml; mirroring it here is enough:

 - repo: https://github.com/rhysd/actionlintrev: v1.7.12hooks:
- id: actionlint# GitHub accepts concurrency.queue, but this pin does not yet know it.# Ignore only that schema false positive.args:
- -ignore
- 'unexpected key "queue" for "concurrency" section'

I verified this against actionlint v1.7.12 on the merged tree: the whole .github/workflows/ set exits 0 with the flag and reports only the queue diagnostic without it, so nothing else is being suppressed. .pre-commit-config.yaml is outside this diff, so it needs a commit rather than a suggestion.

Separately, this looks like an upstream gap rather than a PRQL one — the generator emits queue: max into every adopter's workflows, but the -ignore arg only exists in tend's own pre-commit config, so any adopter running the actionlint hook goes red on the next regen. Worth an issue on max-sixty/tend.

Overlaps with #6251. That PR regenerates the same eight tend-*.yaml files to add sandbox_setup: blocks, and those blocks sit in the with: mapping directly under the uses: max-sixty/tend/claude@… line this PR bumps — so the two will conflict. Whichever lands second should be regenerated with uvx tend init rather than hand-merged, particularly since 0.1.22 changes how block prompts are padded (max-sixty/tend#1090), which is exactly the rendering #6251 depends on.

[prql-bot]

Fixed in 8a41d64, and the remedy is broader than the one my review proposed. Two checks were red on this head, not one — pre-commit.ci - pr and lint-megalinter / MegaLinter — on the same diagnostic. MegaLinter runs actionlint through its own ACTION_ACTIONLINT descriptor, so the -ignore hook arg I suggested for .pre-commit-config.yaml would have cleared pre-commit.ci and left MegaLinter red. The paths/ignore block in .github/actionlint.yaml that landed instead is read by the binary itself, so it covers both runners and any direct CLI call, and it's scoped to .github/workflows/tend-*.yaml so a schema typo in a hand-written workflow still fails.

The upstream gap is filed as max-sixty/tend#1094 — the generator emits queue: max for every adopter, but the suppression only exists in tend's own pre-commit config, so each adopter hits this on their next regen.

Verification and sources

Against the actionlint v1.7.12 release binary (linux_amd64) on this branch:

• no config change → .github/workflows/tend-review.yaml:22:7: unexpected key "queue" for "concurrency" section. expected one of "cancel-in-progress", "group" [syntax-check]
• with the block in 8a41d64 → exits 0 over .github/workflows/*.yaml
• negative control: an injected bogus-top-level-key: true in tend-review.yaml still fails with the block in place, so the ignore isn't swallowing other diagnostics

MegaLinter's failure was the same single blocking diagnostic — run 33297574559 reports Linted [ACTION] files with [actionlint]: Found 1 error(s); everything else it flagged (jscpd, shellcheck, cpplint) is already under DISABLE_ERRORS_LINTERS in .mega-linter.yaml. check-ok-to-merge was red as a consequence of those two.

Upstream state, rechecked: v1.7.12 (2026-03-30) is still the latest release; rhysd/actionlint#657 (issue) and #654 (PR) are open; #661 was closed unmerged. My review called #654 an issue — it's a PR.

[prql-bot]

Nightly regeneration of the tend-* workflow files via uvx tend@latest init. Beyond the action-ref bumps, this release reworks the tend-notifications pre-check and removes the tend-review HEAD gate — both are inlined shell in the generated workflows, so they show up as real diff rather than a version stamp.

tend version: 0.1.20 → 0.1.22

Notable changes

• tend-notifications: the pre-check is rewritten around a repository-level recovery queue — it enables repo watching idempotently each cycle, pages the whole unread list at a 10-minute cutoff, and passes that cutoff to the agent, replacing the old layered mark-read sweep (fix(notifications): recover missed work from unread queue max-sixty/tend#1074). The job also gains a serial concurrency group.
• tend-review: the "Skip when the live HEAD is already examined" gate step is gone. A push mid-review now re-targets the running review instead of letting the queued run exit, and the concurrency group gains queue: max so a push can't evict a pending ready_for_review event (Re-target a review when HEAD moves, instead of discarding it max-sixty/tend#1082, Make Tend review runs less visible max-sixty/tend#1078).
• Skills now check the default branch for an already-landed fix before opening a PR (skills: check the default branch for a landed fix before opening a PR max-sixty/tend#1070), and review-runs adds a run census as a second input when draining stranded triggers (skills(review-runs): add the run census as a second stranded-trigger drain input max-sixty/tend#1073).
• Generator: watched_workflows and branches are validated as string lists (fix(generator): validate watched_workflows and branches as string lists max-sixty/tend#1076), and block prompts no longer get padded blank lines (fix(generator): stop padding blank lines inside block prompts max-sixty/tend#1090).
• Bundled scripts: fail fast when a commit can't be resolved (fix(scripts): fail fast when a commit cannot be resolved max-sixty/tend#1055), and tend-review no longer gates the check poll (fix(scripts): don't let tend-review gate the poll max-sixty/tend#1053).

Full upstream diff: max-sixty/tend@0.1.20...0.1.22

---

Also in this PR: an .github/actionlint.yaml entry for the concurrency.queue key.

0.1.22's tend-review.yaml uses queue: max, a real GitHub concurrency key that actionlint does not recognise — it fails with unexpected key "queue" for "concurrency" section, turning both MegaLinter and the pre-commit actionlint hook red. Upstream tracks this in rhysd/actionlint#654 and #657; the PR adding support (#661) was closed unmerged, and v1.7.12 — the latest release, and the version pinned in .pre-commit-config.yaml — still rejects it. Without the suppression every future nightly regen lands red, so it ships here rather than as a separate PR that this one would have to wait on.

The ignore is scoped to .github/workflows/tend-*.yaml and to that one message. Verified locally with actionlint v1.7.12: the whole workflow directory lints clean with the entry, and adding an unrelated bogus key to the same concurrency: block still errors, so the suppression isn't swallowing real problems.

[prql-bot]

pre-commit.ci is red on this head, and it won't clear on its own.

actionlint rejects queue: max. The new concurrency.queue key in tend-review.yaml is valid GitHub syntax (docs), but actionlint's schema doesn't know it yet, so the pinned v1.7.12 hook fails the run:

.github/workflows/tend-review.yaml:22:7: unexpected key "queue" for "concurrency" section. expected one of "cancel-in-progress", "group" [syntax-check]

Waiting for an autoupdate won't help: v1.7.12 (2026-03-30) is the latest release, rhysd/actionlint#657 and #654 are both open, and the PR that added support (#661) was closed unmerged.

Fix — tend's own repo already hit this and carries the remedy in its .pre-commit-config.yaml; mirroring it here is enough:

 - repo: https://github.com/rhysd/actionlintrev: v1.7.12hooks:
- id: actionlint# GitHub accepts concurrency.queue, but this pin does not yet know it.# Ignore only that schema false positive.args:
- -ignore
- 'unexpected key "queue" for "concurrency" section'

I verified this against actionlint v1.7.12 on the merged tree: the whole .github/workflows/ set exits 0 with the flag and reports only the queue diagnostic without it, so nothing else is being suppressed. .pre-commit-config.yaml is outside this diff, so it needs a commit rather than a suggestion.

Separately, this looks like an upstream gap rather than a PRQL one — the generator emits queue: max into every adopter's workflows, but the -ignore arg only exists in tend's own pre-commit config, so any adopter running the actionlint hook goes red on the next regen. Worth an issue on max-sixty/tend.

Overlaps with #6251. That PR regenerates the same eight tend-*.yaml files to add sandbox_setup: blocks, and those blocks sit in the with: mapping directly under the uses: max-sixty/tend/claude@… line this PR bumps — so the two will conflict. Whichever lands second should be regenerated with uvx tend init rather than hand-merged, particularly since 0.1.22 changes how block prompts are padded (max-sixty/tend#1090), which is exactly the rendering #6251 depends on.

[prql-bot]

Fixed in 8a41d64, and the remedy is broader than the one my review proposed. Two checks were red on this head, not one — pre-commit.ci - pr and lint-megalinter / MegaLinter — on the same diagnostic. MegaLinter runs actionlint through its own ACTION_ACTIONLINT descriptor, so the -ignore hook arg I suggested for .pre-commit-config.yaml would have cleared pre-commit.ci and left MegaLinter red. The paths/ignore block in .github/actionlint.yaml that landed instead is read by the binary itself, so it covers both runners and any direct CLI call, and it's scoped to .github/workflows/tend-*.yaml so a schema typo in a hand-written workflow still fails.

The upstream gap is filed as max-sixty/tend#1094 — the generator emits queue: max for every adopter, but the suppression only exists in tend's own pre-commit config, so each adopter hits this on their next regen.

Verification and sources

Against the actionlint v1.7.12 release binary (linux_amd64) on this branch:

• no config change → .github/workflows/tend-review.yaml:22:7: unexpected key "queue" for "concurrency" section. expected one of "cancel-in-progress", "group" [syntax-check]
• with the block in 8a41d64 → exits 0 over .github/workflows/*.yaml
• negative control: an injected bogus-top-level-key: true in tend-review.yaml still fails with the block in place, so the ignore isn't swallowing other diagnostics

MegaLinter's failure was the same single blocking diagnostic — run 33297574559 reports Linted [ACTION] files with [actionlint]: Found 1 error(s); everything else it flagged (jscpd, shellcheck, cpplint) is already under DISABLE_ERRORS_LINTERS in .mega-linter.yaml. check-ok-to-merge was red as a consequence of those two.

Upstream state, rechecked: v1.7.12 (2026-03-30) is still the latest release; rhysd/actionlint#657 (issue) and #654 (PR) are open; #661 was closed unmerged. My review called #654 an issue — it's a PR.

[prql-bot]

Nightly regeneration of the tend-* workflow files via uvx tend@latest init. Beyond the action-ref bumps, this release reworks the tend-notifications pre-check and removes the tend-review HEAD gate — both are inlined shell in the generated workflows, so they show up as real diff rather than a version stamp.

tend version: 0.1.20 → 0.1.22

Notable changes

• tend-notifications: the pre-check is rewritten around a repository-level recovery queue — it enables repo watching idempotently each cycle, pages the whole unread list at a 10-minute cutoff, and passes that cutoff to the agent, replacing the old layered mark-read sweep (fix(notifications): recover missed work from unread queue max-sixty/tend#1074). The job also gains a serial concurrency group.
• tend-review: the "Skip when the live HEAD is already examined" gate step is gone. A push mid-review now re-targets the running review instead of letting the queued run exit, and the concurrency group gains queue: max so a push can't evict a pending ready_for_review event (Re-target a review when HEAD moves, instead of discarding it max-sixty/tend#1082, Make Tend review runs less visible max-sixty/tend#1078).
• Skills now check the default branch for an already-landed fix before opening a PR (skills: check the default branch for a landed fix before opening a PR max-sixty/tend#1070), and review-runs adds a run census as a second input when draining stranded triggers (skills(review-runs): add the run census as a second stranded-trigger drain input max-sixty/tend#1073).
• Generator: watched_workflows and branches are validated as string lists (fix(generator): validate watched_workflows and branches as string lists max-sixty/tend#1076), and block prompts no longer get padded blank lines (fix(generator): stop padding blank lines inside block prompts max-sixty/tend#1090).
• Bundled scripts: fail fast when a commit can't be resolved (fix(scripts): fail fast when a commit cannot be resolved max-sixty/tend#1055), and tend-review no longer gates the check poll (fix(scripts): don't let tend-review gate the poll max-sixty/tend#1053).

Full upstream diff: max-sixty/tend@0.1.20...0.1.22

---

Also in this PR: an .github/actionlint.yaml entry for the concurrency.queue key.

0.1.22's tend-review.yaml uses queue: max, a real GitHub concurrency key that actionlint does not recognise — it fails with unexpected key "queue" for "concurrency" section, turning both MegaLinter and the pre-commit actionlint hook red. Upstream tracks this in rhysd/actionlint#654 and #657; the PR adding support (#661) was closed unmerged, and v1.7.12 — the latest release, and the version pinned in .pre-commit-config.yaml — still rejects it. Without the suppression every future nightly regen lands red, so it ships here rather than as a separate PR that this one would have to wait on.

The ignore is scoped to .github/workflows/tend-*.yaml and to that one message. Verified locally with actionlint v1.7.12: the whole workflow directory lints clean with the entry, and adding an unrelated bogus key to the same concurrency: block still errors, so the suppression isn't swallowing real problems.

[prql-bot]

pre-commit.ci is red on this head, and it won't clear on its own.

actionlint rejects queue: max. The new concurrency.queue key in tend-review.yaml is valid GitHub syntax (docs), but actionlint's schema doesn't know it yet, so the pinned v1.7.12 hook fails the run:

.github/workflows/tend-review.yaml:22:7: unexpected key "queue" for "concurrency" section. expected one of "cancel-in-progress", "group" [syntax-check]

Waiting for an autoupdate won't help: v1.7.12 (2026-03-30) is the latest release, rhysd/actionlint#657 and #654 are both open, and the PR that added support (#661) was closed unmerged.

Fix — tend's own repo already hit this and carries the remedy in its .pre-commit-config.yaml; mirroring it here is enough:

 - repo: https://github.com/rhysd/actionlintrev: v1.7.12hooks:
- id: actionlint# GitHub accepts concurrency.queue, but this pin does not yet know it.# Ignore only that schema false positive.args:
- -ignore
- 'unexpected key "queue" for "concurrency" section'

I verified this against actionlint v1.7.12 on the merged tree: the whole .github/workflows/ set exits 0 with the flag and reports only the queue diagnostic without it, so nothing else is being suppressed. .pre-commit-config.yaml is outside this diff, so it needs a commit rather than a suggestion.

Separately, this looks like an upstream gap rather than a PRQL one — the generator emits queue: max into every adopter's workflows, but the -ignore arg only exists in tend's own pre-commit config, so any adopter running the actionlint hook goes red on the next regen. Worth an issue on max-sixty/tend.

Overlaps with #6251. That PR regenerates the same eight tend-*.yaml files to add sandbox_setup: blocks, and those blocks sit in the with: mapping directly under the uses: max-sixty/tend/claude@… line this PR bumps — so the two will conflict. Whichever lands second should be regenerated with uvx tend init rather than hand-merged, particularly since 0.1.22 changes how block prompts are padded (max-sixty/tend#1090), which is exactly the rendering #6251 depends on.

[prql-bot]

Fixed in 8a41d64, and the remedy is broader than the one my review proposed. Two checks were red on this head, not one — pre-commit.ci - pr and lint-megalinter / MegaLinter — on the same diagnostic. MegaLinter runs actionlint through its own ACTION_ACTIONLINT descriptor, so the -ignore hook arg I suggested for .pre-commit-config.yaml would have cleared pre-commit.ci and left MegaLinter red. The paths/ignore block in .github/actionlint.yaml that landed instead is read by the binary itself, so it covers both runners and any direct CLI call, and it's scoped to .github/workflows/tend-*.yaml so a schema typo in a hand-written workflow still fails.

The upstream gap is filed as max-sixty/tend#1094 — the generator emits queue: max for every adopter, but the suppression only exists in tend's own pre-commit config, so each adopter hits this on their next regen.

Verification and sources

Against the actionlint v1.7.12 release binary (linux_amd64) on this branch:

• no config change → .github/workflows/tend-review.yaml:22:7: unexpected key "queue" for "concurrency" section. expected one of "cancel-in-progress", "group" [syntax-check]
• with the block in 8a41d64 → exits 0 over .github/workflows/*.yaml
• negative control: an injected bogus-top-level-key: true in tend-review.yaml still fails with the block in place, so the ignore isn't swallowing other diagnostics

MegaLinter's failure was the same single blocking diagnostic — run 33297574559 reports Linted [ACTION] files with [actionlint]: Found 1 error(s); everything else it flagged (jscpd, shellcheck, cpplint) is already under DISABLE_ERRORS_LINTERS in .mega-linter.yaml. check-ok-to-merge was red as a consequence of those two.

Upstream state, rechecked: v1.7.12 (2026-03-30) is still the latest release; rhysd/actionlint#657 (issue) and #654 (PR) are open; #661 was closed unmerged. My review called #654 an issue — it's a PR.

[prql-bot]

Nightly regeneration of the tend-* workflow files via uvx tend@latest init. Beyond the action-ref bumps, this release reworks the tend-notifications pre-check and removes the tend-review HEAD gate — both are inlined shell in the generated workflows, so they show up as real diff rather than a version stamp.

tend version: 0.1.20 → 0.1.22

Notable changes

• tend-notifications: the pre-check is rewritten around a repository-level recovery queue — it enables repo watching idempotently each cycle, pages the whole unread list at a 10-minute cutoff, and passes that cutoff to the agent, replacing the old layered mark-read sweep (fix(notifications): recover missed work from unread queue max-sixty/tend#1074). The job also gains a serial concurrency group.
• tend-review: the "Skip when the live HEAD is already examined" gate step is gone. A push mid-review now re-targets the running review instead of letting the queued run exit, and the concurrency group gains queue: max so a push can't evict a pending ready_for_review event (Re-target a review when HEAD moves, instead of discarding it max-sixty/tend#1082, Make Tend review runs less visible max-sixty/tend#1078).
• Skills now check the default branch for an already-landed fix before opening a PR (skills: check the default branch for a landed fix before opening a PR max-sixty/tend#1070), and review-runs adds a run census as a second input when draining stranded triggers (skills(review-runs): add the run census as a second stranded-trigger drain input max-sixty/tend#1073).
• Generator: watched_workflows and branches are validated as string lists (fix(generator): validate watched_workflows and branches as string lists max-sixty/tend#1076), and block prompts no longer get padded blank lines (fix(generator): stop padding blank lines inside block prompts max-sixty/tend#1090).
• Bundled scripts: fail fast when a commit can't be resolved (fix(scripts): fail fast when a commit cannot be resolved max-sixty/tend#1055), and tend-review no longer gates the check poll (fix(scripts): don't let tend-review gate the poll max-sixty/tend#1053).

Full upstream diff: max-sixty/tend@0.1.20...0.1.22

---

Also in this PR: an .github/actionlint.yaml entry for the concurrency.queue key.

0.1.22's tend-review.yaml uses queue: max, a real GitHub concurrency key that actionlint does not recognise — it fails with unexpected key "queue" for "concurrency" section, turning both MegaLinter and the pre-commit actionlint hook red. Upstream tracks this in rhysd/actionlint#654 and #657; the PR adding support (#661) was closed unmerged, and v1.7.12 — the latest release, and the version pinned in .pre-commit-config.yaml — still rejects it. Without the suppression every future nightly regen lands red, so it ships here rather than as a separate PR that this one would have to wait on.

The ignore is scoped to .github/workflows/tend-*.yaml and to that one message. Verified locally with actionlint v1.7.12: the whole workflow directory lints clean with the entry, and adding an unrelated bogus key to the same concurrency: block still errors, so the suppression isn't swallowing real problems.

[prql-bot]

pre-commit.ci is red on this head, and it won't clear on its own.

actionlint rejects queue: max. The new concurrency.queue key in tend-review.yaml is valid GitHub syntax (docs), but actionlint's schema doesn't know it yet, so the pinned v1.7.12 hook fails the run:

.github/workflows/tend-review.yaml:22:7: unexpected key "queue" for "concurrency" section. expected one of "cancel-in-progress", "group" [syntax-check]

Waiting for an autoupdate won't help: v1.7.12 (2026-03-30) is the latest release, rhysd/actionlint#657 and #654 are both open, and the PR that added support (#661) was closed unmerged.

Fix — tend's own repo already hit this and carries the remedy in its .pre-commit-config.yaml; mirroring it here is enough:

 - repo: https://github.com/rhysd/actionlintrev: v1.7.12hooks:
- id: actionlint# GitHub accepts concurrency.queue, but this pin does not yet know it.# Ignore only that schema false positive.args:
- -ignore
- 'unexpected key "queue" for "concurrency" section'

I verified this against actionlint v1.7.12 on the merged tree: the whole .github/workflows/ set exits 0 with the flag and reports only the queue diagnostic without it, so nothing else is being suppressed. .pre-commit-config.yaml is outside this diff, so it needs a commit rather than a suggestion.

Separately, this looks like an upstream gap rather than a PRQL one — the generator emits queue: max into every adopter's workflows, but the -ignore arg only exists in tend's own pre-commit config, so any adopter running the actionlint hook goes red on the next regen. Worth an issue on max-sixty/tend.

Overlaps with #6251. That PR regenerates the same eight tend-*.yaml files to add sandbox_setup: blocks, and those blocks sit in the with: mapping directly under the uses: max-sixty/tend/claude@… line this PR bumps — so the two will conflict. Whichever lands second should be regenerated with uvx tend init rather than hand-merged, particularly since 0.1.22 changes how block prompts are padded (max-sixty/tend#1090), which is exactly the rendering #6251 depends on.

[prql-bot]

Fixed in 8a41d64, and the remedy is broader than the one my review proposed. Two checks were red on this head, not one — pre-commit.ci - pr and lint-megalinter / MegaLinter — on the same diagnostic. MegaLinter runs actionlint through its own ACTION_ACTIONLINT descriptor, so the -ignore hook arg I suggested for .pre-commit-config.yaml would have cleared pre-commit.ci and left MegaLinter red. The paths/ignore block in .github/actionlint.yaml that landed instead is read by the binary itself, so it covers both runners and any direct CLI call, and it's scoped to .github/workflows/tend-*.yaml so a schema typo in a hand-written workflow still fails.

The upstream gap is filed as max-sixty/tend#1094 — the generator emits queue: max for every adopter, but the suppression only exists in tend's own pre-commit config, so each adopter hits this on their next regen.

Verification and sources

Against the actionlint v1.7.12 release binary (linux_amd64) on this branch:

• no config change → .github/workflows/tend-review.yaml:22:7: unexpected key "queue" for "concurrency" section. expected one of "cancel-in-progress", "group" [syntax-check]
• with the block in 8a41d64 → exits 0 over .github/workflows/*.yaml
• negative control: an injected bogus-top-level-key: true in tend-review.yaml still fails with the block in place, so the ignore isn't swallowing other diagnostics

MegaLinter's failure was the same single blocking diagnostic — run 33297574559 reports Linted [ACTION] files with [actionlint]: Found 1 error(s); everything else it flagged (jscpd, shellcheck, cpplint) is already under DISABLE_ERRORS_LINTERS in .mega-linter.yaml. check-ok-to-merge was red as a consequence of those two.

Upstream state, rechecked: v1.7.12 (2026-03-30) is still the latest release; rhysd/actionlint#657 (issue) and #654 (PR) are open; #661 was closed unmerged. My review called #654 an issue — it's a PR.