fix: clear encrypted-only thinking snapshots

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

.gitignore

@@ -1,5 +1,6 @@
 /target
-.direnv
+/result
+/.direnv
+/.worktree
 *.local*
 .env
-.worktree

.insomnia/.gitignore

@@ -1 +0,0 @@
-/memory/

.insomnia/manifest.toml

@@ -1,30 +0,0 @@
-[scope]
-allow = [
-    { target = ".", permission = "write", recursive = true },
-]
-
-[session]
-record_event_trace = true
-
-[worker]
-reasoning = "high"
-
-[model]
-ref = "codex-oauth/gpt-5.5"
-
-[compaction]
-compact_threshold = 200000
-compact_request_threshold = 240000
-compact_worker_max_input_tokens = 100000
-
-[memory]
-extract_threshold = 50000
-
-consolidation_threshold_files = 5
-consolidation_threshold_bytes = 50000
-
-[web]
-enabled = true
-[web.search]
-provider = "brave"
-api_key_env = "BRAVE_SEARCH_API_KEY"

.insomnia/workflow/auto-maintain.md

@@ -1,148 +0,0 @@
----
-description: TODO / tickets / docs / git history から次の作業候補を見繕い、課題発見や方針決定を半自動でイテレーションする WIP maintainer workflow
-model_invokation: false
-user_invocable: true
-requires: []
----
-# Auto Maintain Workflow (WIP)
-
-insomnia を AI maintainer として運用するための半自動 loop。TODO / tickets から「今進められそうな作業」を選ぶだけでなく、課題の発見、設計判断の切り分け、次に人間へ戻すべき問いの整理までを扱う。
-
-これは unattended 自動開発ではない。実装の並列委譲は `multi-agent-workflow`、worktree の機械的作成は `worktree-workflow` に任せる。本 Workflow はその前段として、何を進めるべきか、何をまだ決めるべきか、下位 orchestrator にどの intent packet を渡すべきかを整理する。
-
-参照:
-
-- `docs/plan/ai-maintainer.md`
-- `tickets/auto-maintain-workflow.md`
-
-## 位置づけ
-
-AI maintainer の目的は、コードを書くこと自体ではなく、プロジェクト状態を前に進めることである。
-
-この Workflow は WIP として、以下を行う。
-
-- TODO / tickets / docs / git history を読んで現在地を把握する。
-- 実装可能な ticket と、方針決定が必要な ticket を分ける。
-- 小さく実装できる候補を提案する。
-- 複数 ticket からなる作業群は、下位 orchestrator に任せる単位として整理する。
-- 設計相談が必要な論点を人間に戻す。
-- 運用上の問題や繰り返し発生する詰まりを report / ticket / workflow 改訂候補として整理する。
-
-## 非目標
-
-現時点では以下をしない。
-
-- 常駐 scheduler として自動実行する。
-- 人間の合意なしに新規 ticket を作る。
-- 人間の合意なしに既存 ticket を大幅変更する。
-- 人間の合意なしに ticket 完了削除を行う。
-- push する。
-- Workflow を自律生成・自律改訂する。
-- scope / permission / history persistence / prompt context 加工原則に関わる判断を勝手に決める。
-
-## 入力として読むもの
-
-必要に応じて以下を読む。
-
-1. `TODO.md`
-2. `tickets/*.md`
-3. `docs/plan/`
-4. `docs/report/`
-5. `git log --oneline` / ticket file の git history
-6. 既存 worktree / branch 状態
-7. 最近の失敗や通知、ユーザーからの観測
-
-TODO と ticket の不整合を見つけたら、勝手に修正せず、まず報告する。ただしユーザーが明示的に「直して」と言った場合は Mode 1 として整理してよい。
-
-## 分類
-
-候補を以下に分ける。
-
-### A. 実装委譲可能
-
-- 要件と完了条件が具体的。
-- 影響範囲が限定的。
-- test / build で確認できる。
-- 大きな設計判断が不要。
-- scope を狭く切れる。
-
-この場合は、人間に候補として提示する。人間が実行を許可したら `$user/multi-agent-workflow` に進む。複数 ticket や連続した作業群では、最上位 Pod が直接 coder を抱えず、下位 orchestrator に intent packet を渡して coder / reviewer sibling loop を管理させる。
-
-### B. 方針決定が必要
-
-- 複数の設計方針が自然に導ける。
-- protocol / permission / scope / persistence / prompt context に触れる。
-- UX の仕様が未確定。
-- 既存 ticket の要件が古い。
-
-この場合は、実装せず、決めるべき問いを短く提示する。
-
-### C. ticket 整理が必要
-
-- TODO にあるが ticket がない。
-- ticket があるが TODO にない。
-- 完了済みに見えるが残っている。
-- ticket の前提が変わっている。
-
-この場合は、不整合と修正案を提示する。修正は人間の許可後に行う。
-
-### D. report / workflow 改善候補
-
-- 同じ tool 問題が繰り返し出る。
-- Workflow の指示が曖昧で実装 Pod が迷った。
-- coder / reviewer / orchestrator の責務が混ざり、親 Pod が細かい code review に戻ってしまった。
-- AI が過剰に Task tool を使うなど、運用上の癖が出た。
-- 通知や Pod completion tracking など、開発基盤の不足が観測された。
-
-この場合は、すぐ ticket 化するか、`docs/report/` に観測として残すか、人間に確認する。
-
-## 半自動 iteration
-
-1. 状態把握
-   - TODO / tickets / git status を読む。
-   - 最近完了した流れや未完了 branch を確認する。
-
-2. 候補抽出
-   - 実装可能そうな ticket を 2〜5 件挙げる。
-   - correctness / developer experience / user-visible UX / cleanup で分類する。
-
-3. 推奨順位
-   - blocking correctness を最優先。
-   - 実害が出ている運用問題を次点。
-   - 小さく完了できる UX / cleanup を次点。
-   - 大きな設計変更は方針相談に回す。
-
-4. 人間への提示
-   - 「次に進めるなら X」を1つ推奨する。
-   - 理由を短く述べる。
-   - 実装委譲する場合の scope / test 方針を添える。
-   - 複数 ticket の作業群なら、下位 orchestrator に任せる単位として提示する。
-
-5. 実行への接続
-   - 人間が「進めて」と言ったら `$user/multi-agent-workflow` に接続する。
-   - 単発 ticket か、下位 orchestrator に任せる ticket 群かを明示する。
-   - 下位 orchestrator に渡す intent / requirements / invariants / non-goals / escalation 条件を短くまとめる。
-   - worktree 作成は `$user/worktree-workflow` に従う。
-
-## エスカレーション基準
-
-以下では実装に進まず、人間へ戻す。
-
-- ticket の要件から複数の設計方針が自然に導ける。
-- 長期構造、crate boundary、protocol、permission、scope、history persistence に触れる。
-- prompt context 加工原則に関わる。
-- 新 ticket の作成、既存 ticket の大幅変更、ticket 完了削除について合意がない。
-- test 不能、再現不能、または作業範囲外の不具合に遭遇した。
-- WorkItem / Thread / Lease / maintainer state など、まだ設計中の概念が必要になる。
-- 下位 orchestrator に委譲するには intent / invariant / escalation 条件が曖昧すぎる。
-
-## まだ固定しないもの
-
-以下は `docs/plan/ai-maintainer.md` の上位設計に残し、本 Workflow では詳細を固定しない。
-
-- WorkItemStore / LeaseStore。
-- operation inbox / trial log。
-- QA feedback を ticket / review / report のどれに落とすか。
-- AI 自身の feedback を Knowledge / report / ticket / workflow 改訂のどれにするか。
-- maintainer doctor。
-- reviewer Pod の評価基準の機械化。

.insomnia/workflow/multi-agent-workflow.md

@@ -1,306 +0,0 @@
----
-description: worktree と sibling の coder / reviewer Pod を使い、下位 orchestrator が複数 ticket の実装・外部レビュー・修正・完了準備を管理する orchestration フロー
-model_invokation: true
-user_invocable: true
-requires: []
----
-# Multi-agent Worktree Workflow
-
-insomnia を insomnia で開発する際の、worktree + coder Pod + 外部 reviewer Pod + orchestrator Pod の標準フロー。これは **最上位 Pod が細かい code review を抱えず、下位 orchestrator が実装と外部レビューの loop を完了状態まで運ぶためのフロー** である。
-
-worktree の機械的作成手順は `$user/worktree-workflow`、実装前の要件同期・反証 preflight は `$user/ticket-preflight-workflow`、ticket 候補選定や方針探索の半自動 loop は `$user/auto-maintain` に分ける。
-
-この Workflow は、対象 ticket が implementation-ready であることを前提にする。設計境界・仕様・authority boundary が未同期の場合は、worktree 作成や coder Pod 起動の前に `ticket-preflight-workflow` を通す。
-
-## 目的
-
-- 実装差分を ticket ごとの child worktree に隔離する。
-- coder Pod に narrow write scope を渡して実装させる。
-- reviewer Pod を coder の子ではなく **同じ orchestrator 配下の sibling** として立て、外部レビューを行わせる。
-- orchestrator は coder / reviewer のやり取り、修正 loop、validation、merge-ready dossier 作成に責任を持つ。
-- 最上位 orchestrator は、コードを直接理解し切ることではなく、委譲した intent / 要件 / invariant に沿って下位 orchestrator が完了まで運んだかを acceptance する。
-
-## 階層モデル
-
-基本形は以下。
-
-```text
-最上位 orchestrator Pod
-  - 人間との会話相手
-  - intent / 要件 / invariant / escalation 条件を定義
-  - 複数の作業群を並列管理
-  - final merge / ticket close / main workspace validation を行う
-  - 原則として line-by-line code review を主業務にしない
-
-下位 orchestrator Pod（area / epic / ticket-group coordinator）
-  - 連続した複数 ticket または大きめの ticket 群を完了状態まで運ぶ
-  - worktree / branch / coder / reviewer / validation / 修正 loop を管理する
-  - coder と reviewer を sibling として扱う
-  - 親には merge-ready dossier と残論点だけを返す
-
-coder Pod
-  - 指定 worktree / branch に実装する
-  - ticket 外判断や設計衝突は orchestrator に戻す
-  - reviewer に直接反論・修正依頼を完結させず、orchestrator に報告する
-
-reviewer Pod
-  - 原則 read-only
-  - ticket / intent packet / diff / validation 結果を読む
-  - 実際のコード変更が概念的に何を変えたかを説明する
-  - intent / 要件 / invariant に反する blocker を分類して返す
-```
-
-一段だけで足りる小さい ticket では、最上位 orchestrator が直接 coder / reviewer sibling を扱ってよい。複数 ticket や設計境界をまたぐ作業では、最上位の下に下位 orchestrator を挟む。
-
-## 開始条件
-
-以下が揃っている時に使う。
-
-- 対象 ticket または ticket 群が決まっている。
-- ticket の背景・要件・完了条件から実装方針が概ね導ける。
-- worktree 作成と git 書き込み操作について、人間の許可がある。
-- main workspace の unrelated dirty changes を把握している。
-- 下位 orchestrator に渡す intent / invariant / non-goals / escalation 条件を短く書ける。
-- 設計境界・仕様・authority boundary に不確定要素がある場合、`ticket-preflight-workflow` の結果が ticket thread に記録されている。
-
-設計方針が複数自然に導ける場合、protocol / scope / permission / history persistence に触れる場合、ticket 自体の再定義が必要な場合は、実装委譲前に `ticket-preflight-workflow` を通し、必要なら人間へ戻す。ただし下位 orchestrator に探索だけを委譲することはできる。
-
-## Intent packet
-
-階層化すると人間の意図が劣化しやすい。下位 orchestrator や coder / reviewer へは、自然文の依頼だけでなく intent packet を渡す。
-
-標準形:
-
-```text
-Intent:
-- 何を実現するか。
-
-Requirements:
-- 完了時に満たすべき observable な要件。
-
-Invariants:
-- 壊してはいけない設計境界。
-- 残してはいけない旧概念や互換層。
-
-Non-goals:
-- 今回やらないこと。
-
-Escalate if:
-- 親へ戻すべき判断条件。
-
-Validation:
-- 実行すべき format / build / test / doctor。
-```
-
-reviewer には coder の実装方針ではなく、この intent packet と diff を中心に読ませる。
-
-## orchestrator の責務
-
-下位 orchestrator を挟まない場合は、以下を最上位 orchestrator が行う。下位 orchestrator を挟む場合は、最上位は intent packet を渡し、以下の実務を下位に委譲する。
-
-1. 状態確認
-   - `git status --short --branch`
-   - 対象 ticket / ticket 群
-   - 関連 TODO / docs / 既存 worktree
-   - preflight が必要な ticket では、`ticket-preflight-workflow` の分類・要件同期・critical risks
-
-2. worktree 作成
-   - `$user/worktree-workflow` に従い `./.worktree/<task-name>` を作る。
-   - `.insomnia` を sparse checkout で除外する。
-
-3. coder Pod spawn
-   - read scope: main workspace 全体。
-   - write scope: child worktree、または必要最小 directory。
-   - task には以下を明示する。
-     - child worktree path / branch
-     - 対象 ticket path
-     - intent packet
-     - Bash は必ず child worktree に `cd` すること
-     - main workspace の `TODO.md` / `tickets/` / `docs/report/` / `.insomnia` は編集しないこと
-     - 範囲外事項
-     - 実行すべき build / test / format
-     - 完了報告項目
-
-4. coder 完了確認
-   - `ReadPodOutput` で報告を読む。
-   - 通知が来ない場合でも、worktree の `git status` / `git diff` / test で完了状態を確認する。
-   - coder が止まった場合、worktree 状態を見て再 spawn / rollback / 親 escalation を判断する。
-
-5. reviewer Pod spawn
-   - reviewer は coder の子ではなく orchestrator 配下の sibling として立てる。
-   - 原則 read-only scope にする。
-   - reviewer に渡すもの:
-     - ticket / intent packet
-     - branch / commit / diff の読み方
-     - 実行済み validation
-     - blocker / non-blocker / acceptable の分類基準
-   - reviewer の主目的は「コードの詳細を親の代わりに説明し、intent / invariant 違反を見つけること」。
-
-6. review → 修正 loop
-   - reviewer finding を orchestrator が読む。
-   - blocker は coder に修正依頼する。
-   - reviewer の指摘を却下する場合は、orchestrator が理由を dossier に残す。
-   - 修正後は focused validation を実行し、必要なら reviewer に再確認させる。
-   - reviewer の blocker が未解決のまま親に提出しない。
-
-7. merge-ready dossier 作成
-   - 親がコードを直接理解しなくても判断できるよう、変更の概念的説明と evidence をまとめる。
-
-8. merge / lifecycle
-   - 最上位 orchestrator または人間の許可を持つ orchestrator が main workspace へ merge する。
-   - `TODO.md` から該当行を削除し、ticket を完了処理して commit する。
-   - main workspace で必要な test / `cargo check --workspace` / `cargo fmt --check` を再実行する。
-
-## coder Pod の責務
-
-- child worktree 内でのみ実装する。
-- main workspace の管理ファイルを書かない。
-- intent / requirements / invariants / non-goals を読んでから実装する。
-- 指定された build / test / format を実行する。
-- ticket 要件外の設計変更、依存関係追加、scope / permission / history persistence / prompt context 加工原則に触れる変更が必要なら止めて orchestrator に報告する。
-- 完了時に以下を報告する。
-  - worktree path / branch
-  - commit hash（commit した場合）
-  - 変更ファイル
-  - 実装概要
-  - 実行した build / test / format
-  - 未解決事項
-  - review に回せるか
-
-## reviewer Pod の責務
-
-reviewer は coder の subordinate ではない。orchestrator 配下の sibling として、実装 diff を外部から読む。
-
-- 原則 read-only で作業する。
-- ticket / intent packet / diff / validation 結果を読む。
-- 実際のコード変更が概念的に何を変えたかを説明する。
-- 親や上位 orchestrator が line-by-line diff を読まずに判断できるよう、以下を整理する。
-  - 変更の概念モデル
-  - intent / requirements との対応
-  - invariant 違反の有無
-  - 旧概念・禁止語彙・不要な互換層の残存
-  - validation の妥当性
-  - blocker / non-blocker / follow-up
-- reviewer は直接 merge しない。
-- reviewer は coder に直接作業指示を出さず、orchestrator に finding を返す。
-
-## commit 方針
-
-coder Pod には child worktree 内での commit を許可してよい。
-
-- commit は ticket 内で意味のある粒度にする。
-  - 例: `feat: ...`、`fix: ...`、`test: ...`、`docs: ...`
-- coder Pod は merge / push / branch deletion / worktree remove をしない。
-- coder Pod は `TODO.md` / ticket の完了処理 commit をしない。
-- orchestrator は review 時に commit 粒度も確認する。
-- 必要な修正は、原則追加 commit として積む。履歴改変や squash は人間の明示指示がある時だけ行う。
-
-## Review → 修正 → 完了の標準形
-
-### Approve
-
-1. coder Pod / reviewer Pod を停止し、scope を回収する。
-2. orchestrator が merge-ready dossier を確認する。
-3. 最上位 orchestrator が必要最小限の spot check を行う。
-4. main workspace で `git merge --no-ff <branch>` する。
-5. `TODO.md` と ticket を完了処理して commit する。
-6. main workspace で検証コマンドを再実行する。
-7. 変更内容・commit・検証結果・残 dirty changes を報告する。
-
-### Request changes
-
-1. reviewer finding または orchestrator finding を blocker / non-blocker に分ける。
-2. blocker はファイル / 行 / 理由 / 修正方針つきで coder に戻す。
-3. coder が停止済みなら、同じ worktree / branch / scope で再 spawn する。
-4. 修正後に focused test と必要な broader test を再実行する。
-5. 必要なら reviewer に再確認させる。
-6. blocker が解消したら dossier を更新する。
-
-### Non-blocking comments
-
-- ticket 要件外の改善はその場で混ぜない。
-- 必要なら後続 ticket / docs/report にする。
-- non-blocking を理由に completion を遅らせない。
-
-## 並列実装時の注意
-
-- 1 ticket = 1 worktree = 1 branch を基本にする。
-- 複数 Pod に同じ write scope を渡さない。
-- parent / orchestrator は coder の write scope 配下を直接編集しない。
-- reviewer は read-only を基本にする。review artifact を書かせる場合は ticket artifacts など限定 scope にする。
-- 依存関係がある ticket は、土台 branch を merge してから次 worktree を切る。
-- parallel に走らせた Pod の完了通知は取りこぼしうるため、`ReadPodOutput` と worktree 状態で確認する。
-
-## merge-ready dossier の標準形
-
-```text
-Status:
-- completed / blocked / needs parent decision
-
-Scope:
-- ticket(s): <path>
-- branch: <name>
-- commits:
-  - <hash> <subject>
-
-Intent check:
-- invariant 1: ok / violated / not applicable, evidence ...
-- invariant 2: ok / violated / not applicable, evidence ...
-
-Implementation summary:
-- 変更の概念的説明: ...
-- 主要変更ファイル: ...
-- compatibility / migration: ...
-
-Coder loop:
-- coder pod: <name>
-- produced commits: ...
-- unresolved coder notes: ...
-
-External review:
-- reviewer pod: <name>
-- blockers found: ...
-- blockers fixed: ...
-- rejected findings and reasons: ...
-- non-blocking follow-ups: ...
-
-Validation:
-- cargo fmt --check
-- cargo check --workspace
-- cargo test ...
-- ./tickets.sh doctor
-
-Parent decision needed:
-- none / specific question
-
-Residual risk:
-- ...
-
-Dirty state:
-- ...
-```
-
-## 最上位 orchestrator の acceptance
-
-最上位 orchestrator は、下位 orchestrator の成果を code review するのではなく acceptance する。
-
-確認するもの:
-
-- intent packet が保持されているか。
-- reviewer が coder と独立した sibling として機能したか。
-- blocker が未解決のまま握りつぶされていないか。
-- 変更の概念的説明が要件と対応しているか。
-- validation が ticket のリスクに対して十分か。
-- escalation すべき判断を下位が勝手に決めていないか。
-
-必要なら spot check するが、常態的な line-by-line review に戻らない。
-
-## この Workflow で扱わないもの
-
-以下は `$user/auto-maintain` または別の設計相談で扱う。
-
-- ticket 候補を見繕うこと。
-- 新規 ticket 作成判断。
-- QA feedback / AI feedback を ticket / report / workflow に落とす判断。
-- 長期 maintainer loop / WorkItemStore / LeaseStore の設計。
-- reviewer Pod の品質評価を機械的に採点する仕組み。

.insomnia/workflow/ticket-preflight-workflow.md

@@ -1,167 +0,0 @@
----
-description: ticket を実装委譲する前に、要件・前提・設計境界・反証観点を同期し、tickets.sh に記録する preflight フロー
-model_invokation: true
-user_invocable: true
-requires: []
----
-# Ticket Preflight Workflow
-
-insomnia プロジェクトで ticket を実装に渡す前に、要件・前提・設計境界・反証観点を同期するための Workflow。これは **実装前の gate** であり、worktree 作成や coder / reviewer Pod の起動は `multi-agent-workflow` / `worktree-workflow` 側で扱う。
-
-目的は「ticket があるから実装する」状態を避け、ticket が **実装可能な仕様** なのか、**調査 ticket** なのか、**人間との仕様同期が必要な未決定 ticket** なのかを明確にすることである。
-
-## 適用する場面
-
-以下のいずれかに当てはまる ticket は、実装委譲前にこの Workflow を通す。
-
-- profile / manifest / scope / permission / session / history / pod-store / prompt context など authority boundary に触れる。
-- ticket の文面から複数の自然な設計方針が導ける。
-- 「どう実装するか」以前に「何を仕様とするか」が曖昧である。
-- 既存 implementation plan があるが、抽象化・責務境界・ユーザー体験に疑問がある。
-- 過去 decision / memory / docs / ticket thread と矛盾しそうである。
-- coder Pod に渡す intent packet を短く書けない。
-
-小さなバグ修正や仕様が明確な局所変更では、この Workflow は省略してよい。ただし省略理由が曖昧な場合は preflight する。
-
-## tickets.sh 運用方針
-
-作業管理の authority は `work-items/` と `tickets.sh` である。preflight の結果は、口頭の会話だけで終わらせず、ticket の `thread.md` または `item.md` に残す。
-
-- 新規の前提・要件・受け入れ条件は、必要に応じて `item.md` を更新する。
-- 調査結果・実装前 plan は `./tickets.sh comment <ticket> --role plan --file <file>` で残す。
-- 採用/却下した設計判断、実装停止判断、仕様同期の結論は `--role decision` で残す。
-- 実装に入ってよい状態になったら、その根拠を intent packet として ticket thread に残す。
-- 仕様が未決定なら、実装 ticket にせず requirements-sync / spike / design ticket として切り分ける。
-- ticket の timestamp/frontmatter が更新される場合は、関連変更と一緒に commit する。
-- ticket 作成・更新・レビュー・完了は git commit で記録する。push はしない。
-
-## 手順
-
-### 1. 状態確認
-
-- `git status --short --branch`
-- 対象 ticket の `item.md` / `thread.md` / artifacts
-- 関連 ticket / docs / workflow / Knowledge / memory decision
-- 既存 worktree / branch / running Pod の有無
-
-この段階で unrelated dirty changes がある場合は、preflight の記録だけを行うか、人間に確認してから進める。
-
-### 2. ticket の種類を分類する
-
-以下のどれかに分類する。
-
-```text
-implementation-ready:
-- 要件・受け入れ条件・invariant が明確で、実装方針が一意または十分絞れている。
-
-requirements-sync-needed:
-- ticket の目的は見えているが、仕様・用語・責務境界・ユーザー体験の同期が必要。
-
-spike-needed:
-- 技術的実現性・依存関係・ライセンス・性能・diagnostics などを先に調べる必要がある。
-
-blocked-needs-human-decision:
-- 複数方針があり、AI が勝手に決めると設計境界や product API を固定してしまう。
-```
-
-`implementation-ready` 以外は、coder Pod に実装を委譲しない。
-
-### 3. 要件同期
-
-最低限、以下を確認する。
-
-- 完了時に observable に何が変わるか。
-- ticket の主語は何か: user-facing behavior / internal architecture / cleanup / investigation。
-- 用語が既存設計と一致しているか。
-- 何をやらないか。
-- 後方互換が必要か、不要な互換層を作ろうとしていないか。
-- 既存の authority boundary を変えるか。
-- runtime state / persisted state / config / profile / manifest / session log / pod metadata のどれが authority か。
-
-必要なら ticket `item.md` の Background / Requirements / Acceptance criteria を更新する。
-
-### 4. 現行コードと過去判断の map を作る
-
-実装前に、少なくとも関連する current code paths を列挙する。
-
-```text
-Current code map:
-- file/function: 現在の責務
-- file/function: 変更候補
-- file/function: 触ってはいけない境界
-```
-
-この map は簡潔でよい。目的は coder Pod が blind に探しながら設計を固定するのを防ぐこと。
-
-### 5. 批判的 preflight
-
-実装方針を一度疑う。以下の問いに答える。
-
-- この ticket は本当に実装 ticket か、それとも仕様同期 ticket か。
-- 最も自然に見える実装が失敗するとしたらどこか。
-- 抽象化に失敗して「別名の同じもの」を作っていないか。
-- runtime-bound な値を reusable config に混ぜていないか。
-- profile / manifest / scope / session / pod-store などの authority を逆転させていないか。
-- user-facing API を安易に public contract 化していないか。
-- external dependency / license / portability / packaging の問題はないか。
-- reviewer が diff だけ読んでも見落とす設計リスクは何か。
-
-この問いへの答えを `plan` または `decision` として ticket thread に残す。
-
-### 6. intent packet を作る
-
-実装に入ってよい場合だけ、`multi-agent-workflow` に渡す intent packet を作る。
-
-```text
-Intent:
-- 何を実現するか。
-
-Requirements:
-- observable な完了条件。
-
-Invariants:
-- 壊してはいけない authority boundary / design boundary。
-
-Non-goals:
-- 今回やらないこと。
-
-Escalate if:
-- 親/人間に戻す判断条件。
-
-Validation:
-- focused test / broader check / doctor / docs 更新。
-
-Current code map:
-- 実装対象と触ってはいけない場所。
-
-Critical risks:
-- reviewer にも見てほしい失敗パターン。
-```
-
-この intent packet が短く書けない場合は、実装委譲せず requirements-sync-needed とする。
-
-## review への引き継ぎ
-
-preflight で出た critical risks は reviewer Pod にも渡す。reviewer は diff だけでなく、ticket の前提・要件・invariant と preflight の反証観点を読む。
-
-reviewer に期待すること:
-
-- 実装が preflight の intent に対応しているか。
-- 抽象化失敗や authority boundary 違反がないか。
-- preflight で挙げた失敗パターンに落ちていないか。
-- validation がリスクに対して十分か。
-
-## 完了条件
-
-この Workflow 自体の完了条件は、次のいずれかである。
-
-- ticket が `implementation-ready` になり、intent packet が thread に記録されている。
-- ticket が `requirements-sync-needed` / `spike-needed` / `blocked-needs-human-decision` として整理され、次に人間へ戻す問いまたは follow-up ticket が明確になっている。
-- ticket 自体が不要/誤りと判断され、理由が decision として記録されている。
-
-## この Workflow でしないこと
-
-- worktree を作成しない。
-- coder Pod に実装を委譲しない。
-- merge / close しない。
-- 仕様未決定のまま「小さく実装してみる」ことで public API を固定しない。

.insomnia/workflow/worktree-workflow.md

@@ -1,119 +0,0 @@
----
-description: insomnia プロジェクトで child git worktree を作成・管理するための機械的手順。coder Pod に作らせず、orchestrator Pod が main workspace で実行する。
-model_invokation: true
-user_invocable: true
-requires: []
----
-# Worktree Workflow
-
-insomnia プロジェクトで実装差分を main workspace から分離するため、`./.worktree/<task-name>` に child git worktree を作る。これは **worktree の扱い方だけ** を定める Workflow であり、ticket 選定、coder / reviewer sibling の起動、外部レビュー、merge の運用は `$user/multi-agent-workflow` 側で扱う。
-
-insomnia では Pod の write scope が排他的に委譲されるため、child worktree に `.insomnia` を置かない。main workspace は orchestration / ticket / docs / memory / workflow 管理の場所として残し、child worktree はコード差分専用の作業面として扱う。
-
-## 適用範囲
-
-この Workflow は親 Pod / 下位 orchestrator が main workspace で実行する。
-
-- coder Pod にこの Workflow を渡して worktree を作らせない。
-- coder Pod は、orchestrator が作成済みの child worktree を受け取り、その中で実装・build・test・報告を行う。
-- reviewer Pod は、coder Pod の子ではなく orchestrator 配下の sibling として、原則 read-only で main workspace と child worktree を読む。
-- ticket 作成、TODO 更新、review artifact、docs/report は main workspace 側で扱う。
-
-## 原則
-
-- 1 ticket / 1 実装 task につき 1 worktree を作る。
-- 複数 ticket を下位 orchestrator に任せる場合も、実装差分は ticket / bounded task ごとに worktree を分ける。
-- worktree path は `./.worktree/<task-name>`。
-- branch 名は原則 `<task-name>` と同じ kebab-case。
-- child worktree には `.insomnia` を出さない。
-- child worktree は実装差分用。`TODO.md` / `tickets/` / `docs/report/` / workflow / memory は原則 main workspace 側で扱う。
-- push はしない。
-
-## 事前確認
-
-作成前に以下を確認する。
-
-1. 対象 ticket / task が決まっているか。
-2. `<task-name>` が branch / path 名に使える kebab-case か。
-3. `git worktree add` を実行してよい許可があるか。
-4. main workspace に混ぜてはいけない未保存差分がないか。
-5. 同名 branch / worktree が既に存在しないか。
-6. coder / reviewer を sibling として扱う orchestrator が誰か明確か。
-
-同名 branch がある場合は、既存 branch を使うか、人間に確認する。`git worktree add -b` で上書きしない。
-
-## 作成手順
-
-main workspace で実行する。
-
-```bash
-git worktree add .worktree/<task-name> -b <task-name>
-
-git -C .worktree/<task-name> sparse-checkout init --no-cone
-git -C .worktree/<task-name> sparse-checkout set --no-cone \
-  '/*' \
-  '!/.insomnia/' \
-  '!/.insomnia/**'
-```
-
-確認する。
-
-```bash
-git -C .worktree/<task-name> status --short --branch
-test ! -e .worktree/<task-name>/.insomnia
-```
-
-失敗した場合は、worktree / branch / lock の状態を確認し、勝手に cleanup せず人間へ報告する。
-
-## Pod へ渡す scope
-
-Pod を使う場合、Pod の cwd は main workspace のままになる。必ず作業対象が child worktree であることを明示し、Bash 実行時は毎回 `cd <repo>/.worktree/<task-name> && ...` させる。
-
-coder Pod 推奨 scope:
-
-```text
-read:  <repo>
-write: <repo>/.worktree/<task-name>
-```
-
-reviewer Pod 推奨 scope:
-
-```text
-read: <repo>
-read: <repo>/.worktree/<task-name>  # main workspace の read に含まれるなら別指定不要
-```
-
-reviewer は原則 write scope を持たない。review artifact を書かせる必要がある場合だけ、ticket artifacts など限定 directory を write scope として渡す。
-
-より狭く切れる場合は、coder の write scope を変更対象 crate / directory まで狭めてよい。ただし build / test に必要な生成物を書けることを確認する。
-
-## child worktree 内の禁止事項
-
-- `.insomnia` を作らない / コピーしない。
-- main workspace の `TODO.md` / `tickets/` / `docs/report/` を編集しない。
-- merge / push / branch deletion / worktree remove をしない。
-- scope / permission / history persistence / prompt context 加工原則に関わる設計変更を無断で行わない。
-
-## 完了時の扱い
-
-worktree 作成 Workflow としては、完了時に merge しない。merge、ticket 完了、TODO 削除は `$user/multi-agent-workflow` または人間の明示指示で行う。
-
-coder Pod へ渡す完了報告項目の標準形:
-
-- worktree path
-- branch 名
-- commit hash（coder Pod に commit を許可した場合）
-- 変更ファイル
-- 実装概要
-- 実行した build / test / format
-- 未解決事項
-- review に回せるか
-
-reviewer Pod へ渡す完了報告項目の標準形:
-
-- 読んだ ticket / intent packet / diff
-- 実際のコード変更の概念的説明
-- intent / requirements / invariant との対応
-- blocker / non-blocker / follow-up
-- validation の妥当性
-- 親または上位 orchestrator が判断すべき残論点

.yoi/.gitignore

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

.yoi/objectives/00001KTNKDX3G/item.md

@@ -0,0 +1,60 @@
+---
+title: "E2E テスト戦略"
+state: "active"
+created_at: "2026-06-09T07:09:26Z"
+updated_at: "2026-06-09T07:09:26Z"
+linked_tickets: ["00001KSKBP9YG"]
+---
+
+## Goal
+
+Yoi の実プロセス・実 socket・実 provider 境界をまたぐ振る舞いを、通常の crate 内 unit / integration test だけに頼らず検証できる E2E テスト戦略を確立する。
+
+最初の到達点は、実 `pod` / product binary を spawn し、protocol 経由で最小シナリオを実行し、graceful shutdown まで確認できる opt-in E2E harness を持つこと。その上で、permission、resume/fork、spawned Pod、provider stream、TUI/Panel などの重要境界を段階的に増やせる状態にする。
+
+## Motivation / background
+
+現状のテストは crate 内の in-process coverage が厚い一方で、以下の性質は単体テストだけでは十分に確認しづらい。
+
+- 実プロセス spawn と runtime dir / socket / env の相互作用。
+- Pod controller / protocol client / session store / metadata / restore の統合挙動。
+- provider endpoint、streaming、auth/token、tool call、continuation、retry の実接続に近い振る舞い。
+- permission deny、scope、manifest/profile 解決、child Pod delegation など、複数 crate と実 runtime state をまたぐ policy。
+- TUI / Panel が前提にする Pod lifecycle や Ticket orchestration の外形。
+
+E2E は常時実行の軽いテストではなく、dogfooding 中に「この機能は実 runtime でも壊れていない」と確認するための opt-in 検証基盤として必要。
+
+## Strategy / design direction
+
+- E2E は通常の `cargo test --workspace` からは外し、明示 feature / 専用 package / 独立 job で opt-in 実行する。
+- まずはワークスペース直下の専用 E2E package / harness として設計し、個別 crate の unit test に押し込めない。
+- protocol を喋る側は TUI の PTY 操作ではなく、typed client / protocol client を使う方向を優先する。
+- provider 依存は最初から全部を対象にしない。
+  - 最小 harness では canned / fixture / mock HTTP server を使う。
+  - provider 差分は代表 provider から段階的に増やす。
+- env / runtime dir / socket path は test ごとに隔離し、並列実行方針を明示する。
+  - 必要なら最初は `--test-threads=1` 相当で安全側に倒す。
+  - 将来的には per-test runtime dir と typed launch config で並列性を上げる。
+- E2E は「全シナリオを大量に持つ」より、重要な runtime seam ごとに少数の高価値 scenario を置く。
+- 失敗時 diagnostics は、secret を出さずに process phase、socket path、session id、log path、provider fixture id を辿れる形にする。
+- E2E harness 自体が flaky にならないよう、network / time / external auth への依存は明示 opt-in に分ける。
+
+## Success criteria / exit conditions
+
+- `cargo test --workspace` では E2E が走らず、通常開発の feedback loop を重くしない。
+- 明示コマンドで E2E harness を実行できる。
+  - 例: `cargo test -p e2e --features e2e` または後続で決める同等コマンド。
+- 最小 scenario が実 `pod` / product binary を spawn し、protocol 経由で 1 turn 実行し、graceful shutdown まで通る。
+- E2E 実行は専用 runtime/data dir を使い、通常の user/workspace state を汚さない。
+- fixture / mock provider の設計があり、少なくとも 1 provider 相当の canned response を実 HTTP 経由で返せる。
+- failure diagnostics から、spawn 失敗・socket 接続失敗・provider fixture 失敗・protocol 失敗・shutdown 失敗を区別できる。
+- 後続 Ticket が permission / resume / fork / spawned Pod / provider streaming / Panel などを追加できる harness boundary がある。
+
+## Decision context
+
+- linked Ticket `00001KSKBP9YG` は、E2E harness の最初の concrete implementation Ticket として扱う。
+- この Objective は E2E 全体の中長期方針・判断軸を保持する。個別 scenario の実装や harness の細部は concrete Ticket に分ける。
+- TUI を直接 PTY で叩く方針は初期 harness では避け、protocol/client 経由を優先する。
+- provider 全対応は初期 scope にしない。fixture / mock HTTP server を基礎にし、代表 provider から段階的に広げる。
+- E2E は flakiness と実行コストが高いため、既定 CI / 既定 workspace test には入れず、opt-in 検証として始める。
+- Objective context は判断材料であり、実装 authority は各 Ticket の body/thread/artifacts と明示的な Ticket relation / OrchestrationPlan に置く。

.yoi/objectives/00001KTR7MZWH/item.md

@@ -0,0 +1,73 @@
+---
+title: "ネイティブGUIアプリケーション"
+state: "active"
+created_at: "2026-06-10T07:41:18Z"
+updated_at: "2026-06-10T07:41:18Z"
+linked_tickets: []
+---
+
+## Goal
+
+Yoi の Pod / Ticket / Orchestrator / workflow 操作を、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 境界を使う。
+
+## Motivation / background
+
+現在の TUI / Panel は dogfooding 可能な状態まで進んでいるが、複数 Pod・複数 Ticket・Orchestrator 状態・session output・role launch・review/merge dossier を同時に扱うには、terminal UI の表示密度・視覚的状態表現・スクロール/選択/比較操作に限界が出ている。
+
+ネイティブ GUI があると、以下をより自然に扱える。
+
+- live / stored Pod、Ticket lane、Orchestrator progress、Companion/Intake 状態の同時表示。
+- Ticket body/thread/artifacts、Pod output、validation evidence、diff/report の並列閲覧。
+- composer target、role action、queue/routing/attach/restore の明確な affordance。
+- long-running orchestration の通知、状態変化、失敗診断の視覚化。
+- 将来的な review / merge-ready dossier / plan board / settings editor の専用 UI。
+
+一方で、GUI を理由に runtime authority を分散させたり、Ticket/Pod state を独自 DB として二重管理したり、prompt/workflow 文字列を GUI code に直書きしたりしてはいけない。
+
+## Strategy / design direction
+
+- GUI は Yoi core の上に乗る client として作る。
+  - Pod lifecycle、session/history、Ticket storage、Profile resolution、workflow/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 余地。
+  - toolkit 選定は Objective では固定しない。候補比較と採用理由を Ticket に残す。
+- 実装は段階的に進める。
+  1. read-only workspace dashboard: Pod / Ticket / Orchestrator 状態を既存 backend から表示する。
+  2. attach / restore / open など、既存 protocol に乗る低リスク操作を追加する。
+  3. composer と role action: Companion / Intake / Orchestrator / coder / reviewer launch を既存 launcher 経由で扱う。
+  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 で見つかった state model の改善は、TUI と共有できる pure data model / client API に寄せる。
+- Prompt / workflow / role guidance は GUI code に直書きしない。
+  - LLM-facing prompt は `resources/prompts` または `.yoi/workflow` / configured resources を正とする。
+  - GUI は prompt 文言を所有せず、選択・起動・runtime context の入力面を担当する。
+- Security / privacy / authority boundary を保つ。
+  - secret-like data は UI diagnostics / logs / model context に漏らさない。
+  - permission / scope / profile の authority は既存 resolver/policy に従う。
+  - GUI convenience action は durable Ticket/Pod state transition と対応付け、暗黙の side effect を避ける。
+
+## Success criteria / exit conditions
+
+- 明示コマンドまたは binary で native GUI を起動できる。
+- 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 境界を壊さない。
+- 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 が定義されている。
+
+## 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 の正本を所有しない。
+- Prompt 直書き禁止方針を守る。GUI 実装中に LLM-facing 文言が必要になった場合は、`resources/prompts` または workflow/resource 側に置く。
+- 初期 target は dogfooding しやすい desktop GUI とし、public release / cross-platform polish / installer は後続段階で扱う。

.yoi/objectives/00001KTR80WMN/item.md

@@ -0,0 +1,111 @@
+---
+title: 'MCP local stdio integration roadmap'
+state: 'active'
+created_at: '2026-06-10T07:48:45Z'
+updated_at: '2026-06-20T05:34:00Z'
+linked_tickets: ['00001KTR81P9X', '00001KV0SP0TY', '00001KVHR3WRF', '00001KVHR3WRY', '00001KVHR3WS6', '00001KVHR3WSD', '00001KVHR3WSN', '00001KVHR3WSW']
+---
+
+## Goal
+
+Add MCP local stdio integration to Yoi without weakening Worker history, prompt-context, scoped tool permission, or Plugin/Feature layering invariants.
+
+MCP is a protocol-backed integration layer on top of `pod::feature`. `pod::feature` supplies contribution/lifecycle/runtime-discovered registration substrate; MCP owns its own enablement, local server trust model, command/env/secret policy, and MCP-specific permission decisions. MCP is not the Plugin model, and Plugin permission policy is not implemented by feature-layer authority grants.
+
+## Motivation / background
+
+Yoi needs to integrate with external capability providers without turning them into hidden context sources or bypassing ordinary Tool/Worker safety rules. MCP is useful because it can expose tools, resources, and prompts from local protocol servers, but those server-provided declarations and results are untrusted and must be normalized through Yoi's existing authority boundaries.
+
+The first MCP slice should focus on local stdio servers because they are concrete enough to implement and debug while keeping remote auth, OAuth, Streamable HTTP, registry distribution, sampling, and elicitation out of the initial trust boundary.
+
+A configured local MCP server runs as a local executable. Yoi feature authority does not sandbox that executable's OS-level side effects, so command/env/secret handling and explicit local trust policy are MCP-layer responsibilities rather than generic `pod::feature` grants.
+
+## Strategy / design direction
+
+- Baseline the initial implementation on MCP specification `2025-11-25`.
+- Start with local stdio MCP servers only.
+- Treat MCP server metadata, tools, resources, prompts, and results as untrusted content.
+- Do not allow MCP resources/prompts to become hidden context injection.
+  - They must be explicit tool operations with history records.
+- Use the normal Yoi ToolRegistry, PreToolCall permission, history, and bounded result paths.
+- Do not add private MCP-only bypasses around Worker/tool invariants.
+- Keep sampling and elicitation fail-closed initially.
+- Keep Streamable HTTP, remote auth, OAuth, and MCP Registry/distribution out of the first slice.
+- Treat local stdio server execution as an explicit MCP config/trust decision, not as a `pod::feature` authority grant.
+- Document clearly that a configured local MCP server runs as a local executable; Yoi feature authority does not sandbox its OS-level side effects.
+
+### Layering decisions
+
+- `pod::feature` is an API/contribution substrate.
+  - It owns contribution declarations, provider/service lifecycle hooks, diagnostics, runtime-discovered registration plumbing, and integration with normal Worker/ToolRegistry paths.
+  - It does not own Plugin permission policy or MCP server trust policy.
+- Plugin is a user-facing package/config/runtime layer over `pod::feature`.
+  - Plugin permissions are Plugin-layer policy.
+  - Plugin package discovery/enablement must not be conflated with MCP local server execution.
+- MCP is a separate feature-backed integration layer.
+  - MCP enablement, command/env/secret handling, server trust, and MCP-specific permission decisions live in MCP config/implementation.
+  - MCP provider-discovered tools/resources/prompts are exposed through the feature API and ordinary Yoi tool paths.
+
+### Concrete implementation tickets
+
+Completed prerequisites:
+
+- `00001KTR81P9X` — Extend `pod::feature` API for external protocol-backed capability providers.
+- `00001KV0SP0TY` — Remove feature-layer HostAuthority model.
+
+Concrete MCP implementation sequence:
+
+1. `00001KVHR3WRF` — MCP local stdio server config and trust policy.
+   - explicit config, command/env/secret redaction, local executable trust boundary, no auto-start.
+2. `00001KVHR3WRY` — MCP stdio JSON-RPC lifecycle client.
+   - subprocess lifecycle, initialize/capability negotiation, diagnostics, shutdown.
+3. `00001KVHR3WS6` — MCP tools/list registration into ToolRegistry.
+   - provider-discovered tools, stable namespacing, schema validation, untrusted metadata normalization, no tools/call yet.
+4. `00001KVHR3WSD` — MCP tools/call execution through ordinary Tool path.
+   - PreToolCall gate before server call, bounded result serialization, history path.
+5. `00001KVHR3WSN` — MCP resources/prompts as explicit tool operations.
+   - resources/list/read and prompts/list/get without hidden context injection.
+6. `00001KVHR3WSW` — MCP list_changed notification handling.
+   - deterministic safe refresh/diagnostic behavior without breaking tool schema or prompt-cache invariants.
+
+The old broad implementation Ticket `00001KTR82RB7` is superseded by this sequence and should not be used as an implementation work item.
+
+### Terminology
+
+Use `runtime-discovered` or `provider-discovered` for MCP tools/resources/prompts discovered from `tools/list`, `resources/list`, or `prompts/list`. Avoid `dynamic tools` / `dynamic registry` in new MCP design prose because those phrases imply that model-visible tool schemas may change during an active LLM run.
+
+The intended invariant is:
+
+```text
+provider-discovered at startup / provider initialization;
+registered into the ordinary ToolRegistry before model exposure;
+run-stable for the duration of a model request/run;
+refreshed only at a safe boundary or reported as a diagnostic.
+```
+
+### Later follow-ups
+
+- Richer MCP task/task-support integration if ordinary tool-call fallback is insufficient.
+- Streamable HTTP transport.
+- OAuth / remote auth.
+- Registry/package distribution.
+- Explicit MCP/Plugin bridge only if separately approved; do not conflate Plugin packages with MCP local server execution.
+
+## Success criteria / exit conditions
+
+- A local mock MCP server can be configured explicitly and initialized.
+- Discovered MCP tools appear as ordinary Yoi tools with stable namespacing.
+- Tool calls go through ordinary permission and history paths.
+- MCP resources/prompts are explicit operations, not hidden context injections.
+- MCP result forms are bounded and safely serialized.
+- Secret values, command/env details, and server diagnostics are redacted where required.
+- Local server trust boundary is documented: Yoi does not sandbox the configured executable through feature authority.
+- Feature, Plugin, and MCP permission/trust responsibilities are documented as separate layers.
+
+## Decision context
+
+- MCP is not the Plugin model; it is a protocol-backed integration layer using `pod::feature` substrate.
+- `pod::feature` should provide contribution/lifecycle/runtime-discovered registration plumbing, not MCP server trust policy or Plugin package permission policy.
+- MCP resources and prompts must never be hidden context injection. They are explicit operations recorded through ordinary history/tool paths.
+- Provider-discovered tools are discovered at startup/provider initialization and registered before model exposure; model-visible schemas remain run-stable during a request/run.
+- Local stdio server execution is a user/config trust decision. Yoi does not sandbox the local executable merely because it is configured through MCP.

.yoi/objectives/00001KVG0HR9M/item.md

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

.yoi/objectives/00001KVJPT2PP/item.md

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

.yoi/objectives/00001KVJSMQXZ/item.md

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

.yoi/profiles.toml

@@ -0,0 +1 @@
+default = "builtin:companion"

.yoi/ticket.config.toml

@@ -0,0 +1,22 @@
+[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,15 +1,8 @@
 ---
-id: 20260527-000001-auto-maintain-workflow
-slug: auto-maintain-workflow
-title: 半自動開発運用 Workflow
-status: open
-kind: task
-priority: P2
-labels: [migrated]
-created_at: 2026-05-27T00:00:01Z
-updated_at: 2026-05-27T00:00:01Z
-assignee: null
-legacy_ticket: tickets/auto-maintain-workflow.md
+title: "半自動開発運用 Workflow"
+state: "closed"
+created_at: "2026-05-27T00:00:01Z"
+updated_at: "2026-06-05T15:56:29Z"
 ---
 
 ## Migration reference

.yoi/tickets/00001KSKBP8Z8/resolution.md

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

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

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

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

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

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

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

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

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

.yoi/tickets/00001KSKBP9YG/item.md

@@ -1,15 +1,10 @@
 ---
-id: 20260527-000002-e2e-harness
-slug: e2e-harness
-title: E2E テストハーネス
-status: open
-kind: task
-priority: P2
-labels: [migrated]
-created_at: 2026-05-27T00:00:02Z
-updated_at: 2026-05-27T00:00:02Z
-assignee: null
-legacy_ticket: tickets/e2e-harness.md
+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

.yoi/tickets/00001KSKBP9YG/resolution.md

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

.yoi/tickets/00001KSKBP9YG/thread.md

@@ -0,0 +1,550 @@
+<!-- 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,15 +1,8 @@
 ---
-id: 20260527-000003-internal-worker-workflow
-slug: internal-worker-workflow
-title: 内部 Worker / 内部 Pod の Workflow 化
-status: open
-kind: task
-priority: P2
-labels: [migrated]
-created_at: 2026-05-27T00:00:03Z
-updated_at: 2026-05-27T00:00:03Z
-assignee: null
-legacy_ticket: tickets/internal-worker-workflow.md
+title: "内部 Worker / 内部 Pod の Workflow 化"
+state: 'closed'
+created_at: "2026-05-27T00:00:03Z"
+updated_at: '2026-06-13T09:56:34Z'
 ---
 
 ## Migration reference

.yoi/tickets/00001KSKBPAXR/resolution.md

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

.yoi/tickets/00001KSKBPAXR/thread.md

@@ -0,0 +1,85 @@
+<!-- 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,15 +1,8 @@
 ---
-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
+title: "Pod/TUI: 手動 rewind 導線"
+state: "closed"
+created_at: "2026-05-27T00:00:04Z"
+updated_at: "2026-05-29T03:09:22Z"
 ---
 
 ## Background

.yoi/tickets/00001KSKBPCW8/item.md

@@ -1,15 +1,8 @@
 ---
-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
+title: "プロンプト: memory / knowledge tool 利用タイミングのガイダンス"
+state: "closed"
+created_at: "2026-05-27T00:00:05Z"
+updated_at: "2026-05-28T23:59:06Z"
 ---
 
 ## Migration reference

.yoi/tickets/00001KSKBPDVG/item.md

@@ -1,15 +1,8 @@
 ---
-id: 20260527-000006-permission-default-policy
-slug: permission-default-policy
-title: Permission: allow-all 既定 policy への整理
-status: open
-kind: task
-priority: P2
-labels: [migrated]
-created_at: 2026-05-27T00:00:06Z
-updated_at: 2026-05-27T00:00:06Z
-assignee: null
-legacy_ticket: tickets/permission-default-policy.md
+title: "Permission: allow-all 既定 policy への整理"
+state: "planning"
+created_at: "2026-05-27T00:00:06Z"
+updated_at: "2026-05-27T00:00:06Z"
 ---
 
 ## Migration reference

.yoi/tickets/00001KSKBPETR/item.md

@@ -1,15 +1,8 @@
 ---
-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
+title: "Inbound PodEvent ハンドリングの重複を統合する"
+state: "closed"
+created_at: "2026-05-27T00:00:07Z"
+updated_at: "2026-05-30T05:37:00Z"
 ---
 
 ## Migration reference

.yoi/tickets/00001KSKBPFT0/item.md

@@ -1,15 +1,8 @@
 ---
-id: 20260527-000008-pod-scope-persistence-authority
-slug: pod-scope-persistence-authority
-title: Pod: scope 永続化 authority の整理
-status: closed
-kind: task
-priority: P2
-labels: [migrated]
-created_at: 2026-05-27T00:00:08Z
-updated_at: 2026-05-30T05:57:16Z
-assignee: null
-legacy_ticket: tickets/pod-scope-persistence-authority.md
+title: "Pod: scope 永続化 authority の整理"
+state: "closed"
+created_at: "2026-05-27T00:00:08Z"
+updated_at: "2026-05-30T05:57:16Z"
 ---
 
 ## Migration reference

.yoi/tickets/00001KSKBPGS8/item.md

@@ -1,15 +1,8 @@
 ---
-id: 20260527-000009-pod-session-fork
-slug: pod-session-fork
-title: Pod: 任意ターンからの Fork（複数ターン巻き戻し）
-status: open
-kind: task
-priority: P2
-labels: [migrated]
-created_at: 2026-05-27T00:00:09Z
-updated_at: 2026-05-27T00:00:09Z
-assignee: null
-legacy_ticket: tickets/pod-session-fork.md
+title: "Pod: 任意ターンからの Fork（複数ターン巻き戻し）"
+state: 'closed'
+created_at: "2026-05-27T00:00:09Z"
+updated_at: '2026-06-20T16:31:29Z'
 ---
 
 ## Migration reference

.yoi/tickets/00001KSKBPGS8/resolution.md

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

.yoi/tickets/00001KSKBPGS8/thread.md

@@ -0,0 +1,25 @@
+<!-- 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,15 +1,8 @@
 ---
-id: 20260527-000010-prompt-eval-metrics
-slug: prompt-eval-metrics
-title: Prompt / Workflow 評価メトリクスと改善 Offer
-status: open
-kind: task
-priority: P2
-labels: [migrated]
-created_at: 2026-05-27T00:00:10Z
-updated_at: 2026-05-27T00:00:10Z
-assignee: null
-legacy_ticket: tickets/prompt-eval-metrics.md
+title: "Prompt / Workflow 評価メトリクスと改善 Offer"
+state: 'closed'
+created_at: "2026-05-27T00:00:10Z"
+updated_at: '2026-06-20T16:31:29Z'
 ---
 
 ## Migration reference
@@ -155,7 +148,7 @@ Claude Code 版の `tool_uses` を、insomnia では tool 種別ごとの偏り
 - 評価 event schema が docs または ticket 内で定義されている
 - eval event を memory consolidation / usage metrics / Workflow improvement offer / `model_invokation` 判断へ接続する方針が文書化されている
 - 既存の Workflow 自動生成禁止・history に commit されない context input 禁止・memory consolidation 方針に反していない
-- `/auto-maintain` または `/worktree-workflow` のどちらか 1 件を対象に、構造審査または小規模 evaluator Pod 試走を行い、結果を記録している
+- `ticket-intake-workflow` / `ticket-orchestrator-routing` / `worktree-workflow` のいずれか 1 件を対象に、構造審査または小規模 evaluator Pod 試走を行い、結果を記録している
 
 ## 参照
 
@@ -163,4 +156,4 @@ Claude Code 版の `tool_uses` を、insomnia では tool 種別ごとの偏り
 - `docs/plan/workflow.md`
 - `docs/plan/memory.md`
 - `tickets/memory-usage-metrics.md`
-- `tickets/auto-maintain-workflow.md`
+- `ticket-intake-workflow.md` / `ticket-orchestrator-routing.md`

.yoi/tickets/00001KSKBPHRG/resolution.md

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

.yoi/tickets/00001KSKBPHRG/thread.md

@@ -0,0 +1,25 @@
+<!-- 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,15 +1,8 @@
 ---
-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
+title: "セッション内 Task ツールの注意機構"
+state: "closed"
+created_at: "2026-05-27T00:00:11Z"
+updated_at: "2026-05-29T04:31:10Z"
 ---
 
 ## Migration reference

.yoi/tickets/00001KSKBPKQ0/item.md

@@ -1,15 +1,8 @@
 ---
-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
+title: "SpawnPod: initial Run delivery confirmation"
+state: "closed"
+created_at: "2026-05-27T00:00:12Z"
+updated_at: "2026-05-28T13:24:48Z"
 ---
 
 ## Migration reference

.yoi/tickets/00001KSKBPMP8/item.md

@@ -1,15 +1,8 @@
 ---
-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
+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
@@ -74,7 +67,6 @@ 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

.yoi/tickets/00001KSKBPNNG/item.md

@@ -1,15 +1,8 @@
 ---
-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:35Z
-assignee: null
-legacy_ticket: tickets/tui-actionbar-transient-notice-api.md
+title: "TUI: actionbar transient notice API"
+state: "closed"
+created_at: "2026-05-27T00:00:14Z"
+updated_at: "2026-05-29T03:57:35Z"
 ---
 
 ## Migration reference

.yoi/tickets/00001KSKBPPMR/item.md

@@ -1,15 +1,8 @@
 ---
-id: 20260527-000015-tui-navigation-mode-design
-slug: tui-navigation-mode-design
-title: TUI: navigation mode / block focus の設計
-status: open
-kind: task
-priority: P2
-labels: [migrated]
-created_at: 2026-05-27T00:00:15Z
-updated_at: 2026-05-27T00:00:15Z
-assignee: null
-legacy_ticket: tickets/tui-navigation-mode-design.md
+title: "TUI: navigation mode / block focus の設計"
+state: 'closed'
+created_at: "2026-05-27T00:00:15Z"
+updated_at: '2026-06-20T16:31:29Z'
 ---
 
 ## Migration reference

.yoi/tickets/00001KSKBPPMR/resolution.md

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

.yoi/tickets/00001KSKBPPMR/thread.md

@@ -0,0 +1,25 @@
+<!-- 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,15 +1,8 @@
 ---
-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
+title: "TUI picker: live pending Pod の表示優先と状態補完"
+state: "closed"
+created_at: "2026-05-27T00:00:16Z"
+updated_at: "2026-05-30T05:00:56Z"
 ---
 
 ## Migration reference

.yoi/tickets/00001KSKBPRK8/item.md

@@ -1,15 +1,8 @@
 ---
-id: 20260527-000017-tui-spawned-pod-panel
-slug: tui-spawned-pod-panel
-title: TUI: spawned child Pod の一覧と一時 attach
-status: open
-kind: task
-priority: P2
-labels: [migrated]
-created_at: 2026-05-27T00:00:17Z
-updated_at: 2026-05-28T14:16:02Z
-assignee: null
-legacy_ticket: tickets/tui-spawned-pod-panel.md
+title: "TUI: spawned child Pod の一覧と一時 attach"
+state: "closed"
+created_at: "2026-05-27T00:00:17Z"
+updated_at: "2026-06-07T03:14:39Z"
 ---
 
 ## Migration reference

.yoi/tickets/00001KSKBPRK8/resolution.md

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

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

@@ -0,0 +1 @@
+{"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,15 +1,10 @@
 ---
-id: 20260527-000018-tui-user-model-setup
-slug: tui-user-model-setup
-title: TUI: ユーザーマニフェストのモデル設定 wizard
-status: open
-kind: task
-priority: P2
-labels: [migrated]
-created_at: 2026-05-27T00:00:18Z
-updated_at: 2026-05-27T00:00:18Z
-assignee: null
-legacy_ticket: tickets/tui-user-model-setup.md
+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

.yoi/tickets/00001KSKBPSJG/resolution.md

@@ -0,0 +1,27 @@
+完了しました。
+
+実施内容:
+- `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

@@ -0,0 +1,307 @@
+<!-- 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,15 +1,8 @@
 ---
-id: 20260527-000019-workspace-memory-lint-cli
-slug: workspace-memory-lint-cli
-title: ワークスペースのメモリーをLintするヘッドレスCLI
-status: closed
-kind: task
-priority: P2
-labels: [migrated, memory, cli]
-created_at: 2026-05-27T00:00:19Z
-updated_at: 2026-05-31T02:15:17Z
-assignee: null
-legacy_ticket: null
+title: "ワークスペースのメモリーをLintするヘッドレスCLI"
+state: "closed"
+created_at: "2026-05-27T00:00:19Z"
+updated_at: "2026-05-31T02:15:17Z"
 ---
 
 ## Background

.yoi/tickets/00001KSKBPVH0/item.md

@@ -1,15 +1,8 @@
 ---
-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
+title: "Generalize system-reminder history append lane"
+state: "closed"
+created_at: "2026-05-27T00:00:20Z"
+updated_at: "2026-05-29T05:05:43Z"
 ---
 
 ## Background