# Upgrade Notes
> Breaking changes for Framework users, release by release, with the code changes each upgrade needs.
Source:
This page collects the changes a Framework application must make when it upgrades across a release that moved or renamed public Rust APIs. Releases that need no code changes are not listed. For every release, see the [changelog](https://github.com/everruns/everruns/blob/main/CHANGELOG.md).
## 0.48
### Harness tree
The built-in harnesses form a tree by use case instead of one chain. Base now carries the system essentials, Conversation and Worker both build on it, and Bashkit Worker builds on Worker. See [Harnesses](https://everruns.com/docs/features/harnesses/).
* `Harness::worker()` no longer includes a shell. It is the worker kit (files, project instructions, skills, long context, budgeting, subagents, tasks) with no compute. Use `Harness::bashkit_worker()` for the previous files-and-bash behavior.
* `Harness::worker_base()` is deprecated and returns `Harness::bashkit_worker()`.
* `Harness::base()` is no longer empty: it adds compaction, error disclosure, tool-call repair, loop detection and parallel tool calls. Build a custom harness with `Harness::builder` for an empty foundation.
* Agent packages may name `bashkit-worker`; `worker-base` still loads and binds Bashkit Worker.
Hosted organizations are migrated once on upgrade. The old Worker included a shell, so everything bound to it moves to the worker that matches its compute:
* Agents with a container or managed Agent sandbox policy move to Sandbox Worker and keep their policy.
* Every other Agent, the org default, custom child harnesses, triggers and sessions move to Bashkit Worker. A Bashkit-only Agent sandbox policy is cleared because Bashkit Worker fixes it.
* Existing sessions keep the compute they started with.
* `worker-base` stays as a deprecated row with its old capabilities, so custom harnesses that name it keep working.
## 0.46
### Integration-catalog package retired
`everruns-integrations-catalog` published its final deprecated forwarding release at 0.45.0. Its source is removed from the workspace and there is no 0.46.0 release of that package. When upgrading platform dependencies to 0.46, use `everruns-capabilities::integrations_catalog` with `hosted-integration-catalog`, as described below. Hosted registration and integration features are preserved; previously published shim versions remain usable and are not yanked.
## 0.45
### Hosted integration registration moves into capabilities
Replace the `everruns-integrations-catalog` dependency with `everruns-capabilities` and enable its `hosted-integration-catalog` feature. Change imports from `everruns_integrations_catalog::` to `everruns_capabilities::integrations_catalog::`. The public registration API, integration set, registration order, and deployment-grade feature gates are preserved. The old package shipped its deprecated forwarding release at 0.45.0 before source retirement in 0.46. Its published versions remain usable.
Framework applications using `everruns` and its selected integration features need no changes. The hosted integration set remains opt-in.
## 0.42
### SQLite connections move to `everruns::sqlite`
The embedded SQLite wrapper moved out of `everruns-durable` into the `everruns` facade, so the `local` feature no longer compiles the durable engine. `everruns-durable`’s `sqlite` feature and `sqlite` module are removed. Replace `everruns-durable = { features = ["sqlite"] }` with `everruns = { features = ["local"] }` and `everruns_durable::sqlite` with `everruns::sqlite`; the functions and types are unchanged. `everruns_durable::UpdateField` still names `UpdateField`; the `everruns_durable::update_field` module is no longer public.
## 0.41
### Embedded SQLite ownership
`everruns::local::SqliteDb` retains its shared callback API, including callbacks typed as `&rusqlite::Connection`, `rusqlite::params!`, and `OptionalExtension`. Connections now open through `everruns-durable`’s optional `sqlite` feature. Framework applications keep the same local stores and schemas; no data migration is needed. Hosts opening independent handles should use `everruns_durable::sqlite::open` or `open_in_memory` (`everruns::sqlite` from 0.42). To add application tables to the Framework database, retain `SqliteDb` and use its `with_conn` callbacks.
### Retired forwarding crates
The five forwarding packages `everruns-engine`, `everruns-host`, `everruns-builtins`, `everruns-mcp`, and `everruns-ag-ui` are removed from source after their single deprecated 0.40 release. Keep the canonical core imports and feature selections described below; published deprecated versions remain usable.
## 0.40
### Consolidated execution modules
The planned release moves the execution, host, built-in, MCP, AG-UI, and A2A modules into `everruns-core`. Its default features remain portable; opt into the modules your host uses. The five former packages will ship one deprecated forwarding release before removal in the next platform release. Existing behavior and protocol formats will be preserved. This step is gated on the complete 0.39 publication, including its deprecated `everruns-platform` shim, before that shim is removed.
| Deprecated crate prefix | Canonical import | Core feature |
| ----------------------- | --------------------------- | ------------ |
| `everruns_engine::` | `everruns_core::engine::` | `engine` |
| `everruns_host::` | `everruns_core::host::` | `host` |
| `everruns_builtins::` | `everruns_core::builtins::` | `builtins` |
| `everruns_mcp::` | `everruns_core::mcp::` | `mcp` |
| `everruns_ag_ui::` | `everruns_core::ag_ui::` | `ag-ui` |
After upgrading, select concrete integrations on `everruns`, and use `everruns::batteries::runtime_capability_registry()` and `everruns::batteries::runtime_egress_service()` for the matching composition. The core host module accepts explicitly injected services. A custom shell hook host supplies a `BashHookDispatcherFactory` through `HostBackends`; the facade injects the Bashkit factory when its `bashkit` feature is enabled. Utility-model bootstrap configuration will live in `everruns::utility_llm` behind `utility-llm`. A2A protocol and outbound client APIs will be available from `everruns_core::a2a` with the `a2a` feature.
## 0.39
### Hosted capabilities and server records
Replace the `everruns-platform` dependency with `everruns-capabilities` and keep the hosted capability features your application uses. Change hosted registry and runtime-store imports from `everruns_platform::` to `everruns_capabilities::`. The platform name receives one deprecated forwarding release before removal.
Library hosts use `everruns_core::AgentDefinition`, `HarnessDefinition`, and `ExecutionSession` for execution configuration and session views. Persisted agent, harness, session, model, provider, skill, and other management records are owned by the server and are no longer exposed by a library crate. Store adapters resolve authorization, versions, inheritance, and lifecycle before returning portable values. Extensions continue to implement the service interfaces in `everruns-contracts`.
HTTP API paths and serialized responses are unchanged by this ownership move; HTTP clients need no migration.
## 0.38
### Runtime store migration
Custom hosts implementing `everruns_platform::PlatformStore` now return `everruns_core::AgentDefinition`, an inheritance-resolved `everruns_core::HarnessDefinition`, `everruns_core::ExecutionSession`, and `everruns_contracts::typed_id::SessionParticipantId`. Resolve authorization, record projection, harness inheritance, and lifecycle validation in the host adapter. The raw `get_harness_chain` method is removed.
`PlatformStoreSubagentDelegate` remains available to attach this runtime store to a `ToolContext`; the stock `SubagentCapability` needs no host-specific override. `LocalPlatformStore` directly forwards its runner’s portable session views.
The deprecated provider, capability, and model-profile shims are removed after their final release. Depend on `everruns-contracts`; replace `everruns_provider::` with `everruns_contracts::`, `everruns_capability::` with `everruns_contracts::capability::`, and `everruns_model_profiles::` with `everruns_contracts::model_profile_data::`.
### Harness levels
`Harness::base()`, `Harness::conversation()`, `Harness::worker()` and `Harness::bashkit_worker()` share the same capability definitions as the hosted harnesses. `Harness::generic()` is deprecated; it keeps its previous capabilities instead of silently switching to Worker.
Choose the smallest foundation and add agent-specific capabilities. Enable the required host integrations separately. Existing `engine.create(agent)` behavior is unchanged when no harness is bound.
On the hosted platform, upgrades pin existing agents that inherited a Generic org default to Generic before selecting Conversation as the new default. Explicit bindings, sessions and custom defaults remain unchanged. The upgrade runs once; a later explicit choice to use Generic as the org default is respected.
If a custom harness already uses a new built-in name, it keeps its ID, display name, configuration and bindings. Its addressable name becomes `-custom`, with a numeric suffix if needed. Update API or CLI calls that select that custom harness by name; calls using its ID keep working.
## 0.18
0.18 narrows `everruns-core` to the neutral execution kernel. Types that were persisted control-plane records, hosted service contracts, product composition or concrete integrations moved to the crate that owns them. The behaviour, the wire formats and the stored schema are unchanged, only the import paths.
### Retain an Engine for sessions
The Framework exposes a concrete application execution owner. The 0.18 API removes `agent.session()` and `agent.resume(id)`; applications retain the engine that owns session identity and resume authority:
```diff
let session = agent.session();
use everruns::Engine;
let engine = Engine::new();
let session = engine.create(agent);
let id = session.session_id();
let resumed = agent.resume(id).await?;
let resumed = engine.resume(id).await?;
```
`Engine` volatile resume is deliberately process-local and engine-scoped. The old `InMemoryEngine` name remains a type alias. Engine retains the immutable Agent snapshot and exact Environment/WorkspaceHead; it does not serialize a Scale-compatible Agent definition.
For a locally persisted session after process restart, rebuild the Agent from trusted application configuration, call `engine.attach(id, agent).await?`, and then `engine.resume(id).await?`. Attachment verifies the persisted session catalog before accepting the behavior snapshot; credentials and closures are never serialized.
This affects you if your Rust code imports from `everruns_core` directly. If you use the `everruns` facade, most of this is invisible: the facade re-exports what applications need, and where a moved type is part of that surface it is re-exported from its new home under the same name.
### The quickest path
Most migrations are a find-and-replace of a crate prefix. Compile, read the unresolved-import errors, and look each symbol up in the tables below.
```bash
cargo build 2>&1 | grep -E "unresolved import|no .* in"
```
Add whichever crates the table points you at:
```toml
everruns-platform = "0.18" # persisted records, hosted service contracts
everruns-host = "0.18" # execution composition and host wiring
everruns-provider = "0.18" # provider SPI, typed IDs, sqlx impls
everruns-capability = "0.18" # capability identity/configuration contract
everruns-mcp = "0.18" # MCP adapter and the OAuth protocol client
everruns-llmsim = "0.18" # deterministic production-safe simulator
```
The earlier `everruns-session-services` preview package was consolidated into `everruns-host`; use `everruns_host::session_services` for its namespaced API.
### Composition
The single biggest change for embedders. `PlatformDefinition` no longer exists.
| 0.17 | 0.18 |
| ------------------------------------------------------ | --------------------------------------------------- |
| `everruns_core::PlatformDefinition` | `everruns_host::HostComposition` |
| `everruns_core::PlatformDefinitionBuilder` | `everruns_host::HostCompositionBuilder` |
| `everruns_server::oss_platform_definition()` | `everruns_server::oss_host_composition()` |
| `everruns_server::oss_platform_definition_for_grade()` | `everruns_server::oss_host_composition_for_grade()` |
| `everruns_worker::default_platform_definition()` | `everruns_worker::default_host_composition()` |
| `ServerAppBuilder::platform_definition(..)` | `ServerAppBuilder::host_composition(..)` |
| `WorkerAppBuilder::platform_definition(..)` | `WorkerAppBuilder::host_composition(..)` |
```diff
use everruns_core::PlatformDefinition;
use everruns_host::HostComposition;
let platform = PlatformDefinition::builder()
let composition = HostComposition::builder()
.capability_registry(capabilities)
.driver_registry(drivers)
.build();
ServerAppBuilder::new().platform_definition(platform)
ServerAppBuilder::new().host_composition(composition)
```
The type is otherwise identical, same fields, same builder methods. It moved to the layer that executes a turn, because selecting a deployment’s capabilities and drivers is composition rather than kernel configuration.
#### Input/Reason/Act execution kernel
Concrete phase execution moved out of `everruns-core`. Import phase algorithms and their I/O values from `everruns-engine`; keep neutral effect contracts in core.
| 0.17 | 0.18 |
| ------------------------------------------------------------------------------ | ------------------------------------------------------------------------- |
| `everruns_core::atoms::{InputAtom, InputAtomInput, InputAtomResult}` | `everruns_engine::{InputAtom, InputAtomInput, InputAtomResult}` |
| `everruns_core::atoms::{ReasonAtom, ReasonInput, ReasonResult}` | `everruns_engine::{ReasonAtom, ReasonInput, ReasonResult}` |
| `everruns_core::atoms::{ActAtom, ActInput, ActResult, ToolCallResult}` | `everruns_engine::{ActAtom, ActInput, ActResult, ToolCallResult}` |
| `everruns_core::atoms::AtomContext` | `everruns_core::ExecutionContext` (also re-exported by `everruns-engine`) |
| `everruns_core::atoms::{PreToolUseHook, PostToolExecHook, PreToolUseDecision}` | `everruns_core::tool_hooks::*` |
The generic `Atom` trait was removed; it had no production dynamic-dispatch use. Call the concrete executor’s inherent async `execute` method. There is no core compatibility module in 0.18. Serialized phase payloads retain the same fields, so durable records remain readable even though the Rust ownership path changed.
#### Turn context and command completion
Store-backed turn preparation now belongs to `everruns-host`. Core keeps the secret-free execution snapshot, pure context transformations, and narrow effects used by custom hosts.
| 0.17 | 0.18 |
| ---------------------------------------------------- | ---------------------------------------------------- |
| `everruns_core::assemble_turn_context` | `everruns_host::assemble_turn_context` |
| `everruns_core::inspect_turn_context` | `everruns_host::inspect_turn_context` |
| `everruns_core::load_execution_snapshot` | `everruns_host::load_execution_snapshot` |
| `everruns_core::load_execution_snapshot_for_session` | `everruns_host::load_execution_snapshot_for_session` |
| `everruns_core::StoreCommandHost` | `everruns_host::StoreCommandHost` |
`everruns_engine::ReasonAtom::new` no longer accepts harness, agent, session, and provider stores or a driver registry. Construct an `everruns_host::StoreTurnContextResolver` from those host services, then pass that resolver plus the narrow message, capability, and event effects to the atom. Hosts that already loaded a `ResolvedExecutionSnapshot` should call `everruns_host::assemble_turn_context_from_snapshot` and execute the atom with the resulting `AssembledTurnContext`; this avoids a second store load.
For a fully custom host, implement the neutral `everruns_core::TurnContextResolver`, or provide already-resolved `ResolvedTurnContextInput` to `everruns_core::assemble_resolved_turn_context`. That input contains a secret-free model/provider identity and an opaque ready driver; provider keys and endpoints are never serializable kernel values.
`CommandTurnContext` now exposes `session_id` directly instead of an `ExecutionSession`. Commands retain the same filtered messages, effective prompt, locale, model, streaming, and error-decision behavior without receiving a session record.
### Persisted records
These are database and API records. Execution consumes a portable projection of each; the stored row is control-plane state.
| 0.17 (`everruns_core::`) | 0.18 |
| ----------------------------------------------------------------------------------------- | -------------------------------- |
| `Agent`, `AgentVersion`, `AgentStatus`, `AgentVersionChangeKind` | `everruns_platform::` |
| `Harness`, `HarnessStatus`, `BuiltInHarnessDefinition`, `BuiltInHarnessRole` | `everruns_platform::` |
| `Session`, `SessionStatus`, `SessionSource`, `SessionActivity`, `SessionParticipant` | `everruns_platform::` |
| `Workspace`, `WorkspaceStatus` | `everruns_platform::workspace::` |
| `Eval`, `EvalCase`, `EvalRun`, `EvalCaseResult`, `EvalRunDataset`, `EvalTarget`, `Scorer` | `everruns_platform::` |
| `Observer`, `ObserverMatch`, `LlmJudgeConfig`, `TraceScore` | `everruns_platform::` |
| `FeatureFlags`, `FeatureFlagMap`, `FeatureFlagDefinition` | `everruns_platform::` |
| `Budget`, `LedgerEntry` | `everruns_platform::` |
If you were reading a stored record to run a turn, you probably want the portable projection instead, `AgentDefinition`, `HarnessDefinition` and `ExecutionSession` all stay in `everruns_core`, produced at the platform loading boundary by `Agent::execution_definition`, `Harness::execution_definition` and `Session::execution_session`.
### Hosted service contracts
| 0.17 (`everruns_core::`) | 0.18 |
| ------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| `session_sqldb::*`, `SessionSqlDbStore`, `DatabaseInfo`, `SqlQueryResult`, `SqlExecuteResult`, `TableSchema`, `ColumnSchema`, `SessionSqlDbError` | `everruns_platform::session_sqldb::` |
| `traits::SessionMutator` | `everruns_host::SessionMutator` (also re-exported by platform) |
| `session_sandbox::*`, config, state, instance, exec/file payloads, `SessionSandboxProvider`, `SessionSandboxProviderPlugin` | `everruns_platform::session_sandbox::` |
| `Connector`, `ConnectorRegistry`, `ConnectorPlugin` | `everruns_platform::connector::` |
| `EmailSender`, `EmailMessage`, `SystemEmailConfig`, `ResendEmailSender` | `everruns_platform::email::` |
| `OAuthClient`, `TokenSet`, `PkcePair` | `everruns_mcp::oauth::protocol::` |
Neutral per-turn contracts remain in `everruns-core`, but the catch-all `everruns_core::traits` module is gone. Import from the owning concern instead, for example `everruns_core::tool_context::ToolContext`, `everruns_core::session_files::SessionFileSystem`, or `everruns_core::provider_resolution::ProviderStore`. The deployment-owned `SessionFileSystemFactory` and its context now come from `everruns-host`.
Two of these also changed how a capability *reaches* the service. `sqldb_store` and `session_mutator` are no longer fields on `ToolContext`; they resolve from the type-keyed extension bag:
```diff
let Some(store) = &context.sqldb_store else { ... };
let Some(store) = context.extensions.get::() else { ... };
let store = &store.0;
```
If you implement a custom host, install them the way `everruns-host` does:
```rust
extensions.insert(Arc::new(SessionSqlDbStoreExt(store)));
extensions.insert(Arc::new(SessionMutatorExt(mutator)));
```
### Capabilities and implementations
| what | 0.18 home |
| ------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| Knowledge Bases and Indexes, Memories, delegation, subagents, background and scheduled work, user hooks, citations, model scouting, platform management | `everruns_platform::capabilities::` |
| Session info and session storage | `everruns_host::session_services::capabilities::` (also re-exported by platform) |
| Session SQL database and session sandbox | `everruns_platform::capabilities::` |
| `spawn_background` and its runtime, event sink, admission permits, reattach | `everruns_platform::background_run::` |
| Portable built-ins, human intent, infinity context, skills, UI prompts, compaction, tool search | `everruns_builtins::` |
| `everruns_openui::{PromptOptions, default_library, generate_prompt}` | `everruns_builtins::openui::{PromptOptions, default_library, generate_prompt}` |
| `everruns_a2ui::{PromptOptions, default_catalog, generate_prompt}` | `everruns_builtins::a2ui::{PromptOptions, default_catalog, generate_prompt}` |
| OpenRouter workspace, model scout, and provider-executed server tools | `everruns_integrations_openrouter::` |
| Filesystem, shell, web fetch, Lua | `everruns_integrations_*` |
| MCP adapter | `everruns_mcp::` |
| In-process HTTP egress transport | `everruns_host::DirectEgressService` |
| Telemetry init, exporter event listeners, `CompositeEventListener` | `everruns_host::observability::` (feature `observability`) |
| `llmsim` driver, configs, scripted turns, registry helpers, host-builder extension | `everruns_llmsim::` |
| in-memory agentic loop, writable test doubles, fixture capabilities | `everruns_test_support::` |
| `everruns_core::in_memory::{InMemoryAgentStore, InMemoryHarnessStore, InMemorySessionStore, InMemoryProviderStore}` | `everruns_host::{InMemoryAgentStore, InMemoryHarnessStore, InMemorySessionStore, InMemoryProviderStore}` |
| `everruns_core::in_memory::{InMemoryMessageRetriever, InMemoryEventEmitter}` | `everruns_test_support::{InMemoryMessageRetriever, InMemoryEventEmitter}` for isolated deterministic tests |
Product presets compose these explicitly. Core registries are now empty by default: use `everruns_host::runtime_capability_registry()` for the Framework preset or `everruns_platform::capabilities::hosted_capability_registry()` for the hosted product catalog.
Hosted conversation history has no writable message-store replacement. Append canonical events through `everruns_host::EventLog` / `HostEventEmitter` and read messages through `EventHistory`. This avoids message/event dual writes and keeps resume and replay behavior identical across in-memory and durable hosts.
`everruns-test-support` continues to re-export its 0.17 simulator paths during the 0.18 migration, so existing test suites can upgrade without an immediate import rewrite. Treat that as a migration bridge: production code, new tests, and low-level hosts should depend on `everruns-llmsim` directly. The application-facing `everruns::Model::simulated` and `Model::simulated_with_config` APIs are unchanged.
### Features
| 0.17 | 0.18 |
| -------------------------------------- | ------------------------------------------------------------------------- |
| `everruns-core/sqlx` | removed, use `everruns-provider` with `features = ["sqlx"]` |
| `everruns-core/embedded-platform-docs` | removed, it gated nothing; use `everruns-platform/embedded-platform-docs` |
| `everruns-platform/sqlx` | removed, it forwarded to core’s and nothing enabled it |
| `everruns-core/llm-tests` | removed, use the `everruns-llm-tests` package for live provider tests |
`everruns-core` now has an empty default feature set. OpenAPI derives remain available only with `features = ["openapi"]`; structural outlines remain available only with `features = ["tree-sitter-outlines"]`. Neither subtree is present in a default core build.
Concrete provider protocol and utility-model implementations also moved to their effectful owners:
| 0.17 (`everruns_core::`) | 0.18 |
| ------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------- |
| `OpenAIProtocolChatDriver`, `openai_protocol` | `everruns_contracts::` |
| `OpenResponsesProtocolChatDriver`, `openresponses_protocol` | `everruns_contracts::` |
| `driver_helpers`, `stream_reconnect` | `everruns_contracts::` |
| `OpenAiUtilityLlmService` (now `ProviderUtilityLlmService`), `SystemUtilityLlmConfig`, `UTILITY_OPENAI_API_KEY_ENV` | `everruns_host::` with `features = ["utility-llm"]` |
Core no longer initializes Rustls. Provider HTTP clients install the workspace crypto provider when they are first constructed, while server, worker, and CLI startup owners install it eagerly. Custom binaries that combine TLS stacks can depend on `everruns-provider` with `features = ["tls-aws-lc-rs"]` and call `everruns_contracts::install_default_crypto_provider()` once during startup; the call is idempotent and safe under concurrent initialization.
### Provider and typed-ID imports
Provider-owned modules are no longer compatibility-exported by `everruns-core`. Low-level consumers must add `everruns-provider` directly. This keeps credentials and concrete driver assembly out of the neutral kernel and makes the dependency owner visible in `Cargo.toml`.
There are two common compiler-error shapes:
1. **The module moved to another crate.** Add that crate and change the prefix.
2. **The module stayed public, but its root convenience re-export was removed.** Keep the dependency and qualify the symbol through its module.
The second case produces the misleading-looking `no X in the root` error. It does not necessarily mean the type moved. These replacements are deliberately literal so they can be applied with ordinary search-and-replace:
| before | after |
| ---------------------------------- | ---------------------------------------------------- |
| `everruns_core::ProviderStore` | `everruns_core::provider_resolution::ProviderStore` |
| `everruns_core::SessionStore` | `everruns_core::execution_loading::SessionStore` |
| `everruns_core::MessageRetriever` | `everruns_core::message_retriever::MessageRetriever` |
| `everruns_core::SessionFileSystem` | `everruns_core::session_files::SessionFileSystem` |
| 0.17 core path | 0.18 direct path |
| --------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| `everruns_core::driver_registry::*` | `everruns_contracts::driver_registry::*` |
| `everruns_core::model::*` | `everruns_contracts::model::*` |
| `everruns_core::model_profiles::*` | `everruns_contracts::model_profiles::*` |
| `everruns_core::model_spec::ModelSpec` | `everruns_contracts::model_spec::ModelSpec` |
| `everruns_core::provider::*` | `everruns_contracts::provider::*` |
| `everruns_core::runtime_provider::*` | `everruns_contracts::runtime_provider::*` |
| `everruns_core::typed_id::*` | `everruns_contracts::typed_id::*` |
| `everruns_core::error::*` | `everruns_contracts::error::*` |
| `everruns_core::tool_types::*` | `everruns_contracts::tool_types::*` |
| `everruns_core::capability_types::{CapabilityId, CapabilityRef, CapabilityError}` | `everruns_contracts::capability::{CapabilityId, CapabilityRef, CapabilityError}` |
| `everruns_core::AgentCapabilityConfig` | `everruns_contracts::capability::CapabilityRef` |
| core plugin capability ID/validation helpers | the same symbol in `everruns_capability` |
| `everruns_core::ExecutionPhase` or `message::ExecutionPhase` | `everruns_contracts::execution_phase::ExecutionPhase` |
| `everruns_core::ToolResultImage` or `tools::ToolResultImage` | `everruns_contracts::tool_types::ToolResultImage` |
| other root-level provider symbols | the same root symbol in `everruns_provider` |
The credential-bearing `everruns_core::ResolvedModel` is removed. Store and transport boundaries now resolve two separate values:
* `ModelSpec`, safe to serialize and pass through the kernel; and
* a host-owned runtime `Provider` (or internal `ProviderConfig`) containing endpoint and authentication state.
`ProviderStore::get_model_spec` and `get_default_model_spec` return only the first value. Hosts obtain provider configuration separately and join it only while constructing a non-serializable driver/provider execution value.
`ProviderStore::get_provider_config` no longer has a default implementation. Every custom host must state where credentials live: return its resolved `ProviderConfig`, or explicitly return `None` when the provider was registered directly in the host registry or is selected but not configured. A missing credential no longer prevents turn-context/command assembly; the constructed driver rejects the first model/list/compact operation locally, before network I/O. This keeps recovery commands reachable without turning an empty token into an outbound authorization header.
### Simulator and compaction naming
`LlmSimRuntimeExt::llm_sim` now only registers/replaces the simulator provider. It never changes the selected model. Existing compact test setups that relied on implicit selection should use the explicit name:
```diff
builder.llm_sim(config)
builder.llm_sim_as_default(config)
```
When a builder already calls `default_model(...)`, keep `.llm_sim(config)`; the selected model is preserved regardless of method order.
`everruns_builtins::CompactionConfig` is the sole application-facing policy builder. The expanded implementation value previously available as `everruns_builtins::compaction::CompactionConfig` is now `everruns_builtins::compaction::RuntimeCompactionConfig` (also re-exported at the crate root). This makes an unqualified `CompactionConfig` unambiguous.
The public core test/backend conveniences are gone as well:
| removed core value | replacement |
| ----------------------------------- | ------------------------------------------------------------------- |
| `EchoTool`, `FailingTool` | define the small test `Tool` locally, or use test-support executors |
| `InMemoryCompactionCheckpointStore` | `everruns_host::InMemoryCompactionCheckpointStore` |
### What deliberately did not move
Worth knowing so you do not go looking:
* **`SessionTask`, `TaskMessage`** and the task registry stay in `everruns_core`. They are turn-execution vocabulary, `wake_queue` decides mid-turn wakes from a task’s wake policy, and they appear in the canonical `task.created` / `task.updated` / `task.message.*` event payloads.
* **`SessionSchedule`, `SessionScheduleStore`** stay. A portable built-in (`usage_limit_auto_continue`) schedules an auto-resume after a provider usage limit, and it sits below platform in the dependency graph.
* Schedule quota and minimum-interval environment variables are no longer read by core. Local/server adapters resolve deployment policy and call the parameterized core validation helpers.
* **`SessionResourceRegistry`** stays. `resource_ownership` and the portable skills capabilities consume it.
* **`SessionFileSystem`, `SessionStorageStore`** and the other neutral store contracts stay. Core owns the contract; hosts own the backend.
The rule these follow: whether something belongs in the kernel is decided by whether a portable execution path consumes it during a turn, not by whether it is persisted. All four above are persisted, and all four are essential for execution.
### Getting unstuck
If a symbol is not in these tables, import it from the crate that defines it; `everruns-core` no longer acts as a compatibility facade for provider-owned APIs. Framework applications can continue to prefer the higher-level `everruns` facade. The crate-level docs on `everruns-core` record where each remaining family lives and why.