# 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.