0.5.0 BlueprintAPIの適用

docs/patch_note/v0.2.0.md

@@ -225,7 +225,7 @@ let worker = Worker::builder()
 ### Code Organization
 
 1. **Eliminated duplicate types** between `worker-types` and `worker` crates
-2. **Clearer separation of concerns** - Role definition vs. PromptComposer execution
+2. **Clearer separation of concerns** - Role定義とシステムプロンプト生成関数の責務を分離
 3. **Consistent error construction** - All error sites updated to use new helper methods
 
 ## Files Changed

docs/patch_note/v0.3.0.md

@@ -1,6 +1,6 @@
 # Release Notes - v0.3.0
 
-**Release Date**: 2025-??-??
+**Release Date**: 2025-10-23
 
 v0.3.0 はプロンプトリソースの解決責務を利用側へ完全に移し、ツール／フック登録の推奨フローを明確化するアップデートです。これにより、ワーカーの動作を環境ごとに柔軟に制御できるようになりました。
 
@@ -11,7 +11,7 @@ v0.3.0 はプロンプトリソースの解決責務を利用側へ完全に移
 
 ## 新機能 / 仕様変更
 
-- `PromptComposer` が `ResourceLoader` を必須依存として受け取り、partials や `{{include_file}}` の読み込みをすべてローダー経由で行うようになりました。
+- システムプロンプトの構築責務をアプリケーション側のクロージャへ移し、Worker から `ResourceLoader` 依存を排除しました。
 - パーシャル読み込み時にフォールバックが失敗した場合、一次／二次エラー内容を含むメッセージを返すよう改善しました。
 - README とドキュメントを刷新し、推奨ワークフロー（ResourceLoader 実装 → Worker 構築 → イベント処理）を明示。`#[worker::tool]` / `#[worker::hook]` マクロを用いた登録例を追加しました。
 - ユニットテスト `test_prompt_composer_uses_resource_loader` を追加し、注入されたローダーがパーシャル／include の解決に使われることを保証。

docs/patch_note/v0.4.0.md

@@ -1,6 +1,6 @@
 # Release Notes - v0.4.0
 
-**Release Date**: 2025-??-??
+**Release Date**: 2025-10-24
 
 v0.4.0 は Worker が `Role` や YAML 設定を扱わず、システムプロンプト生成を完全に利用者へ委譲する大規模リファクタです。これにより、任意のテンプレートエンジンやデータソースを組み合わせてプロンプトを構築できます。
 
@@ -11,19 +11,16 @@ v0.4.0 は Worker が `Role` や YAML 設定を扱わず、システムプロン
 
 ## 新機能 / 仕様変更
 
-- `PromptComposer` は `Arc<SystemPromptFn>` を受け取り、`PromptContext` と履歴メッセージからシステムプロンプト文字列を生成するシンプルなラッパーになりました。
-- `WorkerBuilder` は `.system_prompt(...)` で登録した関数を保持し、メッセージ送信時に毎回システムプロンプトを再生成します。
+- システムプロンプト生成はブループリントが提供するクロージャで一度だけ評価し、ワーカーは生成済みの結果を保持する方針に統一しました。
 - README／サンプルコードを刷新し、システムプロンプト関数・マクロベースのツール／フック登録手順のみを掲載。
-- 新しい `docs/prompt-composer.md` を追加し、`PromptComposer` の利用例をサマリー形式で紹介。
 
 ## 不具合修正
 
-- `PromptComposer` が内部でファイルアクセスを行う経路を排除し、生成関数の失敗時は直近のキャッシュを利用するようにしました。
 - Worker から NIA 固有の設定コードを除去し、環境依存の副作用を縮小。
 
 ## 移行ガイド
 
-1. 旧 `Role` / `ConfigParser` を利用していた場合、`PromptContext` と会話履歴を引数にシステムプロンプト文字列を返す関数を実装し、`.system_prompt(...)` に渡してください。
+1. 旧 `Role` / `ConfigParser` を利用していた場合、`SystemPromptContext` と会話履歴を引数にシステムプロンプト文字列を返す関数を実装し、`.system_prompt(...)` に渡してください。
 2. `Worker::load_config` やリソースパス解決に依存していたコードは削除してください。必要であればアプリケーション側でファイル読み込みを行い、生成関数内で利用してください。
 3. ツール・フックは引き続き `#[worker::tool]` / `#[worker::hook]` マクロを推奨しています（API に変更はありません）。
 

docs/patch_note/v0.5.0.md

@@ -0,0 +1,36 @@
+# Release Notes - v0.5.0
+
+**Release Date**: 2025-10-25
+
+v0.5.0 introduces the Worker Blueprint API and removes the old type-state builder. Configuration now lives on the blueprint, while instantiated workers keep only the materialised system prompt and runtime state.
+
+## Breaking Changes
+
+- Removed `WorkerBuilder` type-state API. `Worker::blueprint()` now returns a configurable `WorkerBlueprint` which must be instantiated explicitly.
+- `Worker::builder()` has been removed; always use `Worker::blueprint()` to configure new workers.
+- Worker no longer exposes Role/YAML utilities; prompt generation is always supplied via `system_prompt_fn` and evaluated during instantiation.
+
+## New Features / Behaviour
+
+- `WorkerBlueprint` stores provider/model/api keys, tools, hooks, and optional precomputed system prompt strings. `instantiate()` evaluates the prompt (if not already cached) and hands the final string to the `Worker`.
+- Instantiated workers retain only the composed system prompt string; the generator function lives solely on the blueprint and is dropped after instantiation.
+- System prompts are no longer recomputed per turn. Tool metadata is appended dynamically as plain text when native tool support is unavailable.
+
+## Migration Guide
+
+1. Replace any legacy `Worker::builder()` usage with:
+   ```rust
+   let mut blueprint = Worker::blueprint();
+   blueprint
+       .provider(LlmProvider::Claude)
+       .model("claude-3-sonnet")
+       .system_prompt_fn(your_fn);
+   let worker = blueprint.instantiate()?;
+   ```
+2. If you need to rebuild a worker, keep the original blueprint around. Instantiated workers no longer round-trip back into a blueprint once the prompt function has been consumed.
+3. Hooks and tools can still be registered on the live worker; blueprint captures their state only before instantiation.
+
+## Developer Notes
+
+- Examples (`builder_basic`, `plugin_usage`) and README now illustrate the blueprint workflow and static system prompts.
+- Internal helpers were adjusted so that workers maintain only runtime state while blueprint owns all configuration.