fix(delete): the prompt promised "Nothing is erased" and then erased things

[fcreme]

Builds on #16 (now merged) — it reuses Get-StyleTrashTimestamp from that PR.

The defect

Show-StyleDeletePlan itemises everything about to happen, then asks for confirmation. It closed with:

  - Nothing is erased: move the folder back to undo.

Confirming runs Move-StyleDirectoryToTrash, whose first act is the sweep — a recursive Remove-Item -Recurse -Force over every trashed style past the 7-day window.

Measured, while deleting an unrelated style:

trashed style present before: True
--- what the prompt says ---
  - MOVE .../styles/mine
      to .../.deleted/mine-20260906-135131
  - The name 'mine' GOES: nothing else provides it
  - Nothing is erased: move the folder back to undo.
--- user presses y ---
trashed style present after : False

precious-20200101-000000 — a style the user deleted earlier and could still have recovered by moving the folder back, exactly as the prompt describes — was destroyed by pressing y on a screen that said nothing would be. The only command that can erase it is the one claiming it cannot, and the user was deleting something else at the time.

The fix

Bounded trash is the point of the feature. The listing never saying so was the defect — and it couldn't say so, because the sweep decided what to remove inline. The only way to learn what a delete was about to erase was to let it.

Get-StyleTrashSweepTarget answers that question without acting on it:

  - The name 'mine' GOES: nothing else provides it
  - ERASE precious-20200101-000000, deleted over 7 days ago
      the trash keeps 7 days; this delete is what clears the rest
  - Nothing of 'mine' is erased: move the folder back to undo.

RED, per the file's existing convention that red is for what does not come back. The closing line is now scoped to the style being deleted — unqualified, it directly contradicted the line above it.

The sweep reads that same function instead of re-deciding, so the set shown and the set removed are one list, not two that agree until they don't. That divergence is the shape of most of the defects in this changelog, including #16 and #17.

Tests

10 new. The two that pin the defect fail on the old code:

[-] names the trashed style that confirming will erase
[-] scopes the undo promise to the style being deleted

Also covered: the prompt stays silent when nothing is expired, planning still writes nothing (including the trash), Get-StyleTrashSweepTarget reads without erasing since it runs pre-consent, and the anti-drift property — erases exactly what the prompt named, and nothing else, asserting the 2-day-old neighbour survives.

One test of mine failed for the wrong reason first: Should -Not -Match 'ERASE' is case-insensitive, so it matched the word "erased" in the undo line and failed on output that was correct. Tightened to '- ERASE '.

Full suite: 1453 passed, 0 failed, HOME sandboxed, real ~/.zshrc checksum-identical after.

🤖 Generated with Claude Code

https://claude.ai/code/session_01UHfeNid3QAWZENXUCYzfjv