@ai-setting/roy-agent-core 1.7.53 → 1.7.55

package/dist/env/task/plugins/card-chat-routing.d.ts

@@ -1,72 +1,60 @@
 /**
- * @fileoverview 任务卡片「该发到哪个群」的路由决策（Task #4230 follow-up）
+ * @fileoverview 任务卡片「该发到哪个群」的路由决策（Task #4230 / #4394）
  *
- * ## 背景（真实 bug，2026-10-15）
+ * ## 现行规则（用户 2026-10-20 明令，Task #4394）
  *
- * Task #4226 的进展卡片被发进了 **「Task 3999 - 多模态ontology提取跟进」** 群。
- * 根因链：
- * 1. 触发消息来自 `oc_d083fc…`（= **task #3999 的跟进群**）；
- * 2. `LarkCliTaskNotifyHook` 的 `replyChannel.chatId` 优先（Task #4220 修复：
- *    让 user 在触发群看到卡片）→ 卡片落到 `oc_d083fc…`；
- * 3. #4226 是 sub-task（parent #2066），`PerTaskGroupChatPlugin` 默认跳过建群
- *    → #4226 从来没有自己的群。
+ * > 去掉专属群卡片逻辑，只保留**触发群的进度卡片**（可用户点击建群）
  *
- * 结果：#3999 的专属群里出现了一张讲 #4226 的卡片 —— 跨任务污染。
+ * 决策优先级：
+ * 1. **有触发群 → 就用触发群**。无条件，不判断它是不是"别的 task 的专属群"。
+ * 2. 没有触发群 → 用本 task（其次最近祖先）自己已有的专属群兜底（卡片不能丢）。
+ * 3. 两者都没有 → `none`（调用方静默 skip）。
  *
- * ## 决策规则（用户确认）
+ * ## 已删除的历史逻辑（Task #4394）
  *
- * - **触发群优先**（保持"在哪聊就在哪看到卡片"）
- * - **但跳过「别 task 的专属群」**：若触发群被判定为某个**非本 task lineage**
- *   的 task 的专属群 → 卡片改发到本 task 自己的群（lineage 无群时新建）
- * - 改投时在触发群补一条**链接卡片**（不是普通消息），让 user 知道卡片去哪了
+ * 旧实现（Task #4230）会在"触发群被判定为别的 task 的专属群"时把卡片**改投**到
+ * 本 task / 祖先的 lineage 群，并在触发群补一张「📂 任务卡片已改投专属群 /
+ * 这里不是本任务的群，进展请看专属群」的指路卡。
  *
- * ## 「专属群」判定信号（多重信号，高精度优先）
+ * 用户实测（Task #4393）该行为是干扰：
+ * ```
+ * 触发群 oc_8947d9e2…（task 4377 的专属群）
+ *   → 卡片被改投到 oc_d27157ac…（lineage 群）
+ *   → 用户在触发群只看到一张"这里不是本任务的群"的灰卡
+ * ```
+ * 用户的诉求是「在哪聊就在哪看到进展」。**跨任务污染不再是需要解决的问题**，
+ * 因此整套「专属群归属判定 + 改投 + 指路卡」链路已彻底删除：
+ * - 删除 `ChatOwnership` / `mergeChatOwnership` / `analyzeContextOwnership`
+ * - 删除 `CardChatDecision.reroutedFrom`
+ * - 删除 `new-group` / `fallback-to-trigger` 两种 source（不再自动建群）
  *
- * - `chat-binding`：session 的 chat↔task 绑定（PerTaskGroupChatPlugin 建群时写入）
- * - `larkPerTaskChatId`：task.context 里插件写入的专属群字段
- * - `followup_chat`：`*followup_chat_id` / `*_group_chat_id` 之类字段（老任务手工建的跟进群）
- * - `chat-name`：群名里的 `Task 3999` / `#3999` 模式（对没留字段的手工群兜底）
+ * ## 建群能力仍在（**用户主动点击**才建）
  *
- * 注意：**不算** `feishu_chat_id` / `chat_id` 这类"会话群"字段 —— 它们表示
- * "这个 task 曾在哪个群聊过"，把普通会话群误判成专属群会让新任务的卡片被
- * 错误地赶去新建群（假阳性比假阴性更烦人）。
+ * 卡片顶部按钮 `create_group` / `disband_group` 由
+ * `lark-card-action-handler.ts` 处理，与本文档的路由决策**完全解耦**：
+ * ```
+ * 用户点「为这个任务建群」
+ *   → card.action.trigger 事件
+ *   → handleCardAction → ports.createGroupChat (lark-cli im +chat-create)
+ *   → 回写 task.context.larkPerTaskChatId
+ *   → patch 卡片（按钮翻成「解散该群」+ 出现「进入专属群」链接）
+ * ```
+ * 建群后下一张进度卡会走本文件的优先级 1（仍进触发群），
+ * 但卡片上多了「进入专属群」链接 —— 这是用户可选的入口，不是自动改投。
  *
- * 本模块是**纯函数**（不碰 IO），IO（DB 反查 / lark-cli 取群名）由调用方
- * （EventSource handler）注入，便于单测覆盖所有分支。
+ * 本模块是**纯函数**（不碰 IO），便于单测覆盖所有分支。
  */
 /** 群名里隐含的 task id（"Task 3999 - xxx" / "#3999 TMO 提取跟进"） */
 export declare const GROUP_NAME_TASK_ID_RE: RegExp;
 /** 会把 chatId 记进 context 的字段名（用于 DB LIKE 反查） */
 export declare const CTX_FIELD_LARK_PER_TASK_CHAT_ID = "larkPerTaskChatId";
-/** 一个群可能的归属证据（多重信号并集） */
-export interface ChatOwnership {
-    chatId: string;
-    /**
-     * 该群归属的 task id（可能多个：历史脏数据 / 多个 task 共用过一个群）
-     *
-     * 空数组 = 没有证据表明它是任何 task 的专属群。
-     */
-    ownerTaskIds: number[];
-    /** 证据来源（诊断用）：chat-binding / larkPerTaskChatId / followup_chat_id / chat-name */
-    sources: string[];
-    /** 群名（DB 记录或实时查询；可能没有） */
-    chatName?: string;
-    /** 是否被判为"专属群"（至少有一条**专属**证据） */
-    dedicated: boolean;
-}
-export type CardChatSource = "trigger-chat" | "own-group" | "ancestor-group" | "new-group" | "fallback-to-trigger" | "none";
+export type CardChatSource = "trigger-chat" | "own-group" | "ancestor-group" | "none";
 export interface CardChatDecision {
     chatId?: string;
     profile?: string;
-    /** 目标群名（新建群时由 ensureGroupChat 回填，用于改投链接卡片渲染） */
+    /** 目标群名（诊断用） */
     chatName?: string;
     source: CardChatSource;
-    /** 因触发群是"别 task 的专属群"而改投时记录（用于回补链接卡片） */
-    reroutedFrom?: {
-        chatId: string;
-        ownerTaskIds: number[];
-        sources: string[];
-    };
     /** 人类可读的决策原因（写进 span / debug 日志） */
     reason: string;
 }
@@ -79,41 +67,17 @@ export declare function extractPerTaskChatProfile(contextStr?: string): string |
 /** 从 task.context JSON 解析记录下来的群名（含 `#3999` / `Task 3999` 模式） */
 export declare function extractRecordedChatNames(contextStr?: string): string[];
 /**
- * 分析「某个 task 的 context 是否主张自己拥有 chatId」
- *
- * 只认**专属**信号；`feishu_chat_id` / `chat_id` 这类会话群字段会被忽略
- * （否则会把普通会话群误判成专属群）。
- */
-export declare function analyzeContextOwnership(contextStr: string | undefined, chatId: string): {
-    owned: boolean;
-    sources: string[];
-    impliedTaskIds: number[];
-};
-/**
- * 由多个 task（DB 反查命中）的 context 汇总出 `ChatOwnership`
+ * 决定卡片该发到哪个群（Task #4394 简化版）
  *
- * @param chatId 目标群
- * @param candidates DB 反查命中的 task（id + context）
- * @param extra 额外信号（chat↔task 绑定 / 实时群名），由调用方提供
- */
-export declare function mergeChatOwnership(chatId: string, candidates: Array<{
-    id: number;
-    context?: string;
-}>, extra?: {
-    boundTaskId?: number | null;
-    /** 该群的真实群名（若调用方查到了） */
-    chatName?: string;
-}): ChatOwnership;
-/**
- * 决定卡片该发到哪个群
+ * 规则只有两条：
+ * 1. **有触发群 → 触发群**（无条件，不做任何"是不是别人的群"判定）
+ * 2. 没触发群 → 用本 task / 祖先已有的专属群兜底
  *
- * @param input.lineageIds 本 task 的 lineage（自己 + 所有祖先）task id
  * @param input.lineageChat lineage 上找到的专属群（自己优先，其次最近祖先）
- * @param input.triggerOwnership 触发群的归属分析（未做分析时传 undefined）
  */
 export declare function decideCardChatTarget(input: {
     taskId?: number;
-    lineageIds: number[];
+    lineageIds?: number[];
     lineageChat?: {
         chatId: string;
         profile?: string;
@@ -121,15 +85,4 @@ export declare function decideCardChatTarget(input: {
     };
     triggerChatId?: string;
     triggerProfile?: string;
-    triggerOwnership?: ChatOwnership;
-    /**
-     * ★ Task #4331：是否允许"new-group"路径（即触发群是别人的群 + 本 task 无群时建专属群）
-     *
-     * 默认 false（用户新要求：默认不建群）
-     * - true：保留 #4230 的老行为（建专属群），用于向后兼容显式开启的场景
-     * - false：触发群是别人的群 + 本 task 无群 → 退回触发群（不建群）
-     *
-     * 不影响其他 source（trigger-chat / own-group / ancestor-group / none）的决策。
-     */
-    allowNewGroup?: boolean;
 }): CardChatDecision;

package/dist/env/task/plugins/index.js

@@ -10,12 +10,12 @@ import {
   formatExtractorInput,
   formatExtractorInputFromDescription,
   parseExtractorOutput
-} from "../../../shared/@ai-setting/roy-agent-core-hch2geta.js";
+} from "../../../shared/@ai-setting/roy-agent-core-g36jevrk.js";
 import"../../../shared/@ai-setting/roy-agent-core-yhsssn86.js";
 import"../../../shared/@ai-setting/roy-agent-core-1pg0fepg.js";
-import"../../../shared/@ai-setting/roy-agent-core-gdsqp6j8.js";
-import"../../../shared/@ai-setting/roy-agent-core-j8e92gj8.js";
-import"../../../shared/@ai-setting/roy-agent-core-na73mym1.js";
+import"../../../shared/@ai-setting/roy-agent-core-6masakz4.js";
+import"../../../shared/@ai-setting/roy-agent-core-b5ew8t0k.js";
+import"../../../shared/@ai-setting/roy-agent-core-a4vzsn0g.js";
 import"../../../shared/@ai-setting/roy-agent-core-8s9jd2qy.js";
 import"../../../shared/@ai-setting/roy-agent-core-jrj30vq3.js";
 import"../../../shared/@ai-setting/roy-agent-core-dv714bqh.js";

package/dist/env/task/plugins/lark-card-patch-notifier.d.ts

@@ -173,21 +173,6 @@ export interface FinishTaskOptions {
     finalStep?: string;
     progress?: number;
 }
-/** 改投链接卡片的入参（Task #4230 follow-up） */
-export interface RedirectNoticeOptions {
-    /** 发到哪个群（通常是"触发群"，即被判定为别 task 专属群的那个） */
-    chatId: string;
-    profile?: string;
-    /** 本 task */
-    taskId?: number | string;
-    taskTitle?: string;
-    /** 卡片实际落在哪个群 */
-    targetChatId: string;
-    /** 目标群名（渲染成可点击文本；缺省显示"专属群"） */
-    targetChatName?: string;
-    /** 改投原因（诊断，写进卡片文案） */
-    reason?: string;
-}
 export interface StartTaskResult {
     messageId: string;
     /** pin 是否成功（失败不影响卡片可见性，但 trace 里可查） */
@@ -418,24 +403,6 @@ export declare function buildTaskCard(opts: {
 export declare function buildChatAppLink(chatId: string, base?: string): string;
 /** 默认 applink 基址（飞书） */
 export declare const DEFAULT_APP_LINK_BASE = "https://applink.feishu.cn";
-/**
- * 构造"卡片已改投专属群"的链接卡片（Task #4230 follow-up）
- *
- * 为什么是卡片而不是普通消息：
- * - 用户明确要求「旧逻辑的普通消息通知不要」；
- * - 改投后触发群里需要一条**可点击**的入口，否则 user 不知道进展卡片去哪了。
- *
- * 注意：这张卡片**不携带任务进展内容**，只是一条"去哪看"的指路牌，避免把
- * 别的 task 的进展细节塞进不属于它的群。
- */
-export declare function buildRedirectCard(opts: {
-    taskId?: number | string;
-    taskTitle?: string;
-    targetChatId: string;
-    /** 目标群名（渲染成可点击文本；缺省显示"专属群"） */
-    targetChatName?: string;
-    reason?: string;
-}): CardPayload;
 /**
  * 格式化耗时为人类可读文本（毫秒 → ms / s / m）
  *
@@ -496,14 +463,6 @@ export declare class LarkCardPatchNotifier {
      * unpin 基础设施，只是渲染的卡片与自持的时间线不同。
      */
     private readonly workflowStates;
-    /**
-     * ★ Task #4237 修复：改投链接卡片幂等表
-     *
-     * key = `${taskId}:${targetChatId}`；同一 (task, 目标群) 只允许发一张
-     * 「任务卡片已改投专属群」卡片 —— 旧实现里两条决策路径各发一次，
-     * 触发群收到两张文案不同的改投卡片。
-     */
-    private readonly redirectsSent;
     constructor(options?: LarkCardPatchNotifierOptions);
     /** 取（或创建）某 messageId 的 mutex —— 不同卡片互不阻塞 */
     private mutexFor;
@@ -514,16 +473,6 @@ export declare class LarkCardPatchNotifier {
      *   `--chat-id/--message-id` 是非法 flag，导致 pin 永远失败 → 用户"还是没有 pin"）。
      */
     startTask(opts: StartTaskOptions): Promise<StartTaskResult>;
-    /**
-     * 在"触发群"发一条**链接卡片**，告知任务进展卡片已改投本 task 的专属群
-     *
-     * Task #4230 follow-up：当触发群被判定为"别的 task 的专属群"时，卡片不会
-     * 再落在触发群（避免跨任务污染），但 user 需要知道去哪里看 → 这里补一张
-     * 不含任务进展内容的指路卡片。
-     *
-     * 失败非致命（触发群里发不出去不影响主流程）。
-     */
-    sendRedirectNotice(opts: RedirectNoticeOptions): Promise<boolean>;
     /**
      * Patch 同一卡片（状态/进度/当前步骤 + 累积里程碑与过程时间线）
      *

package/dist/env/task/plugins/lark-cli-task-notify-plugin.d.ts

@@ -23,10 +23,8 @@
  * ```
  */
 import type { Hook, HookContext } from "../../hook/types";
-import type { Task } from "../types";
 import { getEnvContextOrEmpty } from "../../context";
 import { LarkCardPatchNotifier } from "./lark-card-patch-notifier";
-import { type ChatOwnership } from "./card-chat-routing";
 /**
  * 从 EnvContext 提取 lark 专属字段
  *
@@ -82,16 +80,6 @@ export interface TaskNotifyConfig {
      * 不传 → plugin 自己 new 一个（messageId 由 plugin 的 Map 跟踪）。
      */
     cardNotifier?: LarkCardPatchNotifier;
-    /**
-     * ★ Task #4331：是否允许路由决策走"new-group"路径（建专属群）
-     *
-     * 默认 false：触发群是别人的群 + 本 task 无群时，**不**建专属群，退回触发群
-     * 适用：默认行为（用户新要求：默认不建群）
-     *
-     * 设为 true：保留 #4230 老行为（建专属群并改投）
-     * 适用：显式开启（向后兼容）
-     */
-    allowNewGroup?: boolean;
 }
 /**
  * 卡片路由端口（Task #4230 follow-up）
@@ -101,25 +89,16 @@ export interface TaskNotifyConfig {
  */
 export interface CardRoutingPorts {
     /**
-     * 反查「该群是否是某个 task 的专属群」（多重信号）
+     * task 查询（lineage 上溯：无触发群时找本 task / 祖先的专属群兜底）
      *
-     * 实现建议（见 event-source-handlers.ts）：
-     * - session 的 chat↔task 绑定
-     * - task.context.larkPerTaskChatId / *followup_chat_id
-     * - 群名 "Task 3999" / "#3999"（DB 记录的群名，必要时实时查）
+     * ★ Task #4394：`lookupChatOwnership` / `ensureTaskGroupChat` 两个端口已删除
+     *   —— 卡片不再做"触发群是不是别 task 专属群"的判定，也不再自动建群。
+     *   建群改由用户在卡片上点「为这个任务建群」按钮触发（见 lark-card-action-handler.ts）。
      */
-    lookupChatOwnership?: (chatId: string) => Promise<ChatOwnership | undefined>;
-    /** task 查询（lineage 上溯） */
     getTask?: (id: number) => Promise<{
         context?: string;
         parent_task_id?: number | null;
     } | undefined>;
-    /** 为 task 建/取专属群（lineage 无群且触发群是别人的群时用） */
-    ensureTaskGroupChat?: (task: Task) => Promise<{
-        chatId: string;
-        profile?: string;
-        name?: string;
-    } | undefined>;
 }
 export declare class LarkCliTaskNotifyHook implements Hook {
     readonly name: string;
@@ -156,8 +135,8 @@ export declare class LarkCliTaskNotifyHook implements Hook {
      *
      * 根因：`sendCardStart` 里 `ensureTaskGroupChat` 会写 task.context → 同步触发
      * `task:after.update` → 本 hook 重入 `sendCardUpdate`；此时首卡 messageId 还没写进
-     * `cardMessageIds` → 触发 fallback 补一张卡 + 再发一张改投卡片（同一 task 3 张卡、
-     * 触发群 2 张改投卡片）。
+     * `cardMessageIds` → 触发 fallback 补一张重复卡（同一 task 多张卡）。
+     * （Task #4394 已删除"再发一张改投卡片"那条路径，哨兵仍用于防重复补卡。）
      *
      * 修法：进入 `sendCardStart` 前先占位；重入的 update 看到哨兵直接跳过。
      */
@@ -189,16 +168,20 @@ export declare class LarkCliTaskNotifyHook implements Hook {
     /**
      * 解析「卡片该发到哪个群」（Task #4230 follow-up）
      *
-     * 规则见 card-chat-routing.ts：触发群优先，但跳过"别的 task 的专属群"；
-     * 若是别人的群 → 用本 task（或祖先）的专属群；都没有 → 新建一个。
+     * 规则见 card-chat-routing.ts（Task #4394 简化版）：
+     * - **有触发群 → 就用触发群**（无条件，不改投）
+     * - 没有触发群 → 用本 task（或祖先）已有的专属群兜底
+     * - 都没有 → none（caller skip）
+     *
+     * 已经不再"自动建群"——建群由用户在卡片上点按钮触发。
      *
-     * @returns decision + 最终可用的 chatId/profile + 是否需要回补链接卡片
+     * @returns decision（chatId / profile / source / reason）
      */
     private resolveCardTarget;
     /**
      * 收集 task 的 lineage（自己 → 父 → 祖父…，最多 10 层）
      *
-     * 用于：(a) 找最近的专属群；(b) 判断"某个群属于谁"时确认是否在自己 lineage 上。
+     * 用于：无触发群时找最近的专属群兜底（Task #4394：不再用于"是否别人的群"判定）。
      */
     private collectLineage;
     /** 发初始卡片（+ pin）并缓存 messageId */

package/dist/env/task/plugins/per-task-group-chat-plugin.d.ts

@@ -193,10 +193,10 @@ export interface PerTaskGroupConfig {
      * - 用户在卡片顶部点"为这个任务建群"按钮 → 走 ensureGroupChat 按需建群
      * - 适用：减少群聊爆炸 / 集中讨论 / 减少噪音
      *
-     * ★ 与 LarkCliTaskNotifyPlugin.cardRoutingPorts.ensureTaskGroupChat 协同：
-     *   - LarkCliTaskNotifyPlugin 在路由决策 source="new-group" 时也会调 ensureGroupChat
-     *   - 用户本次改造明确要求"默认不建群"，所以 LarkCliTaskNotifyPlugin 的 new-group 路径
-     *     也被改造为 fallback-to-trigger（不调 ensure）
+     * ★ Task #4394：`LarkCliTaskNotifyPlugin.cardRoutingPorts.ensureTaskGroupChat`
+     *   及其 `new-group` / `fallback-to-trigger` 两条 source 已删除 —— 卡片路由
+     *   **不再自动建群**，`ensureGroupChat` 现在只剩一个调用方：用户点卡片上
+     *   「为这个任务建群」按钮（见 lark-card-action-handler.ts）。
      */
     autoCreateGroup?: boolean;
     /**

package/dist/env/workflow/engine/engine.d.ts

@@ -217,12 +217,61 @@ export declare class WorkflowEngine extends EventEmitter {
      * Main scheduling loop
      */
     private scheduleAndExecute;
+    /**
+     * Dispatch a node without waiting for it to finish (Task #4392 P0-1).
+     *
+     * Registers the node's promise in `sessionState.inFlight` **synchronously**
+     * so the scheduler loop can (a) join it and (b) never mistake "no tracked
+     * work" for "done". The returned promise is intentionally swallowed: node
+     * outcomes propagate through `scheduler.markFailed` and the `node.failed`
+     * event, exactly as they did when the dispatch path awaited them.
+     *
+     * ## Claim guard — why this is not just "call startNode"
+     *
+     * A node can be reachable from **two** dispatch paths:
+     *   1. `scheduleAvailableNodes()` → `scheduler.getReadyNodes()` (DAG readiness)
+     *   2. `processConditionalEdgesAfterCompletion()` → `edgeResult.toStart`
+     *
+     * Under the old serial loop this never mattered: path 2 awaited each target
+     * to completion, so path 1 always found them `completed` already. Once
+     * dispatch became concurrent the two paths race and the *same* node was
+     * executed twice (proven by `engine-parallel-scheduling.test.ts`:
+     * `parallelLimit=2` produced peak concurrency 3 with 4 of 6 leaves run twice).
+     *
+     * `scheduler.running` is the tie-breaker. `startNode` calls
+     * `scheduler.markStarted()` before its first `await`, so the claim is visible
+     * synchronously to the next dispatcher on the same tick — no interleaving
+     * window. Returns `true` only for the caller that actually won the claim.
+     *
+     * ⚠️ The guard deliberately keys off `scheduler.running` and **not** off
+     * `inFlight`, even though both look equivalent. A self-loop back-edge
+     * (`implement → implement`) re-dispatches the node *from inside its own
+     * completion handler*, i.e. while its own promise is still in `inFlight` but
+     * after `resetNodeForReEntry()` cleared `running`. Guarding on `inFlight`
+     * deadlocks exactly that case: the node waits for itself forever.
+     */
+    private dispatchNode;
     /**
      * Wait for next node event
      *
      * Optimization: When there are running nodes, use pure event-driven waiting
      * (no polling). When there are only pending nodes (dependencies not yet met),
      * use a small timeout to re-check scheduling conditions.
+     *
+     * Task #4392 P0-1 — two additions that concurrent dispatch makes necessary:
+     *
+     * 1. **`inFlight` also arms the timeout.** `scheduler.running` is cleared by
+     *    `markCompleted` inside `validateAndExecute`, but the node's promise is
+     *    still settling (AFTER_NODE hook, conditional edges, `checkAndFinalize`).
+     *    In that window `hasRunningNodes` is false while real work continues, so
+     *    we must keep a wakeup source armed or the loop could park forever.
+     *
+     * 2. **`node.scheduled` resolves the wait.** Concurrent dispatch publishes
+     *    `node.scheduled` for sibling nodes (and for loop re-entries) *after* this
+     *    waiter subscribed — with `node.completed`/`node.failed` as the only
+     *    trigger, a round whose completion event fired during the synchronous
+     *    dispatch section would leave the loop blocked until the 100ms poll.
+     *    Subscribing to `node.scheduled` closes that lost-wakeup window.
      */
     private waitForNextNodeEvent;
     /**
@@ -368,6 +417,22 @@ export declare class WorkflowEngine extends EventEmitter {
      * Get session metadata
      */
     private getSessionMetadata;
+    /**
+     * Serialized session-metadata read-modify-write (Task #4392 P0-1).
+     *
+     * Every `node.completed` / `node.failed` handler and every terminal-state
+     * transition mutates metadata via `get → spread → update`. That is safe only
+     * if mutations never interleave. Now that nodes are dispatched concurrently,
+     * two completions can both `await get()` the same snapshot and the later
+     * `update()` silently drops the other's `agentSessions` marker.
+     *
+     * `mutate` receives the freshly-read metadata and must return the next
+     * metadata object. Mutations are chained onto `sessionState.sessionMetadataQueue`
+     * so they apply in a strict total order, and the queue never rejects (a
+     * failed mutation is logged and skipped) so one bad update cannot poison
+     * every later write.
+     */
+    private updateSessionMetadata;
     /**
      * Find workflow definition from repository
      */

package/dist/env/workflow/engine/index.js

@@ -5,10 +5,10 @@ import {
   Scheduler,
   WorkflowEngine,
   init_engine
-} from "../../../shared/@ai-setting/roy-agent-core-35s1w7tc.js";
+} from "../../../shared/@ai-setting/roy-agent-core-aer5kw1j.js";
 import"../../../shared/@ai-setting/roy-agent-core-6atd905e.js";
 import"../../../shared/@ai-setting/roy-agent-core-6167phd4.js";
-import"../../../shared/@ai-setting/roy-agent-core-x8n1r7h4.js";
+import"../../../shared/@ai-setting/roy-agent-core-2bscfrr1.js";
 import"../../../shared/@ai-setting/roy-agent-core-1db4vpc6.js";
 import"../../../shared/@ai-setting/roy-agent-core-ze068vc9.js";
 import"../../../shared/@ai-setting/roy-agent-core-fs36xgcs.js";

package/dist/env/workflow/index.js

@@ -1,6 +1,6 @@
 import {
   WorkflowComponent
-} from "../../shared/@ai-setting/roy-agent-core-4vpk40ss.js";
+} from "../../shared/@ai-setting/roy-agent-core-8eqngasy.js";
 import"../../shared/@ai-setting/roy-agent-core-vrsxhw9e.js";
 import {
   Edge,
@@ -14,21 +14,21 @@ import {
   DecoratorNode,
   init_decorator_node
 } from "../../shared/@ai-setting/roy-agent-core-1ce3fqrk.js";
-import"../../shared/@ai-setting/roy-agent-core-vvxb9522.js";
-import"../../shared/@ai-setting/roy-agent-core-yd21n6c7.js";
-import"../../shared/@ai-setting/roy-agent-core-h93v6p6y.js";
+import"../../shared/@ai-setting/roy-agent-core-6qxh4xrm.js";
+import"../../shared/@ai-setting/roy-agent-core-zvemdfx5.js";
+import"../../shared/@ai-setting/roy-agent-core-7qy3nffr.js";
 import"../../shared/@ai-setting/roy-agent-core-hhrg314p.js";
 import"../../shared/@ai-setting/roy-agent-core-7evvpfwc.js";
-import"../../shared/@ai-setting/roy-agent-core-35s1w7tc.js";
+import"../../shared/@ai-setting/roy-agent-core-aer5kw1j.js";
 import"../../shared/@ai-setting/roy-agent-core-6atd905e.js";
 import"../../shared/@ai-setting/roy-agent-core-6167phd4.js";
-import"../../shared/@ai-setting/roy-agent-core-x8n1r7h4.js";
+import"../../shared/@ai-setting/roy-agent-core-2bscfrr1.js";
 import"../../shared/@ai-setting/roy-agent-core-1db4vpc6.js";
 import"../../shared/@ai-setting/roy-agent-core-ze068vc9.js";
 import"../../shared/@ai-setting/roy-agent-core-fs36xgcs.js";
 import"../../shared/@ai-setting/roy-agent-core-9csa89jx.js";
 import"../../shared/@ai-setting/roy-agent-core-7exqwax1.js";
-import"../../shared/@ai-setting/roy-agent-core-na73mym1.js";
+import"../../shared/@ai-setting/roy-agent-core-a4vzsn0g.js";
 import"../../shared/@ai-setting/roy-agent-core-tjg71zqp.js";
 import"../../shared/@ai-setting/roy-agent-core-ddwa0n6h.js";
 import"../../shared/@ai-setting/roy-agent-core-8s9jd2qy.js";
@@ -85,8 +85,8 @@ import {
   unresolvedVariable
 } from "../../shared/@ai-setting/roy-agent-core-jrj30vq3.js";
 import"../../shared/@ai-setting/roy-agent-core-rvxg1wps.js";
-import"../../shared/@ai-setting/roy-agent-core-pk1b3kvf.js";
-import"../../shared/@ai-setting/roy-agent-core-zy3hqfwg.js";
+import"../../shared/@ai-setting/roy-agent-core-2b8jtv7m.js";
+import"../../shared/@ai-setting/roy-agent-core-0hq21px2.js";
 import"../../shared/@ai-setting/roy-agent-core-c1v263jn.js";
 import {
   AskUserError,

package/dist/env/workflow/nodes/index.js

@@ -7,7 +7,7 @@ import {
   init_skill_node,
   init_tool_node,
   init_workflow_node
-} from "../../../shared/@ai-setting/roy-agent-core-x8n1r7h4.js";
+} from "../../../shared/@ai-setting/roy-agent-core-2bscfrr1.js";
 import"../../../shared/@ai-setting/roy-agent-core-dsevjbck.js";
 import"../../../shared/@ai-setting/roy-agent-core-8seq65bp.js";
 import"../../../shared/@ai-setting/roy-agent-core-jnszp0jq.js";

package/dist/env/workflow/nodes/tool-node.d.ts

@@ -52,6 +52,12 @@ export declare class ToolNode implements Node {
      *   - value is not an object
      *   - success === true (or success field is missing)
      *   - wrapper has no error string
+     *
+     * Task #4392 P0-2: when the wrapper signals a non-zero `exit_code` but carries
+     * no stderr, the bare `Tool exited with code N` message is useless on its own
+     * (#4385 measured 27 such `exit 2` occurrences in the creator sessions, and
+     * 291 failed runs whose `session.metadata.error` was null). We therefore append
+     * the (redacted, single-line, truncated) command plus a stdout tail.
      */
     private extractErrorFromWrapper;
 }

package/dist/env/workflow/plugins/index.js

@@ -1,8 +1,8 @@
 import {
   LarkCliWorkflowNotifyHook,
   createLarkCliWorkflowNotifyHook
-} from "../../../shared/@ai-setting/roy-agent-core-brwzs8wf.js";
-import"../../../shared/@ai-setting/roy-agent-core-j8e92gj8.js";
+} from "../../../shared/@ai-setting/roy-agent-core-9h72sk1n.js";
+import"../../../shared/@ai-setting/roy-agent-core-b5ew8t0k.js";
 import"../../../shared/@ai-setting/roy-agent-core-9csa89jx.js";
 import"../../../shared/@ai-setting/roy-agent-core-qcspfszy.js";
 import"../../../shared/@ai-setting/roy-agent-core-4z3rq5gw.js";

package/dist/env/workflow/tools/index.js

@@ -24,9 +24,9 @@ import {
   getRunWorkflowTool,
   initRunWorkflowTool,
   resetRunWorkflowTool
-} from "../../../shared/@ai-setting/roy-agent-core-vvxb9522.js";
-import"../../../shared/@ai-setting/roy-agent-core-yd21n6c7.js";
-import"../../../shared/@ai-setting/roy-agent-core-h93v6p6y.js";
+} from "../../../shared/@ai-setting/roy-agent-core-6qxh4xrm.js";
+import"../../../shared/@ai-setting/roy-agent-core-zvemdfx5.js";
+import"../../../shared/@ai-setting/roy-agent-core-7qy3nffr.js";
 import"../../../shared/@ai-setting/roy-agent-core-7evvpfwc.js";
 import {
   WORKFLOW_SUBMIT_OUTPUT_TOOL_NAME,
@@ -37,12 +37,12 @@ import {
 } from "../../../shared/@ai-setting/roy-agent-core-1db4vpc6.js";
 import"../../../shared/@ai-setting/roy-agent-core-ze068vc9.js";
 import"../../../shared/@ai-setting/roy-agent-core-7exqwax1.js";
-import"../../../shared/@ai-setting/roy-agent-core-na73mym1.js";
+import"../../../shared/@ai-setting/roy-agent-core-a4vzsn0g.js";
 import"../../../shared/@ai-setting/roy-agent-core-8s9jd2qy.js";
 import"../../../shared/@ai-setting/roy-agent-core-jrj30vq3.js";
 import"../../../shared/@ai-setting/roy-agent-core-rvxg1wps.js";
-import"../../../shared/@ai-setting/roy-agent-core-pk1b3kvf.js";
-import"../../../shared/@ai-setting/roy-agent-core-zy3hqfwg.js";
+import"../../../shared/@ai-setting/roy-agent-core-2b8jtv7m.js";
+import"../../../shared/@ai-setting/roy-agent-core-0hq21px2.js";
 import"../../../shared/@ai-setting/roy-agent-core-c1v263jn.js";
 import"../../../shared/@ai-setting/roy-agent-core-e25xkv53.js";
 import"../../../shared/@ai-setting/roy-agent-core-7hh0brvs.js";

package/dist/env/workflow/tools/workflow-validate-tool.d.ts

@@ -34,18 +34,27 @@ import type { WorkflowService } from "../service/workflow-service";
 /**
  * Input schema for workflow_validate tool.
  *
- * Accepts either `yaml` (string) or `definition` (object) — same flexibility
- * as workflow_add, for symmetric API design.
+ * Accepts `file` (path), `yaml`/`definition_yaml` (string) or `definition`
+ * (object). Precedence: `definition` > `file` > `yaml` / `definition_yaml`.
+ *
+ * Task #4392 P0-4: `file` was added because the tool performs **no shell
+ * expansion**, yet LLMs kept passing `yaml: "$(cat /tmp/x.yaml)"`. That string
+ * is literal, YAML.parse returns a *string*, and the tool replied
+ * `Parsed definition is not an object` — 30 of the 31 measured validate
+ * failures in #4385 §2 C2.
  */
 export declare const WorkflowValidateInputSchema: z.ZodObject<{
     definition: z.ZodOptional<z.ZodAny>;
     definition_yaml: z.ZodOptional<z.ZodString>;
     yaml: z.ZodOptional<z.ZodString>;
+    file: z.ZodOptional<z.ZodString>;
 }, "strip", z.ZodTypeAny, {
+    file?: string | undefined;
     definition?: any;
     definition_yaml?: string | undefined;
     yaml?: string | undefined;
 }, {
+    file?: string | undefined;
     definition?: any;
     definition_yaml?: string | undefined;
     yaml?: string | undefined;