63 lines
4.4 KiB
Markdown
63 lines
4.4 KiB
Markdown
---
|
|
title: "Ticket lifecycle pod feature"
|
|
state: "closed"
|
|
created_at: "2026-06-07T03:35:36Z"
|
|
updated_at: "2026-06-07T04:03:33Z"
|
|
---
|
|
|
|
## 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.
|