Problem
A step-scoped dynamic model resolver configured for step.started runs before eve resolves the model, using a synthetic unstamped event without modelId. The public step.started event is emitted later, after selection, and includes the concrete model id. One event name therefore represents two different boundaries and payload contracts.
This makes the dynamic-model callback inconsistent with the public stream and hook event contract. It also prevents the event type from accurately describing when model selection happens.
Investigation
- Decide whether model preparation should have a distinct public lifecycle event, a model-specific private callback, or another explicit API.
- Define ordering relative to model resolution, compaction, dynamic tools/instructions, and the public
step.started event.
- Define whether the resolver event is stamped and what payload it carries.
- Assess stream, hook, compiler, extension-contract, and backwards-compatibility implications before implementation.
- Update types, validation, docs, and lifecycle tests only after choosing the contract.
Scope
This is intentionally separate from #2017 and its implementation in #2020. The role-aware instructions work must preserve the existing dynamic-model lifecycle unchanged.
Problem
A step-scoped dynamic model resolver configured for
step.startedruns before eve resolves the model, using a synthetic unstamped event withoutmodelId. The publicstep.startedevent is emitted later, after selection, and includes the concrete model id. One event name therefore represents two different boundaries and payload contracts.This makes the dynamic-model callback inconsistent with the public stream and hook event contract. It also prevents the event type from accurately describing when model selection happens.
Investigation
step.startedevent.Scope
This is intentionally separate from #2017 and its implementation in #2020. The role-aware instructions work must preserve the existing dynamic-model lifecycle unchanged.