@blade-hq/agent-react 2612.0.0-beta.8 → 2612.0.0-beta.80

package/dist/lib/agent-computer-command.d.ts

@@ -1,32 +0,0 @@
-export declare function isAgentComputerCommand(command: string): boolean;
-/** 工具调用的 JSON 参数里是不是一条 computer launch 命令。 */
-export declare function isAgentComputerToolCall(argumentsJson: string | null | undefined): boolean;
-export type AgentComputerLaunchOutcome = "pending" | "succeeded" | "failed" | "unknown";
-/** `computer launch` 这条 Bash 工具调用最终是不是真的启动成功了——不能只看
- * `isAgentComputerToolCall` 命中参数就当作成功：可执行文件缺失/不可执行、
- * 启动后随即退出这些 appmirrord 侧的失败，Bash 工具调用本身仍然会走完
- * `status: "done"`（Bash 工具的职责是"跑完这条命令"，命令自己返回非零退出码
- * 不算工具调用失败）。
- *
- * 唯一的判据是输出里有没有出现 `LAUNCH_SUCCESS_MARKER`——launch.go 的
- * cmdLaunch 只要走到成功分支就一定会打印这行文本，不存在"成功了但没打印"
- * 的路径。标记缺失就等价于没有走到那条成功路径，不再退回看 `result.exit_code`
- * 当兜底：那样会给 `computer launch ... || echo failed` 这类复合命令开口子，
- * 让真实失败的 launch 被误判成 succeeded。
- *
- * "pending"：还没跑完（status 既不是终态失败也不是 done），调用方不该现在
- * 就下结论，也不该把这次调用标记成"已处理"——等下一次状态更新再重新判断。
- *
- * "unknown"：`status: "done"` 但 `result` 本身缺失（不是"有 result、没有标记"，
- * 是根本没有 result 这个字段）——历史会话被整理（compaction）之后，归档的
- * 工具调用只保留 `arguments`/`status` 这类摘要字段，完整 `result` payload 不
- * 会重新序列化进历史投影，这是已知且刻意的压缩形状，不是数据丢失异常。这种
- * 情况下"没看到成功标记"不能说明"这次 launch 失败了"，只能说明"证据被裁剪
- * 了"——跟"result 确实回来了、里面就是没有这行文本"是两种不同性质的证据，
- * 前者不能定性为 failed，接入方要按自己的场景（标签页展示可以偏宽松，自动
- * 跳转/替用户做决定的场景应该偏保守）自己决定怎么用。
- */
-export declare function classifyAgentComputerLaunchOutcome(toolCall: {
-    status?: string;
-    result?: unknown;
-}): AgentComputerLaunchOutcome;

package/dist/rich-input/extensions/workflow-mention.d.ts

@@ -1,10 +0,0 @@
-import { Node } from "@tiptap/react";
-/**
- * 工作流胶囊:/ 菜单选中工作流后插入的高亮 mention。
- *
- * 刻意不是 skillMention——那个节点序列化成 <skill>id</skill>,且行首会被判定为
- * 「本条消息绑定哪个技能」(composer-content.ts 的 LeadingSkillMention),工作流
- * 塞进去会被当成技能加载。本节点只负责显示胶囊,序列化回「运行工作流 X」纯文本,
- * 模型侧行为与手打文本完全一致。参数模板作为胶囊后的普通文本,用户可直接编辑。
- */
-export declare const WorkflowMention: Node<any, any>;