ticket: simplify ticket identity fields

2026-06-09 11:57:15 +09:00
parent 48efcc7dfb
commit 191a875f5a
747 changed files with 1311 additions and 2600 deletions
@@ -8,7 +8,7 @@ requires: []

 yoi を yoi で開発する際の、worktree + coder Pod + 外部 reviewer Pod + orchestrator Pod の標準フロー。これは **最上位 Pod が細かい code review を抱えず、下位 orchestrator が実装と外部レビューの loop を完了状態まで運ぶためのフロー** である。

-worktree の機械的作成手順は `$user/worktree-workflow`、ユーザー依頼の Ticket 化は `$user/ticket-intake-workflow`、Ticket の next action 分類は `$user/ticket-orchestrator-routing`、実装前の planning/requirements sync は compatibility slug `$user/ticket-preflight-workflow` に分ける。
+worktree の機械的作成手順は `$user/worktree-workflow`、ユーザー依頼の Ticket 化は `$user/ticket-intake-workflow`、Ticket の next action 分類は `$user/ticket-orchestrator-routing`、実装前の planning/requirements sync は compatibility canonical id `$user/ticket-preflight-workflow` に分ける。

 この Workflow は、対象 ticket が implementation-ready であることを前提にする。implementation-ready は full implementation plan ではなく、recorded intent / binding decisions / invariants / implementation latitude / acceptance criteria / escalation conditions に基づいて coder が bounded investigation を進め、reviewer が判断できる状態を指す。設計境界・仕様・authority boundary が未同期の場合は、worktree 作成や coder Pod 起動の前に planning/requirements sync 互換入口として `ticket-preflight-workflow` を通す。

@@ -105,7 +105,7 @@ reviewer には coder の実装方針ではなく、この intent packet と dif
 下位 orchestrator を挟まない場合は、以下を最上位 orchestrator が行う。下位 orchestrator を挟む場合は、最上位は intent packet を渡し、以下の実務を下位に委譲する。

 1. 状態確認
-   - `git status --short --branch`
+   - `git state --short --branch`
   - 対象 ticket / ticket 群
   - 関連 TODO / docs / 既存 worktree
   - planning sync が必要な ticket では、互換入口 `ticket-preflight-workflow` の分類・要件同期・critical risks
@@ -131,7 +131,7 @@ reviewer には coder の実装方針ではなく、この intent packet と dif

 4. coder 完了確認
   - `ReadPodOutput` で報告を読む。
-   - 通知が来ない場合でも、worktree の `git status` / `git diff` / test で完了状態を確認する。
+   - 通知が来ない場合でも、worktree の `git state` / `git diff` / test で完了状態を確認する。
   - coder が止まった場合、worktree 状態を見て再 spawn / rollback / 親 escalation を判断する。

 5. reviewer Pod spawn
@@ -39,7 +39,7 @@ Intake は以下を行う。
 - 不足している要件を質問する。
 - 作成または refinement する Ticket が、実装・レビュー・検証・完了判断を単独で行える concrete work item であるか確認する。
 - 広い依頼を分割する場合は、進捗コンテナとしての umbrella Ticket ではなく、concrete Ticket / Objective context / split decision record に責務を分ける。
- Ticket の title / slug / kind / priority / labels を提案する。
+- Ticket の title / canonical id / kind / priority / labels を提案する。
 - background / requirements / acceptance criteria / escalation conditions を整理する。
 - binding decisions / invariants と implementation latitude を分けて書く。
 - 具体的な除外や触れてはいけない境界が binding decision である場合は、generic な除外リストではなく invariant / escalation condition として明記する。
@@ -70,7 +70,7 @@ Intake は以下を行う。
 - `TicketComment`: 既存 Ticket refinement / decision / plan の記録。
 - `TicketDoctor`: 必要に応じた整合性確認。

-Intake は `TicketReview`, `TicketStatus`, `TicketClose` を通常使わない。review / status transition / close は Orchestrator または reviewer / maintainer workflow の責務である。
+Intake は `TicketReview`, `TicketStatus`, `TicketClose` を通常使わない。review / state transition / close は Orchestrator または reviewer / maintainer workflow の責務である。

 Ticket tools が利用できない環境では、勝手に file write で代替しない。ユーザーまたは Orchestrator に「Ticket tools がないため materialize できない」と報告し、必要なら `yoi ticket` を使える人間/親 workflow に戻す。

@@ -223,7 +223,7 @@ Related tickets/docs:
 新規 Ticket の場合:

 - `TicketCreate` を使う。
- title / slug / kind / priority / labels / body を指定する。
+- title / canonical id / kind / priority / labels / body を指定する。
 - body に readiness / open questions / risk flags と、binding decisions / invariants、implementation latitude、escalation conditions を Markdown で明記する。

 既存 Ticket refinement の場合:
@@ -236,7 +236,7 @@ Related tickets/docs:

 ユーザーへ以下を返す。

- 作成/更新した Ticket id / slug / title。
+- 作成/更新した Ticket id / canonical id / title。
 - readiness。
 - open questions / risk flags。
 - 次に Orchestrator が取るべき routing 候補。
@@ -293,6 +293,6 @@ Ticket の body は Markdown/freeform を維持する。すべてを strict sche

 ## 他 Workflow への接続

- `ticket-preflight-workflow`: legacy compatibility slug の planning/requirements sync 入口。新規 routing は standalone preflight ではなく planning return/requirements sync として扱う。
+- `ticket-preflight-workflow`: legacy compatibility canonical id の planning/requirements sync 入口。新規 routing は standalone preflight ではなく planning return/requirements sync として扱う。
 - `multi-agent-workflow`: Orchestrator が implementation_ready と判断した後に接続する。
 - `ticket-orchestrator-routing`: この Workflow が作った Ticket を routing する後続 Workflow。
@@ -25,9 +25,9 @@ TicketCreate / TicketComment
  -> 必要に応じて他 Workflow へ接続
 ```

- Intake は Ticket の materialization と planning/clarification を担当する role であり、workflow_state 名ではない。
- workflow_state は `planning -> ready -> queued -> inprogress -> done` を基本遷移とする。
- `ticket-preflight-workflow` は legacy slug 互換の planning/requirements sync entry であり、`preflight` を独立 state / lane / long-lived operation として扱わない。
+- Intake は Ticket の materialization と planning/clarification を担当する role であり、state 名ではない。
+- state は `planning -> ready -> queued -> inprogress -> done` を基本遷移とする。
+- `ticket-preflight-workflow` は legacy canonical id 互換の planning/requirements sync entry であり、`preflight` を独立 state / lane / long-lived operation として扱わない。
 - `ready -> queued` は人間が Orchestrator routing を許可した状態であり、worktree 作成や Pod 起動の許可そのものではない。
 - `multi-agent-workflow` は coder / reviewer Pod と worktree を使う実装・レビュー loop。
 - この Workflow は自動 scheduler / lease / unattended maintainer ではない。
@@ -74,7 +74,7 @@ Orchestrator は以下を行う。
 - `TicketStatus`: pending/open などの状態整理が明示的に許可された場合だけ使う。
 - `TicketWorkflowState`: `queued -> inprogress` acceptance、`inprogress -> done`、または concrete missing decision/information reason を伴う `ready|queued -> planning` に使う。
 - `TicketOrchestrationPlanQuery`: 対象 Ticket や関連 Ticket の ordering / blocker / conflict / waiting-capacity / accepted-plan 記録を読む。queued acceptance 前に必ず確認する。
- `TicketOrchestrationPlanRecord`: Orchestrator が routing 中に project-relevant な ordering / dependency / conflict / capacity/waiting / accepted-plan decision を残す。これは queue reorder、自動起動、workflow_state 変更ではない。
+- `TicketOrchestrationPlanRecord`: Orchestrator が routing 中に project-relevant な ordering / dependency / conflict / capacity/waiting / accepted-plan decision を残す。これは queue reorder、自動起動、state 変更ではない。
 - `TicketClose`: 完了権限と resolution が揃っている場合だけ使う。
 - `TicketDoctor`: routing 前後の整合性確認。

@@ -82,13 +82,13 @@ Orchestrator は以下を行う。

 ## Queued acceptance contract

-`workflow_state = queued` は、Ticket が routing 対象として人間により Orchestrator へ渡された状態である。Orchestrator は queued notification を受けたら、Ticket、workspace state、対象 Ticket の `TicketOrchestrationPlanQuery` 記録、risk domain に応じた bounded project context を読んで、次のどちらかを行う。
+`state = queued` は、Ticket が routing 対象として人間により Orchestrator へ渡された状態である。Orchestrator は queued notification を受けたら、Ticket、workspace state、対象 Ticket の `TicketOrchestrationPlanQuery` 記録、risk domain に応じた bounded project context を読んで、次のどちらかを行う。

 - unblocked と判断する場合: `queued -> inprogress` を記録してから worktree 作成、implementation/review Pod spawn、その他の implementation side effect に進む。
  - `before` / `after` / `blocked_by` / `blocks` / `conflicts_with` / `do_not_parallelize` / waiting-capacity 記録がある場合、それを acceptance 判断の入力にする。記録は自動 scheduler ではないため、実際に進めるかどうかは Orchestrator が読んだうえで明示的に決める。
  - risk flags / risky domain がある場合は、IntentPacket に invariants / reviewer focus / escalation conditions を入れる。risk flag だけを `queued -> planning` の理由にしない。
 - concrete missing decision / information がある場合: `TicketWorkflowState` で `queued -> planning` を記録し、reason/body と `TicketComment` に不足項目、checked context、なぜ coder の implementation latitude では解決できないか、次の planning question/action を残す。既存の claimed live/restorable Intake/Planning Pod があり、既存通知経路が使える場合は同じ理由を通知する。
- external action 待ちなど planning では解決しない blocker の場合: concise な理由を Ticket thread に記録し、queued のまま待つか、既存の Ticket status/state mechanism で明示的に defer/block する。
+- external action 待ちなど planning では解決しない blocker の場合: concise な理由を Ticket thread に記録し、queued のまま待つか、既存の Ticket state/state mechanism で明示的に defer/block する。

 Invariant:

@@ -268,7 +268,7 @@ Action:

 ### 1. 状態確認

- `git status --short --branch`
+- `git state --short --branch`
 - `TicketShow <target>`
 - 関連 Ticket の `TicketList` / `TicketShow`
 - 必要に応じて docs/code/workflow/history
@@ -389,7 +389,7 @@ IntentPacket が短く書けない場合、`implementation_ready` ではなく `
 ### 7. 後続 Workflow へ接続する

 - `requirements_sync_needed` → `ticket-intake-workflow` / human / planning sync
- `return_to_planning` → `ticket-preflight-workflow`（legacy compatibility slug の planning sync entry）
+- `return_to_planning` → `ticket-preflight-workflow`（legacy compatibility canonical id の planning sync entry）
 - `spike_needed` → read-only investigation plan / Pod（許可後）
 - `implementation_ready` → `multi-agent-workflow`
 - `review_needed` → reviewer Pod / review workflow
@@ -1,5 +1,5 @@
 ---
-description: 互換 slug を残した Ticket planning / requirements sync workflow。preflight を独立 lane や workflow_state として扱わない。
+description: 互換 canonical id を残した Ticket planning / requirements sync workflow。preflight を独立 lane や state として扱わない。
 model_invokation: true
 user_invocable: true
 requires: []
@@ -15,7 +15,7 @@ requires: []

 この workflow は次をしてはいけない。

- `preflight` を workflow_state として扱う。
+- `preflight` を state として扱う。
 - `preflight` vocabulary を current Ticket metadata として新規に書く。
 - 「リスクがある」だけで Ticket を戻す。
 - broad effort の進捗を保持するためだけの umbrella/progress-container Ticket を作る。
@@ -95,7 +95,7 @@ git -C .worktree/<task-name> sparse-checkout set --no-cone \
 確認する。

 ```bash
-git -C .worktree/<task-name> status --short --branch
+git -C .worktree/<task-name> state --short --branch
 test ! -e .worktree/<task-name>/.yoi/memory
 if test -d .worktree/<task-name>/.yoi; then
  test ! -e .worktree/<task-name>/.yoi/override.local.toml