yoi/.yoi/tickets/00001KTAV1TH0/item.md

title	state	created_at	updated_at
Task: move Task domain out of tools into pod built-in feature	closed	2026-06-05T02:51:00Z	2026-06-05T03:26:31Z

Issue

Task is now a built-in feature module in pod::feature::builtin::task, and it owns Task reminder hooks and feature lifecycle behavior. However, its domain state and tool implementations still live in crates/tools/src/task.rs as tools::TaskStore, tools::TaskEntry, tools::TaskStatus, tools::TaskSnapshot, and tools::task_tools(...).

That split is semantically wrong: tools should remain a low-level built-in tool helper crate, while Task is now a stateful built-in feature with session-lifetime state, restore/rewind/snapshot behavior, hooks, and model-visible reminder policy.

Keep the next step inside the pod crate. Do not create a new builtin-features crate yet. The larger crate-boundary move can wait until a feature-api crate exists and external plugin APIs are better established.

Direction

Move Task domain and Task tool implementation from tools into the Pod built-in Task feature module.

Target shape:

• crates/pod/src/feature/builtin/task.rs or a nested task/ module owns:
  • TaskStore
  • TaskEntry
  • TaskStatus
  • TaskSnapshot
  • Task tool implementations for TaskCreate, TaskUpdate, TaskGet, TaskList
  • Task reminder hooks and state
  • snapshot/restore/rewind/compaction façade
• crates/tools owns only low-level generic tools and helper state such as filesystem tools, ScopedFs, Tracker, Bash, Web tools, etc.

Requirements

• Remove Task domain ownership from tools.
  • Prefer deleting crates/tools/src/task.rs if no non-Pod production caller needs it.
  • Remove TaskStore, TaskEntry, TaskStatus, TaskSnapshot, and task_tools re-exports from tools unless a carefully justified temporary compatibility path is needed.
• Move Task tool implementations into the Pod built-in Task feature module.
  • Tool names, schemas, descriptions, outputs, and behavior must remain unchanged.
  • Preserve once-materialized tool identity and descriptor-approved contribution checks.
• Keep tools::core_builtin_tools(...) for non-Task low-level tools.
• Audit tools::builtin_tools(...).
  • If only tests/legacy paths use it, either remove it or change those tests/callers to use core_builtin_tools plus the Task feature registry path.
  • Do not keep a production tools::builtin_tools(..., task_store, ...) API that implies Task belongs to tools.
• Update Pod Task feature code to refer to local Task types, not tools::TaskStore / tools::TaskEntry / tools::TaskStatus.
• Update tests.
  • Move TaskStore/tool tests from tools to pod where appropriate.
  • Update tools integration tests so they no longer assume Task tools are registered by tools::builtin_tools.
  • TUI tests currently use tools as a dev-dependency for Task compatibility checks. Either replace those checks with local JSON fixtures / shared literal schemas, or document and keep a test-only compatibility helper only if absolutely necessary.
• Preserve current observable behavior:
  • Task tool API and output text;
  • TaskStore replay/snapshot/restore semantics;
  • Task reminder behavior;
  • TUI parsing compatibility;
  • normal ToolRegistry / PreToolCall permission path.

Non-goals

• Creating a new builtin-features crate.
• Extracting pod::feature / pod::hook into a separate feature-api crate.
• External plugin loading, WASM, package approval, or sandbox authority work.
• Moving Memory, WorkItem, Web, filesystem, or Pod-management tools.
• TUI UI changes.
• Changing Task tool names/schemas/behavior.

Acceptance criteria

• Task domain state and tool implementation no longer live in crates/tools as production API.
• The built-in Task feature module is the owner of TaskStore, Task types, Task tools, and Task reminders.
• tools remains a lower-level tool helper crate without Task feature state.
• Production code does not call tools::task_tools or tools::TaskStore.
• Tests are relocated/updated and continue to verify Task behavior and TUI compatibility.
• Workspace validation passes.