# Delegation intent: move Task domain into pod built-in feature

## Intent

Move Task domain state and Task tool implementation out of the `tools` crate and into the `pod::feature::builtin::task` module. Keep this inside the `pod` crate for now; do not create a new built-in-features crate.

The goal is cohesion: Task is now a stateful built-in feature, so `TaskStore`, Task types, Task tools, reminder hooks, and snapshot/restore façade should live together.

## Worktree / branch

- worktree: `/home/hare/Projects/yoi/.worktree/task-domain-in-pod-feature`
- branch: `work/task-domain-in-pod-feature`

## Requirements

- Move Task domain implementation from `crates/tools/src/task.rs` into the Pod built-in Task feature module.
  - If the file becomes large, prefer `crates/pod/src/feature/builtin/task/` with submodules such as `store.rs`, `tools.rs`, `reminder.rs`, and `mod.rs`.
  - A single `task.rs` file is acceptable if the change stays clear and maintainable.
- Task feature should own:
  - `TaskStore`
  - `TaskEntry`
  - `TaskStatus`
  - `TaskSnapshot`
  - `TaskCreate` / `TaskUpdate` / `TaskGet` / `TaskList` tool implementations
  - reminder hooks/state already moved to the feature
  - snapshot/restore/rewind/compaction façade
- Remove Task production API from `tools`.
  - Remove `tools::TaskStore`, `tools::TaskEntry`, `tools::TaskStatus`, `tools::TaskSnapshot`, and `tools::task_tools` re-exports unless a narrowly justified temporary test-only compatibility path is required.
  - Remove or update `tools::builtin_tools(..., task_store, ...)`; production tools should not imply Task belongs to `tools`.
  - Keep `tools::core_builtin_tools(...)` and non-Task low-level tools intact.
- Update Pod Task feature code to use local Task types and local Task tool factories.
- Move/port Task tests from `tools` to `pod` as needed.
- Update `tools` integration tests so they no longer expect Task tools in `tools::builtin_tools` registration order.
- Update TUI compatibility tests that currently depend on `tools` Task types.
  - Prefer local JSON fixtures or local mirrored structs in TUI tests.
  - Do not make TUI depend on `pod` just for tests unless there is a strong reason and it does not create an undesirable dependency.
- Preserve observable behavior exactly:
  - tool names/schemas/descriptions;
  - tool outputs;
  - TaskStore replay/snapshot text;
  - Task reminder body/cooldown/source;
  - TUI parsing compatibility;
  - normal ToolRegistry / PreToolCall path.

## Non-goals

- Creating a new `builtin-features` crate.
- Extracting `feature-api` from `pod`.
- External plugin loading, WASM, package approval, sandbox authority work.
- Moving other built-in tool groups.
- TUI UI changes.
- Changing Task semantics.

## Suggested files

- `crates/pod/src/feature/builtin/task.rs`
- `crates/pod/src/feature/builtin.rs`
- `crates/pod/src/feature.rs`
- `crates/tools/src/task.rs`
- `crates/tools/src/lib.rs`
- `crates/tools/tests/integration.rs`
- `crates/tools/tests/edge_cases.rs`
- `crates/tui/src/task.rs`
- `crates/tui/src/app.rs` / TUI task compatibility tests if needed

## Validation

Run at least:

- focused Task feature tests moved/updated by this ticket
- `cargo test -p pod task --lib`
- `cargo test -p tools --lib`
- `cargo test -p tools --tests`
- `cargo test -p tui task --lib` or relevant focused TUI task tests
- `cargo test -p pod --lib`
- `cargo test -p llm-worker --lib`
- `cargo check --workspace --all-targets`
- `cargo fmt --check`
- `./tickets.sh doctor`
- `git diff --check`

Run `nix build .#yoi` if feasible.

## Escalate if

- Removing `tools::builtin_tools` breaks important non-Pod production callers.
- TUI compatibility checks require a shared Task schema crate to avoid duplication.
- Moving Task tool implementation into `pod` creates an unexpected dependency cycle.
- Preserving Task snapshot/replay semantics would require behavior changes.

## Completion report

Report:

- worktree path / branch
- commit hash
- changed files
- final Task module layout
- what remains in `tools` and why
- evidence production code no longer uses `tools::TaskStore` / `tools::task_tools`
- tests/validation results
- unresolved risks/follow-ups
- whether ready for external review