task: plan task domain move into pod
This commit is contained in:
parent
6cc2e9ade7
commit
5de4156147
|
|
@ -0,0 +1,15 @@
|
|||
# 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.
|
||||
|
|
@ -0,0 +1,103 @@
|
|||
# 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
|
||||
|
|
@ -0,0 +1,79 @@
|
|||
---
|
||||
id: 20260605-025100-task-domain-in-pod-feature
|
||||
slug: task-domain-in-pod-feature
|
||||
title: Task: move Task domain out of tools into pod built-in feature
|
||||
status: open
|
||||
kind: task
|
||||
priority: P1
|
||||
labels: [tasks, feature-registry, crate-boundary, tools]
|
||||
created_at: 2026-06-05T02:51:00Z
|
||||
updated_at: 2026-06-05T02:53:16Z
|
||||
assignee: null
|
||||
legacy_ticket: null
|
||||
---
|
||||
|
||||
## 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.
|
||||
|
|
@ -0,0 +1,141 @@
|
|||
<!-- event: create author: tickets.sh at: 2026-06-05T02:51:00Z -->
|
||||
|
||||
## Created
|
||||
|
||||
Created by tickets.sh create.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: decision author: hare at: 2026-06-05T02:53:15Z -->
|
||||
|
||||
## 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.
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- event: plan author: hare at: 2026-06-05T02:53:16Z -->
|
||||
|
||||
## 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
|
||||
|
||||
|
||||
---
|
||||
Loading…
Reference in New Issue
Block a user