fix: clear encrypted-only thinking snapshots

# Conflicts:
#	.yoi/tickets/00001KVWPVHFJ/item.md
#	.yoi/tickets/00001KVWPVHFJ/thread.md

.yoi/.gitignore

@@ -1,2 +1,3 @@
 /memory/
 tickets/.ticket-backend.lock
+/workspace.db*

.yoi/objectives/00001KTR80WMN/item.md

@@ -1,63 +1,111 @@
 ---
-title: "MCP integration as external capability provider"
-state: "active"
-created_at: "2026-06-10T07:47:48Z"
-updated_at: "2026-06-10T07:47:48Z"
-linked_tickets: ["00001KST8H4M0", "00001KTR81P9X", "00001KTR82RB7"]
+title: 'MCP local stdio integration roadmap'
+state: 'active'
+created_at: '2026-06-10T07:48:45Z'
+updated_at: '2026-06-20T05:34:00Z'
+linked_tickets: ['00001KTR81P9X', '00001KV0SP0TY', '00001KVHR3WRF', '00001KVHR3WRY', '00001KVHR3WS6', '00001KVHR3WSD', '00001KVHR3WSN', '00001KVHR3WSW']
 ---
 
 ## Goal
 
-Yoi が MCP (Model Context Protocol) server を external capability provider として安全に扱えるようにする。
+Add MCP local stdio integration to Yoi without weakening Worker history, prompt-context, scoped tool permission, or Plugin/Feature layering invariants.
 
-到達点は、MCP server が提供する tools / resources / prompts を、Yoi の既存の Pod / Feature / ToolRegistry / permission / scope / history / bounded result 境界に乗せて利用できる状態にすること。MCP は Yoi の plugin model そのものではなく、protocol-bound bridge / external provider runtime として扱う。
+MCP is a protocol-backed integration layer on top of `pod::feature`. `pod::feature` supplies contribution/lifecycle/runtime-discovered registration substrate; MCP owns its own enablement, local server trust model, command/env/secret policy, and MCP-specific permission decisions. MCP is not the Plugin model, and Plugin permission policy is not implemented by feature-layer authority grants.
 
 ## Motivation / background
 
-MCP は AI application と外部 system を接続する標準 protocol になりつつあり、server は tools、resources、prompts などを提供する。Yoi にとって MCP support は有用だが、外部 server が返す schema、description、annotation、resource content、prompt template はすべて untrusted data であり、Yoi の instruction hierarchy、scope、permission、history persistence、prompt-context 加工原則を弱めてはいけない。
+Yoi needs to integrate with external capability providers without turning them into hidden context sources or bypassing ordinary Tool/Worker safety rules. MCP is useful because it can expose tools, resources, and prompts from local protocol servers, but those server-provided declarations and results are untrusted and must be normalized through Yoi's existing authority boundaries.
 
-現行の `pod::feature` API は static descriptor / static tool contribution を中心にしており、MCP のように startup 時の initialize / capability negotiation / discovery によって surface が決まる provider には不足がある。そのため、MCP 実装だけを先に ad-hoc に入れるのではなく、まず外部 protocol-backed provider を扱える Feature API boundary を整え、その上に MCP implementation を載せる。
+The first MCP slice should focus on local stdio servers because they are concrete enough to implement and debug while keeping remote auth, OAuth, Streamable HTTP, registry distribution, sampling, and elicitation out of the initial trust boundary.
+
+A configured local MCP server runs as a local executable. Yoi feature authority does not sandbox that executable's OS-level side effects, so command/env/secret handling and explicit local trust policy are MCP-layer responsibilities rather than generic `pod::feature` grants.
 
 ## Strategy / design direction
 
-- Broad MCP integration Ticket は progress-container として使わず、この Objective に中期方針を移す。
-- 実装 work item は concrete Ticket に分ける。
-  - `00001KTR81P9X`: `pod::feature` / Worker / ToolRegistry API を external protocol-backed provider に耐える形へ拡張する。
-  - `00001KTR82RB7`: MCP `2025-11-25` local stdio server-feature bridge を実装する。
-- MCP 実装は local stdio transport から始める。
-  - Streamable HTTP、remote auth/OAuth、MCP Registry distribution、workspace-provided package auto-start は後続判断とする。
-- tools / resources / prompts は無理に分けず、MCP server features として扱う。
-  - ただし resources/prompts は direct context injection ではなく、明示 tool operation の結果として history に残す。
-  - `resources/read` / `prompts/get` の結果を history に残らない形で context に注入しない。
-- MCP server は untrusted external capability provider として扱う。
-  - server-provided schema/description/annotation/content/error は instruction ではなく data。
-  - ToolRegistry / PreToolCall permission / history / bounded result path を迂回しない。
-- local process execution は explicit authority として扱う。
-  - filesystem/network authority から暗黙に subprocess 起動権限を派生させない。
-  - secrets は explicit secret/env references で扱い、diagnostics / logs / model context / project records に plaintext として残さない。
-- dynamic discovery / list_changed は prompt/tool schema consistency を壊さない範囲で扱う。
-  - live refresh が危険なら next-turn refresh または restart/reinitialize-required diagnostic を選ぶ。
-  - silent stale state は避ける。
-- Sampling / elicitation は external server が Yoi 側の LLM/user interaction を要求する強い authority なので、初期段階では fail-closed とし、必要なら別 Ticket で approval/resume/UI path を設計する。
+- Baseline the initial implementation on MCP specification `2025-11-25`.
+- Start with local stdio MCP servers only.
+- Treat MCP server metadata, tools, resources, prompts, and results as untrusted content.
+- Do not allow MCP resources/prompts to become hidden context injection.
+  - They must be explicit tool operations with history records.
+- Use the normal Yoi ToolRegistry, PreToolCall permission, history, and bounded result paths.
+- Do not add private MCP-only bypasses around Worker/tool invariants.
+- Keep sampling and elicitation fail-closed initially.
+- Keep Streamable HTTP, remote auth, OAuth, and MCP Registry/distribution out of the first slice.
+- Treat local stdio server execution as an explicit MCP config/trust decision, not as a `pod::feature` authority grant.
+- Document clearly that a configured local MCP server runs as a local executable; Yoi feature authority does not sandbox its OS-level side effects.
+
+### Layering decisions
+
+- `pod::feature` is an API/contribution substrate.
+  - It owns contribution declarations, provider/service lifecycle hooks, diagnostics, runtime-discovered registration plumbing, and integration with normal Worker/ToolRegistry paths.
+  - It does not own Plugin permission policy or MCP server trust policy.
+- Plugin is a user-facing package/config/runtime layer over `pod::feature`.
+  - Plugin permissions are Plugin-layer policy.
+  - Plugin package discovery/enablement must not be conflated with MCP local server execution.
+- MCP is a separate feature-backed integration layer.
+  - MCP enablement, command/env/secret handling, server trust, and MCP-specific permission decisions live in MCP config/implementation.
+  - MCP provider-discovered tools/resources/prompts are exposed through the feature API and ordinary Yoi tool paths.
+
+### Concrete implementation tickets
+
+Completed prerequisites:
+
+- `00001KTR81P9X` — Extend `pod::feature` API for external protocol-backed capability providers.
+- `00001KV0SP0TY` — Remove feature-layer HostAuthority model.
+
+Concrete MCP implementation sequence:
+
+1. `00001KVHR3WRF` — MCP local stdio server config and trust policy.
+   - explicit config, command/env/secret redaction, local executable trust boundary, no auto-start.
+2. `00001KVHR3WRY` — MCP stdio JSON-RPC lifecycle client.
+   - subprocess lifecycle, initialize/capability negotiation, diagnostics, shutdown.
+3. `00001KVHR3WS6` — MCP tools/list registration into ToolRegistry.
+   - provider-discovered tools, stable namespacing, schema validation, untrusted metadata normalization, no tools/call yet.
+4. `00001KVHR3WSD` — MCP tools/call execution through ordinary Tool path.
+   - PreToolCall gate before server call, bounded result serialization, history path.
+5. `00001KVHR3WSN` — MCP resources/prompts as explicit tool operations.
+   - resources/list/read and prompts/list/get without hidden context injection.
+6. `00001KVHR3WSW` — MCP list_changed notification handling.
+   - deterministic safe refresh/diagnostic behavior without breaking tool schema or prompt-cache invariants.
+
+The old broad implementation Ticket `00001KTR82RB7` is superseded by this sequence and should not be used as an implementation work item.
+
+### Terminology
+
+Use `runtime-discovered` or `provider-discovered` for MCP tools/resources/prompts discovered from `tools/list`, `resources/list`, or `prompts/list`. Avoid `dynamic tools` / `dynamic registry` in new MCP design prose because those phrases imply that model-visible tool schemas may change during an active LLM run.
+
+The intended invariant is:
+
+```text
+provider-discovered at startup / provider initialization;
+registered into the ordinary ToolRegistry before model exposure;
+run-stable for the duration of a model request/run;
+refreshed only at a safe boundary or reported as a diagnostic.
+```
+
+### Later follow-ups
+
+- Richer MCP task/task-support integration if ordinary tool-call fallback is insufficient.
+- Streamable HTTP transport.
+- OAuth / remote auth.
+- Registry/package distribution.
+- Explicit MCP/Plugin bridge only if separately approved; do not conflate Plugin packages with MCP local server execution.
 
 ## Success criteria / exit conditions
 
-- `pod::feature` が external protocol-backed capability provider を表現できる。
-- local subprocess execution authority が明示的に型・config・grant として扱われる。
-- Feature-provided long-running service / connection manager を Pod lifetime に安全に接続できる。
-- discovery 後の dynamic tool contribution が通常 ToolRegistry と permission path に統合される。
-- MCP spec baseline `2025-11-25` に基づく local stdio server integration がある。
-- MCP tools が namespaced stable Yoi tool として使える。
-- MCP resources/prompts が明示 tool operation として使え、取得結果は通常 tool result として history に残る。
-- server-provided data が system/developer instruction、scope、permission、prompt-context、history persistence rules を弱めない。
-- secrets / env values / command args containing secrets が diagnostics、logs、model context に plaintext で出ない。
-- Streamable HTTP、remote auth、distribution、sampling、elicitation の扱いが out-of-scope / fail-closed / follow-up として明示されている。
-- local mock MCP server による focused tests と、関連 crate tests、`nix build .#yoi` による packaging validation が定義されている。
+- A local mock MCP server can be configured explicitly and initialized.
+- Discovered MCP tools appear as ordinary Yoi tools with stable namespacing.
+- Tool calls go through ordinary permission and history paths.
+- MCP resources/prompts are explicit operations, not hidden context injections.
+- MCP result forms are bounded and safely serialized.
+- Secret values, command/env details, and server diagnostics are redacted where required.
+- Local server trust boundary is documented: Yoi does not sandbox the configured executable through feature authority.
+- Feature, Plugin, and MCP permission/trust responsibilities are documented as separate layers.
 
 ## Decision context
 
-- `00001KST8H4M0` は broad MCP integration Ticket として作られていたが、今後はこの Objective の背景 context として扱い、実装 authority は concrete Tickets に置く。
-- `00001KTR81P9X` は API/architecture prerequisite。MCP 実装が ToolRegistry / permission / history path を迂回しないための土台を作る。
-- `00001KTR82RB7` は MCP implementation Ticket。API 拡張の結果に乗って local stdio MCP server features を実装する。
-- Objective-to-Ticket links は context であり、dependency/scheduling authority ではない。実際の routing / readiness / blockers は各 Ticket の body/thread/artifacts と Orchestrator 判断に置く。
-- `resources/prompts` は scope 外に固定しない。安全条件は「direct hidden context injection をしない」ことであり、明示 tool result として扱うなら MCP integration の対象に含める。
+- MCP is not the Plugin model; it is a protocol-backed integration layer using `pod::feature` substrate.
+- `pod::feature` should provide contribution/lifecycle/runtime-discovered registration plumbing, not MCP server trust policy or Plugin package permission policy.
+- MCP resources and prompts must never be hidden context injection. They are explicit operations recorded through ordinary history/tool paths.
+- Provider-discovered tools are discovered at startup/provider initialization and registered before model exposure; model-visible schemas remain run-stable during a request/run.
+- Local stdio server execution is a user/config trust decision. Yoi does not sandbox the local executable merely because it is configured through MCP.

.yoi/objectives/00001KVG0HR9M/item.md

@@ -0,0 +1,101 @@
+---
+title: "Plugin platform roadmap"
+state: "active"
+created_at: "2026-06-19T13:18:58Z"
+updated_at: "2026-06-24T19:55:00Z"
+linked_tickets: ["00001KV5R5V2S", "00001KV5W3PHA", "00001KV5W3PHW", "00001KV5W3PJ3", "00001KVFD3YSV", "00001KVFDX9AF", "00001KVFDX9AY", "00001KVG0HR96", "00001KVXHVCR5", "00001KVXK0WD3", "00001KVXK0WDH", "00001KVXK0WDQ", "00001KVXK0WDX", "00001KVXK0WE4", "00001KVXK0WEA"]
+---
+
+## Goal
+
+Build Yoi's Plugin platform as a coherent extension system: packages are discovered and inspected safely, enabled explicitly, registered through typed Plugin surfaces, executed in a sandboxed runtime, constrained by Plugin-layer grants, and authored through SDK/templates rather than raw runtime ABI details.
+
+The long-term platform goal is not merely to run Wasm. It is to make Plugin packages a durable, inspectable, permissioned, and authorable extension layer for Tools first, then host APIs (`https`, `fs`), and later Service / Ingress surfaces when concrete needs justify them.
+
+## Motivation / background
+
+The current Plugin foundation is already substantial:
+
+- package discovery and explicit enablement resolver;
+- Tool surface registration through the ordinary ToolRegistry/model-visible schema path;
+- minimal sandboxed WASM Tool execution;
+- Plugin permission grant enforcement;
+- follow-up Tickets for read-only inspection CLI, `https`, `fs`, and Component Model migration.
+
+The remaining work must be kept as one roadmap because the pieces constrain each other:
+
+- Plugin authoring needs an SDK/PDK and examples, not raw pointer/length Wasm ABI hand-coding.
+- `https` and `fs` host APIs must be grant-gated and shaped so they can move cleanly to typed Component Model interfaces.
+- Diagnostics (`yoi plugin list/show`) are needed before the system becomes harder to debug.
+- Component Model adoption should guide new host API design before a custom raw ABI becomes entrenched.
+- Service / Ingress are useful for bridge-style integrations, but should come after Tool runtime, diagnostics, and host API policy are stable.
+
+Research of common Wasm extension systems points to the same pattern: mature systems combine a package manifest, explicit capabilities, a sandbox runtime, host-provided capability APIs, language SDK/PDK bindings, templates/examples, inspection/check tooling, and versioned interfaces.
+
+## Strategy / design direction
+
+- Keep Plugin as a user-facing package/config/runtime layer above lower-level `pod::feature` substrate.
+  - `pod::feature` provides contribution/registration substrate.
+  - Plugin owns package discovery, enablement, grant policy, runtime selection, authoring UX, and user-facing diagnostics.
+- Preserve authority boundaries.
+  - Package discovery is read-only inventory.
+  - Package presence never registers a Tool/Hook, executes Wasm, starts a Service, reads files, opens network, or injects context.
+  - Explicit enablement and Plugin grants are required before registration/execution/host API use.
+  - Tool calls/results continue through ordinary ToolRegistry and Worker history paths.
+- Treat Component Model as the active Plugin runtime shape before public release.
+  - New typed Plugin host APIs should be designed in WIT-compatible terms.
+  - `runtime.kind = "wasm-component"` is the current Plugin runtime authority for new work.
+  - The earlier `yoi-plugin-wasm-1` raw core-Wasm compatibility bridge is retired from the active roadmap because Plugin has not been publicly released and compatibility would preserve the wrong boundary.
+- Sequence the platform in usable layers:
+  1. Package discovery / explicit enablement / digest-pinned restore. Completed foundation.
+  2. Tool surface registration. Completed foundation.
+  3. Minimal WASM Tool execution. Completed foundation.
+  4. Permission grants. Completed foundation.
+  5. Read-only Plugin CLI inspection (`yoi plugin list/show`) for debugging discovery/enablement/grants/runtime metadata.
+  6. `https` and `fs` host APIs for Tool Plugins, grant-gated and WIT-compatible.
+  7. Remove the raw core-Wasm compatibility bridge and reject legacy runtime manifests.
+  8. Component Model runtime and authoring model become the only active Plugin runtime path.
+  9. Guest SDK/PDK, examples, `check`/`pack`/`new` authoring tooling target Component Model only.
+  10. Service / Ingress runtime is developed as host-managed lifecycle, event queue, output command, and diagnostics slices.
+  11. WebSocket support for long-lived integrations is host-owned connection driver + ingress event delivery + output command, not Plugin-owned polling with `recv(timeout)`.
+- Keep Discord-style bridge goals split into two stages.
+  - Outbound Discord/webhook Tool is possible after `https`.
+  - Bidirectional Discord bridge requires Service + Ingress + WebSocket or inbound HTTP and host routing policy.
+
+## Current implementation split
+
+The broad Plugin runtime redesign is tracked by `00001KVXHVCR5` as context only; implementation should proceed through concrete Tickets instead of routing that umbrella as a single coding task.
+
+1. `00001KVXK0WD3` Remove legacy raw WASM Plugin runtime.
+   - Deletes the active `LegacyToolAdapter` / raw-Wasm execution path.
+2. `00001KVXK0WDH` Reject legacy Plugin runtime in manifest and CLI diagnostics.
+   - Makes `plugin.toml`, `yoi plugin check/list/show`, docs, and fixtures reflect Component Model only runtime authority.
+3. `00001KVXK0WDQ` Define Plugin Service lifecycle and ingress queue runtime.
+   - Adds host-managed lifecycle, bounded queue, serial dispatch, backpressure, timeout, and diagnostics.
+4. `00001KVXK0WDX` Add Plugin service output command model.
+   - Lets service handlers request side effects as grant-checked commands rather than ambient authority.
+5. `00001KVXK0WE4` Add host-owned WebSocket driver for Plugin services.
+   - Converts incoming WS frames into ingress events and sends outbound frames through output commands.
+6. `00001KVXK0WEA` Update Plugin WIT PDK templates for service event runtime.
+   - Aligns authoring API, WIT, PDK, templates, and docs with the new event/command execution model.
+
+## Success criteria / exit conditions
+
+- Users can inspect Plugin discovery/enablement/grant/runtime state through a read-only CLI without executing Plugin code.
+- Plugin authors can build a Tool Plugin without writing raw memory/pointer ABI plumbing.
+- Tool Plugins can safely call grant-gated `https` and `fs` host APIs.
+- Component Model is the only active Plugin runtime path, with WIT-compatible host API types and measured packaging/runtime impact.
+- Plugin grants remain authoritative over registration, execution, and host API calls.
+- Plugin diagnostics explain missing package, invalid manifest, digest/version mismatch, missing grant, rejected schema, runtime mismatch, legacy runtime rejection, and unsupported host API cases safely.
+- Raw core-Wasm Plugin compatibility is removed before public release; tests and docs no longer treat it as a current runtime.
+- Documentation covers package format, Component Model runtime, host API authority, authoring SDK/templates, Service/Ingress event runtime, and operational debugging.
+- Service/Ingress work is host-managed: services have lifecycle/status, ingress uses bounded queues, side effects are output commands, and WebSocket integrations use host-owned connection drivers.
+
+## Decision context
+
+- This Objective is roadmap context, not Ticket authority. Implementation still requires reading concrete Ticket bodies, threads, artifacts, and relations.
+- Component Model direction supersedes Yoi's custom raw ABI as both long-term and current active Plugin runtime authority before public release.
+- `https` / `fs` work should avoid choices that conflict with later WIT typed interfaces.
+- Guest SDK work targets Component Model directly; raw ABI wrappers are not a supported transitional authoring path.
+- Plugin and MCP remain separate. Component Model adoption for Plugin does not imply MCP server execution, MCP prompt/resource injection, or MCP trust policy changes.
+- Plugin surfaces remain Tool / Hook / Service / Ingress; outbound side effects are Tool metadata and host API grants, not a separate surface.

.yoi/objectives/00001KVJPT2PP/item.md

@@ -0,0 +1,249 @@
+---
+title: "Team workspace control plane and runner architecture"
+state: "active"
+created_at: "2026-06-20T14:26:29Z"
+updated_at: "2026-06-21T18:10:00Z"
+linked_tickets: ["00001KVMFFYVX"]
+---
+
+## Goal
+
+Yoi を、単一のローカル開発ディレクトリで動くエージェント実行ツールから、チームで作業・判断・実行結果を管理できるワークスペース基盤へ発展させる。
+
+この Objective の中心は、Web から扱える管理システムを作り、その管理システムにローカル実行環境・リモート実行環境・将来のクラウド実行環境を接続できるようにすることである。管理システムは Ticket、Objective、Memory、Knowledge、Run、Artifact、Runner の正本を持つ。実行環境はその管理システムから仕事を受け取り、コード取得、作業用ディレクトリ作成、エージェント実行、検証、結果報告を行う。
+
+この Objective は Git ホスティングサービスを作るものではない。Git は重要な Repository provider として扱うが、Yoi の Workspace は Git Repository root と同じものにしない。Yoi が作るべきものは、コード・ドキュメント・データ・成果物などの Repository と実行環境を接続しながら、人間とエージェントの作業、Ticket lifecycle、Memory/Knowledge、検証証跡、実行環境配置を管理するチームワークスペースである。
+
+## Glossary
+
+この Objective では、以下の語をこの意味で使う。
+
+- Workspace: チームまたはプロジェクトの管理単位。Ticket、Objective、Memory、Knowledge、Run、Artifact、Policy、Actor、Repository を持つ。Git Repository root ではない。
+- Control plane: Workspace の正本を持ち、Web UI / API / CLI から操作される管理システム。
+- Runner: Control plane から仕事を受け取り、実際にエージェントやツールを動かす実行環境。最初はローカルマシン上の runner、後でリモート runner やクラウド runner を追加する。
+- Repository: Workspace に接続される source/storage。コード、ドキュメント、local directory、object storage、artifact store、dataset などを含む。Git Repository も Repository の一種であり、基本的には filesystem path ではなく URI / URL で識別する。
+- Repository provider: Repository の種類ごとの実装。Git、local filesystem、object store、artifact store、将来の non-Git VCS など。
+- RepositoryPoint: Repository 内の特定地点。Git commit/ref/path、object store version/prefix、file snapshot/path など、provider ごとの revision/ref/snapshot/path を表す。
+- Execution Workspace: Runner が Run のために作る作業用ディレクトリや container filesystem。1 つ以上の RepositoryPoint から materialize される。Git worktree、clone、sparse checkout などはこれを作る手段である。
+- Ticket: チームで扱う作業単位。目的、要件、判断、議論、完了条件、関係、証跡を持つ。
+- Objective: 複数の Ticket を束ねる長期目標や設計方針。
+- Run: Ticket や Objective に対して行われた具体的な実行試行。どの Runner が、どの Execution Workspace で、何を実行し、どんな結果になったかを持つ。
+- Artifact: Run や Ticket に紐づく成果物や証跡。diff、log、validation result、review result、report など。
+- Memory: エージェントやユーザーが再利用するための要約された文脈。Ticket や Run の正本ではない。
+- Knowledge: 保守された知識や設計判断。Memory より人間が維持する資料に近い。
+- Actor: 人間、エージェント、システム、外部サービスなど、Workspace 上で操作や発言を行う主体。
+
+## Motivation / background
+
+現在の Yoi は、ローカルの `.yoi` ディレクトリ、ローカルプロセス、Ticket ファイル、ワークツリー運用によって、自分自身の開発に使えるエージェント実行環境になっている。しかし、チーム利用、Web UI、リモート実行、クラウド実行、最終的な SaaS 提供を考えると、次の前提を変える必要がある。
+
+- Workspace を Git Repository root と同一視しない。
+- ローカル filesystem 上の `.yoi` を、長期的なチーム用正本 store にしない。
+- Ticket をローカル作業メモではなく、チームの作業調整 record にする。
+- Ticket と実行試行を分ける。実行試行は Run として記録する。
+- 管理システムと実行環境を分ける。
+- まず Web から Ticket、Objective、Memory、Knowledge、Run、Artifact、Runner state を見られるようにする。
+- 最初はローカルマシンを Runner として使い、後でリモート Runner、クラウド Runner、runner pool、resource allocation、quota、billing、sandboxing に拡張する。
+- Git ホスティング機能を取り込むのではなく、Git Repository / worktree / clone は Repository provider と Execution Workspace materialization の手段として扱う。
+
+OSS として Control plane、Runner、Web frontend、protocol を公開しつつ、managed service では hosted control plane、runner fleet、リソース柔軟性、team auth、backup、audit、availability、multi-tenant operations で価値を出す。
+
+## Strategy / design direction
+
+### 1. Control plane を先に作る
+
+Team Workspace の正本は server-side control plane に置く。`.yoi` は local backend、single-user/self-hosted compatibility、offline/export/import、runner-local projection、migration bridge として残せるが、multi-user SaaS の正本とはみなさない。
+
+Control plane は Ticket、Objective、Memory、Knowledge、Run、Artifact、Actor、Permission、Audit、Runner state を管理する。Web UI、CLI、TUI、将来の desktop client は、この Control plane を操作する client であり、別の正本 store を持たない。
+
+### 2. Workspace と Repository を同一視しない
+
+Workspace はチームまたはプロジェクトの作業管理単位である。Repository は Workspace に接続される source/storage である。Git Repository は Repository の一種にすぎない。
+
+1 つの Workspace は複数の Repository を持てる。Repository は filesystem path ではなく URI / URL で識別する。例として `git+https://...`、`file://...`、`s3://...`、`artifact://...`、将来の VCS provider URI などを扱えるようにする。
+
+Ticket と Objective は Repository 配下に置かず、Workspace 配下に平たく持つ。Ticket は必要に応じて対象 Repository、ref selector、path、必要 capability を持つ。Objective は複数 Ticket にまたがる target default / scope hint を持てるが、Repository の所有物にはしない。
+
+Run は Ticket の target selector を具体的な RepositoryPoint に解決し、その RepositoryPoint から Execution Workspace を materialize する。Git worktree 相当の機能は、この Execution Workspace を作るための実装戦略として扱う。
+
+短期的には Git を主な Repository provider とする。ただし Yoi の authority model を Git object、Git branch、Git Repository root、worktree path に固定しない。Orchestration は Git そのものではなく、`resolve_ref`、`materialize`、`diff`、`patch`、`commit`、`merge` などの Repository capability に依存する。
+
+### 3. Ticket を team coordination record にする
+
+Ticket は実行そのものではない。Ticket は「何を、なぜ、どの条件で完了とみなすか」を持つ。Ticket は Workspace に平たく所属し、Repository には所属しない。コードやドキュメントを対象にする Ticket は、対象 Repository / ref selector / path / intent を target として持つ。
+
+Ticket target は intent/selector であり、実行再現性のための immutable point ではない。Run が target selector を concrete RepositoryPoint に解決し、実際にどの revision/snapshot を materialize したかを記録する。
+
+```text
+Ticket
+  -> target selectors: Repository + ref selector + path + intent
+  -> Run / Attempt
+  -> resolved RepositoryPoint
+  -> Execution Workspace
+  -> Artifact / Evidence
+  -> Review / Decision
+  -> Audit / Notification
+```
+
+Target 例:
+
+```text
+Ticket targets:
+  - repository: main-code
+    role: primary
+    ref: develop
+    paths: ["crates/pod/"]
+    intent: change
+  - repository: docs
+    role: related
+    ref: main
+    paths: ["docs/development/"]
+    intent: read
+
+Run inputs:
+  - repository: main-code
+    requested_ref: develop
+    resolved_point: git commit abc123
+    mount: /workspace/main-code
+```
+
+Ticket には次の概念が必要になる。
+
+- Actor identity: human / agent / system / service account.
+- Assignment / owner / reviewer / watcher.
+- Typed thread events: comment, decision, plan, review, implementation report, state transition.
+- Linked Objective / Artifact / Run / Repository / RepositoryPoint / Execution Workspace.
+- Permission / visibility.
+- Audit trail.
+- Notification / mention.
+- Board / queue / planning / review / done / archived views.
+- Conflict handling and concurrent editing policy.
+
+### 4. Memory / Knowledge の本格再設計は後回しにする
+
+Memory / Knowledge は Ticket / Run / Artifact のコピーではない。再利用可能な文脈、方針、学習された制約、保守された知識として扱う。ただし、Memory の意味論・抽出・承認・検索・staleness 処理を今この Objective で先に作り込まない。
+
+理由は、Memory の正しい設計が Workspace control plane の record model、Actor / visibility / permission、Ticket と Run の分離、Artifact / evidence、RepositoryPoint、Runner に渡す context の監査方法に依存するためである。これらが固まる前に Memory schema だけを作ると、local `.yoi` 前提や現行 agent runtime 前提に引っ張られ、後で再設計が必要になる。
+
+この Objective では、Memory / Knowledge について以下の platform contract だけを維持する。
+
+- Memory / Knowledge は Control plane が扱う record だが、Ticket / Run / Artifact の authority を置き換えない。
+- 将来、Memory / Knowledge の canonical storage は Workspace control plane 側に置く。
+- local `.yoi` memory は compatibility、offline/export/import、runner-local projection、migration bridge として扱う。
+- Personal Memory、Workspace Memory、Run Summary、Maintained Knowledge は分離が必要である。
+- Generated Memory には provenance、visibility、approval、audit が必要である。
+- Runner / agent に渡した Memory/Knowledge context は、将来 ContextPack などとして Run に記録できる必要がある。
+
+本格的な Memory 再設計は、Memory の保存先を Workspace backend / control plane record に移すタイミングで回収する。それまでは低リスクな観察、問題例の収集、既存 local memory の互換維持に留める。
+
+### 5. 管理システムと実行環境を弱結合にする
+
+Control plane は正本と調整を持つ。Runner は実行を担当する。
+
+初期形:
+
+```text
+Web UI / Control Plane
+  -> Runner connection
+  -> Local machine runner
+  -> Existing Yoi runtime, tools, working copy, build/test commands
+```
+
+この段階では、現在ローカル管理画面が行っている Ticket 選択、エージェント起動、レビュー起動、作業用 checkout 作成、検証実行、結果表示を、Web/control plane から local runner に対して実行できるようにする。
+
+その後で、remote runner、self-hosted runner、hosted cloud runner、runner pool、resource allocation、quota、billing、sandbox、network policy、secret distribution を追加する。
+
+```text
+Phase 1: Web control plane + local runner
+Phase 2: Remote/self-hosted runner
+Phase 3: Hosted cloud runner fleet
+Phase 4: Resource allocation / scheduling / quotas / billing / isolation
+```
+
+### 6. Web frontend を先に作る
+
+Desktop app は対応コストが高いので、まず Web frontend を primary UI とする。
+
+- Web: チームで使う主要 UI。
+- CLI: automation、scripting、local operations。
+- TUI/local panel: local runner cockpit、fallback、dogfooding surface。
+- Future desktop: Web/control-plane model が安定した後に検討する optional client。
+
+Web UI は Ticket、Objective、Memory、Knowledge、Run、Runner、Artifact を扱う。UI の都合で正本を二重化しない。
+
+### 7. 多重起動コストと runtime placement を見直す
+
+Cloud/remote execution を成立させるには、多数のエージェント実行を安く管理できる必要がある。logical agent session と runtime process/resource placement を分ける。
+
+初期 Workspace DB では、Worker を canonical table として永続化しない。Host / Worker 一覧は backend-local runtime inspection や将来の Host protocol から逐次取得する live view とし、Ticket に関わった Worker は Ticket thread events と WorkerRef snapshot / TicketWorkerLink として記録する。
+
+Worker の一元管理、データ永続化、アーカイブは将来的には必要になる。これは Host protocol、remote/self-hosted/hosted worker lifecycle、worker identity、retention policy、audit requirements が固まった後に、dedicated Worker registry / archive model として追加する。v0 で Pod metadata の代替として Worker table を作らない。
+
+検討対象:
+
+- Agent identity と process/runtime placement の分離。
+- Provider client、tool registry、resource cache の共有可能性。
+- Prompt/resource/profile resolution cache。
+- Model call multiplexing and scheduling。
+- Tool execution sandbox reuse。
+- Plugin instance / Service runtime との統合。
+- Session/event stream と runtime lifecycle の分離。
+- Runner-local cache、checkout reuse、build cache、dependency cache。
+
+## Initial phases / candidate tickets
+
+1. **Vocabulary / architecture record**
+   - Workspace / Repository / RepositoryPoint / Execution Workspace / Runner / Control Plane / Run / Ticket / Memory / Knowledge の用語と境界を固める。
+2. **Team-space canonical data model**
+   - Ticket / Objective / Target / Run / Artifact / Actor / Permission / Audit / Memory / Knowledge の entity/event model を設計する。
+3. **Ticket and Run separation**
+   - Ticket lifecycle と execution attempt / orchestration run / validation run を分離し、Ticket thread と Run evidence の責務を明確化する。
+4. **Memory storage migration boundary**
+   - Memory / Knowledge の本格再設計は後回しにし、まずは Workspace backend に移す時の platform contract、compatibility/cache/export 方針、将来の provenance / visibility / approval 要件だけを固定する。
+5. **Control plane backend architecture**
+   - local `.yoi` backend と server-side canonical backend の境界、migration/export/import、compatibility mode を設計する。
+6. **Web control plane MVP design**
+   - read-only Ticket / Objective / Memory / Knowledge / Runner state UI/API の範囲を決める。
+7. **Local runner protocol design**
+   - Web/control plane から local runner に安全な操作を送る protocol と authority boundary を設計する。
+8. **Repository and Execution Workspace materialization model**
+   - Repository URI、Repository provider capability、RepositoryPoint resolution、Git worktree / clone / sparse checkout / future source backend を runner-side strategy として抽象化する。
+9. **Remote/hosted runner foundation**
+   - runner registration, heartbeat, capability advertisement, job assignment, logs/events, secrets, sandbox/resource policy を設計する。
+
+## Non-goals
+
+- Git hosting service を作ること。
+- `.yoi` filesystem をそのまま SaaS canonical store にすること。
+- 最初から full hosted cloud execution を作ること。
+- local execution / CLI / TUI / local panel を捨てること。
+- Ticket を単なる issue tracker clone にすること。
+- Memory を Ticket/Run audit log の代替にすること。
+- Web UI のために core authority を二重化すること。
+- hidden server state を LLM context に直接注入すること。
+- multi-tenant auth/billing/secret/security を shortcut して実装すること。
+
+## Success criteria / exit conditions
+
+- Workspace / Repository / RepositoryPoint / Execution Workspace / Runner / Control Plane / Run / Ticket / Memory / Knowledge の境界が文書化されている。
+- Ticket が team coordination record として、target selector / Run / Artifact / Actor / Permission / Audit と分離された model を持つ。
+- `.yoi` local backend は compatibility/local backend として整理され、server-side canonical backend の設計を阻害しない。
+- Web UI/API が Ticket / Objective / Runner state を中心とした read-only view を提供できる設計または MVP を持つ。Memory / Knowledge は既存 record の表示または将来 placeholder に留め、本格再設計をこの段階の必須条件にしない。
+- Control plane から local runner に対して、現在のローカル管理画面相当の安全な操作を実行できる design/protocol がある。
+- Git Repository root に依存しない Workspace model があり、Git Repository は Repository provider の一種として扱われている。
+- Ticket と Objective は Workspace 配下に平たく存在し、Repository への所属ではなく target selector / scope hint で対象を表現する。
+- Git worktree 相当は Execution Workspace materialization strategy として扱われ、Run が immutable な RepositoryPoint を記録する。
+- Memory / Knowledge は Ticket / Run / Artifact の authority を置き換えない record として platform contract だけを持つ。本格的な意味論・抽出・承認・検索・staleness 処理は、Memory の保存先を Workspace backend / control plane record に移すタイミングで回収する。
+- Hosted runner / resource allocation / SaaS offering に進むための後続 Ticket が切れる状態になっている。
+- 既存 local dogfooding runtime を壊さず、local use と remote-capable architecture が両立している。
+
+## Decision context
+
+- Yoi は hosted Git tool ではなく、team workspace control plane + execution environment として設計する。
+- Team-space の長期 canonical authority は server-side control plane に置く。local `.yoi` は互換/local/offline/export/import surface だが、multi-user SaaS の正本ではない。
+- 実行環境と管理システムは弱結合にする。まず管理システムを独立させ、local runner を実行環境として接続する。その後に remote/self-hosted/hosted runner fleet へ進む。
+- Web frontend を最初の primary team UI とする。Desktop app は web/control-plane model が安定した後に検討する。
+- Git は重要な Repository provider / materialization backend として使うが、Workspace identity と authority を Git Repository root に固定しない。
+- Ticket と Objective は Workspace 配下に平たく持つ。対象コードベースや ref は Repository target selector として表現し、Run が concrete RepositoryPoint に解決する。
+- Memory の本格再設計は後回しにする。先に Workspace / Ticket / Repository / Host/Worker live view / Control plane の基盤を固め、Memory の保存先を Workspace backend に移すタイミングで、意味論・抽出・承認・検索・staleness 処理をまとめて回収する。
+- Worker の一元管理・データ永続化・アーカイブも後続設計に回す。初期 DB では Worker を Pod metadata の代替として永続化せず、live view と Ticket-linked WorkerRef 記録に留める。

.yoi/objectives/00001KVJSMQXZ/item.md

@@ -0,0 +1,268 @@
+---
+title: "効果的な Memory システム設計・検証"
+state: "active"
+created_at: "2026-06-20T15:16:00Z"
+updated_at: "2026-06-20T15:16:00Z"
+linked_tickets: ["00001KSKBPHRG", "00001KT02TCCG", "00001KTGCAFXG", "00001KSKBPTHR"]
+---
+
+## Goal
+
+Yoi の Memory / Knowledge / generated memory / resident context / retrieval / usage metrics を、実際の開発・設計・レビュー・オーケストレーションに効く sensemaking substrate として再設計・検証する。
+
+この Objective でいう「効果的な Memory システム」は、単に多く保存する仕組みではなく、作業中の問いに対して relevant material を集め、根拠を検証可能にし、再表現・仮説形成・反証探索・意思決定・成果物への反映を低コストにする仕組みである。
+
+暫定的な定義:
+
+- foraging cost を下げる: Ticket / Objective / current question に対して、関連する memory / docs / tickets / session evidence / code references を探しやすい。
+- evidence を失わない: Memory が authority そのものにならず、Ticket / docs / git history / session logs / user instruction への検証可能な入口になる。
+- schema 化を支援する: raw summary ではなく、subsystem、invariant、risk、authority boundary、open question、rejected alternative、hypothesis など推論しやすい形へ再表現できる。
+- hypothesis loop を支援する: 支持証拠だけでなく、代替仮説・棄却理由・反証 evidence・stale assumption を扱える。
+- product に戻る: Memory に保存して終わりではなく、Ticket、review、docs、implementation、decision、report に影響を戻せる。
+- stale / contradiction を扱う: 古い前提、矛盾、適用範囲外の memory を検出・降格・更新できる。
+- usage を成果基準で測る: resident exposure や read count ではなく、判断・レビュー・実装・docs に効いたかを観測できる。
+
+## Motivation / background
+
+現在の Memory システムは「墓場化」している。保存された情報はあるが、後続の作業で自然に使われにくく、使われたとしても根拠・適用範囲・鮮度・反証可能性が弱い。結果として Memory は、作業場ではなく古い結論の倉庫になりやすい。
+
+Pirolli & Card 2005 の sensemaking model では、分析作業は単なる保存ではなく、次の変換として捉えられる。
+
+```text
+external data sources
+-> shoebox
+-> evidence file
+-> schema / representation
+-> hypotheses
+-> presentation / product
+```
+
+Yoi の現行 Memory は、この流れのうち「保存」と「一部の検索」には対応しているが、少なくとも以下が弱い。
+
+- Ticket / task / question ごとの shoebox がない。
+- shoebox から evidence snippets を切り出し、source / provenance / applicability / confidence と共に扱う evidence file がない。
+- `summary`, `decision`, `request`, `knowledge` は storage taxonomy であり、sensemaking 用 schema としては粗い。
+- decision は残るが、hypothesis space、alternative、rejected reason、disconfirming evidence が残りにくい。
+- reviewer / orchestrator が confirmation bias を避けるための反証探索導線が弱い。
+- resident exposure と explicit retrieval は観測できても、Memory が product に効いたかは測りにくい。
+
+この Objective は、Memory 関連の設計・検証・検討・考察を一元化し、個別 Ticket がばらばらに storage、prompt、retrieval、metrics を改善して再び墓場を増やすことを防ぐための判断背景である。
+
+## Strategy / design direction
+
+Memory を「長期保存領域」ではなく、Yoi の multi-agent 開発における sensemaking loop の支援機構として設計する。
+
+### 1. Pirolli & Card の stage に合わせて責務を分ける
+
+- external data sources: Tickets、docs、git history、session logs、reports、code、user instructions。
+- shoebox: 特定 Ticket / Objective / design question に対して関連しそうな材料を集めた task-bound working set。
+- evidence file: shoebox から抜き出した根拠 snippet。source anchor、支持/反証、適用範囲、confidence、staleness を持つ。
+- schema / representation: subsystem、invariant、risk、authority boundary、open question、hypothesis、alternative、contradiction など、推論しやすい再表現。
+- hypotheses: 採用前の設計仮説、代替案、棄却条件、反証 evidence。
+- product: Ticket、review、docs、implementation、decision、report、orchestration plan などの成果物。
+
+### 2. 最初の重点は task-bound shoebox と evidence file
+
+Memory 墓場化の最初の原因は、保存情報が現在の問いに集まらないことである。まずは Orchestrator / Intake / Reviewer が Ticket を扱う時に、関連 memory / docs / tickets / reports / prior decisions を shoebox として束ねる導線を作る。
+
+この段階では大きな永続 schema 追加に飛びつかず、report / Ticket artifact / bounded generated context として検証してよい。
+
+### 3. Memory を authority にしない
+
+Memory は Ticket、docs、git history、session logs、user instruction の代替ではない。Memory は authority record への evidence index / schema / reasoning aid として扱う。
+
+したがって、改善案は次の性質を持つべきである。
+
+- source / provenance を辿れる。
+- stale / superseded / contradicted を扱える。
+- Memory の断定をそのまま authority として使わない。
+- Ticket body/thread/artifacts を読まずに Objective や Memory だけで実装判断できる状態を作らない。
+
+### 4. 反証探索を first-class にする
+
+より効果的な Memory は、過去方針を思い出すだけでなく、現在案を疑うために使える必要がある。
+
+Reviewer / Orchestrator / Intake の導線では、次を探せるようにする。
+
+- supporting evidence
+- contradicting evidence
+- stale decisions
+- rejected alternatives
+- unresolved questions
+- authority boundary risks
+- prior failures / reports
+
+### 5. Metrics は exposure から product impact へ寄せる
+
+Memory が prompt に入った、または query されたことは成功ではない。評価は次を区別する。
+
+- resident exposure
+- explicit retrieval
+- cited in response
+- cited in Ticket / review / report
+- changed requirement
+- changed implementation
+- contradicted / invalidated
+- led to docs or decision update
+
+### 6. 後続 Ticket は concrete slice に分割する
+
+この Objective は中期的な設計・検証の一元化 record であり、umbrella Ticket ではない。実装や調査は、単独で実装・レビュー・close できる concrete Ticket に分割する。
+
+候補 slice:
+
+- Memory sensemaking 分析 report を `docs/report/` に作る。
+- Ticket routing 用 Memory shoebox artifact を試作する。
+- evidence snippet schema / source resolver を設計する。
+- hypothesis / rejected alternative / disconfirming evidence の表現を追加する。
+- Reviewer workflow に反証探索を入れる。
+- Memory usage metrics を product impact oriented に拡張する。
+- stale / contradiction / renewal の検出・表示を設計する。
+
+## Success criteria / exit conditions
+
+- Memory システムの目的が「保存」ではなく「sensemaking loop 支援」として project records / docs / prompts / workflows で一貫して説明されている。
+- Pirolli & Card の `shoebox -> evidence file -> schema -> hypotheses -> product` に対応する Yoi 内の責務と非責務が整理されている。
+- Ticket / Objective / docs / session logs / Memory / Knowledge の authority boundary が明確で、Memory が authority を僭称しない。
+- 少なくとも一つの実作業 routing / review / design analysis で、task-bound shoebox または evidence file が生成・利用され、作業品質にどう効いたかが確認されている。
+- Memory records または関連 artifacts が source / provenance / applicability / staleness / supports-or-refutes のいずれかを扱えるようになっている。
+- Reviewer / Orchestrator が supporting evidence だけでなく、contradicting evidence / stale assumptions / rejected alternatives を探す導線を持っている。
+- Memory usage metrics が resident exposure と product impact を区別している。
+- 古い Memory が放置されるのではなく、stale / superseded / contradicted / needs-review として扱える方針がある。
+- 後続の実装 Ticket が concrete slice として分割され、Objective が Ticket dependency や進捗 container として使われていない。
+
+この Objective は、Memory が少なくとも一つの中規模設計・実装・レビュー作業で「関連情報を見つける」「根拠を確認する」「代替案/反証を検討する」「成果物へ反映する」流れを実証し、その設計方針が docs / workflows / metrics に反映された時点で `done` を検討できる。
+
+## Decision context
+
+- ユーザー指摘: 「Memoryシステムが完全に墓場化している」。これは保存量不足ではなく、保存情報が現在の問い・根拠・仮説・成果物に接続されない問題として扱う。
+- ユーザー指示: Memory システムの設計・検証・検討・考察を Objective にまとめ、より効果的な Memory システムを作成する目標のもとで情報を一元化する。
+- 「効果的」の定義は未確定だが、当面は Pirolli & Card の sensemaking process に沿って、foraging cost、evidence quality、schema usefulness、hypothesis/disconfirmation support、product impact、staleness handling を評価軸にする。
+- Memory は durable project authority ではない。Ticket、docs、git history、session logs、明示 user instruction の代替として使わない。
+- Objective context は判断背景であり、個別実装の authority は各 Ticket body/thread/artifacts と明示的な Ticket relations / OrchestrationPlan records にある。
+- `history` に残らない context-only injection を改善案にしない。新しい context input は history に commit する原則を守る。
+- Knowledge は単なる長期保存ではなく、再利用可能な schema / model / procedure / invariant として再検討する余地がある。
+- Generated memory / curated Knowledge / Ticket / docs / report の境界を再定義する場合は、authority boundary と migration/staleness を明示する。
+- 関連する既存 Ticket:
+  - `00001KSKBPHRG` — Prompt / Workflow 評価メトリクスと改善 Offer
+  - `00001KT02TCCG` — Memory prompt: conditional guidance and proactive lookup
+  - `00001KTGCAFXG` — Use .yoi/memory marker for repo-local memory root
+  - `00001KSKBPTHR` — ワークスペースのメモリーをLintするヘッドレスCLI
+
+## Historical references / prior design sources
+
+現在の Memory システムの初期設計時には、Codex Memories / Chronicle と HermesAgent を明示的な参考事例として調査していた。関連する調査・設計記録は、現在は主に以下に退避されている。
+
+- `docs/.local/old-docs/ref/memory-systems.md`
+- `docs/.local/old-docs/plan/memory.md`
+- 初期設計 commit: `ca5a3d11` — `2026-04-21 メモリシステムの設計`
+- 関連 commit:
+  - `0c1276b7` — `Memoryシステムの整理・Promptカタログチケット`
+  - `3d04f793` — `memoryを抽出する仕組みの実装`
+  - `f1b7af62` — `docs: memoryシステムの仕様変更と、動的Tool・VCSの話`
+  - `a2aecbf0` — `update: memoryシステムの"Phase"表記を撤廃`
+
+### Codex Memories / Chronicle から得た設計要素
+
+旧設計では、Codex Memories / Chronicle を `extract -> staging -> consolidation -> durable Markdown memory` の非同期パイプラインとして捉えていた。
+
+主な参照点:
+
+- extract と consolidation の 2 段構成。
+- extract は JSON schema / structured output で分類ブレを抑える。
+- consolidation は reasoning model / agentic rewrite によって、既存 memory と staging entries を統合・整理する。
+- staging と durable memory を分ける。
+- `MEMORY.md` は retrieval-oriented handbook として扱う。
+- `memory_summary.md` は prompt-loaded high-signal context として扱う。
+- `raw_memories.md` は routing layer / task inventory 的な中間層として扱う。
+- workspace diff や usage 情報を使い、stale / deleted evidence / noisy entries を整理する。
+- consolidation は append だけでなく、rewrite / merge / split / trim / drop / cleanup を担う。
+
+Yoi 初期設計では、これを参考に以下を意図していた。
+
+- activity token 閾値で extract を発火する。
+- compact より前に session log range を抽出する。
+- extract は `decisions`, `discussions`, `attempts`, `requests` などの候補を staging に保存する。
+- 抽出時点では Knowledge 化せず、純粋な「起きたこと」に寄せる。
+- consolidation が summary / decisions / requests / knowledge candidates を整理する。
+- consolidation 入力に linter warnings / usage metrics / Knowledge 化候補を含める。
+- stale / superseded / unused / noisy な情報を整理する。
+
+この Objective での再解釈:
+
+- Codex の `raw_memories.md` は、Pirolli & Card の sensemaking model では `shoebox` または `evidence file` に近い。
+- Yoi は extract / consolidation という pipeline だけを継承しても不十分であり、task-bound shoebox / evidence file / hypothesis loop / product feedback がなければ Memory は再び墓場化する。
+- 特に、staging を consolidation の一時入力としてだけ扱うと、後続 Ticket / Objective / review が使う探索入口にならない。
+- Yoi では `raw memories` 相当の中間層を、現在の問いに紐づく working set / evidence index として再設計する必要がある。
+
+### HermesAgent から得た設計要素
+
+旧設計では、Nous Research HermesAgent を 3 層の memory system として整理していた。
+
+- Persistent Memory:
+  - `MEMORY.md` / `USER.md`
+  - Markdown + SQLite / FTS5 session search
+  - 起動時 system prompt snapshot
+  - bounded character limits
+- Skill Library:
+  - procedural memory
+  - `~/.hermes/skills/<name>/SKILL.md`
+  - `skill_manage` tool による agentic CRUD
+- User Model / Honcho:
+  - dialectic user modeling
+  - 外部 service 連携
+
+HermesAgent で特に重要だった点:
+
+- memory / skill review は一定 turn / tool iteration ごとに background agent として起動する。
+- 保存すべきものがなければ `Nothing to save.` で NOP として終了する。
+- Yoi extract の「空配列許容」はこの設計からも影響を受けている。
+- memory は session start 時の frozen snapshot として system prompt に入り、mid-session write で prompt cache を壊さない。
+- persistent memory は bounded で、limit 超過時は deterministic eviction ではなく、agent に replace / remove を促す。
+- procedural memory / skills は一般 memory から分離されている。
+- SQLite FTS5 + LLM summarization による cross-session recall がある。
+
+この Objective での再解釈:
+
+- HermesAgent の `MEMORY.md` / `USER.md` / `skills` の分離は、Yoi の Knowledge / Workflow / prompt resource / docs / Ticket decision / generated memory の責務再整理に使える。
+- reusable procedure, reviewer focus, orchestration tactic, project preference, user preference, design invariant を同じ Memory bucket に入れると墓場化しやすい。
+- `Nothing to save.` / empty extraction allowed は重要だが、保存抑制だけでは効果的な Memory にはならない。保存されたものが task-bound shoebox / evidence / schema / hypothesis / product に接続される必要がある。
+- frozen snapshot / prompt cache 配慮は Yoi の history/context 加工原則と整合するが、それだけでは retrieval / resurfacing / disconfirmation は解決しない。
+
+### Lessons for the next design iteration
+
+Codex と HermesAgent の調査から、Yoi が継承すべきものと、継承するだけでは足りないものを分ける。
+
+継承すべきもの:
+
+- structured extract と agentic consolidation の分離。
+- staging / raw memories / durable memory の分離。
+- 保存対象がなければ NOP にする発火設計。
+- prompt-loaded summary と durable retrieval-oriented memory の分離。
+- stale / noisy / unused entries の cleanup。
+- procedural memory と declarative memory の分離。
+- session search / usage metrics / linter feedback を consolidation に入れる設計。
+
+足りないもの:
+
+- Pirolli & Card の sensemaking stage における各 record の役割定義。
+- Ticket / Objective / current question に紐づく task-bound shoebox。
+- authority record へ戻れる evidence file / provenance / source anchor。
+- hypothesis, alternative hypothesis, rejected reason, disconfirming evidence の first-class 表現。
+- reviewer / orchestrator が confirmation bias を避けるための反証探索導線。
+- resident exposure や read count ではなく product impact を測る metrics。
+- stale / contradiction / renewal を作業中に resurfacing する導線。
+
+したがって、次の Memory 設計は Codex / HermesAgent の単純なコピーではなく、以下を満たす必要がある。
+
+```text
+external data / sessions / tickets / docs / code
+-> task-bound shoebox
+-> evidence file with provenance
+-> schema / representation
+-> hypotheses and disconfirmation
+-> Ticket / review / docs / implementation / decision product
+-> product impact and stale-feedback metrics
+```
+
+この Objective では、以後の Memory 関連 Ticket / report / implementation をこの historical reference と sensemaking model の両方に照らして判断する。

.yoi/tickets/00001KSKBP9YG/artifacts/orchestration-plan.jsonl

@@ -0,0 +1 @@
+{"id":"orch-plan-20260613-141646-1","ticket_id":"00001KSKBP9YG","kind":"accepted_plan","accepted_plan":{"summary":"E2E harness Ticket を inprogress 受理する。Playwright-like declarative API、independent opt-in crate、read-only structured TUI test events、PTY input、failure artifacts、Panel mouse selection / quit latency regression scenario を最小 vertical slice として実装する。root/original workspace では作業しない。","branch":"ticket-00001KSKBP9YG-e2e-harness","worktree":"/home/hare/Projects/yoi/.worktree/e2e-harness","role_plan":"Orchestrator が dedicated child worktree を作成し、Coder Pod に E2E harness / TUI observability / CLI test hook に必要な限定 write scope を渡す。Coder は first slice として declarative PTY Panel harness と mouse/quit regression scenarios を優先し、Reviewer は production contamination と read-only observability invariant を重点確認する。"},"author":"orchestrator","at":"2026-06-13T14:16:46Z"}

.yoi/tickets/00001KSKBP9YG/artifacts/relations.json

@@ -0,0 +1,21 @@
+{
+  "version": 1,
+  "relations": [
+    {
+      "ticket_id": "00001KSKBP9YG",
+      "kind": "related",
+      "target": "00001KV0723PC",
+      "note": "Panel quit latency regression exposed need for measured PTY E2E, ready/barrier synchronization, and failure artifacts.",
+      "author": "orchestrator",
+      "at": "2026-06-13T13:56:37Z"
+    },
+    {
+      "ticket_id": "00001KSKBP9YG",
+      "kind": "related",
+      "target": "00001KV072V89",
+      "note": "Panel mouse selection regression exposed need for TUI/Panel PTY E2E with structured UI feedback and mouse input assertions.",
+      "author": "orchestrator",
+      "at": "2026-06-13T13:56:37Z"
+    }
+  ]
+}

.yoi/tickets/00001KSKBP9YG/artifacts/review-2026-06-13-e2e-harness-rereview.md

@@ -0,0 +1,27 @@
+Approve.
+
+Delta reviewed:
+- Re-reviewed the fix commit `b30b43b9 test: cfg-gate e2e observer payloads` after the earlier request-changes review.
+- Inspected the updated observer module boundary and call sites in `crates/tui/src/lib.rs` and `crates/tui/src/multi_pod.rs`, plus the unchanged harness/tests in `tests/e2e`.
+
+Evidence:
+- `e2e_observer` is now only compiled from `crates/tui/src/lib.rs` under `#[cfg(feature = "e2e-test")]`; the previous normal-build no-op facade was removed.
+- Observer payload construction is gated at call sites with `#[cfg(feature = "e2e-test")]`, including `panel_ready`, `selection_changed`, `action_requested`, `quit_requested`, and `emit_rows_rendered` calls.
+- Panel E2E DTOs/helpers (`PanelE2eRowKey`, `PanelE2eRect`, `PanelE2eRenderedRow`, `PanelE2eRowsRendered`, `App::emit_rows_rendered`) are now behind `#[cfg(feature = "e2e-test")]`, so the normal panel render path no longer builds row snapshots or retains that runtime helper path.
+- The background-task hold seam is still feature-gated: `check_background_task_hold` and `release_background_task_hold` calls are under `#[cfg(feature = "e2e-test")]`, and `YOI_TUI_TEST_HOLD_BACKGROUND_TASK` behavior lives in the gated observer module.
+- Mouse capture tracking remains intact in the harness: it tracks `?1000h` and `?1006h`, `click(...)` requires both capture modes before injecting PTY bytes, the test waits for rendered rows, asserts `selection_changed`, and asserts no `action_requested` dispatch.
+- Quit-latency coverage remains intact: the test waits for `panel_ready`, then verifies an actual pending `reload` background-task barrier before sending Ctrl+C through the PTY and asserting bounded exit.
+- The production/non-production boundary now satisfies the Ticket intent: the harness remains opt-in, observability is read-only and feature-gated, and no UI input/action path is bypassed.
+
+Validation run in `/home/hare/Projects/yoi/.worktree/e2e-harness`:
+- `git diff --check 134e8b8b..HEAD` — passed.
+- `cargo fmt --check` — passed.
+- `cargo check -p tui --all-targets` — passed.
+- `cargo check -p yoi --all-targets` — passed.
+- `cargo check -p tui --all-targets --features e2e-test` — passed.
+- `cargo check -p yoi --all-targets --features e2e-test` — passed.
+- `cargo build -p yoi --features e2e-test` — passed.
+- `YOI_E2E_BIN=/home/hare/Projects/yoi/.worktree/e2e-harness/target/debug/yoi cargo test -p yoi-e2e --features e2e --test panel -- --nocapture` — passed; 2 tests passed.
+- `cargo check -p yoi-e2e --all-targets --features e2e` — passed.
+
+No source changes were made during re-review.

.yoi/tickets/00001KSKBP9YG/artifacts/review-2026-06-13-e2e-harness.md

@@ -0,0 +1,25 @@
+Request changes.
+
+Evidence reviewed:
+- Inspected Ticket record and `git diff 134e8b8b..HEAD` for commits `96561897` and `10a1c383`.
+- `tests/e2e` provides a credible first declarative harness (`PanelHarness::spawn`, `wait_for`, `wait_for_rows`, `click`, `press`, `expect_selection`, `expect_exit_within`, artifacts/metadata/input/output/event logs). This is not merely a fixed-sleep shell script.
+- Mouse-selection scenario waits for rendered rows, verifies both normal mouse and SGR mouse capture before `click`, sends the click through PTY bytes, waits for `selection_changed`, and asserts no `action_requested` dispatch.
+- Quit-latency scenario creates a real feature-gated background-task hold barrier, waits until the task is actually waiting before sending Ctrl+C through the PTY, and measures bounded exit latency.
+- `yoi-e2e` is opt-in via package feature/test `required-features = ["e2e"]`; e2e tests are outside default members. `YOI_TUI_TEST_EVENTS` and `YOI_TUI_TEST_HOLD_BACKGROUND_TASK` env behavior is behind `tui/e2e-test` / `yoi/e2e-test` feature gates, and the hook is observability-only.
+
+Required change:
+- The normal production build still contains/evaluates too much e2e harness glue. In non-`e2e-test` builds, `crates/tui/src/e2e_observer.rs` exposes no-op `emit`/hold functions, but call sites still execute test-specific data construction. In particular `App::emit_rows_rendered` and its panel row key/rect DTOs are compiled unconditionally and `app.emit_rows_rendered()` is called from the panel render path, causing row snapshots to be built every draw even though emission is a no-op. Selection/action/quit call sites also construct `serde_json::json!` payloads before the no-op facade. This violates the recorded boundary that production binaries should not contain harness logic and production-side hooks must be feature-gated/compiled out for normal builds.
+  - Please cfg-gate the call sites/helpers/DTOs, or use a lazy cfg-gated macro/helper so normal builds do not evaluate or retain e2e event payload construction. A tiny compile-only facade is acceptable only if it does not execute or allocate e2e-specific work and does not keep harness DTO logic in the normal runtime path.
+
+Validation run in `/home/hare/Projects/yoi/.worktree/e2e-harness`:
+- `git diff --check 134e8b8b..HEAD` — passed.
+- `cargo fmt --check` — passed.
+- `cargo check -p tui --all-targets` — passed.
+- `cargo check -p yoi --all-targets` — passed.
+- `cargo build -p yoi --features e2e-test` — passed.
+- `YOI_E2E_BIN=/home/hare/Projects/yoi/.worktree/e2e-harness/target/debug/yoi cargo test -p yoi-e2e --features e2e --test panel -- --nocapture` — passed.
+- `cargo check -p tui --all-targets --features e2e-test` — passed.
+- `cargo check -p yoi --all-targets --features e2e-test` — passed.
+- `cargo check -p yoi-e2e --all-targets --features e2e` — passed.
+
+No source changes were made during review.

.yoi/tickets/00001KSKBP9YG/item.md

@@ -1,8 +1,10 @@
 ---
 title: "E2E テストハーネス"
-state: "planning"
+state: 'closed'
 created_at: "2026-05-27T00:00:02Z"
-updated_at: "2026-05-27T00:00:02Z"
+updated_at: '2026-06-13T16:34:06Z'
+queued_by: 'yoi ticket'
+queued_at: '2026-06-13T14:17:34Z'
 ---
 
 ## Migration reference

.yoi/tickets/00001KSKBP9YG/resolution.md

@@ -0,0 +1 @@
+Closed after prior done-state completion.

.yoi/tickets/00001KSKBP9YG/thread.md

@@ -4,4 +4,547 @@
 
 Migrated from tickets/e2e-harness.md. No legacy review file was present at migration time.
 
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-13T13:56:37Z -->
+
+## Decision
+
+E2E scope refinement: TUI/Panel PTY 自動化もこの Ticket の範囲に含める。
+
+背景:
+- Panel mouse selection / Panel Quit latency の直近不具合では、focused unit test と code-path review だけで `done` 判定し、実端末経路の positive validation / measured validation が不足していた。
+- 既存本文の「TUI バイナリを PTY で叩く方針は採らない」は、blind な固定入力スクリプトや GUI 代替としての ad hoc 操作を避ける意図として扱い、TUI/Panel の実プロセス・実端末入力を検証する automated PTY harness は本 Ticket に含める。
+- Pod protocol/subprocess E2E と TUI/Panel PTY E2E は harness の部品は違うが、どちらも「実プロセスを spawn して user-visible boundary を検証する」ため、別 umbrella に分けず、この E2E harness Ticket の phase として扱う。
+
+方針:
+- 固定 sleep + 固定 input だけの PTY script は採用しない。Harness は UI からの structured feedback を待ってから入力を送る。
+- TUI/Panel には test-only / opt-in の observability route を追加する。これは UI action を bypass する command channel ではなく、状態観測・同期・失敗診断のための read-only probe とする。
+- 実際の keyboard / mouse / Ctrl+C 入力は PTY 経由で送る。Probe は `first_draw`、`panel_snapshot_ready`、`rows_rendered`、`selection_changed`、`actionbar_changed`、`background_task_started/finished/aborted`、`quit_requested`、`terminal_cleanup_started/finished`、`exit` などの structured event を JSONL 等で吐く。
+- Mouse E2E は `rows_rendered` の row key と screen rect を待ち、SGR mouse sequence を PTY に送って、`selection_changed` と screen/actionbar/detail の変化を確認する。
+- Quit latency E2E は `panel_ready` / background work pending などの barrier event を待ってから `Ctrl+C` / `Ctrl+D` を送り、`quit_requested -> exit` の elapsed を測る。非本質 background work が abort/drop され、terminal cleanup が行われることも event で確認する。
+- Screen output は `vt100`/`vte` 等の terminal parser で secondary oracle / artifact として保存する。主要同期は structured event に寄せる。
+- Test probe は `--tui-test-events <path>` 等の明示的な hidden/dev/test flag か `e2e` feature 配下の構成で有効化し、通常実行・model context・Ticket authority・Pod protocol には影響させない。
+- Failure artifact として event JSONL、input log、screen dump、stdout/stderr、runtime/data/workspace tmpdir の relevant tree、timing summary を保存する。
+
+受け入れ条件の追加案:
+- `cargo test -p e2e --features e2e`（または同等の opt-in command）で実 `yoi panel` を PTY 上で起動し、structured probe feedback を待ってから入力する harness が動く。
+- Panel row click E2E: rendered row rect を使って SGR mouse click を送り、selected row が変わることを assertion する。
+- Panel quit latency E2E: ready/pending background work barrier 後に Quit 入力を送り、exit latency が閾値内で、nonessential background work が quit を block しないことを assertion する。
+- Fixed sleep だけに依存する test は不可。ready/barrier event が来なければ screen dump と event log を artifact として失敗する。
+- Probe は read-only observability であり、input/action path を bypass しないことを reviewer が確認する。
+
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-13T14:03:56Z -->
+
+## Decision
+
+E2E design decision: Playwright-like declarative test API と production binary 非混入を前提にする。
+
+Decision:
+- E2E は ad hoc shell / fixed sleep script ではなく、Rust の独立 crate から宣言的に scenario を書ける構造にする。
+- 例: `PanelHarness::spawn(...)`、`panel.wait_for(PanelReady)`、`panel.click(row("ticket", id))`、`panel.expect_selection(...)`、`panel.press(CtrlC)`、`panel.expect_exit_within(...)` のように、Playwright 的な wait/action/assertion API を提供する。
+- Harness crate は production binary / normal library API から独立させる。想定配置は `tests/e2e/` または `crates/e2e_harness` + integration tests で、通常 build / release package / normal `yoi` binary に test harness logic を混ぜない。
+- 本番 binary に混ぜる必要があるものは、原則として「既存 TUI state から read-only diagnostic event を emit するための最小 test hook」に限定する。その hook も normal runtime では無効で、明示 feature / hidden dev flag / cfg(test/e2e) 等でしか有効化しない。
+- E2E harness は production code の内部関数を直接呼んで state mutation しない。入力は PTY、観測は structured test events / terminal screen parser、assertion は harness 側で行う。
+- Structured events は protocol authority ではなく test observability artifact として扱う。Ticket/Pod authority や user-visible semantics を変えない。
+
+Rationale:
+- 今回の Panel mouse / Quit latency の失敗は、unit/focused tests と code-path review だけでは user-visible terminal behavior を保証できないことを示した。
+- 一方で fixed sleep + input script は再現性・診断性が低く、ready 状態や background work barrier を確認できない。
+- Playwright-like API なら、test は「何を待ち、何を入力し、何を観測するか」を宣言的に表現でき、失敗時に event log / screen dump / timing artifact を残せる。
+- Production binary への混入を避けることで、release behavior / binary size / authority surface / model-visible surfaces を汚さない。
+
+Acceptance refinement:
+- E2E test author が fixed sleep ではなく `wait_for` / `expect` / `within` を使って Panel/TUI scenario を書ける。
+- Mouse selection と Quit latency の regression は、この declarative harness API 上の scenario として表現される。
+- Test-only observability route は opt-in であり、release/normal execution では無効または到達不能であることを reviewer が確認する。
+- Failure artifact に scenario step、last observed events、screen snapshot、timing、binary path、workspace/runtime dirs が含まれる。
+
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-13T14:16:24Z -->
+
+## Decision
+
+Routing decision: implementation_ready
+
+Reason:
+- ユーザーが E2E harness を 1 Ticket として扱い、Playwright-like declarative API、structured feedback、production binary 非混入を前提に進めることを明示した。
+- Ticket body は旧名/旧構成を含むが、thread decisions により現在の binding direction は明確化済み: Pod subprocess/protocol E2E と TUI/Panel PTY E2E を同じ harness Ticket の phase として扱う。
+- 直近の Panel mouse selection / Panel Quit latency の regression から、実プロセス・実 PTY・structured event feedback・failure artifact を最小スライスに含める必要がある。
+- `TicketRelationQuery` では durable blocker はなく、関連 Ticket は context link のみ。
+- Orchestrator worktree は clean。implementation side effect は state acceptance 後に dedicated child worktree で行う。
+
+Evidence checked:
+- Ticket body / thread decisions。
+- relation records: `00001KV072V89` / `00001KV0723PC` への related links。
+- orchestration plan records: なし。
+- current workspace state: Orchestrator worktree clean、queued/inprogress work なし、implementation child Pods なし。
+- project context: AGENTS guidance の E2E 未設計、prompt/resource boundary、production binary contamination 回避方針、直近 Panel validation failure records。
+
+IntentPacket:
+
+Intent:
+- Yoi の E2E testing foundation を、実プロセス spawn と TUI/Panel PTY automation の両方を扱える opt-in harness として導入する。
+- 最初の vertical slice は、Playwright-like declarative API、structured UI feedback、failure artifact、Panel mouse selection / Panel quit latency の regression scenario を実装できる形にする。
+
+Binding decisions / invariants:
+- E2E harness は independent crate / test surface とし、normal release / normal `yoi` binary に harness logic を混ぜない。
+- 本番 binary 側に必要な変更は opt-in read-only observability hook に限定する。UI action/state mutation を test hook で bypass しない。
+- 実入力は PTY 経由で送る。structured event は synchronization / assertion / artifact のための観測情報であり、authority channel ではない。
+- fixed sleep + fixed input だけの blind script を acceptance にしない。
+- Pod/Ticket authority、prompt/resource boundary、public runtime behavior を E2E 都合で歪めない。
+
+Requirements / acceptance criteria:
+- E2E author が Rust code で `spawn` / `wait_for` / `click` / `press` / `expect_*` / `within` を使って scenario を宣言的に書ける。
+- Opt-in command（例: `cargo test -p e2e --features e2e` または同等）で通常 CI 既定から分離される。
+- TUI/Panel test は panel ready / rows rendered / selection changed / background task / quit events など structured feedback を待ってから PTY input を送る。
+- Panel mouse selection regression と Panel quit latency regression の少なくとも skeleton または minimal passing scenario が declarative harness 上で表現される。
+- Failure artifact として event log、input log、screen dump、timing、binary path、workspace/runtime dirs が残る。
+- Production binary contamination がないこと、または opt-in hook が normal runtime で無効/到達不能であることを reviewer が確認できる。
+
+Implementation latitude:
+- `tests/e2e/` crate か `crates/e2e_harness` + integration tests のどちらに置くかは Coder が codebase constraints を見て選んでよい。ただし normal build/release contamination は避ける。
+- PTY crate、terminal parser、event JSONL format、fixture workspace builder の具体設計は Coder が選んでよい。
+- 最初の slice は full provider E2E ではなく、Panel/TUI harness と minimal process lifecycle / artifact foundation を優先してよい。
+- 既存旧名 `INSOMNIA_*` / `pod` references は現在の `yoi` / config surface に合わせて整理してよい。
+
+Escalate if:
+- read-only observability hook では足りず、production UI action path を test-only command channel で直接操作したくなる場合。
+- normal release binary / normal CLI surface に test-only options を露出させる必要がある場合。
+- workspace structure、Cargo package layout、Nix/package source filter に大きな変更が必要になる場合。
+- Provider stub / Pod protocol E2E まで同時に広げないと Panel slice が進められない場合。
+
+Validation:
+- focused E2E harness tests / example scenarios。
+- `cargo fmt --check`。
+- `git diff --check`。
+- 変更範囲に応じて `cargo check --workspace --all-targets` または narrower package checks。
+- 新 E2E command が opt-in で実行可能であることを report する。
+
+Current code map:
+- `crates/yoi` / CLI launch path: hidden/test-only flag injection の候補。
+- `crates/tui/src/multi_pod.rs`: Panel events / observable state emission の候補。
+- `tests/e2e/` or new harness crate: declarative scenario API / PTY runner / artifact collector。
+- root `Cargo.toml` / package metadata: opt-in package registration と release contamination check。
+
+Critical risks / reviewer focus:
+- Harness code が production binary に混ざっていないこと。
+- Observability hook が read-only で、input/action path を bypass していないこと。
+- Test が fixed sleep 依存ではなく structured feedback / timeouts / artifacts を持つこと。
+- Panel mouse / quit latency regression が今後「unit test だけで done」にならない程度の user-visible path を cover すること。
+
+---
+
+<!-- event: intake_summary author: orchestrator at: 2026-06-13T14:16:54Z -->
+
+## Intake summary
+
+ユーザー確認により、既存 E2E harness Ticket は Pod subprocess E2E と TUI/Panel PTY E2E を一つの実装対象として扱う。Playwright-like declarative API、independent opt-in crate、production binary 非混入、read-only structured observability、PTY input、failure artifact、Panel mouse / quit latency regression scenario が受け入れ方向として明確化済み。
+
+---
+
+<!-- event: state_changed author: orchestrator at: 2026-06-13T14:16:54Z from: planning to: ready reason: user_authorized_e2e_harness_implementation field: state -->
+
+## State changed
+
+Ticket planning が完了しました。state planning -> ready。
+
+
+---
+
+<!-- event: state_changed author: "yoi ticket" at: 2026-06-13T14:17:34Z from: ready to: queued reason: queued field: state -->
+
+## State changed
+
+Ticket を `yoi ticket` が queued にしました。
+
+
+---
+
+<!-- event: state_changed author: orchestrator at: 2026-06-13T14:17:40Z from: queued to: inprogress reason: orchestrator_acceptance_after_user_authorization field: state -->
+
+## State changed
+
+ユーザーが明示的に inprogress 化して進めることを承認した。Ticket evidence / relation records / OrchestrationPlan accepted plan / Orchestrator worktree clean state を確認済みで、blocking relation はない。Implementation side effect の前に state を inprogress として記録する。
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-13T14:18:55Z -->
+
+## Implementation report
+
+Implementation handoff started.
+
+- Worktree: `/home/hare/Projects/yoi/.worktree/e2e-harness`
+- Branch: `ticket-00001KSKBP9YG-e2e-harness`
+- Coder Pod: `coder-00001KSKBP9YG-e2e`
+- Scope: child worktree read、root `Cargo.toml` / `Cargo.lock` write、`tests/e2e` write、selected crates (`crates/tui`, `crates/yoi`, `crates/pod`, `crates/protocol`) write、`target` write、this Ticket record write。`.yoi/memory` や local/runtime/log/lock/secret-like `.yoi` paths は write scope に含めていない。
+- Note: runtime launch validation のため `/home/hare/Projects/yoi` に非再帰 read grant を付けたが、Coder には root/original workspace を inspect/write/git/validate/merge/cleanup しないよう明示済み。
+
+Next:
+- Coder は Playwright-like declarative E2E harness、read-only structured observability、PTY input、Panel mouse / quit latency regression scenario の first slice を実装する。
+- Coder の commit / implementation_report / validation evidence を確認後、Reviewer を read-only 基本で起動する。
+
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-13T14:31:31Z -->
+
+## Decision
+
+Design note: Panel mouse E2E は raw SGR sequence を固定送信するだけでは不十分。
+
+Rationale:
+- Harness が PTY に直接 `ESC [ < ... M` を書くと、実端末が mouse capture 有効時だけ mouse sequence を生成するという条件を bypass してしまい、今回のような「実端末ではイベントが来ない」系の不具合を見逃す可能性がある。
+- Mouse E2E は locator/row rect を使って coordinate を決めるだけでなく、TUI が mouse capture mode を有効化したことも検証する必要がある。
+
+追加すべき test harness 要件:
+- virtual terminal / screen parser は app output の terminal mode sequence（例: normal mouse + SGR mouse mode, `?1000h` / `?1006h` 相当）を tracking し、click helper は capture enabled が観測されていない場合に fail する。
+- もしくは explicit read-only structured event と terminal output assertion の両方で `mouse_capture_enabled` を確認する。
+- `click(row_selector)` は `rows_rendered` の rect から座標を選ぶが、raw SGR injection だけで成功扱いにしない。
+- assertion は `selection_changed` event、screen/actionbar/detail の secondary oracle、そして workflow action が発火していないことを組み合わせる。
+- これにより mouse selection E2E は面倒になるが、capture setup / coordinate mapping / event handling の user-visible path を分離して検証できる。
+
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-13T14:40:42Z -->
+
+## Decision
+
+Coder first-slice review: changes requested before external review.
+
+The initial E2E harness direction is promising, but it does not yet satisfy the regression-prevention bar from this Ticket.
+
+Required changes sent to Coder:
+1. Mouse E2E must not pass solely by injecting raw SGR mouse bytes. Harness must track terminal mouse capture enable output (`?1000h` / `?1006h` equivalent) and fail `click(...)` / expose `expect_mouse_capture_enabled()` when capture was not observed.
+2. Production binary contamination must be reduced. The TUI JSONL observer currently appears to be available in normal builds via `YOI_TUI_TEST_EVENTS`; prefer explicit `e2e-test` feature/cfg gating so release/normal binary has the hook compiled out. Report if feature gating is too large.
+3. Quit latency E2E must wait for a real pending/background-work barrier at the moment of quit, not merely assert that `background_task_started` happened sometime earlier. Strengthen the scenario to prove Ctrl+C while pending work exists exits promptly.
+4. Update implementation_report and validation evidence after changes.
+
+Reason:
+- The mouse selection regression specifically needs to catch missing terminal mouse capture, which raw SGR injection can bypass.
+- The user explicitly requested a structure where E2E harness logic does not mix into the production binary.
+- The quit latency regression needs measured user-visible behavior under a synchronized pending-work condition, not a loose startup smoke test.
+
+---
+
+<!-- event: implementation_report author: hare at: 2026-06-13T14:38:03Z -->
+
+## Implementation report
+
+Implemented an opt-in E2E testing foundation for real `yoi panel` process automation.
+
+API / harness shape:
+- Added workspace package `tests/e2e` (`yoi-e2e`) with required feature `e2e`, so scenarios are opt-in.
+- Added `PanelHarness::spawn(...)`, `wait_for(...)`, `wait_for_rows(...)`, `click(...)`, `press(...)`, `expect_selection(...)`, `expect_exit_within(...)`, and `artifacts()`.
+- Harness drives the real `yoi panel` binary through a Unix PTY and sends SGR mouse / keyboard bytes through that PTY only.
+- Harness captures artifacts under a per-run artifact directory: `events.jsonl`, `input.log`, `pty-output.log`, and `run.json`.
+
+Production / non-production boundary:
+- Harness logic stays in `tests/e2e` and is not mixed into production crates.
+- Production-side change is limited to an opt-in read-only TUI JSONL observer enabled only by `YOI_TUI_TEST_EVENTS`.
+- Observer records Panel/TUI synchronization and assertion events (`panel_ready`, `rows_rendered`, `selection_changed`, `mouse_click`, `action_requested`, `quit_requested`, background task lifecycle, terminal cleanup, exit).
+- The observer does not mutate UI state, inject input, bypass actions, or grant authority; real input remains PTY-only.
+
+Scenarios added:
+- Panel mouse selection regression: waits for rendered rows, sends an SGR mouse click through PTY, asserts selection changed, and asserts no panel action was dispatched.
+- Panel quit latency regression: waits for Panel ready plus background-task barrier, sends Ctrl+C through PTY, asserts clean exit within the threshold, and verifies the quit event.
+
+Files changed:
+- `Cargo.toml`, `Cargo.lock`
+- `crates/tui/src/lib.rs`
+- `crates/tui/src/multi_pod.rs`
+- `crates/tui/src/e2e_observer.rs`
+- `tests/e2e/Cargo.toml`
+- `tests/e2e/src/lib.rs`
+- `tests/e2e/tests/panel.rs`
+
+Validation:
+- `cargo build -p yoi` — passed.
+- `YOI_E2E_BIN=/home/hare/Projects/yoi/.worktree/e2e-harness/target/debug/yoi cargo test -p yoi-e2e --features e2e --test panel -- --nocapture` — passed (2 tests).
+- `cargo fmt --check` — passed.
+- `cargo check -p tui --all-targets` — passed.
+- `cargo check -p yoi --all-targets` — passed.
+- `cargo check -p yoi-e2e --all-targets --features e2e` — passed.
+- `git diff --check` — passed.
+
+Remaining gaps / risks:
+- The first slice is Unix PTY-based; cross-platform PTY support is not implemented.
+- The screen artifact is currently raw PTY output rather than a parsed terminal snapshot.
+- Fixture setup blocks Companion/Orchestrator role auto-spawn by placing intentionally invalid isolated test pod metadata in the fixture data dir; this avoids leaking live background Pods but should be replaced by a cleaner fixture strategy if the Panel gains an explicit test fixture mode.
+
+
+---
+
+<!-- event: implementation_report author: hare at: 2026-06-13T15:00:29Z -->
+
+## Implementation report
+
+Follow-up implementation update for review-required changes:
+
+Mouse E2E false-positive prevention:
+- `PanelHarness` now tracks the PTY output for terminal mouse mode enable/disable escape sequences.
+- It requires both normal mouse tracking (`ESC[?1000h`, with disable `ESC[?1000l`) and SGR mouse mode (`ESC[?1006h`, with disable `ESC[?1006l`) to have been observed as currently enabled.
+- Added `PanelHarness::expect_mouse_capture_enabled()` and the Panel mouse E2E calls it before clicking.
+- `PanelHarness::click(...)` also fails with `MouseCaptureNotEnabled` if mouse capture has not been observed, so raw SGR mouse injection alone cannot make the test pass.
+
+Production binary contamination reduction:
+- Added explicit feature gates:
+  - `tui/e2e-test`
+  - `yoi/e2e-test = ["tui/e2e-test"]`
+- The `YOI_TUI_TEST_EVENTS` JSONL event path and the background-task hold seam are compiled only under `tui/e2e-test`.
+- Normal builds still type-check a no-op facade so call sites stay simple, but env-var observability/hold behavior is compiled out unless the feature is enabled.
+- E2E binary build command is now: `cargo build -p yoi --features e2e-test`.
+
+Quit latency barrier strengthening:
+- Added a feature-gated test-only seam `YOI_TUI_TEST_HOLD_BACKGROUND_TASK=reload` that holds the Panel reload task pending in the E2E binary until quit aborts it.
+- Added `PanelHarness::expect_background_task_pending("reload")`, which verifies that a `background_task_started` event exists and no matching `background_task_finished` or `background_task_aborted` event has superseded it.
+- The quit latency test now uses the hold seam and asserts pending reload work immediately before sending Ctrl+C through the PTY.
+
+Harness/artifact adjustment:
+- E2E fixture artifacts now persist under workspace `target/e2e-artifacts/...` instead of package-local temporary dirs, so failure artifacts remain inspectable.
+
+Validation after update:
+- `cargo fmt --check` — passed.
+- `cargo build -p yoi --features e2e-test` — passed.
+- `YOI_E2E_BIN=/home/hare/Projects/yoi/.worktree/e2e-harness/target/debug/yoi cargo test -p yoi-e2e --features e2e --test panel -- --nocapture` — passed (2 tests).
+- `git diff --check` — passed.
+- `cargo check -p tui --all-targets` — passed.
+- `cargo check -p yoi --all-targets` — passed.
+- `cargo check -p tui --all-targets --features e2e-test` — passed.
+- `cargo check -p yoi --all-targets --features e2e-test` — passed.
+- `cargo check -p yoi-e2e --all-targets --features e2e` — passed.
+
+Remaining gaps / risks:
+- The E2E harness remains Unix PTY based.
+- The screen artifact remains raw PTY output, not a parsed terminal snapshot.
+- The test-only pending-task hold intentionally changes timing only for the `e2e-test` binary; it is not compiled into normal builds.
+
+
+---
+
+<!-- event: review author: hare at: 2026-06-13T15:05:52Z status: request_changes -->
+
+## Review: request changes
+
+Request changes.
+
+Evidence reviewed:
+- Inspected Ticket record and `git diff 134e8b8b..HEAD` for commits `96561897` and `10a1c383`.
+- `tests/e2e` provides a credible first declarative harness (`PanelHarness::spawn`, `wait_for`, `wait_for_rows`, `click`, `press`, `expect_selection`, `expect_exit_within`, artifacts/metadata/input/output/event logs). This is not merely a fixed-sleep shell script.
+- Mouse-selection scenario waits for rendered rows, verifies both normal mouse and SGR mouse capture before `click`, sends the click through PTY bytes, waits for `selection_changed`, and asserts no `action_requested` dispatch.
+- Quit-latency scenario creates a real feature-gated background-task hold barrier, waits until the task is actually waiting before sending Ctrl+C through the PTY, and measures bounded exit latency.
+- `yoi-e2e` is opt-in via package feature/test `required-features = ["e2e"]`; e2e tests are outside default members. `YOI_TUI_TEST_EVENTS` and `YOI_TUI_TEST_HOLD_BACKGROUND_TASK` env behavior is behind `tui/e2e-test` / `yoi/e2e-test` feature gates, and the hook is observability-only.
+
+Required change:
+- The normal production build still contains/evaluates too much e2e harness glue. In non-`e2e-test` builds, `crates/tui/src/e2e_observer.rs` exposes no-op `emit`/hold functions, but call sites still execute test-specific data construction. In particular `App::emit_rows_rendered` and its panel row key/rect DTOs are compiled unconditionally and `app.emit_rows_rendered()` is called from the panel render path, causing row snapshots to be built every draw even though emission is a no-op. Selection/action/quit call sites also construct `serde_json::json!` payloads before the no-op facade. This violates the recorded boundary that production binaries should not contain harness logic and production-side hooks must be feature-gated/compiled out for normal builds.
+  - Please cfg-gate the call sites/helpers/DTOs, or use a lazy cfg-gated macro/helper so normal builds do not evaluate or retain e2e event payload construction. A tiny compile-only facade is acceptable only if it does not execute or allocate e2e-specific work and does not keep harness DTO logic in the normal runtime path.
+
+Validation run in `/home/hare/Projects/yoi/.worktree/e2e-harness`:
+- `git diff --check 134e8b8b..HEAD` — passed.
+- `cargo fmt --check` — passed.
+- `cargo check -p tui --all-targets` — passed.
+- `cargo check -p yoi --all-targets` — passed.
+- `cargo build -p yoi --features e2e-test` — passed.
+- `YOI_E2E_BIN=/home/hare/Projects/yoi/.worktree/e2e-harness/target/debug/yoi cargo test -p yoi-e2e --features e2e --test panel -- --nocapture` — passed.
+- `cargo check -p tui --all-targets --features e2e-test` — passed.
+- `cargo check -p yoi --all-targets --features e2e-test` — passed.
+- `cargo check -p yoi-e2e --all-targets --features e2e` — passed.
+
+No source changes were made during review.
+
+
+---
+
+<!-- event: implementation_report author: hare at: 2026-06-13T15:18:21Z -->
+
+## Implementation report
+
+Follow-up implementation update for reviewer request `559adb9a ticket: request e2e harness changes`:
+
+Production/non-production boundary fix:
+- Removed the normal-build no-op `e2e_observer` module path and now compile the observer module only behind `tui/e2e-test` via `#[cfg(feature = "e2e-test")] mod e2e_observer;`.
+- Added `#[cfg(feature = "e2e-test")]` to all Panel/TUI observability call sites that build JSON payloads, including terminal cleanup/exit, panel ready, rows-rendered, mouse click, selection changes, action requests, quit request, and background task lifecycle events.
+- `App::emit_rows_rendered`, `PanelE2eRowKey`, `PanelE2eRect`, `PanelE2eRenderedRow`, `PanelE2eRowsRendered`, and the conversion helpers are now compiled only with `tui/e2e-test`.
+- Normal builds no longer call `app.emit_rows_rendered()`, no longer evaluate `serde_json::json!` e2e payloads, and no longer retain the Panel E2E DTO/helper logic in the runtime path.
+- The background reload hold seam remains compiled/called only under `tui/e2e-test`; `YOI_TUI_TEST_EVENTS` and `YOI_TUI_TEST_HOLD_BACKGROUND_TASK` behavior remains feature-gated.
+
+Preserved E2E behavior:
+- Mouse E2E still verifies PTY output for normal mouse tracking + SGR mouse enable sequences before any raw SGR click can be sent.
+- `PanelHarness::click(...)` still fails if mouse capture was not observed.
+- Quit latency E2E still uses the feature-gated pending reload hold barrier and asserts the reload task is pending before Ctrl+C.
+
+Validation:
+- `cargo fmt --check` — passed.
+- `cargo check -p tui --all-targets` — passed.
+- `cargo check -p yoi --all-targets` — passed.
+- `cargo check -p tui --all-targets --features e2e-test` — passed.
+- `cargo check -p yoi --all-targets --features e2e-test` — passed.
+- `cargo build -p yoi --features e2e-test` — passed.
+- `YOI_E2E_BIN=/home/hare/Projects/yoi/.worktree/e2e-harness/target/debug/yoi cargo test -p yoi-e2e --features e2e --test panel -- --nocapture` — passed (2 tests).
+- `cargo check -p yoi-e2e --all-targets --features e2e` — passed.
+- `git diff --check` — passed.
+
+Remaining gaps / risks unchanged:
+- The E2E harness remains Unix PTY based.
+- The screen artifact remains raw PTY output rather than a parsed terminal snapshot.
+
+
+---
+
+<!-- event: review author: hare at: 2026-06-13T15:21:30Z status: approve -->
+
+## Review: approve
+
+Approve.
+
+Delta reviewed:
+- Re-reviewed the fix commit `b30b43b9 test: cfg-gate e2e observer payloads` after the earlier request-changes review.
+- Inspected the updated observer module boundary and call sites in `crates/tui/src/lib.rs` and `crates/tui/src/multi_pod.rs`, plus the unchanged harness/tests in `tests/e2e`.
+
+Evidence:
+- `e2e_observer` is now only compiled from `crates/tui/src/lib.rs` under `#[cfg(feature = "e2e-test")]`; the previous normal-build no-op facade was removed.
+- Observer payload construction is gated at call sites with `#[cfg(feature = "e2e-test")]`, including `panel_ready`, `selection_changed`, `action_requested`, `quit_requested`, and `emit_rows_rendered` calls.
+- Panel E2E DTOs/helpers (`PanelE2eRowKey`, `PanelE2eRect`, `PanelE2eRenderedRow`, `PanelE2eRowsRendered`, `App::emit_rows_rendered`) are now behind `#[cfg(feature = "e2e-test")]`, so the normal panel render path no longer builds row snapshots or retains that runtime helper path.
+- The background-task hold seam is still feature-gated: `check_background_task_hold` and `release_background_task_hold` calls are under `#[cfg(feature = "e2e-test")]`, and `YOI_TUI_TEST_HOLD_BACKGROUND_TASK` behavior lives in the gated observer module.
+- Mouse capture tracking remains intact in the harness: it tracks `?1000h` and `?1006h`, `click(...)` requires both capture modes before injecting PTY bytes, the test waits for rendered rows, asserts `selection_changed`, and asserts no `action_requested` dispatch.
+- Quit-latency coverage remains intact: the test waits for `panel_ready`, then verifies an actual pending `reload` background-task barrier before sending Ctrl+C through the PTY and asserting bounded exit.
+- The production/non-production boundary now satisfies the Ticket intent: the harness remains opt-in, observability is read-only and feature-gated, and no UI input/action path is bypassed.
+
+Validation run in `/home/hare/Projects/yoi/.worktree/e2e-harness`:
+- `git diff --check 134e8b8b..HEAD` — passed.
+- `cargo fmt --check` — passed.
+- `cargo check -p tui --all-targets` — passed.
+- `cargo check -p yoi --all-targets` — passed.
+- `cargo check -p tui --all-targets --features e2e-test` — passed.
+- `cargo check -p yoi --all-targets --features e2e-test` — passed.
+- `cargo build -p yoi --features e2e-test` — passed.
+- `YOI_E2E_BIN=/home/hare/Projects/yoi/.worktree/e2e-harness/target/debug/yoi cargo test -p yoi-e2e --features e2e --test panel -- --nocapture` — passed; 2 tests passed.
+- `cargo check -p yoi-e2e --all-targets --features e2e` — passed.
+
+No source changes were made during re-review.
+
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-13T15:23:35Z -->
+
+## Implementation report
+
+Integration outcome: merged and validated.
+
+- Implementation branch: `ticket-00001KSKBP9YG-e2e-harness`
+- Implementation commits: `96561897 test: add opt-in panel e2e harness`, `10a1c383 test: harden panel e2e harness`, `b30b43b9 test: cfg-gate e2e observer payloads`
+- Review commits/events: initial `request_changes` for production-boundary leakage, then `approve` after `e2e-test` cfg gating。
+- Orchestrator merge commit: `b3bd6b11 merge: e2e harness`
+
+Implemented first vertical slice:
+- Added opt-in `tests/e2e` package `yoi-e2e` with Playwright-like `PanelHarness` API for real `yoi panel` process automation through PTY.
+- Added feature-gated read-only TUI observer behind `tui/e2e-test` / `yoi/e2e-test`; normal builds do not compile observer module, event payload construction, row DTOs, or background hold seam.
+- Added Panel mouse selection E2E that waits for rendered rows, verifies terminal mouse capture output (`?1000h` and `?1006h`), sends click through PTY, asserts selection change, and asserts no action dispatch.
+- Added Panel quit latency E2E that creates a feature-gated pending reload barrier, sends Ctrl+C through PTY, and asserts bounded exit.
+- Artifacts include event log, input log, raw PTY output, and run metadata under `target/e2e-artifacts`.
+
+Orchestrator validation after merge:
+- `cargo fmt --check`: PASS
+- `cargo check -p tui --all-targets`: PASS
+- `cargo check -p yoi --all-targets`: PASS
+- `cargo check -p tui --all-targets --features e2e-test`: PASS
+- `cargo check -p yoi --all-targets --features e2e-test`: PASS
+- `cargo build -p yoi --features e2e-test`: PASS
+- `YOI_E2E_BIN=/home/hare/Projects/yoi/.worktree/orchestration/yoi-orchestrator/target/debug/yoi cargo test -p yoi-e2e --features e2e --test panel -- --nocapture`: PASS（2 tests）
+- `cargo check -p yoi-e2e --all-targets --features e2e`: PASS
+- `git diff --check`: PASS
+
+Remaining gaps / risks:
+- Harness is Unix PTY based。
+- Screen artifact is raw PTY output rather than parsed terminal snapshot。
+- This is a first vertical slice for Panel/TUI PTY E2E; broader Pod protocol/provider stub scenarios remain future work under this E2E harness direction。
+
+Next:
+- Mark Ticket `done` and clean up child coder/reviewer Pods plus implementation worktree/branch. Closure remains separate.
+
+---
+
+<!-- event: state_changed author: orchestrator at: 2026-06-13T15:23:44Z from: inprogress to: done reason: merged_and_validated field: state -->
+
+## State changed
+
+E2E harness implementation branch was reviewed, approved after requested production-boundary changes, merged into the Orchestrator branch as `b3bd6b11`, and validated in the Orchestrator worktree. Opt-in Panel PTY E2E tests for mouse selection and quit latency passed, along with formatting, diff check, normal/e2e feature package checks, and E2E package check. Ticket implementation work is done; closure remains separate.
+
+---
+
+<!-- event: comment author: orchestrator at: 2026-06-13T15:27:18Z -->
+
+## Comment
+
+Post-merge design gap: E2E harness の `yoi` binary freshness はまだ自動保証されていない。
+
+Current behavior:
+- `tests/e2e/src/lib.rs::yoi_binary()` は `YOI_E2E_BIN` があればその path を使う。
+- `YOI_E2E_BIN` が無い場合は E2E test binary の `current_exe()` から `target/{debug,release}/yoi` を推測し、最後に `target/debug/yoi` へ fallback する。
+- Harness は `PanelHarness::spawn` と fixture setup commands の両方でその binary path を使い、`YOI_POD_RUNTIME_COMMAND` も同じ binary に向ける。
+- しかし harness 自身は `cargo build -p yoi --features e2e-test` を実行しない。したがって任意タイミングの `cargo test -p yoi-e2e --features e2e` だけでは、最新 source から rebuild された binary が使われる保証はない。
+
+Gap:
+- 今回の validation は Orchestrator が事前に `cargo build -p yoi --features e2e-test` を実行したため正しい binary を使った。
+- ただし harness design としては freshness が runner/manual discipline に依存しており、stale `target/debug/yoi` や別 path の `YOI_E2E_BIN` を使っても test が走り得る。
+
+Follow-up direction:
+- `cargo xtask e2e` / `yoi-e2e-runner` / documented `just e2e` など、必ず `cargo build -p yoi --features e2e-test` を実行してから `YOI_E2E_BIN=<fresh target binary> cargo test -p yoi-e2e --features e2e ...` する single entrypoint が必要。
+- さらに harness は起動 binary が `e2e-test` feature 有効であることを handshake/event/version で検証し、可能なら source commit/build timestamp/path metadata を artifact に残して stale/mismatched binary を diagnostic にするべき。
+
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-13T15:43:37Z -->
+
+## Decision
+
+Follow-up design note: E2E の `yoi` binary freshness は `cargo run` 直起動より、harness 内 `cargo build` + built binary spawn を標準にする。
+
+Decision candidate:
+- `cargo test -p yoi-e2e --features e2e` の test setup から `cargo build -p yoi --features e2e-test --bin yoi` を実行することは可能で、opt-in E2E では許容する。
+- ただし PTY scenario の process-under-test を `cargo run ... -- panel` にするのは避ける。Cargo wrapper の build output、process tree、signal forwarding、exit timing が混ざり、Panel quit latency の測定対象が曖昧になるため。
+- Harness には `BinaryProvider::CargoBuild` のような起動経路を持たせ、test 開始時に current workspace source から `yoi` を build し、得られた `target/{profile}/yoi` path を PTY で直接 spawn する。
+- これにより「任意タイミングの E2E 実行で最新 source から作った binary を使う」ことを起動経路として保証しつつ、実際の UI/latency 測定は Cargo wrapper ではなく `yoi` binary 本体を対象にできる。
+- 複数 test の重複 build は `OnceLock`/suite setup 等で 1 回にまとめる。parallel test 実行時の cargo target lock 待ちは opt-in E2E では許容し、必要なら serial 化する。
+
+Rationale:
+- 起動後 handshake で正しさを検証するより、起動経路として build step を harness に内蔵する方が単純。
+- `cargo run` は可能だが、`run` は build + wrapper spawn を同時に行うため、PTY/Signal/timing の被測定経路に Cargo が入ってしまう。`cargo build` と direct binary spawn に分ける方が E2E の oracle が明確。
+
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-13T15:45:26Z -->
+
+## Decision
+
+Follow-up requested by user: E2E harness should build the current `yoi` binary itself instead of relying on a prebuilt `YOI_E2E_BIN` / inferred `target/debug/yoi`.
+
+Required correction:
+- Default E2E binary provider should run `cargo build -p yoi --features e2e-test --bin yoi` from the workspace root at test time, then spawn the resulting `target/{profile}/yoi` directly through PTY.
+- `YOI_E2E_BIN` may remain as an explicit override, but normal arbitrary `cargo test -p yoi-e2e --features e2e ...` should use a freshly built binary without requiring a separate manual build step.
+- Do not use `cargo run` as the process-under-test because that would put Cargo in the PTY/signal/quit-latency measurement path.
+- Preserve the existing production/non-production boundary and E2E feature gating.
+
+---
+
+<!-- event: state_changed author: hare at: 2026-06-13T16:34:06Z from: done to: closed reason: closed field: state -->
+
+## State changed
+
+Ticket を closed にしました。
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-13T16:34:06Z status: closed -->
+
+## 完了
+
+Closed after prior done-state completion.
+
+
 ---

.yoi/tickets/00001KSKBPAXR/item.md

@@ -1,8 +1,8 @@
 ---
 title: "内部 Worker / 内部 Pod の Workflow 化"
-state: "planning"
+state: 'closed'
 created_at: "2026-05-27T00:00:03Z"
-updated_at: "2026-05-27T00:00:03Z"
+updated_at: '2026-06-13T09:56:34Z'
 ---
 
 ## Migration reference

.yoi/tickets/00001KSKBPAXR/resolution.md

@@ -0,0 +1,11 @@
+## Resolution
+
+ユーザー指示により close する。
+
+この Ticket は legacy migration 由来の「内部 Worker / 内部 Pod を Workflow と同一仕様で扱う」構想だったが、現在の設計では Workflow と Prompt resource / internal prompt は別 boundary として整理されている。
+
+- public builtin workflow / Yoi dogfood workflow の分離、`resources/workflows/<slug>.md`、workspace override、builtin provenance は関連 Ticket で対応済み。
+- internal prompt は `resources/prompts/internal/*` と `PromptCatalog` / `resources/prompts/internal.toml` 側の責務として扱う。
+- 元の要件に残る `INSOMNIA`、`.insomnia/workflow`、旧 `tickets/*.md` 前提は current Yoi 設計と一致しない。
+
+したがって、この Ticket は実装 routing せず、退役 / superseded として完了扱いにする。将来、internal prompt の remaining gap や internal Workflow substrate が必要になった場合は、現在の Prompt resource / Workflow boundary を前提にした別の concrete Ticket として作成する。

.yoi/tickets/00001KSKBPAXR/thread.md

@@ -5,3 +5,81 @@
 Migrated from tickets/internal-worker-workflow.md. No legacy review file was present at migration time.
 
 ---
+
+<!-- event: plan author: ticket-intake at: 2026-06-13T09:25:59Z -->
+
+## Plan
+
+## Intake refinement
+
+既存 Ticket `00001KSKBPAXR` の body / thread / artifacts を確認した。artifacts は `.gitkeep` のみで、thread は migration 記録のみだった。重複 Ticket は作成しない。
+
+### 現状整理
+
+この Ticket は legacy migration 時点の前提を多く含んでいる。
+
+- 旧名 `INSOMNIA`、旧 path `.insomnia/workflow/<slug>.md`、旧 `tickets/*.md` 参照が残っている。
+- その後、Workflow / prompt resource 境界の設計は更新されている。
+  - `00001KTRKZ14C` は closed。public builtin workflow と Yoi dogfood workflow の分離、`resources/workflows/<slug>.md`、`WorkflowSource::Builtin`、workspace override、resident core/optional 方針を記録済み。
+  - `00001KTGFMW70` は closed。embedded builtin Workflow resources、Workflow-required builtin Knowledge fallback/provenance、workspace override を実装済み。
+  - 現在の internal prompt は `resources/prompts/internal/{memory_extract_system,memory_consolidation_system,compact_system}.md` と `PromptCatalog` / `resources/prompts/internal.toml` 側で扱われている。
+
+### Intake 判断
+
+現時点で、この Ticket を元のまま「内部 Worker / 内部 Pod を Workflow と同一仕様で実行する」実装 Ticket として route するのは危険。現在の設計では、Workflow は手続き・procedural flow、Prompt resources は system prompt / role behavior / internal worker prompt を所有する別 boundary であり、両者を混ぜると prompt-context / workflow-boundary / tool authority の責務が曖昧になる。
+
+したがって readiness は `requirements_sync_needed`。Orchestrator に渡す前に、人間/maintainer が次のいずれかを選ぶ必要がある。
+
+1. **退役 / superseded 扱い**: この legacy Ticket は `00001KTRKZ14C`、`00001KTGFMW70`、および現在の `PromptCatalog` internal prompt resource 化で実質的に置き換えられたとして、Orchestrator/human が close する。
+2. **PromptCatalog follow-up へ retarget**: Workflow 化ではなく、internal worker prompt の remaining gap を concrete に切り直す。例: extract / consolidation / compact の workspace/user/prompt-pack override、provenance diagnostics、test coverage、docs の不足確認。
+3. **真の internal Workflow 呼び出し substrate を新設**: 既存の Prompt resource / Workflow boundary を変更する設計 Ticket として再定義する。この場合は、なぜ PromptCatalog では不足か、tool surface 表明を workflow frontmatter に載せる authority model をどう安全にするか、`user_invocable: false` と resident/launch provenance をどう扱うかを先に設計判断する必要がある。
+
+### Binding decisions / invariants for any refinement
+
+- Workflow prose、Prompt fragments/internal prompts、Knowledge records は別 resource boundary として扱う。混ぜる場合は明示的な設計判断が必要。
+- 内部 Worker prompt を model-visible context に載せる場合も、turn を跨ぐ volatile hidden injection にならないよう、既存の history / prompt context 原則に従う。
+- `resources/prompts` にある internal prompt は PromptCatalog の責務であり、Workflow loader の責務へ silently 移さない。
+- `resources/workflows` の builtin workflow は procedural flow の resource であり、Yoi dogfood semantics を public builtin slug に隠さない。
+- `INSOMNIA` / `.insomnia` / legacy `tickets/*.md` 参照は current Ticket routing 前に Yoi / `.yoi` / canonical Ticket ID へ読み替えまたは整理する。
+
+### Risk flags / reviewer focus
+
+- `prompt-context`
+- `workflow-boundary`
+- `runtime-resource`
+- `tool-authority`
+- `memory-prompt`
+- `migration-compat`
+
+### Open question
+
+この Ticket は退役させるか、PromptCatalog follow-up に切り直すか、internal Workflow substrate の新設設計として再定義するか。現時点ではこの人間判断がないため、`ready` にはしない。
+
+---
+
+<!-- event: state_changed author: hare at: 2026-06-13T09:56:34Z from: planning to: closed reason: closed field: state -->
+
+## State changed
+
+Ticket を closed にしました。
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-13T09:56:34Z status: closed -->
+
+## 完了
+
+## Resolution
+
+ユーザー指示により close する。
+
+この Ticket は legacy migration 由来の「内部 Worker / 内部 Pod を Workflow と同一仕様で扱う」構想だったが、現在の設計では Workflow と Prompt resource / internal prompt は別 boundary として整理されている。
+
+- public builtin workflow / Yoi dogfood workflow の分離、`resources/workflows/<slug>.md`、workspace override、builtin provenance は関連 Ticket で対応済み。
+- internal prompt は `resources/prompts/internal/*` と `PromptCatalog` / `resources/prompts/internal.toml` 側の責務として扱う。
+- 元の要件に残る `INSOMNIA`、`.insomnia/workflow`、旧 `tickets/*.md` 前提は current Yoi 設計と一致しない。
+
+したがって、この Ticket は実装 routing せず、退役 / superseded として完了扱いにする。将来、internal prompt の remaining gap や internal Workflow substrate が必要になった場合は、現在の Prompt resource / Workflow boundary を前提にした別の concrete Ticket として作成する。
+
+---

.yoi/tickets/00001KSKBPGS8/item.md

@@ -1,8 +1,8 @@
 ---
 title: "Pod: 任意ターンからの Fork（複数ターン巻き戻し）"
-state: "planning"
+state: 'closed'
 created_at: "2026-05-27T00:00:09Z"
-updated_at: "2026-05-27T00:00:09Z"
+updated_at: '2026-06-20T16:31:29Z'
 ---
 
 ## Migration reference

.yoi/tickets/00001KSKBPGS8/resolution.md

@@ -0,0 +1 @@
+Closed as no longer needed. Arbitrary-turn Pod/session fork and multi-turn rewind are not part of the current desired workflow; current restore/rewind/fork behavior is sufficient for active use, and future history editing should be reopened as a narrower current-runtime design if needed.

.yoi/tickets/00001KSKBPGS8/thread.md

@@ -4,4 +4,22 @@
 
 Migrated from tickets/pod-session-fork.md. No legacy review file was present at migration time.
 
+---
+
+<!-- event: state_changed author: hare at: 2026-06-20T16:31:28Z from: planning to: closed reason: closed field: state -->
+
+## State changed
+
+Ticket を closed にしました。
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-20T16:31:29Z status: closed -->
+
+## 完了
+
+Closed as no longer needed. Arbitrary-turn Pod/session fork and multi-turn rewind are not part of the current desired workflow; current restore/rewind/fork behavior is sufficient for active use, and future history editing should be reopened as a narrower current-runtime design if needed.
+
+
 ---

.yoi/tickets/00001KSKBPHRG/item.md

@@ -1,8 +1,8 @@
 ---
 title: "Prompt / Workflow 評価メトリクスと改善 Offer"
-state: "planning"
+state: 'closed'
 created_at: "2026-05-27T00:00:10Z"
-updated_at: "2026-05-27T00:00:10Z"
+updated_at: '2026-06-20T16:31:29Z'
 ---
 
 ## Migration reference

.yoi/tickets/00001KSKBPHRG/resolution.md

@@ -0,0 +1 @@
+Closed as superseded/no longer needed. Workflow evaluation metrics and improvement planning have moved under the newer Memory redesign / team-workspace memory objectives, so this old prompt/workflow metrics ticket should not remain as a standalone planning item.

.yoi/tickets/00001KSKBPHRG/thread.md

@@ -4,4 +4,22 @@
 
 Migrated from tickets/prompt-eval-metrics.md. No legacy review file was present at migration time.
 
+---
+
+<!-- event: state_changed author: hare at: 2026-06-20T16:31:29Z from: planning to: closed reason: closed field: state -->
+
+## State changed
+
+Ticket を closed にしました。
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-20T16:31:29Z status: closed -->
+
+## 完了
+
+Closed as superseded/no longer needed. Workflow evaluation metrics and improvement planning have moved under the newer Memory redesign / team-workspace memory objectives, so this old prompt/workflow metrics ticket should not remain as a standalone planning item.
+
+
 ---

.yoi/tickets/00001KSKBPPMR/item.md

@@ -1,8 +1,8 @@
 ---
 title: "TUI: navigation mode / block focus の設計"
-state: "planning"
+state: 'closed'
 created_at: "2026-05-27T00:00:15Z"
-updated_at: "2026-05-27T00:00:15Z"
+updated_at: '2026-06-20T16:31:29Z'
 ---
 
 ## Migration reference

.yoi/tickets/00001KSKBPPMR/resolution.md

@@ -0,0 +1 @@
+Closed as no longer needed. The current TUI navigation/block-focus behavior is satisfactory, so the older navigation-mode design ticket is obsolete.

.yoi/tickets/00001KSKBPPMR/thread.md

@@ -4,4 +4,22 @@
 
 Migrated from tickets/tui-navigation-mode-design.md. No legacy review file was present at migration time.
 
+---
+
+<!-- event: state_changed author: hare at: 2026-06-20T16:31:29Z from: planning to: closed reason: closed field: state -->
+
+## State changed
+
+Ticket を closed にしました。
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-20T16:31:29Z status: closed -->
+
+## 完了
+
+Closed as no longer needed. The current TUI navigation/block-focus behavior is satisfactory, so the older navigation-mode design ticket is obsolete.
+
+
 ---

.yoi/tickets/00001KSQBFGE8/item.md

@@ -1,8 +1,8 @@
 ---
 title: "Audit crate responsibility boundaries"
-state: "planning"
+state: 'closed'
 created_at: "2026-05-28T13:13:17Z"
-updated_at: "2026-05-28T13:13:17Z"
+updated_at: '2026-06-20T16:45:54Z'
 ---
 
 ## Background

.yoi/tickets/00001KSQBFGE8/resolution.md

@@ -0,0 +1 @@
+Closed as completed. The crate responsibility boundary audit was already performed and recorded in artifacts/audit.md with concrete findings; any implementation cleanup should be handled by narrower follow-up tickets.

.yoi/tickets/00001KSQBFGE8/thread.md

@@ -4,4 +4,22 @@
 
 Created by tickets.sh create.
 
+---
+
+<!-- event: state_changed author: hare at: 2026-06-20T16:45:54Z from: planning to: closed reason: closed field: state -->
+
+## State changed
+
+Ticket を closed にしました。
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-20T16:45:54Z status: closed -->
+
+## 完了
+
+Closed as completed. The crate responsibility boundary audit was already performed and recorded in artifacts/audit.md with concrete findings; any implementation cleanup should be handled by narrower follow-up tickets.
+
+
 ---

.yoi/tickets/00001KSXRQ4G8/item.md

@@ -1,82 +1,270 @@
 ---
-title: "Plugin: define extension surface for hooks and tools"
-state: "planning"
-created_at: "2026-05-31T01:00:05Z"
-updated_at: "2026-06-03T12:25:05Z"
+title: 'Plugin: define runtime, surface, and minimal host API model'
+state: 'closed'
+created_at: '2026-05-31T01:00:05Z'
+updated_at: '2026-06-19T13:29:26Z'
+assignee: null
 ---
 
+## Goal
+
+Design Yoi's Plugin model as a user-facing package/config/runtime layer built on top of `pod::feature` and a deliberately small host API.
+
+Use three stable terms:
+
+- **Plugin runtime**: how Plugin code/config is executed.
+- **Plugin surface**: what the Plugin adds to Yoi.
+- **Plugin host API**: what Yoi-provided capabilities a Plugin runtime may call while implementing a surface.
+
+`pod::feature` remains the internal substrate for contribution registration, lifecycle diagnostics, and Worker/ToolRegistry/HookRegistry integration. Plugin owns package identity, enablement, runtime selection, Plugin-layer permissions, trust policy, and host API grants.
+
+MCP is not the Plugin model and should not be treated as a Plugin permission backend. MCP is a separate protocol-backed integration layer that also uses `pod::feature` and owns MCP-specific enablement/trust policy.
+
 ## Background
 
-insomnia currently has internal Hook / Tool concepts, plus a separate planned MCP integration ticket (`mcp-integration`). The next design step is to define the project-level Plugin surface: how user/project-provided extensions can contribute Tools and Hooks without weakening scope, permission, history, or prompt-context invariants.
+Yoi already has internal extension-like surfaces:
 
-The plugin surface should not be a grab bag of arbitrary code execution. Candidate extension mechanisms have different trust and protocol properties:
+- Tools via `llm_worker::ToolRegistry` / `ToolDefinition`
+- Hooks via `HookRegistry` / `HookEvent` / `HookAction`
+- Feature contribution declarations in `pod::feature`
+- Built-in features such as task and ticket tools
 
-- MCP: protocol-bound external tool/resource/prompt provider surface.
-- TOML/config-only hooks: declarative configuration for simple hook behavior without arbitrary code.
-- WASM: planned first programmable plugin runtime for Hooks and Tools, with explicit capability imports and sandboxing.
-- General scripting languages: considered, but not the initial direction because arbitrary script execution broadens the trust/runtime surface too quickly.
+Plugin design must not let external packages bypass Worker history, prompt/context invariants, scoped tool permissions, restore snapshot authority, or launch-policy authority.
 
-## Related work
+Prior Hook hardening work constrains model-visible context mutation so Plugin exposure can stay safe. Plugin design should reuse those safe surfaces rather than creating parallel prompt/history/tool paths.
 
-- `work-items/open/20260529-161928-mcp-integration/` — MCP integration as one plugin backend / external capability bridge.
-- `work-items/open/20260603-122317-plugin-feature-contribution-registry/` — implementation-oriented runtime registry split-out for built-in and external feature contributions.
-- `work-items/open/20260603-122317-hook-public-surface-hardening/` — prerequisite hardening for public Hook contribution safety.
-- Existing internal hooks/tools code: `crates/pod`, `crates/tools`, `crates/llm-worker`.
-- Manifest permission policy and scope enforcement must remain authoritative for plugin-provided tools.
+A concrete future use case is a chat bridge such as Slack/Discord. The preferred architecture is not that Yoi starts or bundles a full Slack/Discord SDK process. An externally managed bridge service, such as a `discord.js` service, may expose a small HTTPS API; a Yoi Plugin can call that API using configured URL/auth data. A Plugin may also run a Pod-lifetime service loop and submit external events through a host-mediated Ingress surface, but those semantics must stay concrete and bounded.
+
+## Plugin runtime
+
+Runtime answers: **how is Plugin code/config executed?**
+
+Supported design vocabulary:
+
+- `declarative`: config-only Plugin behavior, no arbitrary code execution.
+- `wasm`: sandboxed WASM Plugin module with explicit host APIs.
+- `external_process`: future/optional runtime. Do not assume it for the initial Plugin model.
+
+The initial runtime direction is:
+
+```text
+runtime: declarative and/or wasm
+host APIs: https + fs, plus surface-intrinsic ingress/diagnostics where required
+surfaces: Tool + Hook + Service + Ingress
+```
+
+## Plugin surface
+
+Surface answers: **what does the Plugin add to Yoi?**
+
+The Plugin surfaces are:
+
+- `Tool`
+- `Hook`
+- `Service`
+- `Ingress`
+
+Do not use `Outbound` as a separate surface. External writes are represented as Tool surface entries with side-effect metadata.
+
+### Tool surface
+
+A Tool surface adds model/workflow-callable operations through ordinary Yoi ToolRegistry paths.
+
+External side effects such as chat sends are Tools:
+
+```text
+discord_send_message
+slack_reply_thread
+github_create_issue_comment
+```
+
+Requirements:
+
+- registers through ordinary ToolRegistry / `pod::feature` paths
+- uses normal model-visible schema exposure
+- passes normal PreToolCall permission policy
+- commits tool call/result through normal history plumbing
+- uses bounded result serialization
+- declares side-effect metadata such as `effect = "external_write"` where applicable
+- validates configured destination allowlists before executing external writes
+
+### Hook surface
+
+A Hook surface reacts to supported Yoi lifecycle events using the hardened public Hook API.
+
+Requirements:
+
+- no raw hidden `Item` injection
+- no prompt/context mutation outside durable history-aware paths
+- explicit supported `HookAction` subset only
+- Hook-triggered external writes must still go through Tool or another explicit host-approved path, not hidden side effects
+
+### Service surface
+
+A Service surface is Pod-lifetime Plugin work managed by Yoi's Plugin runtime.
+
+The initial Service contract is concrete and limited:
+
+- Services start during Pod startup after explicit Plugin enablement is resolved.
+- Services stop when the Pod stops or when the Plugin instance is replaced during restore/relaunch.
+- Services report lifecycle state: `starting`, `ready`, `degraded`, `failed`, `stopping`, `stopped`.
+- Services may use only granted Plugin host APIs, initially `https` and `fs`, plus surface-intrinsic diagnostics and ingress submission where granted.
+- Services must be cancellable and must not block Pod shutdown indefinitely.
+- Service diagnostics must be bounded and must redact secrets.
+
+For chat bridge Plugins, Service is the WASM-side client loop that communicates with an externally managed bridge service over HTTPS polling or other explicitly designed future event mechanisms. WebSocket/SSE are not implied by the word Service; they require separate host API design.
+
+### Ingress surface
+
+Ingress is the host-mediated surface for external events entering Yoi.
+
+Plugins do **not** directly choose `Notify`, `Run`, target Pod, or hidden context insertion. A Plugin submits a typed external event to the host:
+
+```text
+host.ingress.submit(event)
+```
+
+Then host routing policy decides delivery:
+
+```text
+submit external event -> route/dedup/bounds/policy -> notify | run | drop | diagnostic
+```
+
+Initial typed event target for chat bridges:
+
+```text
+ExternalMessageEvent {
+  source_plugin,
+  provider,
+  external_workspace_id/team_id/guild_id,
+  channel_id,
+  thread_id?,
+  message_id,
+  actor_id,
+  actor_display_name?,
+  text,
+  attachments[],
+  timestamp,
+  permalink?,
+  dedup_key,
+}
+```
+
+Requirements:
+
+- external content is untrusted
+- event size is bounded before entering Yoi history/model-visible context
+- host performs deduplication and loop prevention
+- host routing config decides target Pod and delivery mode
+- accepted events are appended through durable history/notification paths before they can affect model context
+- rejected/dropped events produce bounded diagnostics without unnecessarily storing message content
+
+## Plugin host APIs
+
+Host API answers: **what Yoi-provided capabilities can a Plugin runtime call while implementing a surface?**
+
+Host APIs are runtime capabilities controlled by Plugin-layer grants. Keep this set narrow. Do not add a broad API to avoid deciding concrete semantics.
+
+The initial general-purpose host API set is:
+
+- `https`: bounded HTTPS client only.
+- `fs`: scoped filesystem read/write under explicit Plugin grants.
+
+Surface-intrinsic host calls also exist where required:
+
+- `ingress.submit`: available only to Plugins granted the Ingress surface.
+- `diagnostics`: bounded lifecycle/error/health reporting for Plugin runtime and Service surface.
+
+Use `https`, not `web`, for the initial network API. The first network host API should not imply arbitrary browser-like web capabilities, raw TCP, local network access, HTTP without TLS, WebSocket, SSE, DNS policy, or remote fetching semantics beyond the explicitly designed HTTPS client.
+
+### `https` host API
+
+Initial requirements:
+
+- HTTPS only
+- explicit allowlist of origins or exact endpoints
+- bounded request/response size
+- timeout/cancellation
+- configured headers/auth data only through Plugin enablement policy
+- no implicit access to ambient environment variables or host credentials
+- diagnostics must redact credentials and sensitive headers
+
+WebSocket, SSE, long polling helpers, and inbound server/webhook APIs are out of the initial host API unless a later Ticket designs them explicitly.
+
+### `fs` host API
+
+Initial requirements:
+
+- scoped paths explicitly granted by Plugin-layer policy
+- no automatic inheritance from Pod workspace scope
+- bounded read/write operations
+- path traversal protection
+- diagnostics that identify denied paths without leaking file contents
 
 ## Requirements
 
-- Define a Plugin surface that can provide:
-  - Tools callable by the LLM through the normal ToolRegistry / permission / scope path;
-  - Hooks observing or influencing Pod/Worker lifecycle through the existing Hook boundary, not by directly mutating worker history/context.
-- Separate plugin description/registration from plugin runtime implementation.
-  - A plugin manifest should declare provided tools/hooks, required capabilities, configuration schema or config values, and trust/runtime type.
-  - Runtime implementations can include MCP, declarative config hooks, and WASM in separate phases.
-- Keep MCP as a related backend, not the whole plugin model.
-  - MCP servers remain untrusted external capability providers bridged through allowlists, bounded output, scope/permission policy, and explicit resource/prompt use.
-- Define a declarative hook path for simple TOML/config-only behavior where code execution is unnecessary.
-- Define a WASM plugin direction for programmable Hooks/Tools.
-  - WASM modules must receive explicit host imports/capabilities only.
-  - File/network/process access must not be ambient; all external effects go through host-provided capability APIs and existing policy checks.
-  - Tool outputs must be bounded and recorded through normal history/tool-result paths.
-- Preserve LLM context/history invariants.
-  - Plugins must not inject cross-turn invisible context.
-  - If plugin output becomes model-visible, it must enter through durable history/tool/hook paths according to existing rules.
-- Preserve scope and permission invariants.
-  - Plugin-provided tools must not bypass `ScopedFs`, manifest tool permission policy, child scope delegation, or web/network policy.
-- Clarify trust model and lifecycle.
-  - Builtin vs project vs user plugins.
-  - Discovery/enablement through manifest/profile/config.
-  - Versioning / compatibility boundaries.
-  - Diagnostics when a plugin cannot load or asks for unavailable capabilities.
-
-## Non-goals
-
-- Implementing the full WASM runtime in the first design step.
-- Implementing MCP itself beyond referencing the existing MCP integration ticket.
-- Supporting arbitrary host scripting languages as a first-class plugin runtime.
-- Allowing plugins to mutate session history, memory, prompt context, or scope outside approved APIs.
-- Adding UI plugin systems or TUI rendering extensions.
-
-## Suggested phases
-
-1. **Design / architecture note**
-   - Define Plugin, PluginManifest, PluginRuntimeKind, Tool contribution, Hook contribution, capability request, and trust/source model.
-   - Map MCP, declarative hooks, and WASM onto that model.
-2. **Internal registry boundary**
-   - Detailed implementation is split to `plugin-feature-contribution-registry` so this ticket can stay focused on the architecture surface and invariants.
-3. **Declarative hooks MVP**
-   - Add a non-code configuration path for simple hook behavior if an immediate use case exists.
-4. **WASM spike**
-   - Evaluate runtime (`wasmtime` or alternative), host imports, resource limits, serialization, and Nix/package impact.
-5. **MCP bridge alignment**
-   - Ensure `mcp-integration` plugs into the same Tool/permission/output boundary rather than becoming a parallel extension path.
+- Define Plugin as a user-facing layer over `pod::feature`, not as the feature API itself.
+  - Plugin package/config/runtime code eventually contributes through `pod::feature`.
+  - `pod::feature` remains responsible for contribution declarations, lifecycle, diagnostics, and registration plumbing.
+  - Plugin remains responsible for package enablement, provenance, runtime selection, host API grants, and Plugin-layer permission/trust policy.
+- Use the terms `Plugin runtime`, `Plugin surface`, and `Plugin host API`; avoid durable/user-facing use of `contribution category`.
+- Plugin surfaces are Tool / Hook / Service / Ingress.
+- Service has a Pod-lifetime lifecycle contract; it does not imply WebSocket/SSE/raw network support.
+- Ingress is `host.ingress.submit(typed external event)`; host routing decides notify/run/drop/diagnostic.
+- External outbound side effects are Tool surface entries with external-write metadata, not a separate Outbound surface.
+- Initial general-purpose Plugin host APIs are only `https` and `fs`.
+- `ingress.submit` and `diagnostics` are surface-intrinsic host calls, not broad ambient capabilities.
+- Do not expose a generic `web` API in the initial Plugin model.
+- Define Plugin-layer permission and trust model separately from `pod::feature`.
+  - Do not rely on feature-level `HostAuthority` / authority grants for Plugin permissions.
+  - Plugin grants are tied to package identity/runtime/user or workspace config, not feature install reports.
+  - Plugin policy decides which surfaces and host APIs a Plugin runtime can use.
+- Define runtime families separately.
+  - Declarative/config-only Plugins
+  - WASM Plugins
+  - External process Plugins only as an explicit future/optional runtime
+  - MCP remains a separate feature-backed protocol integration, not the Plugin permission model.
+- Plugin metadata, config, external data, and package content are untrusted input.
+- Plugin enablement must be explicit.
+  - package presence/discovery alone cannot enable or execute Plugin code
+  - workspace/user config must opt in to package/runtime/surface activation and host API grants
+- The design must document the boundary among Plugin, MCP, and built-in Features.
 
 ## Acceptance criteria
 
-- The repository has a documented plugin architecture proposal covering Tools, Hooks, runtimes, capability model, trust model, and discovery/enablement.
-- MCP is positioned as one plugin backend / bridge and linked to `mcp-integration`, not treated as the only extension mechanism.
-- The proposal explicitly explains why arbitrary scripting languages are deferred and why WASM is the initial programmable runtime direction.
-- The design preserves existing scope, permission, history, and prompt-context invariants.
-- Follow-up implementation tickets can be cut independently for declarative hooks, WASM runtime, and MCP bridge integration.
-- Any code changes in this ticket, if taken beyond design docs, are limited to safe internal boundaries and have focused tests.
+- A design note or Ticket plan defines Plugin as a user-facing layer over `pod::feature`.
+- The plan uses `runtime`, `surface`, and `host API` terminology and avoids relying on `contribution category` as the durable term.
+- The plan states that Plugin surfaces are Tool / Hook / Service / Ingress.
+- The plan states that Service has concrete Pod-lifetime lifecycle semantics and does not imply unspecified network/event APIs.
+- The plan states that Ingress is typed external-event submission to the host, not direct Notify/Run/context injection.
+- The plan states that external outbound side effects are Tool surface entries with external-write metadata.
+- The plan states that initial general-purpose Plugin host APIs are `https` and `fs` only.
+- The plan states that `https` is HTTPS-only and does not imply generic `web`/browser/raw-network capabilities.
+- The plan states that filesystem access is a Plugin host API controlled by Plugin-layer grants and does not inherit Pod workspace scope automatically.
+- The plan states that Plugin permissions are Plugin-layer policy and are not implemented by `pod::feature` `HostAuthority` grants.
+- The plan states that MCP is a separate feature-backed integration with MCP-specific enablement/trust policy.
+- The public Hook safety invariants from `00001KT6Q08R8` remain intact.
+- Tool Plugins are required to use ordinary ToolRegistry / permission / history / bounded-result paths.
+- No design path allows Plugin package presence alone to execute code or mutate context.
+- The design identifies which follow-up Tickets own package format, runtime implementation, host APIs, and Plugin permission details.
+
+## Suggested decomposition
+
+1. Public Hook surface hardening. Completed by `00001KT6Q08R8`.
+2. Feature contribution API substrate. Completed by `00001KT6Q08R9` and `00001KTR81P9X`.
+3. Plugin package/discovery format. Tracked by `00001KT0Z4BK8`.
+4. Plugin enablement plan + metadata snapshot restore integration.
+5. WASM/declarative runtime slice with Tool and Hook surfaces.
+6. Plugin host API slice for `https` and `fs` only.
+7. Service lifecycle surface.
+8. Ingress external-message submission and routing policy.
+9. Tool external-write metadata and destination allowlist enforcement.
+10. Future Ticket: streaming event APIs such as SSE/WebSocket/long polling, if HTTPS polling is insufficient.
+11. MCP local stdio integration remains tracked separately by `00001KTR82RB7`.
+
+## Notes
+
+- This Ticket is a design coordination Ticket; implementation should be split into concrete Tickets rather than landing a broad Plugin platform in one change.
+- Keep Plugin permission terms distinct from removed feature-layer `HostAuthority` terminology.
+- Avoid requiring Yoi to manage arbitrary external SDK processes for chat bridge support.
+- Avoid broad host APIs. Add host APIs only when a concrete Plugin surface and use case require them.

.yoi/tickets/00001KSXRQ4G8/resolution.md

@@ -0,0 +1,8 @@
+Closed as superseded by durable Objective and design documentation.
+
+This Ticket was a broad Plugin runtime/surface/host API design record rather than a concrete implementation task. The useful design decisions have been moved into durable roadmap/design context:
+- Objective `00001KVG0HR9M` (`Plugin platform roadmap`) now owns the overall Plugin roadmap and sequencing context.
+- `docs/design/plugin-component-model.md` records Component Model research and migration direction.
+- `docs/design/plugin-packages.md` records package/runtime metadata direction.
+
+Concrete implementation work remains tracked by implementation Tickets such as package discovery, Tool registration, WASM runtime, permission grants, CLI inspection, `https`, `fs`, and Component Model runtime migration. Future Plugin work should be filed as concrete implementation Tickets, not broad design umbrella Tickets.

.yoi/tickets/00001KSXRQ4G8/thread.md

@@ -39,4 +39,89 @@ Two implementation-oriented prerequisite tickets are split out:
 This preserves the desired detachable shape: feature state remains in the feature/extension module, while Pod interaction happens through existing durable host surfaces. WorkItem management should be implemented as a built-in feature contribution once the registry boundary is in place, rather than as a special Pod context-injection path.
 
 
+---
+
+<!-- event: decision author: hare at: 2026-06-13T15:29:21Z -->
+
+## Decision
+
+決定:
+- `pod::feature` は API / contribution substrate として扱い、Plugin や MCP の権限管理を担わせない。
+- Plugin は `pod::feature` をユーザー向け package/config/runtime 形式で使わせる層であり、Plugin permission / trust policy は Plugin layer で定義する。
+- MCP は `pod::feature` 上に protocol-backed integration layer を構築するが、MCP server enablement / command-env-secret policy / trust boundary / MCP-specific permission は MCP layer が独自に持つ。
+- MCP local stdio server の OS-level side effects は Yoi feature authority では制御できないため、feature-layer authority / grant を MCP や Plugin の permission model に流用しない。
+
+反映:
+- `00001KTR81P9X` は authority ではなく provider lifecycle / dynamic contribution / normal ToolRegistry path / untrusted normalization に絞る。
+- `00001KTR82RB7` は MCP 固有の explicit config と trust model を持つ。
+- `00001KSXRQ4G8` と `00001KT0Z4BK8` は Plugin permission を Plugin layer として扱い、MCP を初期 Plugin packaging/runtime から分離する。
+
+
+---
+
+<!-- event: decision author: hare at: 2026-06-14T16:53:27Z -->
+
+## Decision
+
+決定:
+- Durable terminology は `Plugin runtime` / `Plugin surface` / `Plugin host API` にする。`contribution category` は分かりづらいため設計語彙として使わない。
+- Plugin surface は Tool / Hook / Service / Ingress の4つに整理する。
+- Outbound は独立 surface にしない。Slack/Discord 送信など外部副作用は `external_write` metadata を持つ Tool として扱う。
+- Ingress は Plugin が Notify/Run を直接呼ぶ API ではなく、typed external event を host に submit する API とする。host routing policy が notify/run/drop を決める。
+- Web/FS/Secret/State/Timer/Diagnostics は Plugin surface ではなく Plugin host API。WASM などの runtime が surface を実装するために、Plugin-layer grant で明示的に許可された範囲だけ使える。
+- Chat bridge target は、Yoi が discord.js/Slack SDK process を起動する前提にしない。外部管理の bridge service に WASM Plugin が configured URL + SecretRef で接続する設計を first-class にする。
+
+
+---
+
+<!-- event: decision author: hare at: 2026-06-14T17:19:59Z -->
+
+## Decision
+
+決定:
+- Initial Plugin surface は Tool / Hook を主軸にする。
+- Service / Ingress は将来候補として残すが、Submit/Notify/Run や lifecycle semantics を具体化する別 Ticket まで初期 contract には入れない。
+- Outbound は独立 surface にしない。外部副作用は `external_write` metadata を持つ Tool として扱う。
+- Plugin host API は初期は `https` と `fs` に絞る。`web` という広い API 名は使わず、HTTPS-only の bounded client と scoped FS として設計する。
+- WebSocket/SSE/long polling、timer、state、secret plaintext access、Ingress submit API は必要性が具体化した時点で追加設計する。
+
+
+---
+
+<!-- event: decision author: hare at: 2026-06-14T17:22:23Z -->
+
+## Decision
+
+決定:
+- Service / Ingress は Plugin surface として必要なので初期設計対象に戻す。
+- Service は Pod-lifetime の Plugin work として具体化する。ただし Service という語は WebSocket/SSE/raw network support を含意しない。初期の外部通信は `https` host API の範囲に限定し、streaming API は別途設計する。
+- Ingress は `host.ingress.submit(typed external event)` として具体化する。Plugin が Notify/Run/context injection を直接選ばず、host routing policy が notify/run/drop/diagnostic を決める。
+- General-purpose host API は引き続き `https` と `fs` に絞る。`ingress.submit` と `diagnostics` は surface-intrinsic host calls として扱い、広い ambient capability にはしない。
+
+
+---
+
+<!-- event: state_changed author: hare at: 2026-06-19T13:29:26Z from: planning to: closed reason: closed field: state -->
+
+## State changed
+
+Ticket を closed にしました。
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-19T13:29:26Z status: closed -->
+
+## 完了
+
+Closed as superseded by durable Objective and design documentation.
+
+This Ticket was a broad Plugin runtime/surface/host API design record rather than a concrete implementation task. The useful design decisions have been moved into durable roadmap/design context:
+- Objective `00001KVG0HR9M` (`Plugin platform roadmap`) now owns the overall Plugin roadmap and sequencing context.
+- `docs/design/plugin-component-model.md` records Component Model research and migration direction.
+- `docs/design/plugin-packages.md` records package/runtime metadata direction.
+
+Concrete implementation work remains tracked by implementation Tickets such as package discovery, Tool registration, WASM runtime, permission grants, CLI inspection, `https`, `fs`, and Component Model runtime migration. Future Plugin work should be filed as concrete implementation Tickets, not broad design umbrella Tickets.
+
+
 ---

.yoi/tickets/00001KT0Z4BK8/artifacts/orchestration-plan.jsonl

@@ -0,0 +1,2 @@
+{"id":"orch-plan-20260614-154052-1","ticket_id":"00001KT0Z4BK8","kind":"waiting_capacity_note","note":"Ticket 自体は implementation_ready で blocking relation なし。現在 `00001KTFY8V80` と `00001KV09WYC6` の Coder Pod が running で、review/integration follow-up capacity も必要なため、追加 spawn は一時待機する。","author":"yoi-orchestrator","at":"2026-06-14T15:40:52Z"}
+{"id":"orch-plan-20260614-154934-2","ticket_id":"00001KT0Z4BK8","kind":"accepted_plan","accepted_plan":{"summary":"Accept queued Plugin package/discovery design Ticket now that one active Coder has moved to review stage. Implement as design proposal and minimal safe references, preserving Plugin/MCP/feature authority boundaries.","branch":"impl/00001KT0Z4BK8-plugin-package-discovery","worktree":"/home/hare/Projects/yoi/.worktree/00001KT0Z4BK8-plugin-package-discovery","role_plan":"Orchestrator creates a dedicated implementation worktree and spawns a Coder with write scope limited to that worktree. Reviewer will run read-only after implementation report. This work is documentation/design-focused and source-disjoint from active Panel/TUI implementation."},"author":"yoi-orchestrator","at":"2026-06-14T15:49:34Z"}

.yoi/tickets/00001KT0Z4BK8/item.md

@@ -1,50 +1,57 @@
 ---
-title: "Plugin distribution package format and discovery"
-state: "planning"
-created_at: "2026-06-01T06:49:53Z"
-updated_at: "2026-06-01T06:50:33Z"
+title: 'Plugin distribution package format and discovery'
+state: 'closed'
+created_at: '2026-06-01T06:49:53Z'
+updated_at: '2026-06-15T06:33:50Z'
+queued_by: 'workspace-panel'
+queued_at: '2026-06-14T15:40:15Z'
 ---
 
 ## Background
 
-The plugin extension surface ticket (`plugin-extension-surface`) defines Plugins as a safe contribution model for Tools and Hooks, with MCP, declarative hooks, and WASM treated as runtime mechanisms. The next design question is how plugins are distributed, discovered, installed, and enabled across user and workspace scopes.
+The plugin extension surface ticket (`00001KSXRQ4G8`) defines Plugins as the user-facing package/config/runtime layer that uses the `pod::feature` API substrate to contribute Tools, Hooks, and related runtime surfaces. The next design question is how plugins are distributed, discovered, installed, and enabled across user and workspace scopes.
+
+MCP is intentionally not modeled as a Plugin package/runtime in this Ticket. MCP is a separate feature-backed protocol integration with its own enablement and trust policy. Plugin package design may later reference MCP-related assets only through an explicitly approved follow-up; package discovery must not imply MCP server execution.
 
 The desired initial direction is a single-file plugin package that can be placed in user or workspace plugin stores, for example:
 
-- `~/.config/insomnia/plugins/<id>.insomnia-plugin`
-- `./.insomnia/plugins/<id>.insomnia-plugin`
+- `${XDG_DATA_HOME:-~/.local/share}/yoi/plugins/<id>.yoi-plugin`
+- `<workspace>/.yoi/plugins/<id>.yoi-plugin`
 
-The package should be easy to copy, inspect, cache, and pin, while preserving Insomnia's scope, permission, history, prompt-context, and trust invariants. In particular, workspace plugins may come from a repository checkout and must not execute merely because an archive exists under `./.insomnia/plugins`.
+The package should be easy to copy, inspect, cache, and pin while preserving Yoi's scope, permission, history, prompt-context, and trust invariants. Workspace plugins may come from a repository checkout and must not execute merely because an archive exists under `./.yoi/plugins`.
 
 ## Requirements
 
 - Define a first-class plugin package format.
-  - Use a single archive file with an Insomnia-specific extension such as `.insomnia-plugin`.
+  - Use a single archive file with a Yoi-specific extension such as `.yoi-plugin`.
   - Require a root plugin manifest file such as `plugin.toml`.
   - Support packaged assets such as `module.wasm`, JSON schemas, README, and license files.
   - Specify archive safety rules, including path traversal rejection, bounded extraction, and deterministic digest calculation.
 - Define plugin stores and source/trust mapping.
-  - User plugin store: `~/.config/insomnia/plugins/`.
-  - Workspace/project plugin store: `./.insomnia/plugins/`.
-  - Map stores to the existing source vocabulary (`User`, `Project`/workspace, and future `Builtin`).
-  - Treat `user:<id>` and `project:<id>` as distinct plugin references; ambiguous unqualified IDs should fail closed.
+  - User plugin store: `${XDG_DATA_HOME:-~/.local/share}/yoi/plugins/`.
+  - Workspace/project plugin store: `<workspace>/.yoi/plugins/`.
+  - Builtin plugin source: Yoi-distributed `builtin:` registry.
+  - Map stores to the source vocabulary (`user`, `project`, `builtin`).
+  - Treat `user:<id>` and `project:<id>` as distinct plugin references; ambiguous unqualified IDs fail closed.
 - Separate discovery from enablement.
-  - Insomnia may discover plugin packages in configured stores.
-  - Discovered packages must not register Tools/Hooks, initialize WASM, or start MCP servers until explicitly enabled by manifest/profile configuration.
-  - Enablement must resolve package identity, version/API compatibility, source, digest, requested capabilities, and host-granted capabilities.
+  - Yoi may discover plugin packages in configured stores.
+  - Discovered packages must not register Tools/Hooks, initialize WASM, start services, or start MCP servers until explicitly enabled by manifest/profile configuration.
+  - Enablement must resolve package identity, version/API compatibility, source, digest, requested Plugin permissions, and effective Plugin-layer grants.
 - Define package manifest semantics.
-  - Include fields for plugin id, version, plugin API version, runtime kind, source/provenance, metadata, contributed tools/hooks, configuration schema, and requested capabilities.
-  - Capability declarations are requests, not grants; effective grants remain controlled by manifest/profile policy, scope, permissions, web/network policy, secret references, and runtime-specific allowlists.
+  - Include fields for plugin id, version, plugin API version, runtime kind, source/provenance, metadata, contributed tool/hook descriptors, configuration schema, and requested Plugin permissions.
+  - Permission declarations are requests, not grants.
+  - Effective grants are controlled by Plugin-layer policy and existing Yoi manifest/profile policy, scope, tool permissions, web/network policy, secret references, and runtime-specific allowlists.
+  - Do not use `pod::feature` `HostAuthority` / authority grants as the Plugin package permission model.
 - Define runtime-specific packaging expectations.
   - Declarative hooks can be packaged as config-only assets without arbitrary code execution.
-  - WASM plugins should package a module plus schemas/assets and run only with explicit host imports/capabilities.
-  - MCP should remain modeled as a backend/bridge; packaging an MCP server or process command requires explicit process/capability design and must not auto-start from workspace packages.
+  - WASM plugins should package a module plus schemas/assets and run only with explicit host imports/capabilities decided by Plugin-layer policy.
+  - MCP is separate from Plugin packaging for now; packaging or launching an MCP server from a plugin package is out of scope unless a later Ticket defines that bridge explicitly.
 - Define cache/pinning behavior.
   - Extract or materialize packages into a digest-keyed cache before runtime initialization.
   - Consider digest pins in manifest/profile enablement entries or a future lock file.
   - Record resolved package digest/source/provenance in the resolved manifest/session metadata where appropriate.
 - Define diagnostics.
-  - Report load/parse/compatibility/capability/runtime failures with plugin id, source, runtime kind, and phase.
+  - Report load/parse/compatibility/permission/runtime failures with plugin id, source, runtime kind, and phase.
   - Diagnostics must not expose secret values, raw credentials, or unsafe command/environment details.
 
 ## Non-goals
@@ -54,29 +61,31 @@ The package should be easy to copy, inspect, cache, and pin, while preserving In
 - Auto-enabling plugins solely because they are present in a plugin directory.
 - Defining UI/TUI rendering extension packaging.
 - Allowing arbitrary host scripting languages as plugin packages.
-- Starting workspace-provided MCP servers without explicit enablement and capability approval.
+- Using `pod::feature` authority grants as the Plugin package permission model.
+- Starting workspace-provided MCP servers from plugin package discovery.
 
 ## Suggested phases
 
 1. **Architecture note**
-   - Define `.insomnia-plugin` package structure, `plugin.toml` fields, source/trust model, discovery vs enablement, archive safety, cache/digest behavior, and runtime mappings.
+   - Define `.yoi-plugin` package structure, `plugin.toml` fields, source/trust model, discovery vs enablement, archive safety, cache/digest behavior, and runtime mappings.
 2. **Manifest/profile config shape**
-   - Add or propose `[plugins]` enablement entries with source/id/version/digest selectors and capability grants.
+   - Add or propose `[plugins]` enablement entries with source/id/version/digest selectors and Plugin-layer permission grants.
 3. **Package discovery prototype**
    - Implement read-only discovery of user/workspace plugin packages and diagnostics without runtime initialization.
 4. **Package validation and cache**
    - Validate archive layout, parse `plugin.toml`, compute digest, and materialize into a digest-keyed cache.
-5. **Registry integration**
-   - Connect validated packages to the plugin contribution registry from `plugin-extension-surface` follow-up work.
+5. **Feature API integration**
+   - Connect enabled, validated Plugin runtime contributions to `pod::feature` as the API substrate.
 6. **Runtime-specific follow-ups**
-   - Split declarative hook packaging, WASM packaging, and MCP packaging/bridge behavior into separate tickets as needed.
+   - Split declarative hook packaging, WASM packaging, and any external process/plugin bridge behavior into separate tickets as needed.
+   - Keep MCP integration in its own Ticket family unless a future explicit bridge is approved.
 
 ## Acceptance criteria
 
 - The repository has a documented plugin distribution/package proposal covering user and workspace plugin stores, single-file archive format, manifest fields, archive safety, cache/digest behavior, and discovery vs enablement.
-- The proposal explicitly states that placing a package in `~/.config/insomnia/plugins/` or `./.insomnia/plugins/` is discovery only, not execution or registration.
+- The proposal explicitly states that placing a package in `${XDG_DATA_HOME:-~/.local/share}/yoi/plugins/` or `<workspace>/.yoi/plugins/` is discovery only, not execution or registration.
 - The design maps package sources to user/project/builtin trust categories and defines how ID collisions and ambiguous selectors are handled.
-- The design explains how capability requests differ from host-granted capabilities and how existing scope/permission/secret/web policy remains authoritative.
-- Runtime-specific notes cover declarative hooks, WASM packages, and MCP backend/bridge packaging constraints.
-- Follow-up implementation tickets can be cut independently for manifest/profile enablement, package discovery, archive validation/cache, WASM packaging, and MCP packaging alignment.
+- The design explains Plugin permission requests/grants as Plugin-layer policy, distinct from `pod::feature` authority/grant concepts.
+- Runtime-specific notes cover declarative hooks and WASM packages; MCP is called out as a separate feature-backed integration, not part of initial Plugin packaging.
+- Follow-up implementation tickets can be cut independently for manifest/profile enablement, package discovery, archive validation/cache, Plugin permission policy, WASM packaging, and any future MCP/plugin bridge alignment.
 - Any code changes in this ticket, if taken beyond design docs, are limited to safe internal boundaries and focused tests.

.yoi/tickets/00001KT0Z4BK8/resolution.md

@@ -0,0 +1,3 @@
+Ticket `00001KT0Z4BK8` (`Plugin distribution package format and discovery`) はすでに `state: done` に到達していたため、workspace Panel から close しました。
+
+この Close action によって、実装作業、state 変更、Orchestrator/Companion launch、worker invocation は開始されていません。

.yoi/tickets/00001KT0Z4BK8/thread.md

@@ -19,4 +19,380 @@ Distribution direction from user discussion:
 - Workspace packages are repository-provided and must be treated conservatively, especially for executable runtimes and MCP/process-spawn behavior.
 
 
+---
+
+<!-- event: decision author: hare at: 2026-06-13T15:29:21Z -->
+
+## Decision
+
+決定:
+- `pod::feature` は API / contribution substrate として扱い、Plugin や MCP の権限管理を担わせない。
+- Plugin は `pod::feature` をユーザー向け package/config/runtime 形式で使わせる層であり、Plugin permission / trust policy は Plugin layer で定義する。
+- MCP は `pod::feature` 上に protocol-backed integration layer を構築するが、MCP server enablement / command-env-secret policy / trust boundary / MCP-specific permission は MCP layer が独自に持つ。
+- MCP local stdio server の OS-level side effects は Yoi feature authority では制御できないため、feature-layer authority / grant を MCP や Plugin の permission model に流用しない。
+
+反映:
+- `00001KTR81P9X` は authority ではなく provider lifecycle / dynamic contribution / normal ToolRegistry path / untrusted normalization に絞る。
+- `00001KTR82RB7` は MCP 固有の explicit config と trust model を持つ。
+- `00001KSXRQ4G8` と `00001KT0Z4BK8` は Plugin permission を Plugin layer として扱い、MCP を初期 Plugin packaging/runtime から分離する。
+
+
+---
+
+<!-- event: decision author: hare at: 2026-06-14T14:34:33Z -->
+
+## Decision
+
+決定:
+- Plugin discovery stores, source-qualified identity, discovery/enablement separation, Pod-startup initialization timing, restore behavior, and MCP boundaryをこの `00001KT0Z4BK8` の安定 contract として統合した。
+- User Plugin package store は `${XDG_DATA_HOME:-~/.local/share}/yoi/plugins/` とし、`~/.config/yoi/plugins/` は使わない。
+- Package presence は discovery only であり、実行・登録・runtime initialization は explicit enablement 後の Pod startup に限定する。
+- Restore は metadata snapshot の enabled Plugin plan を正本とし、fresh discovery で silent upgrade しない。
+
+
+---
+
+<!-- event: intake_summary author: hare at: 2026-06-14T14:53:35Z -->
+
+## Intake summary
+
+Marked ready by `yoi ticket state`.
+
+---
+
+<!-- event: state_changed author: "yoi ticket" at: 2026-06-14T14:53:35Z from: planning to: ready reason: cli_state field: state -->
+
+## State changed
+
+Marked ready by `yoi ticket state`.
+
+
+---
+
+<!-- event: state_changed author: workspace-panel at: 2026-06-14T14:54:52Z from: ready to: planning reason: panel_return_to_planning field: state -->
+
+## State changed
+
+Panel returned ready Ticket 00001KT0Z4BK8 to planning for requirements sync. This is not Queue routing and must not start implementation.
+
+## User refinement instruction
+
+前何回かに渡って実装されたlatencyとかE2Eとかの話なんだけど
+
+
+---
+
+<!-- event: comment author: intake at: 2026-06-14T14:56:35Z -->
+
+## Comment
+
+Intake 確認:
+- Ticket `00001KT0Z4BK8` の body / thread / artifacts を確認した。この Ticket の現在の主題は Plugin distribution package format / discovery / enablement boundary であり、直近の user refinement「前何回かに渡って実装されたlatencyとかE2Eとかの話なんだけど」は、この Ticket の plugin package 要件とは直接対応しない。
+- 関連しそうな既存 Ticket として `00001KV0723PC`（Panel Quit latency）、`00001KSKBP9YG`（E2E harness）、`00001KV0TJVN5`（E2E binary/env isolation）、`00001KV0YK5S0`（E2E tmp/runtime isolation）、`00001KV10SN02`（E2E critical-path coverage）を確認した。いずれも closed で、latency/E2E の実装・検証・残差整理はそちらの系譜に記録されている。
+- 現時点では、Plugin package Ticket の readiness / requirements を変更する根拠は不足している。ユーザーに、(a) `00001KT0Z4BK8` に latency/E2E 由来の検証要件を追加したいのか、(b) latency/E2E 系の既存 Ticket に追記したいのか、(c) 新しい concrete follow-up Ticket が必要なのか、を確認する。
+
+状態:
+- このコメントは要件同期の保留記録であり、queue / implementation routing ではない。
+- duplicate Ticket は作成していない。
+
+---
+
+<!-- event: comment author: intake at: 2026-06-14T15:12:07Z -->
+
+## Comment
+
+ユーザー確認の要点:
+- ユーザーは latency / mouse / E2E の経緯説明ではなく、最終的な evidence status を確認している。
+- Ticket 記録上、`00001KV0723PC` の元の Panel Quit latency 修正は post-merge measurement で「still present / not proven fixed」と記録されており、ユーザー観測の latency 改善としては最終的に認められていない。
+- `00001KV072V89` の元の mouse selection 修正も post-merge user verification で「マウス選択全く効かない」と記録され、元の done decision は insufficient とされている。
+- 後続 E2E は fixture/PTY 上で mouse click/wheel と quit pending-barrier regression を pass させたが、これは user の実環境・実インストール経路で latency が解消したこと、または mouse 操作が実際に動作したことの human/live confirmation ではない。
+- `00001KT0Z4BK8` 自体の Plugin package requirements には現時点で反映しない。必要なら別 follow-up Ticket として「E2E 結果と user-visible validation gap の整理 / merge gate 明文化」を扱う。
+
+---
+
+<!-- event: intake_summary author: hare at: 2026-06-14T15:37:24Z -->
+
+## Intake summary
+
+Marked ready by `yoi ticket state`.
+
+---
+
+<!-- event: state_changed author: "yoi ticket" at: 2026-06-14T15:37:24Z from: planning to: ready reason: cli_state field: state -->
+
+## State changed
+
+Marked ready by `yoi ticket state`.
+
+
+---
+
+<!-- event: state_changed author: workspace-panel at: 2026-06-14T15:40:15Z from: ready to: queued reason: queued field: state -->
+
+## State changed
+
+Ticket を `workspace-panel` が queued にしました。
+
+
+---
+
+<!-- event: decision author: yoi-orchestrator at: 2026-06-14T15:40:52Z -->
+
+## Decision
+
+Routing decision: implementation_ready_but_waiting_capacity
+
+Reason:
+- Ticket body / thread / artifacts、relation、OrchestrationPlan、Orchestrator workspace state を確認した。Plugin package / discovery / enablement boundary の design work item として要件・受け入れ条件・non-goals・invariants は十分に具体化されている。
+- blocking relation / OrchestrationPlan blocker はない。
+- Plugin package work は現在 active な Panel/TUI implementation と source surface が大きく重ならないため、設計上の conflict blocker ではない。
+- ただし現在 `00001KTFY8V80` と `00001KV09WYC6` の2件が inprogress で Coder Pod running。Reviewer follow-up と integration capacity も未使用ではなく、さらに queued Panel/TUI work 2件を待機させている。
+- 現時点では追加 Coder Pod を spawn せず、active Coder のいずれかが implementation report を返して review/integration 見通しが立ってから acceptance する。
+
+Evidence checked:
+- Ticket body/thread: Plugin package design requirements、過去の Plugin/MCP/feature-layer decision、`planning -> ready`、Panel `ready -> queued` を確認。
+- Ticket relations: blocker なし。
+- OrchestrationPlan: 既存 record なし。
+- Orchestrator workspace: `/home/hare/Projects/yoi/.worktree/orchestration` は clean、queue commit `4be6c966` 上。
+- Visible Pods: `yoi-coder-00001KTFY8V80` と `yoi-coder-00001KV09WYC6` が running。
+
+Next action:
+- 先行 inprogress Ticket の少なくとも1件が implementation report / review stage に進み、Coder capacity が空いた時点で再確認し、unblocked なら `queued -> inprogress` acceptance と dedicated worktree 作成へ進む。
+- planning return ではなく queued のまま waiting とする。
+
+---
+
+<!-- event: decision author: yoi-orchestrator at: 2026-06-14T15:49:34Z -->
+
+## Decision
+
+Routing decision: implementation_ready
+
+Reason:
+- 先行 Coder のうち `00001KV09WYC6` が implementation report を返し review stage に入ったため、Plugin work 用の Coder capacity を再評価した。
+- Ticket body / thread / relations / orchestration plan / Orchestrator workspace state を再確認した。blocking relation はなく、既存 waiting note は capacity 起因であり、現在は1件分の Coder capacity を空けられる。
+- 本 Ticket は Plugin package / discovery / enablement boundary の design/documentation work が主で、active Panel/TUI implementation と source surface が大きく重ならない。
+- Plugin/MCP/feature-layer authority boundary に関する prior decisions は Ticket thread に記録済みで、残る不確実性は proposal の構成・記述・必要最小限の config shape 調査に閉じている。
+
+Evidence checked:
+- Ticket body / thread: package format、store/source mapping、discovery vs enablement、manifest semantics、runtime-specific notes、cache/pinning、diagnostics、prior Plugin/MCP/feature-layer decisions を確認。
+- Ticket relations: blocker なし。
+- OrchestrationPlan: capacity waiting note 1件のみ。blocking/conflict record なし。
+- Orchestrator workspace: `/home/hare/Projects/yoi/.worktree/orchestration` は clean、`80a9e40d` 上。
+- Active Pods: `00001KTFY8V80` coder running、`00001KV09WYC6` reviewer running。
+- Bounded code/doc map: Plugin docs は未作成。関連 candidate は `docs/design/*`, `crates/manifest/src/{config,profile}.rs`, `crates/pod/src/feature.rs`, `crates/pod/src/hook.rs`。
+
+IntentPacket:
+
+Intent:
+- `.yoi-plugin` package distribution/discovery/enablement boundary の durable design proposal を repository に追加し、後続 implementation Ticket を独立して切れる状態にする。
+
+Binding decisions / invariants:
+- Package presence in user/workspace plugin stores is discovery only; registration, WASM init, Hooks/Tools contribution, process/server startup, and MCP server launch require explicit enablement and grants.
+- Source-qualified identity is required: `user:<id>`, `project:<id>`, `builtin:<id>` are distinct; ambiguous unqualified IDs fail closed.
+- Plugin permission declarations are requests, not grants. Effective grants are Plugin-layer policy plus existing manifest/profile/scope/tool/web/secret/runtime allowlists.
+- Do not model Plugin permissions with `pod::feature` HostAuthority/grant concepts.
+- MCP remains a separate feature-backed integration and is out of initial Plugin packaging/runtime unless future Ticket explicitly approves a bridge.
+- Archive handling must reject path traversal and unsafe layout, use bounded extraction, compute deterministic digest, and materialize into digest-keyed cache before runtime initialization.
+- Restore should use resolved manifest/session metadata for enabled Plugin plan; fresh discovery must not silently upgrade a restored Pod.
+
+Requirements / acceptance criteria:
+- Repository contains a documented Plugin distribution/package proposal covering `.yoi-plugin` archive structure, root `plugin.toml`, assets, user/workspace/builtin stores, source/trust mapping, identity collision rules, discovery vs enablement, manifest fields, archive safety, cache/digest/pinning, diagnostics, and runtime-specific notes for declarative hooks and WASM.
+- Proposal explicitly states store placement is discovery only, not execution or registration.
+- Proposal distinguishes Plugin permission request/grant model from `pod::feature` authority concepts.
+- Proposal calls out MCP as separate and out of initial Plugin packaging.
+- Follow-up implementation cuts are clear for manifest/profile enablement, package discovery, archive validation/cache, Plugin permission policy, WASM packaging, and any future MCP/plugin bridge.
+
+Implementation latitude:
+- Primary deliverable may be a design doc plus minimal cross-references; code changes are optional and should stay within safe internal boundaries.
+- Coder may choose exact doc path/name consistent with existing docs organization.
+- If proposing config shape, prefer illustrative schemas over broad runtime implementation unless obviously small and safe.
+
+Escalate if:
+- A real runtime implementation becomes necessary to satisfy the Ticket.
+- Plugin package design would require changing Profile/manifest authority semantics, Pod restore semantics, secret handling, or MCP enablement model.
+- The proposal would imply workspace package execution or silent restore upgrades.
+
+Validation:
+- `cargo fmt --check` if code or Rust doc tests are touched.
+- `git diff --check` always.
+- If only Markdown docs are touched, focused validation may be `git diff --check` plus link/path sanity review.
+
+Current code/doc map:
+- Likely doc destination: `docs/design/`.
+- Related architecture candidates: `crates/manifest/src/config.rs`, `crates/manifest/src/profile.rs`, `crates/pod/src/feature.rs`, `crates/pod/src/hook.rs`.
+
+Critical risks / reviewer focus:
+- Discovery vs enablement separation.
+- Plugin permission requests vs grants.
+- MCP separation.
+- Source identity collision/fail-closed behavior.
+- Archive safety and digest/cache semantics.
+- Restore/fresh discovery no silent upgrade invariant。
+
+---
+
+<!-- event: state_changed author: yoi-orchestrator at: 2026-06-14T15:49:39Z from: queued to: inprogress reason: orchestrator_acceptance_after_capacity_release field: state -->
+
+## State changed
+
+Routing decision と accepted implementation plan を記録済み。blocking relation / orchestration-plan blocker はなく、capacity waiting reason は解消した。implementation side effects の前に `queued -> inprogress` acceptance を記録する。
+
+---
+
+<!-- event: implementation_report author: yoi-coder-00001KT0Z4BK8 at: 2026-06-14T15:53:15Z -->
+
+## Implementation report
+
+Implementation report from Coder Pod `yoi-coder-00001KT0Z4BK8`:
+
+Commit:
+- `3c674a70 docs: propose plugin package distribution`
+
+Changed files:
+- `docs/design/plugin-packages.md`
+  - Added the `.yoi-plugin` package/discovery/enablement design proposal.
+- `docs/README.md`
+  - Added the new design doc to the maintained documentation reading order.
+
+Design choices covered:
+- `.yoi-plugin` as a constrained single-file archive with required root `plugin.toml`.
+- Suggested package layout for `module.wasm`, declarative hooks, schemas, README/license, and assets.
+- User/workspace/builtin plugin stores and source-qualified identity: `user:<id>`, `project:<id>`, `builtin:<id>`.
+- Explicit discovery-vs-enablement separation.
+- Store presence under `${XDG_DATA_HOME:-~/.local/share}/yoi/plugins/` or `<workspace>/.yoi/plugins/` is discovery only, never registration/execution.
+- Plugin permission declarations are requests, not grants.
+- Plugin permission policy is explicitly separate from `pod::feature` HostAuthority/grant concepts.
+- Archive validation, traversal rejection, bounded extraction, deterministic digest, digest-keyed cache materialization, and optional pin/lock behavior.
+- Restore uses resolved enabled-plugin plan/digest metadata; fresh discovery must not silently upgrade a restored Pod.
+- Diagnostics guidance without secret leakage.
+- Runtime notes for declarative hooks and WASM.
+- MCP is explicitly out of initial Plugin packaging/runtime and requires a future separate bridge Ticket.
+- Follow-up implementation cuts are listed for enablement schema, discovery, validation/cache, permission policy, declarative hooks, WASM, locks, and future MCP bridge.
+
+Validation reported by coder:
+- Passed: `git diff --check`.
+- Link/path sanity review:
+  - Verified `docs/README.md` references existing `docs/design/plugin-packages.md`.
+  - Verified touched Markdown files have trailing newlines and no tab characters.
+- Post-commit check:
+  - `git status --short --branch` showed clean branch `impl/00001KT0Z4BK8-plugin-package-discovery`.
+  - `git diff --check HEAD~1 HEAD` passed with no whitespace errors.
+- No Rust/code changes were made, so `cargo fmt` / `cargo test` were not run.
+
+Repository status:
+- Child implementation worktree clean after commit.
+
+Residual risks / blockers:
+- This is intentionally a design proposal only. Exact manifest/Profile schema, lock-file format, archive limits, cache path, and WASM ABI details remain for follow-up implementation Tickets.
+
+---
+
+<!-- event: review author: yoi-reviewer-00001KT0Z4BK8 at: 2026-06-14T15:56:22Z status: approve -->
+
+## Review: approve
+
+Review result: approve
+
+Evidence checked:
+- Child worktree/branch:
+  - `/home/hare/Projects/yoi/.worktree/00001KT0Z4BK8-plugin-package-discovery`
+  - `impl/00001KT0Z4BK8-plugin-package-discovery`
+- HEAD: `3c674a70512ca31b5745d901959c04442c1695d0`
+- Base merge point: `d73f748ee8d2e25217cafe3754eb9fa8870ddbed`
+- Diff `d73f748e..HEAD` inspected:
+  - added `docs/design/plugin-packages.md`
+  - updated `docs/README.md`
+- Ticket intent/acceptance context reviewed from the child worktree Ticket record.
+
+Acceptance criteria review:
+- `.yoi-plugin` archive structure and required root `plugin.toml` are documented.
+- Packaged assets/layout are covered, including optional WASM module, hooks, schemas, README/license, and `assets/**`.
+- Stores and source/trust mapping are covered for `builtin:<id>`, `user:<id>`, and `project:<id>`.
+- Package presence in user/workspace stores is clearly discovery only, not execution/registration.
+- Source-qualified identity, ambiguous-id fail-closed behavior, and collision handling are covered.
+- Discovery vs enablement and restore/no-silent-upgrade behavior are explicit.
+- Manifest/Profile enablement shape is illustrative and appropriately deferred.
+- Plugin permission declarations are requests, not grants; effective grants are tied to Plugin-layer policy plus existing manifest/profile/tool/scope/web/secret/runtime authority layers.
+- The document avoids using `pod::feature` HostAuthority/grant concepts as Plugin permission/security model.
+- Archive safety covers traversal rejection, unsafe file types, bounded extraction, deterministic digest, digest-keyed cache, and manifest path validation.
+- Diagnostics guidance covers attribution, bounded output, and no secret leakage.
+- Runtime notes cover declarative hooks, WASM initialization from digest cache, host limits, and ToolRegistry/permission checks.
+- MCP is explicitly separate and out of the initial Plugin package runtime.
+- Follow-up implementation cuts are clear and separable.
+- `docs/README.md` cross-reference is appropriate and remains Why/design-oriented.
+
+Validation performed:
+- Passed: `git diff --check d73f748e..HEAD`
+- Passed: `git diff --check HEAD~1 HEAD`
+- README-listed relative doc target existence checked with shell commands.
+- Manual Markdown/design boundary review completed.
+
+Validation not run:
+- No cargo commands because the change is documentation-only.
+- A Python-based link check could not run because `python3` is unavailable; shell existence checks were used instead.
+
+Conclusion:
+- Approved. No blocking concern remains.
+
+---
+
+<!-- event: implementation_report author: yoi-orchestrator at: 2026-06-14T15:56:45Z -->
+
+## Implementation report
+
+Integration report:
+
+Merged implementation branch into orchestration branch:
+- branch: `impl/00001KT0Z4BK8-plugin-package-discovery`
+- implementation commit: `3c674a70 docs: propose plugin package distribution`
+- merge commit: `2b9dae48 merge: plugin package design`
+
+Reviewer result:
+- `approve` recorded from `yoi-reviewer-00001KT0Z4BK8`.
+
+Validation in Orchestrator worktree `/home/hare/Projects/yoi/.worktree/orchestration`:
+- Passed: `git diff --check`
+- Passed: `test -f docs/design/plugin-packages.md`
+- Passed: `grep -n 'plugin-packages.md' docs/README.md`
+
+Cargo validation:
+- Not run because the merged change is documentation-only.
+
+Notes:
+- The proposal is intentionally design-only. Exact manifest/Profile schema, lock-file format, archive limits, cache path, and WASM ABI remain follow-up implementation work.
+- Orchestrator worktree is clean after validation.
+
+Cleanup planned:
+- Stop related coder/reviewer Pods.
+- Remove only child implementation worktree/branch for this Ticket.
+
+---
+
+<!-- event: state_changed author: yoi-orchestrator at: 2026-06-14T15:56:45Z from: inprogress to: done reason: merged_validated field: state -->
+
+## State changed
+
+Reviewer approved, documentation/design implementation branch merged into the orchestration branch, and documentation-focused validation passed in the Orchestrator worktree. Marking Ticket done in the orchestration branch.
+
+---
+
+<!-- event: state_changed author: hare at: 2026-06-15T06:33:50Z from: done to: closed reason: closed field: state -->
+
+## State changed
+
+Ticket を closed にしました。
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-15T06:33:50Z status: closed -->
+
+## 完了
+
+Ticket `00001KT0Z4BK8` (`Plugin distribution package format and discovery`) はすでに `state: done` に到達していたため、workspace Panel から close しました。
+
+この Close action によって、実装作業、state 変更、Orchestrator/Companion launch、worker invocation は開始されていません。
+
+
 ---

.yoi/tickets/00001KT1JZBX8/item.md

@@ -1,8 +1,8 @@
 ---
 title: "Audit external dependencies and license posture"
-state: "planning"
+state: 'closed'
 created_at: "2026-06-01T12:36:41Z"
-updated_at: "2026-06-01T13:08:45Z"
+updated_at: '2026-06-20T16:45:54Z'
 ---
 
 ## Background

.yoi/tickets/00001KT1JZBX8/resolution.md

@@ -0,0 +1 @@
+Closed as completed. The dependency/license audit was already performed and recorded in artifacts/audit-report.md with implementation report evidence; any dependency cleanup or third-party notice work should be tracked by narrower follow-up tickets.

.yoi/tickets/00001KT1JZBX8/thread.md

@@ -418,4 +418,22 @@ Interpretation:
    - Acceptance: compare current `html5ever`/`RcDom` extractor with viable maintained alternatives; preserve bounded, safe, link-aware extraction behavior; only proceed if measurable binary/build-time benefit exists.
 
 
+---
+
+<!-- event: state_changed author: hare at: 2026-06-20T16:45:54Z from: planning to: closed reason: closed field: state -->
+
+## State changed
+
+Ticket を closed にしました。
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-20T16:45:54Z status: closed -->
+
+## 完了
+
+Closed as completed. The dependency/license audit was already performed and recorded in artifacts/audit-report.md with implementation report evidence; any dependency cleanup or third-party notice work should be tracked by narrower follow-up tickets.
+
+
 ---

.yoi/tickets/00001KTFQ109S/item.md

@@ -1,8 +1,8 @@
 ---
 title: "Workspace panel Companion interface"
-state: "planning"
+state: 'closed'
 created_at: "2026-06-07T00:16:51Z"
-updated_at: "2026-06-07T03:13:01Z"
+updated_at: '2026-06-18T13:06:31Z'
 ---
 
 ## Background

.yoi/tickets/00001KTFQ109S/resolution.md

@@ -0,0 +1,10 @@
+Closed as completed by child Tickets.
+
+The original Workspace Panel Companion interface plan has been implemented through more specific work:
+- direct selected-Pod send was removed from the Panel composer path;
+- Panel composer routing now targets the workspace Companion and Ticket Intake explicitly;
+- workspace Companion Pod lifecycle restore/spawn/observe behavior is implemented;
+- local role/session registry and Ticket claim handling were added for Panel-launched role sessions;
+- project role Profile feature defaults limit Companion authority and keep Ticket orchestration / Pods / Task disabled for Companion by default.
+
+The remaining work in this area should be tracked as targeted follow-up Tickets rather than keeping this umbrella planning Ticket open.

.yoi/tickets/00001KTFQ109S/thread.md

@@ -74,4 +74,31 @@ Companion work is useful but not required for near-term panel operation. The pan
 
 Decision: downgrade Companion-related follow-up priority to P2 so near-term focus can stay on Ticket role config strictness/init, Orchestrator queue automation, and workflow/compaction reliability.
 
+---
+
+<!-- event: state_changed author: hare at: 2026-06-18T13:06:31Z from: planning to: closed reason: closed field: state -->
+
+## State changed
+
+Ticket を closed にしました。
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-18T13:06:31Z status: closed -->
+
+## 完了
+
+Closed as completed by child Tickets.
+
+The original Workspace Panel Companion interface plan has been implemented through more specific work:
+- direct selected-Pod send was removed from the Panel composer path;
+- Panel composer routing now targets the workspace Companion and Ticket Intake explicitly;
+- workspace Companion Pod lifecycle restore/spawn/observe behavior is implemented;
+- local role/session registry and Ticket claim handling were added for Panel-launched role sessions;
+- project role Profile feature defaults limit Companion authority and keep Ticket orchestration / Pods / Task disabled for Companion by default.
+
+The remaining work in this area should be tracked as targeted follow-up Tickets rather than keeping this umbrella planning Ticket open.
+
+
 ---

.yoi/tickets/00001KTFY8V80/artifacts/orchestration-plan.jsonl

@@ -0,0 +1 @@
+{"id":"orch-plan-20260614-152451-1","ticket_id":"00001KTFY8V80","kind":"accepted_plan","accepted_plan":{"summary":"Start implementation for active workflow preservation across compaction in a dedicated child worktree. Keep workflow-state/prompt-context authority boundaries as reviewer focus.","branch":"impl/00001KTFY8V80-active-workflows-compaction","worktree":"/home/hare/Projects/yoi/.worktree/00001KTFY8V80-active-workflows-compaction","role_plan":"Orchestrator creates child implementation worktree, spawns sibling Coder with write scope limited to that worktree, then spawns Reviewer read-only against the same worktree after implementation report. Orchestrator integrates approved branch into orchestration branch and validates in orchestration worktree only."},"author":"yoi-orchestrator","at":"2026-06-14T15:24:51Z"}

.yoi/tickets/00001KTFY8V80/item.md

@@ -1,8 +1,10 @@
 ---
 title: "Preserve active workflows across compaction"
-state: "planning"
+state: 'closed'
 created_at: "2026-06-07T02:23:28Z"
-updated_at: "2026-06-07T02:23:28Z"
+updated_at: '2026-06-15T06:33:44Z'
+queued_by: 'workspace-panel'
+queued_at: '2026-06-14T15:23:07Z'
 ---
 
 ## Background

.yoi/tickets/00001KTFY8V80/resolution.md

@@ -0,0 +1,3 @@
+Ticket `00001KTFY8V80` (`Preserve active workflows across compaction`) はすでに `state: done` に到達していたため、workspace Panel から close しました。
+
+この Close action によって、実装作業、state 変更、Orchestrator/Companion launch、worker invocation は開始されていません。

.yoi/tickets/00001KTFY8V80/thread.md

@@ -4,4 +4,434 @@
 
 Created by LocalTicketBackend create.
 
+---
+
+<!-- event: comment author: ticket-intake at: 2026-06-14T14:13:35Z -->
+
+## Comment
+
+## Intake refinement
+
+既存 Ticket `00001KTFY8V80` を確認した。新規 duplicate Ticket は作成しない。
+
+### Readiness
+
+- readiness: implementation_ready
+- risk_flags: [prompt-context, persistence, workflow-state, compaction]
+
+この Ticket は、active workflow を compaction / rehydration 後も継続可能にする concrete work item として十分に bounded されている。実装戦術の調査余地は残るが、Orchestrator が implementation routing できる要件・受け入れ条件・検証観点は揃っている。
+
+### Binding decisions / invariants
+
+- active workflow の進行中状態を、history に残らない transient context 注入だけで復元してはならない。
+- compaction / restore 後に「どの workflow が継続中か」「どの手順段階・義務が残っているか」をモデルが説明可能でなければならない。
+- workflow state の復元は、prompt context 加工原則に反しない形で durable source から再構成する。
+- missing / corrupt / obsolete workflow state は fail-closed または bounded diagnostic として扱い、silently stale instructions を実行しない。
+- Ticket / Pod history / workflow record / compaction output の authority boundary を混同しない。
+
+### Implementation latitude
+
+- workflow state の永続化先・schema・snapshot 粒度は、既存 Pod/session/compaction architecture に合わせて選んでよい。
+- active workflow body を invocation-time snapshot として保持するか、rehydration 時に最新 resource を参照するかは、実装時に明示的に決定し、互換性・安全性の理由をコードまたは docs / Ticket 報告に残す。
+- UI/diagnostic 表示の具体的な文言や internal field 名は、既存設計に沿って調整してよい。
+
+### Escalation conditions
+
+- workflow snapshot vs latest body の選択が authority boundary または backward compatibility を大きく変える場合。
+- compaction が workflow obligations を再現するために hidden context injection を必要としそうな場合。
+- persisted workflow state の migration / compatibility 方針が既存 records を破壊する場合。
+- implementation が Ticket lifecycle / Orchestrator queue semantics / workflow invocation semantics を広げる必要を見つけた場合。
+
+### Related context checked
+
+- closed `00001KTG3AZQ8` / `00001KTG3BX0R` は Orchestrator routing / merge completion の完了済み関連文脈であり、本 Ticket の duplicate ではない。
+
+---
+
+<!-- event: intake_summary author: ticket-intake at: 2026-06-14T14:13:43Z -->
+
+## Intake summary
+
+既存 Ticket `00001KTFY8V80` を精査し、duplicate は作成しない方針で refinement を記録した。対象は active Workflow invocation/state/obligations を durable state/history と compaction/rehydration 経路に載せ、compaction 後も `/multi-agent-workflow` / `/worktree-workflow` などの active obligations を traceable に継続できるようにする実装 work item。readiness は implementation_ready。risk flags は prompt-context / persistence / workflow-state / compaction。Orchestrator は implementation routing 可能だが、snapshot vs latest workflow body の選択、hidden context injection 回避、missing/corrupt persisted state の fail-closed diagnostic、Ticket/Pod/history/workflow authority boundary を reviewer focus に含める。
+
+---
+
+<!-- event: state_changed author: ticket-intake at: 2026-06-14T14:13:43Z from: planning to: ready reason: intake_ready field: state -->
+
+## State changed
+
+Intake refinement が完了し、要件・受け入れ条件・binding invariants・escalation conditions が Ticket thread に記録されたため `planning -> ready` にします。実装 side effects は Orchestrator routing 後に行います。
+
+---
+
+<!-- event: state_changed author: workspace-panel at: 2026-06-14T15:23:07Z from: ready to: queued reason: queued field: state -->
+
+## State changed
+
+Ticket を `workspace-panel` が queued にしました。
+
+
+---
+
+<!-- event: decision author: yoi-orchestrator at: 2026-06-14T15:24:40Z -->
+
+## Decision
+
+Routing decision: implementation_ready
+
+Reason:
+- Panel Queue により routing が明示的に許可され、Ticket は `queued`。
+- 要件、受け入れ条件、binding invariants、implementation latitude、escalation conditions が Ticket body/thread に揃っている。
+- active Workflow invocation/state/obligations を durable history/state と compaction/rehydration 経路に載せる目的は concrete で、残る不確実性は既存 Pod/session/compaction architecture 内の実装戦術選択に閉じている。
+
+Evidence checked:
+- Ticket body / thread / artifacts: artifacts なし、Intake refinement と `planning -> ready`、Panel `ready -> queued` を確認。
+- Ticket relations: blocking relation なし。
+- OrchestrationPlan records: 既存 record なし。
+- Orchestrator workspace state: `/home/hare/Projects/yoi/.worktree/orchestration` は clean、queue commit `d311fe8f` 上。
+- Visible Pods: spawned child なし。
+- Bounded code map: workflow / compaction 関連は `crates/pod/src/compact/*`, `crates/pod/src/workflow/*`, `crates/pod/src/prompt/*`, `crates/session-store/src/*`, `crates/protocol/src/lib.rs`, `resources/workflows/*` が候補。
+
+IntentPacket:
+
+Intent:
+- compaction を跨ぐ長時間 workflow-governed task で、active workflow と残る operational obligations が失われないようにする。
+
+Binding decisions / invariants:
+- Workflow instructions を、history/state に残らない turn-local transient context だけを根拠に model context へ注入しない。
+- post-compaction context は「available workflow」と「この task で active な workflow obligations」を区別する。
+- missing / corrupt / obsolete active workflow state は silent stale instruction ではなく fail-closed または bounded diagnostic にする。
+- Ticket / Pod history / workflow record / compaction output の authority boundary を混同しない。
+- active workflow state は workflow-governed task の完了または explicit cancellation で clear / completed にできる必要がある。
+
+Requirements / acceptance criteria:
+- active workflow の slug、invocation source/time、task/scope、active/completed、current obligations/checkpoints を durable typed history/state として表現する。
+- compaction が active workflow state を明示的に carry forward する。
+- rehydration が durable source から active workflow guidance を復元できる。
+- snapshot vs latest workflow body の選択を実装報告または docs/code に明示する。
+- focused coverage に、review delegation と merge/close handling の間で compaction が起きる worktree/multi-agent style flow を含める。
+
+Implementation latitude:
+- 永続化先、schema、snapshot 粒度、diagnostic 表現は既存 Pod/session/compaction architecture に合わせて選んでよい。
+- local tactic 調査は coder に委ねるが、authority boundary を広げる必要があれば escalate する。
+
+Escalate if:
+- workflow snapshot vs latest body の選択が authority boundary や backward compatibility を大きく変える。
+- compaction 復元が hidden context injection を必要としそうになる。
+- persisted workflow state migration / compatibility が既存 records を破壊しそうになる。
+- Ticket lifecycle / Orchestrator queue semantics / workflow invocation semantics を広げる必要が出る。
+
+Validation:
+- 変更箇所に応じて `cargo test` / `cargo check` の focused subset。
+- 少なくとも workflow/compaction 関連 unit coverage、`cargo fmt --check`、`git diff --check`。
+
+Current code map:
+- Primary candidates: `crates/pod/src/compact/*`, `crates/pod/src/workflow/*`, `crates/pod/src/prompt/*`, `crates/session-store/src/*`, `crates/protocol/src/lib.rs`。
+- Workflow resources: `resources/workflows/*`。
+
+Critical risks / reviewer focus:
+- hidden context injection 回避。
+- active vs advertised workflow の明確な区別。
+- stale workflow obligations の漏れ込み防止。
+- persisted state の compatibility / corrupt-state diagnostics。
+- compaction 後の traceability と test coverage。
+
+---
+
+<!-- event: state_changed author: yoi-orchestrator at: 2026-06-14T15:24:58Z from: queued to: inprogress reason: orchestrator_acceptance field: state -->
+
+## State changed
+
+Routing decision と accepted implementation plan を記録済み。blocking relation / orchestration-plan blocker はなく、Orchestrator workspace は clean。implementation side effects の前に `queued -> inprogress` acceptance を記録する。
+
+---
+
+<!-- event: implementation_report author: yoi-coder-00001KTFY8V80 at: 2026-06-14T15:50:38Z -->
+
+## Implementation report
+
+Implementation report from Coder Pod `yoi-coder-00001KTFY8V80`:
+
+Commit:
+- `362fedfb fix: preserve active workflows across compaction`
+
+Changed files:
+- `crates/pod/src/active_workflow.rs`
+- `crates/pod/src/lib.rs`
+- `crates/pod/src/pod.rs`
+- `crates/pod/src/segment_log_sink.rs`
+- `resources/prompts/internal/compact_system.md`
+
+Implemented behavior:
+- Added durable typed active workflow state as session-log extension domain `pod.active_workflows`.
+- State records include:
+  - workflow slug
+  - invocation source/time
+  - task scope
+  - active/completed/cancelled status
+  - snapshotted workflow guidance
+  - extracted obligations/checkpoints
+  - completion/cancellation reason/time
+- Workflow bodies are snapshotted at invocation time rather than resolved to latest resource/builtin version during rehydration. Rationale: active workflow authority remains traceable to the original governed task and does not silently change when resource files change later.
+- Compaction now:
+  - feeds active workflow state into compact worker input
+  - writes active workflow state into the replacement segment as typed extension state
+  - injects post-compaction workflow guidance into `SegmentStart.history` from durable state, not transient turn-local data
+- Added `ActiveWorkflowList`, `ActiveWorkflowComplete`, and `ActiveWorkflowCancel` tools so active workflow state can be inspected, completed, or explicitly cancelled.
+- Missing/corrupt/unsupported active workflow extension state fails closed with bounded diagnostics rather than reusing stale prior state.
+
+Validation reported by coder:
+- Passed: `cargo fmt --check`
+- Passed: `git diff --check`
+- Passed: `cargo test -p pod active_workflow --lib`
+  - includes focused coverage for review/merge/close-style obligations crossing compaction/rehydration
+- Passed: `cargo test -p pod includes_active_workflow_snapshot_section --lib`
+- Ran: `cargo test -p pod --lib`
+  - Failed on 2 prompt text assertions reported as unrelated/pre-existing:
+    - `prompt::catalog::tests::pod_orchestration_guidance_section_renders_resource_body`
+    - `prompt::system::tests::pod_orchestration_guidance_is_included_for_pod_management_tools`
+    - both assert the unrelated string `worktree status, diff, and test results`
+
+Repository status:
+- Child implementation worktree clean after commit.
+
+Residual risks / notes:
+- Active workflow obligation extraction is intentionally conservative: it stores full snapshotted guidance as authority and derives bounded checkpoint labels from obligation-like lines.
+- Completion/cancellation tool calls persist through normal history; compaction additionally writes updated typed snapshot into the compacted segment.
+
+---
+
+<!-- event: review author: yoi-reviewer-00001KTFY8V80 at: 2026-06-14T15:58:49Z status: request_changes -->
+
+## Review: request changes
+
+Review result: request_changes
+
+Evidence checked:
+- Child worktree/branch/head:
+  - `/home/hare/Projects/yoi/.worktree/00001KTFY8V80-active-workflows-compaction`
+  - `impl/00001KTFY8V80-active-workflows-compaction`
+  - HEAD `362fedfbe6689886f1e2e7c29da61e39b0ce1e38`
+  - merge base with requested base: `73d0a6a4`
+- `git status --short` was clean.
+- Diff `73d0a6a4..362fedfb` inspected.
+- Read-only validation:
+  - Passed: `git diff --check 73d0a6a4..362fedfb`
+- Cargo/fmt not rerun because review scope was read-only.
+
+What looks good:
+- A typed active workflow snapshot was added with slug, status, invocation source/time, task scope, snapshot policy, snapshotted guidance, obligations/checkpoints, and completion metadata.
+- Active workflow state is separated from advertised workflows; activation comes from invoked `SystemItem::Workflow` rather than resident workflow catalog.
+- Snapshot-vs-latest behavior is explicit via `WorkflowBodySnapshotPolicy::SnapshottedAtInvocation`.
+- Compaction passes active workflow state into compactor input and writes typed `LogEntry::Extension` into the compacted segment.
+- Clear/cancel tools are exposed as `ActiveWorkflowComplete` / `ActiveWorkflowCancel`.
+
+Required changes:
+
+1. Stale active workflow guidance can remain in prompt history after typed state is invalid, completed, or cancelled.
+
+- The implementation writes active workflow rehydration guidance as an ordinary system message in compacted history (`pod.rs` around the compaction replacement history construction).
+- Restore later uses `SegmentStart.history` as worker history.
+- Corrupt/obsolete extension handling drops/diagnoses the typed state but does not remove the old `[Active workflow snapshot]` system message from compacted history.
+- Therefore the model can still see stale workflow obligations even when the durable active-workflow extension is missing/corrupt/obsolete.
+- The same leakage risk applies after completion/cancellation: old compacted system messages can remain until another compaction.
+
+Required fix:
+- Ensure active workflow guidance shown to the model is gated by currently valid active workflow state, not immutable old compacted history.
+- For example, regenerate guidance from validated typed state at context/compaction time, or sanitize/supersede old active workflow system messages when typed state is invalid/inactive.
+- Add focused coverage for compacted history containing an active workflow message plus missing/corrupt/obsolete extension, and for completion/cancellation after compaction.
+
+2. Completion/cancellation durability is inferred from generic tool-call history and trusts bare `ToolCall`s.
+
+- `ActiveWorkflowComplete` / `ActiveWorkflowCancel` mutate only the in-memory store in the tool implementation.
+- They do not append a new typed `LogEntry::Extension` on successful status change.
+- Restore reconstructs completion/cancellation by scanning history.
+- Replay marks workflows completed/cancelled based solely on `Item::ToolCall` names, without requiring a matching successful `ToolResult`.
+
+Required fix:
+- Persist status changes as typed durable active workflow state when the status tool succeeds, or make replay validate a matching non-error tool result/event proving the tool executed successfully.
+- Add focused tests for interrupted/unmatched/error status tool calls.
+
+Prompt-test failure assessment:
+- The reported `cargo test -p pod --lib` failures about `worktree status, diff, and test results` appear unrelated. The diff changes `resources/prompts/internal/compact_system.md`, while the failing assertions are in pod orchestration prompt tests and reference a different prompt resource.
+
+Conclusion:
+- Changes requested. Do not integrate until stale-guidance gating and completion/cancellation durability are fixed and covered.
+
+---
+
+<!-- event: implementation_report author: yoi-coder-00001KTFY8V80 at: 2026-06-14T16:17:48Z -->
+
+## Implementation report
+
+Follow-up implementation report after reviewer request_changes:
+
+New commit:
+- `ff446052 fix: gate active workflow rehydration state`
+
+Changed files in follow-up:
+- `crates/pod/src/active_workflow.rs`
+- `crates/pod/src/ipc/interceptor.rs`
+- `crates/pod/src/pod.rs`
+
+Review blocker 1 resolved: stale active workflow guidance in prompt history
+- Active workflow rehydration guidance is no longer persisted into compacted `SegmentStart.history` as an ordinary system message.
+- Compaction still carries active workflow state forward via typed `pod.active_workflows` extension state.
+- Request context is sanitized before model calls:
+  - stale `[Active workflow snapshot]` system messages are stripped,
+  - current active workflow guidance is regenerated request-locally from validated typed state,
+  - when typed state is missing/corrupt/obsolete/inactive and stale workflow hints are present, a bounded inactive-state message supersedes old compacted references.
+- Restore paths strip stale active workflow rehydration messages before installing worker history.
+- Compaction source/retained histories strip old active workflow rehydration messages so old snapshots are not re-summarized as active authority.
+
+Review blocker 2 resolved: completion/cancellation durability
+- `ActiveWorkflowComplete` / `ActiveWorkflowCancel` now persist successful status changes by committing a new typed `LogEntry::Extension` snapshot through the session log writer.
+- Restore no longer infers completion/cancellation from bare `Item::ToolCall` history.
+- Typed extension state is the authority, avoiding trust in unmatched/interrupted/error tool calls.
+
+Focused coverage added/updated:
+- Compacted history containing active workflow rehydration message plus:
+  - missing extension,
+  - corrupt extension,
+  - obsolete extension.
+- Completion/cancellation after compaction suppressing old compacted guidance.
+- Successful status tool writes a typed durable extension.
+- Unmatched/error status tool calls do not mutate restored active workflow state.
+- Existing review/merge/close workflow obligation coverage still passes.
+
+Validation reported by coder:
+- Passed: `cargo fmt --check`
+- Passed: `git diff --check`
+- Passed: `cargo test -p pod active_workflow --lib`
+  - 7 passed
+- Passed: `cargo test -p pod interceptor --lib`
+  - 19 passed
+- Ran: `cargo test -p pod --lib`
+  - Still fails only on the previously reported unrelated prompt assertion failures:
+    - `prompt::catalog::tests::pod_orchestration_guidance_section_renders_resource_body`
+    - `prompt::system::tests::pod_orchestration_guidance_is_included_for_pod_management_tools`
+    - both assert missing text: `worktree status, diff, and test results`
+    - result: `332 passed; 2 failed`
+
+Repository status:
+- Child implementation worktree clean after follow-up commit.
+
+---
+
+<!-- event: review author: yoi-reviewer-00001KTFY8V80-r2 at: 2026-06-14T16:25:00Z status: approve -->
+
+## Review: approve
+
+Review result: approve
+
+Evidence checked:
+- Child worktree:
+  - `/home/hare/Projects/yoi/.worktree/00001KTFY8V80-active-workflows-compaction`
+- HEAD: `ff446052 fix: gate active workflow rehydration state`
+- Base checked against: `73d0a6a4`
+- Original implementation checked where relevant: `362fedfb`
+
+Prior blocker 1: stale active workflow guidance after compaction
+- Resolved.
+- Active workflow rehydration is now derived from typed `LogEntry::Extension` state via `ActiveWorkflowStore`, not from ordinary prompt/tool-call history.
+- Restore strips prior `[Active workflow snapshot]` system messages before installing history.
+- Rehydration guidance is regenerated request-time from validated active typed state.
+- Missing/corrupt/unsupported extension state fails closed: no active workflow restored, stale rehydration messages stripped, and bounded inactive diagnostic text tells the model not to treat older compacted history/summaries as active workflow authority.
+- Completed/cancelled typed state does not regenerate active guidance.
+- Compaction no longer stores active workflow guidance directly in `SegmentStart.history` as ordinary durable prompt authority; it carries typed extension entries.
+- Focused coverage exists for stale active workflow message plus missing/corrupt/unsupported state and completion/cancellation after compaction.
+
+Prior blocker 2: completion/cancellation durability
+- Resolved.
+- `ActiveWorkflowComplete` / `ActiveWorkflowCancel` mutate store status and commit a fresh typed `LogEntry::Extension` snapshot through the active workflow log committer.
+- Production controller wiring attaches the log writer before feature/tool registration, so status tools have durable commit plumbing.
+- Restore no longer trusts bare unmatched `Item::ToolCall` entries or failed/error calls to infer completed/cancelled state.
+- Focused tests cover unmatched/error status tool calls and explicit completed/cancelled typed extension suppression of active guidance.
+
+Overall acceptance:
+- Durable typed active workflow representation exists.
+- Compaction carries active workflow state forward through typed extension state.
+- Rehydration restores guidance from durable validated state.
+- Snapshot-vs-latest policy is explicit and fail-closed on missing/corrupt/unsupported latest state.
+- No hidden context injection from non-durable transient data was found.
+- Active vs advertised workflow separation is preserved.
+- Clear/cancel/complete behavior is durable typed-state transition.
+
+Validation performed by reviewer:
+- Passed: `git diff --check 73d0a6a4..HEAD`
+- Passed: `cargo fmt --check`
+- `git status --short` remained clean.
+
+Validation not rerun by reviewer:
+- Cargo tests were not rerun because review scope was read-only and tests write build artifacts. Coder-reported focused test results were inspected as evidence.
+
+Full-suite prompt failure assessment:
+- The remaining reported `cargo test -p pod --lib` prompt assertion failures involving `worktree status, diff, and test results` appear unrelated to the active workflow typed-state/compaction changes.
+
+Conclusion:
+- Approved. No remaining blocker found.
+
+---
+
+<!-- event: implementation_report author: yoi-orchestrator at: 2026-06-14T16:26:01Z -->
+
+## Implementation report
+
+Integration report:
+
+Merged implementation branch into orchestration branch:
+- branch: `impl/00001KTFY8V80-active-workflows-compaction`
+- implementation commits:
+  - `362fedfb fix: preserve active workflows across compaction`
+  - `ff446052 fix: gate active workflow rehydration state`
+- merge commit: `64d26f84 merge: preserve active workflows across compaction`
+
+Reviewer result:
+- First review requested changes for stale prompt-history guidance and completion/cancellation durability.
+- Second-pass review `approve` recorded from `yoi-reviewer-00001KTFY8V80-r2`.
+
+Validation in Orchestrator worktree `/home/hare/Projects/yoi/.worktree/orchestration`:
+- Passed: `cargo test -p pod active_workflow --lib`
+  - 7 passed
+- Passed: `cargo test -p pod interceptor --lib`
+  - 19 passed
+- Passed: `cargo fmt --check`
+- Passed: `git diff --check`
+
+Notes:
+- Full `cargo test -p pod --lib` was not rerun at integration because coder already reported only the known unrelated prompt assertion failures. Focused tests and reviewer inspection covered the changed active workflow/compaction/interceptor paths.
+- Orchestrator worktree is clean after validation.
+
+Cleanup planned:
+- Stop related coder/reviewer Pods.
+- Remove only child implementation worktree/branch for this Ticket.
+
+---
+
+<!-- event: state_changed author: yoi-orchestrator at: 2026-06-14T16:26:01Z from: inprogress to: done reason: merged_validated field: state -->
+
+## State changed
+
+Reviewer approved after requested fixes, implementation branch merged into the orchestration branch, and focused validation passed in the Orchestrator worktree. Marking Ticket done in the orchestration branch.
+
+---
+
+<!-- event: state_changed author: hare at: 2026-06-15T06:33:44Z from: done to: closed reason: closed field: state -->
+
+## State changed
+
+Ticket を closed にしました。
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-15T06:33:44Z status: closed -->
+
+## 完了
+
+Ticket `00001KTFY8V80` (`Preserve active workflows across compaction`) はすでに `state: done` に到達していたため、workspace Panel から close しました。
+
+この Close action によって、実装作業、state 変更、Orchestrator/Companion launch、worker invocation は開始されていません。
+
+
 ---

.yoi/tickets/00001KTGG00N8/item.md

@@ -1,8 +1,8 @@
 ---
 title: "Improve Pod notification injection guidance"
-state: "planning"
+state: 'closed'
 created_at: "2026-06-07T07:33:13Z"
-updated_at: "2026-06-07T07:33:13Z"
+updated_at: '2026-06-20T16:23:37Z'
 ---
 
 ## Background

.yoi/tickets/00001KTGG00N8/resolution.md

@@ -0,0 +1 @@
+Closed as stale/currently not needed. Orchestrator role/profile/workflow notification guidance has since improved, and the broad planning issue is not currently reproducing. If similar notification-as-user-turn confusion recurs in default profiles or generic notification wrappers, create a narrower ticket against the current prompt/profile state.

.yoi/tickets/00001KTGG00N8/thread.md

@@ -4,4 +4,39 @@
 
 Created by LocalTicketBackend create.
 
+---
+
+<!-- event: decision author: intake at: 2026-06-20T16:20:17Z -->
+
+## Decision
+
+ユーザー判断により、この Ticket は一旦 close 推奨とする。
+
+理由:
+- Ticket 作成後に Orchestrator profile / role prompt / workflow guidance の改善が複数回入っている。
+- 現在の明示的な Orchestrator role では、通知を user request と誤認しているケースを最近見かけていない。
+- default profile では同種の誤認がまだ起き得る可能性はあるが、現時点でこの broad な planning Ticket を残しておくほどの実害・優先度は確認されていない。
+
+判断:
+- この Ticket は stale / currently not needed として close してよい。
+- 将来 default profile や generic notify_wrapper で同じ問題が再発した場合は、現在の prompt/profile 状態を前提に、より狭い concrete Ticket として切り直す。
+
+---
+
+<!-- event: state_changed author: hare at: 2026-06-20T16:23:37Z from: planning to: closed reason: closed field: state -->
+
+## State changed
+
+Ticket を closed にしました。
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-20T16:23:37Z status: closed -->
+
+## 完了
+
+Closed as stale/currently not needed. Orchestrator role/profile/workflow notification guidance has since improved, and the broad planning issue is not currently reproducing. If similar notification-as-user-turn confusion recurs in default profiles or generic notification wrappers, create a narrower ticket against the current prompt/profile state.
+
+
 ---

.yoi/tickets/00001KTJ42528/item.md

@@ -1,8 +1,8 @@
 ---
 title: "Ticket lifecycle commit noise を減らし commit / publication policy を一本化する"
-state: "planning"
+state: 'closed'
 created_at: "2026-06-07T22:43:09Z"
-updated_at: "2026-06-11T05:45:00Z"
+updated_at: '2026-06-18T12:22:10Z'
 ---
 
 ## 背景

.yoi/tickets/00001KTJ42528/resolution.md

@@ -0,0 +1,11 @@
+Closed as resolved by current dogfooding workflow rather than a new broad implementation.
+
+The active policy is now operationally established:
+- do not commit one Ticket lifecycle event per Git commit mechanically;
+- batch related Ticket-only updates when they belong to the same decision/work burst;
+- keep implementation/code commits separate from Ticket publication commits unless a merge step requires both;
+- stage only exact Ticket paths and never broad auto-commit unrelated user changes;
+- use orchestration worktree/branch for active progress and publish to the main workspace at explicit merge/close/follow-up boundaries;
+- keep audit evidence in Ticket files/thread/resolution even when Git commits are batched.
+
+Future changes should be filed as targeted Tickets, such as Panel dirty-state UX, workflow prompt wording, or automated queue commit behavior.

.yoi/tickets/00001KTJ42528/thread.md

@@ -4,4 +4,32 @@
 
 Created by LocalTicketBackend create.
 
+---
+
+<!-- event: state_changed author: hare at: 2026-06-18T12:22:10Z from: planning to: closed reason: closed field: state -->
+
+## State changed
+
+Ticket を closed にしました。
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-18T12:22:10Z status: closed -->
+
+## 完了
+
+Closed as resolved by current dogfooding workflow rather than a new broad implementation.
+
+The active policy is now operationally established:
+- do not commit one Ticket lifecycle event per Git commit mechanically;
+- batch related Ticket-only updates when they belong to the same decision/work burst;
+- keep implementation/code commits separate from Ticket publication commits unless a merge step requires both;
+- stage only exact Ticket paths and never broad auto-commit unrelated user changes;
+- use orchestration worktree/branch for active progress and publish to the main workspace at explicit merge/close/follow-up boundaries;
+- keep audit evidence in Ticket files/thread/resolution even when Git commits are batched.
+
+Future changes should be filed as targeted Tickets, such as Panel dirty-state UX, workflow prompt wording, or automated queue commit behavior.
+
+
 ---

.yoi/tickets/00001KTJXS31R/artifacts/orchestration-plan.jsonl

@@ -0,0 +1,2 @@
+{"id":"orch-plan-20260612-145604-1","ticket_id":"00001KTJXS31R","kind":"waiting_capacity_note","note":"Queue review 2026-06-12: leave queued for now because three active in-progress implementation branches are already delegated (`00001KTVJFT6F` Panel focus, `00001KTTW04W2` Companion progress notification, `00001KTVJGC0Y` Ticket language guidance). This Ticket's re-kick / active work-set scope overlaps conceptually and likely in code with Panel lifecycle / Companion progress notification and has duplicate-start / scheduler-boundary risk. Reconsider after at least the Panel/Companion-notify active work is merged or blocked, so implementation can validate active_inprogress suppression against current behavior.","author":"orchestrator","at":"2026-06-12T14:56:04Z"}
+{"id":"orch-plan-20260612-154541-2","ticket_id":"00001KTJXS31R","kind":"accepted_plan","accepted_plan":{"summary":"`queued` Ticket の見落としを防ぐ starvation-prevention layer を実装する。Orchestrator が Idle かつ active_inprogress が導出されない場合だけ bounded work-list attention / re-kick を行い、active coder/reviewer/merge/cleanup 待ち中は queued があるだけでは re-kick しない。session-lifetime work set / role-session claims / visible Pods/worktrees / Ticket state を使い、scheduler・queue drain loop・blind spawn は作らない。","branch":"ticket/orchestrator-idle-queued-rekick","worktree":"/home/hare/Projects/yoi/.worktree/orchestrator-idle-queued-rekick","role_plan":"Coder は child worktree に限定して idle Orchestrator queued work discovery / re-kick policy と session-lifetime active-work suppression を実装し、Panel/lifecycle/Ticket routing 周辺の focused tests を追加する。Reviewer は read-only で、scheduler 化していないこと、`queued -> inprogress` acceptance gate、duplicate-start prevention、active_inprogress suppression、waiting reason visibility、recent Companion progress notification / Panel focus behaviorとの整合を確認する。"},"author":"orchestrator","at":"2026-06-12T15:45:41Z"}

.yoi/tickets/00001KTJXS31R/item.md

@@ -1,127 +1,122 @@
 ---
-title: "Prevent idle starvation in Ticket orchestration planning"
-state: 'ready'
+title: "Orchestrator Idle 時の queued Ticket 見落としを防ぐ"
+state: 'closed'
 created_at: "2026-06-08T06:12:35Z"
-updated_at: '2026-06-09T11:35:29Z'
+updated_at: '2026-06-12T16:12:42Z'
+queued_by: 'workspace-panel'
+queued_at: '2026-06-12T14:49:40Z'
 ---
 
-## Background
+## 背景
 
-The current Panel Queue automation mostly handles the transition-time event:
+現在の Panel Queue automation は、主に次の遷移タイミングのイベントを扱っている。
 
 ```text
 ready -> queued
-  -> notify workspace Orchestrator
+  -> workspace Orchestrator に通知
 ```
 
-That is not enough for robust orchestration. Queued Tickets can remain after missed notifications, Orchestrator restarts, planning returns, capacity limits, or multi-ticket coordination. The Orchestrator also needs a lightweight way to remember planned queued work across turns without relying only on session memory.
+これだけでは、安定した orchestration には足りない。通知漏れ、Orchestrator restore/spawn、planning への差し戻し、capacity 制限、複数 Ticket の調整などにより、`queued` Ticket が残り続けることがある。
 
-There is an existing related Ticket:
+ただし、この Ticket は常時 polling する scheduler を作るものではない。目的は、実行可能な queued work があり、Orchestrator Pod の state が `Idle` で、`active_inprogress` が導出されていないときにだけ、bounded な work set を渡して starvation を防ぐことである。
 
-- `ticket-orchestration-plan-tool`
+## ゴール
 
-That Ticket asks for a TaskStore-like surface for Ticket ordering/dependency/conflict/capacity/accepted-plan records. This Ticket folds that need together with queued-backlog re-kick semantics into a narrower operational requirement:
+Orchestrator が `queued` work を見落とさず、かつ `active_inprogress` が導出されている間に無駄な re-kick を繰り返さないための **session-lifetime work set discovery / re-kick policy** を実装する。
 
-> If runnable queued work exists and the Orchestrator is otherwise idle, the system should not wait indefinitely for another user instruction. The Orchestrator should be kicked with a bounded work set so it can either incorporate new queued work into the plan or start the next planned queued Ticket.
+Orchestrator Pod の state が `Idle` で、進められる work が存在する場合は、bounded attention により次の inspection または acceptance/routing に進める。一方で、implementation side effects は必ず `queued -> inprogress` acceptance の記録後に限定し、blind spawn や duplicate start を起こさない。
 
-This is starvation prevention and explicit work-set planning, not a constant background scheduler loop.
+runtime 側で kick 可能かを見る判定は、Orchestrator Pod の state が `Idle` であることに限定する。re-kick を抑制するかどうかは、session-lifetime work set、role/session claims、visible Pod/worktree state から `active_inprogress` の有無として導出する。
 
-## Goal
+## 現在の前提
 
-Implement an Orchestrator attention/re-kick policy and planning store for active Ticket work: distinguish new queued work from planned queued work and accepted in-progress work, persist the plan, and kick the Orchestrator only when work can progress and no active Orchestrator-managed operation is already being waited on.
+- authoritative な Ticket lifecycle は frontmatter の `state` で表す。
+- `new_queued` / `planned_queued` / `active_inprogress` は新しい core Ticket state ではなく、現在の Ticket `state`、session-lifetime work set、role/session claims、visible Pod/worktree state から導出する分類として扱う。
+- work set は Task と同じく session-lifetime の runtime state として扱い、Ticket ごとの durable artifact log として積まない。
+- work set が失われた場合でも、Ticket `state = queued` から `new_queued` として再検出できればよい。失われた session-level ordering / waiting reason は再 inspection で作り直す。
+- Panel / lifecycle hook は Orchestrator に attention / kick を与えてよいが、unattended scheduler loop や常時 polling にはしない。
+- `queued` は Orchestrator が routing / start-if-unblocked を検討できる状態であり、実装・Pod spawn・worktree 作成などの side effect は `queued -> inprogress` 記録後に限る。
 
-## Planning model
+## Work-set classification
 
-The OrchestrationPlan store should distinguish at least:
+実装上は少なくとも次の区別を導出できるようにする。
 
-- `new_queued`: Tickets with `workflow_state = queued` that have not yet been incorporated into the OrchestrationPlan.
-- `planned_queued`: queued Tickets that the Orchestrator has considered and placed into an explicit plan/order/waiting set, but has not yet accepted as `inprogress`.
-- `inprogress`: Tickets accepted by the Orchestrator and currently awaiting worktree/coder/reviewer/planning-sync/merge/cleanup progress.
+- `new_queued`: Ticket `state = queued` だが、現在の Orchestrator session work set にまだ取り込まれていない Ticket。
+- `planned_queued`: Orchestrator が確認し、session work set の order / waiting set に置いたが、まだ `inprogress` として acceptance していない queued Ticket。
+- `active_inprogress`: Orchestrator が acceptance 済みで、coder/reviewer/planning-sync/merge/cleanup などの delegated step の完了待ちとして記録・観測できる Ticket。
+- `actionable_inprogress`: `inprogress` だが、次の action が delegated step の完了待ちではなく、Orchestrator の routing/判断/記録を必要とする Ticket。
 
-The names do not need to become final public API names, but the state distinction is required.
+この分類の名前は内部実装名として固定しなくてよいが、意味上の区別は必要である。
 
-## Requirements
+## 要件
 
-### Active work set discovery / re-kick
+### Work set discovery / re-kick
 
-- Provide a mechanism to identify Tickets that need Orchestrator attention, including at least:
-  - `workflow_state = queued` Tickets not yet present in the OrchestrationPlan (`new_queued`);
-  - planned queued Tickets that are not blocked/capacity-limited and can be started when there is no active in-progress work;
-  - `workflow_state = inprogress` Tickets accepted by Orchestrator whose next action is not merely waiting for an active coder/reviewer/planning-sync/merge step;
-  - queued Tickets left behind after Orchestrator restart, missed notification, or previous capacity stop.
-- On Panel open/Orchestrator restore/spawn, or explicit user action, surface a bounded work list to the Orchestrator when there is actionable work.
-- Avoid unbounded background polling. Prefer explicit events, Panel lifecycle kick, and explicit user/Orchestrator actions.
-- Prevent duplicate starts: re-kick should prompt inspection/planning or acceptance of the next planned item, not blindly start coder Pods.
+- Orchestrator attention が必要な Ticket を、少なくとも次の情報から導出する。
+  - Ticket frontmatter の `state`。
+  - Orchestrator session-lifetime work set。
+  - role/session claims。
+  - visible Pod/worktree state。
+- Panel open、Orchestrator restore/spawn、明示的な user action などの境界で、actionable work がある場合に bounded work list を Orchestrator へ提示できるようにする。
+- 無制限な background polling は避ける。明示イベント、Panel lifecycle kick、明示 user/Orchestrator action を優先する。
+- duplicate start を防ぐ。re-kick は inspection または次の planned item の acceptance を促すものであり、coder Pod を blind spawn しない。
 
 ### Re-kick / starvation-prevention semantics
 
-- If `new_queued` work exists and the Orchestrator is idle/not occupied by an active in-progress operation, kick or notify the Orchestrator so it can incorporate those Tickets into the plan.
-- If no active `inprogress` work exists and runnable `planned_queued` work exists, kick or notify the Orchestrator so it can accept/start the next planned Ticket rather than waiting indefinitely for user instruction.
-- If active `inprogress` work exists and the next expected event is coder/reviewer/planning-sync/merge completion, do not re-kick merely because queued/planned queued work also exists.
-- If planned queued work is blocked, dependency-waiting, conflict-waiting, or capacity-limited, record the reason so the Panel/user can see why nothing starts.
-- A re-kick is an attention signal plus bounded context, not authority to bypass `queued -> inprogress` acceptance or spawn implementation Pods without inspection.
+- `new_queued` work が存在し、Orchestrator Pod の state が `Idle` の場合、Orchestrator に kick/notify して inspection と session work set への取り込みを促す。
+- `active_inprogress` が導出されず、Orchestrator Pod の state が `Idle` で、unblocked かつ capacity/policy 上開始可能な `planned_queued` work がある場合、Orchestrator に kick/notify して次の Ticket の acceptance/routing に進める。
+- `active_inprogress` が導出されている場合、queued/planned queued work が存在するだけでは re-kick しない。
+- `planned_queued` work を開始しない理由が dependency / conflict / dirty workspace / capacity / human gate 等で説明できる場合は、session work set 上の bounded waiting/blocking reason として保持する。
+- re-kick は attention signal と bounded context であり、`queued -> inprogress` acceptance や inspection を迂回する authority ではない。
 
-### Orchestration plan record
+### Session work set semantics
 
-- Provide or define a TaskStore-like but Ticket-domain planning surface for Orchestrator use.
-- The plan should be scoped to Ticket orchestration and support records such as:
-  - current active target set;
-  - state bucket: `new_queued` / `planned_queued` / `inprogress` or equivalent;
-  - ordering: Ticket A before Ticket B;
-  - dependency/blocker: A blocks B / B blocked by A;
-  - conflict: do not run A and B in parallel;
-  - capacity/waiting notes;
-  - accepted work plan: worktree/branch/coder/reviewer plan;
-  - current next action for each target.
-- Distinguish durable project-relevant routing decisions from local runtime/session claims.
-  - Project-relevant decisions should live in Ticket records/thread/artifacts or a typed Ticket orchestration record under project authority.
-  - Local Pod/session claims remain in the local role session registry.
-- Records should survive compaction and be queryable by Ticket id/slug and relation kind.
-- Keep the first version lightweight; do not implement a full scheduler/graph solver.
+Orchestrator は、意味のある routing 境界で session work set を更新する。
 
-### Plan update semantics
+- new queued work を確認し、session work set に取り込んだとき。
+- `queued -> inprogress` acceptance を記録したとき。
+- `inprogress` Ticket の次の action が delegated step 待ちか、Orchestrator action かを判断したとき。
+- capacity stop により planned queued / waiting と reason を残すとき。
+- merge-ready / done に到達し、`active_inprogress` が導出されなくなったため次の planned queued Ticket を検討するとき。
 
-- The Orchestrator should update the plan at meaningful routing boundaries:
-  - new queued work incorporated into the plan;
-  - queued -> inprogress acceptance;
-  - inprogress -> blocked/waiting/planning/done;
-  - capacity stop -> leave planned queued/waiting with reason;
-  - merge-ready/done -> mark complete and consider the next planned queued Ticket if no active work remains.
-- Each update should produce a bounded, inspectable record of:
-  - what was considered;
-  - what was incorporated into the plan;
-  - what was accepted/started;
-  - what was blocked/deferred/returned to planning;
-  - what remains planned queued/waiting.
-- Re-kick should use the current plan/work set so the Orchestrator does not forget leftover queued Tickets between turns.
+session work set は bounded で、Orchestrator の現在 session における判断補助として扱う。
 
-### Relationship to existing work
+- 何を取り込んだか。
+- 次に acceptance / routing すべき候補は何か。
+- 何を waiting としたか。
+- waiting の理由は何か。
+- `active_inprogress` として re-kick を抑制する対象は何か。
 
-- This Ticket should either subsume or update `ticket-orchestration-plan-tool` so there is one coherent plan/re-kick design.
-- It should coordinate with:
-  - `replace-intake-state-with-planning` as a prerequisite that defines the planning lane before this plan/re-kick layer builds on it;
-  - `panel-close-done-tickets` for done -> closed handling;
-  - local role session registry for active Pod/session ownership;
-  - direct/delegation authority work for actual child Pod spawning.
+これらは project-level の永続ログではなく、Task と同様に session lifetime の状態でよい。ユーザー判断や Ticket lifecycle に残すべき内容が生じた場合だけ、Ticket comment / state transition / resolution など既存の durable surface に記録する。
 
-## Non-requirements
+## 非目標
 
-- Do not turn the Panel itself into the scheduler.
-- Do not auto-start unqueued Tickets.
-- Do not re-kick continuously while active coder/reviewer/planning-sync/merge work is already in progress.
-- Do not blindly spawn coder Pods from re-kick without Orchestrator inspection and `queued -> inprogress` acceptance.
-- Do not implement a full dependency graph solver in the first version.
+- Panel 自体を scheduler にすること。
+- `queued` になっていない Ticket を自動開始すること。
+- `active_inprogress` が導出されている間に継続的な re-kick を行うこと。
+- Orchestrator の inspection と `queued -> inprogress` acceptance なしに coder/reviewer Pod を spawn すること。
+- full dependency graph solver を最初の実装で作ること。
+- `new_queued` / `planned_queued` / `active_inprogress` を core Ticket state として追加すること。
+- volatile な orchestration work set を Ticket ごとの durable artifact log として保存すること。
 
-## Acceptance criteria
+## 受け入れ条件
 
-- The system can distinguish new queued work, planned queued work, and accepted in-progress work.
-- New queued Tickets are not left unnoticed while the Orchestrator is otherwise idle.
-- Runnable planned queued Tickets are not left unstarted when there is no active in-progress work and capacity/policy allows progress.
-- The system does not re-kick merely because queued/planned work exists while Orchestrator-managed in-progress work is waiting on coder/reviewer/planning-sync/merge completion.
-- Missed/stale queued Tickets can be surfaced to the Orchestrator without requiring the user to manually requeue each one.
-- The Orchestrator can record and query a lightweight Ticket orchestration plan covering active targets, order/dependency/conflict/capacity, state bucket, and next actions.
-- Plan records survive compaction and do not rely solely on session-lifetime TaskStore state.
-- Re-kick/plan updates leave an auditable record of what was incorporated, started, blocked, returned to planning, or left waiting.
-- Duplicate implementation starts are prevented by consulting current Ticket state, local role/session claims, and plan records.
-- Relevant workflows/prompts/docs are updated.
-- Focused tests, `target/debug/yoi ticket doctor`, `cargo fmt --check`, and `git diff --check` pass.
+- Orchestrator Pod の state が `Idle` のとき、`new_queued` work を検出して bounded work-list attention または session work set への取り込みに進める。
+- `active_inprogress` が導出されず、Orchestrator Pod の state が `Idle` で、`planned_queued` work が unblocked かつ capacity/policy 上開始可能なとき、Orchestrator が次の acceptance/routing を行える。
+- `active_inprogress` が導出されている間は、queued/planned work の存在だけで re-kick しない。
+- 開始しない `planned_queued` work には、session work set 上でユーザーに提示できる bounded waiting/blocking reason が残る。
+- 既存の human gate、`queued -> inprogress` acceptance step、dirty-workspace/dependency/conflict/capacity checks を迂回しない。
+- Ticket state、session work set、role/session claims、visible Pod/worktree state を確認し、duplicate Orchestrator/coder/reviewer/worktree start を起こさない。
+- missed/stale queued Tickets を、ユーザーが手で再 queue しなくても Orchestrator に提示できる。
+- Orchestrator session work set を失っても、`queued` Ticket を再検出して安全に再 inspection できる。
+
+## 検証
+
+- `nix build .#yoi` を通す。
+- Ticket / panel / orchestrator routing 周辺の既存テストまたは追加テストで、少なくとも次の主要分岐を確認する。
+  - Orchestrator Pod `Idle` state での queued detection。
+  - `active_inprogress` 導出時の re-kick suppression。
+  - session work set 上の waiting reason 保持。
+  - duplicate-start prevention。
+  - session work set が空でも `queued` Ticket から再検出できること。
+- 実装報告では、work-set classification に使った情報と、implementation side effects が `queued -> inprogress` 後に限定されていることを明示する。

.yoi/tickets/00001KTJXS31R/resolution.md

@@ -0,0 +1,41 @@
+Orchestrator Idle 時に queued Ticket を見落とさない bounded attention layer を実装した。
+
+実装概要:
+- `crates/tui/src/multi_pod.rs` に session-scoped `OrchestratorWorkSet` を追加し、Panel reload 境界で queued/actionable/planned/active_inprogress を導出するようにした。
+- Idle かつ reachable な Orchestrator Pod にだけ bounded queued-work attention を送る。
+- `active_inprogress` がある場合は re-kick を抑制し、waiting reason を session work set / Panel header detail に保持する。
+- Duplicate-start guard は Ticket id に紐づく local claim / related visible Pods / worktree 表示情報から導出する。
+- Session work set は `MultiPodApp` 内 runtime/session state に留め、durable per-Ticket artifact store は追加していない。
+- `resources/prompts/panel/orchestrator_idle_queue_notice.md` を追加し、Orchestrator attention payload の prompt 本文を resource 化した。
+- Scheduler loop、polling loop、queue drain loop、core Ticket state、implementation side effect、acceptance gate bypass は追加していない。
+
+Review / integration:
+- Implementation commit: `d2fae81a tui: add idle queued orchestrator attention`
+- Reviewer: `yoi-reviewer-idle-queued-rekick` が approve。
+- Orchestrator merge commit: `9538feb1 merge: idle queued orchestrator attention`
+- Ticket completion commit: `60cf2d9f ticket: mark idle queued done`
+
+Validation:
+- `cargo test -p tui queued_attention`: pass, 3 tests
+- `cargo test -p tui planned_queued_prompts`: pass, 1 test
+- `cargo test -p tui rediscovered_queued_work`: pass, 1 test
+- `cargo test -p tui active_inprogress_suppresses`: pass, 1 test
+- `cargo test -p tui idle_orchestrator_gets_bounded_attention`: pass, 1 test
+- `cargo test -p tui workspace_panel`: pass, 12 tests
+- `cargo check -p tui`: pass
+- `cargo fmt --check`: pass
+- `git diff --check HEAD~1..HEAD`: pass
+- `./result/bin/yoi ticket doctor`: `doctor: ok`
+- `nix build .#yoi`: pass
+
+Known broad-suite failures:
+- Existing broad `cargo test -p tui` failures noted in thread remain outside this Ticket and were not blockers for focused implementation/review.
+
+Cleanup:
+- coder/reviewer Pods stopped。
+- child worktree `/home/hare/Projects/yoi/.worktree/orchestrator-idle-queued-rekick` removed。
+- branch `ticket/orchestrator-idle-queued-rekick` deleted。
+
+Non-blocking risks:
+- Failed attention delivery is not fingerprint-marked, so a repeatedly reachable-but-rejecting socket can retry on subsequent Panel reloads; this is consistent with existing notice behavior but may be noisy。
+- Duplicate guard is bounded to Panel-visible claim/Pod/worktree derivation and is not a full global scheduler/lock, matching this Ticket の scoped attention model。

.yoi/tickets/00001KTJXS31R/thread.md

@@ -118,3 +118,398 @@ Ticket 00001KTJXS31R は implementation_ready。残り範囲は既に実装済
 Intake refinement により、既存の plan store 実装との差分、current `state` vocabulary、binding invariants、implementation latitude、validation focus が整理され、Orchestrator が routing できる状態になった。
 
 ---
+
+<!-- event: state_changed author: workspace-panel at: 2026-06-12T14:49:40Z from: ready to: queued reason: queued field: state -->
+
+## State changed
+
+Ticket を `workspace-panel` が queued にしました。
+
+
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-12T14:56:17Z -->
+
+## Decision
+
+Routing decision: leave queued for now (`waiting_capacity_note`)
+
+Reason:
+- This queue review already accepted and delegated three in-progress branches: `00001KTVJFT6F` (Panel focus model), `00001KTTW04W2` (Companion progress notification), and `00001KTVJGC0Y` (Ticket language guidance).
+- This Ticket concerns Orchestrator idle queued re-kick / active work-set behavior and overlaps conceptually with the active Companion progress notification and Panel lifecycle work. Starting it now would raise duplicate-start / scheduler-boundary / integration-conflict risk rather than safe independent parallelism.
+- Relation check: dependency relation target `00001KTG3MDFG` is closed, so this is not blocked by an unresolved relation; the current stop reason is capacity/conflict with active work.
+
+Evidence checked:
+- Ticket body/thread: active in-progress suppression, clean workspace gate, no queue-drain loop, active-work-set snapshot requirements, and escalation conditions.
+- TicketRelationQuery: two relation records checked; `depends_on` target `00001KTG3MDFG` is closed.
+- TicketOrchestrationPlanQuery: no prior records; added `waiting_capacity_note` `orch-plan-20260612-145604-1`.
+- Workspace/Pod state: Orchestrator worktree clean; active sibling coder Pods are running for Panel focus, Companion progress notification, and Ticket language guidance.
+
+Next action:
+- Keep `queued` and reconsider after at least Panel focus / Companion progress notification are merged or blocked, so this Ticket can validate against the current Panel/notification behavior without duplicate scheduler semantics.
+
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-12T15:46:19Z -->
+
+## Decision
+
+Routing decision: implementation_ready
+
+Reason:
+- 前回の waiting reason は、Panel focus / Companion progress notification / Ticket language guidance の active in-progress work と重なる capacity/conflict だった。現在それらは merge/close/cleanup 済みで、visible child Pod は 0、Orchestrator worktree は clean。
+- Relation blocker はない。`depends_on` target `00001KTG3MDFG` は closed 済みで、incoming `related` は non-blocking context である。
+- Ticket body/thread は、session-lifetime work set discovery / re-kick policy、active_inprogress suppression、duplicate-start prevention、no scheduler/no polling/no blind spawn、`queued -> inprogress` acceptance gate を binding decisions として明確にしている。
+- risk flags は orchestration-policy / panel-lifecycle / persistence / role-session / authority-boundary / duplicate-start だが、bounded context check の結果、具体的な未決定 design/API/authority 判断は残っていない。実装方式は Panel/lifecycle/runtime boundary と local session work-set representation の local tactic に閉じている。
+- OrchestrationPlan に accepted plan `orch-plan-20260612-154541-2` を記録済み。
+
+Evidence checked:
+- Ticket body / thread / artifacts: requirements, acceptance criteria, binding decisions, previous waiting_capacity_note, and accepted plan を確認。
+- TicketRelationQuery: `depends_on` target `00001KTG3MDFG` closed、incoming `related` non-blocking。
+- Related Ticket: `00001KTG3MDFG` closed。OrchestrationPlan record/tool surface は実装済みで、この Ticket では再実装しない前提を確認。
+- Recent merged context: Panel focus model、Companion weak progress notify、Ticket language guidance は closed/merged/cleaned up 済み。
+- Code map: `crates/tui/src/workspace_panel.rs`, `crates/tui/src/multi_pod.rs`, `crates/tui/src/role_session_registry.rs`, Ticket state/action surfaces, Pod visibility/state surfaces, recent `companion_progress` weak notify path を確認。
+- Workspace/Pod state: Orchestrator branch `orchestration/yoi-orchestrator` is clean; visible child Pods 0。
+
+IntentPacket:
+
+Intent:
+- Orchestrator が idle で actionable queued work を見落とすことを防ぐ bounded starvation-prevention layer を実装する。
+- `active_inprogress` が導出されている間は queued/planned work があるだけでは re-kick しない。
+- re-kick は inspection / work-set incorporation / next planned acceptance を促す attention であり、scheduler や blind implementation start ではない。
+
+Binding decisions / invariants:
+- `new_queued` / `planned_queued` / `active_inprogress` / `actionable_inprogress` は core Ticket state に追加しない。Ticket `state`、session-lifetime work set、role/session claims、visible Pod/worktree state、OrchestrationPlan records から導出する分類に留める。
+- Work set は session-lifetime runtime state であり、Ticket ごとの durable artifact log として積まない。durable に残すべき判断だけ Ticket comment / state transition / OrchestrationPlan record に残す。
+- 常時 polling / unattended scheduler loop / queue drain loop を作らない。
+- `queued -> inprogress` acceptance なしに coder/reviewer Pod spawn、worktree 作成、implementation side effect を行わない。
+- active coder/reviewer/planning-sync/merge/cleanup 等の完了待ち中は queued/planned work の存在だけで re-kick しない。
+- duplicate Orchestrator/coder/reviewer/worktree start を防ぐ。
+- Panel は authority/backend/scheduler にならず、bounded attention surface に留まる。
+
+Requirements / acceptance criteria:
+- Orchestrator Pod が `Idle` で `new_queued` work があるとき、bounded work-list attention または session work set incorporation に進める。
+- `active_inprogress` がなく、planned queued work が unblocked/capacity-allowed のとき、next acceptance/routing に進める。
+- `active_inprogress` が導出される間は queued/planned work の存在だけで re-kick しない。
+- 開始しない planned queued work には session work set 上でユーザーに提示できる bounded waiting/blocking reason を保持する。
+- Ticket state、session work set、role/session claims、visible Pod/worktree state を使って duplicate start を避ける。
+- session work set が失われても `queued` Ticket から安全に再検出・再 inspection できる。
+
+Implementation latitude:
+- Panel open / Orchestrator restore/spawn / explicit user action のどの boundary で idle detection と attention payload を組むかは実装側で選んでよい。
+- Session work-set の具体的な runtime representation は既存 local role/session registry や Panel app state に合わせて選んでよい。
+- Bounded attention payload の具体形は実装側で選んでよいが、full Ticket thread / unbounded Pod output / hidden context-only injection は避ける。
+- OrchestrationPlan types の最小拡張は必要なら検討してよいが、core Ticket lifecycle state や旧 `workflow_state` は復活させない。
+
+Escalate if:
+- Durable scheduler state / persistent queue runner / polling loop が必要になる。
+- `queued -> inprogress` acceptance gate を迂回しないと実装できない。
+- Duplicate start prevention に新しい global lock/lease authority が必要になる。
+- Panel が lifecycle authority / scheduler になる必要が出る。
+- Role/session claims から active_inprogress を安全に導出できない。
+
+Validation:
+- idle Orchestrator + queued detection。
+- active_inprogress 導出時の re-kick suppression。
+- planned queued waiting reason retention。
+- duplicate-start prevention。
+- session work set loss から queued Ticket 再検出。
+- relevant `cargo test` for `tui` / panel / role session / ticket routing paths。
+- `cargo fmt --check`。
+- `git diff --check`。
+- `cargo run -p yoi -- ticket doctor` または同等。
+- `nix build .#yoi`。
+
+Current code map:
+- `crates/tui/src/workspace_panel.rs`: Ticket rows/actions and state-first Panel view model。
+- `crates/tui/src/multi_pod.rs`: Panel lifecycle, Companion/Orchestrator interactions, recent progress notice / header behavior。
+- `crates/tui/src/role_session_registry.rs`: local role/session claims。
+- `crates/pod-store`, `crates/pod-registry`, and protocol Pod status surfaces only if needed for visible Pod/worktree state derivation。
+- Ticket relation / OrchestrationPlan tool surfaces are already implemented and should be reused/read, not reimplemented as plan store。
+
+Critical risks / reviewer focus:
+- No scheduler / queue drain loop / background polling。
+- No blind worktree/Pod spawn before `queued -> inprogress` acceptance。
+- active_inprogress suppression works and avoids re-kick while coder/reviewer/merge/cleanup is active。
+- duplicate start prevention uses actual Ticket state + claims + visible Pods/worktrees, not heuristic title/labels。
+- session work set is runtime/session scoped, not a new durable per-Ticket artifact log。
+- Recent Companion weak progress notify and Panel focus behavior remain coherent.
+
+Next action:
+- `queued -> inprogress` を記録してから、branch `ticket/orchestrator-idle-queued-rekick` / worktree `/home/hare/Projects/yoi/.worktree/orchestrator-idle-queued-rekick` を作成し、sibling coder に narrow write scope で実装を委譲する。Reviewer は coder evidence 後に read-only で起動する。
+
+---
+
+<!-- event: state_changed author: orchestrator at: 2026-06-12T15:46:28Z from: queued to: inprogress reason: orchestrator_acceptance field: state -->
+
+## State changed
+
+Routing accepted for implementation. Ticket body/thread, dependency relation target, incoming non-blocking relation, previous waiting-capacity note, current Orchestrator workspace state, visible Pods, recent merged Panel/Companion/Ticket-language context, and relevant Panel/lifecycle/role-session code map were rechecked. No unresolved blocker or missing planning decision remains. Implementation side effects will start only after this accepted `queued -> inprogress` transition is recorded, using accepted plan `orch-plan-20260612-154541-2`.
+
+---
+
+<!-- event: plan author: orchestrator at: 2026-06-12T15:47:00Z -->
+
+## Plan
+
+Implementation worktree created for multi-agent handoff.
+
+- Ticket: `00001KTJXS31R`
+- Branch: `ticket/orchestrator-idle-queued-rekick`
+- Worktree: `/home/hare/Projects/yoi/.worktree/orchestrator-idle-queued-rekick`
+- Base: Orchestrator workspace HEAD `e72a4536` (`orchestration/yoi-orchestrator`), including the accepted routing record and `queued -> inprogress` transition.
+- Scope rule: implementation work happens only in this child worktree. Root/original workspace must not be read, written, validated, merged, cleaned, or used for git operations.
+- Next: spawn sibling coder with narrow write scope to the implementation worktree. Reviewer will be started after coder evidence is available.
+
+---
+
+<!-- event: plan author: orchestrator at: 2026-06-12T15:47:50Z -->
+
+## Plan
+
+Coder delegated.
+
+- Coder Pod: `yoi-coder-idle-queued-rekick`
+- Worktree: `/home/hare/Projects/yoi/.worktree/orchestrator-idle-queued-rekick`
+- Branch: `ticket/orchestrator-idle-queued-rekick`
+- Scope: write `/home/hare/Projects/yoi/.worktree/orchestrator-idle-queued-rekick`; read child worktree plus minimal non-recursive runtime-root read required by spawn validation.
+- Task: implement bounded idle-Orchestrator queued-work attention / session work-set rediscovery without scheduler/polling/queue-drain behavior, preserve `queued -> inprogress` acceptance gate, suppress re-kick while active_inprogress work exists, prevent duplicate starts, and add focused tests plus required validation.
+- Constraint: coder was instructed not to use root/original workspace for decision evidence or git/validation/cleanup, and not to create generated memory/local/runtime/log/lock/secret-like `.yoi` paths.
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-12T16:04:17Z -->
+
+## Implementation report
+
+Coder completed implementation.
+
+Coder Pod:
+- `yoi-coder-idle-queued-rekick`
+
+Implementation branch/worktree:
+- Branch: `ticket/orchestrator-idle-queued-rekick`
+- Worktree: `/home/hare/Projects/yoi/.worktree/orchestrator-idle-queued-rekick`
+- Commit: `d2fae81a tui: add idle queued orchestrator attention`
+- Worktree status: clean
+
+Changed surfaces:
+- `crates/tui/src/multi_pod.rs`
+- `resources/prompts/panel/orchestrator_idle_queue_notice.md`
+
+Implementation summary:
+- Adds session-scoped `OrchestratorWorkSet` derived at Panel reload boundary.
+- Derives `active_inprogress`, new/actionable queued, planned queued, waiting reasons, and duplicate guards from Panel Ticket rows, local role-session claims, related Pods, blocked reasons, and live Orchestrator status.
+- Sends bounded Orchestrator attention only when Orchestrator is live/reachable/idle and queued work is actionable.
+- Suppresses attention when active_inprogress exists or duplicate-start guard indicates existing claim/Pod/worktree activity.
+- Retains waiting reason / planned queued information in Panel header detail for session-visible explanation.
+- Adds prompt resource `resources/prompts/panel/orchestrator_idle_queue_notice.md` for the attention payload, preserving the prompt-resource boundary.
+- Does not add scheduler loop, polling loop, queue drain loop, core Ticket states, or persistent work-set artifact store.
+
+Implementation note for reviewer attention:
+- Coder report used the phrase `workflow_state` for `TicketPanelEntry.workflow_state`; this is existing Panel model naming over the typed Ticket state enum, not reintroduction of obsolete Ticket frontmatter `workflow_state`.
+
+Orchestrator-verified evidence from child worktree:
+- `git status --short --branch`: clean on `ticket/orchestrator-idle-queued-rekick`
+- `cargo test -p tui queued_attention`: pass, 3 tests
+- `cargo test -p tui planned_queued_prompts`: pass, 1 test
+- `cargo test -p tui rediscovered_queued_work`: pass, 1 test
+- `cargo test -p tui active_inprogress_suppresses`: pass, 1 test
+- `cargo test -p tui idle_orchestrator_gets_bounded_attention`: pass, 1 test
+- `cargo test -p tui workspace_panel`: pass, 12 tests
+- `cargo check -p tui`: pass
+- `cargo fmt --check`: pass
+- `git diff --check orchestration/yoi-orchestrator...HEAD`: pass
+- `cargo run -p yoi -- ticket doctor`: `doctor: ok`
+- `nix build .#yoi`: pass
+
+Known broad-suite note from coder:
+- `cargo test -p tui` still fails unrelated existing/neighboring expectation tests:
+  - `multi_pod::tests::orchestrator_launch_context_uses_orchestration_root_for_runtime_workspace`
+  - `spawn::tests::profile_choices_use_project_registry_default`
+  - `spawn::tests::profile_choices_include_builtin_and_project_default_marker`
+- Focused tests for this Ticket pass; reviewer should confirm broad failures are unrelated and not introduced by this Ticket.
+
+Next:
+- Spawn read-only sibling reviewer against recorded intent, binding decisions/invariants, acceptance criteria, commit `d2fae81a`, diff, validation evidence, and known broad-suite failures.
+
+---
+
+<!-- event: plan author: orchestrator at: 2026-06-12T16:05:08Z -->
+
+## Plan
+
+Reviewer delegated.
+
+- Reviewer Pod: `yoi-reviewer-idle-queued-rekick`
+- Target branch/worktree: `ticket/orchestrator-idle-queued-rekick` at `/home/hare/Projects/yoi/.worktree/orchestrator-idle-queued-rekick`
+- Commit under review: `d2fae81a tui: add idle queued orchestrator attention`
+- Scope: read-only child worktree plus minimal non-recursive runtime-root read required by spawn validation.
+- Review basis: recorded IntentPacket, binding decisions/invariants, acceptance criteria, implementation summary, diff, focused validation evidence, `nix build` evidence, and known broad-suite failures.
+- Reviewer focus: no scheduler/polling/queue-drain behavior, no acceptance-gate bypass, active_inprogress suppression, duplicate-start prevention, session-scoped work set, prompt-resource boundary, recent Panel/Companion behavior compatibility, and robust focused tests.
+
+---
+
+<!-- event: review author: reviewer:yoi-reviewer-idle-queued-rekick at: 2026-06-12T16:10:24Z status: approve -->
+
+## Review: approve
+
+Approve.
+
+Review target:
+- Worktree: `/home/hare/Projects/yoi/.worktree/orchestrator-idle-queued-rekick`
+- Commit: `d2fae81a tui: add idle queued orchestrator attention`
+
+Evidence:
+- 差分は `crates/tui/src/multi_pod.rs` と `resources/prompts/panel/orchestrator_idle_queue_notice.md` のみ。
+- queued work への通知は idle かつ reachable な Orchestrator Pod に限定されている。
+- `Method::Notify { auto_run: true }` は bounded attention / re-kick として使われるだけで、Ticket 状態変更・Pod spawn・worktree 作成・queue drain は追加されていない。
+- Scheduler / queue drain / background worker は追加されていない。既存 Panel reload 後に fingerprint で重複抑制された通知を送る構成。
+- `queued -> inprogress` acceptance は bypass されていない。通知 payload は Ticket state verification と通常 acceptance 記録を明示し、implementation side effect は行わない。
+- `active_inprogress` suppression は実装されている。`TicketWorkflowState::InProgress` が存在する場合、queued attention は送られず、waiting reason として session work set に残る。
+- Duplicate-start guard は title/label ではなく、Ticket id に紐づく local claim / related visible Pods / worktree 表示情報から導出している。
+- Session work set は `MultiPodApp` 内の runtime/session-scoped state のみで、永続 per-Ticket artifact は追加されていない。
+- Prompt 本文は `resources/prompts/panel/orchestrator_idle_queue_notice.md` に置かれており、Rust 側は include/render の境界に留まっている。
+- `workflow_state` 命名は既存の typed `TicketWorkflowState` / Panel internal naming の利用であり、この差分で obsolete frontmatter authority を再導入しているものではない。
+
+Reviewer-run validation:
+- `cargo test -p tui queued_attention -- --nocapture`: pass, 3 tests
+- `cargo test -p tui planned_queued_prompts -- --nocapture`: pass
+- `cargo test -p tui rediscovered_queued_work -- --nocapture`: pass
+- `cargo test -p tui idle_orchestrator_gets_bounded_attention -- --nocapture`: pass
+- `cargo test -p tui active_inprogress_suppresses -- --nocapture`: pass
+- `cargo test -p tui workspace_panel -- --nocapture`: pass, 12 tests
+- `cargo check -p tui`: pass
+- `git diff --check orchestration/yoi-orchestrator...HEAD && cargo fmt --check`: pass
+
+Known broad-suite failures:
+- `cargo test -p tui`: expected broad-suite failure, 312 passed / 3 failed.
+- Failing tests:
+  - `multi_pod::tests::orchestrator_launch_context_uses_orchestration_root_for_runtime_workspace`
+  - `spawn::tests::profile_choices_use_project_registry_default`
+  - `spawn::tests::profile_choices_include_builtin_and_project_default_marker`
+- The two `spawn` failures are in untouched `crates/tui/src/spawn.rs`.
+- The `orchestrator_launch_context...` failure is in `multi_pod.rs`, but this diff does not touch `build_orchestrator_launch_context` or that test area; it remains the existing/neighboring expectation mismatch reported by coder. Not a blocker for this Ticket.
+
+Non-blocking risks:
+- Failed delivery is not fingerprint-marked, so a repeatedly reachable-but-rejecting socket can retry on subsequent Panel reloads; this is consistent with existing notice behavior but may be noisy.
+- Duplicate guard depends on the Panel’s existing visible claim/pod/worktree derivation, so it prevents duplicate starts for locally visible state but is not a full global scheduler/lock. This matches the Ticket’s bounded Panel-attention scope.
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-12T16:11:43Z -->
+
+## Implementation report
+
+Integration completed in the Orchestrator workspace.
+
+Integrated implementation:
+- Ticket: `00001KTJXS31R`
+- Implementation branch: `ticket/orchestrator-idle-queued-rekick`
+- Implementation commit: `d2fae81a tui: add idle queued orchestrator attention`
+- Reviewer result: approve, no blockers
+- Orchestrator merge commit: `9538feb1 merge: idle queued orchestrator attention`
+- Integration target: `orchestration/yoi-orchestrator`
+
+Post-integration validation from Orchestrator worktree:
+- `cargo test -p tui queued_attention`: pass, 3 tests
+- `cargo test -p tui planned_queued_prompts`: pass, 1 test
+- `cargo test -p tui rediscovered_queued_work`: pass, 1 test
+- `cargo test -p tui active_inprogress_suppresses`: pass, 1 test
+- `cargo test -p tui idle_orchestrator_gets_bounded_attention`: pass, 1 test
+- `cargo test -p tui workspace_panel`: pass, 12 tests
+- `cargo check -p tui`: pass
+- `cargo fmt --check`: pass
+- `git diff --check HEAD~1..HEAD`: pass
+- `./result/bin/yoi ticket doctor`: `doctor: ok`
+- `nix build .#yoi`: pass
+
+Known broad-suite failures:
+- Existing broad `cargo test -p tui` failures noted by coder/reviewer remain outside this Ticket and were not blockers for focused implementation/review.
+
+Remaining non-blocking risks:
+- Failed attention delivery is not fingerprint-marked, so a repeatedly reachable-but-rejecting socket can retry on subsequent Panel reloads; this is consistent with existing notice behavior but may be noisy.
+- Duplicate guard is bounded to Panel-visible claim/Pod/worktree derivation and is not a full global scheduler/lock, matching this Ticket's scoped attention model.
+
+---
+
+<!-- event: state_changed author: orchestrator at: 2026-06-12T16:11:51Z from: inprogress to: done reason: implementation_merged_and_validated field: state -->
+
+## State changed
+
+Implementation was merged into the Orchestrator branch, reviewer approved with no blockers, and post-integration validation passed. Cleanup and closure will be recorded next.
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-12T16:12:22Z -->
+
+## Implementation report
+
+Cleanup completed.
+
+- Stopped coder Pod: `yoi-coder-idle-queued-rekick`
+- Stopped reviewer Pod: `yoi-reviewer-idle-queued-rekick`
+- Removed child worktree: `/home/hare/Projects/yoi/.worktree/orchestrator-idle-queued-rekick`
+- Deleted implementation branch: `ticket/orchestrator-idle-queued-rekick`
+- Orchestrator worktree status after cleanup: clean
+
+Cleanup was limited to child implementation worktree/branch and related child Pods. Root/original workspace was not touched.
+
+---
+
+<!-- event: state_changed author: hare at: 2026-06-12T16:12:42Z from: done to: closed reason: closed field: state -->
+
+## State changed
+
+Ticket を closed にしました。
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-12T16:12:42Z status: closed -->
+
+## 完了
+
+Orchestrator Idle 時に queued Ticket を見落とさない bounded attention layer を実装した。
+
+実装概要:
+- `crates/tui/src/multi_pod.rs` に session-scoped `OrchestratorWorkSet` を追加し、Panel reload 境界で queued/actionable/planned/active_inprogress を導出するようにした。
+- Idle かつ reachable な Orchestrator Pod にだけ bounded queued-work attention を送る。
+- `active_inprogress` がある場合は re-kick を抑制し、waiting reason を session work set / Panel header detail に保持する。
+- Duplicate-start guard は Ticket id に紐づく local claim / related visible Pods / worktree 表示情報から導出する。
+- Session work set は `MultiPodApp` 内 runtime/session state に留め、durable per-Ticket artifact store は追加していない。
+- `resources/prompts/panel/orchestrator_idle_queue_notice.md` を追加し、Orchestrator attention payload の prompt 本文を resource 化した。
+- Scheduler loop、polling loop、queue drain loop、core Ticket state、implementation side effect、acceptance gate bypass は追加していない。
+
+Review / integration:
+- Implementation commit: `d2fae81a tui: add idle queued orchestrator attention`
+- Reviewer: `yoi-reviewer-idle-queued-rekick` が approve。
+- Orchestrator merge commit: `9538feb1 merge: idle queued orchestrator attention`
+- Ticket completion commit: `60cf2d9f ticket: mark idle queued done`
+
+Validation:
+- `cargo test -p tui queued_attention`: pass, 3 tests
+- `cargo test -p tui planned_queued_prompts`: pass, 1 test
+- `cargo test -p tui rediscovered_queued_work`: pass, 1 test
+- `cargo test -p tui active_inprogress_suppresses`: pass, 1 test
+- `cargo test -p tui idle_orchestrator_gets_bounded_attention`: pass, 1 test
+- `cargo test -p tui workspace_panel`: pass, 12 tests
+- `cargo check -p tui`: pass
+- `cargo fmt --check`: pass
+- `git diff --check HEAD~1..HEAD`: pass
+- `./result/bin/yoi ticket doctor`: `doctor: ok`
+- `nix build .#yoi`: pass
+
+Known broad-suite failures:
+- Existing broad `cargo test -p tui` failures noted in thread remain outside this Ticket and were not blockers for focused implementation/review.
+
+Cleanup:
+- coder/reviewer Pods stopped。
+- child worktree `/home/hare/Projects/yoi/.worktree/orchestrator-idle-queued-rekick` removed。
+- branch `ticket/orchestrator-idle-queued-rekick` deleted。
+
+Non-blocking risks:
+- Failed attention delivery is not fingerprint-marked, so a repeatedly reachable-but-rejecting socket can retry on subsequent Panel reloads; this is consistent with existing notice behavior but may be noisy。
+- Duplicate guard is bounded to Panel-visible claim/Pod/worktree derivation and is not a full global scheduler/lock, matching this Ticket の scoped attention model。
+
+---

.yoi/tickets/00001KTR81P9X/artifacts/orchestration-plan.jsonl

@@ -0,0 +1 @@
+{"id":"orch-plan-20260614-061002-1","ticket_id":"00001KTR81P9X","kind":"accepted_plan","accepted_plan":{"summary":"Implement feature-layer dynamic provider/service lifecycle and startup dynamic tool contribution substrate after HostAuthority cleanup, preserving normal ToolRegistry/permission/history paths and leaving MCP/Plugin policy out of scope.","branch":"ticket-00001KTR81P9X-feature-provider-api","worktree":"/home/hare/Projects/yoi/.worktree/feature-provider-api","role_plan":"Coder works on pod feature API and mock provider tests; Reviewer focuses on no authority-layer regression, dynamic schema stability, permission denial path, result bounding, and provider failure diagnostics."},"author":"orchestrator","at":"2026-06-14T06:10:02Z"}

.yoi/tickets/00001KTR81P9X/artifacts/relations.json

@@ -0,0 +1,13 @@
+{
+  "version": 1,
+  "relations": [
+    {
+      "ticket_id": "00001KTR81P9X",
+      "kind": "depends_on",
+      "target": "00001KV0SP0TY",
+      "note": "dynamic provider API should be implemented after feature-layer HostAuthority removal",
+      "author": "yoi ticket",
+      "at": "2026-06-13T16:27:14Z"
+    }
+  ]
+}

.yoi/tickets/00001KTR81P9X/item.md

@@ -1,76 +1,95 @@
 ---
 title: 'Extend pod::feature API for external protocol-backed capability providers'
-state: 'planning'
+state: 'closed'
 created_at: '2026-06-10T07:48:14Z'
-updated_at: '2026-06-10T07:48:14Z'
+updated_at: '2026-06-14T14:00:13Z'
 assignee: null
-readiness: 'requirements_sync_needed'
-risk_flags: ['authority-boundary', 'feature-api', 'tool-registry', 'permission-scope', 'process-exec', 'prompt-context']
+readiness: 'implementation_ready'
+risk_flags: ['feature-api', 'tool-registry', 'permission-scope', 'prompt-context', 'dynamic-registry', 'service-lifecycle']
+queued_by: 'workspace-panel'
+queued_at: '2026-06-14T06:08:25Z'
 ---
 
 ## Background
 
-MCP integration を concrete work item として実装する前に、Yoi の `pod::feature` / Worker / ToolRegistry 境界が外部 protocol-backed capability provider を自然に扱える必要がある。
+Yoi needs `pod::feature` to serve as the common API substrate for capabilities that contribute Tools / Hooks / Services / BackgroundTasks. External protocol-backed providers such as MCP need to discover contributions at startup and expose them through the same Worker / ToolRegistry / permission / history / bounded-result paths as built-in tools.
 
-現行の `pod::feature` API は static descriptor / static tool contribution / host authority grant を中心にしており、MCP のように startup 時の protocol negotiation と discovery によって tools/resources/prompts surface が決まる provider には不足がある。MCP 実装側でこれを ad-hoc に迂回すると、permission、history、bounded result、service lifecycle、feature/plugin boundary が歪む。
+This Ticket defines the feature-layer API required for those providers. It does **not** define Plugin package permissions, MCP server trust policy, local process sandboxing, or a feature-level authority model. Plugin and MCP are separate layers that build on the feature API and own their own user-facing configuration and permission/trust decisions.
 
-Objective context: `00001KTR80WMN`。
+Objective context: `00001KTR80WMN`.
 
 ## Requirements
 
-- `pod::feature` が external protocol-backed capability provider を表現できるようにする。
-- local subprocess を起動する authority を明示的に表現する。
-  - 既存の filesystem/network/service authority に押し込まない。
-  - command / args / cwd / env / secret refs は explicit config/grant に基づく。
-- Pod lifetime に紐づく feature-provided service / connection manager の lifecycle を表現できるようにする。
-- startup / initialize / discovery 後に tool contribution を登録または更新できる host-mediated API を設計する。
-- dynamic contribution は通常の ToolRegistry / PreToolCall permission / history / bounded tool-result path を迂回しない。
-- tool metadata に、MCP など外部 provider が持つ追加 metadata を安全に保持・変換できる余地を作る。
-  - title
-  - output schema
-  - annotations
-  - icons or display metadata
-  - execution/task-support metadata
-- rich / structured tool result を bounded serialization できる共通 path を用意する。
-- capability metadata / schemas / descriptions / results は untrusted data として扱う。
-- live list-changed / registry refresh が current run の tool schema consistency を壊さない方針を決める。
-- API 拡張は MCP 固有名に寄せすぎず、将来の external plugin / bridge provider にも使える feature boundary として設計する。
+- Treat `pod::feature` as the API layer for contribution registration and lifecycle integration.
+  - Feature code exposes contribution types and installation/runtime hooks.
+  - Feature code does not decide Plugin trust, MCP enablement, or external-provider permissions.
+  - Do not add or rely on `HostAuthority` / authority grants for MCP, Plugin, or provider-process permissions.
+- Add a feature-owned provider/service lifecycle surface sufficient for protocol-backed providers.
+  - startup / ready / failed / stopped diagnostics
+  - Pod lifetime integration and deterministic shutdown hooks
+  - provider failure state that makes dependent dynamic tools unavailable with a clear diagnostic
+- Add dynamic contribution registration for startup-discovered tools.
+  - discovery happens before the tool schema is exposed to a model request
+  - registered tools use stable namespacing and normal ToolRegistry registration
+  - tool schema changes during an active run do not silently mutate the model-visible schema
+- Define bounded refresh semantics for provider list changes.
+  - initial implementation may defer live refresh to a turn boundary or report restart/reinitialize-required diagnostics
+  - silent stale or mid-run schema mutation is not allowed
+- Define provider metadata / schema / result normalization as untrusted data.
+  - descriptions, schemas, annotations, titles, and provider metadata cannot weaken system/developer instructions
+  - structured / rich results are converted through a bounded Yoi representation before entering history/model-visible output
+- Ensure dynamic tool calls do not bypass normal Yoi paths.
+  - PreToolCall permission hooks still run
+  - permission denial prevents the provider call
+  - tool results and errors are committed through normal history/result plumbing
+- Keep MCP-specific protocol details in Ticket `00001KTR82RB7`.
+  - command / args / cwd / env / stdio JSON-RPC / MCP lifecycle are MCP-layer concerns
+  - MCP may define its own enablement and trust policy on top of this feature API
+- Keep Plugin user-facing format and Plugin permission model outside this Ticket.
+  - Plugin packages/configs may use the feature API to contribute capabilities
+  - Plugin permission/trust policy belongs to the Plugin layer, not `pod::feature`
 
 ## Acceptance criteria
 
-- external protocol-backed provider を built-in feature として表現できる API がある。
-- subprocess execution authority が `HostAuthority` または同等の明示 grant として型で表現されている。
-- feature-owned long-running service lifecycle を Pod lifetime に接続できる。
-- discovery 後の dynamic tool contribution が通常 ToolRegistry と permission path に統合される。
-- external metadata / schema / result content が untrusted data として扱われる設計になっている。
-- `list_changed` 相当の dynamic registry change について、safe refresh / next-turn refresh / restart-required diagnostic のいずれかが明示され、silent stale にならない。
-- MCP 実装 Ticket が private/ad-hoc API ではなく、この拡張 API に乗って実装できる見通しがある。
-- focused tests で authority grant、dynamic registration、permission denial、bounded result、service diagnostics を確認できる。
-- Validation: relevant crate tests、`cargo fmt --check`、`cargo check --workspace --all-targets`、`nix build .#yoi`。
+- `pod::feature` can represent a provider/service that becomes ready, fails, and stops with install/runtime diagnostics visible to the host.
+- A mock protocol-backed provider can register at least one startup-discovered dynamic tool before the first model request that would expose its schema.
+- The dynamic tool is registered as an ordinary Yoi tool and is visible through the same model-visible schema path as built-in tools.
+- A PreToolCall permission denial for the dynamic tool prevents the mock provider from receiving a call.
+- Provider failure makes dependent dynamic tools unavailable with a bounded, comprehensible diagnostic rather than panic or stale silent failure.
+- Oversized or structured provider result data is bounded before being committed as a tool result.
+- A simulated list-changed/schema-change event is handled by a documented safe path: turn-boundary refresh, restart/reinitialize-required diagnostic, or explicit unsupported diagnostic.
+- Tests/docs make clear that `pod::feature` is not the Plugin permission layer and not the MCP server trust/sandbox layer.
+- No new `HostAuthority` / authority-grant dependency is introduced for external providers, Plugin permissions, or MCP local stdio execution.
+- Validation: focused feature/provider tests, affected crate tests, `cargo fmt --check`, `cargo check --workspace --all-targets`, and `nix build .#yoi`.
 
 ## Binding decisions / invariants
 
-- ToolRegistry / permission / history / bounded result の既存経路を迂回する API は作らない。
-- external provider 由来の schema / description / annotation / content は instruction ではなく untrusted data として扱う。
-- process execution は explicit authority として分離し、filesystem/network authority から暗黙に派生させない。
-- dynamic registry update は prompt/tool schema consistency と cache behavior を壊さないよう、turn boundary または restart/reinitialize diagnostic を持つ。
-- MCP specific shortcut ではなく、`pod::feature` の長期的な extension surface として成立させる。
+- `pod::feature` is an API/contribution substrate, not a security or trust-policy layer.
+- Plugin is a user-facing package/config/runtime layer that uses `pod::feature`; Plugin permissions are Plugin-layer policy.
+- MCP is a separate feature-backed integration layer; MCP enablement, local server trust, and MCP-specific permissions are MCP-layer policy.
+- Dynamic provider contributions must enter through ordinary Worker / ToolRegistry / permission / history / bounded-result paths.
+- Model-visible tool schemas are stable for the duration of a model request/run.
+- External provider metadata and output are untrusted content.
 
-## Implementation latitude
+## Out of scope
 
-- exact type names、crate placement、service handle の形、dynamic registration timing は実装側に委ねる。
-- 初期実装では rich content を provider-native multimodal block として渡さず、bounded structured text/JSON serialization に寄せてもよい。
-- live registry refresh が大きい場合は、まず restart/reinitialize-required diagnostic でもよい。ただし silent stale は避ける。
+- MCP protocol implementation and local stdio transport details.
+- Plugin package format, distribution, provenance, and Plugin runtime permission grants.
+- OS-level sandboxing of external provider processes.
+- Removing all existing `HostAuthority` code from the repository; cleanup is tracked separately by `00001KV0SP0TY` unless directly necessary for this API slice.
 
 ## Escalation conditions
 
-- current Worker / ToolRegistry architecture では dynamic contribution を安全に扱えない場合。
-- process execution authority と profile/config authority の責務境界が曖昧になる場合。
-- rich content を model-provider native content block に渡す必要が出た場合。
-- hook / feature / plugin contribution boundary の既存設計と矛盾する場合。
+- The feature API appears to need policy decisions about Plugin trust or MCP server permissions.
+- Dynamic registry refresh would require mutating model-visible tool schema during an active run.
+- Provider result normalization would require provider-native multimodal blocks to bypass normal bounded tool-result serialization.
+- MCP implementation pressure suggests adding private ToolRegistry/history/context bypasses instead of extending the feature API.
 
 ## Related work
 
 - Objective: `00001KTR80WMN`
+- MCP implementation: `00001KTR82RB7`
+- Plugin extension surface: `00001KSXRQ4G8`
+- Plugin package/discovery: `00001KT0Z4BK8`
+- Feature authority cleanup: `00001KV0SP0TY`
 - Decomposed from broad Ticket: `00001KST8H4M0`
-- Follow-up implementation Ticket: MCP local stdio implementation Ticket created by this intake split.

.yoi/tickets/00001KTR81P9X/resolution.md

@@ -0,0 +1 @@
+Closed after prior done-state completion.

.yoi/tickets/00001KTR81P9X/thread.md

@@ -4,4 +4,196 @@
 
 LocalTicketBackend によって作成されました。
 
+---
+
+<!-- event: decision author: hare at: 2026-06-13T15:29:21Z -->
+
+## Decision
+
+決定:
+- `pod::feature` は API / contribution substrate として扱い、Plugin や MCP の権限管理を担わせない。
+- Plugin は `pod::feature` をユーザー向け package/config/runtime 形式で使わせる層であり、Plugin permission / trust policy は Plugin layer で定義する。
+- MCP は `pod::feature` 上に protocol-backed integration layer を構築するが、MCP server enablement / command-env-secret policy / trust boundary / MCP-specific permission は MCP layer が独自に持つ。
+- MCP local stdio server の OS-level side effects は Yoi feature authority では制御できないため、feature-layer authority / grant を MCP や Plugin の permission model に流用しない。
+
+反映:
+- `00001KTR81P9X` は authority ではなく provider lifecycle / dynamic contribution / normal ToolRegistry path / untrusted normalization に絞る。
+- `00001KTR82RB7` は MCP 固有の explicit config と trust model を持つ。
+- `00001KSXRQ4G8` と `00001KT0Z4BK8` は Plugin permission を Plugin layer として扱い、MCP を初期 Plugin packaging/runtime から分離する。
+
+
+---
+
+<!-- event: intake_summary author: hare at: 2026-06-13T16:27:15Z -->
+
+## Intake summary
+
+Marked ready by `yoi ticket state`.
+
+---
+
+<!-- event: state_changed author: "yoi ticket" at: 2026-06-13T16:27:15Z from: planning to: ready reason: cli_state field: state -->
+
+## State changed
+
+Marked ready by `yoi ticket state`.
+
+
+---
+
+<!-- event: state_changed author: workspace-panel at: 2026-06-14T06:08:25Z from: ready to: queued reason: queued field: state -->
+
+## State changed
+
+Ticket を `workspace-panel` が queued にしました。
+
+
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-14T06:10:02Z -->
+
+## Decision
+
+Routing decision: implementation_ready
+
+Reason:
+- Ticket is queued and requirements/acceptance criteria for feature-layer provider/service lifecycle and dynamic contributions are specified.
+- Outgoing `depends_on 00001KV0SP0TY` is satisfied: HostAuthority cleanup is done and merged.
+- Relation/orchestration plan checks show no remaining blocker.
+- Scope is API/contribution substrate only; Plugin/MCP permission/trust policy remains out of scope.
+
+IntentPacket:
+- Extend `pod::feature` so protocol-backed providers can contribute startup-discovered tools/services/background lifecycle diagnostics through ordinary ToolRegistry / Worker / permission / history / bounded-result paths.
+
+Binding invariants:
+- Do not introduce `HostAuthority` or replacement feature-layer authority grants.
+- Do not implement MCP protocol/trust policy or Plugin permission policy here.
+- Dynamic schemas must be stable for a run; provider metadata/output is untrusted; tool calls must go through normal permission/history/result paths.
+
+Validation:
+- focused feature/provider tests, affected crate tests, `cargo fmt --check`, `git diff --check`, `cargo check --workspace --all-targets`, and `nix build .#yoi` if feasible.
+
+---
+
+<!-- event: state_changed author: orchestrator at: 2026-06-14T06:10:45Z from: queued to: inprogress reason: orchestrator_acceptance_unblocked field: state -->
+
+## State changed
+
+Ticket evidence, satisfied dependency on HostAuthority cleanup, relation records, orchestration plan, and clean workspace state were checked. No blockers remain; accept for implementation before worktree/spawn side effects.
+
+---
+
+<!-- event: implementation_report author: hare at: 2026-06-14T06:30:42Z -->
+
+## Implementation report
+
+Implemented provider feature API for Ticket 00001KTR81P9X.
+
+Summary:
+- Extended `pod::feature` descriptors with `ProtocolProviderDeclaration` and provider lifecycle state/diagnostic reporting.
+- Added `ProtocolProviderContribution` and `FeatureInstallContext::protocol_providers()` so startup-discovered provider tools, services, and background task declarations register through the existing feature install pipeline.
+- Provider tools are materialized once at startup and then installed as ordinary Worker tool definitions, preserving stable schemas for the run and normal permission/history/bounded-result execution paths.
+- Unavailable providers record lifecycle diagnostics and skip discovered contributions without adding a separate feature authority layer.
+- Added focused tests for ready providers, failed providers, undeclared providers, and stable dynamic tool metadata.
+
+Validation:
+- PASS: `cargo fmt --check`
+- PASS: `cargo test -p pod feature::tests`
+- PASS: `cargo check --workspace --all-targets`
+- PASS: `git diff --check`
+- FAIL (pre-existing/unrelated prompt assertion): `cargo test -p pod` fails in `prompt::catalog::tests::pod_orchestration_guidance_section_renders_resource_body` and `prompt::system::tests::pod_orchestration_guidance_is_included_for_pod_management_tools`, both expecting the phrase `worktree status, diff, and test results`.
+- FAIL (environment/resource): `nix build --no-link .#yoi` compiles through the Rust crates but fails during final binary link with `No space left on device`.
+
+Risks/notes:
+- This does not implement MCP protocol, MCP trust policy, plugin permissions, subprocess management, or a replacement HostAuthority-style grant layer.
+- Provider metadata and diagnostics remain install-report data; actual provider tool execution goes through the normal Worker/tool machinery.
+
+
+---
+
+<!-- event: review author: hare at: 2026-06-14T06:36:23Z status: approve -->
+
+## Review: approve
+
+## Review: approve
+
+Reviewed implementation commit `053a4f90` against Ticket `00001KTR81P9X` and base routing commit `f709fc10`.
+
+Evidence:
+- Diff is limited to the Ticket record and `crates/pod/src/feature.rs`.
+- The provider API extension stays in `pod::feature` as a contribution/reporting substrate: `ProviderId`, `ProtocolProviderDeclaration`, `ProtocolProviderLifecycleState`, `ProtocolProviderContribution`, lifecycle diagnostics, and `FeatureInstallContext::protocol_providers()` were added without introducing `HostAuthority`, grant replacement types, MCP trust policy, plugin permission policy, subprocess management, or ToolRegistry/history bypasses.
+- Startup-discovered provider tools are materialized once during feature installation and then registered through `Worker::register_tools`, preserving stable schemas for the run and normal Worker permission/history/result machinery.
+- Ready providers can contribute tools, service declarations, and background task declarations through the existing feature install report/registry surfaces; unavailable providers record lifecycle diagnostics and skip discovered contributions instead of panicking or installing stale tools.
+- Diagnostics cover undeclared provider ids, duplicate tool names through the shared tool registrar, and failed lifecycle states.
+- API shape is type-oriented and localized; I did not find broad compatibility glue or authority-layer leakage.
+
+Validation performed:
+- PASS `cargo fmt --check`
+- PASS `git diff --check f709fc10..HEAD`
+- PASS `cargo test -p pod feature::tests` (17 passed)
+- PASS `cargo check --workspace --all-targets`
+- FAIL `cargo test -p pod`: 323 passed / 2 failed in the same prompt assertion tests reported by Coder (`prompt::catalog::tests::pod_orchestration_guidance_section_renders_resource_body`, `prompt::system::tests::pod_orchestration_guidance_is_included_for_pod_management_tools`, both expecting `worktree status, diff, and test results`). The reviewed diff does not touch prompt resources or those prompt modules, so I classify this as unrelated/pre-existing for this Ticket.
+
+Risks / notes:
+- I did not rerun `nix build`; Coder reported a final-link `No space left on device` after Rust compilation. Focused Rust validation passed.
+- Permission denial and bounded-result behavior are not reimplemented in this diff; they are intentionally inherited because provider tools are installed as ordinary Worker tools.
+
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-14T06:39:37Z -->
+
+## Implementation report
+
+Integration outcome: merged and validated.
+
+- Implementation branch: `ticket-00001KTR81P9X-feature-provider-api`
+- Implementation commit: `053a4f90 feat: add protocol provider feature contributions`
+- Review commit: `d0e8d791 ticket: approve feature provider api`
+- Orchestrator merge commit: `3d140dbb merge: feature provider api`
+
+Reviewer result:
+- `approve`。Provider API extension stays in the contribution/reporting substrate, does not reintroduce HostAuthority/grants, does not implement MCP trust/plugin permission policy, and uses ordinary ToolRegistry/Worker/history/permission paths.
+
+Orchestrator validation after merge:
+- `cargo fmt --check`: PASS
+- `git diff --check`: PASS
+- `cargo test -p pod feature::tests`: PASS
+- `cargo check --workspace --all-targets`: PASS
+
+Not run:
+- `nix build .#yoi`: skipped at integration because prior Coder run hit host disk pressure during final link; this change did not modify dependencies, Cargo.lock, packaging, or source filters. Recent package validation was performed on adjacent E2E/Profile work.
+
+Residual notes:
+- Full `cargo test -p pod` is known to fail unrelated prompt assertion tests expecting old guidance text. Reviewer classified those as unrelated/pre-existing to this feature API diff.
+
+Next:
+- Mark Ticket done and clean up child coder/reviewer Pods plus implementation worktree/branch.
+
+---
+
+<!-- event: state_changed author: orchestrator at: 2026-06-14T06:39:48Z from: inprogress to: done reason: merged_and_validated field: state -->
+
+## State changed
+
+Implementation branch was reviewed, approved, merged into the Orchestrator branch as `3d140dbb`, and validated in the Orchestrator worktree. Feature-provider focused tests, formatting, diff check, and workspace check passed. Ticket implementation work is done; closure remains separate.
+
+---
+
+<!-- event: state_changed author: hare at: 2026-06-14T14:00:13Z from: done to: closed reason: closed field: state -->
+
+## State changed
+
+Ticket を closed にしました。
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-14T14:00:13Z status: closed -->
+
+## 完了
+
+Closed after prior done-state completion.
+
+
 ---

.yoi/tickets/00001KTR82RB7/item.md

@@ -1,11 +1,11 @@
 ---
 title: 'Implement MCP 2025-11-25 local stdio server-feature bridge'
-state: 'planning'
+state: 'closed'
 created_at: '2026-06-10T07:48:49Z'
-updated_at: '2026-06-10T07:48:49Z'
+updated_at: '2026-06-20T05:33:15Z'
 assignee: null
 readiness: 'blocked'
-risk_flags: ['mcp', 'authority-boundary', 'prompt-context', 'permission-scope', 'secrets', 'process-exec', 'feature-api']
+risk_flags: ['mcp', 'prompt-context', 'permission-scope', 'secrets', 'process-exec', 'feature-api', 'trust-boundary']
 ---
 
 ## Background
@@ -14,12 +14,21 @@ Yoi に MCP integration を追加する。対象は現時点の latest MCP speci
 
 この Ticket は MCP 実装を担当し、`pod::feature` / Worker / ToolRegistry の拡張そのものは別 Ticket `00001KTR81P9X` に分離する。MCP 実装は、その拡張 API に乗り、Yoi の通常 ToolRegistry / permission / history / bounded result path を迂回しない。
 
+MCP は Plugin model そのものではなく、feature API 上に構築される protocol-backed integration layer として扱う。MCP server の enablement、local stdio server trust、command/env/secret policy は MCP layer が独自に持つ。`pod::feature` の authority/grant model で MCP server process の能力を制御する前提は置かない。
+
 Objective context: `00001KTR80WMN`。
 
 ## Requirements
 
 - MCP specification `2025-11-25` を基準にする。
 - local stdio transport の MCP server を explicit Profile/config から有効化できる。
+  - package/discovery や workspace presence だけで auto-start しない。
+  - configured server は local executable としてユーザー権限で動く trust boundary であることを docs/diagnostics に明記する。
+  - Yoi `HostAuthority` は server process の OS-level side effects を sandbox しない。
+- MCP local stdio server の configuration/trust policy を MCP layer で定義する。
+  - command / args / cwd / env / secret refs は明示 config 由来にする。
+  - inherited env の扱いと secret redaction を決める。
+  - command/env/secret values を diagnostics / logs / model context に plaintext で出さない。
 - stdio subprocess lifecycle を実装する。
   - stdin/stdout newline-delimited JSON-RPC。
   - stdout は MCP messages として扱う。
@@ -47,10 +56,10 @@ Objective context: `00001KTR80WMN`。
   - `isError`
   - `_meta`
   - text / image / audio / resource_link / embedded resource
-- roots を実装する場合は Yoi authorized scope 由来の root のみに限定する。
+- roots を実装する場合は、Yoi が server に通知する root を Yoi authorized scope 由来の root のみに限定する。
+  - これは server process 自体の OS filesystem access sandbox ではない。
 - sampling / elicitation は初期実装では client capability として宣言せず、要求された場合は fail-closed diagnostic とする。
 - Streamable HTTP transport / OAuth / remote auth / MCP Registry distribution / automatic package execution はこの Ticket の対象外。
-- secret refs / env values / command args containing secrets を diagnostics / logs / model context に plaintext で出さない。
 - local mock MCP server を使った focused tests を追加する。
 - docs に local stdio MCP server の設定例、trust model、permission/scope/secret guidance を追加する。
 
@@ -59,13 +68,14 @@ Objective context: `00001KTR80WMN`。
 - docs/tests/config で MCP spec baseline `2025-11-25` が明記されている。
 - 少なくとも1つの local stdio MCP server を Profile/config で有効化できる。
 - configured server の initialize 成功/失敗が観測可能で、失敗時に server 名と phase が分かる。
+- docs が local stdio server の trust boundary を明記する: server は明示 config で起動される local executable であり、Yoi feature authority では sandbox されない。
 - discovered MCP tools が namespaced stable name で Yoi の model-visible tool schema に現れる。
 - registered MCP tool を呼ぶと `tools/call` が実行され、normal result / `isError: true` / JSON-RPC protocol error が区別される。
 - `resources/list` / `resources/read` と `prompts/list` / `prompts/get` が明示 tool operations として使え、結果が通常 tool result として history に残る。
 - resource/prompt content は history に残らない形で context に注入されない。
 - `structuredContent` / output schema / rich content blocks が bounded serialization される。
 - list-changed notification が silent stale にならず、safe refresh または restart/reinitialize-required diagnostic として扱われる。
-- PreToolCall permission denial が通常 Yoi tool denial と同じ経路で動く。
+- PreToolCall permission denial が通常 Yoi tool denial と同じ経路で動き、denied call は MCP server に送信されない。
 - server-provided metadata/content が system/developer instruction や Yoi scope/permission を弱めない。
 - secrets が diagnostics/logs/model context に plaintext で出ないことを focused test または review で確認できる。
 - sampling / elicitation / Streamable HTTP / remote auth / distribution は disabled, fail-closed, or explicitly out-of-scope として実装・docs に反映されている。
@@ -74,10 +84,11 @@ Objective context: `00001KTR80WMN`。
 ## Binding decisions / invariants
 
 - MCP server は untrusted external capability provider として扱う。
-- MCP integration は `pod::feature` / Worker / ToolRegistry の通常 authority path に乗せ、private/ad-hoc bypass を作らない。
+- MCP integration は `pod::feature` / Worker / ToolRegistry の通常 contribution path に乗せ、private/ad-hoc bypass を作らない。
+- MCP enablement、local stdio command/env/secret policy、server trust model は MCP layer の責務であり、`pod::feature` の authority/grant には載せない。
 - `resources/read` / `prompts/get` の結果を hidden context injection しない。明示 tool result としてのみ model-visible にする。
-- local process 起動は explicit config と explicit process authority に限る。
-- filesystem roots を公開する場合は Yoi authorized scope 由来に限定する。
+- local process 起動は explicit MCP config と explicit user/workspace policy に限る。feature authority から暗黙に派生させない。
+- filesystem roots を server に公開する場合は Yoi authorized scope 由来に限定する。
 - unsupported client features, including sampling and elicitation, are fail-closed。
 
 ## Implementation latitude
@@ -89,6 +100,7 @@ Objective context: `00001KTR80WMN`。
 ## Escalation conditions
 
 - API extension Ticket `00001KTR81P9X` の完了前に private bypass が必要になりそうな場合。
+- MCP local server trust/permission policy が Plugin permission model または feature API authority と混ざりそうな場合。
 - MCP tasks / task-augmented tool calls を full support するために Yoi Task / approval / resume model との統合判断が必要になる場合。
 - server-provided resource/prompt content を tool result 以外の context path に入れる必要が出た場合。
 - Streamable HTTP、remote auth、sampling、elicitation、workspace-provided executable/package auto-start に踏み込む必要が出た場合。
@@ -97,4 +109,5 @@ Objective context: `00001KTR80WMN`。
 
 - Objective: `00001KTR80WMN`
 - API prerequisite: `00001KTR81P9X`
+- Plugin extension surface: `00001KSXRQ4G8`
 - Decomposed from broad Ticket: `00001KST8H4M0`

.yoi/tickets/00001KTR82RB7/resolution.md

@@ -0,0 +1,13 @@
+Closed as superseded by concrete MCP implementation Tickets.
+
+This Ticket bundled config/trust policy, stdio lifecycle, tools/list registration, tools/call execution, resources/prompts operations, result serialization, and list_changed handling into one broad implementation item. That is too coarse for the current Ticket policy: Tickets should be concrete implementation tasks.
+
+The MCP roadmap now lives in Objective `00001KTR80WMN` (`MCP local stdio integration roadmap`). Concrete follow-up Tickets are:
+- `00001KVHR3WRF` — local stdio server config and trust policy;
+- `00001KVHR3WRY` — stdio JSON-RPC lifecycle client;
+- `00001KVHR3WS6` — server tools registration into ToolRegistry;
+- `00001KVHR3WSD` — tools/call execution through ordinary Tool path;
+- `00001KVHR3WSN` — resources/prompts as explicit tool operations;
+- `00001KVHR3WSW` — list_changed notification handling.
+
+Future MCP work should use those concrete Tickets or similarly scoped follow-ups, not this broad umbrella Ticket.

.yoi/tickets/00001KTR82RB7/thread.md

@@ -4,4 +4,52 @@
 
 LocalTicketBackend によって作成されました。
 
+---
+
+<!-- event: decision author: hare at: 2026-06-13T15:29:21Z -->
+
+## Decision
+
+決定:
+- `pod::feature` は API / contribution substrate として扱い、Plugin や MCP の権限管理を担わせない。
+- Plugin は `pod::feature` をユーザー向け package/config/runtime 形式で使わせる層であり、Plugin permission / trust policy は Plugin layer で定義する。
+- MCP は `pod::feature` 上に protocol-backed integration layer を構築するが、MCP server enablement / command-env-secret policy / trust boundary / MCP-specific permission は MCP layer が独自に持つ。
+- MCP local stdio server の OS-level side effects は Yoi feature authority では制御できないため、feature-layer authority / grant を MCP や Plugin の permission model に流用しない。
+
+反映:
+- `00001KTR81P9X` は authority ではなく provider lifecycle / dynamic contribution / normal ToolRegistry path / untrusted normalization に絞る。
+- `00001KTR82RB7` は MCP 固有の explicit config と trust model を持つ。
+- `00001KSXRQ4G8` と `00001KT0Z4BK8` は Plugin permission を Plugin layer として扱い、MCP を初期 Plugin packaging/runtime から分離する。
+
+
+---
+
+<!-- event: state_changed author: hare at: 2026-06-20T05:33:15Z from: planning to: closed reason: closed field: state -->
+
+## State changed
+
+Ticket を closed にしました。
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-20T05:33:15Z status: closed -->
+
+## 完了
+
+Closed as superseded by concrete MCP implementation Tickets.
+
+This Ticket bundled config/trust policy, stdio lifecycle, tools/list registration, tools/call execution, resources/prompts operations, result serialization, and list_changed handling into one broad implementation item. That is too coarse for the current Ticket policy: Tickets should be concrete implementation tasks.
+
+The MCP roadmap now lives in Objective `00001KTR80WMN` (`MCP local stdio integration roadmap`). Concrete follow-up Tickets are:
+- `00001KVHR3WRF` — local stdio server config and trust policy;
+- `00001KVHR3WRY` — stdio JSON-RPC lifecycle client;
+- `00001KVHR3WS6` — server tools registration into ToolRegistry;
+- `00001KVHR3WSD` — tools/call execution through ordinary Tool path;
+- `00001KVHR3WSN` — resources/prompts as explicit tool operations;
+- `00001KVHR3WSW` — list_changed notification handling.
+
+Future MCP work should use those concrete Tickets or similarly scoped follow-ups, not this broad umbrella Ticket.
+
+
 ---

.yoi/tickets/00001KTTW04W2/artifacts/orchestration-plan.jsonl

@@ -0,0 +1,2 @@
+{"id":"orch-plan-20260611-160703-1","ticket_id":"00001KTTW04W2","kind":"accepted_plan","note":"Role Pods は今回起動しない。","accepted_plan":{"summary":"Routing では implementation_ready と判断した。ただし今回の launch instruction は role Pod spawn を explicit follow-up まで待つ指定のため、現時点では queued のまま保持し、worktree 作成・Pod 起動・merge/close は行わない。実装開始時は side effect 前に改めて blocker/workspace state を確認し、queued -> inprogress を記録してから進める。実装対象は Method::Notify の auto_run 追加、idle auto-run 抑止、live Companion への bounded progress notify、Panel freshness 表示、targeted tests。","branch":"ticket/orchestrator-progress-companion-notify","worktree":"/home/hare/Projects/yoi/.worktree/orchestrator-progress-companion-notify","role_plan":"次の明示 follow-up 後に Orchestrator が worktree-workflow で実装 worktree を作り、coder はその worktree に narrow write scope、reviewer は read-only scopeで sibling として起動する。Companion/Orchestrator/Ticket 権限境界、history-backed context、weak/best-effort notification、bounded/sensitive-safe summary を reviewer focus とする。"},"author":"orchestrator","at":"2026-06-11T16:07:03Z"}
+{"id":"orch-plan-20260613-032948-2","ticket_id":"00001KTTW04W2","kind":"accepted_plan","accepted_plan":{"summary":"再設計方針: Panel からは送らない。Orchestrator が Ticket tool で state/comment/review/close などの明示 Ticket event を記録した時だけ、live/reachable Companion へ bounded event notice を `Notify { auto_run:false }` で送る。長文 snapshot / periodic reload / polling / scheduler / auto-kick は作らない。既存 `Method::Notify { auto_run }` 互換部分は保持する。","branch":"ticket/orchestrator-ticket-event-companion-notify","worktree":"/home/hare/Projects/yoi/.worktree/orchestrator-ticket-event-companion-notify","role_plan":"Coder は child worktree に限定して、Panel reload ではなく Orchestrator/Pod 側の明示的な Ticket event に連動する Companion weak notification を実装する。Reviewer は read-only で、Panel 非依存、snapshot feed 不在、通知粒度、history-backed Notify、Companion authority 不変、`auto_run:false` semantics を確認する。"},"author":"orchestrator","at":"2026-06-13T03:29:48Z"}

.yoi/tickets/00001KTTW04W2/item.md

@@ -1,9 +1,11 @@
 ---
 title: 'Orchestrator進捗をAutoKickなしでCompanionへ通知する'
-state: 'planning'
+state: 'closed'
 created_at: '2026-06-11T08:15:24Z'
-updated_at: '2026-06-11T08:15:24Z'
+updated_at: '2026-06-13T04:22:26Z'
 assignee: null
+queued_by: 'workspace-panel'
+queued_at: '2026-06-11T10:31:56Z'
 ---
 
 ## 背景

.yoi/tickets/00001KTTW04W2/resolution.md

@@ -0,0 +1,38 @@
+Orchestrator の明示 Ticket event を Companion に weak notify する形へ再実装した。
+
+実装概要:
+- 以前の Panel reload / periodic refresh 起点の Companion progress feed は削除済みで、今回の実装でも再導入していない。
+- Orchestrator-role lifecycle Ticket tool の post-call event に限定して、live/reachable Companion peer へ `Notify { auto_run:false }` を送る。
+- 対象 event は state change、comment/plan/decision/implementation_report、review、close/resolution 系の explicit mutating Ticket event。
+- Passive Ticket reads/list/show/query では通知しない。
+- missing/stopped/unreachable Companion は no-op とし、spawn/restore しない。
+- Companion authority は増やしていない。
+- Payload は Ticket id/title/state、event kind、short summary、`.yoi/tickets/<id>` ref 程度の bounded event notice に限定し、Ticket list snapshot、full thread、Pod output、diagnostics、provider error details、長大 log は含めない。
+- LLM-facing notice framing は `resources/prompts/pod/ticket_event_companion_notice.md` に置き、Rust は bounded runtime values の構築と render に限定した。
+
+Review / integration:
+- Implementation commits:
+  - `465ef100 feat: notify Companion on Orchestrator ticket events`
+  - `6f8571f7 fix: render ticket event notice from prompt resource`
+- Reviewer: `yoi-reviewer-event-companion-notify` が approve。
+- Orchestrator merge commit: `2e5a60f4 merge: companion ticket event notify`
+- Ticket completion commit: `ee6213ee ticket: mark event companion notify done`
+
+Validation:
+- `cargo test -p pod ticket_event_notify`: pass
+- `cargo test -p pod ticket_event`: pass
+- `cargo test -p pod weak_notify_to_live_peer_uses_notify_without_auto_run_and_noops_when_missing`: pass
+- `cargo test -p tui companion_progress`: pass（0 matched; Panel feed remains absent）
+- `rg` check confirmed no `companion_progress` / progress feed / `send_weak_notify` references in `crates/tui/src/multi_pod.rs`
+- `cargo fmt --check`: pass
+- `git diff --check HEAD~1..HEAD`: pass
+- `./result/bin/yoi ticket doctor`: `doctor: ok`
+- `nix build .#yoi`: pass
+
+Cleanup:
+- coder/reviewer Pods stopped。
+- child worktree `/home/hare/Projects/yoi/.worktree/orchestrator-ticket-event-companion-notify` removed。
+- branch `ticket/orchestrator-ticket-event-companion-notify` deleted。
+
+Non-blocking note:
+- Panel 非通知は TUI diff absence / `rg` check と focused behavior tests で確認した。将来の回帰防止として、Panel reload/open が Companion event notify を呼ばない明示 test を追加してもよい。

.yoi/tickets/00001KTTW04W2/thread.md

@@ -5,3 +5,777 @@
 LocalTicketBackend によって作成されました。
 
 ---
+
+<!-- event: intake_summary author: intake at: 2026-06-11T10:21:40Z -->
+
+## Intake summary
+
+既存 Ticket 00001KTTW04W2 の body/thread/artifacts と関連 Ticket を確認した。これは implementation_ready。範囲は Orchestrator の progress を Companion に read-only weak notification として渡すことであり、AutoKick / re-kick / scheduler ではない。`Method::Notify` に `auto_run: bool` を追加し、Companion progress notice では `auto_run: false` を使う。`auto_run:false` は idle Pod を起こさず NotifyBuffer に積むだけで、live/reachable Companion への best-effort delivery に限定し、missing/stopped Companion の spawn/restore や初期 persistent snapshot は行わない。通知内容は durable/queryable state から bounded に生成し、history に残らない context-only injection、secret/unbounded log、Companion への mutation/spawn/merge authority 付与は禁止。関連の Companion lifecycle/profile policy は closed 済みで、この Ticket は starvation prevention Ticket 00001KTJXS31R とは非重複の follow-up。blocking open questions はない。risk_flags: [notification-semantics, panel-lifecycle, companion-policy, authority-boundary, prompt-context, persistence, sensitive-content]。
+
+---
+
+<!-- event: state_changed author: intake at: 2026-06-11T10:21:40Z from: planning to: ready reason: intake_ready field: state -->
+
+## State changed
+
+Intake refinement により、AutoKick/re-kick との差分、Companion authority 境界、weak notification semantics、bounded/safe context、validation focus が整理され、Orchestrator が routing できる状態になった。
+
+---
+
+<!-- event: state_changed author: workspace-panel at: 2026-06-11T10:31:56Z from: ready to: queued reason: queued field: state -->
+
+## State changed
+
+Ticket を `workspace-panel` が queued にしました。
+
+
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-11T16:07:34Z -->
+
+## Decision
+
+Routing decision: implementation_ready（spawn は explicit follow-up まで保留）
+
+Reason:
+- Ticket body/thread は Orchestrator progress を Companion に read-only weak notification として渡す範囲を十分に固定している。
+- AutoKick / re-kick / scheduler 化は非目標として明示されており、Companion authority 強化、missing/stopped Companion の spawn/restore、persistent snapshot 初期導入、context-only injection、secret/unbounded log 流入も禁止されている。
+- 残る不確実性は既存 Notify / Panel / Companion 実装内での local tactic selection と targeted tests に閉じており、実装前に人間が追加で固定すべき product/API/authority decision は見つからない。
+- 今回の launch instruction は「explicit follow-up before spawning role Pods」なので、ここでは queued -> inprogress、worktree 作成、coder/reviewer spawn は行わない。
+
+Evidence checked:
+- Ticket item/thread: Background、Requirements、Binding decisions / invariants、受け入れ条件、非目標、intake_summary、ready -> queued event。
+- TicketRelationQuery: relation なし。unresolved depends_on / incoming blocks なし。
+- TicketOrchestrationPlanQuery: 既存 plan なし。今回 accepted_plan を記録済み。
+- TicketDoctor: error 0。
+- repository state: `/home/hare/Projects/yoi` は dirty file なし、`develop...origin/develop [ahead 3]`。
+- worktree/branch state: 既存 implementation worktree はなし。`ticket/orchestrator-progress-companion-notify` branch は存在するが `origin/develop` 相当で、実装開始時に merge target の現 HEAD との整合を確認する。
+- bounded code map: `crates/protocol/src/lib.rs` の `Method::Notify`、`crates/pod/src/controller.rs` の Notify handling / RunForNotification、`crates/tui/src/multi_pod.rs` と workspace panel 周辺、`resources/profiles/companion.lua` / profile feature policy。
+
+IntentPacket:
+
+Intent:
+- Orchestrator の Ticket 消化 progress を、live/reachable Companion に read-only weak notification として届け、Panel からその progress context の鮮度/last updated を確認できるようにする。
+
+Binding decisions / invariants:
+- `Notify { auto_run: false }` は idle Pod を起こさず、RunForNotification を staged しない。
+- progress notice は AutoKick / re-kick / scheduler trigger にしない。
+- Companion が missing/stopped の場合、通知だけで spawn/restore しない。
+- 初期実装では persistent progress snapshot store を導入しない。
+- Companion default profile の tool/feature policy を強化せず、Ticket mutation / Pod spawn / merge / worktree cleanup authority を与えない。
+- Companion model context に渡す情報は history に残る形で扱い、history に残らない transient context-only injection をしない。
+- 通知内容は durable/queryable state から bounded に生成し、secret/private context、sensitive provider error detail、unbounded logs、全 Ticket thread / Pod output を含めない。
+- Prompt / workflow の LLM-facing framing を Rust code に直書きしない。必要なら `resources/prompts` 側に置く。
+
+Requirements / acceptance criteria:
+- live/reachable Companion が `Notify { auto_run: false }` 経由で Orchestrator progress notice を受け取れる。
+- missing/stopped Companion では spawn/restore せず、best-effort delivery に留める。
+- bounded summary generation と sensitive/unbounded content 排除が testable である。
+- Panel から Companion progress context の鮮度または last updated が分かる。
+- targeted tests を追加/更新する。
+
+Implementation latitude:
+- `auto_run` の serialization default / migration details、delivery helper の配置、Panel freshness 表示の具体的 UI placement、summary builder の内部構造、test の分割は既存設計に沿う範囲で coder が選んでよい。
+- 既存 branch/worktree の扱いは実装開始時に Orchestrator が再確認し、merge target と整合する安全な branch/worktree で進める。
+
+Escalate if:
+- Companion に新しい mutation/spawn/merge authority を持たせる必要が出た場合。
+- `auto_run:false` が history-backed notification 以外の hidden context injection を要求する場合。
+- missing/stopped Companion 向け persistent snapshot store が初期実装の必須要件になりそうな場合。
+- Method/Protocol の互換性・serde 形式で既存 session/log を壊す設計変更が必要になった場合。
+- Progress notice が scheduler / AutoKick / re-kick の実行契機になりそうな場合。
+
+Validation:
+- targeted tests for `Method::Notify { auto_run: false }` idle behavior, live Companion delivery, missing/stopped no spawn/restore, bounded summary, sensitive/unbounded exclusion。
+- `cargo test -p tui` または該当 targeted tests。
+- `cargo fmt --check`。
+- `git diff --check`。
+- `/home/hare/Projects/yoi/target/debug/yoi ticket doctor`。
+- runtime resource / prompt / packaging に触れた場合は `nix build .#yoi`。
+
+Current code map:
+- `crates/protocol/src/lib.rs`: `Method::Notify` schema / request handling type。
+- `crates/pod/src/controller.rs`: `Notify` handling、NotifyBuffer、RunForNotification staging。
+- `crates/tui/src/multi_pod.rs` / workspace panel 周辺: Companion delivery and freshness UI。
+- `resources/profiles/companion.lua` and profile policy code: Companion authority remains read-only/limited。
+
+Critical risks / reviewer focus:
+- `auto_run:false` が idle Companion を起こしていないこと。
+- progress notification が Orchestrator scheduler / AutoKick / re-kick と結合していないこと。
+- Companion authority が増えていないこと。
+- context は history-backed で、hidden transient injection になっていないこと。
+- bounded/sensitive-safe summary が enforced/tested されていること。
+- missing/stopped Companion で spawn/restore しないこと。
+
+Next action:
+- ユーザー/上位 Orchestrator から実装開始の explicit follow-up が来たら、side effect 前に TicketShow / relation / orchestration plan / git/worktree state を再確認し、問題なければ `queued -> inprogress` を記録してから worktree 作成と sibling coder/reviewer routing に進む。
+
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-12T14:50:56Z -->
+
+## Decision
+
+Routing follow-up: implementation start authorized by user.
+
+Recheck summary:
+- Ticket remains `queued` and previously recorded `implementation_ready` still applies.
+- TicketRelationQuery: no unresolved `depends_on` / incoming `blocks` for this Ticket.
+- TicketOrchestrationPlan: accepted plan `orch-plan-20260611-160703-1` names branch/worktree and defers implementation until explicit follow-up; that follow-up has now arrived.
+- Orchestrator worktree is clean.
+- Visible active work: `00001KTVJFT6F` has coder `yoi-coder-panel-focus-model` running on a separate branch/worktree. There may be minor overlap in `crates/tui/src/multi_pod.rs` around Panel UI, so coder/reviewer must keep the Panel freshness change narrow and integration will recheck conflicts before merge.
+
+Decision:
+- Accept this Ticket now and proceed to `queued -> inprogress` before worktree/Pod side effects.
+- Use existing accepted plan branch `ticket/orchestrator-progress-companion-notify` and worktree `/home/hare/Projects/yoi/.worktree/orchestrator-progress-companion-notify`.
+- Continue to avoid root/original workspace operations; implementation side effects are limited to the child worktree and sibling Pods.
+
+---
+
+<!-- event: state_changed author: orchestrator at: 2026-06-12T14:51:03Z from: queued to: inprogress reason: orchestrator_acceptance field: state -->
+
+## State changed
+
+Explicit user follow-up authorized starting the previously accepted implementation plan. Ticket body/thread, relation blockers, accepted orchestration plan, current Orchestrator workspace state, and visible active work were rechecked. No unresolved blocker or missing planning decision remains. Implementation side effects will start only after this accepted `queued -> inprogress` transition is recorded.
+
+---
+
+<!-- event: plan author: orchestrator at: 2026-06-12T14:51:31Z -->
+
+## Plan
+
+Implementation worktree created for multi-agent handoff.
+
+- Ticket: `00001KTTW04W2`
+- Branch: `ticket/orchestrator-progress-companion-notify`
+- Worktree: `/home/hare/Projects/yoi/.worktree/orchestrator-progress-companion-notify`
+- Base: Orchestrator workspace HEAD `05fe1f6f` (`orchestration/yoi-orchestrator`), including the accepted routing record and `queued -> inprogress` transition.
+- Concurrent work note: `00001KTVJFT6F` is active in `/home/hare/Projects/yoi/.worktree/panel-focus-composer-row-selection`; any Panel UI edits should be narrow and integration will recheck conflict risk.
+- Scope rule: implementation work happens only in this child worktree. Root/original workspace must not be read, written, validated, merged, cleaned, or used for git operations.
+- Next: spawn sibling coder with narrow write scope to the implementation worktree. Reviewer will be started after coder evidence is available.
+
+---
+
+<!-- event: plan author: orchestrator at: 2026-06-12T14:52:34Z -->
+
+## Plan
+
+Coder delegated.
+
+- Coder Pod: `yoi-coder-companion-progress-notify`
+- Worktree: `/home/hare/Projects/yoi/.worktree/orchestrator-progress-companion-notify`
+- Branch: `ticket/orchestrator-progress-companion-notify`
+- Scope: write `/home/hare/Projects/yoi/.worktree/orchestrator-progress-companion-notify`; read child worktree plus minimal non-recursive runtime-root read required by spawn validation.
+- Task: implement `Notify { auto_run: false }` weak progress notification semantics, bounded Orchestrator progress summary delivery to live/reachable Companion, missing/stopped no spawn/restore behavior, Panel freshness/last-updated indication, focused tests, and required validation.
+- Concurrent work note: `00001KTVJFT6F` has active coder work in another worktree and may edit Panel UI; coder was instructed to keep Panel changes narrow and report overlap if it becomes a blocker.
+- Constraint: coder was instructed not to use root/original workspace for decision evidence or git/validation/cleanup, and not to create generated memory/local/runtime/log/lock/secret-like `.yoi` paths.
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-12T15:23:02Z -->
+
+## Implementation report
+
+Coder completed implementation and branch was synchronized with current Orchestrator HEAD before review.
+
+Coder Pod:
+- `yoi-coder-companion-progress-notify`
+
+Implementation branch/worktree:
+- Branch: `ticket/orchestrator-progress-companion-notify`
+- Worktree: `/home/hare/Projects/yoi/.worktree/orchestrator-progress-companion-notify`
+- Implementation commit: `a87d3154 feat: weak companion progress notify`
+- Sync merge commit on implementation branch: `724b79f1 Merge branch 'orchestration/yoi-orchestrator' into ticket/orchestrator-progress-companion-notify`
+- Worktree status: clean
+
+Changed surfaces:
+- `crates/protocol/src/lib.rs`
+- `crates/pod/src/controller.rs`
+- `crates/pod/src/discovery.rs`
+- `crates/pod/tests/controller_test.rs`
+- `crates/tui/src/multi_pod.rs`
+
+Implementation summary:
+- Added `Method::Notify { auto_run: bool }`; missing `auto_run` defaults to `true`, `true` serializes like the old shape, and `false` is explicit.
+- Idle Pod `Notify { auto_run: false }` does not stage `RunForNotification`; explicit next run drains notification history-backed through existing paths.
+- Existing peer notify/discovery paths keep `auto_run: true`.
+- Panel sends bounded progress notices to live/reachable Companion only via weak `Notify { auto_run: false }`.
+- Missing/stopped/unreachable Companion is best-effort no-op; no spawn/restore.
+- Progress summary is bounded to Ticket id/title/state, role pod status, and `.yoi/tickets/<id>` refs; no full thread, long output, diagnostics, provider errors, or secret-like content.
+- Panel title shows Companion progress freshness/last-updated without adding a persistent snapshot store.
+- Companion profile/tool authority is unchanged.
+
+Orchestrator-verified evidence from child worktree after sync with current Orchestrator branch:
+- `git status --short --branch`: clean on `ticket/orchestrator-progress-companion-notify`
+- `cargo test -p protocol`: pass, 39 tests
+- `cargo test -p pod --test controller_test`: pass, 36 tests
+- `cargo test -p tui companion_progress -- --nocapture`: pass, 5 tests
+- `cargo test -p tui send_notify_only_can_deliver_weak_notification_without_auto_run -- --nocapture`: pass, 1 test
+- `cargo check -p protocol -p pod -p tui`: pass
+- `cargo fmt --check`: pass
+- `git diff --check orchestration/yoi-orchestrator...HEAD`: pass
+- `cargo run -p yoi -- ticket doctor`: `doctor: ok`
+- `nix build .#yoi`: pass
+
+Known unrelated validation failures from coder full-suite notes:
+- `cargo test -p pod` still fails existing prompt-resource assertion tests: `worker_instruction_override_from_resources`, `worker_instruction_uses_resource_template`.
+- `cargo test -p tui` still fails existing tests: `multi_pod::tests::orchestrator_launch_context_includes_ticket_and_workspace_facts`, `multi_pod::tests::spawn_or_restore_companion_restores_live_pod`, `multi_pod::tests::spawn_or_restore_companion_spawns_missing_pod`.
+- Focused weak-notify/progress tests pass; reviewer should confirm the broad failures are unrelated/pre-existing and not introduced by this Ticket.
+
+Next:
+- Spawn read-only sibling reviewer against the recorded intent, binding decisions/invariants, acceptance criteria, implementation commit `a87d3154`, synced review head `724b79f1`, diff, validation evidence, and known broad-suite failures.
+
+---
+
+<!-- event: plan author: orchestrator at: 2026-06-12T15:23:52Z -->
+
+## Plan
+
+Reviewer delegated.
+
+- Reviewer Pod: `yoi-reviewer-companion-progress-notify`
+- Target branch/worktree: `ticket/orchestrator-progress-companion-notify` at `/home/hare/Projects/yoi/.worktree/orchestrator-progress-companion-notify`
+- Implementation commit: `a87d3154 feat: weak companion progress notify`
+- Synced review head: `724b79f1 Merge branch 'orchestration/yoi-orchestrator' into ticket/orchestrator-progress-companion-notify`
+- Scope: read-only child worktree plus minimal non-recursive runtime-root read required by spawn validation.
+- Review basis: recorded IntentPacket, binding decisions/invariants, acceptance criteria, implementation summary, diff after syncing with current Orchestrator branch, focused validation evidence, `nix build` evidence, and known broad-suite failures.
+- Reviewer focus: no AutoKick/re-kick/scheduler behavior, legacy notify compatibility, bounded/history-backed progress notices, missing/stopped Companion no-op, no authority expansion, Panel freshness UI compatibility with merged focus model, and robust focused tests.
+
+---
+
+<!-- event: review author: reviewer:yoi-reviewer-companion-progress-notify at: 2026-06-12T15:30:03Z status: request_changes -->
+
+## Review: request changes
+
+Request changes.
+
+Blocker:
+- `crates/tui/src/multi_pod.rs` の `companion_progress_notice()` が、Companion の model context に入る progress notice の framing 文言を Rust に直書きしている。
+- この notice は `dispatch_companion_progress_notice()` から `Notify { auto_run: false }` として送られ、NotifyBuffer 経由で history-backed な SystemItem / LLM context になるため、単なる Panel UI 文言ではなく LLM-facing framing と判断する。
+- Ticket の明示要件「Prompt / workflow 文言を Rust code に直書きしない」「LLM-facing summary framing が必要な場合は `resources/prompts` 側に置く」に反している。
+
+Requested change:
+- Rust 側は bounded runtime values の組み立てに留める。
+- progress notice の framing/template は `resources/prompts` 配下へ移す。
+- template/resource rendering の focused test を追加または既存 `companion_progress` tests を更新し、framing が resource 側から来ることと bounded/sensitive-safe values が維持されることを確認する。
+
+Good evidence confirmed:
+- `auto_run:false` は idle Pod に `RunForNotification` を staged しない。
+- `auto_run:true` と legacy missing field の挙動は維持されている。
+- live/reachable Companion の socket に `Notify { auto_run: false }` を送るだけで、missing/stopped/unreachable では spawn/restore されない。
+- 通知内容は Ticket id/title/state、role pod status、short reason、`.yoi/tickets/<id>` ref に絞られ、thread excerpt / diagnostics / provider error token はテストで除外確認されている。
+- Companion profile / authority 強化は diff 上ない。
+- Panel freshness は header detail 表示で、composer target / row selection の focus model には干渉していない。
+
+Reviewer-run validation:
+- `git diff --check orchestration/yoi-orchestrator...HEAD`: pass
+- `cargo test -p protocol`: pass, 39 tests
+- `cargo test -p pod --test controller_test`: pass, 36 tests
+- `cargo test -p tui companion_progress -- --nocapture`: pass, 5 tests
+- `cargo test -p tui send_notify_only_can_deliver_weak_notification_without_auto_run -- --nocapture`: pass, 1 test
+- `cargo check -p protocol -p pod -p tui`: pass
+- `cargo fmt --check`: pass
+- `cargo run -p yoi -- ticket doctor`: `doctor: ok`
+- `nix build .#yoi`: pass
+
+Broad-suite failures:
+- `cargo test -p pod` currently fails 2 prompt-resource assertion tests.
+- `cargo test -p tui` currently fails 3 unrelated-looking tests.
+- These broad-suite failures do not appear caused by the progress-notify diff and are not the requested-change blocker.
+
+---
+
+<!-- event: plan author: orchestrator at: 2026-06-12T15:31:01Z -->
+
+## Plan
+
+Fix loop delegated to coder.
+
+Reviewer blocker:
+- `companion_progress_notice()` hard-coded LLM-facing progress notice framing in Rust.
+- The notice reaches Companion model context through `Notify { auto_run: false }` / NotifyBuffer, so it must follow the prompt-resource boundary.
+
+Coder fix request:
+- Move progress notice framing/template to `resources/prompts` using existing resource conventions.
+- Keep Rust limited to bounded runtime values and resource rendering/loading.
+- Preserve weak notify semantics, live/reachable-only delivery, missing/stopped no spawn/restore, bounded/sensitive-safe summary, no persistent snapshot store, and no authority expansion.
+- Add/update focused tests proving resource-backed framing and bounded/sensitive-safe runtime values.
+
+Status:
+- Sent fix request to `yoi-coder-companion-progress-notify` on existing branch/worktree.
+- Reviewer verdict remains `request_changes` until coder fix and second review.
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-12T15:40:14Z -->
+
+## Implementation report
+
+Coder completed requested fix.
+
+Coder Pod:
+- `yoi-coder-companion-progress-notify`
+
+Implementation branch/worktree:
+- Branch: `ticket/orchestrator-progress-companion-notify`
+- Worktree: `/home/hare/Projects/yoi/.worktree/orchestrator-progress-companion-notify`
+- Original implementation commit: `a87d3154 feat: weak companion progress notify`
+- Sync merge commit: `724b79f1 Merge branch 'orchestration/yoi-orchestrator' into ticket/orchestrator-progress-companion-notify`
+- Fix commit: `61e6c068 fix: resource-back companion progress notice`
+- Worktree status: clean
+
+Fix summary:
+- Added `resources/prompts/panel/companion_progress_notice.md` for model-facing Companion progress notice framing.
+- Removed hard-coded progress notice framing from Rust.
+- Rust now builds bounded runtime values and renders the prompt resource via `minijinja`.
+- Added focused test proving the notice renders from the prompt resource.
+- Preserved live/reachable-only delivery, missing/stopped no-op, `auto_run:false`, bounded output, sensitive-field exclusion, and no persistent snapshot store.
+- Added `minijinja` to `crates/tui/Cargo.toml`, updated `Cargo.lock`, and updated `package.nix` `cargoHash` for Nix packaging.
+
+Orchestrator-verified evidence from child worktree after fix:
+- `git status --short --branch`: clean on `ticket/orchestrator-progress-companion-notify`
+- `cargo test -p protocol`: pass, 39 tests
+- `cargo test -p pod --test controller_test`: pass, 36 tests
+- `cargo test -p tui companion_progress -- --nocapture`: pass, 6 tests
+- `cargo test -p tui send_notify_only_can_deliver_weak_notification_without_auto_run -- --nocapture`: pass, 1 test
+- `cargo check -p protocol -p pod -p tui`: pass
+- `cargo fmt --check`: pass
+- `git diff --check orchestration/yoi-orchestrator...HEAD`: pass
+- `cargo run -p yoi -- ticket doctor`: `doctor: ok`
+- `nix build .#yoi`: pass
+
+Next:
+- Request reviewer re-review of fix commit `61e6c068`, focusing on the prompt-resource boundary blocker, retention of weak notify safety invariants, dependency/package updates, and validation evidence.
+
+---
+
+<!-- event: review author: reviewer:yoi-reviewer-companion-progress-notify at: 2026-06-12T15:42:21Z status: approve -->
+
+## Review: approve
+
+Approve.
+
+The previous requested-change blocker is resolved.
+
+Review findings:
+- Prompt/resource boundary is now satisfied:
+  - Companion progress notice framing lives in `resources/prompts/panel/companion_progress_notice.md`.
+  - Rust only builds bounded runtime values and renders the prompt resource via `minijinja`.
+  - `COMPANION_PROGRESS_NOTICE_TEMPLATE` uses `include_str!` to load the resource.
+  - `render_companion_progress_notice_template()` renders with strict `minijinja` undefined behavior.
+  - Focused test `companion_progress_notice_uses_prompt_resource_template` confirms rendering comes from the resource.
+  - Grep for prior hard-coded framing found no Rust production copy of the prompt text; only test assertion remains.
+- Weak notify invariants remain intact:
+  - Companion progress dispatch still uses `send_notify_only(..., false)`.
+  - `auto_run:false` controller behavior remains covered by pod controller tests.
+  - `auto_run:true` legacy behavior remains covered by protocol/controller tests.
+- Missing/stopped/unreachable Companion remains no-op:
+  - Target selection still requires Companion panel state to be peer-reachable and a live reachable socket.
+  - No spawn/restore path is introduced for progress delivery.
+- No Companion authority expansion found:
+  - The fix touches prompt rendering, TUI dependency metadata, `Cargo.lock`, and `package.nix`; it does not alter Companion profile/tool authority.
+- Bounded/sensitive-safe summary remains preserved:
+  - Runtime values are bounded before/after rendering.
+  - The summary still uses ticket id/state/title/ref and role pod status, not thread excerpts, diagnostics, Pod output, or provider error details.
+- Dependency/package updates are appropriate:
+  - `minijinja = "2.19.0"` is already used elsewhere in the workspace (`crates/pod`), so adding it to `crates/tui` does not introduce an unexpected new dependency family.
+  - `Cargo.lock` and `package.nix` `cargoHash` were updated, and `nix build .#yoi` passes.
+
+Reviewer-run validation:
+- `git diff --check orchestration/yoi-orchestrator...HEAD`: pass
+- `cargo test -p tui companion_progress -- --nocapture`: pass, 6 tests
+- `cargo test -p tui send_notify_only_can_deliver_weak_notification_without_auto_run -- --nocapture`: pass, 1 test
+- `cargo check -p protocol -p pod -p tui`: pass
+- `cargo fmt --check`: pass
+- `cargo run -p yoi -- ticket doctor`: `doctor: ok`
+- `nix build .#yoi`: pass
+- `cargo test -p protocol`: pass, 39 tests
+- `cargo test -p pod --test controller_test`: pass, 36 tests
+
+No blocking issues remain.
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-12T15:43:51Z -->
+
+## Implementation report
+
+Integration completed in the Orchestrator workspace.
+
+Integrated implementation:
+- Ticket: `00001KTTW04W2`
+- Implementation branch: `ticket/orchestrator-progress-companion-notify`
+- Implementation commits:
+  - `a87d3154 feat: weak companion progress notify`
+  - `61e6c068 fix: resource-back companion progress notice`
+- Reviewer result: approve after fix-loop, no blockers remain
+- Orchestrator merge commit: `56b10a2d merge: companion weak progress notify`
+- Integration target: `orchestration/yoi-orchestrator`
+
+Post-integration validation from Orchestrator worktree:
+- `cargo test -p protocol`: pass, 39 tests
+- `cargo test -p pod --test controller_test`: pass, 36 tests
+- `cargo test -p tui companion_progress -- --nocapture`: pass, 6 tests
+- `cargo test -p tui send_notify_only_can_deliver_weak_notification_without_auto_run -- --nocapture`: pass, 1 test
+- `cargo check -p protocol -p pod -p tui`: pass
+- `cargo fmt --check`: pass
+- `git diff --check HEAD~1..HEAD`: pass
+- `./result/bin/yoi ticket doctor`: `doctor: ok`
+- `nix build .#yoi`: pass
+
+Fix-loop resolution:
+- Reviewer blocker about Rust-hard-coded LLM-facing progress notice framing was resolved by moving framing to `resources/prompts/panel/companion_progress_notice.md` and rendering it from bounded runtime values.
+
+Remaining known broad-suite failures:
+- Existing prompt/TUI broad-suite failures noted earlier remain outside this Ticket and were not blockers for the focused implementation/review.
+
+Remaining risks:
+- None blocking. Added `minijinja` dependency to `crates/tui`, already used elsewhere in workspace; `Cargo.lock` and `package.nix` were updated and Nix build passed.
+
+---
+
+<!-- event: state_changed author: orchestrator at: 2026-06-12T15:43:57Z from: inprogress to: done reason: implementation_merged_and_validated field: state -->
+
+## State changed
+
+Implementation was merged into the Orchestrator branch after reviewer-requested fix, reviewer approved with no blockers, and post-integration validation passed. Cleanup and closure will be recorded next.
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-12T15:44:26Z -->
+
+## Implementation report
+
+Cleanup completed.
+
+- Stopped coder Pod: `yoi-coder-companion-progress-notify`
+- Stopped reviewer Pod: `yoi-reviewer-companion-progress-notify`
+- Removed child worktree: `/home/hare/Projects/yoi/.worktree/orchestrator-progress-companion-notify`
+- Deleted implementation branch: `ticket/orchestrator-progress-companion-notify`
+- Orchestrator worktree status after cleanup: clean
+
+Cleanup was limited to child implementation worktree/branch and related child Pods. Root/original workspace was not touched.
+
+---
+
+<!-- event: state_changed author: hare at: 2026-06-12T15:44:42Z from: done to: closed reason: closed field: state -->
+
+## State changed
+
+Ticket を closed にしました。
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-12T15:44:42Z status: closed -->
+
+## 完了
+
+Orchestrator progress を AutoKick なしで live/reachable Companion に通知する仕組みを実装した。
+
+実装概要:
+- `Method::Notify { auto_run: bool }` を追加し、`auto_run: false` では idle Pod に `RunForNotification` を stage しない weak notification にした。
+- `auto_run: true` と legacy missing-field behavior は既存 Notify と互換にした。
+- Panel から live/reachable Companion へ bounded progress notice を `Notify { auto_run: false }` で送るようにした。
+- missing/stopped/unreachable Companion は best-effort no-op とし、spawn/restore しない。
+- Progress summary は Ticket id/title/state、role pod status、short reason、`.yoi/tickets/<id>` refs に限定し、full thread、Pod output、diagnostics、provider errors、secret-like content を含めない。
+- Panel に Companion progress freshness / last-updated indication を追加した。
+- Reviewer request_changes を受け、Companion progress notice の LLM-facing framing を Rust 直書きから `resources/prompts/panel/companion_progress_notice.md` へ移し、Rust は bounded runtime values の rendering に限定した。
+- Companion profile/tool authority は変更していない。
+
+Review / integration:
+- Implementation commits:
+  - `a87d3154 feat: weak companion progress notify`
+  - `61e6c068 fix: resource-back companion progress notice`
+- Reviewer: `yoi-reviewer-companion-progress-notify` が初回 request_changes、fix 後 approve。
+- Orchestrator merge commit: `56b10a2d merge: companion weak progress notify`
+- Ticket completion commit: `2b64f428 ticket: mark companion notify done`
+
+Validation:
+- `cargo test -p protocol`: pass, 39 tests
+- `cargo test -p pod --test controller_test`: pass, 36 tests
+- `cargo test -p tui companion_progress -- --nocapture`: pass, 6 tests
+- `cargo test -p tui send_notify_only_can_deliver_weak_notification_without_auto_run -- --nocapture`: pass, 1 test
+- `cargo check -p protocol -p pod -p tui`: pass
+- `cargo fmt --check`: pass
+- `git diff --check HEAD~1..HEAD`: pass
+- `./result/bin/yoi ticket doctor`: `doctor: ok`
+- `nix build .#yoi`: pass
+
+Known unrelated broad-suite failures:
+- Existing prompt/TUI broad-suite failures noted in thread remain outside this Ticket and were not blockers for focused implementation/review.
+
+Cleanup:
+- coder/reviewer Pods stopped。
+- child worktree `/home/hare/Projects/yoi/.worktree/orchestrator-progress-companion-notify` removed。
+- branch `ticket/orchestrator-progress-companion-notify` deleted。
+
+Non-blocking risk:
+- Added `minijinja` dependency to `crates/tui`; it is already used elsewhere in the workspace, and `Cargo.lock` / `package.nix` were updated with passing Nix build.
+
+---
+
+---
+
+<!-- event: state_changed author: orchestrator at: 2026-06-13T02:37:58Z from: closed to: planning reason: reopen_implementation_mismatch field: state -->
+
+## State changed
+
+実運用で、実装が Ticket の意図を逸脱していることが確認されたため reopen する。
+
+Reopen reason:
+- 現実の挙動は、Panel を開いているだけで periodic reload に連動して Companion へ progress notice を繰り返し送る形になっている。
+- Ticket は Orchestrator progress を Companion に共有することを求めていたが、Panel を actionless な notification feed source にすること、長文/スナップショット的 progress notice を Panel refresh ごとに送ることは要求していない。
+- `auto_run: false` は idle Pod を起こさないだけで、Notify は Companion history/model context に入るため、通知 spam / context 汚染として扱うべきだった。
+- Progress notice の発生源は Panel の定期 reload ではなく、Pod/Orchestrator の明示的な進捗イベント、または明示 user action に紐づくべきである。
+
+Next planning/fix question:
+- 既存 `Method::Notify { auto_run }` 互換部分は残すか。
+- Panel reload から Companion への automatic dispatch を削除または default-off にするか。
+- Orchestrator/Pod 起点でどの明示イベントだけを Companion に通知するか。
+- 送る場合の payload を snapshot ではなく bounded event notice に縮小するか。
+
+Until this is resolved, current Companion progress notice implementation should be treated as defective and not closed.
+
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-13T03:32:03Z -->
+
+## Decision
+
+Routing decision: implementation_ready（再設計）
+
+User decision:
+- Panel に依存しない形で進める。
+- Companion へ送るのは、Orchestrator の明示的な Ticket event 通知だけにする。
+- Panel periodic reload / snapshot feed / actionless mass notification は実装しない。
+
+Reason:
+- Reopen 後の不足点は、通知発生源と通知粒度だった。ユーザー判断により、発生源は Panel ではなく Orchestrator/Pod 側の Ticket event、粒度は snapshot ではなく event notice と確定した。
+- 既存 `Method::Notify { auto_run }` / idle no-run semantics は有効な基盤として残せる。
+- `auto_run:false` は Companion を起こさない weak notification として使うが、通知は history-backed context になるため、明示 Ticket event に限定する。
+- Relation blocker はなく、現在 visible child Pod はない。Orchestrator worktree は clean。
+
+IntentPacket:
+
+Intent:
+- Orchestrator が Ticket tool により明示的な Ticket event（state change / decision / plan / implementation_report / review / close など）を記録した時だけ、live/reachable Companion に bounded event notice を `Notify { auto_run:false }` で送る。
+
+Binding decisions / invariants:
+- Panel reload、Panel periodic refresh、Panel snapshot から Companion へ通知しない。
+- 長文 snapshot、Ticket list 全体、full thread、Pod output、diagnostics、provider error detail を送らない。
+- 通知は Orchestrator/Pod 側の明示 Ticket event に紐づく event notice に限定する。
+- `auto_run:false` を使い、idle Companion を起こさない。
+- missing/stopped/unreachable Companion を spawn/restore しない。
+- Companion authority を増やさない。
+- 通知は history-backed Notify として扱い、hidden context-only injection はしない。
+- LLM-facing framing が必要なら `resources/prompts` に置き、Rust は bounded runtime values の組み立てと rendering に留める。
+
+Requirements / acceptance criteria:
+- Ticket event 記録時に、live/reachable Companion が bounded event notice を weak Notify として受け取れる。
+- Panel を開いているだけでは Companion に通知が飛ばない。
+- 同一 event につき通知は高々一回で、periodic reload による再送がない。
+- 通知 payload は Ticket id/title/state、event kind、short summary、source path/ref 程度に限定される。
+- missing/stopped Companion で spawn/restore しない。
+- `auto_run:false` の idle no-run semantics は維持される。
+- focused tests で Panel 非依存、event-triggered delivery、no snapshot/feed、missing/stopped no-op、bounded/sensitive-safe content を確認する。
+- `nix build .#yoi` が通る。
+
+Next action:
+- branch `ticket/orchestrator-ticket-event-companion-notify` / worktree `/home/hare/Projects/yoi/.worktree/orchestrator-ticket-event-companion-notify` で sibling coder に実装を委譲する。
+
+---
+
+<!-- event: state_changed author: orchestrator at: 2026-06-13T03:32:03Z from: planning to: ready reason: planning_ready field: state -->
+
+## State changed
+
+ユーザー判断により、通知発生源・粒度・非目標が確定したため implementation-ready とする。
+
+---
+
+<!-- event: state_changed author: orchestrator at: 2026-06-13T03:32:03Z from: ready to: queued reason: user_authorized_queue field: state -->
+
+## State changed
+
+ユーザーが実装続行を明示したため、Orchestrator routing 対象として queued にする。
+
+---
+
+<!-- event: state_changed author: orchestrator at: 2026-06-13T03:32:03Z from: queued to: inprogress reason: orchestrator_acceptance field: state -->
+
+## State changed
+
+Ticket body/thread、reopen decision、relation blockers、accepted plan、current Orchestrator workspace state、visible Pods を再確認した。未解決 blocker や missing planning decision は残っていないため、implementation side effect 前に `queued -> inprogress` acceptance を記録する。
+
+---
+
+<!-- event: plan author: orchestrator at: 2026-06-13T03:33:09Z -->
+
+## Plan
+
+Implementation worktree created and coder delegated.
+
+- Ticket: `00001KTTW04W2`
+- Branch: `ticket/orchestrator-ticket-event-companion-notify`
+- Worktree: `/home/hare/Projects/yoi/.worktree/orchestrator-ticket-event-companion-notify`
+- Coder Pod: `yoi-coder-event-companion-notify`
+- Scope: write child worktree only; read child worktree plus minimal non-recursive runtime-root read required by spawn validation。
+- Task: implement Panel-independent Companion notification for explicit Orchestrator/Pod Ticket events only, using bounded `Notify { auto_run:false }` event notices; do not reintroduce Panel periodic reload/snapshot feed.
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-13T04:09:50Z -->
+
+## Implementation report
+
+Coder completed implementation and prompt-resource fix.
+
+Coder Pod:
+- `yoi-coder-event-companion-notify`
+
+Implementation branch/worktree:
+- Branch: `ticket/orchestrator-ticket-event-companion-notify`
+- Worktree: `/home/hare/Projects/yoi/.worktree/orchestrator-ticket-event-companion-notify`
+- Implementation commits:
+  - `465ef100 feat: notify Companion on Orchestrator ticket events`
+  - `6f8571f7 fix: render ticket event notice from prompt resource`
+- Worktree status: clean
+
+Changed surfaces:
+- `crates/pod/src/controller.rs`
+- `crates/pod/src/discovery.rs`
+- `crates/pod/src/lib.rs`
+- `crates/pod/src/pod.rs`
+- `crates/pod/src/prompt/catalog.rs`
+- `crates/pod/src/ticket_event_notify.rs`
+- `resources/prompts/internal.toml`
+- `resources/prompts/pod/ticket_event_companion_notice.md`
+
+Implementation summary:
+- Added Orchestrator-role Ticket tool post-call hook for explicit Ticket event tools.
+- Event tools include state/comment/plan/decision/implementation_report/review/close paths; passive reads/lists are ignored.
+- The hook sends a bounded event-scoped weak notification to live/reachable Companion peer via `Notify { auto_run:false }`.
+- missing/stopped/unreachable Companion is no-op; no spawn/restore.
+- Panel reload/open/periodic refresh path is not used and Panel progress feed remains removed.
+- Ticket event notice framing is prompt-resource backed by `resources/prompts/pod/ticket_event_companion_notice.md`; Rust fills bounded runtime values and renders the resource.
+- Companion authority is not expanded.
+
+Orchestrator-verified validation:
+- `cargo test -p pod ticket_event_notify`: pass。
+- `cargo test -p pod ticket_event`: pass。
+- `cargo test -p pod weak_notify_to_live_peer_uses_notify_without_auto_run_and_noops_when_missing`: pass。
+- `cargo test -p tui companion_progress`: pass（0 matched; Panel feed tests remain absent）。
+- `rg` check confirmed no `companion_progress` / progress feed / `send_weak_notify` references in `crates/tui/src/multi_pod.rs`。
+- `cargo fmt --check`: pass。
+- `git diff --check orchestration/yoi-orchestrator...HEAD`: pass。
+- `cargo run -p yoi -- ticket doctor`: `doctor: ok`。
+- `nix build .#yoi`: pass。
+
+Next:
+- Spawn read-only reviewer for the Panel-independent event-triggered design, prompt-resource boundary, weak notify semantics, no snapshot feed, and authority/no-spawn invariants.
+
+---
+
+<!-- event: review author: reviewer:yoi-reviewer-event-companion-notify at: 2026-06-13T04:20:19Z result: approve -->
+
+## Review: approve
+
+Review target:
+- Worktree: `/home/hare/Projects/yoi/.worktree/orchestrator-ticket-event-companion-notify`
+- Commits:
+  - `465ef100 feat: notify Companion on Orchestrator ticket events`
+  - `6f8571f7 fix: render ticket event notice from prompt resource`
+
+Evidence:
+- Panel 非依存: 通知処理は `crates/pod/src/ticket_event_notify.rs` の Pod/Orchestrator 側 hook として追加されており、Panel reload/open/periodic refresh 経路ではない。
+- `crates/tui/src/multi_pod.rs` に `send_weak_notify` / `ticket_event` / `companion_progress` の新規参照がない。
+- hook 登録は Orchestrator role 判定と lifecycle Ticket tool access に gated されている。
+- 対象は `TicketComment` / `TicketReview` / `TicketWorkflowState` / `TicketIntakeReady` / `TicketClose` の explicit mutating Ticket event のみで、passive read/list/show/query では発火しない。
+- tool error 時は通知しない。
+- payload は ticket id/title/state、event kind、summary、path/ref に限定され、full thread、Ticket snapshot、Pod output、diagnostics、provider error detail、長大 log を含めない。
+- LLM-facing notice framing は `resources/prompts/pod/ticket_event_companion_notice.md` と `resources/prompts/internal.toml` / `PodPrompt::TicketEventCompanionNotice` に置かれており、Rust 側は bounded runtime values を埋める。
+- `send_weak_notify_to_live_peer` は live/reachable peer にだけ `Method::Notify { auto_run:false }` を送り、missing/unreachable は no-op。spawn/restore 経路はない。
+- Companion authority expansion は見当たらない。
+- scheduler/feed loop/polling/periodic snapshot は追加されていない。
+
+Reviewer-run validation:
+- `cargo test -p pod ticket_event_notify -- --nocapture`: pass。
+- `cargo test -p pod weak_notify_to_live_peer_uses_notify_without_auto_run_and_noops_when_missing -- --nocapture`: pass。
+- `cargo test -p tui companion_progress -- --nocapture`: pass（0 matched）。
+- `cargo test -p pod ticket_event -- --nocapture`: pass。
+- `git diff --check orchestration/yoi-orchestrator...HEAD`: pass。
+- `git status --short --branch`: clean。
+- focused `rg` checks for Panel/feed references and notify hook references。
+
+Non-blocking note:
+- `cargo test -p tui companion_progress` は 0 matched。Panel 非通知は TUI diff がないことと `rg` で確認している。将来の回帰防止には Panel reload/open が Companion event notify を呼ばない明示 test を追加してもよい。
+- Reviewer は read-only 方針を優先して `nix build .#yoi` を再実行せず、Orchestrator の pass 証跡を採用した。
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-13T04:21:40Z -->
+
+## Implementation report
+
+Integration completed in the Orchestrator workspace.
+
+Integrated implementation:
+- Ticket: `00001KTTW04W2`
+- Implementation branch: `ticket/orchestrator-ticket-event-companion-notify`
+- Implementation commits:
+  - `465ef100 feat: notify Companion on Orchestrator ticket events`
+  - `6f8571f7 fix: render ticket event notice from prompt resource`
+- Reviewer result: approve, no blockers
+- Orchestrator merge commit: `2e5a60f4 merge: companion ticket event notify`
+- Integration target: `orchestration/yoi-orchestrator`
+
+Post-integration validation from Orchestrator worktree:
+- `cargo test -p pod ticket_event_notify`: pass。
+- `cargo test -p pod ticket_event`: pass。
+- `cargo test -p pod weak_notify_to_live_peer_uses_notify_without_auto_run_and_noops_when_missing`: pass。
+- `cargo test -p tui companion_progress`: pass（0 matched; Panel feed remains absent）。
+- `rg` check confirmed no `companion_progress` / progress feed / `send_weak_notify` references in `crates/tui/src/multi_pod.rs`。
+- `cargo fmt --check`: pass。
+- `git diff --check HEAD~1..HEAD`: pass。
+- `./result/bin/yoi ticket doctor`: `doctor: ok`。
+- `nix build .#yoi`: pass。
+
+Behavior now:
+- Panel reload/open/periodic refresh does not send Companion notifications。
+- Orchestrator-role lifecycle Ticket tool post-call events can send bounded weak notifications to live/reachable Companion peer only。
+- Passive Ticket reads/lists/show/query do not notify。
+- missing/stopped/unreachable Companion remains no-op; no spawn/restore。
+- LLM-facing event notice framing is prompt-resource backed。
+
+---
+
+<!-- event: state_changed author: orchestrator at: 2026-06-13T04:21:40Z from: inprogress to: done reason: implementation_merged_and_validated field: state -->
+
+## State changed
+
+Implementation was merged into the Orchestrator branch, reviewer approved with no blockers, and post-integration validation passed. Cleanup and closure will be recorded next.
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-13T04:22:26Z -->
+
+## Implementation report
+
+Cleanup completed.
+
+- Stopped coder Pod: `yoi-coder-event-companion-notify`
+- Stopped reviewer Pod: `yoi-reviewer-event-companion-notify`
+- Removed child worktree: `/home/hare/Projects/yoi/.worktree/orchestrator-ticket-event-companion-notify`
+- Deleted implementation branch: `ticket/orchestrator-ticket-event-companion-notify`
+- Orchestrator worktree status after cleanup: clean
+
+Cleanup was limited to child implementation worktree/branch and related child Pods. Root/original workspace was not used as an implementation target.
+
+---
+
+<!-- event: closed author: orchestrator at: 2026-06-13T04:22:26Z -->
+
+## Closed
+
+Resolution written to `resolution.md`.

.yoi/tickets/00001KTVJFT6F/artifacts/orchestration-plan.jsonl

@@ -0,0 +1 @@
+{"id":"orch-plan-20260612-144501-1","ticket_id":"00001KTVJFT6F","kind":"accepted_plan","accepted_plan":{"summary":"`yoi panel` の user-visible focus model を composer target（送信先）と row selection（空 composer 時の navigation/Enter 対象）へ整理し、`item action focus` / `Right action focus` 表示を削除または意味ある no-op/案内へ簡略化する。対象は主に `crates/tui/src/multi_pod.rs` と focused tests。","branch":"ticket/panel-focus-composer-row-selection","worktree":"/home/hare/Projects/yoi/.worktree/panel-focus-composer-row-selection","role_plan":"Coder は child worktree に限定して Panel focus model / key handling / status/actionbar hints と focused tests を実装する。Reviewer は read-only で、composer 入力保護、row selection semantics、Ticket/Pod authority、key hints と実装の一致、single-Pod TUI 範囲外の遵守を確認する。"},"author":"orchestrator","at":"2026-06-12T14:45:01Z"}

.yoi/tickets/00001KTVJFT6F/item.md

@@ -0,0 +1,83 @@
+---
+title: 'Workspace panel の focus model を composer target と row selection に整理する'
+state: 'closed'
+created_at: '2026-06-11T14:48:26Z'
+updated_at: '2026-06-12T15:09:15Z'
+assignee: null
+readiness: 'implementation_ready'
+risk_flags: ['tui-ux', 'input-safety']
+queued_by: 'workspace-panel'
+queued_at: '2026-06-12T14:44:16Z'
+---
+
+## Background
+
+`yoi panel` の現行 focus 表示は `global composer` / `selected row` / `item action` の3状態だが、実際の操作モデルは composer 入力状態と selected row に強く依存している。
+
+特に `item action focus` は Enter の挙動を実質的に変えないため、ユーザーには「focus が移った」ように見える一方で、何が変わったのか分かりづらい。Panel の主な操作対象は composer target と selected row であり、focus 概念がそれ以上に増えることで UX が不明瞭になっている。
+
+関連する broad design Ticket として `00001KSKBPPMR`「TUI: navigation mode / block focus の設計」があるが、本 Ticket は `yoi panel` の現行 focus UX を具体的に整理する実装単位とする。
+
+## Requirements
+
+- `yoi panel` の user-visible focus model を縮小し、composer target と row selection を中心に整理する。
+- composer target は focus ではなく、送信先表示として扱う。
+- selected row は、composer が空のときの navigation / Enter 対象として扱う。
+- `item action focus` は廃止するか、少なくとも user-visible focus として表示しない。
+- `Right action focus` / `Left` の段階的 focus 移動は、必要性を再評価して簡略化する。
+- status line / actionbar / key hints が、実際の Enter・矢印・Esc・Tab の挙動と一致するようにする。
+- composer に入力済みのテキストを誤って壊したり、暗黙に row action へ送ったりしない。
+- Ticket action / Pod open / Companion composer / Ticket Intake target の既存 authority と明示操作は維持する。
+- single-Pod TUI の transcript / block navigation はこの Ticket では扱わない。
+
+## Acceptance criteria
+
+- Panel 上で composer target と selected row の意味が分かりやすく表示される。
+- `global composer` / `selected row` / `item action` のような user-visible focus 表示が、実際の操作以上に状態を増やして見せない。
+- 空 composer と非空 composer で Enter が何をするか、actionbar/status から誤解しにくい。
+- `↑/↓`, `Left`, `Right`, `Esc`, `Tab`, `Enter` の key hints が実装と一致している。
+- `Right action focus` が残る場合は user-visible focus ではなく、実際に意味のある操作として説明される。不要なら削除・無効化される。
+- composer 入力保護が維持される。
+- 既存の Ticket action dispatch / Pod open / Intake launch / Companion send の安全性を落とさない。
+
+## Binding decisions / invariants
+
+- `yoi panel` の改善に限定する。
+- 通常の single-Pod TUI transcript / block focus navigation は範囲外。
+- composer に文字が入っている状態では、通常入力を最優先で保護する。
+- composer target は focus ではなく送信先である。
+- row selection は、空 composer 時の navigation / Enter 対象である。
+- `item action focus` を user-visible focus model から外す。
+- Panel は durable state authority にならず、既存の Ticket / Pod authority を維持する。
+- Ticket の `ready -> queued` などの明示 user action semantics は変更しない。
+
+## Implementation latitude
+
+- `PanelFocus` の状態名・数・遷移は変更してよい。
+- `ItemAction` 相当の状態は削除してよい。
+- `Right` / `Left` の扱いは、実装後の単純な model に合わせて削除・no-op・案内表示のいずれかにしてよい。
+- `Esc` の詳細挙動は input safety を満たす範囲で調整してよい。
+- status line / actionbar / row hints の文言は、実装後の挙動に合わせて整理してよい。
+- UX 改善は最小実装でよく、フル navigation mode や vim-like 操作体系は不要。
+
+## Readiness
+
+- readiness: implementation_ready
+- risk_flags: [tui-ux, input-safety]
+
+## Escalation conditions
+
+- composer 入力保護と row navigation のどちらを優先するかについて、現行 invariant を超える判断が必要になった場合。
+- Ticket lifecycle action の明示性や authority boundary を変える必要が出た場合。
+- Panel だけでなく single-Pod TUI の navigation model 変更が必要だと判明した場合。
+
+## Validation
+
+- `crates/tui/src/multi_pod.rs` 周辺の focused tests を追加・更新する。
+- focus/key handling/status/actionbar の unit tests を通す。
+- `cargo test -p tui multi_` またはより focused な同等テストを通す。
+- TUI 変更なので完了時に `nix build .#yoi` も確認する。
+
+## Related work
+
+- `00001KSKBPPMR` — TUI: navigation mode / block focus の設計

.yoi/tickets/00001KTVJFT6F/resolution.md

@@ -0,0 +1,38 @@
+Workspace panel の focus model を composer target と row selection に整理した。
+
+実装概要:
+- `yoi panel` の user-visible focus 表示から `item action focus` / `Right action focus` / `global composer` / `PanelFocus` / `ItemAction` 系の不要な focus model を除去した。
+- composer target は送信先、row selection は空 composer 時の navigation / Enter 対象として扱う表示・挙動へ整理した。
+- 非空 composer では composer draft / target を優先し、`Enter` は composer send / Intake 起動に向く。
+- 空 composer では selected row が `Enter` 対象になり、既存 Ticket action dispatch / Pod open 経路を使う。
+- `Tab` は composer target の切替のみで selected row と draft を保持する。
+- `Esc` は row selection を解除し、composer draft と target は保持する。
+- `Left` / `Right` は Panel focus 切替ではなく composer cursor 操作として扱う。
+- Ticket action dispatch、Pod open、Intake launch、Companion send の authority / safety semantics は維持した。
+
+Review / integration:
+- Implementation commit: `c5ef6f79 tui: clarify panel composer target and row selection`
+- Reviewer: `yoi-reviewer-panel-focus-model` が approve。
+- Orchestrator merge commit: `d6166c72 merge: panel focus composer row selection`
+- Ticket completion commit: `e330685e ticket: mark panel focus done`
+
+Validation:
+- `cargo test -p tui selected_ticket_row_with_non_empty_composer_shows_composer_enter_behavior`: pass
+- `cargo test -p tui multi_esc_clears_row_selection_without_quitting_and_preserves_draft`: pass
+- `cargo test -p tui multi_composer_target_switch_preserves_typed_text`: pass
+- `cargo test -p tui multi_blank_ticket_intake_enter_uses_selected_row_and_preserves_input`: pass
+- `cargo fmt --check`: pass
+- `git diff --check HEAD~1..HEAD`: pass
+- `./result/bin/yoi ticket doctor`: `doctor: ok`
+- `nix build .#yoi`: pass
+
+Known unrelated validation failure:
+- `cargo test -p tui multi_ --lib` still includes pre-existing failure `multi_pod::tests::orchestrator_launch_context_uses_orchestration_root_for_runtime_workspace`; this was verified on the Orchestrator branch before merge and reviewed as unrelated to this Ticket.
+
+Cleanup:
+- coder/reviewer Pods stopped。
+- child worktree `/home/hare/Projects/yoi/.worktree/panel-focus-composer-row-selection` removed。
+- branch `ticket/panel-focus-composer-row-selection` deleted。
+
+Non-blocking risks:
+- Reviewer found none for this Ticket.

.yoi/tickets/00001KTVJFT6F/thread.md

@@ -0,0 +1,364 @@
+<!-- event: create author: LocalTicketBackend at: 2026-06-11T14:48:26Z -->
+
+## 作成
+
+LocalTicketBackend によって作成されました。
+
+---
+
+<!-- event: intake_summary author: intake at: 2026-06-11T14:48:31Z -->
+
+## Intake summary
+
+Panel focus UX の不満を `yoi panel` 専用の concrete Ticket として整理した。合意済み方針は、user-visible focus model を増やさず、composer target を送信先、selected row を空 composer 時の navigation / Enter 対象として扱い、`item action focus` を user-visible focus から外すこと。既存 Ticket / Pod authority と composer 入力保護は維持する。
+
+---
+
+<!-- event: state_changed author: intake at: 2026-06-11T14:48:31Z from: planning to: ready reason: intake_ready field: state -->
+
+## State changed
+
+Intake clarified the panel focus request and recorded an implementation-ready concrete Ticket. Human can queue it from the panel when ready.
+
+---
+
+<!-- event: state_changed author: workspace-panel at: 2026-06-12T14:44:16Z from: ready to: queued reason: queued field: state -->
+
+## State changed
+
+Ticket を `workspace-panel` が queued にしました。
+
+
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-12T14:45:35Z -->
+
+## Decision
+
+Routing decision: implementation_ready
+
+Reason:
+- Ticket body は `yoi panel` に範囲を限定し、composer target を送信先、row selection を空 composer 時の navigation / Enter 対象として扱う方針を明確に記録している。
+- `item action focus` を user-visible focus model から外すこと、composer 入力保護、既存 Ticket / Pod authority の維持、single-Pod TUI navigation を範囲外にすることが binding invariant として記録済みである。
+- risk flags は `tui-ux` / `input-safety` だが、bounded context check の結果、具体的な未決定 product/API/authority 判断は残っていない。残る不確実性は `crates/tui/src/multi_pod.rs` 周辺の local tactic / focused tests に閉じている。
+- Relation blocker はなく、OrchestrationPlan に accepted plan `orch-plan-20260612-144501-1` を記録済み。現在 inprogress Ticket / child Pod はなく、Orchestrator worktree は clean。
+
+Evidence checked:
+- Ticket body / thread: requirements, acceptance criteria, binding decisions, implementation latitude, escalation conditions, validation, intake summary, `ready -> queued` event を確認。
+- Related design Ticket: `00001KSKBPPMR` は broad planning context であり、本 Ticket が panel-specific concrete implementation unit であることを確認。
+- TicketRelationQuery: outgoing/incoming relation なし、blocker なし。
+- TicketOrchestrationPlanQuery: 既存 record なし、今回 accepted plan を記録。
+- Code map: `crates/tui/src/multi_pod.rs` に `PanelFocus::ItemAction`, `focus_item_action`, `Right action focus` hints, focus/status/actionbar rendering, key handling, focused tests があることを確認。
+- Workspace/Pod state: Orchestrator worktree `orchestration/yoi-orchestrator` は clean、visible child Pod なし、inprogress Ticket なし。
+- Durable context: Panel composer target は selected rows とは別の送信先で、Panel は authority/backend ではなく local view/controller に留める既存方針に一致する。
+
+IntentPacket:
+
+Intent:
+- `yoi panel` の user-visible focus model を composer target と row selection に整理し、実際の Enter/矢印/Esc/Tab 挙動と status/actionbar/key hints を一致させる。
+- `item action focus` / `Right action focus` が user-visible focus として見える状態を削除または実際に意味のある表示に変える。
+
+Binding decisions / invariants:
+- 対象は `yoi panel` のみ。single-Pod TUI transcript / block navigation は範囲外。
+- composer に文字がある場合は通常入力と composer draft 保護を最優先する。
+- composer target は focus ではなく送信先である。
+- row selection は空 composer 時の navigation / Enter 対象である。
+- `item action focus` を user-visible focus model から外す。
+- Panel は durable state authority にならず、Ticket / Pod authority と `ready -> queued` 等の明示 user action semantics を変えない。
+
+Requirements / acceptance criteria:
+- Panel 上で composer target と selected row の意味が分かりやすく表示される。
+- `global composer` / `selected row` / `item action` のように実際の操作以上の focus 状態を見せない。
+- 空 composer と非空 composer で Enter が何をするか、status/actionbar から誤解しにくい。
+- `↑/↓`, `Left`, `Right`, `Esc`, `Tab`, `Enter` の key hints が実装と一致する。
+- `Right action focus` が残る場合は user-visible focus ではなく意味ある操作として説明する。不要なら削除・無効化する。
+- composer 入力保護を維持する。
+- Ticket action dispatch / Pod open / Intake launch / Companion send の安全性を落とさない。
+
+Implementation latitude:
+- `PanelFocus` の状態名・数・遷移は変更してよい。
+- `ItemAction` 相当の状態は削除してよい。
+- `Right` / `Left` は削除、no-op、案内表示のいずれでもよいが、hints と一致させる。
+- `Esc` の詳細挙動は input safety を満たす範囲で調整してよい。
+- UX 改善は最小実装でよく、フル navigation mode / vim-like 操作体系は不要。
+
+Escalate if:
+- composer 入力保護と row navigation の優先順位について記録済み invariant を超える判断が必要になった場合。
+- Ticket lifecycle action の明示性や authority boundary を変える必要が出た場合。
+- single-Pod TUI navigation model 変更が必要だと判明した場合。
+
+Validation:
+- `crates/tui/src/multi_pod.rs` 周辺の focused tests を追加・更新する。
+- focus/key handling/status/actionbar の unit tests を通す。
+- `cargo test -p tui multi_` またはより focused な同等テスト。
+- `cargo fmt --check`。
+- `git diff --check`。
+- `./result/bin/yoi ticket doctor` または同等。
+- `nix build .#yoi`。
+
+Current code map:
+- 主対象: `crates/tui/src/multi_pod.rs`。
+- 既存確認点: `PanelFocus`, `focus_item_action`, `effective_focus`, key handling around `Up/Down/Left/Right/Enter/Tab/Esc`, status/actionbar rendering, row hints, tests around `multi_`.
+
+Critical risks / reviewer focus:
+- composer draft を誤って submit / clear / row action dispatch しないこと。
+- key hints と実装がずれないこと。
+- `Right action focus` / `item action` 表示が残留して UX を曖昧にしないこと。
+- Ticket action dispatch、Pod open、Intake launch、Companion send の authority semantics が変わっていないこと。
+- broad `00001KSKBPPMR` の single-Pod transcript/block navigation scope に踏み込んでいないこと。
+
+Next action:
+- `queued -> inprogress` を記録してから、branch `ticket/panel-focus-composer-row-selection` / worktree `/home/hare/Projects/yoi/.worktree/panel-focus-composer-row-selection` を作成し、sibling coder に narrow write scope で実装を委譲する。Reviewer は coder evidence 後に read-only で起動する。
+
+---
+
+<!-- event: state_changed author: orchestrator at: 2026-06-12T14:45:41Z from: queued to: inprogress reason: orchestrator_acceptance field: state -->
+
+## State changed
+
+Routing accepted for implementation. Ticket body/thread, related broad design Ticket, relation blockers, orchestration plan, code map, current Orchestrator workspace state, in-progress Ticket state, and visible Pods were rechecked. No unresolved blocker or missing planning decision remains. Implementation side effects will start only after this accepted `queued -> inprogress` transition is recorded, using accepted plan `orch-plan-20260612-144501-1`.
+
+---
+
+<!-- event: plan author: orchestrator at: 2026-06-12T14:46:00Z -->
+
+## Plan
+
+Implementation worktree created for multi-agent handoff.
+
+- Ticket: `00001KTVJFT6F`
+- Branch: `ticket/panel-focus-composer-row-selection`
+- Worktree: `/home/hare/Projects/yoi/.worktree/panel-focus-composer-row-selection`
+- Base: Orchestrator workspace HEAD `f13ab294` (`orchestration/yoi-orchestrator`), including the accepted routing record and `queued -> inprogress` transition.
+- Scope rule: implementation work happens only in this child worktree. Root/original workspace must not be read, written, validated, merged, cleaned, or used for git operations.
+- Next: spawn sibling coder with narrow write scope to the implementation worktree. Reviewer will be started after coder evidence is available.
+
+---
+
+<!-- event: plan author: orchestrator at: 2026-06-12T14:46:41Z -->
+
+## Plan
+
+Coder delegated.
+
+- Coder Pod: `yoi-coder-panel-focus-model`
+- Worktree: `/home/hare/Projects/yoi/.worktree/panel-focus-composer-row-selection`
+- Branch: `ticket/panel-focus-composer-row-selection`
+- Scope: write `/home/hare/Projects/yoi/.worktree/panel-focus-composer-row-selection`; read child worktree plus minimal non-recursive runtime-root read required by spawn validation.
+- Task: simplify Panel focus model around composer target and row selection, remove/neutralize user-visible `item action focus` / `Right action focus`, align key hints/status/actionbar with actual behavior, add focused tests, validate with focused TUI tests and `nix build .#yoi`.
+- Constraint: coder was instructed not to use root/original workspace for decision evidence or git/validation/cleanup, and not to create generated memory/local/runtime/log/lock/secret-like `.yoi` paths.
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-12T15:01:02Z -->
+
+## Implementation report
+
+Coder completed implementation.
+
+Coder Pod:
+- `yoi-coder-panel-focus-model`
+
+Implementation branch/worktree:
+- Branch: `ticket/panel-focus-composer-row-selection`
+- Worktree: `/home/hare/Projects/yoi/.worktree/panel-focus-composer-row-selection`
+- Commit: `c5ef6f79 tui: clarify panel composer target and row selection`
+- Worktree status: clean
+
+Changed surfaces:
+- `crates/tui/src/multi_pod.rs`
+- `crates/tui/src/workspace_panel.rs`
+
+Implementation summary:
+- Removed user-visible `PanelFocus` / `ItemAction` style focus model.
+- `Tab` switches composer target without clearing selected row.
+- `Esc` clears row selection while preserving composer draft and target.
+- Non-empty composer prioritizes draft/text input and `Enter` targets composer send.
+- Blank composer uses selected row as `Enter` target for Ticket action / Pod open.
+- Title/status/actionbar/row hints no longer expose `global composer`, `item action`, or `Right action focus` as focus states.
+- `Left` / `Right` are presented as composer cursor movement, not Panel focus switching.
+
+Orchestrator-verified evidence from child worktree:
+- `git status --short --branch`: clean on `ticket/panel-focus-composer-row-selection`
+- Focused changed tests passed individually:
+  - `cargo test -p tui selected_ticket_row_with_non_empty_composer_shows_composer_enter_behavior`
+  - `cargo test -p tui multi_esc_clears_row_selection_without_quitting_and_preserves_draft`
+  - `cargo test -p tui multi_composer_target_switch_preserves_typed_text`
+  - `cargo test -p tui multi_blank_ticket_intake_enter_uses_selected_row_and_preserves_input`
+- `cargo fmt --check`: pass
+- `git diff --check`: pass
+- `cargo run -p yoi -- ticket doctor`: `doctor: ok`
+- `nix build .#yoi`: pass
+
+Known unrelated validation failure:
+- `cargo test -p tui multi_ --lib` fails one test: `multi_pod::tests::orchestrator_launch_context_uses_orchestration_root_for_runtime_workspace`.
+- The same focused failing test also fails on current Orchestrator branch before this implementation is merged, with `context.workspace_root` `/repo/yoi` vs expected `/repo/yoi/.worktree/orchestration/yoi-orchestrator`.
+- The failure is not in the changed focus/composer/row-selection path, but reviewer should still confirm it is unrelated and not introduced by this Ticket.
+
+Next:
+- Spawn read-only sibling reviewer against the recorded intent, binding decisions/invariants, acceptance criteria, commit `c5ef6f79`, diff, focused validation evidence, `nix build` evidence, and the known pre-existing unrelated `multi_` failure.
+
+---
+
+<!-- event: plan author: orchestrator at: 2026-06-12T15:01:54Z -->
+
+## Plan
+
+Reviewer delegated.
+
+- Reviewer Pod: `yoi-reviewer-panel-focus-model`
+- Target branch/worktree: `ticket/panel-focus-composer-row-selection` at `/home/hare/Projects/yoi/.worktree/panel-focus-composer-row-selection`
+- Commit under review: `c5ef6f79 tui: clarify panel composer target and row selection`
+- Scope: read-only child worktree plus minimal non-recursive runtime-root read required by spawn validation.
+- Review basis: recorded IntentPacket, binding decisions/invariants, acceptance criteria, implementation summary, diff, focused validation evidence, `nix build` evidence, and known pre-existing unrelated `multi_` failure evidence.
+- Reviewer focus: composer input protection, blank/non-blank Enter behavior, status/actionbar/key hint consistency, removal of user-visible `item action` / `Right action focus`, Ticket/Pod authority preservation, and staying within Panel scope.
+
+---
+
+<!-- event: review author: reviewer:yoi-reviewer-panel-focus-model at: 2026-06-12T15:07:09Z status: approve -->
+
+## Review: approve
+
+Approve.
+
+Review target:
+- Worktree: `/home/hare/Projects/yoi/.worktree/panel-focus-composer-row-selection`
+- Commit: `c5ef6f79 tui: clarify panel composer target and row selection`
+
+Evidence:
+- 差分は `crates/tui/src/multi_pod.rs` と `crates/tui/src/workspace_panel.rs` に限定され、single-Pod TUI transcript/block navigation は変更していない。
+- `Right action focus` / `global composer` / `item action` / `PanelFocus` / `ItemAction` は現行ツリー上で user-visible 文言・型として残っていない。
+- 非空 composer の `Enter` は composer target 送信 / Intake 起動に向き、row selection の Ticket action / Pod open は待機扱いになる。
+- 空 composer では selected row が `Enter` 対象になり、既存 Ticket action dispatch / Pod open 経路を使う。
+- `Tab` は composer target の切替のみで selected row と draft を保持する。
+- `Esc` は row selection を解除し、composer draft と target は保持する。
+- `Left` / `Right` は Panel focus 切替ではなく composer cursor 操作として扱われる。
+- Ticket action dispatch は従来通り stale/current authority re-check 経路を通り、`ready -> queued` などの明示 action semantics は弱められていない。
+- Companion send は workspace Companion 宛て固定の安全確認を維持し、selected Pod へ誤送信する形にはなっていない。
+
+Reviewer-run validation:
+- `cargo test -p tui selected_ticket_row_with_non_empty_composer_shows_composer_enter_behavior`: pass
+- `cargo test -p tui multi_esc_clears_row_selection_without_quitting_and_preserves_draft`: pass
+- `cargo test -p tui multi_composer_target_switch_preserves_typed_text`: pass
+- `cargo test -p tui multi_blank_ticket_intake_enter_uses_selected_row_and_preserves_input`: pass
+- `cargo fmt --check`: pass
+- `git diff --check orchestration/yoi-orchestrator...HEAD`: pass
+
+Known broad failure:
+- `cargo test -p tui multi_ --lib` fails only `multi_pod::tests::orchestrator_launch_context_uses_orchestration_root_for_runtime_workspace`.
+- The failure is the same `/repo/yoi` vs `/repo/yoi/.worktree/orchestration/yoi-orchestrator` mismatch already confirmed on the current Orchestrator branch, and this implementation does not change that launch-context path. It is pre-existing and not a blocker for this Ticket.
+
+Non-blocking risks:
+- None identified. The added tests directly cover key boundaries, draft protection, and target/row-selection display without brittle full UI snapshots.
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-12T15:08:05Z -->
+
+## Implementation report
+
+Integration completed in the Orchestrator workspace.
+
+Integrated implementation:
+- Ticket: `00001KTVJFT6F`
+- Implementation branch: `ticket/panel-focus-composer-row-selection`
+- Implementation commit: `c5ef6f79 tui: clarify panel composer target and row selection`
+- Reviewer result: approve, no blockers
+- Orchestrator merge commit: `d6166c72 merge: panel focus composer row selection`
+- Integration target: `orchestration/yoi-orchestrator`
+
+Post-integration validation from Orchestrator worktree:
+- `cargo test -p tui selected_ticket_row_with_non_empty_composer_shows_composer_enter_behavior`: pass
+- `cargo test -p tui multi_esc_clears_row_selection_without_quitting_and_preserves_draft`: pass
+- `cargo test -p tui multi_composer_target_switch_preserves_typed_text`: pass
+- `cargo test -p tui multi_blank_ticket_intake_enter_uses_selected_row_and_preserves_input`: pass
+- `cargo fmt --check`: pass
+- `git diff --check HEAD~1..HEAD`: pass
+- `./result/bin/yoi ticket doctor`: `doctor: ok`
+- `nix build .#yoi`: pass
+
+Known unrelated validation failure remains:
+- `cargo test -p tui multi_ --lib` still includes pre-existing failure `multi_pod::tests::orchestrator_launch_context_uses_orchestration_root_for_runtime_workspace`; this was verified on the Orchestrator branch before merge and reviewed as unrelated to this Ticket.
+
+Remaining risks:
+- None identified by reviewer for this Ticket.
+
+---
+
+<!-- event: state_changed author: orchestrator at: 2026-06-12T15:08:11Z from: inprogress to: done reason: implementation_merged_and_validated field: state -->
+
+## State changed
+
+Implementation was merged into the Orchestrator branch, reviewer approved with no blockers, and post-integration validation passed. Cleanup and closure will be recorded next.
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-12T15:08:59Z -->
+
+## Implementation report
+
+Cleanup completed.
+
+- Stopped coder Pod: `yoi-coder-panel-focus-model`
+- Stopped reviewer Pod: `yoi-reviewer-panel-focus-model`
+- Removed child worktree: `/home/hare/Projects/yoi/.worktree/panel-focus-composer-row-selection`
+- Deleted implementation branch: `ticket/panel-focus-composer-row-selection`
+- Orchestrator worktree status after cleanup: clean
+
+Cleanup was limited to child implementation worktree/branch and related child Pods. Root/original workspace was not touched.
+
+---
+
+<!-- event: state_changed author: hare at: 2026-06-12T15:09:15Z from: done to: closed reason: closed field: state -->
+
+## State changed
+
+Ticket を closed にしました。
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-12T15:09:15Z status: closed -->
+
+## 完了
+
+Workspace panel の focus model を composer target と row selection に整理した。
+
+実装概要:
+- `yoi panel` の user-visible focus 表示から `item action focus` / `Right action focus` / `global composer` / `PanelFocus` / `ItemAction` 系の不要な focus model を除去した。
+- composer target は送信先、row selection は空 composer 時の navigation / Enter 対象として扱う表示・挙動へ整理した。
+- 非空 composer では composer draft / target を優先し、`Enter` は composer send / Intake 起動に向く。
+- 空 composer では selected row が `Enter` 対象になり、既存 Ticket action dispatch / Pod open 経路を使う。
+- `Tab` は composer target の切替のみで selected row と draft を保持する。
+- `Esc` は row selection を解除し、composer draft と target は保持する。
+- `Left` / `Right` は Panel focus 切替ではなく composer cursor 操作として扱う。
+- Ticket action dispatch、Pod open、Intake launch、Companion send の authority / safety semantics は維持した。
+
+Review / integration:
+- Implementation commit: `c5ef6f79 tui: clarify panel composer target and row selection`
+- Reviewer: `yoi-reviewer-panel-focus-model` が approve。
+- Orchestrator merge commit: `d6166c72 merge: panel focus composer row selection`
+- Ticket completion commit: `e330685e ticket: mark panel focus done`
+
+Validation:
+- `cargo test -p tui selected_ticket_row_with_non_empty_composer_shows_composer_enter_behavior`: pass
+- `cargo test -p tui multi_esc_clears_row_selection_without_quitting_and_preserves_draft`: pass
+- `cargo test -p tui multi_composer_target_switch_preserves_typed_text`: pass
+- `cargo test -p tui multi_blank_ticket_intake_enter_uses_selected_row_and_preserves_input`: pass
+- `cargo fmt --check`: pass
+- `git diff --check HEAD~1..HEAD`: pass
+- `./result/bin/yoi ticket doctor`: `doctor: ok`
+- `nix build .#yoi`: pass
+
+Known unrelated validation failure:
+- `cargo test -p tui multi_ --lib` still includes pre-existing failure `multi_pod::tests::orchestrator_launch_context_uses_orchestration_root_for_runtime_workspace`; this was verified on the Orchestrator branch before merge and reviewed as unrelated to this Ticket.
+
+Cleanup:
+- coder/reviewer Pods stopped。
+- child worktree `/home/hare/Projects/yoi/.worktree/panel-focus-composer-row-selection` removed。
+- branch `ticket/panel-focus-composer-row-selection` deleted。
+
+Non-blocking risks:
+- Reviewer found none for this Ticket.
+
+---

.yoi/tickets/00001KTVJGC0Y/artifacts/orchestration-plan.jsonl

@@ -0,0 +1 @@
+{"id":"orch-plan-20260612-145344-1","ticket_id":"00001KTVJGC0Y","kind":"accepted_plan","accepted_plan":{"summary":"`ticket.language` guidance を Ticket role launch 専用から外し、Ticket tools を持つすべての Pod（Companion-style non-role context を含む）に durable/model-visible に届くようにする。既存 Ticket record の rewrite は行わず、language policy 境界と prompt-context principle を維持する。","branch":"ticket/ticket-language-guidance-all-tools","worktree":"/home/hare/Projects/yoi/.worktree/ticket-language-guidance-all-tools","role_plan":"Coder は child worktree に限定して Ticket language guidance の universal Ticket-capable context/tool-surface delivery と focused tests を実装する。Reviewer は read-only で、Ticket role / non-role Companion-style context の両方に guidance が model-visible で届くこと、worker/memory/ticket language 境界、prompt-context safety、tool/feature boundary を確認する。"},"author":"orchestrator","at":"2026-06-12T14:53:44Z"}

.yoi/tickets/00001KTVJGC0Y/item.md

@@ -0,0 +1,84 @@
+---
+title: 'Ticket language guidance must apply to all Ticket tool users'
+state: 'closed'
+created_at: '2026-06-11T14:48:44Z'
+updated_at: '2026-06-12T15:20:11Z'
+assignee: null
+readiness: 'implementation_ready'
+risk_flags: ['prompt-context', 'tool-description', 'feature-boundary', 'ticket-language', 'companion']
+queued_by: 'workspace-panel'
+queued_at: '2026-06-12T14:49:39Z'
+---
+
+## Background
+
+`ticket.language` は durable Ticket record の言語設定であり、Ticket を書くすべての Pod に適用されるべき情報である。
+
+現状の実装では、Ticket record language guidance が主に Ticket role launch prompt に入っている。しかし Companion など Ticket role ではない Pod も Ticket tools を受け取り、Ticket の `item.md` / `thread.md` / `resolution.md` や Ticket tool body を書く可能性がある。
+
+そのため、Ticket record language guidance を Ticket role 専用の launch prompt に置くだけでは不十分である。
+
+## Requirements
+
+- Ticket-writing tools を使える Pod には、Ticket role かどうかに関係なく、configured `ticket.language` に従って durable Ticket record / Ticket tool body を書く guidance が model-visible になること。
+- Companion など non-Ticket-role Pod が Ticket tools を扱う場合にも同じ guidance が届くこと。
+- 既存の言語境界を維持すること。
+  - `worker.language`: 通常の会話 prose。
+  - `memory.language`: memory / Knowledge generation。
+  - `ticket.language`: durable Ticket records / Ticket tool bodies。
+- `ticket.language` が設定されていても、protocol literals、file paths、commands、logs、identifiers、quoted external text は不要に翻訳しないこと。
+- prompt-context principle を守ること。モデルの挙動根拠が history / prompt / tool surface に残らない hidden context-only injection を作らないこと。
+- Ticket role prompt だけを唯一の伝達経路にしないこと。
+
+## Acceptance criteria
+
+- Ticket tools を持つ non-Ticket-role Pod、特に Companion-style context でも、Ticket tool bodies を configured `ticket.language` で書く guidance が model-visible になる。
+- Ticket role Pods でも同等の guidance が引き続き届き、既存挙動が退行しない。
+- guidance の source は universal な Ticket capability / tool surface、または feature-scoped system prompt path に置かれ、Ticket role launch prompt 専用ではない。
+- `worker.language` が `ticket.language` を override しない。
+- 既存 Ticket records は翻訳・一括 rewrite しない。
+- focused test または snapshot-style verification で、Ticket role と generic / Companion-style Ticket-capable context の両方に guidance が届くことを確認する。
+- runtime prompt / tool behavior に関わるため、完了前に `nix build .#yoi` を通す。
+
+## Binding decisions / invariants
+
+- `ticket.language` は Ticket record writing の policy であり、Ticket role 固有の policy ではない。
+- Companion や他の non-role Pods が、conversation language から Ticket record language を推測する状態にしてはならない。
+- `worker.language` / `memory.language` / `ticket.language` の責務を混同しない。
+- hidden context-only language injection を実装しない。
+
+## Implementation latitude
+
+実装方式は coder がよりきれいな architecture を選んでよい。
+
+候補:
+
+- `ticket.language` が設定されている場合に Ticket tool descriptions / schema text へ language instruction を入れる。
+- Ticket capability / feature が有効な Pod に対して、feature-scoped system prompt guidance を追加する。
+
+どちらの場合も、guidance は Ticket tools を扱うすべての model context に durable / model-visible な形で届く必要がある。
+
+## Readiness
+
+- readiness: implementation_ready
+- risk_flags: [prompt-context, tool-description, feature-boundary, ticket-language, companion]
+
+## Escalation conditions
+
+- Tool descriptions が現在の構造では configured Ticket language に依存できず、広い ToolRegistry redesign が必要になる場合。
+- feature-scoped prompt guidance が history に残らない context mutation を必要とする場合。
+- Companion の Ticket capability path から Ticket config にアクセスできない場合。
+- 提案実装が Ticket record language と worker response language を混同する場合。
+
+## Validation
+
+- Ticket role prompt / context の focused test。
+- generic / Companion-style Ticket-capable context の guidance を確認する focused test または snapshot-style test。
+- relevant focused `cargo test`。
+- `cargo fmt --check`。
+- `git diff --check`。
+- `nix build .#yoi`。
+
+## Related work
+
+- `00001KTJMDWTR` — Separate Ticket record language from worker response language

.yoi/tickets/00001KTVJGC0Y/resolution.md

@@ -0,0 +1,35 @@
+Ticket tool users 全体に `ticket.language` guidance が届くようにした。
+
+実装概要:
+- `crates/ticket/src/tool.rs` に shared `ticket_tool_description(name, record_language)` を追加し、configured `ticket.language` がある場合は Ticket tool description に durable Ticket record / Ticket tool body language guidance を追加するようにした。
+- `crates/pod/src/feature/builtin/ticket.rs` の builtin Ticket feature `ToolDeclaration` descriptions でも同じ helper を使い、read-only Companion-style context と lifecycle/Ticket-role-style context の両方に guidance が届くようにした。
+- guidance は `worker.language` / `memory.language` / `ticket.language` を区別し、protocol literals、file paths、commands、logs、identifiers、quoted external text は fidelity 優先で保持することを明記した。
+- guidance は Ticket tool / capability surface で model-visible であり、hidden context injection や `ticket_role` launch prompt fragment ではない。
+- Companion/read-only authority や mutating tool exposure は拡大していない。
+
+Review / integration:
+- Implementation commit: `92c4dee7 ticket: guide Ticket tool language universally`
+- Reviewer: `yoi-reviewer-ticket-language-guidance` が approve。
+- Orchestrator merge commit: `ec66cad8 merge: ticket language guidance for tool users`
+- Ticket completion commit: `2ba97b67 ticket: mark language guidance done`
+
+Validation:
+- `cargo test -p ticket ticket_record_language_guidance`: pass
+- `cargo test -p pod ticket_language_guidance`: pass
+- `cargo test -p client ticket_record_language_stays_out_of_first_run_text`: pass
+- `cargo test -p ticket`: pass, 68 tests
+- `cargo fmt --check`: pass
+- `git diff --check HEAD~1..HEAD`: pass
+- `./result/bin/yoi ticket doctor`: `doctor: ok`
+- `nix build .#yoi`: pass
+
+Known unrelated validation failure:
+- `cargo test -p pod` still includes pre-existing failures in Pod orchestration guidance prompt assertion tests. These were verified on the Orchestrator branch before merge and reviewed as unrelated to this Ticket.
+
+Cleanup:
+- coder/reviewer Pods stopped。
+- child worktree `/home/hare/Projects/yoi/.worktree/ticket-language-guidance-all-tools` removed。
+- branch `ticket/ticket-language-guidance-all-tools` deleted。
+
+Non-blocking risk:
+- configured language guidance is appended to every Ticket tool description, including read-only tools. This repeats some prompt text, but it is the accepted universal capability-surface tradeoff for this Ticket.

.yoi/tickets/00001KTVJGC0Y/thread.md

@@ -0,0 +1,365 @@
+<!-- event: create author: LocalTicketBackend at: 2026-06-11T14:48:44Z -->
+
+## 作成
+
+LocalTicketBackend によって作成されました。
+
+---
+
+<!-- event: intake_summary author: intake at: 2026-06-11T14:48:50Z -->
+
+## Intake summary
+
+`ticket.language` guidance が Ticket role launch prompt に偏っており、Companion など non-Ticket-role Pod が Ticket tools を使う場合に durable Ticket record / Ticket tool body の言語指示が届かない問題を concrete implementation Ticket として整理した。要件は、Ticket role に依存せず universal Ticket capability / tool surface または feature-scoped system prompt path から model-visible guidance を届けること。
+
+---
+
+<!-- event: state_changed author: intake at: 2026-06-11T14:48:50Z from: planning to: ready reason: planning_ready field: state -->
+
+## State changed
+
+要件・受け入れ条件・binding decisions・実装余地・escalation conditions・validation が揃っているため、Orchestrator routing 可能な ready Ticket とする。
+
+---
+
+<!-- event: state_changed author: workspace-panel at: 2026-06-12T14:49:39Z from: ready to: queued reason: queued field: state -->
+
+## State changed
+
+Ticket を `workspace-panel` が queued にしました。
+
+
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-12T14:54:15Z -->
+
+## Decision
+
+Routing decision: implementation_ready
+
+Reason:
+- Ticket body は `ticket.language` guidance を Ticket role launch prompt 専用ではなく、Ticket tools を持つすべての Pod に model-visible に届ける要件を明確に記録している。
+- `worker.language` / `memory.language` / `ticket.language` の責務分離、hidden context-only injection 禁止、既存 Ticket record の一括 rewrite 禁止が binding invariant として記録済みである。
+- risk flags は prompt-context / tool-description / feature-boundary / ticket-language / companion だが、bounded context check の結果、具体的な未決定 design/API/authority 判断は残っていない。実装方式は Ticket capability/tool surface または feature-scoped system prompt path の範囲で coder が選べる。
+- Relation blocker はなく、OrchestrationPlan に accepted plan `orch-plan-20260612-145344-1` を記録済み。
+- 現在 active coder は `00001KTVJFT6F`（Panel focus）と `00001KTTW04W2`（Companion progress notify）だが、この Ticket の主対象は Ticket language guidance の prompt/tool/feature boundary であり、Panel UI 変更とは独立している。Companion-adjacent確認はあるが、authority強化や progress notify implementation と結合しないように実装・reviewで確認する。
+
+Evidence checked:
+- Ticket body / thread: requirements, acceptance criteria, binding decisions, implementation latitude, escalation conditions, validation, intake summary, `ready -> queued` event を確認。
+- TicketRelationQuery: outgoing/incoming relation なし、blocker なし。
+- TicketOrchestrationPlanQuery: 既存 record なし、今回 accepted plan を記録。
+- Code/resource map: `ticket.language` / `Ticket record language` / Ticket tool/backend/feature/prompt surfaces を narrow search で確認。直近の role launch split により Ticket role first-run prompt から language guidance が外れているため、本 Ticket の universal delivery 実装が次の自然な境界であることを確認。
+- Workspace/Pod state: Orchestrator worktree clean、active child worktree は別 branch/scope。
+
+IntentPacket:
+
+Intent:
+- `ticket.language` guidance を Ticket role 固有の launch prompt ではなく、Ticket-writing tools を持つすべての Pod に durable/model-visible な形で届ける。
+- Companion-style non-Ticket-role context でも Ticket tool body / durable Ticket record を configured `ticket.language` に従って書く guidance が見えるようにする。
+
+Binding decisions / invariants:
+- `ticket.language` は durable Ticket record / Ticket tool body writing policy であり、Ticket role 固有 policy ではない。
+- `worker.language` は通常 prose、`memory.language` は Memory/Knowledge generation、`ticket.language` は durable Ticket records / Ticket tool bodies の責務に分ける。
+- `ticket.language` が設定されていても protocol literals、file paths、commands、logs、identifiers、quoted external text を不要に翻訳しない。
+- hidden context-only injection を作らない。guidance は tool surface / feature-scoped system prompt / committed prompt path など、モデルから見える根拠を残す。
+- 既存 Ticket records を翻訳・一括 rewrite しない。
+- Companion default authority を強化しない。
+
+Requirements / acceptance criteria:
+- Ticket tools を持つ non-Ticket-role Pod、特に Companion-style context でも guidance が model-visible になる。
+- Ticket role Pods でも同等 guidance が届き、既存挙動が退行しない。
+- guidance source は universal Ticket capability / tool surface または feature-scoped system prompt path にあり、Ticket role launch prompt 専用ではない。
+- `worker.language` が `ticket.language` を override しない。
+- focused test または snapshot-style verification で Ticket role と generic / Companion-style Ticket-capable context の両方を確認する。
+- `nix build .#yoi` が通る。
+
+Implementation latitude:
+- Ticket tool descriptions/schema text に configured Ticket language instruction を入れる方式、または Ticket feature/capability が有効な Pod への feature-scoped prompt guidance を使う方式を選んでよい。
+- 既存 architecture を広く作り替えず、現在の ToolRegistry/feature/prompt resource 境界に合う最小実装を選ぶ。
+- Tests は prompt snapshot 全体に brittle にせず、language guidance の存在/非混同を直接確認する。
+
+Escalate if:
+- Tool descriptions が configured Ticket language に依存できず、広い ToolRegistry redesign が必要になる。
+- feature-scoped prompt guidance が history に残らない context mutation を必要とする。
+- Companion の Ticket capability path から Ticket config にアクセスできない。
+- 実装が Ticket record language と worker response language を混同する。
+- Companion authority を増やす必要が出る。
+
+Validation:
+- Ticket role prompt/context の focused test。
+- generic / Companion-style Ticket-capable context の guidance 確認 test。
+- relevant focused `cargo test`。
+- `cargo fmt --check`。
+- `git diff --check`。
+- `./result/bin/yoi ticket doctor` または同等。
+- `nix build .#yoi`。
+
+Current code map:
+- `crates/ticket/src/config.rs`: `ticket.language` config parsing / validation。
+- `crates/ticket/src/tool.rs`: Ticket tool definitions/descriptions and tests。
+- `crates/pod/src/feature/builtin/ticket.rs`: Ticket feature registration/capability/tool exposure。
+- `crates/pod/src/prompt/*`: feature/system prompt integration if needed。
+- `crates/client/src/ticket_role.rs`: ensure Ticket role launch still receives guidance through the new universal path, not first-run Submit prose。
+
+Critical risks / reviewer focus:
+- guidance が Ticket role launch prompt 専用に戻っていないこと。
+- non-role Ticket-capable context にも model-visible に届くこと。
+- hidden ephemeral context injection ではなく、tool/feature/prompt surface として履歴・prompt根拠が残ること。
+- `worker.language` と `ticket.language` を混同しないこと。
+- Companion authority / Ticket mutation authority を強化しないこと。
+
+Next action:
+- `queued -> inprogress` を記録してから、branch `ticket/ticket-language-guidance-all-tools` / worktree `/home/hare/Projects/yoi/.worktree/ticket-language-guidance-all-tools` を作成し、sibling coder に narrow write scope で実装を委譲する。Reviewer は coder evidence 後に read-only で起動する。
+
+---
+
+<!-- event: state_changed author: orchestrator at: 2026-06-12T14:54:22Z from: queued to: inprogress reason: orchestrator_acceptance field: state -->
+
+## State changed
+
+Routing accepted for implementation. Ticket body/thread, relation blockers, orchestration plan, relevant Ticket language / tool / feature / prompt code map, current Orchestrator workspace state, and active parallel work were rechecked. No unresolved blocker or missing planning decision remains. Implementation side effects will start only after this accepted `queued -> inprogress` transition is recorded, using accepted plan `orch-plan-20260612-145344-1`.
+
+---
+
+<!-- event: plan author: orchestrator at: 2026-06-12T14:54:49Z -->
+
+## Plan
+
+Implementation worktree created for multi-agent handoff.
+
+- Ticket: `00001KTVJGC0Y`
+- Branch: `ticket/ticket-language-guidance-all-tools`
+- Worktree: `/home/hare/Projects/yoi/.worktree/ticket-language-guidance-all-tools`
+- Base: Orchestrator workspace HEAD `76d358e8` (`orchestration/yoi-orchestrator`), including the accepted routing record and `queued -> inprogress` transition.
+- Parallel work note: active child worktrees are `panel-focus-composer-row-selection` and `orchestrator-progress-companion-notify`; this Ticket should stay within Ticket language/tool/feature/prompt guidance surfaces and avoid coupling to their implementation branches.
+- Scope rule: implementation work happens only in this child worktree. Root/original workspace must not be read, written, validated, merged, cleaned, or used for git operations.
+- Next: spawn sibling coder with narrow write scope to the implementation worktree. Reviewer will be started after coder evidence is available.
+
+---
+
+<!-- event: plan author: orchestrator at: 2026-06-12T14:55:42Z -->
+
+## Plan
+
+Coder delegated.
+
+- Coder Pod: `yoi-coder-ticket-language-guidance`
+- Worktree: `/home/hare/Projects/yoi/.worktree/ticket-language-guidance-all-tools`
+- Branch: `ticket/ticket-language-guidance-all-tools`
+- Scope: write `/home/hare/Projects/yoi/.worktree/ticket-language-guidance-all-tools`; read child worktree plus minimal non-recursive runtime-root read required by spawn validation.
+- Task: make configured `ticket.language` guidance model-visible for all Ticket-capable Pods, including non-role Companion-style contexts; preserve worker/memory/ticket language boundaries; avoid hidden context-only injection; add focused tests and required validation.
+- Parallel work note: active sibling worktrees for Panel focus and Companion progress notification exist; coder was instructed to avoid coupling and report concrete merge/design conflict if found.
+- Constraint: coder was instructed not to use root/original workspace for decision evidence or git/validation/cleanup, and not to create generated memory/local/runtime/log/lock/secret-like `.yoi` paths.
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-12T15:10:38Z -->
+
+## Implementation report
+
+Coder completed implementation.
+
+Coder Pod:
+- `yoi-coder-ticket-language-guidance`
+
+Implementation branch/worktree:
+- Branch: `ticket/ticket-language-guidance-all-tools`
+- Worktree: `/home/hare/Projects/yoi/.worktree/ticket-language-guidance-all-tools`
+- Commit: `92c4dee7 ticket: guide Ticket tool language universally`
+- Worktree status: clean
+
+Changed surfaces:
+- `crates/ticket/src/tool.rs`
+- `crates/pod/src/feature/builtin/ticket.rs`
+
+Implementation summary:
+- Ticket tool `ToolMeta.description` now derives from configured `LocalTicketBackend::record_language()`.
+- Added shared `ticket_tool_description(name, record_language)` so all Ticket tool descriptions can include configured Ticket record language guidance.
+- Guidance distinguishes durable Ticket record / Ticket tool body text from normal `worker.language` prose and `memory.language` Memory/Knowledge generation.
+- Guidance preserves protocol literals, file paths, commands, logs, identifiers, and quoted external text when fidelity matters.
+- Feature descriptor `ToolDeclaration` descriptions use the same helper, so Ticket role launch is not the only guidance path.
+- Focused tests cover configured-language presence, unset-language omission, read-only Companion-style context, and lifecycle/Ticket-role-style context.
+- Companion/read-only authority was not changed.
+
+Orchestrator-verified evidence from child worktree:
+- `git status --short --branch`: clean on `ticket/ticket-language-guidance-all-tools`
+- `cargo test -p ticket ticket_record_language_guidance`: pass
+- `cargo test -p pod ticket_language_guidance`: pass
+- `cargo test -p ticket`: pass, 68 tests
+- `cargo fmt --check`: pass
+- `git diff --check`: pass
+- `cargo run -p yoi -- ticket doctor`: `doctor: ok`
+- `nix build .#yoi`: pass
+
+Known unrelated validation failure:
+- `cargo test -p pod` fails two prompt assertion tests:
+  - `prompt::catalog::tests::pod_orchestration_guidance_section_renders_resource_body`
+  - `prompt::system::tests::pod_orchestration_guidance_is_included_for_pod_management_tools`
+- The same two focused tests fail on current Orchestrator branch before this implementation is merged, with the same missing phrase `worktree status, diff, and test results`.
+- These failures are in Pod orchestration guidance prompt assertions, outside the Ticket tool language guidance change, but reviewer should confirm they are unrelated and not introduced by this Ticket.
+
+Next:
+- Spawn read-only sibling reviewer against the recorded intent, binding decisions/invariants, acceptance criteria, commit `92c4dee7`, diff, validation evidence, and known pre-existing unrelated `cargo test -p pod` failures.
+
+---
+
+<!-- event: plan author: orchestrator at: 2026-06-12T15:11:23Z -->
+
+## Plan
+
+Reviewer delegated.
+
+- Reviewer Pod: `yoi-reviewer-ticket-language-guidance`
+- Target branch/worktree: `ticket/ticket-language-guidance-all-tools` at `/home/hare/Projects/yoi/.worktree/ticket-language-guidance-all-tools`
+- Commit under review: `92c4dee7 ticket: guide Ticket tool language universally`
+- Scope: read-only child worktree plus minimal non-recursive runtime-root read required by spawn validation.
+- Review basis: recorded IntentPacket, binding decisions/invariants, acceptance criteria, implementation summary, diff, focused validation evidence, `nix build` evidence, and known pre-existing unrelated `cargo test -p pod` failure evidence.
+- Reviewer focus: universal Ticket tool/capability guidance, Ticket role and generic/Companion-style coverage, worker/memory/ticket language separation, no hidden context-only injection, no authority expansion, and robust focused tests.
+
+---
+
+<!-- event: review author: reviewer:yoi-reviewer-ticket-language-guidance at: 2026-06-12T15:16:59Z status: approve -->
+
+## Review: approve
+
+Approve.
+
+Review target:
+- Worktree: `/home/hare/Projects/yoi/.worktree/ticket-language-guidance-all-tools`
+- Commit: `92c4dee7 ticket: guide Ticket tool language universally`
+
+Evidence:
+- 差分は `crates/ticket/src/tool.rs` と `crates/pod/src/feature/builtin/ticket.rs` に限定されている。
+- guidance は shared `ticket_tool_description(name, record_language)` で生成され、registered Ticket tools の `ToolMeta.description` と builtin Ticket feature の `ToolDeclaration` descriptions の両方に使われている。
+- guidance は Ticket tool / capability surface で model-visible であり、hidden context injection でも `ticket_role` launch prompt fragment でもない。
+- `ticket.language` は `worker.language` / `memory.language` と区別され、protocol literals、paths、commands、logs、identifiers、quoted external text は fidelity 優先で保持する guidance が明記されている。
+- read-only Companion-style access は read-only のままで、mutating tool exposure は拡大していない。
+- Ticket role-style lifecycle access も同じ universal tool-description path でカバーされている。
+- first-run Ticket role text は record-language guidance を launch prose に戻していない。
+
+Reviewer-run validation:
+- `cargo test -p ticket ticket_record_language_guidance`: pass
+- `cargo test -p pod ticket_language_guidance`: pass
+- `cargo test -p ticket`: pass, 68 tests
+- `cargo test -p client ticket_record_language_stays_out_of_first_run_text`: pass
+- `cargo fmt --check`: pass
+- `git diff --check orchestration/yoi-orchestrator...HEAD`: pass
+- `cargo run -p yoi -- ticket doctor`: `doctor: ok`
+- `nix build .#yoi`: pass
+
+Known broad `cargo test -p pod` failures:
+- Reviewer reproduced the two prompt assertion failures on HEAD, both for missing `worktree status, diff, and test results`.
+- This branch has no diff under `crates/pod/src/prompt` or `resources/prompts`, and implementation diff is confined to Ticket tool/feature files.
+- Together with Orchestrator’s base-branch verification, these failures are pre-existing/unrelated and not a blocker for this Ticket.
+
+Non-blocking risk:
+- When configured, language guidance is appended to every Ticket tool description, including read-only tools. This repeats some prompt text, but it is an intentional universal capability-surface tradeoff and satisfies the acceptance criteria.
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-12T15:19:24Z -->
+
+## Implementation report
+
+Integration completed in the Orchestrator workspace.
+
+Integrated implementation:
+- Ticket: `00001KTVJGC0Y`
+- Implementation branch: `ticket/ticket-language-guidance-all-tools`
+- Implementation commit: `92c4dee7 ticket: guide Ticket tool language universally`
+- Reviewer result: approve, no blockers
+- Orchestrator merge commit: `ec66cad8 merge: ticket language guidance for tool users`
+- Integration target: `orchestration/yoi-orchestrator`
+
+Post-integration validation from Orchestrator worktree:
+- `cargo test -p ticket ticket_record_language_guidance`: pass
+- `cargo test -p pod ticket_language_guidance`: pass
+- `cargo test -p client ticket_record_language_stays_out_of_first_run_text`: pass
+- `cargo test -p ticket`: pass, 68 tests
+- `cargo fmt --check`: pass
+- `git diff --check HEAD~1..HEAD`: pass
+- `./result/bin/yoi ticket doctor`: `doctor: ok`
+- `nix build .#yoi`: pass
+
+Known unrelated validation failure remains:
+- `cargo test -p pod` still includes pre-existing failures in Pod orchestration guidance prompt assertion tests. These were verified on the Orchestrator branch before merge and reviewed as unrelated to this Ticket.
+
+Remaining non-blocking risk:
+- When configured, Ticket language guidance is appended to every Ticket tool description, including read-only tools. This repeats some prompt text, but it is the accepted universal capability-surface tradeoff for this Ticket.
+
+---
+
+<!-- event: state_changed author: orchestrator at: 2026-06-12T15:19:29Z from: inprogress to: done reason: implementation_merged_and_validated field: state -->
+
+## State changed
+
+Implementation was merged into the Orchestrator branch, reviewer approved with no blockers, and post-integration validation passed. Cleanup and closure will be recorded next.
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-12T15:19:54Z -->
+
+## Implementation report
+
+Cleanup completed.
+
+- Stopped coder Pod: `yoi-coder-ticket-language-guidance`
+- Stopped reviewer Pod: `yoi-reviewer-ticket-language-guidance`
+- Removed child worktree: `/home/hare/Projects/yoi/.worktree/ticket-language-guidance-all-tools`
+- Deleted implementation branch: `ticket/ticket-language-guidance-all-tools`
+- Orchestrator worktree status after cleanup: clean
+
+Cleanup was limited to child implementation worktree/branch and related child Pods. Root/original workspace was not touched.
+
+---
+
+<!-- event: state_changed author: hare at: 2026-06-12T15:20:11Z from: done to: closed reason: closed field: state -->
+
+## State changed
+
+Ticket を closed にしました。
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-12T15:20:11Z status: closed -->
+
+## 完了
+
+Ticket tool users 全体に `ticket.language` guidance が届くようにした。
+
+実装概要:
+- `crates/ticket/src/tool.rs` に shared `ticket_tool_description(name, record_language)` を追加し、configured `ticket.language` がある場合は Ticket tool description に durable Ticket record / Ticket tool body language guidance を追加するようにした。
+- `crates/pod/src/feature/builtin/ticket.rs` の builtin Ticket feature `ToolDeclaration` descriptions でも同じ helper を使い、read-only Companion-style context と lifecycle/Ticket-role-style context の両方に guidance が届くようにした。
+- guidance は `worker.language` / `memory.language` / `ticket.language` を区別し、protocol literals、file paths、commands、logs、identifiers、quoted external text は fidelity 優先で保持することを明記した。
+- guidance は Ticket tool / capability surface で model-visible であり、hidden context injection や `ticket_role` launch prompt fragment ではない。
+- Companion/read-only authority や mutating tool exposure は拡大していない。
+
+Review / integration:
+- Implementation commit: `92c4dee7 ticket: guide Ticket tool language universally`
+- Reviewer: `yoi-reviewer-ticket-language-guidance` が approve。
+- Orchestrator merge commit: `ec66cad8 merge: ticket language guidance for tool users`
+- Ticket completion commit: `2ba97b67 ticket: mark language guidance done`
+
+Validation:
+- `cargo test -p ticket ticket_record_language_guidance`: pass
+- `cargo test -p pod ticket_language_guidance`: pass
+- `cargo test -p client ticket_record_language_stays_out_of_first_run_text`: pass
+- `cargo test -p ticket`: pass, 68 tests
+- `cargo fmt --check`: pass
+- `git diff --check HEAD~1..HEAD`: pass
+- `./result/bin/yoi ticket doctor`: `doctor: ok`
+- `nix build .#yoi`: pass
+
+Known unrelated validation failure:
+- `cargo test -p pod` still includes pre-existing failures in Pod orchestration guidance prompt assertion tests. These were verified on the Orchestrator branch before merge and reviewed as unrelated to this Ticket.
+
+Cleanup:
+- coder/reviewer Pods stopped。
+- child worktree `/home/hare/Projects/yoi/.worktree/ticket-language-guidance-all-tools` removed。
+- branch `ticket/ticket-language-guidance-all-tools` deleted。
+
+Non-blocking risk:
+- configured language guidance is appended to every Ticket tool description, including read-only tools. This repeats some prompt text, but it is the accepted universal capability-surface tradeoff for this Ticket.
+
+---

.yoi/tickets/00001KTVNQKRP/item.md

@@ -0,0 +1,36 @@
+---
+title: 'runtime workspace と process cwd を分離する'
+state: 'closed'
+created_at: '2026-06-11T15:45:07Z'
+updated_at: '2026-06-13T16:34:06Z'
+assignee: null
+queued_by: 'yoi ticket'
+queued_at: '2026-06-11T15:45:53Z'
+---
+
+## 背景
+
+Ticket role Pod、とくに workspace Orchestrator は、runtime workspace として original workspace を使い続けながら、Bash / file tool の default cwd だけ dedicated orchestration worktree にしたい。
+
+直前の調査で `--workspace` を dedicated worktree に寄せたり、`--tool-cwd` のような追加 CLI surface を作る方向は不適切だと確認した。`--workspace` は runtime workspace / project context の基準であり、process cwd は通常の current directory として扱えばよい。
+
+また、コード内で `pwd` と `cwd` に明確な意味差がない箇所は `cwd` に統一し、用語混乱を減らす。
+
+## 要件
+
+- `--workspace` は runtime workspace / project context の基準として維持する。
+- process current directory は Pod の tool default cwd として起動時に snapshot する。
+- Ticket role Orchestrator は `--workspace = original workspace` のまま、process cwd を dedicated orchestration worktree にして起動・restore される。
+- `--tool-cwd` のような追加 CLI surface は作らない。
+- `SpawnConfig` など host-side launch config で必要なら `cwd` を内部値として持ち、child process の `Command::current_dir` にだけ使う。
+- `pwd` と `cwd` に意図的な意味差がない runtime field / helper / local 変数は `cwd` に統一する。
+- cwd は authority ではないため、scope / delegation / workspace identity の基準として扱わない。
+
+## 受け入れ条件
+
+- Orchestrator role launch/restore が original workspace を runtime workspace として使い、dedicated orchestration worktree を process cwd として使う。
+- child Pod へ `.worktree` 配下を delegate できる authority は original workspace profile/scope に基づいて評価される。
+- `--tool-cwd` などの新しい CLI argument が残らない。
+- `pwd` / `cwd` の命名が混在していた主要 runtime path は `cwd` に統一される。
+- 既存の `SpawnPod.cwd` semantics は「child process cwd を指定する」で維持され、runtime workspace を変更しない。
+- `nix build .#yoi` が通る。

.yoi/tickets/00001KTVNQKRP/resolution.md

@@ -0,0 +1 @@
+Closed after prior done-state completion.

.yoi/tickets/00001KTVNQKRP/thread.md

@@ -0,0 +1,102 @@
+<!-- event: create author: "yoi ticket" at: 2026-06-11T15:45:07Z -->
+
+## 作成
+
+LocalTicketBackend によって作成されました。
+
+---
+
+<!-- event: intake_summary author: hare at: 2026-06-11T15:45:52Z -->
+
+## Intake summary
+
+Marked ready by `yoi ticket state`.
+
+---
+
+<!-- event: state_changed author: "yoi ticket" at: 2026-06-11T15:45:52Z from: planning to: ready reason: cli_state field: state -->
+
+## State changed
+
+Marked ready by `yoi ticket state`.
+
+
+---
+
+<!-- event: state_changed author: "yoi ticket" at: 2026-06-11T15:45:53Z from: ready to: queued reason: queued field: state -->
+
+## State changed
+
+Ticket を `yoi ticket` が queued にしました。
+
+
+---
+
+<!-- event: state_changed author: "yoi ticket" at: 2026-06-11T15:45:53Z from: queued to: inprogress reason: cli_state field: state -->
+
+## State changed
+
+State changed to `inprogress`.
+
+
+---
+
+<!-- event: implementation_report author: hare at: 2026-06-11T15:59:55Z -->
+
+## Implementation report
+
+runtime workspace と process cwd を分離する実装を行った。
+
+- `--workspace` は runtime workspace / project context の基準として維持し、child process の current directory とは分離した。
+- `SpawnConfig` / Ticket role launch plan は内部値として `cwd` を持ち、CLI argument にはせず `Command::current_dir` にのみ使うようにした。
+- Panel Orchestrator launch/restore は `workspace_root = original workspace`、`cwd = dedicated orchestration worktree` として起動する。
+- `SpawnPod.cwd` は child process cwd 指定として扱い、`--workspace` は spawner の runtime workspace を渡すままにした。
+- Pod entrypoint は process cwd を起動時に snapshot し、workspace root とは別に Pod construction へ渡す。`--tool-cwd` は作らない。
+- `pwd` と `cwd` の意図的な意味差がない主要 runtime path は `cwd` に統一した。
+- metadata snapshot restore では、現在の launch manifest の scope/delegation scope を復元後 manifest に反映できるようにした。
+
+検証:
+
+- `cargo check`
+- `cargo test -p client`
+- `cargo test -p pod entrypoint::tests:: -- --nocapture`
+- `cargo test -p pod spawn_pod_launches_runtime_in_workspace_and_process_cwd -- --nocapture`
+- `cargo test -p pod spawn_pod_omitted_cwd_preserves_spawner_cwd -- --nocapture`
+- `cargo fmt --check`
+- `git diff --check`
+- `yoi ticket doctor`
+- `nix build .#yoi`
+
+補足:
+
+- `cargo test -p tools` は doctest の既存不整合 (`core_builtin_tools` の引数数) で失敗したため、この実装の検証対象からは外した。通常 unit/integration tests は通っている。
+
+
+---
+
+<!-- event: state_changed author: "yoi ticket" at: 2026-06-11T15:59:55Z from: inprogress to: done reason: cli_state field: state -->
+
+## State changed
+
+State changed to `done`.
+
+
+---
+
+<!-- event: state_changed author: hare at: 2026-06-13T16:34:06Z from: done to: closed reason: closed field: state -->
+
+## State changed
+
+Ticket を closed にしました。
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-13T16:34:06Z status: closed -->
+
+## 完了
+
+Closed after prior done-state completion.
+
+
+---

.yoi/tickets/00001KTVPS6K3/artifacts/orchestration-plan.jsonl

@@ -0,0 +1,2 @@
+{"id":"orch-plan-20260612-091119-1","ticket_id":"00001KTVPS6K3","kind":"waiting_capacity_note","note":"Workspace Panel Queue notification was received, but this Orchestrator cannot safely accept implementation yet. The Orchestrator Ticket backend still reads the Ticket as `ready`, while the root workspace has unsynced/uncommitted queued Ticket changes for `00001KTVPS6K3`; root workspace is dirty (`.yoi/tickets/00001KTVPS6K3/*` plus `crates/tui/src/multi_pod.rs`). Current active work `00001KTWPE3KQ` is also in review and is specifically fixing the Panel Queue durable handoff/sync path. Re-route this Ticket after the Queue handoff is safely synced/committed and active review/merge state is clear.","author":"orchestrator","at":"2026-06-12T09:11:19Z"}
+{"id":"orch-plan-20260612-123134-2","ticket_id":"00001KTVPS6K3","kind":"accepted_plan","accepted_plan":{"summary":"Ticket role launch の first-run user message を Submit-only の短い入力へ縮小し、role behavior は builtin Profile instruction、procedural guidance は Workflow へ分離する。実装は `crates/client/src/ticket_role.rs`、`resources/profiles/{intake,orchestrator,coder,reviewer}.lua`、`resources/prompts/ticket_role/*.md`、必要な workflow/prompt resource と focused tests を対象にする。","branch":"ticket/shorten-ticket-role-launch-input","worktree":"/home/hare/Projects/yoi/.worktree/shorten-ticket-role-launch-input","role_plan":"Coder は child worktree に限定して implementation と tests/validation を行う。Reviewer は read-only で、Instruction / Workflow / Submit / control-plane 境界、prompt-context 永続性、workspace/cwd/topology 情報の分離、既存 Ticket role launch/Panel launch/workflow invocation の互換性を確認する。"},"author":"orchestrator","at":"2026-06-12T12:31:34Z"}

.yoi/tickets/00001KTVPS6K3/item.md

@@ -0,0 +1,96 @@
+---
+title: 'Ticket role launch inputを短縮し、role behaviorをInstruction/Workflowへ分離する'
+state: 'closed'
+created_at: '2026-06-11T16:03:28Z'
+updated_at: '2026-06-12T13:08:52Z'
+assignee: null
+risk_flags: ['prompt-context', 'workflow-boundary', 'role-launch']
+queued_by: 'workspace-panel'
+queued_at: '2026-06-12T12:29:10Z'
+---
+
+## Background
+
+Ticket role Pod launch 時の初回 user message に、role の振る舞いや手順説明が長く含まれている。これを整理し、model-visible な情報の所管を明確にする。
+
+合意済みの分類:
+
+- Instruction: role behavior、恒常的な環境情報、language、workspace_root / cwd など Pod の動作に必要な環境情報。
+- Workflow: 手続き、手順、routing / implementation / review / close の flow。
+- Submit: 対象 Ticket 指定、ユーザー入力または system-generated action instruction、今回の操作対象として明示する path / worktree / branch / validation / report expectations。
+- Control-plane only: profile selector、workflow slug、launch_prompt ref、pod name など。原則として初回 user message には出さない。
+
+関連する既存 Ticket:
+
+- `00001KTRKZ14C`: Project workflowsをpublic builtinとdogfood運用に分離する。closed。
+- `00001KTGFMW70`: Builtin Workflow and Knowledge resources。closed。
+- `00001KTR6YVDB`: LLM向けプロンプト直書きを廃止してresources/promptsへ集約する。closed。
+
+## Requirements
+
+- Ticket role launch の generated first-run user message から、role behavior / procedural guidance / launch metadata の長文説明を削除する。
+- `Profile selector`、`Workflow`、`Configured launch_prompt ref` のような control-plane metadata は、初回 user message に含めない。
+- role としての振る舞いは builtin role Profile が選ぶ `worker.instruction` に移す。
+- 手続き・手順は Workflow に置く。
+- Submit に残す情報は、対象 Ticket id、ユーザー入力または launcher-generated action instruction、今回の操作対象として必要な per-launch context に限定する。
+- `language` は Instruction の環境情報として扱う。
+- `workspace_root` / `cwd` は Instruction/system 側の環境情報として扱う。ただし Git 操作や worktree 操作の対象として明示が必要な path は、重複しても Submit に書いてよい。
+- `resources/prompts/ticket_role/*.md` に残っている role-specific 長文 fragment を削除、縮小、または Instruction/Workflow 側へ移す。
+- `TicketRoleLaunchContext.user_instruction` は実態に合わせ、必要なら `action_instruction` / `launch_instruction` などへ rename する。user-authored text と launcher-generated instruction が混ざっていることを表現できる名前にする。
+- 既存の workflow invocation、workspace/user prompt override、Ticket role launch、Panel Intake / Orchestrator launch の動作を壊さない。
+
+## Acceptance criteria
+
+- Ticket role launch の first-run `Segment::Text` が短くなり、対象 Ticket / action instruction / per-launch context だけを含む。
+- role behavior は builtin role instruction prompt から供給される。
+- procedural guidance は Workflow に残る、または Workflow に移されている。
+- control-plane metadata は prompt text ではなく launch plan / diagnostics / trace に留まる。
+- Ticket record language guidance は初回 user message ではなく Instruction 側の環境情報として扱われる。
+- Orchestrator launch で必要な workspace/cwd/topology 情報は、Pod 環境情報と per-operation Submit 情報に分離され、Git/worktree 操作対象として必要なものは Submit 内で明示される。
+- 関連する unit tests が新しい出力方針を検証している。
+- `nix build .#yoi` が通る。
+
+## Binding decisions / invariants
+
+- Instruction: 振る舞い、恒常的な環境情報。
+- Workflow: 手続き、手順。
+- Submit: 対象チケットの指定、ユーザー入力または system-generated action instruction、今回の操作対象。
+- `workflow slug` と `profile selector` は初回 user message には不要。
+- `language` は Instruction 所管。
+- `workspace_root` / `cwd` は Instruction/system 側に置く。ただし今回の Git/worktree 操作対象として必要な path は Submit に重複記載してよい。
+- Ticket config に role-level `system_instruction` / `instruction` field は追加しない。builtin role Profile が `worker.instruction` を選ぶ。
+- launch context template 化は行わない。過剰なテンプレート化ではなく、Rust 側の短い Submit 組み立てに留める。
+
+## Implementation latitude
+
+- builtin role instruction prompt のファイル名・配置は実装者が既存 prompt resource conventions に合わせて決めてよい。
+- `resources/prompts/ticket_role` の既存 fragment は、不要なら削除してよい。
+- `user_instruction` rename は、変更範囲が大きすぎる場合は別名追加や段階的移行でもよい。ただし model-visible label は `User/action instruction` より正確な名前にする。
+- Workflow 側に移す文言は public builtin workflow と workspace dogfood workflow の責務差を保つ。
+
+## Readiness
+
+- readiness: implementation_ready
+- risk_flags: [prompt-context, workflow-boundary, role-launch]
+
+## Escalation conditions
+
+- Instruction / Workflow / Submit の境界に収まらない新しい model-visible 情報が見つかった場合は、実装前に判断を戻す。
+- Ticket role launch の dynamic data を Instruction minijinja context に入れたくなる場合は、処理対象データを system prompt に入れていないか確認して判断を戻す。
+- Ticket config schema に新しい instruction field を追加したくなる場合は判断を戻す。
+
+## Validation
+
+- Ticket role launch prompt 出力を検証する unit tests。
+- builtin role Profile が instruction prompt を解決できることの検証。
+- relevant cargo tests。
+- `nix build .#yoi`。
+
+## Related work
+
+- `resources/prompts/ticket_role/*.md`
+- `resources/profiles/{intake,orchestrator,coder,reviewer}.lua`
+- `resources/workflows/*`
+- `.yoi/workflow/*`
+- `crates/client/src/ticket_role.rs`
+- `crates/pod/src/prompt/system.rs`

.yoi/tickets/00001KTVPS6K3/resolution.md

@@ -0,0 +1,32 @@
+Ticket role launch の first-run user message を短縮し、role behavior / procedural guidance / control-plane metadata の所管を分離した。
+
+実装概要:
+- `crates/client/src/ticket_role.rs` の launch Submit text を短縮し、対象 Ticket / action instruction / per-launch context に限定した。
+- `Profile selector`、`Workflow`、`Configured launch_prompt ref`、Ticket record language guidance、runtime workspace/cwd などの control-plane / environment 情報を first-run user text から外した。
+- builtin role Profiles に `worker.instruction = "$yoi/role/<role>"` を設定し、role behavior を `resources/prompts/role/{intake,orchestrator,coder,reviewer}.md` へ移した。
+- procedural guidance は Workflow resources 側に保持・移動した。
+- obsolete な `resources/prompts/ticket_role/*.md` fragments を削除した。
+- boundary を検証する focused unit tests を追加・更新した。
+
+Review / integration:
+- Implementation commit: `949531a0 client: shorten ticket role launch input`
+- Reviewer: `yoi-reviewer-role-launch-input` が approve。
+- Orchestrator merge commit: `bdbd955b merge: ticket role launch input split`
+- Ticket completion commit: `9ad5ed6d ticket: mark role launch done`
+
+Validation:
+- `cargo test -p client ticket_role --lib`: pass
+- `cargo test -p manifest builtin_role_profiles_are_registered_and_resolve --lib`: pass
+- `cargo test -p pod builtin_ticket_role_instructions_resolve --lib`: pass
+- `cargo fmt --check`: pass
+- `git diff --check HEAD~1..HEAD`: pass
+- `nix build .#yoi`: pass
+- `./result/bin/yoi ticket doctor`: `doctor: ok`
+
+Cleanup:
+- coder/reviewer Pods stopped。
+- child worktree `/home/hare/Projects/yoi/.worktree/shorten-ticket-role-launch-input` removed。
+- branch `ticket/shorten-ticket-role-launch-input` deleted。
+
+Non-blocking follow-up:
+- 旧 `.yoi/prompts/ticket_role/*` override は launch Submit text には効かなくなるため、外部ユーザー向けには role behavior は Profile instruction、手順は Workflow override へ移す旨を必要に応じて案内すると安全。

.yoi/tickets/00001KTVPS6K3/thread.md

@@ -0,0 +1,374 @@
+<!-- event: create author: LocalTicketBackend at: 2026-06-11T16:03:28Z -->
+
+## 作成
+
+LocalTicketBackend によって作成されました。
+
+---
+
+<!-- event: intake_summary author: intake at: 2026-06-11T16:03:33Z -->
+
+## Intake summary
+
+Ticket role launch の初回 user message を短縮し、情報所管を Instruction / Workflow / Submit / control-plane に分離する方針で合意済み。language と workspace_root/cwd は Instruction 側の環境情報、Git/worktree 操作対象として必要な path は Submit に重複記載可。workflow slug/profile selector は初回 user message に含めない。
+
+---
+
+<!-- event: state_changed author: intake at: 2026-06-11T16:03:33Z from: planning to: ready reason: planning_ready field: state -->
+
+## State changed
+
+要件・受け入れ条件・境界判断が揃ったため、Orchestrator routing 可能。実装はユーザーが panel で queue した後に開始する。
+
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-12T09:11:30Z -->
+
+## Decision
+
+Routing decision: blocked_by_dependency_or_missing_authority
+
+Reason:
+- Workspace Panel Queue notification was received, but this Orchestrator backend still reads the Ticket as `ready`, not `queued`.
+- The root workspace has unsynced/uncommitted queue-related changes for this Ticket and is dirty, including `.yoi/tickets/00001KTVPS6K3/*` and `crates/tui/src/multi_pod.rs`.
+- Active in-progress work `00001KTWPE3KQ` is currently fixing the Panel Queue durable handoff/sync path and is in reviewer handoff; accepting this new Ticket before that path is reviewed/merged would require manual sync/queue recovery and could mix queue-side effects with unrelated dirty root changes.
+
+Evidence checked:
+- TicketShow `00001KTVPS6K3`: Orchestrator backend state is `ready`.
+- TicketRelationQuery: no relation blockers.
+- TicketOrchestrationPlanQuery: no prior plan records before this routing note.
+- Root/orchestrator git state: Orchestrator branch has local routing record changes; root workspace is dirty with this Ticket's `.yoi` files and `crates/tui/src/multi_pod.rs`.
+- Visible Pods: active reviewer `yoi-reviewer-panel-queue-sync` for `00001KTWPE3KQ`.
+
+Next action:
+- Leave this Ticket unaccepted for implementation in this Orchestrator pass.
+- Re-route after the Panel Queue durable handoff work is resolved and the root/orchestration Ticket state is synchronized cleanly, or after a human explicitly instructs manual recovery for the queued root-side changes.
+
+Escalate if:
+- The queued root-side changes should be manually committed/synced despite the current dirty workspace and active Queue-handoff fix.
+
+---
+
+<!-- event: state_changed author: workspace-panel at: 2026-06-12T12:29:10Z from: ready to: queued reason: queued field: state -->
+
+## State changed
+
+Ticket を `workspace-panel` が queued にしました。
+
+
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-12T12:32:06Z -->
+
+## Decision
+
+Routing decision: implementation_ready
+
+Reason:
+- Ticket body は Ticket role launch の first-run user message から role behavior / procedural guidance / control-plane metadata を外し、Submit に対象 Ticket / action instruction / per-launch context だけを残す方針を明確に記録している。
+- Instruction / Workflow / Submit / control-plane の境界、Ticket config schema に instruction field を追加しないこと、launch context template 化を避けることが binding decision として記録済みである。
+- `ready -> queued` は workspace-panel により再実行され、現在の Orchestrator backend でも `queued` として読める。relation blocker はない。
+- 以前の blocker だった Panel Queue durable handoff work `00001KTWPE3KQ` は closed 済みで、現在の orchestration worktree は clean。残る不確実性は既存 prompt/profile/workflow resource と `crates/client/src/ticket_role.rs` 周辺の bounded implementation investigation に閉じている。
+
+Evidence checked:
+- Ticket body / thread / artifacts: `item.md`、`thread.md`、既存 waiting-capacity note を確認。
+- TicketRelationQuery: outgoing/incoming relation なし、blocker なし。
+- TicketOrchestrationPlanQuery: 既存 `waiting_capacity_note` と、今回の accepted plan `orch-plan-20260612-123134-2` を確認。
+- Related Ticket: `00001KTWPE3KQ` は closed 済みで、Queue handoff blocker は解消済み。
+- Workspace state: Orchestrator worktree `orchestration/yoi-orchestrator` は clean。
+- Code/resource map: `crates/client/src/ticket_role.rs`, `resources/profiles/orchestrator.lua`, `resources/prompts/ticket_role/*.md` と関連 prompt/profile/workflow resource を確認。
+- Durable context: prompt prose は resources/prompts へ集約し、Profile/Workflow が role behavior/procedure を所有する既存方針に一致する。
+- Visible Pods: active child Pod なし。
+
+IntentPacket:
+
+Intent:
+- Ticket role Pod launch の初回 user message を短縮し、model-visible な launch input を Submit-only の per-launch context に近づける。
+- role behavior は builtin role Profile が選ぶ Instruction、procedural guidance は Workflow、control-plane metadata は launch plan/diagnostics/trace に分離する。
+
+Binding decisions / invariants:
+- `Profile selector`、`Workflow`、`Configured launch_prompt ref` などの control-plane metadata は first-run user message に含めない。
+- role behavior / 恒常的環境情報 / language / workspace_root / cwd は Instruction/system 側の責務とする。ただし今回の Git/worktree 操作対象として必要な path は Submit に明示してよい。
+- procedural guidance は Workflow 側に置く。
+- Submit に残す情報は対象 Ticket、action instruction、今回の操作対象として必要な per-launch context に限定する。
+- Ticket config に role-level `system_instruction` / `instruction` field を追加しない。
+- launch context の過剰なテンプレート化は行わず、Rust 側の短い Submit 組み立てに留める。
+- 新しい input を hidden context として差し込まず、必要な model-visible context は適切な Instruction/Workflow/committed user task/history 経由にする。
+
+Requirements / acceptance criteria:
+- Ticket role launch の first-run `Segment::Text` が短くなり、対象 Ticket / action instruction / per-launch context だけを含む。
+- role behavior は builtin role instruction prompt から供給される。
+- procedural guidance は Workflow に残る、または Workflow に移されている。
+- control-plane metadata は prompt text ではなく launch plan / diagnostics / trace に留まる。
+- Ticket record language guidance は first-run user message ではなく Instruction 側の環境情報として扱われる。
+- Orchestrator launch で必要な workspace/cwd/topology 情報は Pod 環境情報と per-operation Submit 情報に分離され、Git/worktree 操作対象として必要なものだけ Submit 内で明示される。
+- 関連 unit tests が新しい出力方針を検証する。
+- `nix build .#yoi` が通る。
+
+Implementation latitude:
+- builtin role instruction prompt のファイル名・配置は既存 prompt resource conventions に合わせて選んでよい。
+- `resources/prompts/ticket_role` の既存 fragment は、不要なら削除または縮小してよい。
+- `TicketRoleLaunchContext.user_instruction` rename は、変更量が大きい場合は段階的移行でもよい。ただし model-visible label は `User/action instruction` より正確な名前にする。
+- Workflow 側に移す文言は public builtin workflow と workspace dogfood workflow の責務差を保つ。
+
+Escalate if:
+- Instruction / Workflow / Submit の境界に収まらない新しい model-visible 情報が見つかる。
+- Ticket role launch の dynamic data を Instruction minijinja context に入れる必要が出る。
+- Ticket config schema に新しい instruction field を追加する必要が出る。
+- Workflow invocation、workspace/user prompt override、Ticket role launch、Panel Intake / Orchestrator launch のいずれかを壊さないと実現できない。
+
+Validation:
+- Ticket role launch prompt 出力の unit tests。
+- builtin role Profile が instruction prompt を解決できることの focused validation。
+- relevant cargo tests。
+- `cargo fmt --check`。
+- `git diff --check`。
+- `target/debug/yoi ticket doctor` または built binary の `yoi ticket doctor`。
+- `nix build .#yoi`。
+
+Current code map:
+- 主対象: `crates/client/src/ticket_role.rs`。
+- Profile/resource: `resources/profiles/{intake,orchestrator,coder,reviewer}.lua`, `resources/prompts/ticket_role/*.md`, 必要な `resources/workflows/*` / `.yoi/workflow/*`。
+- Prompt/system integration check: `crates/pod/src/prompt/system.rs`。
+- Implementation worktree では Orchestrator/main `.yoi` records、`.yoi/memory`、local/runtime/log/lock/secret-like `.yoi` paths を生成・編集しない。
+
+Critical risks / reviewer focus:
+- control-plane metadata が first-run user message に残っていないこと。
+- role behavior / procedure が Submit に残留せず、Instruction / Workflow の適切な boundary に移っていること。
+- Ticket record language guidance と workspace/cwd/topology 情報が hidden/ephemeral context injection になっていないこと。
+- Dynamic Ticket data を system Instruction 側へ混ぜないこと。
+- 既存 Ticket role launch、Panel Intake/Orchestrator launch、workflow invocation、prompt override の動作を壊していないこと。
+
+Next action:
+- `queued -> inprogress` を記録してから、branch `ticket/shorten-ticket-role-launch-input` / worktree `/home/hare/Projects/yoi/.worktree/shorten-ticket-role-launch-input` を作成し、sibling coder に narrow write scope で実装を委譲する。Reviewer は coder evidence 後に read-only で起動する。
+
+---
+
+<!-- event: state_changed author: orchestrator at: 2026-06-12T12:32:11Z from: queued to: inprogress reason: orchestrator_acceptance field: state -->
+
+## State changed
+
+Routing accepted for implementation. Ticket body/thread, relation blockers, orchestration plan, prior waiting-capacity note, closed Queue-handoff dependency, current Orchestrator workspace state, relevant prompt/profile/workflow code map, and visible Pods were rechecked. No unresolved blocker or missing planning decision remains. Implementation side effects will start only after this accepted `queued -> inprogress` transition is recorded, using accepted plan `orch-plan-20260612-123134-2`.
+
+---
+
+<!-- event: plan author: orchestrator at: 2026-06-12T12:32:36Z -->
+
+## Plan
+
+Implementation worktree created for multi-agent handoff.
+
+- Ticket: `00001KTVPS6K3`
+- Branch: `ticket/shorten-ticket-role-launch-input`
+- Worktree: `/home/hare/Projects/yoi/.worktree/shorten-ticket-role-launch-input`
+- Base: Orchestrator workspace HEAD `ae66c447` (`orchestration/yoi-orchestrator`), including the accepted routing record and `queued -> inprogress` transition.
+- Scope rule: implementation work happens only in this child worktree. Root/original workspace must not be read, written, validated, merged, cleaned, or used for git operations.
+- Next: spawn sibling coder with narrow write scope to the implementation worktree. Reviewer will be started after coder evidence is available.
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-12T12:33:47Z -->
+
+## Implementation report
+
+Coder spawn initial attempt failed before socket creation.
+
+- Coder Pod name: `yoi-coder-role-launch-input`
+- Error: `cwd is not readable under the configured scope: /home/hare/Projects/yoi`
+- Recovery: retry with the same child worktree write scope plus minimal non-recursive read authority on the runtime workspace root required by spawn validation. The coder task still explicitly prohibits reading/writing/validating/merging/cleaning/running git in the root/original workspace and must operate from the child worktree only.
+
+---
+
+<!-- event: plan author: orchestrator at: 2026-06-12T12:34:21Z -->
+
+## Plan
+
+Coder delegated.
+
+- Coder Pod: `yoi-coder-role-launch-input`
+- Worktree: `/home/hare/Projects/yoi/.worktree/shorten-ticket-role-launch-input`
+- Branch: `ticket/shorten-ticket-role-launch-input`
+- Scope: write `/home/hare/Projects/yoi/.worktree/shorten-ticket-role-launch-input`; read child worktree plus minimal non-recursive runtime-root read required by spawn validation.
+- Task: shorten Ticket role launch first-run Submit input, move/keep role behavior in builtin Profile instruction, keep procedural guidance in Workflow, keep control-plane metadata out of first-run user text, add focused tests, validate with relevant cargo tests and `nix build .#yoi`.
+- Constraint: coder was instructed not to use root/original workspace for decision evidence or git/validation/cleanup, and not to create generated memory/local/runtime/log/lock/secret-like `.yoi` paths.
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-12T12:56:48Z -->
+
+## Implementation report
+
+Coder completed implementation.
+
+Coder Pod:
+- `yoi-coder-role-launch-input`
+
+Implementation branch/worktree:
+- Branch: `ticket/shorten-ticket-role-launch-input`
+- Worktree: `/home/hare/Projects/yoi/.worktree/shorten-ticket-role-launch-input`
+- Commit: `949531a0 client: shorten ticket role launch input`
+- Worktree status: clean
+
+Changed surfaces:
+- `crates/client/src/ticket_role.rs`
+- `crates/manifest/src/profile.rs`
+- `crates/pod/src/prompt/loader.rs`
+- `resources/profiles/{intake,orchestrator,coder,reviewer}.lua`
+- `resources/prompts/role/{intake,orchestrator,coder,reviewer}.md`
+- removed obsolete `resources/prompts/ticket_role/*.md`
+- `resources/workflows/{multi-agent-workflow,ticket-intake-workflow,ticket-orchestrator-routing}.md`
+
+Orchestrator-verified evidence from child worktree:
+- `git status --short --branch` clean on `ticket/shorten-ticket-role-launch-input`
+- `cargo test -p client ticket_role --lib`: pass, 16 tests
+- `cargo test -p manifest builtin_role_profiles_are_registered_and_resolve --lib`: pass, 1 test
+- `cargo test -p pod builtin_ticket_role_instructions_resolve --lib`: pass, 1 test
+- `cargo fmt --check`: pass
+- `git diff --check orchestration/yoi-orchestrator...HEAD`: pass
+- `./result/bin/yoi ticket doctor`: `doctor: ok`
+- `nix build .#yoi`: pass
+
+Next:
+- Spawn read-only sibling reviewer against the recorded intent, binding decisions/invariants, acceptance criteria, commit `949531a0`, diff, and validation evidence.
+
+---
+
+<!-- event: plan author: orchestrator at: 2026-06-12T12:57:29Z -->
+
+## Plan
+
+Reviewer delegated.
+
+- Reviewer Pod: `yoi-reviewer-role-launch-input`
+- Target branch/worktree: `ticket/shorten-ticket-role-launch-input` at `/home/hare/Projects/yoi/.worktree/shorten-ticket-role-launch-input`
+- Commit under review: `949531a0 client: shorten ticket role launch input`
+- Scope: read-only child worktree plus minimal non-recursive runtime-root read required by spawn validation.
+- Review basis: recorded IntentPacket, binding decisions/invariants, acceptance criteria, implementation summary, diff, and Orchestrator-verified validation evidence.
+- Reviewer focus: control-plane metadata absence from first-run user text, Instruction/Workflow/Submit boundary, no hidden dynamic context injection, profile instruction resolution, workflow/prompt override safety, and non-brittle tests.
+
+---
+
+<!-- event: review author: reviewer:yoi-reviewer-role-launch-input at: 2026-06-12T13:06:54Z status: approve -->
+
+## Review: approve
+
+Approve.
+
+Review target:
+- Worktree: `/home/hare/Projects/yoi/.worktree/shorten-ticket-role-launch-input`
+- Commit: `949531a07ede4fd9f82787454ac4d996f25b272d`
+- Worktree status: clean
+
+Evidence:
+- `crates/client/src/ticket_role.rs` の first-run `Segment::Text` は `build_launch_prompt` で対象 Ticket、`Action instruction`、Panel handoff、intent packet、operation/worktree target、validation/report expectations に限定されている。
+- `profile` / `workflow` / `launch_prompt_ref` / workspace-root 系の制御情報は `TicketRoleLaunchPlan` / `SpawnConfig` 側に残り、Submit text には出ていない。
+- `WorkflowInvoke` は `Segment::WorkflowInvoke` として別 segment に維持されている。
+- unit tests は `Configured launch_prompt`、`Profile selector`、`Workflow:`、Ticket record language、`role_workspace_root` / `role_cwd` 等が first-run text に入らないことと、必要な path/branch/validation/report expectation が残ることを直接検証している。
+- builtin role Profiles は `worker.instruction = "$yoi/role/<role>"` を設定し、`resources/prompts/role/*` に role behavior が移っている。procedural guidance は `resources/workflows/*` に残っている。
+- 削除された `resources/prompts/ticket_role/*` への production code 参照は残っていない。prompt loader の `$user` / `$workspace` 解決機構と workflow invocation は維持されている。
+- `git diff --check orchestration/yoi-orchestrator...HEAD` は問題なし。Orchestrator が提示した focused cargo tests、`cargo fmt --check`、`ticket doctor`、`nix build .#yoi` の validation evidence は受け入れ可能。
+
+Non-blocking risk:
+- 旧 `.yoi/prompts/ticket_role/*` override は、この surface の削除により launch Submit text には効かなくなる。今回の Ticket では既存 fragment の削除が許容されているため blocker ではないが、外部ユーザー向けには role behavior は Profile instruction、手順は Workflow override へ移す旨を後で案内すると安全。
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-12T13:08:07Z -->
+
+## Implementation report
+
+Integration completed in the Orchestrator workspace.
+
+Integrated implementation:
+- Ticket: `00001KTVPS6K3`
+- Implementation branch: `ticket/shorten-ticket-role-launch-input`
+- Implementation commit: `949531a0 client: shorten ticket role launch input`
+- Reviewer result: approve, no blockers
+- Orchestrator merge commit: `bdbd955b merge: ticket role launch input split`
+- Integration target: `orchestration/yoi-orchestrator`
+
+Post-integration validation from Orchestrator worktree:
+- `cargo test -p client ticket_role --lib`: pass, 16 tests
+- `cargo test -p manifest builtin_role_profiles_are_registered_and_resolve --lib`: pass, 1 test
+- `cargo test -p pod builtin_ticket_role_instructions_resolve --lib`: pass, 1 test
+- `cargo fmt --check`: pass
+- `git diff --check HEAD~1..HEAD`: pass
+- `nix build .#yoi`: pass
+- `./result/bin/yoi ticket doctor`: `doctor: ok`
+
+Remaining non-blocking risk:
+- 旧 `.yoi/prompts/ticket_role/*` override は launch Submit text には効かなくなる。今回の Ticket では fragment 削除が許容されているため blocker ではないが、外部ユーザー向けには role behavior は Profile instruction、手順は Workflow override へ移す旨を後続で案内すると安全。
+
+---
+
+<!-- event: state_changed author: orchestrator at: 2026-06-12T13:08:11Z from: inprogress to: done reason: implementation_merged_and_validated field: state -->
+
+## State changed
+
+Implementation was merged into the Orchestrator branch, reviewer approved, and post-integration validation passed. Cleanup and closure will be recorded next.
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-12T13:08:36Z -->
+
+## Implementation report
+
+Cleanup completed.
+
+- Stopped coder Pod: `yoi-coder-role-launch-input`
+- Stopped reviewer Pod: `yoi-reviewer-role-launch-input`
+- Removed child worktree: `/home/hare/Projects/yoi/.worktree/shorten-ticket-role-launch-input`
+- Deleted implementation branch: `ticket/shorten-ticket-role-launch-input`
+- Orchestrator worktree status after cleanup: clean
+
+Cleanup was limited to child implementation worktree/branch and related child Pods. Root/original workspace was not touched.
+
+---
+
+<!-- event: state_changed author: hare at: 2026-06-12T13:08:52Z from: done to: closed reason: closed field: state -->
+
+## State changed
+
+Ticket を closed にしました。
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-12T13:08:52Z status: closed -->
+
+## 完了
+
+Ticket role launch の first-run user message を短縮し、role behavior / procedural guidance / control-plane metadata の所管を分離した。
+
+実装概要:
+- `crates/client/src/ticket_role.rs` の launch Submit text を短縮し、対象 Ticket / action instruction / per-launch context に限定した。
+- `Profile selector`、`Workflow`、`Configured launch_prompt ref`、Ticket record language guidance、runtime workspace/cwd などの control-plane / environment 情報を first-run user text から外した。
+- builtin role Profiles に `worker.instruction = "$yoi/role/<role>"` を設定し、role behavior を `resources/prompts/role/{intake,orchestrator,coder,reviewer}.md` へ移した。
+- procedural guidance は Workflow resources 側に保持・移動した。
+- obsolete な `resources/prompts/ticket_role/*.md` fragments を削除した。
+- boundary を検証する focused unit tests を追加・更新した。
+
+Review / integration:
+- Implementation commit: `949531a0 client: shorten ticket role launch input`
+- Reviewer: `yoi-reviewer-role-launch-input` が approve。
+- Orchestrator merge commit: `bdbd955b merge: ticket role launch input split`
+- Ticket completion commit: `9ad5ed6d ticket: mark role launch done`
+
+Validation:
+- `cargo test -p client ticket_role --lib`: pass
+- `cargo test -p manifest builtin_role_profiles_are_registered_and_resolve --lib`: pass
+- `cargo test -p pod builtin_ticket_role_instructions_resolve --lib`: pass
+- `cargo fmt --check`: pass
+- `git diff --check HEAD~1..HEAD`: pass
+- `nix build .#yoi`: pass
+- `./result/bin/yoi ticket doctor`: `doctor: ok`
+
+Cleanup:
+- coder/reviewer Pods stopped。
+- child worktree `/home/hare/Projects/yoi/.worktree/shorten-ticket-role-launch-input` removed。
+- branch `ticket/shorten-ticket-role-launch-input` deleted。
+
+Non-blocking follow-up:
+- 旧 `.yoi/prompts/ticket_role/*` override は launch Submit text には効かなくなるため、外部ユーザー向けには role behavior は Profile instruction、手順は Workflow override へ移す旨を必要に応じて案内すると安全。
+
+---

.yoi/tickets/00001KTWPE3KQ/artifacts/orchestration-plan.jsonl

@@ -0,0 +1 @@
+{"id":"orch-plan-20260612-084329-1","ticket_id":"00001KTWPE3KQ","kind":"accepted_plan","note":"Role Pods は今回起動しない。明示 follow-up まで queued のまま保持する。","accepted_plan":{"summary":"Routing では implementation_ready と判断した。ただし今回の launch instruction は role Pod spawn を explicit follow-up まで待つ指定のため、現時点では queued のまま保持し、queued -> inprogress、worktree 作成、coder/reviewer spawn、merge/close は行わない。実装開始時は side effect 前に TicketShow / relation / orchestration plan / git/worktree state を再確認し、問題なければ queued -> inprogress を記録してから進める。実装対象は Panel Queue action を root/dev 側 Ticket mutation + Queue commit + orchestration worktree ff-only sync + sync 確認後 Orchestrator notify/kick という durable handoff にすること。","branch":"ticket/panel-queue-orchestrator-sync","worktree":"/home/hare/Projects/yoi/.worktree/panel-queue-orchestrator-sync","role_plan":"次の明示 follow-up 後に Orchestrator が worktree-workflow で実装 worktree を作り、coder はその worktree に narrow write scope、reviewer は read-only scopeで sibling として起動する。Queue commit の対象差分限定、root/orchestration worktree identity checks、ff-only sync、dirty/divergent workspace block、workspace_root と cwd の分離維持を reviewer focus とする。"},"author":"orchestrator","at":"2026-06-12T08:43:29Z"}

.yoi/tickets/00001KTWPE3KQ/item.md

@@ -0,0 +1,125 @@
+---
+title: 'Panel Queue時にdevとOrchestrator worktreeを同期する'
+state: 'closed'
+created_at: '2026-06-12T01:16:39Z'
+updated_at: '2026-06-12T12:26:26Z'
+assignee: null
+queued_by: 'yoi ticket'
+queued_at: '2026-06-12T02:39:25Z'
+---
+
+## 背景
+
+Orchestrator 用 dedicated worktree を分離したことで、Panel が操作する root workspace と Orchestrator が Ticket tools で見る worktree は別 checkout になった。
+
+```text
+root workspace / dev
+  Panel / human が Ticket を操作する場所
+
+orchestration worktree / orchestration branch
+  Orchestrator Pod の cwd
+  Orchestrator の Ticket tools が見る `.yoi/tickets` backend
+```
+
+Ticket tools は Pod の cwd を基準に動作するべきであり、Orchestrator は orchestration worktree 側の `.yoi/tickets` を見る。そのため、Panel の Queue action で root/dev 側の Ticket を `ready -> queued` にするだけでは、Orchestrator が最新 Ticket state を見られない。
+
+Queue は Orchestrator への durable handoff point なので、Orchestrator を kick する前に、root/dev 側の queued Ticket commit が orchestration worktree 側にも反映されている必要がある。
+
+## ゴール
+
+Panel の Queue action を、単なる Ticket state mutation ではなく、次の invariant を満たす安全な handoff として扱う。
+
+1. root workspace の dev 側で対象 Ticket が `ready -> queued` になっている。
+2. その変更が dev に commit されている。
+3. orchestration worktree / branch がその commit を取り込んでいる。
+4. Orchestrator は sync 済みの Ticket backend を見た状態で notify / restore / kick される。
+
+## 要件
+
+### Queue 実行前チェック
+
+Panel の Queue action は、Ticket mutation 前に次の read-only check をすべて行う。ここに書いた条件以外を暗黙に判定しない。
+
+- root workspace の canonical Git top-level が Panel の workspace root と一致する。
+- orchestration worktree の canonical Git top-level が Panel が作成・記録した orchestration worktree path と一致する。
+- root workspace と orchestration worktree の `git rev-parse --git-common-dir` が同じ repository を指す。
+- root workspace の current branch が Panel の merge target branch（この repository では `develop`）と一致する。
+- orchestration worktree の current branch が Panel の orchestration branch と一致する。
+- root workspace の `git status --porcelain` が空である。
+- orchestration worktree の `git status --porcelain` が空である。
+- root workspace 側 Ticket backend で対象 Ticket が `ready` として読める。
+- `git merge-base --is-ancestor <orchestration_head> <root_head>` が成功し、orchestration branch が root branch へ fast-forward 可能である。
+
+いずれかが失敗した場合、Panel は Ticket mutation、commit、branch sync、Orchestrator notify/kick を行わず、失敗した check 名と対象 path / branch / Ticket id を表示する。
+
+### Queue commit
+
+Panel が Queue を実行する場合、root workspace 側で次の順序を守る。
+
+1. 対象 Ticket を `ready -> queued` に遷移する。
+2. `git status --porcelain` の差分が対象 Ticket record だけであることを確認する。
+3. 対象 Ticket record だけを stage する。
+4. dev 上に Queue commit を作る。
+5. 作成した commit sha を記録する。
+
+commit message は機械的でよいが、対象 Ticket id が分かるものにする。
+
+Queue commit は Ticket handoff の authority であり、Orchestrator kick より前に完了している必要がある。
+
+### dev -> orchestration sync
+
+Queue commit 後、Panel は orchestration worktree を Queue commit へ fast-forward する。
+
+自動同期で許可する操作は次だけに限定する。
+
+```text
+git -C <orchestration_worktree> merge --ff-only <queue_commit_sha>
+```
+
+この操作が失敗した場合、Panel は Queue を完了扱いにせず、Orchestrator notify/kick もしない。Panel は `orchestration branch cannot fast-forward to queue commit` と commit sha を表示する。
+
+自動同期では merge commit、rebase、stash、patch apply、conflict resolution、dirty worktree cleanup を行わない。
+
+### Orchestrator kick ordering
+
+Orchestrator notify / restore / kick は、次を確認した後にだけ行う。
+
+- root/dev 側の Queue commit sha が分かっている。
+- orchestration worktree 側 HEAD がその commit を含んでいる。
+- orchestration worktree 側の Ticket backend で対象 Ticket が `queued` として読める。
+
+### Panel feedback
+
+成功時は、Panel に次を表示する。
+
+- queued Ticket id。
+- dev 側 Queue commit sha。
+- orchestration worktree sync 結果。
+- Orchestrator notify/kick の有無。
+
+失敗時は、どの条件で止まったかを具体的に表示する。
+
+例:
+
+- root workspace has uncommitted changes。
+- orchestration worktree is dirty。
+- orchestration branch cannot fast-forward to dev。
+- orchestration worktree does not contain queued commit。
+
+## 非目標
+
+- dirty root workspace の変更を自動 stash / patch / commit すること。
+- dirty orchestration worktree を自動修復すること。
+- dev と orchestration branch の merge conflict を Panel が解決すること。
+- Queue されていない Ticket を自動開始すること。
+- Queue action で Orchestrator の routing / acceptance を代行すること。
+
+## 受け入れ条件
+
+- Panel Queue action が、Ticket `ready -> queued` を dev に commit してから orchestration worktree に同期する。
+- sync 後、orchestration worktree 側 Ticket backend で対象 Ticket が `queued` として確認できる。
+- Orchestrator notify / restore / kick は、orchestration worktree が Queue commit を含むことを確認してから行われる。
+- root dirty / orchestration dirty / branch divergence / non-ff sync required の場合、Queue は block され、理由が Panel に表示される。
+- Panel が自動 conflict resolution や stash を行わない。
+- Ticket tools が cwd 基準で動く設計を前提に、workspace_root と cwd の分離を崩さない。
+- `nix build .#yoi` が通る。

.yoi/tickets/00001KTWPE3KQ/resolution.md

@@ -0,0 +1,20 @@
+Panel Queue handoff implementation was merged from `ticket/panel-queue-orchestrator-sync` into `orchestration/yoi-orchestrator`, then merged into `develop`.
+
+Implemented behavior:
+- Panel Queue performs the root-side Ticket `ready -> queued` mutation and Queue commit.
+- The dedicated orchestration worktree is synchronized with ff-only semantics before Orchestrator notification.
+- Queue success/failure paths report Ticket id, Queue commit, sync result, and notification outcome.
+- Dirty/divergent/state-mismatch/worktree-identity failure cases are blocked with explicit diagnostics.
+
+Validation after merge:
+- `cargo fmt`
+- `cargo test -p client ticket_role`
+- `cargo test -p tui ticket_queue_notification_message_carries_routing_contract`
+- `target/debug/yoi ticket doctor`
+- `cargo check --workspace`
+- `nix build .#yoi`
+- `cargo test -p tui ticket_queue_notification_message_carries_routing_contract`
+
+Cleanup:
+- Removed implementation worktree `/home/hare/Projects/yoi/.worktree/panel-queue-orchestrator-sync`.
+- Deleted merged branch `ticket/panel-queue-orchestrator-sync`.

.yoi/tickets/00001KTWPE3KQ/thread.md

@@ -0,0 +1,305 @@
+<!-- event: create author: "yoi ticket" at: 2026-06-12T01:16:39Z -->
+
+## 作成
+
+LocalTicketBackend によって作成されました。
+
+---
+
+<!-- event: intake_summary author: hare at: 2026-06-12T02:39:25Z -->
+
+## Intake summary
+
+Marked ready by `yoi ticket state`.
+
+---
+
+<!-- event: state_changed author: "yoi ticket" at: 2026-06-12T02:39:25Z from: planning to: ready reason: cli_state field: state -->
+
+## State changed
+
+Marked ready by `yoi ticket state`.
+
+
+---
+
+<!-- event: state_changed author: "yoi ticket" at: 2026-06-12T02:39:25Z from: ready to: queued reason: queued field: state -->
+
+## State changed
+
+Ticket を `yoi ticket` が queued にしました。
+
+
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-12T08:43:58Z -->
+
+## Decision
+
+Routing decision: implementation_ready
+
+Reason:
+- Ticket body は Panel Queue action の目的、binding invariants、失敗時の block 条件、非目標、受け入れ条件を observable に記録している。
+- `ready -> queued` は既に記録済みで、relation blocker はない。
+- 設計境界は「Ticket tools は cwd 基準」「Panel は root/dev 側の Queue commit を authority とし、Orchestrator kick 前に orchestration worktree を ff-only sync する」「自動 conflict resolution / stash / rebase はしない」として十分に固定されている。
+- 残る不確実性は既存 Panel/Ticket/git helper 実装への bounded implementation investigation と local tactic selection に閉じている。
+
+Evidence checked:
+- Ticket body / thread / artifacts: `00001KTWPE3KQ` の本文、state/event、artifact なしを確認。
+- TicketRelationQuery: outgoing/incoming relation なし、blocker なし。
+- TicketOrchestrationPlanQuery: 既存 record なし。今回 `orch-plan-20260612-084329-1` として accepted plan を記録。
+- Workspace state: Orchestrator worktree は `## ticket/orchestrator-progress-companion-notify`、root workspace は `## develop`、どちらも dirty 出力なし。
+- Code map: `crates/tui/src/workspace_panel.rs` と `crates/tui/src/multi_pod.rs` 周辺に Panel Queue / workspace panel / orchestrator launch の実装面があることを確認。
+- Visible Pods: 現在 visible Pod はこの Orchestrator のみで、coder/reviewer は未起動。
+
+IntentPacket:
+
+Intent:
+- Panel Queue action を、root/dev 側の `ready -> queued` commit と orchestration worktree への ff-only sync を完了してから Orchestrator notify/kick する durable handoff にする。
+
+Binding decisions / invariants:
+- root workspace の canonical top-level、orchestration worktree の canonical top-level、共通 git dir、期待 branch、dirty 状態、対象 Ticket の `ready` 状態、orchestration_head が root_head の ancestor であることを mutation 前に検証する。
+- Queue commit は root/dev 側で対象 Ticket record だけを stage/commit する。
+- orchestration worktree への自動同期は `git -C <orchestration_worktree> merge --ff-only <queue_commit_sha>` のみに限定する。
+- merge commit、rebase、stash、patch apply、conflict resolution、dirty cleanup は Panel Queue action では行わない。
+- Orchestrator notify/restore/kick は orchestration worktree HEAD が Queue commit を含み、orchestration worktree 側 Ticket backend で対象 Ticket が `queued` として読めることを確認した後だけ行う。
+- Ticket tools が cwd 基準で動く設計と、workspace_root / cwd / orchestration worktree / merge target の分離を崩さない。
+
+Requirements / acceptance criteria:
+- Queue 成功時、Panel は queued Ticket id、dev 側 Queue commit sha、orchestration worktree sync 結果、Orchestrator notify/kick の有無を表示する。
+- root dirty、orchestration dirty、branch divergence、non-ff sync required、Ticket state mismatch、worktree identity mismatch では Queue を block し、失敗した check 名と対象 path / branch / Ticket id を表示する。
+- `nix build .#yoi` が通る。
+
+Implementation latitude:
+- 既存 Panel action / Git helper / Ticket backend 呼び出しのどこへ checks と sync 処理を分割するかは coder が調査して選んでよい。
+- 表示文言や内部 helper 名は、失敗条件が具体的に伝わり、既存 UX と整合する範囲で調整してよい。
+- Focused tests / unit coverage の追加位置は既存の TUI/client/test 構造に合わせてよい。
+
+Escalate if:
+- Queue action が root/dev 側 Ticket commit 以外の変更を commit/stage する必要が出る。
+- ff-only 以外の sync、stash/rebase/conflict resolution、dirty cleanup を自動化しないと成立しない。
+- Ticket tools の cwd 基準設計、Pod workspace_root/cwd 分離、dedicated Orchestrator worktree の authority boundary を変える必要が出る。
+- Panel が Orchestrator routing/acceptance を代行する必要が出る。
+
+Validation:
+- 変更に対応する focused test / existing relevant cargo test。
+- `cargo fmt --check`。
+- `git diff --check`。
+- `target/debug/yoi ticket doctor`。
+- runtime resource / packaging / prompt へ触れる場合、または最終確認として `nix build .#yoi`。
+
+Current code map:
+- 主な調査対象: `crates/tui/src/workspace_panel.rs`, `crates/tui/src/multi_pod.rs`。
+- Ticket backend / state mutation / CLI helper を変更する場合は `crates/ticket` と `crates/yoi` 側の既存 typed Ticket path に合わせる。
+- Orchestrator/main `.yoi` project records、memory/local/runtime/secret-like `.yoi` paths は implementation worktree 側で勝手に生成・編集しない。
+
+Critical risks / reviewer focus:
+- root workspace と orchestration worktree を取り違えないこと。
+- dirty/divergent 状態で mutation/commit/notify しないこと。
+- Queue commit の差分が対象 Ticket record 以外へ広がらないこと。
+- ff-only 限定を破らないこと。
+- notify/kick が sync 完了前に走らないこと。
+- cwd 基準 Ticket tools と workspace_root 分離を壊さないこと。
+
+Next action:
+- 今回の launch instruction は role Pod spawn を explicit follow-up まで待つ指定なので、ここでは `queued -> inprogress`、worktree 作成、coder/reviewer spawn、merge/close は行わない。
+- 明示 follow-up があれば、side effect 前に TicketShow / relation / orchestration plan / git/worktree state を再確認し、問題がなければ `queued -> inprogress` を記録してから `multi-agent-workflow` に接続する。
+
+---
+
+<!-- event: state_changed author: orchestrator at: 2026-06-12T08:45:20Z from: queued to: inprogress reason: orchestrator_acceptance field: state -->
+
+## State changed
+
+Routing accepted for implementation. Ticket body/thread, relation blockers, orchestration plan, visible Pods, and root/orchestration git state were rechecked. No unresolved dependency/blocker or missing planning decision was found. Implementation side effects will start only after this accepted `queued -> inprogress` transition is recorded; worktree and sibling coder/reviewer routing will use the accepted plan `orch-plan-20260612-084329-1`.
+
+---
+
+<!-- event: plan author: orchestrator at: 2026-06-12T08:45:59Z -->
+
+## Plan
+
+Implementation worktree created for multi-agent handoff.
+
+- Ticket: `00001KTWPE3KQ`
+- Branch: `ticket/panel-queue-orchestrator-sync`
+- Worktree: `/home/hare/Projects/yoi/.worktree/panel-queue-orchestrator-sync`
+- Base: Orchestrator workspace HEAD `de0f533b` (`orchestration/yoi-orchestrator`), including the accepted routing record and `queued -> inprogress` transition.
+- Next: spawn sibling coder with narrow write scope to the implementation worktree. Reviewer will be started after coder evidence is available.
+
+---
+
+<!-- event: plan author: orchestrator at: 2026-06-12T08:47:16Z -->
+
+## Plan
+
+Coder delegated.
+
+- Coder Pod: `yoi-coder-panel-queue-sync`
+- Worktree: `/home/hare/Projects/yoi/.worktree/panel-queue-orchestrator-sync`
+- Branch: `ticket/panel-queue-orchestrator-sync`
+- Scope: read `/home/hare/Projects/yoi`, write `/home/hare/Projects/yoi/.worktree/panel-queue-orchestrator-sync`
+- Task: implement Panel Queue durable handoff with root/dev Queue commit, orchestration worktree ff-only sync, post-sync Ticket verification, and notify/kick ordering. Coder was instructed not to edit Orchestrator/main `.yoi` records or generated memory/runtime/secret-like paths.
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-12T09:05:32Z -->
+
+## Implementation report
+
+Coder completed initial implementation.
+
+- Coder Pod: `yoi-coder-panel-queue-sync`
+- Implementation branch: `ticket/panel-queue-orchestrator-sync`
+- Implementation commit: `04a3c6e0` (`tui: make panel queue handoff durable`)
+- Worktree status checked clean.
+
+Orchestrator validation performed after coder handoff:
+- `git diff --check HEAD^..HEAD` — pass
+- `cargo test -p tui ticket_queue_action -- --nocapture` — pass
+- `cargo fmt --check` — pass
+- `cargo check -p tui --all-targets` — pass
+- `nix build .#yoi` — pass
+- `./result/bin/yoi ticket doctor` — `doctor: ok`
+
+Next: delegate independent reviewer against the recorded Ticket intent, accepted plan, implementation commit, and validation evidence.
+
+---
+
+<!-- event: plan author: orchestrator at: 2026-06-12T09:06:03Z -->
+
+## Plan
+
+Reviewer delegated.
+
+- Reviewer Pod: `yoi-reviewer-panel-queue-sync`
+- Review target: `/home/hare/Projects/yoi/.worktree/panel-queue-orchestrator-sync`, branch `ticket/panel-queue-orchestrator-sync`, commit `04a3c6e0`
+- Scope: read-only `/home/hare/Projects/yoi`
+- Reviewer focus: durable Queue handoff ordering, root/orchestration worktree identity and cleanliness checks, ff-only-only sync, pathscope of Queue commit, no auto conflict/stash/rebase, notify only after sync + Ticket verification, and whether `--no-verify` is acceptable.
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-12T09:12:16Z -->
+
+## Implementation report
+
+Merge-ready dossier (human/parent merge authority required before merge/close/cleanup)
+
+Ticket:
+- `00001KTWPE3KQ` — Panel Queue時にdevとOrchestrator worktreeを同期する
+
+Branch / worktree:
+- Branch: `ticket/panel-queue-orchestrator-sync`
+- Worktree: `/home/hare/Projects/yoi/.worktree/panel-queue-orchestrator-sync`
+- Implementation commit: `04a3c6e0` (`tui: make panel queue handoff durable`)
+
+Intent / invariant check:
+- Panel Queue action is now implemented as root/dev-side Ticket `ready -> queued` mutation plus Queue commit, ff-only sync into the dedicated orchestration worktree, then Orchestrator notify/kick only after sync and Ticket-state verification.
+- Automatic sync path is constrained to `git -C <orchestration_worktree> merge --ff-only <queue_commit_sha>`.
+- No automatic merge commit, rebase, stash, patch apply, conflict resolution, or dirty cleanup path was found.
+- Runtime workspace root / cwd / orchestration worktree / merge target separation remains path-explicit.
+
+Implementation summary:
+- `crates/tui/src/multi_pod.rs` changed.
+- Added Panel Queue preflight for root/orchestration Git identity, branch state, shared common dir, clean worktrees, root Ticket `ready` state, and orchestration-head ancestry.
+- Added root-side Queue commit creation scoped to the target Ticket record.
+- Added ff-only orchestration worktree sync and post-sync verification that orchestration HEAD contains the Queue commit and orchestration Ticket backend reads the Ticket as `queued`.
+- Added focused tests for successful Queue handoff, dirty root blocking, and orchestration branch divergence blocking.
+
+Coder evidence:
+- Coder Pod: `yoi-coder-panel-queue-sync`
+- Commit: `04a3c6e0`
+- Coder reported `cargo fmt --check`, `cargo check -p tui`, `cargo test -p tui ticket_queue_action -- --nocapture`, `git diff --check`, `nix build .#yoi`, and `./result/bin/yoi ticket doctor` passed. Full `cargo test -p tui` had unrelated existing failures reported by coder.
+
+Orchestrator validation evidence:
+- `git diff --check HEAD^..HEAD` — pass
+- `cargo test -p tui ticket_queue_action -- --nocapture` — pass
+- `cargo fmt --check` — pass
+- `cargo check -p tui --all-targets` — pass
+- `nix build .#yoi` — pass
+- `./result/bin/yoi ticket doctor` — `doctor: ok`
+
+Reviewer evidence:
+- Reviewer Pod: `yoi-reviewer-panel-queue-sync`
+- Verdict: approve.
+- Reviewer reran `git diff --check HEAD^..HEAD` and `cargo test -p tui ticket_queue_action -- --nocapture`; both passed.
+- Reviewer found pre-mutation checks, root-side mutation/commit, ff-only sync, notify-after-verify ordering, path-explicit workspace separation, and failure-message specificity acceptable.
+- Reviewer did not treat `--no-verify` as a blocker for the automatic target-Ticket-record metadata commit; noted the tradeoff that local commit hooks do not run.
+
+Blockers fixed / rejected findings:
+- No reviewer blocker.
+- `--no-verify` retained as non-blocking per reviewer rationale: hook-side effects are less acceptable for this narrow automatic Ticket metadata commit than skipping local hooks, with pathscope checks and post-validation covering the handoff.
+
+Residual risks:
+- If sync or verify fails after the root Queue commit is created, the root/dev side remains durably queued and committed; manual follow-up may be required.
+- Clean-worktree checks are preflight checks, not a global lock against concurrent filesystem/git changes during the action.
+- Current root workspace is dirty from separate Panel/user activity (`00001KTVPS6K3` queue attempt and `crates/tui/src/multi_pod.rs` local changes), so merge target safety must be rechecked before any merge.
+
+Dirty state:
+- Implementation worktree was checked clean after commit.
+- Orchestrator worktree has only Ticket dossier changes before this record is committed.
+- Root/merge-target workspace is dirty and must not be used for merge until understood/cleaned or explicitly authorized.
+
+Decision needs:
+- Explicit merge-completion authority is required before merging `ticket/panel-queue-orchestrator-sync` into the recorded merge target, marking final review/done/close, stopping cleanup, or deleting the worktree/branch.
+- If authority is granted later, recheck branch/worktree/commit identity, independent approval, target dirty state, and rerun post-merge validation before Ticket completion.
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-12T09:12:25Z -->
+
+## Implementation report
+
+Coder/reviewer Pods stopped after merge-ready dossier was recorded.
+
+- Stopped: `yoi-coder-panel-queue-sync`
+- Stopped: `yoi-reviewer-panel-queue-sync`
+- Implementation worktree/branch are retained for explicit merge-completion authority.
+
+---
+
+<!-- event: state_changed author: "yoi ticket" at: 2026-06-12T12:26:26Z from: inprogress to: done reason: cli_state field: state -->
+
+## State changed
+
+State changed to `done`.
+
+
+---
+
+<!-- event: state_changed author: hare at: 2026-06-12T12:26:26Z from: done to: closed reason: closed field: state -->
+
+## State changed
+
+Ticket を closed にしました。
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-12T12:26:26Z status: closed -->
+
+## 完了
+
+Panel Queue handoff implementation was merged from `ticket/panel-queue-orchestrator-sync` into `orchestration/yoi-orchestrator`, then merged into `develop`.
+
+Implemented behavior:
+- Panel Queue performs the root-side Ticket `ready -> queued` mutation and Queue commit.
+- The dedicated orchestration worktree is synchronized with ff-only semantics before Orchestrator notification.
+- Queue success/failure paths report Ticket id, Queue commit, sync result, and notification outcome.
+- Dirty/divergent/state-mismatch/worktree-identity failure cases are blocked with explicit diagnostics.
+
+Validation after merge:
+- `cargo fmt`
+- `cargo test -p client ticket_role`
+- `cargo test -p tui ticket_queue_notification_message_carries_routing_contract`
+- `target/debug/yoi ticket doctor`
+- `cargo check --workspace`
+- `nix build .#yoi`
+- `cargo test -p tui ticket_queue_notification_message_carries_routing_contract`
+
+Cleanup:
+- Removed implementation worktree `/home/hare/Projects/yoi/.worktree/panel-queue-orchestrator-sync`.
+- Deleted merged branch `ticket/panel-queue-orchestrator-sync`.
+
+
+---

.yoi/tickets/00001KTX1QMG9/item.md

@@ -0,0 +1,58 @@
+---
+title: '実装ブランチをOrchestrator branch HEADから切る'
+state: 'closed'
+created_at: '2026-06-12T04:34:05Z'
+updated_at: '2026-06-12T08:15:54Z'
+assignee: null
+queued_by: 'yoi ticket'
+queued_at: '2026-06-12T08:11:52Z'
+---
+
+## 背景
+
+Orchestrator 用 dedicated worktree を導入したことで、Panel / human が操作する root workspace と、Orchestrator が Ticket backend として見る orchestration worktree は別 checkout になった。
+
+この設計では、Queue handoff 後の Orchestrator は orchestration branch 上で routing、`queued -> inprogress` acceptance、waiting reason、implementation intent などの durable Ticket 記録を作る。そのため、Orchestrator が作成するチケット実装用 branch は root workspace の `develop` から直接切るのではなく、Orchestrator workspace の現在 HEAD、つまり orchestration branch HEAD から切る必要がある。
+
+実装 worktree を配置する場所と、実装 branch の base は別の概念である。
+
+```text
+実装 worktree の配置場所:
+  original workspace 配下の .worktree/<task>
+
+実装 branch の base:
+  Orchestrator workspace の current HEAD / orchestration branch HEAD
+```
+
+現状の prompt / routing guidance では「implementation worktree は original workspace 配下に作る」ことは書かれているが、「implementation branch は Orchestrator branch HEAD から切る」ことが明示されていない。そのため Orchestrator が original workspace / merge target workspace の `develop` を base と誤解し、Orchestrator branch 上の Ticket 記録を含まない implementation branch を作る余地がある。
+
+## ゴール
+
+Orchestrator が child implementation worktree / branch を作るとき、worktree の配置場所は original workspace 配下に保ちつつ、branch base は Orchestrator workspace の current HEAD にすることを prompt / launch context / helper 実装で明確にする。
+
+## 要件
+
+- Orchestrator routing guidance は、次を明示する。
+  - implementation worktree は `original_workspace_root/.worktree/<task>` 配下に作る。
+  - implementation branch は Orchestrator workspace の current HEAD / orchestration branch HEAD から切る。
+  - merge target workspace / `develop` から implementation branch を直接切らない。
+- `worktree-workflow` または該当する dogfood workflow / prompt が、同じ base branch rule を明示する。
+- Ticket role launch context の `implementation_worktree_root` は配置場所の authority であり、branch base の authority ではないことを LLM-facing text で区別する。
+- merge completion guidance は、implementation branch を orchestration branch に戻し、その後 orchestration branch を merge target workspace / `develop` に戻す順序を明示する。
+- helper code が implementation worktree 作成コマンドを組み立てている場合、その base が root/develop に固定されていないことを確認し、必要なら Orchestrator workspace HEAD を使うよう修正する。
+- 既存の workspace/cwd 分離、Ticket backend が cwd 基準で動く設計を崩さない。
+
+## 非目標
+
+- implementation worktree の配置場所を Orchestrator worktree 配下に変えること。
+- merge target workspace / `develop` を廃止すること。
+- Queue handoff の dev -> orchestration sync policy をこの Ticket で実装すること。
+- Orchestrator branch から develop への最終 merge policy 全体をこの Ticket で実装すること。
+
+## 受け入れ条件
+
+- Orchestrator 向け prompt / workflow guidance が、implementation branch base を Orchestrator workspace HEAD と明示している。
+- `original_workspace_root` / `implementation_worktree_root` は worktree 配置先であり、branch base ではないことが分かる文面になっている。
+- `develop` / merge target workspace から implementation branch を直接切るよう読める指示が残っていない。
+- merge completion guidance が `implementation branch -> orchestration branch -> merge target develop` の順序を示している。
+- 関連する prompt/resource 変更を含めて `nix build .#yoi` が通る。

.yoi/tickets/00001KTX1QMG9/resolution.md

@@ -0,0 +1 @@
+Orchestrator が implementation worktree を original workspace 配下に作成する場合でも、implementation branch は Orchestrator workspace current HEAD / orchestration branch HEAD を base とするよう、role prompt / routing prompt / merge completion prompt に明記した。検証は cargo fmt、cargo test -p client ticket_role、cargo check --workspace、nix build .#yoi、git diff --check、target/debug/yoi ticket doctor で完了。

.yoi/tickets/00001KTX1QMG9/thread.md

@@ -0,0 +1,90 @@
+<!-- event: create author: "yoi ticket" at: 2026-06-12T04:34:05Z -->
+
+## 作成
+
+LocalTicketBackend によって作成されました。
+
+---
+
+<!-- event: intake_summary author: hare at: 2026-06-12T08:11:52Z -->
+
+## Intake summary
+
+Marked ready by `yoi ticket state`.
+
+---
+
+<!-- event: state_changed author: "yoi ticket" at: 2026-06-12T08:11:52Z from: planning to: ready reason: cli_state field: state -->
+
+## State changed
+
+Marked ready by `yoi ticket state`.
+
+
+---
+
+<!-- event: state_changed author: "yoi ticket" at: 2026-06-12T08:11:52Z from: ready to: queued reason: queued field: state -->
+
+## State changed
+
+Ticket を `yoi ticket` が queued にしました。
+
+
+---
+
+<!-- event: state_changed author: "yoi ticket" at: 2026-06-12T08:11:52Z from: queued to: inprogress reason: cli_state field: state -->
+
+## State changed
+
+State changed to `inprogress`.
+
+
+---
+
+<!-- event: implementation_report author: hare at: 2026-06-12T08:15:54Z -->
+
+## Implementation report
+
+実装報告:
+- Orchestrator role prompt の workspace routing context に、implementation worktree の配置先と branch base を分離して明記した。
+- Orchestrator worktree routing prompt に、implementation branch は Orchestrator workspace current HEAD / orchestration branch HEAD から切ると明記した。
+- Merge completion prompt に、implementation branch -> orchestration branch -> merge target の順序を明記した。
+- client prompt generation test に branch base guidance の assertion を追加した。
+
+検証:
+- cargo fmt
+- cargo test -p client ticket_role
+- cargo check --workspace
+- nix build .#yoi
+- git diff --check
+- target/debug/yoi ticket doctor
+
+
+---
+
+<!-- event: state_changed author: "yoi ticket" at: 2026-06-12T08:15:54Z from: inprogress to: done reason: cli_state field: state -->
+
+## State changed
+
+State changed to `done`.
+
+
+---
+
+<!-- event: state_changed author: hare at: 2026-06-12T08:15:54Z from: done to: closed reason: closed field: state -->
+
+## State changed
+
+Ticket を closed にしました。
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-12T08:15:54Z status: closed -->
+
+## 完了
+
+Orchestrator が implementation worktree を original workspace 配下に作成する場合でも、implementation branch は Orchestrator workspace current HEAD / orchestration branch HEAD を base とするよう、role prompt / routing prompt / merge completion prompt に明記した。検証は cargo fmt、cargo test -p client ticket_role、cargo check --workspace、nix build .#yoi、git diff --check、target/debug/yoi ticket doctor で完了。
+
+
+---

.yoi/tickets/00001KTZY8HK2/artifacts/orchestration-plan.jsonl

@@ -0,0 +1 @@
+{"id":"orch-plan-20260614-061002-1","ticket_id":"00001KTZY8HK2","kind":"accepted_plan","accepted_plan":{"summary":"Remove builtin use of `yoi.profile.extend`, establish import+Lua assignment profile inheritance pattern, and make extend fail/deprecate clearly without adding scope replacement semantics.","branch":"ticket-00001KTZY8HK2-profile-extend-removal","worktree":"/home/hare/Projects/yoi/.worktree/profile-extend-removal","role_plan":"Coder updates Lua profile API/resources/tests/docs; Reviewer focuses on intended profile behavior preservation and no hidden authority merge semantics."},"author":"orchestrator","at":"2026-06-14T06:10:02Z"}

.yoi/tickets/00001KTZY8HK2/artifacts/relations.json

@@ -0,0 +1,13 @@
+{
+  "version": 1,
+  "relations": [
+    {
+      "ticket_id": "00001KTZY8HK2",
+      "kind": "related",
+      "target": "00001KV11DHGZ",
+      "note": "scope replacement concern is superseded by moving concrete scope to launch policy",
+      "author": "yoi ticket",
+      "at": "2026-06-14T02:14:43Z"
+    }
+  ]
+}

.yoi/tickets/00001KTZY8HK2/artifacts/review-2026-06-14-approve.md

@@ -0,0 +1,21 @@
+承認します。
+
+Evidence:
+- `crates/manifest/src/profile.rs` の Lua API は `yoi.profile.import(...)` を残し、`yoi.profile.extend(...)` は常にエラーにする互換診断スタブに変更されている。旧 `deep_merge_profile_json` と hidden deep-merge composition は削除されており、診断文も `yoi.profile.import(...)` と explicit Lua assignment への移行を示している。
+- Builtin role profiles (`resources/profiles/{companion,intake,orchestrator,coder,reviewer}.lua`) は `yoi.profile.import("builtin:default")` 後に Lua の明示代入で必要フィールドだけを上書きしている。feature policy は各 role で全 key を明示し、worker instruction は table mutation で default reasoning 等を保持している。
+- scope/delegation は既存 role の明示値を移植しており、profile composition の変更に留まっている。launch policy / authority semantics は別 Ticket `00001KV11DHGZ` の範囲として残され、今回の diff では拡張されていない。
+- Tests cover import + explicit assignment, object replacement instead of deep merge, removed extend diagnostic, and builtin role resolution/policy (`profile::tests`).
+- Resource embedding/packaging risk is low: changed files are existing `resources/profiles/*.lua` loaded through the existing include table; `cargo build -p yoi` passed.
+
+Validation performed:
+- `git diff f709fc10..HEAD` inspected.
+- `cargo fmt --check` passed.
+- `git diff --check f709fc10..HEAD` passed.
+- `cargo test -p manifest profile::tests:: -- --nocapture` passed.
+- `cargo build -p yoi` passed.
+
+Not rerun:
+- `nix build .#yoi` was not rerun in this reviewer scope because it would write outside the permitted `target/`/Ticket-record areas unless using broader Nix/store/result-link authority. Coder reported it was run; cargo build validated resource embedding on this branch.
+
+Risks / notes:
+- Existing callers of `yoi.profile.extend` now fail intentionally; this is the requested break. The retained stub is a diagnostic compatibility trap, not a merge API.

.yoi/tickets/00001KTZY8HK2/item.md

@@ -0,0 +1,80 @@
+---
+title: 'Profile extend API を廃止して import + Lua 代入に寄せる'
+state: 'closed'
+created_at: '2026-06-13T07:31:09Z'
+updated_at: '2026-06-14T14:00:13Z'
+assignee: null
+readiness: 'implementation_ready'
+risk_flags: ['profiles', 'lua-api', 'builtin-resources', 'migration']
+queued_by: 'workspace-panel'
+queued_at: '2026-06-14T06:08:28Z'
+---
+
+## Background
+
+`yoi.profile.extend(base, overrides)` は base Profile と override object を Rust 側で deep merge する convenience API だった。しかし deep merge semantics が隠れるため、object field を「置換したい」のか「部分 merge したい」のかが Profile authoring 上で読み取りづらい。
+
+今回の問題では、以下のような Profile が scope を置換するつもりで object を渡すと、`builtin:default` 側の inherited value と deep merge され、workspace write が残り得た。
+
+```lua
+return yoi.profile.extend("builtin:default", {
+  scope = yoi.scope.workspace_read(),
+})
+```
+
+一方で Lua には通常の table 操作があるため、Profile 継承と field replacement は次の形で明示できる。
+
+```lua
+local p = yoi.profile.import("builtin:default")
+p.worker.instruction = "$yoi/role/orchestrator"
+p.feature.task.enabled = false
+p.feature.ticket = { enabled = true, access = "lifecycle" }
+return p
+```
+
+この形なら、top-level/nested field の代入は ordinary Lua assignment であり、merge/replace の意図が読みやすい。Profile scope については別 Ticket `00001KV11DHGZ` で concrete runtime authority を launch policy に移すため、`extend()` に replacement API を足す必要性はさらに下がった。
+
+## Requirements
+
+- `yoi.profile.extend` を廃止する。
+  - builtin Profile resources は `extend()` を使わず、`yoi.profile.import(...)` + explicit Lua assignment に移行する。
+  - Profile authoring convention は ordinary Lua table mutation / assignment を基本とする。
+- `yoi.profile.import` は残す。
+  - base Profile を取得して手元で変更し、`return p` する構造を公式パターンにする。
+- `extend()` の deep merge semantics に依存する builtin tests/resources を更新する。
+- `extend()` を public API として残す場合は deprecated diagnostic を出すか、削除して明確に fail させる。
+  - どちらにするかは実装時に決めてよいが、builtin resources は使わない。
+  - 不必要な compatibility alias は作らない。
+- Docs/tests/comments から「scope replacement API を足す」方向の記述を削除する。
+  - scope/delegation_scope の concrete authority は `00001KV11DHGZ` の launch policy 側で扱う。
+  - scope 以外でも object replacement が必要な場合は ordinary Lua assignment を使う。
+- Profile merge helper がどうしても必要になった場合は、`extend()` のような曖昧な名前ではなく、`deep_merge` / `shallow_merge` など semantics が明示された別 API として後続 Ticket で検討する。
+
+## Acceptance criteria
+
+- Repository builtin Profile resources no longer call `yoi.profile.extend`.
+- The Profile Lua API supports the official inheritance pattern:
+
+```lua
+local p = yoi.profile.import("builtin:default")
+-- mutate p explicitly
+return p
+```
+
+- Tests cover that `import()` + assignment replaces object fields without deep merge surprise.
+- Existing role Profiles still resolve to the same intended non-scope behavior: worker instructions, feature enablement, model/defaults, compaction, etc.
+- If `extend()` is removed, calling it fails with a clear Lua/profile error. If deprecated instead, it emits/records a clear deprecation diagnostic and builtin resources do not use it.
+- The old requirement to add `yoi.scope.replace(...)` / `replace = true` for scope replacement is removed or explicitly superseded.
+- Validation: focused profile resolution tests and `cargo build -p yoi`. Run `nix build .#yoi` only if resource packaging or lockfile/package changes require it.
+
+## Non-goals
+
+- Moving concrete scope/delegation_scope out of Profiles; tracked by `00001KV11DHGZ`.
+- Designing a general-purpose Lua table utility library.
+- Preserving `extend()` compatibility indefinitely.
+- Plugin/MCP permission design.
+
+## Related work
+
+- Move concrete scope to launch policy: `00001KV11DHGZ`
+- Original scope replacement concern is superseded by this Ticket plus `00001KV11DHGZ`.

.yoi/tickets/00001KTZY8HK2/resolution.md

@@ -0,0 +1 @@
+Closed after prior done-state completion.