dsh-gitbash-shell 0.31.0 → 0.32.0

package/src/schemastery.js

@@ -0,0 +1,178 @@
+/**
+ * dsh-gitbash-shell/schemastery — resolve the ONE schemastery copy whose
+ * semantics match the executing host, instead of whichever copy Node finds
+ * first.
+ *
+ * WHY THIS MODULE EXISTS (issue #12). `@deepseek-ai/schemastery` is a peer, so
+ * it is resolved by walking UP from this plugin's own file. In a hoisted
+ * profile that walk can land on an OLDER copy another dependency hoisted to the
+ * profile root — measured on the reporter's machine: 3.18.2, which has no
+ * `volatile()` — while the host itself runs the copy installed beside its own
+ * shell packages (3.18.4). The executor's base class comes from the HOST's copy
+ * of `@deepseek-ai/dsh-bash-sandbox`: on dsh 0.1.7+ it declares its limits with
+ * `.volatile()` and reads every one of them through `.get()`
+ * (`packages/shell/bash-local/src/index.ts:100-107`, `assertServiceableBashConfig`).
+ * A subclass whose Config was built from a `volatile`-less schemastery
+ * therefore yields PLAIN values and the first shell call dies with
+ * `TypeError: config.timeoutMs.get is not a function`, taking the whole
+ * `ctx.shell` down with it. Issue #6 was the same crash from the other
+ * direction (an unconditional plain Config); v0.24.4 fixed that with a
+ * per-field `schema.volatile` probe, which only helps when the copy we happen
+ * to resolve HAS `volatile()`.
+ *
+ * The choice is therefore driven by the HOST'S BEHAVIOUR, never by our own
+ * resolution order. Asking the base class what it resolves `timeoutMs` to is a
+ * direct read of "does this host call `.get()`?" — true on 0.1.7+, false on
+ * <= 0.1.6 where plain values are the correct answer. Only when the host wants
+ * Volatile refs do we insist on a copy that provides them, and only then do we
+ * try the parent package's own resolution domain first. An unreadable parent
+ * Config keeps the historical behaviour (our own copy, per-field probe), so an
+ * unknown host is never made worse.
+ */
+
+import { createRequire } from 'node:module'
+import { pathToFileURL } from 'node:url'
+
+/** The peer whose copy must agree with the host. */
+export const SCHEMASTERY_PEER = '@deepseek-ai/schemastery'
+
+/** The package whose resolution domain is authoritative — the executor we extend. */
+export const SCHEMASTERY_PARENT = '@deepseek-ai/dsh-bash-sandbox'
+
+const TAG = '[gitbash-shell]'
+
+/** Node's own answer for `specifier` as seen from `base`, or `''` when it fails. */
+export function resolveFrom(base, specifier) {
+  try {
+    return createRequire(base).resolve(specifier)
+  } catch {
+    return ''
+  }
+}
+
+/** Whether one loaded module looks like a usable schemastery. */
+export function isSchemastery(z) {
+  return !!z && typeof z.object === 'function'
+}
+
+/** Whether one loaded schemastery can produce Volatile refs. */
+export function hasVolatile(z) {
+  if (!isSchemastery(z)) return false
+  try {
+    return typeof z.string().volatile === 'function'
+  } catch {
+    return false
+  }
+}
+
+/**
+ * Ask the executing host whether it reads its shell limits through `.get()`.
+ *
+ * `SandboxBashExecutor.Config({})` is the host's OWN schema, built from the
+ * host's own schemastery: it resolves `timeoutMs` to a `Volatile` ref exactly
+ * when the host declares volatile fields. Behaviour, not internals — no private
+ * schema shape is read.
+ *
+ * @param ParentConfig - the base class's `static Config`, if it has one.
+ * @returns `true`/`false` when the host answered, `undefined` when it could not.
+ */
+export function hostWantsVolatileRefs(ParentConfig) {
+  if (typeof ParentConfig !== 'function') return undefined
+  try {
+    const resolved = ParentConfig({})
+    if (!resolved || typeof resolved !== 'object') return undefined
+    return typeof resolved.timeoutMs?.get === 'function'
+  } catch {
+    return undefined
+  }
+}
+
+/**
+ * Pick one already-loaded copy. Pure, so the matrix is testable without a
+ * filesystem: the caller supplies the candidates and their resolution order.
+ *
+ * @param options - the host's answer, our own entry path, and the loaded copies in priority order.
+ * @returns the chosen copy (or undefined) and why, for the log line.
+ */
+export function chooseCopy({ needsVolatile, ownEntry, copies }) {
+  const own = copies.find((copy) => copy.entry === ownEntry)
+  if (copies.length === 0) return { chosen: undefined, reason: 'unresolved' }
+  if (needsVolatile === false) {
+    // <= 0.1.6 reads plain values: the historical answer is the correct one.
+    return { chosen: own ?? copies[0], reason: 'host-plain' }
+  }
+  if (needsVolatile === true) {
+    // Our own copy is the historical answer: keep it whenever it can serve, and
+    // redirect ONLY when it cannot (that redirection is the whole point of #12).
+    if (own !== undefined && hasVolatile(own.z)) return { chosen: own, reason: 'host-volatile' }
+    const capable = copies.find((copy) => hasVolatile(copy.z))
+    return capable
+      ? { chosen: capable, reason: 'host-volatile-redirected' }
+      : { chosen: own ?? copies[0], reason: 'no-volatile-anywhere' }
+  }
+  // The host could not answer: keep the pre-#12 behaviour (our own copy) rather
+  // than guessing a semantics change on its behalf.
+  return { chosen: own ?? copies[0], reason: 'host-unknown' }
+}
+
+/** Load one module by absolute entry path. */
+async function loadAt(entry) {
+  const mod = await import(pathToFileURL(entry).href)
+  return mod?.default ?? mod
+}
+
+/** One process-wide answer: the module graph does not change under us. */
+let cached = null
+
+/**
+ * Resolve, load, and cache the schemastery copy that matches the executing host.
+ *
+ * @param options - `parentConfig` is the executor base class's `static Config`.
+ * @returns the chosen module (or undefined), where it came from, the host's answer, and the reason.
+ */
+export async function loadSchemastery({ parentConfig } = {}) {
+  if (cached !== null) return cached
+  const needsVolatile = hostWantsVolatileRefs(parentConfig)
+  const ownEntry = resolveFrom(import.meta.url, SCHEMASTERY_PEER)
+
+  const wanted = []
+  const parentEntry = resolveFrom(import.meta.url, SCHEMASTERY_PARENT)
+  if (parentEntry !== '') {
+    const beside = resolveFrom(parentEntry, SCHEMASTERY_PEER)
+    if (beside !== '' && beside !== ownEntry) wanted.push({ where: 'the shell packages', entry: beside })
+  }
+  if (ownEntry !== '') wanted.push({ where: 'this plugin', entry: ownEntry })
+
+  const copies = []
+  for (const candidate of wanted) {
+    try {
+      const z = await loadAt(candidate.entry)
+      if (isSchemastery(z)) copies.push({ where: candidate.where, entry: candidate.entry, z })
+    } catch { /* try the next domain */ }
+  }
+
+  const { chosen, reason } = chooseCopy({ needsVolatile, ownEntry, copies })
+  const result = { z: chosen?.z, source: chosen?.where ?? '', entry: chosen?.entry ?? '', needsVolatile, reason }
+  cached = result
+
+  if (result.z === undefined) {
+    console.warn(`${TAG} ${SCHEMASTERY_PEER} is not resolvable from this plugin or from ${SCHEMASTERY_PARENT}; the row Config surface is absent`)
+  } else if (reason === 'no-volatile-anywhere') {
+    // The one case the plugin cannot paper over: the host calls `.get()` on
+    // plain values, so every shell call would fail. Say so where the user will
+    // see it, instead of leaving a mystery TypeError.
+    console.warn(
+      `${TAG} this host reads its shell limits through .get() but NO resolvable ${SCHEMASTERY_PEER} provides volatile()`
+      + ` (tried: ${wanted.map((w) => `${w.where} -> ${w.entry}`).join('; ') || 'nothing resolved'}).`
+      + ' Shell calls will fail with "config.timeoutMs.get is not a function"; install a dsh whose schemastery matches its own shell packages.',
+    )
+  } else if (chosen.where === 'the shell packages') {
+    console.log(`${TAG} ${SCHEMASTERY_PEER} taken from the shell packages instead of this plugin's own resolution (${reason}): ${chosen.entry}`)
+  }
+  return result
+}
+
+/** Test seam: forget the cached answer. */
+export function resetSchemasteryCache() {
+  cached = null
+}

package/src/shell.js

@@ -43,7 +43,7 @@ import { DEFAULT_GIT_BASH, bashResolutionReport, effectiveConfiguredBashPath, re
 
 /** Re-exported for callers that historically read it here (the value now lives in bash-path.js). */
 export { DEFAULT_GIT_BASH }
-import z from '@deepseek-ai/schemastery'
+import { loadSchemastery } from './schemastery.js'
 
 
 /** Log prefix, matching src/index.js. */
@@ -77,7 +77,10 @@ const SETTINGS_NAMESPACE = 'gitbash-shell'
  * ones. Published schemastery 3.18.2 has no `volatile()`, which is exactly why
  * the probe (not an unconditional call) is required.
  */
-function live(schema) {
+function live(schema, needsVolatile) {
+  // A <=0.1.6 host reads plain values: never hand it a ref it will not `.get()`
+  // (issue #12 — the host's own answer wins over what our copy happens to offer).
+  if (needsVolatile === false) return schema
   return typeof schema.volatile === 'function' ? schema.volatile() : schema
 }
 
@@ -86,16 +89,19 @@ function live(schema) {
  * the smoke test can drive BOTH eras with a recording stand-in instead of
  * depending on which schemastery happens to be installed here.
  * @param z schemastery module (real one, or the test's recorder).
+ * @param needsVolatile - the host's OWN answer from src/schemastery.js: `true`
+ *   forces Volatile refs, `false` forces plain values, `undefined` keeps the
+ *   per-field probe (the historical behaviour, kept for an unreadable host).
  * @returns the object schema for the `gitbash-executor` row.
  */
-export function gitBashShellConfig(z) {
+export function gitBashShellConfig(z, needsVolatile) {
   return z.object({
-    cwd: live(z.string()),
-    timeoutMs: live(z.number().default(120000)),
-    maxTimeoutMs: live(z.number().default(600000)),
-    maxOutputBytes: live(z.number().default(64000)),
-    maxSpillBytes: live(z.number().default(64 * 1024 * 1024)),
-    graceMs: live(z.number().default(3000)),
+    cwd: live(z.string(), needsVolatile),
+    timeoutMs: live(z.number().default(120000), needsVolatile),
+    maxTimeoutMs: live(z.number().default(600000), needsVolatile),
+    maxOutputBytes: live(z.number().default(64000), needsVolatile),
+    maxSpillBytes: live(z.number().default(64 * 1024 * 1024), needsVolatile),
+    graceMs: live(z.number().default(3000), needsVolatile),
     // Our own knob: the base class neither declares nor `.get()`s it, and
     // `get bashPath()` below reads it as a plain value, so it stays plain.
     //
@@ -107,8 +113,21 @@ export function gitBashShellConfig(z) {
   })
 }
 
+/**
+ * The schemastery copy that matches the executing host (see src/schemastery.js).
+ * Resolving our own way can land on an OLDER copy another dependency hoisted to
+ * the profile root — one without `volatile()` — and the executor then declares
+ * plain limits for a base class that calls `.get()` on them: every shell call
+ * dies with `config.timeoutMs.get is not a function` (issue #12).
+ *
+ * Deliberately ONE line, and the ONLY top-level await in this module: the smoke
+ * harness evaluates this body inside `new Function`, where an await cannot
+ * appear, so it swaps exactly this expression for a stub.
+ */
+const schema = await loadSchemastery({ parentConfig: SandboxBashExecutor.Config })
+
 /** Resolved configuration: the local executor's knobs, plus the Git Bash path. */
-export const Config = gitBashShellConfig(z)
+export const Config = schema.z ? gitBashShellConfig(schema.z, schema.needsVolatile) : undefined
 
 /** Git Bash executor — mirrors the shipped bash/pwsh sandbox executors. */
 export class GitBashSandboxExecutor extends SandboxBashExecutor {

package/assets/code-gitbash/agent.cordis.ptc.ps.yml

@@ -1,282 +0,0 @@
-# ERA (persona-split): dsh >= 0.1.3-alpha.2 text — the persona row uses the
-# `prefix:`/`suffix:` keys (40792330c0 split dsh-persona single text key).
-# The pre-split texts live in the sibling files named in the banner below; the
-# plugin probes the roster AND the persona form at materialization and writes
-# the picked text as the preset own agent.cordis.yml.
-# ERA: dsh >= 0.1.2 text (built-in preset id `ptc`, presented with mode: ptc).
-# The dsh <= 0.1.1 era text (built-in id `code`) lives in agent.cordis.yml; the
-# plugin probes the roster at materialization and writes the picked text as the
-# preset's own agent.cordis.yml.
-# The `ptc` agent preset: the standard coding agent, presented as PTC mode.
-#
-# Most of `standard` is here unchanged. The deliberate exception is the
-# general-purpose `workflow` tool: PTC mode uses `run_code` as its model-authored
-# composition surface. The `tool-presentation` row turns the remaining registry
-# into a generated SDK, so a sequence that would be five round trips becomes one.
-#
-# The registry itself stays on the host plane — the agent loop's scheduler and
-# the API proxy's presenters are its consumers — so what this preset owns is
-# the PRESENTATION of that registry for this agent alone. Native sessions run
-# beside this one in the same process, each seeing its own catalog.
-#
-# This file is an AGENT-PLANE composition. It is mounted under one agent's
-# scope context, so every tool and prompt section it registers belongs to that
-# session alone. The host composition (`base.cordis.yml` + `web.cordis.yml`)
-# keeps everything a preset must not own: the registries themselves, the
-# sandbox and approval stack, persistence, and the model route.
-#
-# A service row here MUST sit inside a group carrying an `isolate` realm.
-# Without one it publishes into the root realm, where it is process-global
-# rather than per-session and the second session mounting this preset collides
-# with the first; `dsh-agent-presets` rejects that at mount. `true` means an
-# entry-local realm — one private instance per mounted session, which is the
-# default this deployment wants. A shared label would instead pool one instance
-# across every session naming it.
-
-# ── identity ────────────────────────────────────────────────────────────────
-
-# The preset's own persona, shadowing the deployment default for this agent.
-# `{{model}}` and `{{cwd}}` resolve from the agent's own route and workspace.
-- id: persona
-  name: '@deepseek-ai/dsh-persona'
-  config:
-    suffix: Your working directory is {{cwd}}.
-    prefix: >-
-      You are a coding agent powered by the {{model}} model.
-
-- id: agent-instructions
-  name: '@deepseek-ai/dsh-agent-instructions'
-  config:
-    maxBytes: 65536
-
-# ── shell ───────────────────────────────────────────────────────────────────
-
-# `shell-env` stays in the HOST composition: `apps/cli/src/web.ts` injects it to
-# publish `DSH_WEB_URL`/`DSH_WEB_MODE`, and a host row that injects a service is
-# the criterion for host-plane ownership — injection resolves before any session
-# exists, so there is no agent to key by. Behind a preset realm those variables
-# never reached the model's shell at all. Both shell tools consume the host
-# registry from here; the host executor is the Git Bash provider (`dsh-gitbash-shell`)
-# host-plane too.
-- id: tool-bash
-  name: '@deepseek-ai/dsh-tool-bash'
-  # Git Bash on Windows: the host executor is dsh-gitbash-shell (see $DSH_HOME/cordis.patch.yml).
-  disabled: false
-
-- id: tool-pwsh
-  name: '@deepseek-ai/dsh-tool-pwsh'
-  disabled: true
-
-# ── filesystem ──────────────────────────────────────────────────────────────
-
-# Both register into the host `tools` registry and provide nothing, so
-# they need no realm. The `fs` service and its policy stay in the host.
-- id: tool-fs
-  name: '@deepseek-ai/dsh-tool-fs'
-
-- id: tool-fs-search
-  name: '@deepseek-ai/dsh-tool-fs-search'
-  config:
-    sampleOverCapGlobResults: false
-
-# ── background jobs ────────────────────────────────────────────────────────
-
-# Only the model-facing controls. The task REGISTRY stays on the host plane:
-# its producers sit outside any realm this file could put it in — `tool-bash`
-# above resolves it with `ctx.get`, and an entry-local realm here is invisible
-# to every sibling row, so `run_in_background` would answer "background jobs
-# unavailable" while these controls sat in the catalog. The registry is keyed by
-# owning agent anyway, so one host instance serves every session. What a preset
-# chooses is whether its agent can collect and stop background work at all.
-- id: tool-jobs
-  name: '@deepseek-ai/dsh-tool-jobs'
-
-# ── skills ──────────────────────────────────────────────────────────────────
-
-# The skill REGISTRY lives in the host composition and is layered per scope:
-# these rows register into THIS preset's layer of it, so they need no realm.
-# `skill-filesystem` contributes local-root discovery for agents on this preset, and
-# `tool-skill` gives them the catalog and loader; the merged catalog also
-# carries whatever the deployment registered globally (repository plugins).
-- id: skill-filesystem
-  name: '@deepseek-ai/dsh-skill-filesystem'
-
-- id: tool-skill
-  name: '@deepseek-ai/dsh-tool-skill'
-
-# ── goals ───────────────────────────────────────────────────────────────────
-
-# The goal service and session driver stay on the host plane, where the Gateway
-# can resolve them. The human command and model-facing tool register into this
-# preset's scoped layers.
-- id: command-goal
-  name: '@deepseek-ai/dsh-command-goal'
-
-- id: tool-goal
-  name: '@deepseek-ai/dsh-tool-goal'
-
-# ── plan mode ───────────────────────────────────────────────────────────────
-
-# Plan state is per-agent by nature, so an entry-local realm is not a
-# workaround here — it is the correct lifetime.
-- id: planning
-  name: cordis:group
-  group: true
-  isolate:
-    planMode: true
-  config:
-    - id: plan-mode
-      name: '@deepseek-ai/dsh-plan-mode'
-      config:
-        section: |
-              You are in plan mode. Stay in plan mode until exit_plan_mode succeeds or the user switches the session mode. Imperative language to implement changes means plan the implementation, not execute it. A user's conversational agreement — including an answer confirming something you asked — approves nothing and does not end plan mode; fold the confirmed decision into the plan and submit it through exit_plan_mode.
-
-              Explore first. Use non-mutating reads, searches, static analysis, and checks to ground the plan in the actual repository. Do not edit or write files, change configuration, run formatters or code generation that rewrites tracked files, commit, or otherwise carry out the plan. Prefer existing functions and patterns over new machinery.
-
-              The tool catalog stays the same across modes for request-cache stability. These plan-mode rules override any later tool description or guidance that suggests using mutation tools; those tools remain listed to keep the tool catalog unchanged. Do not use todo_write to track this planning phase: it tracks implementation after an approved plan, while the plan itself belongs in exit_plan_mode.
-
-              Resolve discoverable facts by inspection. Use ask_user_question only for user-owned choices or material ambiguity that inspection cannot answer. Do not ask the user where code lives or how current behavior works when you can find out.
-
-              Make the plan decision-complete: state the goal and success criteria; group implementation changes by subsystem; identify public API, schema, and data-flow changes; cover edge cases, failure modes, tests, acceptance criteria, and explicit assumptions. Keep it concise enough to review but detailed enough that another engineer can implement it without making design decisions.
-
-              When ready, call exit_plan_mode with the complete plan markdown, starting with a # title. Make exit_plan_mode the only and final tool call in that assistant response: it presents the plan for approval, and implementation begins only in a later step after approval. Do not paste the final plan as a plain reply or ask "should I proceed?" through prose or ask_user_question. If review rejects it, incorporate the feedback and present again. If the review channel is unavailable or aborted, stay in plan mode and ask the user to switch modes manually; do not proceed with implementation.
-
-# ── compaction ──────────────────────────────────────────────────────────────
-
-# `compaction-basic` reads `toolResultPrune` through `ctx.get`, so the pruner must
-# share this realm rather than sit outside it.
-#
-# `tokenMeter` is deliberately NOT in this realm: the meter stays on the HOST
-# plane, and the rows here resolve that one instance. It takes no configuration,
-# keys every fold by Session, and owns the context-meter projection units the
-# browser reads for every session — behind a realm those units would come and go
-# with whichever presets happen to be mounted. What a preset chooses is whether
-# its agent compacts at all, which is `compaction-basic` below.
-- id: compaction
-  name: cordis:group
-  group: true
-  isolate:
-    compaction: true
-    toolResultPruner: true
-  config:
-    - id: compaction-basic
-      name: '@deepseek-ai/dsh-compaction-basic'
-
-    - id: command-compact
-      name: '@deepseek-ai/dsh-command-compact'
-
-    - id: tool-result-pruner
-      name: '@deepseek-ai/dsh-compaction-tool-result-pruner'
-      config:
-        thresholdChars: 8192
-        headChars: 4096
-        tailChars: 1024
-
-# ── delegation and workflows ────────────────────────────────────────────────
-
-# The `subagents` registry and its spawn/fork backends live in the HOST
-# composition: the registry is a process singleton whose cross-session queries
-# the api-proxy serves to the browser, and a provider name may only be
-# registered once. This preset contributes the delegation TOOLS, which resolve
-# that host registry.
-#
-# `workflows` is different — nothing outside an agent reads it — so every row
-# that reaches it shares one entry-local realm here, and a consumer left
-# outside would resolve a host registry this preset does not populate.
-- id: delegation
-  name: cordis:group
-  group: true
-  isolate:
-    workflowEngine: true
-  config:
-    - id: tool-subagent-control
-      name: '@deepseek-ai/dsh-tool-subagent-control'
-
-    - id: tool-subagent-list-agents
-      name: '@deepseek-ai/dsh-tool-subagent-control/list-agents'
-
-    - id: tool-subagent
-      name: '@deepseek-ai/dsh-tool-subagent'
-      config:
-        provider: spawn
-        toolName: subagent
-        modelSelectionSettings: true
-        backgroundMode: continuable
-
-    # Fork omits model selection so provider/model stay equal to the parent and
-    # the inherited history remains eligible for KV Cache reuse. This preset
-    # keeps fork continuable; parent and child inherit the same messaging tool,
-    # while the parent id and return guidance follow the inherited history.
-    - id: tool-subagent-fork
-      name: '@deepseek-ai/dsh-tool-subagent'
-      config:
-        provider: fork
-        toolName: subagent_fork
-        backgroundMode: continuable
-
-    # Production dsh does not install these optional providers. Install the
-    # matching Bundle in this Profile and restart the Host, then copy this
-    # preset and remove `disabled` from the matching tool row. Host availability
-    # alone grants no tool.
-    - id: tool-subagent-codex
-      name: '@deepseek-ai/dsh-tool-subagent'
-      disabled: true
-      config:
-        provider: codex
-        toolName: subagent_codex
-        backgroundMode: one-shot
-        maxDepth: provider-managed
-
-    - id: tool-subagent-claude-code
-      name: '@deepseek-ai/dsh-tool-subagent'
-      disabled: true
-      config:
-        provider: claude-code
-        toolName: subagent_claude_code
-        backgroundMode: one-shot
-        maxDepth: provider-managed
-
-    - id: workflow-worker-thread
-      name: '@deepseek-ai/dsh-workflow-worker-thread'
-      config:
-        provider: spawn
-
-    - id: tool-workflow
-      name: '@deepseek-ai/dsh-tool-workflow'
-      # Keep the engine above for `ralph`, but do not publish a second
-      # model-authored orchestration surface beside `run_code` in PTC mode.
-      disabled: true
-
-    - id: tool-ralph
-      name: '@deepseek-ai/dsh-tool-ralph'
-      config:
-        subagentProvider: spawn
-        maxRounds: 64
-
-# ── remaining model-facing rows ─────────────────────────────────────────────
-
-- id: tool-ask-user
-  name: '@deepseek-ai/dsh-tool-ask-user'
-
-- id: tool-todo
-  name: '@deepseek-ai/dsh-tool-todo'
-  config:
-    allowParallelInProgress: true
-
-# The `web` service and its search provider stay in the host composition; only
-# the model-facing tool is per-session.
-- id: tool-web
-  name: '@deepseek-ai/dsh-tool-web'
-  config:
-    fetch: true
-    searchTimeoutMs: 60000
-
-# ── presentation ────────────────────────────────────────────────────────────
-
-# PTC mode for this agent alone. The row waits for the host's `codeRuntime`
-# rather than assuming it: a deployment that composes no TypeScript runtime
-# fails this preset at mount, naming this id, instead of at the first request.
-- id: tool-presentation
-  name: '@deepseek-ai/dsh-agent-tool-presentation'
-  config:
-    mode: ptc