@tencent-ai/agent-harness 0.2.0-beta.1 → 0.2.0-beta.2

package/cli/dist-server/types/vendor/cbc-core/node/agent/speaker-label.d.ts

@@ -0,0 +1,44 @@
+export declare function resolveMessageSpeakerLabel(input: {
+    session?: {
+        id?: string;
+        storeId?: string;
+        meta?: Record<string, unknown>;
+    } | undefined;
+    runAgentName?: string;
+}): string | undefined;
+/**
+ * 子会话的**展示名**（给人看）：团队成员用成员名，其余子代理用自身预设名（`meta.agentName`）；
+ * 主会话 / 无会话 / 无身份线索返回 undefined。**只用于展示与遥测标签，不要拿它查表。**
+ */
+export declare function resolveSubAgentDisplayName(session: {
+    id?: string;
+    storeId?: string;
+    meta?: Record<string, unknown>;
+} | undefined): string | undefined;
+/**
+ * 子会话的**查表键**（REPL 沙箱白名单 / overlay 缓存用）：只认「预设名」这一种语义。
+ *
+ * 与展示名刻意分开（评审）：团队成员会把自己的成员名写进 `meta.agentName`（teammate-runner），
+ * 于是 `meta.agentName` 同时承载「预设名」与「成员名」两种含义 —— 拿成员名去查 agent 配置查不到，
+ * 只能落到默认 agent 的兜底（既不是成员自己的白名单、也不是「不过滤」）。取不到可信的预设名时
+ * 返回 undefined = 不额外收窄（与改动前一致），不去猜。
+ */
+export declare function resolveSubAgentAgentKey(session: {
+    id?: string;
+    storeId?: string;
+    meta?: Record<string, unknown>;
+} | undefined): string | undefined;
+/** 展示名的**派发侧镜像**：子会话还没建时拿不到 `meta.teamContext`，但这对值就是稍后写进 session 的同一对。 */
+export declare function resolveSubAgentDisplayNameFromParts(input: {
+    memberName?: string;
+    presetName?: string;
+}): string | undefined;
+/**
+ * 查表键的**派发侧镜像**（AgentManager.sandboxScopedAgentView 传身份用）：
+ * 预设名与成员名**同值**（团队成员把自己的名字写进 meta.agentName）时判为「没有可信预设名」→ undefined，
+ * 与运行期 `resolveSubAgentAgentKey` 同源 —— 否则派发侧按成员名收窄、执行侧判不到，两边分叉。
+ */
+export declare function resolveSubAgentAgentKeyFromParts(input: {
+    memberName?: string;
+    presetName?: string;
+}): string | undefined;

package/cli/dist-server/types/vendor/cbc-core/node/agent/tool-call-loop-detector-service.d.ts

@@ -6,9 +6,9 @@
  * wastes tokens/credits.
  *
  * Detection rules:
- * 1. Generic loop: blacklisted tool with identical arguments 4 consecutive times
+ * 1. Generic loop: blacklisted tool with semantically identical JSON arguments 4 consecutive times
  * 2. Read file loop: Read tool targeting the same file_path 40 consecutive times
- * 3. Non-blacklist loop: any tool NOT in blacklist with identical arguments 40 consecutive times
+ * 3. Non-blacklist loop: any tool NOT in blacklist with semantically identical JSON arguments 40 consecutive times
  */
 import type { AgentInputItem } from '../../../cbc-shared/node/index.js';
 import { Logger } from '../../../../workspace/telemetry/lib/common/index.js';
@@ -38,14 +38,15 @@ export declare class ToolCallLoopDetectorImpl implements ToolCallLoopDetector {
         arguments: string;
     }>;
     /**
-     * Check for generic loop: same tool with identical arguments N consecutive times.
+     * Check for generic loop: same tool with semantically identical JSON arguments
+     * N consecutive times. Malformed or very large argument payloads retain exact-string semantics.
      */
     protected checkGenericLoop(tailCalls: Array<{
         name: string;
         arguments: string;
     }>): LoopDetectionResult;
     /**
-     * Check for non-blacklist tool loop: any tool NOT in the blacklist with identical arguments
+     * Check for non-blacklist tool loop: any tool NOT in the blacklist with semantically identical JSON arguments
      * called N consecutive times (threshold: NON_BLACKLIST_LOOP_THRESHOLD).
      * Scans from the tail of input, collecting only non-blacklist function_call items.
      */

package/cli/dist-server/types/vendor/cbc-core/node/agent/tool-call-loop-guard-protocol.d.ts

@@ -27,7 +27,7 @@ export declare const TOOL_CALL_LOOP_STOPPED_MESSAGE = "Request aborted: user sto
  * - `ToolCallLoopDetector` 在**模型请求前**拦截，静默向模型注入停止消息，用户无感；
  *   它覆盖的是旧的三条规则（黑名单同参 4 次 / Read 同文件 40 次 / 非黑名单同参 40 次）。
  * - `ToolCallLoopGuard` 在**工具执行前**拦截，弹窗让用户自己决定继续还是停止；
- *   它覆盖新增的两条规则（同工具连续 40 次 / 周期序列重复 10 轮）。
+ *   它覆盖新增的两条规则（同工具连续 40 次，Bash 单独放到 80 次 / 周期序列重复 10 轮）。
  *
  * 两者刻意并存：旧规则的静默语义已被线上验证，不因新能力回归。
  */

package/cli/dist-server/types/vendor/cbc-core/node/agent/tool-call-loop-pattern.d.ts

@@ -5,8 +5,13 @@
  */
 import type { ToolCallLoopTriggerType } from '../../../../workspace/telemetry/lib/common/event/types/craft.js';
 export interface ToolCallLoopThresholds {
-    /** 同一工具连续调用达到该次数即判定为循环。 */
+    /** 同一工具连续调用达到该次数即判定为循环。Bash 走单独阈值。 */
     consecutiveThreshold: number;
+    /**
+     * Bash 连续调用的单独阈值。长任务里模型会连续跑很多条不同命令，
+     * 只看工具名时 40 次容易把正常推进误判成循环。
+     */
+    bashConsecutiveThreshold: number;
     /** AAB 块需要连续重复的轮数。 */
     sequenceRepeats: number;
 }
@@ -17,6 +22,8 @@ export interface ToolCallLoopHit {
     /** 重复序列的周期长度；AAB 恒为 3，连续同工具恒为 1。 */
     patternLength: number;
 }
+/** 与 `ToolNames.BASH` 对齐。模式识别层不依赖 agent-protocol，避免把工具名枚举拉进来。 */
+export declare const BASH_LOOP_TOOL_NAME = "Bash";
 export declare const DEFAULT_TOOL_CALL_LOOP_THRESHOLDS: ToolCallLoopThresholds;
 /** AAB 块的长度。多工具循环只识别这一种形状，因此是常量而非可配阈值。 */
 export declare const AAB_PERIOD = 3;
@@ -36,7 +43,7 @@ export declare class ToolCallLoopTracker {
      * 记录一次即将执行的工具调用，返回本次是否命中循环。
      *
      * 命中优先级：先判连续同工具，再判 AAB 重复。两条规则的阈值默认不重叠
-     * （40 次 vs AAB 重复 10 轮），实践中不会互相抢占。
+     * （普通工具 40 次、Bash 80 次 vs AAB 重复 10 轮），实践中不会互相抢占。
      */
     record(toolName: string): ToolCallLoopHit | undefined;
     /**
@@ -52,14 +59,18 @@ export declare class ToolCallLoopTracker {
  * - `ABC`（三者互不相同）通常是正常的多步工作流（读文件 → 改文件 → 跑测试，
  *   然后换下一个文件），按周期重复判它循环误伤面太大；
  * - `ABAB` 这类两工具交替同样不判，避免把翻页 / 分批处理误当循环；
- * - `AAA…` 属于连续同工具，由 consecutiveThreshold 那条规则负责。
+ * - `AAA…` 属于连续同工具，由 consecutiveThreshold / bashConsecutiveThreshold 那条规则负责。
  *
  * `X ≠ Y` 顺带保证了 AAB 一定是本原周期（唯一可能的更短整除周期是 1，
  * 那要求三个元素全等），所以不需要额外的本原性校验。
  */
 export declare function matchesRepeatedAabSequence(history: readonly string[], repeats: number): boolean;
 /**
- * 读取阈值配置。两个环境变量只用于 QA 快速复现，生产不设置即走默认值。
+ * 读取阈值配置。环境变量只用于 QA 快速复现，生产不设置即走默认值。
  * AAB 的周期是形状定义的一部分，不开放配置。
+ *
+ * `CBC_LOOP_GUARD_CONSECUTIVE_THRESHOLD` 只覆盖非 Bash 工具。Bash 用
+ * `CBC_LOOP_GUARD_BASH_CONSECUTIVE_THRESHOLD`，避免 QA 把通用阈值压低时
+ * 把长任务放宽一并关掉。
  */
 export declare function resolveToolCallLoopThresholds(env?: NodeJS.ProcessEnv): ToolCallLoopThresholds;

package/cli/dist-server/types/vendor/cbc-core/node/hooks/agent-trigger.d.ts

@@ -1,31 +1,15 @@
-/**
- * Agent-trigger payload helper, shared by SessionHookManager and ToolHookManager.
- *
- * Mirrors Claude Code's `createBaseHookInput` (utils/hooks.ts) so that every
- * hook event carries enough context for users to branch on
- * "main thread vs sub-agent" inside their Settings-level hooks.
- *
- * Rules (CC parity):
- *  - `agent_type` is the agent's display name; populated from `session.agentName`
- *    when set. On the main thread this is the `--agent` flag (when used) or the
- *    default agent name. Inside a sub-agent this is the sub-agent's `name`
- *    (e.g. "Explore", "Plan", "general-purpose").
- *  - `agent_id` is only meaningful inside a sub-agent run — CC leaves it
- *    `undefined` on the main thread. We honour the same convention by only
- *    emitting it when `session.storeId` is present (sub-agent sessions get a
- *    `agent-{8}` storeId; main sessions do not).
- *
- * Kept dependency-free so it can be imported from anywhere — including modules
- * that must avoid pulling the full `../session` barrel (which transitively
- * loads SessionManager / tips and triggers IoC initialisation).
- */
 export interface AgentTriggerLike {
     id?: string;
     agentName?: string;
     storeId?: string;
+    /** 会话 meta：身份标签要读 agentName / teamContext.memberName，parentSessionId 供子会话判定。 */
     meta?: {
         parentSessionId?: string;
-    };
+        agentName?: string;
+        teamContext?: {
+            memberName?: unknown;
+        };
+    } & Record<string, unknown>;
 }
 export declare function buildAgentTrigger(session: AgentTriggerLike | undefined | null): {
     agent_id?: string;

package/cli/dist-server/types/vendor/cbc-core/node/hooks/hook-protocol.d.ts

@@ -31,7 +31,10 @@ export interface HookInput {
      */
     reason?: SessionEndReason;
     /**
-     * User prompt content (for UserPromptSubmit event)
+     * User prompt content.
+     * - UserPromptSubmit: the submitted prompt text.
+     * - UserPromptExpansion: Claude Code spec required field, always sent — the
+     *   raw, pre-expansion text as typed by the user (e.g. "/deploy prod").
      */
     prompt?: string;
     /**

package/cli/dist-server/types/vendor/cbc-core/node/session/idle-queue-drain-service.d.ts

@@ -1,44 +1,7 @@
 /**
- * Idle Queue Drain Service (Mode A `session.queue` 通道)
- *
- * 为什么需要这个 service
- * =====================
- * 用户在 agent 还在跑（streaming 末尾、工具执行中等）时输入新消息，UI 调
- * `agentService.run([userMsg])` 进来，`MessageQueueAgentRunInterceptor`
- * (input-interceptors.ts:77-84) 看到 `inConversation=true`，把消息塞进
- * `session.queue` 并设 `skipRun=true`。当前 turn 自然结束、emit `agent_end`，
- * 但**没有任何组件**会主动调一次 `agentService.run([], session)` 来触发
- * interceptor 的 drain 分支（input-interceptors.ts:85-103，那条分支会
- * `mergeConsecutiveUserMessages` 把队列里的消息拍成一个新 turn）。
- *
- * 结果：消息僵在 `session.queue`，UI 显示"已发送"，agent 永远不回。
- *
- * `TeamInboxDispatchService` 看起来形态对，但它只检查
- * `RichMessageQueueManager`（团队成员消息进的那个 queue），全 codebase 只有
- * `team-create-tool.ts:332` 一处往 rich queue 写 —— 普通 TUI 用户输入完全
- * 走 `session.queue`，团队 dispatcher 看不到。
- *
- * 这个 service 就填这个空：每个 session 都订阅 `agent_end`，guard 通过后
- * 调一次空 input 的 `agentService.run`，让现有 interceptor 自己合并消费。
- *
- * 与 TeamInboxDispatchService 的关系
- * ==================================
- * - Mode A（默认）：`isDeferredDispatchEnabledSync()===false`。
- *   IdleQueueDrainService 接管 `session.queue` 的 drain；TeamInboxDispatchService
- *   也订阅了，但它看 rich queue（一般为空）→ short-circuit。
- * - Mode B：`isDeferredDispatchEnabledSync()===true`。
- *   IdleQueueDrainService 入口 short-circuit；TeamInboxDispatchService 走
- *   rich queue 的 immediate/pending 路径。
- * 两 service 各自有 `dispatching` Set，最坏情况下都是 short-circuit return，
- * 不会双重发起 run。
- *
- * 它不做的事
- * ==========
- * - 不动 `session.queue` 里的内容（让 interceptor 现有 mergeConsecutive 逻辑
- *   作为唯一消费点，避免逻辑漂移）。
- * - 不在 compact 中触发（`session.isCompressing` guard）。
- * - 不在 Mode B 中触发。
- * - 不影响 cancel 路径的 abort 行为（只在 `agent_end` 后做兜底）。
+ * Wake local queues after a turn ends. Mode A owns session.queue; Mode B tasks
+ * own its non-mirror items. Mode B main sessions remain with rich queue.
+ * MessageQueueAgentRunInterceptor remains the only dequeue/merge point.
  */
 import { Logger } from '../../../../workspace/telemetry/lib/common/index.js';
 import { AgentManager, AgentService } from '../agent/agent-protocol';
@@ -64,21 +27,6 @@ export declare class IdleQueueDrainServiceImpl implements IdleQueueDrainService
      * 空队列直接返回。
      */
     requestDrain(session: Session): void;
-    /**
-     * Guard 链 + 调 agentService.run 触发 interceptor 的 drain 分支。
-     *
-     * Guard 顺序（逐个 short-circuit return）：
-     *   1. 重入：同 session 上一次 tryDrain 还没 await 完。
-     *   2. compact 中：`session.isCompressing===true`。compact 自身的
-     *      continue-run 也会 emit `agent_end`，必须避让。
-     *   3. Mode B：rich queue 通道由 TeamInboxDispatchService 处理。
-     *   4. DI 兜底：headless 等变体可能没拉到 AgentService/AgentManager。
-     *   5. 空队列：没东西好 drain。
-     *   6. 取消记账在途：见下方注释。
-     *
-     * 失败回灌：interceptor 在 line 95 已经 `clearQueue`，如果后续 run 抛错，
-     * 队列里的消息会"被消费但又没真消费"，相当于丢了。所以在调 run 之前
-     * 快照 queue，run 抛错时检查 queue 是否被清空、被清空就把快照灌回。
-     */
+    /** Reuse the existing idle drain and its pre-result failure restoration. */
     private tryDrain;
 }

package/cli/dist-server/types/vendor/cbc-core/node/session/index.d.ts

@@ -8,6 +8,7 @@ export * from './session-response-host-protocol';
 export * from './background-task-protocol';
 export * from './root-session-scope';
 export * from './session-factory';
+export { assertSessionRuntimeOpen, closeSessionRuntime, isSessionRuntimeClosed, sessionRuntimeSignal, } from './session-runtime-lifecycle';
 export * from './session-admission-service';
 export * from './session-manager';
 export * from './session-store';
@@ -25,12 +26,14 @@ export { getSessionCanUseTool, resolveCanUseTool, resolveCanUseToolOwner, setSes
 export type { CanUseTool, CanUseToolOptions, CanUseToolOwner, PermissionBehavior, PermissionDecisionClassification, PermissionResult as CanUseToolPermissionResult, PermissionRuleValue, PermissionUpdate as CanUseToolPermissionUpdate, PermissionUpdateDestination, } from './can-use-tool';
 export * from './dual-channel-interaction';
 export * from './session-persistence';
+export * from './session-persistence-error';
 export * from './session-set-current';
 export * from './cancel-session-runtime-state';
 export * from './user-request-boundary';
 export { isTruncationRecoveryActive } from './truncation-recovery';
 export * from './aborted-stream-draft-store';
 export * from './stream-timeout-retry-budget';
+export { consumeRecoveryRequestPending } from './recovery-budget';
 export * from './session-run-state-machine-protocol';
 export * from './session-run-state-machine';
 export * from './session-run-state-projection-service';

package/cli/dist-server/types/vendor/cbc-core/node/session/interruption-service.d.ts

@@ -8,12 +8,44 @@ import { InterruptionService, type PendingApprovalView, Session, SessionHookMana
 import { SessionRunStateMachine } from './session-run-state-machine-protocol';
 type IIdleQueueDrainService = import('./session-protocol').IdleQueueDrainService;
 export declare class InterruptionServiceImpl implements InterruptionService {
+    private readonly resolvedSandboxItems;
     private pendingInterruptions;
     private itemToSessionMap;
     private interruptionQueues;
     private parentIdToMainSession;
     private childToMainSession;
     private waitForSubscriptions;
+    private readonly approvalSources;
+    private readonly handlingStates;
+    private readonly reportedStaleStates;
+    private readonly reportedDiscardedApprovals;
+    private readonly handledResults;
+    private readonly resumeProgress;
+    /**
+     * Terminal by design: a blocked continuation already proved it cannot make
+     * progress, and a later user request arrives on a *new* RunState, so the
+     * session is never stranded.
+     */
+    private readonly blockedResumeStates;
+    /**
+     * Deliberately not `session.meta.consecutiveEmptyDrainCount`: the idle
+     * empty-drain guard both increments that counter (tripping this
+     * continuation early, aborting a legitimate resume) and resets it
+     * (stretching the budget without bound).
+     */
+    private readonly resumeNoProgressCount;
+    private assertApprovalSource;
+    private approveSource;
+    private awaitPermissionReply;
+    /**
+     * A decision the user actually clicked must never disappear without a word.
+     *
+     * The card is dequeued and the deferred rejected, but the run that owned it
+     * is already gone — so nothing downstream surfaces the rejection and the
+     * user is left believing the tool was approved.
+     */
+    private reportDiscardedDecision;
+    private reportStaleSource;
     /**
      * 权限审批全局真相源（方案一：统一数据源）。
      *
@@ -61,6 +93,8 @@ export declare class InterruptionServiceImpl implements InterruptionService {
     protected readonly idleQueueDrainService?: IIdleQueueDrainService;
     protected readonly traceCollector?: SessionInterruptionTraceHost;
     protected get startupProfiler(): SessionInterruptionProfilerHost;
+    /** Claim before calling out: sandbox callbacks can throw or synchronously re-enter. */
+    private takeSandboxResolve;
     approve(item: RunToolApprovalItem, options?: {
         alwaysApprove?: boolean;
         scope?: 'session' | 'localSettings';
@@ -101,8 +135,9 @@ export declare class InterruptionServiceImpl implements InterruptionService {
      *
      * 幂等：未注册的 sessionId 为 no-op。
      */
-    releaseSession(sessionId: string): void;
-    protected handleInterruptions(session: Session, interruptions: RunToolApprovalItem[]): Promise<void>;
+    releaseSession(target: string | Session): void;
+    protected handleInterruptions(session: Session, interruptions: RunToolApprovalItem[], result?: RunResult<any, any> | StreamedRunResult<any, any> | undefined): Promise<void>;
+    private processInterruptions;
     protected executePendingManualPostCompactHook(session: Session, result: RunResult<any, any> | StreamedRunResult<any, any>): Promise<void>;
     waitFor(session: Session): Promise<void>;
     /**
@@ -334,15 +369,26 @@ export declare class InterruptionServiceImpl implements InterruptionService {
     private static sanitizeToolNotFoundMessage;
     private hasRecentModelErrorRetry;
     /**
-     * 检测是否已有 stream timeout 重试记录
-     * 避免反复重试导致无限循环
+     * 网络 / 流错误自动恢复的统一前置步骤：认领额度 → 可取消的指数退避 → 标记恢复轮。
+     *
+     * 认领放在退避之前、且晚于本 catch 里的第一个 await：session-manager 的 gate 在
+     * `result.completed` reject 后同步读取同一份预算判据，认领若早于 gate 读取，最后
+     * 一次重试会被 gate 误判为「预算已耗尽」而提前下发终态。
+     *
+     * 退避期间会话处于 RETRYING：失败的 run 与写入中断结果的 skipRun run 都已收尾回 idle，
+     * 这里重新置为 busy，TUI 继续显示进行中并响应 Esc，用户新消息进队列而不是直接起 run。
+     * 恢复 run 带 bypassMessageQueue 从 RETRYING 直接发起，中间不回 idle，不留让新 run
+     * 插入的空窗；恢复 run 收尾（AGENT_ENDED）时回 idle 并带出排队消息。
+     *
+     * 退避期间用户取消时退回额度、以 RUN_FAILED 收回 idle 并返回 `cancelled`，调用方不得
+     * 再发起。取消信号在等待前现取：写入中断结果的 skipRun run 会替换 `session.abortController`，
+     * 用户此后按下的 Stop 作用在新 controller 上；排队消息接管 owner 时，其 abort 会级联到这里。
      *
-     * 首 token 超时：允许最多 2 次重试（含线性延迟 2s/4s），给网络波动更多恢复机会
-     * 流数据超时：保持只重试 1 次
-     * 旧的基于历史消息窗口的检测不可靠：长任务（如 8 个子任务）会产生大量消息，
-     * 将 retry marker 推出 5 条消息的窗口，导致误判为"可以再次重试"
+     * 等待结束时若状态既不是 RETRYING 也不是 idle，说明 RETRYING 被迟到的收尾事件冲掉后
+     * 已有新 run 被接纳并在执行，返回 `superseded`，否则恢复 run 会与它同时写同一个会话。
+     * 此时不退回额度——新请求边界已经清零，再减一次会扣掉新链的额度。
      */
-    private incrementStreamTimeoutRetryCount;
+    private prepareRecoveryAttempt;
     /**
      * CLI TUI 手打 `/compact` 裸跑成功后补发 SessionStart('compact')。
      *

package/cli/dist-server/types/vendor/cbc-core/node/session/model-response-interceptors.d.ts

@@ -29,6 +29,24 @@ export declare class finishReasonErrorInterceptor implements ModelResponseInterc
     protected readonly sessionStore: SessionStore;
     protected readonly telemetryService: TelemetryService;
     intercept(ctx: ModelResponseInterceptorContext): Promise<boolean | void>;
+    /**
+     * 处理「已经产出实质内容之后才 `finish_reason=error`」：自动续写，最多 3 次、1s 起步 2 倍退避。
+     *
+     * 没有任何实质输出就 error 的两种形态（仅 reasoning / 零 token）在模型层被转成可重试的
+     * EmptyStreamError，走 interruption-service 的流错误恢复；三者认领同一份 error 预算。
+     *
+     * 能走到这里说明这次 run 已经结束：SDK 只要本轮还有可执行的工具调用就会继续循环，
+     * 不会把控制权交回。因此不存在「参数完整但尚未执行」的工具调用；万一出现，每次构造
+     * 请求前的 `fillFunctionCallResultHistory` 也会补齐配对，不会因孤儿调用触发上游 400。
+     * 本期只统计孤儿数量用于验证这一推论，不改补齐逻辑。
+     *
+     * 预算用尽、退避期间被取消或发起失败时都**不返回 `true`**：没有重跑在路上，本轮必须
+     * 正常收敛给上层，否则 CLI 会一直等一个不存在的 run。
+     */
+    private handleErrorFinishReason;
+    private writeErrorTerminalMessage;
+    /** 统计本轮以 error 收尾时残留的无配对结果工具调用，用于验证「此处不应有孤儿」的推论。 */
+    private logOrphanToolCallsOnError;
     private shouldSkipExpectedSubagentToolCalls;
     /**
      * 处理 length 类型的完成原因：从断点续写（#119765）。

package/cli/dist-server/types/vendor/cbc-core/node/session/recovery-budget.d.ts

@@ -0,0 +1,55 @@
+import type { Session } from './session-protocol';
+/**
+ * `finish_reason=error` 三种表现（已有输出 / 仅 reasoning / 零 token）共用的预算键。
+ *
+ * 三者是同一次上游故障的不同形态，而且会在恢复过程中互相转化（第一次零 token、
+ * 重试后只吐 reasoning、再重试吐了内容后又 error）。各记各的会让一次故障的总轮数
+ * 远超约定上限，所以必须认领同一个键。
+ */
+export declare const ERROR_RECOVERY_COUNT_META_KEY = "errorRecoveryCount";
+/**
+ * 流开始之后的网络错误（错误仍带原始 errno）使用的预算键。
+ *
+ * 响应头之前的连接失败由模型层连接级重试处理，耗尽后被归一化成 HTTP 502 上抛，
+ * 不会再走到这里——两层不会为同一次失败接力。
+ */
+export declare const NETWORK_RECOVERY_COUNT_META_KEY = "networkErrorRetryCount";
+/**
+ * `finish_reason=error` 后注入给模型的续写提示。
+ *
+ * 与截断续写（TRUNCATION_CONTINUATION_PROMPT）的区别是刻意去掉了「把剩下的工作拆小」：
+ * 那句是在修「一次输出太长」的因果，上游内部错误与输出长度无关，带上它既是错误归因，
+ * 也可能让模型把任务切碎、多烧轮次。同样不告诉模型「是服务端出错」——那会给它道歉和
+ * 复述的由头，与 no apology / no recap 自相矛盾。
+ */
+export declare const ERROR_RECOVERY_PROMPT: string;
+/**
+ * 包成 error-recovery system-reminder：stream-json 等输出通道会把只含 system-reminder
+ * 的内部用户消息清空丢弃，避免恢复提示混进用户可见的对话。
+ */
+export declare function buildErrorRecoveryReminder(): string;
+export declare function readRecoveryBudgetCount(session: Session, key: string): number;
+export declare function hasExhaustedRecoveryBudget(session: Session, key: string, limit?: number): boolean;
+/**
+ * 同步完成「判定 + 认领」，返回本次恢复的序号（1-based）；预算已用尽返回 `undefined`。
+ *
+ * 判定与消耗必须在同一个同步段里完成：分散到 `await` 两侧时，两处调用可能同时在
+ * `count = limit - 1` 通过检查，上限就不再成立。
+ */
+export declare function claimRecoveryBudget(session: Session, key: string, limit?: number): number | undefined;
+/** 认领后没有真正发起恢复（退避期间被取消、发起失败）时退回额度。 */
+export declare function releaseRecoveryBudget(session: Session, key: string): void;
+/** 清零并返回旧值，供日志使用。 */
+export declare function resetRecoveryBudget(session: Session, key: string): number;
+/**
+ * 「下一个模型请求是自动恢复轮」的一次性标记。
+ *
+ * 恢复轮的首 token 时限比首次请求短（见模型层）。这个标记在发起恢复 run 前由恢复
+ * 入口显式写入，由模型层在该 run 的第一个模型请求上读取并清除——之后同一 run 的工具
+ * 循环请求回到普通时限。不能改用重试计数反推「是否恢复轮」：计数跨多个模型请求累计，
+ * 反推会让恢复链之后的所有请求都被当成恢复轮。
+ */
+export declare const RECOVERY_REQUEST_PENDING_META_KEY = "recoveryRequestPending";
+export declare function markRecoveryRequestPending(session: Session): void;
+export declare function consumeRecoveryRequestPending(session: Session | undefined): boolean;
+export declare function clearRecoveryRequestPending(session: Session): void;

package/cli/dist-server/types/vendor/cbc-core/node/session/session-hook-manager.d.ts

@@ -208,4 +208,19 @@ export declare class SessionHookManagerImpl implements SessionHookManager {
      * Does NOT support continueRequest.
      */
     executeFinalStopHooks(session: Session, reason?: FinalStopReason): Promise<void>;
+    /**
+     * UserPromptExpansion — Claude Code 官方事件：任何用户输入的命令/skill 展开成
+     * prompt、送进模型之前统一从这里触发，可阻断展开。`command_args` / `prompt` 按
+     * 官方 schema 是必填字段（无参数时发空串，而不是整个省略 key）。
+     */
+    executeUserPromptExpansionHooks(session: Session, payload: {
+        expansionType: 'slash_command' | 'mcp_prompt' | string;
+        commandName: string;
+        commandArgs: string;
+        commandSource?: string;
+        prompt: string;
+    }): Promise<{
+        allowed: boolean;
+        message?: string;
+    }>;
 }

package/cli/dist-server/types/vendor/cbc-core/node/session/session-manager.d.ts

@@ -33,6 +33,15 @@ export declare class SessionManagerImpl implements SessionManager, ApplicationLi
     private sessionStartTimes;
     private addHistoryLocks;
     private resultSubscriptions;
+    private readonly resultSubscriptionOwners;
+    /**
+     * 每个 sessionId 当前活着的会话对象。身份守卫不能只认 result 订阅的登记：
+     * 订阅由调用方事后 `initRunResultHandler` 挂上（teammate / agent-task），而
+     * drain / team-inbox / turn-metrics 在 create 时就按 id 注册了，中间那段
+     * 「已注册、无订阅」的窗口里 owner 读不到，旧任务的延迟释放会摘掉同 id 后继
+     * 会话的注册。WeakRef：登记不得延长会话寿命，deref 为空即无需保护的对象。
+     */
+    private readonly liveSessionsById;
     private overridePermissionModes;
     private overrideModels;
     /**
@@ -177,7 +186,7 @@ export declare class SessionManagerImpl implements SessionManager, ApplicationLi
      *
      * 幂等：未注册的 id 为 no-op；DI 容错：精简变体缺 service 时降级跳过。
      */
-    releaseInMemory(id: string): void;
+    releaseInMemory(target: string | Session): void;
     rename(session: Session, name: string): Promise<void>;
     setOverridePermissionMode(sessionId: string, mode: PermissionMode): void;
     getOverridePermissionMode(sessionId: string): PermissionMode | undefined;

package/cli/dist-server/types/vendor/cbc-core/node/session/session-persistence-error.d.ts

@@ -0,0 +1,43 @@
+/**
+ * Typed local-transcript I/O failure (issue #119545).
+ *
+ * The only reason this type exists: `addHistory` must be able to tell "the
+ * local JSONL copy could not be written" apart from "this turn is broken".
+ * Windows `EBUSY` on the transcript is a third-party sharing violation, and a
+ * side-channel copy must never terminate a turn that is still executing tools.
+ *
+ * Everything else about persistence stays best-effort on purpose: there is no
+ * pending queue, no cross-process outbox and no durability barrier, so nothing
+ * else in the runtime waits on, or can be vetoed by, this file.
+ */
+export type SessionPersistencePhase = 'open' | 'stat' | 'write' | 'close' | 'rollback';
+export type SessionPersistenceRollbackOutcome = 'not-needed' | 'succeeded' | 'failed';
+export interface SessionPersistenceErrorOptions {
+    phase: SessionPersistencePhase;
+    cause: unknown;
+    attempt?: number;
+    rollbackOutcome?: SessionPersistenceRollbackOutcome;
+    retryable?: boolean;
+}
+/**
+ * Windows sharing violations and their POSIX lookalikes. `EBUSY` is the one
+ * this ticket measured (25% of appends within 10ms of the previous write);
+ * `EPERM` / `EACCES` ride along because the same scanners produce them.
+ */
+export declare function isRetryableSessionPersistenceError(error: unknown): boolean;
+export declare class SessionPersistenceError extends Error {
+    readonly phase: SessionPersistencePhase;
+    readonly code?: string;
+    readonly attempt: number;
+    readonly rollbackOutcome: SessionPersistenceRollbackOutcome;
+    readonly retryable: boolean;
+    constructor(options: SessionPersistenceErrorOptions);
+}
+/**
+ * Duck-typed on purpose: core and the host package can each hold their own copy
+ * of this class, so `instanceof` is not reliable across the package boundary.
+ * The required fields keep a foreign error named `SessionPersistenceError` from
+ * being mistaken for one of ours — an unrecognized error still fails the run,
+ * which is the safe direction.
+ */
+export declare function isSessionPersistenceError(error: unknown): error is SessionPersistenceError;