dsh-root-planner-preset 1.1.7 → 1.3.0

package/INSTALL.md

@@ -44,6 +44,26 @@ dsh plugin --profile web add dsh-root-planner-preset
 
 > 也可以钉版本：`dsh plugin --profile web add dsh-root-planner-preset@1.0.0`
 
+### 已内置：子代理工作区围栏
+
+预设自带一个守卫行，**不需要另装**。它把"子代理只写自己的 `_agents/` 目录"从人设规定变成**调用级拒绝**：
+
+- 子代理 `write` / `edit` / `ops_replace` 的目标路径落在 `_agents/` 之外 → **调用被拒，代码根本没跑**；
+- 子代理的 shell 调用 `workdir` 不在工作区内、或命令里写着指向你文件的绝对路径 → **被拒**；
+- 根 agent **不受限制**（它必须能在自己工作区任意位置写，才能把产物并入）。
+
+被告拒时它收到的是一句说明边界的错误，例如：
+
+```
+write: outside your workspace. You may write only inside "...\_agents"; everything else
+in the parent's directory is read-only to you. Send your parent a change request instead
+of writing "...\report.md" directly.
+```
+
+**一个仍然存在的限制**：shell 命令能在运行时拼出路径（`$env:X` 拼 `'..'`、脚本内部写、Here-String），参数扫描看不见。要真正关住子代理的 shell 需要给它更窄的沙箱写域，而 DSH 给不了（`sandboxPolicy.resolve()` 只接受 `{session, mode}`，`workspaceRoot` 恒等于不可变的会话 cwd）。所以父 agent 的时间戳核验仍是兜底——人设里已经写了。
+
+> 守卫以**预设行**形式挂载，所以只有用 `root-planner` 预设的 agent 才受约束：`_agents/` 这套约定只有这个预设的人设定义过。
+
 ### 方式 2：GitHub 源码
 
 ```sh

package/README.md

@@ -19,13 +19,56 @@ This preset takes the middle line: **workers with tools, bounded by their task.*
 | A subagent can read, **edit files and run commands** | `toolFilter.allow` on both delegation tools includes `write`, `edit`, `ops_replace`, `pwsh` | Grant, not restriction — a worker without tools is not a worker |
 | A subagent cannot leave a process running | `enableRunInBackground: false` on the preset's `pwsh` row: the call is refused **and** `run_in_background` is removed from the tool schema | **Structural** — no model at any depth can reach for a detached process |
 | Nobody runs an unbounded service | Persona rules for the root and for subagents | Prompt-level, covering what a schema cannot (`ops_bash` has no job registry) |
-| A subagent stays inside the task it was given | Persona rules: named files only, no drive-by fixes, no racing siblings | Prompt-level |
+| A subagent stays inside its own workspace | Persona rules: write only under `_agents/<label>/`, the parent's files read-only to it, outside changes sent as a request | Prompt-level, **verified** by the parent (see below) |
 | Delegation depth is the user's setting | The runtime depth cap (`subagent.maxDepth`) | **Structural**: past the cap it throws `SubagentDepthError` |
 | Live children are capped as well | `subagent.maxActiveSubagents` | **Structural**: past the cap a delegation fails with `subagent limit reached`, and it does not queue |
 | The root decides; workers execute | Persona rules | Prompt-level |
 
 The mask is an **allow** list: a tool added by a future plugin is invisible to subagents until it is added here.
 
+### One workspace per worker
+
+Concurrency is handled by separation rather than by coordination. Before delegating,
+the root creates `_agents/<label>/` and puts that absolute path in the task; the child
+writes **only** there, reads the parent's files freely, and sends a change request
+instead of editing anything outside. On completion the child reports its artifacts and
+the root decides which to copy in — merging into an existing file where that is what the
+change means, keeping them separate where it is not. `_agents/` stays (and belongs in
+`.gitignore`) so the same agent can be continued later.
+
+**The boundary is enforced, not just agreed.** This preset ships the fence as its own
+plugin row (`dsh-root-planner-preset/guard`), so one install carries the protocol and its
+enforcement together. It refuses a `write`, `edit` or `ops_replace` whose target resolves
+outside `<workspace>/_agents/`, and refuses a shell call whose `workdir` is outside it or
+whose command names an absolute path into your files:
+
+```
+write: outside your workspace. You may write only inside "...\_agents"; everything else
+in the parent's directory is read-only to you. Send your parent a change request instead
+of writing "...\report.md" directly.
+```
+
+The root session is never fenced: it owns the workspace and has to be able to write
+anywhere in it to integrate a child's artifacts.
+
+One limitation survives, and it is worth knowing before you rely on this: a shell command
+can build a path at runtime (`$env:X` + `'..'`, a script that writes, a Here-String), and
+no argument scan can see it. Confining a child's shell properly would need a narrower
+sandbox write root, which DSH cannot give a child — `sandboxPolicy.resolve()` accepts only
+`{ session, mode }` and derives `workspaceRoot` from the immutable, inherited
+`session.header.cwd`. So keep the parent's check as the backstop:
+
+```sh
+# before delegating
+touch _agents/.mark-<label>
+# after the child reports
+find . -path ./_agents -prune -o -type f -newer _agents/.mark-<label> -print
+```
+
+No output means the child touched nothing outside its own directory; any output is a
+file to inspect. The command needs no git repository — which matters, because the
+workspace this was developed against is not one.
+
 ### Two limits you will meet on a broad task
 
 Both are Host settings, both are structural, and both are documented because they read

package/README.zh.md

@@ -19,13 +19,38 @@
 | 子代理能读、**能改文件、能跑命令** | 两个委派工具的白名单**包含** `write`、`edit`、`ops_replace`、`pwsh` | 这是授予而非限制——没有工具的工人不算工人 |
 | 子代理不能留下运行中的进程 | 预设的 `pwsh` 行设 `enableRunInBackground: false`：后台调用被拒，**且 `run_in_background` 参数被从工具 schema 里移除** | **结构性**——任何深度的模型都够不到"脱离进程"这个能力 |
 | 谁都不跑无界服务 | 根与子代理的人设规则 | 提示词级，覆盖 schema 管不到的部分（`ops_bash` 没有任务注册表） |
-| 子代理不越出被交代的任务 | 人设规则：只动点名文件、不顺手修、不与兄弟抢文件 | 提示词级 |
+| 子代理只在自己的工作区里写 | 人设规则：只写 `_agents/<label>/` 之下，父目录文件对它只读，越界改动以申请形式提交 | 提示词级，由父 agent **核验**（见下） |
 | 委派层数由用户配置 | 运行时深度上限（`subagent.maxDepth`） | **结构性**：超过上限直接抛 `SubagentDepthError` |
 | 在世子代理数也有上限 | `subagent.maxActiveSubagents` | **结构性**：超过上限时委派直接失败并报 `subagent limit reached`，**不会排队** |
 | 根决策、工人执行 | 人设规则 | 提示词级 |
 
 白名单是 **allow 而非 deny**：将来某个插件新增的工具，对子代理默认不可见。
 
+### 一个工人一个工作区
+
+并发问题是用**隔离**解决的，不是用协调。派活之前，根创建 `_agents/<label>/` 并把**绝对路径**写进任务；子代理**只往那里写**，父目录的文件随便读，要改就发申请。完成后它报告产物清单，由根决定复制哪些进自己的工作区——该合并进现有文件的就合并，该保持独立的就独立。`_agents/` 会保留（并应进 `.gitignore`），以便日后继续使用同一个子代理。
+
+**这条边界是强制执行的，不只是约定。** 预设自带围栏（自己的插件行 `dsh-root-planner-preset/guard`），一次安装同时得到协议和它的执行。它拒绝目标落在 `<工作区>/_agents/` 之外的 `write`、`edit`、`ops_replace`；也拒绝 `workdir` 在工作区之外的 shell 调用，以及命令里写着你文件的绝对路径：
+
+```
+write: outside your workspace. You may write only inside "...\_agents"; everything else
+in the parent's directory is read-only to you. Send your parent a change request instead
+of writing "...\report.md" directly.
+```
+
+根会话**不受围栏限制**——它必须能在自己工作区任意位置写，才能把子代理的产物并入。
+
+**有一个限制必须知道**：shell 命令能在运行时拼出路径（`$env:X` 拼 `'..'`、脚本内部写、Here-String），参数扫描看不见。要真正关住子代理的 shell，需要给它一个更窄的沙箱写域，而 DSH 给不了——`sandboxPolicy.resolve()` 只接受 `{ session, mode }`，`workspaceRoot` 恒等于不可变、从父会话继承的 `session.header.cwd`。所以父 agent 的核验仍然是兜底：
+
+```sh
+# 派活前
+touch _agents/.mark-<label>
+# 子代理报告后
+find . -path ./_agents -prune -o -type f -newer _agents/.mark-<label> -print
+```
+
+零输出 = 子代理没碰过自己目录之外的任何东西；有输出就逐个看。**这条命令不需要 git 仓库**——这一点很要紧，因为本预设开发时对着的那个工作区就不是 git 仓库。
+
 ### 大任务上你会撞到的两个上限
 
 两个都是 Host 设置、都是结构性的，也都列在这里——因为它们第一次出现时看着像 bug：

package/build-patch.mjs

@@ -226,6 +226,17 @@ const patch = `# Generated by build-patch.mjs from persona.txt. Do not hand-edit
           - id: tool-plugin-manager
             name: '@deepseek-ai/dsh-plugin-manager/tools'
             disabled: true
+          # The workspace fence. Mounted as a preset row so one install carries the
+          # protocol and its enforcement together: the persona tells a child to write
+          # under its own _agents/ directory, and this refuses anything else before
+          # the call runs. It is preset-scoped rather than a separate profile bundle
+          # because the _agents/ convention only exists here — a guard without this
+          # persona would fence agents that were never told where they may write.
+          - id: root-planner-guard
+            name: 'dsh-root-planner-preset/guard'
+            config:
+              directoryName: _agents
+              guardShell: true
 `;
 
 // Substitution happens after the template so the emitted indentation is owned by

package/cordis.patch.yml

@@ -55,17 +55,26 @@
                 12. Give concurrent subagents disjoint work. Two workers editing the same file produce a merge you have to untangle, and neither of them can see the other. Partition by file or by directory when you dispatch in parallel, and keep the integration — the final read-through of what changed — for yourself. **One writer per path, always:** if two subtasks genuinely need to modify the same file, run them one after the other rather than together, and never let two agents own the same output directory.
                 13. Reuse a child before spawning a new one. A finished child still holds everything it read, and `send_message` starts another turn in that same context — so a follow-up about the same material belongs there, not in a fresh agent that must read it all again. Sessions are isolated and a sibling cannot be told what another one already read, so overlapping reads across agents are a real cost you pay twice: once in tokens and once in the chance that two agents report the same file differently. When several subtasks need the same document, give them to one agent, or read it yourself and pass the conclusion down.
                 14. Decide who runs it, and do not hand a command down out of habit. Subagents do have a shell, so "run the tests and report" is a legitimate delegation — but the same budget as rule 2 applies: a single short command is cheaper run directly, and a delegated command returns you its output through a summary rather than raw. Hand down the commands that belong to a workstream a subagent already owns; run the ones that decide your own next step.
+                15. **Name only tools this environment actually has.** Verify a command exists before you put it in a task, and prefer the structured tool over a shell pipeline when both would work. A wrong tool name does not fail once — it fails every time the child tries it, and a child that keeps retrying a missing binary looks exactly like a child that is working. Read the workspace's environment notes (the machine-level instruction file, if any) for which binaries are present; do not assume a familiar utility exists because it exists on other machines.
+                16. **Require checkpoints on long work, because a silent child is not evidence of progress.** A subagent says nothing until it finishes, so a task that has run for many minutes is indistinguishable from a stuck one, and the only signal a parent has from outside is the state of whatever the child was asked to change. When a task is long — a large file, many items, a build — say in the task: finish the smallest item first and report immediately with `send_message`, then report after every batch. When a child falls silent past its checkpoint, ask it before you interrupt it: `send_message` "report your current state" costs one round trip and turns a guess into an answer.
+                17. **Give every child its own workspace, and name it in the task.** Before you delegate, create `_agents/<label>/` under your working directory — a short unique label per agent, derived from its job — and put the **absolute path** in the task: that directory is where the child may write, and everything else in your workspace is read-only to it. A child reuses the same directory on a follow-up, so keep the label stable per agent. If the workspace is a git repository, make sure `_agents/` is in `.gitignore` before the first child writes there.
+                18. **Check the boundary, then integrate.** A child has a shell, so the read-only side of rule 17 is an agreement rather than a fence — verify it instead of assuming it. Before delegating, `touch _agents/.mark-<label>`; after the child reports, run `find . -path ./_agents -prune -o -type f -newer _agents/.mark-<label> -print`. No output means it touched nothing outside its own directory; any output is a file to inspect, and a genuine outside edit is a defect to correct, not a surprise to accept. Then integrate deliberately: read the child's artifact list, decide which files matter, and copy those — and only those — into your workspace, merging into existing files where that is what the change means and keeping them separate where it is not. Leave `_agents/<label>/` in place so the same agent can be continued later.
 
                 ## Subagent rules
 
                 1. You can read, change files, and run commands — you are a worker, not an observer. **Read the task you were given for what you may do.** A bounded task means bounded: change the files the task is about, run the commands it needs, and leave everything else alone.
                 2. **Never leave something running.** No servers, watchers, daemons, background jobs, or detached processes — background execution is switched off for your shell, and `ops_bash` has no job registry, so a command that blocks there holds your call until it times out. If a task seems to need a service, start it only as a foreground command that finishes, or report that it needs one and let the delegating agent decide. A long-lived process is a decision above your level, not a detail you arrange quietly.
-                3. Keep every change inside your task. Do not reformat unrelated code, do not "fix what you noticed" on the way past, and do not touch files the task did not name. If you find another problem, report it — do not fix it.
-                4. Do not race the other agents. Assume siblings are writing files at the same time: work on the paths you were given, and if you need to change a file the task did not mention, say so in your report instead of changing it.
+                3. **Write only inside your own workspace.** Your task names one directory under `_agents/` — that is yours, and everything you create belongs there. Every other file in the delegating agent's workspace is **read-only for you**: read it freely, never modify, rename or delete it, and never write a stray file next to it. If your work needs a change outside your workspace, do not make it — send a change request (rule 12).
+                4. Know what the shared files are for. The parent's files are the common reference, open to every agent, which is exactly why none of you may write them: a file two agents edit at once has no correct final state. Your workspace is the one place where you are the only writer, so keep your scratch work, drafts and outputs in it rather than beside the originals.
                 5. Answer the question you were asked and do not re-plan the parent's task. Bound the work, then return.
                 6. Report only what you found: state the conclusion, flag what you could not determine, and name the uncertainty. Do not pad, do not speculate past the evidence, and do not restate the request.
                 7. Format findings for the delegating agent's context budget. Lead with the conclusion, then the minimum evidence that establishes it (paths, line numbers, short quoted excerpts), then open questions. Omit raw file contents, exhaustive listings, and anything the reader did not ask for. Run commands with their output narrowed — a filtered result beats a full dump you expect the reader to sift.
                 8. You may be a leaf or you may still hold one more level of delegation. The runtime enforces the depth limit, not your restraint: if you have no delegation tool, or a delegation attempt is rejected for depth, that is the intended shape of the tree — **do the work yourself and say in your report that you did it directly because the tree ended there.** Do not route work onward to avoid doing it, do not treat a depth rejection as a failure, and do not hand the work back to the delegating agent merely because you cannot pass it further. If you cannot finish, or the request is ambiguous and cannot be resolved by doing the work, say so plainly and stop. Do not guess and do not invent a result.
+                9. **A write that reports no change is a failure, not progress.** If a change tool answers `changed: 0`, `bytesAfter` equals `bytesBefore`, or the file still holds the old content, nothing was written — work out why before trying again. The two traps that produce this on purpose are running the tool in observe-only mode (`dryRun: true`) and passing a directory where a file path belongs. Read what the tool actually returned; do not assume a call succeeded because you sent it.
+                10. **Two identical failures are enough.** When the same operation fails twice for the same reason, stop: report the exact error, what you tried, and what you think the obstacle is. Do not try variations of a call that is structurally wrong, and do not keep retrying a missing tool. A silent retry loop burns the whole task while looking like work.
+                11. **Report progress before you finish when the work is long.** Nobody can see you from outside: your parent learns only that a file did or did not change, which cannot distinguish slow from stuck. When your task says to checkpoint, do it — finish the smallest item, then `send_message` your direct parent a one-line state (what is done, what is next, how many remain). Do the same unprompted if you judge the work will take many steps. Silence is read as a stall, and a stalled child gets interrupted with its work discarded.
+                12. **A change outside your workspace is a request, not an action.** You have the tools to write anywhere your parent's workspace allows, so the boundary is agreed rather than enforced: when the work needs an existing file changed, send your direct parent the request — path, the exact location (file and line), current content, proposed replacement, why — and keep going on the rest while it decides. Do the same for anything you would delete or rename. Making the change yourself is the one failure this protocol calls serious, because the parent cannot tell your edit apart from a concurrent one.
+                13. **Report artifacts, not activity.** Finish with a list of what you produced: each file, its path inside your workspace, what it is, and whether it is a new file or an edit of something you were given. The parent decides what to copy into its own workspace, so say plainly which are the deliverables and which are scratch — and never copy them out yourself.
 
                 ## When to pass work down
 
@@ -280,3 +289,14 @@
           - id: tool-plugin-manager
             name: '@deepseek-ai/dsh-plugin-manager/tools'
             disabled: true
+          # The workspace fence. Mounted as a preset row so one install carries the
+          # protocol and its enforcement together: the persona tells a child to write
+          # under its own _agents/ directory, and this refuses anything else before
+          # the call runs. It is preset-scoped rather than a separate profile bundle
+          # because the _agents/ convention only exists here — a guard without this
+          # persona would fence agents that were never told where they may write.
+          - id: root-planner-guard
+            name: 'dsh-root-planner-preset/guard'
+            config:
+              directoryName: _agents
+              guardShell: true

package/guard.js

@@ -0,0 +1,190 @@
+// Keeps a delegated subagent inside the workspace its parent gave it.
+//
+// This module ships inside `dsh-root-planner-preset` and is mounted as one of the
+// preset's own plugin rows (`dsh-root-planner-preset/guard`), so installing the preset
+// brings the protocol and its enforcement together. That placement is deliberate: the
+// `_agents/` convention is defined by this preset's persona, and a guard installed
+// without it would fence agents that were never told where they may write.
+//
+// One guard, registered once on the plugin's own context, inspects every tool call
+// and decides from the calling agent's session header. That is deliberately simpler
+// than wiring per-agent listeners: `ToolExecution` already carries `agent`, so the
+// guard needs neither the `agent/created` payload shape nor a per-agent context, and
+// nothing has to be registered or torn down when a child appears or disappears.
+//
+// Why a guard rather than a prompt rule: `tools.guard()` is synchronous and monotonic.
+// It refuses the call instead of asking the model not to make it, and no later guard
+// can force-allow a call this one denied.
+//
+// Two strengths are in play and the difference is not cosmetic:
+//
+//   * File tools carry the target path in their arguments, so a write, edit or
+//     replace outside `_agents/` is refused structurally — the call never runs.
+//   * Shell tools carry a command string, and a command can name a path no argument
+//     scan will see (`$env:HOME` + '..', a script that writes, a Here-String). For
+//     those the guard enforces the two things it can prove: the working directory
+//     must be inside the workspace, and an absolute path written into the command
+//     must not point at the parent's files. Anything assembled at runtime still gets
+//     past — the parent's timestamp check is the backstop for that, and this file
+//     says so rather than pretending the shell is confined.
+
+import { appendFileSync } from 'node:fs'
+import { isAbsolute, join, resolve, sep } from 'node:path'
+
+/** Tools that take a target file path as an argument. */
+const FILE_TOOLS = new Set(['write', 'edit', 'ops_replace'])
+
+/** Tools that take a command string, where the guard is best-effort. */
+const SHELL_TOOLS = new Set(['pwsh', 'ops_bash'])
+
+/** Argument keys the file tools use for their target. */
+const PATH_KEYS = ['path', 'file_path', 'filePath', 'target', 'targetPath']
+
+/** Argument keys the shell tools use for the working directory. */
+const WORKDIR_KEYS = ['workdir', 'cwd']
+
+/**
+ * Compare two absolute paths for containment, case-insensitively because this runs
+ * on Windows where `D:\X` and `d:\x` are the same directory.
+ * @param parent - the directory that must contain `child`.
+ * @param child - the candidate path.
+ * @returns whether `child` is `parent` or below it.
+ */
+function contains(parent, child) {
+  const p = parent.replace(/[\\/]+$/, '').toLowerCase()
+  const c = child.replace(/[\\/]+$/, '').toLowerCase()
+  if (c === p) return true
+  return c.startsWith(`${p}${sep}`) || c.startsWith(`${p}/`) || c.startsWith(`${p}\\`)
+}
+
+/**
+ * Pull the first string argument under any of the given keys.
+ * @param args - the parsed call arguments.
+ * @param keys - candidate keys in priority order.
+ * @returns the value, or `undefined` when none is a string.
+ */
+function firstString(args, keys) {
+  if (typeof args !== 'object' || args === null) return undefined
+  for (const key of keys) {
+    const value = args[key]
+    if (typeof value === 'string' && value.length > 0) return value
+  }
+  return undefined
+}
+
+/**
+ * Resolve one guard for a single agent.
+ * @param cwd - the session working directory, used to resolve relative paths.
+ * @param workspace - the absolute directory the agent may write in.
+ * @returns a synchronous guard.
+ */
+function makeGuard(cwd, workspace) {
+  const describe = (target) =>
+    `outside your workspace. You may write only inside ${JSON.stringify(workspace)}; ` +
+    `everything else in the parent's directory is read-only to you. ` +
+    `Send your parent a change request instead of writing ${JSON.stringify(target)} directly.`
+
+  return (exec) => {
+    const name = exec?.name
+    const args = exec?.arguments
+    if (typeof name !== 'string') return undefined
+
+    if (FILE_TOOLS.has(name)) {
+      const raw = firstString(args, PATH_KEYS)
+      // No path argument at all is the tool's own validation problem, not a boundary
+      // violation — refusing here would only hide the real error message.
+      if (raw === undefined) return undefined
+      const abs = isAbsolute(raw) ? resolve(raw) : resolve(cwd, raw)
+      if (!contains(workspace, abs)) return `${name}: ${describe(abs)}`
+      return undefined
+    }
+
+    if (SHELL_TOOLS.has(name)) {
+      // A shell with no explicit workdir runs in the session cwd, which is the
+      // parent's directory — precisely the place the child may not write. Requiring
+      // the workspace as workdir makes every relative path in the command land where
+      // it belongs.
+      const workdir = firstString(args, WORKDIR_KEYS)
+      const effective = workdir === undefined ? cwd : isAbsolute(workdir) ? resolve(workdir) : resolve(cwd, workdir)
+      if (!contains(workspace, effective)) {
+        return (
+          `${name}: the working directory ${JSON.stringify(effective)} is outside your workspace. ` +
+          `Pass workdir: ${JSON.stringify(workspace)} (or a directory inside it) and use relative paths ` +
+          `so everything you create stays in your workspace.`
+        )
+      }
+      // Best effort: refuse an absolute path in the command that points at the
+      // parent's files. A path assembled at runtime defeats this; the parent's
+      // timestamp check is the backstop.
+      const command = typeof args?.command === 'string' ? args.command : ''
+      const escaped = [...command.matchAll(/[A-Za-z]:[\\/][^\s"'`;|&)]*/g)].map((match) => match[0])
+      const outside = escaped.find((candidate) => {
+        const abs = resolve(candidate)
+        return !contains(workspace, abs) && contains(cwd, abs)
+      })
+      if (outside !== undefined) return `${name}: the command writes ${JSON.stringify(outside)}, ${describe(outside)}`
+      return undefined
+    }
+
+    return undefined
+  }
+}
+
+export const name = 'root-planner-guard'
+
+export const inject = ['tools']
+
+// No `Config` export on purpose: Cordis validates a declared Config with a zod schema
+// (`schema.validate`), and a plain JSON Schema object throws at activation with
+// "Cannot read properties of undefined (reading 'validate')". Shipping no schema and
+// coercing the optional fields in `apply` keeps the row usable without pulling a
+// dependency into a plugin that is installed by directory link.
+const DEFAULTS = { enabled: true, directoryName: '_agents', guardShell: true }
+
+/** Exported for the unit test: the boundary logic is worth testing without a session. */
+export { contains, makeGuard }
+
+export function apply(ctx, config = {}) {
+  const settings = { ...DEFAULTS, ...(typeof config === 'object' && config !== null ? config : {}) }
+  if (settings.enabled === false) return
+  const directoryName =
+    typeof settings.directoryName === 'string' && settings.directoryName.length > 0
+      ? settings.directoryName
+      : DEFAULTS.directoryName
+  const guardShell = settings.guardShell !== false
+
+  const trace = (line) => {
+    if (settings.debug !== true) return
+    try {
+      appendFileSync(
+        settings.debugFile ?? `${process.cwd()}\\guard-debug.log`,
+        `${new Date().toISOString()} ${line}\n`,
+      )
+    } catch {
+      /* a probe must never break the plugin */
+    }
+  }
+
+  trace(`apply: listening on the plugin context (directoryName=${directoryName})`)
+
+  // Registered on the plugin's own context: a plain-context guard applies globally,
+  // and the decision is made per call from `exec.agent`, so no per-agent wiring is
+  // needed and no registration leaks when an agent is disposed.
+  ctx.effect(() => {
+    const dispose = ctx.tools.guard((exec) => {
+      const header = exec?.agent?.session?.header
+      // Only delegated sessions are fenced: the root owns the workspace and must be
+      // able to write anywhere in it, or it could not integrate a child's artifacts.
+      if (header?.origin !== 'subagent') return undefined
+      const cwd = header.cwd ?? process.cwd()
+      if (typeof cwd !== 'string' || cwd.length === 0) return undefined
+      const workspace = join(cwd, directoryName)
+      const guard = makeGuard(cwd, workspace)
+      const verdict = guardShell ? guard(exec) : SHELL_TOOLS.has(exec?.name) ? undefined : guard(exec)
+      trace(`call ${exec?.name} from ${String(header.id)} -> ${verdict === undefined ? 'allow' : 'DENY'}`)
+      return verdict
+    })
+    trace('guard registered')
+    return dispose
+  })
+}

package/package.json

@@ -1,10 +1,32 @@
 {
   "name": "dsh-root-planner-preset",
-  "version": "1.1.7",
+  "version": "1.3.0",
   "type": "module",
-  "description": "DSH agent preset that outsources file reading to strictly read-only subagents, while the root agent keeps the plan and owns every file mutation.",
+  "description": "DSH agent preset: the root agent plans and decides, subagent workers read, write and run commands inside their own _agents/ workspace, and nothing outlives its task.",
   "license": "MIT",
   "author": "XiaoOu2024",
+  "exports": {
+    ".": "./guard.js",
+    "./guard": "./guard.js",
+    "./package.json": "./package.json"
+  },
+  "files": [
+    "guard.js",
+    "persona.txt",
+    "child-tools.mjs",
+    "build-patch.mjs",
+    "verify-patch.mjs",
+    "verify-depth-override.mjs",
+    "lib-yaml.mjs",
+    "release.mjs",
+    "cordis.patch.yml",
+    "tools/",
+    "docs/",
+    "README.md",
+    "README.zh.md",
+    "INSTALL.md",
+    "LICENSE"
+  ],
   "homepage": "https://github.com/XiaoOu2024/dsh-root-planner-preset#readme",
   "repository": {
     "type": "git",
@@ -20,7 +42,8 @@
     "cordis",
     "subagent",
     "delegation",
-    "read-only"
+    "workspace-isolation",
+    "guard"
   ],
   "dsh": {
     "bundle": {

package/persona.txt

@@ -34,17 +34,26 @@ Reading is not planning. Raw file contents and raw query results belong in the a
 12. Give concurrent subagents disjoint work. Two workers editing the same file produce a merge you have to untangle, and neither of them can see the other. Partition by file or by directory when you dispatch in parallel, and keep the integration — the final read-through of what changed — for yourself. **One writer per path, always:** if two subtasks genuinely need to modify the same file, run them one after the other rather than together, and never let two agents own the same output directory.
 13. Reuse a child before spawning a new one. A finished child still holds everything it read, and `send_message` starts another turn in that same context — so a follow-up about the same material belongs there, not in a fresh agent that must read it all again. Sessions are isolated and a sibling cannot be told what another one already read, so overlapping reads across agents are a real cost you pay twice: once in tokens and once in the chance that two agents report the same file differently. When several subtasks need the same document, give them to one agent, or read it yourself and pass the conclusion down.
 14. Decide who runs it, and do not hand a command down out of habit. Subagents do have a shell, so "run the tests and report" is a legitimate delegation — but the same budget as rule 2 applies: a single short command is cheaper run directly, and a delegated command returns you its output through a summary rather than raw. Hand down the commands that belong to a workstream a subagent already owns; run the ones that decide your own next step.
+15. **Name only tools this environment actually has.** Verify a command exists before you put it in a task, and prefer the structured tool over a shell pipeline when both would work. A wrong tool name does not fail once — it fails every time the child tries it, and a child that keeps retrying a missing binary looks exactly like a child that is working. Read the workspace's environment notes (the machine-level instruction file, if any) for which binaries are present; do not assume a familiar utility exists because it exists on other machines.
+16. **Require checkpoints on long work, because a silent child is not evidence of progress.** A subagent says nothing until it finishes, so a task that has run for many minutes is indistinguishable from a stuck one, and the only signal a parent has from outside is the state of whatever the child was asked to change. When a task is long — a large file, many items, a build — say in the task: finish the smallest item first and report immediately with `send_message`, then report after every batch. When a child falls silent past its checkpoint, ask it before you interrupt it: `send_message` "report your current state" costs one round trip and turns a guess into an answer.
+17. **Give every child its own workspace, and name it in the task.** Before you delegate, create `_agents/<label>/` under your working directory — a short unique label per agent, derived from its job — and put the **absolute path** in the task: that directory is where the child may write, and everything else in your workspace is read-only to it. A child reuses the same directory on a follow-up, so keep the label stable per agent. If the workspace is a git repository, make sure `_agents/` is in `.gitignore` before the first child writes there.
+18. **Check the boundary, then integrate.** A child has a shell, so the read-only side of rule 17 is an agreement rather than a fence — verify it instead of assuming it. Before delegating, `touch _agents/.mark-<label>`; after the child reports, run `find . -path ./_agents -prune -o -type f -newer _agents/.mark-<label> -print`. No output means it touched nothing outside its own directory; any output is a file to inspect, and a genuine outside edit is a defect to correct, not a surprise to accept. Then integrate deliberately: read the child's artifact list, decide which files matter, and copy those — and only those — into your workspace, merging into existing files where that is what the change means and keeping them separate where it is not. Leave `_agents/<label>/` in place so the same agent can be continued later.
 
 ## Subagent rules
 
 1. You can read, change files, and run commands — you are a worker, not an observer. **Read the task you were given for what you may do.** A bounded task means bounded: change the files the task is about, run the commands it needs, and leave everything else alone.
 2. **Never leave something running.** No servers, watchers, daemons, background jobs, or detached processes — background execution is switched off for your shell, and `ops_bash` has no job registry, so a command that blocks there holds your call until it times out. If a task seems to need a service, start it only as a foreground command that finishes, or report that it needs one and let the delegating agent decide. A long-lived process is a decision above your level, not a detail you arrange quietly.
-3. Keep every change inside your task. Do not reformat unrelated code, do not "fix what you noticed" on the way past, and do not touch files the task did not name. If you find another problem, report it — do not fix it.
-4. Do not race the other agents. Assume siblings are writing files at the same time: work on the paths you were given, and if you need to change a file the task did not mention, say so in your report instead of changing it.
+3. **Write only inside your own workspace.** Your task names one directory under `_agents/` — that is yours, and everything you create belongs there. Every other file in the delegating agent's workspace is **read-only for you**: read it freely, never modify, rename or delete it, and never write a stray file next to it. If your work needs a change outside your workspace, do not make it — send a change request (rule 12).
+4. Know what the shared files are for. The parent's files are the common reference, open to every agent, which is exactly why none of you may write them: a file two agents edit at once has no correct final state. Your workspace is the one place where you are the only writer, so keep your scratch work, drafts and outputs in it rather than beside the originals.
 5. Answer the question you were asked and do not re-plan the parent's task. Bound the work, then return.
 6. Report only what you found: state the conclusion, flag what you could not determine, and name the uncertainty. Do not pad, do not speculate past the evidence, and do not restate the request.
 7. Format findings for the delegating agent's context budget. Lead with the conclusion, then the minimum evidence that establishes it (paths, line numbers, short quoted excerpts), then open questions. Omit raw file contents, exhaustive listings, and anything the reader did not ask for. Run commands with their output narrowed — a filtered result beats a full dump you expect the reader to sift.
 8. You may be a leaf or you may still hold one more level of delegation. The runtime enforces the depth limit, not your restraint: if you have no delegation tool, or a delegation attempt is rejected for depth, that is the intended shape of the tree — **do the work yourself and say in your report that you did it directly because the tree ended there.** Do not route work onward to avoid doing it, do not treat a depth rejection as a failure, and do not hand the work back to the delegating agent merely because you cannot pass it further. If you cannot finish, or the request is ambiguous and cannot be resolved by doing the work, say so plainly and stop. Do not guess and do not invent a result.
+9. **A write that reports no change is a failure, not progress.** If a change tool answers `changed: 0`, `bytesAfter` equals `bytesBefore`, or the file still holds the old content, nothing was written — work out why before trying again. The two traps that produce this on purpose are running the tool in observe-only mode (`dryRun: true`) and passing a directory where a file path belongs. Read what the tool actually returned; do not assume a call succeeded because you sent it.
+10. **Two identical failures are enough.** When the same operation fails twice for the same reason, stop: report the exact error, what you tried, and what you think the obstacle is. Do not try variations of a call that is structurally wrong, and do not keep retrying a missing tool. A silent retry loop burns the whole task while looking like work.
+11. **Report progress before you finish when the work is long.** Nobody can see you from outside: your parent learns only that a file did or did not change, which cannot distinguish slow from stuck. When your task says to checkpoint, do it — finish the smallest item, then `send_message` your direct parent a one-line state (what is done, what is next, how many remain). Do the same unprompted if you judge the work will take many steps. Silence is read as a stall, and a stalled child gets interrupted with its work discarded.
+12. **A change outside your workspace is a request, not an action.** You have the tools to write anywhere your parent's workspace allows, so the boundary is agreed rather than enforced: when the work needs an existing file changed, send your direct parent the request — path, the exact location (file and line), current content, proposed replacement, why — and keep going on the rest while it decides. Do the same for anything you would delete or rename. Making the change yourself is the one failure this protocol calls serious, because the parent cannot tell your edit apart from a concurrent one.
+13. **Report artifacts, not activity.** Finish with a list of what you produced: each file, its path inside your workspace, what it is, and whether it is a new file or an edit of something you were given. The parent decides what to copy into its own workspace, so say plainly which are the deliverables and which are scratch — and never copy them out yourself.
 
 ## When to pass work down
 

package/release.mjs

@@ -166,15 +166,29 @@ if (dryRun) {
   //  * The output must be shown even on failure. The first version filtered it
   //    down to matching lines and printed a blank line when the command never
   //    ran, hiding the real problem behind a successful-looking step.
-  const published = run(PUBLISHER, ['publish', '--registry', OFFICIAL_REGISTRY, '--access', 'public'], {
-    allowFailure: true,
+  const publishRun = spawnSync(PUBLISHER, ['publish', '--registry', OFFICIAL_REGISTRY, '--access', 'public'], {
+    cwd: here,
+    env,
+    encoding: 'utf8',
     shell: true,
   });
+  const published = `${publishRun.stdout ?? ''}${publishRun.stderr ?? ''}`;
   const summary = published
     .split('\n')
     .map((line) => line.trim())
     .filter((line) => line.length > 0 && !/^Progress:|^Packages:|^\+?$/.test(line));
-  process.stdout.write(`${summary.map((line) => `  ${line}`).join('\n') || '  (the publisher printed nothing — treat that as a failure)'}\n`);
+  process.stdout.write(`${summary.map((line) => `  ${line}`).join('\n') || '  (the publisher printed nothing)'}\n`);
+  // Stop here on a failed publish. Continuing to the registry poll turned a network
+  // blip into ten minutes of waiting and then a confident but wrong diagnosis
+  // ("staged publishing?"), when the publish command had simply not run.
+  if (publishRun.status !== 0) {
+    const reason = publishRun.error ? `${publishRun.error.code}: ${publishRun.error.message}` : `exit ${publishRun.status}`;
+    throw new Error(
+      `the publisher failed (${reason}), so nothing was published and the registry check would only time out.\n` +
+        `Retry the publish by hand once the cause is clear:\n` +
+        `  ${PUBLISHER} publish --registry ${OFFICIAL_REGISTRY} --access public`,
+    );
+  }
 }
 
 // ── Confirm on the registry ──────────────────────────────────────────────────

package/verify-patch.mjs

@@ -9,7 +9,7 @@
 //
 // Usage: node verify-patch.mjs
 
-import { readFileSync } from 'node:fs';
+import { existsSync, readFileSync } from 'node:fs';
 import { dirname, join } from 'node:path';
 import { fileURLToPath } from 'node:url';
 import { CHILD_TOOLS, FORBIDDEN_CAPABILITIES, SCOPE_LOCAL_TOOLS } from './child-tools.mjs';
@@ -56,14 +56,28 @@ check(personaRow?.config?.suffix === 'Your working directory is {{cwd}}.', 'pers
 const expected = readFileSync(join(here, 'persona.txt'), 'utf8').replace(/\r\n/g, '\n').trimEnd();
 check(personaRow?.config?.prefix === expected, 'parsed persona is byte-identical to persona.txt');
 check(!personaRow?.config?.prefix?.includes('\t'), 'persona contains no tab characters');
-check(/read-only/.test(personaRow?.config?.prefix ?? '') === false, 'persona no longer claims subagents are read-only (they are workers with write and shell)');
+check(
+  /You can read, change files, and run commands/.test(personaRow?.config?.prefix ?? ''),
+  'persona states that a subagent is a worker with write and shell',
+);
+// The exact wrong sentence this bundle once shipped. A loose /read-only/ test is no
+// good now that the persona legitimately calls the PARENT's files read-only.
+check(
+  !/You are read-only, and this is structural/.test(personaRow?.config?.prefix ?? ''),
+  'persona does not claim subagents themselves are read-only',
+);
+check(
+  /Write only inside your own workspace/.test(personaRow?.config?.prefix ?? ''),
+  'persona confines a subagent to its own workspace',
+);
 check(
   /Never leave something running/.test(personaRow?.config?.prefix ?? ''),
   'persona forbids long-running processes for subagents',
 );
 
+
 /**
- * Rule count, asserted on purpose.
+ * Rule counts, asserted on purpose.
  *
  * Byte-identity above only proves the patch matches `persona.txt` in the working
  * tree. It says nothing about what was PUBLISHED: 1.1.6 shipped a package.json bump
@@ -71,10 +85,11 @@ check(
  * tree, so npm carried a 13-rule persona while the repository had 14. The byte check
  * could not see that, because both files agreed with each other.
  *
- * Update this number in the same commit as the rule it counts, so the release is the
- * act that carries it.
+ * Update these numbers in the same commit as the rule they count, so the release is
+ * the act that carries it.
  */
-const ROOT_RULE_COUNT = 14;
+const ROOT_RULE_COUNT = 18;
+const SUBAGENT_RULE_COUNT = 13;
 const rootSection = (personaRow?.config?.prefix ?? '').split('## Root agent rules')[1]?.split('## Subagent rules')[0] ?? '';
 const rootRules = [...rootSection.matchAll(/^(\d+)\. /gm)].map((match) => Number(match[1]));
 check(
@@ -86,8 +101,38 @@ check(
   `root rule numbering is 1..${rootRules.length} with no gaps or repeats (found ${rootRules.join(',')})`,
 );
 
+const subagentSection = (personaRow?.config?.prefix ?? '').split('## Subagent rules')[1]?.split('## When to pass work down')[0] ?? '';
+const subagentRules = [...subagentSection.matchAll(/^(\d+)\. /gm)].map((match) => Number(match[1]));
+check(
+  subagentRules.length === SUBAGENT_RULE_COUNT,
+  `persona carries ${SUBAGENT_RULE_COUNT} subagent rules (found ${subagentRules.length})`,
+);
+check(
+  subagentRules.every((value, index) => value === index + 1),
+  `subagent rule numbering is 1..${subagentRules.length} with no gaps or repeats (found ${subagentRules.join(',')})`,
+);
+
 const delegation = plugins.find((row) => row.id === 'delegation');
 check(delegation?.group === true, 'delegation is a group row');
+
+// The workspace fence travels with the preset, so one install carries the protocol and
+// its enforcement. These assertions keep that promise honest: the row must exist, must
+// resolve to this package's own module, and must ship that module.
+const guardRow = plugins.find((row) => row.id === 'root-planner-guard');
+check(guardRow !== undefined, 'the preset mounts the workspace guard as its own row');
+check(
+  guardRow?.name === 'dsh-root-planner-preset/guard',
+  `the guard row resolves to this package's subpath (found ${JSON.stringify(guardRow?.name)})`,
+);
+check(guardRow?.disabled !== true, 'the guard row is enabled');
+check(guardRow?.config?.directoryName === '_agents', 'the guard fences the _agents/ directory');
+check(guardRow?.config?.guardShell === true, 'the guard also applies the shell rules');
+check(existsSync(join(here, 'guard.js')), 'guard.js ships inside the package');
+{
+  const manifest = JSON.parse(readFileSync(join(here, 'package.json'), 'utf8'));
+  check(manifest.exports?.['./guard'] === './guard.js', 'package.json exports ./guard');
+  check((manifest.files ?? []).includes('guard.js'), 'guard.js is in the published files list');
+}
 const delegationRows = delegation?.config ?? [];
 
 // Loader row id -> the model-facing tool name that row publishes.

package/.gitattributes

@@ -1,10 +0,0 @@
-# This bundle is verified by BYTE identity: verify-patch.mjs asserts that the
-# persona parsed out of cordis.patch.yml equals persona.txt exactly. Git's
-# autocrlf would rewrite both files on checkout and silently break that check on
-# every Windows clone, so line endings are pinned to LF for the whole repository.
-* text=auto eol=lf
-
-# Binary if anyone ever adds artwork.
-*.png binary
-*.jpg binary
-*.webp binary

package/.github/CONTRIBUTING.md

@@ -1,126 +0,0 @@
-# Contributing
-
-Thanks for looking. This repository is meant to be maintained by more than its
-author — the license is [MIT](../LICENSE), and issues and pull requests are open
-to anyone.
-## The one thing to know first
-
-**`cordis.patch.yml` is generated. Do not edit it by hand.**
-
-It is produced from `persona.txt` by `build-patch.mjs`, and it has to be indented
-into a YAML block scalar exactly — a single mis-indented line silently truncates
-the ~6 KB persona, which is very hard to spot in review and easy to introduce by
-hand. That is the whole reason the generator exists.
-
-So to change what the agent is told:
-
-```sh
-$EDITOR persona.txt
-node build-patch.mjs      # regenerates cordis.patch.yml
-node verify-patch.mjs     # must print ALL CHECKS PASSED
-```
-
-Commit **both** files. CI re-runs the generator and fails if the committed patch
-does not match `persona.txt` byte for byte, so forgetting the second command is
-caught for you.
-
-## Setup
-
-The bundle itself ships no dependencies. The repository's scripts need one YAML
-parser, which `lib-yaml.mjs` resolves from your own DSH installation — or from a
-local install:
-
-```sh
-npm ci        # installs js-yaml, the only devDependency
-```
-
-## What the checks mean
-
-`node verify-patch.mjs` asserts, among other things:
-
-- the patch parses as loader YAML (including the `!!js` scalars, read as opaque);
-- the persona parsed out of the patch is **byte-identical** to `persona.txt`;
-- both delegation tools publish `subagent` / `subagent_fork`;
-- both `toolFilter.allow` masks exclude every mutation entry point
-  (`write`, `edit`, `ops_replace`, `ops_bash`, `pwsh`) and name **only tools that
-  exist** — a name that is not a registered global tool makes
-  `tools.restrict()` throw the first time a subagent is created.
-
-That last point is the most likely thing to need changing on your machine: the
-mask was written against the author's profile. If your profile registers a
-different set of global tools, the mask is what has to adapt — edit the list near
-the bottom of `verify-patch.mjs` in the same commit.
-
-`node verify-depth-override.mjs` checks the delegation depth override. Depth is a
-**Host setting, not part of this bundle**, so on a machine that never set it the
-script prints `SKIP` and explains why. That is a pass, not a failure.
-
-## Most valuable contributions, in order
-
-1. **Bug reports with real error text**, plus your DSH version and which global
-   tools your profile registers. The `Not verified` section of the
-   [README](../README.md) names exactly where this matters: no subagent has been
-   spawned under this preset in the author's environment to date.
-2. **Mask fixes for other environments** — see above.
-3. **Persona improvements** — the text itself, when you have an observed failure
-   it would have prevented.
-4. **Documentation and translations** — [README.zh.md](../README.zh.md) and
-   [INSTALL.md](../INSTALL.md) especially.
-
-## Ground rules
-
-- **One concern per pull request.** A persona change and a mask change are two
-  pull requests unless one requires the other.
-- Say which preset you tested with, and on which platform.
-- Do not weaken the **process bound**. `enableRunInBackground: false` must stay on
-  the preset's `tool-pwsh` row: a change that lets a subagent detach a server drops
-  the one property this preset enforces structurally rather than by asking nicely.
-  `verify-patch.mjs` fails if it is missing.
-- A subagent keeps `write`, `edit`, `ops_replace` and `pwsh`. They are workers —
-  taking their tools away turns every executable step back into the root's own work,
-  which is the failure mode this preset exists to avoid.
-- Keep `main` linear — the branch protection refuses merge commits, so rebase
-  rather than merge.
-
-## Releasing
-
-`node release.mjs <patch|minor|major|X.Y.Z>` does the whole sequence. Every step in
-it exists because the manual version went wrong at least once:
-
-1. regenerates `cordis.patch.yml` and refuses to continue unless
-   `verify-patch.mjs` passes;
-2. bumps `package.json` and commits with a local-time stamp;
-3. pushes (the owner bypasses branch protection; a collaborator's push is refused,
-   so open a pull request instead);
-4. publishes to `https://registry.npmjs.org/` **explicitly** — the configured
-   registry is a read-only mirror that also lags behind, which is how an install
-   right after a release fails with *No matching version found*;
-5. **polls the registry for the exact version** rather than trusting the exit code,
-   because publishing on this account is staged and `npm publish` can print success
-   without the version ever appearing;
-6. upgrades the local profile so the machine runs what was published.
-
-`--dry-run` walks the whole thing without changing anything; `--skip-install` and
-`--skip-gh` drop the last two steps.
-
-Run it from a terminal. Inside DSH's own sandbox its `spawn` calls fail with
-`EPERM` on Windows — that is the sandbox's piped-stdio boundary, not a defect in
-the script.
-
-**A release is not a verification.** The script can put a version on npm while the
-preset stays unproven. Restart `dsh web`, open a new session on Root Planner, and
-confirm the *root* actually composed with it — `node tools/verify-session.mjs
-<session-dir>` — before believing anything about behaviour.
-
-## How `main` is protected
-
-`main` requires the `verify` status check (strict: the branch must be up to date),
-refuses force pushes and deletions, requires linear history, and requires
-conversations to be resolved. The repository owner can bypass these for a direct
-push in an emergency; **collaborators cannot** — send a pull request and let CI
-run.
-
-If you are added as a collaborator and want to be able to merge your own pull
-requests without waiting for the owner, say so: review requirements are off
-deliberately, because a single-maintainer repository that requires an approval it
-cannot get would deadlock.

package/.github/workflows/verify.yml

@@ -1,51 +0,0 @@
-# Verifies the bundle on every push and pull request.
-#
-# Two failure modes this exists to catch, both of which are silent locally:
-#
-#  1. `cordis.patch.yml` is generated from `persona.txt`. Someone edits the
-#     generated file by hand (or edits persona.txt and forgets to regenerate), and
-#     the persona the preset actually ships no longer matches the source. The
-#     generator is deterministic, so re-running it and diffing the result catches
-#     exactly that drift.
-#  2. A change to the child tool mask names a tool that is not a registered global
-#     tool. `tools.restrict()` throws on an unknown name at child-creation time, so
-#     this only surfaces the first time a subagent is actually spawned — never in a
-#     local syntax check.
-#
-# The bundle itself ships no dependencies; `js-yaml` is a devDependency of this
-# repository only, and `lib-yaml.mjs` picks it up from the checkout.
-
-name: verify
-
-on:
-  push:
-    branches: [main]
-  pull_request:
-  workflow_dispatch:
-
-permissions:
-  contents: read
-
-jobs:
-  verify:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: '22'
-
-      - name: Install the local YAML parser
-        run: npm ci --ignore-scripts
-
-      - name: The committed patch matches persona.txt
-        run: |
-          node build-patch.mjs
-          if ! git diff --exit-code -- cordis.patch.yml; then
-            echo "::error file=cordis.patch.yml::cordis.patch.yml is out of date. Run 'node build-patch.mjs' and commit the result instead of editing it by hand."
-            exit 1
-          fi
-
-      - name: Patch structure, persona byte-identity and the child tool mask
-        run: node verify-patch.mjs