fix(git): protect untracked files hidden by config

[Duang777]

Problem

The destructive clean-worktree guard used bare git status --porcelain calls. Git applies the user's status.showUntrackedFiles preference to that command, so with:

[status]
showUntrackedFiles = no

a worktree containing only untracked files appeared clean. That false result could let wt remove, wt merge --no-commit, or unattended wt step prune remove the worktree without protecting those files.

The same preference also hid the disclosure printed before git add -A: wt merge, wt step commit, and wt step squash still staged and committed the files, but did not name them first.

Fix

• Make WorkingTree::is_dirty() and dirty_files() use git status --porcelain --untracked-files=normal, overriding the display-only preference for safety checks.
• Make both auto-staging warning queries use git status --porcelain -z -uall, so they override the preference and enumerate each file inside untracked directories exactly as git add -A will stage it.

Testing

Regression coverage now exercises:

• Shared clean-check helpers.
• Foreground and background wt remove.
• wt merge --no-commit before ref changes or cleanup.
• Unattended wt step prune while another clean candidate is removed.
• wt step commit and wt step squash auto-staging warnings with two files inside an untracked directory.

Applying only these tests to the old origin/main implementation produced six expected failures across the destructive and disclosure paths. The current branch passes the full project gate:

cargo run -- hook pre-merge --yes
4869 tests passed, 1 skipped
lockfile, pre-commit, clippy, doctest, and rustdoc passed

[worktrunk-bot]

The fix reads correct: --untracked-files=normal overrides status.showUntrackedFiles, and it matches the precedent status_porcelain_cached already set for the shared snapshot, so the two status reads in this file now agree. test (linux) and code-coverage are green at this head.

I'm holding the verdict rather than approving: the diff changes is_dirty/dirty_files, which feed ensure_clean — the gate wt remove's trash-rename fast path relies on in place of git's own dirty check. .claude/skills/running-tend/references/review-pr.md ("Data-Loss Surface: Hold for Human Review") puts that call with a human, so I've requested @max-sixty. Two things worth folding in first.

The same display preference still suppresses the auto-staging disclosure. warn_about_untracked_files is fed by two bare git status --porcelain -z reads: the StageMode::All branch in CommitOptions::commit (src/commands/commit.rs, warn_about_untracked_files(&status)?) and warn_if_auto_staging_untracked in src/commands/repository_ext.rs, which wt step squash calls. Under status.showUntrackedFiles = no neither read returns a ?? entry, so Auto-staging N untracked paths: never prints — while StageMode::All still resolves to git add -A, which stages and commits those files anyway.

This PR makes that path more reachable, not less. wt merge decides whether to commit from current_wt.is_dirty()?, so a showUntrackedFiles = no user whose worktree holds only untracked files now takes the commit branch where they previously didn't — the files go into a commit with no notice, where before the merge dropped them. Closing the loop means the same explicit flag on those two reads. -uall rather than normal is the right one there, since the warning enumerates what git add -A is about to stage and normal would collapse an untracked directory to a single dir/ entry — the same reason ensure_no_target_conflicts already passes -uall. Happy to push that as a commit on this branch if you'd rather it ride along than land as a follow-up.

wt step prune is the third command this protects, and it's the unattended one. The guard is shared, so prune's removal path picks the fix up too — and prune is the case where a showUntrackedFiles = no user could have lost an untracked-only worktree without running a command at all. Suggested a CHANGELOG line that names it.

[worktrunk-bot]

Both items from the last round are addressed, and the CHANGELOG now names wt step prune. Two new things from reading this commit; the data-loss hold with @max-sixty is unchanged by them.

-uall uncaps the disclosure list, and it does so for every user, not just the showUntrackedFiles = no ones. I asked for the flag last round without weighing its output cost. warn_about_untracked_files prints files.join("\n") with no cap, so where -unormal collapsed an untracked directory to one ?? dir/ line, -uall emits one line per file inside it — the snapshot update in this commit (.config/ → .config/wt.toml) is the two-file version of that. On a worktree holding a not-yet-ignored node_modules/ or .venv/, wt merge, wt step commit, and wt step squash now bury their own output under thousands of stderr lines, on the default configuration. The Auto-staging N untracked paths: header already carries the magnitude; the enumeration only has to carry enough for the user to recognise a mistake. GitError::WorktreeRemovalFailed's rendering in src/git/error.rs already has the shape — const MAX_SHOWN: usize = 10 plus and {remaining} more.

wt step relocate --commit is a third git add -A, and it discloses nothing. In src/commands/relocate.rs the auto-commit branch stages with worktree.stage(StageMode::All) and then calls commit_staged_changes(…, StageMode::None), so neither warn_about_untracked_files nor warn_if_auto_staging_untracked is reached — grepping both names finds callers only in src/commands/commit.rs and src/commands/step/squash.rs. The gap predates this PR, but this PR adds a configuration in which it fires: the branch is gated on worktree.is_dirty()?, which now returns true for a showUntrackedFiles = no worktree holding only untracked files. So wt step relocate --commit commits files the user was never shown, where before it left them alone and relocated around them. A warn_about_untracked_files call ahead of the stage closes it, and matches what the other two sites now do.

Both fixes sit outside this diff, so no inline suggestions — say the word and I'll push them as a commit on this branch.

[max-sixty]

thank you @Duang777 !

[worktrunk-bot]

Both items from my last review merged as-is, so they've moved from "could ride along on this branch" to live behavior on main. Recording where they sit rather than letting the thread go quiet on them.

The -uall I asked for shipped without a cap, and that lands on the default configuration. warn_about_untracked_files joins every path with no limit, so where -unormal collapsed an untracked directory to a single ?? dir/ line, wt merge, wt step commit, and wt step squash now emit one line per file inside it — a not-yet-ignored node_modules/ or .venv/ buries the command's own output. That hits every user, not only the showUntrackedFiles = no ones; I asked for the flag last round on correctness grounds without weighing its output cost, so this one is mine. GitError::WorktreeRemovalFailed already has the shape to copy: const MAX_SHOWN: usize = 10 plus and {remaining} more.

wt step relocate --commit still discloses nothing. The auto-commit branch stages with worktree.stage(StageMode::All) and then passes StageMode::None to commit_staged_changes, so neither warn_about_untracked_files nor warn_if_auto_staging_untracked is reached. The gap predates this PR, but the is_dirty change here makes the branch reachable for a showUntrackedFiles = no worktree holding only untracked files.

I'm not opening PRs for these unprompted — I already have six open here competing for your review time. Say the word on either and I'll pick it up.