task: add task tools plugin trial
This commit is contained in:
parent
eea94ea4ba
commit
d8ba6c39f7
|
|
@ -0,0 +1,11 @@
|
||||||
|
# Decision: Task tools as trial built-in plugin
|
||||||
|
|
||||||
|
Use the Task tool group as a trial of the Plugin/Feature boundary, but keep the scope to a built-in plugin 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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
@ -0,0 +1,72 @@
|
||||||
|
---
|
||||||
|
id: 20260604-223500-task-tools-builtin-plugin
|
||||||
|
slug: task-tools-builtin-plugin
|
||||||
|
title: Plugin: extract Task tools as builtin plugin module
|
||||||
|
status: open
|
||||||
|
kind: task
|
||||||
|
priority: P1
|
||||||
|
labels: [plugin, feature-registry, tasks]
|
||||||
|
created_at: 2026-06-04T22:35:00Z
|
||||||
|
updated_at: 2026-06-04T22:35:48Z
|
||||||
|
assignee: null
|
||||||
|
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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
## Direction
|
||||||
|
|
||||||
|
Treat Task tools as a built-in plugin/feature module, not as an ad hoc registration branch.
|
||||||
|
|
||||||
|
- The module contributes only the existing Task tools:
|
||||||
|
- `TaskCreate`
|
||||||
|
- `TaskUpdate`
|
||||||
|
- `TaskGet`
|
||||||
|
- `TaskList`
|
||||||
|
- The module owns or receives the existing `TaskStore` handle from the Pod host.
|
||||||
|
- Tool names, schemas, descriptions, behavior, task reminder/compaction behavior, and model-visible history behavior must not change.
|
||||||
|
- Task tools remain subject to the normal ToolRegistry and PreToolCall permission path.
|
||||||
|
- Contributions are descriptor-declared and registry-validated; no contribution-capability gates are reintroduced.
|
||||||
|
- No external plugin loading, package format, WASM, MCP, WorkItem, or UI/dialog system is in scope.
|
||||||
|
|
||||||
|
## 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.
|
||||||
|
- 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.
|
||||||
|
- Preserve the existing TaskStore sharing semantics:
|
||||||
|
- one Pod-lifetime/session TaskStore shared by all four Task tools;
|
||||||
|
- current TaskStore snapshot/reminder/compaction behavior remains valid.
|
||||||
|
- Ensure the Task feature descriptor exactly declares the four Task tools and no host authorities.
|
||||||
|
- Keep descriptor-approved contribution checks active for Task tools.
|
||||||
|
- Keep once-materialized tool identity behavior from the registry slice.
|
||||||
|
- Add/update focused tests proving:
|
||||||
|
- Task tools install through the built-in feature module;
|
||||||
|
- 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.
|
||||||
|
|
||||||
|
## Non-goals
|
||||||
|
|
||||||
|
- External plugin discovery/loading.
|
||||||
|
- Plugin package format or descriptor lock files.
|
||||||
|
- WASM/runtime sandboxing.
|
||||||
|
- WorkItem/MCP integration.
|
||||||
|
- Moving TaskStore persistence/lifecycle semantics.
|
||||||
|
- Changing Task tool names/schemas/descriptions.
|
||||||
|
- 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.
|
||||||
|
- 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.
|
||||||
|
- Focused tests and workspace checks pass.
|
||||||
|
|
@ -0,0 +1,26 @@
|
||||||
|
<!-- event: create author: tickets.sh at: 2026-06-04T22:35:00Z -->
|
||||||
|
|
||||||
|
## Created
|
||||||
|
|
||||||
|
Created by tickets.sh create.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- event: decision author: hare at: 2026-06-04T22:35:48Z -->
|
||||||
|
|
||||||
|
## Decision
|
||||||
|
|
||||||
|
# Decision: Task tools as trial built-in plugin
|
||||||
|
|
||||||
|
Use the Task tool group as a trial of the Plugin/Feature boundary, but keep the scope to a built-in plugin 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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
|
||||||
|
---
|
||||||
Loading…
Reference in New Issue
Block a user