task: split plugin feature registry tickets

work-items/open/20260531-010005-plugin-extension-surface/artifacts/feature-registry-split-decision.md

@@ -0,0 +1,10 @@
+# Decision: split feature registry and Hook hardening from Plugin architecture
+
+The Plugin architecture ticket remains the broad architecture surface for Tools, Hooks, runtime kinds, capability model, trust model, discovery/enablement, and MCP/WASM/declarative runtime mapping.
+
+Two implementation-oriented prerequisite tickets are split out:
+
+- `plugin-feature-contribution-registry`: define and implement the Pod-layer feature contribution registry so built-in and future external capabilities register through existing Tool / Hook / Notify paths instead of ad hoc Pod code paths.
+- `hook-public-surface-hardening`: audit and harden `pod::hook` before exposing it as a feature/plugin contribution boundary, especially removing public access to raw internal action types that can inject model-visible `Item` values.
+
+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.

work-items/open/20260531-010005-plugin-extension-surface/item.md

@@ -7,7 +7,7 @@ kind: feature
 priority: P2
 labels: [plugin, hooks, tools, wasm, mcp]
 created_at: 2026-05-31T01:00:05Z
-updated_at: 2026-05-31T01:01:09Z
+updated_at: 2026-06-03T12:25:05Z
 assignee: null
 legacy_ticket: null
 ---
@@ -26,6 +26,8 @@ The plugin surface should not be a grab bag of arbitrary code execution. Candida
 ## 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.
 
@@ -69,7 +71,7 @@ The plugin surface should not be a grab bag of arbitrary code execution. Candida
    - 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**
-   - Introduce code structure that can register plugin-provided tool/hook descriptors without changing runtime behavior yet.
+   - 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**

work-items/open/20260531-010005-plugin-extension-surface/thread.md

@@ -21,4 +21,22 @@ Initial decision note from user discussion:
 - General scripting languages were considered, but the initial direction is WASM because it offers a clearer sandbox/capability boundary.
 
 
+---
+
+<!-- event: decision author: hare at: 2026-06-03T12:25:05Z -->
+
+## Decision
+
+# Decision: split feature registry and Hook hardening from Plugin architecture
+
+The Plugin architecture ticket remains the broad architecture surface for Tools, Hooks, runtime kinds, capability model, trust model, discovery/enablement, and MCP/WASM/declarative runtime mapping.
+
+Two implementation-oriented prerequisite tickets are split out:
+
+- `plugin-feature-contribution-registry`: define and implement the Pod-layer feature contribution registry so built-in and future external capabilities register through existing Tool / Hook / Notify paths instead of ad hoc Pod code paths.
+- `hook-public-surface-hardening`: audit and harden `pod::hook` before exposing it as a feature/plugin contribution boundary, especially removing public access to raw internal action types that can inject model-visible `Item` values.
+
+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.
+
+
 ---

work-items/open/20260601-031252-builtin-work-item-intake-routing/item.md

@@ -7,7 +7,7 @@ kind: task
 priority: P1
 labels: [work-item, intake, orchestration, tui]
 created_at: 2026-06-01T03:12:52Z
-updated_at: 2026-06-01T05:26:27Z
+updated_at: 2026-06-03T12:25:05Z
 assignee: null
 legacy_ticket: null
 ---
@@ -21,6 +21,7 @@ legacy_ticket: null
 ## Direction
 
 - `tickets.sh` 相当の work item 管理を、Insomnia の built-in feature / tool surface として設計・実装する。
+- WorkItem は Pod 専用の独自 context injection や特殊 queue ではなく、`plugin-feature-contribution-registry` で定義する feature contribution として既存 Tool / Hook / Notify 経路に載せる。
 - Intake Pod はユーザーと直接会話し、必要な調査・重複確認・要件同期を行い、合意済み WorkItem / ticket を作成できるようにする。
 - Orchestrator はユーザー意図の一次解釈や ticket draft の再承認者ではなく、登録済み WorkItem の scheduling / prioritization / interruption / implementation delegation を担当する。
 - ユーザー向け Inbox 専用 UI は初期スコープにしない。Intake は既存の `--multi` UI の延長として通常の Pod 会話で制御できるようにする。
@@ -42,6 +43,7 @@ Scope は、エージェントが占有して作業する filesystem space を
   - status transition
   - close / resolution
   - doctor / consistency check
+- WorkItem tool surface は `plugin-feature-contribution-registry` の built-in feature contribution として登録できること。
 - WorkItem / ticket の保存形式は、現在の markdown + frontmatter + thread / artifacts 方式との移行可能性を保つこと。
 - 既存の `tickets.sh` 運用を即座に破壊しないこと。built-in 化の途中でも git history / work-items directory を authority として読めること。
 - Intake Pod がユーザーと合意済み WorkItem を作成できる導線を設計すること。

work-items/open/20260601-031252-builtin-work-item-intake-routing/thread.md

@@ -230,4 +230,22 @@ This does not imply unlimited file access. The WorkItem tool should be limited t
 The first implementation can be LocalFilesBackend over current `work-items/`, preserving markdown/frontmatter/thread/artifacts and `tickets.sh` compatibility. The API should already be backend-shaped so GitHub Issues or other trackers can be added later without changing Intake/Orchestrator semantics.
 
 
+---
+
+<!-- event: decision author: hare at: 2026-06-03T12:25:05Z -->
+
+## Decision
+
+# Decision: split feature registry and Hook hardening from Plugin architecture
+
+The Plugin architecture ticket remains the broad architecture surface for Tools, Hooks, runtime kinds, capability model, trust model, discovery/enablement, and MCP/WASM/declarative runtime mapping.
+
+Two implementation-oriented prerequisite tickets are split out:
+
+- `plugin-feature-contribution-registry`: define and implement the Pod-layer feature contribution registry so built-in and future external capabilities register through existing Tool / Hook / Notify paths instead of ad hoc Pod code paths.
+- `hook-public-surface-hardening`: audit and harden `pod::hook` before exposing it as a feature/plugin contribution boundary, especially removing public access to raw internal action types that can inject model-visible `Item` values.
+
+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.
+
+
 ---

work-items/open/20260603-122317-hook-public-surface-hardening/item.md

@@ -0,0 +1,58 @@
+---
+id: 20260603-122317-hook-public-surface-hardening
+slug: hook-public-surface-hardening
+title: Hook: harden public hook surface before plugin exposure
+status: open
+kind: task
+priority: P1
+labels: [hooks, plugin, safety, tests]
+created_at: 2026-06-03T12:23:17Z
+updated_at: 2026-06-03T12:23:17Z
+assignee: null
+legacy_ticket: null
+---
+
+## Issue
+
+`crates/pod/src/hook.rs` is already positioned as the public orchestration extension point over the internal `llm_worker::Interceptor`, but actual production usage is still light. Current usage is mostly manifest permission policy (`PreToolCall`) and usage tracking (`PreLlmRequest`). Before external or plugin-like features rely on Hooks, the public Hook surface needs tighter safety boundaries and better Pod-layer test coverage.
+
+The main concern is that some Hook outputs still reuse internal `llm_worker::interceptor` action types. In particular, `PreRequestAction::ContinueWith(Vec<Item>)` and `TurnEndAction::ContinueWithMessages(Vec<Item>)` allow model-visible item injection from a Hook path. That conflicts with the intended public rule that Hooks must not mutate history/context except through approved durable paths.
+
+## Requirements
+
+- Audit the public Hook API against the intended plugin/feature contract.
+- Replace or wrap internal interceptor action types with safe public Hook action subsets where needed.
+  - `OnPromptSubmit` already has a safe `HookPromptAction`; use the same pattern for other public Hook events.
+  - Public Plugin/Feature Hooks should not be able to return raw `Item` vectors for hidden context/history mutation.
+- Preserve internal mechanisms that legitimately need richer interceptor actions, but keep them separate from public feature/plugin Hooks.
+- Keep manifest permission policy behavior intact.
+  - Deny/ask still fails closed with synthetic tool results as today.
+- Clarify which Hook events are observational only and which can cancel/abort/yield/deny.
+- Add Pod-layer tests for Hook behavior that is currently only lightly covered.
+
+## Suggested test coverage
+
+- `OnPromptSubmit` Hook can cancel a submitted prompt through the safe public action type.
+- `PreLlmRequest` public Hook runs under normal conditions and cannot inject raw `Item` context.
+- `PreToolCall` Hook can deny/skip with a synthetic result through the intended path.
+- `PostToolCall` Hook can observe a bounded summary and abort when allowed, but cannot rewrite tool output unless an explicit safe transform capability is introduced.
+- `OnTurnEnd` public Hook cannot append arbitrary messages through raw internal action types.
+- `OnAbort` Hook is called on abort paths.
+- Multiple Hooks execute in registration order and short-circuit on non-continue actions.
+- Internal mechanisms run in the expected order relative to public Hooks.
+
+## Non-goals
+
+- Implementing a Plugin runtime.
+- Implementing a feature registry.
+- Adding declarative hooks.
+- Adding new Hook event kinds unless a gap is found during the audit.
+- Allowing Hooks to rewrite arbitrary history/tool/model context.
+
+## Acceptance criteria
+
+- Public `pod::hook` APIs no longer expose internal action types that allow raw model-visible `Item` injection.
+- Internal interceptor capabilities remain available only through internal mechanisms where justified.
+- Existing manifest permission policy and usage tracking behavior remain intact.
+- Focused Pod-layer tests cover the Hook events and short-circuit behavior needed by the feature registry/plugin surface.
+- The resulting Hook surface is safe to reference from `plugin-feature-contribution-registry` as the public Hook contribution boundary.

work-items/open/20260603-122317-hook-public-surface-hardening/thread.md

@@ -0,0 +1,7 @@
+<!-- event: create author: tickets.sh at: 2026-06-03T12:23:17Z -->
+
+## Created
+
+Created by tickets.sh create.
+
+---

work-items/open/20260603-122317-plugin-feature-contribution-registry/item.md

@@ -0,0 +1,89 @@
+---
+id: 20260603-122317-plugin-feature-contribution-registry
+slug: plugin-feature-contribution-registry
+title: Plugin: feature contribution registry for built-in and external capabilities
+status: open
+kind: feature
+priority: P1
+labels: [plugin, registry, tools, hooks, orchestration]
+created_at: 2026-06-03T12:23:17Z
+updated_at: 2026-06-03T12:23:17Z
+assignee: null
+legacy_ticket: null
+---
+
+## Issue
+
+Yoi already has many capability surfaces: built-in tools, memory tools, Pod management tools, manifest permission hooks, workflow assets, notifications, and planned WorkItem / MCP / plugin features. If new features keep registering themselves through ad hoc Pod/Worker code paths, Plugin system work will not produce a single management boundary and later features such as WorkItem intake will be hard to detach.
+
+The immediate need is not package distribution or WASM execution. The immediate need is a runtime feature contribution registry that lets built-in features and future external plugins contribute through the same existing host surfaces: Tools, Hooks, and notification/event paths.
+
+## Direction
+
+Introduce a feature registry boundary for Pod runtime capability installation.
+
+- Feature state remains owned by the feature/extension module, not by Pod history or prompt context.
+- Pod interaction happens through existing surfaces:
+  - Tool contributions registered into the normal ToolRegistry / permission / history path.
+  - Hook contributions registered through the public Pod Hook boundary.
+  - Notification/event contributions use existing durable Notify / Event paths rather than invisible context injection.
+- The registry is responsible for discovery/enablement diagnostics and installation into existing surfaces; it must not create a parallel execution path.
+- Built-in features should be expressible as feature contributions first. External plugin runtimes can be added later.
+
+## Placement note
+
+The runtime registry should initially live in the Pod layer, e.g. `crates/pod/src/feature.rs` or an equivalent module, because installation requires access to Worker tool registration, Pod Hook registry setup, manifest/profile-resolved policy, notification buffers, and Pod event bridges.
+
+Pure descriptor types may later move to a separate `plugin` / `extension` crate if needed, but descriptor types must not depend on Pod internals.
+
+## Requirements
+
+- Define feature identity/source/runtime metadata for at least built-in features and future user/project plugins.
+  - Example sources: builtin, user, project.
+  - Example runtime kinds: builtin, declarative, mcp bridge future, wasm future.
+- Define contribution descriptors or install abstractions for:
+  - Tools
+  - Hooks
+  - Notification/event-facing capabilities where needed
+- Define capability request / host grant data structures suitable for policy diagnostics.
+- Add a registry/builder/install context that can install enabled feature contributions into existing Pod/Worker surfaces.
+- Preserve current behavior while moving registration toward the registry.
+  - Existing built-in tool registration must still work.
+  - Existing manifest permission hook behavior must still work.
+  - Existing notification/history invariants must still hold.
+- Keep model-visible plugin/feature output on durable paths: tool result, committed history, or explicit notification/history append paths.
+- Do not let feature contributions mutate session history, memory, prompt context, or scope outside approved host APIs.
+- Document how WorkItem tools should become a built-in feature contribution rather than a special Pod context path.
+
+## Non-goals
+
+- Implementing WASM execution.
+- Implementing plugin package discovery or archive validation.
+- Implementing MCP itself.
+- Implementing WorkItem management tools.
+- Adding UI/TUI rendering plugins.
+- Auto-enabling user/project plugins.
+
+## Suggested phases
+
+1. **Registry design**
+   - Define feature descriptor, source, runtime kind, contribution kinds, capability request/grant, and diagnostics.
+2. **Pod runtime registry skeleton**
+   - Add a Pod-layer feature registry/builder and install context.
+   - Keep behavior unchanged initially.
+3. **Builtin registration migration**
+   - Move a small, low-risk built-in feature group through the registry first.
+   - Then migrate built-in tool groups / memory / Pod-management registration as appropriate.
+4. **Hook integration**
+   - Integrate only after `hook-public-surface-hardening` establishes a safe public Hook action surface.
+5. **Follow-up alignment**
+   - Update WorkItem, MCP, and plugin distribution tickets to depend on this registry boundary where they contribute capabilities.
+
+## Acceptance criteria
+
+- The codebase has a first-class feature contribution registry boundary for Pod runtime installation.
+- At least one built-in capability group is registered through the new registry without changing behavior.
+- The registry can describe Tool and Hook contributions and records source/runtime/capability diagnostics.
+- Feature installation uses existing ToolRegistry, HookRegistry, and notification/history paths; no parallel Pod context injection path is introduced.
+- WorkItem and MCP follow-up tickets can target this registry instead of adding ad hoc registration code.
+- Focused tests cover the migrated built-in registration and capability/diagnostic behavior.

work-items/open/20260603-122317-plugin-feature-contribution-registry/thread.md

@@ -0,0 +1,7 @@
+<!-- event: create author: tickets.sh at: 2026-06-03T12:23:17Z -->
+
+## Created
+
+Created by tickets.sh create.
+
+---