判定

すべての項目には、取りうる操作ごとに判定が付き、判定には理由が添えられます。色だけで区別することはありません。判定ごとに固有のパターン、マーク、ルールがあります。

ブロックと不明の項目は、どんな場合も選択できません。要確認の項目は「それでも含める」を選んだ場合にだけクリーンアップされます。

4 つの判定

判定	意味	クリーンアップ時
READY準備完了	この操作に必要なチェックにすべて合格しました。	最初から選択されています。
REVIEW要確認	既知のリスク、またはあなたにしか判断できないこと。	「それでも含める」で対象になります。
BLOCKEDブロック	使用中、保護対象、または git が破棄を拒む作業を含みます。	選択できません。
UNKNOWN不明	根拠が足りません。	選択できず、準備完了とは決して見なしません。

コマンドラインは同じ判定を大文字の英語で表示します。

理由

判定の理由は、その項目についてわかっていることを具体的に示します。たとえば:

どのエージェントのものか: 「実行中の Claude Code セッションの一部」、またはどのツールが作ったか。
使用中かどうか: その中か親フォルダで実行中のエージェントセッション、そこから実行中のプロセス、開かれたままのファイル。
保存されていない作業: 変更済み、未追跡、またはステージ済みのファイル。プッシュしていないコミット。git のロック。
根拠: 名前だけでは足りない場合に探すマーカー。たとえば node_modules の隣にある package.json。

準備完了

すべてのチェックに合格しています。「クリーンアップ」を押したときにも項目はもう一度チェックされ、その間に何か変わっていれば、その項目はそのまま残します。

要確認

削除してもまず問題ありませんが、Devbroom には知りえないことがあります。たとえば:

ワークツリー内の無視された .env ファイル: git worktree remove は確認なしにこれを削除します。git status がクリーンでも、中に大切なものがないとは限りません。
名前はビルドフォルダに見えるが、それを裏づけるプロジェクトファイルが隣にない。
dist、build、vendor のようなあいまいな名前。ビルドスクリプトが生成するものでない限り。
再ダウンロードにコストがかかるキャッシュ: pnpm ストア、Playwright のブラウザ、Hugging Face のモデル。
エージェント自身が管理しているフォルダ。

ブロック

今触れると、誰かの作業を壊すおそれがあります:

その中か親フォルダでエージェントセッションが実行中、そこからプロセスが実行中、または中のファイルが開かれている。
コミットされていない変更、未追跡のファイル、またはステージ済みの変更があるワークツリー。git は --force なしではこれを削除せず、Devbroom は --force を決して使いません。
メインの作業コピー、サブモジュールを含むワークツリー、または git がロックしているワークツリー。
エージェントのデータベースや認証情報などの保護されたファイル。
エージェント自身のコマンドでのみクリーンアップすべきもの。

不明

どのエージェントのものか判別できなかったか、一部を読み取れませんでした。Devbroom は、わからないものを準備完了と見なすことは決してありません。

独自のルール

プロジェクトのルートにある .devbroom.toml で、そのプロジェクトで何をビルド成果物と見なすかを指定できます。このファイルはエージェントが書いた可能性もあるため、コマンドラインは確認なしにはこれを信頼しません。devbroom clean --yes は、このファイルによってのみ準備完了になっているものを除外します。

前へはじめに 次へルール

最終更新: 2026年10月7日