ticket: close builtin workflow resources

.yoi/objectives/00001KTNKDX3G/item.md

@@ -3,7 +3,7 @@ title: "E2E テスト戦略"
 state: "active"
 created_at: "2026-06-09T07:09:26Z"
 updated_at: "2026-06-09T07:09:26Z"
-linked_tickets: ["20260527-000002-001"]
+linked_tickets: ["00001KSKBP9YG"]
 ---
 
 ## Goal
@@ -52,7 +52,7 @@ E2E は常時実行の軽いテストではなく、dogfooding 中に「この
 
 ## Decision context
 
-- linked Ticket `20260527-000002-001` は、E2E harness の最初の concrete implementation Ticket として扱う。
+- 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 から段階的に広げる。

.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,63 @@
+---
+title: "MCP integration as external capability provider"
+state: "active"
+created_at: "2026-06-10T07:47:48Z"
+updated_at: "2026-06-10T07:47:48Z"
+linked_tickets: ["00001KST8H4M0", "00001KTR81P9X", "00001KTR82RB7"]
+---
+
+## Goal
+
+Yoi が MCP (Model Context Protocol) server を external capability provider として安全に扱えるようにする。
+
+到達点は、MCP server が提供する tools / resources / prompts を、Yoi の既存の Pod / Feature / ToolRegistry / permission / scope / history / bounded result 境界に乗せて利用できる状態にすること。MCP は Yoi の plugin model そのものではなく、protocol-bound bridge / external provider runtime として扱う。
+
+## Motivation / background
+
+MCP は AI application と外部 system を接続する標準 protocol になりつつあり、server は tools、resources、prompts などを提供する。Yoi にとって MCP support は有用だが、外部 server が返す schema、description、annotation、resource content、prompt template はすべて untrusted data であり、Yoi の instruction hierarchy、scope、permission、history persistence、prompt-context 加工原則を弱めてはいけない。
+
+現行の `pod::feature` API は static descriptor / static tool contribution を中心にしており、MCP のように startup 時の initialize / capability negotiation / discovery によって surface が決まる provider には不足がある。そのため、MCP 実装だけを先に ad-hoc に入れるのではなく、まず外部 protocol-backed provider を扱える Feature API boundary を整え、その上に MCP implementation を載せる。
+
+## Strategy / design direction
+
+- Broad MCP integration Ticket は progress-container として使わず、この Objective に中期方針を移す。
+- 実装 work item は concrete Ticket に分ける。
+  - `00001KTR81P9X`: `pod::feature` / Worker / ToolRegistry API を external protocol-backed provider に耐える形へ拡張する。
+  - `00001KTR82RB7`: MCP `2025-11-25` local stdio server-feature bridge を実装する。
+- MCP 実装は local stdio transport から始める。
+  - Streamable HTTP、remote auth/OAuth、MCP Registry distribution、workspace-provided package auto-start は後続判断とする。
+- tools / resources / prompts は無理に分けず、MCP server features として扱う。
+  - ただし resources/prompts は direct context injection ではなく、明示 tool operation の結果として history に残す。
+  - `resources/read` / `prompts/get` の結果を history に残らない形で context に注入しない。
+- MCP server は untrusted external capability provider として扱う。
+  - server-provided schema/description/annotation/content/error は instruction ではなく data。
+  - ToolRegistry / PreToolCall permission / history / bounded result path を迂回しない。
+- local process execution は explicit authority として扱う。
+  - filesystem/network authority から暗黙に subprocess 起動権限を派生させない。
+  - secrets は explicit secret/env references で扱い、diagnostics / logs / model context / project records に plaintext として残さない。
+- dynamic discovery / list_changed は prompt/tool schema consistency を壊さない範囲で扱う。
+  - live refresh が危険なら next-turn refresh または restart/reinitialize-required diagnostic を選ぶ。
+  - silent stale state は避ける。
+- Sampling / elicitation は external server が Yoi 側の LLM/user interaction を要求する強い authority なので、初期段階では fail-closed とし、必要なら別 Ticket で approval/resume/UI path を設計する。
+
+## Success criteria / exit conditions
+
+- `pod::feature` が external protocol-backed capability provider を表現できる。
+- local subprocess execution authority が明示的に型・config・grant として扱われる。
+- Feature-provided long-running service / connection manager を Pod lifetime に安全に接続できる。
+- discovery 後の dynamic tool contribution が通常 ToolRegistry と permission path に統合される。
+- MCP spec baseline `2025-11-25` に基づく local stdio server integration がある。
+- MCP tools が namespaced stable Yoi tool として使える。
+- MCP resources/prompts が明示 tool operation として使え、取得結果は通常 tool result として history に残る。
+- server-provided data が system/developer instruction、scope、permission、prompt-context、history persistence rules を弱めない。
+- secrets / env values / command args containing secrets が diagnostics、logs、model context に plaintext で出ない。
+- Streamable HTTP、remote auth、distribution、sampling、elicitation の扱いが out-of-scope / fail-closed / follow-up として明示されている。
+- local mock MCP server による focused tests と、関連 crate tests、`nix build .#yoi` による packaging validation が定義されている。
+
+## Decision context
+
+- `00001KST8H4M0` は broad MCP integration Ticket として作られていたが、今後はこの Objective の背景 context として扱い、実装 authority は concrete Tickets に置く。
+- `00001KTR81P9X` は API/architecture prerequisite。MCP 実装が ToolRegistry / permission / history path を迂回しないための土台を作る。
+- `00001KTR82RB7` は MCP implementation Ticket。API 拡張の結果に乗って local stdio MCP server features を実装する。
+- Objective-to-Ticket links は context であり、dependency/scheduling authority ではない。実際の routing / readiness / blockers は各 Ticket の body/thread/artifacts と Orchestrator 判断に置く。
+- `resources/prompts` は scope 外に固定しない。安全条件は「direct hidden context injection をしない」ことであり、明示 tool result として扱うなら MCP integration の対象に含める。

.yoi/profiles.toml

@@ -1,21 +1 @@
-default = "project:companion"
+default = "builtin:companion"
-
-[profile.companion]
-description = "Companion role profile: GPT-5.5 with bundled default behavior"
-path = "profiles/companion.lua"
-
-[profile.intake]
-description = "Intake role profile: GPT-5.5 with bundled default behavior"
-path = "profiles/intake.lua"
-
-[profile.orchestrator]
-description = "Orchestrator role profile: GPT-5.5 with bundled default behavior"
-path = "profiles/orchestrator.lua"
-
-[profile.coder]
-description = "Coder role profile: GPT-5.5 with bundled default behavior"
-path = "profiles/coder.lua"
-
-[profile.reviewer]
-description = "Reviewer role profile: GPT-5.5 with bundled default behavior"
-path = "profiles/reviewer.lua"

.yoi/profiles/_base.lua

@@ -1,46 +0,0 @@
-local profile = require("yoi.profile")
-local scope = require("yoi.scope")
-local compact = require("yoi.compact")
-
-return function(opts)
-    return profile {
-        slug = opts.slug,
-        description = opts.description,
-
-        scope = opts.scope or scope.workspace_read(),
-        delegation_scope = opts.delegation_scope,
-
-        session = {
-            record_event_trace = true,
-        },
-
-        worker = {
-            reasoning = "high",
-            language = opts.language or "Japanese",
-        },
-
-        model = {
-            ref = opts.model_ref,
-        },
-
-        compaction = compact.tokens {
-            threshold = 240000,
-            request_threshold = 270000,
-            worker_context_max_tokens = 100000,
-        },
-
-        memory = {
-            extract_threshold = 50000,
-            consolidation_threshold_files = 5,
-            consolidation_threshold_bytes = 50000,
-        },
-
-        web = {
-            enabled = true,
-            search = {
-                provider = "brave",
-                api_key_secret = "web/brave/default",
-            },
-        },
-    }
-end

.yoi/profiles/coder.lua

@@ -1,10 +0,0 @@
-local base = require("_base")
-local scope = require("yoi.scope")
-
-return base {
-    slug = "coder",
-    description = "Coder role profile: GPT-5.5 with bundled default behavior",
-    model_ref = "codex-oauth/gpt-5.5",
-    language = "Japanese",
-    scope = scope.workspace_write(),
-}

.yoi/profiles/companion.lua

@@ -1,8 +0,0 @@
-local base = require("_base")
-
-return base {
-    slug = "companion",
-    description = "Companion role profile: GPT-5.5 with bundled default behavior",
-    model_ref = "codex-oauth/gpt-5.5",
-    language = "Japanese",
-}

.yoi/profiles/intake.lua

@@ -1,8 +0,0 @@
-local base = require("_base")
-
-return base {
-    slug = "intake",
-    description = "Intake role profile: GPT-5.5 with bundled default behavior",
-    model_ref = "codex-oauth/gpt-5.5",
-    language = "Japanese",
-}

.yoi/profiles/orchestrator.lua

@@ -1,10 +0,0 @@
-local base = require("_base")
-local scope = require("yoi.scope")
-
-return base {
-    slug = "orchestrator",
-    description = "Orchestrator role profile: GPT-5.5 with bundled default behavior",
-    delegation_scope = scope.workspace_write(),
-    model_ref = "codex-oauth/gpt-5.5",
-    language = "Japanese",
-}

.yoi/profiles/reviewer.lua

@@ -1,8 +0,0 @@
-local base = require("_base")
-
-return base {
-    slug = "reviewer",
-    description = "Reviewer role profile: GPT-5.5 with bundled default behavior",
-    model_ref = "codex-oauth/gpt-5.5",
-    language = "Japanese",
-}

.yoi/ticket.config.toml

@@ -6,17 +6,17 @@ root = ".yoi/tickets"
 language = "Japanese"
 
 [roles.intake]
-profile = "project:intake"
+profile = "builtin:intake"
 workflow = "ticket-intake-workflow"
 
 [roles.orchestrator]
-profile = "project:orchestrator"
+profile = "builtin:orchestrator"
 workflow = "ticket-orchestrator-routing"
 
 [roles.coder]
-profile = "project:coder"
+profile = "builtin:coder"
 workflow = "multi-agent-workflow"
 
 [roles.reviewer]
-profile = "project:reviewer"
+profile = "builtin:reviewer"
 workflow = "multi-agent-workflow"

.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,8 +1,10 @@
 ---
 title: "TUI: ユーザーマニフェストのモデル設定 wizard"
-state: "ready"
+state: 'closed'
 created_at: "2026-05-27T00:00:18Z"
-updated_at: "2026-06-08T07:29:10Z"
+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 要件は満たしています。
+
+---