task: split feature authority model

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.

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.

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.

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.

work-items/open/20260604-234844-feature-api-authority-separation/thread.md

@@ -0,0 +1,30 @@
+<!-- event: create author: tickets.sh at: 2026-06-04T23:48:44Z -->
+
+## Created
+
+Created by tickets.sh create.
+
+---
+
+<!-- event: decision author: hare at: 2026-06-04T23:50:15Z -->
+
+## 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.
+
+
+---