10 KiB
Created
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-scaffoldis expected to touchcrates/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.rsis 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.rswith feature idbuiltin:ticket. - It currently declares/registers all
ticket::tool::TICKET_TOOL_NAMESthrough the feature registry and requiresHostAuthority::TicketBackend. ticket::tool::TICKET_TOOL_NAMESalready includes lifecycle tools such asTicketIntakeReadyandTicketWorkflowState.- 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/TicketToolSetenum or builder with at least:- read-only/status:
TicketList,TicketShow, maybeTicketDoctorif considered read-only diagnostic; - lifecycle/mutating: comment/review/intake-ready/workflow-state/status/close/create according to the existing tool set.
- read-only/status:
- 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
TicketWorkflowStateshould communicate the queued acceptance sequencing contract: implementation side effects should happen only afterqueued -> inprogressacceptance. - Preserve existing
builtin:ticketbehavior 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/AcceptQueuedTicketunless 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::ticketand/orticket::tool. - Run at minimum
cargo test -p pod ticket --liband relevantcargo test -p ticket tool --libif ticket tool partitions are added. - Run
cargo fmt --checkandgit diff --check; broadercargo check --workspace --all-targetsif 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.
Implementation report
Delegation
Implementation delegated to child Pod ticket-lifecycle-feature-coder-20260607 in worktree .worktree/ticket-lifecycle-pod-feature on branch work/ticket-lifecycle-pod-feature.
Scope:
- Refine the existing built-in Ticket-domain feature (
builtin:ticket) rather than creating an Orchestrator-specific feature. - Add explicit read-only/status vs mutating/lifecycle tool subset support.
- Keep Ticket transition enforcement in typed backend/tool paths.
- Do not implement full Orchestrator automation or composite
StartTicketWorkin this ticket.
Parallel note:
- This is running alongside
ticket-init-role-profile-scaffold; expected code overlap is low. The child was instructed to keep changes localized and report any conflict risk.
The child should commit implementation work in the child worktree and report diff/tests. Merge, review, Ticket closure, and cleanup remain with the parent/human workflow.
Implementation report
Implementation report
Coder Pod ticket-lifecycle-feature-coder-20260607 completed implementation in .worktree/ticket-lifecycle-pod-feature.
Commit:
3d662bc pod: split ticket feature access levels
Reported summary:
- Added
TicketFeatureAccess::{ReadOnly, Lifecycle}forbuiltin:ticket. - Preserved default full lifecycle behavior for
ticket_tools_feature(...). - Added
ticket_tools_feature_with_access(...)and constructors/accessors for explicit access selection. - Feature descriptors declare only tools allowed by the configured access level.
- Feature installation registers only the configured subset.
- Added Ticket tool name partitions:
TICKET_READ_ONLY_TOOL_NAMES:TicketList,TicketShow,TicketDoctor;TICKET_MUTATING_TOOL_NAMES: create/comment/review/intake-ready/workflow-state/status/close.
- Updated
TicketWorkflowStatetool description with thequeued -> inprogressacceptance contract. - Added tests proving read-only install excludes mutating tools and lifecycle install exposes lifecycle tools.
Reported validation:
cargo test -p pod ticket --libcargo test -p ticket tool --libcargo fmt --checkgit diff --checkcargo check --workspace --all-targetsnix build .#yoi
Reported follow-up:
- Call sites still use the default full lifecycle access. Companion/status-specific callers can opt into read-only access once integration points are selected.
- Host authority remains
HostAuthority::TicketBackend; read-only boundary is enforced by subset exposure rather than a separate read-only backend authority.
External review will be delegated before merge.
Review: approve
Approved.
Evidence reviewed:
- Feature identity remains Ticket-domain (
builtin:ticket), not Orchestrator-specific. TicketFeatureAccess::ReadOnlymaps only to read/status tools (TicketList,TicketShow,TicketDoctor).- Feature descriptor and installation register only the tools allowed by the selected access level.
- Lifecycle/default access preserves existing full Ticket tool behavior.
- Tests cover read-only descriptor/install and lifecycle install behavior.
TicketWorkflowStateToolstill delegates to backend workflow-state enforcement; allowed transitions remain enforced by typed Ticket backend/tool paths.- Updated queued acceptance wording is guidance only, not a replacement for backend transition validation.
- Keeping
HostAuthority::TicketBackendfor read-only access is acceptable for this ticket because the boundary here is model-visible tool exposure, not a separate storage-level read-only backend authority.
Reviewer validation:
cargo test -p pod ticket --libcargo test -p ticket tool --libcargo fmt --checkgit diff --checkcargo check --workspace --all-targetsnix build .#yoigit merge-tree --write-tree develop HEAD
Merge readiness:
- Worktree clean.
- Branch contains implementation commit
3d662bc pod: split ticket feature access levels. - Merge-tree against current
developis clean. - No requested changes.
State changed
Ticket closed; workflow_state set to done.
Closed
Implemented, reviewed, merged, and validated.
Summary:
- Refined the existing Ticket-domain
builtin:ticketfeature rather than introducing an Orchestrator-specific feature. - Added
TicketFeatureAccess::{ReadOnly, Lifecycle}. - Added explicit Ticket tool partitions:
- read-only/status tools:
TicketList,TicketShow,TicketDoctor; - mutating/lifecycle tools: create/comment/review/intake-ready/workflow-state/status/close.
- read-only/status tools:
- Feature descriptors and installation now expose only the tools allowed by the configured access level.
- Preserved the existing full lifecycle/default behavior for existing call sites.
- Updated
TicketWorkflowStatetool description with the queued acceptance sequencing contract. - Preserved typed backend/tool transition enforcement.
Implementation:
- Child commit:
3d662bc pod: split ticket feature access levels - Merge commit:
merge: ticket lifecycle feature
Review:
- External reviewer
ticket-lifecycle-feature-reviewer-20260607approved with no blockers.
Validation after merge:
cargo test -p pod ticket --libcargo test -p ticket tool --libcargo fmt --checkgit diff --checkcargo check --workspace --all-targets