chore: update tend workflows (0.1.14 → 0.1.15)

[worktrunk-bot]

Automated nightly regeneration of tend's workflow files.

tend version: 0.1.14 → 0.1.15

Notable changes

• Rate-limit handling: a maintainer can approve past the spike limit (feat(rate-limit): let a maintainer approve past the spike limit tend#874), and tend-mention now skips comments on tend-rate-limit-labelled issues as well as tend-outage ones — the same self-trigger loop guard, widened to every issue tend files about its own health.
• Review flow: a push is queued behind an examined-HEAD gate instead of cancelling the in-flight review (feat(review): queue pushes behind an examined-HEAD gate instead of cancelling tend#903), the review is submitted before a fix is pushed (fix(review): submit the review before pushing a fix tend#834), a force-push triggers a re-review rather than trusting the re-anchored SHA (fix(review): re-review after a force-push instead of trusting the re-anchored review SHA tend#884), and the /code-review second pass is unconditional (fix(review): make the code-review second pass unconditional tend#937).
• CI monitoring: both the check poll and the gh run rerun --failed poll now end terminally when the cap is hit instead of reading as done (fix(running-in-ci): make the CI-monitor poll cap terminal tend#876, fix(running-in-ci): make the rerun poll cap terminal, and print conclusions tend#951), and a failed GitHub-status probe no longer reads as "no incident" (fix(running-in-ci): don't let a failed status probe read as no incident tend#913).
• Nightly: conflicted bot PRs are test-merged locally instead of filtered on the lazy mergeable field (fix(nightly): test-merge bot PRs locally instead of filtering the lazy mergeable field tend#898), and mention runs skip the bot's own review and a third party's content-free approval (fix(mention): skip the bot's own review on someone else's PR tend#916, fix(mention): skip a third party's content-free approval tend#955).
• tend check: an unreadable ruleset bypass list is reported as unknown rather than ungated (check: report an unreadable ruleset bypass list as unknown, not ungated tend#825), environment names are read one per line and addressed encoded (fix(check): read environment names one per line, and address them encoded tend#879), and credential-environments no longer points at the setting it rejects (fix(check): stop pointing credential-environments at the setting it rejects tend#900) — this repo currently SKIPs that check, so its wording should improve here.

Full comparison: max-sixty/tend@0.1.14...0.1.15

[worktrunk-bot]

Self-authored, so no approval — recording the verification instead.

Regenerated .config/tend.yaml through uvx tend@0.1.15 init in a scratch checkout and diffed against this branch: all eight files are byte-identical. The diff is purely generator output, with no hand edits or drift carried in.

Traced the two blocks that carry new logic:

• tend-review gate. The tend-review/<pr> stamp the gate reads is written by 0.1.15's review skill (step 9, "Stamp examined HEADs"), so cancel-in-progress: false and the gate land together rather than leaving the gate reading a status nothing produces. Every failure path in the gate falls open — a gh error, an HTML-body-with-200 blip that breaks the jq parse, or a garbage STAMPED value all end at should_run=true, so a bad API moment costs a redundant agent boot rather than a silently skipped review. Skipping the pre-check for opened/reopened/ready_for_review is right: none of those can be a stale duplicate.
• tend-mention self-review skips. Ordering holds the design the comments claim — the new REVIEW_AUTHOR = worktrunk-bot gate sits after the PR_AUTHOR short-circuit, so the reviewer-to-author handoff on a bot-authored PR still fires (this run is that path), and after both @-mention scans, so an explicit summons still wins. The {body, in_reply_to_id} construction is load-bearing as documented: in_reply_to_id is absent rather than null on a fresh inline comment, and the object build normalizes it so the == null count sees both shapes.

Nothing to flag on the data-safety surface — the one new destructive-looking line, git checkout "$GITHUB_SHA" -- .github/actions/claude-setup, only restores a path inside the runner workspace and guards its own failure with a warning.

[worktrunk-bot]

Adding measurement from today's review-runs sweep (24h to 2026-08-13T08:13Z, 155 completed tend runs, zero failures). The body's change list is accurate but doesn't mention four fixes this repo's own sweep log (#3691) has been carrying as open watches — max-sixty/tend#849, max-sixty/tend#851, max-sixty/tend#870, max-sixty/tend#873 — all of which land in 0.1.15. Two of them fired again in this window, and I measured both rather than asserting them.

max-sixty/tend#873 — cancelled sessions accounted as $0. Three tend-review runs were cancelled mid-flight this window. Each has a token-usage.json reading {"input_tokens":0,"output_tokens":0,...,"cost_usd":0}, and each ships a session JSONL in the same artifact recording real work: 28, 13, and 19 turns. token-report.sh therefore priced this window at $102.77 when the true figure is ~$109.04 — a 5.7% undercount, and the bias scales with push cadence rather than being constant. That matters because the per-window cost line is one of the axes the sweep compares days along, and it fed the arithmetic in #3803.

max-sixty/tend#876 — the CI-monitor poll cap wasn't terminal. Run 31649362807 (tend-mention, the fix pls on #3795) ran 62 minutes. It pushed the fix at minute 5 and commented at minute 6 — deliverable visible — then spent 36 minutes across four re-armed 9-iteration loops polling a single job, every iteration returning in_progress. Every other check on 644a9ba28 had been green since 23:24:45Z; the sole outstanding item was feature-powerset from the nightly workflow, which finished at 00:16:15Z, 51 minutes after the next-slowest check. tend#876 names worktrunk's feature-powerset as its motivating case, so this is the exact scenario it closes.

Neither is a reason to change anything here — both fixes are already in 0.1.15, which is what this PR pins. Recording the numbers so the bump reads as closing measured gaps rather than as routine regeneration.

Method and figures

Cancelled-run usage recovered from each artifact's session JSONL. The JSONL emits one record per content block, so assistant records must be deduplicated by message.id before summing — that method reproduces token-usage.json byte-exactly on a completed run (31649362807: 13,433 output / 86,436 cache-create / 3,081,555 cache-read, matching its token-usage.json field for field), which is what makes it trustworthy on a cancelled one.

Run	Target	Job time	Turns	Output	Cache-create	Cache-read	Reported	Actual
31644930286	#3808	16m	28	22,436	61,456	2,728,404	$0.00	~$2.54
31642050749	#3810	6m	13	21,218	83,792	1,006,582	$0.00	~$1.87
31675695809	#3813	5m	19	11,021	80,030	1,555,570	$0.00	~$1.85

Each ran on an assigned runner with 11 steps and uploaded an artifact, so these are real sessions, not runs displaced before a runner was allocated.

The dollar figures use a rate model fitted by least squares against the window's 58 priced runs — output $25.03/M, cache-create $10.01/M, cache-read $0.50/M — which reproduces every one of those 58 reported costs to within $0.005. They are API-list-price proxies, not a bill.

Poll timeline for 31649362807, from its session JSONL: push 23:08:10Z, comment 23:09:02Z, then poll loops at 23:09→23:18 (pending 20→9), 23:18→23:27 (9→2), and four consecutive loops 23:27→00:04 reporting in_progress on job 94291309935 for all 36 iterations. Follow-up comment posted 00:04:21Z noting the check still pending.

Census for the window is exact in both directions: an artifact sweep over all 155 completed runs found 61 carrying a claude-session-logs artifact, and token-report.sh reported the same 61, with comm empty each way.