@devflow-core/dsh-devflow 0.1.0

package/assets/presets/devflow-2/agent.cordis.yml

@@ -0,0 +1,337 @@
+# ============================================================
+# devflow-2.0 anchored bootstrap (adapted from dsh-liangshen, MIT; source
+# xiaobright/dsh-anchored-standard)
+#
+# TWO-PHASE PERSONA: the FIRST model request sees only the one-line Minimal
+# persona ("You are a helpful software engineer assistant."), the minimal tool
+# pair (persistent `bash` + `str_replace_editor`), NO runtime contexts and NO
+# auto-injected pre-step messages. After the anchor gate passes (first
+# minimal-like reasoning block, 4-step fallback, or first-response release) the
+# session promotes: the wire switches to Code Mode (PTC — a single `run_code`
+# tool), the FULL DevFlow persona below is restored (with {{model}}/{{cwd}}),
+# and workspace instructions (AGENTS.md digest) + the skill catalog are
+# deferred one step, then stay current.
+#
+# This row MUST stay the FIRST row: the pre-step strip relies on waterfall
+# reverse-registration order so request #1 stays minimal-exact.
+# ============================================================
+- id: tool-bootstrap
+  name: ./tool-bootstrap.mjs
+  config:
+    shellTools: [bash]
+    commonTools: [str_replace_editor]
+    messageSources: [user]
+    anchorGate: true
+    maxBootstrapSteps: 4
+    promoteAfterFirstResponse: true
+    bootstrapMaxTokens: 1024
+    # Core work set after a compaction, before re-promotion.
+    compactionTools: [read, write, edit, glob, grep, todo_write, ask_user_question]
+    deferredSources: [agent-instructions, skill-catalog]
+    deferredGraceSteps: 1
+    promotedPresentation: code
+    phase1Persona: You are a helpful software engineer assistant.
+
+# The `devflow` agent preset: the full coding agent plus DevFlow workflow
+# activation, derived from the shipped `standard` preset (kept row-for-row).
+#
+# This file is an AGENT-PLANE composition. The roster mounts it ONCE under a
+# standing scope; every session naming it joins by scope parentage, so the
+# tools and prompt sections registered here cover each joined agent while a
+# session's own state stays keyed per Session/Agent inside the plugins. 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 —
+# another preset publishing the same name collides, and a host reader would
+# resolve one preset's instance for every session; `dsh-agent-presets` rejects
+# that at mount. `true` means an entry-local realm: this standing mount's own
+# private instance, apart from every other preset's. (A shared label does NOT
+# pool instances — `provide()` throws on the second registration under the
+# same realm symbol; labels join REALMS, and are not what this file needs.)
+
+# ── identity ────────────────────────────────────────────────────────────────
+
+# The preset's own persona, shadowing the deployment default for this agent.
+# `tool-bootstrap` swaps it out during phase 1 (one-line Minimal anchor) and
+# restores THIS text after promotion. The DevFlow paragraph guarantees
+# activation even when the model would otherwise skip reading AGENTS.md; the
+# route table and hard boundaries stay in the devflow-core skill and AGENTS.md
+# (single source, no duplication).
+- id: persona
+  name: '@deepseek-ai/dsh-persona'
+  config:
+    text: |-
+      You are a coding agent powered by the {{model}} model. Your working directory is {{cwd}}.
+
+      You run DevFlow. Before any development work — creating features, building components, adding functionality, modifying behavior, or defining an unapproved problem-directed change — load the `devflow-core` skill with the skill tool and read its `core-methods.md` reference, then load only the selected lifecycle owner skill. The route table and hard boundaries live in that skill and in AGENTS.md; do not invent lifecycle details. Pure Q&A, lookup, verification, and investigation-only reports need no lifecycle.
+
+- id: agent-instructions
+  name: '@deepseek-ai/dsh-agent-instructions'
+  config:
+    maxBytes: 65536
+
+# ── minimal phase-1 shell ───────────────────────────────────────────────────
+
+# The PTY registry is an agent-owned service, so it lives in an entry-local
+# realm. The backend still consumes the host sandbox policy and subprocess
+# implementation, while the tool registers into this agent's scoped catalog.
+# This persistent `bash` replaces the Standard ephemeral shell for the WHOLE
+# session (both tools register the name `bash`), which is the exact-Minimal
+# tradeoff this experimental preset evaluates.
+- id: persistent-shell
+  name: cordis:group
+  group: true
+  isolate:
+    terminals: true
+  disabled: !!js process.platform === 'win32'
+  config:
+    - id: pty
+      name: '@deepseek-ai/dsh-terminal'
+
+    - id: terminal-bash
+      name: '@deepseek-ai/dsh-terminal-bash'
+      config:
+        timeoutMs: 300000
+
+    - id: persistent-bash
+      name: '@deepseek-ai/dsh-tool-bash-persistent'
+      config:
+        timeoutMs: 300000
+        description: |-
+          Run commands in a bash shell
+          * When invoking this tool, the contents of the "command" parameter does NOT need to be XML-escaped.
+          * You don't have access to the internet via this tool.
+          * You do have access to a mirror of common linux and python packages via apt and pip.
+          * State is persistent across command calls and discussions with the user.
+          * To inspect a particular line range of a file, e.g. lines 10-25, try 'sed -n 10,25p /path/to/the/file'.
+          * Please avoid commands that may produce a very large amount of output.
+          * Please run long lived commands in the background, e.g. 'sleep 10 &' or start a server in the background.
+
+# Windows-only `bash` tool (custom-bash.mjs): the PTY backend above is
+# linux/darwin-only, so win32 disables the persistent-shell group and
+# registers this `bash` through the ordinary cross-platform subprocess seam
+# (Git Bash). Both platforms end up with exactly one tool named `bash`, so the
+# phase-1 Minimal anchor (shellTools: [bash] + str_replace_editor) is
+# unchanged. Non-zero exit is reported not thrown; state does NOT persist
+# across calls on this path; no OS sandbox confinement on Windows. `bashPath`
+# is optional (defaults to Git Bash inference); set it explicitly only when
+# git is not on PATH.
+- id: custom-bash
+  name: ./custom-bash.mjs
+  disabled: !!js process.platform !== 'win32'
+
+# ── minimal phase-1 filesystem ──────────────────────────────────────────────
+
+# Phase-1 editor as a direct top-level row: it reuses the host's sandboxed
+# `ctx.fs`, not a bare local filesystem. No `dsh-fs-local` realm is mounted, so
+# the phase-1 editor inherits the host file sandbox exactly like every
+# Standard file tool, and the model-facing schema stays the builtin Minimal
+# `str_replace_editor`.
+- id: str-replace-editor
+  name: '@deepseek-ai/dsh-tool-str-replace-editor'
+  config:
+    maxOutputChars: 16000
+
+# ── standard filesystem tools ───────────────────────────────────────────────
+
+# 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, and the
+# registry is keyed by owning agent anyway. With the persistent shell, long
+# commands run through `&`; these controls still expose whatever the host
+# registry tracks.
+- 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).
+# The `skill-catalog` pre-step message is quarantined by `tool-bootstrap`
+# during phase 1 and deferred one step after promotion, then stays current.
+- id: skill-filesystem
+  name: '@deepseek-ai/dsh-skill-filesystem'
+
+- id: tool-skill
+  name: '@deepseek-ai/dsh-tool-skill'
+
+# ── goals ───────────────────────────────────────────────────────────────────
+
+# Only the model-facing tool. The goal SERVICE, its session driver, and the
+# `/goal` command stay on the host plane: the Gateway serves the goal domain as
+# Remote endpoints whose receiver comes from a generated descriptor, so it
+# resolves `goals` on the host and an entry-local realm here would hide it. The
+# registry is keyed by session anyway, so one host instance serves every
+# session. What a preset chooses is whether its agent can call the goal tool.
+- 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.
+#
+# `tool-subagent-report` is host-plane for the same reason as the registry,
+# not because a preset may not want it: it registers a CONTINUABLE SETUP on
+# that singleton rather than a tool this agent calls, and the setup list is
+# not scope-aware — one copy per mounted preset means every child gets
+# `report` registered once per live session, which throws on the second.
+- 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
+        backgroundMode: continuable
+
+    - id: tool-subagent-fork
+      name: '@deepseek-ai/dsh-tool-subagent'
+      config:
+        provider: fork
+        toolName: subagent_fork
+        backgroundMode: continuable
+
+    # Product providers are host-plane singletons. Copy this preset, then
+    # remove `disabled` from either ordinary tool row to expose that product
+    # only to agents composed from the copy.
+    - id: tool-subagent-codex
+      name: '@deepseek-ai/dsh-tool-subagent'
+      disabled: true
+      config:
+        provider: codex
+        toolName: subagent_codex
+        enableRunInBackground: false
+        maxDepth: provider-managed
+
+    - id: tool-subagent-claude-code
+      name: '@deepseek-ai/dsh-tool-subagent'
+      disabled: true
+      config:
+        provider: claude-code
+        toolName: subagent_claude_code
+        enableRunInBackground: false
+        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'
+
+    - 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: false
+    searchTimeoutMs: 60000

package/assets/presets/devflow-2/custom-bash.mjs

@@ -0,0 +1,213 @@
+/**
+ * custom-bash — a Windows-capable `bash` tool for the liangshen preset. It
+ * registers under the SAME name (`bash`) as the persistent shell so the
+ * phase-1 Minimal anchor (bash + str_replace_editor) holds on every platform,
+ * but executes through `ctx.subprocess.spawn` instead of a PTY.
+ *
+ * WHY: DSH's PTY backend is linux/darwin-only — subprocess-local throws
+ * "terminal inspection is unsupported on platform win32", so the
+ * persistent-shell group (dsh-terminal + dsh-terminal-bash +
+ * dsh-tool-bash-persistent) cannot spawn on Windows. agent.cordis.yml disables
+ * that group on win32 and enables this tool instead; both platforms end up
+ * with exactly one `bash` tool and the byte-exact schema anchor is kept.
+ *
+ * Executable resolution (config `bashPath`, no hardcoded install path):
+ * an explicit non-empty `bashPath` wins unconditionally. Unset, the Git Bash
+ * executable is INFERRED in probe order:
+ *  1. the `git` executable on PATH — its install root carries `bin\bash.exe`
+ *     one level up from `cmd\`, beside `bin\`, or two levels up from
+ *     `mingw64\bin\` (the standard installer, choco, and winget all resolve
+ *     here);
+ *  2. the well-known Git-for-Windows roots derived from environment variables
+ *     (ProgramFiles, ProgramFiles(x86), LOCALAPPDATA\Programs\Git, scoop's
+ *     ~\scoop\apps\git\current junction);
+ *  3. plain `bash` through `ctx.subprocess.resolveExecutable` (PATH lookup —
+ *     last resort; on Windows that may pick the WSL shim, which is still true
+ *     bash even though paths shift to /mnt/…).
+ *
+ * If NOTHING resolves the tool fails with an actionable error — it never
+ * silently executes under pwsh/cmd, which are different command languages.
+ *
+ * Semantics mirror the official bash tool: `bash -c <command>` in a fresh
+ * process, bounded output, non-zero exit reported not thrown. No sandbox
+ * confinement on Windows (the sandbox backend is linux-only); the description
+ * says so.
+ *
+ * Ported from xiaobright/dsh-anchored-standard (MIT) — see NOTICE.
+ */
+
+import { access } from 'node:fs/promises'
+import { dirname, join } from 'node:path'
+
+/** Cordis plugin name used by loader diagnostics. */
+export const name = 'custom-bash'
+
+/** The subprocess and tools services must exist before this tool can register. */
+export const inject = ['subprocess', 'tools']
+
+const DEFAULT_TIMEOUT_MS = 120000
+const DEFAULT_MAX_OUTPUT_BYTES = 64000
+
+/**
+ * Git Bash candidate paths, in probe order (see the header): the `git`
+ * executable's install root first, then the well-known env-derived roots.
+ * Exported for tests; pure — existence probing happens at the call site.
+ */
+export function bashCandidates(env, gitExe) {
+  const candidates = []
+  // git at <root>\cmd\git.exe (installer/scoop) or <root>\bin\git.exe →
+  // <root>\bin\bash.exe; <root>\mingw64\bin\git.exe (portable) → two up.
+  // A bare relative name means `git` did not actually resolve to a path.
+  if (typeof gitExe === 'string' && /[/\\]/.test(gitExe)) {
+    const dir = dirname(gitExe)
+    const root = dirname(dir)
+    candidates.push(
+      join(root, 'bin', 'bash.exe'),
+      join(dir, 'bash.exe'),
+      join(dirname(root), 'bin', 'bash.exe'),
+    )
+  }
+  if (env.ProgramFiles) candidates.push(join(env.ProgramFiles, 'Git', 'bin', 'bash.exe'))
+  if (env['ProgramFiles(x86)']) candidates.push(join(env['ProgramFiles(x86)'], 'Git', 'bin', 'bash.exe'))
+  if (env.LOCALAPPDATA) candidates.push(join(env.LOCALAPPDATA, 'Programs', 'Git', 'bin', 'bash.exe'))
+  if (env.USERPROFILE) candidates.push(join(env.USERPROFILE, 'scoop', 'apps', 'git', 'current', 'bin', 'bash.exe'))
+  // Layouts overlap (a `bin` git.exe derives the same bash twice) — probe
+  // order survives the dedupe, insertion order is preserved.
+  return [...new Set(candidates)]
+}
+
+/** Tool parameter schema for the model-facing command. */
+const commandSchema = {
+  type: 'object',
+  properties: {
+    command: {
+      type: 'string',
+      description: 'The bash command to execute (`bash -c` string domain).',
+    },
+    workdir: {
+      type: 'string',
+      description: 'Optional working directory; defaults to the session cwd.',
+    },
+  },
+  required: ['command'],
+  additionalProperties: false,
+}
+
+/** Register the model-facing `bash` tool. */
+export function apply(ctx, config) {
+  const explicitBashPath = typeof config?.bashPath === 'string' && config.bashPath.length > 0 ? config.bashPath : undefined
+  const timeoutMs = Number.isSafeInteger(config?.timeoutMs) && config.timeoutMs > 0 ? config.timeoutMs : DEFAULT_TIMEOUT_MS
+  const maxOutputBytes = Number.isSafeInteger(config?.maxOutputBytes) && config.maxOutputBytes > 0 ? config.maxOutputBytes : DEFAULT_MAX_OUTPUT_BYTES
+
+  // The inferred executable is memoized per plugin instance: candidate probing
+  // walks the filesystem, and the answer cannot change within a mount. A
+  // failed inference is NOT memoized — the plain `bash` fallback resolves
+  // fresh on every execute until some probe succeeds.
+  let inferredShell
+  const exists = (path) => access(path).then(() => true, () => false)
+  const resolveShell = async (signal) => {
+    if (explicitBashPath !== undefined) {
+      // A misconfigured explicit path must fail as itself, not as a
+      // discovery miss — the raw resolution error says which path failed.
+      return ctx.subprocess.resolveExecutable(explicitBashPath, undefined, signal)
+    }
+    if (inferredShell !== undefined) {
+      return ctx.subprocess.resolveExecutable(inferredShell, undefined, signal)
+    }
+    let gitExe
+    try {
+      gitExe = await ctx.subprocess.resolveExecutable('git', undefined, signal)
+    } catch {
+      // git unresolvable → the env-derived candidates below still apply
+    }
+    for (const candidate of bashCandidates(process.env, gitExe)) {
+      if (!(await exists(candidate))) continue
+      try {
+        inferredShell = await ctx.subprocess.resolveExecutable(candidate, undefined, signal)
+        return inferredShell
+      } catch {
+        // Exists but unresolvable (EPERM, a broken scoop junction): keep
+        // probing — one bad root must not block the rest of the chain, and
+        // nothing is memoized so later executes can still find a good one.
+        continue
+      }
+    }
+    try {
+      return await ctx.subprocess.resolveExecutable('bash', undefined, signal)
+    } catch (error) {
+      // Total discovery failure (no Git Bash root, no env root, no bash on
+      // PATH): name the remedies instead of leaking a raw ENOENT. Never
+      // fall back to pwsh/cmd here — the schema promises `bash -c`
+      // semantics; a different shell would silently break every command.
+      throw new Error(`bash executable not found — install Git for Windows, expose a bash on PATH, or set the custom-bash \`bashPath\` config (${String((error && error.message) || error)})`)
+    }
+  }
+
+  ctx.tools.register({
+    name: 'bash',
+    description: [
+      'Run commands in a bash shell (Git Bash on Windows)',
+      '* When invoking this tool, the contents of the "command" parameter does NOT need to be XML-escaped.',
+      "* You don't have access to the internet via this tool.",
+      '* You do have access to a mirror of common linux and python packages via apt and pip.',
+      '* State does NOT persist across command calls: each call runs in a fresh shell.',
+      "* To inspect a particular line range of a file, e.g. lines 10-25, try 'sed -n 10,25p /path/to/the/file'.",
+      '* Please avoid commands that may produce a very large amount of output.',
+      '* NOTE: runs without OS sandbox confinement on Windows (no landlock); treat output as untrusted.',
+    ].join('\n'),
+    parameters: commandSchema,
+    output: {
+      schema: {
+        type: 'object',
+        additionalProperties: false,
+        properties: {
+          text: { type: 'string' },
+        },
+        required: ['text'],
+      },
+      render: (_args, value) => [{ type: 'text', text: value.text }],
+    },
+    async execute(args, exec) {
+      const shell = await resolveShell(exec?.signal)
+      const workdir = typeof args.workdir === 'string' && args.workdir.length > 0
+        ? args.workdir
+        : exec?.agent?.session?.header?.cwd
+      const signal = exec?.signal
+      const handle = ctx.subprocess.spawn({
+        argv: [shell, '-c', args.command],
+        ...workdir !== undefined ? { cwd: workdir } : {},
+        stdio: {
+          stdin: 'ignore',
+          stdout: { maxBytes: maxOutputBytes },
+          stderr: { maxBytes: maxOutputBytes },
+        },
+        ...signal !== undefined ? { signal } : {},
+        graceMs: 3000,
+      })
+      let outcome
+      try {
+        outcome = await handle.done
+      } catch (error) {
+        // A spawn-level failure (bad executable, EPERM) surfaces as a throw,
+        // which the runtime turns into an isError result.
+        throw new Error(`bash spawn failed: ${String(error)}`)
+      }
+      let stdout = ''
+      let stderr = ''
+      try {
+        stdout = handle.collected.stdout.readFrom(0).text
+        stderr = handle.collected.stderr.readFrom(0).text
+      } catch {
+        // Collected readers may be unavailable on some backends; tolerate.
+      }
+      const text = [stdout, stderr].filter((part) => part.length > 0).join('\n')
+      const tail = text.length > 0 ? text : `exit code: ${outcome.exitCode} (no output)`
+      if (outcome.exitCode !== 0) {
+        // Non-zero exit is a reported failure, not a throw: the model sees the
+        // command output plus the exit code.
+        throw new Error(tail)
+      }
+      return { text: tail }
+    },
+  })
+}

package/assets/presets/devflow-2/preset.yml

@@ -0,0 +1,3 @@
+name: DevFlow 2.0 (Anchored)
+description: DevFlow 开发工作流 + 梁神式两阶段锚定：首个请求只暴露一行 persona（You are a helpful software engineer assistant.）+ 最小工具对（持久 bash + str_replace_editor），无运行时上下文与任何注入；anchorGate 门控（首个 minimal-like 推理块或 4 步兜底）+ 1024 输出预算稳定锚定后，晋升为 Code Mode（单一 run_code），恢复完整 DevFlow 人设并自动激活 devflow-core 生命周期（Brainstorm → Spec/Cut → Plan → Build → Prove）与验证完成闭环；workspace 指令与技能目录延迟一步注入。
+order: 6