dsh-loop-engine 0.1.5-rc4 → 0.1.7-rc1

package/lib/types/client/turn-status.d.ts

@@ -20,8 +20,8 @@
  * default, a session running pi included.
  *
  * The reflection's SUBJECT is still a document-level attribute rather than the
- * row's own element: the sheet has to reach a class the harness hashes
- * (`[class$="_turnStatus"]`), which takes an attribute selector on an ancestor,
+ * row's own element: the sheet has to reach a class the harness hashes (see
+ * {@link ROW_SELECTORS}), which takes an attribute selector on an ancestor,
  * and the row offers no session-scoped hook for a plugin to hang it on. A
  * document-level attribute has exactly ONE owner at a time, though — and on this
  * page the WRITERS outnumber the reader: the chip and the composer of every
@@ -47,10 +47,24 @@
  * paints by it, and a leftover attribute is inert on a page whose turn-status row
  * is not rendered.
  *
+ * The paint is also gated on the session being MID-TURN, through a second
+ * document-level attribute ({@link RUNNING_ATTR}, written from the same
+ * reflection). On the 0.1.5 line the row only exists while a turn is in flight,
+ * so the engine attribute alone was enough; on the 0.1.7 line that same button
+ * stays on screen after the turn ends, as the collapsed summary that reads
+ * "用时 4秒" — an engine-only gate leaves the glyph and the sweep animating on a
+ * finished turn, which is not what the live line means. The gate is a surface's
+ * own answer (`session.running`, which every session-scoped seat receives), so a
+ * surface that cannot answer passes nothing and leaves it alone rather than
+ * guessing.
+ *
  * Three facts about the harness markup make that safe and specific:
- *   - the row carries exactly one class whose `[hash]_turnStatus` suffix is
- *     stable across rebuilds (the hash in front is not), so
- *     `[class$="_turnStatus"]` matches it and not the sibling clock;
+ *   - the row has one stable handle per harness generation — an
+ *     `[hash]_turnStatus` class suffix on the 0.1.5 line, and, on the 0.1.7
+ *     line, the `data-turn-process` button whose text is a `<span>` whose hashed
+ *     class ends `_label` — so each generation gets its own copy of the sheet
+ *     ({@link ROW_SELECTORS}) and the one the running app renders matches while
+ *     the other stays inert;
  *   - its gradient paints through the `--dsw-static-deepseek-*` custom
  *     properties, so recoloring is a variable override rather than a fight
  *     over `background` and `background-clip`;
@@ -93,6 +107,11 @@ import type { LoopEngineId } from '../agent-preset-ids.ts';
  * clears the attribute, because the sibling surface of the same session is still
  * on screen painting through it.
  *
+ * The MID-TURN gate is written from here as well, but only by a surface that can
+ * answer it (`running` given): the sheet is gated on both, because the 0.1.7 row
+ * outlives its turn, and a surface with no answer must leave the gate as the
+ * surface that has one left it rather than guess.
+ *
  * The NO-OP covers the late reflection as well — the one from the session the
  * user has just left, whose own answer landing after the switch used to paint
  * over the session that replaced it.
@@ -101,8 +120,10 @@ import type { LoopEngineId } from '../agent-preset-ids.ts';
  *   row): such a page has nothing to say about the row, so nothing is written and
  *   nothing is withdrawn — it leaves the row it found alone.
  * @param engine - the engine that session runs, when it is known.
+ * @param running - whether that session is mid-turn, when the surface knows;
+ *   omitted by a surface with no answer, which leaves the gate alone.
  */
-export declare function reflectTurnStatusEngine(sessionId: string | undefined, engine: LoopEngineId | undefined): void;
+export declare function reflectTurnStatusEngine(sessionId: string | undefined, engine: LoopEngineId | undefined, running?: boolean): void;
 /**
  * Declare which session's surfaces are on screen — the row's one subject.
  *

package/lib/types/client/use-session-engine.d.ts

@@ -55,12 +55,20 @@ import type { SessionEngineCache } from './session-engine.ts';
  *
  * One effect does the whole thing, so the three steps cannot come apart: declare
  * this session as the row's subject (`focusTurnStatusSession`), reflect its
- * engine by that declaration (`reflectTurnStatusEngine`), and release the
- * declaration when this surface goes away (`blurTurnStatusSession`, which
- * withdraws it only while it is still this session's).
+ * engine and its mid-turn gate by that declaration (`reflectTurnStatusEngine`),
+ * and release the declaration when this surface goes away
+ * (`blurTurnStatusSession`, which withdraws it only while it is still this
+ * session's).
+ *
+ * `running` is the session's own live state (`session.running`, from the
+ * session-scoped standard kit) and it is part of the effect's key: the 0.1.7 row
+ * stays on screen after the turn ends, so the paint has to come off when the turn
+ * does — a surface that does not know the state passes nothing and leaves the
+ * gate alone.
  * @param cache - the cache the plugin mounted.
  * @param sessionId - the session to follow, or undefined off a session scope.
+ * @param running - whether that session is mid-turn, when the surface knows.
  * @returns the engine report, or undefined while it is unknown.
  */
-export declare function useEngineOfSession(cache: SessionEngineCache, sessionId: string | undefined): SessionEngineReport | undefined;
+export declare function useEngineOfSession(cache: SessionEngineCache, sessionId: string | undefined, running?: boolean): SessionEngineReport | undefined;
 //# sourceMappingURL=use-session-engine.d.ts.map

package/lib/types/compat.d.ts

@@ -0,0 +1,25 @@
+/**
+ * Runtime harness-generation probe. One released build must serve the 0.1.5
+ * line (`0.1.5-rc.1` … `0.1.5-rc.3`, all sharing the OLD settings API) and the
+ * 0.1.7 line (`0.1.7-rc.1`), which rewrote the settings host and client and
+ * turned the agent-creation announcement async. The differences are not
+ * version strings but API SHAPES, so the switch is a structural probe of the
+ * imported module rather than a semver parse: `@deepseek-ai/dsh-settings`
+ * exported a named `SettingsProvider` class on the 0.1.5 line, and the 0.1.7
+ * rewrite deleted it in favour of `SettingsForms` plus per-entry volatile
+ * Config fields.
+ *
+ * The probe resolves to whichever `@deepseek-ai/dsh-settings` the running
+ * profile actually provides. It is host-side only: the browser bundle must not
+ * import host packages, so `src/client/*` never imports this module.
+ *
+ * @module dsh-loop-engine/compat
+ */
+/**
+ * Whether the running harness predates the profile-backed settings rewrite
+ * (the 0.1.5 line). `true` selects the legacy settings host/client, the
+ * synchronous agent-creation announcement, and the legacy tool-result message
+ * introspection.
+ */
+export declare const LEGACY_HARNESS: boolean;
+//# sourceMappingURL=compat.d.ts.map

package/lib/types/driver-core/host-servers.d.ts

@@ -30,8 +30,12 @@ export interface SkillsService {
 export interface AgentPresetsService {
     /** The effective default preset id. */
     readonly defaultId: string;
-    /** Read one preset's composition text. */
-    read(id: string): Promise<string>;
+    /** 0.1.5 line: read one preset's composition text directly. */
+    read?(id: string): Promise<string>;
+    /** 0.1.7 line: read one preset's document; its `content` is the composition text. */
+    readDocument?(id: string): Promise<{
+        readonly content: string;
+    }>;
 }
 /** The host settings service's mutation seam, as this plugin uses it. */
 export interface SettingsMutator {

package/lib/types/driver-core/hosted-engine-runtime.d.ts

@@ -91,9 +91,9 @@ export interface SwapAgentOptions {
  *
  * Creation and resume follow the registry factory contract and the shared
  * publication transaction: prepare, run setup, then publish through both
- * registries, announce, and emit `agent/session-start`. {@link swap} follows the
- * same transaction onto a session another agent entered, which is the only
- * difference between taking a session over and owning it from birth.
+ * registries and await the serial `agent/created` announcement. {@link swap}
+ * follows the same transaction onto a session another agent entered, which is
+ * the only difference between taking a session over and owning it from birth.
  */
 export declare abstract class HostedEngineRuntime<TConfig, TAgent extends HostedAgent> implements AgentFactory {
     /** Validated configuration owned by this engine instance. */

package/lib/types/driver-core/model-handover.d.ts

@@ -32,6 +32,11 @@
  * and never a guess. The warning names the provider and the model, never a
  * credential.
  *
+ * What counts as "recognized" is deliberately narrow: a non-empty `baseURL` and
+ * a resolvable credential. The wire protocol is handed over when the deployment
+ * declares one, but its absence does NOT refuse the handover — see
+ * {@link resolveModelHandover} and {@link SHIPPED_ROUTE_APIS}.
+ *
  * @module dsh-loop-engine/driver-core/model-handover
  */
 import type { Context } from '@deepseek-ai/cordis';
@@ -54,8 +59,13 @@ export interface DshModelHandover {
     readonly model: string;
     /** Endpoint base as dsh configured it. */
     readonly baseURL: string;
-    /** dsh's wire protocol name for this endpoint. */
-    readonly api: string;
+    /**
+     * dsh's wire protocol name for this endpoint, when the deployment declares
+     * one (or {@link SHIPPED_ROUTE_APIS} knows it for a shipped route). `undefined`
+     * is a normal answer, not a failure: engines that need a protocol degrade the
+     * way each one documents, and engines that do not (`claude-code`) ignore it.
+     */
+    readonly api: string | undefined;
     /** The resolved credential value; never logged, never evented. */
     readonly apiKey: string;
 }
@@ -102,8 +112,16 @@ export interface CredentialsService {
  * `undefined` is the answer in exactly two situations: the selection names no
  * real dsh model ({@link SessionModelOverride} is already `undefined` for the
  * hosted seat), or a real model whose endpoint/credential dsh does not disclose
- * to this read. The second case warns once — it is a deployment-shape gap the
- * operator can see and fix, not a silent downgrade.
+ * to this read — no `baseURL`, or no credential. Both warn once: they are
+ * deployment-shape gaps the operator can see and fix, not a silent downgrade.
+ *
+ * The wire protocol is NOT such a gate. A profile that names no `api` still
+ * hands over its endpoint (with `api: undefined`), because refusing would let
+ * the engine send dsh's model id to the engine's OWN endpoint — a failure that
+ * reads like an auth or model problem while the real one is "wrong endpoint".
+ * Shipped routes whose adapter owns the wire are named in
+ * {@link SHIPPED_ROUTE_APIS} so they hand over a real protocol; anything still
+ * unknown degrades per engine, which is the engine's call to make.
  *
  * Called fresh on every step by each driver, so a model or provider picked
  * mid-conversation reaches the engine's next request rather than being frozen

package/lib/types/driver-core/system-head.d.ts

@@ -0,0 +1,43 @@
+/**
+ * Give a session started on a hosted engine the protected system head the
+ * harness's own loop would have logged.
+ *
+ * The harness loop logs the rendered system prompt as a `system/message` on a
+ * session's first step (`packages/core/agent-loop/src/agent.ts`:
+ * `systemPrompt.project` → `session.append('system/message', …)`). A hosted
+ * engine's external CLI owns its own system prompt, so these drivers log no dsh
+ * system message at all: a session that STARTS on a hosted engine has no surface
+ * head, and if it is later served by the in-process loop the harness logs its
+ * system message MID-log. Session format v4 requires the system message — when
+ * one exists — to be the FIRST surface event, so such a mixed session is refused
+ * on the v3→v4 migration (`packages/session/session-format-v3-to-v4/src/
+ * relationships.ts` `foldSurface`: "system/message requires a protected first
+ * surface head").
+ *
+ * Appending an EMPTY system message as the session's first surface event closes
+ * that hole: the head is protected from the start (a later in-process system
+ * message REPLACES it rather than arriving misplaced), and empty content is
+ * dropped from the derived history (`deriveEventMessage` yields `null`), so no
+ * system prompt is injected into what the engine is handed — the drivers build
+ * their prompt from `serializeHistory`, which ignores the `system` role too.
+ *
+ * Conservative and idempotent: it appends ONLY while the session has no surface
+ * event of its own, so a session the harness loop created (or one already
+ * carrying history) is left exactly as it is. A mid-surface system head would be
+ * refused by the SAME v4 rule and is never produced here.
+ *
+ * @module dsh-loop-engine/driver-core/system-head
+ */
+import type { Session } from '@deepseek-ai/dsh-session';
+/**
+ * Append an empty `system/message` head when the session has no surface event
+ * yet, so a hosted-engine session carries the protected head format v4 expects.
+ *
+ * A no-op once any surface event exists: the head can only ever be the FIRST
+ * surface event, and a later one would be refused on migration.
+ * @param session - the session a hosted driver is about to run a step on.
+ * @param turn - the open turn's number.
+ * @param step - the open step's number.
+ */
+export declare function appendSystemHeadIfMissing(session: Session, turn: number, step: number): void;
+//# sourceMappingURL=system-head.d.ts.map

package/lib/types/engine-codex/model-handover.d.ts

@@ -3,17 +3,28 @@
  * overrides and environment that point it at dsh's model.
  *
  * Codex resolves a custom endpoint through `model_providers.<id>` in its own
- * `config.toml` (`base_url`, `wire_api`, and an `env_key` naming the variable
- * the credential is read from), and `codex app-server` accepts those as `-c
- * key=value` overrides — so the handover needs no edit of `~/.codex`. The
+ * `config.toml` (`name`, `base_url`, `wire_api`, and an `env_key` naming the
+ * variable the credential is read from), and `codex app-server` accepts those as
+ * `-c key=value` overrides — so the handover needs no edit of `~/.codex`. The
  * credential travels in the child's environment under {@link CODEX_DSH_API_KEY_ENV},
  * which the `env_key` names.
  *
- * Codex speaks only OpenAI's wires (`responses` or `chat`). A dsh protocol with
- * no codex equivalent (Anthropic Messages) is NOT guessed: `wire_api` is
- * omitted, so codex uses its own default wire against dsh's base URL and fails
- * loud on the request — the honest outcome, since the plugin cannot make codex
- * speak a protocol it does not implement.
+ * `name` is not optional in practice even though the CLI's own docs describe it
+ * as display metadata: codex 0.149.1 (the version this plugin pins) refuses to
+ * load a provider whose `name` is empty — "provider name must not be empty in
+ * `model_providers`" — and that config error kills `app-server` on startup, which
+ * the driver can only report as "process exited unexpectedly". Omitting it looked
+ * correct and failed before any request was ever sent, so every override this
+ * module builds carries it (verified against the pinned binary).
+ *
+ * Codex speaks only OpenAI's `responses` wire as of the version this plugin pins
+ * (0.149.1 dropped `chat`). A dsh protocol with no codex equivalent (Anthropic
+ * Messages, and now OpenAI Chat Completions) is NOT guessed: `wire_api` is
+ * omitted, so codex falls back to its own default wire and fails loud on the
+ * request — the honest outcome, since the plugin cannot make codex speak a
+ * protocol it does not implement. That default is `responses` as of 0.149.1: the
+ * request lands on `<baseURL>/responses`, which an Anthropic Messages or Chat
+ * Completions endpoint does not serve.
  *
  * @module dsh-loop-engine/engine-codex/model-handover
  */
@@ -36,7 +47,8 @@ export interface CodexModelConfig {
  * The provider id ({@link CODEX_DSH_PROVIDER}) is a plugin-owned name: it exists
  * only in this child's command line, so it cannot collide with a provider the
  * user configured, and the model itself is still handed over as the thread's own
- * `model` param.
+ * `model` param. The provider's `name` repeats that id because codex rejects an
+ * empty one at config load, before any request is made.
  * @param handover - the resolved dsh endpoint for the session's selection.
  * @returns the argv entries and environment to spawn the app-server with.
  */

package/lib/types/engine-pi/model-handover.d.ts

@@ -17,6 +17,10 @@
  * user's own `~/.pi` skills/auth/theme. That is the trade the deployment makes
  * by selecting a real dsh model on pi.
  *
+ * pi's provider schema requires a wire protocol (`api`), so this is the one
+ * engine that cannot express a handover without one; the driver drops such a
+ * handover before it reaches here instead of writing a file pi rejects.
+ *
  * @module dsh-loop-engine/engine-pi/model-handover
  */
 import type { DshModelHandover } from '../driver-core/model-handover.ts';

package/lib/types/index.d.ts

@@ -29,7 +29,7 @@
  * with no record) — it is no longer the thing that decides a running session's
  * engine.
  *
- * The `agent-loop-engine` settings section carries the DEFAULT engine for new
+ * The plugin's own live `engine` Config field carries the DEFAULT engine for new
  * sessions — which preset the roster's default points at — not a process-wide
  * switch: existing sessions keep the engine they run, and nothing is torn down or
  * reloaded by it. (A PER-SESSION switch is a different thing: it is made from the
@@ -38,10 +38,11 @@
  *
  * @module dsh-loop-engine
  */
-import type { Context } from '@deepseek-ai/cordis';
+import type { Context, Volatile } from '@deepseek-ai/cordis';
 import z from '@deepseek-ai/schemastery';
 import { type Config as ClaudeCodeConfig } from './engine-claude/loop.ts';
 import type { CodexApprovalPolicy, CodexSandboxMode } from './engine-codex/types.ts';
+import { type LoopEngineId } from './settings.ts';
 export declare const name = "loop-engine";
 /**
  * Services the plugin's own fiber requires. The plugin declares none of its
@@ -69,7 +70,20 @@ export interface Config extends ClaudeCodeConfig {
     piThinking?: string;
     /** Kimi CLI executable; `'kimi'` resolves through PATH when not pinned to an absolute path. */
     kimiBin?: string;
+    /**
+     * Default engine NEW sessions are created on. A live, profile-backed field:
+     * the settings shell edits it and the running plugin reads it through this
+     * volatile reference (`config.engine.get()`).
+     */
+    engine: Volatile<LoopEngineId>;
+    /** Whether the chat composer shows the engine picker; a live, profile-backed field. */
+    showInComposer: Volatile<boolean>;
 }
+/** Rejected input of the composition entry: live fields arrive as plain values and resolve to references. */
+type ConfigInput = Omit<Config, 'engine' | 'showInComposer'> & {
+    engine?: LoopEngineId;
+    showInComposer?: boolean;
+};
 /**
  * Schema of the loop engine composition entry.
  *
@@ -80,8 +94,15 @@ export interface Config extends ClaudeCodeConfig {
  * omitted deployment tunables fall back to the session). The composition entry
  * is an engine-agnostic superset: every hosted engine's knobs live here at
  * once, because any session may select any engine.
+ *
+ * On the 0.1.7 line `engine` and `showInComposer` are the entry's live fields:
+ * `.volatile()` makes them profile-backed settings the settings shell projects
+ * as form fields, and the runtime reads each one through its reference
+ * (`config.engine.get()`). On the 0.1.5 line there are no live Config fields —
+ * the selection is a settings section (`LOOP_ENGINE_SETTINGS_SCHEMA`), whose
+ * provider owns the storage — so the entry is the engine knobs alone.
  */
-export declare const Config: z<Config>;
+export declare const Config: z<ConfigInput, Config>;
 /** Resolve the managed patch file from configuration, defaulting to the web profile. */
 export declare function resolvePatchPath(config: Config): string;
 /** Atomically replace the patch file (same-directory temp + rename). */
@@ -112,4 +133,5 @@ export declare function syncManagedBlock(path: string): Promise<boolean>;
  * @param config - composition entry for the managed patch file and engine knobs.
  */
 export declare function apply(ctx: Context, config: Config): void;
+export {};
 //# sourceMappingURL=index.d.ts.map

package/lib/types/namespace.d.ts

@@ -1,9 +1,25 @@
 /**
- * Loop engine namespace literal: the one string both halves agree on, in a
- * module with no runtime imports so the browser bundle can import it without
+ * Loop engine namespace literals: the strings both halves agree on, in a
+ * module with no runtime imports so the browser bundle can import them without
  * dragging `dsh-settings` (a host-side service) into the client artifact.
  * @module dsh-loop-engine/namespace
  */
-/** Settings namespace carrying the deployment's selected agent loop engine. */
-export declare const LOOP_ENGINE_SETTINGS_NAMESPACE_LITERAL = "agent-loop-engine";
+/**
+ * Settings namespace carrying the deployment's selected agent loop engine on
+ * the 0.1.7 line.
+ *
+ * Profile-backed settings are addressed by the composing entry id, so this
+ * literal is the plugin's own profile entry id: the shipped `cordis.patch.yml`
+ * inserts the entry as `loop-engine`, and the browser half passes the same
+ * string to `ctx.configForms.get(...)`. A deployment that renames the entry id
+ * must change this literal with it.
+ */
+export declare const LOOP_ENGINE_SETTINGS_NAMESPACE_LITERAL = "loop-engine";
+/**
+ * Settings namespace carrying the same selection on the 0.1.5 line, where a
+ * settings section is addressed by the namespace a provider registers rather
+ * than by a composing entry id. This is the literal the pre-rewrite plugin
+ * shipped; it is stable across the whole 0.1.5 line.
+ */
+export declare const LEGACY_LOOP_ENGINE_SETTINGS_NAMESPACE_LITERAL = "agent-loop-engine";
 //# sourceMappingURL=namespace.d.ts.map

package/lib/types/preset.d.ts

@@ -68,10 +68,14 @@ export declare const STRIPPED_ROWS: readonly ["skill-filesystem", "tool-skill",
  * @returns the stripped composition.
  */
 export declare function stripPresetRows(text: string, ids?: readonly string[]): string;
-/** Minimal read seam over the host's preset roster (`AgentPresets.read`). */
+/** Minimal read seam over the host's preset roster, per harness generation. */
 export interface PresetCompositionSource {
-    /** Read one preset's composition text; throws when the id is unknown. */
-    read(id: string): Promise<string>;
+    /** 0.1.5 line: read one preset's composition text; throws when the id is unknown. */
+    read?(id: string): Promise<string>;
+    /** 0.1.7 line: read one preset's document; `content` is the composition text. */
+    readDocument?(id: string): Promise<{
+        readonly content: string;
+    }>;
 }
 /**
  * Regenerate every hosted engine's preset under the dsh home's user preset root

package/lib/types/settings.d.ts

@@ -1,21 +1,30 @@
 /**
- * Shared loop-engine identity, namespace, and schema.
+ * Shared loop-engine identity, namespaces, and schemas.
  *
- * Both the namespace literal and the engine/preset-id mapping live in
+ * Both the namespace literals and the engine/preset-id mapping live in
  * zero-import modules (`./namespace.ts`, `./agent-preset-ids.ts`) so both halves
  * agree on them: the node half brands the literal as a `SettingsNamespace` and
- * builds this schema, while the browser half imports the same literals without
- * pulling host-side packages (`dsh-settings`, `schemastery`, `node:fs`) into the
- * client bundle (cross-plugin value imports go through cordis services, and
- * `settings-scope.ts` follows the same discipline). This module re-exports them
- * so node-side importers keep their paths.
+ * builds these schemas, while the browser half imports the same literals
+ * without pulling host-side packages (`dsh-settings`, `schemastery`, `node:fs`)
+ * into the client bundle (cross-plugin value imports go through cordis
+ * services). This module re-exports them so node-side importers keep their
+ * paths.
+ *
+ * The two live schema families exist because one build serves two harness
+ * generations: the 0.1.5 line addresses a settings SECTION registered by a
+ * provider under a namespace string ({@link LOOP_ENGINE_SETTINGS_SCHEMA} via
+ * {@link loopEngineSettingsNamespace}), while the 0.1.7 line makes the plugin's
+ * two live fields profile-backed Config entries
+ * ({@link LOOP_ENGINE_ENGINE_SCHEMA} / {@link LOOP_ENGINE_SHOW_IN_COMPOSER_SCHEMA}).
+ * Which family a running plugin builds is decided by `./compat.ts`
+ * (`LEGACY_HARNESS`) in `./index.ts`.
  *
  * @module dsh-loop-engine/settings
  */
 import z from '@deepseek-ai/schemastery';
 import type { SettingsNamespace } from '@deepseek-ai/dsh-settings';
 import type { LoopEngineId } from './agent-preset-ids.ts';
-export { LOOP_ENGINE_SETTINGS_NAMESPACE_LITERAL } from './namespace.ts';
+export { LOOP_ENGINE_SETTINGS_NAMESPACE_LITERAL, LEGACY_LOOP_ENGINE_SETTINGS_NAMESPACE_LITERAL } from './namespace.ts';
 export { HOSTED_ENGINE_IDS, HOSTED_PRESET_PREFIX, LOOP_ENGINE_IDS, SOURCE_PRESET_ID, engineOfPreset, enginePresetId, } from './agent-preset-ids.ts';
 export type { HostedEngineId, LoopEngineId } from './agent-preset-ids.ts';
 /** Stored and composed loop engine selection. */
@@ -26,10 +35,21 @@ export interface LoopEngineSettings {
     showInComposer: boolean;
 }
 /**
- * Schema of the loop engine settings section. The engine union derives from
- * {@link LOOP_ENGINE_IDS}, so adding an engine there also admits it here.
+ * Schema of the loop engine settings section, as the 0.1.5 line's settings host
+ * consumes it. The engine union derives from {@link LOOP_ENGINE_IDS}, so adding
+ * an engine there also admits it here.
  */
 export declare const LOOP_ENGINE_SETTINGS_SCHEMA: z<LoopEngineSettings>;
-/** The shared literal branded as a settings namespace on the node side. */
+/** The 0.1.5-line namespace branded as a settings namespace on the node side. */
 export declare function loopEngineSettingsNamespace(): SettingsNamespace;
+/**
+ * Live Config field schema for the default engine (0.1.7 line). `.volatile()`
+ * declares it profile-backed: the settings shell projects it as a form field,
+ * and a committed edit reaches the running plugin through the live Config
+ * reference. The engine union derives from {@link LOOP_ENGINE_IDS}, so adding
+ * an engine there admits it here too.
+ */
+export declare const LOOP_ENGINE_ENGINE_SCHEMA: z<"in-process" | "claude-code" | "codex" | "pi" | "kimi", "in-process" | "claude-code" | "codex" | "pi" | "kimi", "volatile-defined">;
+/** Live Config field schema for the composer picker toggle (0.1.7 line). */
+export declare const LOOP_ENGINE_SHOW_IN_COMPOSER_SCHEMA: z<boolean, boolean, "volatile-defined">;
 //# sourceMappingURL=settings.d.ts.map

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "dsh-loop-engine",
   "description": "Web-switchable agent loop engine selection for the DeepSeek Harness - out-of-tree plugin (Claude Code / Codex / Pi / Kimi Code drivers) maintained by @kuun993, zero main-repo changes",
-  "version": "0.1.5-rc4",
+  "version": "0.1.7-rc1",
   "publishConfig": {
     "access": "public"
   },
@@ -63,39 +63,39 @@
   "dependencies": {
     "@anthropic-ai/claude-agent-sdk": "0.3.220",
     "@anthropic-ai/sdk": "0.93.0",
-    "@deepseek-ai/schemastery": "3.18.1",
+    "@deepseek-ai/schemastery": "3.18.4",
     "@earendil-works/pi-coding-agent": "0.84.3",
     "@openai/codex": "0.149.1"
   },
   "peerDependencies": {
     "@deepseek-ai/cordis": "^4.0.1",
-    "@deepseek-ai/dsh-agent": "0.1.5-rc.2",
-    "@deepseek-ai/dsh-agent-loop": "0.1.5-rc.2",
-    "@deepseek-ai/dsh-invariants": "0.1.5-rc.2",
-    "@deepseek-ai/dsh-llm": "0.1.5-rc.2",
-    "@deepseek-ai/dsh-scope": "0.1.5-rc.2",
-    "@deepseek-ai/dsh-session": "0.1.5-rc.2",
-    "@deepseek-ai/dsh-session-persistence": "0.1.5-rc.2",
-    "@deepseek-ai/dsh-settings": "0.1.5-rc.2",
-    "@deepseek-ai/dsh-subprocess": "0.1.5-rc.2",
-    "@deepseek-ai/dsh-timeout": "0.1.5-rc.2",
-    "@deepseek-ai/dsh-typert-protocol": "0.1.5-rc.2"
+    "@deepseek-ai/dsh-agent": ">=0.1.5-rc.1 <0.1.6-0 || >=0.1.7-rc.1 <0.1.8-0",
+    "@deepseek-ai/dsh-agent-loop": ">=0.1.5-rc.1 <0.1.6-0 || >=0.1.7-rc.1 <0.1.8-0",
+    "@deepseek-ai/dsh-invariants": ">=0.1.5-rc.1 <0.1.6-0 || >=0.1.7-rc.1 <0.1.8-0",
+    "@deepseek-ai/dsh-llm": ">=0.1.5-rc.1 <0.1.6-0 || >=0.1.7-rc.1 <0.1.8-0",
+    "@deepseek-ai/dsh-scope": ">=0.1.5-rc.1 <0.1.6-0 || >=0.1.7-rc.1 <0.1.8-0",
+    "@deepseek-ai/dsh-session": ">=0.1.5-rc.1 <0.1.6-0 || >=0.1.7-rc.1 <0.1.8-0",
+    "@deepseek-ai/dsh-session-persistence": ">=0.1.5-rc.1 <0.1.6-0 || >=0.1.7-rc.1 <0.1.8-0",
+    "@deepseek-ai/dsh-settings": ">=0.1.5-rc.1 <0.1.6-0 || >=0.1.7-rc.1 <0.1.8-0",
+    "@deepseek-ai/dsh-subprocess": ">=0.1.5-rc.1 <0.1.6-0 || >=0.1.7-rc.1 <0.1.8-0",
+    "@deepseek-ai/dsh-timeout": ">=0.1.5-rc.1 <0.1.6-0 || >=0.1.7-rc.1 <0.1.8-0",
+    "@deepseek-ai/dsh-typert-protocol": ">=0.1.5-rc.1 <0.1.6-0 || >=0.1.7-rc.1 <0.1.8-0"
   },
   "devDependencies": {
-    "@deepseek-ai/dsh-agent-loop": "0.1.5-rc.2",
-    "@deepseek-ai/dsh-attachment": "0.1.5-rc.2",
-    "@deepseek-ai/dsh-client-locale": "0.1.5-rc.2",
-    "@deepseek-ai/dsh-client-store": "0.1.5-rc.2",
-    "@deepseek-ai/dsh-client-ui-conversation": "0.1.5-rc.2",
-    "@deepseek-ai/dsh-client-ui-primitives": "0.1.5-rc.2",
-    "@deepseek-ai/dsh-client-ui-renderer": "0.1.5-rc.2",
-    "@deepseek-ai/dsh-client-ui-settings": "0.1.5-rc.2",
-    "@deepseek-ai/dsh-client-ui-slots": "0.1.5-rc.2",
-    "@deepseek-ai/dsh-home-paths": "0.1.5-rc.2",
-    "@deepseek-ai/dsh-session-persistence-jsonl": "0.1.5-rc.2",
-    "@deepseek-ai/dsh-subprocess-local": "0.1.5-rc.2",
-    "@deepseek-ai/dsh-system-prompt": "0.1.5-rc.2",
-    "@deepseek-ai/dsh-typert-protocol": "0.1.5-rc.2",
+    "@deepseek-ai/dsh-agent-loop": "0.1.7-rc.1",
+    "@deepseek-ai/dsh-attachment": "0.1.7-rc.1",
+    "@deepseek-ai/dsh-client-locale": "0.1.7-rc.1",
+    "@deepseek-ai/dsh-client-store": "0.1.7-rc.1",
+    "@deepseek-ai/dsh-client-ui-conversation": "0.1.7-rc.1",
+    "@deepseek-ai/dsh-client-ui-primitives": "0.1.7-rc.1",
+    "@deepseek-ai/dsh-client-ui-renderer": "0.1.7-rc.1",
+    "@deepseek-ai/dsh-client-ui-settings": "0.1.7-rc.1",
+    "@deepseek-ai/dsh-client-ui-slots": "0.1.7-rc.1",
+    "@deepseek-ai/dsh-home-paths": "0.1.7-rc.1",
+    "@deepseek-ai/dsh-session-persistence-jsonl": "0.1.7-rc.1",
+    "@deepseek-ai/dsh-subprocess-local": "0.1.7-rc.1",
+    "@deepseek-ai/dsh-system-prompt": "0.1.7-rc.1",
+    "@deepseek-ai/dsh-typert-protocol": "0.1.7-rc.1",
     "@types/node": "^22.20.0",
     "@types/react": "^19.0.0",
     "@vitest/coverage-v8": "^4.1.8",