repo-hygiene: clean-batch apply should validate plan records against the requested --tier

[kyle-sexton]

Problem

clean-batch.sh --apply --batch-plan <path> dispatches purely on each plan line's kind (REPO/GITDIR); the apply-time --tier flag is informational only. A stale or swapped plan therefore executes the plan's full gated content while the banner reports the (narrower) requested tier — e.g. --tier build dry-run followed by --tier caches --apply --batch-plan <build-plan> removes both bin/ and .pytest_cache/ while printing Tier: caches.

Bounded: every removed path was still enumerated and confirmation-gated at plan creation (the plan IS the gated set), so nothing un-gated is ever removed — the defect is scope misrepresentation at apply time, not an ungated deletion.

Fix direction

At apply, validate plan records against the requested tier (reject build-class REPO records under --tier caches, gate the GITDIR arm on a git-bearing tier) or drop the apply-time --tier flag entirely so the plan is the sole authority and the banner reflects the plan, not the flag.

Related

• repo-hygiene: no batch mode for caches/build/git tiers — fleet sweep forces hand-rolled orchestration #994 (fleet batch mode, PR feat(repo-hygiene): fleet batch mode for the caches/build/git/all tiers #1064) — where the plan-as-gated-set contract landed
• Deferred from PR feat(repo-hygiene): fleet batch mode for the caches/build/git/all tiers #1064 review (Codex P2) under the convergence freeze; empirical repro in the thread.

Work-class: C3 (bug-fix-shaped) — attended triage 2026-07-23, operator-ratified. 🤖

[kyle-sexton]

This was generated by AI during triage.

Triage — routing the reporter's either/or. Between the two fix options: dropping the apply-time --tier flag entirely removes a useful caller-stated-intent signal and the very input the validation would check against. Validating plan records against the requested tier directly fixes the described defect (banner/scope misrepresentation) while keeping the flag meaningful.

Decision defaulted: validate plan records against the requested --tier at apply (reject build-class REPO records under --tier caches; gate the GITDIR arm on a git-bearing tier) — veto before merge. Routed status: ready on this basis.

[kyle-sexton]

Claim (work lane, T3) — dispatching an implementation subagent this cycle. 2026-07-22T22:30:07Z

[kyle-sexton]

[kyle-sexton]

Done (2026-07-22): clean-batch.sh --apply now pre-scans the whole plan before the banner/any disk touch and refuses atomically (exit 2, nothing removed) when a record isn't authorized under the requested --tier — per the triage decision (validate, don't drop the flag). 57/57 tests pass incl. 3 new tier-authorization cases; exact issue repro verified fixed. Held as draft do-not-merge: PR #853 also bumps plugins/repo-hygiene's version+CHANGELOG (real collision, confirmed via diff). Will auto-close when PR #1088 merges.