fix(repo-hygiene): git-tree-reset dry-run doesn't validate `@{u}`, so dry-run success != apply success

[kyle-sexton]

Summary

git-tree-reset.sh --dry-run does not validate that the upstream (@{u}) actually resolves, so a clean-looking dry-run (Blocked: none) does not predict that --apply will fail. Dry-run/apply parity is broken for the deleted-upstream case.

Component

plugins/repo-hygiene/skills/clean/scripts/git-tree-reset.sh.

Root cause

The dry-run branch (lines ~154–165) prints PlannedReset: git reset --hard <UPSTREAM> and previews git clean -fdxn, but never verifies the upstream ref exists. When UPSTREAM is the literal @{u} (see companion unresolved-upstream issue), dry-run still reports Blocked: none and a nonzero wouldRemove count, implying the apply will proceed cleanly.

Evidence (this session)

Dry-run sweep across 16 repos reported blocked=none for the 6 feature-branch repos whose upstream was gone. The subsequent --apply then failed on every one of those 6 with fatal: ambiguous argument '@{u}'. The dry-run gave zero warning.

Impact

Dry-run is the safety gate the skill's own workflow mandates before --apply. If dry-run cannot surface a condition that will fail (or partially execute destructively) at apply time, the gate provides false assurance.

Expected

Dry-run performs the same upstream-resolution validation as apply and reports the blocked/unresolved state, so dry-run success ⇒ apply will not fail on upstream resolution.

Acceptance criteria

• Move upstream-resolution validation ahead of the dry-run/apply split so both paths see it.
• Dry-run prints the same Blocked: reason apply would (e.g. upstream-unresolved).
• Regression test asserting dry-run and apply agree on the deleted-upstream branch.

[kyle-sexton]

Parked — needs-decision: this appears already resolved by #542 (merged 2026-07-19)

Working this to a fix, I found current origin/main already satisfies every acceptance criterion here. Flagging rather than opening a no-op PR.

Intent vs. effect

PR #542 was scoped to sibling #393 and its body explicitly says #396 was "noted here, not touched." That is true of intent — but the author placed the upstream-resolution gate before the dry-run/apply split rather than only in the apply path, which resolves #396 in effect. So on paper #396 looks open; in the code it is done.

Acceptance-criteria mapping (plugins/repo-hygiene/skills/clean/scripts/git-tree-reset.sh)

• AC1 — validation ahead of the dry-run/apply split: the git rev-parse --verify --quiet '@{u}' gate at lines 120-128 (exit 6) precedes the if [[ "$DRY_RUN" -eq 1 ]] split at line 183. The not-configured case is also gated ahead of the split (lines 103-106, exit 2).
• AC2 — dry-run prints the same Blocked: reason apply would: both paths hit that one gate, emitting Blocked: upstream-unresolved (<remote>/<branch>).
• AC3 — regression test asserting dry-run and apply agree on the deleted-upstream branch: test case build(deps): bump ci-workflows pin to b6431a1 (PSSA RULE_ERROR retry fix) #10 in git-tree-reset.test.sh (lines 154-196) — dry-run assertions at 180-184, apply assertions at 188-196.

Empirical evidence

bash git-tree-reset.test.sh on current origin/main → 45/45 pass, including the dry-run gate:

PASS: [28] unresolvable upstream dry-run exits 6
PASS: [29] unresolvable upstream dry-run reports block
PASS: [30] unresolvable upstream dry-run plans no reset to literal @{u}
PASS: [31] unresolvable upstream apply exits 6
PASS: [32] unresolvable upstream apply reports block

Decision needed

RECOMMENDED — close #396 as already-resolved by #542, with the mapping above as the traceability record. I found no residual sub-requirement across both upstream sub-cases (not-configured -> exit 2, lines 103-106; configured-but-gone -> exit 6, lines 120-128; both before the split).

Alternatives:

1. Close as duplicate/resolved-by fix(repo-hygiene): gate git-tree-reset on unresolvable upstream, never reset --hard @{u} #542 (RECOMMENDED) — nothing left to implement; a code PR would be a no-op.
2. Keep open only if a maintainer identifies a residual requirement I missed — I found none on two readings.
3. Add this traceability note and close (same outcome as 1, explicit link fix(repo-hygiene): git-tree-reset dry-run doesn't validate @{u}, so dry-run success != apply success #396 -> fix(repo-hygiene): gate git-tree-reset on unresolvable upstream, never reset --hard @{u} #542).

No PR opened and no branch pushed — a WIP branch would carry zero commits over origin/main.