ticket: add orchestration follow-up tickets

.yoi/tickets/00001KV09WYC6/item.md

@@ -0,0 +1,97 @@
+---
+title: 'Workspace panel: show Ticket-associated Intake Pods adjacent to Ticket rows'
+state: 'planning'
+created_at: '2026-06-13T10:54:31Z'
+updated_at: '2026-06-13T10:54:31Z'
+assignee: null
+readiness: 'implementation_ready'
+risk_flags: ['panel-ux', 'local-role-session-registry', 'pod-session-state']
+---
+
+## Background
+
+Panel からの操作・表示で、チケットに紐づく Intake Pod をチケットと並べて見たい。
+
+`00001KTFTQDBR` で workspace-scoped local role session registry と Ticket claim index は実装済み。既存実装により Ticket と local Intake Pod/session の関連付け自体は表現されているが、Panel 表示上は subtitle や独立した Pod list に埋もれやすい。Ticket row を見たときに、その Ticket に対応する Intake Pod が隣接・関連表示され、open/attach する対象として認識しやすい状態にする。
+
+既存の設計上の前提:
+
+- local Pod assignment は git-tracked Ticket metadata/thread に書かない。
+- Ticket は高々 1 active local Pod claim を持つ。
+- Intake Pod/session は Ticket と 1:1 とは限らない。
+- pre-Ticket Intake session は Ticket 未紐づけのまま存在できる。
+- Panel は Ticket state / local overlay / Pod metadata を join して表示してよい。
+- 自動 polling や自動 Intake spawn はしない。
+
+今回の作業は registry/schema の再設計ではなく、Panel 上での関連 Pod 表示・操作導線の改善に限定する。
+
+## Requirements
+
+- Workspace Panel の Ticket 表示で、Ticket に紐づく Intake Pod がチケットと隣接して認識できるようにする。
+  - 例: Ticket row の直下/隣接 row、子 row、明示的な inline/column 表示など。
+  - 具体的なレイアウトは既存 Panel UI と整合する範囲で実装側に裁量を残す。
+- 関連判定は既存の local role/session registry、Ticket claim、Pod metadata を使う。
+- Intake role の Pod/session を明確に区別して表示する。
+- live / restorable / stale の claim status が分かるようにする。
+- Ticket に紐づく Intake Pod を選択・Enter/Open した場合は、可能ならその Pod を open/attach する導線にする。
+- 既存の「Ticket を選んで Intake を開始する」挙動では、既存 claim がある場合に二重起動せず、関連 Intake Pod を開く/案内する既存方針を維持する。
+- Ticket と無関係な pre-Ticket Intake Pod は、無理に Ticket row に紐づけて表示しない。
+- 表示は bounded にし、Panel が大量 Pod/Ticket で読みにくくならないようにする。
+
+## Acceptance criteria
+
+- Ticket に local Intake claim / related Intake session がある場合、Panel 上でその Intake Pod が Ticket と隣接・関連表示される。
+- 表示は単なる subtitle だけに埋もれず、ユーザーが「この Ticket の Intake Pod」と認識できる。
+- live / restorable / stale の状態が確認できる。
+- 関連 Intake Pod の open/attach 導線が Panel 操作から使える、または既存の open/attach 操作へ明確に誘導される。
+- Ticket claim の one-active-claim invariant は維持される。
+- local Pod assignment は `.yoi/tickets` の git-tracked records に書かれない。
+- pre-Ticket Intake Pod は Ticket 未紐づけのまま表示され、特定 Ticket に誤って関連付けられない。
+- focused test で、Ticket row と関連 Intake Pod 表示の ViewModel/row ordering または rendering contract が確認される。
+
+## Binding decisions / invariants
+
+- Ticket metadata/frontmatter/thread に local Pod name、socket、claim state、runtime status を保存しない。
+- Panel 表示改善のために automatic polling / automatic Intake spawn を追加しない。
+- selected arbitrary Pod direct-send UX を復活させない。
+- Intake Pod と Ticket の関係を 1:1 と仮定しない。
+- 既存 local role/session registry を基本入力とし、新しい durable Ticket schema は導入しない。
+
+## Implementation latitude
+
+- UI 表現は既存 Panel の行構造に合わせて選んでよい。
+  - Ticket row の下に associated Pod row を挿入する。
+  - Ticket row に role/status chips を追加する。
+  - Ticket-focused row group として表示する。
+- 既存の `related_pods` / `local_claim` ViewModel を拡張するか、新しい typed row kind を追加するかは実装側判断でよい。
+- 既存 subtitle 表示を残すか整理するかは、重複して読みにくくならない範囲で判断してよい。
+
+## Readiness
+
+- readiness: implementation_ready
+- risk_flags: [panel-ux, local-role-session-registry, pod-session-state]
+
+## Escalation conditions
+
+- Panel の selection model / keyboard semantics を大きく変える必要が出た場合。
+- one-active-claim-per-Ticket を崩さないと目的を満たせないように見える場合。
+- pre-Ticket Intake と existing-Ticket Intake の表示分類が曖昧になり、誤関連付けのリスクがある場合。
+- Registry schema migration が必要になりそうな場合。
+
+## Validation
+
+- `cargo test -p tui workspace_panel --lib`
+- 関連箇所を触る場合:
+  - `cargo test -p tui multi_pod --lib`
+  - `cargo test -p tui role_session_registry --lib`
+- `cargo fmt --check`
+- `git diff --check`
+
+## Related work
+
+- `00001KTFTQDBR` — Workspace panel local role session registry
+- `00001KTFQ109S` — Workspace panel Companion interface
+- Code areas:
+  - `crates/tui/src/workspace_panel.rs`
+  - `crates/tui/src/multi_pod.rs`
+  - `crates/tui/src/role_session_registry.rs`

.yoi/tickets/00001KV09WYC6/thread.md

@@ -0,0 +1,7 @@
+<!-- event: create author: LocalTicketBackend at: 2026-06-13T10:54:31Z -->
+
+## 作成
+
+LocalTicketBackend によって作成されました。
+
+---

.yoi/tickets/00001KV09X0XC/item.md

@@ -0,0 +1,102 @@
+---
+title: 'Panel から ready Ticket を指示付きで planning に戻して Intake を再開できるようにする'
+state: 'ready'
+created_at: '2026-06-13T10:54:34Z'
+updated_at: '2026-06-13T10:54:41Z'
+assignee: null
+readiness: 'implementation_ready'
+risk_flags: ['panel-action', 'ticket-lifecycle', 'role-session', 'authority-boundary']
+---
+
+## Background
+
+`yoi panel` では `ready` Ticket に対して主に `Queue` 操作が提示される。
+
+しかし、ユーザー確認なしに Ticket が `ready` になった場合や、`ready` 後に追加指示・要件修正・詳細化が必要になった場合、Panel から安全に `planning` に戻して Intake を再開する導線がないと困る。
+
+`ready` は「人間が Queue できる状態」であり、「ユーザーが詳細化を諦めた状態」ではない。Panel は Queue gate だけでなく、ユーザーが明示的に planning / Intake に戻す操作も提供する必要がある。
+
+## Requirements
+
+- Panel の `ready` Ticket 行に、Queue とは別の「planning に戻して詳細化する」操作を追加する。
+  - UI label / key は実装時に既存 action model に合わせて決めてよい。
+  - 例: `Clarify`, `Revise`, `Back to planning`, `Intake` など。
+- 操作はユーザー入力の追加指示 / 理由を受け取れること。
+  - 指示は Ticket thread に durable に記録する。
+  - 指示なしで実行する場合も、少なくとも bounded な理由または diagnostic を残す。
+- 操作実行時は、現在の Ticket authority を再読込し、対象 Ticket がまだ `ready` であることを確認してから mutation する。
+- `ready -> planning` の状態変更は typed Ticket backend / Rust Ticket API を使って記録する。
+  - shell out や手書きファイル編集で代替しない。
+  - reason は `user_requested_refinement` / `panel_return_to_planning` 相当の具体的な値にする。
+- 状態変更後、同じ Ticket を対象に Intake role Pod を restore / launch して、追加指示を渡す。
+  - 既存の live/restorable Intake claim がある場合はそれを優先して restore / notify する。
+  - claim がない場合は既存の Intake launch path を使ってよい。
+- Intake restore / launch に失敗した場合でも、Ticket が `planning` に戻ったことと、再開失敗の bounded diagnostic がユーザーに見えること。
+  - silently `ready` に戻したり、Queue に進めたりしない。
+- この操作は implementation side effect ではない。
+  - Orchestrator queue / coder / reviewer spawn / worktree 作成を起こさない。
+- Intake が再詳細化した後に `ready` へ戻すかどうかは、通常の Intake 合意 / readiness flow に従う。
+  - 単に restore / launch しただけで自動的に `ready` にしない。
+
+## Acceptance criteria
+
+- Panel の `ready` Ticket 行から、Queue 以外に planning / Intake 再詳細化操作を選べる。
+- 操作時にユーザー指示を保存でき、その指示が restored/launched Intake に渡る。
+- 操作は stale view ではなく現在の Ticket state を再確認してから `ready -> planning` を記録する。
+- `ready` でない Ticket に対しては安全に拒否し、理由を表示する。
+- `ready -> planning` の typed `state_changed` event と、ユーザー指示 / refinement request が Ticket thread に残る。
+- Intake Pod の restore / launch が試行され、成功 / 失敗が Panel 上で bounded に表示される。
+- 操作によって Queue、`queued -> inprogress` acceptance、worktree 作成、coder/reviewer spawn は発生しない。
+- Focused tests が少なくとも以下をカバーする。
+  - ready Ticket の planning return 成功。
+  - stale / non-ready Ticket の拒否。
+  - ユーザー指示が Ticket thread と Intake launch context に入ること。
+  - Intake restore / launch 失敗時の diagnostic。
+  - Queue 操作の既存 semantics が壊れていないこと。
+
+## Binding decisions / invariants
+
+- Panel は scheduler ではない。
+- この操作は implementation routing ではなく、ユーザー主導の requirements sync / refinement への戻しである。
+- `ready` はユーザーが Queue できる状態であって、追加詳細化を禁止する状態ではない。
+- `ready -> planning` はユーザー明示操作と指示 / 理由付きでのみ行う。
+- `queued` / `inprogress` Ticket を戻す操作はこの Ticket の範囲外とする。
+  - それらは Orchestrator ownership / acceptance semantics に関わるため、必要なら別 Ticket で扱う。
+- Ticket mutation は typed backend / Rust API 経由に限定する。
+
+## Implementation latitude
+
+- Panel action label、key binding、composer / modal / prompt 形式は既存 Panel input model に合わせて選んでよい。
+- Intake restore と launch のどちらを優先するかは、既存 role-session claim / Panel role registry の設計に合わせて実装してよい。
+- 状態変更と Intake 起動を完全 atomic にできない場合は、Ticket state を durable に戻したうえで、起動失敗を明確に表示・記録する方針でよい。
+- 既存の Ticket action dispatch / local role session registry / Intake launch helper を再利用する。
+
+## Readiness
+
+- readiness: implementation_ready
+- risk_flags: [panel-action, ticket-lifecycle, role-session, authority-boundary]
+
+## Escalation conditions
+
+- `queued` / `inprogress` から planning へ戻す操作も同時に必要になった場合。
+- Intake restore / launch に必要な role-session claim 情報が現在の Panel から安全に取得できない場合。
+- 実装に Ticket lifecycle transition graph の変更が必要になった場合。
+- Panel action model では指示入力 UI を安全に表現できず、composer model の設計変更が必要になった場合。
+
+## Validation
+
+- Focused Panel / workspace_panel tests。
+- Ticket lifecycle transition tests where applicable。
+- Intake launch / role-session claim tests where applicable。
+- `cargo test -p tui workspace_panel`
+- `cargo test -p ticket`
+- `cargo run -q -p yoi -- ticket doctor`
+- `cargo fmt --check`
+- `git diff --check`
+
+## Related work
+
+- `00001KTDPFY8R` Workspace panel Ticket action dispatch
+- `00001KTJ4QFP0` Replace Ticket intake state with planning state
+- `00001KTK1FPYG` Require project context before Orchestrator returns Tickets to planning
+- `00001KTFX202R` Workspace panel Orchestrator queue automation

.yoi/tickets/00001KV09X0XC/thread.md

@@ -0,0 +1,23 @@
+<!-- event: create author: intake at: 2026-06-13T10:54:34Z -->
+
+## 作成
+
+LocalTicketBackend によって作成されました。
+
+---
+
+<!-- event: intake_summary author: intake at: 2026-06-13T10:54:41Z -->
+
+## Intake summary
+
+ユーザー承認済みの新規 Ticket。Panel の `ready` Ticket に対し、Queue 以外にユーザー指示付きで `planning` へ戻し、同じ Ticket の Intake を restore / launch して再詳細化できる操作を追加する。実装開始ではなく requirements sync / refinement 導線であり、typed Ticket backend 経由の `ready -> planning` 記録、stale state 再確認、指示の thread 永続化、Intake 起動結果の bounded 表示、Queue / Orchestrator / worktree / coder/reviewer side effect 不発生が受け入れ条件。
+
+---
+
+<!-- event: state_changed author: intake at: 2026-06-13T10:54:41Z from: planning to: ready reason: intake_ready field: state -->
+
+## State changed
+
+Intake refinement completed. ユーザーが draft を承認し、意図・受け入れ条件・binding invariants・implementation latitude・escalation conditions・validation が Orchestrator routing 可能な粒度で揃っている。
+
+---