Hare/yoi
1
1
Fork 0
Code Actions Packages Releases Activity
1349a75350
yoi/.yoi/tickets/open/20260607-020215-workspace-panel-orchestrator-queue-automation/thread.md

5.5 KiB
Raw Blame History

Created

Created by LocalTicketBackend create.

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.

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.

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.

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.

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.