ticket: record orchestration plan review dossier
This commit is contained in:
parent
af13abdaa7
commit
897835b678
|
|
@ -8,7 +8,7 @@ priority: P1
|
|||
labels: [ticket, orchestrator, planning, workflow, tools]
|
||||
workflow_state: 'inprogress'
|
||||
created_at: 2026-06-07T03:57:10Z
|
||||
updated_at: '2026-06-08T13:18:35Z'
|
||||
updated_at: '2026-06-08T13:23:45Z'
|
||||
assignee: null
|
||||
queued_by: 'workspace-panel'
|
||||
queued_at: '2026-06-08T11:21:13Z'
|
||||
|
|
|
|||
|
|
@ -256,3 +256,86 @@ Coder-reported design summary:
|
|||
- Supported kinds include ordering, dependency, conflict, waiting/capacity, and accepted-plan records.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: review author: reviewer at: 2026-06-08T13:22:06Z status: approve -->
|
||||
|
||||
## Review: approve
|
||||
|
||||
Review result: approve.
|
||||
|
||||
Evidence:
|
||||
- Inspected commit `b28b7759f51e7c9c7ccaaa15358b475e3889952c` and changed files `.yoi/workflow/ticket-orchestrator-routing.md`, `crates/pod/src/feature/builtin/ticket.rs`, `crates/ticket/src/lib.rs`, and `crates/ticket/src/tool.rs`.
|
||||
- Storage is per-Ticket `artifacts/orchestration-plan.jsonl`; records are JSONL under the Ticket backend root and validated by `ticket doctor`.
|
||||
- Backend/tool surface supports recording and querying by Ticket plus relation kind with kinds `before`, `after`, `blocked_by`, `blocks`, `conflicts_with`, `do_not_parallelize`, `waiting_capacity_note`, and `accepted_plan`.
|
||||
- Query tool is registered in the read-only Ticket tool set; record tool is kept out of read-only and available only in mutating/lifecycle tool sets.
|
||||
- The implementation stores bounded Ticket/project planning fields and does not change workflow_state, reorder queues, start work, implement a scheduler, or introduce broad relation-graph validation.
|
||||
- Orchestrator workflow guidance now tells queued routing to consult plan records and to record durable project-relevant plan decisions.
|
||||
|
||||
Validation run from the review worktree passed:
|
||||
- `cargo fmt --check`
|
||||
- `git diff --check b28b7759f51e7c9c7ccaaa15358b475e3889952c^ b28b7759f51e7c9c7ccaaa15358b475e3889952c`
|
||||
- `cargo test -p ticket orchestration_plan`
|
||||
- `cargo test -p pod feature::builtin::ticket`
|
||||
- `cargo run -q -p yoi -- ticket doctor`
|
||||
- `cargo check --workspace`
|
||||
- `nix build .#yoi`
|
||||
|
||||
---
|
||||
|
||||
<!-- event: implementation_report author: orchestrator at: 2026-06-08T13:23:45Z -->
|
||||
|
||||
## Implementation report
|
||||
|
||||
Merge-ready dossier for human/orchestrator approval.
|
||||
|
||||
Status:
|
||||
- Implementation branch: `ticket-orchestration-plan-tool`
|
||||
- Worktree: `.worktree/ticket-orchestration-plan-tool`
|
||||
- Commit under review: `b28b7759f51e7c9c7ccaaa15358b475e3889952c ticket: add orchestration plan tools`
|
||||
- Reviewer: `reviewer-ticket-orchestration-plan-tool`
|
||||
- Review result: approved; no blocking findings.
|
||||
|
||||
Intent / invariant check:
|
||||
- Adds a lightweight Ticket-domain orchestration plan/note surface.
|
||||
- Does not implement a scheduler, background queue runner, dependency graph solver, TaskStore replacement, or typed Ticket relation metadata.
|
||||
- Does not change Ticket workflow_state semantics or move Tickets automatically.
|
||||
- Keeps local runtime/session/socket/raw model output out of git-tracked plan records.
|
||||
|
||||
Implementation summary:
|
||||
- Adds typed `OrchestrationPlanKind` / `OrchestrationPlanRecord` support.
|
||||
- Stores records as per-Ticket `artifacts/orchestration-plan.jsonl` JSONL.
|
||||
- Adds backend append/query APIs, including query by Ticket id/slug and kind filter.
|
||||
- Adds LLM tools `TicketOrchestrationPlanRecord` and `TicketOrchestrationPlanQuery`.
|
||||
- Exposes query in read-only Ticket tools and record mutation only in mutating/lifecycle Ticket tools.
|
||||
- Adds validation and `ticket doctor` diagnostics for orchestration-plan artifacts.
|
||||
- Updates Orchestrator routing workflow guidance to query/record plan context before accepting queued Tickets.
|
||||
|
||||
Reviewer evidence:
|
||||
- Required record classes are covered: before, after, blocked_by, blocks, conflicts_with, do_not_parallelize, waiting_capacity_note, accepted_plan.
|
||||
- Accepted-plan fields are bounded project-relevant fields (`summary`, `branch`, `worktree`, `role_plan`).
|
||||
- Validation rejects malformed records such as missing related Ticket for relation kinds, invalid accepted-plan combinations, missing waiting notes, oversized/single-line field violations, and artifact owner mismatch.
|
||||
- Capability split was checked in `crates/pod/src/feature/builtin/ticket.rs`.
|
||||
|
||||
Validation evidence:
|
||||
- Coder reported pass:
|
||||
- `cargo fmt --check`
|
||||
- `git diff --check`
|
||||
- `cargo run -q -p yoi -- ticket doctor`
|
||||
- `cargo check --workspace`
|
||||
- `cargo test -p ticket`
|
||||
- `cargo test -p pod feature::builtin::ticket`
|
||||
- `nix build .#yoi`
|
||||
- Reviewer independently ran and passed:
|
||||
- `cargo fmt --check`
|
||||
- `git diff --check b28b7759f51e7c9c7ccaaa15358b475e3889952c^ b28b7759f51e7c9c7ccaaa15358b475e3889952c`
|
||||
- `cargo test -p ticket orchestration_plan`
|
||||
- `cargo test -p pod feature::builtin::ticket`
|
||||
- `cargo run -q -p yoi -- ticket doctor`
|
||||
- `cargo check --workspace`
|
||||
- `nix build .#yoi`
|
||||
|
||||
Residual risks / notes:
|
||||
- This is intentionally execution-plan metadata, not intrinsic project-level Ticket relations. `typed-ticket-relation-metadata` remains separate.
|
||||
- Final merge/close/cleanup is intentionally not performed here without explicit merge approval.
|
||||
|
||||
---
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ priority: 'P1'
|
|||
labels: ['ticket', 'relations', 'planning', 'panel', 'orchestrator']
|
||||
workflow_state: planning
|
||||
created_at: '2026-06-08T07:27:32Z'
|
||||
updated_at: '2026-06-08T07:28:29Z'
|
||||
updated_at: '2026-06-08T13:22:42Z'
|
||||
assignee: null
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -35,3 +35,25 @@ Considerations:
|
|||
The implementation should decide whether unresolved dependencies make Queue invalid, require confirmation, or allow Queue with a visible blocked state. The important requirement is that dependency relation metadata is not only an Orchestrator input; it should also inform the human Queue gate.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: decision author: hare at: 2026-06-08T13:22:42Z -->
|
||||
|
||||
## Decision
|
||||
|
||||
## Design consideration: avoid recreating umbrella Tickets through parent/child relations
|
||||
|
||||
Umbrella Tickets are being deprecated as long-lived broad progress containers. This affects relation design.
|
||||
|
||||
Parent/child relation kinds can easily recreate the umbrella pattern if they imply that one Ticket is a broad container whose close condition depends on manually inspecting child sufficiency. Therefore relation kinds such as `parent` / `child` should be reconsidered before implementation.
|
||||
|
||||
Design guidance:
|
||||
|
||||
- Keep concrete dependency/blocking relations distinct from broad grouping.
|
||||
- Prefer `Objective` records for medium-term goal/strategy grouping.
|
||||
- If decomposition needs to be represented, consider whether a relation such as `derived_from`, `split_from`, or `related` is safer than `parent` / `child`.
|
||||
- Do not make relation metadata imply that a broad umbrella Ticket should remain open as a progress container.
|
||||
- Any relation kind that approximates parent/child must define clear close semantics and avoid ambiguity around whether all child work is sufficient.
|
||||
|
||||
This Ticket should explicitly decide whether to include parent/child relations at all in the first version.
|
||||
|
||||
---
|
||||
|
|
|
|||
|
|
@ -0,0 +1,69 @@
|
|||
---
|
||||
id: '20260608-132230-deprecate-umbrella-tickets'
|
||||
slug: 'deprecate-umbrella-tickets'
|
||||
title: 'Deprecate umbrella Tickets'
|
||||
status: 'open'
|
||||
kind: 'task'
|
||||
priority: 'P2'
|
||||
labels: ['ticket', 'workflow', 'documentation', 'planning']
|
||||
workflow_state: 'planning'
|
||||
created_at: '2026-06-08T13:22:30Z'
|
||||
updated_at: '2026-06-08T13:22:30Z'
|
||||
assignee: null
|
||||
---
|
||||
|
||||
## Background
|
||||
|
||||
Umbrella Tickets have been used as broad containers that split into several implementation Tickets. In practice this creates ambiguous lifecycle semantics:
|
||||
|
||||
- it is unclear when the umbrella itself should be closed;
|
||||
- child Tickets may be complete while the umbrella remains open;
|
||||
- AI-created splits require the user to re-open the umbrella and inspect whether all child work is truly sufficient;
|
||||
- the umbrella can become a mix of initial request, progress container, split decision log, Objective-like strategy context, and completion proxy.
|
||||
|
||||
The `workspace-panel-orchestrator-queue-automation` Ticket exposed this problem: core child slices were completed, but the umbrella remained open and its close condition was not obvious.
|
||||
|
||||
The emerging model is:
|
||||
|
||||
- Ticket: implementable/completable work item shaped by Intake/Planning.
|
||||
- Objective: medium-term goal, motivation, strategy, and success criteria.
|
||||
- Typed Ticket relations: dependency/related/supersedes/blocking metadata between concrete Tickets.
|
||||
- OrchestrationPlan: current execution planning for queued/in-progress work.
|
||||
|
||||
Umbrella Tickets do not fit cleanly into that model.
|
||||
|
||||
## Goal
|
||||
|
||||
Deprecate the use of umbrella Tickets as broad multi-Ticket containers, and update workflow/docs so future work is represented by concrete Tickets plus Objectives/relations instead.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Document that new umbrella Tickets should not be created for broad multi-Ticket efforts.
|
||||
- State that Tickets should be concrete work items that can be implemented, reviewed, validated, and closed on their own terms.
|
||||
- When a broad request must be split:
|
||||
- create concrete implementable Tickets for the slices;
|
||||
- record the split decision in the relevant Ticket/Objective/thread context;
|
||||
- use an Objective for medium-term goal/strategy context when needed;
|
||||
- use typed Ticket relations, once available, for dependency/related/blocking metadata;
|
||||
- do not keep a separate umbrella Ticket open merely as a progress container.
|
||||
- Clarify the migration/cleanup path for existing umbrella Tickets.
|
||||
- They may be closed as superseded/decomposed once concrete follow-up Tickets/Objective context exist.
|
||||
- Closing an umbrella in this way does not mean every related future concern is complete; it means the umbrella container role is retired.
|
||||
- The close resolution should list completed child/concrete Tickets and remaining follow-up Tickets/Objectives.
|
||||
- Update workflow guidance for Intake/Planning and Orchestrator so they avoid creating umbrella Tickets during split/refinement.
|
||||
- Ensure this does not block creating an initial planning Ticket when a user explicitly asks for a concrete design/investigation work item; the deprecated pattern is the long-lived umbrella progress container.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- Designing typed Ticket relation metadata; keep relation-kind decisions in `typed-ticket-relation-metadata`.
|
||||
- Implementing Objective records; covered by `objective-records-for-medium-term-goals`.
|
||||
- Rewriting every historical umbrella immediately.
|
||||
- Removing thread history from existing umbrella Tickets.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Development/workflow docs explain that umbrella Tickets are deprecated and should not be created for new broad efforts.
|
||||
- Intake/Planning guidance explains how to split broad requests without creating an umbrella progress container.
|
||||
- Orchestrator guidance explains how to close or retire existing umbrella Tickets once concrete Tickets/Objectives carry the remaining work.
|
||||
- At least `workspace-panel-orchestrator-queue-automation` has a clear migration/close recommendation recorded or is handled in a follow-up.
|
||||
- `target/debug/yoi ticket doctor` and `git diff --check` pass.
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
<!-- event: create author: LocalTicketBackend at: 2026-06-08T13:22:30Z -->
|
||||
|
||||
## 作成
|
||||
|
||||
LocalTicketBackend によって作成されました。
|
||||
|
||||
---
|
||||
Loading…
Reference in New Issue
Block a user