55 lines
2.9 KiB
Markdown
55 lines
2.9 KiB
Markdown
---
|
|
title: "Define commit policy for Ticket state changes from Intake and Panel"
|
|
state: 'closed'
|
|
created_at: "2026-06-07T22:06:06Z"
|
|
updated_at: '2026-06-11T08:08:44Z'
|
|
---
|
|
|
|
## 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:
|
|
|
|
```text
|
|
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.
|