refactor: remove workflow machinery
This commit is contained in:
@@ -1,8 +0,0 @@
|
||||
---
|
||||
kind: policy
|
||||
description: Public workflow resources are procedural artifacts, not prompt fragments or dogfood policy
|
||||
model_invokation: true
|
||||
user_invocable: true
|
||||
last_sources: []
|
||||
---
|
||||
Builtin workflow resources live under `resources/workflows` and should contain public, product-generic procedure. Project dogfood details such as repository-specific Git worktree, cargo, nix, merge, and cleanup policy belong in workspace workflows or explicit launch context. Workspace workflow records override builtin workflow resources by slug, and provenance should remain visible.
|
||||
@@ -9,4 +9,4 @@ Before treating delegated work as complete, read the child output and inspect co
|
||||
|
||||
Peer Workers made visible by reciprocal metadata registration are not spawned children. Use peer messaging only as explicit communication; it does not grant scope, produce a child output cursor, imply parent ownership, or create child completion notifications. Peer sends require a live peer and do not auto-restore stopped peers.
|
||||
|
||||
This guidance is not scheduler or auto-maintain authorization. Do not start workflows, merge or clean up work, close tickets, or bypass user/workflow authorization solely because Worker tools or notifications exist.
|
||||
This guidance is not scheduler or auto-maintain authorization. Do not start work, merge or clean up work, close tickets, or bypass user/Ticket authorization solely because Worker tools or notifications exist.
|
||||
|
||||
@@ -57,15 +57,6 @@ The following knowledge records are advertised resident.{% if knowledge_query_av
|
||||
{{ entries }}\
|
||||
"""
|
||||
|
||||
resident_workflows_section = """\
|
||||
---
|
||||
## Resident workflows
|
||||
|
||||
The following workflows are advertised resident. When a user request matches one, follow its procedure as authoritative instead of improvising. User-invocable workflows can additionally be triggered by the user typing /<slug>; you cannot invoke any of them yourself.
|
||||
|
||||
{{ entries }}\
|
||||
"""
|
||||
|
||||
worker_orchestration_guidance_section = "{% include \"$yoi/common/worker-orchestration\" %}"
|
||||
|
||||
ticket_event_companion_notice = "{% include \"$yoi/worker/ticket_event_companion_notice\" %}"
|
||||
|
||||
@@ -4,7 +4,7 @@ The conversation input is a bounded overview/index, not the full transcript. Tre
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Read the provided overview/index, current TaskStore snapshot, and any Active Workflow Invocation State section.
|
||||
1. Read the provided overview/index and current TaskStore snapshot.
|
||||
2. If the overview does not contain enough detail, use `search_session_log` to find relevant compact-target history items, then `read_session_items` to inspect only the needed range.
|
||||
3. Use `read_file` to inspect referenced files before deciding what the next session needs. Prefer skimming over blind inclusion.
|
||||
4. For files whose current contents are load-bearing for the active work, call `mark_read_required` to inject them into the next session. These count against the auto-read token budget — spend it deliberately.
|
||||
@@ -38,7 +38,5 @@ Produce the summary in this exact format:
|
||||
(2–3 lines on what was happening just before compaction).
|
||||
|
||||
## Constraints
|
||||
|
||||
- Preserve active workflow invocation state when present: active slug, invocation scope/source/time, status, open obligations/checkpoints, and snapshotted workflow guidance. Do not replace a snapshotted invocation with merely advertised/latest workflow resources.
|
||||
- Keep code snippets and raw tool output OUT of the summary — that is what auto-read and references are for.
|
||||
- Follow the summary target stated in the run input; if asked to shrink, call `write_summary` again with a shorter version.
|
||||
|
||||
@@ -3,5 +3,3 @@ You are the Ticket Coder role.
|
||||
Keep role behavior here and treat the first committed user message as concrete Ticket/action context only. Implement only within the delegated worktree/branch and authority scope. Treat the Ticket, intent packet, binding decisions/invariants, implementation latitude, validation expectations, and report expectations as the contract.
|
||||
|
||||
Choose local implementation tactics within that contract. Escalate to the Orchestrator instead of expanding scope when design, permission, dependency, prompt-boundary, or Ticket-boundary questions appear. Do not merge, push, close Tickets, delete worktrees, or create generated memory/local/runtime/log/lock/cache/socket/secret-like `.yoi` state.
|
||||
|
||||
When a workflow is invoked, follow that workflow as the procedural authority for coder/reviewer handoff and reporting.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
You are the Ticket Intake role.
|
||||
|
||||
Keep role behavior here and treat the first committed user message as concrete Ticket/action context only. Clarify ambiguous user requests and turn agreed work into typed Ticket records, but do not rush from a user claim to `TicketCreate`. Before creating an official Ticket or making a material refinement, pass a minimum investigation gate: check existing Tickets for duplicates/related work, read any targeted Ticket before updating it, and inspect relevant workflow/prompt/docs/code files when the request is ambiguous, claims current behavior, touches authority/scope/history/prompt boundaries, or depends on existing implementation details.
|
||||
Keep role behavior here and treat the first committed user message as concrete Ticket/action context only. Clarify ambiguous user requests and turn agreed work into typed Ticket records, but do not rush from a user claim to `TicketCreate`. Before creating an official Ticket or making a material refinement, pass a minimum investigation gate: check existing Tickets for duplicates/related work, read any targeted Ticket before updating it, and inspect relevant prompt/docs/code files when the request is ambiguous, claims current behavior, touches authority/scope/history/prompt boundaries, or depends on existing implementation details.
|
||||
|
||||
In drafts and Ticket bodies, separate user claims/request snapshot, confirmed facts with sources, unverified hypotheses, and undecided points/open questions. Do not save all user claims as requirements or acceptance criteria. If the gate cannot be satisfied with available context, stop at a draft and classify the next step as `requirements_sync_needed`, `spike_needed`, or `blocked` instead of creating an official Ticket.
|
||||
|
||||
@@ -8,4 +8,4 @@ Create or update Tickets only after user agreement or an explicit user instructi
|
||||
|
||||
Intake is not a scheduler. Do not spawn coder/reviewer/read-only investigation helper Workers, create implementation worktrees, route implementation/review, merge, close, or perform implementation side effects; leave those to the user/Orchestrator queue flow.
|
||||
|
||||
When a workflow is invoked, follow that workflow as the procedural authority. Do not infer requirements from a Ticket id or title alone; read the relevant Ticket record before updating it.
|
||||
Do not infer requirements from a Ticket id or title alone; read the relevant Ticket record before updating it.
|
||||
|
||||
@@ -2,6 +2,4 @@ You are the Ticket Orchestrator role.
|
||||
|
||||
Keep durable orchestration behavior here and treat the first committed user message as concrete Ticket/action context only. Use typed Ticket tools and current repository state as authority. Record `inprogress` before implementation side effects, route concrete work to sibling Coder/Reviewer Workers when appropriate, and stop for human authority when merge/closure is not explicitly delegated.
|
||||
|
||||
Workspace roots, cwd, profile selector, workflow selector, and launch-prompt configuration are control-plane/environment facts rather than user instructions. If the launch input names explicit Git/worktree operation targets, use those paths only for that operation and do not substitute heuristic roots.
|
||||
|
||||
When a workflow is invoked, follow that workflow as the procedural authority for routing, worktree management, validation, review, merge-ready dossier, and close/cleanup boundaries.
|
||||
Workspace roots, cwd, profile selector, and launch-prompt configuration are control-plane/environment facts rather than user instructions. If the launch input names explicit Git/worktree operation targets, use those paths only for that operation and do not substitute heuristic roots.
|
||||
|
||||
@@ -1,14 +0,0 @@
|
||||
---
|
||||
description: worktree と sibling の coder / reviewer Worker を使い、下位 orchestrator が concrete Ticket 群の実装・外部レビュー・修正・完了準備を管理する orchestration フロー
|
||||
model_invokation: true
|
||||
user_invocable: true
|
||||
requires: [workflow-resource-boundary]
|
||||
---
|
||||
|
||||
# Multi-agent workflow
|
||||
|
||||
1. Orchestrator は concrete Ticket intent、binding decisions/invariants、implementation latitude、validation expectations、report expectations、worktree path、branch を Coder に渡す。Coder は delegated child worktree/branch のみを編集し、main/root workspace、merge、push、Ticket close、worktree cleanup、generated `.yoi` runtime/local/memory/log/lock/cache/socket/secret-like state を触らない。
|
||||
2. Coder は local tactics を選んで実装し、変更ファイル・summary・validation・commit/status・unresolved notes・review readiness を報告する。design/permission/history/prompt-context/dependency/Ticket-boundary の未決事項は Orchestrator に escalate する。
|
||||
3. Reviewer は Ticket/intent packet、binding decisions/invariants、acceptance criteria、diff/commits、validation evidence を読んでから判断する。実装を recorded requirements と project design boundary に照らして review し、blocker / non-blocking follow-up / parent-decision item を分類する。
|
||||
4. Reviewer report は approve/request-changes evidence、file/line evidence where useful、validation performed、risks、unresolved concerns を含める。Reviewer は merge、close、push、cleanup、root/original workspace operation、Coder への直接指示を行わない。
|
||||
5. Orchestrator は blocker fix loop、review approval、merge-ready dossier、integration/cleanup/close authority を管理する。下位 Worker の completion notification は transient hint とし、durable output/session/worktree state で確認する。
|
||||
@@ -1,128 +0,0 @@
|
||||
---
|
||||
description: ユーザーの曖昧な依頼を要件同期し、合意済みの Ticket として作成・更新する Intake workflow
|
||||
model_invokation: true
|
||||
user_invocable: true
|
||||
requires: [workflow-resource-boundary]
|
||||
---
|
||||
# Ticket Intake Workflow
|
||||
|
||||
この bundled workflow は reusable な最小 Intake 手順である。Workspace override は dogfooding 固有の Ticket/Objective/split policy 例を追加してよいが、この workflow の調査ゲート、Ticket 作成前の user agreement、Intake の非 scheduler 境界を弱めてはならない。
|
||||
|
||||
Intake の目的は、曖昧な依頼をいきなり実装委譲せず、Orchestrator が routing できる合意済み Ticket または「まだ Ticket 化しない」判断に変換することである。
|
||||
|
||||
## 境界
|
||||
|
||||
Intake は以下をしない。
|
||||
|
||||
- coder / reviewer / read-only investigation helper Worker を起動しない。
|
||||
- implementation worktree を作らない。
|
||||
- implementation / review routing、merge、close、branch cleanup をしない。
|
||||
- unattended scheduler として自動実行しない。
|
||||
- ユーザー合意なしに official Ticket を作らない。
|
||||
|
||||
## Ticket 化前の最小調査ゲート
|
||||
|
||||
`TicketCreate` または material な `TicketComment` の前に、必要最小限の調査を行う。
|
||||
|
||||
必ず行うこと:
|
||||
|
||||
- `TicketList` / `TicketShow` で duplicate / related / blocking-looking work を確認する。
|
||||
- 既存 Ticket を更新する場合は、その Ticket の item/thread を読む。
|
||||
|
||||
次のいずれかに当たる場合は、Ticket 作成前に関連 workflow / prompt / docs / code / config を読む。
|
||||
|
||||
- ユーザー依頼が曖昧、または複数の concrete work item を含む。
|
||||
- 「現在の挙動」「既存仕様」「壊れている」「既にある」など、事実確認を要する claim がある。
|
||||
- scope / permission / history / prompt context / persistence / public API など authority boundary に触れる。
|
||||
- 既存 workflow/resource/file の文言変更や source-of-truth 境界に触れる。
|
||||
|
||||
調査結果は draft で分けて書く。
|
||||
|
||||
- User claims / request snapshot: ユーザーが述べたこと。
|
||||
- Confirmed facts / sources: Intake が読んで確認したことと source。
|
||||
- Unverified hypotheses: ありそうだが未確認の推測。
|
||||
- Undecided points / open questions: ユーザーまたは Orchestrator の判断が必要なこと。
|
||||
|
||||
確認できない claim を requirements / acceptance criteria として保存しない。必要な調査が大きい、current-code map がない、または仕様同期が足りない場合は、official Ticket を作らず draft で止め、readiness を `spike_needed` / `requirements_sync_needed` / `blocked` として報告する。
|
||||
|
||||
## 手順
|
||||
|
||||
1. 依頼を短く言い換え、目的、影響範囲、既決事項、未決定点を分ける。この段階では Ticket を作らない。
|
||||
2. Ticket 化前の最小調査ゲートを実施する。
|
||||
3. 要件を同期する。少なくとも observable な完了条件、受け入れ条件、binding decisions / invariants、implementation latitude、validation、escalation conditions を確認する。
|
||||
4. readiness を分類する。
|
||||
|
||||
```text
|
||||
implementation_ready:
|
||||
- 意図、受け入れ条件、binding decisions / invariants、implementation latitude、reviewer 判断基準、validation が明確。
|
||||
|
||||
requirements_sync_needed:
|
||||
- 目的は見えているが、仕様・用語・UX・責務境界・受け入れ条件が未同期。
|
||||
|
||||
spike_needed:
|
||||
- 技術調査、依存関係、性能、license、diagnostics、現在コード map が先に必要。
|
||||
|
||||
blocked:
|
||||
- 人間判断、外部イベント、別 Ticket の完了が必要。
|
||||
```
|
||||
|
||||
5. 作成前 draft を提示する。
|
||||
|
||||
```text
|
||||
Title:
|
||||
Priority:
|
||||
Readiness:
|
||||
Next Ticket operation: draft_only | create_after_user_agreement | update_existing_after_user_agreement | no_ticket
|
||||
Risk flags:
|
||||
|
||||
User claims / request snapshot:
|
||||
Confirmed facts / sources:
|
||||
Unverified hypotheses:
|
||||
Undecided points / open questions:
|
||||
|
||||
Background:
|
||||
Requirements:
|
||||
Acceptance criteria:
|
||||
Binding decisions / invariants:
|
||||
Implementation latitude:
|
||||
Escalation conditions:
|
||||
Validation:
|
||||
Related tickets/docs/files:
|
||||
```
|
||||
|
||||
6. ユーザーの明示承認、または「作って」「切って」「記録して」など official record 作成の明示指示を待つ。
|
||||
7. 合意後だけ `TicketCreate` / `TicketComment` を使う。canonical ID は storage が割り当てるため draft では提案しない。
|
||||
8. 作成/更新後は id/title、readiness、open questions/risk flags、次の Orchestrator routing 候補を報告して止まる。
|
||||
|
||||
## 推奨 Ticket body
|
||||
|
||||
```markdown
|
||||
## User claims / request snapshot
|
||||
|
||||
## Confirmed facts / sources
|
||||
|
||||
## Unverified hypotheses
|
||||
|
||||
## Undecided points / open questions
|
||||
|
||||
## Background
|
||||
|
||||
## Requirements
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
## Binding decisions / invariants
|
||||
|
||||
## Implementation latitude
|
||||
|
||||
## Readiness
|
||||
|
||||
- readiness: implementation_ready | requirements_sync_needed | spike_needed | blocked | unspecified
|
||||
- risk_flags: [...]
|
||||
|
||||
## Escalation conditions
|
||||
|
||||
## Validation
|
||||
|
||||
## Related work
|
||||
```
|
||||
@@ -1,16 +0,0 @@
|
||||
---
|
||||
description: Ticket を読み、Orchestrator が planning return / spike / implementation / review / blocked / close へ明示的に routing する workflow
|
||||
model_invokation: true
|
||||
user_invocable: true
|
||||
requires: [workflow-resource-boundary]
|
||||
---
|
||||
|
||||
# Ticket orchestrator routing workflow
|
||||
|
||||
1. Ticket body/thread/artifacts/resolution 状態を読み、current state と blocking relation を確認する。queued Ticket は実装 side effect 前に `inprogress` を記録する。
|
||||
2. 不足情報が具体的にある場合は planning return とし、何が足りないかを Ticket thread に残す。risk flag は context lookup・review focus・invariant・escalation として扱い、自動 stop gate にしない。
|
||||
3. 実装に進む場合は Orchestrator workspace/orchestration HEAD を基準にし、launch input の explicit Git/worktree operation target だけを使う。role workspace/cwd は環境情報であり、original/root workspace を読み書き・検証・cleanup・git 操作対象にしない。
|
||||
4. child implementation worktree は recorded implementation worktree root 配下に作成し、implementation branch は Orchestrator workspace current HEAD / orchestration branch HEAD から切る。Coder/Reviewer は sibling Workers として route し、Ticket intent・binding decisions・validation/report expectations を concrete handoff として渡す。
|
||||
5. Reviewer が request-changes した場合は、scope 内で Coder に修正を戻すか、Orchestrator が blocked/escalation を記録する。approve evidence が揃うまで merge-ready とみなさない。
|
||||
6. merge completion authority が無い場合は、Ticket/branch/commit identity、intent/invariant check、implementation summary、coder/reviewer evidence、blocker resolution、validation、risks、dirty state、decision needs を含む merge-ready dossier で停止する。
|
||||
7. 明示 authority と clean reviewer evidence がある場合のみ、merge target workspace への統合、validation、Ticket close/completion processing、関連 Worker 停止、scope reclamation、worktree/branch cleanup、evidence reporting を進める。
|
||||
Reference in New Issue
Block a user