disk-hygiene: the belt does not recognize Recycle Bin deletion, the very spelling the skill tells operators to prefer

[kyle-sexton]

Problem

The skill's manual-handoff lane instructs the operator to prefer reversible removal (Recycle Bin) over permanent deletion. On Windows, PowerShell has no native Recycle Bin delete — Remove-Item is always permanent — so the documented-preferred path requires either the Shell.Application COM interface or Microsoft.VisualBasic.FileIO.FileSystem.

The PowerShell belt does not recognize either as a deletion spelling. The skill therefore steers the operator toward exactly the spelling its own guard cannot see.

Reproduction

During a real cleanup session, six directories were removed with:

Add-Type -AssemblyName Microsoft.VisualBasic
[Microsoft.VisualBasic.FileIO.FileSystem]::DeleteDirectory($path,'OnlyErrorDialogs','SendToRecycleBin')

All six executed with no permission prompt from the belt, while the disk-hygiene clean skill was the active work and the belt was live. For comparison, the same session's Bash lane correctly denied a bare ls -d.

Paths removed this way: C:\cpx-fixture, C:\tmp\openai-docs-cache, C:\ccxp, C:\cpo-6495, C:\builds, C:\cpx-6586.

Every one of these was human-approved and engine-verified first, so nothing was lost — but that is the operator's discipline holding, not the guard's.

Why this is not merely the documented gap

reference/safety-model.md already discloses that the PowerShell lane is a raised bar rather than a fail-closed lane, and that move / rename / overwrite / volume-format spellings are not flagged. This is different in kind: it is not an unflagged adjacent operation, it is the primary deletion path the skill tells you to prefer, unflagged. A guard that catches Remove-Item but not the reversible spelling inverts the incentive — the more careful operator gets less oversight.

Proposed change

Recognize as deletion spellings, at minimum:

• Microsoft.VisualBasic.FileIO.FileSystem::DeleteDirectory / ::DeleteFile (any RecycleOption)
• Shell.Application NameSpace(...) .MoveHere / InvokeVerb('delete') against the bin
• Add-Type -AssemblyName Microsoft.VisualBasic immediately preceding a deletion call

Acceptance criteria

• A Recycle Bin deletion through either interface produces the same final human prompt as Remove-Item.
• The skill's "prefer reversible removal" instruction and the guard's coverage name the same set of spellings.

[kyle-sexton]

An independent /plugin-quality:audit pass over a separate /disk-hygiene:clean session reached the opposite conclusion on the same plugin version, and the source disagrees with this issue's premise. Posting the evidence here rather than filing a duplicate.

The belt does recognize these spellings in 0.17.9

skills/clean/scripts/destructive_guard.py:959-972:

_POWERSHELL_MUTATION_WORDS = re.compile(
    …
    r"remove-item|rm|rmdir|del|erase|rd|ri|clear-content|clear-recyclebin|rimraf|unlink"
    r"|sendtorecyclebin|deletefile|deletedirectory|removedirectory"
    …
)
_POWERSHELL_DOTNET_DELETE = re.compile(r"(?i)(::\s*delete|\.\s*delete\s*\()")

sendtorecyclebin, deletefile, and deletedirectory are all present, and _POWERSHELL_DOTNET_DELETE matches ::delete independently — so [Microsoft.VisualBasic.FileIO.FileSystem]::DeleteDirectory(...) matches on two separate patterns.

The plugin's own tests already assert it. skills/clean/scripts/test_hygiene.py:4570 and :4640 both carry the literal:

"[Microsoft.VisualBasic.FileIO.FileSystem]::DeleteFile('x', 'OnlyErrorDialogs', 'SendToRecycleBin')"

What likely happened instead — arguably a worse finding

In our session, 50 paths / 636,196,790 bytes were removed with exactly this spelling, and the operator's first-hand report was also "no prompt appeared". We recorded that as fact in our own evidence packet. It was wrong.

The operator later described the session as "just hitting approve, approve, approve" — the prompts did fire and were approved without being registered, inside a stream that also contained false positives such as 2>&1 being flagged as file-overwriting redirection (filed separately as a new issue).

So the detection mechanism worked and the human checkpoint did not.

If this issue rests on the same no-prompt-observed evidence, it may be measuring approval fatigue rather than a detection gap. Worth re-checking against the source before any patch to the mutation words, because a patch there would change nothing — the spellings are already covered and already tested.

Caveat

We did not run a controlled before/after (arm the belt, issue the spelling, observe with and without an intervening approval stream). The source and the shipped tests are the grounding for the detection claim; the habituation account is inference from the operator's own report, not an instrumented measurement.

Suggested reframing

If the maintainers agree, this issue may be more valuable retitled toward the real gap: the belt's ask verdicts are indistinguishable from routine prompts in a noisy stream, and nothing records whether a given ask was honoured or rubber-stamped. That is a genuine observability gap, and it survives regardless of which reading of the original report is correct.

[kyle-sexton]

Residual filed as issue 2850. The Shell.Application Recycle Bin patterns from PR 2639 are present on main and work for the spellings written against the bin. The gate requires a literal NameSpace(10)/NameSpace(0xa) token, so the ordinary send-to-bin form $sh.NameSpace(<folder path>).ParseName(<name>).InvokeVerb(delete) still returns no verdict. Decisive control: adding an inert NameSpace(10).Items().Count to the same command flips the identical delete verb from defer to ask.