ticket: split orchestrator automation phases
This commit is contained in:
parent
9aa6e7d1ab
commit
550e0159ed
|
|
@ -8,7 +8,7 @@ priority: P1
|
|||
labels: [panel, orchestrator, ticket, automation, workflow]
|
||||
workflow_state: intake
|
||||
created_at: 2026-06-07T02:02:15Z
|
||||
updated_at: 2026-06-07T03:35:44Z
|
||||
updated_at: 2026-06-07T03:57:24Z
|
||||
assignee: null
|
||||
legacy_ticket: null
|
||||
---
|
||||
|
|
|
|||
|
|
@ -45,3 +45,45 @@ Decision:
|
|||
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.
|
||||
|
||||
---
|
||||
|
|
|
|||
|
|
@ -0,0 +1,66 @@
|
|||
---
|
||||
id: 20260607-035143-orchestrator-queued-ticket-routing
|
||||
slug: orchestrator-queued-ticket-routing
|
||||
title: Orchestrator queued Ticket routing
|
||||
status: open
|
||||
kind: task
|
||||
priority: P1
|
||||
labels: [panel, orchestrator, ticket, routing, workflow]
|
||||
workflow_state: intake
|
||||
created_at: 2026-06-07T03:51:43Z
|
||||
updated_at: 2026-06-07T03:51:43Z
|
||||
assignee: null
|
||||
legacy_ticket: null
|
||||
---
|
||||
|
||||
## Background
|
||||
|
||||
`workspace-panel-orchestrator-queue-automation` defines the overall goal: Panel Queue should notify the workspace Orchestrator, and the Orchestrator should route queued Tickets and start work when unblocked. The first implementation slice should focus on routing acceptance, not full worktree/coder/reviewer/merge execution.
|
||||
|
||||
This ticket uses the current workflow contract as the basis: Queue is a human gate, `queued` means Orchestrator may route, and `inprogress` is the durable Orchestrator acceptance marker before implementation side effects.
|
||||
|
||||
## Goal
|
||||
|
||||
Implement the queued Ticket routing entrypoint for the workspace Orchestrator.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Fire a durable Orchestrator notification when a Panel action transitions a Ticket `ready -> queued`.
|
||||
- Notification content must instruct the Orchestrator to:
|
||||
- read the queued Ticket;
|
||||
- inspect current workspace state;
|
||||
- start if unblocked;
|
||||
- record a blocker/defer reason if not startable.
|
||||
- Update wording away from passive "implementation was not started" semantics. Queue authorizes routing; Orchestrator decides whether to start.
|
||||
- Orchestrator routing workflow/prompt must define the acceptance order:
|
||||
- inspect Ticket/workspace state;
|
||||
- if unblocked, transition `queued -> inprogress`;
|
||||
- do not create worktrees or spawn implementation/review Pods before `inprogress` acceptance;
|
||||
- if `queued -> inprogress` fails, do not create side effects.
|
||||
- First-pass blocker detection should be intentionally small and explicit:
|
||||
- Ticket is no longer `queued`;
|
||||
- `attention_required` is set;
|
||||
- explicit dependency/blocker/preflight gap is recorded in the Ticket;
|
||||
- same Ticket already has an active local role/session/worktree;
|
||||
- branch/worktree name collision;
|
||||
- main workspace is clearly unsafe for orchestration;
|
||||
- a current in-progress Ticket clearly conflicts based on explicit Ticket text or known scope.
|
||||
- If blocked, Orchestrator records a concise decision/comment and leaves the Ticket queued or explicitly defers through existing Ticket status/state mechanisms.
|
||||
- Progress/acceptance should be recorded in the Ticket thread using existing typed events/comments where available.
|
||||
- Use Ticket lifecycle domain tools once available; do not model this as an Orchestrator-specific Ticket tool feature.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- Implementing coder/reviewer worktree routing; that belongs to `orchestrator-worktree-agent-routing`.
|
||||
- Implementing merge/close completion; that belongs to `orchestrator-merge-completion`.
|
||||
- Implementing dynamic workflow state-machine tool gating.
|
||||
- Implementing composite `StartTicketWork` unless it is trivial and does not replace the prompt/workflow contract.
|
||||
- Polling newly-created `intake` Tickets or auto-starting Intake.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Panel Queue produces a durable Orchestrator routing notification with correct semantics.
|
||||
- Orchestrator prompt/workflow states that `queued -> inprogress` acceptance must precede worktree/SpawnPod side effects.
|
||||
- A queued Ticket can be accepted and marked `inprogress` by Orchestrator routing when unblocked.
|
||||
- Blocked queued Tickets get a recorded reason rather than silent no-op.
|
||||
- Tests or prompt/resource tests cover Queue notification wording and the acceptance-order instruction.
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
<!-- event: create author: LocalTicketBackend at: 2026-06-07T03:51:43Z -->
|
||||
|
||||
## Created
|
||||
|
||||
Created by LocalTicketBackend create.
|
||||
|
||||
---
|
||||
|
|
@ -0,0 +1,62 @@
|
|||
---
|
||||
id: 20260607-035201-orchestrator-worktree-agent-routing
|
||||
slug: orchestrator-worktree-agent-routing
|
||||
title: Orchestrator worktree agent routing
|
||||
status: open
|
||||
kind: task
|
||||
priority: P1
|
||||
labels: [orchestrator, worktree, pod, review, workflow]
|
||||
workflow_state: intake
|
||||
created_at: 2026-06-07T03:52:01Z
|
||||
updated_at: 2026-06-07T03:52:01Z
|
||||
assignee: null
|
||||
legacy_ticket: null
|
||||
---
|
||||
|
||||
## Background
|
||||
|
||||
After a queued Ticket is accepted as `inprogress`, the Orchestrator should be able to route implementation work through the existing `worktree-workflow` and `multi-agent-workflow` operational model. The current workflows already describe the desired behavior: create a child worktree, spawn a coder Pod with scoped write access, spawn an independent reviewer sibling, and run review/fix loops.
|
||||
|
||||
This ticket is the worktree/coder/reviewer execution slice under `workspace-panel-orchestrator-queue-automation`.
|
||||
|
||||
## Goal
|
||||
|
||||
Make the workspace Orchestrator execute accepted in-progress Tickets through worktree + coder/reviewer Pod routing using the existing workflow contracts as builtin/role guidance.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Use `worktree-workflow` as the mechanical worktree creation/management contract.
|
||||
- Use `multi-agent-workflow` as the coder/reviewer sibling orchestration contract.
|
||||
- Orchestrator must only start this path after the Ticket is accepted as `inprogress`.
|
||||
- Create one implementation worktree per Ticket/bounded task under `.worktree/<task-name>`.
|
||||
- Exclude `.yoi` from child worktrees and keep Ticket/thread/workflow updates in the main workspace.
|
||||
- Spawn coder Pods with read access to the main workspace and write access only to the child worktree or narrower implementation scope.
|
||||
- Spawn reviewer Pods as Orchestrator siblings, not coder children, with read-only scope by default.
|
||||
- Coder task prompts must include an intent packet: intent, requirements, invariants, non-goals, escalation conditions, validation expectations, worktree path, and branch.
|
||||
- Reviewer task prompts must focus on Ticket intent, diff, invariants, validation adequacy, and blocker/non-blocker classification.
|
||||
- Orchestrator must record progress in the Ticket thread at meaningful checkpoints:
|
||||
- accepted worktree/branch plan;
|
||||
- coder delegated;
|
||||
- coder completed or blocked;
|
||||
- reviewer delegated;
|
||||
- review approved/requested changes;
|
||||
- fix loop outcome.
|
||||
- Orchestrator must not merge in this ticket's scope. It should produce a merge-ready dossier for `orchestrator-merge-completion`.
|
||||
- If compaction occurs, workflow obligations should remain understandable; relate to `preserve-active-workflows-across-compaction` but do not block first implementation on it.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- Queue notification / queued acceptance; that belongs to `orchestrator-queued-ticket-routing`.
|
||||
- Merge/cleanup/close; that belongs to `orchestrator-merge-completion`.
|
||||
- Broad conflict/dependency inference beyond the first-pass routing decision.
|
||||
- Dynamic workflow-state tool gating.
|
||||
- Letting coder Pods edit main workspace Ticket records or `.yoi`.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Orchestrator has builtin/role guidance or implementation wiring that follows `worktree-workflow` and `multi-agent-workflow` for accepted Tickets.
|
||||
- Worktree creation excludes `.yoi`.
|
||||
- Coder and reviewer Pods are spawned as siblings under Orchestrator with the expected scopes.
|
||||
- Progress is recorded in the Ticket thread.
|
||||
- A merge-ready dossier format is produced after review approval and validation.
|
||||
- Tests or prompt/resource tests cover the worktree/coder/reviewer routing instructions and scope boundaries.
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
<!-- event: create author: LocalTicketBackend at: 2026-06-07T03:52:01Z -->
|
||||
|
||||
## Created
|
||||
|
||||
Created by LocalTicketBackend create.
|
||||
|
||||
---
|
||||
|
|
@ -0,0 +1,71 @@
|
|||
---
|
||||
id: 20260607-035231-orchestrator-merge-completion
|
||||
slug: orchestrator-merge-completion
|
||||
title: Orchestrator merge completion
|
||||
status: open
|
||||
kind: task
|
||||
priority: P1
|
||||
labels: [orchestrator, merge, ticket, workflow, validation]
|
||||
workflow_state: intake
|
||||
created_at: 2026-06-07T03:52:31Z
|
||||
updated_at: 2026-06-07T03:52:31Z
|
||||
assignee: null
|
||||
legacy_ticket: null
|
||||
---
|
||||
|
||||
## Background
|
||||
|
||||
Once Orchestrator-managed implementation and independent review have produced a merge-ready dossier, the final automation slice is merging, validating, cleanup, and Ticket completion. The current `multi-agent-workflow` already describes the desired manual/orchestrated behavior. This ticket makes that behavior explicit for workspace Orchestrator automation.
|
||||
|
||||
Merge authority must be explicit. In this dogfooding workspace, Orchestrator may proceed through merge/cleanup/close when workflow/policy conditions are met. More conservative/public defaults may stop at merge-ready dossier instead.
|
||||
|
||||
## Goal
|
||||
|
||||
Implement Orchestrator merge/completion behavior for reviewed in-progress Tickets, based on the existing multi-agent workflow.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Define the merge authority boundary clearly:
|
||||
- in local dogfooding mode/workspace policy, Orchestrator may merge/cleanup/close after review approval and validation;
|
||||
- otherwise Orchestrator must stop at a merge-ready dossier with human action required.
|
||||
- Require an independent reviewer approval before merge, unless a human explicitly overrides and records a decision.
|
||||
- Require a merge-ready dossier including:
|
||||
- Ticket id/slug;
|
||||
- branch/worktree;
|
||||
- commits;
|
||||
- intent/invariant check;
|
||||
- implementation summary;
|
||||
- coder/reviewer Pods;
|
||||
- blockers fixed or rejected findings with reasons;
|
||||
- validation performed;
|
||||
- residual risks;
|
||||
- dirty state.
|
||||
- Before merge, verify main workspace state is safe and unrelated dirty changes are understood.
|
||||
- Merge with `git merge --no-ff <branch>` or the agreed project merge method.
|
||||
- Run post-merge validation appropriate to the change. Minimum baseline should include:
|
||||
- focused tests from the ticket/dossier;
|
||||
- `cargo fmt --check`;
|
||||
- `git diff --check`;
|
||||
- `target/debug/yoi ticket doctor` where applicable.
|
||||
- Use broader validation (`cargo check --workspace --all-targets`, `nix build .#yoi`, etc.) when risk or touched files warrant it.
|
||||
- Record implementation/review/merge/validation outcome in the Ticket thread.
|
||||
- Transition `inprogress -> done` or close the Ticket according to typed Ticket workflow rules.
|
||||
- Remove merged child worktree and delete merged branch unless the user/workflow explicitly asks to keep them.
|
||||
- Stop coder/reviewer Pods and reclaim scopes after completion.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- Queue notification / queued acceptance; that belongs to `orchestrator-queued-ticket-routing`.
|
||||
- Worktree/coder/reviewer routing; that belongs to `orchestrator-worktree-agent-routing`.
|
||||
- Removing the human override path for unusual reviews/merge decisions.
|
||||
- Making merge authority implicit for all public/default configurations.
|
||||
- Solving active workflow compaction persistence; relate to `preserve-active-workflows-across-compaction`.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Orchestrator has explicit merge/completion guidance or implementation wiring based on `multi-agent-workflow`.
|
||||
- Reviewed in-progress Tickets can be merged, validated, closed/done, and cleaned up by Orchestrator in authorized dogfooding mode.
|
||||
- Conservative mode or missing authorization stops at merge-ready dossier rather than merging.
|
||||
- Ticket thread records the merge/completion decision and validation evidence.
|
||||
- Worktrees/branches/Pods are cleaned up after successful merge/close.
|
||||
- Tests or prompt/resource tests cover merge authority boundary and required dossier/validation fields.
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
<!-- event: create author: LocalTicketBackend at: 2026-06-07T03:52:31Z -->
|
||||
|
||||
## Created
|
||||
|
||||
Created by LocalTicketBackend create.
|
||||
|
||||
---
|
||||
|
|
@ -0,0 +1,67 @@
|
|||
---
|
||||
id: 20260607-035710-ticket-orchestration-plan-tool
|
||||
slug: ticket-orchestration-plan-tool
|
||||
title: Ticket orchestration plan tool
|
||||
status: open
|
||||
kind: task
|
||||
priority: P1
|
||||
labels: [ticket, orchestrator, planning, workflow, tools]
|
||||
workflow_state: intake
|
||||
created_at: 2026-06-07T03:57:10Z
|
||||
updated_at: 2026-06-07T03:57:10Z
|
||||
assignee: null
|
||||
legacy_ticket: null
|
||||
---
|
||||
|
||||
## Background
|
||||
|
||||
Orchestrator queue automation needs a lightweight way to remember routing decisions across turns while coordinating multiple Tickets. The existing Task tool is session-lifetime and human/user-visible, but Ticket ordering, dependency, conflict, and routing decisions belong to the Ticket orchestration domain.
|
||||
|
||||
The immediate need is not a full scheduler or dependency graph. The Orchestrator needs a small typed surface to record decisions such as:
|
||||
|
||||
- Ticket A should run before Ticket B;
|
||||
- Ticket B is blocked by Ticket A;
|
||||
- Ticket C conflicts with Ticket D and should not run in parallel;
|
||||
- Ticket E is ready but waiting for capacity;
|
||||
- Ticket F has been accepted by Orchestrator and has a planned worktree/branch.
|
||||
|
||||
These records should help the Orchestrator avoid relying only on prompt memory, especially across compaction and multi-turn routing.
|
||||
|
||||
## Goal
|
||||
|
||||
Design and implement a lightweight Ticket orchestration note/plan tool surface for Orchestrator use, similar in convenience to Task tools but scoped to Ticket ordering and routing decisions.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Provide a typed, lightweight tool/API for recording and querying Orchestrator routing decisions about Tickets.
|
||||
- Support at least:
|
||||
- ordering relation: before/after;
|
||||
- dependency/blocker relation: blocked_by / blocks;
|
||||
- conflict relation: do_not_parallelize / conflicts_with;
|
||||
- capacity/waiting note;
|
||||
- accepted work plan summary such as branch/worktree/pod plan when applicable.
|
||||
- Distinguish durable project-relevant relations from local ephemeral execution notes:
|
||||
- dependency/order/conflict decisions that should affect future orchestration should be recorded in git-tracked Ticket records or typed Ticket thread events/artifacts;
|
||||
- local runtime claims/session details should remain in the local role session registry, not Ticket metadata.
|
||||
- Keep this a Ticket/orchestration domain capability, not a generic TaskStore replacement.
|
||||
- Ensure records are queryable by Ticket id/slug and by relation kind.
|
||||
- Keep the first version simple; do not implement a full scheduler, graph solver, or automatic topological planner.
|
||||
- Integrate with Orchestrator prompts/workflows so the Orchestrator consults these records before accepting queued Tickets.
|
||||
- Avoid using session-lifetime Task tools for durable Ticket dependency/order decisions.
|
||||
- Ensure compaction does not erase the authoritative record; the tool should write to a durable record path.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- Replacing Ticket workflow_state.
|
||||
- Replacing the local role session registry for Pod/session claims.
|
||||
- Implementing full dependency graph scheduling.
|
||||
- Automatically reordering all queued Tickets without Orchestrator judgment.
|
||||
- Making Companion a mutating orchestration actor.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Orchestrator has a simple typed way to record Ticket ordering/dependency/conflict/capacity decisions.
|
||||
- The records survive compaction and are queryable in later turns.
|
||||
- Project-relevant decisions are stored in the Ticket system rather than only session-lifetime Task state.
|
||||
- Local runtime execution details remain out of git-tracked Ticket metadata.
|
||||
- Orchestrator queue routing can consult the recorded decisions before accepting a queued Ticket.
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
<!-- event: create author: LocalTicketBackend at: 2026-06-07T03:57:10Z -->
|
||||
|
||||
## Created
|
||||
|
||||
Created by LocalTicketBackend create.
|
||||
|
||||
---
|
||||
Loading…
Reference in New Issue
Block a user