llm-worker-rs/docs/patch_note/v0.5.0.md

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, model metadata, 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, optional precomputed system prompt messages, and optional model feature flags. instantiate() evaluates the prompt (if not already cached) and hands the final string to the Worker.
• Instantiated workers retain the composed system prompt, the original generator closure, and a Model struct describing provider/model/features; the generator only runs again if a new session requires it.
• System prompts are no longer recomputed per turn. Tool metadata is appended dynamically as plain text when native tool support is unavailable.
• Worker now exposes a Model struct (provider, name, features) in place of the previous loose strings and supports_native_tools helper. Capability heuristics remain for built-in providers but applications can override them via WorkerBlueprint::model_features.

Migration Guide

1. Replace any legacy Worker::builder() usage with:

   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.