Problem. The Runtime preset trait is too narrow for two composition paths, so neither can use the runtime::<R>() shortcut and both wire assembly the long way:
- Linker extensions. The trait bundles only components and add-ons, so a preset that also needs a linker
Extension (the cow-api capability namespace) is inexpressible. nexum-cli wires the long way purely to attach with_extensions([extension::<ReferenceTypes>()]).
- Pre-built instances.
components()/add_ons() are static factories that build from config, so a preset cannot hand back an already-built, programmable instance. A testing MockRuntime preset that returns pre-wired mock chain/store handles is therefore impossible; the mock path uses a Prebuilt<T> component-builder through ComponentsBuilder::new instead, bypassing the preset trait.
Current. trait Runtime { type Types; type ChainBuilder; type StoreBuilder; type ExtBuilder; fn components() -> ComponentsBuilder<..>; fn add_ons() -> AddOns; }. The Ext/ExtBuilder slot is a component backend payload (RuntimeTypes::Ext), not the linker Extension; extensions are supplied separately by the caller, and every component is built from config rather than accepted pre-built.
Change. Decide how far the preset trait should stretch: an fn extensions() provider so a domain preset carries its full launch surface, and/or a pre-built-instance path so a preset can hand back owned, already-wired components. Weigh against #94's position that the preset marker is deliberately not the vehicle for every assembly, and note the mock ergonomics are already met by the harness plus Prebuilt<T> (a MockRuntime preset would be a shortcut, not a functional gap).
Consumers.
Files. crates/nexum-runtime/src/preset.rs, crates/nexum-runtime/src/builder.rs (the PresetBuilder stage).
Risk / size. M; a trait-surface addition plus a design decision.
Depends on. #93. Relates to #80, #274.
Problem. The
Runtimepreset trait is too narrow for two composition paths, so neither can use theruntime::<R>()shortcut and both wire assembly the long way:Extension(the cow-api capability namespace) is inexpressible.nexum-cliwires the long way purely to attachwith_extensions([extension::<ReferenceTypes>()]).components()/add_ons()are static factories that build from config, so a preset cannot hand back an already-built, programmable instance. A testingMockRuntimepreset that returns pre-wired mock chain/store handles is therefore impossible; the mock path uses aPrebuilt<T>component-builder throughComponentsBuilder::newinstead, bypassing the preset trait.Current.
trait Runtime { type Types; type ChainBuilder; type StoreBuilder; type ExtBuilder; fn components() -> ComponentsBuilder<..>; fn add_ons() -> AddOns; }. TheExt/ExtBuilderslot is a component backend payload (RuntimeTypes::Ext), not the linkerExtension; extensions are supplied separately by the caller, and every component is built from config rather than accepted pre-built.Change. Decide how far the preset trait should stretch: an
fn extensions()provider so a domain preset carries its full launch surface, and/or a pre-built-instance path so a preset can hand back owned, already-wired components. Weigh against #94's position that the preset marker is deliberately not the vehicle for every assembly, and note the mock ergonomics are already met by the harness plusPrebuilt<T>(aMockRuntimepreset would be a shortcut, not a functional gap).Consumers.
ReferenceRuntimepreset (needs extensions), parked post-split in packaging: carve nexum-runtime, videre and shepherd into three repos #274.MockRuntimetesting preset (needs pre-built instances), epic epic: mock preset and testing DX #80.nexum-clionto theruntime::<R>()shortcut (needs extensions).Files.
crates/nexum-runtime/src/preset.rs,crates/nexum-runtime/src/builder.rs(thePresetBuilderstage).Risk / size. M; a trait-surface addition plus a design decision.
Depends on. #93. Relates to #80, #274.