--- title: 'Project workflowsをpublic builtinとdogfood運用に分離する' state: 'closed' created_at: '2026-06-10T11:16:30Z' updated_at: '2026-06-11T03:48:35Z' assignee: null queued_by: 'workspace-panel' queued_at: '2026-06-11T02:23:39Z' --- ## 背景 現在の workflow は workspace-local な `.yoi/workflow/*.md` として管理されている。対象は以下。 - `ticket-intake-workflow.md` - `ticket-orchestrator-routing.md` - `ticket-preflight-workflow.md` - `multi-agent-workflow.md` - `worktree-workflow.md` これらには Yoi の public builtin workflow として有用な Ticket / Pod orchestration 原則が含まれている一方、この repository の dogfooding 運用に強く結合した Git / worktree / branch / commit / merge / cargo / nix / `.yoi` sparse checkout などの具体手順も混ざっている。 そのまま builtin 化すると、公開用の標準 workflow が Yoi 開発 repository 固有の運用をユーザー project に押し付けることになる。builtin 化の前に、public default として提供する汎用 workflow と、この repository での dogfooding workflow を明確に分離する必要がある。 ## 現状分析 - Workflow loader は主に `/.yoi/workflow/.md` を読む。 - `WorkflowSource` には現在 `WorkspaceWorkflow` と `Skill { dir }` があり、`Builtin` source はない。 - Pod 起動時に workspace workflows を読み、その後 manifest の `[skills] directories` 由来の `SKILL.md` を registry に merge している。 - resident workflow advertisement は workflow metadata に基づくため、builtin 化した workflow は model context への露出範囲も設計する必要がある。 - 現在の `.yoi/ticket.config.toml` は project-local workflow slug を role に紐づけている。 - Intake: `ticket-intake-workflow` - Orchestrator: `ticket-orchestrator-routing` - Coder/Reviewer: `multi-agent-workflow` ## 問題意識 - `ticket-intake-workflow.md` は builtin 化しやすいが、古い `Action required` / `Attention required` 語彙や Yoi dogfooding 寄りの表現を整理する必要がある。 - `ticket-orchestrator-routing.md` は builtin 化候補だが、Git/worktree/branch など実装隔離 mechanism への具体言及を薄め、workspace state / active workspaces / isolation mechanism といった抽象表現へ寄せる必要がある。 - `ticket-preflight-workflow.md` は内容としては planning / requirements sync に近く、public-facing slug と既存互換名の扱いを決める必要がある。 - `multi-agent-workflow.md` は Yoi dogfooding 色が強く、`yoi を yoi で開発する`、worktree + branch + commit + merge + cargo/nix/yoi doctor などが濃い。そのまま public builtin にしない。 - `worktree-workflow.md` は Git worktree 専用であり、optional な Git workflow としてはあり得るが、default resident workflow にするべきではない。 - LLM-facing workflow 文言は prompt の一種なので、builtin workflow の resource placement は `resources/prompts` 集約方針と整合させる必要がある。 ## 要件 - 現行 project workflows を audit し、public builtin に抽出する内容と dogfood/project-local に残す内容を分離する。 - public builtin workflow に入れるべき抽象原則を整理する。 - Ticket は durable orchestration record。 - Task は session-local progress tracking。 - Objective は中期 goal / decision context。 - Intake は scheduler ではない。 - Ticket 作成前に user agreement を取る。 - broad effort を umbrella/progress-container Ticket にしない。 - binding decisions / invariants と implementation latitude を分ける。 - risk flags は automatic stop gate ではない。 - `queued -> inprogress` は side effect 前の explicit acceptance。 - notification は proof ではない。 - coder/reviewer は sibling として扱う。 - reviewer は intent / invariant / acceptance criteria に照らして判断する。 - merge-ready dossier / handoff report の考え方。 - secrets/private context を records に残さない。 - prompt context / authority boundary に触れる変更は escalation。 - public builtin workflow から、この repository 固有の dogfooding 手順を外す。 - `yoi を yoi で開発する` 前提。 - `.worktree/` 固定。 - `git worktree add` / sparse checkout 除外リスト。 - branch naming / commit / merge / cleanup の細部。 - `TODO.md` / `docs/report` / `.yoi/memory` 固有運用。 - `cargo fmt --check` / `cargo check --workspace` / `cargo test` / `nix build` / `yoi ticket doctor` の固定 validation。 - dogfood workflow はこの repository 用の project-local workflow として残す。 - public builtin と同じ slug で override するか、`yoi-dogfood-*` のような明示 slug に分けるかを判断し、理由を記録する。 - builtin workflow source model を設計する。 - `WorkflowSource::Builtin` または同等の provenance を追加する方針を決める。 - builtin workflow の synthetic path / source label / diagnostics 表示を決める。 - workflow source priority / override semantics を決める。 - workspace `.yoi/workflow/.md` が builtin を override できること。 - skill workflows と builtin workflows の優先順位を明示すること。 - resident advertisement の分類を決める。 - core builtin resident workflow と optional builtin workflow を分ける。 - Git/worktree workflow を default resident にするかどうかを明示する。 - builtin workflow resource placement を決める。 - LLM-facing text 集約方針に従い、`resources/prompts/workflows/` など prompt resource 配下に置く案を検討する。 - workflow crate の record/source model と矛盾させない。 - `.yoi/ticket.config.toml` の workflow selector を、分離後の slug / source model に合わせて更新する。 - stale な `Action required` / `Attention required` workflow 文言を削除・置換する。 ## 推奨する分解案 ### Public builtin core workflows - `ticket-intake-workflow` - `ticket-orchestrator-routing` - `ticket-planning-sync` または既存互換の `ticket-preflight-workflow` ### Public builtin optional workflows - `multi-agent-review-workflow` - `git-worktree-isolation-workflow` optional workflows は builtin resource として提供しても、default resident advertisement には含めない、または profile/feature で明示有効化する。 ### Project dogfood workflows - `yoi-dogfood-multi-agent-workflow` - `yoi-dogfood-worktree-workflow` この repository の concrete Git/worktree/cargo/nix/Ticket doctor 運用は dogfood workflow 側に残す。 ## 受け入れ条件 - 現行 `.yoi/workflow/*.md` の内容が、public builtin 候補と dogfood/project-local 残置対象に分類されている。 - public builtin にそのまま入れてはいけない Git/worktree/Yoi-repo-specific 文言が audit され、移動先または削除理由が記録されている。 - `WorkflowSource::Builtin` など builtin workflow source/provenance の設計が記録されている。 - source priority が明文化されている。 - workspace override が builtin より優先されること。 - skill workflow と builtin workflow の優先順位。 - resident advertisement の core/optional 方針が決まっている。 - builtin workflow resource を `resources/prompts` 配下に置くか、別 resource tree に置くかの判断と理由が記録されている。 - public builtin workflow の slug と dogfood workflow の slug 方針が決まっている。 - `.yoi/ticket.config.toml` をどう移行するかが記録されている。 - `Action required` / `Attention required` のような廃止済み Ticket frontmatter 語彙が workflow から取り除かれる計画になっている。 - 後続実装 Ticket に分割できる粒度まで設計が落ちている。 - `target/debug/yoi ticket doctor` が通る。 ## 非目標 - この Ticket 単体で builtin workflow loader を実装すること。 - この Ticket 単体ですべての workflow content を書き換えて移行完了すること。 - Git/worktree workflow を public default resident workflow として無条件に有効化すること。 - Yoi dogfooding 固有の運用を捨てること。 - workflow 文言を Rust code に直書きすること。