sanitize: remove local path references from current tree

This commit is contained in:
Keisuke Hirata 2026-05-28 06:26:34 +09:00
parent 9ccbdda27c
commit 4361385946
8 changed files with 14 additions and 15 deletions

View File

@ -32,7 +32,7 @@ workflowで明示されない限り、読み取り以外の操作は控えるこ
基本はworktree上の一時的なブランチでコミットを重ね、メインブランチに取り込む運用をしている。 基本はworktree上の一時的なブランチでコミットを重ね、メインブランチに取り込む運用をしている。
コミットメッセージは適当に`<prefix>: *簡潔な1行*`で書いている。 コミットメッセージは適当に`<prefix>: *簡潔な1行*`で書いている。
外部の参考プロジェクトはexternal checkoutでgetしており、必要に応じて`<external-checkouts>`からReadすること。 外部の参考プロジェクトは必要に応じてローカルの外部 checkout からReadすること。
--- ---

View File

@ -32,7 +32,7 @@ workflowで明示されない限り、読み取り以外の操作は控えるこ
基本はworktree上の一時的なブランチでコミットを重ね、メインブランチに取り込む運用をしている。 基本はworktree上の一時的なブランチでコミットを重ね、メインブランチに取り込む運用をしている。
コミットメッセージは適当に`<prefix>: *簡潔な1行*`で書いている。 コミットメッセージは適当に`<prefix>: *簡潔な1行*`で書いている。
外部の参考プロジェクトはexternal checkoutでgetしており、必要に応じて`<external-checkouts>`からReadすること。 外部の参考プロジェクトは必要に応じてローカルの外部 checkout からReadすること。
--- ---

View File

@ -4,7 +4,7 @@ FileRef resolution and file tools follow symlinks only after the resolved target
Recommended external-reference workflow: Recommended external-reference workflow:
- Prefer adding the real external project path, such as a local `external checkout` clone, to the Pod read scope when the Pod is started or spawned. - Prefer adding the real external project path, such as a local external checkout, to the Pod read scope when the Pod is started or spawned.
- If a workspace symlink is used, the symlink target still must be inside readable scope. For writes, the resolved target must be inside writable scope. - If a workspace symlink is used, the symlink target still must be inside readable scope. For writes, the resolved target must be inside writable scope.
- If a relative symlink is broken, recreate it with the correct relative target from the symlink's parent directory, or use an absolute symlink. - If a relative symlink is broken, recreate it with the correct relative target from the symlink's parent directory, or use an absolute symlink.
- Directory traversal tools such as Glob and Grep do not follow symlink directories. Use the resolved target directory directly when it is in read scope. - Directory traversal tools such as Glob and Grep do not follow symlink directories. Use the resolved target directory directly when it is in read scope.

View File

@ -54,7 +54,7 @@ consolidation が以下を検出した場合、Client に Notification を投げ
- DSL 化や step 粒度の制約 — 初期は Markdown 本文そのまま実行 - DSL 化や step 粒度の制約 — 初期は Markdown 本文そのまま実行
- Workflow 実行中の中断・再開・トランザクション管理 - Workflow 実行中の中断・再開・トランザクション管理
- 品質検証フロー: external author empirical-prompt-tuning`docs/ref/memory-systems.md` §6相当の**新規 subagent 試走 + 構造化報告**を Workflow に適用。判定対象は本文の不明瞭点・裁量補完・要件達成率。Knowledge 単体の検証は設けず、`requires` 経由で Workflow から使われる前提で間接回収。SKILL 的用途Workflow 経由しない `#knowledge`)は人間レビューに委ねる - 品質検証フロー: empirical prompt tuning pattern`docs/ref/memory-systems.md` §6相当の**新規 subagent 試走 + 構造化報告**を Workflow に適用。判定対象は本文の不明瞭点・裁量補完・要件達成率。Knowledge 単体の検証は設けず、`requires` 経由で Workflow から使われる前提で間接回収。SKILL 的用途Workflow 経由しない `#knowledge`)は人間レビューに委ねる
## 関連 ## 関連

View File

@ -380,9 +380,9 @@ Skill content のライフサイクルは重要で、**一度発動すると ren
--- ---
## 6. プロンプト・スキルの継続的チューニング (external author empirical-prompt-tuning) ## 6. プロンプト・スキルの継続的チューニング (empirical prompt tuning pattern)
メモリや skill の**中身を腐らせない**側の話。external author が 2025-07 頃に公開し、その後 Claude Code の SKILL として整備したメソッドで、「暗黙知の排除」を自動化する。insomnia のように skill を蓄積する設計では、**書いた直後に客観的に試す**仕組みが無いと品質が崩れていく。ここへの素直な当てはめ材料として記録。 メモリや skill の**中身を腐らせない**側の話。公開されている prompt tuning pattern として、agent-facing な指示を新規 subagent に実行させ、実行者の自己申告と指示側メトリクスを突き合わせて反復改善する方法がある。insomnia のように skill を蓄積する設計では、**書いた直後に客観的に試す**仕組みが無いと品質が崩れていく。ここへの素直な当てはめ材料として記録。
### 基本思想 ### 基本思想
@ -430,11 +430,9 @@ Claude Code の Task tool 戻り値から:
- **skill や lessons を新規追加した直後に、同じ insomnia ハーネス内の別 pod で実行して評価**する自動フロー("skill doctor" 的な存在)を作れる。これは insomnia が pod factory を持っている点と相性がいい。 - **skill や lessons を新規追加した直後に、同じ insomnia ハーネス内の別 pod で実行して評価**する自動フロー("skill doctor" 的な存在)を作れる。これは insomnia が pod factory を持っている点と相性がいい。
- 失敗ログを書いた後、「同じ失敗が再現しないか」を新規 pod で試走する検証ステップが、構造的に**メモリ整備の一部**に組み込める。skill 化しない失敗ログでも有効。 - 失敗ログを書いた後、「同じ失敗が再現しないか」を新規 pod で試走する検証ステップが、構造的に**メモリ整備の一部**に組み込める。skill 化しない失敗ログでも有効。
- 評価指標を自前で定義しておくと、後で他人or 未来の自分)が skill を更新した時に腐敗検知できる。 - 評価指標を自前で定義しておくと、後で他人or 未来の自分)が skill を更新した時に腐敗検知できる。
- 実体は skill 自身として配布されている`public skill example/dot_claude/skills/empirical-prompt-tuning/SKILL.md`。insomnia のメンテ用 skill セットのテンプレにそのまま借りられる。 - 実体は skill 自身として配布されている例がある。insomnia のメンテ用 skill セットのテンプレにも応用できる。
一次ソース: 一次ソースは公開 sanitize branch では省略する。
- https://zenn.dev/external author/articles/empirical-prompt-tuning
- https://github.com/public skill example/blob/main/dot_claude/skills/empirical-prompt-tuning/SKILL.md
--- ---

View File

@ -3,7 +3,7 @@
調査日: 2026-04-26 調査日: 2026-04-26
対象: `crates/llm-worker` (本プロジェクト) / `rig` / `genai` / `swiftide` 対象: `crates/llm-worker` (本プロジェクト) / `rig` / `genai` / `swiftide`
調査方法: 各リポジトリを external checkout で取得し、ソースREADME, Cargo.toml, src/, examples/)を直接読解。 調査方法: 各リポジトリを ローカルに取得し、ソースREADME, Cargo.toml, src/, examples/)を直接読解。
--- ---

View File

@ -21,7 +21,7 @@ legacy_ticket: tickets/prompt-eval-metrics.md
## 背景 ## 背景
external author の empirical-prompt-tuning は、agent-facing な指示Skill / slash command / prompt 等)を新規 subagent に実行させ、実行者の自己申告と指示側メトリクスを突き合わせて反復改善する手法である。insomnia では Workflow / Skill ingest / Knowledge / memory consolidation / usage metrics / Pod orchestration があるため、この手法を単なる「手順」ではなく、**agent-facing instruction の品質観測 pipeline** として扱える。 empirical prompt tuning pattern は、agent-facing な指示Skill / slash command / prompt 等)を新規 subagent に実行させ、実行者の自己申告と指示側メトリクスを突き合わせて反復改善する手法である。insomnia では Workflow / Skill ingest / Knowledge / memory consolidation / usage metrics / Pod orchestration があるため、この手法を単なる「手順」ではなく、**agent-facing instruction の品質観測 pipeline** として扱える。
特に insomnia では以下をシステム側で観測できる。 特に insomnia では以下をシステム側で観測できる。
@ -159,7 +159,7 @@ Claude Code 版の `tool_uses` を、insomnia では tool 種別ごとの偏り
## 参照 ## 参照
- `external skill reference/empirical-prompt-tuning/SKILL.md`(外部参照。取り込み時は必要最小限に一般化する) - empirical prompt tuning skill example(外部参照。取り込み時は必要最小限に一般化する)
- `docs/plan/workflow.md` - `docs/plan/workflow.md`
- `docs/plan/memory.md` - `docs/plan/memory.md`
- `tickets/memory-usage-metrics.md` - `tickets/memory-usage-metrics.md`

View File

@ -27,7 +27,8 @@ legacy_ticket: tickets/session-todo-reminder.md
- 「やったつもり」になって `completed` への更新を忘れる - 「やったつもり」になって `completed` への更新を忘れる
- そもそも TaskStore の存在を忘れて、構造化を諦めて自由記述に回帰する - そもそも TaskStore の存在を忘れて、構造化を諦めて自由記述に回帰する
OpenCode の todo は専用の注意機構を持たない(汎用 reminder 経由)。一方 Claude Code は `task_reminder` を「N リクエスト無アクティビティで初めて発火するナッジ型」として実装しており、毎リクエスト押し戻しはしない(`<local-agent-install>` の local reminder helper functions、閾値 `a local reminder threshold`)。 OpenCode の todo は専用の注意機構を持たない(汎用 reminder 経由)。一方、一部の既存エージェント実装では todo reminder を「N リクエスト無アクティビティで初めて発火するナッジ型」として扱い、毎リクエスト押し戻しはしない。
Insomnia でも同方針を採り、active Task が残っているのに `TaskCreate` / `TaskUpdate` が一定リクエスト呼ばれていない場合に限り、`<system-reminder>` Item を 1件 history に append する。「やったつもり」抑止と、トークン浪費・LLM の自律性侵害のバランスを取るため、毎リクエスト押し戻しはしない。 Insomnia でも同方針を採り、active Task が残っているのに `TaskCreate` / `TaskUpdate` が一定リクエスト呼ばれていない場合に限り、`<system-reminder>` Item を 1件 history に append する。「やったつもり」抑止と、トークン浪費・LLM の自律性侵害のバランスを取るため、毎リクエスト押し戻しはしない。
@ -76,4 +77,4 @@ Insomnia でも同方針を採り、active Task が残っているのに `TaskCr
- 設計指針: `AGENTS.md`LLM コンテキストの加工原則。揮発的注入は禁止、history に append してから commit する) - 設計指針: `AGENTS.md`LLM コンテキストの加工原則。揮発的注入は禁止、history に append してから commit する)
- 前提: `tickets/session-todo.md`Tool 群と TaskStore、`tickets/notify-history-persist.md``pending_history_appends` レーン) - 前提: `tickets/session-todo.md`Tool 群と TaskStore、`tickets/notify-history-persist.md``pending_history_appends` レーン)
- 参考実装: Claude Code の `task_reminder`local reminder helper functions、閾値 `a local reminder threshold` - 参考: 一部エージェント実装の todo reminder は、一定リクエスト無アクティビティ後に発火し、再通知にも cooldown を置くナッジ型として扱われている