課題を実行

提案を承認すると、その仕事は実際の 課題 になります。この段階では、各課題を作業する人またはエージェントに渡し、依存の順序に従って進め、ステータスが進む様子を見守ります。このページでは、課題の担当と割り当て、依存グラフの読み方、未着手 から 検証待ち までのステータスの流れを扱います。

課題ボードを開く

プロジェクトサイドバーで 課題 を選びます。ビュー切り替えで次を切り替えられます。

• カンバン — 未着手、進行中、検証待ち、完了 の四つの列があるボード。各列には件数と見積もり時間の合計が表示されます。未着手 の列には、ステータスが 未着手 の課題と 割り当て済み の課題の両方が入ります。課題を割り当てるとステータスバッジは変わりますが、カードは未着手の列にとどまります。
• DAG — 依存グラフ（下記参照）。
• リスト — ステータスフィルターの付いたコンパクトな一覧で、小さな画面で便利です。

各カードには、課題のステータス、見積もり時間、担当者（未割り当てのときは 割り当て リンク）、作業中のワーカー数、受け入れ基準の進捗（合格数/合計）が表示されます。

カンバンボードでは、各課題が未着手・進行中・検証待ち・完了のどこにあるかを追跡できます。

課題を担当または割り当てる

提案から作成されたばかりの課題は、未着手 かつ未割り当ての状態から始まります。課題を開いて詳細パネルを表示し、割り当て アクションを使います。次のことができます。

• 自分に割り当てる — 課題を自分が引き受けます。あなたの開発者エージェントはすべて、その課題を確認して作業できるようになります。
• 別のユーザーに割り当てる — チームメイトに渡します。
• 特定のエージェントに割り当てる — エージェントを選び、必要ならそのエージェントが実行する作業ディレクトリ（ホストとインスタンス）も選びます。
• 担当を解除（担当者をクリア） — 課題を未着手のプールに戻します。

割り当てると、課題は 未着手 から 割り当て済み へ移ります。

依存グラフを読む

課題が単独で存在することはめったにありません。DAG ビューに切り替えると、課題を依存グラフとして確認できます。各ノードが一つの課題で、矢印はある課題から、その課題に依存する課題へ向かいます。レイアウトは自動で計算されるので、実行の順序を上から下へ読めます。二つのノードの間に線を引いて、依存関係を追加することもできます。

課題は、依存する すべての課題が 完了 になってはじめて開始できます。カンバンボードでは、ブロックされた課題に「ブロック元」のバナーが表示され、上流の課題が完了する前に動かそうとすると、先に依存関係を解消するよう促されます。課題パネルには 依存先 と これにブロックされている課題 の両方が表示されるので、依存のつながりをどちらの方向にもたどれます。

DAG ビューでは依存関係が図示され、実行の順序を読み取れます。

ステータスの流れを追う

課題は決まった順序でステータスが進みます。カンバンの列の間でカードをドラッグするか、担当者が課題パネルからステータスを進めます。

ステータス	意味	次に進む条件
未着手	提案から作成され、まだ誰も引き受けていません。	誰かが担当するか、あなたが割り当てます。
割り当て済み	担当者はいますが、まだ作業が始まっていません。	担当者が作業を始めます（すべての依存が完了していることが必要）。
進行中	作業中です。	担当者がレビューに提出します。
検証待ち	作業は完了し、あなたの検証を待っています。	あなたがそれを検証します。検証して完了を参照。
完了	検証され、受け入れられました。	なし。これにより、依存する課題のブロックが解除されることがあります。

下流の課題のブロックが解除されるのは、課題が 完了 になったときだけです。検証待ち のままでは解除されません。そのため、速やかに検証することが、グラフ全体を滞りなく進める鍵になります。

エージェントは何をするのか

課題がエージェントに割り当てられ、その依存が満たされると、エージェントはそれを担当し、進行中 へ移し、作業を行い、根拠を添えた作業レポートを投稿し、検証待ち へ提出します。あなたはステータスとレポートを見守り、実際の作業はエージェントが担います。エージェントがどう接続し、あなたのプロジェクトで作業をどう進めるのかは、エージェントプラットフォームをご覧ください。

エージェントから安全に提出する

引き継ぎの準備中は課題を in_progress に保ちます。

1. chorus_report_work で完了の根拠を報告し、status は指定しません。
2. chorus_report_criteria_self_check で各受け入れ基準を記録し、すべての必須基準を満たす作業を完了して自己チェックを通します。
3. chorus_get_task でこの課題を読み直し、まだ in_progress であることを確認します。
4. 要約を添えて chorus_submit_for_verify を明示的に呼び出します。これが in_progress → to_verify の遷移であり、呼び出し元は割り当ての所有者である必要があります。
5. 独立レビューと管理者の検証は、担当レビュー者または親エージェントに任せます。

先に chorus_report_work や chorus_update_task に status: "to_verify" を渡さないでください。これらでも状態は変わりますが、その後の明示的な提出は失敗します。正しく提出済みならレビューを待ちます。誤って移した場合のみ、担当者が依存関係のチェックを満たしたうえで chorus_update_task により in_progress に戻します。開発側と管理側の判定と根拠が両方消えるため、自己チェックをやり直し、課題を再読してから提出してください。任意の読み直しチェックは Pi を参照してください。

次へ

課題が 検証待ち に達したら、検証して完了に進み、その受け入れ基準を確認して仕事を受け入れます。