@sunshaobei/dsh-workflow 0.0.0-stage → 2.1.0

package/vendor/dynamic-workflow/engine/persona.d.ts

@@ -0,0 +1,20 @@
+import type { PersonaSpec } from "./types.js";
+/**
+ * persona 规范化：字符串视为 system prompt；display name 落到 persona.name。
+ *
+ * 对象 persona 只取认得的三个键、且只收字符串值：它来自沙箱的线上 JSON，而 persona 会原样落进
+ * journal、进缓存比对与宿主的建会话路径——一个脚本经类型断言塞进来的怪值（`model: 42`、多余
+ * 的键）不该一路搬下去。`model` 缺席即「跑 run 的子代理模型」。
+ */
+export declare function normalizePersona(name: string | undefined, persona: string | PersonaSpec | undefined): PersonaSpec;
+/**
+ * persona 里参与缓存身份比对的部分：名字与 system prompt，**不含 `model`**
+ * （docs/dynamic-workflow/authoring.md「Choosing a model per subagent」）。
+ *
+ * 换模型与改 persona 不是一回事：旧 system prompt 产的转录接新 persona 是身份错乱，而「这个
+ * 子代理改跑另一个模型」是用户对**接下来**的工作的显式选择——与 `AmendWorkflow` 带
+ * `subagent_model` 同一条规则（execution-engine.md「Subagent sessions」）：已完成的活照旧导入，
+ * 下一次 live ask 跑在新模型上。把 model 算进身份，改一个裁判的模型就会让它整段重跑。
+ */
+export declare function personaIdentity(persona: PersonaSpec): PersonaSpec;
+//# sourceMappingURL=persona.d.ts.map

package/vendor/dynamic-workflow/engine/persona.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"persona.d.ts","sourceRoot":"","sources":["../../src/engine/persona.ts"],"names":[],"mappings":"AAMA,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,YAAY,CAAC;AAE9C;;;;;;GAMG;AACH,wBAAgB,gBAAgB,CAC9B,IAAI,EAAE,MAAM,GAAG,SAAS,EACxB,OAAO,EAAE,MAAM,GAAG,WAAW,GAAG,SAAS,GACxC,WAAW,CAWb;AAED;;;;;;;;GAQG;AACH,wBAAgB,eAAe,CAAC,OAAO,EAAE,WAAW,GAAG,WAAW,CAIjE"}

package/vendor/dynamic-workflow/engine/persona.js

@@ -0,0 +1,43 @@
+// ============================================================
+// actor persona 的两个纯函数：规范化（createActor）与缓存身份（matchImportedActor）
+// ============================================================
+// 从 engine.ts / imported-cache.ts 拆出：两者都是「persona 里哪些东西算数」的回答，住在一处才不会
+// 一边加了字段、另一边忘了排除（docs/execution-engine.md「Engine-side persona」）。
+/**
+ * persona 规范化：字符串视为 system prompt；display name 落到 persona.name。
+ *
+ * 对象 persona 只取认得的三个键、且只收字符串值：它来自沙箱的线上 JSON，而 persona 会原样落进
+ * journal、进缓存比对与宿主的建会话路径——一个脚本经类型断言塞进来的怪值（`model: 42`、多余
+ * 的键）不该一路搬下去。`model` 缺席即「跑 run 的子代理模型」。
+ */
+export function normalizePersona(name, persona) {
+    const base = {};
+    if (typeof persona === "string") {
+        base.system = persona;
+    }
+    else if (persona !== null && typeof persona === "object") {
+        if (typeof persona.name === "string")
+            base.name = persona.name;
+        if (typeof persona.system === "string")
+            base.system = persona.system;
+        if (typeof persona.model === "string")
+            base.model = persona.model;
+    }
+    if (base.name === undefined && name !== undefined)
+        base.name = name;
+    return base;
+}
+/**
+ * persona 里参与缓存身份比对的部分：名字与 system prompt，**不含 `model`**
+ * （docs/dynamic-workflow/authoring.md「Choosing a model per subagent」）。
+ *
+ * 换模型与改 persona 不是一回事：旧 system prompt 产的转录接新 persona 是身份错乱，而「这个
+ * 子代理改跑另一个模型」是用户对**接下来**的工作的显式选择——与 `AmendWorkflow` 带
+ * `subagent_model` 同一条规则（execution-engine.md「Subagent sessions」）：已完成的活照旧导入，
+ * 下一次 live ask 跑在新模型上。把 model 算进身份，改一个裁判的模型就会让它整段重跑。
+ */
+export function personaIdentity(persona) {
+    const { model: _model, ...identity } = persona;
+    void _model;
+    return identity;
+}

package/vendor/dynamic-workflow/engine/replay-order.d.ts

@@ -0,0 +1,96 @@
+/**
+ * Replay 的**结算次序闸**（docs/execution-engine.md「Replaying the settle order」）。
+ *
+ * 站点序号是调用到达时的计数器，所以一条分支在 await **之后**做的每一次 journal 调用，
+ * 编号依的是扇出完成的顺序，而不是脚本发起的顺序。那个顺序是墙钟的，节点行里没有任何东西
+ * 能复现它：按准入顺序释放缓存结算，重放的 `Promise.all` 会按数组顺序跑续体，join 之后的第一条
+ * `report` 于是拿到 journal 给「最先跑完的那条分支」的序号，run 死在自己的防御性校验里
+ * （`InputHashMismatch`），被指认为不确定的却是一个纯脚本。2026-09-17 实盘：五路并行调研，
+ * 完成顺序 1、4、2、5、3，resume 在 report#2@2 上炸。
+ *
+ * 所以 resume 重放的是**调度**，不只是答案：本闸持有首生的结算次序，命中缓存的结算在释放点
+ * 挂起，直到它前面的每一条都已释放。次序表之外的实例直接放行——闸门只约束它有证据的那些，
+ * 因此对旧 journal（事件早于本规则）退化成原行为，也不可能把一个它一无所知的 run 锁死。
+ */
+import type { InstanceRef, JournalStorePort, NodeKind, NodeRecord } from "./types.js";
+/**
+ * 重放时一定会兑现一个 promise 的节点 kind：除 `report`（void）与 `artifact`（要看成员族，
+ * 见 {@link claimsOnReplay}）之外的全部。从 {@link NODE_KINDS} 派生：新增的 kind 默认算进来。
+ */
+export declare const REPLAY_WORK_KINDS: readonly NodeKind[];
+/**
+ * 结算次序要的节点行：工作行**不带结果**（只看 kind / status / 坐标），产物行带结果（成员族在
+ * `result.kind` 上，而产物行有界：32 个 id × 每 id 16 版）。报告行一条都不读——它们从不认领
+ * 闸门，而一个 run 可以有 65,536 条（docs/execution-engine.md「Reading the journal」）。
+ */
+export declare function readReplayRows(journal: JournalStorePort, runId: string): {
+    workRows: NodeRecord[];
+    artifactRows: NodeRecord[];
+};
+export declare class ReplaySettleOrder {
+    private readonly order;
+    /** 实例键 → 它在首生结算次序里的位置。 */
+    private readonly position;
+    /** 已释放到哪一位（次序表的游标）。 */
+    private cursor;
+    /** 已到达、正在等自己那一位的释放动作。 */
+    private readonly parked;
+    /** 已轮到、排在微任务里等着投递的释放动作（FIFO，见 {@link enqueue}）。 */
+    private queue;
+    private flushing;
+    /** run 结算后闸门永久打开（见 {@link open}）。 */
+    private opened;
+    constructor(order?: readonly string[]);
+    static empty(): ReplaySettleOrder;
+    /** 首生的结算次序（诊断与测试用）。 */
+    recorded(): readonly string[];
+    /**
+     * 受次序约束地释放一次 replay 命中。表里没有这个实例（全新调用、旧 journal）、闸门已打开、
+     * 或它的位次已被越过时立即执行；否则挂起，等轮到它。
+     */
+    hold(instance: InstanceRef, release: () => void): void;
+    /**
+     * 投递永远晚于**产生这个 promise 的那次调用**：释放动作先进队列，一个微任务之后才执行。
+     *
+     * 少了这一跳，次序就是反的：`Promise.all` 里每条分支都在同一个同步片里发起自己的调用，
+     * 队首那条的释放会**在它自己的 `ask()` 里**同步发生——那时它的 `await` 还没挂上去，于是
+     * 它的续体排在「早先已挂上、刚被这次 pump 兑现」的那条后面。微任务这一跳让所有 `await`
+     * 先挂稳，投递次序因此就是释放次序。这不是时钟：跳的是确定的一步，队列是 FIFO。
+     */
+    private enqueue;
+    /** 把排好的投递按 FIFO 执行完（队列空即空跑，故重复调用安全）。 */
+    private flush;
+    /**
+     * run 结算：闸门永久打开，挂起的按记录次序放完。
+     *
+     * 不放的后果是脚本那侧的 promise 永远不兑现——在 harness 里沙箱马上就被关掉，但在同进程
+     * 跑脚本的装配（引擎测试、`EvalWorkflowSnippet`）里那就是一次挂死。结算之后释放是安全的：
+     * 引擎已 markSettled，每条 host 路径都以 `isRunSettled()` 开头。
+     */
+    open(): void;
+    /** 游标能往前走多少就走多少：队首已到达即释放，然后看下一位。 */
+    private pump;
+}
+/**
+ * 从 run 自己的事件日志恢复首生的结算次序。
+ *
+ * 事实来源是事件而不是新列：结算次序**本来就**逐条记在 `dwf_event` 里，而它与 journal 行同一次
+ * 写入落库；读回来既不用迁移，也让本规则之前跑出来的 journal 立刻可 resume（本地库里 258 个 run
+ * 有 54 个正卡在这个形状上）。同一条路 `recoverImportClosure` 已经走过（零 schema 变更地从事件
+ * 次序恢复关门判定）。
+ *
+ * 只收**每个实例首次**结算的那一条：重放的一世会按本闸释放的次序再发一遍 cached 事件，取首次
+ * 因而跨世稳定，第三世恢复出的仍是同一张表。
+ *
+ * 表里只留「重放时会兑现一个 promise 的终态行」：`report` 是 void、预置产物声明是同步的，两者
+ * 永远不会来认领，留在表里就会把游标堵死；仍是 `running` 的行按重新 live 执行处理，也不认领。
+ */
+export declare function recoverSettleOrder(journal: JournalStorePort, runId: string, 
+/** 已读好的节点行（引擎的 resume 分支本来就要读一次，传进来省掉第二次读）。 */
+nodes?: readonly NodeRecord[]): ReplaySettleOrder;
+/**
+ * 受次序闸约束地兑现一次 replay 命中：轮到它时才执行 `settle` 并按其结果兑现 / 拒绝。
+ * 给的是 promise 路径（world 节点与内容产物）；ask 的释放本就是回调，直接用 {@link ReplaySettleOrder.hold}。
+ */
+export declare function heldResolution<T>(hold: (instance: InstanceRef, release: () => void) => void, instance: InstanceRef, settle: () => T): Promise<T>;
+//# sourceMappingURL=replay-order.d.ts.map

package/vendor/dynamic-workflow/engine/replay-order.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"replay-order.d.ts","sourceRoot":"","sources":["../../src/engine/replay-order.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;GAaG;AAIH,OAAO,KAAK,EAAE,WAAW,EAAE,gBAAgB,EAAE,QAAQ,EAAE,UAAU,EAAY,MAAM,YAAY,CAAC;AAGhG;;;GAGG;AACH,eAAO,MAAM,iBAAiB,EAAE,SAAS,QAAQ,EAEhD,CAAC;AASF;;;;GAIG;AACH,wBAAgB,cAAc,CAC5B,OAAO,EAAE,gBAAgB,EACzB,KAAK,EAAE,MAAM,GACZ;IAAE,QAAQ,EAAE,UAAU,EAAE,CAAC;IAAC,YAAY,EAAE,UAAU,EAAE,CAAA;CAAE,CAKxD;AAED,qBAAa,iBAAiB;IAahB,OAAO,CAAC,QAAQ,CAAC,KAAK;IAZlC,0BAA0B;IAC1B,OAAO,CAAC,QAAQ,CAAC,QAAQ,CAA8B;IACvD,uBAAuB;IACvB,OAAO,CAAC,MAAM,CAAK;IACnB,yBAAyB;IACzB,OAAO,CAAC,QAAQ,CAAC,MAAM,CAAiC;IACxD,mDAAmD;IACnD,OAAO,CAAC,KAAK,CAAyB;IACtC,OAAO,CAAC,QAAQ,CAAS;IACzB,qCAAqC;IACrC,OAAO,CAAC,MAAM,CAAS;gBAEM,KAAK,GAAE,SAAS,MAAM,EAAO;IAM1D,MAAM,CAAC,KAAK,IAAI,iBAAiB;IAIjC,uBAAuB;IACvB,QAAQ,IAAI,SAAS,MAAM,EAAE;IAI7B;;;OAGG;IACH,IAAI,CAAC,QAAQ,EAAE,WAAW,EAAE,OAAO,EAAE,MAAM,IAAI,GAAG,IAAI;IAWtD;;;;;;;OAOG;IACH,OAAO,CAAC,OAAO;IAOf,wCAAwC;IACxC,OAAO,CAAC,KAAK;IAOb;;;;;;OAMG;IACH,IAAI,IAAI,IAAI;IAqBZ,oCAAoC;IACpC,OAAO,CAAC,IAAI;CAWb;AAED;;;;;;;;;;;;;GAaG;AACH,wBAAgB,kBAAkB,CAChC,OAAO,EAAE,gBAAgB,EACzB,KAAK,EAAE,MAAM;AACb,+CAA+C;AAC/C,KAAK,GAAE,SAAS,UAAU,EAAyD,GAClF,iBAAiB,CAqBnB;AA2BD;;;GAGG;AACH,wBAAgB,cAAc,CAAC,CAAC,EAC9B,IAAI,EAAE,CAAC,QAAQ,EAAE,WAAW,EAAE,OAAO,EAAE,MAAM,IAAI,KAAK,IAAI,EAC1D,QAAQ,EAAE,WAAW,EACrB,MAAM,EAAE,MAAM,CAAC,GACd,OAAO,CAAC,CAAC,CAAC,CAUZ"}

package/vendor/dynamic-workflow/engine/replay-order.js

@@ -0,0 +1,229 @@
+/**
+ * Replay 的**结算次序闸**（docs/execution-engine.md「Replaying the settle order」）。
+ *
+ * 站点序号是调用到达时的计数器，所以一条分支在 await **之后**做的每一次 journal 调用，
+ * 编号依的是扇出完成的顺序，而不是脚本发起的顺序。那个顺序是墙钟的，节点行里没有任何东西
+ * 能复现它：按准入顺序释放缓存结算，重放的 `Promise.all` 会按数组顺序跑续体，join 之后的第一条
+ * `report` 于是拿到 journal 给「最先跑完的那条分支」的序号，run 死在自己的防御性校验里
+ * （`InputHashMismatch`），被指认为不确定的却是一个纯脚本。2026-09-17 实盘：五路并行调研，
+ * 完成顺序 1、4、2、5、3，resume 在 report#2@2 上炸。
+ *
+ * 所以 resume 重放的是**调度**，不只是答案：本闸持有首生的结算次序，命中缓存的结算在释放点
+ * 挂起，直到它前面的每一条都已释放。次序表之外的实例直接放行——闸门只约束它有证据的那些，
+ * 因此对旧 journal（事件早于本规则）退化成原行为，也不可能把一个它一无所知的 run 锁死。
+ */
+import { isArtifactPresetOp } from "../facade/registry.js";
+import { NODE_KINDS } from "./journal-read-types.js";
+import { refToString } from "./types.js";
+/**
+ * 重放时一定会兑现一个 promise 的节点 kind：除 `report`（void）与 `artifact`（要看成员族，
+ * 见 {@link claimsOnReplay}）之外的全部。从 {@link NODE_KINDS} 派生：新增的 kind 默认算进来。
+ */
+export const REPLAY_WORK_KINDS = NODE_KINDS.filter((kind) => kind !== "report" && kind !== "artifact");
+/** 结算次序只看这三种事件（{@link settledInstanceKey}），其余事件不必读出来。 */
+const SETTLE_EVENT_TYPES = [
+    "node-settled",
+    "artifact-published",
+    "artifact-failed",
+];
+/**
+ * 结算次序要的节点行：工作行**不带结果**（只看 kind / status / 坐标），产物行带结果（成员族在
+ * `result.kind` 上，而产物行有界：32 个 id × 每 id 16 版）。报告行一条都不读——它们从不认领
+ * 闸门，而一个 run 可以有 65,536 条（docs/execution-engine.md「Reading the journal」）。
+ */
+export function readReplayRows(journal, runId) {
+    return {
+        workRows: journal.listNodes(runId, { kinds: REPLAY_WORK_KINDS, withResult: false }),
+        artifactRows: journal.listNodes(runId, { kinds: ["artifact"], withResult: true }),
+    };
+}
+export class ReplaySettleOrder {
+    order;
+    /** 实例键 → 它在首生结算次序里的位置。 */
+    position;
+    /** 已释放到哪一位（次序表的游标）。 */
+    cursor = 0;
+    /** 已到达、正在等自己那一位的释放动作。 */
+    parked = new Map();
+    /** 已轮到、排在微任务里等着投递的释放动作（FIFO，见 {@link enqueue}）。 */
+    queue = [];
+    flushing = false;
+    /** run 结算后闸门永久打开（见 {@link open}）。 */
+    opened = false;
+    constructor(order = []) {
+        this.order = order;
+        const position = new Map();
+        order.forEach((key, index) => position.set(key, index));
+        this.position = position;
+    }
+    static empty() {
+        return new ReplaySettleOrder([]);
+    }
+    /** 首生的结算次序（诊断与测试用）。 */
+    recorded() {
+        return this.order;
+    }
+    /**
+     * 受次序约束地释放一次 replay 命中。表里没有这个实例（全新调用、旧 journal）、闸门已打开、
+     * 或它的位次已被越过时立即执行；否则挂起，等轮到它。
+     */
+    hold(instance, release) {
+        const key = refToString(instance);
+        const at = this.position.get(key);
+        if (this.opened || at === undefined || at < this.cursor) {
+            release();
+            return;
+        }
+        this.parked.set(key, release);
+        this.pump();
+    }
+    /**
+     * 投递永远晚于**产生这个 promise 的那次调用**：释放动作先进队列，一个微任务之后才执行。
+     *
+     * 少了这一跳，次序就是反的：`Promise.all` 里每条分支都在同一个同步片里发起自己的调用，
+     * 队首那条的释放会**在它自己的 `ask()` 里**同步发生——那时它的 `await` 还没挂上去，于是
+     * 它的续体排在「早先已挂上、刚被这次 pump 兑现」的那条后面。微任务这一跳让所有 `await`
+     * 先挂稳，投递次序因此就是释放次序。这不是时钟：跳的是确定的一步，队列是 FIFO。
+     */
+    enqueue(release) {
+        this.queue.push(release);
+        if (this.flushing)
+            return;
+        this.flushing = true;
+        queueMicrotask(() => this.flush());
+    }
+    /** 把排好的投递按 FIFO 执行完（队列空即空跑，故重复调用安全）。 */
+    flush() {
+        this.flushing = false;
+        const batch = this.queue;
+        this.queue = [];
+        for (const release of batch)
+            release();
+    }
+    /**
+     * run 结算：闸门永久打开，挂起的按记录次序放完。
+     *
+     * 不放的后果是脚本那侧的 promise 永远不兑现——在 harness 里沙箱马上就被关掉，但在同进程
+     * 跑脚本的装配（引擎测试、`EvalWorkflowSnippet`）里那就是一次挂死。结算之后释放是安全的：
+     * 引擎已 markSettled，每条 host 路径都以 `isRunSettled()` 开头。
+     */
+    open() {
+        if (this.opened)
+            return;
+        this.opened = true;
+        // 已排队的先按次序放完：结算路径在 `run-settled` **之前**调用本方法，同步放完这一批，
+        // 命中事件因此不会落到那条终态事件后面。此刻每个挂起项的 await 早就挂稳了，不需要再跳。
+        this.flush();
+        for (let i = this.cursor; i < this.order.length; i++) {
+            const key = this.order[i];
+            if (key === undefined)
+                continue;
+            const release = this.parked.get(key);
+            if (release === undefined)
+                continue;
+            this.parked.delete(key);
+            release();
+        }
+        this.cursor = this.order.length;
+        // 次序表之外的键从不入 parked，这一轮理论上是空的；兜底清空，绝不留下没人兑现的 promise。
+        const leftovers = [...this.parked.values()];
+        this.parked.clear();
+        for (const release of leftovers)
+            release();
+    }
+    /** 游标能往前走多少就走多少：队首已到达即释放，然后看下一位。 */
+    pump() {
+        while (this.cursor < this.order.length) {
+            const key = this.order[this.cursor];
+            if (key === undefined)
+                break;
+            const release = this.parked.get(key);
+            if (release === undefined)
+                break;
+            this.parked.delete(key);
+            this.cursor++;
+            this.enqueue(release);
+        }
+    }
+}
+/**
+ * 从 run 自己的事件日志恢复首生的结算次序。
+ *
+ * 事实来源是事件而不是新列：结算次序**本来就**逐条记在 `dwf_event` 里，而它与 journal 行同一次
+ * 写入落库；读回来既不用迁移，也让本规则之前跑出来的 journal 立刻可 resume（本地库里 258 个 run
+ * 有 54 个正卡在这个形状上）。同一条路 `recoverImportClosure` 已经走过（零 schema 变更地从事件
+ * 次序恢复关门判定）。
+ *
+ * 只收**每个实例首次**结算的那一条：重放的一世会按本闸释放的次序再发一遍 cached 事件，取首次
+ * 因而跨世稳定，第三世恢复出的仍是同一张表。
+ *
+ * 表里只留「重放时会兑现一个 promise 的终态行」：`report` 是 void、预置产物声明是同步的，两者
+ * 永远不会来认领，留在表里就会把游标堵死；仍是 `running` 的行按重新 live 执行处理，也不认领。
+ */
+export function recoverSettleOrder(journal, runId, 
+/** 已读好的节点行（引擎的 resume 分支本来就要读一次，传进来省掉第二次读）。 */
+nodes = Object.values(readReplayRows(journal, runId)).flat()) {
+    const claimable = new Set();
+    for (const node of nodes) {
+        if (node.status !== "completed" && node.status !== "failed")
+            continue;
+        if (!claimsOnReplay(node))
+            continue;
+        claimable.add(refToString(node));
+    }
+    if (claimable.size === 0)
+        return ReplaySettleOrder.empty();
+    const order = [];
+    const seen = new Set();
+    for (const { event } of journal.listEvents(runId, {
+        types: SETTLE_EVENT_TYPES,
+        reportItems: { limit: 0 },
+    })) {
+        const key = settledInstanceKey(event);
+        if (key === undefined || seen.has(key) || !claimable.has(key))
+            continue;
+        seen.add(key);
+        order.push(key);
+    }
+    return new ReplaySettleOrder(order);
+}
+/** 结算事件 → 它结算的实例键；不是结算事件则 undefined。 */
+function settledInstanceKey(event) {
+    if (event.type === "node-settled" ||
+        event.type === "artifact-published" ||
+        event.type === "artifact-failed") {
+        return refToString(event.instance);
+    }
+    return undefined;
+}
+/**
+ * 这一行在 replay 时会不会兑现一个脚本能等的 promise。
+ * ask / world 节点会；`report` 不会（void）；产物行要看成员族——内容成员是效应（async），
+ * 预置声明是同步的，只有前者会来认领闸门。失败的产物行只可能来自内容成员（声明没有拒绝通道）。
+ */
+function claimsOnReplay(node) {
+    if (node.kind === "report")
+        return false;
+    if (node.kind !== "artifact")
+        return true;
+    if (node.status === "failed")
+        return true;
+    const kind = node.result?.kind;
+    return typeof kind === "string" && !isArtifactPresetOp(kind);
+}
+/**
+ * 受次序闸约束地兑现一次 replay 命中：轮到它时才执行 `settle` 并按其结果兑现 / 拒绝。
+ * 给的是 promise 路径（world 节点与内容产物）；ask 的释放本就是回调，直接用 {@link ReplaySettleOrder.hold}。
+ */
+export function heldResolution(hold, instance, settle) {
+    return new Promise((resolve, reject) => {
+        hold(instance, () => {
+            try {
+                resolve(settle());
+            }
+            catch (cause) {
+                reject(cause);
+            }
+        });
+    });
+}

package/vendor/dynamic-workflow/engine/run-terminal.d.ts

@@ -0,0 +1,35 @@
+/**
+ * `ProviderStop` 的结构化明细：通知与
+ * GetWorkflowRun 据此选文案，绝不从 message 反向解析。`reason` 是 contracts 的
+ * `ModelFailureReason` 值（`auth_failed` / `invalid_request` / `rate_limited` …），纯包不 import
+ * contracts 故为 string；`kind` 是策略表的判定键（认证 / 未配置 / 模型不可用 / 请求无效 /
+ * 配额 / 兜底），读文案表时用它而不是 reason。
+ */
+export interface ProviderStopDetails {
+    kind: "auth" | "not_configured" | "model_unavailable" | "invalid_request" | "quota" | "other";
+    reason: string;
+    providerId?: string;
+    providerLabel?: string;
+    modelId?: string;
+    providerCode?: string;
+    /** 触发停止的子代理（`refToString(instance)`）与它的名字 / 出生阶段（有则带）。 */
+    subagent?: string;
+    subagentName?: string;
+    phase?: string;
+    /** provider 的原文，逐字（有界，由 driver 截断）。 */
+    rawMessage?: string;
+    /** 配额类：provider 给出的重置时刻（epoch ms），能解析出来才在场。 */
+    resetAt?: number;
+}
+/**
+ * run 级停滞：driver 观察到本 run 连续
+ * `sinceMs` 毫秒没有任何一次成功的模型请求、期间至少排定过一次重试。纯观察事件，引擎只
+ * `record()`；core 据它发一条 run 中通知。`reason` 是期间占多数的重试原因（`ModelRetryReason`
+ * 值，开放字符串），`cap` 是此刻该 provider 桶的 cap。
+ */
+export interface RunStallInfo {
+    sinceMs: number;
+    reason?: string;
+    cap?: number;
+}
+//# sourceMappingURL=run-terminal.d.ts.map

package/vendor/dynamic-workflow/engine/run-terminal.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"run-terminal.d.ts","sourceRoot":"","sources":["../../src/engine/run-terminal.ts"],"names":[],"mappings":"AAOA;;;;;;GAMG;AACH,MAAM,WAAW,mBAAmB;IAClC,IAAI,EAAE,MAAM,GAAG,gBAAgB,GAAG,mBAAmB,GAAG,iBAAiB,GAAG,OAAO,GAAG,OAAO,CAAC;IAC9F,MAAM,EAAE,MAAM,CAAC;IACf,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,aAAa,CAAC,EAAE,MAAM,CAAC;IACvB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,YAAY,CAAC,EAAE,MAAM,CAAC;IACtB,0DAA0D;IAC1D,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,YAAY,CAAC,EAAE,MAAM,CAAC;IACtB,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,uCAAuC;IACvC,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,+CAA+C;IAC/C,OAAO,CAAC,EAAE,MAAM,CAAC;CAClB;AAED;;;;;GAKG;AACH,MAAM,WAAW,YAAY;IAC3B,OAAO,EAAE,MAAM,CAAC;IAChB,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,GAAG,CAAC,EAAE,MAAM,CAAC;CACd"}

package/vendor/dynamic-workflow/engine/run-terminal.js

@@ -0,0 +1,7 @@
+// ============================================================
+// run 终态的结构化明细
+// ============================================================
+// 从 types.ts 拆出（那份文件抵 400 行 lint 门）：`ProviderStop` 错误码的明细与 run 级停滞观察
+// 事件的载荷。词汇（RunStatus / RunStopReason / WorkflowErrorCode）仍在 types.ts，这里只有
+// 「明细」——它们不参与联合类型，拆走不影响穷举消费者。
+export {};

package/vendor/dynamic-workflow/engine/scheduler-submit.d.ts

@@ -0,0 +1,22 @@
+/**
+ * scheduler.ts 顶到 oxlint max-lines 上限（400 行），把 Boundary B 的两条向上回报
+ * （submit_result 到达、turn 结束）及其 repair / nudge 预算与 submit 归一化拆到本文件；
+ * 公开面仍从 scheduler.ts 导出。
+ *
+ * 自由函数经 {@link SubmitSeam} 拿到调度器的 live 节点表与两条结算入口；AskScheduler 上的
+ * submitAttempted / turnEnded 只是薄委托。
+ */
+import type { AskNode, SchedulerHost } from "./scheduler-types.js";
+import type { InstanceRef } from "./types.js";
+import { WorkflowError } from "./types.js";
+/** 调度器暴露给回报处理的最小接缝：查 live 节点、按结果结算。 */
+export interface SubmitSeam {
+    readonly host: SchedulerHost;
+    /** 按实例查 live 节点（已离开 liveNodes 的返回 undefined）。 */
+    liveNode(instance: InstanceRef): AskNode | undefined;
+    settleOk(node: AskNode, artifact: unknown): void;
+    settleFailed(node: AskNode, error: WorkflowError): void;
+}
+export declare function handleSubmitAttempted(seam: SubmitSeam, instance: InstanceRef, payload: unknown): void;
+export declare function handleTurnEnded(seam: SubmitSeam, instance: InstanceRef, finalText: string): void;
+//# sourceMappingURL=scheduler-submit.d.ts.map

package/vendor/dynamic-workflow/engine/scheduler-submit.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"scheduler-submit.d.ts","sourceRoot":"","sources":["../../src/engine/scheduler-submit.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AAEH,OAAO,KAAK,EAAE,OAAO,EAAE,aAAa,EAAE,MAAM,sBAAsB,CAAC;AACnE,OAAO,KAAK,EAAE,WAAW,EAAa,MAAM,YAAY,CAAC;AACzD,OAAO,EAAmB,aAAa,EAAE,MAAM,YAAY,CAAC;AAE5D,uCAAuC;AACvC,MAAM,WAAW,UAAU;IACzB,QAAQ,CAAC,IAAI,EAAE,aAAa,CAAC;IAC7B,iDAAiD;IACjD,QAAQ,CAAC,QAAQ,EAAE,WAAW,GAAG,OAAO,GAAG,SAAS,CAAC;IACrD,QAAQ,CAAC,IAAI,EAAE,OAAO,EAAE,QAAQ,EAAE,OAAO,GAAG,IAAI,CAAC;IACjD,YAAY,CAAC,IAAI,EAAE,OAAO,EAAE,KAAK,EAAE,aAAa,GAAG,IAAI,CAAC;CACzD;AAED,wBAAgB,qBAAqB,CACnC,IAAI,EAAE,UAAU,EAChB,QAAQ,EAAE,WAAW,EACrB,OAAO,EAAE,OAAO,GACf,IAAI,CA4BN;AAuCD,wBAAgB,eAAe,CAAC,IAAI,EAAE,UAAU,EAAE,QAAQ,EAAE,WAAW,EAAE,SAAS,EAAE,MAAM,GAAG,IAAI,CAsBhG"}

package/vendor/dynamic-workflow/engine/scheduler-submit.js

@@ -0,0 +1,84 @@
+/**
+ * scheduler.ts 顶到 oxlint max-lines 上限（400 行），把 Boundary B 的两条向上回报
+ * （submit_result 到达、turn 结束）及其 repair / nudge 预算与 submit 归一化拆到本文件；
+ * 公开面仍从 scheduler.ts 导出。
+ *
+ * 自由函数经 {@link SubmitSeam} 拿到调度器的 live 节点表与两条结算入口；AskScheduler 上的
+ * submitAttempted / turnEnded 只是薄委托。
+ */
+import { REPAIR_ATTEMPTS, WorkflowError } from "./types.js";
+export function handleSubmitAttempted(seam, instance, payload) {
+    const node = seam.liveNode(instance);
+    if (node === undefined || node.settled)
+        return;
+    // untyped ask 不提供 submit_result；即便收到也不据其结算。
+    if (!node.spec.typed)
+        return;
+    const { value, violations } = normalizeSubmit(seam.host, node.spec.schema, payload);
+    if (violations.length === 0) {
+        seam.host.driver.respondToSubmit(instance, { kind: "accept" });
+        seam.settleOk(node, value);
+        return;
+    }
+    if (node.repairsRemaining > 0) {
+        node.repairsRemaining--;
+        const attempt = REPAIR_ATTEMPTS - node.repairsRemaining;
+        seam.host.driver.respondToSubmit(instance, { kind: "reject", violations });
+        seam.host.record({ type: "node-repairing", instance, attempt, violations });
+        return;
+    }
+    seam.host.driver.cancelAsk(instance);
+    seam.settleFailed(node, new WorkflowError("ValidationFailed", "submit_result failed schema validation repeatedly and the repair budget is exhausted.", { violations }));
+}
+/**
+ * 宽松归一化 submit payload：先按原值校验；仅当原值不过、且原值是 string 时，做一次 JSON.parse
+ * 再校验，成功则以解析后的值为准（既回裁决也落 journal）。
+ *
+ * 实盘发现（GLM-5.3 经 Anthropic 兼容端点）：真实模型常把 submit_result 的 `result` 参数序列化成
+ * JSON 字符串（如 `"{\"title\":...}"`）而非 JSON 对象，导致校验器正确报「expected object, got string」、
+ * repair 3 次后 run 失败。legacy script-workflow 的 parseStructuredResponse 早以宽松 JSON 解析容忍此
+ * 情形；此处补上同等容忍，但 schema-aware：
+ *   1. 原值直接过 → 用原值，绝不解析（保住合法的 string 结果，如 `string | null` schema，`"42"` 须留 `"42"`）。
+ *   2. 原值不过且是 string → 单次 JSON.parse（不递归、不双解析，沿用 legacy 单次抽取先例）后再校验，过则取解析值。
+ *   3. 否则 → 回原值 + 原始违规，交模型 repair。
+ * 引擎是纯包，JSON.parse 纯确定、无 I/O，放这里安全。
+ */
+function normalizeSubmit(host, schema, payload) {
+    const direct = host.validate(schema, payload);
+    if (direct.length === 0)
+        return { value: payload, violations: [] };
+    if (typeof payload === "string") {
+        try {
+            const parsed = JSON.parse(payload);
+            const after = host.validate(schema, parsed);
+            if (after.length === 0)
+                return { value: parsed, violations: [] };
+            // bug：解析成功但解析值仍不过时，曾上报解析前的
+            // `direct` 违规（"$: expected object, got string"），模型面对的其实是已解码对象，无从修起，
+            // 只能反复重引号/双重编码/退化成 "{}"，耗尽 repair 预算。修复违规必须描述模型可修改的值，
+            // 故此处返回 `after`（解析后对象上的路径级违规），单次解析契约不变。
+            return { value: parsed, violations: after };
+        }
+        catch {
+            // 非 JSON 字符串：JSON.parse 抛出，回落到原值违规，交模型 repair。
+        }
+    }
+    return { value: payload, violations: direct };
+}
+export function handleTurnEnded(seam, instance, finalText) {
+    const node = seam.liveNode(instance);
+    if (node === undefined || node.settled)
+        return;
+    if (!node.spec.typed) {
+        seam.settleOk(node, finalText);
+        return;
+    }
+    if (node.nudgesRemaining > 0) {
+        node.nudgesRemaining--;
+        seam.host.driver.respondToSubmit(instance, { kind: "nudge" });
+        seam.host.record({ type: "node-nudged", instance });
+        return;
+    }
+    seam.host.driver.cancelAsk(instance);
+    seam.settleFailed(node, new WorkflowError("ResultNotSubmitted", "The typed ask ended without a submit_result call, so there is no result.", { finalText }));
+}