# 作業記録と判断の責任

Ticketには、利用者の意図と、それに対して判定できる成果を記録する。調査、設計、文書、運用も成果となる。コード、レビュー、マージをすべてのTicketに必須とせず、要求と受入条件に従って結果の返却・終了を判断する。

## 記録の粒度

一つのTicketは、単独で価値と達成を判断できる成果にする。中期的な目標はObjective、一時的な進捗はセッションのTaskで扱う。進捗を束ねるだけのTicketや、その代替となる階層関係を増やさない。

作成・大幅な変更の前に、関連記録と重複を確認する。背景、要求、受入条件、決定事項、実装の裁量、未解決の問いを区別して書く。確認済みの事実、利用者の説明、仮説を混ぜない。担当者の役割制限、そのターンの計画、文書作成後に停止する判断を製品の禁止事項へ転記しない。

実装の承認待ちは、利用者が求めた場合にだけ作業の条件として記録する。未確認事項は必要な調査で絞り、実装手段を早期に必須要件へ変えない。分類タグは検索・分類のために使い、終了理由や着手権限の代用にしない。依存関係は成果間の関係を示すものであり、資源所有や実行順の記録の代わりにはしない。

## 案件・担当・実行を分ける

Ticketの案件状態は`open`と`closed`であり、着手準備や進捗を表さない。終了には理由を残し、`closed`を必ずしも要求充足と解釈しない。Orchestratorの対応状況`waiting`・`inprogress`・`done`は現在の担当期間に対する自己申告であり、案件状態、Worker状態、通知配送、MR判断とは別である。

Assignは担当への委譲であり、readyやQueueの操作を前提にしない。通知受理から対応開始を推測せず、待機理由、次の行動、結果を明示する。待機中・作業中への回答は同じ担当期間を継続し、対応終了後の再依頼は新しい担当期間として扱う。案件の再開やWorkerの交代だけでは、再依頼や実行権限を作らない。

起動や再試行では、現在の担当と永続操作の結果を確認する。未完の依存関係は部分着手・待機の判断材料であり、一律の起動禁止や関連Ticketの自動起動を意味しない。結果不明の起動を別Workerの起動で置き換えず、保存済み委譲の通知失敗を委譲自体の失敗として再Assignしない。

## 正本の確認と成果の報告

実装・routing・レビュー・終了の判断前には、現行Ticketと必要な関連記録を読む。通知、要約、過去の実装報告を現行の要求や承認の証拠にしない。Worker内の操作は、提供されたtyped toolsとsystem instructionsに従う。CLIや保存先の直接編集で欠けた権限を代替しない。typed Ticket toolsのないクライアントでは、Ticketの作成・更新をYoi Workerへ委ねる。

成果には、実際の変更、検証結果、未確認事項、判断に必要な証拠を残す。すべての作業にコメントやartifactを義務付けず、利用者が必要とする返却方法を選ぶ。長い調査結果、生ログ、秘密情報はTicket本文へ転載しない。

対応終了と案件終了はそれぞれ明示的に判断する。結果を返して案件を開いたままにすることもできる。要求充足の判断は担当Worker・利用者の責任であり、Backendの認可・競合検査の成功や、成果物・承認済みMRの存在が代わりに判定するものではない。

## コードの公開とレビュー

公開が作業範囲なら、まとまりのあるcommitを作り、正確なsourceを通常の非force更新で公開する。レビューでは要求、変更全体、検証証拠を独立に確認する。口頭の承認、Profile、Flow遷移を権限の代用にしない。

source変更後は変更後のsourceを再レビューする。targetだけの変化では、未変更sourceへの承認と統合可否の再確認を区別する。通常の修正・再レビュー証拠はMerge Requestに置き、Ticketには調整が必要な阻害要因、決定、最終引継ぎを残す。

統合、Ticketの結論、Worker停止、接続解除、資源削除は別の判断である。対応終了後の担当表示の保持と、未完作業による資源拘束も区別する。終了通知や最終回答だけから後続操作を開始せず、依頼範囲と現在の正本を確認する。未反映の変更を統合済みと報告しない。