15 KiB
Created
Created by tickets.sh create.
Decision
Decision: keep built-in Task feature inside pod for now
Task is a stateful built-in feature, not a low-level tools crate concern. The next step should keep the feature inside pod rather than creating a new crate.
Rationale:
pod::feature/pod::hookare still defined in thepodcrate.- Creating
builtin-featuresnow would either depend onpodor require premature extraction of a feature-api crate. - Feature-per-crate would create too many crates; a future
builtin-featurescrate may be appropriate only after the API boundary is stable. - Moving Task domain state out of
toolsand intopod::feature::builtin::taskfixes the immediate semantic split without forcing crate-boundary churn.
Desired result for this ticket:
toolsprovides low-level generic tool helpers.pod::feature::builtin::taskowns TaskStore, Task types, Task tool implementations, Task reminders, and Task feature lifecycle.
Plan
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.rsinto the Pod built-in Task feature module.- If the file becomes large, prefer
crates/pod/src/feature/builtin/task/with submodules such asstore.rs,tools.rs,reminder.rs, andmod.rs. - A single
task.rsfile is acceptable if the change stays clear and maintainable.
- If the file becomes large, prefer
- Task feature should own:
TaskStoreTaskEntryTaskStatusTaskSnapshotTaskCreate/TaskUpdate/TaskGet/TaskListtool 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, andtools::task_toolsre-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 totools. - Keep
tools::core_builtin_tools(...)and non-Task low-level tools intact.
- Remove
- Update Pod Task feature code to use local Task types and local Task tool factories.
- Move/port Task tests from
toolstopodas needed. - Update
toolsintegration tests so they no longer expect Task tools intools::builtin_toolsregistration order. - Update TUI compatibility tests that currently depend on
toolsTask types.- Prefer local JSON fixtures or local mirrored structs in TUI tests.
- Do not make TUI depend on
podjust 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-featurescrate. - Extracting
feature-apifrompod. - 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.rscrates/pod/src/feature/builtin.rscrates/pod/src/feature.rscrates/tools/src/task.rscrates/tools/src/lib.rscrates/tools/tests/integration.rscrates/tools/tests/edge_cases.rscrates/tui/src/task.rscrates/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 --libcargo test -p tools --libcargo test -p tools --testscargo test -p tui task --libor relevant focused TUI task testscargo test -p pod --libcargo test -p llm-worker --libcargo check --workspace --all-targetscargo fmt --check./tickets.sh doctorgit diff --check
Run nix build .#yoi if feasible.
Escalate if
- Removing
tools::builtin_toolsbreaks important non-Pod production callers. - TUI compatibility checks require a shared Task schema crate to avoid duplication.
- Moving Task tool implementation into
podcreates 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
toolsand why - evidence production code no longer uses
tools::TaskStore/tools::task_tools - tests/validation results
- unresolved risks/follow-ups
- whether ready for external review
Review: approve
Review: task-domain-in-pod-feature
1. Result
approve
2. Summary of implementation
The implementation relocates the Task domain implementation out of tools and into pod::feature::builtin::task. The new Task feature module now owns the task store/domain types, task tool handlers, feature installation, and the existing reminder/snapshot/restore/rewind/compaction façade. The tools crate is reduced to the non-Task built-in tools and no longer exposes tools::TaskStore, tools::task_tools, or a builtin_tools(..., task_store, ...) API.
TUI task parsing remains local to tui and does not add a production dependency on either pod or tools; its tests use local snapshot JSON fixtures instead of importing the previous TaskStore type.
3. Requirement-by-requirement assessment
- Task domain ownership under
pod::feature::builtin::task: satisfied.TaskStore,TaskEntry,TaskStatus,TaskSnapshot, task tool implementations, reminder hook/state, and snapshot/restore/rewind/compaction methods are cohesive under the Pod built-in Task feature module. - No production Task APIs exposed from
tools: satisfied. Thetoolscrate no longer has the Task module/API surface andcore_builtin_tools()now installs only non-Task built-ins. - Non-Task
toolsbehavior remains intact: satisfied. The remaining tool modules, exports, and tests are conceptually unchanged apart from removing Task-specific test coverage fromtools. - Task tool names/schemas/descriptions/outputs unchanged: satisfied. The TaskCreate/TaskUpdate/TaskGet/TaskList definitions and handler response strings were moved without semantic changes.
- TaskStore replay/snapshot/restore and reminder behavior unchanged: satisfied. The store logic and TaskFeature façade preserve the previous append-history, snapshot, restore, rewind, overview, reminder, and compaction behavior.
- TUI task compatibility without undesirable dependency: satisfied.
tuikeeps its own typed compatibility reader and does not depend onpodortoolsin production. - Normal ToolRegistry / PreToolCall path unchanged: satisfied. Task tools are still registered through the built-in feature contribution path and continue through the existing Worker ToolRegistry / PreToolCall policy path.
- No broad unrelated architecture changes: satisfied. I did not find new crate-boundary/API extraction, plugin loading, authority-model, WorkItem/MCP, generic UI/event-channel, or broad refactor work in this diff.
package.nix/Cargo.lock: acceptable. TheCargo.lockchange follows from removing thetoolsdev-dependency fromtui; thecargoHashupdate is therefore expected. The conditionalfetchCargoVendorstatic-crates patch is not part of the Task-domain move, but it is a narrow and safe packaging guard around an existing static-crates workaround, andnix build .#yoi --no-linkpassed with it.- No
.yoi/workflowor old.insomniaworkflow changes included: satisfied. The diff has no changed files under those paths.
4. Blockers
None.
5. Non-blockers / follow-ups
crates/tui/src/task.rsstill has a stale comment referring totools::render_snapshot/tools::TaskStoreownership of the snapshot format. The code is fine, but the comment should be updated in a follow-up or before merge if the author is already revising the branch.- TUI compatibility tests now rely on local fixture JSON, which is appropriate for avoiding a production dependency, but it leaves some residual drift risk if the Pod-owned snapshot format changes without updating the fixture.
6. Validation assessed or rerun
Reviewed:
- Ticket, delegation intent, and decision artifact.
git diff develop...HEADfor the implementation branch.- Changed Task feature, tools, TUI, packaging, and lockfile files.
- Search results for remaining
tools::TaskStore,tools::task_tools, workflow, and.insomniachanges.
Reran from /home/hare/Projects/yoi/.worktree/task-domain-in-pod-feature:
cargo test -p pod task --libcargo test -p tools --libcargo test -p tools --testscargo test -p tui task --libcargo test -p pod --libcargo test -p llm-worker --libcargo check --workspace --all-targetscargo fmt --check./tickets.sh doctorgit diff --checknix build .#yoi --no-link
All rerun validation completed successfully.
7. Residual risk
The main residual risk is fixture drift in TUI task compatibility tests now that tui intentionally does not import the Pod-owned TaskStore type. That risk is acceptable for this ticket because the implementation preserves the existing serialized shape and avoids the undesirable production dependency.
Implementation report
Implementation report: task-domain-in-pod-feature
Worktree / branch
- Worktree:
/home/hare/Projects/yoi/.worktree/task-domain-in-pod-feature - Branch:
work/task-domain-in-pod-feature
Commits
5469335 refactor: move task feature into podc2ed71a docs: update tui task snapshot comments
Summary
Task domain state and Task tool implementations were moved out of the tools crate and into the Pod built-in Task feature module.
Final Task module layout:
crates/pod/src/feature/builtin/task/mod.rs- Task feature contribution, reminder hook/state, snapshot/restore/rewind/compaction façade.
crates/pod/src/feature/builtin/task/store.rsTaskStore,TaskEntry,TaskStatus,TaskSnapshot, replay/snapshot parsing/rendering.
crates/pod/src/feature/builtin/task/tool_impl.rsTaskCreate,TaskUpdate,TaskGet,TaskListtool implementations and localtask_toolsfactory.
tools now retains only non-Task core built-in tool plumbing. Production tools::TaskStore, tools::TaskEntry, tools::TaskStatus, tools::TaskSnapshot, tools::task_tools, and tools::builtin_tools(..., task_store, ...) were removed.
TUI task compatibility tests were changed to use local fixture JSON/text rather than depending on tools Task types. A follow-up cleanup commit updated stale comments in crates/tui/src/task.rs after review.
Changed files
Cargo.lockpackage.nixcrates/pod/src/feature/builtin/task/mod.rscrates/pod/src/feature/builtin/task/store.rscrates/pod/src/feature/builtin/task/tool_impl.rscrates/pod/src/ipc/interceptor.rscrates/tools/src/lib.rscrates/tools/src/tracker.rscrates/tools/tests/edge_cases.rscrates/tools/tests/integration.rscrates/tui/Cargo.tomlcrates/tui/src/task.rs
Evidence
Search for remaining production tools Task APIs in the implementation worktree returned no matches:
rg "tools::(TaskStore|TaskEntry|TaskStatus|TaskSnapshot|task_tools|task::)|tools::task" crates -g '*.rs'
The implementation diff includes no .yoi/workflow or old .insomnia workflow changes.
Validation
Coder-reported validation passed:
cargo test -p pod task --libcargo test -p tools --libcargo test -p tools --testscargo test -p tui task --libcargo test -p pod --libcargo test -p llm-worker --libcargo check --workspace --all-targetscargo fmt --check./tickets.sh doctorgit diff --checkgit diff --cached --checknix build .#yoi
Reviewer-rerun validation passed:
cargo test -p pod task --libcargo test -p tools --libcargo test -p tools --testscargo test -p tui task --libcargo test -p pod --libcargo test -p llm-worker --libcargo check --workspace --all-targetscargo fmt --check./tickets.sh doctorgit diff --checknix build .#yoi --no-link
Cleanup commit validation passed:
cargo test -p tui task --libcargo fmt --checkgit diff --check
Review status
External sibling reviewer approved with no blockers. The only code/comment follow-up was handled by commit c2ed71a.
Unresolved risks / follow-ups
The remaining residual risk is TUI fixture drift if the Pod-owned Task snapshot format changes without updating local TUI compatibility fixtures. This is accepted for this ticket because it avoids an undesirable production dependency from TUI back to Pod or tools.
Closed
Task domain consolidation into the Pod built-in Task feature is complete and merged.
Implementation commits:
5469335 refactor: move task feature into podc2ed71a docs: update tui task snapshot comments- merge commit on
develop: seemerge: move task domain into pod feature
Summary:
- Moved Task domain types and store into
pod::feature::builtin::task. - Moved Task tool implementations into the Pod Task feature module.
- Removed production Task APIs from
tools, includingtools::TaskStore, Task type re-exports,tools::task_tools, and Task-bearingbuiltin_tools(...). - Kept non-Task
tools::core_builtin_tools(...)and tracker/non-Task tool behavior intact. - Preserved Task tool schema/output behavior, Task snapshot/replay semantics, reminder hooks/state, and snapshot/restore/rewind/compaction façade.
- Updated TUI compatibility tests to use local fixtures without adding a production dependency on
podortools.
Review:
- External sibling reviewer approved with no blockers.
- Reviewer non-blocker about stale TUI comments was fixed before merge.
- Remaining accepted residual risk: local TUI fixtures can drift if Pod-owned Task snapshot format changes.
Post-merge validation passed on main workspace:
cargo test -p pod task --libcargo test -p tools --libcargo test -p tools --testscargo test -p tui task --libcargo fmt --checkgit diff --check./tickets.sh doctorcargo check --workspace --all-targets- search for remaining production
toolsTask APIs returned no matches