Support merged-worktree cleanup for PRs targeting release branches or stack parents #14758

Before submitting

• I searched existing issues and discussions and did not find an item covering this specific scope.
• I included enough detail to reproduce or investigate the limitation.

Area

apps/server — automatic merged-worktree cleanup, shared by all clients.

Problem and scope

A feature PR can be merged into a release branch or its stack parent while the project's default branch does not yet contain its commits. Delete merged worktrees retains that feature checkout, even after an ordinary merge that preserves commit ancestry.

This is an intentional, documented policy limitation, not a regression or a claim of prior approval. The current rule requires ancestry in the primary remote's default branch. #14742's triage explicitly excludes PRs merged into release branches or stack parents from its focused squash-merge fix.

This issue requests separate maintainer triage of that non-default-target case, following #14651's request to separate target-selection behavior. It concerns only Delete merged worktrees, not the separate unchanged-worktree rule.

Steps to reproduce

T3 conditions:

1. Enable Delete merged worktrees; disable inactivity, unchanged-worktree and deleted-thread cleanup so other rules cannot mask the result.
2. Use an otherwise eligible T3-managed feature worktree: clean, idle, exclusively owned by its thread, without an active session/terminal or protected ignored files.
3. Open its PR against release, or against a stack parent that has not landed in main.
4. Merge that feature PR normally, preserving its commits. Keep the feature worktree at the merged PR's head; leave the target unmerged into main.
5. Allow the cleanup sweep to evaluate the worktree.

The ancestry condition can be reproduced independently without T3 or a GitHub repository. This runs both target cases in new temporary repositories; neither uses squash:

repro_root=$(mktemp -d)
for target in release stack-parent; do
  git init -q -b main "$repro_root/$target"
  cd "$repro_root/$target" || exit 1
  git config user.name 'Cleanup repro'
  git config user.email 'cleanup-repro@example.invalid'
  printf 'base\n' > file
  git add file
  git commit -qm base
  git switch -qc "$target"
  printf 'parent\n' >> file
  git commit -qam parent
  git switch -qc feature
  printf 'feature\n' >> file
  git commit -qam feature
  git switch -q "$target"
  git merge -q --no-ff feature -m 'Merge feature normally'
  git merge-base --is-ancestor feature main
  printf '%s: feature ancestor of main = %s\n' "$target" "$?"
  git merge-base --is-ancestor feature "$target"
  printf '%s: feature ancestor of target = %s\n' "$target" "$?"
done

Observed output:

release: feature ancestor of main = 1
release: feature ancestor of target = 0
stack-parent: feature ancestor of main = 1
stack-parent: feature ancestor of target = 0

Expected behavior / requested triage decision

Consider allowing merged-worktree cleanup for the completed feature PR without waiting for its target to reach the default branch, while preserving the branch and thread history.

The key scope question is whether a freshly confirmed merged PR is enough for its otherwise eligible checkout to be removed when the target is a release branch or an unmerged stack parent, or whether cleanup should continue waiting for default-branch integration. Please establish that policy and the required evidence before implementation. If eligibility depends on reading the target branch, the behavior when that branch has since been deleted also needs to be explicit.

This request does not change unchanged-worktree cleanup, the existing default-branch ancestry fallback, ignored-file protection, or introduce an unrelated remote/default resolver. Existing ownership, clean-checkout, activity and final policy/HEAD checks remain. A stale PR snapshot, closed-unmerged PR or later unmerged local commit must not be treated as proof that the current checkout was merged.

Actual behavior

Cleanup fetches the primary remote's default branch, tests whether the worktree head is its ancestor, and returns on failure before querying the PR's merged state. The completed child checkout stays until its commits reach the default branch or another cleanup rule qualifies it.

The settings description matches this existing policy. The requested behavior would therefore be an intentional extension, independent of squash-merge detection.

Impact

Completed release/stack child worktrees continue occupying disk despite their PR being merged. Work is not blocked and branches/history are not lost.

Version or commit

Upstream main at 54084ae1e6c32809db040e4fa571c80fdf2d8ae4.

Environment and verification limits

Linux; the script above was run in isolated local Git repositories. Current cleanup source and maintainer comments were inspected. An integrated T3 cleanup run and live GitHub PR merges were not performed; the T3 result is source-traced, not a claimed application test.

Workaround

Wait for the target's commits to reach the default branch, or use the existing inactivity cleanup rule. Those have different timing from cleanup of the already-merged feature PR.