Hare/yoi
1
1
Fork 0
Code Actions Packages Releases Activity
develop
yoi/.yoi/tickets/00001KTAM0TAS/item.md

4.5 KiB
Raw Permalink Blame History

title state created_at updated_at
Task: move TaskStore and reminders into Task feature closed 2026-06-05T00:48:07Z 2026-06-05T02:24:23Z

Issue

TaskCreate / TaskUpdate / TaskGet / TaskList have been extracted into a built-in internal feature module, but Task state is still Pod-owned. Pod owns TaskStore, PodInterceptor owns TaskReminderState, and PodInterceptor::pending_history_appends() contains Task-specific reminder logic.

For the feature/module boundary to be meaningful, Task-specific state and behavior should live in the Task feature module. Pod should provide generic host surfaces: tool registration, hook dispatch, and durable SystemItem append. Pod should not know about TaskStore or Task reminder rules.

Current findings

  • crates/pod/src/feature/builtin/task.rs currently constructs the Task tool feature with a host-provided tools::TaskStore.
  • crates/pod/src/pod.rs still stores task_store: tools::TaskStore and task_reminder_state: Arc<TaskReminderState>.
  • crates/pod/src/ipc/interceptor.rs still stores TaskStore and TaskReminderState, detects task-management tool calls, and emits SystemItem::TaskReminder from pending_history_appends().
  • crates/pod/src/pod.rs also uses TaskStore snapshots for session restore/compaction/reminder context. Those uses must be audited before removing Pod ownership.
  • TUI-facing Task visibility is intentionally out of scope here; if TUI needs a compatibility/status surface, create a follow-up instead of keeping Task ownership in Pod.

Direction

Move TaskStore and Task reminder state into the Task feature module after hook-context-system-item-sink provides a host-mediated SystemItem append handle for Hook contexts.

Target shape:

  • TaskFeature owns:
    • tools::TaskStore
    • Task reminder/cooldown state
    • Task tool contribution construction
    • hooks that track Task tool usage and decide when to emit reminders
  • Pod owns:
    • feature registry
    • Hook dispatch
    • ToolRegistry integration
    • durable SystemItem append/commit authority
    • generic history/session machinery
  • Pod does not own or special-case TaskStore / TaskReminderState.

Requirements

  • Depend on or first implement hook-context-system-item-sink.
  • Move TaskStore construction/ownership from Pod into the built-in Task feature module.
    • Preserve session restore behavior by giving Task feature whatever history snapshot or restore input it needs, rather than keeping TaskStore in Pod.
    • Preserve one session-lifetime TaskStore shared by all Task tools and reminder hooks.
  • Move TaskReminderState and reminder decision logic out of PodInterceptor and into Task feature-owned hooks.
    • A tool hook records Task tool usage.
    • A PreLlmRequest hook evaluates inactivity/cooldown and appends SystemItem::TaskReminder through the host-provided SystemItem append handle.
  • Remove Task-specific checks from PodInterceptor such as direct is_task_management_tool handling for reminder state.
  • Preserve current observable behavior:
    • Task tool names/schemas/descriptions/outputs;
    • TaskStore snapshot/restore semantics;
    • task reminder threshold/cooldown/body/source behavior;
    • model-visible history path via LogEntry::SystemItem / Event::SystemItem;
    • normal ToolRegistry / PreToolCall permission path.
  • Audit compaction/session snapshot code that currently reads self.task_store.
    • Either route this through a Task feature status/snapshot service, or leave a documented temporary compatibility façade with no Task ownership in Pod.
    • Do not silently drop TaskStore snapshot/resume behavior.
  • Keep external-plugin authority model out of this ticket except insofar as the Hook SystemItem append handle is used by a trusted built-in module.

Non-goals

  • TUI UI changes.
  • External plugin loading or package approval.
  • Generic event channels or dialogs.
  • Changing Task tool behavior or adding/removing Task tools.
  • Reworking Memory/WorkItem/Pod-management modules.

Acceptance criteria

  • Task feature module owns TaskStore and Task reminder state.
  • Pod and PodInterceptor no longer contain Task-specific store/reminder state or task-tool special-casing.
  • Task reminder emission is implemented as Task feature Hook logic using host-mediated SystemItem append, not raw Item injection.
  • TaskStore snapshot/restore/compaction behavior is preserved or explicitly routed through a new feature-owned status/snapshot surface.
  • Existing Task tool and Task reminder tests are moved/updated and pass.
  • Workspace validation passes.