[prql-bot]

Automated nightly regeneration of tend's workflow files (uvx tend@latest init).

tend version: 0.1.24 → 0.2.0

Notable changes

• Every generated workflow now gates on an enabled key in .config/tend.yaml — a runtime kill switch that skips checkout, setup, and the agent step without deleting the workflows (max-sixty/tend#1132). The key is absent here, which defaults to enabled, so behavior is unchanged.
• Review sessions now dismiss a standing bot approval when a later review withholds the verdict, and when another PR merging invalidates it (max-sixty/tend#1136, max-sixty/tend#1139).
• tend-ci-fix gets a concurrency group per branch and watched workflow, so concurrent failures on different workflows no longer cancel each other (max-sixty/tend#1148).
• tend-notifications acknowledges each resolved thread individually rather than marking the whole repository read (max-sixty/tend#1121); resolve-conflicts can now use the bot's own commit to unwedge a dependency-bot PR (max-sixty/tend#1140).
• Runner logic moved from Bash and skills into Python, plus new Claude effort/harness arguments and pinned claude_version 2.1.263 / uv 0.12.10 (max-sixty/tend#1158, max-sixty/tend#1161).

Full compare: max-sixty/tend@0.1.24...0.2.0

[prql-bot]

Generated-workflow regen, so the substantive question is fidelity rather than design. I checked it directly: uvx tend==0.2.0 init run against this PR's head (e6ae6b7) leaves a clean working tree — the eight files here are byte-for-byte what the generator emits, with no hand-edits and no stale hunks. 0.2.0 is also the current PyPI release, so @latest and the pinned max-sixty/tend/claude@0.2.0 refs agree.

Two things carry behavior rather than boilerplate, and I exercised both:

The enabled kill switch. .config/tend.yaml has no enabled key, so the gate defaults on — I ran the inlined Ruby against this repo's actual config and it emits enabled=true, meaning every job keeps running exactly as before. The != '0' step conditions in tend-notifications are correctly wrapped rather than left to short-circuit on an empty output, and the always() cleanup steps (eyes-reaction removal, tend-setup restore) can't strand state, since the gate precedes the step that sets it in every file.

The Bash to Python port of the tend-mention and tend-notifications pre-checks. I extracted both scripts and ran them against stubbed gh fixtures. Every decision path matches the shell version it replaces: issues boots, the bot's own comment doesn't, an @-mention boots with reason=mention, an undirected bot comment doesn't, a malformed or unknown dispatch skips quietly, a contentless bot approval on a bot PR skips while the same review with a body boots with reason=participation, and a 404 on the review lookup skips without noise instead of failing red. The notifications check keeps its failure tolerance — with every gh call failing it still emits count=0/conflict_count=0 and exits 0, leaving the queue for the next cycle rather than reddening the job. uv run --script - reads the heredoc from stdin as the workflow expects, and both scripts compile under 3.12.

One observation, upstream-owned rather than actionable here: the gate's gh api .../contents/.config/tend.yaml is unguarded, so a transient contents-API failure fails the step and turns the whole tend job red. That's a new exposure — tend-review's previous first step guarded its call with || echo "::warning::...". It's projected rather than observed, and the fix belongs in the generator since anything written here is overwritten by the next nightly regen, which is also why I haven't left inline suggestions.

[prql-bot]

Routed the one observation from the review upstream, since the fix belongs in the generator: max-sixty/tend#1167 covers the unguarded gh api config fetch in the enabled gate, which fails the whole tend job red on a transient contents-API error instead of degrading. Confirmed it's still unguarded in tend main (7ecee47) and in the generator's own regtest outputs, so it isn't specific to this repo's config.

Nothing to change on this PR — the eight files are byte-for-byte what uvx tend==0.2.0 init emits, and anything patched here would be overwritten by the next nightly regen.