P0-04: Reclaim Audit — measured, not guessed

Method: read-only du -sh/du -sk, find, tmutil listlocalsnapshots. No sudo used; anything that required privilege is marked “not measured (requires privilege)”. No files were deleted, moved, or modified. Measured on 2026-08-08, one machine, one user account.

Machine profile

• Boot volume (/dev/disk3s1s1, APFS container “Macintosh HD”): 926 GiB total, 135 GiB free (~15%). df reports 12 GiB “used” on the raw slice, which undercounts — the real footprint is spread across ~/Library (159G) and ~/code (113G) per du; the discrepancy is normal APFS container/snapshot accounting, not a measurement error.
• Two extra internal/external APFS volumes: One1TBBKP (931G, 469G used — backup disk), One1TBData (931G, 6.4G used — nearly empty).
• What kind of machine this is: professional, polyglot, AI-tooling-heavy developer machine. Evidence: 10+ active source repos under ~/code/dfacto.ai/ spanning finance/ trading, security, AI platform, networking, iOS; package manager caches for npm, pnpm, cargo, Go, Gradle, Maven, Homebrew all populated simultaneously; app-support directories for Claude, Cursor, Zed, JetBrains, VS Code, Antigravity, TabNine, kimi-desktop, Perplexity, AionUi (5+ AI coding tools installed at once); local LLM weights under ~/.lmstudio; Parallels VMs (112G); Docker/colima both present. Not a creative-editing or family/consumer machine — no evidence of Final Cut/Logic/Photoshop caches, and the Photos library is a modest 354M.

Ranked table — measured bytes on this machine

Sum of rows flagged “YES” (excluding the two out-of-scope 72G/39G outliers, excluding the unmeasured TM snapshots and incomplete system-cache floor): ≈ 60G of realistically reclaimable-or-reviewable data on this specific machine, concentrated almost entirely in developer tooling (simulator + package caches + docker + node_modules ≈ 51G of that 60G).

Expected finding: verify or refute?

Partially confirmed, with the composition being different than expected.

• “20-50GB of Xcode alone” — refuted for this machine. Xcode’s own artifacts (DerivedData/Archives/DeviceSupport/its cache) measure 0 bytes. This developer has Xcode installed but isn’t actively building against it.
• “simulator runtimes over 30GB” — refuted but close: 16G runtime + 7.7G devices = 23.7G, under the 30G bar, not over it.
• “50-500GB total across dev tooling” — confirmed at the low end: summing every legitimate dev-tooling bucket (simulator 23.7G + package caches 11.6G + Docker 5.6G + node_modules 10G) lands at ≈51G, comfortably inside the claimed range, and it dwarfs the combined generic-cache categories (user+system caches, logs, trash ≈ 5.5G) by roughly 9x.
• The bigger surprise the hypothesis didn’t predict: the single largest reclaimable- looking blob on the machine (72G) is neither Xcode nor a generic cache — it’s one specific app’s Application Support folder. A fixed category list, however well researched, will miss this class of finding. See module-priority item below.

Net verdict: developer artifacts do dwarf generic OS caches on this machine (as hypothesized), but the specific Xcode/simulator numbers were wrong in direction — the weight moved from “Xcode build products” to “simulator + package manager + docker” — and the single biggest folder on disk was an idiosyncratic app-data blob the fixed hypothesis never named.

Module priority — driving P3 implementation order

1. Trash empty — zero risk, zero regrowth, universal. Trivial to build, must exist.
2. Downloads installer sweep (*.dmg/*.pkg), with duplicate detection — zero regrowth, high confidence; the 3x UTM.dmg duplicate on this machine is the exact pattern a “you already have this” dedup check should catch.
3. Package manager cache sweep (npm/pnpm/yarn/cargo/go/gradle/maven/brew) — biggest FULL-regrowth bucket (11.6G here); safe because it always regenerates; universal across every dev machine regardless of what they’re building.
4. Xcode/simulator module: DerivedData (always safe, FULL regrowth) + stale/unused simulator devices (PARTIAL regrowth, needs “not booted recently” heuristic — 19 of 22 devices here are already near-empty stale shells) + unused runtimes for iOS versions no longer targeted by any installed project. This is the largest generic dev bucket when Xcode is actually in use, even though it measured near-zero on this particular snapshot of this machine.
5. node_modules sweep with staleness filter — only flag node_modules under projects whose git working tree / package.json hasn’t changed in N days; blanket deletion breaks the next npm run in an active project.
6. Docker prune (dangling images/volumes only, default-safe) — requires the daemon to be running to introspect via docker system df -v; must degrade gracefully (as this audit did) when it isn’t, rather than reporting nothing.
7. Generic “largest folders” scanner across ~/Library/Application Support and ~/Library/Containers, not a fixed category list — this is the meta-finding from rank #1 in the table above. A real product needs a fallback that surfaces “biggest folder we don’t have a named rule for” (LLM model weight dirs, VM disks, one-off app renders) because those can outweigh every named category combined.
8. User/system cache cleaning — keep it (users expect it, it’s the “obvious” feature) but do not market it as the primary win; on this data it’s ~5x smaller than dev tooling and ~25x smaller than the single largest outlier folder.
9. Log trimming with a retention window (e.g., keep 7-14 days) — moderate size, mostly one runaway log source (com.apple.diagnosticextensionsd, 1.1G alone here); don’t build per-source logic, just age-based trimming.
10. Large & old file finder (surface, don’t auto-delete) — good insight feature for files like this machine’s 6.5G personal video and 6.3G of LLM model weights; requires human judgment, not automation.
11. .lproj stripping — low priority; small yield (227M sampled here) and real risk of breaking code-signed app bundles on modern macOS. Consider skipping entirely for v1.
12. Time Machine local snapshot management — low priority; macOS self-manages this already based on free space, and sizes aren’t even readable without privilege. Only worth building if the product targets “disk nearly full” emergency scenarios.
13. Photos/Mail/iOS-backup cleanup — low priority on this measured machine (354M / 9M / 0B respectively) but see caveats: this is the category most likely to be completely wrong in priority order on a different kind of machine.

Caveats — n=1

• Single machine, single user account, single point in time. No statistical confidence; this is one professional developer’s Mac on 2026-08-08, not a representative sample.
• This machine is dev/AI-tooling-skewed, not creative or family. On a video/photo editing machine, expect: Photos library caches, DaVinci/Final Cut/Logic render caches, and iOS backups to dominate instead of node_modules/Xcode/Docker — none of which showed meaningfully on this machine (Photos 354M, Mail 9M, iOS backups 0B). On a family/consumer machine, expect dev-tooling categories (ranks 3-6 above, ~51G here) to collapse to near-zero, while Trash, Downloads, Photos, and iOS backups would carry the entire reclaim story.
• System-level caches were under-measured, not zero. /Library/Caches showed only 16M readable; the true figure is higher but requires sudo, which this audit was explicitly forbidden from using. Any product built on this data should re-verify with privileged access before finalizing marketing numbers for that category.
• Docker was not running during measurement (colima daemon down), so image/layer-level detail via docker system df -v wasn’t available — only directory-level size was measured, per the spec’s documented fallback.
• TM local snapshot sizes were not measured — tmutil listlocalsnapshots needs no privilege and gave a count (24), but per-snapshot size requires additional privileged tooling not available read-only.
• The single largest finding (72G videowallpaper folder) is this user’s own product build artifact, not a pattern any other Mac will share verbatim — but the category it represents (large, unnamed, app-specific Application Support blobs) generalizes and is the strongest argument in this whole audit for building a generic “biggest folders” scanner rather than trusting a fixed list, however well-researched.