状態の意味

フェーズ、ステータス、サブステータス、レビュー結果がそれぞれ何を表すのか、表示されたときに待てばよいのか、対処が必要なのかを説明します。

cdg status、cdg dag status、cdg task status は、フェーズ、ステータス、サブステータス、レビュー結果によって、ワークフローとタスクの現在の状態を表します。blocked、working、draining は、通常は待つだけでかまいません。on-hold、paused、killed のタスクと、done で止まってレビューを待っているタスクは、自動的には続行されないため、対処が必要です。対処方法は対処が必要なときを参照してください。

フェーズ

フェーズは、ワークフローまたはタスクが投入済みかどうか、レビュー済みかどうかを表し、planning、submitted、reviewed の順に進みます。ステータスボードでは、ワークフローとタスクがフェーズごとにグループ分けして表示されます。

フェーズ	意味
`planning`（計画中）	まだ投入されておらず、実行されません。書き終えてまだ投入していないワークフローは、このフェーズにあります。レビュー記録をクリアしたあとのワークフローとタスクもここに戻り、再投入できます。
`submitted`（投入済み）	投入済みで、最終的なレビューの結論がまだ出ていません。ワークフローは、キューで待っているか、実行中か、レビュー待ちです。ステータスとサブステータスがあるのは、このフェーズのワークフローとタスクだけです。
`reviewed`（レビュー済み）	最終的なレビューの結論が出ていて、これ以上実行されません。ワークフローはキューを離れています。タスクの結果を下流に渡せるかどうかは、そのレビュー結果で決まります。

タスクとワークフローには、それぞれ独自のフェーズがあります。タスクはワークフローと一緒に投入されますが、レビューはタスクごとに行われます。そのため、ワークフローがまだ submitted であっても、その中でレビューが済んだタスクは reviewed になり、cdg dag status では Reviewed Tasks のグループに表示されます。

reviewed が示すのは、レビューの結論が出たことだけで、結果がメインブランチに入ったことまでは意味しません。分離ブランチモードでは、承認された結果は統合ブランチ cdg/<ワークフロー名>/integration に残ります。共有ワークスペースモードでは、結果はワークスペースにある未コミットの変更です。メインブランチへのマージは自分で行います。仕上げ、マージ、クリーンアップを参照してください。

タスクのステータスとサブステータス

投入されてからレビューされるまでの間、タスクのその時点の状況はステータスとサブステータスで表されます。ステータスボードでは [pending] [blocked] のように 2 つ並んで表示され、前がステータス、後ろがサブステータスです。組み合わせは全部で 7 つあります。

ステータス	サブステータス	意味
`pending`（待機中）	`blocked`（上流待ち）	まだ開始されておらず、条件が整えば自動的に開始されます。依存している上流のタスクがすべて完了してレビューを通るのを待っているか、上流はすべてレビューを通っているものの、同時に実行されているタスクの数が同時実行数の上限に達しているかのどちらかです。後者は、たとえば分離ブランチモードで、空きワークスペースが一時的にない場合です。ワークフローがまだキューで待っている間は、そのタスクもすべてこの組み合わせになります。
`pending`	`on-hold`（保留）	保留になっていて、対処するまで続行できません。理由は `cdg task status` の `Reason:` 行に表示されます。保留は、開始前に起こることも、実行の途中で起こることもあります。開始前に起こるのは、たとえば、ワークスペースに未コミットの変更がある場合や、上流の結果をマージしたときのコンフリクトを自動では解決できなかった場合です。実行の途中で起こるのは、たとえば、Claude Code のセッションが API エラーで停止した場合で、このときもタスクは `pending` に戻ります。上流のレビューで下流を保留にすることを選んだ場合も、下流はここで止まります。
`in-progress`（実行中）	`working`	タスクエージェントが実行中です。エージェントがセッションの中で操作の許可を待っているときも、タスクは `working` と表示されます。
`in-progress`	`draining`（ドレイン中）	タスクは一時停止されていますが、CodeDAG は作業中のタスクエージェントを中断しません。エージェントが現在のターンの作業を終えると、タスクは `paused` になります。それまでは、エージェントがファイルを変更することがあります。
`stopped`（停止中）	`paused`	一時停止され、その場で止まっています。自動的には続行されません。まだ開始されていないタスクに `kill` を実行した場合も、`paused` になります。
`stopped`	`killed`	強制停止されています。タスクエージェントの現在の出力はすぐに中断されますが、セッションは残るので、あとから元のセッションで続行できます。
`done`（完了）	`done`	実行が終わり、レビューを待っています。デフォルトでは自動承認され、タスクはすぐに `reviewed` に入るため、この組み合わせは一瞬しか表示されません。タスクのレビューポリシーが `none` の場合は、ここで止まってレビューを待ちます。分離ブランチモードのタスクは、変更を何も残さなかった場合、自動承認を設定していてもここで止まり、`cdg dag status` はその行の末尾に `zero output, awaiting manual review` と表示します。共有ワークスペースモードでは、こうしたタスクも通常どおり自動承認され、`zero output` とだけ表示されます。

ワークフローのステータスとサブステータス

ワークフローのステータスは、まだレビューされていないすべてのタスクの状況をまとめて表します。実行中のタスクが 1 つでもあれば、ワークフローは in-progress です。pending、stopped、done と表示されるのは、実行中のタスクがないときだけです。そのため、ワークフロー全体が止まっているかどうかを知りたいときは、まずステータスが in-progress かどうかを確認します。

一部のタスクが一時停止または強制停止されている場合

次の 3 つのサブステータスはワークフローにだけあり、一部のタスクだけを一時停止、強制停止、または復旧したときに現れます。ステータスはいずれも in-progress で、ワークフローがまだ完全には止まっていないことを表します。

ステータス	サブステータス	意味
`in-progress`	`draining-with-working`	一部のタスクが一時停止され、現在のステップを終えようとしています。ほかのタスクは通常どおり実行中です。
`in-progress`	`paused-with-active`	一部のタスクがすでに一時停止していて、ほかのタスクは実行中か、現在のステップを終えようとしています。
`in-progress`	`killed-with-active`	一部のタスクがすでに強制停止されていて、ほかのタスクは実行中か、現在のステップを終えようとしています。

一時停止または強制停止されたタスクは、自動的には続行されません。残りのタスクは通常どおり実行され、その下流も通常どおり開始されます。実行中のタスクがなくなると、ワークフローは [stopped] [paused] または [stopped] [killed] になり、そのまま止まり続けます。キューの後ろに並んだワークフローも、このワークフローが復旧されるかレビューされるまで待つことになります。ワークフロー全体を止めたい場合は、ワークフローに対して cdg dag pause または cdg dag kill を使います。2 つの違いは、制御コマンドの構文と適用できる状態を参照してください。

タスクと同じ名前のサブステータス

それ以外のサブステータスは、タスクのサブステータスと名前も意味も同じで、ワークフロー内のタスクについて述べている点だけが異なります。たとえば [stopped] [paused] は、実行中のタスクがなく、少なくとも 1 つのタスクが一時停止されていることを表します。このうちいくつかの組み合わせは、ワークフローでは追加の意味を持ちます。

[pending] [blocked]：実行中のタスクがなく、開始を待っているタスクが残っています。投入したばかりでキューで待っているワークフローは、この組み合わせになります。実行の途中でも、残りのタスクがどれも、done で止まってレビュー待ちになっている上流を待っている場合、ワークフローは同じ組み合わせで表示されます。このとき、ワークフローは自動的には続行されません。
[pending] [on-hold]：実行中のタスクがなく、少なくとも 1 つのタスクが保留になっています。ワークフローそのものが保留になっている場合もあります。たとえば、CodeDAG クレジットが足りずに開始できない場合や、すべてのタスクが終わったあとの統合ブランチへのマージで、自動では解決できないコンフリクトが起きた場合です。ワークフローそのものが保留になった理由は、cdg dag status の Reason: 行に表示され、cdg status でも、ワークフローのファイル名の後ろに括弧付きで表示されます。
[done] [done]：開始を待っているタスクも、実行中のタスクも、止まっているタスクもありません。ただし、レビューが終わっているとは限りません。done で止まってレビューを待っているタスクが残っていることがあります。また、すべてのタスクのレビューが済んでいて、ワークフロー全体のレビューポリシーが none（dagAutoAccepted: none）の場合、ワークフローはここで止まり、ワークフロー全体に対する結論を待ちます。

ワークフローのサブステータスが表せるのは、1 種類のタスクの状況だけです。実行中のタスクは保留のタスクより優先されるため、ワークフローが [in-progress] [working] と表示されていても、on-hold で止まっているタスクがあるかもしれません。同じように、[stopped] [paused] のワークフローにも、保留になっているタスクがあるかもしれません。各タスクの実際の状況は、cdg dag status の各タスクの行で確認してください。

done と reviewed の違い

done はステータスで、タスクエージェントの作業は終わったものの、結果がまだ認められていないことを表します。reviewed はフェーズで、レビューの結論が出たことを表します。この 2 つの間には、レビューゲートがあります。デフォルトではゲートを自動的に通るため、done は一瞬しか表示されないことがほとんどです。タスクやワークフローが done で止まっているときは、結論が出されるのを待っています。結論が出るまで、そのタスクに依存する下流のタスクは開始されません。[done] [done] のワークフローもキューに残ったままで、後ろに並んだワークフローは開始されません。

cdg dag status では、この 2 つは別のグループに表示されます。done のタスクは Submitted Tasks のグループに残り、[done] [done] と表示されます。reviewed に入ったタスクは Reviewed Tasks のグループに移り、レビュー結果だけが表示されます。

レビュー結果

reviewed に入ったタスクとワークフローには、最終的な結論を記録するレビュー結果が 1 つ付きます。承認された結果は引き続き使えますが、キャンセルまたは見送りになった結果は下流に渡されません。

結果	意味
`accepted`（承認済み）	`accept` で結果が承認されています。タスクの結果は下流に渡されます。分離ブランチモードでは、ワークフローの結果は統合ブランチに残ります。
`auto-accepted`（自動承認）	自動承認の設定に従って、CodeDAG が自動的に承認しています。効果は `accepted` と同じです。
`cancelled`（キャンセル済み）	`cancel` でキャンセルされています。この結果は使わないという結論です。分離ブランチモードでは、キャンセルされたタスクの結果は下流に渡されず、統合ブランチにもマージされません。キャンセルされたのがワークフローの場合は、統合ブランチが今回のワークフローのベースに戻ります。
`deferred`（見送り）	`defer` で見送られています。このステップは今回は完了させず、あとで対処するという結論です。結果の扱いは `cancelled` と同じです。

レビューのときに下流へカスケードすることを選ぶと（--downstream cascade）、レビューの対象に直接または間接的に依存していてまだ開始されていない下流のタスク、またはキューの後ろに並んだワークフローにも、同じ cancelled または deferred が付きます。それらが一度も実行されていなくても同じです。

ワークフロー全体に結論を出すと、すでに実行が始まっていてまだレビューされていないタスクには、ワークフローと同じ結果が付きます。まだ開始されていないタスクには、レビュー結果が付きません。こうしたタスクは、個別にレビューされないまま、ワークフローと一緒に reviewed に入ります。cdg dag status では Unreviewed Tasks のグループに表示され、cdg task status の Disposition: 行には unreviewed と表示されます。どちらにも、止まった時点のステータスとサブステータスがそのまま残ります。

キャンセルまたは見送りのとき、タスクがすでに加えた変更をどう扱うかは、分離ブランチモードでは、レビュー時の --code オプションで決まります。スナップショットブランチへの保存、コミット、破棄のいずれかです。共有ワークスペースモードにはタスクブランチがないため、変更はワークスペースに残り、下流からもそのまま見えます。この変更は自分で処理します。オプションに指定できる値とデフォルト値は、--code を参照してください。

レビュー結果を、別の結果に直接変更することはできません。結論を変えたい場合や、もう一度実行したい場合は、先にワークフローのレビュー記録をクリアして planning に戻してから、再投入します。レビュー記録のクリアと再投入を参照してください。

対処が必要なとき

blocked、working、draining は、通常は待つだけでかまいません。自動的に次の状態に進むからです。一方、以下の場合は対処が必要です。対処しないと、タスクやワークフローだけでなく、キューの後ろに並んだワークフローまで止まったままになります。

表示される状況	対処方法
タスクまたはワークフローが `on-hold` になっている	まず `cdg task status <タスク ID> -w <ワークフロー>` で `Reason:` 行を確認します。ワークフローそのものが保留になっている場合は、`cdg dag status` の `Reason:` 行を確認します。理由に応じて対処してから、`cdg task recover` または `cdg dag recover` を実行します。理由ごとの対処手順は、タスクまたはワークフローが on-hold で止まっているを参照してください。
タスクが `paused` または `killed` になっている、あるいはワークフローが `stopped` またはいずれかの `-with-active` の組み合わせになっている	`unpause` または `recover` で、止まっているタスクを続行させます。もう必要がなければ、`cancel` または `defer` でそのまま終わらせることもできます。コマンドの書き方は制御と介入、どの操作を選ぶかは介入と制御を参照してください。
タスクが `done` で止まっている、またはワークフローが `[done] [done]` で止まって結論を待っている	結果を確認してから、`cdg task review` または `cdg dag review` で結論を出します。タスクとワークフローをレビューするを参照してください。タスクがここで止まる理由は、タスクが done で止まったまま進まないを参照してください。
タスクまたはワークフローが長い間 `blocked` のままになっている	何を待っているのかを確認します。タスクの場合は依存している上流を、キューで待っているワークフローの場合はキューの先頭のワークフローを見ます。その相手が `done`、`on-hold`、`stopped` のいずれかで止まっている場合は、そちらに対処すれば、待っている側は自動的に続行されます。キューで待っているワークフローの調べ方は、キューの後ろのワークフローが開始されないを参照してください。分離ブランチモードでは、`done` で止まってレビューを待っているタスクも自分のワークスペースを占有したままなので、ほかのタスクが空きワークスペースを待ち続ける原因にもなります。
タスクがずっと `working` のままなのに、ログに長い間新しい出力がない	止まったままになっているとは限りません。エージェントがサブエージェントを起動してバックグラウンドで作業させているか、セッションの中で操作の許可を待っている可能性があります。見分け方は、止まったままかどうかを見分けるにはを参照してください。
サブステータスが `working (stale owner)` と表示されている	タスクは実行中として記録されたままですが、それを実行していたプロセスがすでに存在しません。たとえば、コンピューターを再起動したあとです。`cdg status` のキュービューには個々のタスクが表示されないため、この場合は、ワークフローの行の下に `Diagnostic:` 行だけが表示されます。ステータスを確認するコマンドは状況を表示するだけで、スケジューリングを再び動かすことはありません。`Diagnostic:` 行の案内に従って復旧して初めて、タスクは元のセッションで続行されます。コンピューターの再起動またはプロセスのクラッシュのあとを参照してください。

目次