86 lines
5.3 KiB
Markdown
86 lines
5.3 KiB
Markdown
---
|
||
title: "内部 Worker / 内部 Pod の Workflow 化"
|
||
state: "planning"
|
||
created_at: "2026-05-27T00:00:03Z"
|
||
updated_at: "2026-05-27T00:00:03Z"
|
||
---
|
||
|
||
## Migration reference
|
||
|
||
- legacy_ticket: tickets/internal-worker-workflow.md
|
||
- migrated_from: TODO.md / tickets directory migration on 2026-05-27
|
||
|
||
# 内部 Worker / 内部 Pod の Workflow 化
|
||
|
||
## 背景
|
||
|
||
INSOMNIA が内部で固定 prompt を持って disposable Worker / 専用 Pod を立ち上げている経路がいくつかある:
|
||
|
||
- extract 活動抽出（`crates/memory/src/extract/prompt.rs::EXTRACT_SYSTEM_PROMPT`）
|
||
- consolidation 統合 + 整理（`tickets/memory-consolidation.md`、本チケット時点では実装中 / 直前）
|
||
- Compact（`PromptCatalog::compact_system`）
|
||
|
||
これらは実装内 `&str` 定数や `PromptCatalog` の overlay で管理されており、prompt の調整や運用カスタマイズが「コード変更 + 再ビルド」を要する。一方、ユーザー向け `/<slug>` Workflow（`tickets/workflow.md`）は `<workspace_root>/.insomnia/workflow/<slug>.md` に住み、frontmatter + Markdown 本文 + `requires` Knowledge inject を持つ宣言形式で運用できる。
|
||
|
||
両者を寄せ、内部 Worker / 内部 Pod の prompt + ツール surface + Knowledge 依存を **Workflow と同一仕様で記述** できる経路を用意する。これにより:
|
||
|
||
- 内部 prompt の運用調整が workspace 側でできる（コード変更不要）
|
||
- consolidation の prompt 案 (`docs/plan/memory-prompts.md`) を workspace に直接 ingest できる
|
||
- 将来 consolidation を独立 Pod に引き上げる際も、Workflow を submit する形に揃えられる
|
||
|
||
## 要件
|
||
|
||
### Workflow の役割拡張
|
||
|
||
`tickets/workflow.md` の Workflow 仕様は「ユーザーが `/<slug>` で submit する制約付き作業」だが、本チケットでは **内部トリガー（Pod 内部の状態遷移）から呼び出される Workflow** を一級扱いに広げる。
|
||
|
||
- 同じファイル形式（`.insomnia/workflow/<slug>.md`）、同じ frontmatter / Linter
|
||
- `user_invocable: false` で `/<slug>` 経路から見えなくする
|
||
- `model_invokation` は通常 Pod 用の system prompt 注入仕様のまま（内部 Workflow は通常 OFF）
|
||
- 内部 Workflow を識別するキー（例: `internal_role`）と、必要なツール surface を表明する手段を frontmatter に追加する。具体 schema は実装で詰める
|
||
|
||
### 内部呼び出し経路
|
||
|
||
Pod 側の既存トリガー（extract post-run / consolidation staging 閾値 / Compact 閾値 等）は固定 `&str` の代わりに Workflow loader 経由で:
|
||
|
||
1. 内部識別キーで該当 Workflow を解決（衝突時は workspace 上書き優先、なければ insomnia bundled default）
|
||
2. `requires` Knowledge を本文の前に inject
|
||
3. Workflow 本文を sub-Worker / sub-Pod の prompt として渡す（system prompt 扱いか初回 submit 扱いかは内部用途で固定し、role ごとに揃える）
|
||
4. 既存のツール登録ロジックは Workflow が表明したツール surface に従う
|
||
|
||
### Bundled defaults
|
||
|
||
ユーザー workspace に該当 Workflow が無い場合に備え、insomnia 同梱の default Workflow を読む層を `PromptCatalog` の overlay と整合する形で持つ。
|
||
|
||
- 既存の Pod prompt 4 層 overlay（builtin / user / workspace / pod-pack）と同じ優先順
|
||
- bundled default の物理配置は実装で決める
|
||
|
||
### 関連チケットとの順序
|
||
|
||
- `tickets/workflow.md`（ユーザー向け Workflow 本体）が先行する。本チケットはその仕様を前提に「内部呼び出し経路」を追加する側
|
||
- `tickets/memory-consolidation.md` は当面 `&str` 定数で実装してよい。本チケット完了時に Workflow 化に乗り換える
|
||
- extract / Compact も同様に role ごとに段階移行
|
||
|
||
## 範囲外
|
||
|
||
- Workflow 仕様自体の本体実装（`tickets/workflow.md`）
|
||
- 内部 Workflow の自動生成（consolidation の offer 等。`docs/plan/memory.md` §Offer 経路 / 将来検討）
|
||
- 既存 `&str` 定数の物理削除タイミング（移行が完了した role ごとに削除する運用）
|
||
- `model_invokation` 注入予算の最適化（既存 Knowledge 常駐注入予算と合算する規約は `docs/plan/memory.md` 側）
|
||
|
||
## 完了条件
|
||
|
||
- 各内部 Worker / 内部 Pod（少なくとも extract / consolidation / Compact のうち、本チケット着手時点で実装済みのもの）が内部識別キー付き Workflow を解決して prompt とツール surface を組み立てる
|
||
- workspace で `.insomnia/workflow/<slug>.md` を上書きすれば内部 Worker の prompt が変わる
|
||
- workspace に該当 Workflow が無い場合、bundled default が使われる
|
||
- `user_invocable: false` の内部 Workflow は `/<slug>` 候補から除外され、ユーザーからは呼べない
|
||
- 内部 Workflow も consolidation の自動書き込み禁止対象のまま（Linter で構造的担保、`workflow.md` と整合）
|
||
- 単体テストで bundled default / workspace overlay / ツール surface 表明 + 解決 + 適用がカバーされる
|
||
|
||
## 参照
|
||
|
||
- 前提: `tickets/workflow.md`
|
||
- 最初の利用者: `tickets/memory-consolidation.md`
|
||
- 関連: `tickets/agent-skills.md`（外部 SKILL ingest 経路。本チケットの内部呼び出し経路とは別軸）
|
||
- 設計: `docs/plan/workflow.md`、`docs/plan/memory.md`、`docs/plan/memory-prompts.md`
|