Verdicts

Chaque élément reçoit un verdict pour chaque action possible, et ce verdict est accompagné de ses raisons. La couleur n'est jamais le seul signe : chaque verdict a son motif, son symbole et sa règle.

Les éléments Bloqués et Inconnus ne peuvent jamais être sélectionnés. Les éléments À vérifier ne sont nettoyés qu'avec « Inclure quand même ».

Quatre verdicts

Verdict Signification Au nettoyage
READYPrêt Toutes les vérifications sont passées pour cette action. Sélectionné d'emblée.
REVIEWÀ vérifier Un risque connu, ou une décision que vous seul pouvez prendre. Avec « Inclure quand même ».
BLOCKEDBloqué Utilisé, protégé, ou contient du travail que git refuserait de jeter. Impossible à sélectionner.
UNKNOWNInconnu Pas assez d'éléments. Impossible à sélectionner, jamais compté comme Prêt.

La ligne de commande affiche les mêmes verdicts en majuscules.

Raisons

Les raisons d'un verdict détaillent ce que l'on sait de l'élément. Par exemple :

  • À quel agent il appartient : « Fait partie d'une session Claude Code en cours », ou quel outil l'a créé.
  • S'il est utilisé : une session d'agent qui tourne dedans ou dans son dossier parent, un processus qui s'en exécute, un fichier ouvert.
  • Travail non enregistré : fichiers modifiés, non suivis ou indexés ; commits non poussés ; un verrou git.
  • Preuves : quand un nom seul ne suffit pas, le marqueur recherché, comme un package.json à côté de node_modules.

Prêt

Toutes les vérifications sont passées. Quand vous appuyez sur Nettoyer, l'élément est encore vérifié une fois ; si quelque chose a changé entre-temps, il n'y touche pas.

À vérifier

Le supprimer ne pose très probablement aucun problème, mais il y a quelque chose que Devbroom ne peut pas savoir. Par exemple :

  • Un fichier .env ignoré dans un worktree : git worktree remove le supprime sans demander. Un git status propre ne prouve pas qu'il n'y a rien de précieux à l'intérieur.
  • Le nom ressemble à un dossier de build, mais les fichiers de projet qui le prouveraient ne sont pas à côté.
  • Des noms vagues comme dist, build et vendor, sauf si un script de build les produit.
  • Des caches coûteux à télécharger de nouveau : le store pnpm, les navigateurs Playwright, les modèles Hugging Face.
  • Des dossiers que l'agent gère lui-même.

Bloqué

Y toucher maintenant pourrait casser le travail de quelqu'un :

  • Une session d'agent tourne dedans ou dans son dossier parent, un processus s'en exécute, ou un de ses fichiers est ouvert.
  • Un worktree avec des modifications non commitées, des fichiers non suivis ou des modifications indexées. Git ne le supprime pas sans --force ; Devbroom n'utilise jamais --force.
  • La copie de travail principale, un worktree avec des sous-modules, ou un worktree verrouillé par git.
  • Des fichiers protégés comme les bases de données et les identifiants des agents.
  • Ce qui ne doit être nettoyé qu'avec la commande propre à l'agent.

Inconnu

Impossible de savoir à quel agent cela appartient, ou une partie n'a pas pu être lue. Devbroom ne compte jamais comme Prêt ce qu'il ne connaît pas.

Vos propres règles

Un fichier .devbroom.toml à la racine d'un projet peut indiquer ce qui compte comme résultat de build dans ce projet. Comme un agent aurait pu écrire ce fichier lui aussi, la ligne de commande ne s'y fie pas sans demander : devbroom clean --yes exclut tout ce qui n'est Prêt qu'en raison de ce fichier.

PrécédentPrise en main SuivantRègles

Dernière mise à jour : 7 octobre 2026