@epoch-agent/core 2.8.0 → 3.1.1

package/dist/index.d.ts

@@ -1,6 +1,6 @@
-import { ToolProvider, EpochTool, EpochPlugin, ToolExposure, EpochSkill, HookType, EpochHook, PluginContext, QuestionRequest, QuestionAnswer, ComplianceCategory, ComplianceAction, ToolArtifactInput, ToolArtifact, TrustLevel, TrustManager as TrustManager$1, TokenUsage, EpochConfig, BudgetBreach, NoticeCode, ProviderType, EpochMessage, JsonSchema, ModelSelection, BackgroundTaskInfo, EpochToolCall, Telemetry, HookManager as HookManager$1, Lang, PermissionManager as PermissionManager$1, ApprovalRequest, ApprovalReply, AgentRoleScope, AgentRoleSource, EpochUserContent, EpochContentPart, AgentRole, PermissionLevel, PlanProposal, ScheduleRunnerSpec, ScheduleBackendKind, ScheduleTrigger, OperationType, ScheduleAllowlist, ScheduleDefinition, ScheduleRunStatus, ScheduleRun, SchedulePendingApproval, DiagnosticSink, CustomCommandDef, ModelRef, ExpandedCommand, CustomCommandSource, ContextBreakdown, WireMcpConnector, AgentEvent, SelectionContext, SetSelectionResult, ModelEntry, ReasoningState, ReasoningChoice, PermissionRuleLists, MoneyDigits, CurrencyDisplay, KeybindingTable, Diagnostic, KeybindingReport, FileOmitReason, SessionOmitReason, EpochToolResult, EpochUserCommand, EpochTurnFacts, LocalizedDetail, ApprovalScope, RuleValue, Operation, ApprovalOutcome, PermissionDecision, ScheduleDraft, ScheduleWideningKind, WireAgentEvent, WireAgentEnvelope, HookEvent, LogFn, HookRegistration, HookHandler, HookContext, VerifyResult, EpochFilePart, EpochSessionPart, MentionSet, EpochImagePart, TrustExecGrant, DecidedTrustLevel, TrustScope, TrustGrant, TrustRecord } from '@epoch-agent/protocol';
-export { API_KEY_ENV_VARS, AgentEvent, AgentEventOf, AgentEventType, ApprovalAnswer, ApprovalOutcome, ApprovalReply, ApprovalRequest, ApprovalScope, BudgetBreach, COMPLIANCE_ACTIONS, COMPLIANCE_CATEGORIES, ComplianceAction, ComplianceCategory, DecidedTrustLevel, EpochConfig, EpochHook, EpochPlugin, EpochSkill, EpochTool, FinishReason, HookContext, HookEvent, HookHandler, HookRegistration, HookType, HookManager as IHookManager, PermissionManager as IPermissionManager, TrustManager as ITrustManager, JsonSchema, MAX_ATTACH_BYTES, MAX_ATTACH_FILES, MAX_ATTACH_TOTAL_BYTES, MAX_SESSION_ATTACH_BYTES, MAX_SESSION_REFS, OPERATION_TYPES, Operation, OperationType, PERMISSION_LEVELS, PLAN_OUTCOMES, PROVIDER_INFOS, PROVIDER_TYPES, PermissionDecision, PermissionLevel, PlanApprovalOutcome, PlanProposal, PluginContext, ProviderInfo, ProviderType, TokenUsage, ToolContext, ToolDefinition, ToolExposure, ToolResult, TrustExecGrant, TrustGrant, TrustLevel, TrustRecord, TrustScope, TrustTier, VerifyResult, apiKeyEnvVar, extractAllMentions, extractMentions, extractSessionMentions, getProviderInfo, isOperationType, isPermissionLevel, isPlanOutcome, isProviderType, normalizeApproval } from '@epoch-agent/protocol';
-import { IsolationBackend, SqliteDatabase, ParseIssue, ShellFlavor } from '@epoch-agent/infra';
+import { ToolProvider, EpochTool, EpochPlugin, ToolExposure, EpochSkill, HookType, EpochHook, PluginContext, QuestionRequest, QuestionAnswer, ComplianceCategory, ComplianceAction, ToolArtifactInput, ToolArtifact, TrustLevel, TrustManager as TrustManager$1, TokenUsage, EpochConfig, BudgetBreach, NoticeCode, ProviderType, EpochMessage, JsonSchema, ModelSelection, AgentMessage, EpochUserContent, TeamTask, TeamTaskStatus, TeamTaskPatch, AgentMemberInfo, AgentMemberStatus, BackgroundTaskInfo, EpochToolCall, Telemetry, HookManager as HookManager$1, Lang, PermissionManager as PermissionManager$1, ApprovalRequest, ApprovalReply, AgentRoleScope, AgentRoleSource, EpochContentPart, AgentEvent, AgentRole, PermissionLevel, PlanProposal, ScheduleRunnerSpec, ScheduleBackendKind, ScheduleTrigger, OperationType, ScheduleAllowlist, ScheduleDefinition, ScheduleRunStatus, ScheduleRun, SchedulePendingApproval, BoardChannel, BoardThread, BoardPost, DiagnosticSink, CustomCommandDef, ModelRef, ExpandedCommand, CustomCommandSource, ContextBreakdown, WireMcpConnector, SelectionContext, SetSelectionResult, ModelEntry, ReasoningState, ReasoningChoice, PermissionRuleLists, MoneyDigits, CurrencyDisplay, KeybindingTable, Diagnostic, KeybindingReport, FileOmitReason, SessionOmitReason, EpochToolResult, EpochUserCommand, EpochTurnFacts, EpochDiffSnapshot, LocalizedDetail, ApprovalScope, RuleValue, Operation, ApprovalOutcome, PermissionDecision, ScheduleDraft, ScheduleWideningKind, WireAgentEvent, WireAgentEnvelope, HookEvent, LogFn, HookRegistration, HookHandler, HookContext, VerifyResult, EpochFilePart, EpochSessionPart, MentionSet, EpochImagePart, TrustExecGrant, DecidedTrustLevel, TrustScope, TrustGrant, TrustRecord } from '@epoch-agent/protocol';
+export { API_KEY_ENV_VARS, AgentEvent, AgentEventOf, AgentEventType, ApprovalAnswer, ApprovalOutcome, ApprovalReply, ApprovalRequest, ApprovalScope, BudgetBreach, COMPLIANCE_ACTIONS, COMPLIANCE_CATEGORIES, ComplianceAction, ComplianceCategory, DecidedTrustLevel, EpochConfig, EpochHook, EpochPlugin, EpochSkill, EpochTool, FinishReason, HookContext, HookEvent, HookHandler, HookRegistration, HookType, HookManager as IHookManager, PermissionManager as IPermissionManager, TrustManager as ITrustManager, JsonSchema, LEGACY_LEVEL_ALIASES, MAX_ATTACH_BYTES, MAX_ATTACH_FILES, MAX_ATTACH_TOTAL_BYTES, MAX_SESSION_ATTACH_BYTES, MAX_SESSION_REFS, OPERATION_TYPES, Operation, OperationType, PERMISSION_LEVELS, PLAN_OUTCOMES, PROVIDER_INFOS, PROVIDER_TYPES, PermissionDecision, PermissionLevel, PlanApprovalOutcome, PlanProposal, PluginContext, ProviderInfo, ProviderType, TokenUsage, ToolContext, ToolDefinition, ToolExposure, ToolResult, TrustExecGrant, TrustGrant, TrustLevel, TrustRecord, TrustScope, TrustTier, VerifyResult, apiKeyEnvVar, approvalPolicyForLevel, extractAllMentions, extractMentions, extractSessionMentions, getProviderInfo, isOperationType, isPermissionLevel, isPlanOutcome, isProviderType, normalizeApproval, resolvePermissionLevel } from '@epoch-agent/protocol';
+import { IsolationBackend, SqliteDatabase, ParseIssue, ShellFlavor, SandboxMode, FailureVerdict } from '@epoch-agent/infra';
 export { BubblewrapOptions, DangerMatch, IS_WINDOWS, IsolationBackend, IsolationOptions, LogLevel, SeatbeltOptions, WINDOWS_HIDE_FLAGS, buildBwrapArgs, buildProfile, checkDangerousCommand, checkObfuscation, createLogger, detectBackend, getDefaultShell, getPythonCommand, isInWorkspace, isReadOnlyCommand, isolate, maskApiKey, probeBubblewrap, probeSeatbelt, complianceDir as resolveComplianceDir, policiesDir as resolvePoliciesDir, setLogLevel } from '@epoch-agent/infra';
 import { z } from 'zod';
 import { existsSync } from 'node:fs';
@@ -182,12 +182,47 @@ declare class ToolRegistry {
     /** 批量注册独立工具 */
     registerTools(tools: EpochTool[], source?: string): void;
     private addTool;
+    /**
+     * 把**某一个来源**的工具表整个换成新的一份，**保住已有工具的位置**。
+     *
+     * ## 为什么不能「撤干净再注册一遍」（2026-10-26）
+     *
+     * 撤回再注册在功能上等价，但**顺序会变**：`this.tools` 是 `Map`，删掉再插
+     * 等于让这个来源的工具全部挪到表尾。而工具表的顺序是**请求前缀的一部分** ——
+     * OpenAI / DeepSeek 的前缀缓存要求「两次请求从第 0 个 token 起完全相同」，
+     * 顺序一动，整段历史按全价重新预填。装了几台 MCP 的会话里，任意一台
+     * `list_changed` 或重连都会触发这件事，而用户看到的是账单，不是报错。
+     *
+     * 所以这里逐个 `set`：`Map` 对**已存在的键**不改插入顺序，于是已发出去的那些
+     * 工具逐字节不动，只有真正新增的才 append 到表尾。hermes 那边把同一条判据写成
+     * `preserve_prefix=True`，docstring 逐字是「existing tools keep their slot and
+     * the schema bytes already sent, new tools append at the tail」。
+     *
+     * ## 和 {@link unregisterBySource} 的分工
+     *
+     * 那个是「**全部**撤掉」（删除一个来源、整表销毁），这个是「**换成这一批**」。
+     * MCP 那条全量刷新的路走这个 —— 它一次 `tools/list` 拿到的是那台 server 的
+     * 完整现状，包括「哪些没了」。
+     *
+     * ## 三条语义
+     *
+     * 1. **新一批里没有的** → 真删（那是 server 撤掉的工具）；
+     * 2. **两边都有** → 就地覆盖（位置不变，description / schema 可以变）；
+     * 3. **只有新一批有** → append 到表尾。
+     *
+     * 跨来源撞名仍然是「先注册的赢」（同 `addTool`），**同批内重名则是先到的赢**
+     * —— 与逐条 `addTool` 的行为一致，只是不再记一条 `keptFrom === droppedFrom`
+     * 那样的自我冲突（那条记录在启动诊断里读起来像 bug）。
+     *
+     * @returns 真被删掉（新一批不再提供）的条数
+     */
+    replaceBySource(tools: readonly EpochTool[], source?: string): number;
     /**
      * 撤掉某个来源的全部工具。
      *
-     * 给「按 server 整体替换」用：MCP 的 `tools/list` 本来就是全量返回，
-     * 逐个 diff 只是自找麻烦 —— 撤干净再重新注册一遍
-     * （对齐 gemini-cli `ToolRegistry.removeMcpToolsByServer()` 的粒度）。
+     * 给「整个来源消失」用（删掉一台 server、销毁注册表）。**热更新不要用它** ——
+     * 撤干净再注册会让这个来源的工具全部挪到表尾，把请求前缀缓存整个废掉，
+     * 判据见 {@link replaceBySource}。
      *
      * 连带清掉与这个来源相关的冲突记录：不清的话每刷新一次就多攒一条，
      * 启动诊断里会出现同一个撞名重复十遍。
@@ -690,8 +725,10 @@ declare class CodeSandbox {
  * 模型压根拿不到这个能力。
  *
  * 工具输出会**如实附上本次的隔离级别**。这不是啰嗦：
- * macOS 上是 OS 强制的（写不出沙箱、默认断网），Linux/Windows 上只有进程隔离，
- * 两者的风险差一个量级，不能让人以为都一样安全。
+ * macOS 上是 OS 强制的（写不出沙箱、默认断网），Windows 上没有 OS 级后端 ——
+ * 但 **JavaScript 那档从 2026-10-27 起挂着 Node 自己的权限模型**
+ * （`sandbox/node-permission.ts`，Node ≥ 22.5 才挂），Python 那档仍然只有进程隔离。
+ * 几档的风险差一个量级，不能让人以为都一样安全。
  *
  * ## ⚠️ 2026-08-16 起 `terminal` 也走隔离层了，但**边界不一样**
  *
@@ -1709,6 +1746,44 @@ interface CompressConfig {
      * 不给（或空串）时摘要提示词**逐字**保持原样，理由同 `instruction` / `plan`。
      */
     goal?: string;
+    /**
+     * **撞墙之后**那一次压缩：不按尾部 token 预算留，只保最小的那几条
+     * （2026-10-28）。
+     *
+     * ## 它修的是哪一种救不回来
+     *
+     * `determineBoundaries` 的尾部预算 = `threshold × contextLength × targetRatio`
+     * （[compressor.ts](./compressor.ts) 的 Phase 2）。窗口设得越大，这一份预算越宽
+     * ——**宽到能把整段历史都吃进去**，于是中段为空、`compress()` 在 Phase 2
+     * 之后直接返回、`shrank()` 判为没变小，最后原样抛。
+     *
+     * 而这不是假想的边角：撞墙**恰恰常常发生在 token 侧还宽松的时候**。
+     * 图片的 token 按宽高估（一张 2 MB 截图只记一千出头），字节却是几 MB ——
+     * 于是「窗口 200K、历史才 10K token」这种看起来毫无压力的会话，请求体已经
+     * 撞穿了网关。那时正常那一套边界计算一条都不愿松手，而我们要的正是
+     * 「能拿多少拿多少」。
+     *
+     * ## 落到哪一档（判据是一次明确的选择，不是顺手）
+     *
+     * `true` 时尾部预算按 **0** 算，于是尾部循环只受那两条下限约束：
+     * `protectLastN` 条、`minTailUserMessages` 条 user 消息。
+     *
+     * - **头部的 `protectFirstN` 不动。** 保住的那一条是会话开头的第一条用户消息，
+     *   摘要模板的 `## Goal` 正是对着它写的 —— 连它一起压掉，摘要就失去了
+     *   「这一摊到底要干什么」的锚点，压出来的是一段不知道自己为了什么而写的转述。
+     * - **那两条下限也不动。** 它们守的是「刚才在干什么」，压掉之后模型会拿一份
+     *   摘要接着干一件它已经做到一半的事，而它不知道做到哪儿了。
+     *
+     * 也就是说：`force` 松的是**按 token 摊开的那份预算**，不是任何一条保护。
+     *
+     * ## 谁给、谁不给
+     *
+     * **只有 `AgentLoop` 撞墙后的那一次给**（`compressNow` 的 `force`）。
+     * 自动压缩的两条线（轮初硬线、轮末软线）和手动 `/compact` 都不给 ——
+     * 那几处上一发是**正常结束**的，没有「这一发根本发不出去」这个前提，
+     * 按正常预算留够近期内容才是对的。
+     */
+    force?: boolean;
 }
 /**
  * 压缩用的消息形状。
@@ -1725,6 +1800,27 @@ interface CompressMessage {
     toolCallIds?: string[];
     /** tool 消息回应的 tool call id */
     toolCallId?: string;
+    /**
+     * 这一步模型的思考原文（2026-10-28）。
+     *
+     * ## 它为什么必须**穿过**压缩器，而不是在这里被丢掉
+     *
+     * 两件事，缺一件就是 bug：
+     *
+     * 1. **head / tail 原样保留那一段，思考不能掉。** 压缩的形状是
+     *    `head + 摘要 + tail`，两头是逐字带过去的。而 DeepSeek 思考模式 + `tools`
+     *    时要求**每一条**历史 assistant 都带 `reasoning_content`（判据在
+     *    `EpochMessage.reasoning` 上）。这里不带上，压一次就把两头的思考洗掉了 ——
+     *    不是因为「模型变笨」，是下一次请求直接 400。
+     * 2. **中间段进摘要时，思考是素材的一部分。** 摘要是唯一活下来的那一段，
+     *    而「为什么这么做」几乎全在思考里（正文常常只有一句「我查一下」）。
+     *    只喂 `content` 等于让摘要模型对着一堆动作猜动机。
+     *
+     * ⚠️ **它是 `content` 之外的一格，不是并进 `content`**：并进去的话
+     * `unflattenMessage` 还原时分不出哪半是正文、哪半是思考，回灌给模型的
+     * `reasoning_content` 会连正文一起塞进去 —— 而模型会读到「自己说过两遍」。
+     */
+    reasoning?: string;
 }
 /**
  * 摘要调用的产出。
@@ -2448,6 +2544,324 @@ interface UtilityModelInfo {
     issue?: string;
 }
 
+/**
+ * 一个成员的收件箱 —— 子 agent 那一侧的投递口。
+ *
+ * ## 它实现的是 `SteerSource`
+ *
+ * 引擎（`loop.ts:723`）在每个**步骤边界**调一次 `take()`，把拿到的东西当成
+ * 一条 `steer` 事件插进当前这一轮。所以「子任务跑到第 3 步收到一条消息、
+ * 当轮改变行为」这件事，**不需要新机制** —— 主会话的插话走的就是这条路
+ * （`agent-session.ts:174` 把宿主的队列原样透给 `RunInput.steer`）。
+ *
+ * 我们做的只是：给子 agent 也接一个源，而那个源的另一头是 `send_message`。
+ *
+ * ## 满了丢最老的，但要**说一声**
+ *
+ * 计划里的风险一是上下文膨胀：成员互发消息时历史会一直长，而子 agent 的
+ * 上下文刻意是小的。所以给收件箱一个硬容量。
+ *
+ * 丢最老的而不是拒收新的：拒收会让**最新的纠正**进不来，而那正是这个功能
+ * 存在的理由。代价是老消息没了 —— 所以 `take()` 时如果丢过，前面补一行
+ * 说明。静默丢话是最坏的一种：模型不知道自己漏看了什么。
+ *
+ * ## 为什么 `take()` 一次取干净
+ *
+ * 判据和 `SteerSource.take()` 上那段逐字相同：两条消息之间没有模型的回答，
+ * 分两轮送进去等于让它对着第一句先答一遍 —— 而这两句本来是**同一批**
+ * 纠正。这里 additionally 把几条消息拼成同一条 user 内容，省一次角色切换。
+ */
+
+/** 一个成员收件箱最多攒多少条还没被读走的消息 */
+declare const DEFAULT_INBOX_CAPACITY = 20;
+declare class AgentInbox implements SteerSource {
+    private readonly capacity;
+    private queue;
+    private dropped;
+    constructor(capacity?: number);
+    /**
+     * 投一条。返回 `false` = 因为满了挤掉了一条更老的。
+     *
+     * 返回值不是「成功与否」：**这条总是进去了**。它只用来让调用方在工具结果
+     * 里说一句「顺带挤掉了 N 条」，而不是让模型以为一切照旧。
+     */
+    push(msg: AgentMessage): boolean;
+    pending(): boolean;
+    /**
+     * 取走全部待读消息，折成**一条** user 内容。
+     *
+     * 前缀由 protocol 的 `agentMessageLine` 拼 —— 那是两个消费方（这里和父会话的
+     * `TaskNoticeTracker`）逐字相同的唯一保证，见那个函数的注释。
+     */
+    take(): EpochUserContent[];
+    /** 还没被读走的条数。`list_agents` 和排障用 */
+    get size(): number;
+}
+
+/**
+ * 团队共享任务板（阶段 2）—— 一组带依赖和归属的任务，多个成员看得见同一份。
+ *
+ * ## 为什么是内存、不是 SQLite
+ *
+ * 判据和 `registry.ts` 文件头那条**逐字相同**：这份东西的读者是**同一个进程里
+ * 的那几个成员**。别的进程既不该看见你的任务、也不该往里写 —— 那是两拨互不
+ * 相干的活，混在一块板上只会互相干扰。要跨进程共享的是**讨论板**（阶段 3），
+ * 它才走 SQLite。
+ *
+ * ## `expectedRevision` 是 compare-and-set，不是「乐观锁的装饰」
+ *
+ * 两个成员同时看到「任务 3 还是 pending」，各自都决定去认领它。没有这道闸门
+ * 的话后写的那个会静默盖掉前一个，而**两边都收到成功**—— 于是两个人干同一件
+ * 事，而板上写着只有一个 owner。
+ *
+ * 所以 `update()` 收一个调用方**上一次读到的** revision：对不上就整笔拒绝，
+ * 一个字段都不改，并告诉它现在是多少（让它可以重读再决定，而不是瞎猜）。
+ * 不传 = 不检查，那条路留给「我确实是唯一写者」的场景。
+ *
+ * 这和 harness 的 `team_task_update`、codex 的 DAG 板是同一条规矩。
+ */
+
+/** 一次写入的结果。失败时**一个字段都没改** */
+type TaskWriteResult = {
+    ok: true;
+    task: TeamTask;
+} | {
+    ok: false;
+    reason: string;
+};
+declare class TeamTaskBoard {
+    private readonly capacity;
+    private readonly tasks;
+    /** 插一个变更回调。registry 拿它把「板子变了」也算进「团队变了」 */
+    private readonly listeners;
+    constructor(capacity?: number);
+    onChange(cb: () => void): () => void;
+    private notify;
+    /**
+     * 建一条。
+     *
+     * `dependsOn` 里出现不存在的 id 是**硬失败**：那种依赖永远不会被满足，
+     * 而任务会一直卡在「等一个不存在的东西」上，看起来像「它还没开始」。
+     */
+    create(input: {
+        title: string;
+        description?: string;
+        owner?: string;
+        dependsOn?: string[];
+    }): TaskWriteResult;
+    get(id: string): TeamTask | undefined;
+    list(filter?: {
+        status?: TeamTaskStatus;
+        owner?: string;
+    }): TeamTask[];
+    /**
+     * 改一条。
+     *
+     * `expectedRevision` 给了就必须**正好等于**当前值 —— 这是两个成员同时认领
+     * 同一件事时唯一能拦住「后写的静默盖掉前一个」的地方。
+     */
+    update(id: string, patch: TeamTaskPatch, expectedRevision?: number): TaskWriteResult;
+}
+
+/**
+ * 进程内的成员表 —— 谁在、它现在什么状态、它的收件箱在哪。
+ *
+ * ## 为什么**不持久化**
+ *
+ * 一个成员就是一次 `new AgentLoop(...).run()`（`session-factory.ts:1306`），
+ * 跑完那个实例就没人持有了。它能被「记住」的唯一载体是会话库里那一行
+ * （`persistDelegateTurn`，带 `parent_id`）—— 而那是**事后回看**用的，
+ * 不是「它还活着」的证据。
+ *
+ * 所以这张表每个进程一套，进程退出即消失。这和阶段 3 的讨论板是**两回事**：
+ * 板子要跨进程共享（那是它存在的理由），所以它走 SQLite；roster 跨进程没有
+ * 意义 —— 别的进程里的成员不在你这个进程里，你既看不到它的收件箱也打不断它。
+ * 混在一起做会让「板上有一条消息，但收件人是另一个进程里早就结束的成员」
+ * 变成一种没法处理的中间态。
+ *
+ * ## 为什么收件箱住在表里而不是调用方手里
+ *
+ * 两个不相干的调用方要往同一个成员塞话：父 agent 的 `send_message`
+ * （`core/src/tools/builtin/send-message.ts`）和阶段 2 的成员之间互发。
+ * 收件箱跟着成员走，这两条路就都只需要一个 `agentId`。
+ *
+ * 另外子 agent 那一侧（`runtime/src/session-factory.ts`）拿到收件箱的方式
+ * 是**按 `subSessionId` 反查** —— 它手里只有这个，没有 agentId。所以表同时
+ * 按两个键索引，见 `bySession()`。
+ */
+
+/**
+ * 一次投递的结果。
+ *
+ * `ok: false` 时消息**没有进任何收件箱** —— 调用方（那个工具）要把 `reason`
+ * 原样交给模型，别自己改写。原因是这条路的失败模式全是「模型以为送到了」：
+ * 发给一个已经收工的成员，它下一轮永远不来，而父 agent 会干等着。
+ */
+type DeliveryResult = {
+    ok: true;
+    to: string;
+    status: AgentMemberStatus;
+} | {
+    ok: false;
+    to: string;
+    reason: string;
+};
+declare class TeamRegistry {
+    private readonly inboxCapacity;
+    private readonly members;
+    /** 按子会话 id 反查 —— 子 agent 那一侧只有这个键 */
+    private readonly bySessionId;
+    /**
+     * 主会话的收件箱们 —— 按 sessionId 索引。
+     *
+     * 不再只有一个 `lead` 收件箱：每个主会话有自己的身份（用 sessionId 做 agentId），
+     * 这样不同会话派出的成员不会串话，且会话之间可以互相通信。
+     */
+    private readonly mainInboxes;
+    /** 登记过的主会话 id（判据在 `registerSession` 上） */
+    private readonly sessions;
+    /**
+     * 打断用的回调（`interrupt_agent` 拉的就是它们）。
+     *
+     * 和 `members` 分开存：那个控制器住在 `DelegateManager.runSingleTask` 里，
+     * 而成员登记**早于**控制器诞生（先登记才能早点收到消息）。所以这条线是
+     * 「后补的」，判据在 `setAbort` 上。
+     */
+    private readonly aborters;
+    /** 「团队变了」的订阅者（`wait_agent` 挂在这里） */
+    private readonly listeners;
+    /** 共享任务板（阶段 2）。它也变动时也会叫醒 `wait_agent` */
+    readonly tasks: TeamTaskBoard;
+    constructor(inboxCapacity?: number);
+    /** 订阅「团队变了」。返回取消订阅 */
+    onChange(cb: () => void): () => void;
+    /**
+     * 叫醒所有等着的（`wait_agent` 的底座）。
+     *
+     * ⚠️ **`setActivity` 刻意不叫**：它每完成一步就变一次，接上去的话
+     * `wait_agent` 会在一个子 agent 跑得正欢时每一步都返回一次，而调用方要的是
+     * 「有实质变化」（新人 / 新消息 / 任务动了）。
+     */
+    private notify;
+    /**
+     * 等下一次团队变化。
+     *
+     * @returns `true` = 真的变了；`false` = 等到超时或被中止。
+     *   两种情况都只报「有没有变」，**不带变了什么** —— 调用方应该自己去
+     *   `list_agents` / `team_task_list` 读一遍，而不是相信一个可能已经过时的摘要。
+     */
+    waitForChange(ms: number, signal?: {
+        readonly aborted: boolean;
+    }): Promise<boolean>;
+    /**
+     * 派出去一个成员。返回它的 `AgentMemberInfo`（含 `agentId`）。
+     *
+     * `agentId` 今天就是子会话 id：一次派活的子会话本来就唯一，再造一个短名
+     * 只是多一个要同步的映射。阶段 2 的 `spawn_teammate` 要「具名」时再让
+     * 调用方传 `agentId` 进来。
+     */
+    createMember(args: {
+        sessionId: string;
+        parentSessionId: string;
+        /** 具名成员（阶段 2 的 `spawn_teammate`）。缺省 = 子会话 id */
+        agentId?: string;
+        /** 角色名。纯展示，进 `list_agents` */
+        role?: string;
+    }): AgentMemberInfo;
+    /**
+     * 补上「怎么打断这个成员」。
+     *
+     * 控制器诞生在 `DelegateManager.runSingleTask` 里，而成员登记比它早 ——
+     * 所以那条线只能事后接进来。没接上的成员 `interrupt()` 返回 `false`，
+     * 而不是假装打断了。
+     */
+    setAbort(agentId: string, fn: () => void): void;
+    /** 打断一个成员。返回 `false` = 没有可打断的（已经收工，或者从没接上） */
+    interrupt(agentId: string): boolean;
+    /** 按 `agentId` 取。返回的是**快照**，改它不会影响表 */
+    get(agentId: string): AgentMemberInfo | undefined;
+    /** 按子会话 id 取 —— 子 agent 那一侧唯一的入口 */
+    bySession(sessionId: string): AgentMemberInfo | undefined;
+    /** 全部成员，按派出去的先后 */
+    list(): AgentMemberInfo[];
+    /** 把一个成员的收件箱交给子 agent 那一侧（`sub.run({ steer })`） */
+    inboxOf(agentId: string): AgentInbox | undefined;
+    /** 同上，按子会话 id 查 */
+    inboxBySession(sessionId: string): AgentInbox | undefined;
+    /**
+     * 登记一段主会话 —— 「这个 id 是活的会话」的唯一凭据。
+     *
+     * ## 为什么需要它
+     *
+     * `deliver` 现在要同时接受两种收件人：成员（在 `members` 里）和**别的主会话**
+     * （不在表里）。只看「表里没有」就当成主会话的话，一个拼错的成员名会被静默
+     * 投进一个永远没人读的箱子 —— 那正是 `send_message` 从一开始就要防的
+     * 「调用方以为送到了」。
+     *
+     * 所以主会话先登记再寻址，剩下的未知 id 仍然报错。登记点只有一处：
+     * `AgentLoop.runTurns()` 开跑时登记自己（判据在那儿）。
+     */
+    registerSession(sessionId: string): void;
+    /** 这个 id 是不是一段登记过的主会话（诊断和 `list_agents --all` 用） */
+    hasSession(sessionId: string): boolean;
+    /** 登记过的全部主会话 id，按登记先后 */
+    sessionIds(): string[];
+    /**
+     * 取主会话的收件箱。**不存在时会新建** —— 这样成员给一个还没调用过团队工具的
+     * 主会话发消息时，它下一轮能收到，而不是因为「收件箱不存在」失败。
+     */
+    mainInbox(sessionId: string): AgentInbox;
+    /**
+     * 记它此刻在干什么。
+     *
+     * 来源是 `SubAgentRunner.onProgress` 那条通道。**没有就不叫**，别填占位符 ——
+     * `list_agents` 会把它原样印出来，一句话占位会让模型以为那是真进度。
+     */
+    setActivity(agentId: string, line: string): void;
+    /**
+     * 把它重新标成「在跑」（阶段 2 的 `followup_task`）。
+     *
+     * ## 为什么不是再 `createMember` 一次
+     *
+     * 成员已经在表里了 —— 再建一次撞名，而那个错会以「`followup_task` 明明成了、
+     * 却报成员名被占用」的形态出现。这一条只动状态，不动身份：`sessionId`、
+     * `parentSessionId`、`role`、`startedAt` 全部保留 —— 续跑的是**同一个**成员，
+     * 不是新派出去的一个。
+     *
+     * ## `finishedAt` 必须清掉
+     *
+     * `markFinished` 有一道「`finishedAt` 只写一次」的闸。不清的话这一轮跑完
+     * 那道闸会把新的收工挡掉 —— 成员会永远停在 `running`，而 `list_agents`
+     * 上那一行看着像还在干活。
+     *
+     * `activity` 也清：它上一轮最后那句话（「读完了 src/a.ts」）说的是**上一次**
+     * 的收尾，留着会让 `list_agents` 在它刚醒来时报告一句过期的话。
+     */
+    markRunning(agentId: string): void;
+    /** 收工（或挂掉）。`finishedAt` 只写一次 —— 重复调用是空操作 */
+    markFinished(agentId: string, status: Extract<AgentMemberStatus, 'idle' | 'finalized' | 'failed'>): void;
+    /**
+     * 投一条消息。
+     *
+     * ## `finalized` / `failed` 一律失败，消息**不进收件箱**
+     *
+     * 计划里那条规矩（照 codex 的 `api.rs:35-36`）：通知不唤醒已终结的 agent。
+     * 收进一个永远不会有下一轮读它的箱子，等于给调用方一个假成功 —— 而父 agent
+     * 接下来会照常等回音。
+     *
+     * 阶段 2 有了 `followup_task`（2026-10-30）之后，唤醒走的是**另一条路**：
+     * 用 `resumeSessionId` 另起一轮 `run()`，而不是往这个箱子里塞一条「等下一轮」
+     * 的消息。两件事刻意分开 —— 收进一个不会有人读的箱子却报成功，正是这一条要防的。
+     */
+    deliver(msg: AgentMessage): DeliveryResult;
+    /** 造一条消息。`id` 现在没有消费方（阶段 2 的重试去重要用），但形状先定下 */
+    static message(args: {
+        from: string;
+        to: string;
+        text: string;
+    }): AgentMessage;
+}
+
 /**
  * 给人看的路径：工作区内走相对路径，分隔符统一成 `/`。
  *
@@ -2505,15 +2919,74 @@ type BackgroundTaskSource = () => readonly BackgroundTaskInfo[];
  */
 declare class TaskNoticeTracker {
     private readonly source;
+    /**
+     * 成员表（阶段 1）。给了才把成员发来的话拌进这条 note。
+     *
+     * 不给 = 行为和改造前逐字节相同 —— 用例、嵌入宿主不必为了跑一轮
+     * 对话去建一张成员表。
+     */
+    private readonly team?;
+    /**
+     * 讨论板的订阅拉取点（阶段 3）。`pending` 纯读，`markRead` 推到最新。
+     *
+     * ⚠️ **`markRead` 只在确定要返回 note 时调**（见下面 `notice()` 里那一段）：
+     * 提前推游标等于把还没进上下文的帖子标记成「看过了」。
+     */
+    private readonly board?;
     private readonly seen;
-    constructor(source: BackgroundTaskSource | undefined);
+    constructor(source: BackgroundTaskSource | undefined, 
+    /**
+     * 成员表（阶段 1）。给了才把成员发来的话拌进这条 note。
+     *
+     * 不给 = 行为和改造前逐字节相同 —— 用例、嵌入宿主不必为了跑一轮
+     * 对话去建一张成员表。
+     */
+    team?: TeamRegistry | undefined, 
+    /**
+     * 讨论板的订阅拉取点（阶段 3）。`pending` 纯读，`markRead` 推到最新。
+     *
+     * ⚠️ **`markRead` 只在确定要返回 note 时调**（见下面 `notice()` 里那一段）：
+     * 提前推游标等于把还没进上下文的帖子标记成「看过了」。
+     */
+    board?: {
+        pending: () => Array<{
+            target: string;
+            count: number;
+        }>;
+        markRead: () => void;
+    } | undefined);
+    /**
+     * 取走父亲收件箱里的成员消息，折成 notice 里的那几行。
+     *
+     * ⚠️ **只能在确定要返回一条 note 时调**（`take()` 会清空队列）。
+     * 现在的调用点（`loop.ts:1367`）拿到什么就往 `messages` 里推什么，
+     * 所以那里是安全；哪天有人把它改成「先问一句再决定」，这个函数就要跟着改。
+     */
+    private takeAgentMessages;
     /**
      * 算出这一轮要报的话；没有变化时返回 `null`。
      *
      * 返回 `null` 而不是空串很重要 —— 调用方据此决定**要不要往 messages 里塞
      * 一条消息**。塞一条空消息会白白多一轮 role 切换，还可能打断 prompt cache。
      */
-    notice(): string | null;
+    notice(sessionId?: string): string | null;
+    /**
+     * 和 {@link notice} 同一次计算，但把**成员发来的那几行**单独交出来
+     * （2026-11-02）。
+     *
+     * 判据是它有两类消费方：模型那一侧要整段（后台任务 + 成员消息 + 讨论板），
+     * 而**界面和会话历史只要成员消息那一半** —— 后台任务状态每轮都可能变，
+     * 把它落进库等于往对话里灌噪音。拆开之后两个消费方各取所需，
+     * 而不是让落盘那一侧拿字符串前缀去猜哪几行是消息。
+     *
+     * ⚠️ **取走就没了**（`take()` 清空队列），所以 `notice()` 和它
+     * **不能对同一个箱子里调两次** —— 调一次拿 `text` 和 `agent` 两样。
+     * 两个方法都留着的理由是旧调用方只要一句话。
+     */
+    noticeDetailed(sessionId?: string): {
+        text: string;
+        agent: string[];
+    } | null;
 }
 /**
  * 一条变化的措辞。**不带输出、不带 pid**。
@@ -2834,6 +3307,28 @@ interface AgentConfig {
      * 而它们同名的那半个词已经让人查错过一次方向。
      */
     maxOutputTokens?: number;
+    /**
+     * 单次请求里**所有图片 base64 的合计**上限（字节，2026-10-28）。
+     *
+     * **缺省 = `DEFAULT_MAX_REQUEST_IMAGE_BYTES`（8 MiB，猜的）**，判据全文
+     * （含「为什么这个数没有权威出处」）在 `provider/body-limit-cache.ts` 的文件头。
+     *
+     * ⚠️ 它是**字节**这条线，和 `contextLength`（token）是两个量纲 ——
+     * 一张 2 MB 的截图在 token 账上只记一千出头，在字节账上是 2.7 MB。
+     * 两条线都要有，因为只有文本那一半时 token 会先抓住，而只有图片时
+     * token 那条线**永远抓不住**。
+     *
+     * 撞上一次之后，学到的值会在比它更小时顶替它（`effectiveImageBudget`）。
+     */
+    maxRequestImageBytes?: number;
+    /**
+     * 数据目录（`~/.epoch` 那一层），学到的字节上限存进它的 `cache/` 下。
+     *
+     * 不给就**不学、也不读**历史学习值 —— 退回只用配置值/缺省值。理由同
+     * `MultimodalPolicy.homeDir`：这一层够不着「这台机器的数据目录在哪」，
+     * 自己猜一个 `homedir()` 在测试和多 profile 场景下会写错地方。
+     */
+    homeDir?: string;
     /**
      * 预先算好的项目上下文（含工作区信任判定和已加载的指令文件）。
      *
@@ -3177,6 +3672,35 @@ interface AgentConfig {
      * core 不 import plugin-terminal（分层不允许），所以这条线由装配层接。
      */
     backgroundTasks?: BackgroundTaskSource;
+    /**
+     * 成员表（阶斵 1）。给了就在每轮 LLM 请求前把**成员发来的话**拌成一条 note
+     * （与上面 `backgroundTasks` 那条并排，但各自一条）。
+     *
+     * 不给 = 行为与改造前逐字节相同。子 agent 那条**不要填**：它没有可寻址的
+     * 成员表，它的收件箱是另一回事（`RunInput.steer`，由 `subRunner` 接）。
+     *
+     * ⚠️ 只取类型（编译后擦掉）：`TeamRegistry` 反过来依赖 `SteerSource`，
+     * 运行期走 type-only 才不会成环。
+     */
+    team?: TeamRegistry;
+    /**
+     * 讨论板的订阅拉取点（阶段 3）。给了就在每轮请求前把「你订阅的格子有新帖」
+     * 拌成一条 note（与上面两条并排，各自一条）。
+     *
+     * 两个回调而不是一个对象：`markRead` 必须**只在确定要返回 note 时**调
+     * （它会把游标推到最新），而 `pending()` 是纯读。把它们合成一个
+     * `pendingAndMark()` 会让「这次没返回 note」变成一次静默漏看。
+     *
+     * 不给 = 行为与改造前逐字节相同。子 agent 那条**不要填** ——
+     * 它的收件箱是 `RunInput.steer`，和板子无关。
+     */
+    board?: {
+        pending: () => Array<{
+            target: string;
+            count: number;
+        }>;
+        markRead: () => void;
+    };
     /**
      * 内容合规闸门（core 的 `compliance/`）。给了就在两处生效：
      * 模型输出（`agent/turn.ts` 那个唯一出口）和用户输入（发请求之前）。
@@ -3225,6 +3749,15 @@ interface HistoryEntry {
     role: 'user' | 'assistant';
     content: string;
     parts?: EpochContentPart[];
+    /**
+     * 这一轮的思考原文（2026-10-28）。
+     *
+     * ⚠️ **必须能跟着历史穿过来。** 原来它只落在会话库的 `messages.reasoning` 列上
+     * 给人看，`loadHistory()` 一个字都不带 —— 于是刷新页面 / `--resume` 之后下一条
+     * 消息发出去，DeepSeek 看不见上一轮的 reasoning_content，当场 400。
+     * 判据在 registry 的 `CARRIES_REASONING_BACK` 上。
+     */
+    reasoning?: string;
 }
 interface RunInput {
     /** 纯文本或多模态部件数组。两种形态 AI SDK 都原生接受，不需要在这里分支 */
@@ -3272,6 +3805,26 @@ interface RunInput {
      * 不给就是今天的行为：这一轮跑完才轮到下一条消息。
      */
     steer?: SteerSource;
+    /**
+     * 这一轮每产出一个事件就旁路回调一次（2026-10-27）。
+     *
+     * ## 为什么是在 `run()` 上开个口，而不是改成让调用方用 `stream()`
+     *
+     * `run()` 和 `stream()` 走的是同一个 `runTurns()`，但 `stream()` 不回
+     * `RunResult`（它的 `turns` 是内部数组，调用方拿不到）。子 agent 那一路
+     * 既需要完整结果（它的汇总要交给父 agent），又需要知道「跑到哪一步了」
+     * （后台作业的 `task_output` 一直只写着「还没跑完」）。改 `stream()` 的返回
+     * 等于把两个生成器合并，而那是另一笔账。
+     *
+     * ## 默认什么都不做
+     *
+     * 不给这一格 = 改造前的行为，引擎一处都不多花。
+     *
+     * ## ⚠️ 回调里不要抛
+     *
+     * 它住在引擎的事件循环里，抛出来会把整轮掀翻。要防护自己在回调里做完。
+     */
+    onEvent?: (ev: AgentEvent) => void;
 }
 /**
  * 「正在跑的这一轮里，用户又说话了吗」——**由宿主实现，引擎只来拉**。
@@ -3336,6 +3889,16 @@ interface TurnRecord {
         result: string;
     }>;
     duration: number;
+    /**
+     * 在这**一次请求之前**插进来的消息（2026-11-02）。今天只有一种来源：
+     * 子 agent 的收件箱（`drainSteer` 在步骤边界取走的 `send_message`）。
+     *
+     * 它进这一步的判据是**顺序**：这些消息是在本步那次模型请求之前进上下文的，
+     * 所以落盘时它们应该排在本步 assistant 行**前面**（`persistDelegateTurn`
+     * 那一侧就是这么用的）。不带它的话，子会话的历史里只有它自己说过的话，
+     * 「谁跟它说了什么」查不到 —— 而子 agent 恰恰是靠这些话才改的行为。
+     */
+    received?: string[];
 }
 /** 中止信号的最小接口（AbortSignal 也满足） */
 interface AbortLike {
@@ -3347,37 +3910,39 @@ interface AbortLike {
  *
  * LLM 调用 delegate_task 工具，派发子任务给独立 Agent 并行执行。
  *
- * ## 后台子 agent：接口留着了，**这一轮没实现**（方案 49 PR-3）
+ * ## 两种派法：同步等（默认）和后台作业（`background: true`）
+ *
+ * 默认仍然是**同步等**：`delegate()` 一路 `await` 到所有子任务结束才返回，
+ * 这一条一个字没改 —— 大多数委托十几次工具调用就回来了，模型拿到结论直接接着
+ * 往下干，是它要的形状。
  *
- * 今天 `delegate_task` 是**同步等**的：`delegate()` 一路 `await` 到所有子任务
- * 结束才返回，于是父 agent 那一轮就卡在这儿。方案 49 §3.1 把这一格列成
- * 「作业种类之三：后台子 agent —— **没有**（`delegate_task` 是同步等的）」，
- * 而 §3.3 的判据是「现在统一，不等它」：等到真做后台子 agent 时再统一，
- * 代价是那时要同时改三处已经发出去的工具。
+ * `background: true` 是 2026-10-26 接上的第三类作业（`JobKind = 'agent'`）：
+
+ * - 派完**立刻返回作业 id**（`a1`），父回合接着干别的
+ * - 作业登记在**派活的那个会话**名下（`task_*` 那道按会话分区的墙靠它）
+ * - 子任务结束 / 失败 / 被杀时，`task_output` 读得到汇总，下一轮开头
+ *   `TaskNoticeTracker` 会挂一条「a1 已结束」的 `user` note
+ * - **父回合的终止不再打到它身上**：用户按停只停父回合，后台子任务继续跑
+ *   （四家竞品一致：Claude Code 在后台 agent 的 abort controller 上专门留了
+ *   一句注释说明它不挂父链）。要收掉它只有两条路 —— `task_stop a1`，或者
+ *   进程退出
  *
- * PR-3 把作业表下沉到了 [infra/jobs.ts](../../../infra/src/jobs.ts)，
- * 那张表的 `JobKind` 里**已经有 `'agent'` 这一档**，接法因此是确定的：
+ * ### 为什么不学另外三家「一律后台」
  *
- * ```ts
- * const job = registerJob<{ abort: AbortController }>({
- *   sessionId: parentSessionId,   // 归派活的那个会话 —— task_* 那道墙靠它
- *   kind: 'agent',
- *   label: task.goal,             // 一行标签就是它的目标（见 JobInfo.label）
- *   maxOutput: …, artifactsDir: …, artifactLabel: 'agent',
- *   stop: async () => controller.abort(),  // 「怎么收」由产出方给
- *   terminates: true,             // 子 agent 有终点，task_wait 对它有意义
- *   detail: { abort: controller },
- * });
- * ```
+ * 那三家（codex / hermes-agent / deepseek-harness）没有这个开关，它们的
+ * 委托入口本来就**只有后台一种**。我们保留默认同步，判据是我们的宿主没有
+ * 它们那套推送：`epoch -p` 一轮结束就是结束，TUI 空转时也不会自己开口。
+ * 一轮里「派出去然后等结论」仍然是最常见的形态，把它也改成异步，模型得
+ * 每派一次就 `task_wait` 一次，等于白多一轮往返。
  *
- * 之后 `task_list` / `task_output` / `task_wait` / `task_stop`
- * **一行都不用改**就认得它（那四个已经是 kind 无关的了），`epoch doctor` 的
- * 作业一节同理。要补的只有 `job-notice.ts` 的 `KIND_MARK` ——
- * 那是一张 `Record<JobKind, string>`，漏了会在编译期报缺键。
+ * ### 作业的 `stop` 收的是控制器，不是进程
  *
- * ⚠️ **刻意不在这里放一个空壳**（没有 `startBackground()` 占位）：一个没有调用方
- * 的入口会被下一个人当成「已经能用了」，而它的权限口径（后台派活要不要重新过
- * `delegate_task` 那一档 `command`）还没判过。真做那一轮要答的就是这个问题。
+ * `JobSpec.stop` 收的是一个 `AbortController.abort()` —— 子 agent 不是子进程，
+ * 退出时那张按 pid 记的表摸不到它。所以「进程退出时收干净」这件事在这一族上
+ * 是靠**进程一起没了**实现的，不是靠 `release()`。
+ *
+ * ⚠️ **`detail` 里只放 controller**：`task_*` 那四个工具不读它，`jobSandbox()`
+ * 读的那一格（`sandbox`）在这一族上不存在，于是它照旧返回 `undefined`。
  */
 
 /** 子任务定义 */
@@ -3391,6 +3956,26 @@ interface SubTask {
      * 是常见形态，强制整批同角色没道理。
      */
     role?: string;
+    /**
+     * 具名成员（阶段 2 的 `spawn_teammate`）。缺省 = 用子会话 id。
+     *
+     * 给了之后 `send_message` / `interrupt_agent` 都能按这个名字找到它 ——
+     * 而 `delegate_task` 派出去的匿名成员只能靠 `list_agents` 看到那个
+     * `delegate-xxxx`。重名由 registry 直接抛（不会静默改名）。
+     */
+    agentId?: string;
+    /**
+     * 接着这个**子会话**再跑一轮（阶段 2 的 `followup_task`）。
+     *
+     * 给了之后：
+     * - 会话 id 就用它（不现生成 `delegate-xxxx`）—— 而“用同一个 id”就是这整
+     *   条路的实现：runner 会按它把库里那段历史装回来；
+     * - **不重新登记成员**（那个成员已经在了，重登记会撞名），改走 `markRunning`。
+     *
+     * ⚠️ 它和 `agentId` **不绑定**：匿名成员（`delegate_task` 派出去的）也有一行
+     * 子会话，也能被续。只是它们没有名字，得用 `list_agents` 看到的那个 id 寻址。
+     */
+    resumeSessionId?: string;
 }
 /** 委托参数（工具接收） */
 interface DelegateArgs {
@@ -3399,6 +3984,11 @@ interface DelegateArgs {
     max_concurrent?: number;
     /** `goal` 简写形式的角色名 */
     role?: string;
+    /**
+     * `true` = 派到后台立刻返回（作业 id 形如 `a1`）。缺省 `false` = 同步等，
+     * 与改造前逐字节相同。判据与取舍见文件头「两种派法」那一节。
+     */
+    background?: boolean;
 }
 /** 委托结果 */
 interface DelegateTaskResult {
@@ -3413,9 +4003,23 @@ interface DelegateTaskResult {
     }>;
     total_duration: number;
 }
+/** `delegate()` 的返回值。后台那一档多两个字段，同步那一档不受影响 */
+interface DelegateOutcome {
+    success: boolean;
+    output: string;
+    duration: number;
+    /** 只有后台派活才有 —— 模型拿它去 `task_output` / `task_wait` / `task_stop` */
+    jobId?: string;
+    /** 父回合是不是被放走了（后台那一档）。**不是**「有没有作业」 */
+    background?: boolean;
+}
 /**
  * 子 Agent 被禁止的工具 [Hermes]。
  *
+ * ⚠️ `send_message` **不在**这个名单里（2026-10-30 起，阶段 1 的父子单通道）。
+ * 它曾经在（继承自 Hermes 的名单），但那时候全仓也没有这个工具的实现 ——
+ * 那是一个**预防性的封禁**，不是做过又删掉的东西。放行的判据写在下面那一条。
+ *
  * plan 模式那两个（方案 35）在这里不是「子任务用不上」，是**会串台**：
  * 子 agent 和父 agent 共用同一个 `PermissionManager`（见 build.ts 的 runner），
  * 子 agent 调一次 `enter_plan_mode` 就把**父会话**的权限级别压成了只读，
@@ -3426,7 +4030,21 @@ declare const BLOCKED_TOOLS: readonly string[];
 interface DelegateConfig {
     max_concurrent_children: number;
     max_spawn_depth: number;
+    /**
+     * 一个子任务最多跑多久（毫秒）。**`0` = 不限时**。
+     *
+     * 真源是 `config.delegate.taskTimeoutSec`（秒），在 `build.ts` 里折成毫秒；
+     * 构造函数里那个 `900_000` 只给不经过配置的调用方（用例、嵌入宿主）。
+     */
     task_timeout: number;
+    /**
+     * 成员表（阶段 1）。给了才登记成员、才能被 `send_message` 寻址到。
+     *
+     * 不给 = 行为和改造前逐字节相同（用例、嵌入宿主不必为了跑一次子任务去建表）。
+     * 它和上面两个数是不同类别的东西（一个是实例、两个是数量），但都从同一个
+     * `createDelegateTool` 的配置面进来 —— 拆成两个参数得多改一打调用方。
+     */
+    team?: TeamRegistry;
 }
 declare class DelegateManager {
     private config;
@@ -3438,29 +4056,43 @@ declare class DelegateManager {
      *
      * @param parentSessionId 派活的那个会话（`ToolContext.sessionId`）。一路带到
      *   `runner` 上，让子任务的花费和文件快照记到**它**头上而不是装配时那个会话
+     * @param signal 父回合的终止信号。**只有同步那一档会挂到子任务上** ——
+     *   后台派活的判据见文件头「两种派法」
      */
-    delegate(args: DelegateArgs, parentSessionId: string, signal?: AbortLike): Promise<{
-        success: boolean;
-        output: string;
-        duration: number;
-    }>;
+    delegate(args: DelegateArgs, parentSessionId: string, signal?: AbortLike): Promise<DelegateOutcome>;
+    /**
+     * 把这一批登记成一格 `agent` 作业。
+     *
+     * 归**派活的那个会话**（不是子任务自己那个 `delegate-xxxx`）：`task_*` 那道
+     * 按会话分区的墙靠这一格 —— 记到子任务名下的话，父会话一结束就谁都看不见、
+     * 也停不掉了。
+     */
+    private registerJob;
     private normalizeTasks;
+    /**
+     * 分批跑，每批最多 `maxConcurrent` 个。
+     *
+     * @param signal **整批**那个控制器的信号（不是父回合的）—— 每一格再各自
+     *   派生一个，判据在 {@link runSingleTask} 上
+     * @param onDone 每收一格回调一次。后台那一档用它往作业缓冲里写进度；
+     *   同步那一档不传（写进去也没有人读 —— 那一档没有作业）
+     */
     private runWithConcurrency;
     /**
      * 跑一个子任务。
      *
      * ## 每个子任务一个自己的 controller（2026-09-24）
      *
-     * 父回合的终止和这一格的超时**都打到它上面**，子 agent 拿到的是它的 signal。
-     * 原来两样都没有接：`sub.run()` 不带 signal，于是父会话按了终止，父回合要干等
-     * 所有子任务跑完（每个最多 `task_timeout`，一批一批串着等）；而超时只是
-     * `Promise.race` 抢答 —— 父回合往下走了，子 agent 在后台接着跑、接着花钱，
-     * 屏幕上一个字都看不见。
+     * 进来的 `signal` 是**整批**那个控制器的（`delegate()` 建的），每格再链一个
+     * 自己的：这一格的超时只掐它自己，而 `task_stop` / 父回合终止打的是整批那一个，
+     * 于是两件事都成立 —— 超时不会误伤兄弟，收批也不会漏掉哪一格。
      *
-     * 父 signal 是鸭子类型（`ToolContext.signal` 只保证有 `aborted`）时接不上监听，
-     * 只在开跑前判一次 —— 真宿主递下来的都是真 `AbortSignal`。
+     * 父回合的终止是不是真的会打下来，取决于派法：同步那一档 `delegate()` 把
+     * 父 signal 链到整批控制器上，后台那一档**不链**（判据在文件头）。
      */
     private runSingleTask;
+    /** 进度那一行里的「谁、干了什么、多久」—— 和汇总标题同一套写法 */
+    private describeResult;
     private buildSummary;
 }
 
@@ -3496,18 +4128,60 @@ interface SubAgentRunner {
      * 实现方要把它交给子 agent 的 `run()` —— 不交的话按了终止它照跑，判据在
      * `DelegateManager.runSingleTask` 上。可选只是为了不拆已有的调用方
      */
-    signal?: AbortSignal): Promise<{
+    signal?: AbortSignal, 
+    /**
+     * 子任务跑的过程中每完成一步回调一次（2026-10-27）。
+     *
+     * 收的是一行已经拼好的人话（`读文件 `src/a.ts``），不是事件对象 ——
+     * 两个调用方（作业缓冲 / 未来的其他通道）要的是同一句话，而把事件形状
+     * 漏上去等于让每个调用方重写一遍折行逻辑。
+     *
+     * **同步那一档目前不给**：父回合正卡在这个工具调用上，没有地方显示它。
+     * 后台那一档接了 —— 那里的 `task_output` 在此之前只能看到「还没跑完」。
+     */
+    onProgress?: (line: string) => void, 
+    /**
+     * 这一次是不是**接着一个已有的子会话**跑（阶段 2 的 `followup_task`）。
+     *
+     * ⚠️ 收一个对象而不是第 8 个位置参数：这个接口已经有七格了，再加一格
+     * 位置参数之后，每处调用都变成一串「第四个是 role、第六个是 signal」的
+     * 排列谜题。而对象只增不减，下一个开关加进去也不用改签名。
+     *
+     * 实现方看到 `resume` 为真时应该把 `sessionId` 那段**已有历史**装进去
+     * （`session-store.loadHistory()`）—— 不装的话第二次跑就是一段全新的对话，
+     * 而「再跑一轮」的全部意义就是它还记得上一次。
+     */
+    runOptions?: SubAgentRunOptions): Promise<{
         text: string;
         error?: string;
     }>;
 }
+/** {@link SubAgentRunner} 第 8 个参数 */
+interface SubAgentRunOptions {
+    /**
+     * 接着这个子会话的**已有历史**跑。
+     *
+     * 缺省（`undefined` / `false`）= 这是一次全新的派活，`sessionId` 那一格
+     * 是个刚生成的 id，库里没有它那一行。
+     */
+    resume?: boolean;
+}
 /**
  * @param roles 可派的角色表（方案 18）。**函数而不是数组** —— 角色表理论上
  *   可以在运行期变，而工具描述是每次 `list()` 时读的，给数组就把它钉死在
  *   装配那一刻。这跟 `toolProvider` 是同一条规矩（方案 15）。
  *   不给 = 没有角色系统，`role` 入参一律报错，其余行为与改造前一致。
  */
-declare function createDelegateTool(runner: SubAgentRunner, config?: Partial<DelegateConfig>, roles?: () => readonly AgentRole[]): EpochTool;
+declare function createDelegateTool(runner: SubAgentRunner, config?: Partial<DelegateConfig>, roles?: () => readonly AgentRole[], 
+/**
+ * 拿到这里面的那个 manager（阶段 2 的 `spawn_teammate` 要复用同一个）。
+ *
+ * 为什么要它：`spawn_teammate` 和 `delegate_task` 走的是**同一套派活逻辑**
+ * （并发、超时、成员登记、收尾），差只差在参数。各建一个 manager 也能跑，
+ * 但那样两边会给同一个 team 建两份互不相干的调度状态 —— 而那正是将来
+ * 「为什么超时时间不一样」这类问题的温床
+ */
+onManager?: (manager: DelegateManager) => void): EpochTool;
 
 /**
  * goal 的类型（[方案 52](../../../../docs/verify/VERIFY_RECORD-52-goal.md)）——
@@ -4019,13 +4693,20 @@ declare function createMemoryTool(memory: MemoryManager$1): EpochTool;
  *
  * ⚠️ **这一段 2026-08-28 之前写的是「`run_code` 的边界在权限管线，不在进程隔离」，
  * 那句话被 PR-3 判为假**（程序里 `import('node:fs')` 直通，权限管线整个被绕过）。
- * 今天的口径是「一次 `run_code` = 一次任意本机代码执行，边界是审批那一下」，
+ * 那时改成了「一次 `run_code` = 一次任意本机代码执行，边界是审批那一下」，
  * 全文在 [PR-3 记录 §二](../../../../docs/verify/VERIFY_RECORD-51-code-mode-pr3.md)。
  *
- * **但这个文件的立意不受影响**，而这一点值得说清：它跑在我们自己的进程里的一个
- * worker 线程上，所以这四道上限守的是**「别把宿主拖死」**（死循环、吃内存、
- * 一个写错的 `for` 调一万次工具），不是「别越权」。越权那一半今天由审批兜着。
- * 也就是说下面这张表**仍然成立**，只是它列的不再是「多出来的全部能力」：
+ * **2026-10-27 又收窄了一层**：`runner.ts` 给 worker 挂了 `--permission` +
+ * 清空的 env（判据在 [policy.ts](./policy.ts) 的文件头）。所以今天的口径是
+ * 「审批是边界，权限策略把程序限制在工作目录内、起不了子进程、看不见 env」。
+ * ⚠️ **但下面的表仍然成立，它守的东西也没变** —— 这个文件管的是「别把宿主拖死」，
+ * 不是「别越权」。权限模型不管死循环、不管吃内存、更不管
+ * 「一个写错的 `for` 调一万次工具」，而这四格里没有一格能被 `--permission` 代替。
+ *
+ * 它跑在我们自己的进程里的一个 worker 线程上，所以这四道上限守的是
+ * **「别把宿主拖死」**（死循环、吃内存、一个写错的 `for` 调一万次工具），
+ * 不是「别越权」。越权那一半今天由审批 + 权限策略两层兜着 ——
+ * 而下面这张表列的是**权限策略一格都盖不到**的那部分：
  *
  * | 多出来的能力                      | 这里的哪一格                              |
  * | --------------------------------- | ----------------------------------------- |
@@ -4114,14 +4795,14 @@ declare const CODE_MODE_LIMITS: CodeModeLimits;
  * | ------------ | ---------------------------------------------- | ---------------------------------------- |
  * | 干什么       | 算东西、处理数据                               | **编排工具调用**                         |
  * | 能不能碰宿主 | **不能** —— 写不出沙箱、默认断网、读不到 `$HOME` | **必须能** —— 它的全部意义就是回调工具  |
- * | 隔离级别     | macOS 上 OS 强制（Seatbelt）                   | **一点都没有**，跑在我们自己的 worker 线程里 |
- * | 安全模型     | 沙箱是边界                                     | **审批是边界**（见下一节，2026-08-28 拍板）|
+ * | 隔离级别     | macOS 上 OS 强制（Seatbelt）                   | worker 线程 + Node 权限模型（`code-mode/policy.ts`） |
+ * | 安全模型     | 沙箱是边界                                     | **审批是边界**；权限策略只收窄「程序能碰什么」       |
  *
  * 所以 `sandbox/sandbox.ts` 的那整套设计（沙箱目录在 tmpdir、`~/.epoch` 在读黑名单
  * 里）对这个工具**一条都不适用** —— 一个连 `~/.epoch` 都读不到的程序怎么调
  * `file_read`。**别把两个工具的措辞「统一」**，它们说的是两条不同的路。
  *
- * ## ⚠️ 它的边界是**审批**，不是隔离（2026-08-28 拍板，方案 51 PR-3）
+ * ## ⚠️ 边界是**审批**；权限策略只是让那次审批的语义变准
  *
  * 这一段 2026-08-28 之前写的是「一个 `run_code` 程序能做的事**逐字等于**模型
  * 一个个调那些工具能做的事」。**那句话是假的**，而且是被实测推翻的：程序跑在
@@ -4132,16 +4813,36 @@ declare const CODE_MODE_LIMITS: CodeModeLimits;
  * [PR-4 记录](../../../../../docs/verify/VERIFY_RECORD-51-code-mode-pr4.md) §三 第 3 / 4 条，
  * 那不是理论上的洞，是模型自己找到并用上的路。
  *
- * PR-3 **判定不做**引擎隔离（三个选项和判据在
+ * PR-3 那轮**判定不做**引擎隔离（三个选项和判据在
  * [PR-3 记录](../../../../../docs/verify/VERIFY_RECORD-51-code-mode-pr3.md) §二），
  * 改成把边界说准：
  *
  * > **一次 `run_code` = 一次任意本机代码执行，和 `terminal` 同一档。
  * > 边界是审批那一下 —— 用户看到程序全文，批的是「这段程序可以跑」。**
  *
- * 于是这个工具的 `operation: 'command'` 和 `describeTarget` = 程序全文
- * **从实现细节升级成了承重墙**，各有一条会红的用例钉着（`tool-executor.test.ts`
- * 的「run_code 的审批对象是程序全文」、tui 的「多行 / 超宽 target」）。
+ * ## 2026-10-27：那句话里「一点隔离都没有」的一半补上了
+ *
+ * PR-3 当时只有两个选项：preload 拦 `node:fs`（实测无效，`Module._load` 只盖 CJS），
+ * 或者上 OS 隔离（要改成子进程，动整个进程模型）。两个都不成立，所以「不做」
+ * 在那时是对的。
+ *
+ * 第三条路是 worker 自己的 `execArgv` 挂 `--permission`：进程模型一个字不动，
+ * 策略只作用在那一个线程上。实测数据和它**没**拦住什么（网络、env）全部在
+ * [policy.ts](../../code-mode/policy.ts) 的文件头。
+ *
+ * 于是口径变成两句：
+ *
+ * > **审批仍然是边界**；权限策略把「一次任意本机代码执行」收窄成
+ * > 「工作目录内读写、起不了子进程、看不见环境变量」。
+ *
+ * 剩下那个没被收窄的是**网络**，而这里不假装它变了：权限模型不管网络，
+ * 所以一段恶意程序照样能把读到的内容发出去。想在 `bypass` 档 / headless
+ * 预授权下开着它，判断照旧同 `docs/TOOLS.md` 那句 —— 「那一眼是唯一的边界」。
+ *
+ * `operation: 'command'` 和 `describeTarget` = 程序全文仍然是承重墙，
+ * 各有一条会红的用例钉着（`tool-executor.test.ts` 的「run_code 的审批对象是程序全文」、
+ * tui 的「多行 / 超宽 target」）。加权限策略**不改**这一格：策略算错时
+ * 程序起不来，而审批框里看到的仍然是全文。
  * 落进 git 的 `permissions.allow` 里也一条 `run_code` 规则都不许有
  * （`permission/rule-validate.ts` 的 `NEVER_ALLOW_TOOL_NAMES`）。
  *
@@ -4184,6 +4885,9 @@ declare const CODE_MODE_LIMITS: CodeModeLimits;
  * 断网要么靠子进程 + 沙箱（PR-3 记录 §二 选项 C，重开条件在 §五末尾），要么不做。
  * 原来的理由是「它想联网就调 `web_fetch`，那条路有 SSRF 三层防护」——
  * 那句话仍然成立，只是它**描述不了今天的现状**。
+ * ⚠️ **2026-10-27 加权限策略之后再确认一遍：它管不了网络。** 实测带着
+ * `--permission` 跑，`fetch` 照样通 —— 权限模型只管文件系统、子进程、worker、
+ * 原生插件这四类。别把「加了策略」读成「断网了」。
  *
  * ## ⚠️ 三条边界，别在读这个文件时以为方案已经全落了
  *
@@ -4761,8 +5465,6 @@ type ScheduleIssueCode =
  | 'permission-unknown'
 /** 工作目录不存在 */
  | 'work-dir-missing'
-/** `maxBudgetUsd` 必填且必须为正。**这是刻意的摩擦**，见协议上那段 */
- | 'budget-missing'
 /** `maxTurns` 必须是正整数 */
  | 'max-turns-invalid'
 /** 墙钟超时必须是正数 */
@@ -4793,18 +5495,18 @@ type ScheduleIssueCode =
 /** 清单里有一条规则写错了（`detail` 是 `rule-validate` 给的位置与原因） */
  | 'rule-invalid'
 /**
- * 「跳过全部检查」+ 空工作区。
+ * 「完全访问」+ 空工作区。
  *
  * ⚠️ **2026-09-18 起没有产出点了** —— 空着落到的是 `~/.epoch/automation/<id>/`，
  * 一个确定、专属、隔离的目录，不是「不确定的 cwd」。判据全文在
  * `validate.ts` 的 `bypassIssues()` 第 1 条上。保留这条 code 是为了不破坏协议。
  */
  | 'bypass-needs-workdir'
-/** 「跳过全部检查」的工作区指到了家目录本身 —— 那和不绑定没有区别 */
+/** 「完全访问」的工作区指到了家目录本身 —— 那和不绑定没有区别 */
  | 'bypass-workdir-too-broad'
-/** 「跳过全部检查」缺三把尺子中的某一把 */
+/** 「完全访问」缺尺子 —— 今天只剩超时那一把 */
  | 'bypass-needs-limits'
-/** 「跳过全部检查」没有拿到那次二次确认 */
+/** 「完全访问」没有拿到那次二次确认 */
  | 'bypass-not-confirmed';
 /** 全集。CLI 侧靠它穷举文案，少一条编译不过 */
 declare const SCHEDULE_ISSUE_CODES: readonly ScheduleIssueCode[];
@@ -4843,7 +5545,6 @@ interface ScheduleImportInput {
     allowOperations: readonly OperationType[];
     allowRules: readonly string[];
     maxTurns: number;
-    maxBudgetUsd: number;
     timeoutMs: number;
     showInSessionList?: boolean;
     trigger: ScheduleTrigger;
@@ -4874,8 +5575,6 @@ interface CreateScheduleInput {
     allowOperations?: readonly OperationType[];
     allowRules?: readonly string[];
     maxTurns?: number;
-    /** **必填**，没有默认值 */
-    maxBudgetUsd: number;
     timeoutMs?: number;
     /**
      * 跑完的会话直接进会话列表吗。缺省 `false` = 收起来（归档），
@@ -4922,8 +5621,7 @@ interface CreateScheduleInput {
  * `ScheduleControl.update` 解析掉；**`ScheduleStore.update` 的入参不收它**
  * （同 `create(input & { workDir: string })` 那条契约，收窄在编译期）。
  */
-type UpdateScheduleInput = Partial<Omit<CreateScheduleInput, 'maxBudgetUsd' | 'workDir' | 'model' | 'role' | 'startDate' | 'endDate'>> & {
-    maxBudgetUsd?: number;
+type UpdateScheduleInput = Partial<Omit<CreateScheduleInput, 'workDir' | 'model' | 'role' | 'startDate' | 'endDate'>> & {
     /** `null` = 不绑工作区了 → 落回 `~/.epoch/automation/<id>/`，**不是**删掉这一格 */
     workDir?: string | null;
     model?: string | null;
@@ -4933,74 +5631,57 @@ type UpdateScheduleInput = Partial<Omit<CreateScheduleInput, 'maxBudgetUsd' | 'w
     endDate?: string | null;
 };
 /**
- * 三把尺子的缺省值 —— **「调 API / CLI 没给这一格时引擎用什么」**。
+ * 两把尺子的缺省值 —— **「调 API / CLI 没给这一格时引擎用什么」**。
  *
- * ## ⚠️ `maxBudgetUsd` **不在这里**，而 2026-09-18 之后这句话更要紧了
+ * ## ⚠️ 2026-10-29：只剩轮次和超时（预算那一把整个撤了）
  *
- * 它没有引擎兜底：没给就是一条 `budget-required`（网线上 400，CLI 上必给 `--budget`）。
+ * 这里原来还挂着一段「预算不在这份缺省里，因为一个假默认会让『一觉醒来 40
+ * 美元』变成我们的错」。那次撤掉的不只是那一段注释，而是**那一格本身**：
+ * `maxBudgetUsd` 已经从契约、库、网线、CLI、表单上全部退场，判据在
+ * `validate.ts` 的 `bypassIssues()` 上。
  *
- * 那一天新建**表单**上它开始预填 200 了，而那是**另一份缺省**
- * （protocol 的 `WireScheduleDefaults.maxBudgetUsd`，判据全文在那个接口上）：
- * 一份说「表单打开时格子里印什么」，一份说「没给值时引擎用什么」。
- * 把 200 抄进这一份的表现是**网线那一道闸整个消失** —— 任何一个不经表单的调用方
- * 从此都能建出一条没人想过预算的任务，而那正是这一格的缺席拦着的事。
+ * 于是这一份和界面预填那一份（protocol 的 `WireScheduleDefaults`）**不再有
+ * 任何区别** —— 两份都只是「轮次 + 超时」。
  */
 declare const SCHEDULE_DEFAULTS: {
     /**
-     * 和交互缺省**同一个常量**（2026-09-04，原来这儿是自己的一个 `20`）。
+     * 轮次上限。**`0` = 不限**（`UNLIMITED_TURNS`）。
+     *
+     * ## 为什么缺省是「不限」，而不是一个保守的数
      *
-     * 那个 20 的理由写的是「无人看着的一轮不该比有人看着的更长」。它不成立了 ——
-     * 它当初拦的是「跑飞了没人按 Esc」，而这一层真正拦住那件事的是 `maxBudgetUsd`：
-     * 它在这套功能里**必填**（所以它不在这份缺省里），而钱是比轮次准的尺子。
-     * 用轮次替它把无人值守的活压到 20，拦掉的绝大多数不是跑飞，是「这个任务本来
-     * 就要 60 轮」—— 而那种失败要等到第二天 9 点才看得见（同下面
+     * 这一格原来是自己的一个 `20`，理由写的是「无人看着的一轮不该比有人看着的
+     * 更长」。它不成立了 —— 它当初拦的是「跑飞了没人按 Esc」，而用轮次替它把
+     * 无人值守的活压到 20，拦掉的绝大多数不是跑飞，是「这个任务本来就要 60 轮」
+     * —— 而那种失败要等到第二天 9 点才看得见（同下面
      * `SCHEDULE_DEFAULT_ALLOWLIST` 那节的判据）。
      *
      * ⚠️ 这一份是**没有配置在手时的兜底**。真正拿着用户那格 `maxTurns` 的地方是
      * `server/src/schedule/handlers.ts` 的 `defaultsOf()` —— 表单预填走它，
      * 所以用户把设置里那个数改成 500，新建任务那一格就预填 500。
      *
-     * ⚠️ **2026-09-06 起这个缺省是「不设上限」**（`UNLIMITED_TURNS`），因为上面那条
-     * 判据跟着交互缺省一起走到了头：既然轮次拦掉的绝大多数不是跑飞，那把它当无人
-     * 值守的兜底闸门就是**拿错了尺子**。这条路上兜住跑飞的仍然是 `maxBudgetUsd`
-     * （必填，所以它不在这份缺省里）和 `timeoutMs`。要一道轮次闸门的人在新建任务
+     * ⚠️ **2026-09-06 起这个缺省是「不设上限」**（`UNLIMITED_TURNS`），判据同上。
+     * 🔴 **2026-10-29 起这条路真正兜得住「跑飞」的只剩下面那一个 `timeoutMs`**
+     * —— 预算那把尺子没了，而这一格缺省是 0。要一道轮次闸门的人在新建任务
      * 那一格自己填一个数。
      */
     readonly maxTurns: 0;
     /**
-     * 墙钟超时。唯一能拦住「一条命令挂住了」的那把尺子 —— 前两把在那种情形下
-     * 都不增长（轮次不动、花费不动）。
+     * 墙钟超时。**无人值守路上唯一兜得住「跑飞」的那把尺子**（2026-10-29 起）。
+     *
+     * 它要拦两种前一把拦不住的东西：一条 `terminal` 命令挂住了（那种情况下轮次
+     * 不增长），以及一个每轮都很便宜、但一轮接一轮跑下去的循环。
      *
      * ⚠️ **2026-09-18 从 15 分钟抬到 60 分钟**（用户定的）。15 分钟那条线当初是
      * 照着「一次巡检」估的，而它砍掉的不是跑飞，是**本来就要跑久的那种任务**：
      * 一条被这把尺子掐断的运行和跑飞长得一模一样（都是 `timeout`），
      * 而定时任务的反馈回路按天算 —— 第二天早上看到的只有「超时了」三个字。
      *
-     * 兜住真正跑飞的是必填的 `maxBudgetUsd`（钱是比时间准的尺子），
-     * 判据同上面 `maxTurns` 那一段。
-     *
      * ⚠️ 这个数**两条路共用**（CLI 不给 `--timeout`、表单预填，都读它）——
      * 在服务端那侧另写一份的表现，`runtime/schedule/control.ts` 那段注释记着：
      * 「表单预填 200、直接调这个 API 却得到 20」。
      */
     readonly timeoutMs: number;
 };
-/**
- * 新建**表单**里预算那一格印什么（2026-09-18，用户定的 200 美元）。
- *
- * ## ⚠️ 它**刻意不在** {@link SCHEDULE_DEFAULTS} 里，这一条是承重的
- *
- * 那一份答的是「调 API / CLI 没给这一格时引擎用什么」，而这一格**没有**那种兜底：
- * 网线上没给预算就是 400（`budget-required`），CLI 上 `--budget` 照旧必给。
- *
- * 这一份答的是另一个问题：「表单打开时那个格子里印着什么」。两者混成一份的表现是
- * 网线那道闸整个消失 —— 任何一个不经表单的调用方从此都能建出一条没人想过预算的
- * 任务，而定时任务是没人看着的（一觉醒来那笔账已经花完了）。
- *
- * 判据全文、以及这个数撤掉了方案 45 §3.5 的哪一半，写在 protocol 的
- * `WireScheduleDefaults` 上。
- */
-declare const SCHEDULE_FORM_BUDGET_USD = 200;
 /**
  * 新建任务时预填的最小清单（方案 45 §3.2 的落点）。
  *
@@ -5326,8 +6007,10 @@ declare class ScheduleRegistrar {
  *
  * 1. `validateSchedule()` 照旧跑，红了就**一个字都不写**（半条任务比没有更糟）；
  * 2. 「无人值守下跑不出结果」的那两族措辞照旧**拒收**（`unattendedIssues`）；
- * 3. `bypass` 档照旧要 `SCHEDULE_FORM_BUDGET_USD` 的预算和正的超时
- *    （`bypassIssues` 的 `bypass-needs-limits`），而工作目录不许宽到等于没绑。
+ * 3. `bypass` 档照旧要**正的超时**（`bypassIssues` 的 `bypass-needs-limits`），
+ *    而工作目录不许宽到等于没绑。
+ *    ⚠️ **2026-10-29 起这条尺子只剩超时**：那一刻那条第 2 条里的「三把尺子」
+ *    改成了「超时 + 轮次（而轮次缺省不限）」—— 判据在 `validate.ts` 上。
  *
  * ## ⚠️ 有一档仍然降级成提案：`plan`（只读调研模式）
  *
@@ -5410,6 +6093,219 @@ interface ScheduleDraftDeps {
 }
 declare function createScheduleDraftTool(deps: ScheduleDraftDeps): EpochTool;
 
+/**
+ * `send_message` —— agent 之间发一条消息（阶段 1：父子单通道）。
+ *
+ * ## 它和 `delegate_task` 不是一回事
+ *
+ * - `delegate_task` 是**派活**：开一个新成员、给它一段 goal、等它交结论
+ * - 这个工具是**对已经在跑的人说一句**：不新开成员、不等结论、不改变谁在干活
+ *
+ * 所以它不能替代 `delegate_task`，也不该被用来「再派一个」。模型手上两个都有时
+ * 最容易犯的错是拿它当派活用 —— 描述里那段「什么时候用它」就是为这个写的。
+ *
+ * ## 投递语义（两个方向不对称，这是刻意的）
+ *
+ * - **发给一个 running 成员**：进它的收件箱，引擎在**下一个步骤边界**取走
+ *   （`loop.ts:723` 的 `steer.take()`）。它当轮就会看到，不用等这一轮跑完
+ * - **发给 `lead`**：进主会话的收件箱，下一轮 `TaskNoticeTracker` 在请求前
+ *   拼成一条 note（`loop.ts:1367`）。**父会话没在跑时它待在那儿不动**
+ * - **发给已经收工的成员**：直接失败。收进一个永远不会有下一轮读它的箱子
+ *   等于给调用方一个假成功 —— 父 agent 会照着它继续等回音
+ *
+ * 第三条是 codex `api.rs:35-36` 那条规矩的本地版：通知**不唤醒**已终结的 agent。
+ * 阶段 2 有了 `followup_task`，唤醒才会变成一条显式的路。
+ */
+
+/** 工具名。`BLOCKED_TOOLS` 那边按这个名字放行，别各写各的 */
+declare const SEND_MESSAGE_TOOL = "send_message";
+declare function createSendMessageTool(team: TeamRegistry): EpochTool;
+
+/**
+ * 讨论板（阶段 3）—— **跨进程**共享的一块板。
+ *
+ * ## 为什么它和 roster / 任务板不是一类东西
+ *
+ * `registry.ts` 和 `tasks.ts` 都是内存里的：那两样的读者是**同一个进程里的
+ * 那几个成员**，别的进程既不该看见也不该写。而板子存在的**全部理由**就是
+ * 「我开着两个 epoch 窗口，它们看到的是同一块板」。
+ *
+ * 所以它走 SQLite，并且挂在 `~/.epoch/sessions.db` 这个**本来就多进程共享**的
+ * 文件上（判据：`session/db.ts:1193`、`fts-health.ts:297` 都写着「两个进程打开
+ * 同一个 sessions.db」），用 `migrate()` 的 namespace 隔离，不另开一个文件。
+ * 另开文件的话 `openDatabase` 的 refCount 要自己再管一份，而那边已经有一套了。
+ *
+ * ## 通知是**拉取式**的，不唤醒任何人
+ *
+ * 照 codex `api.rs:35-36` 那条规矩：通知不唤醒已终结的 agent。这里更彻底 ——
+ * 板子自己**不投递任何东西**，它只记「每个订阅者看到哪一条了」（`last_seen_seq`）。
+ * 谁想知道有没有新帖，谁自己来 `pendingFor()` 拉。
+ *
+ * 这样做的代价是「发帖的人不知道对方看没看」，而收益是不用维护投递队列、
+ * 也不会有「消息发往一个早就退出的进程」那种没法处理的中间态。
+ *
+ * ## `append` 和 `post` 的差别
+ *
+ * - `post`：发帖，**会自动订阅作者并通知订阅者**
+ * - `append`：静默写入，不订阅、不通知（贴证据、记流水用它）
+ *
+ * 这是 codex 的同一条分法（`PostBehavior::Discussion` / `SilentAppend`）。
+ */
+
+/** 单条帖子的字符上限。超了截断并明说 —— 不静默丢 */
+declare const MAX_POST_CHARS = 20000;
+/** 订阅目标：`channel:<名字>` 或 `thread:<id>` */
+type BoardTarget = {
+    kind: 'channel';
+    name: string;
+} | {
+    kind: 'thread';
+    id: string;
+};
+/** 一条「你有新帖」的摘要。**不带正文** —— 要看得自己去 read_thread */
+interface BoardPending {
+    target: string;
+    count: number;
+}
+declare class BoardStore {
+    private readonly path;
+    private readonly db;
+    constructor(homeDir: string);
+    /** 归还连接（引用计数 -1）。宿主 dispose 时调 */
+    close(): void;
+    createChannel(args: {
+        name: string;
+        description?: string;
+        by: string;
+    }): BoardChannel;
+    /** 只改描述，**不碰帖子和订阅**。不存在的频道会被建出来（判据同 codex 的 upsert） */
+    upsertChannel(args: {
+        name: string;
+        description: string;
+        by: string;
+    }): BoardChannel;
+    channel(name: string): BoardChannel | undefined;
+    listChannels(): BoardChannel[];
+    listThreads(channel: string, limit?: number): BoardThread[];
+    /**
+     * 发帖。
+     *
+     * - 目标是**频道**：开一个新线程，这条是 root post，标题取正文第一行
+     * - 目标是**线程**：回复进去
+     *
+     * 无论哪种，作者都会被**自动订阅**（判据同 codex：`Posting subscribes its author`），
+     * 且不会收到自己这条的通知（`last_seen_seq` 直接推到它自己这条）。
+     */
+    post(args: {
+        target: BoardTarget;
+        author: string;
+        text: string;
+    }): {
+        post: BoardPost;
+        threadId: string;
+    };
+    /** 静默追加：不订阅、不通知 */
+    append(args: {
+        target: BoardTarget;
+        author: string;
+        text: string;
+    }): {
+        post: BoardPost;
+        threadId: string;
+    };
+    private write;
+    readThread(threadId: string, limit?: number): BoardPost[];
+    readPost(id: string): BoardPost | undefined;
+    searchPosts(query: string, channel?: string, limit?: number): BoardPost[];
+    /**
+     * 订阅。`seenSeq` 给了就把游标推到那儿（作者发帖时用）。
+     *
+     * 重复订阅是**幂等**的：只更新游标（如果新游标更小就不动 —— 别让一次
+     * 重订阅把读者没看的帖子吞掉）。
+     */
+    subscribe(agent: string, target: BoardTarget, seenSeq?: number): void;
+    /** 全板最大的 seq（空板是 0） */
+    private maxSeq;
+    unsubscribe(agent: string, target: BoardTarget): boolean;
+    /**
+     * 这个 agent 订阅的格子里，**自它上次看之后**新增了多少条。
+     *
+     * 只给条数，不给正文 —— 要读自己去 `read_thread`。判据同 `waitForChange`：
+     * 一个会过期的摘要比没有更坏。
+     */
+    pendingFor(agent: string): BoardPending[];
+    /** 把游标推到「现在」（读过之后调）。不带 target = 全部 */
+    markRead(agent: string, target?: BoardTarget): void;
+    private countSince;
+}
+
+/**
+ * 讨论板的 11 个工具（阶段 3）。
+ *
+ * ## 寻址：`target` 一个参数两种形态
+ *
+ * - `th-xxxxxxxx` → 一个线程（回复进去）
+ * - 其他 → 频道名（**开一个新线程**，这条是 root post）
+ *
+ * 不做 `channel:name` 那种前缀：列表里 `th-` 开头的 id 和频道名永远不会撞，
+ * 而少一层语法就是少一处模型会写错的地方。
+ *
+ * ## `post` 和 `append` 的区别要写进描述
+ *
+ * 前者会**订阅作者并通知订阅者**，后者静默。模型拿 `append` 去「在讨论里说一句」
+ * 的话，别人永远不知道有新内容 —— 那是最容易发生的一种误用，所以两边的描述
+ * 都把这一点写在第一句。
+ *
+ * ## 板子是**跨进程**的，所以这里没有任何「当前进程内」的假设
+ *
+ * 别人的窗口发的帖，你这边 `read_thread` 读得到；反过来也一样。这也是这几个
+ * 工具和 `send_message` / `team_task_*` 的根本差别 —— 那两组只在进程内。
+ */
+
+/**
+ * @param store 板子。`undefined` = 这个进程没开起来（比如 homeDir 不可写），
+ *   那时**一个工具都不注册** —— 装了但每次调用都报错，模型会以为那是它用错了
+ */
+declare function createBoardTools(store: BoardStore, deps: {
+    agentOf: (sessionId: string) => string | undefined;
+}): EpochTool[];
+/** 工具名清单（门禁和 `docs/TOOLS.md` 按它们对名字） */
+declare const BOARD_TOOL_NAMES: readonly string[];
+
+/**
+ * 阶段 2 的团队工具：派具名成员、看名册、等变化、打断，以及共享任务板。
+ *
+ * ## 八个工具为什么在一个文件里
+ *
+ * 它们共享**同一份状态**（`TeamRegistry`，任务板挂在它下面），而且语义上是一套：
+ * 名册 + 消息 + 任务。拆成三个文件的话，`wait_agent` 那种「等任意一种变化」
+ * 的工具会横跨两边，反而要 import 两处。
+ *
+ * ## 曝光：只 `list_agents` 是 Direct
+ *
+ * 计划里定的：20 个新工具默认 `Deferred`（走 `tool_search` 按需发现），
+ * 只留最常用的直接出现。`list_agents` 是每次想跟谁说话之前都要看一眼的那个，
+ * 放 Deferred 会让模型先 `tool_search` 一次再 `list_agents` —— 两步换一步。
+ *
+ * ## `spawn_teammate` 和 `delegate_task` 的区别（描述里必须说清）
+ *
+ * - `delegate_task`：一次性，派完等结论，跑完即止
+ * - `spawn_teammate`：具名、后台、**跑着的时候能收到消息**
+ *
+ * 合并它们会让模型两头都判断错：拿 `delegate_task` 去派一个「需要中途纠正」的活，
+ * 那个成员根本收不到消息（它一开始就没名字）。
+ */
+
+/**
+ * 全部阶段 2 工具。
+ *
+ * 顺序不影响行为（注册表按名字去重），但 `list_agents` 排前面：
+ * 它是 `ToolExposure.Direct` 的那一个，而其余是 Deferred。
+ */
+declare function createTeamTools(team: TeamRegistry, manager: DelegateManager): EpochTool[];
+/** 工具名清单。`BLOCKED_TOOLS` 和门禁按它们对名字，别各写各的 */
+declare const TEAM_TOOL_NAMES: readonly string[];
+
 /**
  * 「哪些历史会话，这一段会话能读」—— **全仓唯一一份判定**（方案 48 §四）。
  *
@@ -5563,12 +6459,24 @@ declare function resolveSessionVisibility(input: SessionVisibilityInput): Sessio
  * ## 为什么这值得一个工具
  *
  * `delegate_task` 派出去的子 agent 有**独立的 sessionId**，`fork()` 出来的会话
- * 也有 `parent_id`。于是「刚才那个子 agent 到底干了什么」今天无从查起：
- * 它的结论回来了（一段 summary），但它中间读了哪些文件、试过哪些路、
- * 在哪一步拐弯，全都在另一段会话里 —— 而模型手上连那段会话的 id 都没有。
+ * 也有 `parent_id`。于是「刚才那个子 agent 到底干了什么」可查：它的结论回来了
+ * （一段 summary），而它中间读了哪些文件、试过哪些路、在哪一步拐弯，
+ * 全在另一段会话里。
  *
  * 这一份给的就是那些 id：拿到之后接 `session_messages_search` 就能进去看。
  *
+ * ## ⚠️ 2026-10-27 之前这段说明是假话
+ *
+ * 那时子 agent 的过程**从来没落过盘**：`delegate-xxxxxxxx` 只是个临时字符串，
+ * `sessions` 表里根本没有它那一行。于是上面那句话（以及 `docs/TOOLS.md` 里
+ * 同一句）描述的是一个不存在的能力 —— 模型照着描述去查，查回来是空的，
+ * 而它没有办法分辨「真没有」和「没存下来」。
+ *
+ * 修法不是改文案：`subRunner` 跑完之后把这一轮按步折下来落进库，并写上
+ * `parent_id`（判据在 `runtime/src/session-factory.ts` 的 `persistDelegateTurn` 上）。
+ * 那段会话的 `source` 是 `delegate`，所以它不会出现在「接着哪一段聊」的列表里
+ * —— 列表那一边有 `includeDelegate` 这个开关，判据在 `DELEGATE_SESSION_SOURCE` 上。
+ *
  * ## 为什么不长在 [authorization.ts](./authorization.js) 里
  *
  * 那边的 `lineageOf()` 也走 `parent_id`，但它要的是**一串 id**（拼进 WHERE），
@@ -6840,6 +7748,22 @@ declare class TrackerDB {
     countOpen(sessionId: string): number;
     /** 全量替换会话的 TODO 列表（事务：DELETE + INSERT 批量） */
     replaceAll(sessionId: string, todos: TodoItem[]): void;
+    /**
+     * 删掉一段会话的全部 TODO（2026-10-27）。返回删了几条。
+     *
+     * ## 什么时候需要它
+     *
+     * `delegate_task` 派出去的子任务用**自己那个** `sessionId` 写 TODO
+     * （判据在 `AgentConfig.pendingTodos` 上：闸门要读的是「它自己那几件活」）。
+     * 而那个 id 对应的 sessions 行是**跑完之后才补建的** —— 建行失败或压根没落盘时，
+     * 这几行 TODO 就成了谁也删不掉的孤儿：`epoch sessions` 列不到它，
+     * 会话保留期清理也扫不到它（那一支按 `sessions` 表扫）。
+     *
+     * 所以那一条失败路径上要主动收一下。正常路径**不在这儿删**：子会话已经有
+     * 自己的 sessions 行了，`SessionDB.deleteSession` 会连带清掉
+     * （判据在 db.ts 的 `DELETE FROM todos WHERE session_id = ?` 那一行）。
+     */
+    deleteBySession(sessionId: string): number;
     /** 释放连接（引用计数归零才真正关闭） */
     close(): void;
 }
@@ -10430,6 +11354,15 @@ interface BreakdownInput {
         tool: EpochTool;
         source: string;
     }>;
+    /**
+     * 上一次请求的用量（2026-10-26）。**只用来算缓存那一格**，不给就整个缺席 ——
+     * 「没跑过任何一轮」和「跑了一轮但一次没命中」是两件事，前者不该显示成 0%。
+     *
+     * 口径是**最近一次**而不是累计：累计值会随着高命中的历史越来越好看，
+     * 从而掩盖「刚改的这一处根本没生效」—— 而这正是 {@link ContextBreakdown.cache}
+     * 存在的理由。
+     */
+    lastUsage?: TokenUsage;
 }
 declare function buildContextBreakdown(input: BreakdownInput): ContextBreakdown;
 
@@ -11155,6 +12088,34 @@ declare class AgentLoop {
     private learnedSkills;
     constructor(config: AgentConfig);
     abort(): void;
+    /**
+     * 撞上「请求体太大」之后的第一段救援：**摘掉最老的几张图**，返回摘过的那份。
+     *
+     * ## 为什么它排在压缩之前（这是全套改动的判据所在）
+     *
+     * 1. **代价差一个量级**：摘图是纯本地操作（把 base64 换成一行占位），压缩是
+     *    一发真实的摘要请求（花钱、要等几秒）。而这一档的现场绝大多数是图撑的
+     *    （`request-bytes.ts` 文件头那张量纲表），先试便宜的那个。
+     * 2. **压缩的代价高得多，而且它动的是整段历史**：`compress()` 收到的是文本投影
+     *    （`message-codec.ts` 的 `flattenMessage` 明确把 `parts` 丢掉），所以图片
+     *    它确实能拿掉。但拿掉图只是它的副作用 —— 它真正干的是把中段**整段换成一段
+     *    摘要**，而那是不可逆的。仅仅为了几张老图就这么干，不值当。
+     *
+     * ## ⚠️ 目标**不能用 {@link imageBudget}**（实测踩到过）
+     *
+     * 走到这儿说明那一次**真的超了**，而 `imageBudget()` 正是撞墙前用的那个数。
+     * 拿它当「摘到多少为止」，在「配置值给得太宽松」和「没有 `homeDir`、学不到
+     * 值」这两档上都会得出「一张都不用摘」（图总量本来就小于那个宽松预算），
+     * 于是救援原地空转、重发同一份东西。
+     *
+     * 撞墙这个事实本身就说明「必须比刚才小」，所以目标是**实发量打八折**
+     * （同 `LEARN_SHRINK` 的口径：留两成余量）。学到的那个值只是让**下一次**
+     * 不必先撞一次。
+     *
+     * @returns 摘动了就回新的 messages + 摘了几张；**一张都摘不掉时回 `null`**
+     *   —— 调用方据此知道「这一招不管用」，别拿一模一样的东西再撞一次墙
+     */
+    private tryOffloadForBodyLimit;
     /**
      * 多模态策略的**现读出口**：尺寸上限来自 config，`supportsImages` 来自
      * provider 自己（见 {@link AgentProvider.capabilities}）。
@@ -11173,6 +12134,47 @@ declare class AgentLoop {
      * 磁盘缓存）。相对一次模型调用，这个量级不值得为它留一个会说谎的快照。
      */
     private multimodal;
+    /**
+     * 这一发该按多大的图片预算走 —— **配置/缺省值和学习值取小的那个**。
+     *
+     * ## 为什么每轮现算，不构造时算一次
+     *
+     * 判据逐字同 {@link multimodal}：**学习值会在一次 run 中途变化** ——
+     * 撞上 1051 的那一刻 {@link learnBodyLimit} 刚把它写下去，而同一轮接下来的
+     * 重发就该按新值（更紧的那个）走。构造时算一次的话，那一次重发用的还是撞墙
+     * 前那个宽松的预算，于是再摘不掉、再撞一次。
+     *
+     * ## 没有 `homeDir` 时
+     *
+     * 不读历史学习值（盘上那份在哪都不知道），只用配置值/缺省值 —— 于是「学」
+     * 这件事在这种宿主上不发生。这是一个**明确的降级**，不是 bug：没给数据目录的
+     * 嵌入宿主不该被我们写文件。
+     */
+    private imageBudget;
+    /**
+     * 记一笔「这个端点收不下这么大的图片」。best-effort：写不进去只是下次再撞一遍。
+     *
+     * ⚠️ 传进来的是**这一次真的发出去的字节数**（不是预算值）。两者的区别就是这条线
+     * 的全部意义：预算可能比它小（那我们不该撞），撞上了说明预算偏大，而偏大多少
+     * 只看这一次的实发量。
+     */
+    private learnBodyLimit;
+    /**
+     * 学习缓存的三元组 `[homeDir, provider, model]` —— 没有 `homeDir` 时回
+     * `undefined`，于是「学」和「读」两条路一起关掉。
+     *
+     * ⚠️ **`provider` 那一格只能退而求其次。** `body-limit-cache.ts` 的文件头要求
+     * 缓存键带 provider（同一个裸名在两家下面可以是两个模型、端点更是各家自己的），
+     * 但 `AgentLoop` 手上**没有** provider 类型：`AgentProvider` 只给 `modelId`
+     * （一个裸名，`agent/types.ts`），provider 身份在 router 里，core 这一层够不着。
+     *
+     * 所以这里 provider 给空串，也就是**本机所有 provider 共享同一条学习值**。
+     * 这是已知的精度损失，方向是**安全的那一侧**：两个端点里更保守的那个值被两边
+     * 共用，代价是最慢那家让我们摘得比别家早一点（可逆、不花钱），而不是在宽松
+     * 那家上撞墙。要修成真带 provider，得让装配层把它递进 `AgentConfig` ——
+     * 那是一次跨包改契约，不在这一笔的范围里。
+     */
+    private imageLimitKey;
     /**
      * 「这一轮会用哪个模型、它认不认图」——**给 system prompt 用的那一份**
      * （2026-09-02）。判据全文在 `AgentProvider.modelId` 上。
@@ -11253,6 +12255,12 @@ declare class AgentLoop {
     contextBreakdown(opts: {
         historyText: string;
         toolSource?: (name: string) => string | undefined;
+        /**
+         * 上一次请求的用量（2026-10-26）。只用来算缓存那一格 —— `/context` 要回答
+         * 「我说了缓存到底有没有生效」，而这句话只能由 provider 报的真数回答。
+         * 不给就是「这个宿主量不到」，那一格整个缺席（不是 0%）。
+         */
+        lastUsage?: TokenUsage;
     }): ContextBreakdown;
     /** 执行一次对话，收敛成最终结果 */
     run(input: RunInput): Promise<RunResult>;
@@ -12167,7 +13175,7 @@ declare function describeJsonError(err: unknown, text: string): string;
  * | -------------------------------- | ------------------------------------------ |
  * | `allowManagedPermissionRulesOnly` | 其余各层的 allow / ask / deny 全部忽略     |
  * | `allowManagedHooksOnly`          | 用户级 hook 一律不加载                     |
- * | `disableBypassPermissionsMode`   | `permission: bypass` 拒绝启动              |
+ * | `disableBypassPermissionsMode`   | 审批轴 = `never` 的那一档拒绝启动（今天就是 `auto`） |
  *
  * ## 这一层**不过信任闸门**，而且不该过
  *
@@ -12246,12 +13254,17 @@ declare class ManagedPolicyError extends Error {
  *
  * ## 为什么是**拒绝启动**而不是静默降级到 default
  *
- * 降级是「更安全」的那一侧，但它会让用户以为自己在 bypass 里 —— 然后每一次
+ * 降级是「更安全」的那一侧，但它会让用户以为自己在那一档里 —— 然后每一次
  * 审批弹窗都成了怪现象，而真正的原因（IT 禁掉了这个级别）一个字都看不见。
- * 权限级别是用户**显式**要的东西（`--permission bypass` 或 config.yaml 里那一行），
+ * 权限级别是用户**显式**要的东西（`--permission auto` 或 config.yaml 里那一行），
  * 显式请求被策略挡下必须当面说，这跟「配了个不认识的级别回退到 default」
  * 那种笔误不是一回事。
  *
+ * ⚠️ **2026-10-27 起它挡的是「审批轴 = `never`」这个组合，不再是一个档位名。**
+ * 合并 `auto` + `bypass` 之后，「不问」这件事不再由某个档位名独有 ——
+ * 用一个 `level === 'auto'` 判断也能对得上今天的代码，但那是第二份知识，
+ * 下一次加一档 `never` 的档位时它会静默漏掉。
+ *
  * 挡的是级别本身，不区分它从哪一层来 —— `--permission`、`EPOCH_PERMISSION`、
  * `~/.epoch/config.yaml` 最后都汇进同一个 `config.permission`，
  * 在这里分叉等于把「哪个来源算数」这个问题又答一遍。
@@ -13600,13 +14613,7 @@ declare const EpochConfigSchema: z.ZodObject<{
     maxOutputTokens: z.ZodOptional<z.ZodInt>;
     homeDir: z.ZodDefault<z.ZodString>;
     dbPath: z.ZodDefault<z.ZodString>;
-    permission: z.ZodDefault<z.ZodEnum<{
-        default: "default";
-        acceptEdits: "acceptEdits";
-        plan: "plan";
-        auto: "auto";
-        bypass: "bypass";
-    }>>;
+    permission: z.ZodPipe<z.ZodDefault<z.ZodString>, z.ZodTransform<"default" | "acceptEdits" | "plan" | "auto", string>>;
     permissions: z.ZodOptional<z.ZodObject<{
         allow: z.ZodOptional<z.ZodArray<z.ZodString>>;
         ask: z.ZodOptional<z.ZodArray<z.ZodString>>;
@@ -13634,6 +14641,9 @@ declare const EpochConfigSchema: z.ZodObject<{
     sandbox: z.ZodPrefault<z.ZodObject<{
         terminal: z.ZodDefault<z.ZodBoolean>;
     }, z.core.$strip>>;
+    delegate: z.ZodPrefault<z.ZodObject<{
+        taskTimeoutSec: z.ZodDefault<z.ZodInt>;
+    }, z.core.$strip>>;
     tools: z.ZodPrefault<z.ZodObject<{
         deferMcp: z.ZodDefault<z.ZodBoolean>;
         mode: z.ZodDefault<z.ZodEnum<{
@@ -13649,6 +14659,9 @@ declare const EpochConfigSchema: z.ZodObject<{
         enabled: z.ZodDefault<z.ZodBoolean>;
         threshold: z.ZodDefault<z.ZodNumber>;
     }, z.core.$strip>>;
+    limits: z.ZodPrefault<z.ZodObject<{
+        maxRequestImageBytes: z.ZodOptional<z.ZodInt>;
+    }, z.core.$strip>>;
     memory: z.ZodPrefault<z.ZodObject<{
         memoryCharLimit: z.ZodDefault<z.ZodInt>;
         userCharLimit: z.ZodDefault<z.ZodInt>;
@@ -13796,6 +14809,10 @@ declare const EpochConfigSchema: z.ZodObject<{
         }> & z.core.$partial, z.ZodString>>;
         hidden: z.ZodOptional<z.ZodBoolean>;
     }, z.core.$strip>>;
+    scheduleRemoveConfirm: z.ZodOptional<z.ZodRecord<z.ZodEnum<{
+        zh: "zh";
+        en: "en";
+    }> & z.core.$partial, z.ZodString>>;
     user: z.ZodOptional<z.ZodObject<{
         label: z.ZodString;
         icon: z.ZodOptional<z.ZodString>;
@@ -14378,6 +15395,177 @@ interface SchemaExport {
  */
 declare function buildSchemaExports(): SchemaExport[];
 
+/**
+ * 配置键的**全量**表 —— 从 `EpochConfigSchema` 派生，一个字都不手抄。
+ *
+ * ## 它存在的原因
+ *
+ * `epoch config set` 原来认 24 个键，而那 24 个是**手抄**在三张 `Record` 里的
+ * （`SCALAR_FIELDS` / `SECTION_FIELDS` / `BUDGET_FIELDS`）。schema 有 45 个顶层键 /
+ * 83 个叶子，于是「知道的」和「能改的」差着五十多个 —— 而那个差距在任何一屏上都
+ * 看不见：用户（或模型）照着 schema / 文档敲一个键，收到的是「未知配置项」，
+ * 它读起来和「这个功能没做」一模一样。
+ *
+ * `cli/commands/config.ts` 的注释里记着这个坑的三次前科（`permission` / `shell` /
+ * 设置页那一串），每一次都是手抄名单落下的。这一份把它从根上断掉：**清单只有
+ * schema 一个真源**，`set` / `unset` / 报错提示 / `config list` 全部查这张表。
+ *
+ * ## 值域也是派生的
+ *
+ * {@link checkConfigValue} 按 JSON Schema 的 `type` / `enum` / `minimum` /
+ * `exclusiveMinimum` / `maximum` / `minLength` 校验 —— 那几格正是 zod 的
+ * `.int().positive().max(10000)` / `.enum([...])` / `.min(1)` 编译出来的东西
+ * （实测：`automation.keepRuns` 拿到 `exclusiveMinimum: 0, maximum: 10000`，
+ * `budget.onUnknownPricing` 拿到 `enum: ['block','warn']`）。
+ *
+ * 于是 `epoch config set` 的值域**永远等于 schema**，而不再是「另一份人肉对齐的
+ * 近似」。这一层原来最容易出错的形态是「放行 `1.5`，而引擎那侧是 `z.int()`，
+ * 于是整份配置退回默认值」—— `sessions.retentionDays` 与 `automation.*` 两处
+ * 的注释各记了一次。
+ *
+ * ## 三档可写性，判据写在每一档旁边
+ *
+ * | 档 | 判据 | 今天几个 |
+ * | --- | --- | --- |
+ * | `scalar` | 顶层标量，或**一层** `段.字段`，且不是 {@link BLOCKED} 里那三个 | 37 |
+ * | `manual` | 两层以上的路径，或数组 / 对象 | 40 |
+ * | `blocked` | 「位置 / 身份」类的三个键 | 3 |
+ *
+ * ### 为什么两层以上的路径不开放
+ *
+ * `setSectionField` 的就地改写只做一层（`infra/src/config-yaml.ts` 文件头那句
+ * 「代价是只能改标量和一层嵌套——够用」）。把它扩成正则任意深度，要处理每一层
+ * 的缩进、兄弟字段和注释归属，而那个手术碰坏用户注释的形态是静默的。
+ *
+ * 更硬的一条在 `display.currency` 上：它的 `code` / `rate` 在 schema 里是
+ * **required 成对**的（JSON Schema 那句 `required: ['code','rate']`）。只写一个，
+ * 整份配置过不了 `EpochConfigSchema`，而 loader 的语义是「不逐字段抢救」——
+ * 结果是**整份配置连同模型和 key 一起退回默认值**。为一个货币单位付这个代价
+ * 不值得，所以这一族留给人手改文件（手改时他看得见旁边那一行）。
+ *
+ * ### 为什么 {@link BLOCKED} 那三个键连手改都算「不是设置」
+ *
+ * 它们不是「某个开关的值」，是「数据放在哪 / 我是哪个档」。而这三个键今天的
+ * 真源**不在 config.yaml 里**：
+ *
+ * - `profile`：唯一真源是环境变量 `EPOCH_PROFILE`（`infra/src/paths.ts` 的
+ *   `resolveHomeDir()` / `resolveProfile()` 都只读环境变量）。写进 yaml 一个字都
+ *   不会切目录，只会让「关于」那一屏（`WireAbout.profile`）报一个假的当前档。
+ * - `homeDir`：有两套解析真源 —— `paths.ts` 那一家只看 `EPOCH_HOME` /
+ *   `EPOCH_PROFILE`，而 runtime 到处读 `config.homeDir`。写它不会让配置文件搬家
+ *   （`configPath()` 照样在旧家），只会让**数据**跑去新家，于是同一个进程里
+ *   配置文件、会话库、凭据分散在两个目录。
+ * - `dbPath`：同族，而且切得更碎 —— `runtime/src/services.ts` 读
+ *   `config.dbPath`，而 `runtime/src/schedule/control.ts` 用的是
+ *   `dbPath(homeDir)`。写它只切走一半的库。
+ *
+ * 换句话说：把这三个键放行不会「让配置更灵活」，只会造出一台**看起来改了、
+ * 其实只改了一半**的机器。要搬家的正路是环境变量（`EPOCH_HOME` /
+ * `EPOCH_PROFILE`），那是它们本来的入口。
+ *
+ * ### 另外三个键的单独判据（写在这一层，是因为它们各自的原因不一样）
+ *
+ * - **`modelEntries`**：schema 上自己写着「写在 config.yaml 里不生效」——
+ *   真源是 `models.json`，loader 读到这一格会报一条 `legacy_ignored`。
+ * - **`hooks`**：旧格式，已搬去 `hooks.json`。这一格只保证「是个对象」，
+ *   内部结构由 hook 自己的 schema 校验（这里给它写一个字段表就等于维护第二份）。
+ * - **`display.currency.code` / `.rate`**：两格在 schema 里是 **required 成对**的
+ *   （`required: ['code','rate']`）。只写一个，整份配置过不了校验、按 loader
+ *   一贯的「不逐字段抢救」退回默认值 —— 模型和 key 一起没。
+ */
+
+/** 一个叶子能是的那几种标量。数组 / 对象不在这里 */
+type ConfigKeyKind = 'string' | 'integer' | 'number' | 'boolean';
+/**
+ * 这个键能不能通过 `epoch config set` 写。
+ *
+ * 三档的含义和判据见文件头那张表 —— **别照着名字猜**，
+ * `blocked` 不是「危险」，是「它不是设置」。
+ */
+type ConfigKeyWrite = 'scalar' | 'manual' | 'blocked';
+/**
+ * 不能 `config set` 的**原因码**。
+ *
+ * ⚠️ 这一格是给 CLI 翻译用的，**不是给人读的** —— 人读的是 catalog 里那几句
+ * （`cli.config.manual_nested` / `manual_structured` / `not_a_setting`）。
+ *
+ * 为什么不在表里存一句「为什么不能写」的中文描述：`config set` / `config list`
+ * 会把它拼进输出，而英文界面上就长出一句英文夹中文的话。存原因码、
+ * 让文案走 catalog，两边各自才是对的。
+ */
+type ConfigKeyReason = 'position' | 'structured' | 'nested';
+/** 键表里的一行 */
+interface ConfigKeyEntry {
+    /** 点分路径，和 `config.yaml` 里的写法逐字一致（`budget.maxCostUsd`） */
+    path: string;
+    /** 段名；顶层键没有这一格 */
+    section?: string;
+    /** 段内的字段名；顶层键没有这一格 */
+    field?: string;
+    kind: ConfigKeyKind;
+    write: ConfigKeyWrite;
+    /** `write !== 'scalar'` 时**必有**：不能 `config set` 的原因码（CLI 据此选文案） */
+    reason?: ConfigKeyReason;
+    /** 枚举型键的可选值 */
+    choices?: readonly string[];
+    minimum?: number;
+    exclusiveMinimum?: number;
+    maximum?: number;
+    exclusiveMaximum?: number;
+    minLength?: number;
+    /** schema 里写的内置默认值。没有默认值的键（`model` / `budget.maxCostUsd` …）不带这格 */
+    builtin?: SettingValue;
+}
+/**
+ * 全部配置键，按 schema 里的声明顺序排。
+ *
+ * 调用方**不许**改它（`readonly`），也不许在别处再抄一份 —— 报错提示、
+ * `config list`、`config set` / `unset` 认的键必须来自这一个数组。
+ */
+declare function configKeyTable(): readonly ConfigKeyEntry[];
+/** 按点分路径查一行；不认识的键返回 `undefined`（调用方据此报「未知配置项」） */
+declare function configKeyByPath(path: string): ConfigKeyEntry | undefined;
+/**
+ * 全部能 `config set` 的键。报错提示和 `config list --all` 都从这里取。
+ *
+ * 顺序就是 schema 的顺序 —— 分段天然相邻，不需要再排一次。
+ */
+declare function writableConfigKeys(): readonly ConfigKeyEntry[];
+/** 校验失败的原因。带格子是因为 CLI 要把它拼进一句人话（catalog 里那几条） */
+type ConfigValueProblem = {
+    code: 'not-a-kind';
+    kind: ConfigKeyKind;
+} | {
+    code: 'not-in-choices';
+    choices: readonly string[];
+} | {
+    code: 'below-minimum';
+    bound: number;
+    exclusive: boolean;
+} | {
+    code: 'above-maximum';
+    bound: number;
+    exclusive: boolean;
+} | {
+    code: 'too-short';
+    minLength: number;
+};
+/** {@link checkConfigValue} 的结论。成功时带上**该写进 yaml 的字面量** */
+type ConfigValueCheck = {
+    ok: true;
+    literal: string;
+} | {
+    ok: false;
+    problem: ConfigValueProblem;
+};
+/**
+ * 一个字符串能不能当这个键的值，以及它该以什么字面量写进 yaml。
+ *
+ * 校验顺序是固定的：类型 → 枚举 → 边界 → 长度。顺序有意义 —— 反过来的话
+ * `budget.warnAtPercent: abc` 会先撞上「不在 0~100 之间」，而真正的问题是它不是个数。
+ */
+declare function checkConfigValue(entry: ConfigKeyEntry, raw: string): ConfigValueCheck;
+
 /**
  * `~/.epoch/keybindings.json` 的加载（方案 31 PR-1 / PR-2）。
  *
@@ -15655,6 +16843,13 @@ interface Message {
     tokenCount?: number;
     finishReason?: string;
     reasoning?: string;
+    /**
+     * 这一步里工具改过的文件（补丁预览，v7）。和 `reasoning` 同一个位置：
+     * 一条 assistant 行 = 一步，那一步可能改了多个文件。
+     *
+     * 老库里这一列是 NULL（迁移刚加的），读侧见到 `undefined` 就当没有补丁卡。
+     */
+    diffs?: EpochDiffSnapshot[];
     active: boolean;
     compacted: boolean;
     observed: boolean;
@@ -15680,6 +16875,30 @@ interface Session {
     /** 获取上下文窗口内的消息 [OpenCode] */
     getContext(maxTokens?: number): Message[];
 }
+/**
+ * `delegate_task` 派出去的子任务，在 `sessions.source` 上记的那一档。
+ *
+ * ## 为什么要有一个自己的 source，而不是沿用 `'cli'`
+ *
+ * 子会话从 2026-10-27 起**真的会落盘**（在那之前只有一段临时 id，库里的
+ * `sessions` 表根本没有它那一行 —— 判据在 `runtime` 的 `subRunner` 上）。
+ * 落盘之后它就和用户自己的对话长得一模一样了，而这是两件事：
+ *
+ * - **它不是「用户的一段对话」**：`epoch -r`（最近一段）、`epoch -c`
+ *   （这个目录下最近一段）接上去都接错了对象 —— 用户想接着聊的是他自己那段，
+ *   不是十分钟前派出去的那个子任务。
+ * - **但它的过程必须读得到**：`session_trace` 从父会话沿着 `parent_id` 往下走，
+ *   要能列出它；`session_messages_read` 要能读回它每一步调了什么工具。
+ *
+ * 所以这两条路被刻意分开了：**列表 / `-r` / `-c` 默认排除它**（判据在
+ * `SessionDB.listSessions` 的 `includeDelegate` 上），**血缘和消息读回不排除**
+ * （那两条走的是各自的 SQL，不经过列表）。
+ *
+ * ⚠️ 这是一个**跨包的名字**：`core`（写行 / 列表过滤）和 `runtime`（建行）各用
+ * 一次，所以真源只在这儿一份。字符串抄两遍的下场是有人改了其中一处，
+ * 而表现只是「子会话忽然出现在列表里」—— 没有一处会红。
+ */
+declare const DELEGATE_SESSION_SOURCE = "delegate";
 interface CreateSessionInput {
     id?: string;
     title?: string;
@@ -15731,6 +16950,8 @@ interface AppendMessageInput {
     tokenCount?: number;
     finishReason?: string;
     reasoning?: string;
+    /** 这一步里工具改过的文件（补丁预览，v7）。**只该传给 assistant 行** */
+    diffs?: EpochDiffSnapshot[];
 }
 interface ListSessionsInput {
     /**
@@ -15773,6 +16994,17 @@ interface ListSessionsInput {
      * 再传进来（我们这边的同步层退 2s），代价只是重复拉几行、而那是幂等的。
      */
     updatedSince?: number;
+    /**
+     * 要不要把 `delegate_task` 派出去的子任务会话一起列出来。**默认不要。**
+     *
+     * 判据在 {@link DELEGATE_SESSION_SOURCE} 上：子会话不是用户的一段对话，
+     * 而 `epoch -r` / `epoch -c` / 侧栏列表问的都是「接着哪一段聊」。
+     * 它落盘是为了 `session_trace` + `session_messages_read` 读得回过程，
+     * 那条路上不经过这里。
+     *
+     * 只有「这个库里一共有哪些行」这一类调用方（增量备份、诊断）才该传 `true`。
+     */
+    includeDelegate?: boolean;
 }
 interface ListSessionsOutput {
     sessions: SessionMeta[];
@@ -16390,6 +17622,11 @@ declare class SessionManager implements SessionManager$1 {
      * 那不是摘要，是残缺的原文，句子往往截在一半，喂回模型比不给更糟。
      */
     compact(sessionId: string, summarize?: (transcript: string) => Promise<string | null>): Promise<CompactionResult>;
+    /**
+     * 把库里那几张图片下放成一行占位（2026-10-28）。判据全文在
+     * {@link SessionDB.offloadImageParts} 上 —— 这一层只是转发，**一个数都不算**。
+     */
+    offloadImageParts(sessionId: string): number;
     /**
      * 把引擎刚压完的那一次落进库里（方案 64 PR-1）。判据全文在
      * {@link SessionDB.archiveAndCompact} 上 —— 这一层只是转发，**一个数都不算**。
@@ -17368,18 +18605,25 @@ declare const MAX_AUDIT_ENTRIES = 500;
  * 拆的直接原因是 manager.ts 越过了 500 行硬线，但拆得动本身说明这一档确实
  * 独立：它是「没有任何规则命中时的兜底」，语义上不该和规则匹配混在一个类里。
  *
- * 五档的意图（对标 Hermes `approval.py`）：
+ * 四档的意图（对标 Hermes `approval.py` + deepseek-harness 的两根轴）：
+ *
+ * | 级别          | 审批 | 沙箱                 | 意图                                          |
+ * | ------------- | ---- | -------------------- | --------------------------------------------- |
+ * | `auto`        | never| `danger-full-access` | 全放行，**但底线那一层照旧**：灾难级拒、tier-2 拒、判不了放行 |
+ * | `plan`        | ask  | `read-only`          | 只读：写入 / 网络 / 执行代码一律拒，**只读命令放行**；区外**读**要问 |
+ * | `acceptEdits` | ask  | `workspace-write`    | 同 `auto`，但**工作区外的文件**要确认         |
+ * | `default`     | ask  | `workspace-write`    | 只读操作免确认（**工作区外的读除外**），其余一律确认 |
  *
- * | 级别          | 意图                                               |
- * | ------------- | -------------------------------------------------- |
- * | `bypass`      | 全放行 —— 但**挡不住第 1 层那两条 deny**，那层在前面 |
- * | `auto`        | 信任 agent：这一档自己不拦，边界全在第 1 层         |
- * | `plan`        | 只读：写入 / 命令 / 网络 / 执行代码一律拒；区外**读**要问 |
- * | `acceptEdits` | 同 `auto`，但**工作区外的文件**要确认               |
- * | `default`     | 只读操作免确认（**工作区外的读除外**），其余一律确认 |
+ * ## ⚠️ 2026-10-27：五档并成四档，`bypass` 并进 `auto`
+ *
+ * 实测（真 `PermissionManager` 跑 15 项日常操作）合并前的弹窗数是
+ * **11 / 5 / 2 / 1**（default / acceptEdits / auto / bypass），而 `auto` 与
+ * `bypass` 只差「判不了」那一格外加规则表 `ask` 那一族 —— 两档说不出
+ * 「用户凭什么选它而不是另一个」。合并方向取宽的（{@link ruleAskActive} 现在
+ * 只对 `auto` 为假），老名字 `bypass` 走 protocol 的别名表静默映射过来。
  *
  * ⚠️ **「工作区外」那一格是 `plan` / `default` / `acceptEdits` 三档共用的**
- * （2026-10-08）：`auto` / `bypass` 放行，其余三档问一句，判据在
+ * （2026-10-08）：`auto` 放行，其余三档问一句，判据在
  * {@link outsideWorkspace} 上。**档位管的是「问了之后算不算数」，不是「要不要问」**
  * —— 而「算不算数」由权限层算出来的 `grantedPaths` 兑现，工具层照它放行
  * （判据在 protocol 的 `ToolContext.grantedPaths` 上）。
@@ -17389,7 +18633,7 @@ declare const MAX_AUDIT_ENTRIES = 500;
  *
  * ## ⚠️ 这一档哪天要用「沙箱模式」，调 `sandboxModeForLevel()`，别在这儿长第二张表
  *
- * 上面那张五档表还有一个孪生兄弟：**同样五档 → 沙箱模式**（`read-only` /
+ * 上面那张四档表还有一个孪生兄弟：**同样四档 → 沙箱模式**（`read-only` /
  * `workspace-write` / `danger-full-access`），它今天住在
  * [infra/src/sandbox/policy.ts](../../../infra/src/sandbox/policy.ts)。
  * 方案 46 §2.2 原文说那段推导本该住在这个文件旁边（「那是权限系统的知识，
@@ -17800,29 +19044,52 @@ declare class PermissionManager implements PermissionManager$1 {
      *    plan 模式下一条判不了的命令会弹给用户，用户点「允许」它就真跑了 ——
      *    而 `checkPlan()` 那句「plan 模式禁止写入和命令执行」压根没机会说话。
      *
-     * 2. **`bypass` + `obfuscated` → 放行。** 排在缓存前面，于是「`bypass` 整段不查
+     * 2. **`never` 档下要人确认的底线分成两小支，落点相反**（2026-10-27 定的第二支）。
+     *
+     *    2a. **`obfuscated` → 放行。** 排在缓存前面，于是「`never` 整段不查
      *    审批缓存」（{@link checkRulesAndCache} 那一节）对**规则那条路**逐字仍然成立。
+     *    塌向「放行」的理由：这条判定的原话是「静态检查无法判定其真实行为，需人工确认」
+     *    —— 它是一句「我判不了」，不是一句「这危险」，而这一档的字面意思正是
+     *    「别拿你判不了的事来问我」。逐字就是 Hermes 的 yolo。
      *
-     *    ⚠️ **认码，不是认「所有 ask 形状的底线」**（2026-09-10 用户拍的）：
-     *    `dangerous-command`（tier-2，危险但可恢复）在这一档下**照旧问**。
-     *    用户的原话是「除了那种真的非常危险的操作，和无法判断的才会……停下来找
-     *    用户」，而他随后选定的两档形状是：**危险的问一句（点了就能干活）、
-     *    判不了的不问**。所以这一支只塌 `obfuscated`。
+     *    ⚠️ **代价说清楚**：这一档 + 提示注入 + `$(…)` 拼命令名这条路由此打通。
+     *    Hermes 在 `tools/approval.py` 那句 `# this and bypass every approval check
+     *    (prompt-injection escalation path)` 上承认的是同一个敞口。不接受的人该做的
+     *    是**别用这一档**，而不是让这一档偷偷弹框 —— 一个说了「不问」却还在问的
+     *    开关，会让用户学会闭眼点「允许」，那比敞口更坏。
      *
-     *    ⚠️ 塌向「放行」而不是 Codex 的「拒绝」：这条判定的原话是「静态检查无法
-     *    判定其真实行为，需人工确认」—— 它是一句「我判不了」，不是一句「这危险」，
-     *    而 `bypass` 的字面意思正是「别拿你判不了的事来问我」。这一档下**逐字就是
-     *    Hermes 的 yolo**（它的 floor 只有 hardline，判不了那一族住在 Tier-2、
-     *    被 yolo 整段跳过）。
+     *    2b. **`dangerous-command`（tier-2，危险但可恢复）→ 拒绝。**
      *
-     *    ⚠️ **代价说清楚**：`bypass` + 提示注入 + `$(…)` 拼命令名这条路由此打通。
-     *    Hermes 在 `tools/approval.py` 那句 `# this and bypass every approval check
-     *    (prompt-injection escalation path)` 上承认的是同一个敞口。不接受的人该做的是
-     *    **别用这一档**，而不是让这一档偷偷弹框 —— 一个说了「不问」却还在问的开关，
-     *    会让用户学会闭眼点「允许」，那比敞口更坏。
+     *    ## ⚠️ 2026-10-27：这一支从「问一句」翻成「拒绝」（用户拍的）
+     *
+     *    原判据（2026-09-10）是「危险的问一句（点了就能干活）、判不了的不问」。
+     *    它当时是对的 —— 那一版把「危险」和「判不了」一起塌成放行，而最高档下
+     *    `sudo apt install` 永远做不了是一句更坏的话。
+     *
+     *    翻过来的理由是**两家参照实现在这一点上一致，而只有我们不同**：
+     *
+     *    - Codex `exec_policy.rs:812`：`AskForApproval::Never => Decision::Forbidden`，
+     *      注释原文「we prefer to prompt the user rather than outright forbid the
+     *      command, but if the user has explicitly disabled prompts, we must forbid」；
+     *    - deepseek-harness `user-approval/src/index.ts` 的 `ApprovalPolicy`：`'never'`
+     *      的定义是「every ask resolves `'rejected'` deterministically」。
+     *
+     *    两家都是**拒绝**，而这一档承诺的是「不问」—— 承诺兑现之后必须有一个落点，
+     *    两家一致选了拒绝（fail closed），我们照此对齐。
+     *
+     *    ⚠️ **落到用户身上的代价**：`auto` 档下 `sudo apt install` /
+     *    `git push --force` / `chmod 777` 这类**做不了**，模型会收到一句拒绝而不是
+     *    一个可以点的出口。要干这些事得换回 `default` 或 `acceptEdits` 档 ——
+     *    那两档照旧弹窗，点了就能干活。这条差别是刻意的：**这一档不再提供
+     *    「点一下就放行」这个出口**，它只提供「不问」。
+     *
+     *    ⚠️ **灾难级（`rm -rf /`）不受影响**：它在 `hard-limits.ts` 里直接
+     *    不带 `requireApproval`，压根走不到这个方法。
+     *
+     *    ⚠️ **`plan` 档不受影响**：第 1 条在它前面就 return 了。
      *
      * 3. **用户以前对这一条明确答过 → 照他的答复。** 这是另一个缺陷：审批缓存躺在
-     *    这一层**后面**，所以一条判不了 / tier-2 危险的命令上点一百次「永久允许」，
+     *    这一层**后面**，所以一条 tier-2 危险的命令上点一百次「永久允许」，
      *    第一百零一次照样弹 —— 那个出口在这一族上是**画着但不通**的。
      *
      *    ⚠️ 这里查缓存**不受 `approvalCacheActive()` 约束**（那条只管规则那条路）：
@@ -17830,6 +19097,11 @@ declare class PermissionManager implements PermissionManager$1 {
      *    2026-08-17 那条判据（`bypass` 下缓存的 deny 不该拦住任何东西）没有被翻 ——
      *    它说的是**档位本来就放行**的操作，而这一支下面的操作档位从来不放行。
      *
+     *    ⚠️ **2026-10-27 起它在「不问」那一档的 tier-2 拒绝之前**，这是刻意的：
+     *    用户在 `default` / `acceptEdits` 档下点过「永久允许」的 `sudo apt install`，
+     *    换到 `auto` 档之后**照旧放行** —— 那是一个真实的授权，`never` 的意思是
+     *    「别拿没授权的事来问我」，不是「我批过的也不作数」。要撤销去审批面板撤。
+     *
      *    这不是「让缓存绕过黑名单」：绕不过的是 deny 形状的那两条（灾难级危险命令、
      *    敏感路径），它们在 `hard.requireApproval` 为假时压根走不到这儿。
      *
@@ -17838,12 +19110,16 @@ declare class PermissionManager implements PermissionManager$1 {
      */
     private settleUnaskable;
     /**
-     * **规则那条路**上会不会查审批缓存（2026-08-17 的判据：`bypass` 整段不查，
+     * **规则那条路**上会不会查审批缓存（2026-08-17 的判据：`never` 那一档整段不查，
      * 全文在 {@link checkRulesAndCache} 上）。
      *
      * ⚠️ **它不是「这个档位记不记得住」**：安全底线那条路（{@link settleUnaskable}）
      * 在任何档位下都查缓存。宿主要知道的是**这一次问的这道题**记不记得住，
      * 那个答案在 `PermissionDecision.rememberable` 上，由 {@link rememberFlag} 打。
+     *
+     * ⚠️ 2026-10-27 起它和 {@link ruleAskActive} 走同一个判据（审批轴），但**仍是
+     * 两个方法**：一个问「规则表说要问，这一档还问不问」，一个问「弹窗答案的记忆
+     * 这一档查不查」。合并成一处的话，哪天其中一条改了判据，另一条会**无声地**跟着改。
      */
     approvalCacheActive(): boolean;
     /**
@@ -18551,7 +19827,7 @@ declare function nextRunAt(trigger: ScheduleTrigger, from?: number, startDate?:
  * 那是「这个任务每天都失败，而你要三天后才发现」。所以保存时校验、
  * 校验不过不许存 —— 定时任务的反馈回路按天算，能提前的每一步都值钱。
  *
- * ## 「定时任务 + 跳过全部检查」的三条硬约束**挂在组合上**
+ * ## 「定时任务 + 完全访问」的三条硬约束**挂在组合上**
  *
  * `bypass` 在对话里是一档现成的权限档，用户自己看着屏幕时选它是他的事；
  * 但一个**无人值守、每天自己跑一次**的 `bypass` 是另一回事 —— 那正是
@@ -18569,7 +19845,6 @@ interface ValidateScheduleInput {
     /** 绝对路径。空串 = 用户没绑工作区（`bypass` 下这是硬伤） */
     workDir: string;
     maxTurns: number;
-    maxBudgetUsd: number;
     timeoutMs: number;
     trigger: ScheduleTrigger;
     startDate?: string;
@@ -18661,8 +19936,22 @@ declare function parseScheduleDraft(raw: unknown): DraftParse;
  * 这次提案**放宽**了什么。
  *
  * 三类都是授权面变大的方向（判据在 `ScheduleWideningKind` 上）。新建那一支的
- * 基线是**引擎那份缺省档**（`default`）而不是「空」—— 拿空当基线的话每一条新任务
- * 都会被标成「放宽了」，而一枚恒亮的警示标等于没有警示标。
+ * 基线是**引擎那份缺省档**（`SCHEDULE_DEFAULT_PERMISSION`）而不是「空」——
+ * 拿空当基线的话每一条新任务都会被标成「放宽了」，而一枚恒亮的警示标等于没有警示标。
+ *
+ * ## 🔴 2026-10-27：基线从 `default` 抬到了 `auto`，于是「新建」那一支再也标不出来了
+ *
+ * 这不是失手，是抬档的必然结果：基线既然已经是**最宽那一档**，没有任何一档
+ * 在它右边 —— `indexOf(level) > indexOf(base)` 对新建立永远不成立。
+ *
+ * 那一支的警示因此**没有消费者了**。留着它而不是删掉，是因为 `update` 那一支
+ * 靠的正是同一个比较（拿那条任务现在的档当基线），而那一条照旧有效；
+ * 把两支拆开会让「放宽」这个概念在两处各有一个定义。
+ *
+ * ⚠️ **新建那条路的警示不是丢了，是换了一个地方说**：权限档现在默认就是最宽
+ * 那一档，于是「这条新任务将不经确认地做这些事」这句话由**卡片上那份清单** +
+ * `validate.ts` 那三道网（工作目录不许宽得等于没绑 / 尺子必须有值 / 二次确认）
+ * 接住。用户在卡片上看见的是它的绝对值，而不是一个「相对刚才变宽了」的相对值。
  */
 declare function draftWidening(draft: ScheduleDraft, current?: ScheduleDefinition): ScheduleWideningKind[];
 /**
@@ -18674,10 +19963,9 @@ declare function draftWidening(draft: ScheduleDraft, current?: ScheduleDefinitio
  * 看见「未知命令」。那一支的真话是「改一条已有任务今天只有界面那条路」，
  * 由工具输出说出来。
  *
- * ⚠️ **`--budget` 那一格现在是真数了。** 2026-10-20 之前它是 `<你定一个上限>` 的
- * 占位符（草稿没有预算，而 `epoch schedule add` 缺 `--budget` 会当场拒绝），
- * 于是这条命令行和表单那条路落在同一处摩擦上。今天草稿带着预算，这条命令行
- * 因此真的可以直接粘贴跑起来 —— 打印的就是**已经落库的那个数**。
+ * ⚠️ **命令里已经没有 `--budget` 了**（2026-10-29 撤掉了预算那把尺子，
+ * `epoch schedule add` 也不再认那个旗子）。轮次和超时那两格走缺省，所以这一行
+ * 拼出来的就是一份完整可用的 `add`。
  */
 declare function draftCommandLine(draft: ScheduleDraft): string | undefined;
 
@@ -19339,6 +20627,30 @@ declare const DEFAULT_COMPLIANCE_SETTINGS: ComplianceSettings;
  *
  * 通过 shell 命令执行 hook 脚本，JSON 通过 stdin/stdout 通信。
  * 退出码 2 = 关键阻止，其他非零 = 警告。
+ *
+ * ## 沙箱（2026-10-26 补上，方案 65 §2.3）
+ *
+ * 这条子进程以前是**完全无边界**的 `spawn(command, { shell: true })`，而同一个
+ * 仓库里 `terminal` 是包在 `confine()` 里的 —— 同一能力两套边界。而 hook 的口子
+ * 并不小：它是**任意 shell**，来源是七份配置文件（项目级那三份要过工作区信任闸门，
+ * 通过之后就是永久授权），并且 `tool:before` / `verify:stop` 是**自动执行**的，
+ * 没有人会在那一刻再回答一次「要不要跑」。
+ *
+ * 现在它在 macOS / Linux 上走和 `terminal` 同一条 `confine()`，边界见
+ * {@link hookSandboxPolicy}。Windows 没有后端（判据在 infra 的
+ * `sandbox/backend.ts` 文件头），所以那一支**逐字节保持改之前的样子**。
+ *
+ * ## 一条不许漏的：沙箱拒绝**不进表决**
+ *
+ * 被挡住时退出码是普通的非零（seatbelt 是 1），`blocked` 照旧只有 `exitCode === 2`
+ * 才成立。这不是没顺手改 —— 是**不能**改：`verify:stop` 上「阻止」等于
+ * 「不许收工」，而一条被沙箱挡住的 `verify:stop` 下一轮还是被挡住，于是
+ * 模型永远收不了工（确定性死循环，不是概率问题）。沙箱拒绝那条路由
+ * [manager.ts](./manager.ts) 的 `reportIfNotRun()` **如实说出口**，说清
+ * 「这条 hook 没跑成」而不是「它通过了」。
+ *
+ * 「放行」这个方向本身沿用的是 2026-08-08 定下的取舍（hook 不是安全边界），
+ * 判据在 `manager.ts` 的 `reportIfNotRun()` 上 —— 别在这里另开一套。
  */
 
 /** Command hook 配置 */
@@ -19372,6 +20684,40 @@ interface CommandHookResult {
     rejectReason?: string;
     /** stdout 解析为 JSON 时的结构化输出 */
     output?: Record<string, unknown>;
+    /**
+     * 这一次的沙箱账。**永远有值** —— 「没包上」也是一个要说出口的结论
+     * （同 infra 的 `Confinement`：`confine()` 不返回 null 就是为了这个）。
+     */
+    sandbox: CommandHookSandbox;
+    /**
+     * 非零退出时这次失败属于哪一种（判据在 infra 的 `sandbox/classify.ts` 文件头）。
+     *
+     * ⚠️ **只在包上了沙箱时才有值**：没有沙箱就没有「被沙箱挡了」和
+     * 「沙箱没起来」这两种可能，硬跑一遍分类器只会拿当前平台压根不产生的方言
+     * 去匹配（`terminal` 那条路也是这么分的，见 `plugin-terminal/src/sandbox.ts`
+     * 的 `ConfinedShell.classify`）。
+     */
+    failure?: FailureVerdict;
+}
+/** hook 这一次跑在什么边界里 —— 形状对齐 `plugin-terminal` 的 `SandboxOutcome` */
+interface CommandHookSandbox {
+    /** 真包上了没有。`false` 时看 {@link skipped} */
+    confined: boolean;
+    /** 按哪一档包的。**恒为 `workspace-write`**，判据在 {@link hookSandboxPolicy} 上 */
+    mode: SandboxMode;
+    backend: IsolationBackend;
+    /**
+     * 没包上的原因。三档是**三句不同的话**（同 infra 的 `Confinement.reason`，
+     * 但少了 `config-disabled` 一档 —— hook 这一侧今天没有自己的开关，
+     * 判据在 {@link hookSandboxPolicy}）：
+     * `mode-disabled` 走不到（mode 是钉死的），留着它是为了形状对齐。
+     *
+     * ⚠️ `Confinement.reason` 2026-10-27 多了一档（`escalated`；
+     * 方案 65 §2.1），**它在这里刻意不存在**：那一档的唯一产地
+     * 是 `SandboxPolicy.bypass`，而 hook 的 policy 从来不设那一格（见
+     * {@link hookSandboxPolicy}）。收窄在 {@link hookSkipReason} 里。
+     */
+    skipped?: 'config-disabled' | 'mode-disabled' | 'no-backend';
 }
 
 /**
@@ -21125,6 +22471,105 @@ declare function imagePartTokens(image: string): number | undefined;
  */
 declare function pendingImageTokens(messages: readonly EpochMessage[]): number;
 
+/**
+ * 「这一次请求里图片一共占多少**字节**」—— 和那条 token 预算**是两个量纲**。
+ *
+ * ## 为什么非要有这一条线（2026-10-28）
+ *
+ * 仓库里已经有一条按容量的预算：`isPromptOversize`（protocol 的 `usage.ts:202`），
+ * 它判 token 占窗口的几成。那条线**看不见图片的字节**，而这两件事在图片上会
+ * 彻底分家：
+ *
+ * | 量纲 | 谁在看 | 一张 2 MB 的截图记多少 |
+ * | --- | --- | --- |
+ * | token | `isPromptOversize` / `shouldCompress` / `pendingImageTokens` | **约一千出头**（按宽高估，`image-tokens.ts:48`） |
+ * | 字节 | **本文件** | 2.7 MB（base64 是原文的 4/3） |
+ *
+ * 而 chat completions 是**无状态**的：每一轮都把整段历史重发一遍，历史里每张图
+ * 都以 base64 再传一次。于是「几个 2 MB 的截图」在 token 账上还空着九成，请求体
+ * 已经撞穿了网关那条上限 —— 表现是 `PROVIDER_BODY_TOO_LARGE`（1051）或者说
+ * 「请求体过大」，而**两条 token 线一个都不会动**。
+ *
+ * ## 为什么只数图片，不数整份请求体
+ *
+ * 因为**只有图片是「token 少、字节大」的那一个**。文本这两个量纲是单调同向的
+ * （一段一 MB 的日志在 token 账上就是几十万），它太大时 `isPromptOversize` 那条
+ * 线早就先抓住了，轮不到这里。
+ *
+ * 反过来做的代价很大：要数整份请求体就得 `JSON.stringify(system + tools + messages)`
+ * 一遍 —— 那是每轮几 MB 的字符串拼接，而且它会把「这一轮该不该发」这个判断
+ * 绑在 SDK 的消息形状上（`toModelMessages` 是唯一认那个形状的地方，
+ * 见 `provider/sdk-adapter.ts` 的文件头）。
+ *
+ * ## 三类图里只有一类有字节可数
+ *
+ * `EpochImagePart.image` 有三种形态（判据在 protocol 的 `message.ts:60`）：
+ *
+ * | 形态 | 数不数 | 为什么 |
+ * | --- | --- | --- |
+ * | 裸 base64 / `data:` URL | 数 | 它就摆在请求体里 |
+ * | `http(s)` URL | **不数** | provider 自己去取，我们连字节都没有 —— 猜一个数去拦人是最坏的选择（判据同 `image-tokens.ts` 的那两条取舍） |
+ *
+ * `data:` 前缀（`data:image/png;base64,`，约 22 字节）**剥掉再数**：它是个常数、
+ * 量级无关，但剥掉之后数出来的就是真正的载荷，和小票上那两个数对得上账
+ * （`artifact.bytes` 是原始字节，base64 是它的 4/3）。
+ */
+
+/**
+ * 这一组消息里**所有图片**的 base64 字节合计。
+ *
+ * ## 必须扫两处，不是一处
+ *
+ * 图有两条进请求体的路，而它们**恰好对应两种撑爆的现场**：
+ *
+ * | 从哪来 | 形状 | 对应哪种现场 |
+ * | --- | --- | --- |
+ * | 用户贴的图 | `message.parts[].type === 'image'` | 历史累积（第二轮那种，每条消息都发不出去） |
+ * | **工具产物** | `toolResults[].artifacts[].data` | 一轮内累积（第一轮那种，工具跑几次就撑爆） |
+ *
+ * 只扫第一处的话，`stripHistoryImages`（`agent/loop.ts:269`）那种**只看 user 行
+ * 的 `parts`** 的老盲区会原地复现一次：工具截图（`plugin-file` 的 `file_read` 读
+ * png、`page_shot` 那类）全部漏掉，而它们恰恰是体积最大的一族。
+ *
+ * ## `artifacts[].data` 才是判据，不是 `artifacts` 非空
+ *
+ * 有没有 `data` 是闸门的结论（`context/artifact-gate.ts:183` 那段：有 `data` 就
+ * 进上下文、没有就只是一句 summary）。被闸门拦下的图**一个字节都不进请求体**，
+ * 把它算进预算会让下放发生在根本不需要的时候 —— 而那种误操作是有损的。
+ */
+declare function requestImageBytes(messages: readonly EpochMessage[]): number;
+/**
+ * 把**最老的**几张图换成占位文本，直到剩下的字节数落在预算内。
+ *
+ * ## `keepFresh` 是这一整个特性的安全性所在
+ *
+ * 它说的是「最新的 N 条消息里的图一张都不摘」。**必须 ≥ 1**，理由是这一轮用户
+ * 刚贴的那张图：他正等着模型看图回答，把它摘掉等于把这一轮的活直接干废 ——
+ * 而模型还会一本正经地照着一句「图片已下放」去答，用户完全看不出发生了什么。
+ *
+ * 所以下放只从**旧**的一头开始。代价是「一张巨图 + 预算很小」这一档下放不动
+ * （最老的那张就是最新的那张），那时回 `offloaded: 0`，调用方据此知道
+ * 「这一招不管用」—— 别在那儿硬摘一张正在用的图。
+ *
+ * ## 为什么不是「摘到刚好够」而是「按张为单位」
+ *
+ * 一张图是不可分的：摘一半的 base64 是坏数据。所以这里逐张摘，直到总量进预算。
+ * 最坏情况是超摘一点点（最后那一张其实可以留着），那个代价可以接受 ——
+ * 反过来「差一点没摘够」会让这次救援白跑一趟，而重发的那一发是要么成功要么
+ * 再撞一次墙。
+ *
+ * @param keepFresh 最新的多少条消息里的图不碰。**0 是不安全的**（见上），
+ *   调用方给 `undefined` 时按 1 处理
+ */
+declare function offloadOldestImages(messages: readonly EpochMessage[], opts?: {
+    budgetBytes: number;
+    keepFresh?: number;
+}): {
+    messages: EpochMessage[];
+    offloaded: number;
+    remainingBytes: number;
+};
+
 /**
  * 上下文压缩器 — 默认 ContextEngine 实现。
  * 4 阶段算法（Hermes agent/context_compressor.py），**中间多了一道闸**
@@ -21272,7 +22717,7 @@ declare class ContextCompressor implements ContextEngine {
      */
     private cleanupOrphans;
     /**
-     * 一组消息的 token 总量。逐条过 {@link estimateTokens}，不另立口径。
+     * 一组消息的 token 总量。逐条过 {@link messageTokens}，不另立口径。
      *
      * 这里原来是三个私有函数（`estimateTokens` / `estimateTokenCount` /
      * `tokensForChars`），各自写着 `chars / 4`，和 `model-metadata.ts` 里那份
@@ -21862,7 +23307,9 @@ interface RunCodeOutcome {
  * 失败的分类。**给模型看的措辞按这个分叉**，因为每一档的正确下一步都不一样：
  * 触顶要少调几次、超时要提 `timeout`、OOM 要少占内存、`throw` 要改程序。
  */
-type RunCodeFailure = 'timeout' | 'oom' | 'cap' | 'throw' | 'aborted' | 'worker-missing';
+type RunCodeFailure = 'timeout' | 'oom' | 'cap' | 'throw' | 'aborted' | 'worker-missing'
+/** 权限策略把 worker 自己拦在门外 —— 判据在 `policy.ts` 的文件头 */
+ | 'policy';
 declare function runCode(input: RunCodeInput): Promise<RunCodeOutcome>;
 
 /**
@@ -21907,4 +23354,4 @@ declare function resolveCodeModeWorker(baseDir: string, exists?: typeof existsSy
  */
 declare function codeModeWorkerPath(): string | undefined;
 
-export { ABOUT_DESC_MAX_CHARS, ABOUT_README_MAX_CHARS, AGENT_ROLE_DIAG_MODULE, ARTIFACT_MAX_TOTAL_BYTES, ARTIFACT_RETENTION_DEFAULTS, ATTACHMENT_MAX_TOTAL_BYTES, ATTACHMENT_RETENTION_DEFAULTS, type AcquireResult, type ActivePlugin, type AgentConfig, AgentLoop, type AgentProvider, type AgentSite, type AgentSiteRef, AppearanceStore, type AppendMessageInput, ApprovalCache, type ApprovalDecision, type ArtifactOpenRefusal, type ArtifactRetention, type AskQuestionDeps, type AttachmentRetention, BLOCKED_TOOLS, type BackendOptions, type BackendOutcome, type BackgroundTaskSource, type BaseOrigin, type BaseSlot, type BeginTurnInput, type BreakdownInput, BudgetGuard, type BudgetGuardOptions, type BudgetInfo, type BudgetLevel, type BudgetOptions, type BudgetStatus, BudgetStore, type BudgetStoreOptions, type BuildFireArgvInput, type BuildIndexOptions, CHECKPOINT_MAX_TOTAL_BYTES, CLAUDE_EVENT_NAMES, CLAUDE_TOOL_NAMES, CODE_MODE_LIMITS, CODE_MODE_SDK_TAG, CONFIG_KEYS, CURRENT_CONFIG_VERSION, type CachedApproval, type CachedDecision, type CheckpointCapture, type CheckpointFile, CheckpointManager, type CheckpointManagerOptions, type CheckpointManifest, CheckpointStore, type CheckpointStoreOptions, type CheckpointSummary, type ClaudeHooksParseOptions, type CodeModeLimits, type CodeRequest, type CodeResult, CodeSandbox, type CommandHookConfig, type CommandHookResult, type CommandLoadOutcome, type CommandLoadSummary, type CommandResult, type CommandRunner, type CompactionResult, type CompiledRules, type ComplianceDirSpec, type ComplianceDirsSummary, ComplianceEngine, type ComplianceEngineInput, type ComplianceGate, type ComplianceHit, type ComplianceRule, type ComplianceRuleSource, type ComplianceSettings, type ComplianceVerdict, type CompressConfig, type CompressResult, type ConfigMigration, type ConfigOrigins, ContextCompressor, type ContextEngine, type CreateScheduleInput, type CreateSessionInput, DEFAULT_COMPLIANCE_ACTIONS, DEFAULT_COMPLIANCE_SETTINGS, DEFAULT_COMPRESSION_THRESHOLD, DEFAULT_GOAL_MAX_ROUNDS, DEFAULT_MAX_HOLD_CHARS, type DelegateArgs, type DelegateConfig, DelegateManager, type DelegateTaskResult, type DiagnoseOptions, type DiscoverOutcome, type DiscoveredFile, type DoctorReport, type DraftParse, EMPTY_RULES, EPOCH_DISK_LEDGER, type EntryProbeCode, type EntryProbeResult, EpochConfigSchema, type ExpandOptions, type ExtractOutcome, FTS_TABLES, FTS_TRIGGERS, type FallbackEvent, type FileSlots, type FileSourceKind, type ForkInput, type FrontmatterParse, type FrontmatterSplit, type FtsHealth, type FtsReclaim, type FtsSpace, type FtsTableHealth, GOAL_BLOCK_CODES, type GateAxis, type GateVerdict, type GenerateInput, type GenerateOutput, type Goal, type GoalBlockReason, type GoalClear, type GoalPhase, type GoalPromptView, type GoalRefusal, type GoalRoundResult, GoalService, GoalStore, type GoalToolDeps, type GoalWrite, HEADLESS_AUDIT_CODES, type HeadlessPolicy, type HookConfigEntry, HookManager, type HookManagerOptions, type HookMatcher, type HookSourceKind, type HookSourceStatus, type HookSourcesOptions, type HookSourcesSummary, type HooksParseOutcome, type MemoryManager$1 as IMemoryManager, INSTRUCTION_BUDGET_CHARS, INSTRUCTION_FILES, type SessionManager$1 as ISessionManager, type SkillSystem$1 as ISkillSystem, ImageLoadError, type ImageSize, type ImportDecision, type ImportGate, type ImportGoal, type ImportMessage, type ImportNode, type ImportPartsResult, type ImportSessionInput, type ImportSessionMeta, type ImportSessionResult, type ImportSkipReason, type ImportTodo, ImportTrustStore, type InstallDependency, type InstallOptions, type InstallOutcome, type InstallPreview, type InstallStep, type InstructionScan, type InstructionSource, type IsolationReason, type IsolationReport, type JsonSchemaDocument, LAUNCHD_LABEL_PREFIX, LOCK_HEARTBEAT_MS, LOCK_STALE_MS, type LastOpenSession, LastOpenSessions, type LayerOutcome, type LayerScalars, type LayerStatus, type LearningContext, type LearningResult, type LearningSkipReason, type LexiconLoadOutcome, type LifecycleOutcome, type ListCandidatesInput, type ListSessionsInput, type ListSessionsOutput, type LoadCommandsOptions, type LoadConfigOptions, type LoadKeybindingsOptions, type LoadKeybindingsResult, type LoadRolesOptions, type LoadedPlugin, type LockHolder, MARKETPLACE_DISPLAY_FIELDS, MARKETPLACE_FILE, MAX_AUDIT_ENTRIES, MAX_COMMAND_DEPTH, MAX_GOAL_MAX_ROUNDS, MAX_IMPORT_DEPTH, MAX_LAST_OPEN_SESSIONS, MAX_OBJECTIVE_CHARS, MAX_REASON_CHARS, MAX_RECENT_WORKSPACES, MODEL_ENTRIES_FILE, MODEL_GIVE_UP_THRESHOLD, MULTIMODAL_DEFAULTS, type ManagedPolicy, ManagedPolicyError, type ManagedSettings, ManagedSettingsSchema, type MarketplaceCatalog, type MarketplaceCategory, type MarketplaceDisplay, type MarketplaceDisplayField, type MarketplaceEntry, type MarketplaceOutcome, type MarketplaceRecord, type MarketplaceStatus, type MemoryConfig, type MemoryEntry, type MemoryImportRecord, type MemoryImportResult, MemoryManager, type MemoryManagerOptions, type MemoryNotice, type MemoryRemoval, type MemorySearchResult, type MemoryTarget, type MemoryWriteResult, type MentionPart, type MentionResolution, type Message, type MessageHit, type MessageRecord, type MessageSurface, type ModelCapability, ModelFailureTracker, type ModelMetaEntry, type ModelPricing, type MultimodalPolicy, NOMINAL_TOTAL_BYTES, NO_REVEALED_TOOLS, type NonInteractiveProbe, type OsTaskSnapshot, type OutputGuard, PACK_EXCLUDES, PERMISSION_AUDIT_CODES, PLUGIN_ICON_MAX_BYTES, PLUGIN_LAYOUT, PLUGIN_MANIFEST_FILE, PLUGIN_MANIFEST_KEYS, PLUGIN_NAME_PATTERN, PLUGIN_ROOT_ENV, PLUGIN_ROOT_TOKEN, PLUGIN_VISIBILITY, POLICY_DECISIONS, PROBE_VERSION, PROJECT_AGENTS_SUBDIR, PROVIDER_NO_CREDENTIAL, type PackFile, type PackLimits, type PackOutcome, type PackPlan, type PackPlanOutcome, type PermissionAuditCode, type PermissionAuditEntry, type PermissionAuditOutcome, type PermissionAuditScope, type PermissionAuditSnapshot, PermissionManager, type PersistFailureKind, type PersistedBudget, type PersistedPart, type PlanApprovalFn, type PlanEnterResult, type PlanModeDeps, PlanModeState, type PlanSettlement, type PluginAbout, type PluginArtifacts, type PluginAuthor, PluginAuthorSchema, type PluginCommandDir, type PluginCounts, type PluginDoc, type PluginHookFile, type PluginInventory, type PluginLoadOptions, type PluginManifest, type PluginPathRef, type PluginRecord, type PluginScope, type PluginSettingsFile, type PluginSourceType, type PluginStateReadOutcome, PluginStore, type PluginVisibility, type PolicyDirSpec, type PolicyDirsSummary, type PolicyLoadOutcome, type PolicyRule, PolicyRuleSchema, type PricingAt, type PricingOverride, type ProjectContext, type ProjectExtensionInventory, ProviderError, ProviderRouter, type ProviderStreamChunk, type ProviderToolCall$1 as ProviderToolCall, type ProviderWarning, type PruneResult, type QuestionAskFn, RECORDING_KEEP_RUNS, RECORDING_MAX_BYTES, ROLE_FRONTMATTER_SCHEMA, RUN_CODE_TOOL, type ReadMessagesInput, type ReadMessagesOutput, type RecentWorkspace, RecentWorkspaces, type RecordRunInput, type RecorderOptions, type RecoveryAction, type RegisterInput, type RegisterOutcome, type RegistrarOptions, type RegistrationPatch, type RepairOutcome, type ResolveMentionsOptions, type ResolveReferenceInput, type ResolveSettingsOptions, type ResolvedCompression, type ResolvedReference, type ResolvedSource, type ResponseFormat, type RestorePartsOptions, type RewindAction, type RewindDrift, type RewindFilePlan, type RewindOptions, type RewindOutcome, type RewindPreview, type RoleCreateFailure, type RoleCreateInput, type RoleCreateOptions, type RoleCreateOutcome, type RoleLoadOutcome, type RoleLoadSummary, type RoleMergeNotice, type RoleMergeResult, type RoleRemoveFailure, type RoleRemoveOptions, type RoleRemoveOutcome, type RoleScope, type RuleMatch, type RuleSuggestion, type RuleVerdict, type RunCodeFailure, type RunCodeInput, type RunCodeOutcome, type RunCodeToolDeps, type RunEstimateInput, type RunInput, type RunResult, type RunningSchedule, SANDBOX_COVERS, SANDBOX_EXCLUDES, SCALAR_KEYS, SCHEDULE_DEFAULTS, SCHEDULE_DEFAULT_ALLOWLIST, SCHEDULE_FORM_BUDGET_USD, SCHEDULE_ISSUE_CODES, SCHTASKS_FOLDER, SESSION_MESSAGES_READ_TOOL, SESSION_MESSAGES_SEARCH_TOOL, SESSION_QUERY_TOOLS, SESSION_SEARCH_TOOL, SESSION_TRACE_TOOL, SETTINGS_LAYER_ORDER, SETTING_WRITE_KEYS, SETTING_WRITE_LAYERS, SKILL_ASSET_DIRS, SKILL_CREATE_TOOL, SKILL_EDIT_TOOL, SKILL_FILE, SKILL_PATCH_TOOL, SKILL_VIEW_TOOL, SKILL_WRITE_FILE_TOOL, SLASH_COMMANDS_DIAG_MODULE, type ScalarKey, type ScanInstructionsOptions, type ScheduleArgvRefusal, type ScheduleArgvResult, type ScheduleArgvWarning, type ScheduleBackend, type ScheduleCliEntry, type ScheduleDraftDeps, type ScheduleDrift, type ScheduleDriftKind, type ScheduleImportInput, type ScheduleInstallForm, type ScheduleIssue, type ScheduleIssueCode, type ScheduleLock, ScheduleRecorder, ScheduleRegistrar, ScheduleStore, type ScheduleValidation, type SchemaExport, type SearchHit, type SearchInput, type SearchMessagesInput, type SearchMessagesOutput, type SearchOutput, type SearchSessionsInput, type SelectionDeps, type SelfConnector, type SelfIndexInput, type SelfSettings, type Session, type SessionCandidate, type SessionHit, SessionManager, type SessionMentionDeps, type SessionMeta, SessionQueries, SessionReferences, type SessionSearchDeps, type SessionStats, type SessionSurface, type SessionTrace, type SessionVisibility, type SessionVisibilityInput, type SettingApply, type SettingApplyFacts, type SettingChain, type SettingFutile, type SettingLayer, type SettingStep, type SettingValue, type SettingValueKind, type SettingWriteFailure, type SettingWriteKey, type SettingWriteLayer, type SettingWriteOutcome, type SettingWriteRequest, type SettingWriteTarget, type SettingWriteTargetsOptions, type SettingsFile, SettingsFileError, SettingsFileSchema, type SettingsLayer, type SettingsResolution, type ShadowFinding, type ShadowKind, type Skill, type SkillDirSource, type SkillDirSpec, type SkillDirsSummary, type SkillImportConflict, type SkillImportDone, type SkillImportEntry, type SkillImportFailure, type SkillImportForm, type SkillImportOptions, type SkillImportPreview, type SkillImportResult, type SkillIndexEntry, type SkillIndexOptions, type SkillIndexResidency, type SkillIndexStats, SkillLearner, type SkillLearningProvider, type SkillMeta, type SkillStats, SkillSystem, type SkillSystemOptions, type SkillViewDeps, type SkillWriteDeps, type SteerSource, type StoredAppearance, type SubAgentRunner, type SubTask, type SubToolCaller, type SummarizeOutput, type SurfaceMessage, type SystemPromptParams, type SystemPromptSegments, TOOL_SEARCH_TOOL, TaskNoticeTracker, type TodoItem, type ToggleOutcome, type ToolCall, type ToolConflict, type ToolGate, type ToolNameFidelity, type ToolNameLookup, ToolRegistry, type ToolRevealState, type ToolScope, type ToolSearchDeps, type ToolTableCost, type TraceInput, type TraceNode, TrackerDB, type TrustDecision, type TrustGate, type TrustGateOptions, TrustManager, type TurnRecord, type TurnTiming, UNSETTABLE_USER_KEYS, type UpdateScheduleInput, type UtilityModelInfo, type ValidateScheduleInput, type VersionCheck, Workspace, type WorkspaceFiles, type WorkspaceIssue, type WorkspaceIssueKind, acquireScheduleLock, addMarketplace, addUsage, admitArtifact, admitArtifacts, affectedPaths, approvalEntryFor, approvalRootFor, artifactLaunchArgv, artifactOpenRefusal, assertLevelAllowed, blockedRoleTools, buildContextBreakdown, buildFireArgv, buildFtsMatchQuery, buildSchemaExports, buildSystemPrompt, buildTrigramMatchQuery, builtinRoles, capabilityOfRef, checkEpochVersion, checkFtsHealth, checkShadowing, classifyPersistFailure, classifyProviderError, clearModelCache, coalesceRecording, codeModeWorkerPath, commandNameFromRelPath, compileRuleLists, compressionOptions, computeCost, computeCostMicros, computeExecHash, countRules, createAllowAllGate, createAllowAllImportGate, createAskQuestionTool, createCodeExecTool, createDelegateTool, createDenyAllGate, createDenyAllImportGate, createGoalTool, createImportGate, createMemoryTool, createPlanModeTools, createPluginScope, createRoleFile, createRoleScope, createRunCodeTool, createScheduleDraftTool, createSessionMessagesReadTool, createSessionMessagesSearchTool, createSessionSearchTool, createSessionSearchTools, createSessionTraceTool, createSkillViewTool, createSkillWriteTools, createTodoTool, createToolRevealState, createToolScope, createToolSearchTool, createTrustGate, currentEpochVersion, decideImport, decideTrust, defaultConfig, describeArtifactRefusal, describeBackgroundTask, describeHeadlessPolicy, describeIsolation, describeJsonError, diagnoseSchedules, discoverMarkdown, discoverModels, discoverProject, discoverySpec, displayAllows, displayCurrency, draftCommandLine, draftWidening, escapeRuleContent, estimateImageTokens, estimateRunTokens, estimateTokens, evaluateSelection, expandCommand, expandImports, explainSetting, extractArchive, findInstructionFiles, findProjectInstructions, findRole, formatBytes, formatSkillIndex, formatUsd, gateForTool, getCapability, getConfigIssues, getConfigOrigins, getImportGate, getTrustGate, grantedPathsFor, hasDedicatedExecContent, hasExecTierContent, hasPromptCaching, hasProviderCredentials, hasReadTierContent, hasUsableModel, imageFromBase64, imageFromPath, imagePartTokens, importParts, importSkills, installPlugin, instructionDirs, instructionNotices, intervalSlots, inventoryProjectExtensions, inventoryTotal, isBlockCode, isCodeModeDeferred, isEmptyRules, isGoalPhase, isNonInteractive, isReadOnlySubCall, isSettingWriteLayer, isTransientPersistFailure, isValidInterval, isValidPluginName, isWithinWindow, isWritableSettingKey, labelSlug, layerRank, listEntryModels, listRunningSchedules, listSessionCandidates, listWorkspaceFiles, loadCommandDefinitions, loadCommandFile, loadCommands, loadConfig, loadHookSources, loadKeybindings, loadLexiconDir, loadLexiconFiles, loadModelEntries, loadPlugins, loadPolicyFiles, loadPolicyRules, loadRoleDefinitions, loadRoleDir, loadedImports, localDateString, managedSwitchNotes, mapClaudeToolName, mapEpochToolName, mapOperationType, matchPreauthorization, matchRuleLists, matchesHook, mentionsPluginRoot, mergeHeadlessPolicy, mergeRoles, mergeSchedulePatch, microsToUsd, modelEntriesPath, modelListCandidates, needsAllowlist, nextRunAt, noConfigOrigins, noManagedPolicy, noPlugins, normalizeModelEntry, normalizeTrigger, openArtifact, originOf, packFileName, packPlugin, parseClaudeSettingsHooks, parseClock, parseDate, parseFrontmatter, parseHooksConfig, parseHooksConfigVerbose, parseImportLine, parseModelEntry, parseModelList, parseRoleDefinition, parseScheduleDraft, parseSkillFrontmatter, parseTrigger, pendingImageTokens, persistFailureCode, persistParts, persistToolResults, persistedUsage, planPack, previewSkillImport, pricingFor, projectEntryForDisplay, pruneArtifacts, pruneAttachments, pruneRecordings, pruneSchedules, readEntryKey, readImageSize, readMarketplaces, readPluginAbout, readPluginIcon, readPluginManifest, readPluginRecords, readRecording, readSessionSurface, reclaimFtsSpace, redactLine, refreshOpenRouterMetadata, removeMarketplace, removeRecordings, removeRoleFile, removeSessionArtifacts, removeSessionAttachments, renderImportTree, renderProjectContext, renderSdkDeclaration, renderSelfIndex, repairSchedules, resolveArtifactRetention, resolveCodeModeWorker, resolveComplianceDirs, resolveEntrySource, resolveInWorkspace, resolveMarketplaceRef, resolveMentions, resolveMultimodalPolicy, resolvePolicyDirs, resolvePricingAt, resolveProjectRoot, resolveScheduleBackend, resolveSessionReference, resolveSessionVisibility, resolveSettings, resolveSkillDirs, resolveSource, resolveTar, resolveWorkspace, restoreParts, revealScopedProvider, roleScopedProvider, roleSourceLabel, ruleCovers, ruleFromString, ruleToString, runCode, runCommand, sanitizeArgNames, sanitizeCommand, sanitizeFtsQuery, sanitizePath, sanitizeToolOutput, saveModelEntries, scanInstructions, scanPluginDir, scanSkillDirs, searchMarketplaces, setDisplayCurrency, setImportGate, setPluginEnabled, setTrustGate, settingValueChoices, settingValueKind, settingWriteApply, settingWriteLayers, settingWriteTargets, skillIndexDescription, skillIndexResidency, skillIndexStats, sniffMediaType, splitFrontmatter, staticToolProvider, stripArtifactData, substitutePluginRoot, suggestRuleFromApproval, systemOpenArgv, systemPromptSegments, testModelEntry, toPosix, toolDefinitionTokens, toolMatches, toolTableTokens, totalTokens, traceSession, triggerPeriodMs, unescapeRuleContent, uninstallPlugin, unknownRoleSkills, unknownRoleTools, unloadedInstructionFiles, unsetUserSetting, updateMarketplace, updatePlugin, usdToMicros, validateSchedule, validateTrigger, validateWindow, withGoalCompression, withGoalPrompt, workspaceDisplayPath, writeSettingValue };
+export { ABOUT_DESC_MAX_CHARS, ABOUT_README_MAX_CHARS, AGENT_ROLE_DIAG_MODULE, ARTIFACT_MAX_TOTAL_BYTES, ARTIFACT_RETENTION_DEFAULTS, ATTACHMENT_MAX_TOTAL_BYTES, ATTACHMENT_RETENTION_DEFAULTS, type AcquireResult, type ActivePlugin, type AgentConfig, AgentInbox, AgentLoop, type AgentProvider, type AgentSite, type AgentSiteRef, AppearanceStore, type AppendMessageInput, ApprovalCache, type ApprovalDecision, type ArtifactOpenRefusal, type ArtifactRetention, type AskQuestionDeps, type AttachmentRetention, BLOCKED_TOOLS, BOARD_TOOL_NAMES, type BackendOptions, type BackendOutcome, type BackgroundTaskSource, type BaseOrigin, type BaseSlot, type BeginTurnInput, type BoardPending, BoardStore, type BoardTarget, type BreakdownInput, BudgetGuard, type BudgetGuardOptions, type BudgetInfo, type BudgetLevel, type BudgetOptions, type BudgetStatus, BudgetStore, type BudgetStoreOptions, type BuildFireArgvInput, type BuildIndexOptions, CHECKPOINT_MAX_TOTAL_BYTES, CLAUDE_EVENT_NAMES, CLAUDE_TOOL_NAMES, CODE_MODE_LIMITS, CODE_MODE_SDK_TAG, CONFIG_KEYS, CURRENT_CONFIG_VERSION, type CachedApproval, type CachedDecision, type CheckpointCapture, type CheckpointFile, CheckpointManager, type CheckpointManagerOptions, type CheckpointManifest, CheckpointStore, type CheckpointStoreOptions, type CheckpointSummary, type ClaudeHooksParseOptions, type CodeModeLimits, type CodeRequest, type CodeResult, CodeSandbox, type CommandHookConfig, type CommandHookResult, type CommandLoadOutcome, type CommandLoadSummary, type CommandResult, type CommandRunner, type CompactionResult, type CompiledRules, type ComplianceDirSpec, type ComplianceDirsSummary, ComplianceEngine, type ComplianceEngineInput, type ComplianceGate, type ComplianceHit, type ComplianceRule, type ComplianceRuleSource, type ComplianceSettings, type ComplianceVerdict, type CompressConfig, type CompressResult, type ConfigKeyEntry, type ConfigKeyKind, type ConfigKeyReason, type ConfigKeyWrite, type ConfigMigration, type ConfigOrigins, type ConfigValueCheck, type ConfigValueProblem, ContextCompressor, type ContextEngine, type CreateScheduleInput, type CreateSessionInput, DEFAULT_COMPLIANCE_ACTIONS, DEFAULT_COMPLIANCE_SETTINGS, DEFAULT_COMPRESSION_THRESHOLD, DEFAULT_GOAL_MAX_ROUNDS, DEFAULT_INBOX_CAPACITY, DEFAULT_MAX_HOLD_CHARS, DELEGATE_SESSION_SOURCE, type DelegateArgs, type DelegateConfig, DelegateManager, type DelegateTaskResult, type DeliveryResult, type DiagnoseOptions, type DiscoverOutcome, type DiscoveredFile, type DoctorReport, type DraftParse, EMPTY_RULES, EPOCH_DISK_LEDGER, type EntryProbeCode, type EntryProbeResult, EpochConfigSchema, type ExpandOptions, type ExtractOutcome, FTS_TABLES, FTS_TRIGGERS, type FallbackEvent, type FileSlots, type FileSourceKind, type ForkInput, type FrontmatterParse, type FrontmatterSplit, type FtsHealth, type FtsReclaim, type FtsSpace, type FtsTableHealth, GOAL_BLOCK_CODES, type GateAxis, type GateVerdict, type GenerateInput, type GenerateOutput, type Goal, type GoalBlockReason, type GoalClear, type GoalPhase, type GoalPromptView, type GoalRefusal, type GoalRoundResult, GoalService, GoalStore, type GoalToolDeps, type GoalWrite, HEADLESS_AUDIT_CODES, type HeadlessPolicy, type HookConfigEntry, HookManager, type HookManagerOptions, type HookMatcher, type HookSourceKind, type HookSourceStatus, type HookSourcesOptions, type HookSourcesSummary, type HooksParseOutcome, type MemoryManager$1 as IMemoryManager, INSTRUCTION_BUDGET_CHARS, INSTRUCTION_FILES, type SessionManager$1 as ISessionManager, type SkillSystem$1 as ISkillSystem, ImageLoadError, type ImageSize, type ImportDecision, type ImportGate, type ImportGoal, type ImportMessage, type ImportNode, type ImportPartsResult, type ImportSessionInput, type ImportSessionMeta, type ImportSessionResult, type ImportSkipReason, type ImportTodo, ImportTrustStore, type InstallDependency, type InstallOptions, type InstallOutcome, type InstallPreview, type InstallStep, type InstructionScan, type InstructionSource, type IsolationReason, type IsolationReport, type JsonSchemaDocument, LAUNCHD_LABEL_PREFIX, LOCK_HEARTBEAT_MS, LOCK_STALE_MS, type LastOpenSession, LastOpenSessions, type LayerOutcome, type LayerScalars, type LayerStatus, type LearningContext, type LearningResult, type LearningSkipReason, type LexiconLoadOutcome, type LifecycleOutcome, type ListCandidatesInput, type ListSessionsInput, type ListSessionsOutput, type LoadCommandsOptions, type LoadConfigOptions, type LoadKeybindingsOptions, type LoadKeybindingsResult, type LoadRolesOptions, type LoadedPlugin, type LockHolder, MARKETPLACE_DISPLAY_FIELDS, MARKETPLACE_FILE, MAX_AUDIT_ENTRIES, MAX_COMMAND_DEPTH, MAX_GOAL_MAX_ROUNDS, MAX_IMPORT_DEPTH, MAX_LAST_OPEN_SESSIONS, MAX_OBJECTIVE_CHARS, MAX_POST_CHARS, MAX_REASON_CHARS, MAX_RECENT_WORKSPACES, MODEL_ENTRIES_FILE, MODEL_GIVE_UP_THRESHOLD, MULTIMODAL_DEFAULTS, type ManagedPolicy, ManagedPolicyError, type ManagedSettings, ManagedSettingsSchema, type MarketplaceCatalog, type MarketplaceCategory, type MarketplaceDisplay, type MarketplaceDisplayField, type MarketplaceEntry, type MarketplaceOutcome, type MarketplaceRecord, type MarketplaceStatus, type MemoryConfig, type MemoryEntry, type MemoryImportRecord, type MemoryImportResult, MemoryManager, type MemoryManagerOptions, type MemoryNotice, type MemoryRemoval, type MemorySearchResult, type MemoryTarget, type MemoryWriteResult, type MentionPart, type MentionResolution, type Message, type MessageHit, type MessageRecord, type MessageSurface, type ModelCapability, ModelFailureTracker, type ModelMetaEntry, type ModelPricing, type MultimodalPolicy, NOMINAL_TOTAL_BYTES, NO_REVEALED_TOOLS, type NonInteractiveProbe, type OsTaskSnapshot, type OutputGuard, PACK_EXCLUDES, PERMISSION_AUDIT_CODES, PLUGIN_ICON_MAX_BYTES, PLUGIN_LAYOUT, PLUGIN_MANIFEST_FILE, PLUGIN_MANIFEST_KEYS, PLUGIN_NAME_PATTERN, PLUGIN_ROOT_ENV, PLUGIN_ROOT_TOKEN, PLUGIN_VISIBILITY, POLICY_DECISIONS, PROBE_VERSION, PROJECT_AGENTS_SUBDIR, PROVIDER_NO_CREDENTIAL, type PackFile, type PackLimits, type PackOutcome, type PackPlan, type PackPlanOutcome, type PermissionAuditCode, type PermissionAuditEntry, type PermissionAuditOutcome, type PermissionAuditScope, type PermissionAuditSnapshot, PermissionManager, type PersistFailureKind, type PersistedBudget, type PersistedPart, type PlanApprovalFn, type PlanEnterResult, type PlanModeDeps, PlanModeState, type PlanSettlement, type PluginAbout, type PluginArtifacts, type PluginAuthor, PluginAuthorSchema, type PluginCommandDir, type PluginCounts, type PluginDoc, type PluginHookFile, type PluginInventory, type PluginLoadOptions, type PluginManifest, type PluginPathRef, type PluginRecord, type PluginScope, type PluginSettingsFile, type PluginSourceType, type PluginStateReadOutcome, PluginStore, type PluginVisibility, type PolicyDirSpec, type PolicyDirsSummary, type PolicyLoadOutcome, type PolicyRule, PolicyRuleSchema, type PricingAt, type PricingOverride, type ProjectContext, type ProjectExtensionInventory, ProviderError, ProviderRouter, type ProviderStreamChunk, type ProviderToolCall$1 as ProviderToolCall, type ProviderWarning, type PruneResult, type QuestionAskFn, RECORDING_KEEP_RUNS, RECORDING_MAX_BYTES, ROLE_FRONTMATTER_SCHEMA, RUN_CODE_TOOL, type ReadMessagesInput, type ReadMessagesOutput, type RecentWorkspace, RecentWorkspaces, type RecordRunInput, type RecorderOptions, type RecoveryAction, type RegisterInput, type RegisterOutcome, type RegistrarOptions, type RegistrationPatch, type RepairOutcome, type ResolveMentionsOptions, type ResolveReferenceInput, type ResolveSettingsOptions, type ResolvedCompression, type ResolvedReference, type ResolvedSource, type ResponseFormat, type RestorePartsOptions, type RewindAction, type RewindDrift, type RewindFilePlan, type RewindOptions, type RewindOutcome, type RewindPreview, type RoleCreateFailure, type RoleCreateInput, type RoleCreateOptions, type RoleCreateOutcome, type RoleLoadOutcome, type RoleLoadSummary, type RoleMergeNotice, type RoleMergeResult, type RoleRemoveFailure, type RoleRemoveOptions, type RoleRemoveOutcome, type RoleScope, type RuleMatch, type RuleSuggestion, type RuleVerdict, type RunCodeFailure, type RunCodeInput, type RunCodeOutcome, type RunCodeToolDeps, type RunEstimateInput, type RunInput, type RunResult, type RunningSchedule, SANDBOX_COVERS, SANDBOX_EXCLUDES, SCALAR_KEYS, SCHEDULE_DEFAULTS, SCHEDULE_DEFAULT_ALLOWLIST, SCHEDULE_ISSUE_CODES, SCHTASKS_FOLDER, SEND_MESSAGE_TOOL, SESSION_MESSAGES_READ_TOOL, SESSION_MESSAGES_SEARCH_TOOL, SESSION_QUERY_TOOLS, SESSION_SEARCH_TOOL, SESSION_TRACE_TOOL, SETTINGS_LAYER_ORDER, SETTING_WRITE_KEYS, SETTING_WRITE_LAYERS, SKILL_ASSET_DIRS, SKILL_CREATE_TOOL, SKILL_EDIT_TOOL, SKILL_FILE, SKILL_PATCH_TOOL, SKILL_VIEW_TOOL, SKILL_WRITE_FILE_TOOL, SLASH_COMMANDS_DIAG_MODULE, type ScalarKey, type ScanInstructionsOptions, type ScheduleArgvRefusal, type ScheduleArgvResult, type ScheduleArgvWarning, type ScheduleBackend, type ScheduleCliEntry, type ScheduleDraftDeps, type ScheduleDrift, type ScheduleDriftKind, type ScheduleImportInput, type ScheduleInstallForm, type ScheduleIssue, type ScheduleIssueCode, type ScheduleLock, ScheduleRecorder, ScheduleRegistrar, ScheduleStore, type ScheduleValidation, type SchemaExport, type SearchHit, type SearchInput, type SearchMessagesInput, type SearchMessagesOutput, type SearchOutput, type SearchSessionsInput, type SelectionDeps, type SelfConnector, type SelfIndexInput, type SelfSettings, type Session, type SessionCandidate, type SessionHit, SessionManager, type SessionMentionDeps, type SessionMeta, SessionQueries, SessionReferences, type SessionSearchDeps, type SessionStats, type SessionSurface, type SessionTrace, type SessionVisibility, type SessionVisibilityInput, type SettingApply, type SettingApplyFacts, type SettingChain, type SettingFutile, type SettingLayer, type SettingStep, type SettingValue, type SettingValueKind, type SettingWriteFailure, type SettingWriteKey, type SettingWriteLayer, type SettingWriteOutcome, type SettingWriteRequest, type SettingWriteTarget, type SettingWriteTargetsOptions, type SettingsFile, SettingsFileError, SettingsFileSchema, type SettingsLayer, type SettingsResolution, type ShadowFinding, type ShadowKind, type Skill, type SkillDirSource, type SkillDirSpec, type SkillDirsSummary, type SkillImportConflict, type SkillImportDone, type SkillImportEntry, type SkillImportFailure, type SkillImportForm, type SkillImportOptions, type SkillImportPreview, type SkillImportResult, type SkillIndexEntry, type SkillIndexOptions, type SkillIndexResidency, type SkillIndexStats, SkillLearner, type SkillLearningProvider, type SkillMeta, type SkillStats, SkillSystem, type SkillSystemOptions, type SkillViewDeps, type SkillWriteDeps, type SteerSource, type StoredAppearance, type SubAgentRunner, type SubTask, type SubToolCaller, type SummarizeOutput, type SurfaceMessage, type SystemPromptParams, type SystemPromptSegments, TEAM_TOOL_NAMES, TOOL_SEARCH_TOOL, TaskNoticeTracker, TeamRegistry, type TodoItem, type ToggleOutcome, type ToolCall, type ToolConflict, type ToolGate, type ToolNameFidelity, type ToolNameLookup, ToolRegistry, type ToolRevealState, type ToolScope, type ToolSearchDeps, type ToolTableCost, type TraceInput, type TraceNode, TrackerDB, type TrustDecision, type TrustGate, type TrustGateOptions, TrustManager, type TurnRecord, type TurnTiming, UNSETTABLE_USER_KEYS, type UpdateScheduleInput, type UtilityModelInfo, type ValidateScheduleInput, type VersionCheck, Workspace, type WorkspaceFiles, type WorkspaceIssue, type WorkspaceIssueKind, acquireScheduleLock, addMarketplace, addUsage, admitArtifact, admitArtifacts, affectedPaths, approvalEntryFor, approvalRootFor, artifactLaunchArgv, artifactOpenRefusal, assertLevelAllowed, blockedRoleTools, buildContextBreakdown, buildFireArgv, buildFtsMatchQuery, buildSchemaExports, buildSystemPrompt, buildTrigramMatchQuery, builtinRoles, capabilityOfRef, checkConfigValue, checkEpochVersion, checkFtsHealth, checkShadowing, classifyPersistFailure, classifyProviderError, clearModelCache, coalesceRecording, codeModeWorkerPath, commandNameFromRelPath, compileRuleLists, compressionOptions, computeCost, computeCostMicros, computeExecHash, configKeyByPath, configKeyTable, countRules, createAllowAllGate, createAllowAllImportGate, createAskQuestionTool, createBoardTools, createCodeExecTool, createDelegateTool, createDenyAllGate, createDenyAllImportGate, createGoalTool, createImportGate, createMemoryTool, createPlanModeTools, createPluginScope, createRoleFile, createRoleScope, createRunCodeTool, createScheduleDraftTool, createSendMessageTool, createSessionMessagesReadTool, createSessionMessagesSearchTool, createSessionSearchTool, createSessionSearchTools, createSessionTraceTool, createSkillViewTool, createSkillWriteTools, createTeamTools, createTodoTool, createToolRevealState, createToolScope, createToolSearchTool, createTrustGate, currentEpochVersion, decideImport, decideTrust, defaultConfig, describeArtifactRefusal, describeBackgroundTask, describeHeadlessPolicy, describeIsolation, describeJsonError, diagnoseSchedules, discoverMarkdown, discoverModels, discoverProject, discoverySpec, displayAllows, displayCurrency, draftCommandLine, draftWidening, escapeRuleContent, estimateImageTokens, estimateRunTokens, estimateTokens, evaluateSelection, expandCommand, expandImports, explainSetting, extractArchive, findInstructionFiles, findProjectInstructions, findRole, formatBytes, formatSkillIndex, formatUsd, gateForTool, getCapability, getConfigIssues, getConfigOrigins, getImportGate, getTrustGate, grantedPathsFor, hasDedicatedExecContent, hasExecTierContent, hasPromptCaching, hasProviderCredentials, hasReadTierContent, hasUsableModel, imageFromBase64, imageFromPath, imagePartTokens, importParts, importSkills, installPlugin, instructionDirs, instructionNotices, intervalSlots, inventoryProjectExtensions, inventoryTotal, isBlockCode, isCodeModeDeferred, isEmptyRules, isGoalPhase, isNonInteractive, isReadOnlySubCall, isSettingWriteLayer, isTransientPersistFailure, isValidInterval, isValidPluginName, isWithinWindow, isWritableSettingKey, labelSlug, layerRank, listEntryModels, listRunningSchedules, listSessionCandidates, listWorkspaceFiles, loadCommandDefinitions, loadCommandFile, loadCommands, loadConfig, loadHookSources, loadKeybindings, loadLexiconDir, loadLexiconFiles, loadModelEntries, loadPlugins, loadPolicyFiles, loadPolicyRules, loadRoleDefinitions, loadRoleDir, loadedImports, localDateString, managedSwitchNotes, mapClaudeToolName, mapEpochToolName, mapOperationType, matchPreauthorization, matchRuleLists, matchesHook, mentionsPluginRoot, mergeHeadlessPolicy, mergeRoles, mergeSchedulePatch, microsToUsd, modelEntriesPath, modelListCandidates, needsAllowlist, nextRunAt, noConfigOrigins, noManagedPolicy, noPlugins, normalizeModelEntry, normalizeTrigger, offloadOldestImages, openArtifact, originOf, packFileName, packPlugin, parseClaudeSettingsHooks, parseClock, parseDate, parseFrontmatter, parseHooksConfig, parseHooksConfigVerbose, parseImportLine, parseModelEntry, parseModelList, parseRoleDefinition, parseScheduleDraft, parseSkillFrontmatter, parseTrigger, pendingImageTokens, persistFailureCode, persistParts, persistToolResults, persistedUsage, planPack, previewSkillImport, pricingFor, projectEntryForDisplay, pruneArtifacts, pruneAttachments, pruneRecordings, pruneSchedules, readEntryKey, readImageSize, readMarketplaces, readPluginAbout, readPluginIcon, readPluginManifest, readPluginRecords, readRecording, readSessionSurface, reclaimFtsSpace, redactLine, refreshOpenRouterMetadata, removeMarketplace, removeRecordings, removeRoleFile, removeSessionArtifacts, removeSessionAttachments, renderImportTree, renderProjectContext, renderSdkDeclaration, renderSelfIndex, repairSchedules, requestImageBytes, resolveArtifactRetention, resolveCodeModeWorker, resolveComplianceDirs, resolveEntrySource, resolveInWorkspace, resolveMarketplaceRef, resolveMentions, resolveMultimodalPolicy, resolvePolicyDirs, resolvePricingAt, resolveProjectRoot, resolveScheduleBackend, resolveSessionReference, resolveSessionVisibility, resolveSettings, resolveSkillDirs, resolveSource, resolveTar, resolveWorkspace, restoreParts, revealScopedProvider, roleScopedProvider, roleSourceLabel, ruleCovers, ruleFromString, ruleToString, runCode, runCommand, sanitizeArgNames, sanitizeCommand, sanitizeFtsQuery, sanitizePath, sanitizeToolOutput, saveModelEntries, scanInstructions, scanPluginDir, scanSkillDirs, searchMarketplaces, setDisplayCurrency, setImportGate, setPluginEnabled, setTrustGate, settingValueChoices, settingValueKind, settingWriteApply, settingWriteLayers, settingWriteTargets, skillIndexDescription, skillIndexResidency, skillIndexStats, sniffMediaType, splitFrontmatter, staticToolProvider, stripArtifactData, substitutePluginRoot, suggestRuleFromApproval, systemOpenArgv, systemPromptSegments, testModelEntry, toPosix, toolDefinitionTokens, toolMatches, toolTableTokens, totalTokens, traceSession, triggerPeriodMs, unescapeRuleContent, uninstallPlugin, unknownRoleSkills, unknownRoleTools, unloadedInstructionFiles, unsetUserSetting, updateMarketplace, updatePlugin, usdToMicros, validateSchedule, validateTrigger, validateWindow, withGoalCompression, withGoalPrompt, workspaceDisplayPath, writableConfigKeys, writeSettingValue };