Hare/yoi
1
1
Fork 0
Code Actions Packages Releases Activity
bab30952b8
yoi/work-items/open/20260605-025100-task-domain-in-pod-feature/thread.md

10 KiB
Raw Blame History

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::hook are still defined in the pod crate.
  • Creating builtin-features now would either depend on pod or require premature extraction of a feature-api crate.
  • Feature-per-crate would create too many crates; a future builtin-features crate may be appropriate only after the API boundary is stable.
  • Moving Task domain state out of tools and into pod::feature::builtin::task fixes the immediate semantic split without forcing crate-boundary churn.

Desired result for this ticket:

  • tools provides low-level generic tool helpers.
  • pod::feature::builtin::task owns 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.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

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. The tools crate no longer has the Task module/API surface and core_builtin_tools() now installs only non-Task built-ins.
  • Non-Task tools behavior remains intact: satisfied. The remaining tool modules, exports, and tests are conceptually unchanged apart from removing Task-specific test coverage from tools.
  • 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. tui keeps its own typed compatibility reader and does not depend on pod or tools in 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. The Cargo.lock change follows from removing the tools dev-dependency from tui; the cargoHash update is therefore expected. The conditional fetchCargoVendor static-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, and nix build .#yoi --no-link passed with it.
  • No .yoi/workflow or old .insomnia workflow changes included: satisfied. The diff has no changed files under those paths.

4. Blockers

None.

5. Non-blockers / follow-ups

  • crates/tui/src/task.rs still has a stale comment referring to tools::render_snapshot / tools::TaskStore ownership 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...HEAD for the implementation branch.
  • Changed Task feature, tools, TUI, packaging, and lockfile files.
  • Search results for remaining tools::TaskStore, tools::task_tools, workflow, and .insomnia changes.

Reran from /home/hare/Projects/yoi/.worktree/task-domain-in-pod-feature:

  • cargo test -p pod task --lib
  • cargo test -p tools --lib
  • cargo test -p tools --tests
  • cargo test -p tui task --lib
  • 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
  • nix 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.