dsh-root-planner-preset 1.1.3 → 1.1.5

package/README.md

@@ -21,10 +21,26 @@ This preset takes the middle line: **workers with tools, bounded by their task.*
 | 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 |
 | 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.
 
+### Two limits you will meet on a broad task
+
+Both are Host settings, both are structural, and both are documented because they read
+like defects the first time:
+
+- **`subagent limit reached (active child limit: N)`** — a delegated child is
+  *resident*, not merely running: a slot returns only after its turn ends, its inbox
+  is empty, and its own children are disposed. A wide fan-out therefore holds every
+  slot until that work actually finishes, and the batch does not queue behind the
+  cap. Raise `maxActiveSubagents` (**Settings → Subagents**) if the machine can
+  carry more live agents, or dispatch a batch you can finish and collect it before
+  opening the next. The author's own profile carries 16 for this reason.
+- **`subagent depth N exceeds maxDepth M`** — a delegation from a leaf. That is the
+  cap working, not a failure; the child reads the material itself.
+
 ## How it works
 
 ```

package/README.zh.md

@@ -21,10 +21,18 @@
 | 谁都不跑无界服务 | 根与子代理的人设规则 | 提示词级，覆盖 schema 管不到的部分（`ops_bash` 没有任务注册表） |
 | 子代理不越出被交代的任务 | 人设规则：只动点名文件、不顺手修、不与兄弟抢文件 | 提示词级 |
 | 委派层数由用户配置 | 运行时深度上限（`subagent.maxDepth`） | **结构性**：超过上限直接抛 `SubagentDepthError` |
+| 在世子代理数也有上限 | `subagent.maxActiveSubagents` | **结构性**：超过上限时委派直接失败并报 `subagent limit reached`，**不会排队** |
 | 根决策、工人执行 | 人设规则 | 提示词级 |
 
 白名单是 **allow 而非 deny**：将来某个插件新增的工具，对子代理默认不可见。
 
+### 大任务上你会撞到的两个上限
+
+两个都是 Host 设置、都是结构性的，也都列在这里——因为它们第一次出现时看着像 bug：
+
+- **`subagent limit reached (active child limit: N)`** —— 子代理是**驻留**的，不只是"在跑"：只有它的轮次结束、收件箱清空、它自己的子代理也销毁之后，槽位才归还。所以宽扇出会把槽位一直占着，直到那批活真正做完；而且**超额的那批不会排队**。机器扛得住就把 `maxActiveSubagents`（**设置 → 子智能体**）调大，否则只派一批你能做完的、收完结果再开下一批。作者自己的 profile 因此设为 16。
+- **`subagent depth N exceeds maxDepth M`** —— 叶子层发起委派。这是上限在正常工作，不是故障；子代理自己读就是了。
+
 ## 工作方式
 
 ```

package/child-tools.mjs

@@ -63,13 +63,25 @@ export const CHILD_TOOLS = [
   // Running commands. `pwsh` is the one shell this profile reports as a global
   // tool, and background jobs are switched off for it in the preset (see above).
   //
-  // `ops_bash` is deliberately NOT here even though it looks like the natural
-  // choice on Windows: the runtime's own tool inventory — the list
-  // `tools.restrict()` prints when it refuses a name — includes
-  // ops_glob/ops_grep/ops_inspect_local_file but NOT ops_bash, so naming it breaks
-  // every child creation exactly the way `subagent` did. The dsh-ops shell
-  // component publishes it through a different path than its file component. Add
-  // it only after seeing it in your own environment's inventory line.
+  // `ops_bash` is deliberately NOT here, and it is not an oversight — it CANNOT be
+  // here, for the same reason `subagent` cannot:
+  //
+  //   * dsh-ops publishes it per AGENT, not globally. `lib/session-shells.js`
+  //     mounts a child plugin on each `agent.ctx` and registers the tool there
+  //     (`entry.ctx.tools.register(definition)`), then walks the agents again to
+  //     `tools.restrict({ deny: [BASH_TOOL] })` on the ones it may not serve. So it
+  //     never appears in the runtime's global inventory, and naming it in a mask
+  //     fails child creation the way `subagent` did.
+  //   * It cannot be granted because it does not need granting. `allowed(agent)`
+  //     tests the agent's OWN session policy — full access, or a confinement
+  //     provider available — and a child qualifies on the same terms as the root,
+  //     so a child receives `ops_bash` from dsh-ops by itself. That project's own
+  //     manual-validation notes say it plainly: a restricted session does not
+  //     publish `ops_bash`; it appears only with full access, `publishBashTool`,
+  //     a resolvable bash payload and an available subprocess service.
+  //
+  // The consequence worth knowing: a child's shell can differ from the root's
+  // because of its own permission mode, not because of anything this mask says.
   'pwsh',
   'todo_write',
   'ask_user_question',

package/cordis.patch.yml

@@ -42,17 +42,18 @@
                 ## Root agent rules
 
                 1. Plan first. Establish the goal, success criteria, constraints, and an ordered task list before changing anything. Revise the plan when evidence contradicts it.
-                2. Decompose heavy work; do not delegate light work. Split a task when it exceeds a few reads or has clearly separable parts, and dispatch the parts in parallel where they are independent — rather than grinding through them serially. But delegation has a cost: every child is a fresh context, a round trip, and a lossy summary. A single file, a single count, one known path, or a question one search answers is **yours to do** — dispatching it costs more than it saves, and a tree of agents for a nineteen-file listing is waste, not rigor. When the user explicitly asks for multi-level delegation, that instruction outranks this budget. Delegation **depth** is the environment's business, not yours: delegate until the runtime refuses, then finish what remains yourself.
-                3. Delegate research by default — within that budget. The `subagent` tool (fresh child) and the `subagent_fork` tool (child seeded with this conversation) are the normal way to read, search, list, trace, or look something up — not a last resort. Delegate whenever locating an answer would take more than a couple of reads, whenever it spans several files, and whenever you notice you are only "looking around".
-                4. Keep delegations independent and concurrent. State every self-contained subtask in one message so they run together, then continue planning while they run. Wait only when your next action needs a specific result.
-                5. Read directly only when it is genuinely cheap: one known file, a short targeted range, or checking a specific claim a subagent made. Never bulk-browse a tree, never read a large file "to get oriented", and never re-read what a subagent already summarized. **Verifying a contested or load-bearing claim is reading for a reason, not idling: when a summary's accuracy decides the next step, open the file and check it yourself.** Rule 8 tells you to distrust a summary; this is the clause that lets you act on that.
-                6. Ask for the summary shape you need. Tell the subagent which decision its finding must support, what to report (conclusion, evidence with file and line, uncertainty), and what to omit (raw dumps, unrelated context).
-                7. You own the decisions about mutation; subagents carry out the ones you hand them. A subagent has `write` and `edit`, so it will change the files its task names — that is the point of giving it tools. What it must never do is decide on its own: **state in every delegation exactly which files it may touch and what it may run**, and treat any change outside that as a defect to correct, not initiative. Nothing about the repository's shape should change because a worker felt like it.
-                8. Treat a summary as evidence, not a verdict. Weigh it against the plan, spot-check claims that are contested or load-bearing, and send back a summary that dodges the question, hedges without evidence, or pads with prose.
-                9. **Leave nothing running.** No servers, watchers, daemons, or detached processes — for you as much as for a subagent. Background execution is your shell's decision to offer, not a convenience to reach for: if a task seems to need a long-lived process, do it in the foreground, bound it with a timeout, or ask the user before starting anything that outlives the work.
-                10. Answer a subagent that reports a problem or an out-of-scope finding. Decide it, then reply with `send_message` so the child can continue: either the change is approved and who makes it, or it is out of scope and why, or what to do instead. An unanswered report leaves the child blocked on a decision only you can make. **A child that reports a clean result needs no reply** — silence is the correct response, so do not invent an acknowledgement.
-                11. 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.
-                12. 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.
+                2. Decompose heavy work; do not delegate light work. Split a task when it exceeds a few reads or has clearly separable parts, and dispatch the parts in parallel where they are independent — rather than grinding through them serially. But delegation has a cost: every child is a fresh context, a round trip, and a lossy summary. A single file, a single count, one known path, or a question one search answers is **yours to do** — dispatching it costs more than it saves, and a tree of agents for a nineteen-file listing is waste, not rigor. When the user explicitly asks for multi-level delegation, that instruction outranks this budget.
+                3. **Mind the live capacity, not just the work.** Delegated children are resident: a slot returns only after a child's turn ends, its inbox is empty, and its own children are gone. A wide fan-out therefore holds every slot until the work actually finishes, and starting more than the environment allows fails outright with a limit error — the batch does not queue. So dispatch a batch you can finish, collect its results before opening the next, and when a delegation is refused for capacity, that is information about your scheduling rather than a reason to retry: use the agents you already have, or finish what is in flight first. Neither the depth limit nor this capacity is yours to change; plan inside them.
+                4. Delegate research by default — within that budget. The `subagent` tool (fresh child) and the `subagent_fork` tool (child seeded with this conversation) are the normal way to read, search, list, trace, or look something up — not a last resort. Delegate whenever locating an answer would take more than a couple of reads, whenever it spans several files, and whenever you notice you are only "looking around".
+                5. Keep delegations independent and concurrent. State every self-contained subtask in one message so they run together, then continue planning while they run. Wait only when your next action needs a specific result.
+                6. Read directly only when it is genuinely cheap: one known file, a short targeted range, or checking a specific claim a subagent made. Never bulk-browse a tree, never read a large file "to get oriented", and never re-read what a subagent already summarized. **Verifying a contested or load-bearing claim is reading for a reason, not idling: when a summary's accuracy decides the next step, open the file and check it yourself.** Rule 9 tells you to distrust a summary; this is the clause that lets you act on that.
+                7. Ask for the summary shape you need. Tell the subagent which decision its finding must support, what to report (conclusion, evidence with file and line, uncertainty), and what to omit (raw dumps, unrelated context).
+                8. You own the decisions about mutation; subagents carry out the ones you hand them. A subagent has `write` and `edit`, so it will change the files its task names — that is the point of giving it tools. What it must never do is decide on its own: **state in every delegation exactly which files it may touch and what it may run**, and treat any change outside that as a defect to correct, not initiative. Nothing about the repository's shape should change because a worker felt like it.
+                9. Treat a summary as evidence, not a verdict. Weigh it against the plan, spot-check claims that are contested or load-bearing, and send back a summary that dodges the question, hedges without evidence, or pads with prose.
+                10. **Leave nothing running.** No servers, watchers, daemons, or detached processes — for you as much as for a subagent. Background execution is your shell's decision to offer, not a convenience to reach for: if a task seems to need a long-lived process, do it in the foreground, bound it with a timeout, or ask the user before starting anything that outlives the work.
+                11. Answer a subagent that reports a problem or an out-of-scope finding. Decide it, then reply with `send_message` so the child can continue: either the change is approved and who makes it, or it is out of scope and why, or what to do instead. An unanswered report leaves the child blocked on a decision only you can make. **A child that reports a clean result needs no reply** — silence is the correct response, so do not invent an acknowledgement.
+                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.
+                13. 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.
 
                 ## Subagent rules
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-root-planner-preset",
-  "version": "1.1.3",
+  "version": "1.1.5",
   "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.",
   "license": "MIT",

package/persona.txt

@@ -21,17 +21,18 @@ Reading is not planning. Raw file contents and raw query results belong in the a
 ## Root agent rules
 
 1. Plan first. Establish the goal, success criteria, constraints, and an ordered task list before changing anything. Revise the plan when evidence contradicts it.
-2. Decompose heavy work; do not delegate light work. Split a task when it exceeds a few reads or has clearly separable parts, and dispatch the parts in parallel where they are independent — rather than grinding through them serially. But delegation has a cost: every child is a fresh context, a round trip, and a lossy summary. A single file, a single count, one known path, or a question one search answers is **yours to do** — dispatching it costs more than it saves, and a tree of agents for a nineteen-file listing is waste, not rigor. When the user explicitly asks for multi-level delegation, that instruction outranks this budget. Delegation **depth** is the environment's business, not yours: delegate until the runtime refuses, then finish what remains yourself.
-3. Delegate research by default — within that budget. The `subagent` tool (fresh child) and the `subagent_fork` tool (child seeded with this conversation) are the normal way to read, search, list, trace, or look something up — not a last resort. Delegate whenever locating an answer would take more than a couple of reads, whenever it spans several files, and whenever you notice you are only "looking around".
-4. Keep delegations independent and concurrent. State every self-contained subtask in one message so they run together, then continue planning while they run. Wait only when your next action needs a specific result.
-5. Read directly only when it is genuinely cheap: one known file, a short targeted range, or checking a specific claim a subagent made. Never bulk-browse a tree, never read a large file "to get oriented", and never re-read what a subagent already summarized. **Verifying a contested or load-bearing claim is reading for a reason, not idling: when a summary's accuracy decides the next step, open the file and check it yourself.** Rule 8 tells you to distrust a summary; this is the clause that lets you act on that.
-6. Ask for the summary shape you need. Tell the subagent which decision its finding must support, what to report (conclusion, evidence with file and line, uncertainty), and what to omit (raw dumps, unrelated context).
-7. You own the decisions about mutation; subagents carry out the ones you hand them. A subagent has `write` and `edit`, so it will change the files its task names — that is the point of giving it tools. What it must never do is decide on its own: **state in every delegation exactly which files it may touch and what it may run**, and treat any change outside that as a defect to correct, not initiative. Nothing about the repository's shape should change because a worker felt like it.
-8. Treat a summary as evidence, not a verdict. Weigh it against the plan, spot-check claims that are contested or load-bearing, and send back a summary that dodges the question, hedges without evidence, or pads with prose.
-9. **Leave nothing running.** No servers, watchers, daemons, or detached processes — for you as much as for a subagent. Background execution is your shell's decision to offer, not a convenience to reach for: if a task seems to need a long-lived process, do it in the foreground, bound it with a timeout, or ask the user before starting anything that outlives the work.
-10. Answer a subagent that reports a problem or an out-of-scope finding. Decide it, then reply with `send_message` so the child can continue: either the change is approved and who makes it, or it is out of scope and why, or what to do instead. An unanswered report leaves the child blocked on a decision only you can make. **A child that reports a clean result needs no reply** — silence is the correct response, so do not invent an acknowledgement.
-11. 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.
-12. 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.
+2. Decompose heavy work; do not delegate light work. Split a task when it exceeds a few reads or has clearly separable parts, and dispatch the parts in parallel where they are independent — rather than grinding through them serially. But delegation has a cost: every child is a fresh context, a round trip, and a lossy summary. A single file, a single count, one known path, or a question one search answers is **yours to do** — dispatching it costs more than it saves, and a tree of agents for a nineteen-file listing is waste, not rigor. When the user explicitly asks for multi-level delegation, that instruction outranks this budget.
+3. **Mind the live capacity, not just the work.** Delegated children are resident: a slot returns only after a child's turn ends, its inbox is empty, and its own children are gone. A wide fan-out therefore holds every slot until the work actually finishes, and starting more than the environment allows fails outright with a limit error — the batch does not queue. So dispatch a batch you can finish, collect its results before opening the next, and when a delegation is refused for capacity, that is information about your scheduling rather than a reason to retry: use the agents you already have, or finish what is in flight first. Neither the depth limit nor this capacity is yours to change; plan inside them.
+4. Delegate research by default — within that budget. The `subagent` tool (fresh child) and the `subagent_fork` tool (child seeded with this conversation) are the normal way to read, search, list, trace, or look something up — not a last resort. Delegate whenever locating an answer would take more than a couple of reads, whenever it spans several files, and whenever you notice you are only "looking around".
+5. Keep delegations independent and concurrent. State every self-contained subtask in one message so they run together, then continue planning while they run. Wait only when your next action needs a specific result.
+6. Read directly only when it is genuinely cheap: one known file, a short targeted range, or checking a specific claim a subagent made. Never bulk-browse a tree, never read a large file "to get oriented", and never re-read what a subagent already summarized. **Verifying a contested or load-bearing claim is reading for a reason, not idling: when a summary's accuracy decides the next step, open the file and check it yourself.** Rule 9 tells you to distrust a summary; this is the clause that lets you act on that.
+7. Ask for the summary shape you need. Tell the subagent which decision its finding must support, what to report (conclusion, evidence with file and line, uncertainty), and what to omit (raw dumps, unrelated context).
+8. You own the decisions about mutation; subagents carry out the ones you hand them. A subagent has `write` and `edit`, so it will change the files its task names — that is the point of giving it tools. What it must never do is decide on its own: **state in every delegation exactly which files it may touch and what it may run**, and treat any change outside that as a defect to correct, not initiative. Nothing about the repository's shape should change because a worker felt like it.
+9. Treat a summary as evidence, not a verdict. Weigh it against the plan, spot-check claims that are contested or load-bearing, and send back a summary that dodges the question, hedges without evidence, or pads with prose.
+10. **Leave nothing running.** No servers, watchers, daemons, or detached processes — for you as much as for a subagent. Background execution is your shell's decision to offer, not a convenience to reach for: if a task seems to need a long-lived process, do it in the foreground, bound it with a timeout, or ask the user before starting anything that outlives the work.
+11. Answer a subagent that reports a problem or an out-of-scope finding. Decide it, then reply with `send_message` so the child can continue: either the change is approved and who makes it, or it is out of scope and why, or what to do instead. An unanswered report leaves the child blocked on a decision only you can make. **A child that reports a clean result needs no reply** — silence is the correct response, so do not invent an acknowledgement.
+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.
+13. 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.
 
 ## Subagent rules
 

package/release.mjs

@@ -39,7 +39,8 @@ const here = dirname(fileURLToPath(import.meta.url));
 const OFFICIAL_REGISTRY = 'https://registry.npmjs.org/';
 const PROXY = process.env.HTTPS_PROXY ?? process.env.HTTP_PROXY ?? 'http://127.0.0.1:7897';
 const GIT = process.env.DSH_RELEASE_GIT ?? 'git';
-const GH = process.env.DSH_RELEASE_GH ?? 'gh';
+// `gh` is not installed on PATH on this machine; it lives in a standalone extract.
+const GH = process.env.DSH_RELEASE_GH ?? 'D:/Tools/gh/2.102.0/bin/gh.exe';
 const PUBLISHER = process.env.DSH_RELEASE_PUBLISHER ?? (process.platform === 'win32' ? 'pnpm' : 'npm');
 
 const argv = process.argv.slice(2);
@@ -219,6 +220,26 @@ step(`Upgrade the local "${profile}" profile so the machine runs what was publis
 if (dryRun || skipInstall) {
   process.stdout.write('  skipped\n');
 } else {
+  // The profile installs through the CONFIGURED registry, which is a mirror that
+  // lags the official one — so a version that just went live can still answer
+  // "No matching version found" here. That is what made this step fail after the
+  // 1.1.4 release, with nothing wrong on the npm side. Wait for the mirror, then
+  // name the official registry anyway so the install works either way.
+  const mirror = process.env.DSH_RELEASE_MIRROR ?? 'https://registry.npmmirror.com/';
+  const probeMirror = () =>
+    spawnSync('curl', ['-s', '-o', '/dev/null', '-w', '%{http_code}', '-m', '20', '-x', PROXY, `${mirror}${manifest.name}/${version}`], {
+      encoding: 'utf8',
+    }).stdout?.trim();
+  let mirrored = false;
+  for (let attempt = 1; attempt <= 30 && !mirrored; attempt += 1) {
+    mirrored = probeMirror() === '200';
+    if (!mirrored) {
+      if (attempt === 1) process.stdout.write(`  waiting for ${mirror} to mirror ${version}…\n`);
+      await new Promise((resolve) => setTimeout(resolve, 20_000));
+    }
+  }
+  process.stdout.write(mirrored ? `  ${mirror} has it\n` : `  ${mirror} still lacks it; using the official registry\n`);
+
   // `dsh` is a shell shim on Windows too, so it is invoked through Node rather
   // than spawned directly. DSH_RELEASE_DSH overrides the entry point.
   const dshEntry = process.env.DSH_RELEASE_DSH ?? 'D:/nodejs/npm_global/node_modules/@deepseek-ai/dsh/lib/bin.js';

package/tools/inspect-preset-events.mjs

@@ -0,0 +1,85 @@
+// Reports the preset-related events in one session log — the durable evidence of
+// which preset a session was composed with, and whether a selection was attempted.
+//
+// Usage: node tools/inspect-preset-events.mjs <session-dir>
+
+import { readFileSync } from 'node:fs';
+import { join } from 'node:path';
+import { createZstdDecompress } from 'node:zlib';
+
+/** Locate the end of the first zstd frame, where the next one begins. */
+function firstFrameEnd(buf) {
+  for (let i = 4; i + 4 <= buf.length; i += 1) {
+    if (buf[i] === 0x28 && buf[i + 1] === 0xb5 && buf[i + 2] === 0x2f && buf[i + 3] === 0xfd) return i;
+  }
+  return buf.length;
+}
+
+/** Decompress a concatenated-zstd log frame by frame. */
+async function decompressAll(buf) {
+  let rest = buf;
+  let text = '';
+  while (rest.length > 0) {
+    const slice = rest.subarray(0, firstFrameEnd(rest));
+    try {
+      text += await new Promise((resolve, reject) => {
+        const chunks = [];
+        const dec = createZstdDecompress();
+        dec.on('data', (chunk) => chunks.push(chunk));
+        dec.on('error', reject);
+        dec.on('end', () => resolve(Buffer.concat(chunks).toString('utf8')));
+        dec.end(slice);
+      });
+    } catch {
+      break;
+    }
+    if (slice.length >= rest.length) break;
+    rest = rest.subarray(slice.length);
+  }
+  return text;
+}
+
+const dir = process.argv[2];
+if (dir === undefined) {
+  process.stderr.write('usage: node tools/inspect-preset-events.mjs <session-dir>\n');
+  process.exit(2);
+}
+
+const text = await decompressAll(readFileSync(join(dir, 'session.v4.jsonl.zstd')));
+const events = text
+  .split('\n')
+  .filter((line) => line.trim().length > 0)
+  .flatMap((line) => {
+    try {
+      return [JSON.parse(line)];
+    } catch {
+      return [];
+    }
+  });
+
+process.stdout.write(`${events.length} events, ${text.length} chars\n\n`);
+
+const header = events[0];
+process.stdout.write(`header: id=${header?.id}\n  agentPreset=${header?.agentPreset}\n  origin=${header?.origin} depth=${header?.delegationDepth}\n`);
+
+process.stdout.write('\npreset-related events:\n');
+let found = 0;
+for (const event of events) {
+  const type = String(event.type ?? '');
+  if (!/preset/i.test(type)) continue;
+  found += 1;
+  process.stdout.write(`  #${events.indexOf(event)} ${type} ${JSON.stringify(event.data ?? event).slice(0, 220)}\n`);
+}
+if (found === 0) process.stdout.write('  (none — no agent-preset/selected event was ever appended)\n');
+
+process.stdout.write('\nuser messages (first 3):\n');
+let users = 0;
+for (const event of events) {
+  const content = event.data?.message?.content ?? event.message?.content;
+  const role = event.data?.message?.role ?? event.message?.role;
+  if (role !== 'user' || typeof content !== 'string') continue;
+  users += 1;
+  if (users > 3) break;
+  process.stdout.write(`  #${events.indexOf(event)} ${JSON.stringify(content.slice(0, 160))}\n`);
+}
+if (users === 0) process.stdout.write('  (no user messages recorded yet)\n');

package/tools/verify-session.mjs

@@ -58,7 +58,7 @@ async function decompressAll(buf) {
   return text;
 }
 
-/** Read one session directory into {header, events}. */
+/** Read one session directory into {header, events, text}. */
 async function readSession(dir) {
   const text = await decompressAll(readFileSync(join(dir, 'session.v4.jsonl.zstd')));
   const events = text
@@ -71,9 +71,17 @@ async function readSession(dir) {
         return [];
       }
     });
-  return { header: events[0], events };
+  return { header: events[0], events, text };
 }
 
+/**
+ * A phrase only this preset's persona contains, so finding it in a session proves
+ * that session was composed with root-planner. Chosen against the alternative of
+ * matching "You are a delegated subagent", which DSH injects into EVERY subagent's
+ * runtime context and therefore proves nothing.
+ */
+const PERSONA_MARKER = 'the same rules govern every node';
+
 const argv = process.argv.slice(2);
 const quiet = argv.includes('--quiet');
 const expectDepthIndex = argv.indexOf('--expect-depth');
@@ -139,11 +147,48 @@ const check = (ok, label) => {
 
 if (!quiet) process.stdout.write(`root session: ${root.header?.id}\n`);
 
+/**
+ * Which preset a session is ACTUALLY running.
+ *
+ * The session header's `agentPreset` is written when the session is created, with
+ * the default preset, and the client then switches preset through
+ * `agentPresets.select()` — which appends an `agent-preset/selected` event and
+ * recomposes the agent, but never rewrites the header. Judging a run by the header
+ * reports "standard" for a session that is genuinely running something else, and
+ * this tool made exactly that mistake twice before the prompt text settled it.
+ *
+ * Identity is therefore taken from the strongest available evidence, in order:
+ *   1. this preset's persona prose appearing in the session's own content — only a
+ *      session composed with root-planner can contain it;
+ *   2. the recorded `agent-preset/selected` event;
+ *   3. the header, which is the creation default and the weakest of the three.
+ * @param session - one read session.
+ * @returns the resolved preset id and what it was resolved from.
+ */
+function resolvePreset(session) {
+  if ((session.text ?? '').includes(PERSONA_MARKER)) {
+    return { preset: 'root-planner', evidence: 'persona text in the session' };
+  }
+  for (const event of session.events) {
+    if (event.type === 'agent-preset/selected' && typeof event.data?.agentPreset === 'string') {
+      return { preset: event.data.agentPreset, evidence: 'agent-preset/selected event' };
+    }
+  }
+  return { preset: session.header?.agentPreset, evidence: 'session header (creation default)' };
+}
+
+const rootPreset = resolvePreset(root);
 check(
-  root.header?.agentPreset === 'root-planner',
-  `root session is composed with root-planner (found "${root.header?.agentPreset ?? '?'}") — if this fails, the run proves nothing about the preset`,
+  rootPreset.preset === 'root-planner',
+  `root session runs root-planner (found "${rootPreset.preset}" via ${rootPreset.evidence})`,
 );
 check(root.header?.delegationDepth === 0, `root is at depth 0 (found ${root.header?.delegationDepth})`);
+if (!quiet && root.header?.agentPreset !== rootPreset.preset) {
+  process.stdout.write(
+    `note: the header says "${root.header?.agentPreset}" while the session runs "${rootPreset.preset}" ` +
+      `(${rootPreset.evidence}) — the header is the creation default, not the running preset\n`,
+  );
+}
 
 const children = sessions.filter((session) => session.header?.parentSession === root.header?.id);
 const byId = new Map(sessions.map((session) => [session.header?.id, session]));
@@ -160,8 +205,9 @@ const depthOf = (session) => {
 if (!quiet) {
   process.stdout.write(`\n${sessions.length} session(s) total:\n`);
   for (const session of sessions) {
+    const preset = resolvePreset(session);
     process.stdout.write(
-      `  ${String(session.header?.id).slice(0, 20)}  preset=${String(session.header?.agentPreset).padEnd(14)} ` +
+      `  ${String(session.header?.id).slice(0, 20)}  preset=${String(preset.preset).padEnd(14)} ` +
         `depth=${depthOf(session)}  parent=${String(session.header?.parentSession ?? '(root)').slice(0, 20)}\n`,
     );
   }
@@ -173,9 +219,10 @@ check(descendants.length > 0, 'the root actually delegated (at least one child s
 
 for (const session of descendants) {
   const depth = depthOf(session);
+  const preset = resolvePreset(session);
   check(
-    session.header?.agentPreset === 'root-planner',
-    `child ${String(session.header?.id).slice(0, 8)} at depth ${depth} inherits root-planner (found "${session.header?.agentPreset ?? '?'}")`,
+    preset.preset === 'root-planner',
+    `child ${String(session.header?.id).slice(0, 8)} at depth ${depth} runs root-planner (found "${preset.preset}" via ${preset.evidence})`,
   );
 }