ticket: add workflow policy cleanup tasks

.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.

.yoi/tickets/open/20260607-224309-reduce-ticket-lifecycle-commit-noise/thread.md

@@ -0,0 +1,7 @@
+<!-- event: create author: LocalTicketBackend at: 2026-06-07T22:43:09Z -->
+
+## Created
+
+Created by LocalTicketBackend create.
+
+---

.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.

.yoi/tickets/open/20260607-225448-replace-intake-state-with-planning/thread.md

@@ -0,0 +1,7 @@
+<!-- event: create author: LocalTicketBackend at: 2026-06-07T22:54:48Z -->
+
+## Created
+
+Created by LocalTicketBackend create.
+
+---

.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

.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.
 
 ---
+
+<!-- event: decision author: hare at: 2026-06-07T23:08:01Z -->
+
+## 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.
+
+---