イシュー

イシューは 1 件の作業のコンテキスト、担当者、ステータス、実行履歴を 1 か所に保持します。

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

イシューの構成

内容	役割
タイトルと説明	目的、背景、要件、受け入れ条件。
ステータスと優先度	作業がどの段階にあり、何を先に進めるか。
担当者	ワークスペースのメンバー、エージェント、またはスクワッド。
日付、ラベル、カスタムプロパティ	計画、分類、チーム独自のフィールド。
プロジェクトと親子関係	より大きな作業への所属、または子イシューへの分割。
アクティビティと実行ログ	コメント、ステータス変更、実行タスク、エージェントが返した結果。

イシューの作成

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

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

担当者の選択

担当者	効果
メンバー	そのメンバーが作業を進めます。実行タスクは作成されません。
エージェント	そのエージェントの実行タスクが 1 件作成されます。
スクワッド	スクワッドのリーダーが受け取り、誰に任せるかを決めます。

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

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

ステータス

どのワークスペースにも 7 つの組み込みステータスが用意されています。この 7 つはそのまま 7 つのカテゴリ（trackica が知っている挙動の集合で、数は固定です）でもあり、それぞれの組み込みステータスが自分のカテゴリの名前になっています。

ステータス	意味
`backlog`	まだ着手しない。エージェントに割り当て済みのイシューは、`backlog` を離れて初めて実行タスクが作成されます。
`todo`	内容が固まり、開始を待っている。
`in_progress`	作業中。
`in_review`	結果が出て、確認待ち。
`done`	完了。
`blocked`	今は先に進めない。
`cancelled`	中止したが、記録は残す。

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

次の 2 つの変更はシステムが行います。

実行が失敗し、そのイシューにほかの実行がなく、リトライも起動しなかった場合、in_progress は todo に戻ります。
紐づく GitHub PR がクローズ意図付きでマージされ、open または draft のまま残る紐づき PR がほかにない場合、イシューは done になります。

カスタムステータス

ワークスペースの owner または admin は、設定 → ステータスから独自のステータスを追加できます（Code Review、QA、Rework など）。新しいステータスは 7 つのカテゴリからひとつを選び、そのカテゴリの挙動をそのまま引き継ぎます。

カテゴリ	そのカテゴリのステータスに共通する挙動
`backlog`	保留。エージェントを割り当てても実行は始まりません。このカテゴリの外へ移したときに実行が始まります（移動先が `done` または `cancelled` の場合を除く）。
`todo`	開始待ち。`backlog` と違い、このカテゴリのイシューはエージェントを割り当てた時点で実行が始まります。
`in_progress`	作業中とみなされます。ほかに実行がない状態で実行が失敗すると、イシューは `todo` に戻ります。
`in_review`	納品済みでレビュー待ちとみなされます。オートパイロットの実行を完了し、過去の「実行失敗」通知も自動的にアーカイブされます。
`done`	完了とみなされます。子イシューのステージを終わらせ、親イシューの進捗に数えられます。
`blocked`	外部依存で止まっている状態で、自動では再開しません。
`cancelled`	中止したが記録は残す状態で、子イシューのステージにとっては同じく終了扱いです。

つまり in_review カテゴリの Code Review ステータスは in_review とまったく同じようにオートパイロットの実行を完了し、イシューを backlog から todo カテゴリの Rework ステータスへ移すと、todo へ移したときとまったく同じように担当エージェントが起動します。

名前はチームが読むためのもので、プラットフォームが従うのはカテゴリです。このドキュメントのほかの箇所で「あるステータスになると何かが起きる」と書かれている場合、そのルールはカテゴリのものなので、同じカテゴリのカスタムステータスにも当てはまります。逆は成り立ちません。プラットフォーム自身がステータスを設定するとき（上記の todo への差し戻しや、マージされた PR による done）は、そのカテゴリのカスタムステータスではなく組み込みステータスが書き込まれます。

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

カテゴリは作成後に変更できません。 変更すると、すでにそのステータスにあるイシューの挙動を黙って書き換えることになるため、編集画面では読み取り専用です。まず挙動を決めてから名前を付けてください。
ボードの列はステータスではなくカテゴリです。 ステータスを追加しても列は増えません。列はカテゴリごとに 1 つです。カスタムステータスは所属カテゴリの列に入り、カードにはステータス名の小さなチップが付くので、In Review の列でも Code Review と QA を見分けられます。
組み込みステータスはロックされています。 名前・色・カテゴリは変更できず、アーカイブもできません。このページを一度も開かないワークスペースのボードは、これまでとまったく同じままです。
アーカイブは無効化であり、削除ではありません。 すでにそのステータスにあるイシューは、名前も色も挙動もそのままです。次に誰かがステータスを設定するときに、選択肢として出てこなくなるだけです。

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

イシューと実行タスク

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

プロジェクトと子イシュー

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

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

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

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

イシューの構成

イシューの作成

担当者の選択

ステータス

カスタムステータス

イシューと実行タスク

プロジェクトと子イシュー

ビューの切り替え

イシューの削除

次のステップ

このページの内容