From d8ba6c39f7dfecf304dea111add7bea581c82497 Mon Sep 17 00:00:00 2001 From: Hare Date: Fri, 5 Jun 2026 07:35:51 +0900 Subject: [PATCH] task: add task tools plugin trial --- .../artifacts/.gitkeep | 0 .../artifacts/decision.md | 11 +++ .../item.md | 72 +++++++++++++++++++ .../thread.md | 26 +++++++ 4 files changed, 109 insertions(+) create mode 100644 work-items/open/20260604-223500-task-tools-builtin-plugin/artifacts/.gitkeep create mode 100644 work-items/open/20260604-223500-task-tools-builtin-plugin/artifacts/decision.md create mode 100644 work-items/open/20260604-223500-task-tools-builtin-plugin/item.md create mode 100644 work-items/open/20260604-223500-task-tools-builtin-plugin/thread.md diff --git a/work-items/open/20260604-223500-task-tools-builtin-plugin/artifacts/.gitkeep b/work-items/open/20260604-223500-task-tools-builtin-plugin/artifacts/.gitkeep new file mode 100644 index 00000000..e69de29b 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 new file mode 100644 index 00000000..29e1c9c9 --- /dev/null +++ b/work-items/open/20260604-223500-task-tools-builtin-plugin/artifacts/decision.md @@ -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. 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 new file mode 100644 index 00000000..cc2c5ac9 --- /dev/null +++ b/work-items/open/20260604-223500-task-tools-builtin-plugin/item.md @@ -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. diff --git a/work-items/open/20260604-223500-task-tools-builtin-plugin/thread.md b/work-items/open/20260604-223500-task-tools-builtin-plugin/thread.md new file mode 100644 index 00000000..26a5b2c1 --- /dev/null +++ b/work-items/open/20260604-223500-task-tools-builtin-plugin/thread.md @@ -0,0 +1,26 @@ + + +## Created + +Created by tickets.sh create. + +--- + + + +## 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. + + +---