Verdetti

Ogni elemento riceve un verdetto per ogni azione possibile, e il verdetto arriva con i suoi motivi. Il colore non è mai l'unico segnale: ogni verdetto ha il suo motivo grafico, il suo simbolo e la sua regola.

Gli elementi Bloccati e Sconosciuti non si possono selezionare, mai. Gli elementi Da verificare vengono puliti solo con “Includi comunque”.

Quattro verdetti

Verdetto Cosa significa Durante la pulizia
READYPronto Tutti i controlli superati per questa azione. Già selezionato.
REVIEWDa verificare Un rischio noto, o una decisione che spetta solo a te. Con “Includi comunque”.
BLOCKEDBloccato In uso, protetto, o contiene lavoro che git si rifiuterebbe di buttare via. Non selezionabile.
UNKNOWNSconosciuto Prove insufficienti. Non selezionabile, mai considerato Pronto.

La riga di comando mostra gli stessi verdetti in maiuscolo.

Motivi

I motivi di un verdetto spiegano ciò che si sa dell'elemento. Per esempio:

  • A quale agente appartiene: “Parte di una sessione di Claude Code in esecuzione”, o quale strumento lo ha creato.
  • Se è in uso: una sessione di agente in esecuzione al suo interno o nella cartella superiore, un processo che parte da lì, un file tenuto aperto.
  • Lavoro non salvato: file modificati, non tracciati o nell'area di staging; commit non inviati con push; un lock di git.
  • Prove: dove il nome da solo non basta, il marcatore che cerca, come un package.json accanto a node_modules.

Pronto

Tutti i controlli superati. Quando premi Pulisci l'elemento viene comunque controllato ancora una volta; se nel frattempo qualcosa è cambiato, viene lasciato stare.

Da verificare

Eliminarlo va quasi certamente bene, ma c'è qualcosa che Devbroom non può sapere. Per esempio:

  • Un file .env ignorato in un worktree: git worktree remove lo elimina senza chiedere. Un git status pulito non prova che dentro non ci sia nulla di valore.
  • Il nome sembra quello di una cartella di build, ma i file di progetto che lo dimostrerebbero non sono accanto.
  • Nomi generici come dist, build e vendor, a meno che non li produca uno script di build.
  • Cache costose da riscaricare: lo store di pnpm, i browser di Playwright, i modelli di Hugging Face.
  • Cartelle che l'agente gestisce da sé.

Bloccato

Toccarlo adesso potrebbe rovinare il lavoro di qualcuno:

  • Una sessione di agente è in esecuzione al suo interno o nella cartella superiore, un processo parte da lì, o un suo file è tenuto aperto.
  • Un worktree con modifiche non salvate in un commit, file non tracciati o modifiche nell'area di staging. Git non lo rimuove senza --force; Devbroom non usa mai --force.
  • La copia di lavoro principale, un worktree con submodule, o uno bloccato da git.
  • File protetti come i database e le credenziali degli agenti.
  • Cose che vanno pulite solo con il comando dell'agente.

Sconosciuto

Non è stato possibile capire a quale agente appartenga, o una parte non era leggibile. Devbroom non considera mai Pronto qualcosa che non conosce.

Le tue regole

Un .devbroom.toml nella radice di un progetto può indicare cosa conta come output di build in quel progetto. Dato che anche quel file potrebbe averlo scritto un agente, la riga di comando non se ne fida senza chiedere: devbroom clean --yes esclude tutto ciò che è Pronto solo grazie a quel file.

PrecedentePer iniziare SuccessivoRegole

Ultimo aggiornamento: 7 ottobre 2026