ticket: refine plugin feature layering

.yoi/objectives/00001KTR80WMN/item.md

@@ -1,63 +1,72 @@
 ---
-title: "MCP integration as external capability provider"
-state: "active"
-created_at: "2026-06-10T07:47:48Z"
-updated_at: "2026-06-10T07:47:48Z"
-linked_tickets: ["00001KST8H4M0", "00001KTR81P9X", "00001KTR82RB7"]
+title: 'MCP local stdio integration architecture'
+state: 'active'
+created_at: '2026-06-10T07:48:45Z'
+updated_at: '2026-06-13T15:30:22Z'
 ---
 
-## Goal
+## Objective
 
-Yoi が MCP (Model Context Protocol) server を external capability provider として安全に扱えるようにする。
+Add MCP local stdio integration to Yoi without weakening Worker history, prompt-context, scoped tool permission, or Plugin/Feature layering invariants.
 
-到達点は、MCP server が提供する tools / resources / prompts を、Yoi の既存の Pod / Feature / ToolRegistry / permission / scope / history / bounded result 境界に乗せて利用できる状態にすること。MCP は Yoi の plugin model そのものではなく、protocol-bound bridge / external provider runtime として扱う。
+MCP should be implemented as a protocol-backed integration layer on top of `pod::feature`. `pod::feature` supplies the contribution/lifecycle API substrate; MCP owns its own enablement, local server trust model, command/env/secret policy, and MCP-specific permissions. MCP is not the Plugin model, and Plugin permission policy is not implemented by feature-layer authority grants.
 
-## Motivation / background
+## Strategic direction
 
-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 加工原則を弱めてはいけない。
+- Baseline the 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 be hidden context injection.
+  - They must be explicit tool operations with history records.
+- Use the normal Yoi tool registry, 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.
 
-現行の `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 を載せる。
+## Layering decisions
 
-## Strategy / design direction
+- `pod::feature` is an API/contribution substrate.
+  - It owns contribution declarations, provider/service lifecycle hooks, diagnostics, dynamic 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 dynamic tools/resources/prompts are exposed through the feature API and ordinary Yoi tool paths.
 
-- 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 を設計する。
+## Work breakdown
 
-## Success criteria / exit conditions
+1. `00001KTR81P9X` — Extend `pod::feature` API for protocol-backed external providers.
+   - provider/service lifecycle
+   - startup discovery and dynamic contribution registration
+   - bounded refresh semantics
+   - metadata/result normalization
+   - no feature-layer authority model for MCP/Plugin permissions
+2. `00001KTR82RB7` — Implement MCP `2025-11-25` local stdio server bridge.
+   - explicit MCP config and trust model
+   - initialize/capability negotiation
+   - tools/resources/prompts list/call/read/get
+   - bounded result serialization
+   - list-changed diagnostics/refresh behavior
+3. `00001KV0SP0TY` — Remove feature-layer HostAuthority model.
+   - remove authority/grant terminology from `pod::feature`
+   - keep real permission/trust policy in owning Plugin/MCP/manifest/tool layers
+4. Later follow-ups, if needed.
+   - richer MCP tasks / task-support integration
+   - remote/HTTP transports
+   - OAuth / registry / package distribution
+   - Plugin package/runtime alignment, if an explicit MCP/plugin bridge is later approved
 
-- `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 が定義されている。
+## Success criteria
 
-## 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 の対象に含める。
+- 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.

.yoi/tickets/00001KSXRQ4G8/item.md

@@ -1,82 +1,88 @@
 ---
-title: "Plugin: define extension surface for hooks and tools"
-state: "planning"
-created_at: "2026-05-31T01:00:05Z"
-updated_at: "2026-06-03T12:25:05Z"
+title: 'Plugin: define extension surface for hooks and tools'
+state: 'planning'
+created_at: '2026-05-31T01:00:05Z'
+updated_at: '2026-06-13T15:29:21Z'
+assignee: null
 ---
 
+## Goal
+
+Design Yoi's Plugin surface as the user-facing package/config/runtime layer built on top of `pod::feature`.
+
+`pod::feature` is the internal API substrate for contribution registration: Tools, Hooks, BackgroundTasks, Services, diagnostics, and lifecycle integration. Plugin is the layer that makes that substrate usable by users and workspaces through package metadata, enablement config, runtime choices, provenance, and Plugin-layer permissions.
+
+MCP is not the Plugin model and should not be treated as a Plugin permission backend. MCP is a separate protocol-backed integration layer that also uses the feature API and owns its own MCP-specific enablement/trust policy.
+
 ## Background
 
-insomnia currently has internal Hook / Tool concepts, plus a separate planned MCP integration ticket (`mcp-integration`). The next design step is to define the project-level Plugin surface: how user/project-provided extensions can contribute Tools and Hooks without weakening scope, permission, history, or prompt-context invariants.
+Yoi already has internal extension-like surfaces:
 
-The plugin surface should not be a grab bag of arbitrary code execution. Candidate extension mechanisms have different trust and protocol properties:
+- Tools via `llm_worker::ToolRegistry` / `ToolDefinition`
+- Hooks via `HookRegistry` / `HookEvent` / `HookAction`
+- Feature contribution declarations in `pod::feature`
+- Built-in features such as task and ticket tools
 
-- MCP: protocol-bound external tool/resource/prompt provider surface.
-- TOML/config-only hooks: declarative configuration for simple hook behavior without arbitrary code.
-- WASM: planned first programmable plugin runtime for Hooks and Tools, with explicit capability imports and sandboxing.
-- General scripting languages: considered, but not the initial direction because arbitrary script execution broadens the trust/runtime surface too quickly.
+The Plugin surface should expose extension points without letting external packages bypass Worker history, prompt/context invariants, scoped tool permissions, or role/profile configuration.
 
-## Related work
-
-- `work-items/open/20260529-161928-mcp-integration/` — MCP integration as one plugin backend / external capability bridge.
-- `work-items/open/20260603-122317-plugin-feature-contribution-registry/` — implementation-oriented runtime registry split-out for built-in and external feature contributions.
-- `work-items/open/20260603-122317-hook-public-surface-hardening/` — prerequisite hardening for public Hook contribution safety.
-- Existing internal hooks/tools code: `crates/pod`, `crates/tools`, `crates/llm-worker`.
-- Manifest permission policy and scope enforcement must remain authoritative for plugin-provided tools.
+Prior Hook hardening work constrains model-visible context mutation so Plugin exposure can stay safe. Plugin design should reuse those safe surfaces rather than creating a parallel tool/hook runtime.
 
 ## Requirements
 
-- Define a Plugin surface that can provide:
-  - Tools callable by the LLM through the normal ToolRegistry / permission / scope path;
-  - Hooks observing or influencing Pod/Worker lifecycle through the existing Hook boundary, not by directly mutating worker history/context.
-- Separate plugin description/registration from plugin runtime implementation.
-  - A plugin manifest should declare provided tools/hooks, required capabilities, configuration schema or config values, and trust/runtime type.
-  - Runtime implementations can include MCP, declarative config hooks, and WASM in separate phases.
-- Keep MCP as a related backend, not the whole plugin model.
-  - MCP servers remain untrusted external capability providers bridged through allowlists, bounded output, scope/permission policy, and explicit resource/prompt use.
-- Define a declarative hook path for simple TOML/config-only behavior where code execution is unnecessary.
-- Define a WASM plugin direction for programmable Hooks/Tools.
-  - WASM modules must receive explicit host imports/capabilities only.
-  - File/network/process access must not be ambient; all external effects go through host-provided capability APIs and existing policy checks.
-  - Tool outputs must be bounded and recorded through normal history/tool-result paths.
-- Preserve LLM context/history invariants.
-  - Plugins must not inject cross-turn invisible context.
-  - If plugin output becomes model-visible, it must enter through durable history/tool/hook paths according to existing rules.
-- Preserve scope and permission invariants.
-  - Plugin-provided tools must not bypass `ScopedFs`, manifest tool permission policy, child scope delegation, or web/network policy.
-- Clarify trust model and lifecycle.
-  - Builtin vs project vs user plugins.
-  - Discovery/enablement through manifest/profile/config.
-  - Versioning / compatibility boundaries.
-  - Diagnostics when a plugin cannot load or asks for unavailable capabilities.
-
-## Non-goals
-
-- Implementing the full WASM runtime in the first design step.
-- Implementing MCP itself beyond referencing the existing MCP integration ticket.
-- Supporting arbitrary host scripting languages as a first-class plugin runtime.
-- Allowing plugins to mutate session history, memory, prompt context, or scope outside approved APIs.
-- Adding UI plugin systems or TUI rendering extensions.
-
-## Suggested phases
-
-1. **Design / architecture note**
-   - Define Plugin, PluginManifest, PluginRuntimeKind, Tool contribution, Hook contribution, capability request, and trust/source model.
-   - Map MCP, declarative hooks, and WASM onto that model.
-2. **Internal registry boundary**
-   - Detailed implementation is split to `plugin-feature-contribution-registry` so this ticket can stay focused on the architecture surface and invariants.
-3. **Declarative hooks MVP**
-   - Add a non-code configuration path for simple hook behavior if an immediate use case exists.
-4. **WASM spike**
-   - Evaluate runtime (`wasmtime` or alternative), host imports, resource limits, serialization, and Nix/package impact.
-5. **MCP bridge alignment**
-   - Ensure `mcp-integration` plugs into the same Tool/permission/output boundary rather than becoming a parallel extension path.
+- Define Plugin as a user-facing layer over `pod::feature`, not as the feature API itself.
+  - Plugin package/config/runtime code eventually contributes through `pod::feature`.
+  - `pod::feature` remains responsible for contribution declarations, lifecycle, diagnostics, and registration plumbing.
+  - Plugin remains responsible for package enablement, provenance, runtime selection, and Plugin-layer permission/trust policy.
+- Define supported contribution categories.
+  - Tools
+  - Hooks
+  - Background tasks / services, if included in the initial model
+  - Future extensions must remain explicit contribution categories, not arbitrary host access.
+- Define Plugin-layer permission and trust model separately from `pod::feature`.
+  - Do not rely on feature-level `HostAuthority` / authority grants for Plugin permissions.
+  - Plugin grants should be tied to package identity/runtime/user or workspace config, not to feature install reports.
+  - Plugin policy must decide which contribution categories and host APIs a Plugin runtime can use.
+- Define runtime families separately.
+  - Declarative/config-only Plugins
+  - WASM or another sandboxed runtime, if/when selected
+  - External process/plugin bridge, if/when selected
+  - MCP remains a separate feature-backed protocol integration, not the Plugin permission model.
+- Hook Plugins must use the hardened public Hook surface.
+  - no raw hidden `Item` injection
+  - no prompt/context mutation outside durable history-aware paths
+  - explicit supported `HookAction` subset only
+- Tool Plugins must register ordinary Yoi tools.
+  - normal tool schema exposure
+  - normal PreToolCall permission path
+  - normal tool-result history path
+  - bounded result serialization
+- Plugin metadata and package content are untrusted input.
+- Plugin enablement must be explicit.
+  - package presence/discovery alone cannot enable or execute Plugin code
+  - workspace/user config must opt in to package/runtime/contribution activation
+- The design must document the boundary among Plugin, MCP, and built-in Features.
 
 ## Acceptance criteria
 
-- The repository has a documented plugin architecture proposal covering Tools, Hooks, runtimes, capability model, trust model, and discovery/enablement.
-- MCP is positioned as one plugin backend / bridge and linked to `mcp-integration`, not treated as the only extension mechanism.
-- The proposal explicitly explains why arbitrary scripting languages are deferred and why WASM is the initial programmable runtime direction.
-- The design preserves existing scope, permission, history, and prompt-context invariants.
-- Follow-up implementation tickets can be cut independently for declarative hooks, WASM runtime, and MCP bridge integration.
-- Any code changes in this ticket, if taken beyond design docs, are limited to safe internal boundaries and have focused tests.
+- A design note or Ticket plan defines Plugin as a user-facing layer over `pod::feature`.
+- The plan states that Plugin permissions are Plugin-layer policy and are not implemented by `pod::feature` `HostAuthority` grants.
+- The plan states that MCP is a separate feature-backed integration with MCP-specific enablement/trust policy.
+- Contribution categories and runtime families are named with explicit in/out of scope decisions for the first implementation slice.
+- The public Hook safety invariants from `00001KT6Q08R8` remain intact.
+- Tool Plugins are required to use ordinary ToolRegistry / permission / history / bounded-result paths.
+- No design path allows Plugin package presence alone to execute code or mutate context.
+- The design identifies which follow-up Tickets own package format, runtime implementation, and Plugin permission details.
+
+## Suggested decomposition
+
+1. Public Hook surface hardening. Completed by `00001KT6Q08R8`.
+2. Feature contribution API substrate. Completed initial slice by `00001KT6Q08R9`; dynamic provider work continues in `00001KTR81P9X`.
+3. Plugin package/discovery format. Tracked by `00001KT0Z4BK8`.
+4. Plugin permission/runtime policy Ticket. Create or refine after runtime family is selected; do not put this policy into `pod::feature`.
+5. MCP local stdio integration. Tracked separately by `00001KTR82RB7`; it uses feature API but is not Plugin permission work.
+
+## Notes
+
+- This Ticket is a design coordination Ticket; implementation should be split into concrete Tickets rather than landing a broad Plugin platform in one change.
+- Keep Plugin permission terms distinct from `HostAuthority`. If `HostAuthority` remains in code, it is not the Plugin policy surface.
+- Avoid adding support for arbitrary scripting languages until package identity, runtime sandbox/trust, and permission policy are explicit.

.yoi/tickets/00001KSXRQ4G8/thread.md

@@ -39,4 +39,22 @@ Two implementation-oriented prerequisite tickets are split out:
 This preserves the desired detachable shape: feature state remains in the feature/extension module, while Pod interaction happens through existing durable host surfaces. WorkItem management should be implemented as a built-in feature contribution once the registry boundary is in place, rather than as a special Pod context-injection path.
 
 
+---
+
+<!-- event: decision author: hare at: 2026-06-13T15:29:21Z -->
+
+## Decision
+
+決定:
+- `pod::feature` は API / contribution substrate として扱い、Plugin や MCP の権限管理を担わせない。
+- Plugin は `pod::feature` をユーザー向け package/config/runtime 形式で使わせる層であり、Plugin permission / trust policy は Plugin layer で定義する。
+- MCP は `pod::feature` 上に protocol-backed integration layer を構築するが、MCP server enablement / command-env-secret policy / trust boundary / MCP-specific permission は MCP layer が独自に持つ。
+- MCP local stdio server の OS-level side effects は Yoi feature authority では制御できないため、feature-layer authority / grant を MCP や Plugin の permission model に流用しない。
+
+反映:
+- `00001KTR81P9X` は authority ではなく provider lifecycle / dynamic contribution / normal ToolRegistry path / untrusted normalization に絞る。
+- `00001KTR82RB7` は MCP 固有の explicit config と trust model を持つ。
+- `00001KSXRQ4G8` と `00001KT0Z4BK8` は Plugin permission を Plugin layer として扱い、MCP を初期 Plugin packaging/runtime から分離する。
+
+
 ---

.yoi/tickets/00001KT0Z4BK8/item.md

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

.yoi/tickets/00001KT0Z4BK8/thread.md

@@ -19,4 +19,22 @@ Distribution direction from user discussion:
 - Workspace packages are repository-provided and must be treated conservatively, especially for executable runtimes and MCP/process-spawn behavior.
 
 
+---
+
+<!-- event: decision author: hare at: 2026-06-13T15:29:21Z -->
+
+## Decision
+
+決定:
+- `pod::feature` は API / contribution substrate として扱い、Plugin や MCP の権限管理を担わせない。
+- Plugin は `pod::feature` をユーザー向け package/config/runtime 形式で使わせる層であり、Plugin permission / trust policy は Plugin layer で定義する。
+- MCP は `pod::feature` 上に protocol-backed integration layer を構築するが、MCP server enablement / command-env-secret policy / trust boundary / MCP-specific permission は MCP layer が独自に持つ。
+- MCP local stdio server の OS-level side effects は Yoi feature authority では制御できないため、feature-layer authority / grant を MCP や Plugin の permission model に流用しない。
+
+反映:
+- `00001KTR81P9X` は authority ではなく provider lifecycle / dynamic contribution / normal ToolRegistry path / untrusted normalization に絞る。
+- `00001KTR82RB7` は MCP 固有の explicit config と trust model を持つ。
+- `00001KSXRQ4G8` と `00001KT0Z4BK8` は Plugin permission を Plugin layer として扱い、MCP を初期 Plugin packaging/runtime から分離する。
+
+
 ---

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

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

.yoi/tickets/00001KTR81P9X/item.md

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

.yoi/tickets/00001KTR81P9X/thread.md

@@ -4,4 +4,39 @@
 
 LocalTicketBackend によって作成されました。
 
+---
+
+<!-- event: decision author: hare at: 2026-06-13T15:29:21Z -->
+
+## Decision
+
+決定:
+- `pod::feature` は API / contribution substrate として扱い、Plugin や MCP の権限管理を担わせない。
+- Plugin は `pod::feature` をユーザー向け package/config/runtime 形式で使わせる層であり、Plugin permission / trust policy は Plugin layer で定義する。
+- MCP は `pod::feature` 上に protocol-backed integration layer を構築するが、MCP server enablement / command-env-secret policy / trust boundary / MCP-specific permission は MCP layer が独自に持つ。
+- MCP local stdio server の OS-level side effects は Yoi feature authority では制御できないため、feature-layer authority / grant を MCP や Plugin の permission model に流用しない。
+
+反映:
+- `00001KTR81P9X` は authority ではなく provider lifecycle / dynamic contribution / normal ToolRegistry path / untrusted normalization に絞る。
+- `00001KTR82RB7` は MCP 固有の explicit config と trust model を持つ。
+- `00001KSXRQ4G8` と `00001KT0Z4BK8` は Plugin permission を Plugin layer として扱い、MCP を初期 Plugin packaging/runtime から分離する。
+
+
+---
+
+<!-- event: intake_summary author: hare at: 2026-06-13T16:27:15Z -->
+
+## Intake summary
+
+Marked ready by `yoi ticket state`.
+
+---
+
+<!-- event: state_changed author: "yoi ticket" at: 2026-06-13T16:27:15Z from: planning to: ready reason: cli_state field: state -->
+
+## State changed
+
+Marked ready by `yoi ticket state`.
+
+
 ---

.yoi/tickets/00001KTR82RB7/item.md

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

.yoi/tickets/00001KTR82RB7/thread.md

@@ -4,4 +4,22 @@
 
 LocalTicketBackend によって作成されました。
 
+---
+
+<!-- event: decision author: hare at: 2026-06-13T15:29:21Z -->
+
+## Decision
+
+決定:
+- `pod::feature` は API / contribution substrate として扱い、Plugin や MCP の権限管理を担わせない。
+- Plugin は `pod::feature` をユーザー向け package/config/runtime 形式で使わせる層であり、Plugin permission / trust policy は Plugin layer で定義する。
+- MCP は `pod::feature` 上に protocol-backed integration layer を構築するが、MCP server enablement / command-env-secret policy / trust boundary / MCP-specific permission は MCP layer が独自に持つ。
+- MCP local stdio server の OS-level side effects は Yoi feature authority では制御できないため、feature-layer authority / grant を MCP や Plugin の permission model に流用しない。
+
+反映:
+- `00001KTR81P9X` は authority ではなく provider lifecycle / dynamic contribution / normal ToolRegistry path / untrusted normalization に絞る。
+- `00001KTR82RB7` は MCP 固有の explicit config と trust model を持つ。
+- `00001KSXRQ4G8` と `00001KT0Z4BK8` は Plugin permission を Plugin layer として扱い、MCP を初期 Plugin packaging/runtime から分離する。
+
+
 ---

.yoi/tickets/00001KV0SP0TY/item.md

@@ -0,0 +1,56 @@
+---
+title: 'Remove feature-layer HostAuthority model'
+state: 'ready'
+created_at: '2026-06-13T15:30:22Z'
+updated_at: '2026-06-13T16:27:15Z'
+assignee: null
+readiness: 'implementation_ready'
+risk_flags: ['feature-api', 'tool-registry', 'ticket-tools']
+---
+
+## Background
+
+Current `pod::feature` contains `HostAuthority`, `HostAuthorityRequest`, and `HostAuthorityGrantSet`. In practice this layer does not enforce OS-level or Plugin/MCP permissions: current install code grants requested authorities and uses them mostly as declaration/reporting and contribution registration checks.
+
+The project decision is to keep `pod::feature` as an API/contribution substrate and move real permission/trust decisions to the owning layers:
+
+- Plugin package/runtime permission policy belongs to the Plugin layer.
+- MCP local stdio enablement, command/env/secret policy, and server trust belong to the MCP layer.
+- filesystem/tool/pod permissions remain in existing manifest/profile/tool permission paths.
+- Ticket feature access remains explicit Ticket feature configuration and backend validation, not feature-layer authority grants.
+
+Therefore the feature-layer authority model should be removed, not renamed or preserved as diagnostics. Any remaining report data should use ordinary contribution/installation diagnostic terminology without `Authority`, `Grant`, or permission semantics.
+
+## Requirements
+
+- Remove `HostAuthority`, `HostAuthorityRequest`, `HostAuthorityGrantSet`, and related feature install report fields from `pod::feature`.
+- Do not introduce renamed feature-layer authority/grant types as a replacement; use ordinary diagnostics for non-permission install information.
+- Remove contribution registration checks that depend on feature-layer authority grants.
+- Keep contribution declaration/registration checks that are still useful without authority terminology.
+  - duplicate contribution names
+  - undeclared contribution categories, if currently checked
+  - feature install diagnostics
+- Update built-in features that currently request host authorities.
+  - Ticket feature should rely on validated `TicketFeatureConfig`, backend root validation, and access-level configuration.
+  - Task feature should not mention host authority.
+- Ensure no Plugin or MCP Ticket depends on feature-layer authority grants after the cleanup.
+- Update comments/docs/tests that describe feature-layer authority as future Plugin/MCP permission infrastructure.
+- Do not use this cleanup to introduce Plugin permission policy or MCP server trust policy; those remain separate layers.
+
+## Acceptance criteria
+
+- The codebase no longer exposes `HostAuthority*` or equivalent feature-layer authority/grant types as part of the `pod::feature` public API.
+- Built-in task and ticket feature tests pass without authority grants.
+- Ticket tools still require explicit Ticket feature config/access and validated backend root.
+- Feature install reports still provide useful diagnostics for skipped/failed contributions without implying security grants.
+- Grep/review confirms Plugin and MCP planning Tickets do not rely on feature authority for permission/trust control.
+- Validation: focused feature/ticket/task tests, `cargo fmt --check`, affected crate tests, `cargo check --workspace --all-targets`, and `nix build .#yoi`.
+
+## Related work
+
+- Feature API dynamic provider work: `00001KTR81P9X`
+- MCP local stdio integration: `00001KTR82RB7`
+- Plugin extension surface: `00001KSXRQ4G8`
+- Plugin package/discovery: `00001KT0Z4BK8`
+- Earlier feature registry scaffold: `00001KT6Q08R9`
+- Earlier authority naming split: `00001KTAGM2V0`

.yoi/tickets/00001KV0SP0TY/thread.md

@@ -0,0 +1,36 @@
+<!-- event: create author: "yoi ticket" at: 2026-06-13T15:30:22Z -->
+
+## 作成
+
+LocalTicketBackend によって作成されました。
+
+---
+
+<!-- event: decision author: hare at: 2026-06-13T16:08:36Z -->
+
+## Decision
+
+決定:
+- feature-layer `HostAuthority` は残さず削除する。
+- rename して診断用に温存する案も採用しない。`Authority` / `Grant` という語彙を `pod::feature` public API に残すと、Plugin/MCP permission layer と再び混同されるため。
+- feature install report に必要な情報は ordinary diagnostics / skipped contribution reason として表現する。
+
+
+---
+
+<!-- event: intake_summary author: hare at: 2026-06-13T16:27:15Z -->
+
+## Intake summary
+
+Marked ready by `yoi ticket state`.
+
+---
+
+<!-- event: state_changed author: "yoi ticket" at: 2026-06-13T16:27:15Z from: planning to: ready reason: cli_state field: state -->
+
+## State changed
+
+Marked ready by `yoi ticket state`.
+
+
+---