Verdicts

Every item gets a verdict for every action that could be taken, and the verdict comes with its reasons. Color is never the only sign: each verdict has its own pattern, its own mark and its own rule.

Blocked and Unknown items can't be selected, ever. Review items are cleaned only with “Include anyway”.

Four verdicts

Verdict What it means When cleaning
READYReady Every check passed for this action. Selected from the start.
REVIEWReview A known risk, or a call only you can make. With “Include anyway”.
BLOCKEDBlocked In use, protected, or holding work git would refuse to throw away. Can't be selected.
UNKNOWNUnknown Not enough evidence. Can't be selected, never counted as Ready.

The command line prints the same verdicts in capitals.

Reasons

A verdict's reasons spell out what's known about the item. For example:

  • Which agent it belongs to: “Part of a running Claude Code session”, or which tool made it.
  • Whether it's in use: an agent session running in it or in its parent folder, a process running from it, a file held open.
  • Unsaved work: modified, untracked or staged files; unpushed commits; a git lock.
  • Evidence: where a name alone isn't enough, the marker it looks for, such as a package.json beside node_modules.

Ready

Every check passed. When you press Clean the item is still checked once more; if anything changed in between, it's left alone.

Review

Deleting it is very likely fine, but there's something Devbroom can't know. For example:

  • An ignored .env file in a worktree: git worktree remove deletes it without asking. A clean git status doesn't prove there's nothing of value inside.
  • The name looks like a build folder, but the project files that would prove it aren't beside it.
  • Vague names such as dist, build and vendor, unless a build script produces them.
  • Caches that are expensive to download again: the pnpm store, Playwright browsers, Hugging Face models.
  • Folders the agent manages itself.

Blocked

Touching it now could break someone's work:

  • An agent session runs in it or in its parent folder, a process runs from it, or a file in it is held open.
  • A worktree with uncommitted changes, untracked files or staged changes. Git won't remove it without --force; Devbroom never uses --force.
  • The main working copy, a worktree with submodules, or one git has locked.
  • Protected files such as agents' databases and credentials.
  • Things that should be cleaned only with the agent's own command.

Unknown

It couldn't tell which agent this belongs to, or part of it couldn't be read. Devbroom never counts something it doesn't know as Ready.

Your own rules

A .devbroom.toml at a project's root can say what counts as build output in that project. Since an agent could have written that file too, the command line doesn't trust it without asking: devbroom clean --yes leaves out anything that's Ready only because of that file.

PreviousGetting started NextRules

Last updated: October 7, 2026