yoi/work-items/open/20260605-040104-ticket-built-in-feature-tools/thread.md

Created

Created by tickets.sh create.

---

Decision

Decision: keep Ticket tool behavior mostly in the ticket crate and use pod only as a thin built-in feature adapter.

Rationale:

• ticket should own the Ticket domain/backend and the behavior of Ticket operations.
• pod::feature is still owned by the pod crate, so feature installation/authority wiring cannot be fully crate-contained without extracting a lower feature-api crate.
• Extracting feature-api is explicitly out of scope for this ticket.
• Putting Ticket tools in crates/tools would repeat the Task tool responsibility problem.

Dependency shape:

ticket -> llm-worker   # Tool/ToolDefinition implementation only
pod -> ticket          # built-in feature adapter and backend-root wiring

Forbidden:

ticket -> pod

Implementation direction:

• crates/ticket may add Ticket tool input/output types and Tool implementations.
• crates/pod/src/feature/builtin/ticket.* should only install/register those tools through FeatureContribution and resolve host/backend authority.
• Ticket tools must operate through typed TicketBackend/LocalTicketBackend, not through tickets.sh or generic filesystem writes.

---

Plan

Preflight result: implementation-ready.

Prerequisites are complete:

• ticket-local-files-backend added the typed Ticket backend and LocalTicketBackend.
• feature-api-authority-separation clarified host-authority naming in pod::feature.

Scope for implementation:

• Add the MVP Ticket tool surface: create/list/show/comment/review/status/close/doctor.
• Keep Ticket tool behavior in crates/ticket and use a thin pod adapter for built-in feature registration and backend-root/authority wiring.
• Do not implement Intake workflow, Orchestrator routing, TUI changes, external trackers, MCP/plugin loading, scheduler/lease behavior, or work-items/ rename.

Detailed delegation intent is recorded in artifacts/delegation-intent.md.

---