タスク
タスクは 1 件の作業のコンテキスト、担当者、ステータス、実行履歴を 1 か所に保持します。
タスクは Clowld Space で作業を進める基本単位です。機能、バグ、調査など、メンバーまたはエージェントが責任を持って進める作業はすべてタスクになります。関連する議論、ステータスの変化、実行のたびの記録が同じ場所に残るため、チャット履歴やターミナルのログからコンテキストを組み立て直す必要はありません。
タスクの構成
| 内容 | 役割 |
|---|---|
| タイトルと説明 | 目的、背景、要件、受け入れ条件。 |
| ステータスと優先度 | 作業がどの段階にあり、何を先に進めるか。 |
| 担当者 | ワークスペースのメンバー、エージェント、またはスクワッド。 |
| 日付、ラベル、カスタムプロパティ | 計画、分類、チーム独自のフィールド。 |
| トピックと親子関係 | より大きな作業への所属、または子タスクへの分割。 |
| アクティビティと実行ログ | コメント、ステータス変更、実行、エージェントが返した結果。 |

タスクの作成
タスク ページまたはトピック内で作成します。タイトルだけで作成でき、ほかのプロパティは後からいつでも補えます。
各タスクには CS-123 のような番号が付きます。数字はワークスペース内で増えていき、管理者がワークスペースのタスクプレフィックスを変更すると、番号は新しいプレフィックスで表示されます。詳細はワークスペースを参照してください。
担当者の選択
| 担当者 | 効果 |
|---|---|
| メンバー | そのメンバーが作業を進めます。実行は作成されません。 |
| エージェント | そのエージェントの実行が 1 件作成されます。 |
| スクワッド | スクワッドのリーダーが受け取り、誰に任せるかを決めます。 |
エージェントまたはスクワッドに割り当てると、タスクが backlog にない限り即座にキューへ入ります。ランタイムがオフラインの場合、実行はキューで待機します。アーカイブ済みのエージェントとスクワッドには割り当てられません。
割り当てはエージェントのアクセス範囲(Access)を回避しません。スクワッドに割り当てる場合は、リーダーの Access が検証されます。詳細はタスクをエージェントに割り当てるを参照してください。
ステータス
どのワークスペースにも 7 つの組み込みステータスが用意されており、4 つのライフサイクルカテゴリに分類されます。
| カテゴリ | 組み込みステータス | 意味 |
|---|---|---|
unstarted | backlog、todo | まだ始まっていない作業。計画済みでも保留中でも同じです。 |
started | in_progress、in_review、blocked | 着手済み、確認待ち、または今は先に進めない状態。 |
done | done | 無事に完了した終了状態。 |
closed | cancelled | もう追いかけない終了状態で、成功による完了ではありません。 |
カテゴリはライフサイクルの判断を単純に保つためのものです。ボード、リスト、フィルタ、並び替えはいずれも個々のステータスを見ており、具体的なステータスにはエージェントや自動化が依存する細かい挙動が残ります。
| ステータス | 意味 |
|---|---|
backlog | まだ着手しない。エージェントに割り当て済みのタスクは、backlog を離れて初めて実行が作成されます。 |
todo | 内容が固まり、開始を待っている。 |
in_progress | 作業中。 |
in_review | 結果が出て、確認待ち。 |
done | 完了。 |
blocked | 今は先に進めない。 |
cancelled | 中止したが、記録は残す。 |
ステータス間に固定のフローはなく、メンバーもエージェントも直接変更できます。
エージェントは、作業がタスクに与えた実際の変化をそのままステータスに書き込みます。タスクが求めているもの(コードでも、調査でも、設計でも、タスク自身が求めるレビューでも)を作り始めた時点で in_progress に進め、実行中からボードに反映させます。納品したら in_review に進め、ターンを越えて作業が続く場合は in_progress のままにします。そのタスク自身の成果物を生まないターン(質問への回答、他所が持つ作業への助言)では、最初から最後までステータスを変更しません。これらの変更は、実行中にエージェントが Clowld Space CLI から明示的に書き込むものです。実行の開始や完了でサーバーがタスクのステータスを切り替えることはありません(下記の 2 つのシステム例外を除く)。done は通常、人による確認か、Closes CS-123 のような closing keyword を含む紐づき PR のマージによって設定されます。
次の 2 つの変更はシステムが行います。
- 実行が失敗し、そのタスクにほかの実行がなく、リトライも起動しなかった場合、
in_progressはtodoに戻ります。 - 開いている PR やドラフトがなく、マージ済みの PR に
Closes CS-123のような closing keyword がある場合、設定した状態へ変更します(既定は完了)。ワークスペースまたはタスクごとに変更を無効にできます。GitHub 連携を参照してください。
カスタムステータス
ワークスペースの owner または admin は、設定 → ステータスから独自のステータスを追加できます(Code Review、QA、Rework など)。どのステータスも 4 つのライフサイクルカテゴリのいずれかに属します。
| カテゴリ | ライフサイクル上の意味 |
|---|---|
unstarted | まだ始まっていない。組み込みの backlog と todo を含みます。 |
started | 進行中。確認待ちや返信待ちも含みます。 |
done | 無事に完了した終了状態。 |
closed | 中止、またはもう追いかけない終了状態で、成功による完了ではありません。 |
カスタムステータスが引き継ぐのはライフサイクル上の意味だけで、組み込みステータスの個別の挙動は引き継ぎません。backlog の保留、in_review によるオートパイロット実行の完了、blocked の失敗処理、in_progress の失敗からの復帰は、いずれも引き継がれません。その挙動が必要な場合は、対応する組み込みステータスを使ってください。以前に作られたカスタムステータスも同じルールに従います。Awaiting Response は進行中の作業であり、レビューの自動完了ではありません。割り当てと作成は、これまでどおり一般的なエージェントのトリガールールに従います。
プラットフォーム自身がステータスを設定するとき(todo への差し戻しや、マージされた PR による done)に書き込まれるのは、常に組み込みステータスです。
インストール済みのクライアント向けに、API の既存のカテゴリフィールドは 7 値の転送用 enum を返し続けます。新しいクライアントはそれを 4 つのカテゴリに正規化します。転送上の値が挙動の継承を与えることはありません。データベースに保存されるのは 4 つのライフサイクル値だけです。
ここから次の 4 点が導かれます。
- カテゴリは作成後に変更できません。 変更すると、すでにそのステータスにあるタスクの挙動を黙って書き換えることになるため、編集画面では読み取り専用です。まず挙動を決めてから名前を付けてください。
- ステータスによるグループ化は個々のステータスを使います。 ボードの列、リストのセクション、スイムレーンのステータス列は、組み込みステータスとカスタムステータスをそれぞれ区別します。
Code ReviewとQAはどちらもstartedに属していても、別々の列になります。カテゴリは内部的なライフサイクルの分類であり、列名の代わりではありません。 - 組み込みステータスはロックされています。 名前・色・カテゴリは変更できず、アーカイブもできません。このページを一度も開かないワークスペースのボードは、これまでとまったく同じままです。
- アーカイブは無効化であり、削除ではありません。 すでにそのステータスにあるタスクは、名前も色も挙動もそのままです。次に誰かがステータスを設定するときに、選択肢として出てこなくなるだけです。
組み込みステータスは表示言語に合わせて翻訳されますが、カスタムステータスは入力した名前がそのまま表示されます。API と CLI はキーで参照します: clowld issue status CS-42 code_review。設定ページではキーを名前から生成します。API では明示的に指定でき、省略した場合だけ名前から生成されます。いずれの場合もキーは作成時に確定し、あとで名前を変更してもキーは変わりません。
タスクと実行
タスクは継続して存在する作業の記録であり、実行はエージェントによる 1 回の具体的な実行です。1 つのタスクからは、最初の実装、追加の修正、再度の確認というように、複数の実行が順に生まれることがあります。実行の完了はその 1 回の実行が終わったことを意味するだけで、タスクが完了したかどうかはタスクのステータスで判断します。
トピックと子タスク
タスクは最大 1 つのトピックに属し、トピックはその中の実行に共有の説明とリソースを提供します。別のトピックへ移してもコピーは作られません。
大きな作業は子タスクに分割できます。親タスクが全体の目標を保持し、子タスクはそれぞれ独立して進みます。親子のステータスは連動しません。
子タスクにはステージ(stage)を設定でき、1、2、3 とバッチごとに進められます。未完了の最も早いステージのすべての子タスクが done または cancelled に到達すると、親タスクに子タスク完了の通知が届きます。親タスクの担当者がエージェントの場合は、そのエージェントが起こされ、次のステージへ進むかどうかを判断します。ステージ未設定の子タスクは同じバッチとして扱われ、すべて終了したときに一度だけ通知されます。
ビューの切り替え
タスクページには、リスト、ボード、テーブル、ガント、スイムレーンの 5 つのビューがあります。ステータス、担当者、トピックなどのプロパティで絞り込み・並べ替えでき、表示されるのはどれも同じタスクです。
タスクの削除
ワークスペースのメンバーは誰でもタスクを削除できます。
削除は元に戻せません。タスクとそのコメント、添付ファイル、関連レコードは完全に削除され、終了していない実行はキャンセルされます。作業を続けないだけであれば、ステータスを cancelled に変更してください。議論と結果は引き続き参照できます。
カスタム属性
所有者と管理者がワークスペース設定でフィールドを定義し、タスクを編集できるメンバーが値を入力します。1.2.7 の multi_text と multi_url は選択肢を事前定義しない自由入力の文字列リストです。
フィールドを開き、項目を入力して Enter で追加し、各行の削除ボタンで取り除きます。URL は http:// または https:// が必要で、重複値は追加されません。入力順と原文を保ちます。保存失敗時は下書きが残るため、原因を解消して再試行できます。最後の項目を削除すると値がクリアされます。
古いクライアントでは新しい型が読み取り専用になる場合があります。更新してから編集してください。アーカイブ済み属性への新規入力はできませんが、既存値はクリアできます。
次のステップ
- トピック — 複数のタスクで完了する作業を整理します。
- コメント — タスクを中心に議論、返信、@メンションを行います。
- タスクをエージェントに割り当てる — 作業をエージェントに渡して最初の実行を開始します。
- 実行 — キュー、実行、リトライ、キャンセルの仕組みを理解します。
タスク内のクイック移動
Web と Desktop のタイムライン横の目盛りから、説明・サブタスク・コメントスレッドへ移動できます。ホバーまたはフォーカスでプレビューし、サブタスクでは完了数と総数を確認できます。クリックは位置移動のみで状態を変更しません。説明だけのタスクと Mobile では表示されません。