yoi/.yoi/tickets/closed/20260607-033536-ticket-lifecycle-pod-feature/item.md

id	slug	title	status	kind	priority	labels	workflow_state	created_at	updated_at	assignee	legacy_ticket
20260607-033536-ticket-lifecycle-pod-feature	ticket-lifecycle-pod-feature	Ticket lifecycle pod feature	closed	task	P1	ticket pod-feature tools orchestration workflow	done	2026-06-07T03:35:36Z	2026-06-07T04:03:33Z	null	null

Background

Panel/Orchestrator queue automation needs Ticket lifecycle operations to be available to Pods through the feature/tool system. This should not be modeled as an "Orchestrator feature": features should represent domain capabilities, not roles. Orchestrator, Intake, Companion, coder, and reviewer profiles may each be granted different subsets of the Ticket domain capability by policy/profile configuration.

The immediate motivation is queued Ticket handling: when a Ticket enters workflow_state = queued, the Orchestrator should be able to inspect Ticket state, record decisions/progress/blockers, and transition lifecycle state according to the Ticket workflow contract before starting worktree/Pod side effects. Prompt instructions are acceptable for sequencing initially; the first step is to make the Ticket lifecycle capability a proper pod::feature domain feature.

Goal

Implement a pod::feature-based Ticket lifecycle domain feature that registers typed Ticket lifecycle tools for Pods, without making the feature role-specific.

Domain model

• Feature identity should be Ticket-domain oriented, e.g. ticket_lifecycle / ticket rather than orchestrator.
• Role/profile policy decides which tools or permission level a Pod receives.
• Orchestrator may receive mutating lifecycle tools.
• Companion should receive read/status-only Ticket tools by default.
• Intake may receive create/update/intake-ready tools needed to materialize Tickets.
• Coder/reviewer may receive report/review/comment tools as appropriate.

Requirements

• Add or extend a pod::feature module for Ticket lifecycle/tool registration.
• Register typed Ticket tools through the feature system rather than ad-hoc role-specific wiring.
• Cover at least the lifecycle operations needed by Panel/Orchestrator automation:
  • Ticket list/show read access;
  • append comment/decision/implementation report events;
  • append review events where granted;
  • intake -> ready intake-ready operation where granted;
  • queued -> inprogress and inprogress -> done workflow-state transitions where granted;
  • close Ticket where granted.
• Keep transition enforcement in the Ticket backend/tool implementation, not only in prompts.
• Do not make this an Orchestrator-only feature. The same domain feature must be grantable with different permissions to different role profiles.
• Provide a clear policy/config surface for read-only vs mutating Ticket lifecycle access, or use the existing feature/tool permission machinery if it already supports this distinction.
• Ensure tool descriptions/prompts communicate the sequencing contract:
  • queued Ticket implementation side effects should occur only after queued -> inprogress acceptance;
  • prompt sequencing is acceptable initially, but tool behavior must still enforce valid workflow transitions.
• Preserve current typed Ticket backend invariants and doctor validation.
• Keep local Pod/session assignment out of git-tracked Ticket metadata; use the existing local role session registry for local runtime association when needed.

Non-goals

• Implementing full Orchestrator queue automation in this ticket.
• Implementing workflow state-machine-based dynamic tool gating.
• Replacing prompt/workflow sequencing with a complete operation-state enforcement runtime.
• Making StartTicketWork / AcceptQueuedTicket a composite tool unless it naturally falls out as a small wrapper; composite orchestration can remain a follow-up.
• Adding Companion Bash or broad workspace mutation authority.

Acceptance criteria

• Ticket lifecycle tools are contributed through a Ticket-domain pod::feature.
• The feature can be granted to different roles/profiles with different authority levels; it is not hard-coded as an Orchestrator feature.
• Orchestrator-capable profiles can receive the Ticket lifecycle tools needed to inspect queued Tickets and perform queued -> inprogress / inprogress -> done transitions.
• Read-only/status roles can receive Ticket read tools without mutating lifecycle authority.
• Existing Ticket transition constraints remain enforced by typed backend/tool paths.
• Tests cover feature registration and at least one read-only vs mutating permission/grant distinction, or document why the existing feature permission tests already cover it.