Host setting subagent.maxDepth is not enforced on delegation paths that call SubagentRuntime directly (workflow / spawn_teammate / ralph)

[ruoqidezhishi]

Summary

The host-level subagent.maxDepth setting (Settings → Plugins → Subagent; default 1, described as "Only the main Agent can create Subagents") is applied only by dsh-tool-subagent instances, which copy it into each request they create. SubagentRuntime.start() / startContinuable() never consult the host setting themselves, and resolveChildDepth(parent, maxDepth) passes the derived depth through unchanged whenever maxDepth === undefined.

As a result, first-party delegation paths that call the runtime directly bypass the cap completely:

Path	Call site	Passes maxDepth?
dsh-tool-subagent (subagent, subagent_fork)	resolveMaxDepth(config.maxDepth) → request.maxDepth	yes
dsh-workflow-ptc (workflow)	lib/index.js startChild() → this.subagents.start(provider, {...})	no
dsh-experimental-agent-team (spawn_teammate)	startContinuable({ childId, provider, label, request: { prompt, parent } })	no
dsh-tool-ralph	ctx.workflowEngine.start()	no

maxActiveSubagents does not cover them either: workflow uses the one-shot start() path, and every assertAdmitting / pool.reserve / holdOwnership call site sits inside the continuable machinery (dsh-subagent/lib/index.js L856–1929) while the one-shot start() is at L3216 — so those children are outside both limits.

Reproduction (real dispatch, not static analysis)

Isolated DSH_HOME (hard-linked .credentials.yaml + junction to profiles/node_modules) with a one-shot profile composed of @deepseek-ai/dsh-base + @deepseek-ai/dsh-headless, and settings.yaml:

subagent:
  maxDepth: 1

The main agent (depth 0) delegates one child via subagent with run_in_background: false. That child (depth 1) then attempts both channels in the same turn. Raw returns:

Channel	Raw return
subagent (depth 1 → 2)	Error: subagent depth 2 exceeds maxDepth 1
workflow (depth 1 → 2)	workflow "reply-grandchild-alive" completed (1 agent). + Return value: "GRANDCHILD_ALIVE"

The workflow script used:

const r = await agent("只回复 GRANDCHILD_ALIVE");
return r;

So within one and the same child agent, the ordinary path is correctly refused (depth 2 > maxDepth 1), while the workflow path creates and runs a depth-2 agent. The refusal message also confirms the depth check itself works and that the child truly is at depth 1 — the two results are directly comparable.

Why this reads as unintended

• The plugin settings help text promises a global recursion policy: "限制 Agent 创建 Subagent 的递归层级 / Limits how many levels of Subagents an Agent can create", with 1 = "仅允许主 Agent 创建 Subagent / Only the main Agent can create Subagents".
• docs/subsystems/subagent.zh.md titles the section "深度是绝对的树上限" (depth is an absolute tree cap).
• .agents/notes/implemented/feature/2026-07-12-subagent-persona-tool-filter-and-depth.zh.md states that dsh-tool-subagent copies these controls into every request it creates, and that callers invoking SubagentRuntime directly choose them per request. So the per-request plumbing is by design — but that leaves a shipped first-party tool silently outside a setting the UI presents as global.

Either behavior alone would be fine; the combination is the surprise. It also matters for cost: unbounded workflow fan-out is precisely the expensive shape (in our own session logs, L2+L3 delegation accounted for ~72% of tokens).

Possible fixes (any one would resolve the mismatch)

1. Apply it at the service level — in SubagentRuntime.start() / startContinuable(), fall back to settingsSource().maxDepth when request.maxDepth is undefined (an explicit per-request value still wins). This makes the host setting a real floor for every delegation channel, including third-party plugins, and matches the "absolute tree cap" wording.
2. Thread it through the first-party callers — dsh-workflow-ptc.startChild(), dsh-experimental-agent-team's spawn_teammate, and the ralph path.
3. Or scope the promise — if workflow is intentionally exempt, say so in the settings help text and document it in the subagent subsystem page.

Option 1 looks smallest and closest to the documented intent; option 3 at minimum removes the mismatch.

Environment

• dsh 0.1.6-alpha.2, Windows (also installed on WSL at the same version), node v24.19.0
• The cap was verified to be active in the same run (the subagent branch was refused), so this is not a misconfiguration of the test.

Happy to run further repros or test a patch.

---

中文版（同上内容）

概要

宿主级设置 subagent.maxDepth（设置 → 插件 → Subagent，默认 1，文案为「仅允许主 Agent 创建 Subagent」）只由 dsh-tool-subagent 实例施加 —— 它把该值复制进自己创建的每个请求。SubagentRuntime.start() / startContinuable() 自身从不读宿主设置，而 resolveChildDepth(parent, maxDepth) 在 maxDepth === undefined 时直接放行推导出的深度。

因此，直接调用 runtime 的一等公民派发通道完全绕过该上限：workflow（dsh-workflow-ptc.startChild() 不传 maxDepth）、spawn_teammate（dsh-experimental-agent-team 不传）、ralph（走 workflowEngine）。

maxActiveSubagents 也管不到它们：workflow 走一次性 start()，而 assertAdmitting / pool.reserve / holdOwnership 全部位于 continuable 机制内（dsh-subagent/lib/index.js L856–1929），一次性 start() 在 L3216 —— 两道上限都不覆盖。

复现（真派发，非静态分析）

隔离 DSH_HOME + @deepseek-ai/dsh-base + @deepseek-ai/dsh-headless 一次性 profile，settings.yaml 写 subagent.maxDepth: 1。主 agent（depth 0）派一个子 agent，该子 agent（depth 1）在同一轮里分别走两条通道：

通道	原始返回
subagent（depth 1 → 2）	Error: subagent depth 2 exceeds maxDepth 1
workflow（depth 1 → 2）	workflow "reply-grandchild-alive" completed (1 agent). + Return value: "GRANDCHILD_ALIVE"

同一个子 agent 内，普通通道被正确拒绝，workflow 通道却建成并跑完了一个 depth-2 的 agent；而拒绝消息本身反证了深度校验有效、该子确在 depth 1，两个结果可直接对照。

为什么像是无意的

• 插件设置帮助文案承诺的是全局递归策略：「限制 Agent 创建 Subagent 的递归层级」。
• docs/subsystems/subagent.zh.md 该节标题为「深度是绝对的树上限」。
• 而设计说明写明 dsh-tool-subagent 把这些控制复制进它创建的每个请求、直调 SubagentRuntime 的调用方按请求选择 —— 逐请求机制是有意设计，但这让一个已交付的一等公民工具静默地落在用户读作"全局"的设置之外。

可选修法（任一即可消除不一致）

1. 服务层兜底：start() / startContinuable() 在 request.maxDepth 为 undefined 时回落到 settingsSource().maxDepth（显式按请求给出的值仍优先）。最小改动，且与「绝对的树上限」表述一致，对第三方插件同样生效。
2. 打通一等公民调用方：dsh-workflow-ptc.startChild()、spawn_teammate、ralph 路径。
3. 收窄承诺：若 workflow 有意豁免，请在设置帮助文案与 subagent 子系统文档中写明。

环境

dsh 0.1.6-alpha.2（Windows；WSL 同为该版本），node v24.19.0。同一次运行内普通通道被拒 ⇒ 排除"测试配置写错"。

[argszero]

Confirmed from source, with the exact bypass call sites, the fix seam that already exists, and — more usefully — the two ways the obvious one-line fix breaks working configurations.

The bypass, located. maxDepth does not appear anywhere under packages/workflow/, packages/experimental/agent-team/, or packages/tool-ralph/, so the three paths you list all funnel through two call sites:

• workflow-ptc — workflow-ptc/src/host.ts:200: this.subagents.start(this.provider, { prompt, parent, signal, …outputSchema, …agentOptions }) — no maxDepth. tool-ralph reaches the same site through ctx.workflowEngine.start().
• agent-team — agent-team/src/roster.ts:282: this.ctx.subagents.startContinuable({ childId, provider, label, request: { prompt, parent }, signal }) — no maxDepth.

One precision on the capacity half. Your table is right about workflow/ralph (they use the one-shot start()), but agent-team goes through startContinuable(), and that path does call this.activations.assertAdmitting(parent) (continuation.ts:108) before anything else. So team members are counted against maxActiveSubagents; what they escape is maxDepth only. The three paths are not uniform in which limit they miss.

The seam already exists and the runtime never calls it. SubagentRuntime.resolveMaxDepth() is precisely the resolver this needs:

// subagent/src/index.ts:248-251
resolveMaxDepth(configured?: number | 'provider-managed'): number | undefined {
  if (configured === 'provider-managed') return undefined
  return configured ?? (this.settingsSource() as Required<Config>).maxDepth
}

Its only production callers are inside tool-subagent (:330 capability guard, :515 request construction). The runtime's own start paths do not consult it: start() calls only assertSubagentMaxDepth(request.maxDepth) (:594), and the continuable path does the same (continuation.ts:109). That is why the setting is enforced exactly where one package happens to have wired it up.

Which is also the argument for fixing it in the runtime rather than in each caller: defaulting at the two start paths covers all four delegation paths at once, and the three bypassing packages need no change at all. SubagentRuntime owns Config and already owns settingsSource(), so it is the one place that can honour its own setting.

But request.maxDepth ?? this.resolveMaxDepth() is not that fix — it breaks two things that work today.

1. 'provider-managed' does not survive the boundary. tool-subagent:523 builds the request as ...maxDepth !== undefined ? { maxDepth } : {}. When the tool is configured with 'provider-managed', resolveMaxDepth() returns undefined and the key is omitted entirely — so at the runtime, "the provider owns this" and "the caller said nothing" are the same value. A runtime that reads undefined as unspecified will hand the host cap to the external providers the sentinel exists to exempt.
2. It trips the capability gate. assertCapabilities (index.ts:680) contains { when: request.maxDepth !== undefined, cap: 'depthLimit' }, and start() calls it before anything else (:593). Injecting a number therefore makes every provider without depthLimit throw UNSUPPORTED_CAPABILITY — and the external providers are exactly those (claude-code / acp / codex / sdk). The "fix" would turn three paths that silently ignore a setting into every external delegation failing at start-up. tool-subagent:330-332 exists to catch this at mount time, with the same advice it gives users: set maxDepth: 'provider-managed' to leave the recursion budget to the provider.

So the numeric default cannot be applied unconditionally. Two shapes work: (a) default only when the resolved provider declares the depthLimit capability, or (b) let the sentinel survive the boundary — allow 'provider-managed' in the request type and have the runtime honour it per-provider, so "provider-owned" is distinguishable from "unspecified". Either keeps the four paths under one policy without converting a silent bypass into a hard failure.

Not mountable as a plugin — the seam is closed on the read side too. Worth stating so it does not read as an unexplored option:

• All four subagent/* events are @mode emit (subagent/src/index.ts:143-173) — there is no waterfall, so nothing can intercept a start.
• subagent/start is published after the child exists (lifecycle.ts:161, :198), so a listener can observe a depth-2 child but cannot refuse it.
• A provider cannot be shadowed: registration is by unique name and a repeat fails the runtime invariant (invariant.ts:32-36), and SubagentRuntime.providers is a private Map (:204).

So the enforcement has to live in SubagentRuntime itself; a plugin could at most report an over-depth child after the fact.

[ruoqidezhishi]

Verified all of it against the tree. Every line reference checks out — host.ts:200, roster.ts:282, index.ts:248-251 / :204 / :593-594 / :680, tool-subagent:330 / :515 / :523, lifecycle.ts:161 / :198 — with one off-by-one: assertAdmitting is continuation.ts:**107**, not :108 (:108 is requirePersistence).

Both corrections accepted:

Not uniform in which limit they miss. I scoped maxActiveSubagents to workflow in the prose but then grouped the three loosely in the summary. Concretely: workflow and ralph enter at index.ts:591 (start()) and miss both limits; agent-team enters at continuation.ts:104 and hits assertAdmitting on the first line, so team members do consume a slot and escape maxDepth only.

The fix seam. resolveMaxDepth is exactly it, and the asymmetry you point at is the whole story: start() at :591 calls assertSubagentMaxDepth at :594 and never the resolver, so enforcement exists only where tool-subagent happened to wire it up. Fixing it in the runtime covers all four paths and asks nothing of the three bypassing packages — agreed that's the right seam.

Your two objections to request.maxDepth ?? this.resolveMaxDepth() are both real, and I can add the mechanism for each:

1. Sentinel collapse. resolveMaxDepth('provider-managed') returns undefined (:249), and tool-subagent:523 spreads ...maxDepth !== undefined ? { maxDepth } : {} — so at the boundary "provider-owned" and "caller said nothing" are literally the same value, and the runtime cannot tell them apart.
2. Capability gate. assertCapabilities (:676-690) runs at :593, ahead of assertSubagentMaxDepth at :594, and :680 demands depthLimit whenever request.maxDepth !== undefined. NO_START_CAPABILITIES (out-of-process.ts:57, with depthLimit: false at :60) is false by design, and its own comment (:52-55) states the contract — a child in another process cannot honour parent-enforced start features, so the service rejects a request needing any of them before start runs, "never accepted-then-ignored". Injecting a number would therefore convert a silent bypass into UNSUPPORTED_CAPABILITY for precisely the providers the sentinel exists to exempt. That is a fair hit on my option 1 as written.

One detail that falls out of shape (b) and I think is worth pinning down: widening the request field alone is not enough. If 'provider-managed' is allowed to survive to the runtime, :680's predicate has to become a numeric check (typeof request.maxDepth === 'number') — as written, !== undefined makes carrying the sentinel trip the very gate it exists to avoid. So (b) is two edits: widen SubagentStartRequest.maxDepth, and narrow :680.

Combining (a) and (b) is what I would now propose, after expectProvider(name) in both start paths:

const maxDepth = request.maxDepth === 'provider-managed'
  ? undefined
  : request.maxDepth
    ?? (provider.capabilities.depthLimit
      ? (this.settingsSource() as Required<Config>).maxDepth
      : undefined)

The numeric default is only ever applied where the provider can enforce it; the sentinel stays distinguishable from "unspecified"; the capability gate keeps its meaning ("the caller asked for something this provider cannot do"); and the three bypassing packages need no change. One behaviour change worth stating plainly: an unspecified maxDepth on a depthLimit-capable provider would now mean the host setting — the intended semantics, but a change for anyone relying on the current bypass.

Also agreed that the plugin route is closed — worth having on record so it does not get re-opened: all four subagent/* events are @mode emit (no waterfall, hence no interception point), subagent/start is emitted from callbacks that already hold the child (lifecycle.ts:161, :198), and providers cannot be shadowed (:204 private map; registerProvider throwing DUPLICATE_PROVIDER). At most a plugin could report an over-depth child after the fact.

Thanks for reading it against the source rather than just the report.

[ruoqidezhishi]

Correction to my previous comment. I checked the two claims against the tree instead of reasoning from the predicate alone, and I got the edit count wrong.

I wrote that shape (b) is "two edits". It is at least three, and the one I missed is the load-bearing one on the continuable path.

What holds: :680's predicate is request.maxDepth !== undefined, so carrying the sentinel does demand depthLimit at the gate. But assertCapabilities has exactly one call site — index.ts:593, inside start(). SubagentRuntime.startContinuable (index.ts:262-264) is a one-line delegation to continuation.ts:104, which never calls it.

What I missed: assertSubagentMaxDepth rejects the sentinel outright. Called on the real exported function:

assertSubagentMaxDepth('provider-managed')
  -> TypeError: subagent maxDepth must be a non-negative safe integer

and it guards both entry points — index.ts:594 (one-shot) and continuation.ts:109 (continuable). So on the continuable path the sentinel's only obstacle is that assertion, not the capability gate; and on the one-shot path, narrowing :680 alone still leaves :594 throwing immediately after. The "two edits" I proposed would not have worked.

Shape (b) is therefore:

1. widen SubagentStartRequest.maxDepth to number | 'provider-managed' and carry the sentinel through tool-subagent:515-523 instead of collapsing it into key-omission;
2. narrow :680 to a numeric check (typeof request.maxDepth === 'number') — otherwise the sentinel demands depthLimit at the gate;
3. relax assertSubagentMaxDepth to admit the sentinel — otherwise it throws at :594 and at continuation.ts:109.

One further observation, flagged as un-chased rather than asserted: because assertCapabilities has a single call site inside start(), the continuable path appears to run no capability gate at all, so agentOptions / toolFilter / persona carried into startContinuable are not checked against provider.capabilities there. I have not verified whether a later layer compensates, so I am not claiming a defect — only that the gate you would expect at that boundary is not on that path. Worth someone closer to that code confirming either way.

Net effect on the proposal: this makes the capability-gated default the safer half. It needs no type widening and no assertion change — it only ever injects a number, and only where depthLimit is true — so it closes all four delegation paths without touching the sentinel contract.

[ruoqidezhishi]

Correction #2 — this time over the report itself. Two independent verification passes went over this thread: one over the fix analysis, one over the report against the full master tree (commit ddefc45). The first found the edit count was still wrong; the second found several things wrong with the report. Both passes' findings are reproduced below only after I re-derived them myself.

The core finding stands. The bypass was independently reproduced from scratch in a fresh isolated DSH_HOME: the same depth-1 child returns Error: subagent depth 2 exceeds maxDepth 1 on subagent, and workflow "..." completed (1 agent). + Return value: "GRANDCHILD_ALIVE" on workflow. (The "..." is a placeholder — the workflow name is chosen by the model.)

What was wrong in the report.

1. A citation points at the wrong file, and the file it points at actually agrees with the implementation. I attributed the heading "深度是绝对的树上限" to docs/subsystems/subagent.zh.md. It is not there — it is an H3 in the 2026-07-12 Agent Note (…-subagent-persona-tool-filter-and-depth.zh.md:52). Worse, the passage I should have quoted is the docs page's own (subagent.zh.md:467): a start is rejected when the derived depth exceeds the 已定义 absolute request.maxDepth 上限 — per-request, which is exactly what the code does. So that leg of the "documentation promises more than the code delivers" argument was wrong.

2. The design note was read backwards. The note is the document that documents this gap, not one that contradicts the behavior. Its English version says it plainly (.md:90): encoding the cap as a creation-time tool filter "does not protect direct service callers or alternate delegation tools". The zh line I quoted (:25) sits in the same paragraph that says direct callers choose these controls per request. Citing it as evidence of inconsistency had the sign flipped; it is evidence the gap was anticipated.

3. The settings quote was cherry-picked. I quoted subagentDepthHelp ("限制 Agent 创建 Subagent 的递归层级"). The same card also carries subagentDepthOverride: "如果某个工具单独设置了最大递归深度，以该工具的设置为准" — i.e. the UI does say a tool-level setting wins. That does not close the gap, but quoting only the first line overstated it.

Precisions.

• The setting is held and resolved by SubagentRuntime itself (Config.maxDepth, default 1). "The runtime never reads the setting" is true of start() and startContinuable() — it is not true of the class.
• With maxDepth: 'provider-managed', the field is omitted from the request, not copied into it. "Copies it into every request" needed that qualifier.
• maxActiveSubagents is enforced by pool.reserve (continuation-activation.ts:489), which is the only capacity gate; assertAdmitting is a separate gate for draining. Listing them together as "the count limit" was loose, even though the conclusion (both live inside the continuable machinery) holds.
• On reachability: workflow-ptc is a stable base row, so workflow is live in any default deployment. agent-team ships only as an experimental profile and is absent from the stable bundles — however, the machine this report came from explicitly mounts agent-team-profile + agent-team-web-profile, so both bypasses were live there.
• The bypass is unbounded, not "one level deeper": the depth-2 child still holds workflow, and resolveChildDepth applies no cap at all when maxDepth is undefined. The capacity pool is the only asymptotic bound, and one-shot runs sit outside that too.
• Footnote, not a delegation channel: the user-facing /fork command (session-controller/src/commands.ts:258-272) creates a child session with parentSession via agents.create with no depth check, and that child's depth is 0. There is no model-facing tool for it, so I am not counting it — noting it only for completeness.

Superseding the fix analysis in my previous comment. The edit list there was still incomplete:

• assertSubagentMaxDepth is called at index.ts:215, :219, :594, continuation.ts:109, and tool-subagent/src/index.ts:317 — which, note, already special-cases the sentinel with if (config.maxDepth !== 'provider-managed'). There is one more in a different package: dsh-subagent-in-process-driver/lib/index.js:162, and that is the path both spawn and fork take. So the relaxation has to go in the shared function; written as guards at the two request-path sites, the driver still throws.
• A compile break blocks the whole thing. Widening SubagentStartRequest.maxDepth does not merely need :680 narrowed — it does not build. resolveChildDepth is declared (parent: Agent, maxDepth: number | undefined): number (child-agent.d.ts:31) and is called with request.maxDepth at continuation.ts:112 and dsh-subagent-in-process-driver:165:
  error TS2345: Argument of type 'number | "provider-managed" | undefined' is not assignable to parameter of type 'number | undefined'.
  The same file narrowed back to number compiles clean.
• A trap that depends on how step 1 is written. tool-subagent's mount-time guard is if (ctx.subagents.resolveMaxDepth(config.maxDepth) !== undefined && !subagentProvider.capabilities.depthLimit) throw …. The sentinel makes resolveMaxDepth return undefined, so it passes today. Implement step 1 by making resolveMaxDepth pass the sentinel through, and that guard flips to true and rejects — at mount time — exactly the no-depthLimit providers the sentinel exists for.
• What the sentinel would mean afterwards. resolveChildDepth tests childDepth > maxDepth; with the sentinel that is 2 > 'provider-managed', which is false in JS. So once the assertion is relaxed, maxDepth: 'provider-managed' becomes silently unlimited rather than "enforced by the provider". Measured with a proper parent stub at depth 1: maxDepth: 1 → SubagentDepthError; maxDepth: 'provider-managed' → returns 2, no error. That needs an explicit decision rather than relying on a string comparison that happens to be false.
• Reachability, so this is not over-prioritized. The only rows in the shipped compositions that set maxDepth: 'provider-managed' are tool-subagent-codex and tool-subagent-claude-code, both disabled: true, and no codex / claude-code subagent provider package exists. So the sentinel has zero reachable callers today, and the capability-gated numeric default remains the change with actual effect — needing none of the edits above.

One upstream doc bug found along the way. The 2026-07-12 note (:58) states that the loader-parsed dsh-tool-subagent configuration "默认值为 3". It does not: tool-subagent/src/index.ts:130 declares no default, omission falls back to the host setting (currently 1), and the base bundle sets no maxDepth on its tool-subagent rows either. The note's "3" no longer matches the code and is worth correcting there.

Thanks for the patience — and apologies for the churn. The first comment in this thread got the edit count wrong; this is the second pass over my own text, and both errors were mine rather than yours.

[argszero]

Thanks — I re-derived each of your four claims at ddefc45 (the same tree you used) and they hold. Two of them correct my analysis, so let me consolidate rather than restate.

Where my analysis was incomplete (your point 1). I gave the assertion inventory as four request-path sites and concluded "fix it in the runtime and all four are covered at once". The conclusion survives; the inventory did not. assertSubagentMaxDepth is a single exported function (packages/subagent/subagent/src/depth.ts:42), called at:

• subagent/src/index.ts:215 (mount-time config check) and :219 (the on-change validate callback),
• subagent/src/index.ts:594 (the start() path),
• subagent/src/continuation.ts:109,
• tool-subagent/src/index.ts:317 (your sentinel special case — if (config.maxDepth !== 'provider-managed')),
• subagent-in-process-driver/src/index.ts:108 — the one I missed. Your lib/index.js:162 is its built form; the source line is :108, immediately above :111's resolveChildDepth(parent, request.maxDepth).

So the inventory is six, and one is outside packages/subagent/subagent/. That matters for exactly the reason you give: a relaxation written as guards at the two request-path sites leaves the driver throwing.

The good news your finding implies. Because all six go through one function, there is exactly one home for the relaxation — and it is the same edit that resolves your mount-time-guard trap. depth.ts:42 is typed (maxDepth: unknown) and its whole contract is "a cap that can represent an exact delegation depth" (typeof maxDepth !== 'number' ⇒ TypeError). Teach that function the sentinel as "no numeric cap" and :215/:219/:317 all keep working unchanged — with :317's special case becoming redundant belt-and-braces — instead of flipping to a mount-time rejection.

Your compile break is real, and it has one choke point. resolveChildDepth is declared (parent: Agent, maxDepth: number | undefined): number at child-agent.ts:50, and both call sites you cite pass request.maxDepth straight through (continuation.ts:112, subagent-in-process-driver/src/index.ts:111). That is a single shared declaration rather than two guards, so widening it in the same edit unblocks both — the TS2345 is a cost of the change, not a second defect.

The sentinel semantics (your point 4) — agreed, and it is worse than a string comparison. child-agent.ts:50 body: if (maxDepth !== undefined && childDepth > maxDepth). With the sentinel that is 2 > 'provider-managed' ⇒ false, while the guard's first clause is already satisfied, so nothing throws: silently unlimited, exactly as you measured. Since resolveChildDepth also returns the depth its callers use, the sentinel cannot flow into it without changing its contract — so the honest shape is to branch on the sentinel before the call (sentinel ⇒ the provider owns the bound), rather than to depend on an ordering that happens to fall through.

Your assertAdmitting correction is right, and my wording was loose. I had written that agent-team "does count against maxActiveSubagents" because startContinuable() calls assertAdmitting. In fact assertAdmitting (continuation-activation.ts:446-452) is a draining/admission gate, while the capacity gate is pool.reserve(this.maxActiveSubagents()) at :489, throwing ACTIVATION_LIMIT_REACHED. They are sequential inside materialize() (:485, then :489) but distinct. The conclusion — capacity lives inside the continuable machinery, not on the direct start() path — stands; the attribution did not.

Your report corrections (the Agent Note citation, the sign-flipped design note, the subagentDepthOverride line in the same settings card) I take at face value: they read like they make the thread more actionable for a maintainer, which is the point.