v0.1.7-rc4

Hosted engines can finally be selected on the 0.1.7 line.

The presets were being written where nothing reads them

The plugin authors one stripped copy of the deployment's standard preset per hosted engine as a directory under $DSH_HOME/.agent-presets/. That is the 0.1.5 mechanism, and 0.1.7 deleted it: the dsh-agent-presets package is gone, a preset is now a composed @deepseek-ai/dsh-agent-preset row, and no harness code reads that directory any more.

Measured on a live 0.1.7-rc.2 web host with the plugin installed and authoring reporting success, the roster answered ["standard","ptc","minimal","cordis"] -- none of the four loop-engine-*. So session/create {agentPreset:'loop-engine-kimi'} failed with Unknown agent preset: loop-engine-kimi, and every session fell back to the harness loop. That single cause accounts for the whole family of preset errors: hosted engines could not be selected at all.

agentPresets.register() is not the fix -- activate() requires entry OBJECTS and every public read exposes only ids, text, or an inventory without config. So the modern line writes the presets where the harness looks: four - insert: rows of @deepseek-ai/dsh-agent-preset in the profile patch the plugin already manages, each config.plugins being the source composition minus the stripped rows. That reuses the existing textual strip (no YAML parser, no new dependency), is rewritten atomically and idempotently like the managed block, and falls back to plugins: [] rather than a valueless key that would fail the whole profile boot. The 0.1.5 line keeps the directory authoring and gains no rows.

Verified end to end on 0.1.7-rc.2

Boot a web host, session/create {agentPreset:'loop-engine-kimi'} succeeds, the session records that preset, its request/header provider is external (the plugin's hosted route -- the Kimi driver drove it), the model answers, a Bash tool call is attempted and recorded, and the durable log passes the harness's own V4 relationship validation with zero projection mismatches and zero duplicated results. The YAML shape was separately proven loadable with the harness's own loader (entryListSchema + applyEntryPatches + entryListProblem).

Both suites green: 62 files / 1181 cases on 0.1.7 (per-file coverage still 100%), 1179 passed plus the 2 modern-only tests skipped on the 0.1.5 line. No peer-range change, so nothing moves for users on either line.