Baixar worktrunk v0.72.0 per a Windows

Release Notes
Improved
- wt merge and wt step push leave the target worktree's uncommitted changes in place: Both commands used to move a dirty target worktree's changes aside with an autostash (git stash push -u) and restore them after the push, because the fast-forward's receive.denyCurrentBranch=updateInstead refuses any dirty worktree at all. That design entered refs/stash — a repo-global namespace any process can mutate — and restored staged changes as unstaged. Both strategies now advance the target through one path: a compare-and-swap update-ref, then update-index --refresh plus read-tree -m -u in the target worktree (git's documented lenient push-to-checkout policy), with a CAS rollback if the sync can't apply, so branch and worktree move together or not at all. Uncommitted changes at paths the push doesn't touch never move — unstaged edits stay unstaged, staged entries stay staged, untracked files stay put, and refs/stash is never involved. The upfront check that names a conflicting file also reads --porcelain -uall now, so an untracked file inside an untracked directory is caught and named rather than slipping past a collapsed dir/ entry. (Breaking: the fast-forward path no longer runs a git push, so pre-push and the receive-side hooks — pre-receive, update, post-receive, post-update, and any push-to-checkout — no longer fire. A git merge run in the target wouldn't run them either, which is the line the module spec draws, and the new sync reimplements the lenient policy push-to-checkout documents rather than invoking the hook. Separately, a sync that can't apply now fails the command with the ref rolled back, where --no-ff previously warned and left the worktree stale behind its own branch.) (#3703, #3684, #3693, thanks @gubasso for reporting the stash race that started this)
- 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, so github.attacker.example carried the exact label and classified fine, while the rule shut out the self-hoster with a hyphenated name. github-enterprise.acme.com, mygithub.com, gitlab-internal.company.com, and the github-personal SSH alias classify again, so CI status, wt switch --prs, and repo.provider work with no config. The cost is a host that merely sounds like a forge getting a forge CLI run at it, which surfaces as that CLI's error rather than as silence. Azure DevOps keeps suffix matching on dev.azure.com / visualstudio.com — those are service domains rather than a brand in the host — and userinfo still resolves to the network host, so https://github.com@attacker.example/… is attacker.example. The github-personal diagnostic 0.71.0 added is gone with the rule it explained. (#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 every repository on that host, nested groups and all. Every matching entry applies, least- to most-specific, so a narrower key wins where two set the same field and leaves the rest alone. The table also gained forge.platform and forge.hostname, which previously lived only in each repository's committed .config/wt.toml — so a self-hosted host carrying none of the three brand names needs one user-config entry rather than a block in every repo. A repository's own [forge] still wins field by field. approved-commands matches by the same rules, but only a hand-written key is ever a pattern: wt config approvals add records under the exact project identifier, and clear empties only the exact entry. Docs (#3701, thanks @chrishas35 for the request and @witt-bit for the workspace-scoped case it partly serves)
- wt list --format=json schema 2 has a published JSON Schema: The contract is at worktrunk.dev/schema/list-v2.json, and wt list --print-schema prints the same document. Four fields that were bare strings — checks.status, display.state, default_branch.integration.reason, and worktree.operation — are now enumerated vocabularies, so a new variant is a compile error rather than a value silently missing from the published schema. The emitted JSON is unchanged. (#3747)
- Approval state and branch-removal outcomes are machine-readable: wt config approvals list --format=json reports which of three states a non-interactive run would hit — no_commands, approved, approval_required — so an orchestrator can learn that a run would stop for approval without running the operation or passing --yes. A separate stale list carries approvals whose command template has changed since, which --yes would otherwise silently re-approve; it co-occurs with all three states, so it isn't a fourth. Separately, removal's branch_deleted boolean collapsed five internal outcomes into two values, reporting a lost CAS race and an explicit --no-delete-branch as the same false, and a deferred deletion as true on intent alone. branch_outcome names them: deleted, deferred, not_attempted, retained_unmerged, retained_checked_out, retained_raced, retained_failed. (Breaking: branch_deleted is replaced, not supplemented, on wt remove --format=json and wt step prune --format=json's live path.) (#3710, thanks @NathanaelRea for the requests)
- A detached worktree is named by its commit, not -: The Branch cell hardcoded - for a worktree with no branch, which reads as missing data rather than as a state — and it was the odd one out, since the skeleton row, the statusline, and the picker all reached for (detached). The cell now carries the row's abbreviated HEAD in dim yellow, and the picker filters and the statusline name the worktree the same way. Detached worktrees aren't exotic here: Codex creates one per session. (#3675)
- Every commit hash worktrunk prints follows core.abbrev: The wt list table sliced head[..8] while --format=json's short_sha carried git's %h, so one commit read 1b9f1d96 in the table and 1b9f1d9 in JSON. wt switch --prs's log tab and wt config state's CI cache table sliced to 8 too. All of them now ask git how wide it abbreviates in this repo, cached once per process, so core.abbrev = 12 no longer truncates mid-hash and the default 7 stops reserving a column nothing fills. Where the commit-details batch fails, the Commit cell is now empty rather than a slice of a SHA git refused. (#3676, #3677)
Fixed
- wt merge and wt step push refuse a target worktree parked mid-operation: The target sync is a two-tree merge, which refuses an unmerged index but not a stopped cherry-pick or rebase whose conflict has already been staged. A target paused between steps could therefore have the push range written into it, and the user's --continue would commit the synced tree as the step's result. The old fast-forward path got this check for free from receive.denyCurrentBranch=updateInstead, which refused any unclean target outright; both strategies now ask directly, and the refusal names the worktree holding the operation. (#3759)
- An alias or hook wrapping wt switch or wt remove keeps your subdirectory: wt switch and wt remove land you in the destination's matching subdirectory, but the resolution read the user's position from the wt process's own cwd — which answers "where is the user standing?" only for a top-level invocation. Alias and hook bodies run with the worktree root as their working directory, so with [aliases] finish = "wt remove -y", wt finish from feature/apps/gateway dropped you at the primary worktree root. The shell's directory now travels with the CD directive file, to exactly the children allowed to move the user's shell, and each layer forwards it so nesting composes. Nothing about the working directory of alias or hook bodies changes; {{ cwd }} is still the worktree root. Fixes #3723. (#3724, thanks @vivienm for reporting)
- An rm alias no longer breaks the shell wrappers' cleanup: zsh, bash, and nushell all expand aliases when the wrapper's function is parsed, so a user's alias rm='rm -v' defined before the wrapper was installed baked itself into the cleanup. On zsh and bash that printed two lines of removed '/tmp/…' noise per wt invocation. On nushell it was worse: nushell raises on a non-zero external exit, so an rm alias that failed aborted the wrapper before it returned — the command's stdout was silently discarded and three temp files leaked. All three now bypass alias resolution (command rm, and ^rm on nushell, whose builtin is kept on Windows where there is no external rm), with the nushell cleanup wrapped in try so it can never abort the wrapper again. (#3714, thanks @Ar4l), (#3732)
- A failing --execute body no longer strands the nushell wrapper's temp files: The wrapper's --execute call wasn't wrapped in try, so a body exiting non-zero unwound the whole function — cleanup never ran, all three mktemp files leaked, and the stdout the function still owed was discarded. The existing test passed because the unwind happened to carry the exit code out to the shell, not because the wrapper handled it. (#3734)