ticket: use base32 project record ids
This commit is contained in:
@@ -0,0 +1,84 @@
|
||||
---
|
||||
title: "Workspace panel Orchestrator queue automation"
|
||||
state: "closed"
|
||||
created_at: "2026-06-07T02:02:15Z"
|
||||
updated_at: "2026-06-09T04:44:35Z"
|
||||
---
|
||||
|
||||
## Background
|
||||
|
||||
The panel currently has pieces of the Ticket orchestration path:
|
||||
|
||||
- Panel Ticket Intake can start an Intake role Pod from a user instruction.
|
||||
- Intake can materialize or update a Ticket and mark it `workflow_state = ready`.
|
||||
- Panel can Queue a ready Ticket, transitioning `ready -> queued` and notifying the workspace Orchestrator.
|
||||
|
||||
However, the intended semantics of `queued` are stronger than a passive notification. Once a human queues a Ticket, the Orchestrator should treat it as eligible for routing and proceed if the workspace state allows it. The Orchestrator, not the panel, should decide whether work can start now or should wait because of conflicts, dependencies, capacity, or planning/readiness gaps.
|
||||
|
||||
The current route is not yet a complete automated path from Panel/Intake through Orchestrator-managed implementation, review, merge, and Ticket completion.
|
||||
|
||||
## Goal
|
||||
|
||||
Implement a first-class Panel -> Intake/Queue -> Orchestrator automation path where queued Tickets are actively routed by the Orchestrator and, when unblocked, progressed through implementation/review/merge/close workflow.
|
||||
|
||||
## Target semantics
|
||||
|
||||
- `ready`: Ticket is materialized and can be queued by the human.
|
||||
- `queued`: Human has authorized Orchestrator routing. The Orchestrator should inspect current state and start work if unblocked.
|
||||
- `inprogress`: Orchestrator has accepted the Ticket as its durable responsibility marker and owns routing/coordination until completion, explicit defer, or explicit block. It does not merely mean that a coder Pod is already running.
|
||||
- `done`: Implementation/review/merge outcome is complete and the Ticket can be closed or has been closed.
|
||||
|
||||
## Orchestrator acceptance contract
|
||||
|
||||
- `inprogress` is the durable Orchestrator acceptance marker for a queued Ticket.
|
||||
- Orchestrator must inspect the Ticket and current workspace state before accepting queued work.
|
||||
- Orchestrator must transition `queued -> inprogress` before creating implementation worktrees or spawning implementation/review Pods, unless a typed operation performs the acceptance and side-effect setup atomically.
|
||||
- If `queued -> inprogress` fails, Orchestrator must not spawn implementation/review Pods for that Ticket.
|
||||
- After `inprogress` acceptance, worktree/spawn/first-run failures should be recorded as progress/block/failure on the in-progress Ticket rather than silently reverting to queued or starting a duplicate route.
|
||||
- The short-term implementation may enforce this through Orchestrator prompt/workflow text plus the existing typed Ticket workflow-state tool.
|
||||
- The long-term target is a typed Orchestrator operation such as `AcceptQueuedTicket` or `StartTicketWork` that validates the queued state, records acceptance, establishes any local claim/lease, and returns the bounded context needed for worktree/Pod launch.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Update the panel Queue notification/prompt text so it clearly tells the Orchestrator to route the queued Ticket and start if unblocked, rather than implying that implementation must not start.
|
||||
- Add Orchestrator-side handling for queued Tickets:
|
||||
- read the Ticket and current workflow state;
|
||||
- inspect active worktrees/branches/Pods and queued/inprogress Tickets where available;
|
||||
- decide whether there are conflicts, dependency blockers, planning/readiness gaps, or capacity constraints;
|
||||
- if unblocked, transition `queued -> inprogress` using the typed Ticket workflow tool/path before implementation side effects;
|
||||
- if blocked, record a concise reason and leave the Ticket queued or defer through the existing Ticket status/state mechanism as appropriate.
|
||||
- Ensure Orchestrator cannot create implementation worktrees or spawn implementation/review Pods for a queued Ticket until the Ticket is already accepted as `inprogress` or the same typed operation atomically accepts it.
|
||||
- Add or design toward a typed accept/start operation for Orchestrator routing so the `queued -> inprogress` acceptance contract is not only prompt-enforced.
|
||||
- Connect Orchestrator routing to the existing Ticket workflows:
|
||||
- the planning/requirements-sync workflow when requirements/design readiness are uncertain;
|
||||
- `worktree-workflow` for worktree creation/management;
|
||||
- `multi-agent-workflow` or equivalent sibling coder/reviewer routing for implementation and review.
|
||||
- Ensure Orchestrator can spawn or coordinate implementation/review Pods only after the queued Ticket has been accepted as in progress and scope/worktree boundaries are clear.
|
||||
- Carry enough run/assignment state for the panel to show that a queued Ticket has been accepted or is blocked/waiting.
|
||||
- Define the merge/completion boundary explicitly:
|
||||
- for local dogfooding, Orchestrator may proceed through merge/cleanup when the queued workflow and current policy authorize it;
|
||||
- otherwise it must stop at a merge-ready dossier with a clear human action required.
|
||||
- After successful merge/validation, record implementation/report/review events and close or mark the Ticket done according to the typed Ticket workflow state rules.
|
||||
- Preserve the human Queue gate: newly ready Tickets must not be automatically started without being queued.
|
||||
- Preserve no-polling semantics for Intake creation; the automation begins from explicit Queue or explicit Orchestrator action, not background file polling.
|
||||
- Coordinate with `workspace-panel-local-role-session-registry` if local role/session assignment is needed to prevent duplicate Orchestrator/coder/reviewer ownership.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- Making the panel itself a scheduler.
|
||||
- Starting implementation directly from Intake before the Ticket reaches `ready` and is queued.
|
||||
- Ignoring conflicts with existing active worktrees, branches, or in-progress Tickets.
|
||||
- Blindly spawning coder Pods from a notification without reading the Ticket and current workspace state.
|
||||
- Replacing the existing Ticket workflow documents; this ticket should wire them into the Orchestrator route.
|
||||
- Reintroducing direct selected-Pod send from the panel.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Queue notification/prompt semantics say that Orchestrator should route and start if unblocked.
|
||||
- A queued Ticket can be accepted by the Orchestrator, moved to `inprogress`, and routed to implementation through existing worktree/coder/reviewer workflows.
|
||||
- Implementation/review Pod spawning is prevented for a queued Ticket unless the Ticket has already been accepted as `inprogress` or a typed accept/start operation performs that transition atomically.
|
||||
- If acceptance fails, no implementation side effects occur; if post-acceptance side effects fail, the failure/block is recorded on the in-progress Ticket.
|
||||
- Blocking conditions are recorded instead of silently doing nothing.
|
||||
- The panel can distinguish at least queued-waiting, in-progress, and blocked/deferred outcomes from Orchestrator routing.
|
||||
- The path from Panel Intake -> ready Ticket -> Queue -> Orchestrator routing is documented and covered by focused tests or integration-style unit tests around the routing logic.
|
||||
- The merge/completion boundary is explicit and validated against current policy before automatic merge/close is allowed.
|
||||
@@ -0,0 +1,13 @@
|
||||
Closed as an obsolete umbrella/progress-container Ticket.
|
||||
|
||||
This Ticket's original role was to collect the broad Panel Queue -> Orchestrator automation effort. That umbrella pattern is now deprecated: concrete work should live in implementable Tickets, medium-term context should live in Objectives, and Ticket relations should remain non-hierarchical.
|
||||
|
||||
The concrete slices recorded in this Ticket thread were split out and handled separately:
|
||||
|
||||
- `orchestrator-queued-ticket-routing`
|
||||
- `orchestrator-worktree-agent-routing`
|
||||
- `orchestrator-merge-completion`
|
||||
|
||||
Remaining or follow-up concerns are tracked by concrete Tickets/Objectives instead of this umbrella, including active queued-work planning/re-kick, non-hierarchical Ticket relations, Objective records, and umbrella deprecation work.
|
||||
|
||||
This close does not assert that every future Panel Queue -> Orchestrator concern is complete; it retires this Ticket as a broad container.
|
||||
@@ -0,0 +1,137 @@
|
||||
<!-- event: create author: LocalTicketBackend at: 2026-06-07T02:02:15Z -->
|
||||
|
||||
## Created
|
||||
|
||||
Created by LocalTicketBackend create.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: decision author: hare at: 2026-06-07T02:35:20Z -->
|
||||
|
||||
## Decision
|
||||
|
||||
## In-progress acceptance contract
|
||||
|
||||
`workflow_state = inprogress` should be the durable Orchestrator acceptance marker, not merely proof that a coder Pod is already running.
|
||||
|
||||
Contract:
|
||||
- `ready`: materialized Ticket waiting for the human Queue gate.
|
||||
- `queued`: human has authorized Orchestrator routing; Orchestrator should inspect Ticket/workspace state and start if unblocked.
|
||||
- `inprogress`: Orchestrator has accepted the queued Ticket and owns coordination/progress/block/failure reporting until completion or explicit defer/block.
|
||||
|
||||
Ordering invariant:
|
||||
- Orchestrator must not create implementation worktrees or spawn implementation/review Pods for a queued Ticket unless the Ticket has already been accepted as `inprogress`, or the same typed operation atomically accepts it.
|
||||
- If `queued -> inprogress` fails, do not spawn implementation Pods.
|
||||
- If side effects fail after `inprogress` acceptance, record the failure/block under the in-progress Ticket rather than silently returning to queued or starting a duplicate path.
|
||||
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: decision author: hare at: 2026-06-07T03:56:37Z -->
|
||||
|
||||
## Decision
|
||||
|
||||
## Split into routing / agent execution / merge completion
|
||||
|
||||
Split the Orchestrator automation work into three child tickets so the implementation can proceed in bounded slices while preserving the existing `worktree-workflow` and `multi-agent-workflow` contracts.
|
||||
|
||||
Child tickets:
|
||||
|
||||
1. `orchestrator-queued-ticket-routing`
|
||||
- Panel Queue notification and Orchestrator routing entrypoint.
|
||||
- `queued -> inprogress` acceptance before implementation side effects.
|
||||
- First-pass blocker/dependency/conflict recording.
|
||||
|
||||
2. `orchestrator-worktree-agent-routing`
|
||||
- Use `worktree-workflow` and `multi-agent-workflow` as builtin/role guidance for accepted in-progress Tickets.
|
||||
- Create child worktree, spawn coder/reviewer sibling Pods with correct scopes, run review/fix loop, and produce merge-ready dossier.
|
||||
|
||||
3. `orchestrator-merge-completion`
|
||||
- Merge authority boundary, reviewer approval, validation, merge, Ticket done/close, and worktree/branch/Pod cleanup.
|
||||
- Dogfooding workspace may authorize merge/cleanup/close; conservative/default mode stops at merge-ready dossier.
|
||||
|
||||
This keeps the umbrella focused on the end-to-end Panel Queue -> Orchestrator automation while allowing each operational slice to land independently.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: decision author: hare at: 2026-06-07T03:57:24Z -->
|
||||
|
||||
## Decision
|
||||
|
||||
## Related planning-memory split
|
||||
|
||||
Created `ticket-orchestration-plan-tool` for the lightweight Orchestrator memory/tool surface around Ticket ordering, dependency, conflict, capacity, and accepted-plan decisions.
|
||||
|
||||
Decision:
|
||||
- Use Ticket/orchestration domain records for project-relevant routing decisions rather than session-lifetime Task tools.
|
||||
- Keep local Pod/session claims in the local role session registry.
|
||||
- Keep this separate from the core queued routing / worktree-agent / merge-completion slices so the first automation path can still rely on prompt/workflow sequencing while gaining a durable place for ordering/dependency decisions.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: decision author: coder at: 2026-06-09T01:26:26Z -->
|
||||
|
||||
## Decision
|
||||
|
||||
## Umbrella/progress-container migration recommendation
|
||||
|
||||
This Ticket currently functions as a long-lived umbrella/progress container for the concrete Orchestrator automation slices created in the thread:
|
||||
|
||||
- `orchestrator-queued-ticket-routing`
|
||||
- `orchestrator-worktree-agent-routing`
|
||||
- `orchestrator-merge-completion`
|
||||
- related Objective/context follow-up for orchestration planning as needed
|
||||
|
||||
Recommendation: do not keep this Ticket open merely to track aggregate progress. Once the concrete follow-up Tickets and any needed Objective context are confirmed, close this Ticket as superseded/decomposed. The close resolution should make clear that the umbrella/container role is retired, not that every future Panel Queue -> Orchestrator concern is complete, and should list completed concrete Tickets plus remaining follow-up Tickets/Objectives.
|
||||
|
||||
No backend schema, workflow_state, Objective record implementation, or typed relation implementation is required for this migration note.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: state_changed author: hare at: 2026-06-09T04:44:35Z from: planning to: done reason: closed field: workflow_state -->
|
||||
|
||||
## State changed
|
||||
|
||||
Ticket closed; workflow_state を done に設定しました。
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- event: close author: hare at: 2026-06-09T04:44:35Z status: closed -->
|
||||
|
||||
## 完了
|
||||
|
||||
Closed as an obsolete umbrella/progress-container Ticket.
|
||||
|
||||
This Ticket's original role was to collect the broad Panel Queue -> Orchestrator automation effort. That umbrella pattern is now deprecated: concrete work should live in implementable Tickets, medium-term context should live in Objectives, and Ticket relations should remain non-hierarchical.
|
||||
|
||||
The concrete slices recorded in this Ticket thread were split out and handled separately:
|
||||
|
||||
- `orchestrator-queued-ticket-routing`
|
||||
- `orchestrator-worktree-agent-routing`
|
||||
- `orchestrator-merge-completion`
|
||||
|
||||
Remaining or follow-up concerns are tracked by concrete Tickets/Objectives instead of this umbrella, including active queued-work planning/re-kick, non-hierarchical Ticket relations, Objective records, and umbrella deprecation work.
|
||||
|
||||
This close does not assert that every future Panel Queue -> Orchestrator concern is complete; it retires this Ticket as a broad container.
|
||||
|
||||
---
|
||||
Reference in New Issue
Block a user