From eddb33cf83a5210ab93fc7a5b5148a02c4bb06e7 Mon Sep 17 00:00:00 2001 From: Hare Date: Mon, 8 Jun 2026 18:13:46 +0900 Subject: [PATCH] docs: fix planning sync workflow references --- .yoi/workflow/multi-agent-workflow.md | 10 +++++----- .yoi/workflow/ticket-intake-workflow.md | 2 +- docs/development/work-items.md | 4 ++-- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/.yoi/workflow/multi-agent-workflow.md b/.yoi/workflow/multi-agent-workflow.md index 7feaa939..aaf2f066 100644 --- a/.yoi/workflow/multi-agent-workflow.md +++ b/.yoi/workflow/multi-agent-workflow.md @@ -8,9 +8,9 @@ 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 sync は `$user/ticket-planning sync-workflow` に分ける。 +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` に分ける。 -この 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 起動の前に `ticket-planning sync-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` を通す。 ## 目的 @@ -61,9 +61,9 @@ reviewer Pod - worktree 作成と git 書き込み操作について、人間の許可がある。 - main workspace の unrelated dirty changes を把握している。 - 下位 orchestrator に渡す binding decisions / invariants、implementation latitude、escalation conditions を短く書ける。 -- 設計境界・仕様・authority boundary に不確定要素がある場合、`ticket-planning sync-workflow` の結果が ticket thread に記録されている。 +- 設計境界・仕様・authority boundary に不確定要素がある場合、planning/requirements sync 互換入口 `ticket-preflight-workflow` の結果が ticket thread に記録されている。 -product / API / UX / authority / design-boundary 方針が複数自然に導ける場合、protocol / scope / permission / history persistence に触れる場合、ticket 自体の再定義が必要な場合は、実装委譲前に `ticket-planning sync-workflow` を通し、必要なら人間へ戻す。実装ファイルの探索、既存コード読解、局所的な構成選択のような bounded implementation uncertainty は、intent / binding decisions / invariants / implementation latitude / acceptance criteria / escalation conditions が明確なら coder に委ねてよい。 +product / API / UX / authority / design-boundary 方針が複数自然に導ける場合、protocol / scope / permission / history persistence に触れる場合、ticket 自体の再定義が必要な場合は、実装委譲前に planning/requirements sync 互換入口 `ticket-preflight-workflow` を通し、必要なら人間へ戻す。実装ファイルの探索、既存コード読解、局所的な構成選択のような bounded implementation uncertainty は、intent / binding decisions / invariants / implementation latitude / acceptance criteria / escalation conditions が明確なら coder に委ねてよい。 ## Intent packet @@ -106,7 +106,7 @@ reviewer には coder の実装方針ではなく、この intent packet と dif - `git status --short --branch` - 対象 ticket / ticket 群 - 関連 TODO / docs / 既存 worktree - - planning sync が必要な ticket では、`ticket-planning sync-workflow` の分類・要件同期・critical risks + - planning sync が必要な ticket では、互換入口 `ticket-preflight-workflow` の分類・要件同期・critical risks 2. worktree 作成 - `$user/worktree-workflow` に従い `./.worktree/` を作る。 diff --git a/.yoi/workflow/ticket-intake-workflow.md b/.yoi/workflow/ticket-intake-workflow.md index 2d57127f..78a46191 100644 --- a/.yoi/workflow/ticket-intake-workflow.md +++ b/.yoi/workflow/ticket-intake-workflow.md @@ -276,6 +276,6 @@ Ticket の body は Markdown/freeform を維持する。すべてを strict sche ## 他 Workflow への接続 -- `ticket-planning sync-workflow`: legacy slug の互換入口。新規 routing は standalone planning sync ではなく planning return/requirements sync として扱う。 +- `ticket-preflight-workflow`: legacy compatibility slug の planning/requirements sync 入口。新規 routing は standalone preflight ではなく planning return/requirements sync として扱う。 - `multi-agent-workflow`: Orchestrator が implementation_ready と判断した後に接続する。 - `ticket-orchestrator-routing`: この Workflow が作った Ticket を routing する後続 Workflow。 diff --git a/docs/development/work-items.md b/docs/development/work-items.md index 982abf0d..6da4809b 100644 --- a/docs/development/work-items.md +++ b/docs/development/work-items.md @@ -22,7 +22,7 @@ Use the highest-level interface that matches the work: - Use `yoi panel` for the Ticket/Intake/Orchestrator workspace UI and role-launch actions. - Inside Pods, use typed Ticket tools to create, inspect, comment, review, and close Tickets. -- For multi-step work, follow the Ticket Intake, Orchestrator Routing, Preflight, and Multi-agent workflows. +- For multi-step work, follow the Ticket Intake, Orchestrator Routing, planning/requirements-sync, and Multi-agent workflows. Maintainers can inspect the local `.yoi/tickets/` files directly when debugging storage, but normal user instructions should go through `yoi panel`, Ticket tools, or `yoi ticket ...`. @@ -126,7 +126,7 @@ Ticket-driven development normally moves through these gates: 1. Intake 2. Orchestrator routing -3. Preflight or spike when needed +3. Planning/requirements sync or spike when needed 4. Implementation assignment 5. Review 6. Merge / validation / cleanup