@dipoleml/dcode-cli 1.0.0 → 1.2.0

package/node_modules/@dcode/shared/dist/dcode-protocol-v4/workflow-runs-actor-session.js

@@ -0,0 +1,44 @@
+// ============================================================
+// actor 的 `sessionId`：持有这个子代理转录的那条会话（workflowRuns 归约的一条规则）
+// ============================================================
+// 住在归约主文件之外，与 workflow-runs-actor-status.ts 同一个理由（主文件的 max-lines 门），
+// 也同一条纪律：纯函数、无时钟、无 I/O。
+//
+// 为什么 sessionId 会动（docs/dynamic-workflow/presentation.md「Subagent transcripts」）：
+// `actor-created` 给的是 run service 为本 run 铸的会话，而修订 run 里一个答案全部来自导入命中的
+// 子代理从没建过这条会话——命中不建会话，那些交换只活在前驱的会话里。transcript 面板照
+// `sessionId` 订阅，指向一条不存在的会话就只剩 error + retry；所以这个字段要跟着「转录此刻
+// 在哪」走，而不是停在铸出来的那个 id 上。
+import { boundedSessionId } from "./workflow-runs-entries.js";
+/**
+ * 一条节点事件之后，它点名的子代理的 actor 表（没变即原引用）。
+ *
+ * 只有两种 ask 事件说「这个子代理的转录在哪条会话里」：
+ *   - **缓存命中的结算**：载荷带 `sourceSessionId` 即答案读自前驱的那条会话（导入命中，或修订
+ *     run resume 时对一条导入行的重放）；不带即答案在本 run 里产生过，信封上的 `actorSessionId`
+ *     （本 run 的会话）就是它；
+ *   - **派发**：子代理开始 live 跑，本 run 的会话此刻已经建好——导入过前缀的已经播了种。
+ *
+ * 最后一条说了算。同一个子代理的 ask 按序结算，而导入分歧是单调的：导入命中在前、指向前驱的
+ * 会话；从第一次 live 派发起，本 run 的会话持有全部，抄进来的前缀也在里面。其余事件、没有
+ * actor ref 的事件（world-read）、两个 id 都读不出的老载荷、以及不在表上的子代理：一律不动。
+ */
+export function actorsWithTranscriptSession(actors, eventType, payload, actorRef, envelopeSessionId) {
+    if (actorRef === null)
+        return actors;
+    const sessionId = eventType === "node-settled" && payload.cached === true
+        ? (boundedSessionId(payload.sourceSessionId) ?? boundedSessionId(envelopeSessionId))
+        : eventType === "node-dispatched"
+            ? boundedSessionId(envelopeSessionId)
+            : undefined;
+    if (sessionId === undefined)
+        return actors;
+    const index = actors.findIndex((actor) => actor.siteId === actorRef.siteId && actor.ordinal === actorRef.ordinal);
+    // 没变的保持引用：键级增量按引用先判「这条变了吗」（workflow-runs-delta.ts）。
+    if (index < 0 || actors[index].sessionId === sessionId)
+        return actors;
+    const next = actors.slice();
+    next[index] = { ...actors[index], sessionId };
+    return next;
+}
+//# sourceMappingURL=workflow-runs-actor-session.js.map

package/node_modules/@dcode/shared/dist/dcode-protocol-v4/workflow-runs-actor-status.d.ts

@@ -1,6 +1,6 @@
 import type { WorkflowRunState } from "./workflow-runs.js";
 /**
- * 三态推导：
+ * 三态推导（docs/dynamic-workflow/concurrency.md「Protocol state」）：
  *   running   有节点在 executing / repairing / nudged（模型请求已发出、正在跑）
  *   waiting   有 live 节点（queued / dispatched / waiting），或尚无任何节点且 run 未终态
  *   completed 其余：全部节点已结算，或 run 已终态（终态压过一切：一个终态 run 里没有任何人

package/node_modules/@dcode/shared/dist/dcode-protocol-v4/workflow-runs-actor-status.js

@@ -1,7 +1,8 @@
 // ============================================================
 // actor 三态的**派生**（workflowRuns 归约的一条规则）
 // ============================================================
-// 纯函数，只从节点与 run 状态推导，不读取时钟或执行 I/O。
+// 住在归约主文件之外，与 workflow-runs-concurrency.ts / -phases.ts / -started.ts / -caps.ts
+// 同一个理由（主文件的 max-lines 门），也同一条纪律：纯函数、无时钟、无 I/O。
 //
 // 为什么必须派生：引擎的 Boundary C 除了 `actor-created` 之外**不发任何 actor 生命周期事件**，
 // 所以「这个子代理在动吗、在等吗、干完了吗」没有事件可搬，只能由它名下节点的相位与 run 的
@@ -15,7 +16,7 @@ function actorKey(siteId, ordinal) {
     return `${siteId}\0${ordinal}`;
 }
 /**
- * 三态推导：
+ * 三态推导（docs/dynamic-workflow/concurrency.md「Protocol state」）：
  *   running   有节点在 executing / repairing / nudged（模型请求已发出、正在跑）
  *   waiting   有 live 节点（queued / dispatched / waiting），或尚无任何节点且 run 未终态
  *   completed 其余：全部节点已结算，或 run 已终态（终态压过一切：一个终态 run 里没有任何人

package/node_modules/@dcode/shared/dist/dcode-protocol-v4/workflow-runs-caps.js

@@ -1,14 +1,15 @@
 // ============================================================
 // 界留下的痕迹：被拒实例的计数器、整键的条目预算、以及读面唯一的步数读法
 // ============================================================
-// 纯函数，负责容量与计数规则，不读取时钟或执行 I/O。
+// 住在归约主文件之外，与 workflow-runs-concurrency.ts / -phases.ts / -started.ts 同一个理由
+// （主文件的 max-lines 门），也同一条纪律：纯函数、无时钟、无 I/O。
 //
-// 触界时无法入表的实例也需要计数；已有条目照常更新，淘汰与重新入表由对应规则处理。
-// 三类规则分别负责：
+// 这三件事是同一件事的三面。触界的语义是**拒新**（已有条目照常更新），所以一个宽到撞界的 run
+// 里总有些实例永远不在表上：
 //   - 计数器让它们**可数**——`truncated` 只说得出「有东西没进来」，说不出多少；
 //   - 条目预算让整个状态键**有界**——单条 run 的界乘以 maxRuns 离快照上限太近；
 //   - workflowRunStepCounts 是唯一允许的步数读法——表内 + 表外，读面三处（run 卡、时间线摘要、
-//     TUI 镜像）共用同一计算，保证同一条 run 的显示步数一致。
+//     TUI 镜像）曾经各数各的，于是同一条 run 在三个地方显示三个步数。
 import { WORKFLOW_RUNS_LIMITS, } from "./workflow-runs.js";
 /**
  * 把一条**被拒**实例的事件记进 usage 的两个计数器。

package/node_modules/@dcode/shared/dist/dcode-protocol-v4/workflow-runs-concurrency.d.ts

@@ -2,41 +2,48 @@ import { type WorkflowRunState } from "./workflow-runs.js";
 /**
  * `concurrency-changed` → `run.concurrency`。
  *
- * ceiling 由本 run 见过的最大 `previous` / `next` 推导（事件不带它；桶从天花板起步，所以首条
- * 事件的 `previous` 就是天花板，只降不升的序列里它也恒是最大值）。`cooldownMs` 只在带
- * Retry-After 的限流上在场；`idle_reset` 清掉它。`next` 读不动（缺席 / 非正整数）时整条只抬水位：
- * 没有 cap 就没有可显示的东西。
+ * `ceiling` 是默认并发 D（docs/dynamic-workflow/concurrency.md「Protocol state」）：`run-started` 已把它
+ * 记在 `run.concurrencyCeiling` 上时一律取那一个。共享桶的自动增长可以到 2D、被抬高的 run 还能更高，
+ * 所以「见过的最大 previous / next」早已不是 D——它只是**老 CLI**（不发 `concurrencyCeiling`）时的
+ * 退路：那时桶从天花板起步、只降不升，最大值恰好就是天花板。`cooldownMs` 只在带 Retry-After 的
+ * 限流上在场；`idle_reset` 清掉它。`next` 读不动（缺席 / 非正整数）时整条只抬水位：没有 cap 就没有
+ * 可显示的东西。
  *
  * `limit` 照搬：它是本 run 自己的界（`run-started` 带来的），与共享桶的涨落无关——治理器压低
  * 或放开一个 provider key，不会改变用户给这次 run 定的上限。
  */
 export declare function reduceConcurrencyChanged(run: WorkflowRunState, payload: Record<string, unknown>): WorkflowRunState;
 /**
- * `run-started` → `run.concurrency.limit`：本 run **自己的**那条界。载荷带引擎的
- * `caps.maxConcurrency` 与 CLI 在铸载荷那一刻算出的 `concurrencyCeiling`（天花板是进程事实，
- * 不是引擎事实，所以它由 CLI 拼进载荷，与 `resumedFrom` 同一先例）。
+ * `run-started` → `run.concurrency.limit`：本 run **自己的**那条界
+ * （docs/dynamic-workflow/concurrency.md「Two bounds on a run」）。载荷带引擎的
+ * `caps.maxConcurrency` 与 CLI 在铸载荷那一刻算出的 `concurrencyCeiling`——默认并发 D（线上键名
+ * 早于「默认并发」这个概念，为兼容旧端保留）。D 是进程事实，不是引擎事实，所以它由 CLI 拼进
+ * 载荷，与 `resumedFrom` 同一先例。
  *
- * 只在 `maxConcurrency < ceiling` 时记：跑在天花板上的 run 与从前逐字节相同，一个键都不多。
- * 老 CLI 不发 `concurrencyCeiling`，读不出天花板就无从判断这个 run 是否被压低——什么都不改。
+ * 只在 `maxConcurrency ≠ D` 时记——**高于或低于**都记：D 是起点不是上限，用户可以把一个 run 调得
+ * 比默认更并行。跑在默认上的 run 与从前逐字节相同，一个键都不多。老 CLI 不发 `concurrencyCeiling`，
+ * 读不出 D 就无从判断这个 run 有没有自己的界——什么都不改。
  *
  * 共享桶那一侧（`cap` / `key` / `cooldownMs`）原样留着：resume 会为同一个 runId 再发一条
- * `run-started`，而那时进程里很可能已经学到了一个被限流压低的 cap，用天花板把它盖掉就是把
- * 读数抬回一个假值。同理 `ceiling` 只升不降——与 `reduceConcurrencyChanged` 同一条水位规则。
+ * `run-started`，而那时进程里很可能已经学到了一个被限流压低的 cap，用 D 把它盖掉就是把读数
+ * 抬回一个假值。
  */
 export declare function reduceRunStartedConcurrency(run: WorkflowRunState, payload: Record<string, unknown>): WorkflowRunState;
 /**
- * `run-caps-changed` → `run.concurrency.limit`：run **在飞时**它自己的那条界被改了。只改 `max_concurrency` 的修订就地生效——不停这次 run、
+ * `run-caps-changed` → `run.concurrency.limit`：run **在飞时**它自己的那条界被改了
+ * （docs/dynamic-workflow/concurrency.md）。只改 `max_concurrency` 的修订就地生效——不停这次 run、
  * 不另起一次——引擎改完 caps 发这条事件，载荷与 `run-started` 同形（引擎的 `caps.maxConcurrency`
- * 加 CLI 拼进来的 `concurrencyCeiling`）。所以这里与 `reduceRunStartedConcurrency` 读同两个字段、
- * 守同一条「只在低于天花板时记」：同一个数经两条路进来不能得出两份读数。
+ * 加 CLI 拼进来的 `concurrencyCeiling`，即默认并发 D）。所以这里与 `reduceRunStartedConcurrency`
+ * 读同两个字段、守同一条「只在 ≠ D 时记」：同一个数经两条路进来不能得出两份读数。
  *
- * 天花板按「载荷 → 本 run 已知值」取。它是进程事实、整条 run 恒定，`run-started` 已经把它记在
+ * D 按「载荷 → 本 run 已知值」取。它是进程事实、整条 run 恒定，`run-started` 已经把它记在
  * `run.concurrencyCeiling` 上了，所以这条事件比 `run-started` 多一层退路；两个都没有才无从判断
- * 这个数是否被压低，什么都不改。`caps` 读不动同理。
+ * 这个数是不是默认，什么都不改。`caps` 读不动同理。
  *
- * 升回天花板要把 `limit` **摘掉**而不是写成天花板：跑在天花板上的 run 按协议没有自己的界。摘完
- * 若共享桶那一侧也无话可说（cap 在水位上、不在冷却），整个 `concurrency` 键随之缺席——与一个
- * 从没被压低过的 run 逐字节相同。本来就没有 `limit` 时一个字不动（幂等的支点）。
+ * 调回 D 要把 `limit` **摘掉**而不是写成 D：跑在默认上的 run 按协议没有自己的界。摘完若共享桶
+ * 那一侧也无话可说（cap 不低于 D、不在冷却——长到 D 之上的 cap 对一个默认 run 同样无话可说，
+ * 读数是 `min(cap, D)`），整个 `concurrency` 键随之缺席——与一个从没调过界的 run 逐字节相同。
+ * 本来就没有 `limit` 时一个字不动（幂等的支点）。
  */
 export declare function reduceRunCapsChanged(run: WorkflowRunState, payload: Record<string, unknown>): WorkflowRunState;
 /**

package/node_modules/@dcode/shared/dist/dcode-protocol-v4/workflow-runs-concurrency.js

@@ -5,15 +5,17 @@
 // `concurrency-changed` 的规则住在这里。与主归约同一条纪律：纯函数、无时钟——事件上的
 // `cooldownMs` 是相对量，deadline 由 UI 按收到状态的时刻推算。
 import { WORKFLOW_RUNS_LIMITS, } from "./workflow-runs.js";
-/** 事件里的 `reason` 值：桶空闲重置回天花板——它不是冷却，收到即清掉旧的 cooldown。 */
+/** 事件里的 `reason` 值：桶空闲重置回默认并发——它不是冷却，收到即清掉旧的 cooldown。 */
 const CONCURRENCY_IDLE_RESET_REASON = "idle_reset";
 /**
  * `concurrency-changed` → `run.concurrency`。
  *
- * ceiling 由本 run 见过的最大 `previous` / `next` 推导（事件不带它；桶从天花板起步，所以首条
- * 事件的 `previous` 就是天花板，只降不升的序列里它也恒是最大值）。`cooldownMs` 只在带
- * Retry-After 的限流上在场；`idle_reset` 清掉它。`next` 读不动（缺席 / 非正整数）时整条只抬水位：
- * 没有 cap 就没有可显示的东西。
+ * `ceiling` 是默认并发 D（docs/dynamic-workflow/concurrency.md「Protocol state」）：`run-started` 已把它
+ * 记在 `run.concurrencyCeiling` 上时一律取那一个。共享桶的自动增长可以到 2D、被抬高的 run 还能更高，
+ * 所以「见过的最大 previous / next」早已不是 D——它只是**老 CLI**（不发 `concurrencyCeiling`）时的
+ * 退路：那时桶从天花板起步、只降不升，最大值恰好就是天花板。`cooldownMs` 只在带 Retry-After 的
+ * 限流上在场；`idle_reset` 清掉它。`next` 读不动（缺席 / 非正整数）时整条只抬水位：没有 cap 就没有
+ * 可显示的东西。
  *
  * `limit` 照搬：它是本 run 自己的界（`run-started` 带来的），与共享桶的涨落无关——治理器压低
  * 或放开一个 provider key，不会改变用户给这次 run 定的上限。
@@ -23,7 +25,7 @@ export function reduceConcurrencyChanged(run, payload) {
     if (next === undefined)
         return run;
     const previous = positiveInteger(payload.previous) ?? next;
-    const ceiling = Math.max(run.concurrency?.ceiling ?? 0, previous, next);
+    const ceiling = run.concurrencyCeiling ?? Math.max(run.concurrency?.ceiling ?? 0, previous, next);
     const key = nonEmptyString(payload.key);
     const limit = run.concurrency?.limit;
     const cooldownMs = payload.reason === CONCURRENCY_IDLE_RESET_REASON
@@ -41,16 +43,19 @@ export function reduceConcurrencyChanged(run, payload) {
     return { ...run, concurrency };
 }
 /**
- * `run-started` → `run.concurrency.limit`：本 run **自己的**那条界。载荷带引擎的
- * `caps.maxConcurrency` 与 CLI 在铸载荷那一刻算出的 `concurrencyCeiling`（天花板是进程事实，
- * 不是引擎事实，所以它由 CLI 拼进载荷，与 `resumedFrom` 同一先例）。
+ * `run-started` → `run.concurrency.limit`：本 run **自己的**那条界
+ * （docs/dynamic-workflow/concurrency.md「Two bounds on a run」）。载荷带引擎的
+ * `caps.maxConcurrency` 与 CLI 在铸载荷那一刻算出的 `concurrencyCeiling`——默认并发 D（线上键名
+ * 早于「默认并发」这个概念，为兼容旧端保留）。D 是进程事实，不是引擎事实，所以它由 CLI 拼进
+ * 载荷，与 `resumedFrom` 同一先例。
  *
- * 只在 `maxConcurrency < ceiling` 时记：跑在天花板上的 run 与从前逐字节相同，一个键都不多。
- * 老 CLI 不发 `concurrencyCeiling`，读不出天花板就无从判断这个 run 是否被压低——什么都不改。
+ * 只在 `maxConcurrency ≠ D` 时记——**高于或低于**都记：D 是起点不是上限，用户可以把一个 run 调得
+ * 比默认更并行。跑在默认上的 run 与从前逐字节相同，一个键都不多。老 CLI 不发 `concurrencyCeiling`，
+ * 读不出 D 就无从判断这个 run 有没有自己的界——什么都不改。
  *
  * 共享桶那一侧（`cap` / `key` / `cooldownMs`）原样留着：resume 会为同一个 runId 再发一条
- * `run-started`，而那时进程里很可能已经学到了一个被限流压低的 cap，用天花板把它盖掉就是把
- * 读数抬回一个假值。同理 `ceiling` 只升不降——与 `reduceConcurrencyChanged` 同一条水位规则。
+ * `run-started`，而那时进程里很可能已经学到了一个被限流压低的 cap，用 D 把它盖掉就是把读数
+ * 抬回一个假值。
  */
 export function reduceRunStartedConcurrency(run, payload) {
     const limit = positiveInteger(plainRecord(payload.caps)?.maxConcurrency);
@@ -58,36 +63,38 @@ export function reduceRunStartedConcurrency(run, payload) {
     const ceiling = readCeiling !== undefined && readCeiling <= WORKFLOW_RUNS_LIMITS.maxConcurrencyCeiling
         ? readCeiling
         : undefined;
-    // 天花板本身单独记一份（`run.concurrencyCeiling`）：「配置」弹层的步进器要知道停在哪，而
-    // 跑在天花板上的 run 没有 `concurrency` 可挂。读不出就沿用已知值——与 subagentModel 同一条退化规则。
+    // D 本身单独记一份（`run.concurrencyCeiling`）：「配置」弹层要写「默认 N」、判「等于默认 = 不设
+    // 自己的界」，而跑在默认上的 run 没有 `concurrency` 可挂。读不出就沿用已知值——与 subagentModel
+    // 同一条退化规则。
     const withCeiling = ceiling === undefined || run.concurrencyCeiling === ceiling
         ? run
         : { ...run, concurrencyCeiling: ceiling };
-    if (limit === undefined || ceiling === undefined || limit >= ceiling)
+    if (limit === undefined || ceiling === undefined || limit === ceiling)
         return withCeiling;
     const existing = withCeiling.concurrency;
     const concurrency = {
-        // 没有共享桶读数时，cap 从天花板起步——桶本来就是从那里开始的（同 reduceConcurrencyChanged
-        // 推导 ceiling 的那条依据）。
+        // 没有共享桶读数时，cap 从 D 起步——桶本来就是从那里开始的。
         ...(existing ?? { cap: ceiling }),
-        ceiling: Math.max(existing?.ceiling ?? 0, ceiling),
+        ceiling,
         limit,
     };
     return { ...withCeiling, concurrency };
 }
 /**
- * `run-caps-changed` → `run.concurrency.limit`：run **在飞时**它自己的那条界被改了。只改 `max_concurrency` 的修订就地生效——不停这次 run、
+ * `run-caps-changed` → `run.concurrency.limit`：run **在飞时**它自己的那条界被改了
+ * （docs/dynamic-workflow/concurrency.md）。只改 `max_concurrency` 的修订就地生效——不停这次 run、
  * 不另起一次——引擎改完 caps 发这条事件，载荷与 `run-started` 同形（引擎的 `caps.maxConcurrency`
- * 加 CLI 拼进来的 `concurrencyCeiling`）。所以这里与 `reduceRunStartedConcurrency` 读同两个字段、
- * 守同一条「只在低于天花板时记」：同一个数经两条路进来不能得出两份读数。
+ * 加 CLI 拼进来的 `concurrencyCeiling`，即默认并发 D）。所以这里与 `reduceRunStartedConcurrency`
+ * 读同两个字段、守同一条「只在 ≠ D 时记」：同一个数经两条路进来不能得出两份读数。
  *
- * 天花板按「载荷 → 本 run 已知值」取。它是进程事实、整条 run 恒定，`run-started` 已经把它记在
+ * D 按「载荷 → 本 run 已知值」取。它是进程事实、整条 run 恒定，`run-started` 已经把它记在
  * `run.concurrencyCeiling` 上了，所以这条事件比 `run-started` 多一层退路；两个都没有才无从判断
- * 这个数是否被压低，什么都不改。`caps` 读不动同理。
+ * 这个数是不是默认，什么都不改。`caps` 读不动同理。
  *
- * 升回天花板要把 `limit` **摘掉**而不是写成天花板：跑在天花板上的 run 按协议没有自己的界。摘完
- * 若共享桶那一侧也无话可说（cap 在水位上、不在冷却），整个 `concurrency` 键随之缺席——与一个
- * 从没被压低过的 run 逐字节相同。本来就没有 `limit` 时一个字不动（幂等的支点）。
+ * 调回 D 要把 `limit` **摘掉**而不是写成 D：跑在默认上的 run 按协议没有自己的界。摘完若共享桶
+ * 那一侧也无话可说（cap 不低于 D、不在冷却——长到 D 之上的 cap 对一个默认 run 同样无话可说，
+ * 读数是 `min(cap, D)`），整个 `concurrency` 键随之缺席——与一个从没调过界的 run 逐字节相同。
+ * 本来就没有 `limit` 时一个字不动（幂等的支点）。
  */
 export function reduceRunCapsChanged(run, payload) {
     const maxConcurrency = positiveInteger(plainRecord(payload.caps)?.maxConcurrency);
@@ -102,23 +109,24 @@ export function reduceRunCapsChanged(run, payload) {
     if (maxConcurrency === undefined || ceiling === undefined)
         return withCeiling;
     const existing = withCeiling.concurrency;
-    if (maxConcurrency < ceiling) {
+    if (maxConcurrency !== ceiling) {
         const concurrency = {
-            // 没有共享桶读数时 cap 从天花板起步——与 reduceRunStartedConcurrency 同一条依据。
+            // 没有共享桶读数时 cap 从 D 起步——与 reduceRunStartedConcurrency 同一条依据。
             ...(existing ?? { cap: ceiling }),
-            ceiling: Math.max(existing?.ceiling ?? 0, ceiling),
+            ceiling,
             limit: maxConcurrency,
         };
         return { ...withCeiling, concurrency };
     }
     if (existing?.limit === undefined)
         return withCeiling;
-    const { limit: _lifted, ...shared } = existing;
+    const { limit: _lifted, ...rest } = existing;
+    const shared = { ...rest, ceiling };
     return shared.cooldownMs === undefined && shared.cap >= shared.ceiling
         ? withoutConcurrency(withCeiling)
         : { ...withCeiling, concurrency: shared };
 }
-/** 摘掉整个 `concurrency` 键（不是留一个空对象）：协议上「跑在天花板上」就是这个键不在。 */
+/** 摘掉整个 `concurrency` 键（不是留一个空对象）：协议上「跑在默认上、无话可说」就是这个键不在。 */
 function withoutConcurrency(run) {
     const { concurrency: _cleared, ...rest } = run;
     return rest;

package/node_modules/@dcode/shared/dist/dcode-protocol-v4/workflow-runs-delta.d.ts

@@ -62,15 +62,16 @@ export declare function applyWorkflowRunRemoved(state: WorkflowRunsState | undef
  * 每次淘汰都让出一个位子，一个够宽的 flush 窗口里被删掉的不同键因此可以多于 1024 条。
  * 淘汰之前这不可能：表只增不减，一世之内被碰过的不同键最多就是表界那么多。
  *
- * 超界载荷会让整个 patch 解析失败、整帧被丢；publisher 的两道限制（500 op / 1 MiB）在这个
+ * 超界的载荷不会被剥掉一个键，它让整个 patch 解析失败、整帧被丢、那条订阅从此静默
+ * （workflow-runs.ts 记的那次事故的形状），而 publisher 的两道兜底（500 op / 1 MiB）在这个
  * 量级上都不会响。四张表都查是因为这道闸很便宜，而且不该依赖上面那条论证一直成立。
  *
  * 合并是**优化**，所以拒绝合并永远是安全的：两条 op 各自都在界内，逐条投递的终态一个字节都不差。
  */
 export declare function workflowRunUpdateWithinWireBounds(delta: WorkflowRunUpdatedDelta, limits?: WorkflowRunWireBounds): boolean;
 /**
- * 条目表的容量上限，默认使用 {@link WORKFLOW_RUNS_LIMITS}。
- * 增量应用和合并必须使用一致的上限。
+ * 条目表的线上界。只为测试留的注入口（默认就是 {@link WORKFLOW_RUNS_LIMITS}）：真界是 1024，
+ * 而「合并被拒」这条路径在小界下才走得到，property 测试需要它真的被走到。
  */
 export interface WorkflowRunWireBounds {
     readonly maxActors: number;

package/node_modules/@dcode/shared/dist/dcode-protocol-v4/workflow-runs-delta.js

@@ -14,7 +14,7 @@
 //      diff 的第一道闸是引用比较，深比较只发生在真正动过的那条 run 上。
 //   3. 正确性绝不依赖引用：引用相等只是快路径，不等时一律退回结构比较。
 //
-// 契约：对任意一对 reducer 产出的 (prior, next)，
+// 契约（被 property 测试钉住）：对任意一对 reducer 产出的 (prior, next)，
 // `JSON.stringify(applyAll(带 prior 的快照, diff(prior, next)).workflowRuns) === JSON.stringify(next)`
 // ——**逐字节**，不只是深相等。键序因此是本模块的一等公民，见 {@link canonicalWorkflowRun}。
 import { WORKFLOW_RUNS_LIMITS, workflowRunSchema, } from "./workflow-runs.js";
@@ -26,7 +26,7 @@ import { WORKFLOW_RUNS_LIMITS, workflowRunSchema, } from "./workflow-runs.js";
  * 重建 run 时没有那段历史。两边各自按这张表重排一次，序就对齐了——这也是为什么 reducer 的
  * 出口同样要走一遍本函数（那是一处，不是两处）。
  *
- * 键序从 schema 派生，避免独立维护字段表导致生产者和消费者使用不同的 run 结构。
+ * 从 schema 派生而不是手抄：手抄一份 run 字段表曾经酿成过事故（见 delta.ts 的 header 注释）。
  */
 const WORKFLOW_RUN_KEYS = Object.keys(workflowRunSchema.shape);
 const WORKFLOW_RUN_KEY_SET = new Set(WORKFLOW_RUN_KEYS);
@@ -378,7 +378,8 @@ function upsertWorkflowRunEntries(current, incoming) {
  * 每次淘汰都让出一个位子，一个够宽的 flush 窗口里被删掉的不同键因此可以多于 1024 条。
  * 淘汰之前这不可能：表只增不减，一世之内被碰过的不同键最多就是表界那么多。
  *
- * 超界载荷会让整个 patch 解析失败、整帧被丢；publisher 的两道限制（500 op / 1 MiB）在这个
+ * 超界的载荷不会被剥掉一个键，它让整个 patch 解析失败、整帧被丢、那条订阅从此静默
+ * （workflow-runs.ts 记的那次事故的形状），而 publisher 的两道兜底（500 op / 1 MiB）在这个
  * 量级上都不会响。四张表都查是因为这道闸很便宜，而且不该依赖上面那条论证一直成立。
  *
  * 合并是**优化**，所以拒绝合并永远是安全的：两条 op 各自都在界内，逐条投递的终态一个字节都不差。

package/node_modules/@dcode/shared/dist/dcode-protocol-v4/workflow-runs-entries.d.ts

@@ -9,15 +9,25 @@ import { type WorkflowRunActor } from "./workflow-runs.js";
 export declare function workflowActorEntry(ref: {
     siteId: string;
     ordinal: number;
-}, name: unknown, phaseName: string | undefined, sessionId: string | undefined): WorkflowRunActor;
+}, name: unknown, phaseName: string | undefined, sessionId: string | undefined, model: unknown): WorkflowRunActor;
 /** 子代理展示名的线上界（见文件头那次订阅失效）。 */
 export declare function boundedActorName(name: string | undefined): string | undefined;
 /**
- * 实例出生阶段名的线上界。与 {@link boundedActorName}
+ * 实例出生阶段名的线上界（docs/dynamic-workflow/presentation.md）。与 {@link boundedActorName}
  * 同族、同理由，但**直接截断、不加省略号**——这个字段不是给人读的文本而是一个关联键，
  * UI 的 `phaseNameMatches` 正是按前缀把截断的名字关联回 display 阶段。
  */
 export declare function boundedPhaseName(name: string | undefined): string | undefined;
+/**
+ * 会话 id 的线上读法：界内的非空串原样收下，其余一律当缺席。**不截断**——与子代理模型串同理，
+ * 一个被砍短的 id 指向的是另一条会话，宁可不认。
+ */
+export declare function boundedSessionId(value: unknown): string | undefined;
 /** 空串按缺席处理：协议线上只有「键在场」与「键缺席」两态。 */
 export declare function nonEmptyString(value: unknown): string | undefined;
+/** 引擎的 `InstanceRef` / `ActorRef` 同构：站点 id × 序号。缺任一即无法定位，返回 null。 */
+export declare function workflowInstanceRef(value: unknown): {
+    siteId: string;
+    ordinal: number;
+} | null;
 //# sourceMappingURL=workflow-runs-entries.d.ts.map

package/node_modules/@dcode/shared/dist/dcode-protocol-v4/workflow-runs-entries.js

@@ -1,8 +1,14 @@
-// 出生事实的读取：按协议容量上限生成 actor 条目。
-// 纯函数，不读取时钟或执行 I/O。
+// ============================================================
+// 出生事实的读法：脚本作者写的那些字符串怎么按线上界落成一个 actor 条目
+// ============================================================
+// 从 workflow-runs-reducer.ts 拆出（主文件的 max-lines 门），与 -caps.ts / -eviction.ts /
+// -started.ts 同一条先例，也同一条纪律：纯函数、无时钟、无 I/O。
 //
-// 名字与阶段名由脚本生成，可能超过协议长度限制。渲染端会严格校验每一帧，超长值可能使
-// 增量和恢复快照都被拒绝。因此生产者按 schema 上限裁剪，完整值仍保留在 journal 中。
+// 这几个界不是展示预算而是**安全界**。名字与阶段名都是脚本作者任意拼出来的
+// （`agent("reader-" + paths.join("+"))`、`phase("检查 " + file)`），而 CLI 不校验出站帧、
+// 渲染端对每一帧做严格校验——2026-09-04 一个 131 字的子代理名让父会话在那个 actor 出现之后的
+// 每一帧（online / recovery / initial 快照）全部被拒，订阅以 `fault.subscription.recoveryFailed`
+// 永久失效。所以生产者按 schema 界裁剪，线上永远合法；完整值仍在 journal 里。
 import { WORKFLOW_RUNS_LIMITS } from "./workflow-runs.js";
 /**
  * 一个 actor 条目的铸造。两处调用必须**逐字同形**：`actor-created`，以及带出生事实的
@@ -11,31 +17,63 @@ import { WORKFLOW_RUNS_LIMITS } from "./workflow-runs.js";
  *
  * `status` 落的是占位值：紧接着的 `withDerivedWorkflowActorStatuses` 会按节点与 run 终态重算。
  */
-export function workflowActorEntry(ref, name, phaseName, sessionId) {
+export function workflowActorEntry(ref, name, phaseName, sessionId, model) {
     const bounded = boundedActorName(nonEmptyString(name));
+    const canonical = boundedActorModel(nonEmptyString(model));
     return {
         siteId: ref.siteId,
         ordinal: ref.ordinal,
         ...(bounded === undefined ? {} : { name: bounded }),
         ...(sessionId ? { sessionId } : {}),
         ...(phaseName === undefined ? {} : { phaseName }),
+        ...(canonical === undefined ? {} : { model: canonical }),
         status: "waiting",
     };
 }
+/**
+ * 子代理模型的线上界：超界**整个丢掉**而不截断——截断的规范串是另一个（不存在的）模型，
+ * 画出来就是一句假话；缺席只是退回「跑在 run 的子代理模型上」那一格。
+ */
+function boundedActorModel(model) {
+    return model === undefined || model.length > WORKFLOW_RUNS_LIMITS.maxSubagentModelLength
+        ? undefined
+        : model;
+}
 /** 子代理展示名的线上界（见文件头那次订阅失效）。 */
 export function boundedActorName(name) {
     return name === undefined ? undefined : name.slice(0, WORKFLOW_RUNS_LIMITS.maxActorNameLength);
 }
 /**
- * 实例出生阶段名的线上界。与 {@link boundedActorName}
+ * 实例出生阶段名的线上界（docs/dynamic-workflow/presentation.md）。与 {@link boundedActorName}
  * 同族、同理由，但**直接截断、不加省略号**——这个字段不是给人读的文本而是一个关联键，
  * UI 的 `phaseNameMatches` 正是按前缀把截断的名字关联回 display 阶段。
  */
 export function boundedPhaseName(name) {
     return name === undefined ? undefined : name.slice(0, WORKFLOW_RUNS_LIMITS.maxPhaseNameLength);
 }
+/**
+ * 会话 id 的线上读法：界内的非空串原样收下，其余一律当缺席。**不截断**——与子代理模型串同理，
+ * 一个被砍短的 id 指向的是另一条会话，宁可不认。
+ */
+export function boundedSessionId(value) {
+    const text = nonEmptyString(value);
+    return text !== undefined && text.length <= WORKFLOW_RUNS_LIMITS.maxSessionIdLength
+        ? text
+        : undefined;
+}
 /** 空串按缺席处理：协议线上只有「键在场」与「键缺席」两态。 */
 export function nonEmptyString(value) {
     return typeof value === "string" && value.length > 0 ? value : undefined;
 }
+/** 引擎的 `InstanceRef` / `ActorRef` 同构：站点 id × 序号。缺任一即无法定位，返回 null。 */
+export function workflowInstanceRef(value) {
+    if (typeof value !== "object" || value === null || Array.isArray(value))
+        return null;
+    const record = value;
+    const siteId = nonEmptyString(record.siteId);
+    const ordinal = record.ordinal;
+    if (siteId === undefined || typeof ordinal !== "number")
+        return null;
+    return { siteId, ordinal };
+}
 //# sourceMappingURL=workflow-runs-entries.js.map

package/node_modules/@dcode/shared/dist/dcode-protocol-v4/workflow-runs-eviction.d.ts

@@ -1,7 +1,7 @@
 import { type WorkflowRunActor, type WorkflowRunNode, type WorkflowRunState } from "./workflow-runs.js";
 /**
- * 归约使用的三项条目容量上限，默认使用 {@link WORKFLOW_RUNS_LIMITS}。
- * 淘汰与计数规则适用于调用方传入的上限。
+ * 归约要用到的三条条目界。本包的默认值就是 {@link WORKFLOW_RUNS_LIMITS}；单独定义成接口是为了
+ * 让测试能注入小界——1024 条要三千多条事件才撞得到，而这里的规则与界的**大小**无关。
  */
 export interface WorkflowRunEntryLimits {
     readonly maxActors: number;

package/node_modules/@dcode/shared/dist/dcode-protocol-v4/workflow-runs-eviction.js

@@ -1,13 +1,15 @@
 // ============================================================
 // 表满时腾位：谁可以让位、什么时候入座、以及被腾掉的东西怎么继续可数
 // ============================================================
-// 淘汰规则是纯函数，不读取时钟或执行 I/O。表外条目的分阶段计数由 workflow-runs-unlisted.ts 维护。
+// 住在归约主文件之外，与 workflow-runs-caps.ts / -concurrency.ts / -phases.ts / -started.ts
+// 同一个理由（主文件的 max-lines 门），也同一条纪律：纯函数、无时钟、无 I/O。格子表的加减法
+// 在同族的 workflow-runs-unlisted.ts。
 //
 // 为什么要腾位。触界的老语义是**拒新**，而读面画的是「此刻哪些子代理在跑」——于是一个宽
 // fan-out 的 run 跑过 1024 之后，新起的子代理一个都进不来，run 卡与站点花名册永远停在最早
 // 那批**已经结束**的身上，恰好把这个特性存在的理由抹掉。腾位把它反过来：终态的条目让位。
 //
-// 只淘汰终态条目还不够：一个阶段可能
+// 只腾位还不够，2026-09-20 的事故（5 × 2000 个子代理、并发 13）说的正是剩下那一半：一个阶段
 // 在头几秒里把**全部** actor-created 与**全部** node-queued 发完，头 1024 条还排着队就把两张表
 // 塞满，一条终态都没有，于是后面 976 个连人带活全被拒；调度器随后按 FIFO 派活，从第 1025 个
 // 开始每一个**正在跑**的子代理都不在表上。一个子代理变重要是在它**被派活**的那一刻，不是在
@@ -78,15 +80,19 @@ export function seatWorkflowNode(run, seat, limits = WORKFLOW_RUNS_LIMITS) {
     if (seat.eventType === "node-dispatched" && seat.actor !== null && run.truncated === true) {
         return activateInstance(run, seat.ref, seat.actor, limits);
     }
-    if (seat.eventType !== "node-queued")
-        return { run, admitNew: byBirth, activated: false };
-    // B2：溢出过的 run 里，一条认不出主人的 queued 连位子都不该占——它画不出徽章（pill 按
-    // run.actors 过滤），而后面被派下去的活正需要那个位子。游离节点（world-read）不在此列。
-    if (run.truncated === true &&
+    // B2：溢出过的 run 里，一条认不出主人的**出生**连位子都不该占——它画不出徽章（pill 按
+    // run.actors 过滤），而后面被派下去的活正需要那个位子。两条出生都算：`node-queued`，以及
+    // 重发了出生事实的缓存结算。后者放进来还会**卡死**：点名了 actor 的节点不是游离节点，而组是按
+    // 已列 actor 建的，于是它哪一类受害者都不是，永远淘汰不掉。游离节点（world-read）不在此列。
+    if (seat.born &&
+        run.truncated === true &&
         seat.actorRef !== null &&
         !run.actors.some((actor) => sameInstance(actor, seat.actorRef))) {
         return { run, admitNew: false, activated: false };
     }
+    // 出生即结算的缓存命中从不腾位（它没跑过，没有要展示的进行态）；腾位只给活的新人。
+    if (seat.eventType !== "node-queued")
+        return { run, admitNew: byBirth, activated: false };
     return {
         run: withRoomForNode(run, seat.ref, seat.actorRef, limits),
         admitNew: byBirth,
@@ -217,8 +223,9 @@ function pickGroupVictim(run, owner, allowZeroNode) {
         groups.filter((group) => group.idle).at(-1) ??
         // 零节点 actor 同理取最靠后的，而且是最后一档：它没有节点、没有分数、表里也没有历史，
         // 淘汰它读者看不见任何损失，而它自己下一次被派活时会带着事实回来。少了这一档，一次
-        // resume 之后的宽 fan-out 会卡死——空表重开、前缀把 2000 个 actor 重新建出来、命中缓存的
-        // 结算又不带 actor，于是一张全是零节点 actor 的表谁都淘汰不动，此后每一次派发都被拒。
+        // resume 之后的宽 fan-out 会卡死——空表重开、前缀把 2000 个 actor 重新建出来，而它们的
+        // 第一问还没回来（老 journal 里命中缓存的结算又不带 actor），于是一张全是零节点 actor 的表
+        // 谁都淘汰不动，此后每一次派发都被拒。
         (allowZeroNode ? groups.filter((group) => group.zeroNode).at(-1) : undefined));
 }
 function spareGroups(run, owner) {
@@ -299,7 +306,7 @@ function listedGroups(run) {
     });
     return groups;
 }
-/** 游离节点：没有 actor 的已列节点（world-read）。只有已结算的才是候选。 */
+/** 游离节点：没有 actor 的已列节点（world-read，或老 journal 的缓存命中）。只有已结算的才是候选。 */
 function looseSettledNodes(run) {
     const candidates = [];
     run.nodes.forEach((node, index) => {

package/node_modules/@dcode/shared/dist/dcode-protocol-v4/workflow-runs-holes.d.ts

@@ -0,0 +1,33 @@
+import { type WorkflowRunState } from "./workflow-runs.js";
+/**
+ * 留白的站点 id：`hole#` 加 8 位十六进制，键是留白的**名字**，与嵌套深度无关（CLI 的
+ * analysis/hole-id.ts 铸造；apps/dcode-cli/packages/dynamic-workflow/docs/analysis.md「Sites」）。
+ * id 里不再写嵌套关系：一个留白在哪个留白里面，看它自己的阶段 / 站上的 `fill`。
+ */
+export declare const WORKFLOW_HOLE_SITE_ID_PATTERN: RegExp;
+/**
+ * `run-launched.holes` / `hole-filled.holes` 的搬运：下标指向**被接受的**那张 `phaseNames`，所以
+ * 越界、非整数、重复一律丢——越界的下标会让侧栏把一盏虚线灯画到一个不存在的站上。一项都不剩时
+ * 返回 `undefined`：键不建。
+ */
+export declare function readPhaseHoles(raw: unknown, count: number): number[] | undefined;
+/**
+ * 载荷上的声明阶段表（`run-launched` 与 `hole-filled` 同形）：按声明序、裁到与 `phases` 同一对界。
+ * 空表返回 `undefined`，调用方据此不动已有的表。
+ */
+export declare function readPhaseNames(raw: unknown): string[] | undefined;
+export declare function reduceHoleReached(run: WorkflowRunState, payload: Record<string, unknown>): WorkflowRunState;
+/**
+ * `hole-filled`：主代理的补全接进了 run。三件事一步做完——那条记录翻成 filled、阶段表换成补全后的
+ * 声明表（超集：留白的体在留白的位置展开）、留白下标表整张换新。「同时在跑」表按插入位置右移：
+ * 补全只在留白那一站之后插入 k 站，旧表里 > h 的下标一律 +k；表的形状对不上（不是这种插入）就丢掉，
+ * 宁可侧栏少画双线段，也不把它连到错的站上。
+ */
+export declare function reduceHoleFilled(run: WorkflowRunState, payload: Record<string, unknown>): WorkflowRunState;
+/**
+ * 剥掉 waiting 记录（新的一世 / 终态）：真相是进程内的停驻 deferred，与 pendingQuestions 同一条理由——
+ * 一个已停的 run 没有人在等补全；resume 重跑到那个站点会再发一条 `hole-reached`。filled 记录跨世保留：
+ * 那是接进 run 的代码，不是残影。一条不剩时整个键摘掉。
+ */
+export declare function withoutWaitingHoles(run: WorkflowRunState): WorkflowRunState;
+//# sourceMappingURL=workflow-runs-holes.d.ts.map