The working order behind our disk audits

Readers deserve to know whether advice was assembled or merely typed. This desk runs every cleanup through the same five stages, in order, before publishing a word about it. The order appears throughout individual guides, so here it stands alone, quotable and disputable on its own merits.

Stage one: measure without editing

An audit begins by recording free space and largest movers with no deletions allowed yet, using whichever method from the checking basics reads fastest for that machine. Baselines taken mid-cleanup produce flattering fiction, which is why this stage forbids touching anything, however tempting.

Stage two: rank suspects before judgments

Growth gets attributed to named families, caches, snapshots, libraries, synced duplicates, with sizes attached, following the hunting craft described in the large-file search and, when trees swallow files, the terminal weighing from du and df practice. Attribution precedes action; acting on vibes is how healthy containers die young.

Stage three: act smallest-risk first

Trash families empty, then oversized strays leave, then selective cache trims per stated boundaries, while anything irreversible goes to an external drive instead of oblivion. Snapshots and system-managed regions wait untouched unless a specific failure justifies surgery, the position defended fully in the snapshot explainer.

A worked minute, to make stages concrete

Tuesday, afternoon: df reads sixty gigabytes free. Wednesday morning it reads fifty-eight, no installs between. Old habits would start deleting. The order instead asks two questions: which folder grew overnight per the du pair, and did a backup run fail meanwhile? Nine times out of ten the answer names snapshots or swap, both self-resolving, both documented across guides already linked above. Deletion never enters the conversation until stages one and two survive challenge twice.

Stages four and five: verify, then record

Rerun stage one's exact measurement after letting the system settle hours, not minutes, so thinning finishes honestly; record both figures and one line about what left, permanently, on sheets from the field kit page. Records make next quarter's audit archaeology-proof and give corrections a paper trail when reality disagrees with our instructions somewhere in the wild.

What the order deliberately refuses

Three shortcuts fail audits predictably, so the working order names them banned. Cleaning before baselining, because unrecorded recovery is unverifiable recovery. Sorting Library folders by size at midnight, because permission errors and system-owned containers punish exactly that curiosity, its legitimate limits being the entire subject of the cache etiquette page. And trusting any single figure printed in a storage chart, since two sources checked against each other cost one minute and save afternoons of blame aimed at innocent folders.

Where readers fit into the order

The same five stages work verbatim on your machine, which is their entire design goal; nothing here requires exotic equipment beyond patience and honesty about numbers. When any step misfires against your setup, report the divergence to the support desk: corrections apply publicly under policy rules, keeping this methodology accountable rather than ornamental.

Why publishing the order beats keeping it quiet

Method kept private protects nobody but its author. Written down, an order acquires witnesses: readers spot stage four shortcuts their machines resent, corrections arrive pointing at steps that failed on hardware we never touched, and revisions happen in daylight with dates attached. Every guide across Cleanup Guides cites these stages implicitly; this page makes the citations explicit so disagreement has somewhere precise to land. That is the entire ambition of a working order made public, and precisely why nothing here pretends invention: sequences survive because they work for strangers, not because someone guards them.

One closing note belongs in every reader's records alongside the five stages: exceptions discovered are contributions, not complaints. A stage that failed on hardware we never tested, a command whose output diverged from its description on your release, a boundary proved wrong in practice; each reports through the same mailbox as typos and receives the same public treatment. Methodology published this way improves at the speed of its readership rather than the speed of one desk's imagination, which is why transparency appears first among these stages' quiet virtues.