案件、タスク、記録

案件は実際の一案件です。変更されないプレイブック Version に固定して開始することも、title だけの都度作成の案件として開始することもできます。プレイブックに紐づく案件はプレイブック ID と Version ID を保持しますが、Step の進捗は追跡しません。

案件 lifecycle

案件の status は open または closed です。close 時の outcome は completed、cancelled、abandoned です。completed にするには全タスクが closed である必要があります。cancel または abandon では、残っている open タスクを案件 transition の一部として閉じます。案件を reopen してもタスクは reopen されません。

archive は close とは別の操作です。archive した案件はすべての一覧、件数、引き継ぎグラフから外れ、読み取りでも解決されなくなりますが、そのタスク・記録・引き継ぎは削除されず保持されます。archive できるのは現在の担当者だけで、web app から実行します。

タスクや記録が一件もないまま案件を完了できます。案件の存在と outcome だけを残せばよい場合は、この軽量な形を使ってください。

公開案件は記録を出し、タスクは出さない

案件の ACL にも、プレイブックと同じ public を足せます。public だけの読み手が見るのは公開タイトル、入力、記録、読み取れる引き継ぎ近傍です。タスク、担当、共同作業者の身元は公開しません。タスクの結果が必要なら、すでに記録になっているものを出します。

案件 ACL の共同作業者は、生きている案件を今までどおり見ます。公開しても新しい案件は作りません。同じ案件が続き、あとから追記した記録も同じ公開 projection に入ります。

案件 mutation は optimistic concurrency を使います。最新の lockVersion を送信し、conflict 後は古い intent をそのまま再送せず、案件を読み直して変更がまだ妥当か判断してください。仕事の共同作業者は担当の変更、タイトルの変更、終了、再開、引き継ぎの接続ができます。アクセスの変更とアーカイブは現在の担当者に限られます。started_by は履歴です。

タスクは必要時だけ作る

タスクは案件内で明示された仕事です。kind は work または approval（承認）で、User への割り当て、source Step への link、承認の場合は対象記録への link を持てます。承認タスクは人または agent がその記録を判断することです。案件の共有証拠を Epismo AI が判断し、完了後に origin=system の review 記録を追記する Epismo AI review とは別です。

案件開始時に各 Step のタスクは作られません。責任、引き継ぎ、承認、個別追跡する仕事を見える状態にする必要があるときだけタスクを作ります。複数タスクを同時に open にでき、ひとつを閉じても案件は自動進行しません。

タスク更新も lockVersion を使います。案件を編集できる人は、進行中のタスクの内容と担当者を更新できます。終了したタスクを再開できるのは、親案件が進行中のあいだだけです。

案件の引き継ぎ（handoff）でつなぐ

案件は引き継ぎ（fromCaseId -> toCaseId）によって有向非巡回グラフ（DAG）として接続できます。各案件の ACL と lifecycle を保ちながら、複数段階のワークフローやチーム間の連携を表現できます。引き継ぎの作成・削除には元案件の閲覧権限と先案件の編集権限が必要です。公開案件は、編集できる案件へ続けられますが、閲覧だけでは公開案件へ仕事を接続できません。

• 循環防止: トランザクション分離と到達可能性チェックにより、サイクルや自己参照の接続を厳格に拒否します。
• 候補探索: 事前に接続可能な上流・下流の案件候補を探索できるため、試行錯誤なしに安全な接続先を決定できます。
• 引き継ぎグラフ: 指定した案件を起点に、scope（self、ancestors、descendants、neighbors、connected）に応じた DAG を取得できます。

記録が引き継ぎ面になる

記録は案件の時系列上の共有コンテキストで、タスクまたは source Step にも紐付けられます。kind は閉じた集合です。クライアントが書くのは note（コメント、判断、引き継ぎ）、output（成果物。追記すると Epismo AI review がキューされることがあります）、または review（判定。data.verdict は pass、changes_requested、insufficient）です。server が書くのは activity（協調イベント）と Epismo AI の review（origin=system）です。任意の人が読める内容、構造化データ、origin（user、agent、system）、作成者、クライアント情報、作成日時も持ちます。user または agent が作った記録は作成者だけが更新・削除でき、task と provenance は固定です。削除は content と data を空にし、参照が切れないよう deleted_at 付きの tombstone を残します。

成果、根拠、判断、file・object 参照、引き継ぎの要約、意味のある error を記録に残してください。chain-of-thought、全 tool call、生 shell output、credential、retry 履歴、heartbeat、runtime graph を自動保存しないでください。案件の編集者は POST /v1/cases/{caseId}/review で Epismo AI review をキューでき、呼び出しは即座に返ります。任意の prompt で固定のレビュー規則のあとに呼び出し側の指示を追加できます。案件の autoReview を有効にすると OUTPUT 記録の追記でもキューします。完了後の記録は kinds=review と origins=system で確認します。案件の編集者は POST /v1/cases/{caseId}/overview で一発の状況オーバービューも取れます。同期で応答に本文が返ります。同じ idempotency key を再送すると再生成せず前回のブリーフを受け取ります。自動・手動のレビューとオーバービューは、開始時に固定した案件の billing account から課金されます。Case のホームが Epismo AI を許可している必要があります（AI 設定）。許可されていないとき、autoReview をオンにする操作と手動レビュー・オーバービュー依頼は拒否され、すでにオンの自動レビューは Record も課金もなくスキップします。

記録の kind、content、data の訂正と削除は作成者だけが行えます。案件 ACL に含まれる参加者は、引き続き新しい記録を追記できます。記録は案件内で一覧し、安定 cursor とタスク、author、kind、origin、ACL、sort order の filter を利用できます。引き継ぎ scope（ancestors や connected など）を指定することで、各案件に対する閲覧権限を個別に評価しながら接続先案件の記録も含めて取得できます。