ticket: split ticket lifecycle feature

2026-06-07 12:35:57 +09:00
parent 24d6a62a54
commit c57d13e61b
5 changed files with 96 additions and 1 deletions
@@ -8,7 +8,7 @@ priority: P1
 labels: [panel, orchestrator, ticket, automation, workflow]
 workflow_state: intake
 created_at: 2026-06-07T02:02:15Z
-updated_at: 2026-06-07T02:35:20Z
+updated_at: 2026-06-07T03:35:44Z
 assignee: null
 legacy_ticket: null
 ---
@@ -27,3 +27,21 @@ Ordering invariant:
 Short-term implementation may enforce this through Orchestrator workflow/prompt text plus the existing typed workflow-state tool. Longer-term, prefer a typed Orchestrator operation such as `AcceptQueuedTicket` / `StartTicketWork` that validates `queued`, records the acceptance transition, establishes any local claim/lease, and only then allows worktree/Pod launch.

 ---
+
+<!-- event: decision author: hare at: 2026-06-07T03:35:44Z -->
+
+## Decision
+
+## Split: Ticket lifecycle domain feature
+
+Created `ticket-lifecycle-pod-feature` to pull the domain tool/feature part out of Orchestrator automation.
+
+Decision:
+- Ticket lifecycle should be implemented as a Ticket-domain `pod::feature`, not an Orchestrator feature.
+- Features represent domain capabilities; roles/profiles decide which subset/authority they receive.
+- Orchestrator automation should consume the Ticket lifecycle feature for queued Ticket inspection and lifecycle transitions.
+- Companion/Intake/coder/reviewer may receive different Ticket feature subsets according to their policies.
+
+This keeps `workspace-panel-orchestrator-queue-automation` focused on routing behavior, queued notification handling, acceptance sequencing, and worktree/Pod orchestration rather than basic Ticket tool registration.
+
+---