ticket: record builtin workflow review and companion progress intake

This commit is contained in:
Keisuke Hirata 2026-06-11 17:50:54 +09:00
parent 58666e3377
commit fb772e29bd
No known key found for this signature in database
3 changed files with 42 additions and 7 deletions

View File

@ -2,7 +2,7 @@
title: "Builtin Workflow and Knowledge resources"
state: 'inprogress'
created_at: "2026-06-07T07:27:08Z"
updated_at: '2026-06-11T08:46:27Z'
updated_at: '2026-06-11T08:50:25Z'
queued_by: 'workspace-panel'
queued_at: '2026-06-11T08:29:19Z'
---

View File

@ -164,3 +164,32 @@ Notes:
- This is a first-pass builtin resource implementation. It covers embedded builtin Workflow and Workflow-required Knowledge fallback/provenance. Broader KnowledgeQuery builtins and user-level workflow/knowledge resource directories remain follow-up boundaries if desired.
---
<!-- event: review author: reviewer-builtin-workflow-knowledge-resources at: 2026-06-11T08:50:25Z status: approve -->
## Review: approve
Branch-local review verdict: approve
Blockers: none.
Non-blocking notes:
- The implementation keeps the intended boundaries: workflows are embedded from `resources/workflows`, required workflow Knowledge is embedded separately from `resources/knowledge`, and prompt resources are not mixed into either path.
- Workspace workflow files override builtin workflow fallback by slug, while existing skill shadow behavior remains intact.
- Required Knowledge resolution checks workspace `.yoi/knowledge/<slug>.md` first and falls back to bundled Knowledge only on missing workspace file.
- Workflow invocation/system items expose provenance for both workflow source and required Knowledge source.
- The bundled Knowledge content is public design/process context and is only inserted through recorded workflow invocation system items, not hidden cross-turn context injection.
- Broader builtin KnowledgeQuery/user-level resource directory behavior remains outside this branchs scope, consistent with the provided scope note.
Validation run by reviewer:
- `cargo fmt --check` passed.
- `cargo test -p workflow --lib` passed.
- `cargo test -p pod workflow --lib` passed.
- `cargo check -p workflow -p pod` passed.
- `git diff --check $(git merge-base HEAD develop)..HEAD` passed.
- `/home/hare/Projects/yoi/target/debug/yoi ticket doctor` passed.
- `nix build .#yoi` passed.
No files were intentionally modified and no final main-branch Ticket approval/close was recorded by reviewer.
---

View File

@ -24,6 +24,10 @@ Companion が Workspace の Orchestrator 進捗を低コストで説明できる
- Orchestrator Pod に追加 user input / system input を送らない。
- queued work を再提示して Orchestrator を動かす目的では使わない。
- Orchestrator が idle かどうかの制御や scheduler 代替にしない。
- `Method::Notify``auto_run: bool` (default: true) を追加し、Companion 向けの弱い進捗通知では `auto_run: false` を使う。
- `auto_run: true` は既存挙動を維持し、idle Pod なら `RunForNotification` を staged する。
- `auto_run: false``NotifyBuffer` に積むだけで、idle Pod を起こさない。
- running/paused Pod では既存 drain path に従い、次の turn/resume/run で history に入る。
- Companion に対して、Orchestrator progress を read-only context として共有する。
- active Ticket / recently handled Ticket。
- state transition: `queued -> inprogress`、review requested、review approved、merge-ready、merged、done/closed、blocked など。
@ -44,7 +48,9 @@ Companion が Workspace の Orchestrator 進捗を低コストで説明できる
- secret/private context、provider errors の sensitive detail、unbounded logs を含めない。
- Panel / Companion lifecycle と統合する。
- Companion が live/reachable の場合に progress notice を届けるか、Companion が読むための local progress snapshot を更新する。
- Companion が stopped/missing の場合、通知で spawn/restore しない。次回 Companion 起動時に読める snapshot として扱う案を検討する。
- Companion が stopped/missing の場合、通知で spawn/restore しない。初期実装では persistent snapshot store は作らず、live/reachable Companion への `Notify { auto_run: false }` に限定する。
- `auto_run: false` の通知は弱い通知であり、drain 前に Pod が停止すれば失われ得ることを許容する。
- durable progress snapshot は必要性が出るまで導入しない。
- UI 上の通知と LLM context injection の境界を守る。
- Companion へ model context として渡すなら、必ず history に残る形で渡す。
- history に残らない transient context injection はしない。
@ -54,17 +60,17 @@ Companion が Workspace の Orchestrator 進捗を低コストで説明できる
## 受け入れ条件
- Orchestrator の Ticket 消化 progress を Companion が説明できる read-only context として受け取れる、または起動時に参照できる。
- Orchestrator の Ticket 消化 progress を、live/reachable Companion が `Notify { auto_run: false }` 経由の read-only weak notification として受け取れる。
- progress notification は Orchestrator AutoKick / re-kick を発生させない。
- Companion が missing/stopped の場合に通知だけで自動 spawn/restore ない。
- Companion が missing/stopped の場合に通知だけで自動 spawn/restore せず、初期実装では persistent snapshot も作らない。
- Companion default profile の tool/feature policy は強化されず、実装・Ticket mutation・Pod spawn・merge authority を持たない。
- 通知内容は bounded で、Ticket id/title/state、role pod status、short reason、artifact/path references を中心にする。
- 通知は durable/queryable state から再構成できる情報を source とし、Pod completion notification だけを authority としない。
- 通知内容は durable/queryable state から作るが、`auto_run: false` 通知自体は weak/best-effort として扱い、未drain状態の永続化は要求しない。
- Companion model context に渡す情報は history に残る形で扱われ、context-only injection にならない。
- Panel から、Companion が持つ Orchestrator progress context の鮮度または last updated が分かる。
- targeted tests が追加・更新されている。
- AutoKick が発生しないこと。
- live Companion への notice delivery または snapshot update
- `Method::Notify { auto_run: false }` が idle Pod に `RunForNotification` を staged しないこと。
- live Companion への `Notify { auto_run: false }` delivery
- missing/stopped Companion で spawn/restore しないこと。
- bounded summary generation。
- sensitive/unbounded content を含めないこと。