エンティティのライフサイクル参考

Chorus における作業はすべて、三種類のエンティティ、着想（Idea）、提案（Proposal）、 課題（Task） のいずれかであり、それぞれが小さく固定された状態の集合を経ていきます。本ページは、 エンティティごとにその状態を挙げ、各状態が何を意味し、どの動作がエンティティを前へ進めるのかを示します。

成果を届ける流れ全体が各段階のあいだをどう引き継いでいくのか、その上位の視点については ワークフロー参考をご覧ください。本ページはそのエンティティ別の対になる説明です。

着想（Idea）

着想は、自身に保存された状態としては要件詳細化（elaboration） フェーズだけを追跡します。詳細化が 完了すると、着想は終わったものとみなされます。ボード上で見えるそれ以降の進展、つまり計画、構築、検証、 完了は、着想そのものに保存されているのではなく、関連づいた提案と課題から派生したものです。

状態	意味	前へ進める要因
open	作成されたが、まだ誰も着手していない。	誰かが着想を担当するか、エージェントが詳細化を開始する → elaborating。
elaborating	要件詳細化が進行中：エージェントが確認の質問をラウンドごとに投げ、あなたがそれに答える。	詳細化が確定する（すべての質問に回答されるか、詳細化がスキップされる）→ elaborated。
elaborated	保存される状態の終端。共通理解が確認され、着想は提案へ進める準備が整っている。	これ以上の保存状態の遷移はない。この先の進展は派生である（下記参照）。

派生する進展

着想が elaborated に達したあと、Chorus は関連づいた提案と課題の状態から、ボード用の表示ステータスを 算出します。着想には保存された completed や closed の状態は存在せず、着想の状態を直接設定する方法も ありません。それは要件詳細化と下流の作業の副次的な効果としてのみ変化します。

派生ラベル	適用される条件
計画中	詳細化済みだが、まだ提出された提案がない（提案がない、または下書きの状態）。
提案をレビュー	提案が提出され、あなたのレビューを待っている。
構築中	提案が承認され、その課題が進められている。
作業を検証	少なくとも一つの課題が検証に提出された。
完了	提案が承認され、すべての課題が done（または closed）に達した。

提案（Proposal）

提案はレビューのための容れ物です。エージェントが用意した文書草稿と課題草稿を保持し、承認すると それらの草稿が実体の文書と課題へ物化（materialize） されます。

状態	意味	前へ進める要因
draft	執筆・編集中。草稿の追加や変更は draft の間だけ可能。	作成者がレビューに提出する → pending。
pending	提出され、レビュー担当者を待っている。	レビュー担当者が承認する → approved、または却下する → draft に戻る（レビューメモ付き）。
approved	受け入れられた。その文書草稿と課題草稿が実体の文書と課題へ物化される。	レビューの流れの終端。
closed	撤回または放棄された。そこから作成された課題はクローズされる。	終端。

却下された提案は draft に戻り、作成者が修正して再提出できます。レビュー担当者のメモは修正のための コンテキストとして残されます。削除できるのは draft または closed の提案だけです。

課題（Task）

課題は単一の作業単位を、実行と検証を通じて運びます。

状態	意味	前へ進める要因
open	未担当で、担当可能。	誰かが担当するか割り当てられる → assigned。
assigned	担当者はいるが、作業は始まっていない。	担当者が作業を開始する → in_progress（すべての依存が解除されている場合のみ）。
in_progress	作業中。	担当者が提出する → to_verify。
to_verify	作業が完了し証拠が提出され、検証を待っている。	検証担当者が受け入れる → done、または差し戻す → in_progress。
done	検証済みで完了。	通常の流れの終端。
closed	取り消された、たとえば提案が撤回されたとき。	終端。

依存と解除

課題は他の課題に依存でき、有向非巡回グラフを形成します。ある課題の後続は、その上流の課題が done に到達したときにのみ解除されます（上流が closed の場合も解除済みとみなされます）。それまで、 後続の課題は in_progress へ移れません。課題を to_verify から done 以外のどんな理由でも外へ戻すと、 その受け入れ基準はリセットされます。これらの依存の連結はプロジェクトのリソースグラフで 確認でき、課題 DAG ビューから追加・編集できます（課題を実行を参照）。

エージェントがすること

エージェントは課題を assigned → in_progress → to_verify と進め、各課題の受け入れ基準に対して 証拠を提出します。最終の to_verify → done の検証は、人（またはその代理を務める管理者エージェント）が 行います。その接続がどう機能するかは、エージェントプラットフォームの参考をご覧ください。