[prql-bot]

Regenerates the tend workflows on 0.2.13, up from the 0.2.11 currently pinned. The diff is only the pinned action version and the setup-uv version it installs (0.12.13 → 0.12.17); no workflow gained or lost a job, trigger or permission.

What the upgrade changes for this repo:

• A cancelled required check no longer reads as green. The poll helper treated a check that completed without a usable conclusion as neither pending nor failed, so it reported "every gating check settled green" over a check that never produced a result — the usual trigger being a second push cancelling the first head's run. Cancelled now lands in an explicit unverified bucket, and the approval path stops approving on it (fix(poll): report a cancelled gating check as unverified, not green max-sixty/tend#1323).
• Fewer runs lost before the agent starts. A transient failure binding the sandbox's bridge sockets took down SandboxManager.initialize with nothing retrying, spending the run at zero turns — the shape behind the "Bot temporarily unavailable" report in Bot temporarily unavailable #6349. The launch now retries past it (fix(sandbox): retry the SRT launch past a transient bridge-socket failure max-sixty/tend#1327).
• The bot's claude.ai account no longer feeds CI sessions. Claude Code syncs the signed-in account's skills, plugins and MCP connectors into terminal sessions, headless included, which made that account an unreviewed instruction and tool source for a process that pushes commits and posts as the bot. Sessions now run without it (fix(claude): keep the bot's claude.ai account out of CI sessions max-sixty/tend#1328).
• /tmp is writable inside the sandbox. Previously only $TMPDIR was, so any tool hard-coding a path under /tmp failed on a read-only filesystem; the runner-owned containers moved to /var/tmp instead (Make /tmp writable inside the sandbox max-sixty/tend#1324).

Also in the range: corrections to run-tend's list of restored instruction paths (max-sixty/tend#1311), ground-claims reading a past run's code at that run's commit rather than at HEAD (max-sixty/tend#1319), and review-runs spotting a workflow wedged behind a run parked in waiting (max-sixty/tend#1320).

0.2.12 ran the agent in the job's own checkout through a copy-on-write view (max-sixty/tend#1333, max-sixty/tend#1334); 0.2.13 reverts it (max-sixty/tend#1339), so this upgrade carries none of it.

Full comparison: max-sixty/tend@0.2.11...0.2.13

[prql-bot]

One consequence worth settling before this merges, because it lands in a different PR: 0.2.13 makes /tmp writable inside the sandbox (max-sixty/tend#1324), and #6345 is a workaround for exactly the failure that fixes.

#6345 pre-creates NuGet's migration marker in sandbox_setup: because NuGet.Common.Migrations.MigrationRunner opens a mutex backed by a hard-coded /tmp path and dies with errno == EROFS. At 0.2.13 /tmp is in the sandbox runtime's allowWrite list, and tend's own changelog entry for #1324 names NuGet's build mutex as the motivating case. So once this lands, the mkdir/touch pair in .config/tend.yaml and the EROFS paragraph in running-tend are dead config describing a constraint that no longer holds — and the MigrationRunner bookkeeping they encode (bump the marker number when a later SDK bumps NuGet's migration count) is maintenance nobody needs to carry.

#6345's other half is unaffected: the -m:1 guidance is about AF_UNIX sockets being refused sandbox-wide, which 0.2.13 doesn't change.

Regeneration check

Regenerated with uvx tend@0.2.13 init against this repo's .config/tend.yaml in a scratch tree: all nine tend-*.yaml files came out byte-identical to this PR's. 0.2.13 is the latest tend release. The eight max-sixty/tend/claude@ pins are all at 0.2.13 and no 0.2.11 or 0.12.13 reference remains anywhere in the repo; tend-mention-relay.yaml correctly has no action pin to bump.

Nothing else in the 0.2.11…0.2.13 range needs a repo-side change: 0.2.12's copy-on-write view (#1333, #1334) is reverted by #1339, so sandbox_setup: keeps 0.2.11's semantics and the existing nextest/insta/pre-commit/toolchain installs are untouched. TMPPREFIX leaving the reserved sandbox_env keys is a no-op here — this repo sets no sandbox_env. No repo file hard-codes a sandbox path that 0.2.12's move of the runner-owned containers to /var/tmp would invalidate.