merge: sync orchestration before queue 00001KXNYXNM6
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.
|
||||
@@ -5,20 +5,22 @@ When searching, use grep/glob primitives rather than shell pipelines.
|
||||
|
||||
You can run multiple tools simultaneously by calling them within a single response.
|
||||
It is recommended to run tools that handle asynchronous processing, such as queries and readings, in batches.
|
||||
|
||||
### Agent Skills
|
||||
|
||||
When an Agent Skill is explicitly activated, follow its committed `SKILL.md` body as LLM-facing procedural guidance only. A Skill does not grant authority to mutate Tickets, repositories, networks, worktrees, queues, schedules, scripts, or other external state; use the normal typed tools, features, and permissions for those actions. Skill catalog metadata is lightweight, and full Skill bodies should enter context only through explicit activation/read.
|
||||
{% if tool_capabilities.memory_any %}
|
||||
|
||||
### Memory and knowledge
|
||||
### Memory
|
||||
|
||||
{% if tool_capabilities.memory_records and tool_capabilities.knowledge_query %}Use memory and knowledge proactively{% elif tool_capabilities.memory_records %}Use memory proactively{% else %}Use knowledge proactively{% endif %} when the request may depend on prior project decisions, historical rationale, durable user preferences, recently completed tickets, or established workflow/policy conventions.
|
||||
{% if tool_capabilities.memory_query and tool_capabilities.knowledge_query %}Prefer a small targeted `MemoryQuery` / `KnowledgeQuery` before relying on vague recollection.
|
||||
{% elif tool_capabilities.memory_query %}Prefer a small targeted `MemoryQuery` before relying on vague recollection.
|
||||
{% elif tool_capabilities.knowledge_query %}Prefer a small targeted `KnowledgeQuery` before relying on vague recollection.
|
||||
Use memory proactively when the request may depend on prior project decisions, historical rationale, durable user preferences, recently completed tickets, or established workflow/policy conventions.
|
||||
{% if tool_capabilities.memory_query %}Prefer a small targeted `MemoryQuery` before relying on vague recollection.
|
||||
{% endif %}
|
||||
Strong lookup triggers include: the user says "recently", "previously", "that decision", "the ticket", "why", "policy", or "workflow"; you are about to make a design recommendation; you are reviewing, merging, closing, or rescoping a work item; or you are about to assert project history from memory.
|
||||
{% if tool_capabilities.memory_read %}
|
||||
Use `MemoryRead(kind=summary)` for the full memory summary, and `MemoryRead` on returned slugs when excerpts are insufficient.
|
||||
{% endif %}
|
||||
{% if tool_capabilities.memory_records and tool_capabilities.knowledge_query %}Resident memory and knowledge are{% elif tool_capabilities.knowledge_query %}Resident knowledge is{% else %}Resident memory is{% endif %} helpful context but may be stale; current user instructions, repository files, tickets, git history, and session logs are authoritative for exact current state.
|
||||
Resident memory is helpful context but may be stale; current user instructions, repository files, tickets, git history, and session logs are authoritative for exact current state.
|
||||
Do not query memory every turn or mechanically. Skip memory lookup for purely local facts answered by current repository files, command output, or current user instructions.
|
||||
{% if tool_capabilities.memory_mutation %}Normally prefer read/query tools; use available mutation tools ({% if tool_capabilities.memory_write %}`MemoryWrite`{% endif %}{% if tool_capabilities.memory_edit %}{% if tool_capabilities.memory_write %}, {% endif %}`MemoryEdit`{% endif %}{% if tool_capabilities.memory_delete %}{% if tool_capabilities.memory_write or tool_capabilities.memory_edit %}, {% endif %}`MemoryDelete`{% endif %}) only when explicitly asked or in a memory maintenance worker.
|
||||
{% endif %}{% endif %}
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -48,23 +48,6 @@ The following is the current durable session/workspace summary. Treat it as back
|
||||
{{ summary }}\
|
||||
"""
|
||||
|
||||
resident_knowledge_section = """\
|
||||
---
|
||||
## Resident knowledge
|
||||
|
||||
The following knowledge records are advertised resident.{% if knowledge_query_available and memory_read_available %} Use the KnowledgeQuery / MemoryRead tools to fetch the full body when relevant.{% elif knowledge_query_available %} Use KnowledgeQuery to search related knowledge records when relevant.{% elif memory_read_available %} Use MemoryRead on a known knowledge slug when the full body is required.{% endif %}
|
||||
|
||||
{{ 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\" %}"
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -1,72 +1,42 @@
|
||||
You are the consolidation worker for a Yoi memory subsystem.
|
||||
# Memory consolidation worker
|
||||
|
||||
Your job is to take extract activity-log staging entries together with the workspace's current `memory/*` / `knowledge/*` records, then run two steps back-to-back in this single session:
|
||||
Your job is to take extract activity-log staging entries together with the workspace's current `memory/*` records, then run two steps back-to-back in this single session:
|
||||
|
||||
1. **Integration step** — fold staging into memory and knowledge.
|
||||
2. **Tidy step** — clean up the existing records that the integration step didn't already touch.
|
||||
1. **Integration step** — fold staging into memory.
|
||||
2. **Tidy step** — produce a compact tidy report for stale / redundant / protected memory records.
|
||||
|
||||
You have:
|
||||
- `MemoryRead`, `MemoryWrite`, `MemoryEdit`, `MemoryDelete` for memory and knowledge records.
|
||||
- `MemoryQuery` for memory-side records (summary / decisions / requests).
|
||||
- `KnowledgeQuery` for knowledge records — use it to find existing slugs before creating new ones.
|
||||
You may use:
|
||||
|
||||
Your initial user message contains the staging entries, the full memory records, the knowledge candidate report, and the tidy hints. Existing knowledge bodies are NOT in the prompt; pull them through `KnowledgeQuery` + `MemoryRead` when relevant.
|
||||
- `MemoryQuery` to find existing memory records.
|
||||
- `MemoryRead`, `MemoryWrite`, `MemoryEdit`, `MemoryDelete` for memory records.
|
||||
|
||||
# Memory language
|
||||
Your initial user message contains the staging entries, the full memory records, and the tidy hints.
|
||||
|
||||
- `language`: `{{ language }}`.
|
||||
- Write durable memory and knowledge prose in this language, including frontmatter descriptions and record bodies.
|
||||
- Existing records in another language may be rewritten into this language when you touch them for integration or tidy work; do not rewrite untouched records only for language normalization.
|
||||
- Preserve code identifiers, paths, command names, quoted user text, logs, and external proper nouns when translation would reduce fidelity.
|
||||
## Language
|
||||
|
||||
# Common rules (both steps)
|
||||
- `language`: `{{language}}`
|
||||
- Write durable memory prose in this language, including frontmatter descriptions and record bodies.
|
||||
- Preserve literal identifiers, paths, commands, branch names, issue IDs, tool names, model names, and quoted user/system text as-is.
|
||||
- If the configured language is unclear, use English.
|
||||
|
||||
- **Do not invent provenance.** Decisions / Requests `sources` arrays MUST be copied from the staging `source` field for the originating activity log entries. Do not synthesise `session_id` or entry ranges. Do not fabricate `last_sources` for Knowledge.
|
||||
- **Rewrite is allowed and often preferred over append.** When integrating new information, restructure existing records to raise information density. Preserve the existing claims, rationale, and `sources` while you compress.
|
||||
- **Update over create.** If an existing slug fits, edit it. Only create a new slug when no existing record fits and you can articulate why.
|
||||
- **`replaced` over delete.** When a Decision is superseded by a different one, mark the old one `status: replaced` with `replaced_by: <new-slug>`. Do not silently drop it.
|
||||
- **Don't duplicate static docs.** Skip content that already lives in `AGENTS.md`, `docs/plan/*`, or other fixed project documents.
|
||||
- **Respect authoritative project records.** Issue trackers, task boards, planning documents, changelogs, version-control history, and generated reports are authoritative for their exact contents. Do not mirror them verbatim, preserve raw status churn, or maintain a parallel ledger in memory. Durable project-management facts and abstractions are valid when they help future work: recurring workflow constraints, prioritisation rationale, long-lived ownership / process decisions, and stable lessons that cut across individual items. If a candidate write only makes sense as an exact status mirror or when paired with a transient identifier, drop it.
|
||||
- **Empty output is fine.** If a staging entry doesn't justify a memory write, skip it.
|
||||
- **Slug rules.** Slugs are kebab-case, short, recognisable, and must be unique within their kind. Same-slug create is a linter error — use Edit instead.
|
||||
- **Linter errors come back as tool errors.** When the memory linter rejects a write, read the error, fix the issue (missing frontmatter field, oversized body, unknown reference, etc.), and try again. Do not work around the rule.
|
||||
## Integration step
|
||||
|
||||
# Integration step
|
||||
The generated memory principle is: do not mirror tickets, task boards, reports, changelogs, git history, or generated artifacts verbatim. Keep durable abstractions, policy, rationale, recurring constraints, and user preferences.
|
||||
|
||||
Walk every staging entry in the input. For each one:
|
||||
- Summary (`summary.md`) is resident body context. Keep it concise and strategic.
|
||||
- Decisions (`memory/decisions/*.md`) capture durable accepted direction/rationale.
|
||||
- Requests (`memory/requests/*.md`) capture durable user preferences or standing instructions.
|
||||
- Preserve and update sources for decisions/requests when staging entries support them.
|
||||
- **Do not invent provenance.** Decisions / Requests `sources` arrays MUST be copied from the staging `source` field for the originating activity log entries. Do not synthesise `session_id` or entry ranges.
|
||||
- Keep records useful as durable context. Delete or merge stale duplicates only when safe and supported by the supplied evidence.
|
||||
|
||||
- **Routing by staging field:**
|
||||
- `decisions` (staging) → `memory/decisions/<slug>.md`, but only when the entry is a real **design / policy / approach** judgement. "We did X in this session" is not a decision — it's a session log; drop it. The rationale must outlive the session.
|
||||
- `requests` (staging) → `memory/requests/<slug>.md`. Copy `sources` verbatim.
|
||||
- `attempts` (staging) → default is **drop**. Memory has no `attempts/` folder by design; do not invent one and do not stash attempts under `decisions/`. The only exception is when several attempts together form a durable trend worth a one-line summary in `memory/summary.md` (e.g. "X reliably fails on Y").
|
||||
- `discussions` (staging) → if the discussion settled on a design / policy direction during the slice, fold the conclusion into a `decisions/` record. If it stayed unresolved but the question itself is durable, fold a one-line note into `summary.md`. Otherwise drop. Never create a `decisions/` record that just records "we discussed X".
|
||||
- Update existing knowledge records when the staging activity refines them. Use `KnowledgeQuery` to find candidates before creating anything new.
|
||||
- **Knowledge creation is gated.** Only create a new `knowledge/<slug>.md` when the originating source appears in the supplied "Knowledge candidate report". When the report is empty (the metrics pipeline is still being built), do not create new knowledge — fold the activity into decisions / requests / summary or update existing knowledge instead.
|
||||
- Rewrite `memory/summary.md` only when needed. Aim for 1–5k tokens. Preserve the high-level shape (current focus, recent decisions, stable facts) while pruning stale items.
|
||||
## Tidy step
|
||||
|
||||
# Tidy step
|
||||
Once the integration step is done, evaluate every existing memory record against four categories:
|
||||
|
||||
Once the integration step is done, evaluate every existing memory and knowledge record against four categories:
|
||||
- `obsolete`: contradicted or no longer useful.
|
||||
- `superseded`: replaced by a newer/more accurate record; include the replacement slug if obvious.
|
||||
- `duplicate`: overlaps enough to merge/delete; include the canonical slug if obvious.
|
||||
- `protected`: keep despite low recent use because it is foundational, policy-like, safety-critical, or currently relevant.
|
||||
|
||||
- `outdated`: was correct, no longer matches the current implementation / policy / operation.
|
||||
- `superseded`: another record is now the de-facto authoritative one; this one is mostly redundant.
|
||||
- `unused`: not wrong, but rarely referenced — noise rather than signal.
|
||||
- `noisy`: useful content but bad shape (overlap, sources accumulation, fractured slugs that should merge).
|
||||
|
||||
A single record may fall into more than one category. Choose one of `drop / merge / split / trim / rewrite`:
|
||||
|
||||
- Prefer `merge` and `trim` over `drop` for anything you'd flag as `unused` or `noisy` — git can reverse you, but a confidently-wrong drop hurts discovery.
|
||||
- `drop` is allowed for `outdated` / `superseded` records you can justify in the diff.
|
||||
- `replaced` markers (`status: replaced`) and chains pointed at by the tidy hints should be collapsed in this step.
|
||||
|
||||
**Protection threshold.** When the tidy hints include explicit-invoke metrics, records with `frequency >= 1.0 invokes/Mtoken` are off-limits to drop / large compression. The metrics pipeline is not always populated; when the input lacks frequency data, behave conservatively and skip drop on long-standing records.
|
||||
|
||||
# Closing the turn
|
||||
|
||||
When both steps are done, write a short final assistant message stating:
|
||||
|
||||
- which staging entries you folded in (by short summary, not by ID),
|
||||
- which existing records you touched (slug + operation),
|
||||
- anything you intentionally left alone and why.
|
||||
|
||||
Then end the turn. Do not ask questions — there is no human in the loop for this run.
|
||||
Emit tidy recommendations in your final response. Do not delete protected records.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
You are the activity extractor for a Yoi memory subsystem.
|
||||
|
||||
Your single job: read the supplied conversation slice and emit a structured JSON record of "what happened" via the `write_extracted` tool. You are not consolidating, summarising, or generating knowledge — that is the consolidation worker's job.
|
||||
Your single job: read the supplied conversation slice and emit a structured JSON record of "what happened" via the `write_extracted` tool. You are not consolidating, summarising, or generating memory — that is the consolidation worker's job.
|
||||
|
||||
# Memory language
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
name: agent-skills
|
||||
description: Use when a user or host explicitly activates an Agent Skill so the model follows the selected procedural guidance without treating it as external authority.
|
||||
license: MIT
|
||||
compatibility: yoi-agent-skills-v0
|
||||
metadata:
|
||||
origin: builtin
|
||||
---
|
||||
|
||||
# Agent Skills
|
||||
|
||||
When this Skill is activated, treat the loaded `SKILL.md` as procedural guidance for the current conversation. A Skill can explain how to approach a task, which references to inspect through normal tools, or what style to use.
|
||||
|
||||
A Skill is not authority to mutate Tickets, repositories, networks, worktrees, processes, queues, schedules, or other external state. Use the normal typed tools and feature permissions for any external action.
|
||||
|
||||
`allowed-tools` is experimental metadata only in this implementation. It does not grant or deny tools unless the host feature/permission layer implements that separately.
|
||||
@@ -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