fix: resolve relation summaries to Ticket keys

# Conflicts:
#	crates/workspace-server/src/store.rs

.gitignore

@@ -1,6 +1,7 @@
 /target
 /result
 /.direnv
-/.worktree
+/.yoi/dev
+.worktree
 *.local*
 .env

.yoi/.gitignore

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

.yoi/objectives/00001KTR7MZWH/item.md

@@ -2,15 +2,15 @@
 title: "ネイティブGUIアプリケーション"
 state: "active"
 created_at: "2026-06-10T07:41:18Z"
-updated_at: "2026-06-10T07:41:18Z"
+updated_at: "2026-07-15T21:18:00Z"
 linked_tickets: []
 ---
 
 ## Goal
 
-Yoi の Pod / Ticket / Orchestrator / workflow 操作を、TUI だけでなくネイティブ GUI から扱えるようにする。
+Yoi の Pod / Ticket / Orchestrator / Skill・prompt resource 操作を、TUI だけでなくネイティブ GUI から扱えるようにする。
 
-最初の到達点は、既存の runtime / Ticket backend / Pod protocol / Profile / workflow authority を再実装せずに、workspace の状態を視覚的に把握し、選択した Pod・Ticket・role action に対して安全に操作できる desktop GUI client を持つこと。GUI は core authority ではなく client surface とし、既存 CLI/TUI と同じ durable state・同じ protocol・同じ permission/prompt/workflow 境界を使う。
+最初の到達点は、既存の runtime / Ticket backend / Pod protocol / Profile / Skill/prompt resource authority を再実装せずに、workspace の状態を視覚的に把握し、選択した Pod・Ticket・role action に対して安全に操作できる desktop GUI client を持つこと。GUI は core authority ではなく client surface とし、既存 CLI/TUI と同じ durable state・同じ protocol・同じ permission/prompt/resource 境界を使う。
 
 ## Motivation / background
 
@@ -24,12 +24,12 @@ Yoi の Pod / Ticket / Orchestrator / workflow 操作を、TUI だけでなく
 - long-running orchestration の通知、状態変化、失敗診断の視覚化。
 - 将来的な review / merge-ready dossier / plan board / settings editor の専用 UI。
 
-一方で、GUI を理由に runtime authority を分散させたり、Ticket/Pod state を独自 DB として二重管理したり、prompt/workflow 文字列を GUI code に直書きしたりしてはいけない。
+一方で、GUI を理由に runtime authority を分散させたり、Ticket/Pod state を独自 DB として二重管理したり、prompt/resource 文字列を GUI code に直書きしたりしてはいけない。
 
 ## Strategy / design direction
 
 - GUI は Yoi core の上に乗る client として作る。
-  - Pod lifecycle、session/history、Ticket storage、Profile resolution、workflow/prompt authority は既存 core を正とする。
+  - Pod lifecycle、session/history、Ticket storage、Profile resolution、resource/prompt authority は既存 core を正とする。
   - GUI 固有 state は selection、layout、local UI preference などに限定する。
 - 最初に toolkit / architecture の小さな spike を置く。
   - 評価軸は Rust code reuse、async/runtime 統合、native packaging、Linux dogfooding しやすさ、testability、accessibility、long-running log/output 表示、将来の cross-platform 余地。
@@ -41,10 +41,10 @@ Yoi の Pod / Ticket / Orchestrator / workflow 操作を、TUI だけでなく
   4. Ticket body/thread/artifacts、Pod output、validation evidence、review report を閲覧しやすくする。
   5. 必要に応じて settings/profile/config editor や merge-ready dossier UI を追加する。
 - TUI は廃止前提にしない。
-  - GUI 導入後も CLI/TUI は fallback / automation / terminal-first workflow として維持する。
+  - GUI 導入後も CLI/TUI は fallback / automation / terminal-first operation flow として維持する。
   - GUI で見つかった state model の改善は、TUI と共有できる pure data model / client API に寄せる。
-- Prompt / workflow / role guidance は GUI code に直書きしない。
+- Prompt / resource / role guidance は GUI code に直書きしない。
-  - LLM-facing prompt は `resources/prompts` または `.yoi/workflow` / configured resources を正とする。
+  - LLM-facing prompt は `resources/prompts` または `.yoi/skills` / configured resources を正とする。
   - GUI は prompt 文言を所有せず、選択・起動・runtime context の入力面を担当する。
 - Security / privacy / authority boundary を保つ。
   - secret-like data は UI diagnostics / logs / model context に漏らさない。
@@ -57,17 +57,17 @@ Yoi の Pod / Ticket / Orchestrator / workflow 操作を、TUI だけでなく
 - GUI は既存 workspace config、Profile、Ticket backend、Pod registry/protocol を使い、独自の authority store を持たない。
 - 最小 dashboard で live/stored Pod、Ticket lane/state、Orchestrator/role session の概況を確認できる。
 - GUI から少なくとも attach/restore/open 相当の安全な Pod 操作ができる。
-- GUI から Ticket Intake または既存 role launcher を使った role action を実行でき、既存の prompt/workflow/resource 境界を壊さない。
+- GUI から Ticket Intake または既存 role launcher を使った role action を実行でき、既存の prompt/resource 境界を壊さない。
 - Pod output / Ticket body/thread/artifacts を、TUI より見通しよく閲覧できる最小 UI がある。
 - GUI 固有 state と core durable state の境界が文書化されている。
 - toolkit / architecture 選定理由、採用しなかった選択肢、packaging 方針が Ticket artifact または design note として残っている。
 - GUI で使う state transformation / action eligibility は pure model として test 可能で、主要な selection/action state の unit test がある。
-- GUI 実装は CLI/TUI の既存 workflow を破壊せず、必要な targeted validation が定義されている。
+- GUI 実装は CLI/TUI の既存 operation flow を破壊せず、必要な targeted validation が定義されている。
 
 ## Decision context
 
 - この Objective は中長期の方向性・判断軸を保持する。具体的な toolkit 選定、crate 構成、初期 dashboard 実装、role action 実装、packaging は個別 Ticket に分ける。
 - GUI は TUI の単純な置換ではなく、複数 Pod / Ticket / Orchestrator を扱う workspace cockpit として設計する。
-- authority は既存 core に残す。GUI は client/view/controller surface であり、Pod/Ticket/workflow/prompt の正本を所有しない。
+- authority は既存 core に残す。GUI は client/view/controller surface であり、Pod/Ticket/resource/prompt の正本を所有しない。
-- Prompt 直書き禁止方針を守る。GUI 実装中に LLM-facing 文言が必要になった場合は、`resources/prompts` または workflow/resource 側に置く。
+- Prompt 直書き禁止方針を守る。GUI 実装中に LLM-facing 文言が必要になった場合は、`resources/prompts` または Skill/resource 側に置く。
 - 初期 target は dogfooding しやすい desktop GUI とし、public release / cross-platform polish / installer は後続段階で扱う。

.yoi/objectives/00001KVJPT2PP/item.md

@@ -1,36 +1,38 @@
 ---
-title: "Team workspace control plane and runner architecture"
+title: "Team workspace control plane and runtime architecture"
 state: "active"
 created_at: "2026-06-20T14:26:29Z"
-updated_at: "2026-06-21T18:10:00Z"
+updated_at: "2026-07-15T21:18:00Z"
-linked_tickets: ["00001KVMFFYVX"]
+linked_tickets: ["00001KVMFFYVX", "00001KWMBAA6V"]
 ---
 
 ## Goal
 
 Yoi を、単一のローカル開発ディレクトリで動くエージェント実行ツールから、チームで作業・判断・実行結果を管理できるワークスペース基盤へ発展させる。
 
-この Objective の中心は、Web から扱える管理システムを作り、その管理システムにローカル実行環境・リモート実行環境・将来のクラウド実行環境を接続できるようにすることである。管理システムは Ticket、Objective、Memory、Knowledge、Run、Artifact、Runner の正本を持つ。実行環境はその管理システムから仕事を受け取り、コード取得、作業用ディレクトリ作成、エージェント実行、検証、結果報告を行う。
+この Objective の中心は、Web から扱える管理システムを作り、その管理システムにローカル Runtime・リモート Runtime・将来のクラウド Runtime を接続できるようにすることである。管理システムは Ticket、Objective、Memory、Skill catalog、Artifact、Policy、Actor、Repository、Runtime state の正本を持つ。Runtime はその管理システムから Worker launch request / config bundle / repository target / authority を受け取り、作業環境を用意して Worker を実行し、結果・イベント・証跡を返す。
 
-この Objective は Git ホスティングサービスを作るものではない。Git は重要な Repository provider として扱うが、Yoi の Workspace は Git Repository root と同じものにしない。Yoi が作るべきものは、コード・ドキュメント・データ・成果物などの Repository と実行環境を接続しながら、人間とエージェントの作業、Ticket lifecycle、Memory/Knowledge、検証証跡、実行環境配置を管理するチームワークスペースである。
+この Objective は Git ホスティングサービスを作るものではない。Git は重要な Repository provider として扱うが、Yoi の Workspace は Git Repository root と同じものにしない。Yoi が作るべきものは、コード・ドキュメント・データ・成果物などの Repository と Runtime を接続しながら、人間とエージェントの作業、Ticket lifecycle、Memory、Skill catalog、検証証跡、実行環境配置を管理するチームワークスペースである。
 
 ## Glossary
 
 この Objective では、以下の語をこの意味で使う。
 
-- Workspace: チームまたはプロジェクトの管理単位。Ticket、Objective、Memory、Knowledge、Run、Artifact、Policy、Actor、Repository を持つ。Git Repository root ではない。
+- Workspace: チームまたはプロジェクトの管理単位。Ticket、Objective、Memory、Skill catalog、Artifact、Policy、Actor、Repository、Runtime state を持つ。Git Repository root ではない。
 - Control plane: Workspace の正本を持ち、Web UI / API / CLI から操作される管理システム。
-- Runner: Control plane から仕事を受け取り、実際にエージェントやツールを動かす実行環境。最初はローカルマシン上の runner、後でリモート runner やクラウド runner を追加する。
+- Runtime: Worker 群を束ねる実行基盤。Worker lifecycle、sandbox、mount、cache、checkout/worktree/container filesystem などの working directory materialization、event/control plane を管理する。将来的には 1 つの Runtime が複数 Workspace / Repository の Worker を抱えられる。
+- Worker: Runtime が管理する 1 つの agent/session/process。Runtime が用意した working directory と authority の中で動く。
 - Repository: Workspace に接続される source/storage。コード、ドキュメント、local directory、object storage、artifact store、dataset などを含む。Git Repository も Repository の一種であり、基本的には filesystem path ではなく URI / URL で識別する。
+- RepositoryId: Workspace 内でどの Repository を対象にするかを指す安定 identifier。Git hash、branch、path ではない。
 - 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 を表す。
+- RepositorySelector: Repository provider に渡す未解決の地点指定。branch/tag/PR/revspec/bookmark/revset/path@revision/object version/latest など provider-specific な symbolic / mutable / query-like locator であり、それ自体は再現性の authority ではない。
-- Execution Workspace: Runner が Run のために作る作業用ディレクトリや container filesystem。1 つ以上の RepositoryPoint から materialize される。Git worktree、clone、sparse checkout などはこれを作る手段である。
+- RepositoryPoint: RepositorySelector をある時点で解決した具体地点。Git commit/tree、Mercurial changeset、SVN revision、object store version/manifest digest、file snapshot など provider ごとの immutable / reproducible point を表し、Artifact/evidence に残す。
+- working directory: Runtime が Worker のために作る作業環境。1 つ以上の RepositoryPoint から materialize される作業用ディレクトリ、container filesystem、sandbox mount の集合であり、Git worktree、clone、sparse checkout などはこれを作る手段である。Browser-facing UI/API では product `Workspace` と混同しないよう、この呼称に寄せる。`Volume` は storage backing の候補名に留め、作業領域そのものの呼称にはしない。
 - Ticket: チームで扱う作業単位。目的、要件、判断、議論、完了条件、関係、証跡を持つ。
 - Objective: 複数の Ticket を束ねる長期目標や設計方針。
-- Run: Ticket や Objective に対して行われた具体的な実行試行。どの Runner が、どの Execution Workspace で、何を実行し、どんな結果になったかを持つ。
+- Artifact: Ticket や Worker 実行に紐づく成果物や証跡。diff、log、validation result、review result、report など。
-- Artifact: Run や Ticket に紐づく成果物や証跡。diff、log、validation result、review result、report など。
+- Memory: エージェントやユーザーが再利用するための要約された文脈。Ticket や Artifact の正本ではない。
-- Memory: エージェントやユーザーが再利用するための要約された文脈。Ticket や Run の正本ではない。
+- Skill catalog: `.yoi/skills` / builtin skills から Workspace backend が解決する procedural guidance catalog。外部状態 authority は持たず、Ticket / Worker / workdir などの操作は typed feature/tool surface が担う。
-- Knowledge: 保守された知識や設計判断。Memory より人間が維持する資料に近い。
 - Actor: 人間、エージェント、システム、外部サービスなど、Workspace 上で操作や発言を行う主体。
 
 ## Motivation / background
@@ -40,21 +42,21 @@ Yoi を、単一のローカル開発ディレクトリで動くエージェン
 - Workspace を Git Repository root と同一視しない。
 - ローカル filesystem 上の `.yoi` を、長期的なチーム用正本 store にしない。
 - Ticket をローカル作業メモではなく、チームの作業調整 record にする。
-- Ticket と実行試行を分ける。実行試行は Run として記録する。
+- 実行証跡は Ticket thread、Artifact、WorkerRef snapshot、Runtime event として扱い、独立した実行単位概念を先に増やさない。
-- 管理システムと実行環境を分ける。
+- 管理システムと Runtime を分ける。
-- まず Web から Ticket、Objective、Memory、Knowledge、Run、Artifact、Runner state を見られるようにする。
+- まず Web から Ticket、Objective、Memory、Skill catalog、Artifact、Runtime / Worker state を見られるようにする。
-- 最初はローカルマシンを Runner として使い、後でリモート Runner、クラウド Runner、runner pool、resource allocation、quota、billing、sandboxing に拡張する。
+- 最初はローカル Runtime を使い、後でリモート Runtime、クラウド Runtime、runtime pool、resource allocation、quota、billing、sandboxing に拡張する。
-- Git ホスティング機能を取り込むのではなく、Git Repository / worktree / clone は Repository provider と Execution Workspace materialization の手段として扱う。
+- Git ホスティング機能を取り込むのではなく、Git Repository / worktree / clone は Repository provider と working directory materialization の手段として扱う。
 
-OSS として Control plane、Runner、Web frontend、protocol を公開しつつ、managed service では hosted control plane、runner fleet、リソース柔軟性、team auth、backup、audit、availability、multi-tenant operations で価値を出す。
+OSS として Control plane、Runtime、Web frontend、protocol を公開しつつ、managed service では hosted control plane、runtime 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 の正本とはみなさない。
+Team Workspace の正本は server-side control plane に置く。`.yoi` は local backend、single-user/self-hosted compatibility、offline/export/import、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 を持たない。
+Control plane は Ticket、Objective、Memory、Skill catalog、Artifact、Actor、Permission、Audit、Repository、Runtime / Worker state を管理する。Web UI、CLI、TUI、将来の desktop client は、この Control plane を操作する client であり、別の正本 store を持たない。
 
 ### 2. Workspace と Repository を同一視しない
 
@@ -62,9 +64,15 @@ Workspace はチームまたはプロジェクトの作業管理単位である
 
 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 の所有物にはしない。
+Ticket と Objective は Repository 配下に置かず、Workspace 配下に平たく持つ。Ticket は必要に応じて対象 RepositoryId、RepositorySelector、path scope、必要 capability を持つ。Objective は複数 Ticket にまたがる target default / scope hint を持てるが、Repository の所有物にはしない。
 
-Run は Ticket の target selector を具体的な RepositoryPoint に解決し、その RepositoryPoint から Execution Workspace を materialize する。Git worktree 相当の機能は、この Execution Workspace を作るための実装戦略として扱う。
+RepositorySelector は Git branch/tag の抽象化ではない。Selector は provider-specific な未解決 locator であり、Git provider なら branch/tag/ref/revspec/PR/commit、Mercurial provider なら bookmark/revset/changeset、SVN provider なら path/revision、object store provider なら prefix/version/latest などを解釈する。実行時には Control plane または Repository provider が Selector を RepositoryPoint に解決し、Runtime はその RepositoryPoint を materialize する。
+
+Worker launch request は Ticket の target selector を concrete RepositoryPoint に解決し、その RepositoryPoint から Runtime が working directory を materialize する。Git worktree 相当の機能は、この working directory を作るための実装戦略として扱う。
+
+Backend は cwd や `--workspace` を暗黙の Repository として扱わない。`--workspace` は当面 workspace config root / local descriptor root を指すだけであり、Repository registry は明示設定された Workspace config から構築する。短期的には `.yoi/workspace-backend.local.toml` の `[[repositories]]` を local descriptor として使い、`uri = "."` のような local repository も明示 entry として登録する。`./` を暗黙 Repository として自動採用しない。
+
+`.yoi` は現在の local backend / fs-store / compatibility surface として残るが、long-term Backend store ではない。将来的には `~/.yoi` 側に Backend store と Workspace registry を置き、1 Backend process が複数 Workspace を扱える形へ移行する。`.yoi/workspace-backend.local.toml` はその移行までの workspace-local descriptor / override surface として扱う。
 
 短期的には 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 に依存する。
 
@@ -72,15 +80,14 @@ Run は Ticket の target selector を具体的な RepositoryPoint に解決し
 
 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 したかを記録する。
+Ticket target は intent/selector であり、実行再現性のための immutable point ではない。Worker launch request が target selector を concrete RepositoryPoint に解決し、Runtime が実際にどの revision/snapshot を materialize したかを Artifact / evidence として記録する。
 
 ```text
 Ticket
   -> target selectors: Repository + ref selector + path + intent
-  -> Run / Attempt
   -> resolved RepositoryPoint
-  -> Execution Workspace
+  -> working directory
-  -> Artifact / Evidence
+  -> WorkerRef / Artifact / Evidence
   -> Review / Decision
   -> Audit / Notification
 ```
@@ -100,7 +107,7 @@ Ticket targets:
     paths: ["docs/development/"]
     intent: read
 
-Run inputs:
+Worker launch materialization:
   - repository: main-code
     requested_ref: develop
     resolved_point: git commit abc123
@@ -112,51 +119,76 @@ 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.
+- Linked Objective / Artifact / WorkerRef / Repository / RepositoryPoint / working directory.
 - Permission / visibility.
 - Audit trail.
 - Notification / mention.
 - Board / queue / planning / review / done / archived views.
 - Conflict handling and concurrent editing policy.
 
-### 4. Memory / Knowledge の本格再設計は後回しにする
+### 4. Memory / Skill catalog の本格再設計は後回しにする
 
-Memory / Knowledge は Ticket / Run / Artifact のコピーではない。再利用可能な文脈、方針、学習された制約、保守された知識として扱う。ただし、Memory の意味論・抽出・承認・検索・staleness 処理を今この Objective で先に作り込まない。
+Memory は Ticket / Artifact のコピーではない。再利用可能な文脈、方針、学習された制約を扱うが、Ticket や Artifact の authority を置き換えない。Skill catalog は procedural guidance の catalog であり、外部状態 authority を持たない。Knowledge record kind は削除方針なので、この Objective では separate Knowledge storage を新しい control plane entity として増やさない。
 
-理由は、Memory の正しい設計が Workspace control plane の record model、Actor / visibility / permission、Ticket と Run の分離、Artifact / evidence、RepositoryPoint、Runner に渡す context の監査方法に依存するためである。これらが固まる前に Memory schema だけを作ると、local `.yoi` 前提や現行 agent runtime 前提に引っ張られ、後で再設計が必要になる。
+理由は、Memory と Skill catalog の正しい設計が Workspace control plane の record model、Actor / visibility / permission、Ticket、Artifact / evidence、RepositoryPoint、Runtime に渡す context の監査方法に依存するためである。これらが固まる前に Memory schema や Skill API だけを作ると、local `.yoi` 前提や現行 agent runtime 前提に引っ張られ、後で再設計が必要になる。
 
-この Objective では、Memory / Knowledge について以下の platform contract だけを維持する。
+この Objective では、Memory / Skill catalog について以下の platform contract だけを維持する。
 
-- Memory / Knowledge は Control plane が扱う record だが、Ticket / Run / Artifact の authority を置き換えない。
+- Memory は Control plane が扱う record だが、Ticket / Artifact の authority を置き換えない。
-- 将来、Memory / Knowledge の canonical storage は Workspace control plane 側に置く。
+- Skill catalog は Workspace backend が扱う prompt/resource catalog だが、Ticket / Worker / workdir / queue の authority を持たない。
-- local `.yoi` memory は compatibility、offline/export/import、runner-local projection、migration bridge として扱う。
+- 将来、Memory と Skill catalog の canonical storage / API は Workspace control plane 側に置く。
-- Personal Memory、Workspace Memory、Run Summary、Maintained Knowledge は分離が必要である。
+- local `.yoi` memory と `.yoi/skills` は compatibility、offline/export/import、local projection、migration bridge として扱う。
+- Personal Memory、Workspace Memory、Worker Summary、Skill catalog は分離が必要である。
 - Generated Memory には provenance、visibility、approval、audit が必要である。
-- Runner / agent に渡した Memory/Knowledge context は、将来 ContextPack などとして Run に記録できる必要がある。
+- Runtime / Worker に渡した Memory / Skill context は、将来 ContextPack などとして Artifact/evidence に記録できる必要がある。
 
 本格的な Memory 再設計は、Memory の保存先を Workspace backend / control plane record に移すタイミングで回収する。それまでは低リスクな観察、問題例の収集、既存 local memory の互換維持に留める。
 
-### 5. 管理システムと実行環境を弱結合にする
+### 5. Control plane / Runtime を分離する
 
-Control plane は正本と調整を持つ。Runner は実行を担当する。
+Control plane は正本と調整を持つ。Runtime は Worker 群と実行基盤を管理する。初期実装では local backend と runtime process が同じマシン上にあり、役割が近く見えるが、設計上は分ける。
 
 初期形:
 
 ```text
 Web UI / Control Plane
-  -> Runner connection
+  -> Runtime registry / local backend
-  -> Local machine runner
+  -> Runtime process
-  -> Existing Yoi runtime, tools, working copy, build/test commands
+  -> Workers
+  -> Existing Yoi tools, working copy, build/test commands
 ```
 
-この段階では、現在ローカル管理画面が行っている Ticket 選択、エージェント起動、レビュー起動、作業用 checkout 作成、検証実行、結果表示を、Web/control plane から local runner に対して実行できるようにする。
+この段階では、現在ローカル管理画面が行っている Ticket 選択、エージェント起動、レビュー起動、作業用 checkout 作成、検証実行、結果表示を、Web/control plane から local Runtime に対して実行できるようにする。
 
-その後で、remote runner、self-hosted runner、hosted cloud runner、runner pool、resource allocation、quota、billing、sandbox、network policy、secret distribution を追加する。
+長期的には Runtime が作業環境の用意まで請け負う。Runtime は Worker launch request / config bundle / repository target / authority を受け取り、必要な checkout、worktree、container filesystem、sandbox mount、cache、secret boundary を準備して Worker を起動する。Runtime 起動時に特定 Workspace path を必須にする形は暫定であり、Workspace / Repository 情報は Runtime process 起動引数ではなく Worker launch request 側の入力に寄せる。
+
+Sandbox と authority 分離が成立している前提では、1 つの Runtime が複数 Workspace / Repository の Worker を抱えられる。したがって Runtime identity は Git repository root や single workspace directory と同一視しない。Runtime は execution substrate、Workspace は作業管理 record の正本として扱う。
+
+Worker の作業環境を用意する経路は次のようにまとめる。
 
 ```text
-Phase 1: Web control plane + local runner
+Ticket / user intent
-Phase 2: Remote/self-hosted runner
+  -> RepositoryId + RepositorySelector + path scope + required authority
-Phase 3: Hosted cloud runner fleet
+  -> resolved RepositoryPoint
+  -> WorkerLaunchRequest / ConfigBundle / AuthorityBundle
+  -> Runtime WorkingDirectoryMaterializer
+  -> working directory allocation
+  -> Worker process
+  -> WorkerRef + Artifact/evidence
+```
+
+Control plane は Workspace authority、Ticket target、Repository registry、Actor permission、設定 bundle の正本を持つ。Control plane または Repository provider は RepositorySelector を RepositoryPoint に解決し、どの地点を対象にしたかを evidence に残す。Runtime は RepositoryPoint、materialization policy、sandbox policy、mount/cache/secret policy、Worker config を受け取り、Runtime-local な working directory を確保して Worker を起動する。
+
+この境界では、Worker は host filesystem path や Repository credential を自分で発見しない。Worker は Runtime が materialize した working directory root、mount、環境変数、tool authority、config bundle だけを見る。Runtime は working directory の lifecycle、cleanup、cache reuse、namespace、quota、sandbox boundary、event collection を管理する。Control plane / Browser-facing API は raw host path、secret、socket、internal runtime path を authority-bearing internals として扱い、必要な evidence だけを Artifact として公開する。
+
+v0 materializer は existing local root を明示的な working directory として返してよい。ただし型と呼び出し順序は、後で Git worktree、clone、sparse checkout、container filesystem、remote object snapshot、multi-repository mount に置き換えられる形にする。Runtime process 起動時の `--workspace` はこの v0 materializer の legacy bootstrap input であり、Runtime identity や long-term workspace binding ではない。
+
+その後で、remote Runtime、self-hosted Runtime、hosted cloud runtime fleet、runtime pool、resource allocation、quota、billing、sandbox、network policy、secret distribution を追加する。
+
+```text
+Phase 1: Web control plane + local Runtime
+Phase 2: Remote/self-hosted Runtime
+Phase 3: Hosted cloud runtime fleet
 Phase 4: Resource allocation / scheduling / quotas / billing / isolation
 ```
 
@@ -166,50 +198,52 @@ Desktop app は対応コストが高いので、まず Web frontend を primary
 
 - Web: チームで使う主要 UI。
 - CLI: automation、scripting、local operations。
-- TUI/local panel: local runner cockpit、fallback、dogfooding surface。
+- TUI/local panel: fallback、dogfooding surface。
 - Future desktop: Web/control-plane model が安定した後に検討する optional client。
 
-Web UI は Ticket、Objective、Memory、Knowledge、Run、Runner、Artifact を扱う。UI の都合で正本を二重化しない。
+Web UI は Ticket、Objective、Memory、Skill catalog、Runtime、Worker、Artifact を扱う。UI の都合で正本を二重化しない。
 
 ### 7. 多重起動コストと runtime placement を見直す
 
-Cloud/remote execution を成立させるには、多数のエージェント実行を安く管理できる必要がある。logical agent session と runtime process/resource placement を分ける。
+Cloud/remote execution を成立させるには、多数のエージェント実行を安く管理できる必要がある。logical Worker session と Runtime process/resource placement を分ける。Runtime は Git Repository root や Workspace path に固定されず、request ごとに必要な working directory を materialize できる実行基盤として扱う。
 
-初期 Workspace DB では、Worker を canonical table として永続化しない。Host / Worker 一覧は backend-local runtime inspection や将来の Host protocol から逐次取得する live view とし、Ticket に関わった Worker は Ticket thread events と WorkerRef snapshot / TicketWorkerLink として記録する。
+初期 Workspace DB では、Worker を canonical table として永続化しない。Runtime / Worker 一覧は backend-local runtime inspection や将来の Runtime 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 を作らない。
+Worker の一元管理、データ永続化、アーカイブは将来的には必要になる。これは Runtime protocol、remote/self-hosted/hosted runtime lifecycle、worker identity、retention policy、audit requirements が固まった後に、dedicated Worker registry / archive model として追加する。v0 で Pod metadata の代替として Worker table を作らない。
 
 検討対象:
 
-- Agent identity と process/runtime placement の分離。
+- Worker identity と Runtime process/resource placement の分離。
+- 1 Runtime が複数 Workspace / Repository の Worker を抱える場合の namespace、quota、cleanup、audit boundary。
+- Runtime-side working directory materialization、sandbox、mount、checkout/worktree/container filesystem の責務。
 - Provider client、tool registry、resource cache の共有可能性。
-- Prompt/resource/profile resolution cache。
+- Prompt/resource/profile/config bundle 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。
+- Runtime-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 の用語と境界を固める。
+   - Workspace / RepositoryId / RepositorySelector / RepositoryPoint / working directory / Runtime / Worker / Control Plane / Ticket / Memory の用語と境界を固める。
 2. **Team-space canonical data model**
-   - Ticket / Objective / Target / Run / Artifact / Actor / Permission / Audit / Memory / Knowledge の entity/event model を設計する。
+   - Ticket / Objective / Target / Artifact / Actor / Permission / Audit / Memory の entity/event model を設計する。
-3. **Ticket and Run separation**
+3. **Ticket evidence model**
-   - Ticket lifecycle と execution attempt / orchestration run / validation run を分離し、Ticket thread と Run evidence の責務を明確化する。
+   - Ticket lifecycle、WorkerRef、Artifact、validation evidence、review evidence、Ticket thread の責務を明確化する。
 4. **Memory storage migration boundary**
-   - Memory / Knowledge の本格再設計は後回しにし、まずは Workspace backend に移す時の platform contract、compatibility/cache/export 方針、将来の provenance / visibility / approval 要件だけを固定する。
+   - Memory の本格再設計は後回しにし、まずは 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 の範囲を決める。
+   - read-only Ticket / Objective / Memory / Runtime / Worker state UI/API の範囲を決める。
-7. **Local runner protocol design**
+7. **Local Runtime protocol design**
-   - Web/control plane から local runner に安全な操作を送る protocol と authority boundary を設計する。
+   - Web/control plane から local Runtime に安全な操作を送り、Runtime が Worker lifecycle と working directory materialization を担う protocol と authority boundary を設計する。
-8. **Repository and Execution Workspace materialization model**
+8. **Repository and working directory materialization model**
-   - Repository URI、Repository provider capability、RepositoryPoint resolution、Git worktree / clone / sparse checkout / future source backend を runner-side strategy として抽象化する。
+   - Repository URI、Repository provider capability、RepositorySelector resolution、RepositoryPoint evidence、Git worktree / clone / sparse checkout / future source backend を Runtime-side materialization strategy として抽象化する。
-9. **Remote/hosted runner foundation**
+9. **Remote/hosted runtime foundation**
-   - runner registration, heartbeat, capability advertisement, job assignment, logs/events, secrets, sandbox/resource policy を設計する。
+   - runtime registration, heartbeat, capability advertisement, job assignment, logs/events, secrets, sandbox/resource policy を設計する。
 
 ## Non-goals
 
@@ -218,32 +252,36 @@ Worker の一元管理、データ永続化、アーカイブは将来的には
 - 最初から full hosted cloud execution を作ること。
 - local execution / CLI / TUI / local panel を捨てること。
 - Ticket を単なる issue tracker clone にすること。
-- Memory を Ticket/Run audit log の代替にすること。
+- Memory を Ticket/Artifact 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 の境界が文書化されている。
+- Workspace / RepositoryId / RepositorySelector / RepositoryPoint / working directory / Runtime / Worker / Control Plane / Ticket / Memory の境界が文書化されている。
-- Ticket が team coordination record として、target selector / Run / Artifact / Actor / Permission / Audit と分離された model を持つ。
+- Ticket が team coordination record として、target selector / 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 に留め、本格再設計をこの段階の必須条件にしない。
+- Web UI/API が Ticket / Objective / Runtime / Worker state を中心とした read-only view を提供できる設計または MVP を持つ。Memory は既存 record の表示または将来 placeholder に留め、本格再設計をこの段階の必須条件にしない。
-- Control plane から local runner に対して、現在のローカル管理画面相当の安全な操作を実行できる design/protocol がある。
+- Control plane から local Runtime に対して、現在のローカル管理画面相当の安全な操作を実行できる design/protocol がある。
+- Runtime は single Workspace / Git repository root 専用 process ではなく、sandbox/authority が成立すれば複数 Workspace / Repository の Worker を抱えられる execution substrate として設計されている。
 - Git Repository root に依存しない Workspace model があり、Git Repository は Repository provider の一種として扱われている。
-- Ticket と Objective は Workspace 配下に平たく存在し、Repository への所属ではなく target selector / scope hint で対象を表現する。
+- Ticket と Objective は Workspace 配下に平たく存在し、Repository への所属ではなく RepositoryId / RepositorySelector / path scope / intent で対象を表現する。
-- Git worktree 相当は Execution Workspace materialization strategy として扱われ、Run が immutable な RepositoryPoint を記録する。
+- Git worktree 相当は working directory materialization strategy として扱われ、Artifact/evidence が concrete RepositoryPoint を記録する。
-- Memory / Knowledge は Ticket / Run / Artifact の authority を置き換えない record として platform contract だけを持つ。本格的な意味論・抽出・承認・検索・staleness 処理は、Memory の保存先を Workspace backend / control plane record に移すタイミングで回収する。
+- Memory は Ticket / Artifact の authority を置き換えない record として platform contract だけを持つ。本格的な意味論・抽出・承認・検索・staleness 処理は、Memory の保存先を Workspace backend / control plane record に移すタイミングで回収する。
-- Hosted runner / resource allocation / SaaS offering に進むための後続 Ticket が切れる状態になっている。
+- Hosted Runtime / 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 として設計する。
+- Yoi は hosted Git tool ではなく、team workspace control plane + Runtime 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 へ進む。
+- 実行環境と管理システムは弱結合にする。まず管理システムを独立させ、local Runtime を実行環境として接続する。その後に remote/self-hosted/hosted runtime fleet へ進む。
+- Runtime は Worker 群を束ねる実行基盤であり、将来的には作業環境の用意、sandbox、mount、checkout/worktree/container filesystem、cache、secret boundary を Worker launch request ごとに準備する。Runtime process は single Workspace / Git repository root 専用に固定しない。RepositorySelector は provider-specific な未解決 locator、RepositoryPoint は解決済み evidence として扱う。
 - 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 に解決する。
+- Ticket と Objective は Workspace 配下に平たく持つ。対象コードベースや地点指定は RepositoryId / RepositorySelector / path scope / intent として表現し、Worker launch materialization が concrete RepositoryPoint に解決する。
-- Memory の本格再設計は後回しにする。先に Workspace / Ticket / Repository / Host/Worker live view / Control plane の基盤を固め、Memory の保存先を Workspace backend に移すタイミングで、意味論・抽出・承認・検索・staleness 処理をまとめて回収する。
+- Backend Repository は cwd inspection ではなく、Workspace config の明示 Repository registry から構築する。`--workspace` は Repository ではなく workspace config root / local descriptor root を指す。
+- `./.yoi` は local descriptor / fs-store / compatibility surface であり、将来の Backend canonical store と Workspace registry は `~/.yoi` 側へ寄せる。
+- Memory の本格再設計は後回しにする。先に Workspace / Ticket / Repository / Runtime/Worker live view / Control plane の基盤を固め、Memory の保存先を Workspace backend に移すタイミングで、意味論・抽出・承認・検索・staleness 処理をまとめて回収する。
 - Worker の一元管理・データ永続化・アーカイブも後続設計に回す。初期 DB では Worker を Pod metadata の代替として永続化せず、live view と Ticket-linked WorkerRef 記録に留める。

.yoi/objectives/00001KVJSMQXZ/item.md

@@ -2,13 +2,13 @@
 title: "効果的な Memory システム設計・検証"
 state: "active"
 created_at: "2026-06-20T15:16:00Z"
-updated_at: "2026-06-20T15:16:00Z"
+updated_at: "2026-07-17T23:10:00Z"
-linked_tickets: ["00001KSKBPHRG", "00001KT02TCCG", "00001KTGCAFXG", "00001KSKBPTHR"]
+linked_tickets: ["00001KSKBPHRG", "00001KT02TCCG", "00001KTGCAFXG", "00001KSKBPTHR", "00001KXMEZNYC", "00001KXMK7YMC", "00001KXNYXNM6", "00001KXRM6G0G", "00001KXS56AS5", "00001KXMK846H"]
 ---
 
 ## Goal
 
-Yoi の Memory / Knowledge / generated memory / resident context / retrieval / usage metrics を、実際の開発・設計・レビュー・オーケストレーションに効く sensemaking substrate として再設計・検証する。
+Yoi の Memory / Knowledge / Skills / generated context / resident context / retrieval / usage metrics を、実際の開発・設計・レビュー・オーケストレーションに効く sensemaking substrate として再設計・検証する。Memory は短期・変化前提の context、Knowledge は育てる long-term note、Skill は移植可能な workflow として分け、この Objective ではそれらと authority record / docs / typed tools の境界を再整理する。
 
 この Objective でいう「効果的な Memory システム」は、単に多く保存する仕組みではなく、作業中の問いに対して relevant material を集め、根拠を検証可能にし、再表現・仮説形成・反証探索・意思決定・成果物への反映を低コストにする仕組みである。
 
@@ -41,9 +41,9 @@ Yoi の現行 Memory は、この流れのうち「保存」と「一部の検
 
 - Ticket / task / question ごとの shoebox がない。
 - shoebox から evidence snippets を切り出し、source / provenance / applicability / confidence と共に扱う evidence file がない。
-- `summary`, `decision`, `request`, `knowledge` は storage taxonomy であり、sensemaking 用 schema としては粗い。
+- `summary`, `decision`, `request` は durable memory storage taxonomy であり、sensemaking 用 schema としては粗い。Knowledge は古い record kind をそのまま残すのではなく、育てる long-term note subsystem として再設計する。再利用可能な手順は Skill、保守された設計資料は Knowledge / docs / Ticket decisions に寄せる。
 - decision は残るが、hypothesis space、alternative、rejected reason、disconfirming evidence が残りにくい。
-- reviewer / orchestrator が confirmation bias を避けるための反証探索導線が弱い。
+- reviewer / orchestrator が confirmation bias を避けるための反証探索導線が弱い。関連する手順誘導は旧 Workflow ではなく Skill と role prompt / typed tools へ寄せる。
 - resident exposure と explicit retrieval は観測できても、Memory が product に効いたかは測りにくい。
 
 この Objective は、Memory 関連の設計・検証・検討・考察を一元化し、個別 Ticket がばらばらに storage、prompt、retrieval、metrics を改善して再び墓場を増やすことを防ぐための判断背景である。
@@ -67,7 +67,16 @@ Memory 墓場化の最初の原因は、保存情報が現在の問いに集ま
 
 この段階では大きな永続 schema 追加に飛びつかず、report / Ticket artifact / bounded generated context として検証してよい。
 
-### 3. Memory を authority にしない
+### 3. Session Overview を extract の足場にする
+
+現在の extract は、tool call / tool result summary を含む flat slice から意味を復元しようとして断片化しやすい。改善方針は、main Worker が通常 Assistant Message として Progress message を残し、user messages + Assistant messages を Session Overview として先に読む形にする。
+
+- Progress message は専用 Tool ではなく通常 Message とし、ユーザーへの進捗報告と extract 用 semantic summary を兼ねる。
+- extract worker には専用の read-only evidence tools を渡し、Overview で重要そうに見えた箇所だけ session range / tool summaries / source anchors を探索させる。
+- extract worker は Memory / Knowledge / Skill を直接更新しない。output は必ず staging を挟み、source / provenance を host 側で機械的に保持する。
+- trigger は初期実装では現行通り Worker run cycle 完了後の threshold 判定にする。LLM call 単位や Run 中の Overview accumulation trigger は含めない。
+
+### 4. Memory を authority にしない
 
 Memory は Ticket、docs、git history、session logs、user instruction の代替ではない。Memory は authority record への evidence index / schema / reasoning aid として扱う。
 
@@ -78,7 +87,7 @@ Memory は Ticket、docs、git history、session logs、user instruction の代
 - Memory の断定をそのまま authority として使わない。
 - Ticket body/thread/artifacts を読まずに Objective や Memory だけで実装判断できる状態を作らない。
 
-### 4. 反証探索を first-class にする
+### 5. 反証探索を first-class にする
 
 より効果的な Memory は、過去方針を思い出すだけでなく、現在案を疑うために使える必要がある。
 
@@ -92,7 +101,7 @@ Reviewer / Orchestrator / Intake の導線では、次を探せるようにす
 - authority boundary risks
 - prior failures / reports
 
-### 5. Metrics は exposure から product impact へ寄せる
+### 6. Metrics は exposure から product impact へ寄せる
 
 Memory が prompt に入った、または query されたことは成功ではない。評価は次を区別する。
 
@@ -105,7 +114,7 @@ Memory が prompt に入った、または query されたことは成功では
 - contradicted / invalidated
 - led to docs or decision update
 
-### 6. 後続 Ticket は concrete slice に分割する
+### 7. 後続 Ticket は concrete slice に分割する
 
 この Objective は中期的な設計・検証の一元化 record であり、umbrella Ticket ではない。実装や調査は、単独で実装・レビュー・close できる concrete Ticket に分割する。
 
@@ -115,23 +124,30 @@ Memory が prompt に入った、または query されたことは成功では
 - Ticket routing 用 Memory shoebox artifact を試作する。
 - evidence snippet schema / source resolver を設計する。
 - hypothesis / rejected alternative / disconfirming evidence の表現を追加する。
-- Reviewer workflow に反証探索を入れる。
+- Reviewer Skill / review process に反証探索を入れる。
 - Memory usage metrics を product impact oriented に拡張する。
 - stale / contradiction / renewal の検出・表示を設計する。
+- turn 中の Progress message を通常 Assistant Message として残す prompt/guidance を追加する (`00001KXMEZNYC`)。
+- Session Overview + Evidence index を使う extract input を設計・実装する。
+- extract worker 専用の read-only evidence search/read/source-anchor tools を設計する。
+- extract output を staging に限定し、source range と output entry を結びつける schema を設計する。
 
 ## Success criteria / exit conditions
 
-- Memory システムの目的が「保存」ではなく「sensemaking loop 支援」として project records / docs / prompts / workflows で一貫して説明されている。
+- Memory システムの目的が「保存」ではなく「sensemaking loop 支援」として project records / docs / prompts / Skills で一貫して説明されている。
 - Pirolli & Card の `shoebox -> evidence file -> schema -> hypotheses -> product` に対応する Yoi 内の責務と非責務が整理されている。
-- Ticket / Objective / docs / session logs / Memory / Knowledge の authority boundary が明確で、Memory が authority を僭称しない。
+- Ticket / Objective / docs / session logs / Memory / Skills の authority boundary が明確で、Memory が authority を僭称せず、Skill は手順資源として外部状態 authority を持たない。
 - 少なくとも一つの実作業 routing / review / design analysis で、task-bound shoebox または evidence file が生成・利用され、作業品質にどう効いたかが確認されている。
 - Memory records または関連 artifacts が source / provenance / applicability / staleness / supports-or-refutes のいずれかを扱えるようになっている。
+- extract が User / Assistant messages 由来の Session Overview を primary input とし、tool logs を evidence として探索できる設計になっている。
+- extract worker 専用の read-only evidence tools が設計され、main Worker の tool surface を増やさない方針になっている。
+- extract output は direct Memory / Knowledge / Skill write ではなく staging を挟む方針になっている。
 - 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` を検討できる。
+この Objective は、Memory が少なくとも一つの中規模設計・実装・レビュー作業で「関連情報を見つける」「根拠を確認する」「代替案/反証を検討する」「成果物へ反映する」流れを実証し、その設計方針が docs / Skills / metrics に反映された時点で `done` を検討できる。
 
 ## Decision context
 
@@ -141,13 +157,14 @@ Memory が prompt に入った、または query されたことは成功では
 - 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 として再検討する余地がある。
+- Knowledge は古い unused record kind をそのまま残すのではなく、育てる long-term Markdown note subsystem として再設計する。再利用可能な手順・作法は Agent Skills (`.yoi/skills/<skill>/SKILL.md`) へ、durable policy/rationale は Knowledge / maintained docs / Ticket decisions へ、外部状態 authority は typed feature/tool surface へ分ける。
-- Generated memory / curated Knowledge / Ticket / docs / report の境界を再定義する場合は、authority boundary と migration/staleness を明示する。
+- Generated memory / Ticket / docs / report / Skill の境界を再定義する場合は、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
+  - `00001KXMEZNYC` — ターン中のProgress messageを残す指示を追加する
 
 ## Historical references / prior design sources
 
@@ -183,9 +200,9 @@ Yoi 初期設計では、これを参考に以下を意図していた。
 - activity token 閾値で extract を発火する。
 - compact より前に session log range を抽出する。
 - extract は `decisions`, `discussions`, `attempts`, `requests` などの候補を staging に保存する。
-- 抽出時点では Knowledge 化せず、純粋な「起きたこと」に寄せる。
+- 抽出時点では durable policy / Skill / docs へ早期分類せず、純粋な「起きたこと」に寄せる。
-- consolidation が summary / decisions / requests / knowledge candidates を整理する。
+- consolidation が summary / decisions / requests と、必要に応じた docs / Skill / Ticket decision 更新候補を整理する。
-- consolidation 入力に linter warnings / usage metrics / Knowledge 化候補を含める。
+- consolidation 入力に linter warnings / usage metrics / stale cleanup 候補を含める。
 - stale / superseded / unused / noisy な情報を整理する。
 
 この Objective での再解釈:
@@ -224,7 +241,10 @@ HermesAgent で特に重要だった点:
 
 この Objective での再解釈:
 
-- HermesAgent の `MEMORY.md` / `USER.md` / `skills` の分離は、Yoi の Knowledge / Workflow / prompt resource / docs / Ticket decision / generated memory の責務再整理に使える。
+- HermesAgent の `MEMORY.md` / `USER.md` / `skills` の分離は、Yoi の Memory / Knowledge / Skills / prompt resources / docs / Ticket decision / generated memory の責務再整理に使える。
+- Yoi は foreground isolation 自体をすでに持つため、取り入れるべきなのは isolation そのものではなく、Overview を足場にした maintenance / extraction の質改善である。
+- main Worker が通常 Assistant Message として残す Progress message は、人間向け進捗報告と machine-readable session overview を兼ねられる。
+- extract worker は専用 read-only evidence tools で必要箇所だけ探索し、direct write ではなく staging に出力する。
 - 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 は解決しない。
@@ -242,6 +262,7 @@ Codex と HermesAgent の調査から、Yoi が継承すべきものと、継承
 - stale / noisy / unused entries の cleanup。
 - procedural memory と declarative memory の分離。
 - session search / usage metrics / linter feedback を consolidation に入れる設計。
+- user / Assistant messages から作る Session Overview を semantic guide にし、tool logs を evidence として探索する設計。
 
 足りないもの:
 

.yoi/objectives/00001KVJSMQXZ/memory-architecture-overview.md

@@ -0,0 +1,916 @@
+---
+created_at: "2026-07-15T21:33:00Z"
+updated_at: "2026-07-16T18:20:00Z"
+objective: "00001KVJSMQXZ"
+status: "architecture-draft"
+notes: "Memory / Knowledge / Skills を別々の workspace resource として再設計するための draft architecture。この文書は Objective resource であり、実装 authority ではない。"
+---
+
+# Memory / Knowledge / Skills architecture overview
+
+## 1. Position
+
+Yoi は **Memory**、**Knowledge**、**Skills** を 1 つの汎用 record store に押し込めず、別々の resource class として扱う。
+
+最初に固めるべきなのは、成果物が人間に読める形で成長できる workspace resource model である。Pirolli & Card の sensemaking process は有用な背景知識だが、storage taxonomy を shoebox / evidence / hypothesis として先に固定しない。sensemaking は Memory / Knowledge / Skills の上に乗る usage pattern として扱う。
+
+Target split:
+
+- **Memory**: 短期 fact、嗜好、現在の focus、進行中の context。変化する前提で書く。
+- **Knowledge**: 長期的に育てる note。人間と agent が改訂し、相互リンクで mesh を形成し、durable project understanding として読めるもの。
+- **Skill**: Agent Skills format に従う、移植可能で確立された手順・workflow。
+
+この文書の中核は次の 2 つである。
+
+1. resource class の境界を明確にする。
+2. session から extract / staging / consolidation を経て resource に至る pipeline の責務を明確にする。
+
+## 2. Design goals
+
+- 人間が読め、成長できる artifact を作る。
+  - 一時的な model summary だけでは足りない。
+  - 有用な成果は Knowledge note、Skill、Ticket decision、doc、report に育てられるべき。
+- 揮発的なものと durable なものを分ける。
+  - 短期 context が長期 note を汚染しないようにする。
+  - 長期 note が session extraction のたびに上書きされないようにする。
+- 手順と note を分ける。
+  - 繰り返し使える作業方法は Knowledge note ではなく Skill にする。
+- authority boundary を明示する。
+  - Ticket は work authority を定義する。
+  - docs と Objective resources は maintained design context を持つ。
+  - Knowledge notes は育てる project understanding を持つ。
+  - Skills は execution を guide する。
+  - Memory は変化する working context と preferences を追跡する。
+  - typed feature/tool surfaces が external state changes を所有する。
+- 可能な限り Workspace backend を resource API の共有 authority にする。
+  - `WorkspaceClient::Http` が使えるときに、Worker ごとに local view が分岐してはいけない。
+
+## 3. Resource model
+
+### 3.1 Memory
+
+Memory は、agent が作業を継続する助けになる volatile / short-to-medium-term な情報を扱う。長期的な project truth のふりはしない。
+
+Memory record に入るもの:
+
+- 現在の focus。
+- user preferences。
+- working assumptions。
+- authority が別にある recent decisions の要約や pointer。
+- 進行中の constraints。
+- あとで Ticket / doc / session を再確認するための reminder。
+- session から得た observations。
+- 変化することが前提の personal / workspace context。
+
+Memory は provisional に書く:
+
+- いつ / なぜ learned したかを書く。
+- どの前提で learned したかを必要な範囲で書く。
+- staleness / supersession を許す。
+- authoritative records を verbatim にコピーしない。
+- 可能なら Tickets / docs / Knowledge notes への pointer を優先する。
+
+Memory は resident context と lightweight lookup には有用だが、permanent note system として最適化しない。
+
+#### 3.1.1 Memory storage profile: bounded H2 Markdown file
+
+Memory の初期 storage profile は、bounded な single Markdown file にする。
+
+Memory は Knowledge のような note bundle ではない。1〜3 行程度の short items を H2 section ごとに並べる resident context surface として扱う。
+
+初期 filesystem shape:
+
+```text
+.yoi/memory/
+  memory.md
+  _staging/
+  _resolutions.jsonl
+```
+
+`memory.md` は H2 section を基本単位にする。
+
+```md
+# Workspace Memory
+
+## Current focus
+
+- Memory extract redesign is focused on Overview-first extraction and staging resolution.
+  Source: Objective 00001KVJSMQXZ. Stale when related tickets close.
+
+## Preferences
+
+- User prefers implementation Tickets, not design-only Tickets.
+  Source: 2026-07-16 session.
+
+## Working assumptions
+
+- Knowledge should be OKF-compatible, while volatile Memory and staging should not be OKF.
+  Source: architecture objective.
+
+## Reminders
+
+- Re-check extract/consolidation prompts after staging resolution is implemented.
+```
+
+Recommended H2 sections:
+
+- `## Current focus`
+- `## Preferences`
+- `## Working assumptions`
+- `## Constraints`
+- `## Reminders`
+- `## Stale or superseded`
+
+Each item should stay short. When useful, include `Source` and `Stale when` inline. Long explanations, evidence-heavy analysis, durable rationale, citations, and cross-linked concepts should be routed to Knowledge rather than expanded inside Memory.
+
+The single-file layout is an initial storage profile, not an API contract. Workers, Web, Runtime, and CLI should use the Workspace Memory API view rather than depending on the exact file layout, so storage can later split or evolve without changing the model-visible contract.
+
+#### Memory examples
+
+```text
+User preference: prefers direct commits only when explicitly requested.
+Source: repeated user corrections in sessions around git operations.
+Staleness: revisit if user changes repo workflow.
+```
+
+```text
+Current focus: web Workspace console and Workspace-backed Ticket/Skill authority.
+Source: recent Tickets and Objective updates.
+Expected to change after current milestone.
+```
+
+### 3.2 Knowledge
+
+Knowledge は long-term note system。人間と agent が育て、改訂し、link し、split / merge しながら読むもの。抽出 snippet の山ではなく、project understanding の mesh を形成する。
+
+Target Knowledge は、古い未使用の Knowledge feature をそのまま残すものではない。legacy implementation は先に削除してよい。置き換えは proper workspace note subsystem として設計する。
+
+Knowledge notes の要件:
+
+- Markdown-first で人間が読める。
+- OKF-compatible な concept document として扱える。
+- stable path / slug を持ち、OKF concept ID として参照できる。
+- Yoi 内部で move / rename に強い identity が必要な場合は、extension frontmatter として `yoi_id` を持てる。
+- bidirectional links / backlinks を support する。
+- Obsidian-style wiki links (`[[slug]]`, `[[slug|label]]`) を support し、Knowledge mesh の authoring shorthand として使える。
+- 必要なら tags や typed relations を support する。
+- 重要な claim には provenance / citations を残す。
+- Tickets、Objectives、docs、commits、reports、Skills、他 Knowledge notes に link できる。
+- review / staleness / supersession を support する。
+- 自動生成だけに頼らず、意図的に maintain される。
+
+Knowledge は、長期 architecture note、conceptual model、subsystem explanation、decision context、recurring constraints、domain understanding を育てる場所である。
+
+#### 3.2.1 Knowledge format profile: OKF-compatible bundle
+
+Yoi Knowledge は、可能な限り Open Knowledge Format (OKF) compatible な bundle として設計する。
+
+OKF から採用する baseline:
+
+- Knowledge bundle は Markdown file tree とする。
+- non-reserved `.md` file は concept document とする。
+- concept document は YAML frontmatter + Markdown body とする。
+- path without `.md` を OKF concept ID として扱う。
+- `type` は required field とする。
+- `title`, `description`, `resource`, `tags`, `timestamp` は recommended field とする。
+- normal Markdown links を OKF-compatible graph edges として扱う。
+- Obsidian-style wiki links (`[[slug]]`, `[[slug|label]]`) も graph edges として扱い、Markdown links へ解決・export できるようにする。
+- `index.md` は progressive disclosure のための directory listing として使える。
+- `log.md` は agent-readable update history として使える。
+- `# Citations` section は external source / authority reference を示す convention として使う。
+- consumers は unknown frontmatter fields、unknown `type`、broken links を tolerant に扱う。
+
+Yoi は OKF に extension frontmatter を足してよい。候補:
+
+```yaml
+yoi_id: 00001...
+status: draft | active | stale | superseded
+source_refs: []
+authority_refs: []
+objective_refs: []
+ticket_refs: []
+skill_refs: []
+reviewed_at: 2026-07-16T00:00:00Z
+staleness: "Revisit when ..."
+supersedes: []
+superseded_by: null
+```
+
+Filesystem shape の例:
+
+```text
+.yoi/knowledge/
+  index.md
+  log.md
+  architecture/
+    index.md
+    memory-architecture.md
+    workspace-authority.md
+  references/
+    pirolli-card-2005-sensemaking.md
+```
+
+OKF compatibility は Knowledge の exchange / storage profile であり、Memory / staging / Skill の format ではない。
+
+- Memory は短期・変化前提の resident context store なので OKF にしない。
+- staging は extract / consolidation の審査キューなので OKF にしない。
+- Skill は Agent Skills format を維持する。OKF `type: Playbook` に吸収しない。
+
+#### Knowledge examples
+
+- `workspace-authority-model`
+  - Workspace backend が Tickets / Skills / Runtime views の authority である理由を説明する。
+  - Ticket backend API design、Skill support ticket、Workspace control plane Objective に link する。
+- `memory-knowledge-skill-boundary`
+  - Memory / Knowledge / Skills の boundary を定義する。
+  - この architecture resource と将来の implementation Tickets に link する。
+- `ticket-lifecycle-authority`
+  - Ticket state authority と transition graph の rationale を説明する。
+  - 関連 decisions と code locations に link する。
+
+### 3.3 Skill
+
+Skill は、ある種類の task に対して確立された、portable な workflow / procedure。Agent Skills format に従う。
+
+```text
+.yoi/skills/<skill-name>/
+  SKILL.md
+  scripts/
+  references/
+  assets/
+```
+
+Skill は state machine ではなく、external authority も所有しない。agent が available tools を使って task をどう実行するかを示す prompt/resource guidance である。
+
+Skill に含めるもの:
+
+- いつその Skill を使うか。
+- step-by-step procedure。
+- expected inputs。
+- expected outputs / report shape。
+- examples。
+- edge cases。
+- optional references / scripts / assets。
+
+Skill は、project-specific assumptions が少なく、別 workspace に移しても使えるとき portable と言える。
+
+#### Skill examples
+
+- `coder-review-cycle`
+  - Coder が実装、検証、review request、feedback 対応、dossier 作成をどう行うか。
+- `ticket-intake`
+  - 曖昧な user request を accepted Ticket requirements に変換する方法。
+- `architecture-review`
+  - design proposals、alternatives、authority boundaries を評価する方法。
+
+## 4. Resource boundaries and authority
+
+### 4.1 Memory vs Knowledge
+
+Memory は provisional / change-oriented。Knowledge は maintained / growth-oriented。
+
+Memory を使うべきとき:
+
+- 情報が短命。
+- preference や working assumption である。
+- resident context として有用。
+- 長期的な置き場所がまだ明確でない。
+
+Knowledge を使うべきとき:
+
+- 時間をかけて読み直し、改訂するべき情報。
+- durable project concept を説明する情報。
+- 複数の future tasks から link されるべき情報。
+- backlinks / mesh structure が有用な note。
+- 人間が project understanding として browse できるべきもの。
+
+Promotion path:
+
+```text
+Memory observation -> candidate note/update -> Knowledge note / docs / Ticket decision
+```
+
+Promotion は明示的に行う。すべての Memory item が Knowledge になるわけではない。
+
+### 4.2 Knowledge vs Docs
+
+Docs は public / project-facing な maintained exposition。Knowledge は internal で、link され、発展する understanding。
+
+Knowledge note は後で doc になり得るが、threshold は違う:
+
+- Knowledge は uncertainty、partial models、evidence links を含められる。
+- Docs は settled explanations または user/developer guidance を提示するべき。
+
+### 4.3 Knowledge vs Ticket decisions
+
+Ticket decisions は work item history と state の authority。Knowledge notes は複数 Ticket をまたいだ synthesis。
+
+ある decision が Ticket の requirement、state、acceptance criteria を変えるなら、それは Ticket に記録する。Knowledge はそこに link し、より広い pattern を説明できる。
+
+### 4.4 Skill vs Knowledge
+
+Knowledge は「何が true か」「project をどう理解するか」を説明する。Skill は「recurring task をどう実行するか」を説明する。
+
+Skill を使うべきとき:
+
+- review process。
+- implementation process。
+- release checklist。
+- architecture evaluation method。
+
+Knowledge を使うべきとき:
+
+- Workspace authority model。
+- Memory architecture。
+- Ticket lifecycle rationale。
+
+### 4.5 Skill vs Feature/Plugin
+
+Skill は prompt/resource guidance。Feature/Plugin は executable authority と tool surface。
+
+Skill は「何をどう進めるか」を書けるが、Ticket、Workspace、Memory、外部状態を変更する権限そのものは持たない。その権限は Feature/Plugin や typed tool/API が持つ。
+
+例: Skill は「review 前に Ticket shoebox を作る」と指示できる。実際に作成する authority は Workspace / Memory feature の typed tool/API が提供する。
+
+## 5. Workspace API authority
+
+Target architecture は Workspace-backed にする。
+
+### 5.1 Memory API
+
+Workspace backend が最終的に提供するもの:
+
+- Memory list / search / read / write / edit / delete。
+- resident memory summary の生成または取得。
+- staleness / supersession markers。
+- sessions や artifacts からの Memory candidate proposal。
+- provenance と audit events。
+- preference / current-focus surfaces。
+
+移行期間中は local `.yoi/memory` を compatibility / offline storage として残してよい。初期 storage profile は H2 section ベースの bounded `.yoi/memory/memory.md` だが、これは API contract ではない。
+
+### 5.2 Knowledge API
+
+Workspace backend は、raw filesystem layout を唯一の interface にするのではなく、proper note API を提供する。
+
+- Knowledge catalog / list / search。
+- note read / write / edit / delete。
+- OKF-compatible frontmatter validation / normalization。
+- link / backlink extraction from Markdown links and wiki links (`[[slug]]`)。
+- relation / tag metadata。
+- staleness / supersession markers。
+- note diagnostics / lint。
+- source / provenance refs and citations。
+- Markdown files からの import / export。
+- OKF bundle import / export profile。
+
+Filesystem representation は `.yoi/knowledge/` 配下の OKF-compatible bundle を第一候補にする。ただし Worker / Runtime / Web / CLI は、利用可能なら raw filesystem ではなく Workspace API view に収束する。
+
+### 5.3 Skill API
+
+Skill support は separate Skill Ticket の方針に従う。
+
+- Workspace backend が discovery / lint / catalog / activation を所有する。
+- `.yoi/skills/<skill>/SKILL.md` は workspace storage convention。
+- `WorkspaceClient::Http` が使えるとき、Workers は Workspace API から Skill metadata / body を使う。
+- Skill references / assets は backend-resolved authority または Skill resource APIs 経由で access する。
+
+## 6. Session-to-resource pipeline
+
+この章が extract 改善の中心である。`extract -> staging -> consolidate` の分割は維持する。3 つは同じ memory maintenance pipeline の一部だが、判断の種類が違う。
+
+```text
+Session history
+  -> Overview + Evidence index
+  -> extract
+  -> staging
+  -> consolidation
+  -> Memory / Knowledge candidate / Skill candidate / Ticket-doc candidate / discard
+```
+
+役割の要約:
+
+- **extract**: session から候補を拾う。recall 寄り。Memory 化はしない。
+- **staging**: provenance 付き候補キュー。まだ Memory ではない。
+- **consolidation**: staging を審査・剪定・統合する。precision 寄り。Memory 肥大化と陳腐化を防ぐ。
+
+### 6.1 Overview: transcript as semantic backbone
+
+Overview は、committed history にある user messages と normal Assistant text outputs から作る。Assistant text outputs には、最終応答だけでなく、長い作業中の Progress message も含める。
+
+Progress message は専用 Tool ではなく、ordinary user-visible prose response として残す。Tool surface を増やさず、ユーザーへの進捗報告と extract 用 semantic summary を兼ねるためである。
+
+Overview に含めるもの:
+
+- user requests / corrections / approvals。
+- Assistant progress messages。
+- Assistant final responses。
+- parent delegation や Ticket context のように、history に commit された task context。
+- tool evidence への bounded index。
+
+Overview に含めないもの:
+
+- raw reasoning / chain-of-thought。
+- raw tool-result content 全文。
+- secret-like data。
+- history に commit されていない hidden context injection。
+
+Overview の意図は、extract worker に「何のための探索だったか」「どの判断が節目だったか」「どこが未解決か」を伝えることである。Overview は authority ではない。durable output には evidence と source anchors が必要である。
+
+### 6.2 Extract: candidate generation
+
+Extract は candidate generation であり、Memory 化ではない。runtime 側の extract worker が Overview と session evidence を読んで、後で記憶化を検討すべき **flat candidate records** を staging に出す。
+
+Extract の責務:
+
+- Overview を読んで、記憶化を検討すべき candidate を見つける。
+- 必要な箇所だけ evidence tools で確認する。
+- candidate ごとに bounded evidence snippets / source anchors を選ぶ。
+- candidate ごとに `stage_candidate` を呼び、1 candidate = 1 staging record として保存する。
+- 最後に `finish_extraction` を呼び、staged count または NOP reason を残す。
+
+Extract がしてはいけないこと:
+
+- Memory / Knowledge / Skill / Ticket / docs を直接変更しない。
+- batch payload として複数 candidate を 1 staging record にまとめない。
+- tool result 全文や reasoning を無制限に取り込まない。
+- local slice だけから根拠を推測しない。
+- tool call chronology、generic progress、current focus update を抽出しない。
+- 「進捗報告があった」こと自体を Memory 化しない。
+
+Staging candidate は、Consolidation がそれ単体で discard / merge / promote / defer を判断できる最小単位にする。
+
+旧 `decisions` / `discussions` / `attempts` / `requests` batch schema は維持しなくてよい。互換性よりも、flat candidate records と clear responsibility を優先する。
+
+#### 6.2.1 Extract candidate taxonomy
+
+Extract が抽出する対象は activity log ではない。抽出対象は次の candidate kinds に絞る。
+
+| kind | extract で見る観点 | consolidation での扱い |
+| --- | --- | --- |
+| `preference` | ユーザーまたは workspace の継続的な好み・作法。単発指示ではなく、今後の agent behavior に効くもの。 | Memory に短く merge / replace する候補。既存 preference と重複するなら統合。Ticket/docs の要件そのものなら mirror せず authority link へ。曖昧なら discard / defer。 |
+| `working_assumption` | 現時点で仮に置いている設計・実装前提。future work に影響し、変更条件や反証条件があり得るもの。 | Memory に入れる場合は short-lived assumption として stale condition 必須。長期設計なら Knowledge candidate。すでに authority record に反映済みなら Memory には pointer だけ、または discard。 |
+| `constraint` | 今後守るべき境界・禁止・invariant。実装や review でチェック可能なもの。 | active implementation に効くなら Memory。durable policy なら Ticket decision / Knowledge / docs candidate。破られた既存 Memory があれば mark_stale / replace。 |
+| `decision` | alternatives / chosen / rationale がある判断。単なる事実確認や作業進行ではないもの。 | まず authority routing を判断する。Ticket 要件・state・acceptance に関係するなら Ticket decision/comment candidate。長期設計なら Knowledge/Objective candidate。短期実装判断だけ Memory に短く置く。会話中の一時結論なら discard。 |
+| `open_question` | 未解決で後続作業に影響する問い。next action が書けるもの。単なる会話中の疑問ではない。 | Memory reminder にするか、Ticket follow-up / planning item に送る。解決済みなら discard。長く残る概念的問いなら Knowledge candidate。TTL / defer reason を持たせる。 |
+| `lesson` | 検証・失敗・試行から得た再利用価値のある学び。同じ失敗を避ける、作業方法を改善する、Skill 化できる可能性があるもの。 | Memory に短く残すか、recurring / portable なら Skill candidate。単なる tool execution result は discard。validation evidence として Ticket/report に残すべきものは authority link。 |
+
+抽出しないもの:
+
+- `current_focus` update。これは resident summary surface であり、extract candidate kind ではない。
+- tool call chronology。
+- file read/write history。
+- generic progress updates。
+- one-off chit-chat。
+- resolved local confusion。
+- assistant self-corrections without durable consequence。
+- authoritative Ticket/docs/git facts copied verbatim。
+- validation results unless they imply a reusable lesson, active blocker, or authority evidence。
+- implementation details that belong only in commit diff。
+
+### 6.3 Extract worker tools
+
+extract worker には `session-explore` feature の constrained tools だけを渡す。これは main Worker の tool 数を増やすものではない。
+
+Tool surface:
+
+- `search_evidence`: session snapshot / tool summaries / message index から query で候補 range を探す。
+- `read_evidence`: bounded な session entry range、tool call/result summary、host が許す bounded excerpt を読む。
+- `stage_candidate`: 1 candidate を staging record として保存する。
+- `finish_extraction`: extract run を終了し、staged count または NOP reason を記録する。
+
+`stage_candidate` は direct Memory write ではない。これは staging write だけを行う output tool である。
+
+`stage_candidate` input の概念形:
+
+```json
+{
+  "kind": "decision",
+  "claim": "Overview is runtime-only extract projection, not staging data.",
+  "why_useful": "Clarifies extract/consolidate responsibility boundary.",
+  "staleness": "Revisit if Workspace can directly explore runtime sessions.",
+  "evidence_ids": ["E001", "E002"]
+}
+```
+
+Host wrapper は `evidence_ids` を runtime reference environment から解決し、bounded evidence snippets と source anchors を staging record に機械的に付与する。LLM に自由な source anchor を書かせない。
+
+`finish_extraction` の概念形:
+
+```json
+{
+  "staged_count": 0,
+  "reason": "Only local progress and tool chronology; no durable candidates."
+}
+```
+
+候補が無い場合は `stage_candidate` を呼ばず、`finish_extraction` で NOP を明示する。tool call なし終了も host 側では NOP fallback として扱ってよいが、基本は `finish_extraction` を要求する。
+
+制約:
+
+- read-only evidence access。file write、Ticket mutation、Memory/Knowledge/Skill direct write は持たせない。
+- bounded output。large tool result は summary / excerpt / pointer に留める。
+- provenance first。extract worker が根拠を推測せず、読んだ evidence ids を `stage_candidate` に渡す。
+
+### 6.4 Staging: flat provenance-backed candidate records
+
+Staging は Memory ではない。Staging は、extract が切り出した candidate を provenance 付きで保管し、consolidation が後で審査できるようにする queue である。
+
+Staging は flat records にする。
+
+```text
+1 extract run = 0..N staging records
+1 staging record = 1 candidate = 1 consolidation decision unit
+```
+
+1 record の概念形:
+
+```json
+{
+  "schema_version": 2,
+  "id": "stg_...",
+  "extract_run_id": "er_...",
+  "source": {
+    "segment_id": "segment-1",
+    "range": [120, 180]
+  },
+  "kind": "constraint",
+  "claim": "Extract worker must not direct-write Memory/Knowledge/Skill; it only writes staging.",
+  "why_useful": "Preserves runtime/embedded responsibility boundary.",
+  "staleness": "Revisit if extract and consolidation move into the same Workspace execution context.",
+  "evidence": [
+    {
+      "id": "E001",
+      "kind": "message",
+      "entry_range": [132, 133],
+      "excerpt": "extract worker は Memory / Knowledge / Skill を直接更新しない",
+      "summary": "User and architecture discussion fixed staging-only extract boundary."
+    }
+  ],
+  "source_refs": [
+    {
+      "evidence_id": "E001",
+      "evidence_kind": "message",
+      "entry_range": [132, 133]
+    }
+  ]
+}
+```
+
+Staging の責務:
+
+- candidate kind / claim / hints を保持する。
+- extract が選んだ bounded evidence snippets を保持する。
+- source anchors を保持する。
+- extract と consolidation を decouple する。
+- duplicate / defer / discard / consumed の追跡対象になる。
+- crash / cancel / long-running work の途中でも、後から審査できる候補を残す。
+
+Staging がしてはいけないこと:
+
+- Memory として resident context に直接入らない。
+- Knowledge note の代替にならない。
+- raw session log や Overview 全体の保存場所にならない。
+- extract run 単位の batch file として複数 candidate を抱え込まない。
+- staging entry をすべて Memory 化する前提にしない。
+
+Pirolli & Card 的には、staging は shoebox / evidence file に近い。ただし Yoi の storage taxonomy そのものを shoebox にするのではなく、審査前の evidence-backed candidate queue として扱う。
+
+### 6.5 Staging resolution: the important filter
+
+Staging から Memory 化する段階が、Memory 肥大化と陳腐化を防ぐ中核 filter である。
+
+Consolidation は staging entry ごとに resolution / disposition を決めるべきである。
+
+Disposition action 候補:
+
+- `discard`: 保存価値なし。discard reason を残す。
+- `merge_memory`: 既存 Memory に統合する。
+- `replace_memory`: 古い Memory を新しい内容で置換する。
+- `mark_memory_stale`: 既存 Memory が古くなったことを記録する。
+- `delete_memory`: 邪魔または誤った Memory を削除する。
+- `defer`: 価値判断できないため短期保留する。TTL / defer reason を持つ。
+- `promote_to_knowledge_candidate`: long-term note に育てる候補へ送る。
+- `promote_to_skill_candidate`: recurring / portable procedure の候補へ送る。
+- `link_to_authority`: Ticket / doc / commit / Objective への pointer だけ残す。
+- `create_ticket_or_doc_candidate`: authority / public guidance にすべき候補として送る。
+
+Resolution に残すべき情報:
+
+- staging entry id。
+- action。
+- reason。
+- source anchors。
+- target record / candidate destination。
+- consolidation run id / consumed_by。
+- reviewed_at。
+- discard / defer / stale reason。
+
+Consumed staging を削除する場合も、resolution は残す。これにより「何を Memory にしなかったか」が改善材料として残る。
+
+### 6.6 Consolidation: memoryization, routing, and gardening
+
+Consolidation は precision-oriented pass である。staging を読んで、Memory にするか、別 resource candidate に送るか、捨てるかを決める。
+
+Consolidation の責務:
+
+- staging entry を candidate kind ごとの扱いに沿って評価する。
+- Memory 化するなら usefulness / staleness / source を要求する。
+- 既存 Memory と merge / replace / mark stale / delete する。
+- decision / constraint / lesson などを authority / Knowledge / Skill / Ticket / docs candidate に routing する。
+- discard reason / defer reason を残す。
+- linter feedback / usage evidence / tidy hints を使う。
+- Memory bloat と stale records を防ぐ。
+
+Consolidation がしてはいけないこと:
+
+- staging entry を無条件に append しない。
+- Ticket / docs / git / session log の mirror を Memory に作らない。
+- Knowledge / Skill / docs を background review だけで無制限に rewrite しない。
+- source / provenance のない claim を durable Memory にしない。
+
+Memory 化に必要な minimum fields / prose:
+
+```text
+content: 何を覚えるか
+why_useful: 今後なぜ役立つか
+source: staging / evidence anchor
+staleness: 何が起きたら古くなるか
+destination_reason: なぜ Knowledge / Skill / Ticket / docs ではなく Memory なのか
+```
+
+Consolidation は append worker ではなく garden worker である。新規作成より、既存 record の統合・置換・陳腐化・削除を優先する。
+
+### 6.7 Trigger policy
+
+発火単位は LLM call 単位にしない。LLM call 単位では文脈が薄く、断片的な extraction になりやすい。
+
+初期方針:
+
+- 現行通り、Worker run cycle が完了してから threshold を判定し、超えていれば extract を発火する。
+- extract 開始時点で immutable snapshot / Overview projection / Evidence index を作る。
+- LLM call ごとには発火しない。
+- Run 中の Overview accumulation trigger / mid-run extract は初期実装に含めない。
+- 将来 long-running 中に mid-run 発火を入れる場合も、direct update ではなく staging/checkpoint extraction に限定する。
+
+この trigger は、まず既存の post-run memory job model を保ち、extract の入力品質と staging record 粒度の改善に集中する。
+
+## 7. Sensemaking interpretation
+
+Sensemaking は storage taxonomy ではなく、pipeline の見方として使う。
+
+Pirolli & Card の flow を Yoi に対応させるとこうなる:
+
+```text
+External data sources
+  = session log, tool results, Tickets, docs, code, web refs
+
+Shoebox
+  = Overview + Evidence index + selected candidate ranges
+
+Evidence file
+  = source anchors 付き staging entries
+
+Schemas / hypotheses
+  = Memory 化すべきか、Knowledge/Skill に送るべきか、stale かの判断
+
+Product
+  = Memory update, Knowledge candidate, Skill candidate,
+    Ticket/doc update, review evidence, discard resolution
+```
+
+重要なのは、Memory 化を evidence から product へ進める審査の一形態として扱うこと。Memory record は「将来の作業に効く」という hypothesis なので、why_useful、staleness、source が必要である。
+
+初期 sensemaking support は lightweight でよい:
+
+- task-bound collected references as Ticket/Objective artifacts。
+- provenance 付き evidence summaries。
+- review Skills における explicit contradictory evidence sections。
+- recurring patterns を synthesize する Knowledge notes。
+- staging resolution に discard / defer / promote reason を残す。
+
+## 8. Human-readable growth paths
+
+中核要件は、有用な material が人間に読める形へ成長できること。
+
+Typical paths:
+
+```text
+Session observation
+  -> staging candidate
+  -> Memory record
+  -> Knowledge note candidate
+  -> Knowledge note with links/backlinks
+  -> maintained doc or Ticket decision if it becomes authority
+```
+
+```text
+Repeated successful procedure
+  -> staging candidate / Memory observation / Ticket comment
+  -> Skill candidate
+  -> `.yoi/skills/<skill>/SKILL.md`
+  -> builtin or shared Skill if portable
+```
+
+```text
+Design discussion
+  -> Objective resource
+  -> Knowledge note synthesis
+  -> implementation Tickets
+  -> docs after stabilization
+```
+
+Architecture は、これらの promotion を explicit and reviewable にする。
+
+## 9. External reference lessons
+
+### 9.1 Current Yoi pipeline
+
+現在の Yoi extraction は activity-log pipeline:
+
+- `build_extract_input` が conversation slice を flat Markdown として render する。
+  - user / assistant text は保持する。
+  - tool-call names を含める。
+  - raw tool-result content ではなく tool-result summaries のみを含める。
+  - reasoning は落とす。
+- extract worker の tool は `write_extracted` 1 つだけ。
+- `write_extracted` は `decisions`、`discussions`、`attempts`、`requests` を持つ structured `ExtractedPayload` を 1 件受け取る。
+- LLM は provenance を作らない。Worker が `StagingRecord` を書くときに `source` を機械的に付与する。
+- empty payload は valid で、no-op として扱える。
+- consolidation は後で staging entries、full current Memory records、usage evidence、tidy hints を consume する。
+- consolidation は Memory tools 経由で write し、linter feedback に対応し、record を merge / replace し、outdated / superseded / unused / noisy records を clean up する。
+
+残す価値がある点:
+
+- foreground 応答生成から memory maintenance が隔離されている。
+- provenance が host 側で機械付与される。
+- extract が direct write せず staging を挟む。
+- empty / no-op が許される。
+- consolidation が linter feedback と tidy hints を使う。
+
+変えるべき点:
+
+- flat slice ではなく Overview-first / Evidence-index-second にする。
+- extract worker に read-only evidence tools を持たせる。
+- staging を一時バッファではなく審査キューとして扱う。
+- consolidation に entry-level disposition / resolution を要求する。
+- legacy Knowledge as generated memory 前提を外す。
+
+### 9.2 HermesAgent
+
+HermesAgent は background review により、conversation snapshot から Memory / Skill update を直接判断する。
+
+参考になる点:
+
+- maintenance を foreground interaction から隔離する。
+- 保存すべきものがなければ NOP にする。
+- Memory と Skill を分ける。
+- prompt snapshot / drift / injection guard を重視する。
+
+そのまま採用しない点:
+
+- direct write-only review を主経路にしない。
+- aggressive Skill update bias を避ける。
+- `MEMORY.md` / `USER.md` two-file model を Yoi 全体の architecture にしない。
+
+Yoi では、Hermes 的な direct maintenance は bounded Memory update lane では参考になるが、extract worker 自体は direct write しない。
+
+### 9.3 Codex
+
+Codex は session / rollout を durable source として扱い、background pipeline が後から claim / extract / consolidate する。
+
+参考になる点:
+
+- durable source。
+- phase separation。
+- claim / lease / retry / global lock。
+- workspace diff / baseline guard。
+- extraction と consolidation の分離。
+
+Yoi では、Codex 的な durable job / phase pipeline は staging resolution と consolidation scheduling に取り入れる価値がある。ただし、この architecture phase ではまず Overview-first extract と staging resolution を優先する。
+
+## 10. Implementation posture
+
+現在の実装は redesign してよい。既存の Memory / Knowledge shape があるからという理由で残さない。
+
+ただし big-bang rewrite は避ける。この architecture が accepted されてから分割する。
+
+Recommended implementation sequence:
+
+1. **Knowledge removal 後の current Memory を clarify する**
+   - short-term / resident Memory を維持する。
+   - Memory が Knowledge を代替しなければならない、という前提を外す。
+   - legacy `knowledge/*` を generated memory として扱う stale consolidation prompt language を削除する。
+
+2. **Progress message guidance を追加する**
+   - 長い作業や tool loop の節目で、main Worker が ordinary user-visible prose response として短い Progress message を残す。
+   - 専用 Tool は追加しない。
+   - Progress message は public に見せられる作業状態、確認済み事実、判断、未解決点、次の作業に限定する。
+
+3. **Overview-first extract input を実装する**
+   - user messages + Assistant text outputs を semantic Overview として優先する。
+   - tool calls / tool results は Evidence index として分離する。
+   - committed history だけから Overview を作り、hidden context injection を避ける。
+
+4. **Extract worker 専用 evidence tools と staging output tools を実装する**
+   - extract worker に read-only Evidence search / Evidence read を渡す。
+   - main Worker の tool surface は増やさない。
+   - output tools は `stage_candidate` / `finish_extraction` にする。
+   - `stage_candidate` は 1 candidate = 1 flat staging record を書く。
+   - source range と candidate record を結びつけられる schema / staging format を実装する。
+
+5. **Staging-first extract を維持する**
+   - extract worker は direct Memory / Knowledge / Skill write をしない。
+   - overview accumulation / evidence growth / run or task boundary で extract を予約する。
+   - mid-run 発火を入れる場合も staging/checkpoint extraction に限定する。
+
+6. **Staging resolution / disposition を実装する**
+   - staging entry ごとに discard / merge / replace / stale / delete / defer / promote / link を記録する。
+   - consumed staging を削除する前に resolution log / archive を残す。
+   - discard reason と defer reason を extract prompt 改善に使えるようにする。
+
+7. **Target Knowledge note model を設計する**
+   - OKF-compatible Markdown concept document / bundle profile。
+   - Yoi extension frontmatter。
+   - link / backlink model。
+   - provenance / citations / staleness metadata。
+   - Workspace API surface。
+   - reviewable Knowledge updates の candidate / staging format。
+
+8. **Consolidation / tidy lane を更新する**
+   - staging entries、existing Memory、usage evidence、linter feedback、stale/noisy hints を統合する。
+   - legacy Knowledge as generated memory 前提を外す。
+   - Memory update、Knowledge candidate、Skill candidate を分けて扱う。
+
+9. **Minimal Knowledge catalog/read/write を実装する**
+   - OKF-compatible Markdown files と Workspace API から始める。
+   - frontmatter validation / lint と backlinks を追加する。
+   - `index.md` progressive disclosure と `# Citations` の扱いを実装する。
+
+10. **Skill support を別に実装する**
+    - Agent Skills standard と Workspace authority に従う。
+    - Skill と Knowledge note schema を混ぜない。
+    - automatic Skill modification は recurrence と portability で gate する。
+
+11. **Promotion workflows/tools を追加する**
+    - Memory -> Knowledge candidate。
+    - Knowledge -> docs / Ticket decision candidate。
+    - repeated procedure -> Skill candidate。
+
+12. **Resource classes が安定してから sensemaking helpers を追加する**
+    - collected refs。
+    - evidence extraction。
+    - contradiction / staleness views。
+    - product-impact metrics。
+
+## 11. Non-goals
+
+- Memory を唯一の long-term knowledge store として扱うこと。
+- Knowledge を名前だけ変えた generated memory として扱うこと。
+- Skill を Workflow tracker や state machine として扱うこと。
+- Worker history / tool results の外で context injection を隠すこと。
+- Knowledge notes を Tickets / docs / git history より authoritative にすること。
+- review なしに Knowledge / Skills / docs を自動 rewrite すること。
+- extract worker に direct resource mutation authority を持たせること。
+- extract run 単位の batch staging record に複数 candidate を抱え込ませること。
+- staging entry をすべて Memory 化すること。
+- human-readable artifact model が安定する前に vector database を設計すること。
+- volatile Memory や staging queue を OKF concept document として扱うこと。
+- H2 Markdown single-file layout を Workspace Memory API の長期 contract として固定すること。
+- Agent Skills format を OKF Playbook documents で置き換えること。
+
+## 12. Open decisions
+
+- Knowledge bundle の exact directory organization: flat files、nested directories、domain directories のどれを初期推奨にするか。
+- Yoi extension frontmatter の exact fields。
+- Yoi stable `yoi_id` を必須にするか optional にするか。
+- OKF `type` values の初期 convention をどうするか。
+- Link syntax は OKF-compatible Markdown links と Obsidian-style wiki links (`[[slug]]`, `[[slug|label]]`) を support する。canonical internal representation と export normalization をどうするか。
+- Knowledge note IDs / slugs と titles の関係。
+- Memory は local-first のままにするか、Knowledge と同じ phase で Workspace API-first にするか。
+- Memory / Knowledge APIs は同じ crate にするか、別 domain crates にするか。
+- Memory -> Knowledge の promotion UI/tool をどうするか。
+- personal Memory と workspace Memory をどう区別するか。
+- Knowledge drafts の auto-generation をどこまで許すか。
+- extract worker 専用 evidence tools の exact API: search/read の引数、上限、evidence id format。
+- `stage_candidate` / `finish_extraction` の exact tool schema。
+- flat staging record の exact fields: `claim`, `why_useful`, `staleness`, `evidence`, `source_refs`, `extract_run_id` など。
+- Overview trigger を overview token count、Assistant message count、evidence growth、run/task boundary のどれで制御するか。
+- mid-run extract をどこまで許すか。初期は staging/checkpoint extraction に限定する方針。
+- staging resolution log / archive の保持期間と compact policy。
+- どの Memory sidecar writes を direct に許し、どれを staged proposals にするか。extract worker 自体は direct write しない。
+- Skill sidecar output は patches/proposals だけから始めるか、low-risk Skill edits を auto-apply してよいか。
+- Memory / Knowledge / Skill Workspace APIs をまたぐ sidecar audit events をどう表現するか。
+- prompt-cache-aware sidecar input で full replay と digest-plus-tail をどう選ぶか。
+
+## 13. Exit criteria for architecture phase
+
+この architecture は、次が満たされたら Tickets に分割できる。
+
+- Memory / Knowledge / Skill boundary が accepted される。
+- OKF-compatible bundle / Markdown concept documents としての target Knowledge が accepted される。
+- Memory / Knowledge / Skills の Workspace backend authority が accepted される。
+- Overview-first extract、extract worker 専用 evidence tools、staging-first output の方針が accepted される。
+- staging resolution / disposition と、staging -> Memory 化 filter の方針が accepted される。
+- 最初の implementation slice が選ばれる。
+- non-goals が accepted され、old Workflow tracking や old unused Knowledge をそのまま再作成しないことが確認される。

.yoi/objectives/00001KVJSMQXZ/resources/pirolli-card-2005-sensemaking.md

@@ -0,0 +1,137 @@
+---
+source_url: "https://andymatuschak.org/files/papers/Pirolli%2C%20Card%20-%202005%20-%20The%20sensemaking%20process%20and%20leverage%20points%20for%20analyst%20technology%20as.pdf"
+fetched_at: "2026-07-15T21:24:00Z"
+content_type: "application/pdf"
+notes: "Untrusted external reference captured as local Objective resource for Memory sensemaking design. This is a summary/extraction for design discussion, not project authority."
+---
+
+# Pirolli & Card (2005): The sensemaking process and leverage points for analyst technology
+
+## Citation / source
+
+Peter Pirolli and Stuart Card, PARC. "The Sensemaking Process and Leverage Points for Analyst Technology as Identified Through Cognitive Task Analysis" (2005).
+
+Source PDF: <https://andymatuschak.org/files/papers/Pirolli%2C%20Card%20-%202005%20-%20The%20sensemaking%20process%20and%20leverage%20points%20for%20analyst%20technology%20as.pdf>
+
+## Core model
+
+The paper frames intelligence analysis as a sensemaking task:
+
+```text
+Information -> Schema -> Insight -> Product
+```
+
+The analyst transforms raw data into progressively more structured representations so expertise can apply and so results can be communicated.
+
+The paper's notional data flow is especially relevant to Yoi Memory design:
+
+```text
+External data sources
+  -> shoebox
+  -> evidence file
+  -> schemas
+  -> hypotheses
+  -> presentation / work product
+```
+
+- **External data sources**: raw material, mostly text in the studied setting.
+- **Shoebox**: the smaller subset collected as relevant for the task.
+- **Evidence file**: extracted snippets / nuggets from the shoebox, plus low-level inferences.
+- **Schemas**: re-representations that organize information for analysis.
+- **Hypotheses**: tentative conclusions with supporting or disconfirming evidence.
+- **Product**: report / presentation / action suited for communication.
+
+## Two major loops
+
+The process has two interacting loops rather than a simple linear pipeline.
+
+### Foraging loop
+
+Activities aimed at finding and selecting information:
+
+- search and filter external data sources;
+- collect potentially relevant material into a shoebox;
+- read and extract evidence snippets;
+- follow up on questions generated by extracted evidence.
+
+The paper highlights the exploration / enrichment / exploitation tradeoff:
+
+- **Exploration**: monitor or search more of the information space; increases recall.
+- **Enrichment**: narrow the collected set into smaller, higher-precision subsets.
+- **Exploitation**: read/extract/analyze the chosen material more thoroughly.
+
+Analyst tooling can help by changing the cost structure of search, scanning, assessment, selection, attention shifting, and follow-up searches.
+
+### Sensemaking loop
+
+Activities aimed at structuring and reasoning:
+
+- schematize evidence;
+- build a case;
+- generate / manage hypotheses;
+- marshal evidence for and against hypotheses;
+- tell a story / produce a report;
+- re-evaluate based on feedback or new evidence.
+
+The paper emphasizes opportunistic mixing of bottom-up and top-down processing:
+
+- **Bottom-up**: data triggers schemas, relations, hypotheses, and products.
+- **Top-down**: hypotheses / client feedback trigger new searches, re-reading, and re-organization.
+
+## Leverage points
+
+### Foraging loop leverage
+
+- Cost structure of exploration / enrichment / exploitation.
+- Cost structure of scanning, recognizing, and selecting items for attention.
+- Cost of shifting attentional control to a new domain or task.
+- Cost of follow-up searches generated by extracted information.
+- Broad-band low-fidelity assessment plus narrow-band high-fidelity processing is a useful design pattern.
+
+### Sensemaking loop leverage
+
+- Span of attention for evidence, hypotheses, and evidentiary relations.
+- Generation of alternative hypotheses.
+- Confirmation bias and failure to seek disconfirming evidence.
+- External representations can expand working memory for evidence/hypothesis structures.
+- Tools should help distribute attention toward diagnostic evidence and disconfirming relations.
+
+## Implications for Yoi Memory Objective
+
+This paper directly supports the Objective's direction that effective Memory is not just durable storage or retrieval count.
+
+Useful design implications:
+
+1. **Task-bound shoebox**
+   - For each Ticket / Objective / question, provide a bounded collection of potentially relevant materials.
+   - Include provenance and why each item was collected.
+
+2. **Evidence file**
+   - Extract snippets from source material with source, applicability, confidence, and context.
+   - Evidence should be usable for support and disconfirmation, not only recall.
+
+3. **Schema / representation layer**
+   - The system should help create intermediate structures: timelines, entity/relation maps, alternatives, checklists, hypothesis spaces, decision tables.
+   - These are separate from raw Memory records.
+
+4. **Hypotheses and alternatives**
+   - Record competing explanations, rejected alternatives, open questions, and evidence gaps.
+   - Avoid only storing final decisions.
+
+5. **Disconfirming evidence**
+   - Reviewer / Orchestrator support should explicitly search for contradiction and diagnostic evidence.
+   - This belongs in Skill guidance and typed review tooling, not in a separate Knowledge store.
+
+6. **Metrics**
+   - Measure whether Memory changes product quality, review quality, decision quality, or time-to-evidence.
+   - Avoid treating exposure/retrieval counts alone as success.
+
+7. **Product connection**
+   - The loop should end in a product: Ticket decision, implementation report, review, design doc, Skill update, or validated artifact.
+   - Memory that never reaches a product is likely a graveyard.
+
+## Boundary with current Yoi direction
+
+- Knowledge as a separate record kind is being removed; this paper's reusable representations should map to Memory artifacts, Ticket artifacts, maintained docs, or Skills depending on authority.
+- Workflow tracking is being removed; procedural guidance such as "generate alternatives" or "seek disconfirming evidence" should live in Skills / role prompts and be enforced by typed tools where authority is needed.
+- Workspace backend should eventually be the authority for task-bound shoebox / evidence artifacts when Memory moves from local compatibility storage to control-plane records.

.yoi/objectives/00001KWW44EXK/item.md

@@ -0,0 +1,343 @@
+---
+title: "Runtime working directory materialization and sandboxed agent environments"
+state: "active"
+created_at: "2026-07-06T16:28:12Z"
+updated_at: "2026-07-10T16:50:00Z"
+linked_tickets: ["00001KWPC13WQ", "00001KWMBAA6V", "00001KX6BPY7M", "00001KX6CRVBE"]
+---
+
+## Goal
+
+Runtime が Worker ごとに安全で安価な作業環境を用意できるようにする。Yoi の Runtime は、単に既存ディレクトリで Worker process を起動する launcher ではなく、RepositoryPoint から working directory を materialize し、sandbox / mount / cache / cleanup / evidence を管理する実行基盤になる。
+
+この Objective の中心は、Worker 用 working directory の materialization、Repository cache、working directory allocation、sandboxed agent environment の境界を設計し、将来的に 1 つの Runtime が複数 Workspace / Repository の Worker を抱えられるようにすることである。
+
+初期実装では Git/local repository を主対象にしてよい。ただし設計は Git worktree 固定にしない。Git worktree、bare object cache、sparse checkout、copy-on-write snapshot、reflink copy、APFS clonefile、btrfs snapshot、overlay filesystem、container filesystem、remote object snapshot は、すべて working directory materialization strategy の候補として扱う。
+
+## Motivation / background
+
+現在の Runtime は `--workspace` で与えられた単一 root を Worker の workspace scope として使う。この形では次の問題がある。
+
+- 複数 Worker が同じ repository root を scope として要求すると allocation conflict が起きる。
+- Runtime が single Workspace / Git repository root 専用 process になってしまう。
+- Worker が source repository root を直接触るため、sandbox / cleanup / quota / evidence の境界が曖昧になる。
+- Worker ごとに full clone すると容量と時間のコストが大きすぎる。
+- `.yoi` / Backend fs-store / Workspace descriptor と、Worker 実行用 checkout / scratch / build output の lifecycle が混ざりやすい。
+
+Yoi は Workspace / Repository / Runtime を分ける方針になっている。Backend は Repository registry、RepositorySelector、RepositoryPoint、Ticket/Artifact evidence の authority を持つ。一方 Runtime は RepositoryPoint を受け取り、Worker が使う working directory を用意する責務を持つべきである。
+
+したがって、Repository を持ってくる実体ディレクトリは Backend / Workspace store ではなく Runtime 管理領域に置く。`./.yoi` は local descriptor / compatibility / project record surface であり、Worker ごとの checkout、worktree、snapshot、sandbox root、build cache、dependency cache を置く場所ではない。
+
+参考になる方向性として、Rift のような copy-on-write workspace snapshot / reflink / btrfs snapshot / APFS clonefile による安価な workspace creation がある。ただし Yoi は Rift を Git worktree 代替 CLI として直接前提にするのではなく、Runtime materializer backend の一候補として扱う。
+
+## Glossary
+
+- Runtime root: Runtime が自身の store、cache、Worker metadata、working directory allocation を管理する root。長期的には `~/.yoi/runtimes/<runtime-id>/` 配下など、Workspace backend store とは別に置く。
+- Repository cache: Runtime-local の共有 source/cache。Git なら bare mirror / object cache / packfile cache など。重く、長寿命で、複数 Worker allocation から共有される。
+- working directory: Worker ごとの作業環境。短寿命で、Worker が読み書きする root / mounts / scratch / overlay を含む。Browser-facing UI では `workspace` と混同しないよう `workdir` と表示してよい。`Volume` は storage backing の候補名であり、この作業領域そのものの呼称にはしない。
+- Worker record: 作業単位として保存する record。profile、Runtime、RepositoryPoint / workdir evidence、session/transcript refs、status、diagnostics、summary、pinned flag を束ねる。Session 単体ではなく Worker を保存・削除の単位にする。
+- Materialization strategy: RepositoryPoint から working directory を作る実装戦略。Git detached worktree、sparse checkout、CoW snapshot、reflink copy、overlay、container filesystem など。
+- WorkingDirectoryAllocation: Runtime が払い出した作業環境の record。allocation id、worker id、workspace id、repository point、materializer kind、root、mounts、cleanup policy、status を持つ。
+- Sandbox policy: Worker が見られる filesystem、network、process、secret、tool authority の境界を表す policy。
+- Dirty state policy: local uncommitted changes を Worker environment に含めるかどうかの方針。clean point only、patch artifact apply、snapshot current worktree など。
+
+## Strategy / design direction
+
+### 1. Backend store と Runtime execution storage を分ける
+
+Workspace/backend store は canonical or local descriptor records を扱う。
+
+```text
+Backend / Control plane store
+  - Workspace registry
+  - Repository registry
+  - Ticket / Objective
+  - Artifact metadata / evidence
+  - Actor / Permission / Audit
+  - Runtime registry / observed state
+```
+
+Runtime execution storage は Worker 実行のための materialized filesystem と cache を扱う。
+
+```text
+Runtime root
+  - runtime catalog / runtime-local DB
+  - config bundles
+  - worker metadata / transcript references
+  - repository-cache
+  - working-directories
+  - sandbox state
+  - build/dependency cache
+  - cleanup ledger
+```
+
+この 2 つを混ぜない。特に `.yoi` や workspace config root に Worker ごとの checkout/worktree/sandbox root を置かない。
+
+推奨配置の方向:
+
+```text
+~/.yoi/
+  workspace-server/
+    backend.db
+    workspaces/
+      <workspace-id>/
+        workspace.db
+        artifacts/
+
+  runtimes/
+    <runtime-id>/
+      runtime.db
+      config-bundles/
+      workers/
+        <worker-id>/
+          metadata/
+      repository-cache/
+        git/
+          <repository-cache-key>/
+            bare.git
+      working-directories/
+        <allocation-id>/
+          root/
+          mounts/
+          scratch/
+          materialization.json
+      build-cache/
+      tmp/
+```
+
+### 2. clone ではなく materialize と呼ぶ
+
+Runtime は Repository を毎回 clone するのではない。Runtime は RepositoryPoint を Worker 用の working directory として materialize する。
+
+```text
+RepositoryId + RepositorySelector
+  -> resolved RepositoryPoint
+  -> Runtime repository-cache
+  -> WorkingDirectoryMaterializer
+  -> WorkingDirectoryAllocation
+  -> Worker process
+```
+
+Git の場合でも materialization strategy は複数あり得る。
+
+- shared bare cache + detached Git worktree
+- sparse checkout
+- partial clone / blob filter
+- reflink copy
+- btrfs writable snapshot
+- APFS clonefile
+- overlay filesystem
+- external tool backed snapshot, e.g. Rift-like CoW workspace creation
+
+### 3. Repository cache と Worker working directory を分離する
+
+full clone を Worker ごとに作らない。重い source/object data は Runtime-local repository cache に集約し、Worker ごとの working directory は cheap allocation にする。
+
+Git v0 の方向:
+
+```text
+repository-cache/git/<repo-key>/bare.git
+working-directories/<allocation-id>/root/<repository-id>/
+```
+
+初回:
+
+```text
+git clone --mirror <uri> repository-cache/git/<repo-key>/bare.git
+```
+
+次回以降:
+
+```text
+git -C repository-cache/git/<repo-key>/bare.git fetch --prune
+```
+
+Worker allocation:
+
+```text
+git --git-dir=<bare.git> worktree add --detach <execution-root>/<repository-id> <commit>
+```
+
+Git branch 名を直接 checkout しない。Git worktree は同一 branch を複数 worktree に checkout しづらいため、RepositorySelector を RepositoryPoint に解決し、resolved commit を detached worktree として materialize する。Worker が branch を必要とする場合は Worker/Task ごとの synthetic branch を別途作る。
+
+### 4. Dirty state を明示 policy にする
+
+local dirty changes を暗黙に Worker に見せない。
+
+可能な policy:
+
+- `clean_point_only`: dirty workspace は materialization 拒否。再現性が高く v0 の default 候補。
+- `patch_artifact`: clean RepositoryPoint を materialize し、Backend が保存した dirty diff artifact を apply する。
+- `current_worktree_snapshot`: CoW/reflink/Rift-like snapshot で現在の working tree を snapshot として materialize する。便利だが evidence と cleanup の扱いを明示する必要がある。
+- `direct_legacy_mount`: 既存 root をそのまま渡す。debug/legacy only。通常 Worker creation の default にしない。
+
+Dirty state を含める場合、Artifact/evidence には source RepositoryPoint、patch/snapshot digest、created_at、materializer kind を残す。
+
+### 5. Sandbox を materialization と同じ境界で扱う
+
+working directory は単なる directory path ではなく、Worker が見てよい filesystem view である。Runtime は working directory allocation と同時に sandbox/mount/authority を構築する。
+
+Worker に渡すもの:
+
+- workspace root
+- repository mounts
+- scratch/cache dirs
+- tool authority
+- env vars
+- config bundle
+- secret handles, not raw secrets
+
+Worker が自分で発見してはいけないもの:
+
+- host repository root
+- Backend store path
+- `.yoi` authority-bearing internals
+- raw credentials
+- Runtime socket/store/cache internals
+- sibling Worker working directories
+
+Sandbox v0 は strong isolation でなくてもよい。ただし型と lifecycle は、後で container sandbox、namespace, mount filtering, network policy, secret boundary に拡張できる形にする。
+
+### 6. working directory registry を持つ
+
+Runtime は materialized workspace を filesystem だけでなく registry でも管理する。
+
+必要な record:
+
+```text
+WorkingDirectoryAllocation
+  id
+  runtime_id
+  worker_id
+  workspace_id
+  repository_points[]
+  materializer_kind
+  root
+  mounts[]
+  scratch
+  source_cache_refs[]
+  sandbox_policy
+  dirty_state_policy
+  cleanup_policy
+  status: active | stopped | cleanup_pending | removed | failed
+  created_at
+  stopped_at
+  diagnostics[]
+```
+
+この registry は Runtime root 側に置く。Backend は必要な evidence と summary だけを受け取る。Browser-facing API は raw host paths を原則漏らさない。
+
+### 7. Heavy regenerable artifacts は policy で除外または cache 化する
+
+Worker working directory creation では、`node_modules`, `target`, `.venv`, framework cache, dist, build, coverage などを無条件に full copy しない。
+
+Materialization policy は以下を持てるようにする。
+
+- exclude regenerable artifacts
+- include manifests / lockfiles
+- share dependency cache
+- use build cache
+- path scope / sparse checkout
+- per-repository materialization options
+
+Rift の filtered CoW creation のように、重い artifacts を除外しながら source tree を高速に用意できる strategy を将来取り込めるようにする。
+
+## Initial implementation phases
+
+### Phase 1: Materialization boundary and legacy allocation record
+
+- `CreateWorkerRequest` に working directory request / target placeholder を追加する。
+- `WorkingDirectoryMaterializer` trait を `worker-runtime` に追加する。
+- `WorkerRuntimeExecutionBackend` が Worker spawn 前に materializer を呼ぶ順序にする。
+- v0 materializer は existing local root を explicit allocation として返してよいが、`direct_legacy_mount` として明示し、通常設計の final form と混同しない。
+- Allocation record / cleanup policy / diagnostics の型を先に作る。
+- Worker が source repository root を直接 scope として要求する経路を deprecated/legacy に閉じ込める。
+
+### Phase 2: Runtime root and working directory storage
+
+- `--runtime-root` を導入し、Runtime state / repository-cache / working-directories / worker metadata / worker runtime dirs を Runtime root 配下へ寄せる。
+- `--workspace` は legacy bootstrap input としてだけ扱い、Runtime identity / long-term workspace binding から外す。
+- Runtime root default は user data 配下にする。
+- working directory allocation registry を Runtime root に保存する。
+
+### Phase 3: Git cached detached worktree materializer
+
+- Git repository cache を Runtime root に作る。
+- RepositorySelector を RepositoryPoint に解決する呼び出し境界を作る。
+- resolved commit/tree を evidence として残す。
+- Worker ごとに detached worktree を `working-directories/<allocation-id>/root/<repository-id>` に作る。
+- Worker stop / cleanup 時に `git worktree remove` と registry cleanup を行う。
+- dirty state は v0 では `clean_point_only` を default にし、dirty local workspace は明示 diagnostic で拒否する。
+
+### Phase 4: Path scope / sparse checkout / cache policies
+
+- Ticket target / Worker launch request の path scope を materialization に渡す。
+- Git sparse checkout を materializer strategy として追加する。
+- heavy artifact exclude / dependency cache / build cache policy を導入する。
+
+### Phase 5: CoW / snapshot materializer
+
+- btrfs snapshot、Linux reflink、macOS APFS clonefile、Rift-like snapshot backend を materializer strategy として検討・実装する。
+- `current_worktree_snapshot` policy を evidence と cleanup 付きで扱う。
+- source root と generated workspace の registry / ancestor / cleanup model を設計する。
+
+### Phase 6: Strong sandbox and remote Runtime support
+
+- container filesystem / mount namespace / network policy / secret handle / tool authority を Runtime allocation と統合する。
+- Runtime が複数 Workspace / Repository の Worker を同時に抱える場合の namespace、quota、cleanup、audit boundary を固める。
+- remote/self-hosted/hosted Runtime fleet で repository cache と working directory storage をどう扱うかを設計する。
+
+### 7. Worker / Session / workdir retention and cleanup policy
+
+- Worker を保存・削除単位にする。Session / transcript は Worker に内包または参照される履歴として扱い、Session 単体を長期保存 authority にしない。
+- Worker lifecycle は `running -> stopped -> delete` を基本にする。`archived` を lifecycle state として導入しない。
+- Worker には `pinned` flag を持たせる。Pinned Worker は manual delete / cleanup / future automatic prune から守られる。
+- Worker delete は Worker record と内包する Session / transcript history の削除を意味する。Workdir files は自動削除しない。
+- Session / transcript は削除可能にする。圧縮 archive storage や高度な summarized retention は必要になった時点で別の storage policy として設計する。
+- Workdir 実ファイルは durable history ではなく再現可能 cache として扱う。RepositoryPoint / resolved commit から再現でき、dirty/uncommitted state が無いなら、running Worker に紐づかない workdir files は manual cleanup eligible とする。
+- Dirty Workdir は活動中または要判断状態として扱う。削除は可能だが、changes ごと消す explicit confirmation を要求する。Dirty orphan は recovery Worker 起動または explicit discard の判断対象であり、通常の clean cleanup と区別する。
+- Workdir record は materialization evidence として扱う。実ファイルが削除済みなら `removed`、外部要因で欠落しているなら stale/missing materialization として診断可能にする。
+- Worker と Workdir の関係は Backend registry の link table を authority にする。Worker record は最後に活動した RepositoryPoint / resolved commit / workdir binding summary を保持し、Stopped Worker + Removed Workdir でも必要に応じて再 materialize できるようにする。
+- Cleanup/delete は当面 manual-first にする。削除前に対象、理由、削除される bytes、blocking conditions（running Worker、pinned Worker、dirty state、unreachable commit など）を plan として提示する。
+- 将来的には容量/期限ベースの automatic prune を設定可能にする予定。ただし automatic prune は user-configured policy と pinned protection を前提にし、初期の manual cleanup/delete とは別段階で扱う。
+- UI 表示は `workdir` に寄せる。内部型/API の互換名 `working_directory` は移行中に残ってよいが、Browser-facing navigation では Runtime 管理配下の `Workdirs` として扱う。
+
+## Non-goals
+
+- v0 で完全な container sandbox を実装すること。
+- Worker ごとに full clone すること。
+- `.yoi` や Backend workspace store に Worker working directory を置くこと。
+- Git worktree を唯一の materialization strategy として固定すること。
+- Dirty local changes を暗黙に Worker に渡すこと。
+- Browser-facing API に raw host path、secret、Runtime internal store path を公開すること。
+- Repository credential / secret distribution の本格設計をこの Objective だけで完了させること。
+
+## Success criteria / exit conditions
+
+- Runtime root、Repository cache、working directory、Backend/Workspace store の境界が文書化されている。
+- Runtime が Worker spawn 前に working directory materializer を呼ぶ型と順序を持つ。
+- Worker は source repository root ではなく materialized working directory を scope として起動する。
+- working directory allocation が Runtime registry に記録され、cleanup policy を持つ。
+- Git/local repository の v0 materializer が full clone 連発ではなく shared cache / detached worktree / cheap allocation の方向に進んでいる。
+- dirty state policy が明示され、clean point、patch artifact、snapshot のどれを使ったか evidence に残せる。
+- Runtime process 起動時の `--workspace` は legacy bootstrap input として隔離され、Runtime identity や single workspace binding とみなされない。
+- Worker ごとの scope allocation conflict が、同一 source root を直接渡す設計ではなく materialized workspace allocation によって解消される。
+- Sandbox / mount / cache / secret boundary を後続実装で強化できる model になっている。
+- Worker record が Session / transcript refs と pinned flag を束ね、`pinned` Worker を cleanup/delete/future automatic prune から守れる。
+- Workdir 実ファイルは再現可能 cache として manual cleanup/delete でき、削除前に plan-first で linked Worker、session retention、commit reachability、dirty/missing 状態を確認できる。
+- 将来的に容量/期限ベースの automatic prune を user-configured policy として追加できる設計余地がある。
+
+## References
+
+- [Rift: Worktree alternative for fast copy-on-write workspaces](https://github.com/anomalyco/rift) — CoW snapshot / reflink / btrfs snapshot / APFS clonefile による高速 workspace creation、heavy regenerable artifacts の除外、workspace registry などを Runtime materializer backend 設計の参考にする。
+
+## Decision context
+
+- Runtime は Worker 群を束ねる実行基盤であり、Worker 用の作業環境を用意する責務を持つ。
+- Repository は clone されるものではなく、RepositoryPoint から Worker 用 working directory として materialize される。
+- Runtime execution storage は Backend/Workspace store と分離する。`.yoi` は Worker working directory 置き場ではない。
+- full clone を Worker ごとに作らない。Runtime-local repository cache と Worker-local cheap workspace allocation を分ける。
+- Git detached worktree は v0 materialization strategy として有力だが、Git worktree 固定の設計にはしない。
+- CoW snapshot / reflink / btrfs snapshot / APFS clonefile / Rift-like workspace creation は、将来の materializer backend として検討する。
+- Dirty local state は暗黙に渡さず、policy と evidence を持って扱う。
+- Sandbox は後付けの別機能ではなく、working directory allocation と同じ境界で扱う。

.yoi/profiles.toml

@@ -1 +1,3 @@
 default = "builtin:companion"
+
+[profile]

.yoi/ticket.config.toml

@@ -1,22 +0,0 @@
-[backend]
-provider = "builtin:yoi_local"
-root = ".yoi/tickets"
-
-[ticket]
-language = "Japanese"
-
-[roles.intake]
-profile = "builtin:intake"
-workflow = "ticket-intake-workflow"
-
-[roles.orchestrator]
-profile = "builtin:orchestrator"
-workflow = "ticket-orchestrator-routing"
-
-[roles.coder]
-profile = "builtin:coder"
-workflow = "multi-agent-workflow"
-
-[roles.reviewer]
-profile = "builtin:reviewer"
-workflow = "multi-agent-workflow"

.yoi/tickets/00001KSKBP8Z8/item.md

@@ -1,81 +0,0 @@
----
-title: "半自動開発運用 Workflow"
-state: "closed"
-created_at: "2026-05-27T00:00:01Z"
-updated_at: "2026-06-05T15:56:29Z"
----
-
-## Migration reference
-
-- legacy_ticket: tickets/auto-maintain-workflow.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# 半自動開発運用 Workflow
-
-## 背景
-
-insomnia では insomnia 自身の開発を、ユーザーがタスクを投げ、設計相談をし、実装 Pod / reviewer Pod に分担させる形で進めている。既に Workflow / Skills、SpawnPod、Pod 間通信、scope 委譲、ticket / review lifecycle は揃っており、局所的な実装判断は AI に移譲できる余地が大きい。
-
-一方で、完全な unattended 自動開発にするには、永続ジョブキュー、git 書き込み権限、設計判断のエスカレーション基準など未整理の領域がある。初期段階では、常駐 scheduler ではなく、ユーザーが明示的に起動する「maintainer workflow」として、TODO / tickets を俯瞰し、実装・レビュー・修正依頼を orchestration し、設計境界や完了判断だけを人間に戻す運用を整備する。
-
-## 要件
-
-### Workflow の役割
-
-`/auto-maintain` 相当の Workflow を用意し、親 Pod が以下を実行できるようにする。
-
-- `TODO.md` と `tickets/` から着手候補を把握する
-- 既存方針・既存 ticket から実装方針が十分に導ける作業を選ぶ
-- 要件が曖昧、または設計判断が必要な場合は実装前に人間へ質問する
-- 実装 Pod を spawn し、適切な read / write scope を委譲する
-- 実装 Pod の完了報告と diff / build / test 結果を確認する
-- 必要に応じて reviewer Pod、または親 Pod 自身でレビューする
-- レビュー指摘があれば修正を依頼する
-- 最終的に「完了候補」として人間に報告する
-
-### エスカレーション基準
-
-Workflow は、少なくとも以下の場合に作業を止めて人間へ確認する。
-
-- ticket の要件から複数の設計方針が自然に導け、選択が将来の構造に影響する
-- scope / permission / history 永続化 / prompt context 加工原則など、システムの安全モデルに触れる
-- 新しい ticket の追加、既存 ticket の大幅な要件変更、ticket 完了削除を行う
-- git の commit / merge / push など書き込み操作が必要になる
-- テスト不能、再現不能、または作業範囲外の不具合に遭遇する
-
-### Pod orchestration 規約
-
-- 実装 Pod と reviewer Pod は原則分ける。ただし scope 衝突や作業粒度により、親 Pod がレビューしてもよい。
-- 実装 Pod に worktree write scope を渡す場合、review artifact を親または reviewer が書く前に実装 Pod を停止して scope を回収する。
-- spawn 時は、作業対象 worktree の write scope だけでなく、必要な参照元 ticket / project root の read scope も明示する。
-- 子 Pod の出力は `ReadPodOutput` で確認し、必要なら `SendToPod` で追加依頼する。
-- orphan 化した Pod や不要になった Pod は `StopPod` する。
-
-### 成果物
-
-- Workflow 本文、またはそれに準じる運用手順が workspace から呼び出せる形で追加される
-- Workflow が resident workflow として広告可能かどうかを判断し、必要なら `model_invokation` 設定を含める
-- 実際の insomnia 開発 ticket を 1 件以上試走し、実装 Pod / review / 人間確認の境界が機能することを確認する
-- 試走で見つかった不足（永続ジョブキュー、scope handoff、review artifact の置き場所等）は、本チケット内で解決せず、必要なら別 ticket として切り出す
-
-## 範囲外
-
-- 常駐 scheduler / daemon による unattended 実行
-- git commit / merge / push の自動化
-- ticket 完了削除の自動化
-- Workflow の状態機械化、永続ジョブキュー化、トランザクション管理
-- scope owner handoff など、Pod 権限モデル自体の変更
-
-## 完了条件
-
-- `/auto-maintain` 相当の半自動開発運用 Workflow が利用可能になっている
-- Workflow は TODO / tickets から作業を選び、実装 Pod / reviewer / 人間確認を使い分ける手順を明示している
-- エスカレーション基準により、設計判断・git 書き込み・ticket 完了判断が人間に戻る
-- 少なくとも 1 件の小さな実開発作業で試走し、結果と不足点が記録されている
-- 既存の Workflow / Skill / memory の設計方針、特に Workflow 自動生成禁止と history に commit されない context input 禁止に反していない
-
-## 参照
-
-- `docs/plan/workflow.md`
-- `docs/report/2026-05-05-file-ticket-scope.md`
-- `tickets/internal-worker-workflow.md`

.yoi/tickets/00001KSKBP8Z8/resolution.md

@@ -1,25 +0,0 @@
-The old Auto Maintain workflow is retired and removed.
-
-Resolution:
-
-- Deleted `.yoi/workflow/auto-maintain.md`.
-- Closed this Ticket as superseded by the newer Ticket-based orchestration workflow split:
-  - `ticket-intake-workflow`
-  - `ticket-orchestrator-routing`
-  - `ticket-preflight-workflow`
-  - `multi-agent-workflow`
-- Updated `multi-agent-workflow` to point to Ticket Intake / Orchestrator Routing / Preflight instead of `$user/auto-maintain`.
-- Updated `ticket-intake-workflow` to remove the obsolete auto-maintain connection.
-- Updated `prompt-eval-metrics` so future prompt/workflow evaluation targets the current Ticket workflows or worktree workflow instead of `/auto-maintain`.
-
-Rationale:
-
-`auto-maintain` had become a broad and unstable WIP workflow with old assumptions around TODO/tickets and maintenance loops. Keeping it resident risks encouraging large implicit automation and bypassing the clearer gates now provided by Ticket Intake, Ticket Orchestrator Routing, Ticket Preflight, and Multi-agent Worktree Workflow.
-
-Future maintainer/scheduler/lease behavior should be designed as explicit follow-up work, not revived through the deleted auto-maintain workflow.
-
-Validation:
-
-- `git diff --check`
-- `./tickets.sh doctor`
-- open workflow/docs search no longer finds `auto-maintain` references outside this closed historical Ticket context.

.yoi/tickets/00001KSKBP8Z8/thread.md

@@ -1,40 +0,0 @@
-<!-- event: migration author: tickets.sh-migration at: 2026-05-27T00:00:01Z -->
-
-## Migrated
-
-Migrated from tickets/auto-maintain-workflow.md. No legacy review file was present at migration time.
-
----
-
-<!-- event: close author: hare at: 2026-06-05T15:56:29Z status: closed -->
-
-## Closed
-
-The old Auto Maintain workflow is retired and removed.
-
-Resolution:
-
-- Deleted `.yoi/workflow/auto-maintain.md`.
-- Closed this Ticket as superseded by the newer Ticket-based orchestration workflow split:
-  - `ticket-intake-workflow`
-  - `ticket-orchestrator-routing`
-  - `ticket-preflight-workflow`
-  - `multi-agent-workflow`
-- Updated `multi-agent-workflow` to point to Ticket Intake / Orchestrator Routing / Preflight instead of `$user/auto-maintain`.
-- Updated `ticket-intake-workflow` to remove the obsolete auto-maintain connection.
-- Updated `prompt-eval-metrics` so future prompt/workflow evaluation targets the current Ticket workflows or worktree workflow instead of `/auto-maintain`.
-
-Rationale:
-
-`auto-maintain` had become a broad and unstable WIP workflow with old assumptions around TODO/tickets and maintenance loops. Keeping it resident risks encouraging large implicit automation and bypassing the clearer gates now provided by Ticket Intake, Ticket Orchestrator Routing, Ticket Preflight, and Multi-agent Worktree Workflow.
-
-Future maintainer/scheduler/lease behavior should be designed as explicit follow-up work, not revived through the deleted auto-maintain workflow.
-
-Validation:
-
-- `git diff --check`
-- `./tickets.sh doctor`
-- open workflow/docs search no longer finds `auto-maintain` references outside this closed historical Ticket context.
-
-
----

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

@@ -1 +0,0 @@
-{"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

@@ -1,21 +0,0 @@
-{
-  "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

@@ -1,27 +0,0 @@
-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

@@ -1,25 +0,0 @@
-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,100 +0,0 @@
----
-title: "E2E テストハーネス"
-state: 'closed'
-created_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
-
-- legacy_ticket: tickets/e2e-harness.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# E2E テストハーネス
-
-## 背景
-
-`CLAUDE.md:6` で明記している通り、現状「実プロセスをスポーンさせての E2E」は未設計である。crate 内 integration test は 121 ファイル / 969 ケースまで揃っているが、以下の領域は in-process では再現できず、複数チケットの完了条件が宙に浮いている。
-
-- `pod-cli-manifest-flags`: `--manifest` / `INSOMNIA_USER_MANIFEST` / 併用 conflict など実 CLI 挙動
-- `pod-persistent-state`: Pod プロセス**再起動後**の active session 復元、spawner 再起動後の `ListPods` 復元
-- `pod-session-fork`: `pod_cli` から fork → 新 session で run まで通せる
-- `pod-parent-turn-callback`: 実子 Pod を spawn した状態の親 history 反映
-- `pod-empty-turn-rollback`: 「TUI / pod_cli いずれの経路でも」明記
-- `permission-extension-point.review.md:21`: `[permissions]` を含む Pod 構築 → tool deny までの結合検証
-- `llm-worker-stream-continuation`: SSE 途中切断 + 継続/中断と課金重複が無いことの確認
-- `native-gui-mvp`: GUI から `pod` subprocess を起動 → socket 接続 → graceful shutdown
-
-`crates/pod/tests/spawn_pod_test.rs` のように subprocess を `/bin/true` ですり替える擬似手法は既にあるが、これは「子 Pod が即終了する状況下での registry 書き込み」を見るためのもので、実 pod を立ち上げての protocol 往復はしていない。
-
-## 方針
-
-- ワークスペース直下 **`tests/e2e/`** に E2E 専用の crate を切る。E2E は単一の crate / バイナリの責務ではないため、既存 `crates/<x>/tests/` には置かない。
-- 実 `pod` バイナリは `env!("CARGO_BIN_EXE_pod")` で取得。ファイルシステムは tmpdir に閉じ、`INSOMNIA_RUNTIME_DIR` / data dir / `INSOMNIA_USER_MANIFEST` 等を env で完全 sandbox 化する。
-- protocol を喋る側は **`tickets/client-crate.md` で切り出す `client` crate** を直接利用する。TUI バイナリを PTY で叩く方針は採らない（GUI MVP との整合と E2E 安定性の観点から）。
-- CI 既定実行から外す。`--features e2e` か独立ジョブで opt-in。ローカルでは `cargo test -p e2e --features e2e` 相当で叩ける形にする。
-
-## 詰めたい論点（実装前に決める）
-
-### 1. LLM provider のスタブ手段が fixture HTTP 再生だけで充足するか
-
-既存 `crates/llm-worker/tests/anthropic_fixtures.rs` 等は in-process loader として書かれており、HTTP サーバーとして再生する形にはなっていない。E2E では Pod プロセスが env で渡された URL に対して実 HTTP を叩く以上、**最低限「fixture を返す HTTP サーバー」** は必要。
-
-ただし、それだけで充足するかは不明:
-
-- **動的応答が要るシナリオ**: SSE を途中で能動的に切る (`llm-worker-stream-continuation`)、tool 呼び出しの結果に応じて分岐する応答、複数ターンに渡る会話の途中で挙動を変える、など。録画再生だけでは作りにくい。
-- **provider 差**: Anthropic / OpenAI Responses / Gemini / Ollama / Codex OAuth で endpoint / 認証 / スキーマが違う。E2E で全 provider を回す必要は無いが、最低 1〜2 provider はハーネスを持たせるべきで、選定が要る。
-- **OAuth 系**: Codex OAuth はトークン取得経路自体が外部依存。E2E では事前注入された token を読む形に倒すか、OAuth flow ごと canned server で模すか。
-
-このチケットでは「fixture HTTP 再生」を出発点としつつ、**動的応答のための最小 canned server インターフェース**（テストケース側からハンドラを差し替えられる形）も同時に検討範囲に含める。両方が無いと上のシナリオが書けない。
-
-### 2. provider URL の差し替え経路
-
-各 provider の base URL を env で上書きできる前提が、現コードに揃っているか確認・整備する必要がある。揃っていなければ別チケットに切り出すか、本チケット内で minimal に対応するか決める。
-
-### 3. fixture 形式
-
-既存の in-process fixture (`tests/*_fixtures.rs`) と HTTP 再生用 fixture を同じソースから作るか、別管理にするか。共通化できるなら record/replay 経路を整備する。
-
-### 4. 並列実行と env 干渉
-
-`spawn_pod_test.rs` は env mutex で直列化している。E2E でも env (`INSOMNIA_*`)・runtime dir・socket path に依存する以上、テスト並列度の方針を決める（`--test-threads=1`、test-per-process、または env を引数にハンドオフして mutex 不要にする）。
-
-### 5. 失敗時の診断
-
-実プロセスが絡むためスタックトレースだけでは原因特定しにくい。pod の stderr / stdout、session log、runtime dir の中身をテスト失敗時に dump する仕組みを最初に入れておく。
-
-## 要件
-
-- `tests/e2e/` 以下に E2E 用 crate（仮称 `e2e`）が存在し、`Cargo.toml` の `[features] e2e = []` で gate されている。
-- `cargo test -p e2e --features e2e` で実 `pod` バイナリを spawn し、protocol 経由で 1 シナリオ（最小: spawn → 1 turn 実行 → graceful shutdown）が通る。
-- LLM provider のスタブが少なくとも 1 provider 分動き、上の最小シナリオが本物の HTTP 越しに完結する。
-- env / tmpdir / socket path が tmpdir 内に閉じ、テスト間の干渉が無い。
-- テスト失敗時に pod プロセスの stderr / 関連ファイルが artefact として確認できる。
-- CI 既定パス (`cargo test --workspace`) では E2E が走らない。opt-in jobs でだけ走る。
-- 上の論点 1〜5 が文書化されている（チケット内 or `docs/` 配下のいずれか）。
-
-## 完了条件
-
-- 上記要件を満たすハーネスが入り、最小シナリオ 1 本が通る。
-- 後続シナリオ（permission deny / cli-manifest-flags / spawn 親子 / resume / fork / stream-continuation）を**書く側の手順書**が提示されている（fixture 追加方法、シナリオ crate の追加方法、env のお作法）。
-- 個別シナリオの実装は本チケットに含めない。後続チケットで切る。
-
-## 範囲外
-
-- 個別 E2E シナリオの実装（permission deny / cli flags / spawn / resume / fork / stream-continuation）。それぞれ後続チケット。
-- 全 provider 分の HTTP スタブ（最初は 1 provider に絞る）。
-- TUI バイナリを PTY で操作する経路。
-- GUI バイナリの E2E（`tickets/native-gui-mvp.md` 完了後に別途）。
-- E2E を CI 既定で走らせる切替。
-
-## 依存 / 関連
-
-- `tickets/client-crate.md`（protocol を喋る client crate を切り出す。E2E はここに依存して書く）
-- `tickets/llm-worker-stream-continuation.md`（動的応答 canned server を必要とする最初のシナリオ）
-- `tickets/permission-extension-point.review.md`（最初に書きたいシナリオ）
-- `crates/pod/tests/spawn_pod_test.rs`（env mutex 等の流儀を流用）
-- `crates/llm-worker/tests/*_fixtures.rs`（fixture 資産の出発点）
-- `CLAUDE.md:6`（E2E 未設計の宣言）

.yoi/tickets/00001KSKBP9YG/resolution.md

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

.yoi/tickets/00001KSKBP9YG/thread.md

@@ -1,550 +0,0 @@
-<!-- event: migration author: tickets.sh-migration at: 2026-05-27T00:00:02Z -->
-
-## Migrated
-
-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,85 +0,0 @@
----
-title: "内部 Worker / 内部 Pod の Workflow 化"
-state: 'closed'
-created_at: "2026-05-27T00:00:03Z"
-updated_at: '2026-06-13T09:56:34Z'
----
-
-## Migration reference
-
-- legacy_ticket: tickets/internal-worker-workflow.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# 内部 Worker / 内部 Pod の Workflow 化
-
-## 背景
-
-INSOMNIA が内部で固定 prompt を持って disposable Worker / 専用 Pod を立ち上げている経路がいくつかある:
-
-- extract 活動抽出（`crates/memory/src/extract/prompt.rs::EXTRACT_SYSTEM_PROMPT`）
-- consolidation 統合 + 整理（`tickets/memory-consolidation.md`、本チケット時点では実装中 / 直前）
-- Compact（`PromptCatalog::compact_system`）
-
-これらは実装内 `&str` 定数や `PromptCatalog` の overlay で管理されており、prompt の調整や運用カスタマイズが「コード変更 + 再ビルド」を要する。一方、ユーザー向け `/<slug>` Workflow（`tickets/workflow.md`）は `<workspace_root>/.insomnia/workflow/<slug>.md` に住み、frontmatter + Markdown 本文 + `requires` Knowledge inject を持つ宣言形式で運用できる。
-
-両者を寄せ、内部 Worker / 内部 Pod の prompt + ツール surface + Knowledge 依存を **Workflow と同一仕様で記述** できる経路を用意する。これにより:
-
-- 内部 prompt の運用調整が workspace 側でできる（コード変更不要）
-- consolidation の prompt 案 (`docs/plan/memory-prompts.md`) を workspace に直接 ingest できる
-- 将来 consolidation を独立 Pod に引き上げる際も、Workflow を submit する形に揃えられる
-
-## 要件
-
-### Workflow の役割拡張
-
-`tickets/workflow.md` の Workflow 仕様は「ユーザーが `/<slug>` で submit する制約付き作業」だが、本チケットでは **内部トリガー（Pod 内部の状態遷移）から呼び出される Workflow** を一級扱いに広げる。
-
-- 同じファイル形式（`.insomnia/workflow/<slug>.md`）、同じ frontmatter / Linter
-- `user_invocable: false` で `/<slug>` 経路から見えなくする
-- `model_invokation` は通常 Pod 用の system prompt 注入仕様のまま（内部 Workflow は通常 OFF）
-- 内部 Workflow を識別するキー（例: `internal_role`）と、必要なツール surface を表明する手段を frontmatter に追加する。具体 schema は実装で詰める
-
-### 内部呼び出し経路
-
-Pod 側の既存トリガー（extract post-run / consolidation staging 閾値 / Compact 閾値 等）は固定 `&str` の代わりに Workflow loader 経由で:
-
-1. 内部識別キーで該当 Workflow を解決（衝突時は workspace 上書き優先、なければ insomnia bundled default）
-2. `requires` Knowledge を本文の前に inject
-3. Workflow 本文を sub-Worker / sub-Pod の prompt として渡す（system prompt 扱いか初回 submit 扱いかは内部用途で固定し、role ごとに揃える）
-4. 既存のツール登録ロジックは Workflow が表明したツール surface に従う
-
-### Bundled defaults
-
-ユーザー workspace に該当 Workflow が無い場合に備え、insomnia 同梱の default Workflow を読む層を `PromptCatalog` の overlay と整合する形で持つ。
-
-- 既存の Pod prompt 4 層 overlay（builtin / user / workspace / pod-pack）と同じ優先順
-- bundled default の物理配置は実装で決める
-
-### 関連チケットとの順序
-
-- `tickets/workflow.md`（ユーザー向け Workflow 本体）が先行する。本チケットはその仕様を前提に「内部呼び出し経路」を追加する側
-- `tickets/memory-consolidation.md` は当面 `&str` 定数で実装してよい。本チケット完了時に Workflow 化に乗り換える
-- extract / Compact も同様に role ごとに段階移行
-
-## 範囲外
-
-- Workflow 仕様自体の本体実装（`tickets/workflow.md`）
-- 内部 Workflow の自動生成（consolidation の offer 等。`docs/plan/memory.md` §Offer 経路 / 将来検討）
-- 既存 `&str` 定数の物理削除タイミング（移行が完了した role ごとに削除する運用）
-- `model_invokation` 注入予算の最適化（既存 Knowledge 常駐注入予算と合算する規約は `docs/plan/memory.md` 側）
-
-## 完了条件
-
-- 各内部 Worker / 内部 Pod（少なくとも extract / consolidation / Compact のうち、本チケット着手時点で実装済みのもの）が内部識別キー付き Workflow を解決して prompt とツール surface を組み立てる
-- workspace で `.insomnia/workflow/<slug>.md` を上書きすれば内部 Worker の prompt が変わる
-- workspace に該当 Workflow が無い場合、bundled default が使われる
-- `user_invocable: false` の内部 Workflow は `/<slug>` 候補から除外され、ユーザーからは呼べない
-- 内部 Workflow も consolidation の自動書き込み禁止対象のまま（Linter で構造的担保、`workflow.md` と整合）
-- 単体テストで bundled default / workspace overlay / ツール surface 表明 + 解決 + 適用がカバーされる
-
-## 参照
-
-- 前提: `tickets/workflow.md`
-- 最初の利用者: `tickets/memory-consolidation.md`
-- 関連: `tickets/agent-skills.md`（外部 SKILL ingest 経路。本チケットの内部呼び出し経路とは別軸）
-- 設計: `docs/plan/workflow.md`、`docs/plan/memory.md`、`docs/plan/memory-prompts.md`

.yoi/tickets/00001KSKBPAXR/resolution.md

@@ -1,11 +0,0 @@
-## 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

@@ -1,85 +0,0 @@
-<!-- event: migration author: tickets.sh-migration at: 2026-05-27T00:00:03Z -->
-
-## Migrated
-
-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/00001KSKBPBX0/item.md

@@ -1,148 +0,0 @@
----
-title: "Pod/TUI: 手動 rewind 導線"
-state: "closed"
-created_at: "2026-05-27T00:00:04Z"
-updated_at: "2026-05-29T03:09:22Z"
----
-
-## Background
-
-`pod-empty-turn-rollback` / `tui-empty-turn-restore` により、AI 側出力が 0 の interrupted turn については Pod 側で自動 rollback し、TUI 側で入力を復元できるようになった。
-
-次に欲しいのは、直前 turn だけの rollback command ではなく、TUI から過去の user message を選び、その地点まで会話を戻してその入力を composer に復元する **manual rewind** 導線である。
-
-誤送信、モデル選択ミス、途中で方針を変えた場合などに、ユーザーは過去の入力を選び直し、必要なら編集してから Enter で retry できる。選択した瞬間に再実行はしない。
-
-## UX
-
-- `:rewind` command を追加する。
-- `:rollback` は `:rewind` の alias として扱ってよい。
-- `Ctrl+R` は rewind/rollback を表す shortcut として、同じ picker を開く。
-- `:rewind` / `Ctrl+R` は引数を取らず、TUI 内の picker を開く。
-- Rewind picker は popup/overlay ではなく、通常の conversation/history view area を一時的に置き換える dedicated view として表示する。
-  - composer/input area と actionbar/status area は通常通り残す。
-  - main view area だけが message history から rewind target list に切り替わる。
-  - Esc 等で picker を閉じると、通常の conversation/history view に戻る。
-- `:rewind` command は `Idle` / `Paused` の時だけ picker を開く。`Running` 中は visible diagnostic を出して何もしない。
-- `Ctrl+R` shortcut も Pod が停止中 (`Idle` または `Paused`) の時だけ有効にする。`Running` 中は無視または visible diagnostic にする。
-- picker は過去の user message を新しい順に表示する。
-  - turn number / index
-  - timestamp または relative time
-  - message preview
-  - eligible / disabled reason
-- picker で user message を選択すると、Pod はその user message の直前まで history/session log を rewind し、選択された message を TUI composer に復元する。
-- 選択後は、composer に該当 message が入っている状態になる。
-  - Enter を押すとその message で retry できる。
-  - ユーザーは送信前に編集できる。
-  - 選択しただけで自動実行しない。
-- Esc 等で picker を閉じると何も変更しない。
-
-## Semantics
-
-Manual rewind は destructive operation として扱う。選択地点より後の履歴 suffix は捨てる。fork は優先度低めの別機能であり、この ticket の実装では fork を作らない。
-
-- Rewind は current active segment/session に対して行う。
-- Rewind 成功時、選択された `UserInput` entry 自体も履歴から取り除かれ、composer に戻る。
-- Rewind 後、選択地点より後の assistant output / later user messages / usage entries / display blocks は現 branch から消える。
-- 元 suffix を保持したい場合は将来の `pod-session-fork` で扱う。この ticket では保持しない。
-- Tool side effect の undo はしない。
-
-Initial safety policy:
-
-- Pod が `Idle` または `Paused` の時だけ許可する。
-- `Running` 中は拒否する。
-- picker 表示時から head が変わった場合は apply 時に再検証して拒否する。
-- segment rotation / compaction を跨ぐ rewind は初期実装では対象外でよい。
-- suffix に tool call / tool result / other side-effect-looking entries が含まれる場合でも、初期方針としては destructive rewind を許可してよい。ただし UI には「以降の履歴は破棄され、tool side effects は undo されない」ことが分かる notice/diagnostic を出す。
-- 実装上どうしても安全に整合性を保てない suffix 種別がある場合は、具体的な disabled reason を表示して拒否する。
-
-## Protocol / ownership
-
-TUI がローカルに履歴を削るのではなく、Pod が authoritative に rewind を検証・適用する。
-
-Suggested protocol shape:
-
-```rust
-Method::ListRewindTargets { limit: Option<usize> }
-Method::RewindTo {
-    target: RewindTargetId,
-    expected_head_entries: usize,
-}
-
-Event::RewindTargets { targets: Vec<RewindTarget> }
-Event::RewindApplied {
-    entries: Vec<serde_json::Value>,
-    input: Vec<Segment>,
-    summary: RewindSummary,
-}
-```
-
-Exact names may differ, but the behavior should stay:
-
-- listing targets and applying a target are separate operations.
-- apply revalidates target identity and current head.
-- success returns enough entries for clients to reseed their view.
-- success returns the selected user input segments so TUI can restore the composer.
-- failure uses visible diagnostics, e.g. `Event::Error { code: InvalidRequest, message }`.
-
-`RunResult::RolledBack` should not be reused for this idle control operation. It remains the run-lifecycle signal for submit-time empty-turn rollback.
-
-## Implementation notes
-
-- Target identity can initially be current segment + entry index:
-
-```rust
-RewindTargetId {
-    segment_id: SegmentId,
-    user_input_entry_index: usize,
-}
-```
-
-- Include `expected_head_entries` to reject stale picker selections.
-- Each target should include:
-  - preview
-  - original `Vec<Segment>`
-  - turn/index metadata if available
-  - whether the target is eligible
-  - disabled/warning reason if relevant
-  - the entry count to truncate to, which is before the selected user message.
-- Rewind apply must keep these in sync:
-  - worker history
-  - `user_segments`
-  - session store segment log
-  - `SegmentLogSink` mirror
-  - usage history / trackers
-  - TUI view reconstructed from returned entries
-- If a complete current-state reconstruction from log is simpler and safer than maintaining many historical snapshots, prefer that over fragile partial truncation.
-
-## Acceptance criteria
-
-- `:rewind` opens a picker of past user messages by replacing the normal conversation/history view area, not by drawing a small popup.
-- `Ctrl+R` opens the same picker only while Pod status is `Idle` or `Paused`; it is disabled/rejected while `Running`.
-- Selecting a message rewinds the Pod state to before that message and restores the message into the TUI composer.
-- Rewind does not auto-run; pressing Enter after selection retries the restored message.
-- Rewind success updates Pod session log, SegmentLogSink mirror, worker state, and TUI display consistently.
-- Esc returns from the rewind picker to the normal conversation/history view without changing Pod state.
-- Rewind failure leaves state unchanged and shows a clear reason.
-- Picker selections are revalidated at apply time to avoid stale-head corruption.
-- Rewound suffix is intentionally discarded; no fork is created.
-- Tool side effects are not undone; UI/diagnostics make this clear when relevant.
-- Tests cover target listing, apply success, stale-head rejection, composer restore, TUI display reseed, and at least one suffix-with-tool case.
-- `cargo fmt --check`
-- `cargo check -p protocol -p pod -p tui`
-- Relevant focused tests.
-
-## Out of scope
-
-- Creating a fork when rewinding.
-- Fork tree visualization.
-- Merging branches.
-- Undoing tool side effects.
-- Rollback history stack / redo.
-- Rewind across compacted segments unless it falls out naturally from implementation.
-
-## Related
-
-- `20260527-000009-pod-session-fork` remains a lower-priority future feature for preserving alternate histories.
-- Completed: `pod-empty-turn-rollback`
-- Completed: `tui-empty-turn-restore`

.yoi/tickets/00001KSKBPBX0/resolution.md

@@ -1,155 +0,0 @@
----
-id: 20260527-000004-manual-turn-rollback
-slug: manual-turn-rollback
-title: Pod/TUI: 手動 rewind 導線
-status: closed
-kind: task
-priority: P2
-labels: [tui, pod, ux]
-created_at: 2026-05-27T00:00:04Z
-updated_at: 2026-05-29T03:09:22Z
-assignee: null
-legacy_ticket: tickets/manual-turn-rollback.md
----
-
-## Background
-
-`pod-empty-turn-rollback` / `tui-empty-turn-restore` により、AI 側出力が 0 の interrupted turn については Pod 側で自動 rollback し、TUI 側で入力を復元できるようになった。
-
-次に欲しいのは、直前 turn だけの rollback command ではなく、TUI から過去の user message を選び、その地点まで会話を戻してその入力を composer に復元する **manual rewind** 導線である。
-
-誤送信、モデル選択ミス、途中で方針を変えた場合などに、ユーザーは過去の入力を選び直し、必要なら編集してから Enter で retry できる。選択した瞬間に再実行はしない。
-
-## UX
-
-- `:rewind` command を追加する。
-- `:rollback` は `:rewind` の alias として扱ってよい。
-- `Ctrl+R` は rewind/rollback を表す shortcut として、同じ picker を開く。
-- `:rewind` / `Ctrl+R` は引数を取らず、TUI 内の picker を開く。
-- Rewind picker は popup/overlay ではなく、通常の conversation/history view area を一時的に置き換える dedicated view として表示する。
-  - composer/input area と actionbar/status area は通常通り残す。
-  - main view area だけが message history から rewind target list に切り替わる。
-  - Esc 等で picker を閉じると、通常の conversation/history view に戻る。
-- `:rewind` command は `Idle` / `Paused` の時だけ picker を開く。`Running` 中は visible diagnostic を出して何もしない。
-- `Ctrl+R` shortcut も Pod が停止中 (`Idle` または `Paused`) の時だけ有効にする。`Running` 中は無視または visible diagnostic にする。
-- picker は過去の user message を新しい順に表示する。
-  - turn number / index
-  - timestamp または relative time
-  - message preview
-  - eligible / disabled reason
-- picker で user message を選択すると、Pod はその user message の直前まで history/session log を rewind し、選択された message を TUI composer に復元する。
-- 選択後は、composer に該当 message が入っている状態になる。
-  - Enter を押すとその message で retry できる。
-  - ユーザーは送信前に編集できる。
-  - 選択しただけで自動実行しない。
-- Esc 等で picker を閉じると何も変更しない。
-
-## Semantics
-
-Manual rewind は destructive operation として扱う。選択地点より後の履歴 suffix は捨てる。fork は優先度低めの別機能であり、この ticket の実装では fork を作らない。
-
-- Rewind は current active segment/session に対して行う。
-- Rewind 成功時、選択された `UserInput` entry 自体も履歴から取り除かれ、composer に戻る。
-- Rewind 後、選択地点より後の assistant output / later user messages / usage entries / display blocks は現 branch から消える。
-- 元 suffix を保持したい場合は将来の `pod-session-fork` で扱う。この ticket では保持しない。
-- Tool side effect の undo はしない。
-
-Initial safety policy:
-
-- Pod が `Idle` または `Paused` の時だけ許可する。
-- `Running` 中は拒否する。
-- picker 表示時から head が変わった場合は apply 時に再検証して拒否する。
-- segment rotation / compaction を跨ぐ rewind は初期実装では対象外でよい。
-- suffix に tool call / tool result / other side-effect-looking entries が含まれる場合でも、初期方針としては destructive rewind を許可してよい。ただし UI には「以降の履歴は破棄され、tool side effects は undo されない」ことが分かる notice/diagnostic を出す。
-- 実装上どうしても安全に整合性を保てない suffix 種別がある場合は、具体的な disabled reason を表示して拒否する。
-
-## Protocol / ownership
-
-TUI がローカルに履歴を削るのではなく、Pod が authoritative に rewind を検証・適用する。
-
-Suggested protocol shape:
-
-```rust
-Method::ListRewindTargets { limit: Option<usize> }
-Method::RewindTo {
-    target: RewindTargetId,
-    expected_head_entries: usize,
-}
-
-Event::RewindTargets { targets: Vec<RewindTarget> }
-Event::RewindApplied {
-    entries: Vec<serde_json::Value>,
-    input: Vec<Segment>,
-    summary: RewindSummary,
-}
-```
-
-Exact names may differ, but the behavior should stay:
-
-- listing targets and applying a target are separate operations.
-- apply revalidates target identity and current head.
-- success returns enough entries for clients to reseed their view.
-- success returns the selected user input segments so TUI can restore the composer.
-- failure uses visible diagnostics, e.g. `Event::Error { code: InvalidRequest, message }`.
-
-`RunResult::RolledBack` should not be reused for this idle control operation. It remains the run-lifecycle signal for submit-time empty-turn rollback.
-
-## Implementation notes
-
-- Target identity can initially be current segment + entry index:
-
-```rust
-RewindTargetId {
-    segment_id: SegmentId,
-    user_input_entry_index: usize,
-}
-```
-
-- Include `expected_head_entries` to reject stale picker selections.
-- Each target should include:
-  - preview
-  - original `Vec<Segment>`
-  - turn/index metadata if available
-  - whether the target is eligible
-  - disabled/warning reason if relevant
-  - the entry count to truncate to, which is before the selected user message.
-- Rewind apply must keep these in sync:
-  - worker history
-  - `user_segments`
-  - session store segment log
-  - `SegmentLogSink` mirror
-  - usage history / trackers
-  - TUI view reconstructed from returned entries
-- If a complete current-state reconstruction from log is simpler and safer than maintaining many historical snapshots, prefer that over fragile partial truncation.
-
-## Acceptance criteria
-
-- `:rewind` opens a picker of past user messages by replacing the normal conversation/history view area, not by drawing a small popup.
-- `Ctrl+R` opens the same picker only while Pod status is `Idle` or `Paused`; it is disabled/rejected while `Running`.
-- Selecting a message rewinds the Pod state to before that message and restores the message into the TUI composer.
-- Rewind does not auto-run; pressing Enter after selection retries the restored message.
-- Rewind success updates Pod session log, SegmentLogSink mirror, worker state, and TUI display consistently.
-- Esc returns from the rewind picker to the normal conversation/history view without changing Pod state.
-- Rewind failure leaves state unchanged and shows a clear reason.
-- Picker selections are revalidated at apply time to avoid stale-head corruption.
-- Rewound suffix is intentionally discarded; no fork is created.
-- Tool side effects are not undone; UI/diagnostics make this clear when relevant.
-- Tests cover target listing, apply success, stale-head rejection, composer restore, TUI display reseed, and at least one suffix-with-tool case.
-- `cargo fmt --check`
-- `cargo check -p protocol -p pod -p tui`
-- Relevant focused tests.
-
-## Out of scope
-
-- Creating a fork when rewinding.
-- Fork tree visualization.
-- Merging branches.
-- Undoing tool side effects.
-- Rollback history stack / redo.
-- Rewind across compacted segments unless it falls out naturally from implementation.
-
-## Related
-
-- `20260527-000009-pod-session-fork` remains a lower-priority future feature for preserving alternate histories.
-- Completed: `pod-empty-turn-rollback`
-- Completed: `tui-empty-turn-restore`

.yoi/tickets/00001KSKBPBX0/thread.md

@@ -1,170 +0,0 @@
-<!-- event: migration author: tickets.sh-migration at: 2026-05-27T00:00:04Z -->
-
-## Migrated
-
-Migrated from tickets/manual-turn-rollback.md. No legacy review file was present at migration time.
-
----
-
-<!-- event: close author: hare at: 2026-05-29T03:09:22Z status: closed -->
-
-## Closed
-
----
-id: 20260527-000004-manual-turn-rollback
-slug: manual-turn-rollback
-title: Pod/TUI: 手動 rewind 導線
-status: closed
-kind: task
-priority: P2
-labels: [tui, pod, ux]
-created_at: 2026-05-27T00:00:04Z
-updated_at: 2026-05-29T03:09:22Z
-assignee: null
-legacy_ticket: tickets/manual-turn-rollback.md
----
-
-## Background
-
-`pod-empty-turn-rollback` / `tui-empty-turn-restore` により、AI 側出力が 0 の interrupted turn については Pod 側で自動 rollback し、TUI 側で入力を復元できるようになった。
-
-次に欲しいのは、直前 turn だけの rollback command ではなく、TUI から過去の user message を選び、その地点まで会話を戻してその入力を composer に復元する **manual rewind** 導線である。
-
-誤送信、モデル選択ミス、途中で方針を変えた場合などに、ユーザーは過去の入力を選び直し、必要なら編集してから Enter で retry できる。選択した瞬間に再実行はしない。
-
-## UX
-
-- `:rewind` command を追加する。
-- `:rollback` は `:rewind` の alias として扱ってよい。
-- `Ctrl+R` は rewind/rollback を表す shortcut として、同じ picker を開く。
-- `:rewind` / `Ctrl+R` は引数を取らず、TUI 内の picker を開く。
-- Rewind picker は popup/overlay ではなく、通常の conversation/history view area を一時的に置き換える dedicated view として表示する。
-  - composer/input area と actionbar/status area は通常通り残す。
-  - main view area だけが message history から rewind target list に切り替わる。
-  - Esc 等で picker を閉じると、通常の conversation/history view に戻る。
-- `:rewind` command は `Idle` / `Paused` の時だけ picker を開く。`Running` 中は visible diagnostic を出して何もしない。
-- `Ctrl+R` shortcut も Pod が停止中 (`Idle` または `Paused`) の時だけ有効にする。`Running` 中は無視または visible diagnostic にする。
-- picker は過去の user message を新しい順に表示する。
-  - turn number / index
-  - timestamp または relative time
-  - message preview
-  - eligible / disabled reason
-- picker で user message を選択すると、Pod はその user message の直前まで history/session log を rewind し、選択された message を TUI composer に復元する。
-- 選択後は、composer に該当 message が入っている状態になる。
-  - Enter を押すとその message で retry できる。
-  - ユーザーは送信前に編集できる。
-  - 選択しただけで自動実行しない。
-- Esc 等で picker を閉じると何も変更しない。
-
-## Semantics
-
-Manual rewind は destructive operation として扱う。選択地点より後の履歴 suffix は捨てる。fork は優先度低めの別機能であり、この ticket の実装では fork を作らない。
-
-- Rewind は current active segment/session に対して行う。
-- Rewind 成功時、選択された `UserInput` entry 自体も履歴から取り除かれ、composer に戻る。
-- Rewind 後、選択地点より後の assistant output / later user messages / usage entries / display blocks は現 branch から消える。
-- 元 suffix を保持したい場合は将来の `pod-session-fork` で扱う。この ticket では保持しない。
-- Tool side effect の undo はしない。
-
-Initial safety policy:
-
-- Pod が `Idle` または `Paused` の時だけ許可する。
-- `Running` 中は拒否する。
-- picker 表示時から head が変わった場合は apply 時に再検証して拒否する。
-- segment rotation / compaction を跨ぐ rewind は初期実装では対象外でよい。
-- suffix に tool call / tool result / other side-effect-looking entries が含まれる場合でも、初期方針としては destructive rewind を許可してよい。ただし UI には「以降の履歴は破棄され、tool side effects は undo されない」ことが分かる notice/diagnostic を出す。
-- 実装上どうしても安全に整合性を保てない suffix 種別がある場合は、具体的な disabled reason を表示して拒否する。
-
-## Protocol / ownership
-
-TUI がローカルに履歴を削るのではなく、Pod が authoritative に rewind を検証・適用する。
-
-Suggested protocol shape:
-
-```rust
-Method::ListRewindTargets { limit: Option<usize> }
-Method::RewindTo {
-    target: RewindTargetId,
-    expected_head_entries: usize,
-}
-
-Event::RewindTargets { targets: Vec<RewindTarget> }
-Event::RewindApplied {
-    entries: Vec<serde_json::Value>,
-    input: Vec<Segment>,
-    summary: RewindSummary,
-}
-```
-
-Exact names may differ, but the behavior should stay:
-
-- listing targets and applying a target are separate operations.
-- apply revalidates target identity and current head.
-- success returns enough entries for clients to reseed their view.
-- success returns the selected user input segments so TUI can restore the composer.
-- failure uses visible diagnostics, e.g. `Event::Error { code: InvalidRequest, message }`.
-
-`RunResult::RolledBack` should not be reused for this idle control operation. It remains the run-lifecycle signal for submit-time empty-turn rollback.
-
-## Implementation notes
-
-- Target identity can initially be current segment + entry index:
-
-```rust
-RewindTargetId {
-    segment_id: SegmentId,
-    user_input_entry_index: usize,
-}
-```
-
-- Include `expected_head_entries` to reject stale picker selections.
-- Each target should include:
-  - preview
-  - original `Vec<Segment>`
-  - turn/index metadata if available
-  - whether the target is eligible
-  - disabled/warning reason if relevant
-  - the entry count to truncate to, which is before the selected user message.
-- Rewind apply must keep these in sync:
-  - worker history
-  - `user_segments`
-  - session store segment log
-  - `SegmentLogSink` mirror
-  - usage history / trackers
-  - TUI view reconstructed from returned entries
-- If a complete current-state reconstruction from log is simpler and safer than maintaining many historical snapshots, prefer that over fragile partial truncation.
-
-## Acceptance criteria
-
-- `:rewind` opens a picker of past user messages by replacing the normal conversation/history view area, not by drawing a small popup.
-- `Ctrl+R` opens the same picker only while Pod status is `Idle` or `Paused`; it is disabled/rejected while `Running`.
-- Selecting a message rewinds the Pod state to before that message and restores the message into the TUI composer.
-- Rewind does not auto-run; pressing Enter after selection retries the restored message.
-- Rewind success updates Pod session log, SegmentLogSink mirror, worker state, and TUI display consistently.
-- Esc returns from the rewind picker to the normal conversation/history view without changing Pod state.
-- Rewind failure leaves state unchanged and shows a clear reason.
-- Picker selections are revalidated at apply time to avoid stale-head corruption.
-- Rewound suffix is intentionally discarded; no fork is created.
-- Tool side effects are not undone; UI/diagnostics make this clear when relevant.
-- Tests cover target listing, apply success, stale-head rejection, composer restore, TUI display reseed, and at least one suffix-with-tool case.
-- `cargo fmt --check`
-- `cargo check -p protocol -p pod -p tui`
-- Relevant focused tests.
-
-## Out of scope
-
-- Creating a fork when rewinding.
-- Fork tree visualization.
-- Merging branches.
-- Undoing tool side effects.
-- Rollback history stack / redo.
-- Rewind across compacted segments unless it falls out naturally from implementation.
-
-## Related
-
-- `20260527-000009-pod-session-fork` remains a lower-priority future feature for preserving alternate histories.
-- Completed: `pod-empty-turn-rollback`
-- Completed: `tui-empty-turn-restore`
-
-
----

.yoi/tickets/00001KSKBPCW8/item.md

@@ -1,80 +0,0 @@
----
-title: "プロンプト: memory / knowledge tool 利用タイミングのガイダンス"
-state: "closed"
-created_at: "2026-05-27T00:00:05Z"
-updated_at: "2026-05-28T23:59:06Z"
----
-
-## Migration reference
-
-- legacy_ticket: tickets/memory-tool-guidance-prompt.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# プロンプト: memory / knowledge tool 利用タイミングのガイダンス
-
-## 背景
-
-通常 Pod には `MemoryQuery` / `MemoryRead` / `KnowledgeQuery` / `MemoryWrite` 等の memory / knowledge tools が提供されているが、現状の通常 system prompt はそれらを「いつ使うべきか」をほとんど説明していない。
-
-現在の `resources/prompts/common/tool-usage.md` は、既知パスなら Read、検索なら Grep/Glob、並列可能ならまとめる、という汎用 tool 方針に留まる。memory / knowledge tools の description には操作方法はあるが、モデルが自発的に memory lookup すべき状況は明示されていない。
-
-このため、過去の決定・ユーザー嗜好・以前の経緯を問われても、モデルが `MemoryQuery` / `MemoryRead` を自発的に使わない可能性が高い。`summary.md` resident injection により短い durable context は常時見えるようになるが、詳細な過去判断や request を探すには query guidance が必要である。
-
-## 方針
-
-通常 Pod の system prompt に、memory / knowledge tools の利用タイミングを短く追加する。
-
-目的は「必要な時に過去情報を探す」ことであり、毎 turn memory query を強制することではない。memory / knowledge は helpful context だが stale になり得るため、現在の user instruction / files / tickets / git state / session log を上書きする権威として扱わせない。
-
-## 推奨する追加文言
-
-`resources/prompts/common/tool-usage.md` に新しい小節を足すか、`resources/prompts/common/memory.md` を作って `default.md` から include する。
-
-例:
-
-```md
-## Memory and knowledge
-
-Use memory and knowledge tools when the user asks about past decisions, prior requests, durable preferences, project history, or why something was done. Do not guess from vague recollection when a targeted memory lookup would answer the question.
-
-- Use `MemoryQuery` for durable memory records: summary, decisions, and requests.
-- Use `KnowledgeQuery` for project knowledge records.
-- Use `MemoryRead(kind=summary)` when you need the full workspace memory summary.
-- Use `MemoryRead` on returned slugs when query excerpts are insufficient.
-
-Resident memory and knowledge are helpful context but may be stale. Current user instructions, repository files, tickets, git history, and session logs are more authoritative for exact current state.
-
-Do not query memory on every turn. Prefer it when past context, user preferences, or prior rationale materially affects the answer or implementation.
-```
-
-文言は実装時に自然に調整してよいが、以下の意味は維持する。
-
-- 過去判断 / 過去依頼 / ユーザー嗜好 / project history / why 系では memory lookup を促す。
-- `MemoryQuery`, `KnowledgeQuery`, `MemoryRead(kind=summary)`, slug read の役割を明示する。
-- resident context は stale になり得ると明示する。
-- current user instruction / files / tickets / git / session logs の方が exact current state では強いと明示する。
-- 毎 turn query しないと明示する。
-
-## 要件
-
-- 通常 Pod の default prompt に memory / knowledge tool 利用タイミングの guidance が入る。
-- internal prompts (`memory_extract_system`, `memory_consolidation_system`, `compact_system`) の挙動を変えない。
-- guidance は短く、通常 turn の token overhead を過度に増やさない。
-- guidance は memory / knowledge を current authority より上に置かない。
-- guidance は毎 turn memory query を促さない。
-- `MemoryWrite` / `MemoryEdit` / `MemoryDelete` の自発的利用を安易に促さない。
-  - 通常作業では read/query を促し、write/edit/delete は明示的な依頼または memory maintenance worker に寄せる。
-
-## 完了条件
-
-- `resources/prompts/default.md` から memory guidance が render される。
-- prompt render / catalog 関連 test があれば更新されている。
-- internal worker prompt には不要な memory guidance が混ざらない。
-- `cargo fmt --check` と関連 test が通る。
-
-## 範囲外
-
-- `summary.md` resident injection の実装。これは `memory-summary-resident-injection.md` で扱う。
-- memory tool descriptions の大幅変更。
-- memory usage metrics の設計変更。
-- global memory / project local memory の store 分離。

.yoi/tickets/00001KSKBPCW8/resolution.md

@@ -1,87 +0,0 @@
----
-id: 20260527-000005-memory-tool-guidance-prompt
-slug: memory-tool-guidance-prompt
-title: プロンプト: memory / knowledge tool 利用タイミングのガイダンス
-status: closed
-kind: task
-priority: P2
-labels: [migrated]
-created_at: 2026-05-27T00:00:05Z
-updated_at: 2026-05-28T23:59:06Z
-assignee: null
-legacy_ticket: tickets/memory-tool-guidance-prompt.md
----
-
-## Migration reference
-
-- legacy_ticket: tickets/memory-tool-guidance-prompt.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# プロンプト: memory / knowledge tool 利用タイミングのガイダンス
-
-## 背景
-
-通常 Pod には `MemoryQuery` / `MemoryRead` / `KnowledgeQuery` / `MemoryWrite` 等の memory / knowledge tools が提供されているが、現状の通常 system prompt はそれらを「いつ使うべきか」をほとんど説明していない。
-
-現在の `resources/prompts/common/tool-usage.md` は、既知パスなら Read、検索なら Grep/Glob、並列可能ならまとめる、という汎用 tool 方針に留まる。memory / knowledge tools の description には操作方法はあるが、モデルが自発的に memory lookup すべき状況は明示されていない。
-
-このため、過去の決定・ユーザー嗜好・以前の経緯を問われても、モデルが `MemoryQuery` / `MemoryRead` を自発的に使わない可能性が高い。`summary.md` resident injection により短い durable context は常時見えるようになるが、詳細な過去判断や request を探すには query guidance が必要である。
-
-## 方針
-
-通常 Pod の system prompt に、memory / knowledge tools の利用タイミングを短く追加する。
-
-目的は「必要な時に過去情報を探す」ことであり、毎 turn memory query を強制することではない。memory / knowledge は helpful context だが stale になり得るため、現在の user instruction / files / tickets / git state / session log を上書きする権威として扱わせない。
-
-## 推奨する追加文言
-
-`resources/prompts/common/tool-usage.md` に新しい小節を足すか、`resources/prompts/common/memory.md` を作って `default.md` から include する。
-
-例:
-
-```md
-## Memory and knowledge
-
-Use memory and knowledge tools when the user asks about past decisions, prior requests, durable preferences, project history, or why something was done. Do not guess from vague recollection when a targeted memory lookup would answer the question.
-
-- Use `MemoryQuery` for durable memory records: summary, decisions, and requests.
-- Use `KnowledgeQuery` for project knowledge records.
-- Use `MemoryRead(kind=summary)` when you need the full workspace memory summary.
-- Use `MemoryRead` on returned slugs when query excerpts are insufficient.
-
-Resident memory and knowledge are helpful context but may be stale. Current user instructions, repository files, tickets, git history, and session logs are more authoritative for exact current state.
-
-Do not query memory on every turn. Prefer it when past context, user preferences, or prior rationale materially affects the answer or implementation.
-```
-
-文言は実装時に自然に調整してよいが、以下の意味は維持する。
-
-- 過去判断 / 過去依頼 / ユーザー嗜好 / project history / why 系では memory lookup を促す。
-- `MemoryQuery`, `KnowledgeQuery`, `MemoryRead(kind=summary)`, slug read の役割を明示する。
-- resident context は stale になり得ると明示する。
-- current user instruction / files / tickets / git / session logs の方が exact current state では強いと明示する。
-- 毎 turn query しないと明示する。
-
-## 要件
-
-- 通常 Pod の default prompt に memory / knowledge tool 利用タイミングの guidance が入る。
-- internal prompts (`memory_extract_system`, `memory_consolidation_system`, `compact_system`) の挙動を変えない。
-- guidance は短く、通常 turn の token overhead を過度に増やさない。
-- guidance は memory / knowledge を current authority より上に置かない。
-- guidance は毎 turn memory query を促さない。
-- `MemoryWrite` / `MemoryEdit` / `MemoryDelete` の自発的利用を安易に促さない。
-  - 通常作業では read/query を促し、write/edit/delete は明示的な依頼または memory maintenance worker に寄せる。
-
-## 完了条件
-
-- `resources/prompts/default.md` から memory guidance が render される。
-- prompt render / catalog 関連 test があれば更新されている。
-- internal worker prompt には不要な memory guidance が混ざらない。
-- `cargo fmt --check` と関連 test が通る。
-
-## 範囲外
-
-- `summary.md` resident injection の実装。これは `memory-summary-resident-injection.md` で扱う。
-- memory tool descriptions の大幅変更。
-- memory usage metrics の設計変更。
-- global memory / project local memory の store 分離。

.yoi/tickets/00001KSKBPCW8/thread.md

@@ -1,102 +0,0 @@
-<!-- event: migration author: tickets.sh-migration at: 2026-05-27T00:00:05Z -->
-
-## Migrated
-
-Migrated from tickets/memory-tool-guidance-prompt.md. No legacy review file was present at migration time.
-
----
-
-<!-- event: close author: hare at: 2026-05-28T23:59:06Z status: closed -->
-
-## Closed
-
----
-id: 20260527-000005-memory-tool-guidance-prompt
-slug: memory-tool-guidance-prompt
-title: プロンプト: memory / knowledge tool 利用タイミングのガイダンス
-status: closed
-kind: task
-priority: P2
-labels: [migrated]
-created_at: 2026-05-27T00:00:05Z
-updated_at: 2026-05-28T23:59:06Z
-assignee: null
-legacy_ticket: tickets/memory-tool-guidance-prompt.md
----
-
-## Migration reference
-
-- legacy_ticket: tickets/memory-tool-guidance-prompt.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# プロンプト: memory / knowledge tool 利用タイミングのガイダンス
-
-## 背景
-
-通常 Pod には `MemoryQuery` / `MemoryRead` / `KnowledgeQuery` / `MemoryWrite` 等の memory / knowledge tools が提供されているが、現状の通常 system prompt はそれらを「いつ使うべきか」をほとんど説明していない。
-
-現在の `resources/prompts/common/tool-usage.md` は、既知パスなら Read、検索なら Grep/Glob、並列可能ならまとめる、という汎用 tool 方針に留まる。memory / knowledge tools の description には操作方法はあるが、モデルが自発的に memory lookup すべき状況は明示されていない。
-
-このため、過去の決定・ユーザー嗜好・以前の経緯を問われても、モデルが `MemoryQuery` / `MemoryRead` を自発的に使わない可能性が高い。`summary.md` resident injection により短い durable context は常時見えるようになるが、詳細な過去判断や request を探すには query guidance が必要である。
-
-## 方針
-
-通常 Pod の system prompt に、memory / knowledge tools の利用タイミングを短く追加する。
-
-目的は「必要な時に過去情報を探す」ことであり、毎 turn memory query を強制することではない。memory / knowledge は helpful context だが stale になり得るため、現在の user instruction / files / tickets / git state / session log を上書きする権威として扱わせない。
-
-## 推奨する追加文言
-
-`resources/prompts/common/tool-usage.md` に新しい小節を足すか、`resources/prompts/common/memory.md` を作って `default.md` から include する。
-
-例:
-
-```md
-## Memory and knowledge
-
-Use memory and knowledge tools when the user asks about past decisions, prior requests, durable preferences, project history, or why something was done. Do not guess from vague recollection when a targeted memory lookup would answer the question.
-
-- Use `MemoryQuery` for durable memory records: summary, decisions, and requests.
-- Use `KnowledgeQuery` for project knowledge records.
-- Use `MemoryRead(kind=summary)` when you need the full workspace memory summary.
-- Use `MemoryRead` on returned slugs when query excerpts are insufficient.
-
-Resident memory and knowledge are helpful context but may be stale. Current user instructions, repository files, tickets, git history, and session logs are more authoritative for exact current state.
-
-Do not query memory on every turn. Prefer it when past context, user preferences, or prior rationale materially affects the answer or implementation.
-```
-
-文言は実装時に自然に調整してよいが、以下の意味は維持する。
-
-- 過去判断 / 過去依頼 / ユーザー嗜好 / project history / why 系では memory lookup を促す。
-- `MemoryQuery`, `KnowledgeQuery`, `MemoryRead(kind=summary)`, slug read の役割を明示する。
-- resident context は stale になり得ると明示する。
-- current user instruction / files / tickets / git / session logs の方が exact current state では強いと明示する。
-- 毎 turn query しないと明示する。
-
-## 要件
-
-- 通常 Pod の default prompt に memory / knowledge tool 利用タイミングの guidance が入る。
-- internal prompts (`memory_extract_system`, `memory_consolidation_system`, `compact_system`) の挙動を変えない。
-- guidance は短く、通常 turn の token overhead を過度に増やさない。
-- guidance は memory / knowledge を current authority より上に置かない。
-- guidance は毎 turn memory query を促さない。
-- `MemoryWrite` / `MemoryEdit` / `MemoryDelete` の自発的利用を安易に促さない。
-  - 通常作業では read/query を促し、write/edit/delete は明示的な依頼または memory maintenance worker に寄せる。
-
-## 完了条件
-
-- `resources/prompts/default.md` から memory guidance が render される。
-- prompt render / catalog 関連 test があれば更新されている。
-- internal worker prompt には不要な memory guidance が混ざらない。
-- `cargo fmt --check` と関連 test が通る。
-
-## 範囲外
-
-- `summary.md` resident injection の実装。これは `memory-summary-resident-injection.md` で扱う。
-- memory tool descriptions の大幅変更。
-- memory usage metrics の設計変更。
-- global memory / project local memory の store 分離。
-
-
----

.yoi/tickets/00001KSKBPDVG/item.md

@@ -1,43 +0,0 @@
----
-title: "Permission: allow-all 既定 policy への整理"
-state: "planning"
-created_at: "2026-05-27T00:00:06Z"
-updated_at: "2026-05-27T00:00:06Z"
----
-
-## Migration reference
-
-- legacy_ticket: tickets/permission-default-policy.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# Permission: allow-all 既定 policy への整理
-
-## 背景
-
-現在の tool permission は `[permissions]` セクションが無い場合に permission 層を無効化し、`[permissions]` がある場合だけ `default_action` を必須としている。
-
-実行時の意味として、未指定時の挙動はほぼ `default_action = "allow"` と同じであり、`Option<ToolPermissionConfig>` による「無効」と allow-all policy が型上で分かれていることが仕様理解と実装の分岐を増やしている。
-
-## 要件
-
-- resolved manifest の permission は常に policy として存在する形に整理する。
-- 既定 policy は allow-all とし、`default_action = "allow"` かつ rule なしと同等にする。
-- manifest に `[permissions]` が無い既存ユーザー設定は従来通り全ツール実行可能にする。
-- `default_action = "deny"` による allowlist 型運用と、`default_action = "allow"` + deny rule による blocklist 型運用を明確に維持する。
-- merge/parse 用の partial config では、「その層が permissions に触れていない」ことを表現できるようにする。
-
-## 方針
-
-`PodManifest` のような resolve 後の型では `permissions: ToolPermissionConfig` を持ち、`ToolPermissionConfig::default()` を allow-all とする。
-
-`PodManifestConfig` / partial 側では階層 manifest の merge semantics のために `Option<PermissionConfigPartial>` を残してよい。resolve 時に未指定を allow-all default policy へ畳み込む。
-
-`[permissions]` セクションを書いた場合の `default_action` 必須制約は見直す。rule だけを書いた場合は `default_action = "allow"` と解釈できるようにするか、明示必須を維持する場合でも resolved 型上は allow-all default と矛盾しない形にする。
-
-## 完了条件
-
-- resolve 後の manifest から permission policy の `Option` が消えている。
-- `[permissions]` 未指定時に allow-all policy が得られる。
-- permission rule 評価と Pod への built-in hook 登録が、常在 policy 前提で単純化されている。
-- manifest resolve / merge / permission hook のテストが新しい既定値をカバーしている。
-- docs の `[permissions]` 説明が allow-all 既定であることを明記している。

.yoi/tickets/00001KSKBPDVG/thread.md

@@ -1,7 +0,0 @@
-<!-- event: migration author: tickets.sh-migration at: 2026-05-27T00:00:06Z -->
-
-## Migrated
-
-Migrated from tickets/permission-default-policy.md. No legacy review file was present at migration time.
-
----

.yoi/tickets/00001KSKBPETR/item.md

@@ -1,69 +0,0 @@
----
-title: "Inbound PodEvent ハンドリングの重複を統合する"
-state: "closed"
-created_at: "2026-05-27T00:00:07Z"
-updated_at: "2026-05-30T05:37:00Z"
----
-
-## Migration reference
-
-- legacy_ticket: tickets/pod-inbound-pod-event-dedup.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# Inbound PodEvent ハンドリングの重複を統合する
-
-## 背景
-
-子 Pod から `Method::PodEvent(event)` を受けたときの処理が `controller_loop` と `drive_turn` の 2 箇所にコピーされている。
-
-`controller.rs:693-720`（idle / paused 中）:
-
-```rust
-Method::PodEvent(event) => {
-    crate::ipc::event::apply_event_side_effects(
-        &event, &spawned_registry, &spawner_name, &self_parent_socket,
-    ).await;
-    pod.push_pod_event_notify(event);
-    if shared_state.get_status() == PodStatus::Idle {
-        pending = Some(PendingRun::RunForNotification);
-    }
-}
-```
-
-`controller.rs:861-879`（in-flight turn 中）:
-
-```rust
-Some(Method::PodEvent(event)) => {
-    let self_parent_socket = parent_socket.cloned();
-    crate::ipc::event::apply_event_side_effects(
-        &event, spawned_registry, self_name, &self_parent_socket,
-    ).await;
-    notify_buffer.push_pod_event(event);
-}
-```
-
-差分は 2 点:
-
-1. **buffer への push 経路**: `pod.push_pod_event_notify(event)` vs `notify_buffer.push_pod_event(event)`。両者は同じ `NotifyBuffer` を叩く（`pod.rs:845-846` は `self.pending_notifies.push_pod_event(event)` を呼ぶだけで、`notify_buffer_handle()` はその `pending_notifies.clone()` を返す）。**完全に等価**。
-2. **auto-kick**: idle 経路だけ `PendingRun::RunForNotification` を stage する。in-flight 経路は in-flight 自体が消化するので不要。
-
-つまり「event の処理本体」（side-effects + notify buffer への push）は同一で、後段の auto-kick だけが state-dependent な分岐。にもかかわらず関数化されておらず、片方をいじってもう片方を忘れると挙動が割れる。
-
-## 要件
-
-- side-effects 適用 + NotifyBuffer への typed push の流れを単一関数 `handle_inbound_pod_event` に切り出す。
-- `controller_loop` / `drive_turn` の両方からこのヘルパーを呼ぶ形に置き換える。
-- auto-kick (`PendingRun::RunForNotification` の stage) は呼び出し側の責務として残す。これは Pod のライフサイクル状態に依存した判断で、ヘルパー内には押し込めない。
-- 関数シグネチャは引数を最小化する。`event`、`spawned_registry`、`self_name: &str`、`self_parent_socket: &Option<PathBuf>` または `Option<&PathBuf>`、`notify_buffer: &NotifyBuffer` の 5 つで足りる前提。`Pod` への可変参照は不要（`notify_buffer` で代用可能）。
-- 動作変化なし。既存の `Method::PodEvent` 挙動（in-flight / idle 両方）が完全に同一で続行すること。
-
-## 完了条件
-
-- `controller.rs` 内に `apply_event_side_effects` 呼び出しが 1 箇所だけ残り、`controller_loop` と `drive_turn` の `Method::PodEvent` アームはどちらも `handle_inbound_pod_event(...)` 呼び出し + idle 経路のみ auto-kick stage、という形になる。
-- 既存の inbound PodEvent 関連テスト（特に `apply_event_side_effects` の idempotency や `notify_buffer` への typed push）が通る。
-
-## 範囲外
-
-- `apply_event_side_effects` 自体の中身変更。
-- `NotifyBuffer` API のリネーム / 統合。
-- `pod.push_pod_event_notify` の削除（[[pod-interrupt-prep-internalize]] と同じく将来の整理対象だが、本チケットでは外向き API は触らない）。

.yoi/tickets/00001KSKBPETR/resolution.md

@@ -1,76 +0,0 @@
----
-id: 20260527-000007-pod-inbound-pod-event-dedup
-slug: pod-inbound-pod-event-dedup
-title: Inbound PodEvent ハンドリングの重複を統合する
-status: closed
-kind: task
-priority: P2
-labels: [migrated]
-created_at: 2026-05-27T00:00:07Z
-updated_at: 2026-05-30T05:37:00Z
-assignee: null
-legacy_ticket: tickets/pod-inbound-pod-event-dedup.md
----
-
-## Migration reference
-
-- legacy_ticket: tickets/pod-inbound-pod-event-dedup.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# Inbound PodEvent ハンドリングの重複を統合する
-
-## 背景
-
-子 Pod から `Method::PodEvent(event)` を受けたときの処理が `controller_loop` と `drive_turn` の 2 箇所にコピーされている。
-
-`controller.rs:693-720`（idle / paused 中）:
-
-```rust
-Method::PodEvent(event) => {
-    crate::ipc::event::apply_event_side_effects(
-        &event, &spawned_registry, &spawner_name, &self_parent_socket,
-    ).await;
-    pod.push_pod_event_notify(event);
-    if shared_state.get_status() == PodStatus::Idle {
-        pending = Some(PendingRun::RunForNotification);
-    }
-}
-```
-
-`controller.rs:861-879`（in-flight turn 中）:
-
-```rust
-Some(Method::PodEvent(event)) => {
-    let self_parent_socket = parent_socket.cloned();
-    crate::ipc::event::apply_event_side_effects(
-        &event, spawned_registry, self_name, &self_parent_socket,
-    ).await;
-    notify_buffer.push_pod_event(event);
-}
-```
-
-差分は 2 点:
-
-1. **buffer への push 経路**: `pod.push_pod_event_notify(event)` vs `notify_buffer.push_pod_event(event)`。両者は同じ `NotifyBuffer` を叩く（`pod.rs:845-846` は `self.pending_notifies.push_pod_event(event)` を呼ぶだけで、`notify_buffer_handle()` はその `pending_notifies.clone()` を返す）。**完全に等価**。
-2. **auto-kick**: idle 経路だけ `PendingRun::RunForNotification` を stage する。in-flight 経路は in-flight 自体が消化するので不要。
-
-つまり「event の処理本体」（side-effects + notify buffer への push）は同一で、後段の auto-kick だけが state-dependent な分岐。にもかかわらず関数化されておらず、片方をいじってもう片方を忘れると挙動が割れる。
-
-## 要件
-
-- side-effects 適用 + NotifyBuffer への typed push の流れを単一関数 `handle_inbound_pod_event` に切り出す。
-- `controller_loop` / `drive_turn` の両方からこのヘルパーを呼ぶ形に置き換える。
-- auto-kick (`PendingRun::RunForNotification` の stage) は呼び出し側の責務として残す。これは Pod のライフサイクル状態に依存した判断で、ヘルパー内には押し込めない。
-- 関数シグネチャは引数を最小化する。`event`、`spawned_registry`、`self_name: &str`、`self_parent_socket: &Option<PathBuf>` または `Option<&PathBuf>`、`notify_buffer: &NotifyBuffer` の 5 つで足りる前提。`Pod` への可変参照は不要（`notify_buffer` で代用可能）。
-- 動作変化なし。既存の `Method::PodEvent` 挙動（in-flight / idle 両方）が完全に同一で続行すること。
-
-## 完了条件
-
-- `controller.rs` 内に `apply_event_side_effects` 呼び出しが 1 箇所だけ残り、`controller_loop` と `drive_turn` の `Method::PodEvent` アームはどちらも `handle_inbound_pod_event(...)` 呼び出し + idle 経路のみ auto-kick stage、という形になる。
-- 既存の inbound PodEvent 関連テスト（特に `apply_event_side_effects` の idempotency や `notify_buffer` への typed push）が通る。
-
-## 範囲外
-
-- `apply_event_side_effects` 自体の中身変更。
-- `NotifyBuffer` API のリネーム / 統合。
-- `pod.push_pod_event_notify` の削除（[[pod-interrupt-prep-internalize]] と同じく将来の整理対象だが、本チケットでは外向き API は触らない）。

.yoi/tickets/00001KSKBPETR/thread.md

@@ -1,91 +0,0 @@
-<!-- event: migration author: tickets.sh-migration at: 2026-05-27T00:00:07Z -->
-
-## Migrated
-
-Migrated from tickets/pod-inbound-pod-event-dedup.md. No legacy review file was present at migration time.
-
----
-
-<!-- event: close author: hare at: 2026-05-30T05:37:00Z status: closed -->
-
-## Closed
-
----
-id: 20260527-000007-pod-inbound-pod-event-dedup
-slug: pod-inbound-pod-event-dedup
-title: Inbound PodEvent ハンドリングの重複を統合する
-status: closed
-kind: task
-priority: P2
-labels: [migrated]
-created_at: 2026-05-27T00:00:07Z
-updated_at: 2026-05-30T05:37:00Z
-assignee: null
-legacy_ticket: tickets/pod-inbound-pod-event-dedup.md
----
-
-## Migration reference
-
-- legacy_ticket: tickets/pod-inbound-pod-event-dedup.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# Inbound PodEvent ハンドリングの重複を統合する
-
-## 背景
-
-子 Pod から `Method::PodEvent(event)` を受けたときの処理が `controller_loop` と `drive_turn` の 2 箇所にコピーされている。
-
-`controller.rs:693-720`（idle / paused 中）:
-
-```rust
-Method::PodEvent(event) => {
-    crate::ipc::event::apply_event_side_effects(
-        &event, &spawned_registry, &spawner_name, &self_parent_socket,
-    ).await;
-    pod.push_pod_event_notify(event);
-    if shared_state.get_status() == PodStatus::Idle {
-        pending = Some(PendingRun::RunForNotification);
-    }
-}
-```
-
-`controller.rs:861-879`（in-flight turn 中）:
-
-```rust
-Some(Method::PodEvent(event)) => {
-    let self_parent_socket = parent_socket.cloned();
-    crate::ipc::event::apply_event_side_effects(
-        &event, spawned_registry, self_name, &self_parent_socket,
-    ).await;
-    notify_buffer.push_pod_event(event);
-}
-```
-
-差分は 2 点:
-
-1. **buffer への push 経路**: `pod.push_pod_event_notify(event)` vs `notify_buffer.push_pod_event(event)`。両者は同じ `NotifyBuffer` を叩く（`pod.rs:845-846` は `self.pending_notifies.push_pod_event(event)` を呼ぶだけで、`notify_buffer_handle()` はその `pending_notifies.clone()` を返す）。**完全に等価**。
-2. **auto-kick**: idle 経路だけ `PendingRun::RunForNotification` を stage する。in-flight 経路は in-flight 自体が消化するので不要。
-
-つまり「event の処理本体」（side-effects + notify buffer への push）は同一で、後段の auto-kick だけが state-dependent な分岐。にもかかわらず関数化されておらず、片方をいじってもう片方を忘れると挙動が割れる。
-
-## 要件
-
-- side-effects 適用 + NotifyBuffer への typed push の流れを単一関数 `handle_inbound_pod_event` に切り出す。
-- `controller_loop` / `drive_turn` の両方からこのヘルパーを呼ぶ形に置き換える。
-- auto-kick (`PendingRun::RunForNotification` の stage) は呼び出し側の責務として残す。これは Pod のライフサイクル状態に依存した判断で、ヘルパー内には押し込めない。
-- 関数シグネチャは引数を最小化する。`event`、`spawned_registry`、`self_name: &str`、`self_parent_socket: &Option<PathBuf>` または `Option<&PathBuf>`、`notify_buffer: &NotifyBuffer` の 5 つで足りる前提。`Pod` への可変参照は不要（`notify_buffer` で代用可能）。
-- 動作変化なし。既存の `Method::PodEvent` 挙動（in-flight / idle 両方）が完全に同一で続行すること。
-
-## 完了条件
-
-- `controller.rs` 内に `apply_event_side_effects` 呼び出しが 1 箇所だけ残り、`controller_loop` と `drive_turn` の `Method::PodEvent` アームはどちらも `handle_inbound_pod_event(...)` 呼び出し + idle 経路のみ auto-kick stage、という形になる。
-- 既存の inbound PodEvent 関連テスト（特に `apply_event_side_effects` の idempotency や `notify_buffer` への typed push）が通る。
-
-## 範囲外
-
-- `apply_event_side_effects` 自体の中身変更。
-- `NotifyBuffer` API のリネーム / 統合。
-- `pod.push_pod_event_notify` の削除（[[pod-interrupt-prep-internalize]] と同じく将来の整理対象だが、本チケットでは外向き API は触らない）。
-
-
----

.yoi/tickets/00001KSKBPFT0/item.md

@@ -1,69 +0,0 @@
----
-title: "Pod: scope 永続化 authority の整理"
-state: "closed"
-created_at: "2026-05-27T00:00:08Z"
-updated_at: "2026-05-30T05:57:16Z"
----
-
-## Migration reference
-
-- legacy_ticket: tickets/pod-scope-persistence-authority.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# Pod: scope 永続化 authority の整理
-
-## 背景
-
-Pod の scope は複数の場所に関連情報が存在している。
-
-- session log の `pod.scope` extension: Pod 自身の復元用 runtime scope snapshot
-- Pod metadata: Pod 名から active session/segment への pointer と spawned child 情報
-- spawned child 情報: child に委譲した scope
-- runtime registry: live Pod の allocation / conflict detection 用 scope
-- runtime mirror: `spawned_pods.json` 等の現在プロセス向け表示・制御用情報
-
-これらは用途が異なるが、どの情報が durable authority で、どれが live mirror / derived state なのかが読み取りづらい。特に restore、compact/fork による segment 切替、child scope の委譲・reclaim、runtime registry の再構築で、scope の保存先と復元順序が曖昧だと権限の過大復元または過小復元につながる。
-
-## 要件
-
-- Pod scope に関する durable authority を明確に定義する。
-  - Pod 自身の base scope / effective runtime scope / deny による delegated-out 部分を区別する。
-  - spawned child に委譲した scope と、親 Pod 自身の effective scope を区別する。
-  - live registry / runtime mirror は durable authority ではないことを明確にする。
-- Pod 名からの restore に必要な情報の保存先を一貫させる。
-  - Pod 名から active session/segment を解決できる。
-  - 解決した Pod が、前回終了時点の effective scope を過大に復元しない。
-  - child が生存・復元対象の場合、親の delegated-out scope が意図せず reclaim されない。
-- segment 遷移で scope が失われない。
-  - compact / fork / resume / attach の後も、次にその segment を restore したとき同じ effective scope が得られる。
-  - 新 segment 作成時に scope authority が必要なら、初期状態として確実に引き継がれる。
-- spawned child の scope 永続化を親 Pod の restore/reclaim 要件と整合させる。
-  - 親は child に委譲済みの scope を把握できる。
-  - child 停止・shutdown・restore 時の prune により、親の effective write scope が正しく reclaim される。
-  - explicit deny と delegated-out deny を混同しない。
-- runtime registry 再構築時の入力と副作用を定義する。
-  - restore 時にどの durable state から allocation を再作成するかが明確である。
-  - stale / unreachable child を pruning した場合、durable state と runtime mirror が矛盾しない。
-- 保存形式は inspect/debug しやすい。
-  - Pod ごとに「active pointer」「自身の scope」「spawned child と delegated scope」が追跡できる。
-  - restore 失敗時に、欠けている authority が何か分かる error になる。
-- session log の conversation/history authority と scope authority の関係を明確にする。
-  - scope 更新が conversation history の意味内容を汚染しない。
-  - append-only session log に置く場合は、compact/fork と replay semantics 上の扱いが明示される。
-  - Pod metadata に置く場合は、session/segment lineage との整合と更新順序が明示される。
-
-## 完了条件
-
-- Pod scope に関する durable authority / runtime mirror / derived state の責務がコードとドキュメント上で一致している。
-- Pod restore が、前回の effective scope を過大復元しない regression test を持つ。
-- compact または fork 後の新 segment restore で scope が失われない regression test を持つ。
-- spawned child に scope 委譲済みの親 Pod を restore しても、child 側の write scope が親に二重に戻らない regression test を持つ。
-- child 停止・shutdown・restore pruning 後に、親の effective scope と durable state が一致する regression test を持つ。
-- runtime registry / runtime mirror が durable authority と矛盾した場合の扱いが test で確認されている。
-
-## 範囲外
-
-- manifest scope 設定そのものの設計変更。
-- tool permission policy の allow / ask / deny 挙動変更。
-- UI 表示だけで scope 不整合を隠す対応。
-- 既存の壊れた手元 session log を自動修復する migration。

.yoi/tickets/00001KSKBPFT0/resolution.md

@@ -1,3 +0,0 @@
-後続の `session-pod-state-boundary` / `pod-store` / spawned registry work により、scope authority の主設計と restore/reclaim 実装は吸収済み。
-
-残る小粒な責務重複は `KNOWN_ISSUES.md` に移したため、この migrated ticket は superseded として閉じる。

.yoi/tickets/00001KSKBPFT0/thread.md

@@ -1,17 +0,0 @@
-<!-- event: migration author: tickets.sh-migration at: 2026-05-27T00:00:08Z -->
-
-## Migrated
-
-Migrated from tickets/pod-scope-persistence-authority.md. No legacy review file was present at migration time.
-
----
-
-<!-- event: close author: hare at: 2026-05-30T05:57:16Z status: closed -->
-
-## Closed
-
-後続の `session-pod-state-boundary` / `pod-store` / spawned registry work により、scope authority の主設計と restore/reclaim 実装は吸収済み。
-
-残る小粒な責務重複は `KNOWN_ISSUES.md` に移したため、この migrated ticket は superseded として閉じる。
-
----

.yoi/tickets/00001KSKBPGS8/item.md

@@ -1,68 +0,0 @@
----
-title: "Pod: 任意ターンからの Fork（複数ターン巻き戻し）"
-state: 'closed'
-created_at: "2026-05-27T00:00:09Z"
-updated_at: '2026-06-20T16:31:29Z'
----
-
-## Migration reference
-
-- legacy_ticket: tickets/pod-session-fork.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# Pod: 任意ターンからの Fork（複数ターン巻き戻し）
-
-## 背景
-
-`tickets/pod-empty-turn-rollback.md` は「直近 Submit が AI 応答ゼロのまま中断された」極めて狭いケースだけを自動で巻き戻す簡易フォーム。それを超える「3 ターン前から別の方針でやり直したい」「ある分岐は捨てて別ルートを試したい」といった **複数ターン巻き戻し** は、過去ターン境界からの Fork として実装する。
-
-session_store には既に primitive が揃っている:
-
-- `session::fork(state)` — 現状から新 session_id へ分岐（`crates/session-store/src/session.rs:400`）
-- `session::fork_at(source_id, at_hash)` — 既存セッションログ上の任意 entry hash から分岐（同 :424）
-- `SessionOrigin { session_id, at_hash }` — `SessionStart.forked_from` に出自を記録
-
-未着手なのは Pod / protocol / クライアントへの露出と、ターン境界 ↔ entry hash の対応付け。
-
-## 要件
-
-- Pod に「現セッションから Fork して新セッションへ切り替える」操作を追加。Fork 起点はターン境界で指定する:
-  - protocol に新 Method（仮: `Method::Fork { from: ForkPoint }`）を追加
-  - `ForkPoint` は最低限「ターン番号」「entry hash」のいずれかで起点を指す
-  - ターン番号 → entry hash の解決は Pod / session_store 側で行う（`save_turn_end` のログ entry を境界として使うのが自然）
-- Fork 後の Pod 状態:
-  - 新 session_id を active に切り替え、worker.history を fork 起点までの内容で再構築
-  - 元セッションは破壊されない（後から switch back 可能な前提を残す）
-  - 走行中（Running / Paused）状態での Fork は拒否し、Idle 限定
-- Fork ツリーが追跡可能であること:
-  - `forked_from` chain が session_store のログから辿れる（既存挙動の確認込み）
-  - クライアントから「このセッションの祖先 / 子孫」を引ける API（最低限、`SessionOrigin` を読める形）
-- pod_cli / TUI からの呼び出しインターフェースの設計:
-  - 本チケットで protocol 上の Method は確定させる
-  - pod_cli の引数仕様もここに含める（最低限 `pod fork --turn N` 程度）
-  - TUI 側の UX（ターンを選択して fork する操作）は別チケット
-- セッション切り替え後の `runtime_dir` の扱いを decide:
-  - 1 つの runtime に対して active session が切り替わる形
-  - セッションごとに別 runtime を持つ形
-  - のどちらが今の構成と整合するか調査の上で決定
-
-## 完了条件
-
-- `Method::Fork` で過去ターン起点の新セッションが作成され、そこから `Method::Run` で続行できる
-- 元セッションが fork 後も独立に存在し、別 Pod プロセスから resume できる（破壊されていない）
-- Fork ツリーが session_store のログから機械的に辿れる
-- pod_cli から fork → 新セッションでの run まで通せる
-- `pod-empty-turn-rollback` の自動巻き戻しと共存（自動巻き戻しは本機能を使わずに従来通りの直接 truncate 方式で良い、と決めるならその根拠も明記）
-
-## 範囲外
-
-- Fork ツリーの可視化 UI（TUI / GUI）— 別チケット
-- TUI 上での「ターンを選んで fork」UX — 別チケット
-- 異なる Fork 間でのマージ
-- 過去ターンの物理削除型リベース（fork は常に非破壊）
-- 自動 GC / 古い fork の整理
-
-## 依存 / 関連
-
-- `tickets/pod-empty-turn-rollback.md`（直近 Submit のみの自動巻き戻し。本チケットは汎用 fork）
-- session_store の既存 `fork` / `fork_at` を流用

.yoi/tickets/00001KSKBPGS8/resolution.md

@@ -1 +0,0 @@
-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

@@ -1,25 +0,0 @@
-<!-- event: migration author: tickets.sh-migration at: 2026-05-27T00:00:09Z -->
-
-## Migrated
-
-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,159 +0,0 @@
----
-title: "Prompt / Workflow 評価メトリクスと改善 Offer"
-state: 'closed'
-created_at: "2026-05-27T00:00:10Z"
-updated_at: '2026-06-20T16:31:29Z'
----
-
-## Migration reference
-
-- legacy_ticket: tickets/prompt-eval-metrics.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# Prompt / Workflow 評価メトリクスと改善 Offer
-
-## 背景
-
-empirical prompt tuning pattern は、agent-facing な指示（Skill / slash command / prompt 等）を新規 subagent に実行させ、実行者の自己申告と指示側メトリクスを突き合わせて反復改善する手法である。insomnia では Workflow / Skill ingest / Knowledge / memory consolidation / usage metrics / Pod orchestration があるため、この手法を単なる「手順」ではなく、**agent-facing instruction の品質観測 pipeline** として扱える。
-
-特に insomnia では以下をシステム側で観測できる。
-
-- evaluator Pod の session id / history
-- tool call / tool result
-- usage tokens
-- workflow / knowledge の明示使用ログ（use 回数、last used、source breakdown。`tickets/memory-usage-metrics.md`）
-- `model_invokation` 常駐注入の exposure cost 指標
-- extract / consolidation による recurring pattern 抽出
-- Workflow 自動書き込み禁止に基づく improvement offer
-
-したがって、`/empirical-prompt-tuning` 相当の Workflow は、評価実行を orchestration するだけでなく、評価結果を構造化 event として残し、将来的に memory consolidation / usage metrics / Workflow improvement offer / `model_invokation` 判断へ接続するべきである。
-
-## 要件
-
-### `/empirical-prompt-tuning` Workflow
-
-`.insomnia/workflow/empirical-prompt-tuning.md` を追加し、Workflow / Skill / prompt / Knowledge を評価対象として扱える手順を用意する。
-
-Workflow は少なくとも以下を明示する。
-
-- 評価対象 target の固定
-  - kind: workflow / skill / prompt / knowledge
-  - slug または path
-  - git revision または content hash
-- Iteration 0: description / body consistency check
-- scenario set の作成
-  - median 1 件
-  - edge 1〜2 件
-  - requirements checklist 3〜7 項目
-  - `[critical]` 項目を最低 1 つ含める
-- evaluator Pod は毎回新規に spawn し、同じ evaluator を再利用しない
-- evaluator Pod は実装者ではなく評価者として動く
-- evaluator report は以下の構造にする
-  - Deliverable
-  - Requirement achievement
-  - Trace: Understanding / Planning / Execution / Formatting
-  - Unclear points: Issue / Cause / General Fix Rule
-  - Discretionary fill-ins
-  - Retries
-- 1 iteration 1 theme の最小修正を原則とする
-- Workflow / prompt の実ファイル書き換えは人間承認後に限る
-- Workflow 自動生成 / 自動更新は禁止し、必要な改善は offer として人間に戻す
-
-### 評価 event schema
-
-評価結果を、将来の system metrics / memory consolidation に流せる構造化 event として定義する。
-
-最低限の field:
-
-```text
-eval_run_id
-target_kind
-target_slug_or_path
-target_revision_or_hash
-scenario_id
-scenario_kind: median | edge | holdout
-evaluator_pod_name
-evaluator_session_id
-started_at / ended_at
-success: bool
-accuracy: number
-critical_passed: bool
-tool_call_count
-tool_call_count_by_tool
-input_tokens
-output_tokens
-cache_read_tokens / cache_write_tokens if available
-scope_error_count
-file_search_count
-escalation_count
-unclear_points[]
-  phase: Understanding | Planning | Execution | Formatting
-  issue
-  cause
-  general_fix_rule
-discretionary_fill_ins[]
-retries
-```
-
-初期実装で全 field が機械取得できない場合は、取得可能なものと evaluator self-report 由来のものを分ける。未取得 field は空にしてよいが、schema 上は将来埋められる形にする。
-
-### Metrics / memory consolidation との接続
-
-本チケットでは、評価 event を memory / metrics pipeline に接続する設計を明文化し、可能な最小実装を入れる。
-
-接続方針:
-
-- evaluator self-report は consolidation extract の活動抽出対象になる
-- repeated `General Fix Rule` は consolidation が recurring failure pattern として統合できる
-- recurring pattern は即 Knowledge 化せず、明示使用ログと Doctor / prompt-eval の事後評価を通す
-- Workflow 改善は `.insomnia/workflow/*.md` へ自動書き込みせず、Notification / report / ticket などの offer に留める
-- `model_invokation` ON 判断では、明示使用ログと resident exposure cost に加えて、eval success rate / unclear point count / description-body consistency を判断材料にする
-
-### 評価指標の解釈
-
-Claude Code 版の `tool_uses` を、insomnia では tool 種別ごとの偏りとして解釈する。
-
-例:
-
-- Glob / Grep が突出: references / 探索方針が prompt 内で弱い
-- Read が突出: required context の入口が弱い
-- scope error が出る: permission / worktree / escalation 境界が弱い
-- SpawnPod / SendToPod が多い: orchestration の粒度や子 Pod 指示が曖昧
-- ticket / git write に向かう: escalation criteria が弱い
-
-定量指標は補助であり、Unclear points / Discretionary fill-ins / General Fix Rule を主指標とする。
-
-### Failure pattern ledger
-
-手書き台帳だけにせず、eval event から抽出可能な failure pattern として扱う。
-
-- `General Fix Rule` を class-level pattern として正規化する
-- 同じ pattern が複数 scenario / 複数 iteration / 複数 target で再発した場合、consolidation が decision / knowledge candidate / workflow improvement offer に統合できる
-- 同じ pattern が 3 回以上再発した場合、局所 patch ではなく target prompt の構造変更を提案する
-
-## 範囲外
-
-- Workflow の自動書き換え
-- Knowledge の即時自動作成
-- `model_invokation` ON/OFF の完全自動切替
-- evaluator Pod の永続ジョブキュー化
-- prompt DSL 化
-- LLM judge による主観的 A/B 比較の採用
-- すべての metrics field の初期実装での完全自動取得
-
-## 完了条件
-
-- `.insomnia/workflow/empirical-prompt-tuning.md` が追加され、insomnia の evaluator Pod / metrics / memory consolidation 前提で記述されている
-- Workflow は Iteration 0、scenario checklist、Trace、Issue / Cause / General Fix Rule、1 iteration 1 theme、人間承認 gate を明示している
-- 評価 event schema が docs または ticket 内で定義されている
-- eval event を memory consolidation / usage metrics / Workflow improvement offer / `model_invokation` 判断へ接続する方針が文書化されている
-- 既存の Workflow 自動生成禁止・history に commit されない context input 禁止・memory consolidation 方針に反していない
-- `ticket-intake-workflow` / `ticket-orchestrator-routing` / `worktree-workflow` のいずれか 1 件を対象に、構造審査または小規模 evaluator Pod 試走を行い、結果を記録している
-
-## 参照
-
-- empirical prompt tuning skill example（外部参照。取り込み時は必要最小限に一般化する）
-- `docs/plan/workflow.md`
-- `docs/plan/memory.md`
-- `tickets/memory-usage-metrics.md`
-- `ticket-intake-workflow.md` / `ticket-orchestrator-routing.md`

.yoi/tickets/00001KSKBPHRG/resolution.md

@@ -1 +0,0 @@
-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

@@ -1,25 +0,0 @@
-<!-- event: migration author: tickets.sh-migration at: 2026-05-27T00:00:10Z -->
-
-## Migrated
-
-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/00001KSKBPJQR/item.md

@@ -1,73 +0,0 @@
----
-title: "セッション内 Task ツールの注意機構"
-state: "closed"
-created_at: "2026-05-27T00:00:11Z"
-updated_at: "2026-05-29T04:31:10Z"
----
-
-## Migration reference
-
-- legacy_ticket: tickets/session-todo-reminder.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# セッション内 Task ツールの注意機構
-
-## 背景
-
-`tickets/session-todo.md` で導入した Task ツール群があっても、LLM はそれを使わずに作業を続け得る。ツールを呼ばないまま会話が長引くと、
-
-- 開始した作業の `inprogress` がずっと放置されたままになる
-- 「やったつもり」になって `completed` への更新を忘れる
-- そもそも TaskStore の存在を忘れて、構造化を諦めて自由記述に回帰する
-
-OpenCode の todo は専用の注意機構を持たない（汎用 reminder 経由）。一方、一部の既存エージェント実装では todo reminder を「N リクエスト無アクティビティで初めて発火するナッジ型」として扱い、毎リクエスト押し戻しはしない。
-
-
-Insomnia でも同方針を採り、active Task が残っているのに `TaskCreate` / `TaskUpdate` が一定リクエスト呼ばれていない場合に限り、`<system-reminder>` Item を 1件 history に append する。「やったつもり」抑止と、トークン浪費・LLM の自律性侵害のバランスを取るため、毎リクエスト押し戻しはしない。
-
-## 前提
-
-- `tickets/session-todo.md` の TaskStore と `TaskCreate` / `TaskUpdate` / `TaskList` / `TaskGet` ツールが利用可能
-- `Interceptor::pending_history_appends` レーンが利用可能（`tickets/notify-history-persist.md` で導入済み）
-
-## 方針
-
-- **`pending_history_appends` で実装**。発火時に `<system-reminder>` ブロックを含む新規 system message Item を返し、Worker が `worker.history` に append する。Notify / PodEvent と同じレーンで永続化・resume・compaction が自動で揃う
-- **揮発的注入は採らない**（`AGENTS.md` 「LLM コンテキストの加工原則」で禁止。history に commit せずに context を変えると、resume 時に LLM の発言の根拠が再現できなくなる）
-- **system-reminder 注入機構の汎用化はやらない**。利用者が Task 1機構しかない段階で抽象を立てない（`AGENTS.md`「概念の追加は不在が問題になってから」）。タグ形式 `<system-reminder>...</system-reminder>` の規約は本実装で踏襲する
-- **発火はナッジ型**。N リクエスト無アクティビティで初めて発火し、cooldown も持つ
-
-## 要件
-
-### Interceptor
-
-- `pending_history_appends` で以下を **AND** で満たす場合のみ発動し、`<system-reminder>` ブロックを含む `Item::system_message` を 1件返す。条件外なら空 `Vec<Item>` を返す
-  - active Task（`pending` または `inprogress`）が 1件以上存在する
-  - 直近 N リクエスト（暫定 N=8）`TaskCreate` / `TaskUpdate` のいずれも呼ばれていない
-  - 前回 reminder Item の append から M リクエスト（暫定 M=8）以上経過
-- ここで言う「リクエスト」は LLM への 1回の推論呼び出し（assistant 応答 1回）の単位。1ユーザー発火内で tool ループが回れば、`tool_result` を受けて発火する次のリクエストもそれぞれ 1としてカウントする
-- カウンタは Pod 側の session-lifetime 状態として保持する（`requests_since_last_task_management` / `requests_since_last_reminder`）。resume 時は worker.history の逆走査で再計算するか 0 リセットで再開する。後者でも「初回ナッジが最大 N リクエスト遅れる」だけで挙動として致命ではない
-- 返す Item の本文は `<system-reminder>` で囲み、現在の active Task を `taskid` / `status` / `subject` を含む簡潔な形式で列挙する。`description` は長大化を避けるため省略してよい
-- active Task が空の場合は何も append しない（思い出させる対象が無いなら不要）
-
-## 完了条件
-
-- 直近 N リクエスト連続で `TaskCreate` / `TaskUpdate` が呼ばれず、かつ active Task が残っている場合に限り、`pending_history_appends` が `<system-reminder>` を含む `Item::system_message` を 1件返す
-- 返された Item が `worker.history` に append され、その後のリクエスト・`history.json`・resume 後の `get_history` でも同じ Item が見える（揮発レーンは持たない）
-- `TaskCreate` / `TaskUpdate` のいずれかが呼ばれるとカウンタがリセットされ、再び N リクエスト経過するまでは reminder が出ない
-- reminder が一度出たあとは、cooldown M リクエストが経過するまで再注入されない
-- active Task が 0件の場合は reminder が出ない
-- 単体テストで Interceptor の発火条件（リクエスト回数閾値、active 0件、cooldown）がカバーされる
-
-## 範囲外
-
-- inprogress 滞留検出 / 多重 inprogress 検出など、状態異常ベースの追加トリガ（必要になれば別チケットで追加）
-- system-reminder 注入機構の汎用化（`TODO.md` に立項済み、別途検討）
-- `TaskCreate` / `TaskUpdate` の戻り値に active Task 全件を埋め込む強化（必要に応じて Tool ticket 側で対応）
-- サブエージェント / sidechain での独自 reminder 発火（main Pod の interceptor から動く構造のため自然に対象外）
-
-## 参照
-
-- 設計指針: `AGENTS.md`（LLM コンテキストの加工原則。揮発的注入は禁止、history に append してから commit する）
-- 前提: `tickets/session-todo.md`（Tool 群と TaskStore）、`tickets/notify-history-persist.md`（`pending_history_appends` レーン）
-- 参考: 一部エージェント実装の todo reminder は、一定リクエスト無アクティビティ後に発火し、再通知にも cooldown を置くナッジ型として扱われている

.yoi/tickets/00001KSKBPJQR/resolution.md

@@ -1,80 +0,0 @@
----
-id: 20260527-000011-session-todo-reminder
-slug: session-todo-reminder
-title: セッション内 Task ツールの注意機構
-status: closed
-kind: task
-priority: P2
-labels: [migrated]
-created_at: 2026-05-27T00:00:11Z
-updated_at: 2026-05-29T04:31:10Z
-assignee: null
-legacy_ticket: tickets/session-todo-reminder.md
----
-
-## Migration reference
-
-- legacy_ticket: tickets/session-todo-reminder.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# セッション内 Task ツールの注意機構
-
-## 背景
-
-`tickets/session-todo.md` で導入した Task ツール群があっても、LLM はそれを使わずに作業を続け得る。ツールを呼ばないまま会話が長引くと、
-
-- 開始した作業の `inprogress` がずっと放置されたままになる
-- 「やったつもり」になって `completed` への更新を忘れる
-- そもそも TaskStore の存在を忘れて、構造化を諦めて自由記述に回帰する
-
-OpenCode の todo は専用の注意機構を持たない（汎用 reminder 経由）。一方、一部の既存エージェント実装では todo reminder を「N リクエスト無アクティビティで初めて発火するナッジ型」として扱い、毎リクエスト押し戻しはしない。
-
-
-Insomnia でも同方針を採り、active Task が残っているのに `TaskCreate` / `TaskUpdate` が一定リクエスト呼ばれていない場合に限り、`<system-reminder>` Item を 1件 history に append する。「やったつもり」抑止と、トークン浪費・LLM の自律性侵害のバランスを取るため、毎リクエスト押し戻しはしない。
-
-## 前提
-
-- `tickets/session-todo.md` の TaskStore と `TaskCreate` / `TaskUpdate` / `TaskList` / `TaskGet` ツールが利用可能
-- `Interceptor::pending_history_appends` レーンが利用可能（`tickets/notify-history-persist.md` で導入済み）
-
-## 方針
-
-- **`pending_history_appends` で実装**。発火時に `<system-reminder>` ブロックを含む新規 system message Item を返し、Worker が `worker.history` に append する。Notify / PodEvent と同じレーンで永続化・resume・compaction が自動で揃う
-- **揮発的注入は採らない**（`AGENTS.md` 「LLM コンテキストの加工原則」で禁止。history に commit せずに context を変えると、resume 時に LLM の発言の根拠が再現できなくなる）
-- **system-reminder 注入機構の汎用化はやらない**。利用者が Task 1機構しかない段階で抽象を立てない（`AGENTS.md`「概念の追加は不在が問題になってから」）。タグ形式 `<system-reminder>...</system-reminder>` の規約は本実装で踏襲する
-- **発火はナッジ型**。N リクエスト無アクティビティで初めて発火し、cooldown も持つ
-
-## 要件
-
-### Interceptor
-
-- `pending_history_appends` で以下を **AND** で満たす場合のみ発動し、`<system-reminder>` ブロックを含む `Item::system_message` を 1件返す。条件外なら空 `Vec<Item>` を返す
-  - active Task（`pending` または `inprogress`）が 1件以上存在する
-  - 直近 N リクエスト（暫定 N=8）`TaskCreate` / `TaskUpdate` のいずれも呼ばれていない
-  - 前回 reminder Item の append から M リクエスト（暫定 M=8）以上経過
-- ここで言う「リクエスト」は LLM への 1回の推論呼び出し（assistant 応答 1回）の単位。1ユーザー発火内で tool ループが回れば、`tool_result` を受けて発火する次のリクエストもそれぞれ 1としてカウントする
-- カウンタは Pod 側の session-lifetime 状態として保持する（`requests_since_last_task_management` / `requests_since_last_reminder`）。resume 時は worker.history の逆走査で再計算するか 0 リセットで再開する。後者でも「初回ナッジが最大 N リクエスト遅れる」だけで挙動として致命ではない
-- 返す Item の本文は `<system-reminder>` で囲み、現在の active Task を `taskid` / `status` / `subject` を含む簡潔な形式で列挙する。`description` は長大化を避けるため省略してよい
-- active Task が空の場合は何も append しない（思い出させる対象が無いなら不要）
-
-## 完了条件
-
-- 直近 N リクエスト連続で `TaskCreate` / `TaskUpdate` が呼ばれず、かつ active Task が残っている場合に限り、`pending_history_appends` が `<system-reminder>` を含む `Item::system_message` を 1件返す
-- 返された Item が `worker.history` に append され、その後のリクエスト・`history.json`・resume 後の `get_history` でも同じ Item が見える（揮発レーンは持たない）
-- `TaskCreate` / `TaskUpdate` のいずれかが呼ばれるとカウンタがリセットされ、再び N リクエスト経過するまでは reminder が出ない
-- reminder が一度出たあとは、cooldown M リクエストが経過するまで再注入されない
-- active Task が 0件の場合は reminder が出ない
-- 単体テストで Interceptor の発火条件（リクエスト回数閾値、active 0件、cooldown）がカバーされる
-
-## 範囲外
-
-- inprogress 滞留検出 / 多重 inprogress 検出など、状態異常ベースの追加トリガ（必要になれば別チケットで追加）
-- system-reminder 注入機構の汎用化（`TODO.md` に立項済み、別途検討）
-- `TaskCreate` / `TaskUpdate` の戻り値に active Task 全件を埋め込む強化（必要に応じて Tool ticket 側で対応）
-- サブエージェント / sidechain での独自 reminder 発火（main Pod の interceptor から動く構造のため自然に対象外）
-
-## 参照
-
-- 設計指針: `AGENTS.md`（LLM コンテキストの加工原則。揮発的注入は禁止、history に append してから commit する）
-- 前提: `tickets/session-todo.md`（Tool 群と TaskStore）、`tickets/notify-history-persist.md`（`pending_history_appends` レーン）
-- 参考: 一部エージェント実装の todo reminder は、一定リクエスト無アクティビティ後に発火し、再通知にも cooldown を置くナッジ型として扱われている

.yoi/tickets/00001KSKBPJQR/thread.md

@@ -1,95 +0,0 @@
-<!-- event: migration author: tickets.sh-migration at: 2026-05-27T00:00:11Z -->
-
-## Migrated
-
-Migrated from tickets/session-todo-reminder.md. No legacy review file was present at migration time.
-
----
-
-<!-- event: close author: hare at: 2026-05-29T04:31:10Z status: closed -->
-
-## Closed
-
----
-id: 20260527-000011-session-todo-reminder
-slug: session-todo-reminder
-title: セッション内 Task ツールの注意機構
-status: closed
-kind: task
-priority: P2
-labels: [migrated]
-created_at: 2026-05-27T00:00:11Z
-updated_at: 2026-05-29T04:31:10Z
-assignee: null
-legacy_ticket: tickets/session-todo-reminder.md
----
-
-## Migration reference
-
-- legacy_ticket: tickets/session-todo-reminder.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# セッション内 Task ツールの注意機構
-
-## 背景
-
-`tickets/session-todo.md` で導入した Task ツール群があっても、LLM はそれを使わずに作業を続け得る。ツールを呼ばないまま会話が長引くと、
-
-- 開始した作業の `inprogress` がずっと放置されたままになる
-- 「やったつもり」になって `completed` への更新を忘れる
-- そもそも TaskStore の存在を忘れて、構造化を諦めて自由記述に回帰する
-
-OpenCode の todo は専用の注意機構を持たない（汎用 reminder 経由）。一方、一部の既存エージェント実装では todo reminder を「N リクエスト無アクティビティで初めて発火するナッジ型」として扱い、毎リクエスト押し戻しはしない。
-
-
-Insomnia でも同方針を採り、active Task が残っているのに `TaskCreate` / `TaskUpdate` が一定リクエスト呼ばれていない場合に限り、`<system-reminder>` Item を 1件 history に append する。「やったつもり」抑止と、トークン浪費・LLM の自律性侵害のバランスを取るため、毎リクエスト押し戻しはしない。
-
-## 前提
-
-- `tickets/session-todo.md` の TaskStore と `TaskCreate` / `TaskUpdate` / `TaskList` / `TaskGet` ツールが利用可能
-- `Interceptor::pending_history_appends` レーンが利用可能（`tickets/notify-history-persist.md` で導入済み）
-
-## 方針
-
-- **`pending_history_appends` で実装**。発火時に `<system-reminder>` ブロックを含む新規 system message Item を返し、Worker が `worker.history` に append する。Notify / PodEvent と同じレーンで永続化・resume・compaction が自動で揃う
-- **揮発的注入は採らない**（`AGENTS.md` 「LLM コンテキストの加工原則」で禁止。history に commit せずに context を変えると、resume 時に LLM の発言の根拠が再現できなくなる）
-- **system-reminder 注入機構の汎用化はやらない**。利用者が Task 1機構しかない段階で抽象を立てない（`AGENTS.md`「概念の追加は不在が問題になってから」）。タグ形式 `<system-reminder>...</system-reminder>` の規約は本実装で踏襲する
-- **発火はナッジ型**。N リクエスト無アクティビティで初めて発火し、cooldown も持つ
-
-## 要件
-
-### Interceptor
-
-- `pending_history_appends` で以下を **AND** で満たす場合のみ発動し、`<system-reminder>` ブロックを含む `Item::system_message` を 1件返す。条件外なら空 `Vec<Item>` を返す
-  - active Task（`pending` または `inprogress`）が 1件以上存在する
-  - 直近 N リクエスト（暫定 N=8）`TaskCreate` / `TaskUpdate` のいずれも呼ばれていない
-  - 前回 reminder Item の append から M リクエスト（暫定 M=8）以上経過
-- ここで言う「リクエスト」は LLM への 1回の推論呼び出し（assistant 応答 1回）の単位。1ユーザー発火内で tool ループが回れば、`tool_result` を受けて発火する次のリクエストもそれぞれ 1としてカウントする
-- カウンタは Pod 側の session-lifetime 状態として保持する（`requests_since_last_task_management` / `requests_since_last_reminder`）。resume 時は worker.history の逆走査で再計算するか 0 リセットで再開する。後者でも「初回ナッジが最大 N リクエスト遅れる」だけで挙動として致命ではない
-- 返す Item の本文は `<system-reminder>` で囲み、現在の active Task を `taskid` / `status` / `subject` を含む簡潔な形式で列挙する。`description` は長大化を避けるため省略してよい
-- active Task が空の場合は何も append しない（思い出させる対象が無いなら不要）
-
-## 完了条件
-
-- 直近 N リクエスト連続で `TaskCreate` / `TaskUpdate` が呼ばれず、かつ active Task が残っている場合に限り、`pending_history_appends` が `<system-reminder>` を含む `Item::system_message` を 1件返す
-- 返された Item が `worker.history` に append され、その後のリクエスト・`history.json`・resume 後の `get_history` でも同じ Item が見える（揮発レーンは持たない）
-- `TaskCreate` / `TaskUpdate` のいずれかが呼ばれるとカウンタがリセットされ、再び N リクエスト経過するまでは reminder が出ない
-- reminder が一度出たあとは、cooldown M リクエストが経過するまで再注入されない
-- active Task が 0件の場合は reminder が出ない
-- 単体テストで Interceptor の発火条件（リクエスト回数閾値、active 0件、cooldown）がカバーされる
-
-## 範囲外
-
-- inprogress 滞留検出 / 多重 inprogress 検出など、状態異常ベースの追加トリガ（必要になれば別チケットで追加）
-- system-reminder 注入機構の汎用化（`TODO.md` に立項済み、別途検討）
-- `TaskCreate` / `TaskUpdate` の戻り値に active Task 全件を埋め込む強化（必要に応じて Tool ticket 側で対応）
-- サブエージェント / sidechain での独自 reminder 発火（main Pod の interceptor から動く構造のため自然に対象外）
-
-## 参照
-
-- 設計指針: `AGENTS.md`（LLM コンテキストの加工原則。揮発的注入は禁止、history に append してから commit する）
-- 前提: `tickets/session-todo.md`（Tool 群と TaskStore）、`tickets/notify-history-persist.md`（`pending_history_appends` レーン）
-- 参考: 一部エージェント実装の todo reminder は、一定リクエスト無アクティビティ後に発火し、再通知にも cooldown を置くナッジ型として扱われている
-
-
----

.yoi/tickets/00001KSKBPKQ0/item.md

@@ -1,77 +0,0 @@
----
-title: "SpawnPod: initial Run delivery confirmation"
-state: "closed"
-created_at: "2026-05-27T00:00:12Z"
-updated_at: "2026-05-28T13:24:48Z"
----
-
-## Migration reference
-
-- legacy_ticket: tickets/spawnpod-initial-run-confirmation.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# SpawnPod: initial Run delivery confirmation
-
-## 背景
-
-`SpawnPod` は child Pod を起動し、初回 task を `Method::Run` として送る。しかし、実例として `impl-llm-worker-stream-continuation` を再作成した際、runtime registry / socket / process は生きている一方で、初回 task の session log が materialize されず、Pod は `idle` のままだった。
-
-確認された状態:
-
-- `<runtime-dir>/pods.json` に live allocation がある
-- `<runtime-dir>/<pod>/status.json` は `state: "idle"` と runtime `segment_id` を持つ
-- `<insomnia-sessions>/pods/<pod>/metadata.json` は pending segment のまま
-- 対応する session / segment `.jsonl` が存在しない
-- `ReadPodOutput` は no new assistant text
-
-`SpawnPod` の送信側は `send_run` で `Method::Run` を write してすぐ切断し、`TurnStart` 等の ack を待っていない。一方 server 側は接続直後に `Snapshot` を書いてから method を読むため、client がすぐ close すると server が snapshot write で失敗し、method を読む前に connection handler が終了する race があり得る。
-
-この場合 `SpawnPod` は成功を返すが、child Pod は初回 task を実行していない。
-
-同種の問題は child Pod の通知経路でも既に踏んでおり、送信側が write 後にすぐ切断せず、receiver 側の acknowledgement / observable event を待つ形にして解消している。`SpawnPod` の初回 task delivery も同じ性質の race と見なす。
-
-追加確認として、Pod socket server は接続直後に replayed `Alert` と connect-time `Snapshot` を送ってから client `Method` を読む。したがって one-shot / send-only client は初期 event を消化してから Method を送る必要がある。
-
-- `send_run_and_confirm` は `Method::Run` を送った後に event を読む実装になっており、Snapshot が大きい場合や Run payload が大きい場合に双方向で詰まる余地がある。
-- `connect_and_send` / `fetch_history` は既に Snapshot まで drain / read しており、この系統の問題は対策済み。
-- `probe_socket` は最初の event だけを見て `Snapshot` でなければ status を取らないため、replayed `Alert` が先に来る live Pod で reachable だが status unknown になる可能性がある。
-- `PodClient::connect` は background reader を起動するため、通常の TUI attach / interactive client では初期 Snapshot を詰まらせにくい。
-
-## 方針
-
-`SpawnPod` は child process / socket の起動だけでなく、初回 task が controller に受理され、少なくとも `UserMessage` または `TurnStart` が観測できるまで確認してから成功を返す。
-
-既存の `SendToPod` / `SpawnPod` が使う run delivery confirmation ロジックを、接続直後の `Alert` / `Snapshot` drain を含む形へ共通化・安全化する。
-
-## 要件
-
-- `SpawnPod` の初回 task 送信は fire-and-forget にしない。
-  - `Method::Run` 送信後、`UserMessage` / `TurnStart` / `InvokeStart` など、run が受理されたことを示す event を待つ。
-  - timeout 時は `SpawnPod` を失敗扱いにする。
-- 初回 task delivery に失敗した場合、process / registry / delegated scope の扱いを明確にする。
-  - cleanup するか、attach 可能な idle Pod として残すかを実装で決める。
-  - 少なくとも成功扱いで返さない。
-- Server が connection 開始時に `Alert` / `Snapshot` を書く設計と競合しない。
-  - client 側が `Alert` / `Snapshot` を読みながら `Method::Run` ack を待つ形にする。
-  - `send_run_and_confirm` は connect-time `Snapshot` を消化してから `Method::Run` を送る。
-- live Pod status probe は replayed `Alert` によって status 取得を落とさない。
-  - `probe_socket` は first event だけで判断せず、`Snapshot` まで初期 event を読む。
-- `SpawnPod` 成功後は、child Pod の metadata が pending でも、初回 run が開始済みであることを確認できる。
-  - session log materialization のタイミングそのものは別設計でもよい。
-- `SendToPod` と `SpawnPod` の run delivery confirmation ロジックを可能な範囲で共通化する。
-
-## 完了条件
-
-- `SpawnPod` が初回 task の受理確認を待つ。
-- 初回 task が実行されない race を再現する test または regression test がある。
-- connect-time `Alert` / `Snapshot` がある状態でも `send_run_and_confirm` が詰まらず、受理 event を観測する regression test がある。
-- `probe_socket` が replayed `Alert` の後の `Snapshot` から status を取得できる regression test がある。
-- `SpawnPod` が success を返した後、child Pod が idle pending のまま task 未実行になる状態が起きない。
-- delivery timeout / failure 時の error message が人間に分かる。
-- `cargo fmt --check` と関連 crate の test が通る。
-
-## 範囲外
-
-- `tui -r` picker に live pending Pod を表示する修正。
-- session log の SegmentStart materialization 方針変更。
-- spawned child Pod panel UI。

.yoi/tickets/00001KSKBPKQ0/resolution.md

@@ -1,84 +0,0 @@
----
-id: 20260527-000012-spawnpod-initial-run-confirmation
-slug: spawnpod-initial-run-confirmation
-title: SpawnPod: initial Run delivery confirmation
-status: closed
-kind: task
-priority: P2
-labels: [migrated]
-created_at: 2026-05-27T00:00:12Z
-updated_at: 2026-05-28T13:24:48Z
-assignee: null
-legacy_ticket: tickets/spawnpod-initial-run-confirmation.md
----
-
-## Migration reference
-
-- legacy_ticket: tickets/spawnpod-initial-run-confirmation.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# SpawnPod: initial Run delivery confirmation
-
-## 背景
-
-`SpawnPod` は child Pod を起動し、初回 task を `Method::Run` として送る。しかし、実例として `impl-llm-worker-stream-continuation` を再作成した際、runtime registry / socket / process は生きている一方で、初回 task の session log が materialize されず、Pod は `idle` のままだった。
-
-確認された状態:
-
-- `<runtime-dir>/pods.json` に live allocation がある
-- `<runtime-dir>/<pod>/status.json` は `state: "idle"` と runtime `segment_id` を持つ
-- `<insomnia-sessions>/pods/<pod>/metadata.json` は pending segment のまま
-- 対応する session / segment `.jsonl` が存在しない
-- `ReadPodOutput` は no new assistant text
-
-`SpawnPod` の送信側は `send_run` で `Method::Run` を write してすぐ切断し、`TurnStart` 等の ack を待っていない。一方 server 側は接続直後に `Snapshot` を書いてから method を読むため、client がすぐ close すると server が snapshot write で失敗し、method を読む前に connection handler が終了する race があり得る。
-
-この場合 `SpawnPod` は成功を返すが、child Pod は初回 task を実行していない。
-
-同種の問題は child Pod の通知経路でも既に踏んでおり、送信側が write 後にすぐ切断せず、receiver 側の acknowledgement / observable event を待つ形にして解消している。`SpawnPod` の初回 task delivery も同じ性質の race と見なす。
-
-追加確認として、Pod socket server は接続直後に replayed `Alert` と connect-time `Snapshot` を送ってから client `Method` を読む。したがって one-shot / send-only client は初期 event を消化してから Method を送る必要がある。
-
-- `send_run_and_confirm` は `Method::Run` を送った後に event を読む実装になっており、Snapshot が大きい場合や Run payload が大きい場合に双方向で詰まる余地がある。
-- `connect_and_send` / `fetch_history` は既に Snapshot まで drain / read しており、この系統の問題は対策済み。
-- `probe_socket` は最初の event だけを見て `Snapshot` でなければ status を取らないため、replayed `Alert` が先に来る live Pod で reachable だが status unknown になる可能性がある。
-- `PodClient::connect` は background reader を起動するため、通常の TUI attach / interactive client では初期 Snapshot を詰まらせにくい。
-
-## 方針
-
-`SpawnPod` は child process / socket の起動だけでなく、初回 task が controller に受理され、少なくとも `UserMessage` または `TurnStart` が観測できるまで確認してから成功を返す。
-
-既存の `SendToPod` / `SpawnPod` が使う run delivery confirmation ロジックを、接続直後の `Alert` / `Snapshot` drain を含む形へ共通化・安全化する。
-
-## 要件
-
-- `SpawnPod` の初回 task 送信は fire-and-forget にしない。
-  - `Method::Run` 送信後、`UserMessage` / `TurnStart` / `InvokeStart` など、run が受理されたことを示す event を待つ。
-  - timeout 時は `SpawnPod` を失敗扱いにする。
-- 初回 task delivery に失敗した場合、process / registry / delegated scope の扱いを明確にする。
-  - cleanup するか、attach 可能な idle Pod として残すかを実装で決める。
-  - 少なくとも成功扱いで返さない。
-- Server が connection 開始時に `Alert` / `Snapshot` を書く設計と競合しない。
-  - client 側が `Alert` / `Snapshot` を読みながら `Method::Run` ack を待つ形にする。
-  - `send_run_and_confirm` は connect-time `Snapshot` を消化してから `Method::Run` を送る。
-- live Pod status probe は replayed `Alert` によって status 取得を落とさない。
-  - `probe_socket` は first event だけで判断せず、`Snapshot` まで初期 event を読む。
-- `SpawnPod` 成功後は、child Pod の metadata が pending でも、初回 run が開始済みであることを確認できる。
-  - session log materialization のタイミングそのものは別設計でもよい。
-- `SendToPod` と `SpawnPod` の run delivery confirmation ロジックを可能な範囲で共通化する。
-
-## 完了条件
-
-- `SpawnPod` が初回 task の受理確認を待つ。
-- 初回 task が実行されない race を再現する test または regression test がある。
-- connect-time `Alert` / `Snapshot` がある状態でも `send_run_and_confirm` が詰まらず、受理 event を観測する regression test がある。
-- `probe_socket` が replayed `Alert` の後の `Snapshot` から status を取得できる regression test がある。
-- `SpawnPod` が success を返した後、child Pod が idle pending のまま task 未実行になる状態が起きない。
-- delivery timeout / failure 時の error message が人間に分かる。
-- `cargo fmt --check` と関連 crate の test が通る。
-
-## 範囲外
-
-- `tui -r` picker に live pending Pod を表示する修正。
-- session log の SegmentStart materialization 方針変更。
-- spawned child Pod panel UI。

.yoi/tickets/00001KSKBPKQ0/thread.md

@@ -1,99 +0,0 @@
-<!-- event: migration author: tickets.sh-migration at: 2026-05-27T00:00:12Z -->
-
-## Migrated
-
-Migrated from tickets/spawnpod-initial-run-confirmation.md. No legacy review file was present at migration time.
-
----
-
-<!-- event: close author: hare at: 2026-05-28T13:24:48Z status: closed -->
-
-## Closed
-
----
-id: 20260527-000012-spawnpod-initial-run-confirmation
-slug: spawnpod-initial-run-confirmation
-title: SpawnPod: initial Run delivery confirmation
-status: closed
-kind: task
-priority: P2
-labels: [migrated]
-created_at: 2026-05-27T00:00:12Z
-updated_at: 2026-05-28T13:24:48Z
-assignee: null
-legacy_ticket: tickets/spawnpod-initial-run-confirmation.md
----
-
-## Migration reference
-
-- legacy_ticket: tickets/spawnpod-initial-run-confirmation.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# SpawnPod: initial Run delivery confirmation
-
-## 背景
-
-`SpawnPod` は child Pod を起動し、初回 task を `Method::Run` として送る。しかし、実例として `impl-llm-worker-stream-continuation` を再作成した際、runtime registry / socket / process は生きている一方で、初回 task の session log が materialize されず、Pod は `idle` のままだった。
-
-確認された状態:
-
-- `<runtime-dir>/pods.json` に live allocation がある
-- `<runtime-dir>/<pod>/status.json` は `state: "idle"` と runtime `segment_id` を持つ
-- `<insomnia-sessions>/pods/<pod>/metadata.json` は pending segment のまま
-- 対応する session / segment `.jsonl` が存在しない
-- `ReadPodOutput` は no new assistant text
-
-`SpawnPod` の送信側は `send_run` で `Method::Run` を write してすぐ切断し、`TurnStart` 等の ack を待っていない。一方 server 側は接続直後に `Snapshot` を書いてから method を読むため、client がすぐ close すると server が snapshot write で失敗し、method を読む前に connection handler が終了する race があり得る。
-
-この場合 `SpawnPod` は成功を返すが、child Pod は初回 task を実行していない。
-
-同種の問題は child Pod の通知経路でも既に踏んでおり、送信側が write 後にすぐ切断せず、receiver 側の acknowledgement / observable event を待つ形にして解消している。`SpawnPod` の初回 task delivery も同じ性質の race と見なす。
-
-追加確認として、Pod socket server は接続直後に replayed `Alert` と connect-time `Snapshot` を送ってから client `Method` を読む。したがって one-shot / send-only client は初期 event を消化してから Method を送る必要がある。
-
-- `send_run_and_confirm` は `Method::Run` を送った後に event を読む実装になっており、Snapshot が大きい場合や Run payload が大きい場合に双方向で詰まる余地がある。
-- `connect_and_send` / `fetch_history` は既に Snapshot まで drain / read しており、この系統の問題は対策済み。
-- `probe_socket` は最初の event だけを見て `Snapshot` でなければ status を取らないため、replayed `Alert` が先に来る live Pod で reachable だが status unknown になる可能性がある。
-- `PodClient::connect` は background reader を起動するため、通常の TUI attach / interactive client では初期 Snapshot を詰まらせにくい。
-
-## 方針
-
-`SpawnPod` は child process / socket の起動だけでなく、初回 task が controller に受理され、少なくとも `UserMessage` または `TurnStart` が観測できるまで確認してから成功を返す。
-
-既存の `SendToPod` / `SpawnPod` が使う run delivery confirmation ロジックを、接続直後の `Alert` / `Snapshot` drain を含む形へ共通化・安全化する。
-
-## 要件
-
-- `SpawnPod` の初回 task 送信は fire-and-forget にしない。
-  - `Method::Run` 送信後、`UserMessage` / `TurnStart` / `InvokeStart` など、run が受理されたことを示す event を待つ。
-  - timeout 時は `SpawnPod` を失敗扱いにする。
-- 初回 task delivery に失敗した場合、process / registry / delegated scope の扱いを明確にする。
-  - cleanup するか、attach 可能な idle Pod として残すかを実装で決める。
-  - 少なくとも成功扱いで返さない。
-- Server が connection 開始時に `Alert` / `Snapshot` を書く設計と競合しない。
-  - client 側が `Alert` / `Snapshot` を読みながら `Method::Run` ack を待つ形にする。
-  - `send_run_and_confirm` は connect-time `Snapshot` を消化してから `Method::Run` を送る。
-- live Pod status probe は replayed `Alert` によって status 取得を落とさない。
-  - `probe_socket` は first event だけで判断せず、`Snapshot` まで初期 event を読む。
-- `SpawnPod` 成功後は、child Pod の metadata が pending でも、初回 run が開始済みであることを確認できる。
-  - session log materialization のタイミングそのものは別設計でもよい。
-- `SendToPod` と `SpawnPod` の run delivery confirmation ロジックを可能な範囲で共通化する。
-
-## 完了条件
-
-- `SpawnPod` が初回 task の受理確認を待つ。
-- 初回 task が実行されない race を再現する test または regression test がある。
-- connect-time `Alert` / `Snapshot` がある状態でも `send_run_and_confirm` が詰まらず、受理 event を観測する regression test がある。
-- `probe_socket` が replayed `Alert` の後の `Snapshot` から status を取得できる regression test がある。
-- `SpawnPod` が success を返した後、child Pod が idle pending のまま task 未実行になる状態が起きない。
-- delivery timeout / failure 時の error message が人間に分かる。
-- `cargo fmt --check` と関連 crate の test が通る。
-
-## 範囲外
-
-- `tui -r` picker に live pending Pod を表示する修正。
-- session log の SegmentStart materialization 方針変更。
-- spawned child Pod panel UI。
-
-
----

.yoi/tickets/00001KSKBPMP8/item.md

@@ -1,203 +0,0 @@
----
-title: "Ticket 管理: tickets.sh による WorkItem / Thread MVP"
-state: "closed"
-created_at: "2026-05-27T00:00:13Z"
-updated_at: "2026-05-27T19:28:41Z"
----
-
-## Migration reference
-
-- legacy_ticket: tickets/tickets-sh-workitem-thread-mvp.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# Ticket 管理: tickets.sh による WorkItem / Thread MVP
-
-## 背景
-
-現在の ticket 運用は `TODO.md` と `tickets/*.md`、必要に応じて `tickets/*.review.md` を Git 履歴で管理している。要件と完了条件を追うには機能しているが、multi-agent worktree workflow と組み合わせると review / 修正依頼 / 実装報告が扱いづらい。
-
-特に `.review.md` は、review artifact を main workspace の ticket directory に作る必要がある。一方で実装 Pod は child worktree だけに write scope を持つため、review thread と実装 thread が分断されやすい。子 Pod を止めて scope を回収し、review file を作り、再度 restore / spawn するような運用になりがちで面倒である。
-
-Git は履歴の保存層として有用だが、人間や AI maintainer が毎回 file move / delete / review file 作成 / git log 探索を直接操作するのは低級すぎる。repository 内の file backend を正本にしつつ、`tickets.sh` で create / list / show / comment / review / close などの意味的操作を提供する。
-
-この ticket は `docs/plan/maintainer-work-items.md` の抽象メモを踏まえた最小実装である。既存 `TODO.md` / `tickets/` を併用したまま新規領域を試すのではなく、今回の MVP では既存 `TODO.md` / `tickets/*.md` を手動で `work-items/` に移し、`tickets.sh doctor` が通る状態までをゴールにする。
-
-## 方針
-
-- 新しい正本は repo root の `work-items/` に置く。
-- 既存 `TODO.md` / `tickets/*.md` は手動 migration の入力として扱う。
-- migration 完了後、`TODO.md` は残す場合でも legacy / generated view 相当の最小内容にする。少なくとも未完了 item の正本を `tickets/*.md` に残さない。
-- `tickets.sh` は Git を内部保存層として前提にしてよいが、操作単位は file path ではなく WorkItem 操作にする。
-- 初期実装では自動 commit しない。
-  - `tickets.sh` は file 操作まで。
-  - `git add/commit` は利用者または追加指示に任せる。
-- `--help` だけで基本操作と migration 方針が分かるようにする。
-- shell script なので依存は POSIX shell + 基本 Unix tool に寄せる。`jq` 必須にはしない。
-- 既存 `tickets/*.review.md` がある場合は、対象 WorkItem の `thread.md` に review event として手動で移す。
-
-## backend schema
-
-```text
-work-items/
-  README.md
-  open/
-    20260526-123456-short-slug/
-      item.md
-      thread.md
-      artifacts/
-  pending/
-    ...
-  closed/
-    ...
-      resolution.md
-      artifacts/
-```
-
-`item.md` は YAML frontmatter + Markdown body。
-
-```yaml
----
-id: 20260526-123456-short-slug
-slug: short-slug
-title: Human-readable title
-status: open
-kind: feature
-priority: P2
-labels: [maintainer, workflow]
-created_at: 2026-05-26T12:34:56Z
-updated_at: 2026-05-26T12:34:56Z
-assignee: null
----
-
-## Background
-
-...
-
-## Acceptance criteria
-
-- ...
-```
-
-`legacy_ticket` は migration 直後の追跡用 metadata とする。移行元 file は Git history で参照できるため、migration commit 後に `tickets/foo.md` を残し続けない。
-
-`thread.md` は append-only Markdown event log とする。JSONL より人間が読みやすいことを優先する。
-
-```md
-<!-- event: comment author: hare at: 2026-05-26T12:40:00Z -->
-
-## Comment
-
-...
-
----
-
-<!-- event: review author: orchestrator at: 2026-05-26T13:00:00Z status: request_changes -->
-
-## Review: request changes
-
-...
-```
-
-`tickets.sh` が必ず event header と separator を付ける。機械 parse は初期実装では簡易でよい。
-
-## コマンド MVP
-
-```text
-./tickets.sh help
-./tickets.sh list [--status open|pending|closed|all]
-./tickets.sh show <id-or-slug>
-./tickets.sh create --title <title> [--slug <slug>] [--kind <kind>] [--priority P2] [--label a,b]
-./tickets.sh comment <id-or-slug> [--role comment|plan|decision|implementation_report] [--author <name>] [--file <path>]
-./tickets.sh review <id-or-slug> --approve|--request-changes [--author <name>] [--file <path>]
-./tickets.sh status <id-or-slug> open|pending|closed
-./tickets.sh close <id-or-slug> [--resolution <text>|--file <path>]
-./tickets.sh doctor
-```
-
-`help` / `--help` は同じ内容を出す。
-
-### list
-
-- `work-items/{open,pending,closed}/*/item.md` を scan する。
-- status / id / slug / title / kind / priority / updated_at を一行で表示する。
-- 初期実装では frontmatter parser は簡易でよい。
-
-### show
-
-- `item.md` と `thread.md` の末尾を読みやすく表示する。
-- 完全な thread 全体を出すか、初期は tail 表示でもよい。`--all` は後続でよい。
-
-### create
-
-- ID は `YYYYMMDD-HHMMSS-<slug>`。
-- 同一 path が存在する場合は短い random suffix または pid suffix を付けて衝突回避する。
-- `work-items/open/<id>/item.md`, `thread.md`, `artifacts/` を作る。
-- central `SEQUENCE` は作らない。
-
-### comment / review
-
-- `thread.md` に append する。
-- `item.md` の `updated_at` を更新する。
-- review は role/comment の special case として、`approve` / `request_changes` が分かる event header を付ける。
-- `.review.md` は作らない。
-
-### status / close
-
-- status directory を move する。
-- `item.md` frontmatter の `status` と `updated_at` を更新する。
-- `close` は `status closed` + optional `resolution.md` + close event append。
-- 完了しても削除しない。
-
-### doctor
-
-- directory status と frontmatter `status` の一致を検査する。
-- `item.md` / `thread.md` / `artifacts/` の存在を検査する。
-- duplicate slug / duplicate id を検査する。
-- `TODO.md` / `tickets/*.md` に未移行の未完了 ticket が残っていないことを検査する。
-- `tickets/*.review.md` が残っていないことを検査する。
-- work-items 配下の markdown frontmatter に必須 field があることを検査する。
-- error は非ゼロ exit。
-
-## 手動 migration 要件
-
-この ticket の作業には既存運用からの手動 migration を含める。
-
-- 現在 `TODO.md` に載っている未完了 ticket を `work-items/open/` に移す。
-- 各 `tickets/*.md` の本文を対応する `item.md` に移す。
-- 既存 `tickets/*.review.md` があれば対応する `thread.md` に review event として移す。
-- 移行元 ticket path は `legacy_ticket` metadata または本文の参照欄に残す。
-- migration commit 後、未完了 work item の正本として `tickets/*.md` を残さない。
-- `TODO.md` は legacy notice / generated view 相当の最小内容に更新する。
-- `tickets.sh doctor` が repository の移行状態まで含めて 0 になることをゴールにする。
-
-## 要件
-
-- `tickets.sh --help` で使い方と migration 後の配置が分かる。
-- `create/list/show/comment/review/status/close/doctor` が動く。
-- WorkItem ID は timestamp-based で、central sequence file を使わない。
-- close しても削除せず `work-items/closed/` に移動する。
-- review は `.review.md` ではなく thread event として append できる。
-- `doctor` が directory status と frontmatter status の不一致を検出する。
-- `doctor` が未移行 `TODO.md` / `tickets/*.md` / `tickets/*.review.md` を検出する。
-- 初期実装では自動 git commit しない。
-- README 相当の usage は `--help` または `work-items/README.md` に含める。
-
-## 完了条件
-
-- repo root に `tickets.sh` が追加される。
-- `work-items/README.md` で schema / migration 後の運用が説明される。
-- `tickets.sh create` で WorkItem を作成できる。
-- `tickets.sh comment` / `tickets.sh review` で thread event を append できる。
-- `tickets.sh close` で closed に移動できる。
-- 既存 `TODO.md` / `tickets/*.md` / `tickets/*.review.md` が手動で `work-items/` に移行される。
-- migration 後、`tickets.sh doctor` が repository 全体の状態に対して 0 になる。
-- 不整合 fixture または smoke test で `doctor` が非ゼロになることを確認する。
-- shellcheck が利用可能なら通る。無い場合は少なくとも focused smoke test を実行する。
-
-## 範囲外
-
-- Rust crate / DB / remote backend 実装。
-- LeaseStore / Pod run tracking の実装。
-- Git commit の自動化。
-- TUI 統合。
-- WorkItem から TODO.md を自動生成する仕組み。

.yoi/tickets/00001KSKBPMP8/resolution.md

@@ -1,211 +0,0 @@
----
-id: 20260527-000013-tickets-sh-workitem-thread-mvp
-slug: tickets-sh-workitem-thread-mvp
-title: Ticket 管理: tickets.sh による WorkItem / Thread MVP
-status: closed
-kind: task
-priority: P2
-labels: [migrated]
-created_at: 2026-05-27T00:00:13Z
-updated_at: 2026-05-27T19:28:41Z
-assignee: null
-legacy_ticket: tickets/tickets-sh-workitem-thread-mvp.md
----
-
-## Migration reference
-
-- legacy_ticket: tickets/tickets-sh-workitem-thread-mvp.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# Ticket 管理: tickets.sh による WorkItem / Thread MVP
-
-## 背景
-
-現在の ticket 運用は `TODO.md` と `tickets/*.md`、必要に応じて `tickets/*.review.md` を Git 履歴で管理している。要件と完了条件を追うには機能しているが、multi-agent worktree workflow と組み合わせると review / 修正依頼 / 実装報告が扱いづらい。
-
-特に `.review.md` は、review artifact を main workspace の ticket directory に作る必要がある。一方で実装 Pod は child worktree だけに write scope を持つため、review thread と実装 thread が分断されやすい。子 Pod を止めて scope を回収し、review file を作り、再度 restore / spawn するような運用になりがちで面倒である。
-
-Git は履歴の保存層として有用だが、人間や AI maintainer が毎回 file move / delete / review file 作成 / git log 探索を直接操作するのは低級すぎる。repository 内の file backend を正本にしつつ、`tickets.sh` で create / list / show / comment / review / close などの意味的操作を提供する。
-
-この ticket は `docs/plan/maintainer-work-items.md` の抽象メモを踏まえた最小実装である。既存 `TODO.md` / `tickets/` を併用したまま新規領域を試すのではなく、今回の MVP では既存 `TODO.md` / `tickets/*.md` を手動で `work-items/` に移し、`tickets.sh doctor` が通る状態までをゴールにする。
-
-## 方針
-
-- 新しい正本は repo root の `work-items/` に置く。
-- 既存 `TODO.md` / `tickets/*.md` は手動 migration の入力として扱う。
-- migration 完了後、`TODO.md` は残す場合でも legacy / generated view 相当の最小内容にする。少なくとも未完了 item の正本を `tickets/*.md` に残さない。
-- `tickets.sh` は Git を内部保存層として前提にしてよいが、操作単位は file path ではなく WorkItem 操作にする。
-- 初期実装では自動 commit しない。
-  - `tickets.sh` は file 操作まで。
-  - `git add/commit` は利用者または追加指示に任せる。
-- `--help` だけで基本操作と migration 方針が分かるようにする。
-- shell script なので依存は POSIX shell + 基本 Unix tool に寄せる。`jq` 必須にはしない。
-- 既存 `tickets/*.review.md` がある場合は、対象 WorkItem の `thread.md` に review event として手動で移す。
-
-## backend schema
-
-```text
-work-items/
-  README.md
-  open/
-    20260526-123456-short-slug/
-      item.md
-      thread.md
-      artifacts/
-  pending/
-    ...
-  closed/
-    ...
-      resolution.md
-      artifacts/
-```
-
-`item.md` は YAML frontmatter + Markdown body。
-
-```yaml
----
-id: 20260526-123456-short-slug
-slug: short-slug
-title: Human-readable title
-status: open
-kind: feature
-priority: P2
-labels: [maintainer, workflow]
-created_at: 2026-05-26T12:34:56Z
-updated_at: 2026-05-26T12:34:56Z
-assignee: null
-legacy_ticket: tickets/foo.md
----
-
-## Background
-
-...
-
-## Acceptance criteria
-
-- ...
-```
-
-`legacy_ticket` は migration 直後の追跡用 metadata とする。移行元 file は Git history で参照できるため、migration commit 後に `tickets/foo.md` を残し続けない。
-
-`thread.md` は append-only Markdown event log とする。JSONL より人間が読みやすいことを優先する。
-
-```md
-<!-- event: comment author: hare at: 2026-05-26T12:40:00Z -->
-
-## Comment
-
-...
-
----
-
-<!-- event: review author: orchestrator at: 2026-05-26T13:00:00Z status: request_changes -->
-
-## Review: request changes
-
-...
-```
-
-`tickets.sh` が必ず event header と separator を付ける。機械 parse は初期実装では簡易でよい。
-
-## コマンド MVP
-
-```text
-./tickets.sh help
-./tickets.sh list [--status open|pending|closed|all]
-./tickets.sh show <id-or-slug>
-./tickets.sh create --title <title> [--slug <slug>] [--kind <kind>] [--priority P2] [--label a,b]
-./tickets.sh comment <id-or-slug> [--role comment|plan|decision|implementation_report] [--author <name>] [--file <path>]
-./tickets.sh review <id-or-slug> --approve|--request-changes [--author <name>] [--file <path>]
-./tickets.sh status <id-or-slug> open|pending|closed
-./tickets.sh close <id-or-slug> [--resolution <text>|--file <path>]
-./tickets.sh doctor
-```
-
-`help` / `--help` は同じ内容を出す。
-
-### list
-
-- `work-items/{open,pending,closed}/*/item.md` を scan する。
-- status / id / slug / title / kind / priority / updated_at を一行で表示する。
-- 初期実装では frontmatter parser は簡易でよい。
-
-### show
-
-- `item.md` と `thread.md` の末尾を読みやすく表示する。
-- 完全な thread 全体を出すか、初期は tail 表示でもよい。`--all` は後続でよい。
-
-### create
-
-- ID は `YYYYMMDD-HHMMSS-<slug>`。
-- 同一 path が存在する場合は短い random suffix または pid suffix を付けて衝突回避する。
-- `work-items/open/<id>/item.md`, `thread.md`, `artifacts/` を作る。
-- central `SEQUENCE` は作らない。
-
-### comment / review
-
-- `thread.md` に append する。
-- `item.md` の `updated_at` を更新する。
-- review は role/comment の special case として、`approve` / `request_changes` が分かる event header を付ける。
-- `.review.md` は作らない。
-
-### status / close
-
-- status directory を move する。
-- `item.md` frontmatter の `status` と `updated_at` を更新する。
-- `close` は `status closed` + optional `resolution.md` + close event append。
-- 完了しても削除しない。
-
-### doctor
-
-- directory status と frontmatter `status` の一致を検査する。
-- `item.md` / `thread.md` / `artifacts/` の存在を検査する。
-- duplicate slug / duplicate id を検査する。
-- `TODO.md` / `tickets/*.md` に未移行の未完了 ticket が残っていないことを検査する。
-- `tickets/*.review.md` が残っていないことを検査する。
-- work-items 配下の markdown frontmatter に必須 field があることを検査する。
-- error は非ゼロ exit。
-
-## 手動 migration 要件
-
-この ticket の作業には既存運用からの手動 migration を含める。
-
-- 現在 `TODO.md` に載っている未完了 ticket を `work-items/open/` に移す。
-- 各 `tickets/*.md` の本文を対応する `item.md` に移す。
-- 既存 `tickets/*.review.md` があれば対応する `thread.md` に review event として移す。
-- 移行元 ticket path は `legacy_ticket` metadata または本文の参照欄に残す。
-- migration commit 後、未完了 work item の正本として `tickets/*.md` を残さない。
-- `TODO.md` は legacy notice / generated view 相当の最小内容に更新する。
-- `tickets.sh doctor` が repository の移行状態まで含めて 0 になることをゴールにする。
-
-## 要件
-
-- `tickets.sh --help` で使い方と migration 後の配置が分かる。
-- `create/list/show/comment/review/status/close/doctor` が動く。
-- WorkItem ID は timestamp-based で、central sequence file を使わない。
-- close しても削除せず `work-items/closed/` に移動する。
-- review は `.review.md` ではなく thread event として append できる。
-- `doctor` が directory status と frontmatter status の不一致を検出する。
-- `doctor` が未移行 `TODO.md` / `tickets/*.md` / `tickets/*.review.md` を検出する。
-- 初期実装では自動 git commit しない。
-- README 相当の usage は `--help` または `work-items/README.md` に含める。
-
-## 完了条件
-
-- repo root に `tickets.sh` が追加される。
-- `work-items/README.md` で schema / migration 後の運用が説明される。
-- `tickets.sh create` で WorkItem を作成できる。
-- `tickets.sh comment` / `tickets.sh review` で thread event を append できる。
-- `tickets.sh close` で closed に移動できる。
-- 既存 `TODO.md` / `tickets/*.md` / `tickets/*.review.md` が手動で `work-items/` に移行される。
-- migration 後、`tickets.sh doctor` が repository 全体の状態に対して 0 になる。
-- 不整合 fixture または smoke test で `doctor` が非ゼロになることを確認する。
-- shellcheck が利用可能なら通る。無い場合は少なくとも focused smoke test を実行する。
-
-## 範囲外
-
-- Rust crate / DB / remote backend 実装。
-- LeaseStore / Pod run tracking の実装。
-- Git commit の自動化。
-- TUI 統合。
-- WorkItem から TODO.md を自動生成する仕組み。

.yoi/tickets/00001KSKBPMP8/thread.md

@@ -1,226 +0,0 @@
-<!-- event: migration author: tickets.sh-migration at: 2026-05-27T00:00:13Z -->
-
-## Migrated
-
-Migrated from tickets/tickets-sh-workitem-thread-mvp.md. No legacy review file was present at migration time.
-
----
-
-<!-- event: close author: hare at: 2026-05-27T19:28:41Z status: closed -->
-
-## Closed
-
----
-id: 20260527-000013-tickets-sh-workitem-thread-mvp
-slug: tickets-sh-workitem-thread-mvp
-title: Ticket 管理: tickets.sh による WorkItem / Thread MVP
-status: closed
-kind: task
-priority: P2
-labels: [migrated]
-created_at: 2026-05-27T00:00:13Z
-updated_at: 2026-05-27T19:28:41Z
-assignee: null
-legacy_ticket: tickets/tickets-sh-workitem-thread-mvp.md
----
-
-## Migration reference
-
-- legacy_ticket: tickets/tickets-sh-workitem-thread-mvp.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# Ticket 管理: tickets.sh による WorkItem / Thread MVP
-
-## 背景
-
-現在の ticket 運用は `TODO.md` と `tickets/*.md`、必要に応じて `tickets/*.review.md` を Git 履歴で管理している。要件と完了条件を追うには機能しているが、multi-agent worktree workflow と組み合わせると review / 修正依頼 / 実装報告が扱いづらい。
-
-特に `.review.md` は、review artifact を main workspace の ticket directory に作る必要がある。一方で実装 Pod は child worktree だけに write scope を持つため、review thread と実装 thread が分断されやすい。子 Pod を止めて scope を回収し、review file を作り、再度 restore / spawn するような運用になりがちで面倒である。
-
-Git は履歴の保存層として有用だが、人間や AI maintainer が毎回 file move / delete / review file 作成 / git log 探索を直接操作するのは低級すぎる。repository 内の file backend を正本にしつつ、`tickets.sh` で create / list / show / comment / review / close などの意味的操作を提供する。
-
-この ticket は `docs/plan/maintainer-work-items.md` の抽象メモを踏まえた最小実装である。既存 `TODO.md` / `tickets/` を併用したまま新規領域を試すのではなく、今回の MVP では既存 `TODO.md` / `tickets/*.md` を手動で `work-items/` に移し、`tickets.sh doctor` が通る状態までをゴールにする。
-
-## 方針
-
-- 新しい正本は repo root の `work-items/` に置く。
-- 既存 `TODO.md` / `tickets/*.md` は手動 migration の入力として扱う。
-- migration 完了後、`TODO.md` は残す場合でも legacy / generated view 相当の最小内容にする。少なくとも未完了 item の正本を `tickets/*.md` に残さない。
-- `tickets.sh` は Git を内部保存層として前提にしてよいが、操作単位は file path ではなく WorkItem 操作にする。
-- 初期実装では自動 commit しない。
-  - `tickets.sh` は file 操作まで。
-  - `git add/commit` は利用者または追加指示に任せる。
-- `--help` だけで基本操作と migration 方針が分かるようにする。
-- shell script なので依存は POSIX shell + 基本 Unix tool に寄せる。`jq` 必須にはしない。
-- 既存 `tickets/*.review.md` がある場合は、対象 WorkItem の `thread.md` に review event として手動で移す。
-
-## backend schema
-
-```text
-work-items/
-  README.md
-  open/
-    20260526-123456-short-slug/
-      item.md
-      thread.md
-      artifacts/
-  pending/
-    ...
-  closed/
-    ...
-      resolution.md
-      artifacts/
-```
-
-`item.md` は YAML frontmatter + Markdown body。
-
-```yaml
----
-id: 20260526-123456-short-slug
-slug: short-slug
-title: Human-readable title
-status: open
-kind: feature
-priority: P2
-labels: [maintainer, workflow]
-created_at: 2026-05-26T12:34:56Z
-updated_at: 2026-05-26T12:34:56Z
-assignee: null
-legacy_ticket: tickets/foo.md
----
-
-## Background
-
-...
-
-## Acceptance criteria
-
-- ...
-```
-
-`legacy_ticket` は migration 直後の追跡用 metadata とする。移行元 file は Git history で参照できるため、migration commit 後に `tickets/foo.md` を残し続けない。
-
-`thread.md` は append-only Markdown event log とする。JSONL より人間が読みやすいことを優先する。
-
-```md
-<!-- event: comment author: hare at: 2026-05-26T12:40:00Z -->
-
-## Comment
-
-...
-
----
-
-<!-- event: review author: orchestrator at: 2026-05-26T13:00:00Z status: request_changes -->
-
-## Review: request changes
-
-...
-```
-
-`tickets.sh` が必ず event header と separator を付ける。機械 parse は初期実装では簡易でよい。
-
-## コマンド MVP
-
-```text
-./tickets.sh help
-./tickets.sh list [--status open|pending|closed|all]
-./tickets.sh show <id-or-slug>
-./tickets.sh create --title <title> [--slug <slug>] [--kind <kind>] [--priority P2] [--label a,b]
-./tickets.sh comment <id-or-slug> [--role comment|plan|decision|implementation_report] [--author <name>] [--file <path>]
-./tickets.sh review <id-or-slug> --approve|--request-changes [--author <name>] [--file <path>]
-./tickets.sh status <id-or-slug> open|pending|closed
-./tickets.sh close <id-or-slug> [--resolution <text>|--file <path>]
-./tickets.sh doctor
-```
-
-`help` / `--help` は同じ内容を出す。
-
-### list
-
-- `work-items/{open,pending,closed}/*/item.md` を scan する。
-- status / id / slug / title / kind / priority / updated_at を一行で表示する。
-- 初期実装では frontmatter parser は簡易でよい。
-
-### show
-
-- `item.md` と `thread.md` の末尾を読みやすく表示する。
-- 完全な thread 全体を出すか、初期は tail 表示でもよい。`--all` は後続でよい。
-
-### create
-
-- ID は `YYYYMMDD-HHMMSS-<slug>`。
-- 同一 path が存在する場合は短い random suffix または pid suffix を付けて衝突回避する。
-- `work-items/open/<id>/item.md`, `thread.md`, `artifacts/` を作る。
-- central `SEQUENCE` は作らない。
-
-### comment / review
-
-- `thread.md` に append する。
-- `item.md` の `updated_at` を更新する。
-- review は role/comment の special case として、`approve` / `request_changes` が分かる event header を付ける。
-- `.review.md` は作らない。
-
-### status / close
-
-- status directory を move する。
-- `item.md` frontmatter の `status` と `updated_at` を更新する。
-- `close` は `status closed` + optional `resolution.md` + close event append。
-- 完了しても削除しない。
-
-### doctor
-
-- directory status と frontmatter `status` の一致を検査する。
-- `item.md` / `thread.md` / `artifacts/` の存在を検査する。
-- duplicate slug / duplicate id を検査する。
-- `TODO.md` / `tickets/*.md` に未移行の未完了 ticket が残っていないことを検査する。
-- `tickets/*.review.md` が残っていないことを検査する。
-- work-items 配下の markdown frontmatter に必須 field があることを検査する。
-- error は非ゼロ exit。
-
-## 手動 migration 要件
-
-この ticket の作業には既存運用からの手動 migration を含める。
-
-- 現在 `TODO.md` に載っている未完了 ticket を `work-items/open/` に移す。
-- 各 `tickets/*.md` の本文を対応する `item.md` に移す。
-- 既存 `tickets/*.review.md` があれば対応する `thread.md` に review event として移す。
-- 移行元 ticket path は `legacy_ticket` metadata または本文の参照欄に残す。
-- migration commit 後、未完了 work item の正本として `tickets/*.md` を残さない。
-- `TODO.md` は legacy notice / generated view 相当の最小内容に更新する。
-- `tickets.sh doctor` が repository の移行状態まで含めて 0 になることをゴールにする。
-
-## 要件
-
-- `tickets.sh --help` で使い方と migration 後の配置が分かる。
-- `create/list/show/comment/review/status/close/doctor` が動く。
-- WorkItem ID は timestamp-based で、central sequence file を使わない。
-- close しても削除せず `work-items/closed/` に移動する。
-- review は `.review.md` ではなく thread event として append できる。
-- `doctor` が directory status と frontmatter status の不一致を検出する。
-- `doctor` が未移行 `TODO.md` / `tickets/*.md` / `tickets/*.review.md` を検出する。
-- 初期実装では自動 git commit しない。
-- README 相当の usage は `--help` または `work-items/README.md` に含める。
-
-## 完了条件
-
-- repo root に `tickets.sh` が追加される。
-- `work-items/README.md` で schema / migration 後の運用が説明される。
-- `tickets.sh create` で WorkItem を作成できる。
-- `tickets.sh comment` / `tickets.sh review` で thread event を append できる。
-- `tickets.sh close` で closed に移動できる。
-- 既存 `TODO.md` / `tickets/*.md` / `tickets/*.review.md` が手動で `work-items/` に移行される。
-- migration 後、`tickets.sh doctor` が repository 全体の状態に対して 0 になる。
-- 不整合 fixture または smoke test で `doctor` が非ゼロになることを確認する。
-- shellcheck が利用可能なら通る。無い場合は少なくとも focused smoke test を実行する。
-
-## 範囲外
-
-- Rust crate / DB / remote backend 実装。
-- LeaseStore / Pod run tracking の実装。
-- Git commit の自動化。
-- TUI 統合。
-- WorkItem から TODO.md を自動生成する仕組み。
-
-
----

.yoi/tickets/00001KSKBPNNG/item.md

@@ -1,59 +0,0 @@
----
-title: "TUI: actionbar transient notice API"
-state: "closed"
-created_at: "2026-05-27T00:00:14Z"
-updated_at: "2026-05-29T03:57:35Z"
----
-
-## Migration reference
-
-- legacy_ticket: tickets/tui-actionbar-transient-notice-api.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# TUI: actionbar transient notice API
-
-## 背景
-
-TUI の actionbar は最下部の補助表示行として、現在の mode や一時的な操作フィードバックを出す場所になりつつある。
-
-一方で、現在は `Ctrl-C` の二段階終了 guard のような一時通知も `app.push_error(...)` 等で view 上に残る message として扱われている。これは後から見返すログではなく、数秒だけ見えれば十分な操作フィードバックである。
-
-また、memory audit log 実装では extract / consolidation worker の直近 event を actionbar に表示する予定であり、個別機能ごとに ad hoc な actionbar 表示を増やすと優先順位・寿命・表示競合の扱いが散らばる。
-
-## 方針
-
-Actionbar を「history / transcript に残さない transient UI state」の共通表示面として扱う API を App 側に用意する。
-
-永続的に残すべき Pod event / model output / tool result / user-visible error と、一時的な操作フィードバックを分離する。actionbar notice は UI の補助表示であり、LLM context や session history へ暗黙注入しない。
-
-## 要件
-
-- App に actionbar transient notice を設定・期限切れ・取得するための API を追加する。
-  - 例: `flash_actionbar_notice(text, duration)` または `set_actionbar_notice(...)`
-  - notice には最低限 `text`, `level`, `source`, `expires_at` 相当を持たせる。
-  - time source はテストしやすい形にする。
-- actionbar rendering は transient notice を優先表示できる。
-  - 既存の command mode marker、queued input hint、scroll indicator、view mode label と競合しない優先順位を定義する。
-  - notice が期限切れなら表示しない。
-- `Ctrl-C` の二段階終了 guard の表示を view log から actionbar notice に移す。
-  - `Pod keeps running` などの一時説明は transcript/view 上に残さない。
-  - 二度押しの挙動自体は変えない。
-- memory worker の actionbar 表示が既に実装済みの場合、可能な範囲でこの API に寄せる。
-  - 未実装・別 branch 上の場合は、この ticket の範囲では API 設計が衝突しないようにする。
-- actionbar notice は通常の LLM context に暗黙注入しない。
-  - 必要な正本ログは各機能の audit/session log に残す。
-
-## 完了条件
-
-- actionbar transient notice 用 API が App/UI に追加されている。
-- `Ctrl-C` 二段階終了 guard の一時メッセージが actionbar に表示され、view log には残らない。
-- notice の期限切れと優先表示の挙動がテストされている。
-- 既存の command mode / queued input / scroll / view mode actionbar 表示が破綻していない。
-- `cargo fmt --check` と関連 TUI テストが通る。
-
-## 範囲外
-
-- actionbar の複数行化。
-- 汎用 notification center / viewer UI。
-- Pod / worker の正本ログ形式の変更。
-- memory audit log 本体の実装。

.yoi/tickets/00001KSKBPNNG/resolution.md

@@ -1,66 +0,0 @@
----
-id: 20260527-000014-tui-actionbar-transient-notice-api
-slug: tui-actionbar-transient-notice-api
-title: TUI: actionbar transient notice API
-status: closed
-kind: task
-priority: P2
-labels: [migrated]
-created_at: 2026-05-27T00:00:14Z
-updated_at: 2026-05-29T03:57:34Z
-assignee: null
-legacy_ticket: tickets/tui-actionbar-transient-notice-api.md
----
-
-## Migration reference
-
-- legacy_ticket: tickets/tui-actionbar-transient-notice-api.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# TUI: actionbar transient notice API
-
-## 背景
-
-TUI の actionbar は最下部の補助表示行として、現在の mode や一時的な操作フィードバックを出す場所になりつつある。
-
-一方で、現在は `Ctrl-C` の二段階終了 guard のような一時通知も `app.push_error(...)` 等で view 上に残る message として扱われている。これは後から見返すログではなく、数秒だけ見えれば十分な操作フィードバックである。
-
-また、memory audit log 実装では extract / consolidation worker の直近 event を actionbar に表示する予定であり、個別機能ごとに ad hoc な actionbar 表示を増やすと優先順位・寿命・表示競合の扱いが散らばる。
-
-## 方針
-
-Actionbar を「history / transcript に残さない transient UI state」の共通表示面として扱う API を App 側に用意する。
-
-永続的に残すべき Pod event / model output / tool result / user-visible error と、一時的な操作フィードバックを分離する。actionbar notice は UI の補助表示であり、LLM context や session history へ暗黙注入しない。
-
-## 要件
-
-- App に actionbar transient notice を設定・期限切れ・取得するための API を追加する。
-  - 例: `flash_actionbar_notice(text, duration)` または `set_actionbar_notice(...)`
-  - notice には最低限 `text`, `level`, `source`, `expires_at` 相当を持たせる。
-  - time source はテストしやすい形にする。
-- actionbar rendering は transient notice を優先表示できる。
-  - 既存の command mode marker、queued input hint、scroll indicator、view mode label と競合しない優先順位を定義する。
-  - notice が期限切れなら表示しない。
-- `Ctrl-C` の二段階終了 guard の表示を view log から actionbar notice に移す。
-  - `Pod keeps running` などの一時説明は transcript/view 上に残さない。
-  - 二度押しの挙動自体は変えない。
-- memory worker の actionbar 表示が既に実装済みの場合、可能な範囲でこの API に寄せる。
-  - 未実装・別 branch 上の場合は、この ticket の範囲では API 設計が衝突しないようにする。
-- actionbar notice は通常の LLM context に暗黙注入しない。
-  - 必要な正本ログは各機能の audit/session log に残す。
-
-## 完了条件
-
-- actionbar transient notice 用 API が App/UI に追加されている。
-- `Ctrl-C` 二段階終了 guard の一時メッセージが actionbar に表示され、view log には残らない。
-- notice の期限切れと優先表示の挙動がテストされている。
-- 既存の command mode / queued input / scroll / view mode actionbar 表示が破綻していない。
-- `cargo fmt --check` と関連 TUI テストが通る。
-
-## 範囲外
-
-- actionbar の複数行化。
-- 汎用 notification center / viewer UI。
-- Pod / worker の正本ログ形式の変更。
-- memory audit log 本体の実装。

.yoi/tickets/00001KSKBPNNG/thread.md

@@ -1,81 +0,0 @@
-<!-- event: migration author: tickets.sh-migration at: 2026-05-27T00:00:14Z -->
-
-## Migrated
-
-Migrated from tickets/tui-actionbar-transient-notice-api.md. No legacy review file was present at migration time.
-
----
-
-<!-- event: close author: hare at: 2026-05-29T03:57:35Z status: closed -->
-
-## Closed
-
----
-id: 20260527-000014-tui-actionbar-transient-notice-api
-slug: tui-actionbar-transient-notice-api
-title: TUI: actionbar transient notice API
-status: closed
-kind: task
-priority: P2
-labels: [migrated]
-created_at: 2026-05-27T00:00:14Z
-updated_at: 2026-05-29T03:57:34Z
-assignee: null
-legacy_ticket: tickets/tui-actionbar-transient-notice-api.md
----
-
-## Migration reference
-
-- legacy_ticket: tickets/tui-actionbar-transient-notice-api.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# TUI: actionbar transient notice API
-
-## 背景
-
-TUI の actionbar は最下部の補助表示行として、現在の mode や一時的な操作フィードバックを出す場所になりつつある。
-
-一方で、現在は `Ctrl-C` の二段階終了 guard のような一時通知も `app.push_error(...)` 等で view 上に残る message として扱われている。これは後から見返すログではなく、数秒だけ見えれば十分な操作フィードバックである。
-
-また、memory audit log 実装では extract / consolidation worker の直近 event を actionbar に表示する予定であり、個別機能ごとに ad hoc な actionbar 表示を増やすと優先順位・寿命・表示競合の扱いが散らばる。
-
-## 方針
-
-Actionbar を「history / transcript に残さない transient UI state」の共通表示面として扱う API を App 側に用意する。
-
-永続的に残すべき Pod event / model output / tool result / user-visible error と、一時的な操作フィードバックを分離する。actionbar notice は UI の補助表示であり、LLM context や session history へ暗黙注入しない。
-
-## 要件
-
-- App に actionbar transient notice を設定・期限切れ・取得するための API を追加する。
-  - 例: `flash_actionbar_notice(text, duration)` または `set_actionbar_notice(...)`
-  - notice には最低限 `text`, `level`, `source`, `expires_at` 相当を持たせる。
-  - time source はテストしやすい形にする。
-- actionbar rendering は transient notice を優先表示できる。
-  - 既存の command mode marker、queued input hint、scroll indicator、view mode label と競合しない優先順位を定義する。
-  - notice が期限切れなら表示しない。
-- `Ctrl-C` の二段階終了 guard の表示を view log から actionbar notice に移す。
-  - `Pod keeps running` などの一時説明は transcript/view 上に残さない。
-  - 二度押しの挙動自体は変えない。
-- memory worker の actionbar 表示が既に実装済みの場合、可能な範囲でこの API に寄せる。
-  - 未実装・別 branch 上の場合は、この ticket の範囲では API 設計が衝突しないようにする。
-- actionbar notice は通常の LLM context に暗黙注入しない。
-  - 必要な正本ログは各機能の audit/session log に残す。
-
-## 完了条件
-
-- actionbar transient notice 用 API が App/UI に追加されている。
-- `Ctrl-C` 二段階終了 guard の一時メッセージが actionbar に表示され、view log には残らない。
-- notice の期限切れと優先表示の挙動がテストされている。
-- 既存の command mode / queued input / scroll / view mode actionbar 表示が破綻していない。
-- `cargo fmt --check` と関連 TUI テストが通る。
-
-## 範囲外
-
-- actionbar の複数行化。
-- 汎用 notification center / viewer UI。
-- Pod / worker の正本ログ形式の変更。
-- memory audit log 本体の実装。
-
-
----

.yoi/tickets/00001KSKBPPMR/item.md

@@ -1,74 +0,0 @@
----
-title: "TUI: navigation mode / block focus の設計"
-state: 'closed'
-created_at: "2026-05-27T00:00:15Z"
-updated_at: '2026-06-20T16:31:29Z'
----
-
-## Migration reference
-
-- legacy_ticket: tickets/tui-navigation-mode-design.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# TUI: navigation mode / block focus の設計
-
-## 背景
-
-TUI の操作は現在 composer を中心にしており、履歴 block / task 表示 / queued input / system 操作の間を移動する統一的な navigation model はまだない。今後 command mode、manual compact、rollback、Pod picker、queue 編集などが増えると、Ctrl/Alt shortcut だけでは操作体系が散らばる。
-
-一方で、通常入力は最優先で守る必要がある。特に streaming 中の入力取りこぼしや rollback restore、Run 中 input queue を入れたことで、composer の文字入力を暗黙操作で壊さないことが重要になっている。
-
-本チケットは navigation mode のアイデアを保持する設計 ticket であり、すぐ実装する前提ではない。
-
-## アイデア
-
-- 通常は composer mode。
-  - 文字入力、Enter submit/queue、`@` / `#` / `/` 補完を優先する。
-- `Esc` など明示操作で navigation mode に入る。
-  - 履歴 block / task pane / queued input / picker 的 UI に focus を移す。
-  - focus があることを視覚的に分かるようにする。
-- navigation mode では `j/k` または `↑/↓` で block focus / scroll を行う。
-  - `i` / `Enter` / `Esc` で composer に戻る案。
-- composer のカーソルが最上行にある時の `↑` で履歴へ抜ける自然操作も候補。
-  - ただし multi-line input / IME / completion / typed segment と衝突しやすいため、初期実装では慎重に扱う。
-  - 暗黙 focus 移動より、明示 navigation mode を優先する案が安全。
-- command mode (`:`) とは分ける。
-  - command mode は system command 入力。
-  - navigation mode は画面上の対象選択 / scroll / block action。
-
-## 検討事項
-
-- mode 名と status/actionbar 表示。
-- composer mode から navigation mode へ入る key。
-- navigation mode から composer mode へ戻る key。
-- `↑/↓` を composer cursor movement と block focus movement のどちらに使うか。
-- block focus の単位。
-  - Turn header
-  - User message
-  - Assistant block
-  - Tool call/result
-  - System message
-  - Task row
-  - Queued input row
-- focused block に対する action。
-  - copy
-  - expand/collapse
-  - retry/fork/rollback など将来操作
-- scrollback と block focus の関係。
-- search (`/` ではなく別 key が必要。`/` は WorkflowRef と衝突する可能性)。
-- mouse support を入れるか。
-
-## 完了条件（未確定）
-
-- navigation mode の keymap と UI 表示方針が決まる。
-- composer 入力を壊さない focus 移動ルールが決まる。
-- block focus の最小単位が決まる。
-- command mode / queue / rollback / Pod picker と衝突しない。
-- 実装 ticket に分割できる。
-
-## 範囲外
-
-- 今すぐの実装。
-- command mode の実装（`tickets/tui-command-mode.md`）。
-- compact command の実装。
-- Vim 完全互換。

.yoi/tickets/00001KSKBPPMR/resolution.md

@@ -1 +0,0 @@
-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

@@ -1,25 +0,0 @@
-<!-- event: migration author: tickets.sh-migration at: 2026-05-27T00:00:15Z -->
-
-## Migrated
-
-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/00001KSKBPQM0/item.md

@@ -1,74 +0,0 @@
----
-title: "TUI picker: live pending Pod の表示優先と状態補完"
-state: "closed"
-created_at: "2026-05-27T00:00:16Z"
-updated_at: "2026-05-30T05:00:56Z"
----
-
-## Migration reference
-
-- legacy_ticket: tickets/tui-picker-live-pending-pods.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# TUI picker: live pending Pod の表示優先と状態補完
-
-## 背景
-
-`tui -r` の Pod picker は session store の name-keyed Pod metadata と runtime registry の live allocation を合わせて表示している。しかし、spawned child Pod がまだ最初の user turn / SegmentStart を materialize していない場合、Pod metadata は pending segment のままになり、session log も存在しない。
-
-実例として、`impl-llm-worker-stream-continuation` は live socket と runtime registry 上の segment_id を持っていたが、metadata は以下のように `session_id` のみだった。
-
-```json
-{
-  "pod_name": "impl-llm-worker-stream-continuation",
-  "active": {
-    "session_id": "019e5bc6-c3f3-7193-98a1-d64c635f86a1"
-  }
-}
-```
-
-一方で runtime 側には segment_id が存在する。
-
-```json
-{
-  "pod_name": "impl-llm-worker-stream-continuation",
-  "segment_id": "019e5bc6-c3f3-7193-98a1-d6559bdc9cd6",
-  "state": "idle"
-}
-```
-
-この状態の Pod は attach 可能だが、session log がないため `updated_at = 0` になり、picker の `updated_at desc` sort と `MAX_ROWS = 10` truncate によって一覧から漏れやすい。
-
-## 方針
-
-Live socket が reachable な Pod は、session log / metadata active segment が未確定でも attach 可能な対象として picker に表示する。restore 可能性と attach 可能性を分け、live pending Pod は restore 不能でも live attach 対象として扱う。
-
-## 要件
-
-- `tui -r` picker は reachable live Pod を stopped Pod より優先して表示する。
-  - `updated_at = 0` でも live row が `MAX_ROWS` truncate で落ちない。
-  - sort key は少なくとも live first, updated_at desc, pod_name になる。
-- Live Pod の metadata が pending segment の場合でも picker row に表示する。
-  - preview は `[live, pending segment]` など、人間が状態を理解できる文言にする。
-  - debug id 表示では runtime registry の segment_id を可能なら表示する。
-- Runtime registry / live status に segment_id があり、metadata に segment_id が無い場合、表示上は runtime segment_id を補完できるようにする。
-  - ただし session log が存在しない限り restore 可能とは扱わない。
-  - attach は live socket に対して行う。
-- Existing stopped / corrupt Pod metadata rows の表示を壊さない。
-- `ListVisiblePods` / discovery 側にも同様の pending live 表示不整合がある場合、必要なら後続 ticket に切り出す。
-  - この ticket の主対象は `tui -r` picker。
-
-## 完了条件
-
-- live pending Pod が `tui -r` に表示される。
-- live pending Pod を選択すると live socket に attach する。
-- live pending Pod が多数の stopped Pod によって `MAX_ROWS` truncate から漏れない。
-- picker の sort / row build の unit test が追加または更新されている。
-- `cargo fmt --check` と `cargo test -p tui picker` あるいは関連 TUI test が通る。
-
-## 範囲外
-
-- pending Pod metadata を runtime segment_id で永続的に書き換えること。
-- session log が無い Pod を restore 可能にすること。
-- spawned child Pod の first turn / SegmentStart materialization 方針の変更。
-- 汎用 spawned Pod panel UI。

.yoi/tickets/00001KSKBPQM0/resolution.md

@@ -1,81 +0,0 @@
----
-id: 20260527-000016-tui-picker-live-pending-pods
-slug: tui-picker-live-pending-pods
-title: TUI picker: live pending Pod の表示優先と状態補完
-status: closed
-kind: task
-priority: P2
-labels: [migrated]
-created_at: 2026-05-27T00:00:16Z
-updated_at: 2026-05-30T05:00:56Z
-assignee: null
-legacy_ticket: tickets/tui-picker-live-pending-pods.md
----
-
-## Migration reference
-
-- legacy_ticket: tickets/tui-picker-live-pending-pods.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# TUI picker: live pending Pod の表示優先と状態補完
-
-## 背景
-
-`tui -r` の Pod picker は session store の name-keyed Pod metadata と runtime registry の live allocation を合わせて表示している。しかし、spawned child Pod がまだ最初の user turn / SegmentStart を materialize していない場合、Pod metadata は pending segment のままになり、session log も存在しない。
-
-実例として、`impl-llm-worker-stream-continuation` は live socket と runtime registry 上の segment_id を持っていたが、metadata は以下のように `session_id` のみだった。
-
-```json
-{
-  "pod_name": "impl-llm-worker-stream-continuation",
-  "active": {
-    "session_id": "019e5bc6-c3f3-7193-98a1-d64c635f86a1"
-  }
-}
-```
-
-一方で runtime 側には segment_id が存在する。
-
-```json
-{
-  "pod_name": "impl-llm-worker-stream-continuation",
-  "segment_id": "019e5bc6-c3f3-7193-98a1-d6559bdc9cd6",
-  "state": "idle"
-}
-```
-
-この状態の Pod は attach 可能だが、session log がないため `updated_at = 0` になり、picker の `updated_at desc` sort と `MAX_ROWS = 10` truncate によって一覧から漏れやすい。
-
-## 方針
-
-Live socket が reachable な Pod は、session log / metadata active segment が未確定でも attach 可能な対象として picker に表示する。restore 可能性と attach 可能性を分け、live pending Pod は restore 不能でも live attach 対象として扱う。
-
-## 要件
-
-- `tui -r` picker は reachable live Pod を stopped Pod より優先して表示する。
-  - `updated_at = 0` でも live row が `MAX_ROWS` truncate で落ちない。
-  - sort key は少なくとも live first, updated_at desc, pod_name になる。
-- Live Pod の metadata が pending segment の場合でも picker row に表示する。
-  - preview は `[live, pending segment]` など、人間が状態を理解できる文言にする。
-  - debug id 表示では runtime registry の segment_id を可能なら表示する。
-- Runtime registry / live status に segment_id があり、metadata に segment_id が無い場合、表示上は runtime segment_id を補完できるようにする。
-  - ただし session log が存在しない限り restore 可能とは扱わない。
-  - attach は live socket に対して行う。
-- Existing stopped / corrupt Pod metadata rows の表示を壊さない。
-- `ListVisiblePods` / discovery 側にも同様の pending live 表示不整合がある場合、必要なら後続 ticket に切り出す。
-  - この ticket の主対象は `tui -r` picker。
-
-## 完了条件
-
-- live pending Pod が `tui -r` に表示される。
-- live pending Pod を選択すると live socket に attach する。
-- live pending Pod が多数の stopped Pod によって `MAX_ROWS` truncate から漏れない。
-- picker の sort / row build の unit test が追加または更新されている。
-- `cargo fmt --check` と `cargo test -p tui picker` あるいは関連 TUI test が通る。
-
-## 範囲外
-
-- pending Pod metadata を runtime segment_id で永続的に書き換えること。
-- session log が無い Pod を restore 可能にすること。
-- spawned child Pod の first turn / SegmentStart materialization 方針の変更。
-- 汎用 spawned Pod panel UI。

.yoi/tickets/00001KSKBPQM0/thread.md

@@ -1,179 +0,0 @@
-<!-- event: migration author: tickets.sh-migration at: 2026-05-27T00:00:16Z -->
-
-## Migrated
-
-Migrated from tickets/tui-picker-live-pending-pods.md. No legacy review file was present at migration time.
-
----
-
-<!-- event: plan author: hare at: 2026-05-30T04:54:03Z -->
-
-## Plan
-
-## Preflight implementation plan
-
-Classification: implementation-ready.
-
-No blocking preflight gap remains. The product rule is settled: reachable live Pods must be visible/attachable even if durable session-log metadata is incomplete, but missing session logs must not make them restorable.
-
-Implementation detail to preserve:
-- Treat “pending live” as a display/model condition, not persisted state.
-- Use reachable `LivePodInfo` plus incomplete stored/session summary or runtime-only segment id to improve row order/preview/debug ids.
-- Do not mark the Pod restorable unless stored metadata has a usable active segment/session under existing restore rules.
-
-Current code map:
-- `crates/tui/src/picker.rs`: picker construction, row rendering, live attach socket override.
-- `crates/tui/src/pod_list.rs`: shared model merge/sort/truncation/actions; current sort is updated_at desc only; `merge_live` already supplements segment id from runtime.
-- `crates/tui/src/main.rs`: selected live row attaches via socket override before restore fallback.
-- `crates/tui/src/multi_pod.rs`: also uses `PodList`, so ordering effects should be checked.
-- `crates/pod/src/discovery.rs`: List/Attach/Restore behavior is related but out of scope.
-- `crates/pod-registry/src/table.rs`: runtime allocation segment id source.
-- `crates/pod-store/src/lib.rs`: pending active segment metadata; do not persist runtime supplementation.
-
-Implementation phases:
-1. Change `PodList::from_sources` sorting to reachable-live first, then updated_at desc, then pod_name asc; truncation remains after sorting.
-2. Make reachable live pending preview explicit, e.g. `[live, pending segment]`, when durable summary is incomplete.
-3. Preserve and test runtime segment id supplementation for display/debug ids only.
-4. Add focused `pod_list` tests for live-first-before-truncation, live pending runtime segment attach-only behavior, and live-only runtime segment attach-only behavior.
-5. Adjust existing sort/multi-pod tests only as needed.
-6. Keep `PodDiscovery::inspect` / `AttachOrRestorePod` behavior out of scope; record follow-up if needed.
-
-Critical risks:
-- Live attachability and restoreability must stay separate.
-- Do not persist runtime segment supplementation to pod-store.
-- Sort must happen before truncation.
-- Do not duplicate picker-specific merge/sort logic; fix shared `PodList`.
-- Rank reachable live rows, not unreachable registry allocations.
-- Preview wording must not imply restoreability.
-- Multi-Pod dashboard ordering may change; reviewer should check it remains intended.
-
-Validation plan:
-- `cargo test -p tui pod_list`
-- `cargo test -p tui picker`
-- `cargo test -p tui multi_pod`
-- `cargo test -p tui`
-- `cargo fmt --check`
-
-
----
-
-<!-- event: review author: hare at: 2026-05-30T05:00:32Z status: approve -->
-
-## Review: approve
-
-Approve.
-
-The change correctly moves the live-priority rule into shared `PodList` construction, so both the resume picker and multi-Pod dashboard consume the same merged/sorted model. Reachable live Pods now sort ahead of non-live/unreachable/stopped/corrupt rows before truncation, and live pending rows get display-only runtime segment supplementation plus clearer pending preview text without changing pod-store metadata or restore behavior.
-
-Blocker findings: none.
-
-Requirement coverage:
-- Reachable live rows sort before stopped/corrupt/unreachable rows before truncation.
-- Sorting remains deterministic inside groups: `updated_at` desc, then pod name asc.
-- Live pending/runtime-only rows remain attachable/openable but not restorable.
-- Runtime segment id supplementation is display/model-only; no pod-store write path is touched.
-- Pending preview uses `[live, pending segment]` and does not imply restoreability.
-- Shared `PodList` was fixed rather than duplicating picker-specific logic.
-- Unreachable registry allocations are not promoted.
-- PodDiscovery / AttachOrRestore behavior was not broadened.
-
-Validation reviewed from coder report:
-- `cargo test -p tui pod_list` — passed.
-- `cargo test -p tui picker` — passed.
-- `cargo test -p tui multi_pod` — passed.
-- `cargo test -p tui` — passed.
-- `cargo fmt --check` — passed.
-
-Final verdict: approve.
-
-
----
-
-<!-- event: close author: hare at: 2026-05-30T05:00:56Z status: closed -->
-
-## Closed
-
----
-id: 20260527-000016-tui-picker-live-pending-pods
-slug: tui-picker-live-pending-pods
-title: TUI picker: live pending Pod の表示優先と状態補完
-status: closed
-kind: task
-priority: P2
-labels: [migrated]
-created_at: 2026-05-27T00:00:16Z
-updated_at: 2026-05-30T05:00:56Z
-assignee: null
-legacy_ticket: tickets/tui-picker-live-pending-pods.md
----
-
-## Migration reference
-
-- legacy_ticket: tickets/tui-picker-live-pending-pods.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# TUI picker: live pending Pod の表示優先と状態補完
-
-## 背景
-
-`tui -r` の Pod picker は session store の name-keyed Pod metadata と runtime registry の live allocation を合わせて表示している。しかし、spawned child Pod がまだ最初の user turn / SegmentStart を materialize していない場合、Pod metadata は pending segment のままになり、session log も存在しない。
-
-実例として、`impl-llm-worker-stream-continuation` は live socket と runtime registry 上の segment_id を持っていたが、metadata は以下のように `session_id` のみだった。
-
-```json
-{
-  "pod_name": "impl-llm-worker-stream-continuation",
-  "active": {
-    "session_id": "019e5bc6-c3f3-7193-98a1-d64c635f86a1"
-  }
-}
-```
-
-一方で runtime 側には segment_id が存在する。
-
-```json
-{
-  "pod_name": "impl-llm-worker-stream-continuation",
-  "segment_id": "019e5bc6-c3f3-7193-98a1-d6559bdc9cd6",
-  "state": "idle"
-}
-```
-
-この状態の Pod は attach 可能だが、session log がないため `updated_at = 0` になり、picker の `updated_at desc` sort と `MAX_ROWS = 10` truncate によって一覧から漏れやすい。
-
-## 方針
-
-Live socket が reachable な Pod は、session log / metadata active segment が未確定でも attach 可能な対象として picker に表示する。restore 可能性と attach 可能性を分け、live pending Pod は restore 不能でも live attach 対象として扱う。
-
-## 要件
-
-- `tui -r` picker は reachable live Pod を stopped Pod より優先して表示する。
-  - `updated_at = 0` でも live row が `MAX_ROWS` truncate で落ちない。
-  - sort key は少なくとも live first, updated_at desc, pod_name になる。
-- Live Pod の metadata が pending segment の場合でも picker row に表示する。
-  - preview は `[live, pending segment]` など、人間が状態を理解できる文言にする。
-  - debug id 表示では runtime registry の segment_id を可能なら表示する。
-- Runtime registry / live status に segment_id があり、metadata に segment_id が無い場合、表示上は runtime segment_id を補完できるようにする。
-  - ただし session log が存在しない限り restore 可能とは扱わない。
-  - attach は live socket に対して行う。
-- Existing stopped / corrupt Pod metadata rows の表示を壊さない。
-- `ListVisiblePods` / discovery 側にも同様の pending live 表示不整合がある場合、必要なら後続 ticket に切り出す。
-  - この ticket の主対象は `tui -r` picker。
-
-## 完了条件
-
-- live pending Pod が `tui -r` に表示される。
-- live pending Pod を選択すると live socket に attach する。
-- live pending Pod が多数の stopped Pod によって `MAX_ROWS` truncate から漏れない。
-- picker の sort / row build の unit test が追加または更新されている。
-- `cargo fmt --check` と `cargo test -p tui picker` あるいは関連 TUI test が通る。
-
-## 範囲外
-
-- pending Pod metadata を runtime segment_id で永続的に書き換えること。
-- session log が無い Pod を restore 可能にすること。
-- spawned child Pod の first turn / SegmentStart materialization 方針の変更。
-- 汎用 spawned Pod panel UI。
-
-
----

.yoi/tickets/00001KSKBPRK8/item.md

@@ -1,78 +0,0 @@
----
-title: "TUI: spawned child Pod の一覧と一時 attach"
-state: "closed"
-created_at: "2026-05-27T00:00:17Z"
-updated_at: "2026-06-07T03:14:39Z"
----
-
-## Migration reference
-
-- legacy_ticket: tickets/tui-spawned-pod-panel.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# TUI: spawned child Pod の一覧と一時 attach
-
-## 背景
-
-insomnia の開発では、親 Pod が複数の実装 Pod / reviewer Pod を spawn し、並列に作業させる運用が増えている。現在、spawned child の状態確認や出力確認は主に tool (`ListPods`, `ReadPodOutput`, `SendToPod`, `StopPod`) 経由で行っているが、TUI 上では親 Pod の会話と child Pod の進捗を行き来しにくい。
-
-ネイティブ GUI は将来的には便利だが、現時点で必要なタスクではない。まず TUI のまま、現在の Pod が spawn した child Pod を一覧し、一時的に attach / view できる UI を用意したい。
-
-## Prerequisite
-
-- `20260528-141602-tui-pod-list-view-abstraction`
-
-This ticket should build on the shared TUI Pod list/view abstraction instead of introducing a separate child-Pod-specific list model. The child panel may specialize the source/visibility to current-parent spawned children, but row status, reachability diagnostics, attach target representation, selection, and refresh behavior should reuse the prerequisite abstraction.
-
-## 要件
-
-- TUI 上で、現在の Pod が spawn した child Pod を一覧できる。
-  - source は spawned child registry / Pod state persistence を使う。
-  - ホスト上の全 Pod を無条件に見せる UI にはしない。
-  - current parent から見える child Pod だけを対象にする。
-- 各 child row には最低限以下を表示する。
-  - pod name
-  - alive / stopped / unreachable などの状態
-  - delegated scope の概要
-  - 最終更新時刻または最終出力時刻（取得できる範囲）
-  - 未読出力の有無または最終 assistant text preview（可能なら）
-- TUI から child Pod に一時 attach / view できる。
-  - 親 Pod の TUI を完全に終了せず、child の履歴 / streaming 出力を確認できる。
-  - 戻る操作で親 Pod view に戻れる。
-  - 最小実装では read-only view でもよい。child へ入力を送る操作は後続でもよい。
-- child view 中でも、どの Pod を見ているか視覚的に分かる。
-  - status line / title / breadcrumb など。
-- child が stopped / unreachable の場合は明確に表示し、attach 失敗を診断する。
-- 既存 tool の `ListPods` / `ReadPodOutput` / `SendToPod` / `StopPod` の意味を変えない。
-- visibility は parent-child 関係に基づけ、Pod discovery の global list と混ぜない。
-
-## 操作案
-
-詳細 keybinding は実装時に確定する。
-
-候補:
-
-- command mode から `:pods` で child Pod list を開く。
-- list 上で Enter すると child view へ一時 attach。
-- `Esc` / `b` / command で parent view へ戻る。
-- child view から `:send` などで入力する機能は後続 ticket にしてよい。
-
-## 完了条件
-
-- 親 Pod の TUI で spawned child Pod の一覧を表示できる。
-- live child Pod を選択すると、その child の snapshot / streaming output を TUI 上で確認できる。
-- parent view に戻れる。
-- stopped / unreachable child は一覧上で状態が分かり、attach 失敗が診断される。
-- ホスト全 Pod ではなく、parent から見える child Pod だけが対象である。
-- `cargo fmt --check`
-- `cargo check --workspace`
-- `cargo test -p tui -p pod -p protocol`
-
-## 範囲外
-
-- ネイティブ GUI クライアント。
-- 複数 Pod view の同時分割表示。
-- child Pod への full interactive input。
-- child Pod の自動再起動。
-- host-wide Pod browser。
-- Pod discovery tool の visibility model 変更。

.yoi/tickets/00001KSKBPRK8/resolution.md

@@ -1,3 +0,0 @@
-Closed as intentionally not planned.
-
-The old migrated spawned-Pod panel idea has been superseded by the workspace panel, Pod list/open/attach behavior, Ticket role launching, and the local role session registry. The remaining direction is not to revive this standalone spawned-child panel ticket. Future panel work should be tracked through the newer workspace panel / orchestration tickets.

.yoi/tickets/00001KSKBPRK8/thread.md

@@ -1,39 +0,0 @@
-<!-- event: migration author: tickets.sh-migration at: 2026-05-27T00:00:17Z -->
-
-## Migrated
-
-Migrated from tickets/tui-spawned-pod-panel.md. No legacy review file was present at migration time.
-
----
-
-<!-- event: decision author: hare at: 2026-06-05T04:03:38Z -->
-
-## Decision
-
-Decision: deprioritize this ticket for the current multi-agent system direction.
-
-Current need is not a TUI panel for spawned Pods. The priority is Ticket-driven intake/routing: making Tickets a code-facing durable orchestration record, then exposing Ticket operations to Intake/Orchestrator through a typed backend/tool surface.
-
-This ticket is not closed as technically invalid; it is moved out of the active multi-agent implementation path. Revisit only if direct child Pod visibility/attach UI becomes a concrete UX requirement.
-
-
----
-
-<!-- event: state_changed author: hare at: 2026-06-07T03:14:39Z from: intake to: done reason: closed field: workflow_state -->
-
-## State changed
-
-Ticket closed; workflow_state set to done.
-
-
----
-
-<!-- event: close author: hare at: 2026-06-07T03:14:39Z status: closed -->
-
-## Closed
-
-Closed as intentionally not planned.
-
-The old migrated spawned-Pod panel idea has been superseded by the workspace panel, Pod list/open/attach behavior, Ticket role launching, and the local role session registry. The remaining direction is not to revive this standalone spawned-child panel ticket. Future panel work should be tracked through the newer workspace panel / orchestration tickets.
-
----

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

@@ -1 +0,0 @@
-{"id":"orch-plan-20260610-090202-1","ticket_id":"00001KSKBPSJG","kind":"accepted_plan","accepted_plan":{"summary":"Implement the model setup wizard as an explicit one-shot CLI path, not normal Pod startup: add `yoi setup-model` that launches a setup TUI. The wizard should select a bundled model/provider entry, optionally accept an auth hint/reference when the provider requires one, and persist a user default Profile by updating the user Profile registry under the normal config root (`profiles.toml` plus a generated user Profile Lua file such as `profiles/default.lua`). It must not write workspace `.yoi`, session history, Ticket files, runtime/local/secret-like files, or start/attach a Pod during setup. Existing normal launch semantics remain unchanged except that subsequent default startup can use the persisted user default Profile.","branch":"tui-model-setup-wizard","worktree":"/home/hare/Projects/yoi/.worktree/tui-model-setup-wizard","role_plan":"Coder implements in `.worktree/tui-model-setup-wizard` with write scope limited to the child worktree. Orchestrator keeps Ticket/progress records in the main workspace. Reviewer will be delegated after coder report."},"author":"orchestrator","at":"2026-06-10T09:02:02Z"}

.yoi/tickets/00001KSKBPSJG/item.md

@@ -1,99 +0,0 @@
----
-title: "TUI: ユーザーマニフェストのモデル設定 wizard"
-state: 'closed'
-created_at: "2026-05-27T00:00:18Z"
-updated_at: '2026-06-10T09:31:45Z'
-queued_by: 'yoi ticket'
-queued_at: '2026-06-10T07:59:32Z'
----
-
-## Migration reference
-
-- legacy_ticket: tickets/tui-user-model-setup.md
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# TUI: ユーザーマニフェストのモデル設定 wizard
-
-## 背景
-
-spawn UI（`tickets/tui-pod-spawn-ui.md`）が `[model]` を user / project の cascade レイヤから取る前提なので、初回起動のユーザーは事前に `~/.config/insomnia/manifest.toml` を手で書く必要がある。catalog（`crates/provider/src/catalog.rs`）に provider / model の一覧と `AuthHint`（API key の env 名や Codex OAuth 等の認証方式）が既に揃っているので、これを使って TUI 内で対話的にセットアップできるようにする。
-
-`provider::catalog` の公開 API:
-
-- `load_providers() -> Vec<ProviderEntry>`: builtin + user override マージ済み
-- `load_models() -> Vec<ModelEntry>`: 同上
-- `ProviderEntry`: `id` / `display_name` / `scheme` / `auth_hint` 等
-- `ModelEntry`: `id` / `provider` / `capability`
-- `AuthHint`: `None` / `ApiKey { env: Option<String> }` / `CodexOAuth`
-
-これらが「UI で何を選ばせ、何を聞くか」を直接ガイドしてくれる構造になっている。
-
-## 要件
-
-### 起動経路
-
-- 専用サブコマンド `tui setup-model`（仮）として alt-screen TUI で起動する
-- 引数なしで叩くと既存の spawn flow に入るので、それとは別の入口
-
-### Wizard フロー
-
-1. **provider 選択**: `load_providers()` の結果をリスト表示。`display_name` を見せ、上下キー + Enter で選択
-2. **model 選択**: 選んだ provider の `id` で `load_models()` をフィルタしてリスト表示。1 つだけならスキップ可
-3. **認証情報入力**: 選んだ provider の `auth_hint` で分岐
-   - `None` → スキップ
-   - `ApiKey { env: Some(name) }` → 「環境変数 `<name>` を使う」または「key ファイルパスを入力」を選ばせる
-   - `ApiKey { env: None }` → key ファイルパス入力（絶対パス推奨、ホーム展開はする）
-   - `CodexOAuth` → 「`codex login` で OAuth を済ませてください」案内 + `~/.codex/auth.json` の存在チェック
-4. **確認画面**: 書き込み内容のプレビュー（生成される TOML）を表示、Enter で確定 / Esc でキャンセル
-5. **書き込み**: `~/.config/insomnia/manifest.toml`（または `$XDG_CONFIG_HOME` 配下、`manifest::user_manifest_path()`）に `[model]` を書く
-
-### 書き込みフォーマット
-
-catalog 由来なので `ref` 形式を採用する:
-
-```toml
-[model]
-ref = "<provider_id>/<model_id>"
-
-[model.auth]
-kind = "api_key"
-file = "/abs/path/to/key"
-```
-
-`AuthHint::None` の場合は `[model.auth]` を省く。`CodexOAuth` の場合は `kind = "codex_oauth"`。
-
-### 既存ファイルの扱い
-
-`~/.config/insomnia/manifest.toml` が既に存在する場合:
-
-- `[model]` セクションが無い → 末尾に追加
-- `[model]` セクションが既にある → 上書き確認を出す（既存の値をプレビュー表示してから）
-- ファイル全体が壊れた TOML → エラー表示してキャンセル
-
-### キャンセル / エラー経路
-
-- どのステップでも Esc / Ctrl-C で抜けられる。書き込み前ならファイルは触らない
-- catalog 読み込み失敗 / ファイル書き込み失敗は alt-screen 内でエラー表示してから終了
-
-## 設計で決めること
-
-- **API key ファイルパスの入力 UX**: テキスト入力欄でフリーフォーム、補完なしで良いか、`~` / `$HOME` 展開するか
-- **環境変数で済ませる選択肢の見せ方**: ApiKey で env 指定がある場合、デフォルト「env を使う」かデフォルト「key ファイルを使う」か
-- **多 provider / 多 model 時の選択 UI**: シンプルな縦リストか、検索フィルタ付きか
-- **既存 `[model]` の上書き確認の粒度**: TOML 全体 diff か、変わるキーだけハイライトか
-
-## 完了条件
-
-- `tui setup-model` サブコマンドで wizard が起動する
-- catalog から provider / model 一覧を取って表示・選択できる
-- `AuthHint` の各バリアントに対応した入力 UI が動く
-- 確定すると `~/.config/insomnia/manifest.toml` に `[model]` が書き込まれる
-- 既存ファイルの `[model]` 上書き時は確認が出る
-- セットアップ後に spawn flow（引数なし `tui` 起動）が model resolve エラー無しで Pod を spawn できる
-
-## 範囲外
-
-- catalog 自体の編集（新規 provider / model の追加）UI。`providers.toml` / `models.toml` の手書き運用は維持
-- 複数モデル設定（`[compaction.model]` 等）の wizard 化
-- project manifest (`.insomnia/manifest.toml`) への書き込み。本チケットは user 層のみ
-- spawn flow からの自動誘導（model 不在検出時に「`m` で setup wizard を起動」分岐）。本チケット完了後に spawn UI 側で別途検討

.yoi/tickets/00001KSKBPSJG/resolution.md

@@ -1,27 +0,0 @@
-完了しました。
-
-実施内容:
-- `yoi setup-model` を top-level command として追加しました。
-- setup path は通常の Pod 起動/attach/session 復元とは分離され、選択した catalog-backed model を user config 配下の Profile 設定として保存します。
-- `profiles.toml` の default selector と `[profile.default]`、および generated `profiles/default.lua` を deterministic に書きます。
-- setup 実行中に workspace `.yoi`、Ticket、session、runtime/local/secret-like files は書きません。
-- `yoi --help` に `yoi setup-model` を表示します。
-- `package.nix` cargoHash も更新しました。
-
-Merge:
-- Branch: `tui-model-setup-wizard`
-- Merge commit: `021661b5 merge: setup model wizard`
-
-確認:
-- Branch-local reviewer `reviewer-tui-model-setup-wizard` が approve。
-- `cargo fmt --check` passed。
-- `git diff --check` passed。
-- `cargo test -p tui setup_model --lib` passed。
-- `cargo test -p yoi setup_model --bin yoi` passed。
-- `cargo check -p yoi` passed。
-- `target/debug/yoi ticket doctor` passed。
-- typed `TicketDoctor` は 0 errors / 3 pre-existing diagnostics。
-- `nix build .#yoi` passed。
-
-残作業:
-- なし。将来的に richer alt-screen setup UI に発展させる余地はありますが、本 Ticket の one-shot setup command / Profile persistence 要件は満たしています。

.yoi/tickets/00001KSKBPSJG/thread.md

@@ -1,307 +0,0 @@
-<!-- event: migration author: tickets.sh-migration at: 2026-05-27T00:00:18Z -->
-
-## Migrated
-
-Migrated from tickets/tui-user-model-setup.md. No legacy review file was present at migration time.
-
----
-
-<!-- event: decision author: ticket-intake at: 2026-06-08T07:29:01Z -->
-
-## Decision
-
-## Intake refinement: current Yoi context
-
-This is an existing migrated Ticket; no duplicate Ticket was created. The original body remains useful for the desired wizard shape, but several migrated assumptions are stale and must be treated as superseded where they conflict with current Yoi code and project decisions.
-
-### Current request snapshot
-
-Add an interactive TUI setup flow that helps a first-time user choose a provider/model from the provider catalog and persist a user-level default model configuration so a normal fresh `yoi` spawn can resolve a model without manual TOML editing.
-
-### Binding decisions / invariants
-
-- Product entrypoint is the installed `yoi` binary, not an old standalone `tui`/`insomnia` binary. The CLI surface should be chosen under the `yoi` CLI owner boundary; the migrated `tui setup-model` spelling is only historical/placeholder text.
-- Current config paths use `manifest::paths::config_dir()` with default `$XDG_CONFIG_HOME/yoi` / `$HOME/.config/yoi`, not `~/.config/insomnia`.
-- Normal reusable runtime configuration is Profile-oriented. The implementation must decide, with preflight, whether this wizard writes/updates `profiles.toml`, a profile-local model fragment, or another explicit user config surface; it must not silently reintroduce the removed ambient manifest-cascade model.
-- Current catalog auth hints are `AuthHint::None`, `AuthHint::ApiKey`, `AuthHint::SecretRef { ref_ }`, and `AuthHint::CodexOAuth`; the migrated `ApiKey { env: Option<String> }` flow is stale.
-- Secret values must not be written into Ticket bodies, logs, diagnostics, or generated artifacts. Prefer the existing local secret-store / `yoi keys` boundary for normal provider credentials; raw `model.auth.file` remains a low-level explicit-file source, not the default UX if a safer secret-ref path is available.
-- The wizard must be cancel-safe: no user config/secret writes before explicit confirmation, and failed parsing/writing must leave existing config usable.
-
-### Implementation latitude
-
-- The exact command name may be settled during preflight, but should fit existing `yoi` CLI semantics and help text.
-- A simple vertical provider/model list is sufficient for the first implementation; search/filtering can be deferred unless preflight finds the catalog size makes it necessary.
-- If only one model exists for the selected provider, skipping the model-choice step is acceptable.
-- Preview may show the generated/surgical config change rather than a full diff, as long as overwrite of an existing model/default is explicit.
-
-### Acceptance criteria
-
-- A first-time user can launch the setup flow from the `yoi` CLI without entering normal Pod spawn by accident.
-- The flow loads current `provider::catalog::load_providers()` and `load_models()` data, displays provider/model choices, and handles all current `AuthHint` variants.
-- The confirmed result persists a user-level default model/profile configuration at the current Yoi config path, without storing plaintext secrets in config by default.
-- Existing user config with an existing model/default is detected and requires overwrite confirmation; malformed config is reported and not rewritten.
-- Esc/Ctrl-C cancel before confirmation leaves files unchanged.
-- After setup, a normal fresh `yoi` spawn can resolve the selected model/profile without a model-resolve error.
-- Validation includes focused Rust tests for CLI parsing/config rendering/update behavior and `nix build .#yoi` because this changes CLI/TUI/runtime resources/packaging-visible code.
-
-### Readiness / routing signal
-
-- readiness: spike_needed
-- needs_preflight: true
-- risk_flags: [cli-ux, profiles-config, secrets, auth-boundary, migration-staleness, tui]
-
-This Ticket is ready for Orchestrator routing to preflight/spike, not direct implementation. Preflight should first settle the current user-config write target and command spelling, then either update the Ticket body or record a concise binding decision before implementation.
-
----
-
-<!-- event: intake_summary author: ticket-intake at: 2026-06-08T07:29:10Z -->
-
-## Intake summary
-
-Updated existing Ticket 20260527-000018-tui-user-model-setup in place; no duplicate was created. The migrated request is now clarified as a Yoi CLI/TUI first-run model setup flow, with stale `tui`/`insomnia`/old AuthHint assumptions explicitly superseded in the thread. Routing readiness is spike/preflight, not direct implementation: first settle current `yoi` command spelling and the user-level config write target for Profile-oriented model defaults, then implement the wizard. needs_preflight=true; risk_flags=[cli-ux, profiles-config, secrets, auth-boundary, migration-staleness, tui].
-
----
-
-<!-- event: state_changed author: ticket-intake at: 2026-06-08T07:29:10Z from: intake to: ready reason: intake_ready field: workflow_state -->
-
-## State changed
-
-Intake clarification completed for the existing Ticket. The Ticket is ready for Orchestrator routing to preflight/spike; implementation should not begin until the preflight decisions called out in the intake summary are recorded.
-
----
-
-<!-- event: state_changed author: "yoi ticket" at: 2026-06-10T07:59:32Z from: ready to: queued reason: queued field: state -->
-
-## State changed
-
-Ticket を `yoi ticket` が queued にしました。
-
-
----
-
-<!-- event: decision author: hare at: 2026-06-10T07:59:32Z -->
-
-## Decision
-
-Human authorized Queue from workspace panel notification; Orchestrator read the Ticket and will accept before implementation side effects.
-
-
----
-
-<!-- event: state_changed author: "yoi ticket" at: 2026-06-10T07:59:32Z from: queued to: inprogress reason: cli_state field: state -->
-
-## State changed
-
-State changed to `inprogress`.
-
-
----
-
-<!-- event: decision author: hare at: 2026-06-10T07:59:32Z -->
-
-## Decision
-
-Accepting implementation after workspace inspection. Expected overlap with prompt-resource cleanup is low, so route in parallel in a dedicated worktree.
-
-
----
-
-<!-- event: plan author: orchestrator at: 2026-06-10T09:02:02Z -->
-
-## Plan
-
-Routing decision: implementation_ready
-
-Reason:
-- Ticket is already `inprogress`; relation query and orchestration-plan query show no blockers.
-- Existing thread marked this as needing a small preflight. Bounded code/context check resolved the implementation-shaping decisions without needing another planning round.
-
-Evidence checked:
-- Ticket body/thread/artifacts for `00001KSKBPSJG`.
-- Relation records: none.
-- Orchestration plan records: none before this routing pass.
-- Current worktree/branch state: `.worktree/tui-model-setup-wizard` exists and has no implementation commit yet.
-- Current CLI surface in `crates/yoi/src/main.rs` includes top-level `panel`, `keys`, `pod`, `ticket`, `objective`, `session`, `memory lint`; setup is not yet present.
-- Profile/config surface in `crates/manifest/src/paths.rs` and `crates/manifest/src/profile.rs`; active reusable Profiles are Lua-first with user registry/config under the normal config root.
-- Provider/model catalog resources under `resources/providers` and `resources/models`.
-
-Binding decisions / invariants:
-- Add an explicit one-shot setup entry point `yoi setup-model`; it must not run normal Pod startup, create sessions, attach sockets, or spawn Pods while configuring.
-- Persist the result as a user default Profile through normal Profile mechanisms: user `profiles.toml` plus a generated user Profile Lua file (for example `profiles/default.lua`) under the normal config root. Do not write workspace `.yoi`, Ticket records, session history, runtime/local/secret-like files, or project records from the setup wizard.
-- Do not introduce legacy manifest authority or new environment-variable configuration surfaces.
-- Keep existing startup/profile semantics intact; the setup wizard only creates/updates config that normal startup already knows how to consume.
-- If provider credential handling needs more than selecting/recording an existing auth hint/ref, escalate rather than inventing a new secret store flow.
-
-Implementation latitude:
-- Exact TUI layout and internal state machine organization are up to coder, bounded by the one-shot setup and persistence invariants.
-- Coder may choose the generated profile name/path if it is deterministic, user-config scoped, and unambiguous from the default selector.
-- Coder may keep the catalog/model choice set modest and testable for the first implementation.
-
-Validation:
-- Focused CLI/parser and setup persistence tests.
-- Focused TUI/setup module tests where practical.
-- `cargo fmt --check` or `cargo fmt`, `git diff --check`, focused cargo tests, and broader `cargo check`/`nix build .#yoi` before merge because this touches CLI/TUI/config/package source surfaces.
-
-Escalate if:
-- The implementation requires changing Profile registry semantics, secret-store behavior, normal Pod launch behavior, or workspace `.yoi` authority.
-- Credential entry/storage cannot be limited to an existing explicit auth reference/hint.
-
----
-
-<!-- event: plan author: orchestrator at: 2026-06-10T09:08:59Z -->
-
-## Plan
-
-Routing update: blocked_by_dependency_or_missing_authority
-
-Reason:
-- This Ticket remains `inprogress` and has an accepted implementation plan for `.worktree/tui-model-setup-wizard`, but the current Orchestrator process cannot delegate write scope to the child worktree.
-- Attempted `SpawnPod` for `coder-tui-model-setup-wizard` with write scope limited to the child worktree failed: requested scope `/home/hare/Projects/yoi/.worktree/tui-model-setup-wizard` is not within the spawner effective scope.
-- Retrying with broader `/home/hare/Projects/yoi` write scope also failed for the same effective-scope reason.
-- Direct file write to the child worktree through the available tool scope is read-only, so the Orchestrator cannot safely implement the Ticket in this session either.
-
-Evidence checked:
-- Ticket body/thread/artifacts and relation/orchestration-plan records.
-- Current CLI/profile/provider code map was boundedly inspected and the accepted plan was recorded.
-- Worktree `.worktree/tui-model-setup-wizard` exists, but no coder was spawned and no implementation files were changed.
-
-Next action:
-- Continue this Ticket from a Pod/session with delegated write scope for `.worktree/tui-model-setup-wizard`, or explicitly re-route/clean up the existing inprogress worktree.
-- Do not treat this as planning uncertainty; the current blocker is write/delegation authority for implementation side effects.
-
----
-
-<!-- event: implementation_report author: orchestrator at: 2026-06-10T09:16:45Z -->
-
-## Implementation report
-
-Implementation report
-
-Branch/worktree: `tui-model-setup-wizard` / `.worktree/tui-model-setup-wizard`
-Commits:
-- `6bb023e9 merge develop into setup wizard worktree` (brought branch up to current `develop` before implementation)
-- `32be6075 feat: add setup model command`
-
-Summary:
-- Added a top-level `yoi setup-model` command that enters a one-shot setup path separate from normal Pod startup.
-- Added `tui::setup_model` to list catalog-backed models/providers, prompt for a default selection, and persist user Profile config under the normal user config directory.
-- Persistence writes `profiles.toml` with `default = "user:default"` and `[profile.default] path = "profiles/default.lua"`, plus generated `profiles/default.lua` using the selected model ref.
-- The setup path does not start/attach a Pod, create sessions, or write workspace `.yoi` records.
-- Added CLI parser tests for `setup-model` and persistence tests for generated profile config.
-
-Validation run in branch:
-- `cargo fmt`
-- `cargo test -p tui setup_model --lib` passed.
-- `cargo test -p yoi parse_setup_model --bin yoi` passed.
-- `cargo check -p yoi` passed.
-- `git diff --check` passed.
-
-Notes:
-- `nix build .#yoi` was not run in the branch yet; Orchestrator should run it before merge because this touches CLI/TUI/config/package source surfaces.
-- The implementation uses a simple bounded terminal setup flow rather than broad TUI refactoring.
-
----
-
-<!-- event: review author: reviewer-tui-model-setup-wizard at: 2026-06-10T09:29:42Z status: approve -->
-
-## Review: approve
-
-Branch-local review verdict: approve
-
-Blockers: none.
-
-Reviewer confirmed after fixes:
-- `package.nix` cargoHash was updated and `nix build .#yoi` passed.
-- Top-level help now lists `yoi setup-model`.
-- Tracked worktree is clean.
-
-Validation run by reviewer:
-- `cargo test -p tui setup_model --lib` passed.
-- `cargo test -p yoi setup_model --bin yoi` passed.
-- `cargo check -p yoi` passed.
-- `git diff --check $(git merge-base HEAD develop)..HEAD` passed.
-- `nix build .#yoi` passed.
-
-This is branch-local review evidence; final main-branch approval/close belongs to merge-completion.
-
----
-
-<!-- event: review author: orchestrator at: 2026-06-10T09:31:33Z status: approve -->
-
-## Review: approve
-
-Main-branch review/merge-completion approval.
-
-Verified before merge:
-- Branch-local reviewer approved after blocker fix.
-- Merge target matched branch `tui-model-setup-wizard` / worktree `.worktree/tui-model-setup-wizard` and commits `6bb023e9`, `32be6075`, `66d6bf2e`, `c06817b4`.
-- Packaging blocker was fixed by updating `package.nix` cargoHash; top-level help lists `yoi setup-model`.
-
-Merged:
-- `git merge --no-ff tui-model-setup-wizard -m "merge: setup model wizard"`
-- Merge commit: `021661b5 merge: setup model wizard`
-
-Post-merge validation:
-- `cargo fmt --check` passed.
-- `git diff --check` passed.
-- `cargo test -p tui setup_model --lib` passed.
-- `cargo test -p yoi setup_model --bin yoi` passed.
-- `cargo check -p yoi` passed.
-- `target/debug/yoi ticket doctor` passed.
-- typed `TicketDoctor` reported 0 errors and 3 pre-existing diagnostics.
-- `nix build .#yoi` passed.
-
-Result: approve.
-
----
-
-<!-- event: state_changed author: orchestrator at: 2026-06-10T09:31:33Z from: inprogress to: done reason: merged_and_validated field: state -->
-
-## State changed
-
-Merged branch `tui-model-setup-wizard` with merge commit `021661b5`; branch-local review approved after fixes and post-merge validation passed (`cargo fmt --check`, `git diff --check`, `cargo test -p tui setup_model --lib`, `cargo test -p yoi setup_model --bin yoi`, `cargo check -p yoi`, `target/debug/yoi ticket doctor`, `nix build .#yoi`).
-
----
-
-<!-- event: state_changed author: hare at: 2026-06-10T09:31:45Z from: done to: closed reason: closed field: state -->
-
-## State changed
-
-Ticket を closed にしました。
-
-
----
-
-<!-- event: close author: hare at: 2026-06-10T09:31:45Z status: closed -->
-
-## 完了
-
-完了しました。
-
-実施内容:
-- `yoi setup-model` を top-level command として追加しました。
-- setup path は通常の Pod 起動/attach/session 復元とは分離され、選択した catalog-backed model を user config 配下の Profile 設定として保存します。
-- `profiles.toml` の default selector と `[profile.default]`、および generated `profiles/default.lua` を deterministic に書きます。
-- setup 実行中に workspace `.yoi`、Ticket、session、runtime/local/secret-like files は書きません。
-- `yoi --help` に `yoi setup-model` を表示します。
-- `package.nix` cargoHash も更新しました。
-
-Merge:
-- Branch: `tui-model-setup-wizard`
-- Merge commit: `021661b5 merge: setup model wizard`
-
-確認:
-- Branch-local reviewer `reviewer-tui-model-setup-wizard` が approve。
-- `cargo fmt --check` passed。
-- `git diff --check` passed。
-- `cargo test -p tui setup_model --lib` passed。
-- `cargo test -p yoi setup_model --bin yoi` passed。
-- `cargo check -p yoi` passed。
-- `target/debug/yoi ticket doctor` passed。
-- typed `TicketDoctor` は 0 errors / 3 pre-existing diagnostics。
-- `nix build .#yoi` passed。
-
-残作業:
-- なし。将来的に richer alt-screen setup UI に発展させる余地はありますが、本 Ticket の one-shot setup command / Profile persistence 要件は満たしています。
-
----

.yoi/tickets/00001KSKBPTHR/item.md

@@ -1,57 +0,0 @@
----
-title: "ワークスペースのメモリーをLintするヘッドレスCLI"
-state: "closed"
-created_at: "2026-05-27T00:00:19Z"
-updated_at: "2026-05-31T02:15:17Z"
----
-
-## Background
-
-The memory linter currently exists as library/pre-write validation used by memory tools, but there is no headless command to check all existing workspace memory/knowledge records at once. This makes it hard to validate `.insomnia/memory` and `.insomnia/knowledge` before commits, migrations, or manual edits.
-
-The installed user-facing binary is currently produced by the `tui` crate as `insomnia`. It is acceptable for this ticket to add the headless lint command to that crate/binary instead of introducing a separate binary. A future rename from `tui` crate to `insomnia`, or a more explicit single-binary CLI structure, can be handled separately.
-
-## Requirements
-
-- Add a headless CLI mode to the existing `insomnia` binary in the `tui` crate.
-- Preferred invocation shape: `insomnia memory lint [--workspace <PATH>] [--json] [--warnings-as-errors]`.
-  - `insomnia memory` without `lint` should remain available as a normal positional Pod name if possible.
-  - If this shape is awkward with the current parser, keep the command unambiguous and document the chosen shape in tests/help text.
-- Default workspace root is the current working directory.
-- `--workspace <PATH>` overrides the workspace root passed to `memory::WorkspaceLayout::new`.
-- Lint all existing records classified by `memory::WorkspaceLayout`:
-  - `.insomnia/memory/summary.md` when present;
-  - `.insomnia/memory/decisions/*.md`;
-  - `.insomnia/memory/requests/*.md`;
-  - `.insomnia/knowledge/*.md`.
-- Do not lint subsystem-owned opaque trees such as `.insomnia/memory/_staging`, `_logs`, `_usage`.
-- Use the existing `memory::Linter` and `WriteMode::Update` for existing files so the CLI matches tool pre-write validation semantics without triggering create-only duplicate slug checks on the file itself.
-- Print a deterministic, human-readable report by default:
-  - file path;
-  - errors;
-  - warnings;
-  - summary counts.
-- Exit status:
-  - `0` if no errors, and no warnings when `--warnings-as-errors` is set;
-  - `1` if lint errors are found, or warnings are found with `--warnings-as-errors`;
-  - `2` for CLI usage / I/O / unexpected runtime failures.
-- `--json` may be simple but should be machine-readable and stable enough for scripts: include workspace, files, errors, warnings, and counts.
-- The command must not start a Pod, connect to sockets, enter raw terminal mode, or mutate files.
-
-## Non-goals
-
-- Renaming the `tui` crate to `insomnia`.
-- Adding a separate installed binary.
-- Linting Workflow files; workflow linting can be a future command.
-- Auto-fixing memory/knowledge records.
-- Changing memory schema/linter rules.
-
-## Acceptance criteria
-
-- `insomnia memory lint` runs headlessly against the current directory and reports existing memory/knowledge lint results.
-- `insomnia memory lint --workspace <PATH>` works in tests/fixtures.
-- The command exits non-zero for lint errors.
-- `--warnings-as-errors` makes warnings fail.
-- `--json` returns valid JSON containing counts and per-file diagnostics.
-- Existing Pod/TUI argument parsing behavior remains covered by tests, especially positional Pod names and `--multi`/`--resume` conflicts.
-- `cargo fmt --check`, focused `cargo test -p tui` tests, `cargo check -p tui`, `./tickets.sh doctor`, and `git diff --check` pass.

.yoi/tickets/00001KSKBPTHR/resolution.md

@@ -1 +0,0 @@
-Implemented `insomnia memory lint` as a headless command in the existing user-facing `insomnia` binary. The command lints workspace memory/knowledge records with the existing `memory::Linter` using `WriteMode::Update`, supports human and JSON output, handles warnings-as-errors, preserves `insomnia memory` as a positional Pod name, and returns before TUI/raw-terminal or Pod connection paths. External review approved and validation passed.

.yoi/tickets/00001KSKBPTHR/thread.md

@@ -1,105 +0,0 @@
-<!-- event: migration author: tickets.sh-migration at: 2026-05-27T00:00:19Z -->
-
-## Migrated
-
-Migrated from TODO.md entry without a legacy ticket file. No legacy review file was present at migration time.
-
----
-
-<!-- event: plan author: hare at: 2026-05-31T00:51:55Z -->
-
-## Plan
-
-Planning note:
-
-- Keep this in the existing user-facing `insomnia` binary implemented by the `tui` crate. Do not add another installed command for this ticket.
-- The command should be headless: parse args, lint files, print report, exit. It must not initialize terminal UI or connect to a Pod.
-- `insomnia memory lint` is preferred, but `insomnia memory` alone should continue to be a valid Pod-name attach/create path if practical with the current parser.
-- Use `memory::Linter` directly so CLI behavior tracks tool pre-write validation. Existing files should be linted with `WriteMode::Update`.
-- Keep crate rename / single-binary architecture as future cleanup, not part of this ticket.
-
-
----
-
-<!-- event: implementation_report author: hare at: 2026-05-31T02:14:28Z -->
-
-## Implementation report
-
-Implementation report from coder Pod `workspace-memory-lint-coder-20260531`:
-
-- Branch: `workspace-memory-lint-cli`
-- Commit: `7a717f2d259563df562913e0c3ceb388b094b697` (`cli: add workspace memory lint`)
-- Added `insomnia memory lint [--workspace <PATH>] [--json] [--warnings-as-errors]` as a headless mode in the existing `tui` crate/user-facing `insomnia` binary.
-- `insomnia memory` alone remains a positional Pod name.
-- The lint command resolves workspace root, collects existing summary/decisions/requests/knowledge records through `memory::WorkspaceLayout`, and lints with existing `memory::Linter` using `WriteMode::Update`.
-- The command prints deterministic human output by default and stable JSON with workspace/files/errors/warnings/counts when `--json` is requested.
-- Exit codes follow the ticket: 0 clean, 1 lint failures or warnings-as-errors, 2 usage/I/O/output/runtime failures.
-- The headless path returns before raw terminal setup or Pod connection/spawn logic.
-
-Validation reported by coder:
-
-- `cargo fmt --check` passed
-- `cargo test -p tui memory_lint -- --nocapture` passed
-- `cargo test -p tui` passed
-- `cargo check -p tui` passed
-- `./tickets.sh doctor` passed
-- `git diff --check` passed
-
-Unresolved issues: none.
-
-
----
-
-<!-- event: review author: hare at: 2026-05-31T02:14:28Z status: approve -->
-
-## Review: approve
-
-External review by reviewer Pod `workspace-memory-lint-reviewer-rerun-20260531`: approve.
-
-The original reviewer Pod `workspace-memory-lint-reviewer-20260531` became non-visible to the parent before output could be recovered; this review was rerun with a replacement read-only reviewer Pod.
-
-Reviewer summary:
-
-- The implementation adds `insomnia memory lint` as a headless mode in the existing user-facing `insomnia` binary.
-- The memory lint path branches before raw terminal setup and Pod connection/spawn logic.
-- Parser tests preserve `insomnia memory` as positional Pod name behavior.
-- The collector targets summary, decisions, requests, and knowledge records while ignoring opaque memory subsystem directories and workflow files.
-- Existing `memory::Linter` and `WriteMode::Update` are used, and the code only reads files / writes reports.
-- Human and JSON outputs are deterministic enough for the ticket, and exit code mapping matches requirements.
-
-Blockers: none.
-
-Non-blocking follow-ups:
-
-- Add broader fixture coverage for `_staging`, `_usage`, knowledge, and decisions if desired.
-- Add process-level exit-code integration tests if a CLI test harness is introduced later.
-
-Validation adequacy: coder-reported validation is sufficient for this ticket. Reviewer additionally checked `git diff --check develop...HEAD` read-only.
-
-
----
-
-<!-- event: implementation_report author: hare at: 2026-05-31T02:15:16Z -->
-
-## Implementation report
-
-Main workspace validation after merge:
-
-- `cargo fmt --check` passed
-- `cargo test -p tui memory_lint -- --nocapture` passed (10 passed)
-- `cargo test -p tui` passed (224 passed)
-- `cargo check -p tui` passed with pre-existing dead-code warnings in `llm-worker` and `tui`
-- `./tickets.sh doctor` passed
-- `git diff --check` passed
-
-
----
-
-<!-- event: close author: hare at: 2026-05-31T02:15:17Z status: closed -->
-
-## Closed
-
-Implemented `insomnia memory lint` as a headless command in the existing user-facing `insomnia` binary. The command lints workspace memory/knowledge records with the existing `memory::Linter` using `WriteMode::Update`, supports human and JSON output, handles warnings-as-errors, preserves `insomnia memory` as a positional Pod name, and returns before TUI/raw-terminal or Pod connection paths. External review approved and validation passed.
-
-
----

.yoi/tickets/00001KSKBPVH0/item.md

@@ -1,62 +0,0 @@
----
-title: "Generalize system-reminder history append lane"
-state: "closed"
-created_at: "2026-05-27T00:00:20Z"
-updated_at: "2026-05-29T05:05:43Z"
----
-
-## Background
-
-`session-todo-reminder` established the first concrete `<system-reminder>...</system-reminder>` user: Task inactivity reminders are appended through `pending_history_appends` so the reminder is persisted in `worker.history` before the next LLM request. This follows the context-processing rule that new non-volatile input must be appended to history rather than injected only into request context.
-
-The current implementation should now be generalized so future reminder producers do not each hand-roll XML tags, `SystemItem` construction, source labeling, cooldown/priority plumbing, or history-append integration.
-
-This ticket is about making the system-reminder append lane a small typed facility. It is not about adding new reminder policies beyond existing Task reminders.
-
-## Requirements
-
-- Introduce a typed internal representation for pending system reminders.
-  - text/body
-  - source/kind, e.g. task inactivity
-  - optional priority/order key if needed
-  - helper that renders the body inside `<system-reminder>...</system-reminder>` exactly once
-- Route reminders through the existing `Interceptor::pending_history_appends` lane.
-  - The final result must still be `Item::System(SystemItem { kind: InvokeKind::SystemReminder, ... })` or equivalent current protocol type.
-  - The reminder must be appended to `worker.history`; do not introduce hidden request-only context injection.
-- Refactor `session-todo-reminder` to use this typed helper/facility.
-  - Task reminder behavior, thresholds, cooldown, and tests should remain unchanged.
-  - The helper should prevent double-wrapping if the body is already tagged, or the API should make double-wrapping impossible.
-- Keep `Notify` / `PodEvent` behavior unchanged.
-  - Do not merge raw notify and system reminder semantics.
-  - If they share buffering mechanics, keep the public behavior and rendered tags distinct.
-- Keep ordering deterministic.
-  - If multiple reminder producers are added later, ordering should be explicit or stable.
-  - For now, existing Task reminder order relative to Notify/PodEvent should be preserved unless there is a clear reason to change it.
-- Add docs/comments near the facility explaining the rule:
-  - system reminders are durable input and must be appended through history.
-  - they are not transient UI notices.
-  - they are not prompt-cache/context-only injections.
-
-## Acceptance criteria
-
-- There is a typed system-reminder helper/facility rather than ad-hoc string construction in Task reminder code.
-- Task inactivity reminders still appear as `<system-reminder>...</system-reminder>` in `pending_history_appends` output.
-- The helper emits `InvokeKind::SystemReminder` / current system-reminder item kind.
-- Existing Task reminder tests continue to pass.
-- New focused tests cover:
-  - rendering wraps body once.
-  - source/kind is retained or observable where appropriate.
-  - Task reminder uses the helper and remains history-append based.
-  - no hidden context-only injection path is introduced.
-- `cargo fmt --check`
-- `cargo check -p pod -p llm-worker -p session-store`
-- Relevant focused tests, e.g. `cargo test -p pod reminder --no-default-features`.
-
-## Out of scope
-
-- Adding a second reminder policy.
-- Changing Task reminder thresholds/cooldown.
-- Changing Notify/PodEvent user-visible behavior.
-- UI actionbar notices.
-- Prompt text changes.
-- Generic notification center or reminder scheduling service.

.yoi/tickets/00001KSKBPVH0/resolution.md

@@ -1,69 +0,0 @@
----
-id: 20260527-000020-system-reminder-injection-generalization
-slug: system-reminder-injection-generalization
-title: Generalize system-reminder history append lane
-status: closed
-kind: task
-priority: P2
-labels: [pod, llm-worker, history, system-reminder]
-created_at: 2026-05-27T00:00:20Z
-updated_at: 2026-05-29T05:05:43Z
-assignee: null
-legacy_ticket: null
----
-
-## Background
-
-`session-todo-reminder` established the first concrete `<system-reminder>...</system-reminder>` user: Task inactivity reminders are appended through `pending_history_appends` so the reminder is persisted in `worker.history` before the next LLM request. This follows the context-processing rule that new non-volatile input must be appended to history rather than injected only into request context.
-
-The current implementation should now be generalized so future reminder producers do not each hand-roll XML tags, `SystemItem` construction, source labeling, cooldown/priority plumbing, or history-append integration.
-
-This ticket is about making the system-reminder append lane a small typed facility. It is not about adding new reminder policies beyond existing Task reminders.
-
-## Requirements
-
-- Introduce a typed internal representation for pending system reminders.
-  - text/body
-  - source/kind, e.g. task inactivity
-  - optional priority/order key if needed
-  - helper that renders the body inside `<system-reminder>...</system-reminder>` exactly once
-- Route reminders through the existing `Interceptor::pending_history_appends` lane.
-  - The final result must still be `Item::System(SystemItem { kind: InvokeKind::SystemReminder, ... })` or equivalent current protocol type.
-  - The reminder must be appended to `worker.history`; do not introduce hidden request-only context injection.
-- Refactor `session-todo-reminder` to use this typed helper/facility.
-  - Task reminder behavior, thresholds, cooldown, and tests should remain unchanged.
-  - The helper should prevent double-wrapping if the body is already tagged, or the API should make double-wrapping impossible.
-- Keep `Notify` / `PodEvent` behavior unchanged.
-  - Do not merge raw notify and system reminder semantics.
-  - If they share buffering mechanics, keep the public behavior and rendered tags distinct.
-- Keep ordering deterministic.
-  - If multiple reminder producers are added later, ordering should be explicit or stable.
-  - For now, existing Task reminder order relative to Notify/PodEvent should be preserved unless there is a clear reason to change it.
-- Add docs/comments near the facility explaining the rule:
-  - system reminders are durable input and must be appended through history.
-  - they are not transient UI notices.
-  - they are not prompt-cache/context-only injections.
-
-## Acceptance criteria
-
-- There is a typed system-reminder helper/facility rather than ad-hoc string construction in Task reminder code.
-- Task inactivity reminders still appear as `<system-reminder>...</system-reminder>` in `pending_history_appends` output.
-- The helper emits `InvokeKind::SystemReminder` / current system-reminder item kind.
-- Existing Task reminder tests continue to pass.
-- New focused tests cover:
-  - rendering wraps body once.
-  - source/kind is retained or observable where appropriate.
-  - Task reminder uses the helper and remains history-append based.
-  - no hidden context-only injection path is introduced.
-- `cargo fmt --check`
-- `cargo check -p pod -p llm-worker -p session-store`
-- Relevant focused tests, e.g. `cargo test -p pod reminder --no-default-features`.
-
-## Out of scope
-
-- Adding a second reminder policy.
-- Changing Task reminder thresholds/cooldown.
-- Changing Notify/PodEvent user-visible behavior.
-- UI actionbar notices.
-- Prompt text changes.
-- Generic notification center or reminder scheduling service.

.yoi/tickets/00001KSKBPVH0/thread.md

@@ -1,84 +0,0 @@
-<!-- event: migration author: tickets.sh-migration at: 2026-05-27T00:00:20Z -->
-
-## Migrated
-
-Migrated from TODO.md entry without a legacy ticket file. No legacy review file was present at migration time.
-
----
-
-<!-- event: close author: hare at: 2026-05-29T05:05:43Z status: closed -->
-
-## Closed
-
----
-id: 20260527-000020-system-reminder-injection-generalization
-slug: system-reminder-injection-generalization
-title: Generalize system-reminder history append lane
-status: closed
-kind: task
-priority: P2
-labels: [pod, llm-worker, history, system-reminder]
-created_at: 2026-05-27T00:00:20Z
-updated_at: 2026-05-29T05:05:43Z
-assignee: null
-legacy_ticket: null
----
-
-## Background
-
-`session-todo-reminder` established the first concrete `<system-reminder>...</system-reminder>` user: Task inactivity reminders are appended through `pending_history_appends` so the reminder is persisted in `worker.history` before the next LLM request. This follows the context-processing rule that new non-volatile input must be appended to history rather than injected only into request context.
-
-The current implementation should now be generalized so future reminder producers do not each hand-roll XML tags, `SystemItem` construction, source labeling, cooldown/priority plumbing, or history-append integration.
-
-This ticket is about making the system-reminder append lane a small typed facility. It is not about adding new reminder policies beyond existing Task reminders.
-
-## Requirements
-
-- Introduce a typed internal representation for pending system reminders.
-  - text/body
-  - source/kind, e.g. task inactivity
-  - optional priority/order key if needed
-  - helper that renders the body inside `<system-reminder>...</system-reminder>` exactly once
-- Route reminders through the existing `Interceptor::pending_history_appends` lane.
-  - The final result must still be `Item::System(SystemItem { kind: InvokeKind::SystemReminder, ... })` or equivalent current protocol type.
-  - The reminder must be appended to `worker.history`; do not introduce hidden request-only context injection.
-- Refactor `session-todo-reminder` to use this typed helper/facility.
-  - Task reminder behavior, thresholds, cooldown, and tests should remain unchanged.
-  - The helper should prevent double-wrapping if the body is already tagged, or the API should make double-wrapping impossible.
-- Keep `Notify` / `PodEvent` behavior unchanged.
-  - Do not merge raw notify and system reminder semantics.
-  - If they share buffering mechanics, keep the public behavior and rendered tags distinct.
-- Keep ordering deterministic.
-  - If multiple reminder producers are added later, ordering should be explicit or stable.
-  - For now, existing Task reminder order relative to Notify/PodEvent should be preserved unless there is a clear reason to change it.
-- Add docs/comments near the facility explaining the rule:
-  - system reminders are durable input and must be appended through history.
-  - they are not transient UI notices.
-  - they are not prompt-cache/context-only injections.
-
-## Acceptance criteria
-
-- There is a typed system-reminder helper/facility rather than ad-hoc string construction in Task reminder code.
-- Task inactivity reminders still appear as `<system-reminder>...</system-reminder>` in `pending_history_appends` output.
-- The helper emits `InvokeKind::SystemReminder` / current system-reminder item kind.
-- Existing Task reminder tests continue to pass.
-- New focused tests cover:
-  - rendering wraps body once.
-  - source/kind is retained or observable where appropriate.
-  - Task reminder uses the helper and remains history-append based.
-  - no hidden context-only injection path is introduced.
-- `cargo fmt --check`
-- `cargo check -p pod -p llm-worker -p session-store`
-- Relevant focused tests, e.g. `cargo test -p pod reminder --no-default-features`.
-
-## Out of scope
-
-- Adding a second reminder policy.
-- Changing Task reminder thresholds/cooldown.
-- Changing Notify/PodEvent user-visible behavior.
-- UI actionbar notices.
-- Prompt text changes.
-- Generic notification center or reminder scheduling service.
-
-
----

.yoi/tickets/00001KSKBPWG8/item.md

@@ -1,21 +0,0 @@
----
-title: "Bashツールがファイル編集に常用されている問題をdesciptionで抑制"
-state: "closed"
-created_at: "2026-05-27T00:00:21Z"
-updated_at: "2026-05-31T22:36:34Z"
----
-
-## Migration reference
-
-- legacy_ticket: null
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# Bashツールがファイル編集に常用されている問題をdesciptionで抑制
-
-## Background
-
-This work item was migrated from an unfinished TODO.md entry that did not have a dedicated legacy ticket file.
-
-## Acceptance criteria
-
-- Define the concrete requirements before implementation.

.yoi/tickets/00001KSKBPWG8/resolution.md

@@ -1 +0,0 @@
-Closed without implementation for now. Current Bash tool description already nudges agents toward Read/Edit/Glob/Grep over shell-based file edits, and this is not urgent enough to carry as an active work item. If the behavior becomes a recurring problem, reopen as a focused prompt-description polish ticket covering Bash child processes such as cat/tee/sed/perl/python rewrites.

.yoi/tickets/00001KSKBPWG8/thread.md

@@ -1,16 +0,0 @@
-<!-- event: migration author: tickets.sh-migration at: 2026-05-27T00:00:21Z -->
-
-## Migrated
-
-Migrated from TODO.md entry without a legacy ticket file. No legacy review file was present at migration time.
-
----
-
-<!-- event: close author: hare at: 2026-05-31T22:36:34Z status: closed -->
-
-## Closed
-
-Closed without implementation for now. Current Bash tool description already nudges agents toward Read/Edit/Glob/Grep over shell-based file edits, and this is not urgent enough to carry as an active work item. If the behavior becomes a recurring problem, reopen as a focused prompt-description polish ticket covering Bash child processes such as cat/tee/sed/perl/python rewrites.
-
-
----

.yoi/tickets/00001KSKBPXFG/item.md

@@ -1,109 +0,0 @@
----
-title: "Nix profile entrypoints that resolve to portable Pod manifests"
-state: "closed"
-created_at: "2026-05-27T00:00:22Z"
-updated_at: "2026-05-29T17:45:59Z"
----
-
-## Migration reference
-
-- legacy_ticket: null
-- migrated_from: TODO.md / tickets directory migration on 2026-05-27
-
-# Nix profile entrypoints that resolve to portable Pod manifests
-
-## Background
-
-This work item was migrated from an unfinished TODO.md entry:
-
-> 事前定義したManifestをProfile的に扱い、Orchestrator/Coder/Researcherで別々のモデル/設定を使わせる運用ができるようにする
-
-The current manifest cascade is good at configuration defaults by location: built-in defaults, user manifest, workspace manifest, and explicit overlays. That is less suitable for operational role selection. Users want to choose between profiles such as Orchestrator, Coder, Researcher, Reviewer, or cheap/fast variants, and they want those profiles to be portable as a pure artifact rather than assembled implicitly from several ambient layers.
-
-Another problem is authoring ergonomics. The current manifest exposes many low-level numeric parameters that require implementation-specific intuition, such as compaction thresholds, pruning protection sizes, memory thresholds, and feature-specific token limits. Profiles should let users express high-level intent and reusable presets while the resolver produces the precise runtime manifest.
-
-## Related work
-
-- `work-items/open/20260529-145355-manifest-profile-encrypted-secrets/item.md`: profiles should integrate with explicit encrypted secret references so API keys/tokens are not limited to process environment variables.
-
-## Design direction
-
-Use Nix as the default human-authored profile format. A profile is a Nix expression that produces the final Pod manifest/configuration artifact through an Insomnia-provided `mkProfile` / `mkManifest` style library.
-
-The profile itself is the source of truth. Commonality, imports, role presets, and any cascade-like behavior should be expressed in Nix by the profile author instead of being implemented as an additional ambient manifest cascade in Insomnia.
-
-The runtime boundary should be:
-
-```text
-selected Nix profile + explicit startup inputs
-  => deterministic resolved manifest/config snapshot
-  => Pod runtime
-```
-
-Do not introduce a three-layer authoring model where Nix generates TOML profiles that then merge into TOML manifests. That would make manifest/profile/Nix ownership unclear and hard to operate. Rust should consume the resolved artifact, ideally as a typed JSON/config representation, and preserve a snapshot for Pod restore.
-
-## Requirements
-
-- Add a Nix-based profile entrypoint as the default path for new Pod creation.
-  - Provide an Insomnia Nix library with `mkProfile` / `mkManifest` helpers.
-  - The helper should produce a pure resolved manifest/config artifact that Rust can deserialize and validate.
-  - Profile authors may use Nix imports/functions to share common settings, implement their own cascade, or build role presets.
-- Treat the resolved manifest/config as the runtime contract.
-  - Persist the selected profile identity/source and the resolved snapshot in Pod/session metadata.
-  - Pod resume should prefer the saved resolved snapshot, not silently re-evaluate the Nix profile.
-  - Re-evaluating a profile for an existing Pod must be explicit because it may change model, tools, permissions, or thresholds.
-- Move role-oriented authoring into profiles.
-  - Support profiles for roles such as Orchestrator, Coder, Researcher, Reviewer, and cost/performance variants.
-  - Profiles should be able to select model/provider settings, prompts, tools, permissions, memory behavior, web/search behavior, workflows, skills, and context/compaction strategy.
-  - Prefer semantic presets in the Nix library for values that are difficult to tune by raw numbers, e.g. context budget, compaction behavior, retention, autonomy, and tool policy.
-  - Keep raw low-level numeric overrides available as an advanced escape hatch, not the primary user-facing interface.
-- Shrink ambient cascade to discovery/default selection rather than runtime config merging.
-  - User/project configuration may provide profile registries, aliases, defaults, and UI preferences.
-  - User/project configuration should not be required as intermediate runtime override layers for model IDs, compaction thresholds, or other behavior controlled by the selected profile.
-  - Existing TOML manifest cascade can remain as compatibility/debug/test infrastructure, but it should not be the main profile design.
-- Add profile discovery and selection UX.
-  - New Pod creation UI should show a selectable profile field such as `profile: coder (default)`.
-  - The profile picker should list built-in/user/project/explicit profiles with enough source/default information to avoid ambiguity.
-  - CLI/TUI should support explicit profile selection by name/source and by path/flakeref where appropriate.
-  - Ambiguous profile names should fail closed or require source-qualified selection rather than being implicitly merged.
-- Keep secrets as references, not plaintext values.
-  - Nix profiles may refer to credentials using typed secret references, e.g. `secrets.ref "brave.search.default"`.
-  - Nix evaluation output, resolved config serialization, diagnostics, session logs, and model context must not contain plaintext secrets.
-  - Secret dereferencing/decryption happens in Rust at the consumer boundary.
-- Define compatibility and fallback behavior.
-  - `--manifest` / TOML manifest loading may continue to work for compatibility, tests, fixtures, and low-level debugging.
-  - If Nix is unavailable, diagnostics should clearly say that profile resolution requires Nix and point to the manifest/resolved-config fallback path.
-  - Existing manifest behavior should not be broken until the Nix profile path is implemented and documented.
-
-## Open design points
-
-- Exact Nix entrypoint shape:
-  - flake output names, e.g. `insomniaProfiles.<name>` / `profiles.<name>`
-  - path-based profiles, e.g. `.insomnia/profiles/coder/profile.nix`
-  - whether both are supported initially
-- Exact Rust-facing artifact:
-  - JSON resolved config vs TOML manifest snapshot vs a new typed `ResolvedPodConfig`
-  - whether `PodManifest` remains the final runtime type or becomes the legacy/compatibility representation
-- Profile registry/default storage:
-  - where user-level profile aliases live
-  - where project-level defaults live
-  - how built-in profiles are exposed
-- How much Nix support is external-command based initially vs embedded/library-integrated later.
-- How profile summaries are generated for the new Pod UI without exposing low-level internals or secrets.
-
-## Acceptance criteria
-
-- A Nix profile can be selected when creating a new Pod and resolves to the complete runtime manifest/config for that Pod.
-- Insomnia provides a documented `mkProfile` / `mkManifest` Nix helper for producing a valid resolved profile artifact.
-- Profile authors can share common settings and implement cascade-like composition in Nix without relying on ambient user/project manifest merging.
-- New Pod UI includes profile selection and displays the effective default, e.g. `profile: coder (default)`.
-- CLI/TUI profile selection supports at least one explicit path/flakeref flow and one discovered-name/default flow.
-- Resolved profile artifacts are validated with clear diagnostics before Pod creation.
-- Pod/session metadata persists the selected profile identity/source and the resolved snapshot.
-- Pod resume uses the persisted resolved snapshot unless the user explicitly asks to reload/re-resolve the profile.
-- Secret references are preserved as references through Nix evaluation and resolved config; plaintext secrets are not written to config snapshots, logs, diagnostics, or model context.
-- Existing TOML manifest path remains available as a compatibility/debug/test path during the migration.
-- Documentation explains the new profile model, why ambient cascade is no longer the primary runtime config mechanism, and how users should structure reusable Nix profiles.
-- Focused tests cover Nix profile resolution, validation errors, profile default/source selection, ambiguity handling, snapshot persistence, and no-plaintext secret serialization paths.
-- `cargo fmt --check`
-- Relevant manifest/profile/pod/tui tests pass.