Release v0.78.0

[max-sixty]

Version bump to 0.78.0 plus the changelog section for this release, a comment-preservation fix the release review turned up, a PTY test-filter fix, and merges of main (commits that landed during the review, including #4124, #4122, #4141, #4140 and #4145).

Bump level: minor. cargo semver-checks reports 2 breaking library changes — a new leftover_branch field on the GitError::WorktreeCreationFailed struct variant, and DEPRECATED_TEMPLATE_VARS removed. Pre-1.0, so a breaking change takes a minor bump.

Comment-preservation fix

A config save — declining the commit-generation offer, say — dropped the trailing comment on every value it rewrote. That was already true in v0.77.0 for a line the save itself changed (skip-commit-generation-prompt = false # note → true, reproduced on the v0.77.0 binary). #4080 widened it to lines the command never touched: retired template variables now migrate on every load, so the next unrelated save rewrote any line naming one. #4080's own PR said this "needs a call before merge" and merged without one.

• replace_keeping_decor keeps the value's decor (spacing after =, trailing comment) when merge_tables replaces a scalar. Comments above a line sit on the key and were never at risk.
• main's fix(config): preserve unknown keys and comments when rewriting an inline config section #4120 independently reworked the inline-table arm and moved a key's leading comment onto the rewritten header, but documented that a trailing comment after the closing brace "is still dropped". replace_inline_with_table now carries it after the header's ], so both of its callers keep it.
• Tests: the existing comment-preservation test goes back to a retired name (the only fixture that exercises the replacement) and adds a comment on the mutated line; a new test snapshots and re-parses an inline [projects] entry. Each fails without its half of the fix.

Not fixed, and identical on v0.77.0: a save deletes an explicitly written default value (e.g. skip-commit-generation-prompt = false # note) as a stale key, comment included.

--help correction

#4104 moved the OpenCode plugin path to etcetera's Xdg strategy, which uses $XDG_CONFIG_HOME only when absolute — a deliberate, documented choice — but wt config plugins opencode --help still said install mirrors OpenCode's precedence. OpenCode reads a relative value as-is, so the help now says an empty $OPENCODE_CONFIG_DIR and an empty or relative $XDG_CONFIG_HOME are ignored.

Data-loss surface review

Independent finders swept the full diff, including the five commits merged from main. Nothing holds the tag; candidates were adjudicated against v0.77.0 binaries:

• Fixed in this release, reproduced on v0.77.0: fix: ignore an empty or relative XDG_*_HOME across every XDG base-directory read #4104 stops wt config shell install (with Nushell) deleting a nushell/vendor/autoload/wt.nu under the current directory when $XDG_CONFIG_HOME is empty or relative; fix(config): preserve unknown keys and comments when rewriting an inline config section #4120 stops a save or migration from writing an inline section's comment inside [commit] brackets, which made the config unparseable, and from dropping unknown keys.
• wt step prune --min-age doesn't apply where no reflog exists — pre-existing, proven by building the pre-Age branches by reflog entry in wt step prune; fix four doc claims #4077 binary. git clone --bare and git fetch into refs/heads/* write no reflog, so in the bare layout tips-patterns.md recommends every branch starts unprotected. Docstring corrected here; behavioral fix is follow-up.
• wt config update --output <path> replaces any named file whole, no existence check or prompt — pre-existing, follow-up.
• wt config shell install fish --yes replaces a hand-written wrapper at the XDG path — accepted ("ownership is the path", predates fix(shell): reclaim the legacy wrapper paths instead of inspecting them #3602), newly reachable only for users with $XDG_CONFIG_HOME set. The FAQ's delete inventory now cross-references it.
• --var <retired-name> binds a name nothing references after refactor(config): stop supplying the deprecated template variables, migrating them on load #4080 — inert, no shipped usage; follow-up.
• feat(config)!: split the Pi and oh-my-pi plugin installers #4135 migrates nothing: an existing oh-my-pi hook stays put, pi uninstall points at omp uninstall. PI_CODING_AGENT_DIR='~/x' is used literally (Pi expands ~) — creates a stray directory, deletes nothing; follow-up.

Changelog

37 entries; each new or edited entry was re-verified against v0.77.0 until a pass came back clean (six passes in all). Passes caught, among others: the OpenCode -x recipe was wrong since 0.76.0, not 0.75.0; #4080's JSON reaches every hook, not just pre-start/post-start; a quoted git error string git never prints; a copy-button overlap that existed only inside this release; #4104's relative-XDG_CONFIG_HOME OpenCode change described as a fix when OpenCode reads that path as-is; and which commands a broken inline section stopped. Fixed leads with the data-loss entries.

Open PRs checked against v0.77.0

• fix(config): keep template-variable migration in step with the template parser #4124 fixed a bug new in this release, caused by refactor(config): stop supplying the deprecated template variables, migrating them on load #4080, and has landed and been merged in here. The hand-rolled template-variable scanner it extends is slated for removal; see its commit message.
• fix(git): close hidden status safety gaps #4112 — no data-loss regression vs v0.77.0; two small non-safety regressions from fix(git): protect untracked files hidden by config #4111 (an uncapped auto-staging file list, a narrow Nothing to commit refusal under status.showUntrackedFiles = no). Not merged, by decision.
• fix(config): migrate deprecated keys in an inline [projects] scope #4122 (merged in) and fix(config): stop reporting valid empty per-project sections as unknown #4123 — pre-existing bugs, identical on v0.77.0.

PTY filter fix

test (macos) failed once on a shell's failed-setpgid diagnostic that landed straight after the capture's trailing \x1b[0m, with no newline between, so #4136's line-anchored filter missed it. The filter now also matches right after an SGR escape and keeps the escape; its test gains that shape and fails on the old pattern.

Validation

• cargo run -- hook pre-merge --yes — 4930 tests passed, 1 skipped; clippy, fmt, doc-sync, snapshot and lockfile checks green
• Nightly on the original cut-from tip (https://github.com/max-sixty/worktrunk/actions/runs/35060617020): green across full-tests on linux/macos/windows, feature-powerset, all release-targets, nix-flake, minimal-versions, link-check

This was written by Claude Code on behalf of max-sixty

🤖 Generated with Claude Code

[worktrunk-bot]

Two things left after the base merge — the changelog, and one docstring line.
The merge's resolution already closes what I'd have raised on
replace_keeping_decor: the header indent and dropped blank-line separator the
release-branch version produced are gone now that replace_inline_with_table
owns the inline→standard case, and the new snapshot pins the result.

The changelog doesn't cover what the base merge made reachable. Four
user-facing commits are now ancestors of the release commit, and none has an
entry:

• #4135 feat(config)!: split the Pi and oh-my-pi plugin installers — breaking; wt config plugins pi stops writing the oh-my-pi hook
• #4120 fix(config): preserve unknown keys and comments when rewriting an inline config section
• #4126 fix(config): report a failed migration diff instead of rendering none
• #4104 fix: ignore an empty or relative XDG_*_HOME across every XDG base-directory read

release.yaml builds the release notes from the tree at the tag, so these ship
undocumented unless they're folded in first. Drafts suggested inline; I wrote
them from each PR's description rather than its full diff, so they still want
the release skill's own verification pass. #4104 may read better combined with
the existing #4085 and #4107 entries — all three are the same "non-absolute env
var resolved against the wrong directory" shape.

The release-branch fix belongs in that #4120 entry. The PR body drops it
because "a 0.77.0 reader never had the broken behavior", which holds for the
unrelated-line amplification #4080 introduced but not for the mutated line
itself: merge_tables's scalar arm is byte-identical at v0.77.0, so any key
whose value a save changed lost its trailing comment there too. That is what
this PR's own # comment on the mutated line assertion covers — reverting just
the replace_keeping_decor call reproduces it. The reachable 0.77.0 paths are
narrow (skip-commit-generation-prompt = false # … flipping to true, a
project entry whose worktree-path is replaced), so whether it earns its own
words is a judgment call; the stated reason for omitting it is what doesn't
hold.

Not approving. src/commands/step/prune.rs carries the --min-age guard that
decides whether wt step prune deletes a branch with no worktree —
orphan_branch_age is what CheckSource::Orphan feeds into the RemovalPlan
age gate — and the FAQ edit extends "What can Worktrunk delete?". running-tend's
references/review-pr.md, under "Data-Loss Surface: Hold for Human Review",
holds both for a human either way. It also says to request review from
@max-sixty, which is moot here since you're the author.

[worktrunk-bot]

One user-visible move in this release still has no changelog entry: where the
OpenCode plugin is written under a relative $XDG_CONFIG_HOME.

At v0.77.0, opencode_plugins_dir took a non-empty $XDG_CONFIG_HOME at
face value — PathBuf::from(xdg).join("opencode") — so XDG_CONFIG_HOME=cfg
put the plugin at <invocation dir>/cfg/opencode/plugins/worktrunk.ts. #4104
replaced that arm with Xdg::config_dir(), so 0.78.0 writes
~/.config/opencode/… instead. Install, uninstall, and the wt config show
status line all resolve through plugin_path(), so a plugin an older wt left
at the relative path is now neither reported as outdated nor removable by
wt config plugins opencode uninstall.

The PR body says a verification pass rejected calling this a fix, because
OpenCode reads a relative value as-is. That holds for the framing, but the path
moved either way, and the identical empty-OPENCODE_CONFIG_DIR case one rung
up carries its own entry (#4084). Suggested as a clause on the #4104 entry,
since it's the same commit.

Everything else in the four new commits checks out against the code it
describes. The data-loss hold from the previous review is unchanged.

[worktrunk-bot]

A relative $XDG_CONFIG_HOME moved the OpenCode plugin's path too, and plugin_path() is what install, uninstall, and the status line all read — so the old file is stranded rather than migrated. Wording is a starting point; the release skill's verification pass should still take it.

Suggested change

- **`wt config shell install` for Nushell no longer deletes a `wt.nu` under the current directory**: an empty or relative `$XDG_CONFIG_HOME` resolved against it, so install removed a `nushell/vendor/autoload/wt.nu` beneath it unread, as a stale wrapper. It now falls back to `~/.config`, which also fixes unread `tea` logins that let `wt switch pr:<n>` treat a Gitea host as GitHub. ([#4104](https://github.com/max-sixty/worktrunk/pull/4104))

- **`wt config shell install` for Nushell no longer deletes a `wt.nu` under the current directory**: an empty or relative `$XDG_CONFIG_HOME` resolved against it, so install removed a `nushell/vendor/autoload/wt.nu` beneath it unread, as a stale wrapper. It now falls back to `~/.config`, which also fixes unread `tea` logins that let `wt switch pr:<n>` treat a Gitea host as GitHub, and moves the OpenCode plugin off that same relative path — reinstall with `wt config plugins opencode install`, and delete any `opencode/plugins/worktrunk.ts` an earlier version left there. ([#4104](https://github.com/max-sixty/worktrunk/pull/4104))

[worktrunk-bot]

The new #4124 entry scopes the bug to wt config update, but the rewrite it
fixes runs on every config load. migrate_template_vars_doc is a
DeprecationRule::Structural row, and its comment in
src/config/deprecation.rs says why — "the load-path rewrite is what keeps an
unmigrated template rendering what it always did". So a hook, alias, or
worktree-path template hitting either shape rendered wrong on every wt
command; wt config update only writes the same rewrite into the file. As
written, a reader who never runs wt config update reads the entry as "not
me". The #4122 entry added alongside it gets this right — "now migrate", no
command named — and merge.no-ff sits on the same Structural load path.

The entry also stops at "left unmigrated, for hand-editing". No renderer
supplies the retired names any more, so a template that binds one now fails its
SemiStrict expansion — or renders nothing, in a squash template — and, per
template_bound_names, raises no deprecation warning naming the cause. A
0.77.0 config that worked breaks on upgrade with nothing pointing at why, which
is worth the clause. Suggested wording covers both halves; the release skill's
verification pass should still take it.

[worktrunk-bot]

Suggested change

- **`wt config update` no longer changes what a template renders when renaming a retired variable**: it rewrote `{{ repo_root }}` inside a quoted string, and turned `{{ repo_root }}{% set repo_root = 'x' %}{{ repo_root }}` into one printing the path twice. A template that binds a retired name or its replacement is now left unmigrated, for hand-editing. ([#4124](https://github.com/max-sixty/worktrunk/pull/4124), thanks @zach-hammad-vs for reporting)

- **Renaming a retired template variable no longer changes what the template renders**: the rename runs on every config load, where it rewrote `{{ repo_root }}` inside a quoted string and turned `{{ repo_root }}{% set repo_root = 'x' %}{{ repo_root }}` into one printing the path twice. A template that binds a retired name or its replacement is now left unmigrated and no longer warns, so it fails expansion — or renders nothing, in a squash template — until the name is hand-edited. ([#4124](https://github.com/max-sixty/worktrunk/pull/4124), thanks @zach-hammad-vs for reporting)

[worktrunk-bot]

The rewritten #4124 entry promises a loud failure where the squash-template case is silent. deprecated_vars_in_template keeps a pair only when used_vars.contains(*old) && !bound.contains(old) && !bound.contains(new), so binding the canonical name drops it too: {% for commit_details in commits %} in a squash template leaves commits retired. build_prompt renders under minijinja's default UndefinedBehavior::Lenient, which iterates an undefined value as an empty sequence, so that prompt loses its commit list with no error and no deprecation warning — the RETIRED_VARS and template_bound_names docstrings in src/config/deprecation.rs both spell this out, the latter naming that exact shape. "A template that binds a retired name … fails to render until edited" covers neither the binding shape (this commit dropped the previous wording's "or its replacement") nor the outcome, so the user whose commit prompt silently emptied reads the entry as not theirs.

Suggested inline. I left the sentence's lead as written — the still-open thread on this entry covers that half.

Not approving: the data-loss hold from the first review is unchanged.

[worktrunk-bot]

The head merge put #4145 on the release branch with no changelog entry. be39a71e drops the is_main_worktree gate on ProjectConfig::load's unknown-field warning, so a project-config key that is ignored at runtime now says so from any worktree. Before it, the message fired only from the primary worktree — which is not where wt merge runs, and in a bare repo is nowhere at all — while wt config show warned from anywhere through collect_unknown_warnings, so the two channels disagreed about the same file. It closes a user report (#4144), and release.yaml builds the notes from the tree at the tag, so as it stands 0.78.0 ships it undocumented. Suggested inline; placement next to the other warning entry is a guess, and the release skill's verification pass should still take the wording.

The merge's other two commits need no entry: #4141 is the scanner-to-parser refactor, whose own message records that the shadowing policy is unchanged, and #4139 is comments only.

Not approving: the data-loss hold from the first review is unchanged.