From 06c5cb7652a49ad8c0ac6e20a7c18967bb742098 Mon Sep 17 00:00:00 2001 From: Hare Date: Fri, 5 Jun 2026 08:50:18 +0900 Subject: [PATCH] task: split feature authority model --- .../artifacts/decision.md | 8 +-- .../item.md | 15 ++--- .../artifacts/.gitkeep | 0 .../artifacts/decision.md | 15 +++++ .../item.md | 58 +++++++++++++++++++ .../thread.md | 30 ++++++++++ 6 files changed, 115 insertions(+), 11 deletions(-) create mode 100644 work-items/open/20260604-234844-feature-api-authority-separation/artifacts/.gitkeep create mode 100644 work-items/open/20260604-234844-feature-api-authority-separation/artifacts/decision.md create mode 100644 work-items/open/20260604-234844-feature-api-authority-separation/item.md create mode 100644 work-items/open/20260604-234844-feature-api-authority-separation/thread.md diff --git a/work-items/open/20260604-223500-task-tools-builtin-plugin/artifacts/decision.md b/work-items/open/20260604-223500-task-tools-builtin-plugin/artifacts/decision.md index 29e1c9c9..fbca34b4 100644 --- a/work-items/open/20260604-223500-task-tools-builtin-plugin/artifacts/decision.md +++ b/work-items/open/20260604-223500-task-tools-builtin-plugin/artifacts/decision.md @@ -1,11 +1,11 @@ -# Decision: Task tools as trial built-in plugin +# Decision: Task tools as trial built-in feature module -Use the Task tool group as a trial of the Plugin/Feature boundary, but keep the scope to a built-in plugin module. +Use the Task tool group as a trial of the Feature API boundary, but keep the scope to an internal built-in module. Rationale: - `TaskCreate` / `TaskUpdate` / `TaskGet` / `TaskList` are already small and state-bounded around `TaskStore`. - They do not need external plugin loading, network, filesystem, secrets, model notification authority, or custom UI. -- The feature registry slice already routes them through the registry; the remaining useful trial is to extract the concrete Task feature into a clean module boundary that future built-in plugins can copy. +- The feature registry slice already routes them through the registry; the remaining useful trial is to extract the concrete Task feature into a clean module boundary that future built-in modules can copy. -This ticket should not introduce a package loader or sandbox. It should validate the public API shape by making Task tools look like a normal built-in plugin/feature contribution: descriptor-declared tools, no host authorities, install through registry, normal ToolRegistry/PreToolCall behavior preserved. +This ticket should not introduce a package loader, sandbox, or external-plugin permission model. It should validate the public API shape by making Task tools look like a normal built-in feature contribution: descriptor-declared tools, no host authorities, install through registry, normal ToolRegistry/PreToolCall behavior preserved. diff --git a/work-items/open/20260604-223500-task-tools-builtin-plugin/item.md b/work-items/open/20260604-223500-task-tools-builtin-plugin/item.md index cc2c5ac9..c4ffeed8 100644 --- a/work-items/open/20260604-223500-task-tools-builtin-plugin/item.md +++ b/work-items/open/20260604-223500-task-tools-builtin-plugin/item.md @@ -1,7 +1,7 @@ --- id: 20260604-223500-task-tools-builtin-plugin slug: task-tools-builtin-plugin -title: Plugin: extract Task tools as builtin plugin module +title: Feature: extract Task tools as builtin module status: open kind: task priority: P1 @@ -14,13 +14,13 @@ legacy_ticket: null ## Issue -The feature contribution registry slice proved the registry path by registering `TaskCreate` / `TaskUpdate` / `TaskGet` / `TaskList` through a built-in `FeatureModule`. That is a useful proof, but the Task tool group still lives as an inline built-in helper inside the registry implementation rather than as a clean plugin-like module. +The feature contribution registry slice proved the registry path by registering `TaskCreate` / `TaskUpdate` / `TaskGet` / `TaskList` through a built-in `FeatureModule`. That is a useful proof, but the Task tool group still lives as an inline built-in helper inside the registry implementation rather than as a clean internal module. -As a trial of the Plugin/Feature boundary, extract the Task tool group into a first-class built-in plugin module using the same public-ish Feature API shape that future built-in/external plugin modules should use. This should validate whether the registry API is usable without giving Task tools special Pod-side wiring. +As a trial of the Feature API boundary, extract the Task tool group into a first-class built-in internal module using the same public-ish Feature API shape that future built-in modules and external plugins should use. This should validate whether the registry API is usable without giving Task tools special Pod-side wiring or treating internal module extraction as an external-plugin permission problem. ## Direction -Treat Task tools as a built-in plugin/feature module, not as an ad hoc registration branch. +Treat Task tools as a built-in feature/internal module, not as an ad hoc registration branch. - The module contributes only the existing Task tools: - `TaskCreate` @@ -35,7 +35,7 @@ Treat Task tools as a built-in plugin/feature module, not as an ad hoc registrat ## Requirements -- Move the Task built-in feature out of the generic registry implementation into a clean module boundary suitable as a reference pattern for built-in plugins. +- Move the Task built-in feature out of the generic registry implementation into a clean module boundary suitable as a reference pattern for built-in feature modules. - Candidate placement: `crates/pod/src/feature/builtin/task.rs` or equivalent. - Keep `pod::feature` focused on registry/types rather than concrete built-in feature implementations. - Expose a clear construction function such as `task_tools_feature(task_store: tools::TaskStore) -> impl FeatureModule` from the built-in feature module. @@ -50,7 +50,7 @@ Treat Task tools as a built-in plugin/feature module, not as an ad hoc registrat - descriptor declarations match the installed tool names; - normal TaskCreate/TaskUpdate/TaskGet/TaskList behavior still works or existing tests continue to cover it; - no contribution authority variants are reintroduced. -- Document, in code comments or test names where appropriate, that this is the reference built-in plugin module pattern. +- Document, in code comments or test names where appropriate, that this is the reference built-in feature module pattern. ## Non-goals @@ -60,12 +60,13 @@ Treat Task tools as a built-in plugin/feature module, not as an ad hoc registrat - WorkItem/MCP integration. - Moving TaskStore persistence/lifecycle semantics. - Changing Task tool names/schemas/descriptions. +- Resolving the broader internal-module vs external-plugin authority split; that is tracked separately by `feature-api-authority-separation`. - Adding/removing Task tools. - Reworking all built-in tool groups. ## Acceptance criteria -- Task tool registration is represented as a clean built-in plugin/feature module rather than inline registry implementation detail. +- Task tool registration is represented as a clean built-in feature module rather than inline registry implementation detail. - Behavior and model-visible tool metadata for `TaskCreate` / `TaskUpdate` / `TaskGet` / `TaskList` are unchanged. - Feature descriptor declarations and install-time contributions are reconciled through the existing registry boundary. - No new host authority grants are required for Task tools. diff --git a/work-items/open/20260604-234844-feature-api-authority-separation/artifacts/.gitkeep b/work-items/open/20260604-234844-feature-api-authority-separation/artifacts/.gitkeep new file mode 100644 index 00000000..e69de29b diff --git a/work-items/open/20260604-234844-feature-api-authority-separation/artifacts/decision.md b/work-items/open/20260604-234844-feature-api-authority-separation/artifacts/decision.md new file mode 100644 index 00000000..63da839c --- /dev/null +++ b/work-items/open/20260604-234844-feature-api-authority-separation/artifacts/decision.md @@ -0,0 +1,15 @@ +# Decision: separate internal feature modules from external-plugin authority + +Internal modules extracted from Pod implementation files should not be treated as if they require the external-plugin permission model. + +For an internal built-in module such as Task tools: + +- the feature registry is an API/registration boundary; +- descriptor-declared contributions are reconciled at install time; +- normal ToolRegistry and PreToolCall permission behavior remains authoritative; +- host state such as `TaskStore` can be passed by the Pod host constructor; +- requested host authorities should normally be empty. + +The external-plugin authority model remains necessary for sandbox/object-capability grants when plugin code receives dangerous host APIs such as filesystem, network, secrets, model-visible durable notification/history append, Pod-management façade, persistent state, or authority-bearing service access. + +This split should be implemented separately from the Task tools extraction. The Task tools extraction should validate the contribution-only built-in module path without solving external plugin approval. diff --git a/work-items/open/20260604-234844-feature-api-authority-separation/item.md b/work-items/open/20260604-234844-feature-api-authority-separation/item.md new file mode 100644 index 00000000..ff1adbfc --- /dev/null +++ b/work-items/open/20260604-234844-feature-api-authority-separation/item.md @@ -0,0 +1,58 @@ +--- +id: 20260604-234844-feature-api-authority-separation +slug: feature-api-authority-separation +title: Feature API: separate internal modules from external-plugin authority model +status: open +kind: task +priority: P1 +labels: [plugin, feature-registry, permissions, architecture] +created_at: 2026-06-04T23:48:44Z +updated_at: 2026-06-04T23:50:15Z +assignee: null +legacy_ticket: null +--- + +## Issue + +The first feature-registry slice intentionally placed contribution descriptors and future external-plugin host authorities in the same `pod::feature` module. That was acceptable as a scaffold, but it risks making simple internal module extraction look like it participates in the external-plugin permission model. + +For internal modules that are merely moved outside a Pod implementation file, the registry should act as an API/registration boundary: descriptor-declared contributions, install reports, and normal ToolRegistry/Hook paths. It should not require or imply sandbox/user-approval authorities unless the module asks the host for dangerous external/plugin-style APIs. + +## Direction + +Separate the concepts in code and naming: + +- **Contribution boundary**: tools, hooks, background task declarations, service providers, descriptor/digest locking, duplicate checks, install reports. +- **Internal built-in module boundary**: in-process modules constructed by the host with explicit Rust handles such as `TaskStore`; normally no host-authority request/grant flow. +- **External-plugin authority boundary**: user-approved sandbox/object-capability grants for host-provided APIs and handles such as filesystem, network, secrets, model-visible durable notification, Pod-management façade, persistent/plugin state, and authority-bearing service access. + +The goal is not to remove the authority model. The goal is to prevent the authority model from being mixed into every internal module extraction. + +## Requirements + +- Audit `pod::feature` names and APIs for places where external-plugin authority concepts are presented as required for internal built-in modules. +- Make the API clearly support a contribution-only built-in module path. + - Internal modules should be able to declare contributions and install without requesting authorities. + - Descriptor/contribution reconciliation still applies. + - Normal per-call tool permission / PreToolCall policy still applies. +- Keep `HostAuthority` or equivalent only for host-provided dangerous authorities. + - Do not reintroduce contribution-authority variants such as `ContributeTool`, `ContributeHook`, `RunBackgroundTask`, or `ProvideService`. +- Consider whether the authority request/grant types should be renamed, nested, moved, or documented as external-plugin/sandbox-oriented. +- Clarify how built-in modules receive in-process state/handles from the host without treating those constructor arguments as plugin authorities. +- Clarify how future external plugins will get only approved host handles/services, without changing the internal module path. +- Update tests or add focused tests where needed so a built-in module with zero requested authorities is a normal first-class path. + +## Non-goals + +- Implementing external plugin loading or package approval lock files. +- Implementing a real user approval resolver. +- Changing existing manifest/tool permission policy. +- Extracting Memory or Pod management out of core. +- Changing Task tool behavior. + +## Acceptance criteria + +- The code/design clearly distinguishes contribution registration from external-plugin host authority grants. +- Internal built-in modules can be represented as contribution-only modules without authority boilerplate. +- Authority model remains available for future external plugins and host-provided dangerous APIs. +- Tests/documentation make it hard to confuse descriptor-approved contributions with sandbox authorities. diff --git a/work-items/open/20260604-234844-feature-api-authority-separation/thread.md b/work-items/open/20260604-234844-feature-api-authority-separation/thread.md new file mode 100644 index 00000000..2bef2448 --- /dev/null +++ b/work-items/open/20260604-234844-feature-api-authority-separation/thread.md @@ -0,0 +1,30 @@ + + +## Created + +Created by tickets.sh create. + +--- + + + +## Decision + +# Decision: separate internal feature modules from external-plugin authority + +Internal modules extracted from Pod implementation files should not be treated as if they require the external-plugin permission model. + +For an internal built-in module such as Task tools: + +- the feature registry is an API/registration boundary; +- descriptor-declared contributions are reconciled at install time; +- normal ToolRegistry and PreToolCall permission behavior remains authoritative; +- host state such as `TaskStore` can be passed by the Pod host constructor; +- requested host authorities should normally be empty. + +The external-plugin authority model remains necessary for sandbox/object-capability grants when plugin code receives dangerous host APIs such as filesystem, network, secrets, model-visible durable notification/history append, Pod-management façade, persistent state, or authority-bearing service access. + +This split should be implemented separately from the Task tools extraction. The Task tools extraction should validate the contribution-only built-in module path without solving external plugin approval. + + +---