@dipoleml/dcode-cli 1.0.0 → 1.2.0

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

@@ -3,10 +3,15 @@ export declare const WORKFLOW_RUNS_LIMITS: {
     /** 最近若干个 run；超出按最旧淘汰。 */
     readonly maxRuns: 8;
     /**
-     * actors 与 nodes 使用相同的容量上限，避免节点可展示而所属子代理提前被截断。
-     * 键级增量使每个事件只传输改动部分；容量上限用于限制单条 run 的投影大小，
-     * 并限制异常脚本持续创建条目带来的资源消耗。跨 run 的总量由 {@link maxTotalEntries} 控制。
-     * 这是展示状态的容量限制，不限制引擎实际运行的子代理数量。
+     * actors 与 nodes **同界**。每个节点都属于某个 actor，所以 nodes 的界已经隐含了 actor
+     * 数的量级；把 actors 压得更低（曾是 32）只会让一个平常的 50 路 fan-out 在检视器里
+     * 静默少掉 18 个子代理，而节点表、引擎、图三层都装得下。
+     *
+     * 2026-09-20 从 256 抬到 1024：原来那条界的理由是「状态键按事件整体重发，无界即 O(N²)
+     * 字节」，而键级增量（workflow-runs-delta.ts）落地后每条事件只发改动量，那条理由没了。
+     * 剩下的两条理由都还在，而且都不需要 256 这么紧：挡住「疯掉的脚本在循环里 `agent()`」，
+     * 以及让单条 run 的字节数有个上界。**跨 run** 的总量另有 {@link maxTotalEntries} 管。
+     * 它仍然不是产品意义上的子代理上限。
      */
     readonly maxActors: 1024;
     readonly maxNodes: 1024;
@@ -20,7 +25,7 @@ export declare const WORKFLOW_RUNS_LIMITS: {
      */
     readonly maxTotalEntries: 6144;
     /**
-     * 详情页 Results 区的**展示**预算，刻意远小于引擎的 run 级 report 上限（256 条）：
+     * 详情页 Results 区的**展示**预算，刻意远小于引擎的 run 级 report 上限（`REPORT_CAPS.maxItemsPerRun`）：
      * 协议线上的界是展示预算，引擎的界才是契约，两者不必相等。超出这个界的条目仍在
      * journal 里（`dwf_node.kind = "report"`），只是不进这条高频状态键。
      */
@@ -44,7 +49,12 @@ export declare const WORKFLOW_RUNS_LIMITS: {
      */
     readonly maxSubagentModelLength: 256;
     /**
-     * `run.concurrencyCeiling` 的上界。天花板按 `min(16, cores − 2)` 推导，这条界只挡坏载荷
+     * actor `sessionId` 的线上上界。会话 id 是铸出来或读出来的标识，不是展示文本：超界的值
+     * 整条丢弃而不是截断——一个被砍短的会话 id 指向的是另一条（或不存在的）会话。
+     */
+    readonly maxSessionIdLength: 256;
+    /**
+     * `run.concurrencyCeiling`（默认并发 D）的上界。D 按 `max(4, min(16, cores − 2))` 推导，这条界只挡坏载荷
      * （reducer 读到界外的值当作读不出，沿用已知值）。
      */
     readonly maxConcurrencyCeiling: 1024;
@@ -68,6 +78,16 @@ export declare const WORKFLOW_RUNS_LIMITS: {
     readonly maxPhases: 32;
     /** 阶段名的线上上界，与 display 的 `CREATE_WORKFLOW_GRAPH_MAX_NAME_CHARS` 同值（UI 按名字关联两边）。 */
     readonly maxPhaseNameLength: 128;
+    /**
+     * 一条 run 记得的留白条数（docs/dynamic-workflow/presentation.md「Holes on the timeline」）。与 display
+     * 载荷的 `holes` 同界：时间线上画不出的留白，投影里也不必记。一个留白就是一个阶段，所以它天然
+     * 不会多过 `maxPhases`。
+     */
+    readonly maxHoles: 32;
+    /** 留白类型原文（`Plan`）的线上上界，与 display 的同名字段同值。 */
+    readonly maxHoleTypeLength: 128;
+    /** 留白的提示语在 run 状态里的上限（侧板等待体要画它）；超长时截到 499 字加 `…`。 */
+    readonly maxHolePromptLength: 500;
     /**
      * 一次 ask 的**任务摘要**上界（`node-queued` 的 `instructionsHead`）。与引擎侧的
      * `INSTRUCTIONS_HEAD_MAX_CHARS` 同值：那一头已经按这条界切好，这里是线上的第二道闸。
@@ -88,7 +108,8 @@ export declare const WORKFLOW_RUNS_LIMITS: {
  * **旧消费者**（没有 `workflowRunDeltas` 能力的那一代）编译进去的 actors / nodes 界。
  *
  * ⚠ 这两个数**永远不能改**：它们不是我们的界，是别人二进制里的校验界。超界的载荷不会被
- * 剥掉一个键——它会让整个 `state.updated` patch 解析失败、整帧被丢，那条订阅从此静默。所以给这类订阅者
+ * 剥掉一个键——它会让整个 `state.updated` patch 解析失败、整帧被丢，那条订阅从此静默
+ * （2026-09-04 的那次 `fault.subscription.recoveryFailed` 就是这个形状）。所以给这类订阅者
  * 发帧前必须先过 `clampWorkflowRunsForLegacy`。
  *
  * 「前 256 条」不是随手取的：旧归约触界时是**拒新**，它产出的恰好就是最早的那 256 条。
@@ -98,7 +119,8 @@ export declare const WORKFLOW_RUNS_LEGACY_LIMITS: {
     readonly maxNodes: 256;
 };
 /**
- * 一个被控制流进入过的阶段（`phase("…")` 标记）。`name` 是作者原词（时间线按它关联 display 的 `phases[].name`）；`rounds` 是进入
+ * 一个被控制流进入过的阶段（`phase("…")` 标记；docs/dynamic-workflow/presentation.md
+ * 2026-09-05）。`name` 是作者原词（时间线按它关联 display 的 `phases[].name`）；`rounds` 是进入
  * 次数——单调（reducer 取 max），所以 resume 重放的前缀不会把它加倍。
  */
 export declare const workflowRunPhaseSchema: z.ZodObject<{
@@ -107,7 +129,7 @@ export declare const workflowRunPhaseSchema: z.ZodObject<{
 }, z.core.$strip>;
 export type WorkflowRunPhase = z.infer<typeof workflowRunPhaseSchema>;
 /**
- * 界在某个**出生阶段**上花掉了多少。
+ * 界在某个**出生阶段**上花掉了多少（docs/dynamic-workflow/presentation.md「Reduction」）。
  *
  * 两个计数器（{@link workflowRunUsageSchema} 的 `nodesUnlisted` / `nodesUnlistedSettled`）说得出
  * 一条 run 总共少列了多少，说不出少在**哪一站**——而读面是按站画的：一个站点的花名册、计数环和
@@ -128,7 +150,7 @@ export declare const workflowRunUnlistedPhaseSchema: z.ZodObject<{
 }, z.core.$strip>;
 export type WorkflowRunUnlistedPhase = z.infer<typeof workflowRunUnlistedPhaseSchema>;
 /**
- * run 级用量：观察面，不是控制面。`spentTokens` 直接取
+ * run 级用量：观察面，不是控制面（docs/dynamic-workflow/authoring.md）。`spentTokens` 直接取
  * 引擎 `usage-updated` 事件携带的已花总量（与 `dwf_run.spent_tokens` 同一同步步骤写入，
  * 二者永远相等）；`nodesUsed` 是本 run 已派发（dispatched）的节点数，由节点事件计数——
  * 没有任何上限可以拿来反算，也不需要。
@@ -150,8 +172,11 @@ export type WorkflowRunUsage = z.infer<typeof workflowRunUsageSchema>;
  *   - `completed`：其余（全部节点已结算，或 run 已终态）。
  * 不存在可观察的 actor 级 failed：某次 ask 失败仍是「它的活干完了」，结果在节点上。
  *
- * `sessionId` 是 actor 会话 id（phase 5 的 transcript 下钻直接读它）。它同样不在 Boundary C 上，
- * 而是 run service 按 `(runId, actorRef)` 确定性铸造的同一个函数算出来的。
+ * `sessionId` 是**持有这个子代理转录的那条会话**（transcript 下钻直接读它，
+ * docs/dynamic-workflow/presentation.md「Subagent transcripts」）。通常是 run service 按
+ * `(runId, actorRef)` 确定性铸造的本 run 会话；修订 run 里一个到目前为止全部答案都来自导入
+ * 命中的子代理没有自己的会话（命中不建会话），这时它是前驱里被读取的那条会话，由缓存结算的
+ * `sourceSessionId` 带来，第一次 live 派发之后换回本 run 的会话（种子已抄入前缀）。
  */
 export declare const workflowRunActorSchema: z.ZodObject<{
     siteId: z.ZodString;
@@ -160,10 +185,11 @@ export declare const workflowRunActorSchema: z.ZodObject<{
     sessionId: z.ZodOptional<z.ZodString>;
     status: z.ZodEnum<{
         running: "running";
-        completed: "completed";
         waiting: "waiting";
+        completed: "completed";
     }>;
     phaseName: z.ZodOptional<z.ZodString>;
+    model: z.ZodOptional<z.ZodString>;
 }, z.core.$strip>;
 export type WorkflowRunActor = z.infer<typeof workflowRunActorSchema>;
 /**
@@ -197,13 +223,13 @@ export declare const workflowRunNodeSchema: z.ZodObject<{
         "world-read": "world-read";
     }>>;
     phase: z.ZodEnum<{
-        queued: "queued";
-        executing: "executing";
         waiting: "waiting";
-        settled: "settled";
+        queued: "queued";
         dispatched: "dispatched";
+        executing: "executing";
         repairing: "repairing";
         nudged: "nudged";
+        settled: "settled";
     }>;
     outcome: z.ZodOptional<z.ZodEnum<{
         failed: "failed";
@@ -228,16 +254,17 @@ export type WorkflowRunNode = z.infer<typeof workflowRunNodeSchema>;
  * 实际并发是**两者取小**：
  *
  * - `cap`：本 run 所在 provider key 的**共享**闸门现状（治理器按 key 分桶、按 run 扇出，
- *   随 `concurrency-changed` 移动）；`ceiling`：CPU 推导的天花板。事件本身不带 ceiling，
- *   归约按该 run 见过的最大 `previous` / `next` 推导（桶从天花板起步，所以第一条事件的
- *   `previous` 就是它；只降不升的序列里它也恒是最大值）。
+ *   随 `concurrency-changed` 移动）。
+ * - `ceiling`：默认并发 D（线上键名早于「默认并发」，旧端还在读它，故保留）。它是参照线不是上限：
+ *   共享 cap 可以自动长到 2D，用户也可以把本 run 调到 D 之上。已知 `run.concurrencyCeiling` 时就取
+ *   它；只有老 CLI（不发 D）才退回「见过的最大 `previous` / `next`」。
  * - `limit`：本 run **自己的**界（`CreateWorkflow` / `AmendWorkflow` 的 `max_concurrency`
- *   落到 `caps.maxConcurrency`），随 `run-started` 到达、整条 run 不动。**只在低于天花板时
- *   在场**：跑在天花板上的 run 与从前一模一样，一个键都不多。
+ *   落到 `caps.maxConcurrency`），随 `run-started` 到达、就地 retune 时随 `run-caps-changed` 移动。
+ *   **只在 ≠ D 时在场**（高于低于都算）：跑在默认上的 run 与从前一模一样，一个键都不多。
  * - `cooldownMs`：带 Retry-After 的限流冻结新派发的时长，**相对量**（同 `retryInMs` 的理由）；
  *   `idle_reset` 与 run 终态清掉它。
  *
- * UI 只在 `min(cap, limit) < ceiling` 时显示读数（见 workflowRunConcurrencyView）。
+ * UI 的读数规则见 workflowRunConcurrencyView（docs/dynamic-workflow/concurrency.md「What the user sees」）。
  */
 export declare const workflowRunConcurrencySchema: z.ZodObject<{
     key: z.ZodOptional<z.ZodString>;
@@ -294,21 +321,47 @@ export declare const workflowRunPendingQuestionSchema: z.ZodObject<{
     askedAt: z.ZodOptional<z.ZodNumber>;
 }, z.core.$strip>;
 export type WorkflowRunPendingQuestion = z.infer<typeof workflowRunPendingQuestionSchema>;
+/**
+ * 一个留白（docs/dynamic-workflow/authoring.md「Holes」；投影侧见 docs/dynamic-workflow/presentation.md
+ * 「Holes on the timeline」）：脚本里一处 `hole<T>("名字")`，run 走到它就停驻那条分支、等主代理用
+ * `FillWorkflowHole` 补上代码。身份是**站点 id**（名字键 `hole#<8 位十六进制>`）：同一站点在循环里可以停驻多个 ordinal，
+ * 表里只留最新的那一个——补全是按站点一次性的，读面要说的也只是「这个留白等着 / 补上了」。
+ *
+ * `state`：`waiting` = 引擎里有停驻的 deferred（真相在 CLI 进程内，与 pendingQuestions 同族，所以新的
+ * 一世与终态都把它剥掉）；`filled` = 补全已接进 run（事实在 journal 的 `hole-filled` 事件里，跨世保留）。
+ * `type` 是作者写的类型原文；载荷不带它时缺席，读面退回 display 载荷的 `holes[].type` 按站点 id 取。
+ * `since` 是到达时刻（epoch 毫秒，由事件携带——本模块无时钟），`filledAt` / `filledBy` 随 `hole-filled` 到达。
+ */
+export declare const workflowRunHoleSchema: z.ZodObject<{
+    siteId: z.ZodString;
+    ordinal: z.ZodNumber;
+    name: z.ZodString;
+    type: z.ZodOptional<z.ZodString>;
+    prompt: z.ZodOptional<z.ZodString>;
+    state: z.ZodEnum<{
+        waiting: "waiting";
+        filled: "filled";
+    }>;
+    since: z.ZodOptional<z.ZodNumber>;
+    filledAt: z.ZodOptional<z.ZodNumber>;
+    filledBy: z.ZodOptional<z.ZodString>;
+}, z.core.$strip>;
+export type WorkflowRunHole = z.infer<typeof workflowRunHoleSchema>;
 export declare const workflowRunSchema: z.ZodObject<{
     runId: z.ZodString;
     toolCallId: z.ZodOptional<z.ZodString>;
     status: z.ZodEnum<{
-        pending: "pending";
         running: "running";
         completed: "completed";
-        stopped: "stopped";
+        pending: "pending";
         errored: "errored";
+        stopped: "stopped";
     }>;
     stopReason: z.ZodOptional<z.ZodEnum<{
-        interrupted: "interrupted";
-        user: "user";
-        model: "model";
         provider: "provider";
+        model: "model";
+        user: "user";
+        interrupted: "interrupted";
         superseded: "superseded";
     }>>;
     resumedFrom: z.ZodOptional<z.ZodString>;
@@ -329,10 +382,11 @@ export declare const workflowRunSchema: z.ZodObject<{
         sessionId: z.ZodOptional<z.ZodString>;
         status: z.ZodEnum<{
             running: "running";
-            completed: "completed";
             waiting: "waiting";
+            completed: "completed";
         }>;
         phaseName: z.ZodOptional<z.ZodString>;
+        model: z.ZodOptional<z.ZodString>;
     }, z.core.$strip>>;
     nodes: z.ZodArray<z.ZodObject<{
         siteId: z.ZodString;
@@ -342,13 +396,13 @@ export declare const workflowRunSchema: z.ZodObject<{
             "world-read": "world-read";
         }>>;
         phase: z.ZodEnum<{
-            queued: "queued";
-            executing: "executing";
             waiting: "waiting";
-            settled: "settled";
+            queued: "queued";
             dispatched: "dispatched";
+            executing: "executing";
             repairing: "repairing";
             nudged: "nudged";
+            settled: "settled";
         }>;
         outcome: z.ZodOptional<z.ZodEnum<{
             failed: "failed";
@@ -415,6 +469,21 @@ export declare const workflowRunSchema: z.ZodObject<{
     currentPhase: z.ZodOptional<z.ZodString>;
     phaseNames: z.ZodOptional<z.ZodArray<z.ZodString>>;
     phaseAlongside: z.ZodOptional<z.ZodArray<z.ZodArray<z.ZodNumber>>>;
+    phaseHoles: z.ZodOptional<z.ZodArray<z.ZodNumber>>;
+    holes: z.ZodOptional<z.ZodArray<z.ZodObject<{
+        siteId: z.ZodString;
+        ordinal: z.ZodNumber;
+        name: z.ZodString;
+        type: z.ZodOptional<z.ZodString>;
+        prompt: z.ZodOptional<z.ZodString>;
+        state: z.ZodEnum<{
+            waiting: "waiting";
+            filled: "filled";
+        }>;
+        since: z.ZodOptional<z.ZodNumber>;
+        filledAt: z.ZodOptional<z.ZodNumber>;
+        filledBy: z.ZodOptional<z.ZodString>;
+    }, z.core.$strip>>>;
     unlistedByPhase: z.ZodOptional<z.ZodArray<z.ZodObject<{
         phaseName: z.ZodOptional<z.ZodString>;
         actors: z.ZodNumber;
@@ -432,17 +501,17 @@ export declare const workflowRunsStateSchema: z.ZodObject<{
         runId: z.ZodString;
         toolCallId: z.ZodOptional<z.ZodString>;
         status: z.ZodEnum<{
-            pending: "pending";
             running: "running";
             completed: "completed";
-            stopped: "stopped";
+            pending: "pending";
             errored: "errored";
+            stopped: "stopped";
         }>;
         stopReason: z.ZodOptional<z.ZodEnum<{
-            interrupted: "interrupted";
-            user: "user";
-            model: "model";
             provider: "provider";
+            model: "model";
+            user: "user";
+            interrupted: "interrupted";
             superseded: "superseded";
         }>>;
         resumedFrom: z.ZodOptional<z.ZodString>;
@@ -463,10 +532,11 @@ export declare const workflowRunsStateSchema: z.ZodObject<{
             sessionId: z.ZodOptional<z.ZodString>;
             status: z.ZodEnum<{
                 running: "running";
-                completed: "completed";
                 waiting: "waiting";
+                completed: "completed";
             }>;
             phaseName: z.ZodOptional<z.ZodString>;
+            model: z.ZodOptional<z.ZodString>;
         }, z.core.$strip>>;
         nodes: z.ZodArray<z.ZodObject<{
             siteId: z.ZodString;
@@ -476,13 +546,13 @@ export declare const workflowRunsStateSchema: z.ZodObject<{
                 "world-read": "world-read";
             }>>;
             phase: z.ZodEnum<{
-                queued: "queued";
-                executing: "executing";
                 waiting: "waiting";
-                settled: "settled";
+                queued: "queued";
                 dispatched: "dispatched";
+                executing: "executing";
                 repairing: "repairing";
                 nudged: "nudged";
+                settled: "settled";
             }>;
             outcome: z.ZodOptional<z.ZodEnum<{
                 failed: "failed";
@@ -549,6 +619,21 @@ export declare const workflowRunsStateSchema: z.ZodObject<{
         currentPhase: z.ZodOptional<z.ZodString>;
         phaseNames: z.ZodOptional<z.ZodArray<z.ZodString>>;
         phaseAlongside: z.ZodOptional<z.ZodArray<z.ZodArray<z.ZodNumber>>>;
+        phaseHoles: z.ZodOptional<z.ZodArray<z.ZodNumber>>;
+        holes: z.ZodOptional<z.ZodArray<z.ZodObject<{
+            siteId: z.ZodString;
+            ordinal: z.ZodNumber;
+            name: z.ZodString;
+            type: z.ZodOptional<z.ZodString>;
+            prompt: z.ZodOptional<z.ZodString>;
+            state: z.ZodEnum<{
+                waiting: "waiting";
+                filled: "filled";
+            }>;
+            since: z.ZodOptional<z.ZodNumber>;
+            filledAt: z.ZodOptional<z.ZodNumber>;
+            filledBy: z.ZodOptional<z.ZodString>;
+        }, z.core.$strip>>>;
         unlistedByPhase: z.ZodOptional<z.ZodArray<z.ZodObject<{
             phaseName: z.ZodOptional<z.ZodString>;
             actors: z.ZodNumber;

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

@@ -12,10 +12,15 @@ export const WORKFLOW_RUNS_LIMITS = {
     /** 最近若干个 run；超出按最旧淘汰。 */
     maxRuns: 8,
     /**
-     * actors 与 nodes 使用相同的容量上限，避免节点可展示而所属子代理提前被截断。
-     * 键级增量使每个事件只传输改动部分；容量上限用于限制单条 run 的投影大小，
-     * 并限制异常脚本持续创建条目带来的资源消耗。跨 run 的总量由 {@link maxTotalEntries} 控制。
-     * 这是展示状态的容量限制，不限制引擎实际运行的子代理数量。
+     * actors 与 nodes **同界**。每个节点都属于某个 actor，所以 nodes 的界已经隐含了 actor
+     * 数的量级；把 actors 压得更低（曾是 32）只会让一个平常的 50 路 fan-out 在检视器里
+     * 静默少掉 18 个子代理，而节点表、引擎、图三层都装得下。
+     *
+     * 2026-09-20 从 256 抬到 1024：原来那条界的理由是「状态键按事件整体重发，无界即 O(N²)
+     * 字节」，而键级增量（workflow-runs-delta.ts）落地后每条事件只发改动量，那条理由没了。
+     * 剩下的两条理由都还在，而且都不需要 256 这么紧：挡住「疯掉的脚本在循环里 `agent()`」，
+     * 以及让单条 run 的字节数有个上界。**跨 run** 的总量另有 {@link maxTotalEntries} 管。
+     * 它仍然不是产品意义上的子代理上限。
      */
     maxActors: 1_024,
     maxNodes: 1_024,
@@ -29,7 +34,7 @@ export const WORKFLOW_RUNS_LIMITS = {
      */
     maxTotalEntries: 6_144,
     /**
-     * 详情页 Results 区的**展示**预算，刻意远小于引擎的 run 级 report 上限（256 条）：
+     * 详情页 Results 区的**展示**预算，刻意远小于引擎的 run 级 report 上限（`REPORT_CAPS.maxItemsPerRun`）：
      * 协议线上的界是展示预算，引擎的界才是契约，两者不必相等。超出这个界的条目仍在
      * journal 里（`dwf_node.kind = "report"`），只是不进这条高频状态键。
      */
@@ -53,7 +58,12 @@ export const WORKFLOW_RUNS_LIMITS = {
      */
     maxSubagentModelLength: 256,
     /**
-     * `run.concurrencyCeiling` 的上界。天花板按 `min(16, cores − 2)` 推导，这条界只挡坏载荷
+     * actor `sessionId` 的线上上界。会话 id 是铸出来或读出来的标识，不是展示文本：超界的值
+     * 整条丢弃而不是截断——一个被砍短的会话 id 指向的是另一条（或不存在的）会话。
+     */
+    maxSessionIdLength: 256,
+    /**
+     * `run.concurrencyCeiling`（默认并发 D）的上界。D 按 `max(4, min(16, cores − 2))` 推导，这条界只挡坏载荷
      * （reducer 读到界外的值当作读不出，沿用已知值）。
      */
     maxConcurrencyCeiling: 1_024,
@@ -77,6 +87,16 @@ export const WORKFLOW_RUNS_LIMITS = {
     maxPhases: 32,
     /** 阶段名的线上上界，与 display 的 `CREATE_WORKFLOW_GRAPH_MAX_NAME_CHARS` 同值（UI 按名字关联两边）。 */
     maxPhaseNameLength: 128,
+    /**
+     * 一条 run 记得的留白条数（docs/dynamic-workflow/presentation.md「Holes on the timeline」）。与 display
+     * 载荷的 `holes` 同界：时间线上画不出的留白，投影里也不必记。一个留白就是一个阶段，所以它天然
+     * 不会多过 `maxPhases`。
+     */
+    maxHoles: 32,
+    /** 留白类型原文（`Plan`）的线上上界，与 display 的同名字段同值。 */
+    maxHoleTypeLength: 128,
+    /** 留白的提示语在 run 状态里的上限（侧板等待体要画它）；超长时截到 499 字加 `…`。 */
+    maxHolePromptLength: 500,
     /**
      * 一次 ask 的**任务摘要**上界（`node-queued` 的 `instructionsHead`）。与引擎侧的
      * `INSTRUCTIONS_HEAD_MAX_CHARS` 同值：那一头已经按这条界切好，这里是线上的第二道闸。
@@ -97,7 +117,8 @@ export const WORKFLOW_RUNS_LIMITS = {
  * **旧消费者**（没有 `workflowRunDeltas` 能力的那一代）编译进去的 actors / nodes 界。
  *
  * ⚠ 这两个数**永远不能改**：它们不是我们的界，是别人二进制里的校验界。超界的载荷不会被
- * 剥掉一个键——它会让整个 `state.updated` patch 解析失败、整帧被丢，那条订阅从此静默。所以给这类订阅者
+ * 剥掉一个键——它会让整个 `state.updated` patch 解析失败、整帧被丢，那条订阅从此静默
+ * （2026-09-04 的那次 `fault.subscription.recoveryFailed` 就是这个形状）。所以给这类订阅者
  * 发帧前必须先过 `clampWorkflowRunsForLegacy`。
  *
  * 「前 256 条」不是随手取的：旧归约触界时是**拒新**，它产出的恰好就是最早的那 256 条。
@@ -107,7 +128,8 @@ export const WORKFLOW_RUNS_LEGACY_LIMITS = {
     maxNodes: 256,
 };
 /**
- * 一个被控制流进入过的阶段（`phase("…")` 标记）。`name` 是作者原词（时间线按它关联 display 的 `phases[].name`）；`rounds` 是进入
+ * 一个被控制流进入过的阶段（`phase("…")` 标记；docs/dynamic-workflow/presentation.md
+ * 2026-09-05）。`name` 是作者原词（时间线按它关联 display 的 `phases[].name`）；`rounds` 是进入
  * 次数——单调（reducer 取 max），所以 resume 重放的前缀不会把它加倍。
  */
 export const workflowRunPhaseSchema = z.object({
@@ -115,7 +137,7 @@ export const workflowRunPhaseSchema = z.object({
     rounds: z.number().int().positive(),
 });
 /**
- * 界在某个**出生阶段**上花掉了多少。
+ * 界在某个**出生阶段**上花掉了多少（docs/dynamic-workflow/presentation.md「Reduction」）。
  *
  * 两个计数器（{@link workflowRunUsageSchema} 的 `nodesUnlisted` / `nodesUnlistedSettled`）说得出
  * 一条 run 总共少列了多少，说不出少在**哪一站**——而读面是按站画的：一个站点的花名册、计数环和
@@ -135,7 +157,7 @@ export const workflowRunUnlistedPhaseSchema = z.object({
     settled: z.number().int().nonnegative(),
 });
 /**
- * run 级用量：观察面，不是控制面。`spentTokens` 直接取
+ * run 级用量：观察面，不是控制面（docs/dynamic-workflow/authoring.md）。`spentTokens` 直接取
  * 引擎 `usage-updated` 事件携带的已花总量（与 `dwf_run.spent_tokens` 同一同步步骤写入，
  * 二者永远相等）；`nodesUsed` 是本 run 已派发（dispatched）的节点数，由节点事件计数——
  * 没有任何上限可以拿来反算，也不需要。
@@ -144,7 +166,8 @@ export const workflowRunUsageSchema = z.object({
     spentTokens: z.number().int().nonnegative(),
     nodesUsed: z.number().int().nonnegative(),
     /**
-     * 撞上 {@link WORKFLOW_RUNS_LIMITS.maxNodes} 被**拒之表外**的实例数，以及其中已结算的条数。`truncated` 只说得出「有东西没进来」，说不出
+     * 撞上 {@link WORKFLOW_RUNS_LIMITS.maxNodes} 被**拒之表外**的实例数，以及其中已结算的条数
+     * （docs/dynamic-workflow/presentation.md）。`truncated` 只说得出「有东西没进来」，说不出
      * 有多少——于是一个 3000 路 fan-out 的 run 在读面上会显示成「1024 步」，那是一句假话。
      *
      * 两条都是**加出来**的计数（被拒实例根本不在表里，没有可去重的身份），所以归约只在事件
@@ -164,14 +187,17 @@ export const workflowRunUsageSchema = z.object({
  *   - `completed`：其余（全部节点已结算，或 run 已终态）。
  * 不存在可观察的 actor 级 failed：某次 ask 失败仍是「它的活干完了」，结果在节点上。
  *
- * `sessionId` 是 actor 会话 id（phase 5 的 transcript 下钻直接读它）。它同样不在 Boundary C 上，
- * 而是 run service 按 `(runId, actorRef)` 确定性铸造的同一个函数算出来的。
+ * `sessionId` 是**持有这个子代理转录的那条会话**（transcript 下钻直接读它，
+ * docs/dynamic-workflow/presentation.md「Subagent transcripts」）。通常是 run service 按
+ * `(runId, actorRef)` 确定性铸造的本 run 会话；修订 run 里一个到目前为止全部答案都来自导入
+ * 命中的子代理没有自己的会话（命中不建会话），这时它是前驱里被读取的那条会话，由缓存结算的
+ * `sourceSessionId` 带来，第一次 live 派发之后换回本 run 的会话（种子已抄入前缀）。
  */
 export const workflowRunActorSchema = z.object({
     siteId: z.string().min(1).max(64),
     ordinal: z.number().int().nonnegative(),
     name: z.string().min(1).max(WORKFLOW_RUNS_LIMITS.maxActorNameLength).optional(),
-    sessionId: z.string().min(1).max(256).optional(),
+    sessionId: z.string().min(1).max(WORKFLOW_RUNS_LIMITS.maxSessionIdLength).optional(),
     status: z.enum(["waiting", "running", "completed"]),
     /**
      * 这个实例**出生**在哪个阶段：它的 ordinal 被铸造的那一刻，控制流所在的 `phase("…")` 标记名。UI 按**名字**与 `phases[].name`
@@ -181,6 +207,12 @@ export const workflowRunActorSchema = z.object({
      * 或者发事件的是不带这个键的旧 CLI。
      */
     phaseName: z.string().min(1).max(WORKFLOW_RUNS_LIMITS.maxPhaseNameLength).optional(),
+    /**
+     * 这个子代理的模型：persona 点名了模型时，宿主按本 run 的绑定表解析出的规范串
+     * `providerId/modelId[$level]`（docs/dynamic-workflow/presentation.md「Reduction」）。缺席即它跑在
+     * run 的子代理模型上（或发事件的是不带这个键的旧 CLI）。与 `subagentModel` 同界。
+     */
+    model: z.string().min(1).max(WORKFLOW_RUNS_LIMITS.maxSubagentModelLength).optional(),
 });
 /**
  * 一次 ask 里**最近一次**工具调用（`node-progress` 携带）。`name` 是工具名；`target` 是一个
@@ -258,16 +290,17 @@ export const workflowRunNodeSchema = z.object({
  * 实际并发是**两者取小**：
  *
  * - `cap`：本 run 所在 provider key 的**共享**闸门现状（治理器按 key 分桶、按 run 扇出，
- *   随 `concurrency-changed` 移动）；`ceiling`：CPU 推导的天花板。事件本身不带 ceiling，
- *   归约按该 run 见过的最大 `previous` / `next` 推导（桶从天花板起步，所以第一条事件的
- *   `previous` 就是它；只降不升的序列里它也恒是最大值）。
+ *   随 `concurrency-changed` 移动）。
+ * - `ceiling`：默认并发 D（线上键名早于「默认并发」，旧端还在读它，故保留）。它是参照线不是上限：
+ *   共享 cap 可以自动长到 2D，用户也可以把本 run 调到 D 之上。已知 `run.concurrencyCeiling` 时就取
+ *   它；只有老 CLI（不发 D）才退回「见过的最大 `previous` / `next`」。
  * - `limit`：本 run **自己的**界（`CreateWorkflow` / `AmendWorkflow` 的 `max_concurrency`
- *   落到 `caps.maxConcurrency`），随 `run-started` 到达、整条 run 不动。**只在低于天花板时
- *   在场**：跑在天花板上的 run 与从前一模一样，一个键都不多。
+ *   落到 `caps.maxConcurrency`），随 `run-started` 到达、就地 retune 时随 `run-caps-changed` 移动。
+ *   **只在 ≠ D 时在场**（高于低于都算）：跑在默认上的 run 与从前一模一样，一个键都不多。
  * - `cooldownMs`：带 Retry-After 的限流冻结新派发的时长，**相对量**（同 `retryInMs` 的理由）；
  *   `idle_reset` 与 run 终态清掉它。
  *
- * UI 只在 `min(cap, limit) < ceiling` 时显示读数（见 workflowRunConcurrencyView）。
+ * UI 的读数规则见 workflowRunConcurrencyView（docs/dynamic-workflow/concurrency.md「What the user sees」）。
  */
 export const workflowRunConcurrencySchema = z.object({
     key: z.string().min(1).max(WORKFLOW_RUNS_LIMITS.maxConcurrencyKeyLength).optional(),
@@ -335,6 +368,29 @@ export const workflowRunPendingQuestionSchema = z.object({
      */
     askedAt: z.number().int().nonnegative().optional(),
 });
+/**
+ * 一个留白（docs/dynamic-workflow/authoring.md「Holes」；投影侧见 docs/dynamic-workflow/presentation.md
+ * 「Holes on the timeline」）：脚本里一处 `hole<T>("名字")`，run 走到它就停驻那条分支、等主代理用
+ * `FillWorkflowHole` 补上代码。身份是**站点 id**（名字键 `hole#<8 位十六进制>`）：同一站点在循环里可以停驻多个 ordinal，
+ * 表里只留最新的那一个——补全是按站点一次性的，读面要说的也只是「这个留白等着 / 补上了」。
+ *
+ * `state`：`waiting` = 引擎里有停驻的 deferred（真相在 CLI 进程内，与 pendingQuestions 同族，所以新的
+ * 一世与终态都把它剥掉）；`filled` = 补全已接进 run（事实在 journal 的 `hole-filled` 事件里，跨世保留）。
+ * `type` 是作者写的类型原文；载荷不带它时缺席，读面退回 display 载荷的 `holes[].type` 按站点 id 取。
+ * `since` 是到达时刻（epoch 毫秒，由事件携带——本模块无时钟），`filledAt` / `filledBy` 随 `hole-filled` 到达。
+ */
+export const workflowRunHoleSchema = z.object({
+    siteId: z.string().min(1).max(64),
+    ordinal: z.number().int().nonnegative(),
+    name: z.string().min(1).max(WORKFLOW_RUNS_LIMITS.maxPhaseNameLength),
+    type: z.string().min(1).max(WORKFLOW_RUNS_LIMITS.maxHoleTypeLength).optional(),
+    /** 主代理收到的提示语（`hole-reached` 载荷的 `prompt`），已按 {@link WORKFLOW_RUNS_LIMITS.maxHolePromptLength} 截断。 */
+    prompt: z.string().min(1).max(WORKFLOW_RUNS_LIMITS.maxHolePromptLength).optional(),
+    state: z.enum(["waiting", "filled"]),
+    since: z.number().int().nonnegative().optional(),
+    filledAt: z.number().int().nonnegative().optional(),
+    filledBy: z.string().min(1).max(128).optional(),
+});
 export const workflowRunSchema = z.object({
     runId: z.string().min(1).max(128),
     /** 发起该 run 的 CreateWorkflow 工具调用（工具卡 → 详情页的关联键）。 */
@@ -388,16 +444,18 @@ export const workflowRunSchema = z.object({
         .max(WORKFLOW_RUNS_LIMITS.maxPendingQuestions)
         .optional(),
     /**
-     * 并发现状（见 {@link workflowRunConcurrencySchema}）。只在**两条界里有一条低于天花板**时
-     * 在场：收到过 `concurrency-changed`（共享桶被限流压低），或 `run-started` 带来一个低于天花板
-     * 的 `limit`（用户给这次 run 定了上限）。两者都没有的 run 一直跑在天花板上，没有可说的。
+     * 并发现状（见 {@link workflowRunConcurrencySchema}）。收到过 `concurrency-changed`（共享桶动过），
+     * 或 `run-started` / `run-caps-changed` 带来一个 ≠ 默认并发的 `limit`（用户给这次 run 定了界）时
+     * 在场。两者都没有的 run 一直跑在默认上，没有可说的。
      * optional 的理由与 `reports` / `pendingQuestions` 同。
      */
     concurrency: workflowRunConcurrencySchema.optional(),
     /**
-     * 本机的并发天花板（`run-started` 载荷的 `concurrencyCeiling`，CLI 铸载荷时拼进去的进程事实）。
-     * 与 `concurrency.ceiling` 不同：那是读数芯片自己的水位，只随芯片在场；这一个**只要读得到就在**，
-     * 不论本 run 是否低于它——「配置」弹层的步进器停在这里。optional 的理由与 `concurrency` 同：老 CLI 不发，少一个键是退化。
+     * 默认并发 D（`run-started` 载荷的 `concurrencyCeiling`，CLI 铸载荷时拼进去的进程事实；键名早于
+     * 「默认并发」这个概念，为兼容旧端保留）。它是起点不是上限。与 `concurrency` 不同，它**只要读得到
+     * 就在**，不论本 run 有没有自己的界——「配置」弹层据它写「默认 N」、判「等于默认 = 不设自己的界」
+     * （docs/dynamic-workflow/concurrency.md「Protocol state」）。optional 的理由与 `concurrency` 同：
+     * 老 CLI 不发，少一个键是退化。
      */
     concurrencyCeiling: z
         .number()
@@ -460,6 +518,23 @@ export const workflowRunSchema = z.object({
         .array(z.array(z.number().int().nonnegative()).max(WORKFLOW_RUNS_LIMITS.maxPhases))
         .max(WORKFLOW_RUNS_LIMITS.maxPhases)
         .optional(),
+    /**
+     * `phaseNames` 里哪几站是**还开着的留白**（下标表，`run-launched.holes` / `hole-filled.holes`；
+     * docs/dynamic-workflow/presentation.md「Holes on the timeline」的「The model」）。侧栏只从 `phaseNames`
+     * 画迷你轨道，没有 display 载荷可查，所以这张表是它把留白画成虚线灯的唯一依据。补全之后那一站
+     * 不再是留白，表随 `hole-filled` 整张换新。依附 `phaseNames`：后者不在场时它一定不在场；一个都没有
+     * 时同样缺席。
+     */
+    phaseHoles: z
+        .array(z.number().int().nonnegative())
+        .max(WORKFLOW_RUNS_LIMITS.maxPhases)
+        .optional(),
+    /**
+     * 这条 run 的留白（见 {@link workflowRunHoleSchema}），按首次到达顺序。**零条时整个键缺席**，与
+     * `pendingQuestions` 同规。optional 的理由与 `reports` 逐字相同：往已有状态键追加字段，旧 CLI 不发它
+     * 时少一个键是退化，不是整帧被丢。
+     */
+    holes: z.array(workflowRunHoleSchema).max(WORKFLOW_RUNS_LIMITS.maxHoles).optional(),
     /**
      * 界在各个出生阶段上花掉了多少（见 {@link workflowRunUnlistedPhaseSchema}）。**一格都没有时
      * 整个键缺席**。表长比 `maxPhases` 多一格：那一格是「无阶段」，它与具名阶段共用同一张表。

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

@@ -19,9 +19,9 @@ export declare const workflowRunWorkspaceNodeKindSchema: z.ZodEnum<{
 export type WorkflowRunWorkspaceNodeKind = z.infer<typeof workflowRunWorkspaceNodeKindSchema>;
 /** journal 行的状态（`NodeRecordStatus` 的线上镜像）。 */
 export declare const workflowRunWorkspaceNodeStatusSchema: z.ZodEnum<{
+    failed: "failed";
     running: "running";
     completed: "completed";
-    failed: "failed";
 }>;
 export type WorkflowRunWorkspaceNodeStatus = z.infer<typeof workflowRunWorkspaceNodeStatusSchema>;
 /** 结构化失败：journal `error_json` 的 code + message（其余字段不出协议）。 */
@@ -58,9 +58,9 @@ export declare const workflowRunWorkspaceNodeSchema: z.ZodObject<{
     args: z.ZodOptional<z.ZodArray<z.ZodUnknown>>;
     inputTruncated: z.ZodOptional<z.ZodLiteral<true>>;
     status: z.ZodEnum<{
+        failed: "failed";
         running: "running";
         completed: "completed";
-        failed: "failed";
     }>;
     error: z.ZodOptional<z.ZodObject<{
         code: z.ZodString;
@@ -94,9 +94,9 @@ export declare const v4ConversationWorkflowRunWorkspaceResultSchema: z.ZodObject
         args: z.ZodOptional<z.ZodArray<z.ZodUnknown>>;
         inputTruncated: z.ZodOptional<z.ZodLiteral<true>>;
         status: z.ZodEnum<{
+            failed: "failed";
             running: "running";
             completed: "completed";
-            failed: "failed";
         }>;
         error: z.ZodOptional<z.ZodObject<{
             code: z.ZodString;
@@ -125,9 +125,9 @@ export declare const v4ConversationWorkflowRunNodeResultParamsSchema: z.ZodObjec
 export type V4ConversationWorkflowRunNodeResultParams = z.infer<typeof v4ConversationWorkflowRunNodeResultParamsSchema>;
 export declare const v4ConversationWorkflowRunNodeResultResultSchema: z.ZodObject<{
     status: z.ZodEnum<{
+        failed: "failed";
         running: "running";
         completed: "completed";
-        failed: "failed";
     }>;
     result: z.ZodOptional<z.ZodUnknown>;
     error: z.ZodOptional<z.ZodObject<{

package/node_modules/@dcode/shared/dist/dcode-protocol-v4/workspace-hook-review.d.ts

@@ -87,8 +87,8 @@ export declare const workspaceHookReviewRequestPayloadSchema: z.ZodObject<{
         resolvedTimeoutMs: z.ZodNumber;
         resolvedMaxOutputBytes: z.ZodNumber;
         executionMode: z.ZodEnum<{
-            foreground: "foreground";
             background: "background";
+            foreground: "foreground";
         }>;
         configuredEnabled: z.ZodBoolean;
         editable: z.ZodBoolean;

package/node_modules/@dcode/shared/dist/dcode-session-content-profile.d.ts

@@ -0,0 +1,5 @@
+import type { DCodeSessionStateSnapshot } from "./dcode-protocol/index.js";
+export type DCodeSessionContentProfile = "full" | "index";
+/** 生成 task index 专用的轻量 snapshot；不修改入参（CLI 侧 messages 可能来自共享缓存）。 */
+export declare function elideSessionSnapshotForIndex<T extends DCodeSessionStateSnapshot>(snapshot: T): T;
+//# sourceMappingURL=dcode-session-content-profile.d.ts.map