ticket: migrate open tickets to planning state
This commit is contained in:
parent
603af8bd3b
commit
07f8b3cb8a
|
|
@ -8,7 +8,7 @@ priority: P1
|
|||
labels: [ticket, workflow-state, orchestrator, panel, intake, planning]
|
||||
workflow_state: 'done'
|
||||
created_at: 2026-06-07T22:54:48Z
|
||||
updated_at: '2026-06-08T09:19:17Z'
|
||||
updated_at: '2026-06-08T10:19:05Z'
|
||||
assignee: null
|
||||
legacy_ticket: null
|
||||
queued_by: 'workspace-panel'
|
||||
|
|
|
|||
|
|
@ -464,4 +464,23 @@ Residual notes:
|
|||
- Historical `.yoi/tickets/**` records still contain old `Preflight`, `preflight_needed`, and `needs_preflight` text as durable audit/history artifacts; they were intentionally not rewritten.
|
||||
- `ticket-preflight-workflow` filename remains as a compatibility slug, but its content now explicitly describes planning/requirements sync rather than a separate workflow state/lane/long-lived operation.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: decision author: hare at: 2026-06-08T10:19:05Z -->
|
||||
|
||||
## Decision
|
||||
|
||||
## Local migration and compatibility direction
|
||||
|
||||
After the local Ticket record migration, do not preserve long-term compatibility for state-as-`intake` or `needs_preflight` / `preflight_needed` records.
|
||||
|
||||
Direction:
|
||||
- migrate open local Ticket records to explicit `workflow_state: planning`;
|
||||
- remove legacy preflight frontmatter fields from open Ticket records;
|
||||
- treat any remaining historical mentions in thread logs as audit history, not current workflow inputs;
|
||||
- update code/prompts/workflows toward the new model rather than adding broad compatibility branches for the old local data shape.
|
||||
|
||||
Compatibility should be limited to bounded migration/error diagnostics where needed, not a permanent runtime surface.
|
||||
|
||||
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ status: open
|
|||
kind: task
|
||||
priority: P2
|
||||
labels: [migrated]
|
||||
workflow_state: planning
|
||||
created_at: 2026-05-27T00:00:02Z
|
||||
updated_at: 2026-05-27T00:00:02Z
|
||||
assignee: null
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ status: open
|
|||
kind: task
|
||||
priority: P2
|
||||
labels: [migrated]
|
||||
workflow_state: planning
|
||||
created_at: 2026-05-27T00:00:03Z
|
||||
updated_at: 2026-05-27T00:00:03Z
|
||||
assignee: null
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ status: open
|
|||
kind: task
|
||||
priority: P2
|
||||
labels: [migrated]
|
||||
workflow_state: planning
|
||||
created_at: 2026-05-27T00:00:06Z
|
||||
updated_at: 2026-05-27T00:00:06Z
|
||||
assignee: null
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ status: open
|
|||
kind: task
|
||||
priority: P2
|
||||
labels: [migrated]
|
||||
workflow_state: planning
|
||||
created_at: 2026-05-27T00:00:09Z
|
||||
updated_at: 2026-05-27T00:00:09Z
|
||||
assignee: null
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ status: open
|
|||
kind: task
|
||||
priority: P2
|
||||
labels: [migrated]
|
||||
workflow_state: planning
|
||||
created_at: 2026-05-27T00:00:10Z
|
||||
updated_at: 2026-05-27T00:00:10Z
|
||||
assignee: null
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ status: open
|
|||
kind: task
|
||||
priority: P2
|
||||
labels: [migrated]
|
||||
workflow_state: planning
|
||||
created_at: 2026-05-27T00:00:15Z
|
||||
updated_at: 2026-05-27T00:00:15Z
|
||||
assignee: null
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ status: open
|
|||
kind: audit
|
||||
priority: P2
|
||||
labels: [architecture, crates]
|
||||
workflow_state: planning
|
||||
created_at: 2026-05-28T13:13:17Z
|
||||
updated_at: 2026-05-28T13:13:17Z
|
||||
assignee: null
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ status: open
|
|||
kind: audit
|
||||
priority: P2
|
||||
labels: [llm-worker, docs, api, release]
|
||||
workflow_state: planning
|
||||
created_at: 2026-05-29T04:19:11Z
|
||||
updated_at: 2026-05-29T04:19:11Z
|
||||
assignee: null
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ status: open
|
|||
kind: feature
|
||||
priority: P2
|
||||
labels: [mcp, tools, security, profiles]
|
||||
workflow_state: planning
|
||||
created_at: 2026-05-29T16:19:28Z
|
||||
updated_at: 2026-05-29T16:19:28Z
|
||||
assignee: null
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ status: open
|
|||
kind: feature
|
||||
priority: P2
|
||||
labels: [tui, worker, interrupt, ux]
|
||||
workflow_state: planning
|
||||
created_at: 2026-05-30T05:37:21Z
|
||||
updated_at: 2026-05-30T05:38:11Z
|
||||
assignee: null
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ status: open
|
|||
kind: feature
|
||||
priority: P2
|
||||
labels: [plugin, hooks, tools, wasm, mcp]
|
||||
workflow_state: planning
|
||||
created_at: 2026-05-31T01:00:05Z
|
||||
updated_at: 2026-06-03T12:25:05Z
|
||||
assignee: null
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ status: open
|
|||
kind: task
|
||||
priority: P2
|
||||
labels: [tui, composer, history, persistence]
|
||||
workflow_state: planning
|
||||
created_at: 2026-06-01T02:11:04Z
|
||||
updated_at: 2026-06-05T23:01:38Z
|
||||
assignee: null
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ status: open
|
|||
kind: feature
|
||||
priority: P2
|
||||
labels: [plugin, distribution, workspace, user]
|
||||
workflow_state: planning
|
||||
created_at: 2026-06-01T06:49:53Z
|
||||
updated_at: 2026-06-01T06:50:33Z
|
||||
assignee: null
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ status: open
|
|||
kind: task
|
||||
priority: P2
|
||||
labels: [audit, dependencies, license]
|
||||
workflow_state: planning
|
||||
created_at: 2026-06-01T12:36:41Z
|
||||
updated_at: 2026-06-01T13:08:45Z
|
||||
assignee: null
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ status: open
|
|||
kind: task
|
||||
priority: P2
|
||||
labels: [companion, profile, prompt, tools, panel]
|
||||
workflow_state: intake
|
||||
workflow_state: planning
|
||||
created_at: 2026-06-07T00:16:51Z
|
||||
updated_at: 2026-06-07T02:45:32Z
|
||||
assignee: null
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ status: open
|
|||
kind: task
|
||||
priority: P2
|
||||
labels: [tui, panel, companion, orchestration]
|
||||
workflow_state: intake
|
||||
workflow_state: planning
|
||||
created_at: 2026-06-07T00:16:51Z
|
||||
updated_at: 2026-06-07T03:13:01Z
|
||||
assignee: null
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ status: open
|
|||
kind: task
|
||||
priority: P1
|
||||
labels: [panel, orchestrator, ticket, automation, workflow]
|
||||
workflow_state: intake
|
||||
workflow_state: planning
|
||||
created_at: 2026-06-07T02:02:15Z
|
||||
updated_at: 2026-06-07T03:57:24Z
|
||||
assignee: null
|
||||
|
|
@ -21,7 +21,7 @@ The panel currently has pieces of the Ticket orchestration path:
|
|||
- 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 preflight gaps.
|
||||
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.
|
||||
|
||||
|
|
@ -52,13 +52,13 @@ Implement a first-class Panel -> Intake/Queue -> Orchestrator automation path wh
|
|||
- 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, preflight gaps, or capacity constraints;
|
||||
- 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:
|
||||
- `ticket-preflight-workflow` when requirements/design readiness are uncertain;
|
||||
- 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.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ status: open
|
|||
kind: task
|
||||
priority: P1
|
||||
labels: [workflow, compaction, history, orchestration]
|
||||
workflow_state: intake
|
||||
workflow_state: planning
|
||||
created_at: 2026-06-07T02:23:28Z
|
||||
updated_at: 2026-06-07T02:23:28Z
|
||||
assignee: null
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ status: open
|
|||
kind: task
|
||||
priority: P2
|
||||
labels: [workflow, knowledge, resources, builtin]
|
||||
workflow_state: intake
|
||||
workflow_state: planning
|
||||
created_at: 2026-06-07T07:27:08Z
|
||||
updated_at: 2026-06-07T07:27:08Z
|
||||
assignee: null
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ status: open
|
|||
kind: task
|
||||
priority: P2
|
||||
labels: [pod, notification, prompt, orchestration, ux]
|
||||
workflow_state: intake
|
||||
workflow_state: planning
|
||||
created_at: 2026-06-07T07:33:13Z
|
||||
updated_at: 2026-06-07T07:33:13Z
|
||||
assignee: null
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ status: open
|
|||
kind: task
|
||||
priority: P2
|
||||
labels: [ticket, orchestration, role, cleanup]
|
||||
workflow_state: intake
|
||||
workflow_state: planning
|
||||
created_at: 2026-06-07T08:43:44Z
|
||||
updated_at: 2026-06-07T08:43:44Z
|
||||
assignee: null
|
||||
|
|
@ -17,11 +17,11 @@ legacy_ticket: null
|
|||
|
||||
`investigator` was introduced by prior AI-driven Ticket orchestration design as a fixed Ticket role alongside `intake`, `orchestrator`, `coder`, and `reviewer`. It was not part of the current desired role profile set, and the former TUI `:ticket investigate` surface has already been removed.
|
||||
|
||||
Investigation/read-only research remains useful, but it should be modeled as a task-specific helper Pod spawned by Intake/Orchestrator/preflight when needed, not as a permanent fixed Ticket role with workspace config/profile slots.
|
||||
Investigation/read-only research remains useful, but it should be modeled as a task-specific helper Pod spawned by Intake/Orchestrator/planning when needed, not as a permanent fixed Ticket role with workspace config/profile slots.
|
||||
|
||||
## Goal
|
||||
|
||||
Remove `investigator` as a fixed Ticket role and clean up user/project-facing references while preserving the ability for Orchestrator/preflight flows to spawn read-only investigation helper Pods as ordinary task-specific Pods.
|
||||
Remove `investigator` as a fixed Ticket role and clean up user/project-facing references while preserving the ability for Orchestrator/planning flows to spawn read-only investigation helper Pods as ordinary task-specific Pods.
|
||||
|
||||
## Requirements
|
||||
|
||||
|
|
@ -34,7 +34,7 @@ Remove `investigator` as a fixed Ticket role and clean up user/project-facing re
|
|||
- Treat `[roles.investigator]` in current config according to the project’s desired compatibility policy; prefer a clear config error or documented migration over silently using an unsupported role.
|
||||
- Update launcher/client/TUI tests and prompt generation that currently mention or branch on `Investigator`.
|
||||
- Remove docs/workflow wording that presents `investigator` as a fixed role or configured role slot.
|
||||
- Preserve wording/behavior that allows Orchestrator/preflight to create read-only helper Pods for investigation when explicitly useful.
|
||||
- Preserve wording/behavior that allows Orchestrator/planning to create read-only helper Pods for investigation when explicitly useful.
|
||||
- Do not reintroduce the removed TUI `:ticket investigate` command surface.
|
||||
- Do not add a generic arbitrary role registry as part of this cleanup.
|
||||
|
||||
|
|
@ -42,7 +42,7 @@ Remove `investigator` as a fixed Ticket role and clean up user/project-facing re
|
|||
|
||||
- No runtime fixed-role enum/config/scaffold path exposes `investigator` as a Ticket role.
|
||||
- `yoi ticket init` no longer emits `[roles.investigator]`.
|
||||
- Project docs describe investigation as an optional helper-Pod activity under Intake/Orchestrator/preflight, not a configured Ticket role.
|
||||
- Project docs describe investigation as an optional helper-Pod activity under Intake/Orchestrator/planning, not a configured Ticket role.
|
||||
- Existing Ticket role launch flows for intake/orchestrator/coder/reviewer still work.
|
||||
- Focused tests for `ticket::config`, `client::ticket_role`, and any affected TUI role-launch/panel paths pass.
|
||||
- `target/debug/yoi ticket doctor`, `cargo fmt --check`, and `git diff --check` pass.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ status: open
|
|||
kind: task
|
||||
priority: P2
|
||||
labels: [ticket, intake, panel, git, workflow]
|
||||
workflow_state: intake
|
||||
workflow_state: planning
|
||||
created_at: 2026-06-07T22:06:06Z
|
||||
updated_at: 2026-06-07T22:06:06Z
|
||||
assignee: null
|
||||
|
|
@ -28,13 +28,13 @@ The project workflow treats Ticket records as git-authored project records, but
|
|||
|
||||
## Goal
|
||||
|
||||
Define and implement the commit policy for Ticket state transitions performed by Intake/Panel actions, especially `intake -> ready`.
|
||||
Define and implement the commit policy for Ticket state transitions performed by Intake/Panel actions, especially `planning -> ready`.
|
||||
|
||||
## Questions to resolve
|
||||
|
||||
- Should Intake/Panel auto-commit Ticket-only metadata/thread changes such as `intake -> ready`?
|
||||
- Should Intake/Panel auto-commit Ticket-only metadata/thread changes such as `planning -> ready`?
|
||||
- If yes, which actions are safe to auto-commit?
|
||||
- `intake -> ready`
|
||||
- `planning -> ready`
|
||||
- `ready -> queued`
|
||||
- `queued -> inprogress`
|
||||
- action_required / attention_required updates
|
||||
|
|
@ -56,7 +56,7 @@ Define and implement the commit policy for Ticket state transitions performed by
|
|||
## Acceptance criteria
|
||||
|
||||
- The project has an explicit documented policy for commits after Intake/Panel Ticket state changes.
|
||||
- `intake -> ready` behavior follows that policy consistently.
|
||||
- `planning -> ready` behavior follows that policy consistently.
|
||||
- Dirty Ticket-only state after a Panel/Intake action is either committed safely or clearly surfaced to the user.
|
||||
- Tests cover the selected behavior where practical.
|
||||
- `target/debug/yoi ticket doctor`, `cargo fmt --check`, and `git diff --check` pass.
|
||||
|
|
|
|||
|
|
@ -34,11 +34,11 @@ Observed bug:
|
|||
- `workspace-panel-nonblocking-transitions` has:
|
||||
|
||||
```yaml
|
||||
workflow_state: intake
|
||||
workflow_state: planning
|
||||
attention_required: null
|
||||
```
|
||||
|
||||
- Panel should derive `Clarify` from `workflow_state: intake`.
|
||||
- Panel should derive `Clarify` from `workflow_state: planning`.
|
||||
- Instead, `attention_required` is interpreted as set and Panel derives `Edit` with an `attention_required is set` blocker.
|
||||
|
||||
YAML `null` is valid YAML; the bug is that Ticket frontmatter is not consistently parsed as YAML/null-aware data.
|
||||
|
|
@ -71,7 +71,6 @@ At minimum verify:
|
|||
- `assignee`
|
||||
- `legacy_ticket`
|
||||
- `readiness`
|
||||
- `needs_preflight`
|
||||
- `risk_flags`
|
||||
- `action_required`
|
||||
- `workflow_state`
|
||||
|
|
@ -83,7 +82,7 @@ At minimum verify:
|
|||
## Acceptance criteria
|
||||
|
||||
- A Ticket with `attention_required: null` is parsed with `attention_required == None`.
|
||||
- A Ticket with `workflow_state: intake` and `attention_required: null` derives Panel action `Clarify`, not `Edit`.
|
||||
- A Ticket with `workflow_state: planning` and `attention_required: null` derives Panel action `Clarify`, not `Edit`.
|
||||
- Existing nullable fields no longer rely on per-field ad-hoc string `"null"` filtering.
|
||||
- YAML sequence labels/risk flags parse correctly.
|
||||
- Existing Ticket fixture tests and `target/debug/yoi ticket doctor` pass.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ status: open
|
|||
kind: task
|
||||
priority: P2
|
||||
labels: [ticket, workflow, git, process, cleanup]
|
||||
workflow_state: intake
|
||||
workflow_state: planning
|
||||
created_at: 2026-06-07T22:43:09Z
|
||||
updated_at: 2026-06-07T22:43:09Z
|
||||
assignee: null
|
||||
|
|
@ -18,7 +18,7 @@ legacy_ticket: null
|
|||
Recent Ticket-driven / multi-agent work has produced many small commits where most commits are Ticket record lifecycle events rather than implementation changes. A typical implemented Ticket currently creates commits such as:
|
||||
|
||||
```text
|
||||
ticket: preflight ...
|
||||
ticket: planning ...
|
||||
ticket: delegate ...
|
||||
feat/fix: ...
|
||||
ticket: report implementation ...
|
||||
|
|
@ -41,7 +41,7 @@ Define and implement a lower-noise commit policy for Ticket lifecycle records pr
|
|||
- Reduce commit count caused by one-event-per-commit Ticket record updates.
|
||||
- Define which Ticket lifecycle events should be batched together.
|
||||
- Candidate batching policy:
|
||||
- Combine preflight + delegation into one `ticket: delegate ...` commit when done in one orchestration step.
|
||||
- Combine planning + delegation into one `ticket: delegate ...` commit when done in one orchestration step.
|
||||
- Combine implementation report + reviewer approval into one `ticket: approve ...` commit when approval is known before committing the record.
|
||||
- Batch multiple newly discovered follow-up Tickets into one `ticket: add ... tasks` commit when created in the same conversation/decision burst.
|
||||
- Keep close commits separate when they move open -> closed and write `resolution.md`, unless a better policy is explicitly chosen.
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ title: Relax implementation planning readiness toward intent and reviewability
|
|||
status: open
|
||||
kind: task
|
||||
priority: P2
|
||||
labels: [workflow, ticket, orchestrator, preflight, review]
|
||||
labels: [workflow, ticket, orchestrator, planning, review]
|
||||
workflow_state: done
|
||||
created_at: 2026-06-07T23:00:44Z
|
||||
updated_at: 2026-06-07T23:38:32Z
|
||||
|
|
@ -17,15 +17,15 @@ queued_at: 2026-06-07T23:03:35Z
|
|||
|
||||
## Background
|
||||
|
||||
Current Intake / Preflight / Orchestrator workflow wording tends to require implementation strategy to be narrowed too early. In practice, the most reliable implementation investigation often happens when the implementation Pod/coder reads the code and attempts the change in the scoped worktree.
|
||||
Current Intake / Planning / Orchestrator workflow wording tends to require implementation strategy to be narrowed too early. In practice, the most reliable implementation investigation often happens when the implementation Pod/coder reads the code and attempts the change in the scoped worktree.
|
||||
|
||||
The higher-level planning/intake stage should prioritize clarifying intent, constraints, and reviewable outcomes rather than over-specifying the implementation approach. Reviewers need enough intent and acceptance criteria to judge whether the implementation matches the user's/project's intent; coders should retain room to discover the best local implementation path unless a design decision is explicitly fixed.
|
||||
|
||||
Current problem:
|
||||
|
||||
- Intake/Planning `ready` and Orchestrator `implementation_ready` are easy to interpret as requiring a nearly fixed implementation plan.
|
||||
- Orchestrator may over-classify tickets as `preflight_needed` when some uncertainty could safely be resolved by the coder during implementation and checked by reviewer.
|
||||
- This creates extra preflight churn and can make the workflow feel stalled.
|
||||
- Orchestrator may over-return Tickets to planning when some uncertainty could safely be resolved by the coder during implementation and checked by reviewer.
|
||||
- This creates extra planning-return churn and can make the workflow feel stalled.
|
||||
|
||||
Desired direction:
|
||||
|
||||
|
|
@ -33,11 +33,11 @@ Desired direction:
|
|||
- Keep implementation judgment available to the coder where safe.
|
||||
- Make reviewer validation against intent the key quality gate.
|
||||
- Treat explicit design decisions/invariants as binding when present.
|
||||
- Use preflight for genuine design-boundary/product/API/authority uncertainty, not every implementation unknown.
|
||||
- Use return-to-planning for genuine design-boundary/product/API/authority uncertainty, not every implementation unknown.
|
||||
|
||||
## Goal
|
||||
|
||||
Adjust Ticket Intake/Planning, Orchestrator routing, and Preflight workflow guidance so readiness is based on clear intent and reviewability, while preserving coder discretion for implementation details unless constrained by explicit decisions.
|
||||
Adjust Ticket Intake/Planning, Orchestrator routing, and Planning workflow guidance so readiness is based on clear intent and reviewability, while preserving coder discretion for implementation details unless constrained by explicit decisions.
|
||||
|
||||
## Requirements
|
||||
|
||||
|
|
@ -55,13 +55,13 @@ Adjust Ticket Intake/Planning, Orchestrator routing, and Preflight workflow guid
|
|||
|
||||
### Orchestrator routing
|
||||
|
||||
- Narrow `preflight_needed` so it is reserved for real design/product/API/authority-boundary uncertainty, not ordinary code investigation or implementation tactic selection.
|
||||
- Narrow return-to-planning so it is reserved for real design/product/API/authority-boundary uncertainty, not ordinary code investigation or implementation tactic selection.
|
||||
- Make `implementation_ready` allow bounded implementation uncertainty when:
|
||||
- intent and acceptance criteria are clear;
|
||||
- coder can investigate safely within scope;
|
||||
- reviewer can evaluate against recorded intent;
|
||||
- escalation conditions are defined.
|
||||
- Keep `preflight_needed` for cases where implementing would implicitly decide product/API/UX/authority boundaries or violate known design constraints.
|
||||
- Keep return-to-planning for cases where implementing would implicitly decide product/API/UX/authority boundaries or violate known design constraints.
|
||||
- Require Orchestrator to record whether implementation latitude is allowed and what must be escalated.
|
||||
|
||||
### Coder/reviewer handoff
|
||||
|
|
@ -77,13 +77,13 @@ Adjust Ticket Intake/Planning, Orchestrator routing, and Preflight workflow guid
|
|||
|
||||
- Update `.yoi/workflow/ticket-intake-workflow.md`.
|
||||
- Update `.yoi/workflow/ticket-orchestrator-routing.md`.
|
||||
- Update `.yoi/workflow/ticket-preflight-workflow.md`.
|
||||
- Update the planning/requirements-sync workflow guidance.
|
||||
- Update `.yoi/workflow/multi-agent-workflow.md` if needed to reflect coder latitude and reviewer intent-checking.
|
||||
- Adjust role prompt wording/tests if generated prompt guidance currently over-demands pre-decided implementation plans.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- Do not remove preflight; narrow when it is required.
|
||||
- Do not remove return-to-planning; narrow when it is required.
|
||||
- Do not allow coders to make product/API/authority decisions silently.
|
||||
- Do not weaken explicit design decisions or invariants recorded by humans/Orchestrator.
|
||||
- Do not change Ticket state machine names in this ticket unless it is already being handled by the planning-state rename work.
|
||||
|
|
@ -91,9 +91,9 @@ Adjust Ticket Intake/Planning, Orchestrator routing, and Preflight workflow guid
|
|||
## Acceptance criteria
|
||||
|
||||
- Workflows clearly distinguish ready-for-routing, implementation handoff, and fully specified implementation plan.
|
||||
- Orchestrator routing guidance no longer treats ordinary implementation investigation as automatic `preflight_needed`.
|
||||
- Orchestrator routing guidance no longer treats ordinary implementation investigation as automatic return-to-planning.
|
||||
- Intent packet template includes sections for binding decisions, implementation latitude, and escalation conditions.
|
||||
- Reviewer guidance focuses on intent/constraints/acceptance criteria and explicit decisions.
|
||||
- Example wording makes clear that coder investigation is acceptable when intent is clear and risks are bounded.
|
||||
- Existing Ticket/preflight tests or prompt tests are updated if affected.
|
||||
- Existing Ticket planning/routing tests or prompt tests are updated if affected.
|
||||
- `target/debug/yoi ticket doctor`, `cargo fmt --check`, and `git diff --check` pass.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ status: 'open'
|
|||
kind: 'task'
|
||||
priority: 'P1'
|
||||
labels: ['ticket', 'orchestrator', 'planning', 'panel', 'taskstore', 'queue']
|
||||
workflow_state: 'intake'
|
||||
workflow_state: planning
|
||||
created_at: '2026-06-08T06:12:35Z'
|
||||
updated_at: '2026-06-08T06:27:33Z'
|
||||
assignee: null
|
||||
|
|
@ -22,7 +22,7 @@ ready -> queued
|
|||
-> notify workspace Orchestrator
|
||||
```
|
||||
|
||||
That is not enough for robust orchestration. Queued Tickets can remain after missed notifications, Orchestrator restarts, preflight returns, capacity limits, or multi-ticket coordination. The Orchestrator also needs a lightweight way to remember planned queued work across turns without relying only on session memory.
|
||||
That is not enough for robust orchestration. Queued Tickets can remain after missed notifications, Orchestrator restarts, planning returns, capacity limits, or multi-ticket coordination. The Orchestrator also needs a lightweight way to remember planned queued work across turns without relying only on session memory.
|
||||
|
||||
There is an existing related Ticket:
|
||||
|
||||
|
|
@ -44,7 +44,7 @@ The OrchestrationPlan store should distinguish at least:
|
|||
|
||||
- `new_queued`: Tickets with `workflow_state = queued` that have not yet been incorporated into the OrchestrationPlan.
|
||||
- `planned_queued`: queued Tickets that the Orchestrator has considered and placed into an explicit plan/order/waiting set, but has not yet accepted as `inprogress`.
|
||||
- `inprogress`: Tickets accepted by the Orchestrator and currently awaiting worktree/coder/reviewer/preflight/merge/cleanup progress.
|
||||
- `inprogress`: Tickets accepted by the Orchestrator and currently awaiting worktree/coder/reviewer/planning-sync/merge/cleanup progress.
|
||||
|
||||
The names do not need to become final public API names, but the state distinction is required.
|
||||
|
||||
|
|
@ -55,7 +55,7 @@ The names do not need to become final public API names, but the state distinctio
|
|||
- Provide a mechanism to identify Tickets that need Orchestrator attention, including at least:
|
||||
- `workflow_state = queued` Tickets not yet present in the OrchestrationPlan (`new_queued`);
|
||||
- planned queued Tickets that are not blocked/capacity-limited and can be started when there is no active in-progress work;
|
||||
- `workflow_state = inprogress` Tickets accepted by Orchestrator whose next action is not merely waiting for an active coder/reviewer/preflight/merge step;
|
||||
- `workflow_state = inprogress` Tickets accepted by Orchestrator whose next action is not merely waiting for an active coder/reviewer/planning-sync/merge step;
|
||||
- queued Tickets left behind after Orchestrator restart, missed notification, or previous capacity stop.
|
||||
- On Panel open/Orchestrator restore/spawn, or explicit user action, surface a bounded work list to the Orchestrator when there is actionable work.
|
||||
- Avoid unbounded background polling. Prefer explicit events, Panel lifecycle kick, and explicit user/Orchestrator actions.
|
||||
|
|
@ -65,7 +65,7 @@ The names do not need to become final public API names, but the state distinctio
|
|||
|
||||
- If `new_queued` work exists and the Orchestrator is idle/not occupied by an active in-progress operation, kick or notify the Orchestrator so it can incorporate those Tickets into the plan.
|
||||
- If no active `inprogress` work exists and runnable `planned_queued` work exists, kick or notify the Orchestrator so it can accept/start the next planned Ticket rather than waiting indefinitely for user instruction.
|
||||
- If active `inprogress` work exists and the next expected event is coder/reviewer/preflight/merge completion, do not re-kick merely because queued/planned queued work also exists.
|
||||
- If active `inprogress` work exists and the next expected event is coder/reviewer/planning-sync/merge completion, do not re-kick merely because queued/planned queued work also exists.
|
||||
- If planned queued work is blocked, dependency-waiting, conflict-waiting, or capacity-limited, record the reason so the Panel/user can see why nothing starts.
|
||||
- A re-kick is an attention signal plus bounded context, not authority to bypass `queued -> inprogress` acceptance or spawn implementation Pods without inspection.
|
||||
|
||||
|
|
@ -116,7 +116,7 @@ The names do not need to become final public API names, but the state distinctio
|
|||
|
||||
- Do not turn the Panel itself into the scheduler.
|
||||
- Do not auto-start unqueued Tickets.
|
||||
- Do not re-kick continuously while active coder/reviewer/preflight/merge work is already in progress.
|
||||
- Do not re-kick continuously while active coder/reviewer/planning-sync/merge work is already in progress.
|
||||
- Do not blindly spawn coder Pods from re-kick without Orchestrator inspection and `queued -> inprogress` acceptance.
|
||||
- Do not implement a full dependency graph solver in the first version.
|
||||
|
||||
|
|
@ -125,7 +125,7 @@ The names do not need to become final public API names, but the state distinctio
|
|||
- The system can distinguish new queued work, planned queued work, and accepted in-progress work.
|
||||
- New queued Tickets are not left unnoticed while the Orchestrator is otherwise idle.
|
||||
- Runnable planned queued Tickets are not left unstarted when there is no active in-progress work and capacity/policy allows progress.
|
||||
- The system does not re-kick merely because queued/planned work exists while Orchestrator-managed in-progress work is waiting on coder/reviewer/preflight/merge completion.
|
||||
- The system does not re-kick merely because queued/planned work exists while Orchestrator-managed in-progress work is waiting on coder/reviewer/planning-sync/merge completion.
|
||||
- Missed/stale queued Tickets can be surfaced to the Orchestrator without requiring the user to manually requeue each one.
|
||||
- The Orchestrator can record and query a lightweight Ticket orchestration plan covering active targets, order/dependency/conflict/capacity, state bucket, and next actions.
|
||||
- Plan records survive compaction and do not rely solely on session-lifetime TaskStore state.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ status: 'open'
|
|||
kind: 'task'
|
||||
priority: 'P1'
|
||||
labels: ['ticket', 'orchestrator', 'planning', 'workflow', 'prompt']
|
||||
workflow_state: 'intake'
|
||||
workflow_state: planning
|
||||
created_at: '2026-06-08T07:17:22Z'
|
||||
updated_at: '2026-06-08T07:17:22Z'
|
||||
assignee: null
|
||||
|
|
@ -15,9 +15,9 @@ legacy_ticket: null
|
|||
|
||||
## Background
|
||||
|
||||
`replace-intake-state-with-planning` removes the standalone `preflight` concept and represents implementation-readiness gaps as a return to the `planning` lane with a visible reason.
|
||||
`replace-intake-state-with-planning` represents implementation-readiness gaps as a return to the `planning` lane with a visible reason.
|
||||
|
||||
That creates an important follow-up requirement for Orchestrator routing: returning a Ticket to planning must not become the new form of blind preflight rejection. The Orchestrator should not look only at Ticket text, `risk_flags`, or broad risky domains and decide to stop. It must consider relevant project context before deciding that implementation cannot proceed.
|
||||
That creates an important follow-up requirement for Orchestrator routing: returning a Ticket to planning must not become the new form of blind planning rejection. The Orchestrator should not look only at Ticket text, `risk_flags`, or broad risky domains and decide to stop. It must consider relevant project context before deciding that implementation cannot proceed.
|
||||
|
||||
The recent `allow-spawnpod-child-workspace-cwd` discussion exposed the failure mode: a Ticket can touch authority/Pod/scope areas while still containing enough binding decisions and acceptance criteria to route to implementation. In that case, risk should become reviewer focus and escalation conditions, not an automatic return to planning.
|
||||
|
||||
|
|
@ -28,7 +28,7 @@ Update Orchestrator routing guidance so a Ticket is returned to planning only wh
|
|||
## Requirements
|
||||
|
||||
- Treat this as a follow-up to `replace-intake-state-with-planning`.
|
||||
- First remove/fold the standalone `preflight` concept into planning.
|
||||
- First settle the planning-state model.
|
||||
- Then apply this policy to the Orchestrator's return-to-planning decision.
|
||||
- Update `ticket-orchestrator-routing` or equivalent prompt/workflow guidance.
|
||||
- Before returning a queued/ready Ticket to planning, the Orchestrator must inspect enough context to distinguish:
|
||||
|
|
@ -52,7 +52,7 @@ Update Orchestrator routing guidance so a Ticket is returned to planning only wh
|
|||
|
||||
## Non-goals
|
||||
|
||||
- Reintroducing `preflight` as a separate operation, state, or lane.
|
||||
- Reintroducing a separate readiness-check operation, state, or lane outside planning.
|
||||
- Making every queued Ticket require extensive code archaeology.
|
||||
- Removing Orchestrator judgment; the point is to make the judgment evidence-based.
|
||||
- Letting coder Pods silently decide product/API/authority boundaries that are genuinely missing.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ status: 'open'
|
|||
kind: 'task'
|
||||
priority: 'P1'
|
||||
labels: ['ticket', 'relations', 'planning', 'panel', 'orchestrator']
|
||||
workflow_state: 'intake'
|
||||
workflow_state: planning
|
||||
created_at: '2026-06-08T07:27:32Z'
|
||||
updated_at: '2026-06-08T07:28:29Z'
|
||||
assignee: null
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user