docs(step): prefix the copy-ignored --require-include example with $ - #3706

…ion (#3722)

Daily review of the 2026-08-02T08:51Z → 2026-08-03T08:51Z tend window. 8
runs failed, all with the same root cause, and one of them left a PR
permanently un-reviewed. This adds the recovery step that was missing.

## What happened

Every failure in the window was `claude -p exited non-zero (exit=1)` at
the harness step, across three workflows — `tend-notifications` ×5,
`tend-review` ×2, `tend-nightly` ×1. The session logs give one cause for
all eight:

```
{"model":"<synthetic>","stop":"stop_sequence",
 "content":["You've hit your session limit · resets 8:30am (UTC)"]}
```

Two 5-hour subscription windows were exhausted (resets at 03:10Z and
08:30Z). That is quota, not a bug — no fix PR is warranted for the
exhaustion itself.

The consequence is the problem. The harness recorded all eight in the
`tend-outage` issue
[#3715](#3715), one row
each with the run link and the triggering `#N`, and then nothing re-ran
them. `tend-review` fires only on `pull_request_target`, so a review
that dies at turn 1 never retries.
[#3712](#3712) recovered by
luck — a later push re-triggered it.
[#3721](#3721) did not: at
analysis time it was the only non-bot open PR in the repo with zero
`worktrunk-bot` reviews, its head unchanged since 06:06Z, and nothing
was going to re-trigger it. I re-ran
[30789110268](https://github.com/max-sixty/worktrunk/actions/runs/30789110268)
manually (attempt 2) to unblock it.

## Why codify it

This isn't a one-off. "Bot temporarily unavailable" issues recur about
weekly — [#3715](#3715),
[#3632](#3632),
[#3586](#3586),
[#3260](#3260),
[#3153](#3153), and ~15
more back to April. The failure is structural: a rate-limited run always
dies at turn 1, always leaves its trigger unserviced, and there is no
decision point where the bot could have done better. It's also invisible
— the PR just sits there looking reviewed-by-nobody, and the last two
review windows both recorded "0 failed runs", so the log gave no warning
either.

## The change

One section in `running-tend`, placed next to the existing CI-fix
classification guidance:

- Drain the open `tend-outage` issue during the daily `review-runs`
sweep and extract the stranded run IDs and triggers.
- Re-run only event-triggered runs — `tend-nightly` and
`tend-notifications` recover on their next cron tick.
- Check the PR still lacks the work before re-running, so a trigger that
already recovered via a later push doesn't burn quota twice.
- Diagnose the cause from the session log rather than the issue body,
which says only "The bot failed to process a request".

Both recipes were run against this window's data before being written
down: the outage-issue drain returns all 8 run IDs plus `#3712` /
`#3721`, and the session-log `jq` returns the session-limit line from
the downloaded artifact.

<details><summary>Window detail</summary>

**Spend**: $49.74 API-list across 52 token-bearing runs (7.7K in /
304.6K out / 2.5M cache-create / 31.2M cache-read). Per workflow:
`tend-review` $35.16 (29 runs, 15 distinct PRs), `tend-weekly` $4.64
(1), `tend-notifications` $4.34 (10), `tend-mention` $5.60 (11). Down
from $86.04 the prior window, partly because eight runs died at turn 1
for $0. No waste outlier — the review spend tracks real PR throughput.

**Outcomes**: 3 bot PRs merged
([#3706](#3706),
[#3707](#3707),
[#3708](#3708)), 0 closed
without merge, 0 maintainer corrective comments. `tend-nightly`
[30793479820](https://github.com/max-sixty/worktrunk/actions/runs/30793479820)
died at turn 1, so this window's nightly sweep produced nothing — it
recovers on tomorrow's cron. No job ran long (max 4 min among failures;
nothing near the 360-min cap).

**Notifications cadence checked, not a problem**: `*/15` gives ~36
runs/day, but only 10 reached the harness — the workflow's pre-Claude
notification gate exits the rest before any token spend. ~6 substantive
runs/day at ~$0.87. Not the quota driver.

</details>

---------

Co-authored-by: worktrunk-bot <254187624+worktrunk-bot@users.noreply.github.com>

worktrunk 0.72.0

Created-by: HarmonybrewBot
Commit-by: HarmonybrewBot
Merged-by: HarmonybrewBot
Description: Created by `brew bump`

---

Created with `brew bump-formula-pr`.<details>
  <summary>release notes</summary>
  <pre>## Release Notes

### Improved

- **A host carrying a forge's name anywhere resolves to that forge again**: 0.71.0 required `github`, `gitlab`, or `gitea` as a whole dot-separated label, which read as an ownership check but wasn't one — an attacker controls their own DNS — while shutting out self-hosters with hyphenated names. `github-enterprise.acme.com`, `mygithub.com`, and the `github-personal` SSH alias classify again, so CI status, `wt switch --prs`, and `repo.provider` work with no config. ([#3673](max-sixty/worktrunk#3673))

- **One `[projects."…"]` entry can cover every repository on a host, and can set the forge**: A key containing `*` matches any run of characters, `/` included, so `[projects."git.company.example/*"]` covers a whole host; every matching entry applies, least- to most-specific. The table also gained `forge.platform` and `forge.hostname`, so a self-hosted host needs one entry here rather than a block in every repo. [Docs](https://worktrunk.dev/config/#user-project-specific-settings) ([#3701](max-sixty/worktrunk#3701), thanks @chrishas35 for the request and @witt-bit for the workspace-scoped case it partly serves)

- **`wt merge` and `wt step push` leave the target worktree's uncommitted changes in place**: The autostash that held a dirty target's changes restored them as unstaged; both now advance the target with a compare-and-swap `update-ref` and `read-tree -m -u`, which leaves uncommitted work untouched. (Breaking: the fast-forward path no longer runs `git push`, so `pre-push` and the receive-side hooks no longer fire, and a failed sync errors with the ref rolled back.) ([#3703](max-sixty/worktrunk#3703), [#3684](max-sixty/worktrunk#3684), [#3693](max-sixty/worktrunk#3693), thanks @gubasso for reporting)

- **Approval state and branch-removal outcomes are machine-readable**: `wt config approvals list --format=json` reports whether a non-interactive run would stop for approval. `wt remove` and `wt step prune` replace `branch_deleted` with `branch_outcome`: `deleted`, `deferred`, `not_attempted`, `retained_unmerged`, `retained_checked_out`, `retained_raced`, `retained_failed`. (Breaking.) ([#3710](max-sixty/worktrunk#3710), thanks @NathanaelRea for the requests)

- **Every commit hash worktrunk prints follows `core.abbrev`**: The `wt list` table, `wt switch --prs`'s `log` tab, and `wt config state`'s CI cache table sliced to 8 characters while `--format=json` carried git's `%h`. All now ask git how wide it abbreviates in this repo. ([#3676](max-sixty/worktrunk#3676), [#3677](max-sixty/worktrunk#3677))

- **`wt list --format=json` schema 2 has a published JSON Schema**: [worktrunk.dev/schema/list-v2.json](https://worktrunk.dev/schema/list-v2.json) holds the contract, and `wt list --print-schema` prints the same document. Four fields that were bare strings are now enumerated vocabularies; the emitted JSON is unchanged. ([#3747](max-sixty/worktrunk#3747))

- **A detached worktree is named by its commit, not `-`**: The Branch cell hardcoded `-`, which reads as missing data rather than a state; it now carries the row's abbreviated HEAD, and the picker and statusline name the worktree the same way. ([#3675](max-sixty/worktrunk#3675))

### Fixed

- **Piped output is plain and no longer panics**: `wt list | head -3` exited 101 with `failed printing to stdout: Broken pipe`, and `wt list` wrote ANSI to a pipe unconditionally. Every stdout surface now exits cleanly, and the human-read ones are plain when piped unless `CLICOLOR_FORCE=1`. ([#3746](max-sixty/worktrunk#3746), [#3766](max-sixty/worktrunk#3766))

- **A CI check that hasn't finished no longer reads as passed**: Each forge's status parser missed documented values, so a GitHub PR parked on an approval gate showed green, and GitLab's `canceling` and Azure DevOps's `postponed` read as no CI at all. ([#3741](max-sixty/worktrunk#3741), [#3740](max-sixty/worktrunk#3740))

- **The shell wrappers survive an `rm` alias and a failing `--execute`**: Aliases bake into the wrapper at parse time, so `alias rm='rm -v'` reached its cleanup — noise on zsh and bash, and on nushell an abort that leaked three temp files, as a failing `--execute` body also did. ([#3714](max-sixty/worktrunk#3714), thanks @Ar4l), ([#3732](max-sixty/worktrunk#3732), [#3734](max-sixty/worktrunk#3734))

- **An alias or hook wrapping `wt switch` or `wt remove` keeps your subdirectory**: The user's position came from the `wt` process's cwd, which inside an alias body is the worktree root, so an aliased `wt remove` from `feature/apps/gateway` landed at the primary worktree's root. Fixes [#3723](max-sixty/worktrunk#3723). ([#3724](max-sixty/worktrunk#3724), thanks @vivienm for reporting)

- **`wt merge` and `wt step push` refuse a target worktree parked mid-operation**: The two-tree sync refuses an unmerged index but not a stopped cherry-pick or rebase whose conflict was already staged, so the push range could land in a paused target and be committed by `--continue`. ([#3759](max-sixty/worktrunk#3759))

- **The Claude plugin's worktree-remove hook resolves against the worktree path**: The hook anchored at `CLAUDE_PROJECT_DIR`, which the `claude agents` view routinely leaves outside any repository, so `wt remove` died with `not a git repository` and the session became undeletable. Its guard now also requires a `.git` entry. ([#3754](max-sixty/worktrunk#3754), [#3767](max-sixty/worktrunk#3767), thanks @judewang for the fix and the report)

- **A Gitea API error is reported as one, not as a parse failure**: `tea api` exits 0 whatever the HTTP status, so both call sites guessed from the body's shape and blamed an API change for an API error. `--include` surfaces the status instead. ([#3713](max-sixty/worktrunk#3713), [#3600](max-sixty/worktrunk#3600))

- **`--print-schema` and the doc-generation help flags name the right command**: All three found the subcommand by scanning `argv` for a `/wt` suffix, which never matches `wt.exe` under a backslash path, so on Windows they read the binary's own path as the command. ([#3762](max-sixty/worktrunk#3762))

- **A multibyte shell name no longer panics**: `extract_filename_from_path` sliced at `len() - 4` to test for `.exe` with no char-boundary check: `SHELL=/bin/日本語 wt config show` panicked, and on macOS every process name goes through it during shell detection. ([#3727](max-sixty/worktrunk#3727))

- **`wt` installed under a dotted name generates shell integration for that name**: `binary_name` used `file_stem`, which cuts at the last dot, so `wt config shell init bash` under `wt.old` emitted a wrapper for `wt`. It now strips only the executable suffix. ([#3719](max-sixty/worktrunk#3719))

- **Concurrent `wt step prune` removals no longer race the worktree registry**: `git worktree remove` reads every sibling under `.git/worktrees/`, so two overlapping removals could have one read a sibling mid-teardown. Registry-mutating removals now serialize behind a second lock. ([#3692](max-sixty/worktrunk#3692))

- **The `wt switch` first-run offer previews the legacy files it removes**: Accepting "Install shell integration?" could delete a deprecated worktrunk-managed wrapper the prompt never named. What gets removed is unchanged. ([#3656](max-sixty/worktrunk#3656))

- **`wt config create --project` writes a resolvable link**: The comment it writes into `.config/wt.toml` carried a raw Zola target, because the link-conversion regex stopped at the first `]` — here the one closing a nested code span. ([#3731](max-sixty/worktrunk#3731))

- **`wt list --branches` counts a local branch containing `/` as local**: The summary tally classified branch-only rows by `branch.contains('/')`, so a local `feature/login` counted under "N remote branches". ([#3687](max-sixty/worktrunk#3687))

- **`wt step relocate`'s human summary counts template-error branches as skipped**: `--format=json` already folded them into `skipped`; the human tally undercounted by the number of branches whose `worktree-path` template failed to expand. ([#3688](max-sixty/worktrunk#3688))

### Documentation

- **SignPath attribution appears with the artifacts it describes**: The code-signing notice and a route to the policy now sit in the install section's Windows block on the README and the docs landing page, as SignPath Foundation's OSS program requires. ([#3709](max-sixty/worktrunk#3709))

- **`wt step copy-ignored`'s `--require-include` example renders as a terminal block**: It was the only `console` block in the command's long help missing the `$ ` prefix. ([#3706](max-sixty/worktrunk#3706))

### Internal

- **Library API rework** (Breaking library API): `cargo-semver-checks` fails five lints — `LegacyForgeAlias` and `Repository::legacy_forge_alias` removed with the forge-classification revert, `Repository::forge_platform_override` removed for one shared resolver, `stage_worktree_removal` gained two parameters, `UserProjectOverrides` gained a `forge` field, and the `real-repo-benches` feature was removed. ([#3673](max-sixty/worktrunk#3673), [#3694](htt

See merge request: Harmonybrew/homebrew-core!16275