Why Twelve Identical Stashes Made Us Stop Before Deleting Anything

Twelve matching bundles of unfinished work were sitting in nearly every workspace we checked, in the same pattern and the same order. We don’t know how long they had been there. Twelve identical leftovers is the kind of find that makes a person want to grab a broom.

We slowed down instead.

A stash is a small saved bundle of unfinished changes that gets put aside for later. Think of it like a bag of receipts tucked into a kitchen drawer because you mean to sort them another day. One bag is ordinary. Finding the same bag, with the same receipts in the same order, in nearly every drawer is different. It suggests the drawers were copied from one original drawer.

That was a clue, not a conclusion.

The count was not enough

At first, the matching count seemed like enough. It wasn’t. A count tells you a pattern exists. It can’t tell you whether those bundles are old clutter or somebody’s unfinished work. We could have treated the number as a cleanup list, and it would have been quick, but it would not have been careful.

Our first approach, trusting the summary alone, did not work. It cost us time, because we had to stop, go beneath the count and compare the actual records. That is a better cost than deleting work and asking questions afterward.

Independent places usually collect different kinds of mess. One has an experiment that went nowhere. One is tidy. One has a recent detour nobody has cleaned up yet. When the incidental details match exactly, it is reasonable to ask whether those places came from the same prepared copy instead of being made separately. Reasonable is not the same as proven.

What we checked

We treated the pattern as a question. We compared a small, authorized sample instead of assuming every match meant the same thing. We checked whether the entries really matched, whether their history and order matched, and whether there was a documented path that could explain how the copies came to exist. We also checked a trusted inventory to see which copies existed and which were still active.

That last part matters more than it sounds. The activity screen showed active workspaces, not every workspace that existed. Had we used it as the whole truth, we could have cleaned only part of the problem, missed the inactive copies and told ourselves the job was done.

It is like clearing the coats from the hooks by the front door and announcing that the house is tidy. There may still be jackets in the closet, on the chair upstairs or in the back of a car. The view was useful. It just had limits.

What has to be in place before anything is deleted

Once repeated leftovers have been checked and shown to be stale, cleaning them up can help. It removes noise and makes real unfinished work easier to notice. But the cleanup has to leave room for exceptions, because the one bundle that still matters is the one that makes a broad sweep dangerous.

Before changing anything, we would want four things:

1. A full list from a source meant to be complete, not whichever report happens to be open.
2. A clear check for active ownership. If a person or process is still using something, that matters more than tidiness.
3. A documented way to recover the work if the judgment is wrong.
4. Small steps with a check after each one, rather than one large action and a hope that it landed cleanly.

We would also write down why the repeated bundles were treated as duplicates, who approved the call and what the recovery plan was. Months later, that lets someone understand the decision without guessing what the pattern meant at the time.

A very neat pattern can point back to a shared past. The copies may have started from the same prepared snapshot. They may have carried more history forward than anyone meant to carry. Or they may include work that still belongs to someone. The pattern gives us a place to investigate. It does not give us permission to erase.

Twelve is still the number that matters. Whatever gets swept, the recovery plan and the ownership check have to account for all twelve, not just the ones the activity screen happened to show. The count that made us want to grab a broom is the same count we now use to prove we looked in every drawer before touching one.

dxdev LESSON · paste into your AI coding agent
LESSON: A suspiciously uniform pattern across independent places is a question to investigate, not permission to clean up
SOURCE: dxdev.com/everyday-ai/twelve-matching-bundles-were-not-a-cleaning
WHAT HAPPENED: Twelve matching leftover stashes, small saved bundles of unfinished changes, turned up in the same pattern and the same order across nearly every workspace checked, a uniformity that made it tempting to treat the count as a straightforward cleanup list. Independent workspaces usually collect different kinds of leftover mess, so an exact match across many of them suggested they'd been copied from one prepared original rather than accumulated separately, though that was a clue and not proof. A dashboard used to check which workspaces existed and were active turned out to only show active ones, not a complete inventory; using it as the whole truth risked cleaning only part of the problem while missing quiet, inactive copies entirely. The eventual approach compared a small authorized sample directly, checked whether the entries, their history, and their order genuinely matched, looked for a documented path explaining how the copies came to exist, and confirmed via a trusted, complete inventory rather than the activity screen alone.
THE RULE: A suspiciously uniform pattern across independent places is a signal to investigate a shared origin, not a green light to delete. Before any bulk cleanup, get a full list from a source that's actually complete rather than whichever report happens to be open, check for active ownership, and make sure there's a documented recovery path if the judgment turns out wrong.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any bulk-cleanup decision, leftover branches, cached copies, stale stashes, made from a pattern-match count alone, without checking whether the matching items share a documented, verified origin.
  2. Any inventory or activity dashboard being treated as the complete list of what exists, when it's actually scoped to only active or currently-visible items.
  3. Any destructive cleanup operation run as one large sweep rather than small staged steps with a check after each, or run without a documented recovery plan.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.