38 lines
2.4 KiB
Markdown
38 lines
2.4 KiB
Markdown
# 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:
|
|
```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.
|