タスク

タスクは Multica で作業を進める基本単位です。機能、バグ、調査など、メンバーまたはエージェントが責任を持って進める作業はすべてタスクになります。関連する議論、ステータスの変化、実行のたびの記録が同じ場所に残るため、チャット履歴やターミナルのログからコンテキストを組み立て直す必要はありません。

タスクの構成

タスクの作成

タスク ページまたはプロジェクト内で作成します。タイトルだけで作成でき、ほかのプロパティは後からいつでも補えます。

各タスクには MUL-123 のような番号が付きます。数字はワークスペース内で増えていき、管理者がワークスペースのタスクプレフィックスを変更すると、番号は新しいプレフィックスで表示されます。詳細はワークスペースを参照してください。

担当者の選択

エージェントまたはスクワッドに割り当てると、タスクが backlog にない限り即座にキューへ入ります。ランタイムがオフラインの場合、実行はキューで待機します。アーカイブ済みのエージェントとスクワッドには割り当てられません。

割り当てはエージェントのアクセス範囲（Access）を回避しません。スクワッドに割り当てる場合は、リーダーの Access が検証されます。詳細はタスクをエージェントに割り当てるを参照してください。

ステータス

どのワークスペースにも 7 つの組み込みステータスが用意されており、4 つのライフサイクルカテゴリに分類されます。

カテゴリはライフサイクルの判断を単純に保つためのものです。ボード、リスト、フィルタ、並び替えはいずれも個々のステータスを見ており、具体的なステータスにはエージェントや自動化が依存する細かい挙動が残ります。

ステータス間に固定のフローはなく、メンバーもエージェントも直接変更できます。

エージェントは、作業がタスクに与えた実際の変化をそのままステータスに書き込みます。タスクが求めているもの（コードでも、調査でも、設計でも、タスク自身が求めるレビューでも）を作り始めた時点で in_progress に進め、実行中からボードに反映させます。納品したら in_review に進め、ターンを越えて作業が続く場合は in_progress のままにします。そのタスク自身の成果物を生まないターン（質問への回答、他所が持つ作業への助言）では、最初から最後までステータスを変更しません。これらの変更は、実行中にエージェントが Multica CLI から明示的に書き込むものです。実行の開始や完了でサーバーがタスクのステータスを切り替えることはありません（下記の 2 つのシステム例外を除く）。done は通常、人による確認か、ワークスペースがマージ後の変更先を done にしている場合の紐づき PR のマージによって設定されます。

カスタムステータス

ワークスペースの owner または admin は、設定 → ステータスから独自のステータスを追加できます（Code Review、QA、Rework など）。どのステータスも 4 つのライフサイクルカテゴリのいずれかに属します。

カスタムステータスが引き継ぐのはライフサイクル上の意味だけで、組み込みステータスの個別の挙動は引き継ぎません。backlog の保留、in_review によるオートパイロット実行の完了、blocked の失敗処理、in_progress の失敗からの復帰は、いずれも引き継がれません。その挙動が必要な場合は、対応する組み込みステータスを使ってください。以前に作られたカスタムステータスも同じルールに従います。Awaiting Response は進行中の作業であり、レビューの自動完了ではありません。割り当てと作成は、これまでどおり一般的なエージェントのトリガールールに従います。

プラットフォーム自身がステータスを設定するとき（todo への差し戻しや、マージされた PR による done）に書き込まれるのは、常に組み込みステータスです。

インストール済みのクライアント向けに、API の既存のカテゴリフィールドは 7 値の転送用 enum を返し続けます。新しいクライアントはそれを 4 つのカテゴリに正規化します。転送上の値が挙動の継承を与えることはありません。データベースに保存されるのは 4 つのライフサイクル値だけです。

ここから次の 4 点が導かれます。

• カテゴリは作成後に変更できません。 変更すると、すでにそのステータスにあるタスクの挙動を黙って書き換えることになるため、編集画面では読み取り専用です。まず挙動を決めてから名前を付けてください。
• ステータスによるグループ化は個々のステータスを使います。 ボードの列、リストのセクション、スイムレーンのステータス列は、組み込みステータスとカスタムステータスをそれぞれ区別します。Code Review と QA はどちらも started に属していても、別々の列になります。カテゴリは内部的なライフサイクルの分類であり、列名の代わりではありません。
• 組み込みステータスはロックされています。 名前・色・カテゴリは変更できず、アーカイブもできません。このページを一度も開かないワークスペースのボードは、これまでとまったく同じままです。
• アーカイブは無効化であり、削除ではありません。 すでにそのステータスにあるタスクは、名前も色も挙動もそのままです。次に誰かがステータスを設定するときに、選択肢として出てこなくなるだけです。

組み込みステータスは表示言語に合わせて翻訳されますが、カスタムステータスは入力した名前がそのまま表示されます。API と CLI はキーで参照します: multica issue status MUL-42 code_review。設定ページではキーを名前から生成します。API では明示的に指定でき、省略した場合だけ名前から生成されます。いずれの場合もキーは作成時に確定し、あとで名前を変更してもキーは変わりません。

タスクと実行

タスクは継続して存在する作業の記録であり、実行はエージェントによる 1 回の具体的な実行です。1 つのタスクからは、最初の実装、追加の修正、再度の確認というように、複数の実行が順に生まれることがあります。実行の完了はその 1 回の実行が終わったことを意味するだけで、タスクが完了したかどうかはタスクのステータスで判断します。

プロジェクトと子タスク

タスクは最大 1 つのプロジェクトに属し、プロジェクトはその中の実行に共有の説明とリソースを提供します。別のプロジェクトへ移してもコピーは作られません。

大きな作業は子タスクに分割できます。親タスクが全体の目標を保持し、子タスクはそれぞれ独立して進みます。親子のステータスは連動しません。

子タスクにはステージ（stage）を設定でき、1、2、3 とバッチごとに進められます。未完了の最も早いステージのすべての子タスクが done または cancelled に到達すると、親タスクに子タスク完了の通知が届きます。親タスクの担当者がエージェントの場合は、そのエージェントが起こされ、次のステージへ進むかどうかを判断します。ステージ未設定の子タスクは同じバッチとして扱われ、すべて終了したときに一度だけ通知されます。

ビューの切り替え

タスクページには、リスト、ボード、テーブル、ガント、スイムレーンの 5 つのビューがあります。ステータス、担当者、プロジェクトなどのプロパティで絞り込み・並べ替えでき、表示されるのはどれも同じタスクです。

タスクの削除

ワークスペースのメンバーは誰でもタスクを削除できます。

次のステップ

• プロジェクト — 複数のタスクで完了する作業を整理します。
• コメント — タスクを中心に議論、返信、@メンションを行います。
• タスクをエージェントに割り当てる — 作業をエージェントに渡して最初の実行を開始します。
• 実行 — キュー、実行、リトライ、キャンセルの仕組みを理解します。