Problem
/disk-hygiene:clean rejects an OS-managed volume root such as C: outright. That guard is correct — nothing should walk the system volume — but it leaves no supported path for the common real case: a handful of non-system, user-created directories sitting at the volume root, which is exactly the kind of orphaned state the skill exists to find.
Evidence
A session auditing C:\ found six user-created directories at the root (builds, ccxp, cpo-6495, cpx-6586, cpx-fixture, tmp), holding 4.8 GB of residue between them. Reaching them required hand-simulating the missing capability: six separate single-directory invocations, six snapshots, six run directories, with the operator enumerating the root by hand for what is experienced as one job.
Everything else at that root was OS-owned, hidden, system, or a reparse point — i.e. the exclusion the guard exists to enforce was trivially satisfiable, and the interesting entries were all plainly user-created.
Proposed change — "root-children mode"
Accept an OS-managed volume root as a target only in an explicitly bounded mode that:
- Enumerates the root's immediate entries only — never walks the root itself.
- Hard-excludes OS-owned, hidden, system, and reparse entries under the existing guard rules.
- Presents the surviving candidates for explicit human selection — the mode never infers which directories are in scope.
- Scans the selected subtrees as a single multi-subtree run producing one snapshot and one report.
The guard's refusal to walk the root itself is preserved; what changes is that the root becomes addressable as a listing, not as a scan target.
Acceptance criteria
- Targeting
C: without the new mode still fails exactly as it does today.
- In the new mode, the root's own files and OS-owned entries are never scanned or offered.
- Selection is explicit and prompted; a general "clean everything" is not selection.
- One run directory, one snapshot, one report covers all selected subtrees.
Problem
/disk-hygiene:cleanrejects an OS-managed volume root such asC:outright. That guard is correct — nothing should walk the system volume — but it leaves no supported path for the common real case: a handful of non-system, user-created directories sitting at the volume root, which is exactly the kind of orphaned state the skill exists to find.Evidence
A session auditing
C:\found six user-created directories at the root (builds,ccxp,cpo-6495,cpx-6586,cpx-fixture,tmp), holding 4.8 GB of residue between them. Reaching them required hand-simulating the missing capability: six separate single-directory invocations, six snapshots, six run directories, with the operator enumerating the root by hand for what is experienced as one job.Everything else at that root was OS-owned, hidden, system, or a reparse point — i.e. the exclusion the guard exists to enforce was trivially satisfiable, and the interesting entries were all plainly user-created.
Proposed change — "root-children mode"
Accept an OS-managed volume root as a target only in an explicitly bounded mode that:
The guard's refusal to walk the root itself is preserved; what changes is that the root becomes addressable as a listing, not as a scan target.
Acceptance criteria
C:without the new mode still fails exactly as it does today.