diff --git a/work-items/open/20260531-010005-plugin-extension-surface/artifacts/feature-registry-split-decision.md b/work-items/open/20260531-010005-plugin-extension-surface/artifacts/feature-registry-split-decision.md new file mode 100644 index 00000000..8b3b429a --- /dev/null +++ b/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. diff --git a/work-items/open/20260531-010005-plugin-extension-surface/item.md b/work-items/open/20260531-010005-plugin-extension-surface/item.md index 5789803a..33b1402b 100644 --- a/work-items/open/20260531-010005-plugin-extension-surface/item.md +++ b/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** diff --git a/work-items/open/20260531-010005-plugin-extension-surface/thread.md b/work-items/open/20260531-010005-plugin-extension-surface/thread.md index e2a886a2..e5aefea3 100644 --- a/work-items/open/20260531-010005-plugin-extension-surface/thread.md +++ b/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. +--- + + + +## 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. + + --- diff --git a/work-items/open/20260601-031252-builtin-work-item-intake-routing/item.md b/work-items/open/20260601-031252-builtin-work-item-intake-routing/item.md index eafffb1d..64e6151b 100644 --- a/work-items/open/20260601-031252-builtin-work-item-intake-routing/item.md +++ b/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 を作成できる導線を設計すること。 diff --git a/work-items/open/20260601-031252-builtin-work-item-intake-routing/thread.md b/work-items/open/20260601-031252-builtin-work-item-intake-routing/thread.md index 18f4986b..e1f4501a 100644 --- a/work-items/open/20260601-031252-builtin-work-item-intake-routing/thread.md +++ b/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. +--- + + + +## 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. + + --- diff --git a/work-items/open/20260603-122317-hook-public-surface-hardening/artifacts/.gitkeep b/work-items/open/20260603-122317-hook-public-surface-hardening/artifacts/.gitkeep new file mode 100644 index 00000000..e69de29b diff --git a/work-items/open/20260603-122317-hook-public-surface-hardening/item.md b/work-items/open/20260603-122317-hook-public-surface-hardening/item.md new file mode 100644 index 00000000..97e66d38 --- /dev/null +++ b/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)` and `TurnEndAction::ContinueWithMessages(Vec)` 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. diff --git a/work-items/open/20260603-122317-hook-public-surface-hardening/thread.md b/work-items/open/20260603-122317-hook-public-surface-hardening/thread.md new file mode 100644 index 00000000..963ee2d7 --- /dev/null +++ b/work-items/open/20260603-122317-hook-public-surface-hardening/thread.md @@ -0,0 +1,7 @@ + + +## Created + +Created by tickets.sh create. + +--- diff --git a/work-items/open/20260603-122317-plugin-feature-contribution-registry/artifacts/.gitkeep b/work-items/open/20260603-122317-plugin-feature-contribution-registry/artifacts/.gitkeep new file mode 100644 index 00000000..e69de29b diff --git a/work-items/open/20260603-122317-plugin-feature-contribution-registry/item.md b/work-items/open/20260603-122317-plugin-feature-contribution-registry/item.md new file mode 100644 index 00000000..254fa72c --- /dev/null +++ b/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. diff --git a/work-items/open/20260603-122317-plugin-feature-contribution-registry/thread.md b/work-items/open/20260603-122317-plugin-feature-contribution-registry/thread.md new file mode 100644 index 00000000..963ee2d7 --- /dev/null +++ b/work-items/open/20260603-122317-plugin-feature-contribution-registry/thread.md @@ -0,0 +1,7 @@ + + +## Created + +Created by tickets.sh create. + +---