diff --git a/.yoi/tickets/open/20260607-224309-reduce-ticket-lifecycle-commit-noise/artifacts/.gitkeep b/.yoi/tickets/open/20260607-224309-reduce-ticket-lifecycle-commit-noise/artifacts/.gitkeep new file mode 100644 index 00000000..e69de29b diff --git a/.yoi/tickets/open/20260607-224309-reduce-ticket-lifecycle-commit-noise/item.md b/.yoi/tickets/open/20260607-224309-reduce-ticket-lifecycle-commit-noise/item.md new file mode 100644 index 00000000..755fe43f --- /dev/null +++ b/.yoi/tickets/open/20260607-224309-reduce-ticket-lifecycle-commit-noise/item.md @@ -0,0 +1,60 @@ +--- +id: 20260607-224309-reduce-ticket-lifecycle-commit-noise +slug: reduce-ticket-lifecycle-commit-noise +title: Reduce Ticket lifecycle commit noise +status: open +kind: task +priority: P2 +labels: [ticket, workflow, git, process, cleanup] +workflow_state: intake +created_at: 2026-06-07T22:43:09Z +updated_at: 2026-06-07T22:43:09Z +assignee: null +legacy_ticket: null +--- + +## Background + +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: delegate ... +feat/fix: ... +ticket: report implementation ... +ticket: approve ... +merge: ... +ticket: close ... +``` + +This keeps a detailed audit trail, but it makes project history look noisy and overly fine-grained. Recent examples also include many one-off follow-up Ticket creation commits and automated Panel/Orchestrator record commits. + +The desired direction is to keep the Ticket audit trail, but reduce commit count by batching compatible Ticket record updates into fewer, more meaningful commits. + +## Goal + +Define and implement a lower-noise commit policy for Ticket lifecycle records produced by manual orchestration, Panel actions, Intake, and multi-agent workflows. + +## Requirements + +- Preserve git history as the authoritative timeline for Ticket records. +- 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 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. +- Decide how automated Panel/Intake/Orchestrator Ticket updates should be committed or surfaced so they do not create excessive micro-commits. +- Update relevant workflow docs/prompts so agents stop committing every single Ticket event mechanically. +- Avoid losing important review/approval evidence; batching should change commit grouping, not remove Ticket thread events. +- Avoid broad history rewriting as part of implementation unless explicitly requested. + +## Acceptance criteria + +- Workflows document the preferred lower-noise commit grouping for Ticket lifecycle events. +- Agents following `/multi-agent-workflow`, `/worktree-workflow`, and Ticket role flows have clear guidance on when to batch Ticket records. +- Ticket close / merge / approval evidence remains auditable in files. +- Automated Panel/Intake/Orchestrator Ticket updates have a documented commit/dirty-state policy aligned with `define-ticket-action-commit-policy` or reference that ticket if it remains separate. +- No implementation code changes are mixed with this policy update unless required for automation support. +- `target/debug/yoi ticket doctor`, `cargo fmt --check`, and `git diff --check` pass. diff --git a/.yoi/tickets/open/20260607-224309-reduce-ticket-lifecycle-commit-noise/thread.md b/.yoi/tickets/open/20260607-224309-reduce-ticket-lifecycle-commit-noise/thread.md new file mode 100644 index 00000000..8204b4ae --- /dev/null +++ b/.yoi/tickets/open/20260607-224309-reduce-ticket-lifecycle-commit-noise/thread.md @@ -0,0 +1,7 @@ + + +## Created + +Created by LocalTicketBackend create. + +--- diff --git a/.yoi/tickets/open/20260607-225448-replace-intake-state-with-planning/artifacts/.gitkeep b/.yoi/tickets/open/20260607-225448-replace-intake-state-with-planning/artifacts/.gitkeep new file mode 100644 index 00000000..e69de29b diff --git a/.yoi/tickets/open/20260607-225448-replace-intake-state-with-planning/item.md b/.yoi/tickets/open/20260607-225448-replace-intake-state-with-planning/item.md new file mode 100644 index 00000000..ab08ecb8 --- /dev/null +++ b/.yoi/tickets/open/20260607-225448-replace-intake-state-with-planning/item.md @@ -0,0 +1,90 @@ +--- +id: 20260607-225448-replace-intake-state-with-planning +slug: replace-intake-state-with-planning +title: Replace Ticket intake state with planning state +status: open +kind: task +priority: P1 +labels: [ticket, workflow-state, orchestrator, panel, intake, planning] +workflow_state: intake +created_at: 2026-06-07T22:54:48Z +updated_at: 2026-06-07T22:54:48Z +assignee: null +legacy_ticket: null +--- + +## Background + +The Ticket workflow state `intake` is currently used for more than initial intake. It also represents clarification, requirements synchronization, and preflight/planning work before a Ticket is implementation-ready. + +This naming is misleading in panel/orchestration flows: + +- A Ticket can be returned from Orchestrator routing because implementation requires preflight or requirements clarification. +- Such a Ticket should go back to the planning/clarification lane, not appear as a brand-new intake item. +- Current Orchestrator `preflight_needed` behavior can look like nothing happened because it may only comment and avoid starting coder Pods. +- Users need a visible state/action that says the Ticket is under planning / needs planning work. + +Desired direction: + +- Remove `intake` as the user-facing workflow state name. +- Replace it with a planning-oriented state such as `planning` or `under_planning`. +- Orchestrator `preflight_needed` / requirements-sync-needed routing should return the Ticket to this planning state and notify any active Intake/Planning Pod if one exists. + +## Goal + +Rename/reframe Ticket `workflow_state = intake` into a planning-oriented state and make Orchestrator preflight-needed routing visibly return Tickets to that lane instead of silently stalling. + +## Requirements + +### State model / migration + +- Replace `intake` in the Ticket workflow-state model with a planning-oriented state name. + - Candidate names: `planning`, `under_planning`, or another concise name chosen during implementation. + - Prefer a name that communicates requirements clarification / preflight preparation, not only initial intake. +- Define migration behavior for existing Tickets with `workflow_state: intake`. + - Either migrate records to the new value or support legacy `intake` as an input alias with normalized output. +- Update typed transition graph accordingly. + - Existing start path becomes `planning -> ready -> queued -> inprogress -> done`. + - Allow Orchestrator to route `queued` or `ready` back to `planning` when preflight/requirements sync is needed, with a reason. +- Update CLI, Ticket tools, TUI panel, prompts, workflow docs, and tests that refer to `intake` as a workflow state. +- Keep the Intake role name separate if still useful for the Pod/persona; this ticket is about workflow state naming and lane semantics. + +### Orchestrator preflight-needed behavior + +- When Orchestrator determines `preflight_needed` or requirements-sync-needed: + - Do not start coder Pods. + - Record a typed routing/state-change event with a clear reason. + - Return the Ticket to the planning state, or otherwise ensure the planning lane visibly owns it. + - Surface the reason in Panel/Ticket UI so the user can see why implementation did not start. +- If a live/restorable Intake/Planning Pod claim exists for that Ticket, notify/send it the routing-back reason and requested planning/preflight action. +- If no such Pod exists, Panel should show that planning/clarification/preflight attention is needed and provide the existing launch path. +- Preserve auditability: the state transition and reason must be recorded in Ticket files/thread. + +### UI / terminology + +- Replace user-facing `intake` workflow-state labels in Panel and docs with the chosen planning-oriented label. +- Clarify that this lane covers: + - initial Ticket clarification; + - requirements synchronization; + - preflight preparation; + - Orchestrator return-to-planning decisions. +- Avoid confusing `Intake` role/profile naming with the workflow state if the role remains named Intake. + +## Non-goals + +- Do not redesign the entire Ticket workflow state machine beyond replacing/reframing `intake` and adding return-to-planning behavior. +- Do not remove the Intake Pod role/profile unless a separate decision is made. +- Do not implement arbitrary role registries. +- Do not change implementation worktree/coder/reviewer mechanics except where Orchestrator routing needs to return to planning. + +## Acceptance criteria + +- New/updated Tickets use the planning-oriented workflow-state name instead of `intake`. +- Existing `workflow_state: intake` Tickets are migrated or parsed compatibly and emitted in the new form according to the chosen policy. +- Panel no longer presents the state as simply `intake`; it shows planning/clarification/preflight terminology. +- Orchestrator `preflight_needed` routing produces a visible state/typed event and returns the Ticket to the planning lane. +- A claimed live/restorable Intake/Planning Pod is notified when Orchestrator returns a Ticket for planning/preflight. +- Without a claimed Pod, Panel clearly shows planning/preflight attention is needed and provides a launch path. +- Tests cover state parsing/migration, transition graph, Panel action derivation, and Orchestrator return-to-planning behavior. +- Relevant docs/workflows are updated. +- `target/debug/yoi ticket doctor`, focused `cargo test` suites, `cargo fmt --check`, and `git diff --check` pass. diff --git a/.yoi/tickets/open/20260607-225448-replace-intake-state-with-planning/thread.md b/.yoi/tickets/open/20260607-225448-replace-intake-state-with-planning/thread.md new file mode 100644 index 00000000..aecfeb35 --- /dev/null +++ b/.yoi/tickets/open/20260607-225448-replace-intake-state-with-planning/thread.md @@ -0,0 +1,7 @@ + + +## Created + +Created by LocalTicketBackend create. + +--- diff --git a/.yoi/tickets/open/20260607-230044-relax-implementation-planning-readiness/item.md b/.yoi/tickets/open/20260607-230044-relax-implementation-planning-readiness/item.md index d90e8b2d..7cfeac7c 100644 --- a/.yoi/tickets/open/20260607-230044-relax-implementation-planning-readiness/item.md +++ b/.yoi/tickets/open/20260607-230044-relax-implementation-planning-readiness/item.md @@ -8,7 +8,7 @@ priority: P2 labels: [workflow, ticket, orchestrator, preflight, review] workflow_state: queued created_at: 2026-06-07T23:00:44Z -updated_at: 2026-06-07T23:03:58Z +updated_at: 2026-06-07T23:08:01Z assignee: null legacy_ticket: null queued_by: workspace-panel diff --git a/.yoi/tickets/open/20260607-230044-relax-implementation-planning-readiness/thread.md b/.yoi/tickets/open/20260607-230044-relax-implementation-planning-readiness/thread.md index 8276f1e0..891b1a51 100644 --- a/.yoi/tickets/open/20260607-230044-relax-implementation-planning-readiness/thread.md +++ b/.yoi/tickets/open/20260607-230044-relax-implementation-planning-readiness/thread.md @@ -63,3 +63,26 @@ Escalate if: - Prompt/resource changes are required beyond workflow docs and need separate validation scope. --- + + + +## Decision + +## Human decision: human-provided intent can satisfy preflight boundary for this policy cleanup + +This Ticket itself exists to relax over-eager preflight/planning gates. The current Orchestrator routed it as `preflight_needed` mainly because Intake recorded `needs_preflight: true` and risk flags such as `workflow-policy`, `orchestration-semantics`, `reviewer-handoff`, and `prompt-guidance`. + +That reaction is useful evidence for the problem this Ticket should fix: current guidance can mechanically classify workflow-policy changes as preflight-needed even when the human has already provided the intended boundary. + +For this Ticket, additional preflight is not required before implementation if the implementation follows this human decision: + +- Prioritize clarifying user/project intent over freezing implementation tactics early. +- Leave bounded implementation-investigation latitude to the coder when the intent, constraints, and acceptance criteria are clear enough for review. +- Reviewer should judge whether the implementation matches recorded intent, explicit constraints, acceptance criteria, and binding design decisions. +- If a design approach/invariant is explicitly recorded by the human, Orchestrator, or Ticket thread, the coder must follow it or escalate/record a justified deviation. +- Preflight remains mandatory when implementation would otherwise silently decide product/API/UX/authority-boundary questions or weaken explicit design constraints. +- `needs_preflight: true` and risk flags should be treated as strong signals, not unconditional hard blockers, when a human decision has already supplied the missing policy boundary. + +Implementation should use this as the binding policy boundary and update workflow wording accordingly. Escalate only if the wording would weaken authority/product/API/design-boundary gates rather than narrowing unnecessary preflight churn. + +---