chore: merge develop preserving documentation structure and console UX

Integrate develop at 523bade3 while retaining concise agent guidance, rustdoc-owned design rationale, and current console history/rewind behavior. Adapt incoming tests to public entry-ID rewind and synchronize OpenAPI/TypeScript artifacts.

Validation: default-member cargo test --all-features (4936 passed, 23 ignored), root cargo check, all-feature rustdoc with broken links denied, format/diff/name guards, OpenAPI and 11 TypeScript freshness checks. Web: 613 unit, 327 component, 7 Ticket browser and 3 Console browser tests; check/build passed. Merged-state Ticket visual review at 1440/768/390px in light/dark; no matching pre-merge image baseline. E2E/live-provider checks not run.

docs/development/work-items.md

@@ -1,6 +1,6 @@
 # 作業記録と判断の責任
 
-Ticketには、利用者の意図と、それに対して判定できる成果を記録する。調査、設計、文書、運用も成果となる。コード、レビュー、マージをすべてのTicketに必須とせず、要求と受入条件に従って結果の返却・完了・終了を判断する。
+Ticketには、利用者の意図と、それに対して判定できる成果を記録する。調査、設計、文書、運用も成果となる。コード、レビュー、マージをすべてのTicketに必須とせず、要求と受入条件に従って結果の返却・終了を判断する。
 
 ## 記録の粒度
 
@@ -8,7 +8,15 @@ Ticketには、利用者の意図と、それに対して判定できる成果
 
 作成・大幅な変更の前に、関連記録と重複を確認する。背景、要求、受入条件、決定事項、実装の裁量、未解決の問いを区別して書く。確認済みの事実、利用者の説明、仮説を混ぜない。担当者の役割制限、そのターンの計画、文書作成後に停止する判断を製品の禁止事項へ転記しない。
 
-実装の承認待ちは、利用者が求めた場合にだけ作業の条件として記録する。未確認事項は必要な調査で絞り、実装手段を早期に必須要件へ変えない。依存関係は成果間の関係を示すものであり、資源所有や実行順の記録の代わりにはしない。
+実装の承認待ちは、利用者が求めた場合にだけ作業の条件として記録する。未確認事項は必要な調査で絞り、実装手段を早期に必須要件へ変えない。分類タグは検索・分類のために使い、終了理由や着手権限の代用にしない。依存関係は成果間の関係を示すものであり、資源所有や実行順の記録の代わりにはしない。
+
+## 案件・担当・実行を分ける
+
+Ticketの案件状態は`open`と`closed`であり、着手準備や進捗を表さない。終了には理由を残し、`closed`を必ずしも要求充足と解釈しない。Orchestratorの対応状況`waiting`・`inprogress`・`done`は現在の担当期間に対する自己申告であり、案件状態、Worker状態、通知配送、MR判断とは別である。
+
+Assignは担当への委譲であり、readyやQueueの操作を前提にしない。通知受理から対応開始を推測せず、待機理由、次の行動、結果を明示する。待機中・作業中への回答は同じ担当期間を継続し、対応終了後の再依頼は新しい担当期間として扱う。案件の再開やWorkerの交代だけでは、再依頼や実行権限を作らない。
+
+起動や再試行では、現在の担当と永続操作の結果を確認する。未完の依存関係は部分着手・待機の判断材料であり、一律の起動禁止や関連Ticketの自動起動を意味しない。結果不明の起動を別Workerの起動で置き換えず、保存済み委譲の通知失敗を委譲自体の失敗として再Assignしない。
 
 ## 正本の確認と成果の報告
 
@@ -16,10 +24,12 @@ Ticketには、利用者の意図と、それに対して判定できる成果
 
 成果には、実際の変更、検証結果、未確認事項、判断に必要な証拠を残す。すべての作業にコメントやartifactを義務付けず、利用者が必要とする返却方法を選ぶ。長い調査結果、生ログ、秘密情報はTicket本文へ転載しない。
 
+対応終了と案件終了はそれぞれ明示的に判断する。結果を返して案件を開いたままにすることもできる。要求充足の判断は担当Worker・利用者の責任であり、Backendの認可・競合検査の成功や、成果物・承認済みMRの存在が代わりに判定するものではない。
+
 ## コードの公開とレビュー
 
 公開が作業範囲なら、まとまりのあるcommitを作り、正確なsourceを通常の非force更新で公開する。レビューでは要求、変更全体、検証証拠を独立に確認する。口頭の承認、Profile、Flow遷移を権限の代用にしない。
 
 source変更後は変更後のsourceを再レビューする。targetだけの変化では、未変更sourceへの承認と統合可否の再確認を区別する。通常の修正・再レビュー証拠はMerge Requestに置き、Ticketには調整が必要な阻害要因、決定、最終引継ぎを残す。
 
-統合、Ticketの結論、Worker停止、接続解除、資源削除は別の判断である。終了通知や最終回答だけから後続操作を開始せず、依頼範囲と現在の正本を確認する。未反映の変更を統合済みと報告しない。
+統合、Ticketの結論、Worker停止、接続解除、資源削除は別の判断である。対応終了後の担当表示の保持と、未完作業による資源拘束も区別する。終了通知や最終回答だけから後続操作を開始せず、依頼範囲と現在の正本を確認する。未反映の変更を統合済みと報告しない。