yoi/.yoi/tickets/open/20260607-220606-define-ticket-action-commit-policy/item.md

id	slug	title	status	kind	priority	labels	workflow_state	created_at	updated_at	assignee	legacy_ticket
20260607-220606-define-ticket-action-commit-policy	define-ticket-action-commit-policy	Define commit policy for Ticket state changes from Intake and Panel	open	task	P2	ticket intake panel git workflow	planning	2026-06-07T22:06:06Z	2026-06-07T22:06:06Z	null	null

Background

Ticket state changes such as moving a Ticket from intake to ready modify .yoi/tickets/.../item.md and append thread events. During panel/Intake dogfooding, a Ticket can become ready from UI/action flow and leave the repository dirty without an automatic commit.

Example observed after panel interaction:

M .yoi/tickets/open/20260607-213808-remove-workspace-panel-bare-letter-shortcuts/item.md
M .yoi/tickets/open/20260607-213808-remove-workspace-panel-bare-letter-shortcuts/thread.md

The project workflow treats Ticket records as git-authored project records, but it is currently unclear whether Intake/Panel actions should auto-commit such state transitions, prompt the user/orchestrator to commit, or intentionally leave them dirty.

Goal

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 planning -> ready?
• If yes, which actions are safe to auto-commit?
  • planning -> ready
  • ready -> queued
  • queued -> inprogress
  • action_required / attention_required updates
  • comments / intake summaries
• If no, how should the UI clearly surface that a Ticket state transition left project records dirty and needs a human/orchestrator commit?
• Should commit authority differ between Companion, Intake, Orchestrator, and typed Ticket tools?
• How should this interact with worktree-based implementation branches and main workspace authority?

Requirements

• Preserve git history as the authoritative timeline for Ticket state transitions.
• Avoid surprising broad auto-commits that include unrelated user changes.
• If auto-commit is implemented, stage only the exact Ticket paths touched by the action and use concise conventional commit messages.
• If auto-commit is not implemented, add clear UI/actionbar/diagnostic guidance when Ticket actions leave dirty Ticket files.
• Ensure Panel/Intake flows do not silently leave users thinking a transition is fully recorded when git state still needs attention.
• Do not change Ticket workflow-state semantics in this ticket unless required to express commit policy.
• Do not auto-commit implementation code changes or child worktree changes as part of Ticket action handling.

Acceptance criteria

• The project has an explicit documented policy for commits after Intake/Panel Ticket state changes.
• 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.