From 43f273de03c9f0322b31b08d8c34094b5d422f21 Mon Sep 17 00:00:00 2001 From: Hare Date: Sun, 7 Jun 2026 12:48:02 +0900 Subject: [PATCH] ticket: preflight ticket lifecycle feature --- .../item.md | 4 +- .../thread.md | 66 +++++++++++++++++++ 2 files changed, 68 insertions(+), 2 deletions(-) diff --git a/.yoi/tickets/open/20260607-033536-ticket-lifecycle-pod-feature/item.md b/.yoi/tickets/open/20260607-033536-ticket-lifecycle-pod-feature/item.md index 508de93c..b611fdec 100644 --- a/.yoi/tickets/open/20260607-033536-ticket-lifecycle-pod-feature/item.md +++ b/.yoi/tickets/open/20260607-033536-ticket-lifecycle-pod-feature/item.md @@ -6,9 +6,9 @@ status: open kind: task priority: P1 labels: [ticket, pod-feature, tools, orchestration, workflow] -workflow_state: intake +workflow_state: ready created_at: 2026-06-07T03:35:36Z -updated_at: 2026-06-07T03:35:36Z +updated_at: 2026-06-07T03:47:55Z assignee: null legacy_ticket: null --- diff --git a/.yoi/tickets/open/20260607-033536-ticket-lifecycle-pod-feature/thread.md b/.yoi/tickets/open/20260607-033536-ticket-lifecycle-pod-feature/thread.md index 2c81c8fd..b563b082 100644 --- a/.yoi/tickets/open/20260607-033536-ticket-lifecycle-pod-feature/thread.md +++ b/.yoi/tickets/open/20260607-033536-ticket-lifecycle-pod-feature/thread.md @@ -4,4 +4,70 @@ Created by LocalTicketBackend create. +--- + + + +## Plan + +## Preflight / implementation intent + +Classification: implementation-ready and safe to run in parallel with `ticket-init-role-profile-scaffold`. + +Parallelism note: +- `ticket-init-role-profile-scaffold` is expected to touch `crates/yoi/src/ticket_cli.rs`, `crates/ticket/src/config.rs`, and maybe role-launch tests. +- This ticket should primarily touch `crates/pod/src/feature/builtin/ticket.rs`, `crates/ticket/src/tool.rs`, feature registration tests, and possibly role/profile integration tests. +- Coordinate carefully if `ticket/src/config.rs` is touched, but the expected overlap is low. + +Current code map / discovery: +- A built-in Ticket feature already exists at `crates/pod/src/feature/builtin/ticket.rs` with feature id `builtin:ticket`. +- It currently declares/registers all `ticket::tool::TICKET_TOOL_NAMES` through the feature registry and requires `HostAuthority::TicketBackend`. +- `ticket::tool::TICKET_TOOL_NAMES` already includes lifecycle tools such as `TicketIntakeReady` and `TicketWorkflowState`. +- The missing piece is not creating Ticket tools from nothing; it is shaping this existing Ticket-domain feature into an explicit lifecycle capability with authority subsets/grants suitable for roles such as read-only Companion vs mutating Orchestrator/Intake/coder/reviewer. + +Intent: +- Keep this as a Ticket-domain feature, not an Orchestrator feature. +- Extend/refine the existing built-in Ticket feature so it can expose read-only vs mutating/lifecycle tool subsets according to profile/policy/grant selection. +- Preserve backend/tool transition enforcement; prompts can specify sequencing, but invalid workflow transitions must still fail in typed Ticket backend/tool paths. + +Requirements for first implementation: +- Do not duplicate Ticket tools outside the feature system. +- Do not create an Orchestrator-specific feature id. +- Provide a clear API/config surface for Ticket feature authority level or tool subset. Suggested initial shape: a `TicketFeatureAccess` / `TicketToolSet` enum or builder with at least: + - read-only/status: `TicketList`, `TicketShow`, maybe `TicketDoctor` if considered read-only diagnostic; + - lifecycle/mutating: comment/review/intake-ready/workflow-state/status/close/create according to the existing tool set. +- Feature descriptor should declare only tools that the configured feature instance may register, and installation should register only that subset. +- Tests should prove read-only installation does not expose mutating tools, while lifecycle/mutating installation exposes the needed lifecycle tools. +- Tool descriptions for `TicketWorkflowState` should communicate the queued acceptance sequencing contract: implementation side effects should happen only after `queued -> inprogress` acceptance. +- Preserve existing `builtin:ticket` behavior where needed, or provide an intentional default that does not silently grant broad mutation to roles that should be read-only. If compatibility choices are ambiguous, prefer a small explicit API and report the integration follow-up. + +Non-goals: +- Do not implement full Orchestrator queue automation. +- Do not implement workflow state-machine dynamic tool gating. +- Do not implement `StartTicketWork` / `AcceptQueuedTicket` unless it is a trivial wrapper; it is acceptable to leave composite orchestration as follow-up. +- Do not add Companion Bash or broad write authority. +- Do not alter local role session registry semantics. + +Validation: +- Add/update focused tests in `pod::feature::builtin::ticket` and/or `ticket::tool`. +- Run at minimum `cargo test -p pod ticket --lib` and relevant `cargo test -p ticket tool --lib` if ticket tool partitions are added. +- Run `cargo fmt --check` and `git diff --check`; broader `cargo check --workspace --all-targets` if feature API surfaces change broadly. + +--- + + + +## Intake summary + +Implementation-ready: refine the existing built-in Ticket-domain feature (`builtin:ticket`) into a lifecycle capability with explicit read-only vs mutating/lifecycle tool subsets. This can run in parallel with ticket init scaffold because expected code overlap is low. + +--- + + + +## State changed + +Ticket intake complete; workflow_state intake -> ready. + + ---