@sema-agent/client-core 0.77.1 → 0.78.0

package/dist/notifications.d.ts

@@ -1,11 +1,3 @@
-/**
- * ⚠️ 调用方契约(交叉复审 [MED] 登记):cli 原版在渲染前有两条默认值回填——
- *   summary 缺省 ⇒ `Background task "${taskId}" ${status}`;status 非串 ⇒ 'unknown'(0.72.12 起;此前 'completed')。
- * 本纯函数不做回填(职责在 adapt() 输入侧),直接透传引擎原始 JSON 会渲出空 <summary>。
- * 落 adapt() 时必须先补齐这两个字段再调本函数。
- * 另注:<status> 段转义为**有意统一变更**(cli 原版曾不转义;2026-07-25 双侧统一为转义,
- * status 为受控枚举零实际影响,顺手关闭注入面)。
- */
 export interface TaskNotificationFields {
     taskId: string;
     status: string;
@@ -23,96 +15,33 @@ export interface TaskNotificationFields {
     resumable?: boolean;
     externalSource?: string;
 }
-/** 通知 user-turn XML 渲染(core task-notification 同形;external 帧开标签带 from= 属性)。 */
 export declare function renderTaskNotificationXml(n: TaskNotificationFields): string;
-/**
- * core 1.262.0 残局包([558]A/D)— 从 task_notification 帧派生残局显示行,与 core 进程内
- * renderResidual(core/task-notification.ts:75-86)**逐字节对齐**:先 `- tool target → outcome`
- * 步骤行,再 ONE `edited: path (×N), …` 行(editedFiles 折进 recent-steps,core 不铸独立
- * <edited-files> tag——别自创)。字段是 additive 的,老引擎没有 ⇒ []。返回裸串,转义由调用方按
- * 自己的面做(XML/Ink 行)。cli deriveNotificationResidualLines 的等价搬运。
- */
 export declare function deriveNotificationResidualLines(n: Record<string, unknown>): string[];
-/**
- * 引擎 task_notification 原始 payload → renderTaskNotificationXml 的入参(**含上面注释里那两条
- * 回填**:summary 缺省 ⇒ `Background task "<id>" <status>`;status 非串 ⇒ 'unknown',summary 改说 outcome unknown)。
- * task_id 空串/缺失 ⇒ null(RB-75 同族:空 id 会塌成 ':status' 共享桶互吞,无 id 的通知本就无意义)。
- * 字段名映射按 wire 真形:task_id/output_file/task_type/source 是 snake/wire 名,其余同名。
- */
 export declare function normalizeTaskNotification(n: Record<string, unknown>): TaskNotificationFields | null;
-/** 通知去重键——cli engineTaskNotificationDedupKey **逐字等价**(对抗复审抓的
- *  等价性破坏,0.1.1 修):无 seq 不追加段(与 seq:1 是不同键);仅 external 用
- *  `external:` 前缀;seq 收 number|string。格式:`[external:]taskId:status[:seq]`。 */
 export declare function taskNotificationDedupKey(n: {
     taskId: string;
     status: string;
     seq?: number | string;
     taskType?: string;
 }): string;
-/**
- * ⇄ B7(T2):同一把键的 **裸 wire 载荷** 入口 —— cli `upstreamBridge.engineTaskNotificationDedupKey`
- * 的等价物(入参是引擎 `task_notification` 帧的原始 payload:snake_case `task_id` / `task_type`)。
- *
- * 🔴 **不是第二份算法**:字段归一之后直接委托给上面那一个 `taskNotificationDedupKey`。
- * 两份手写算法正是这条键在 0.1.1 被 对抗复审抓到过的形(无 seq 追不追段的差异会让
- * 「重放去重」整条失效而两边代码看着都对);pure 门 B7 段对两个入口做**同键对拍**。
- *
- * 键形:`[external:]taskId:status[:seq]`。缺 `task_id` ⇒ 空 taskId 段(与 cli 逐字一致 ——
- * 空 id 的通知本就在 `normalizeTaskNotification` 那一层被丢弃,这里不额外加语义)。
- *
- * ⚠️ **P1-3(完成事件单一权威)未到货 ⇒ 只搬不删**:引擎给出 `completionId` 之后,这把
- * 「客户端按 taskId:status[:seq] 自己重算」的键才能换成「读引擎发的 id」。退役条件见
- * `compensations.ts` 的 T2 行。
- */
 export declare function taskNotificationDedupKeyFromWire(n: Record<string, unknown>): string;
-/**
- * ⇄ B7(T3):从**落盘转录**里的 `<task-notification>` 块反解去重键 —— #63 resume 回植的
- * **纯解析半场**(适配器实例的 `importLedgerFromTranscript` 与宿主的 resume 装载腿共用这一份)。
- *
- * 为什么要单独导出:cli 里这段解析有**两份**(`upstreamBridge.seedEngineTaskNotificationDedupFromTranscript`
- * 与包内 `WireToCcAdapterImpl.importLedgerFromTranscript`),两份的差异会让 resume 回植在某一侧
- * 静默失效。B7 把解析收成一份纯函数,两个消费口都调它;壳侧那份 shim 化后直接调
- * `bridgeAdapter().importLedgerFromTranscript(...)`。
- *
- * 🔴 键形必须是**无 seq** 的:落盘 XML 不带 seq,Monitor 的 `:seq` 批键形与之不同 —— 这正是
- * 「绝不误伤 Monitor 多批流」的判据(cli `taskNotificationResumeSeed` 单测双向钉的就是它)。
- *
- * ⚠️ **P1-3 到货后**:仍需回植(crash 窗口是客观存在的),但不必再解 XML —— 转录里会直接带
- * `completionId`。退役条件见 `compensations.ts` 的 T3 行。
- */
 export interface TranscriptNotificationSeeds {
-    /** 渲染去重键(`[external:]taskId:status`,**无 seq 段**)。 */
     renderedKeys: string[];
-    /** 跨通道记账键(裸 taskId;仅**非 external** 的终态 completed/failed/killed)。 */
     notifiedKeys: string[];
-    /** 解出的块数(= cli `seeded` 返回值)。 */
     seeded: number;
 }
 export declare function parseTranscriptNotificationSeeds(messages: ReadonlyArray<unknown>): TranscriptNotificationSeeds;
-/** 宿主队列条目的最小结构形(壳 QueuedCommand 的子集;本包只读这三个键)。 */
 export interface QueuedCommandLike {
     mode?: unknown;
     agentId?: unknown;
     value?: unknown;
 }
 export interface NotificationQueuePort {
-    /** 壳 = messageQueueManager.enqueuePendingNotification(无显式优先级 ⇒ 队列缺省 'later')。 */
     enqueuePendingNotification(command: {
         value: string;
         mode: 'task-notification';
     }): void;
-    /** 壳 = messageQueueManager.removeByFilter;返回被摘掉的条目(数量是判据)。 */
     removeByFilter(predicate: (cmd: QueuedCommandLike) => boolean): QueuedCommandLike[];
-    /**
-     * B7:`mode:'prompt'` 的 **isMeta** 回植(今天唯一的消费者 = plan_review 结局,
-     * `hitl/planReviewWire.ts`)。与上面那条是**不同的队列语义**(task-notification 走
-     * `<task-notification>` 通道;这条是一个 isMeta 的 prompt turn),所以是第二个动词而不是
-     * 给第一个加参数。
-     *
-     * 🔴 **可选**(`?`):既有宿主(壳 B2 起装的那份)不实现它照样满足接口 —— 加必填方法会让所有
-     * 已装配的宿主在类型层一起红,而这条动词只有一个消费者。缺席 ⇒ 计 miss + 该结局不回植
-     * (模型在 approve 之后原地不动),**不是**静默可接受的面,所以计 miss 而不是静默。
-     */
     enqueueMetaPrompt?(command: {
         value: string;
         mode: 'prompt';
@@ -121,47 +50,14 @@ export interface NotificationQueuePort {
         workload: string;
     }): void;
 }
-/** 宿主装配:壳侧 shim / web 宿主在**模块加载期**装(装之前的调用会计入 miss)。 */
 export declare function installNotificationQueuePort(port: NotificationQueuePort | null): void;
-/** 🔴 未注入队列口而发生的投递次数 —— 恒应为 0;>0 = 宿主装配漏了,通知已静默丢失。 */
 export declare function notificationQueuePortMisses(): number;
-/** 测试钩:清 port + miss 计数(不动台账,台账各有自己的 reset)。 */
 export declare function _resetNotificationQueuePortForTest(): void;
-/**
- * B1(frame-lane-matrix 三节定谳)— Path A 回声到达时丢弃同 run 的 pending 队列条目。
- * 双投机理:活跃 turn 内 Path B(workflow_complete/bg_notification/probe feeder →
- * enqueuePendingNotification)先入队,Path A(引擎 server-side steer-inject 的
- * task_notification 回声帧)随流到达——引擎侧模型已收到一遍;turn 收口 idle 排水若再
- * auto-submit 队列条目 = 模型二收同一份 XML。壳撤不回引擎侧注入(跨进程),但能在
- * drain 前把已被回声证实送达的同 run 队列条目丢掉。键空间 = 裸 taskId/runId(与
- * notifiedRunIds/cardEnqueuedRunIds 同域);条目匹配按队列 XML 的 <task-id> 标签
- * (enqueue 两族与 bridge 渲染同用 escapeXml,键形字节对齐)。仅主线程 task-notification
- * 条目(agentId undefined);用户输入/其他模式绝不触碰。
- */
-/**
- * B7:plan_review 结局回植(`hitl/planReviewWire.ts` 的唯一调用点)。走队列口的
- * `enqueueMetaPrompt` 可选动词 —— 口或动词缺席 ⇒ 计 miss(与 `port()` 同一个计数器,宿主
- * 只看 `hostPortMisses()` 一个数)并**返回 false**,调用方 fail-soft。
- *
- * 🔴 为什么不复用 `enqueuePendingNotification`:那条走的是 `<task-notification>` 通道(队列
- * 的 `task-notification` 模式,drain 时按通知语义处理);plan_review 结局是一个 **isMeta 的
- * prompt turn**。混用 = 结局被当成后台任务完成通知渲染,是「看起来送到了」的假绑定。
- */
 export declare function enqueuePlanReviewOutcome(value: string): boolean;
 export declare function dropQueuedNotificationsForRun(taskId: string): number;
-/**
- * Pre-seed the runId dedup WITHOUT enqueueing — the completion already reached the model in-band
- * (clay 2026-07-04 复审:模型用 TaskOutput 轮询拿到 workflow 终态并当轮总结完;引擎 completion inbox
- * 不知道"轮询已送达",下一次开流仍补发 workflow_complete —— 对模型是纯重复,还触发一轮"这是补发通知,
- * 无需重复"的空转)。终态在 turn 内经过壳的投影(TaskOutput workflow 终态卡 / 引擎 server-side 已
- * steer-inject 的 task_notification 帧)即预标记,Channel A 对同 runId 的补发直接丢弃。
- */
 export declare function markEngineWorkflowNotified(runId: string): void;
-/** 跨通道去重的**读**口(适配器 workflow_complete 臂的发射门;cli 同域)。 */
 export declare function isEngineWorkflowNotified(runId: string): boolean;
-/** 「这个 run 的完成卡已入队」的**写**口(cli 侧等价物 = 两个 enqueue 函数内的 `cardEnqueuedRunIds.add`)。 */
 export declare function noteWorkflowCompletionCardEnqueued(runId: string): void;
-/** 台账序列化面(`exportLedger`)—— 只读快照,顺序 = 插入序。 */
 export declare function listNotifiedRuns(): string[];
 export declare function listWorkflowCompletionCardsEnqueued(): string[];
 export declare function isWorkflowCompletionCardEnqueued(runId: string): boolean;
@@ -171,83 +67,29 @@ type WorkflowStatusProbe = (runId: string) => Promise<{
     summary: string;
 } | null>;
 export declare function outstandingWorkflowCount(): number;
-/** headless(-p)退出门用([1340] BGB 分化案):**可送达**的 outstanding 数——probe 未装
- *  (mock/离线)恒 0,print 驱动器不为永远等不到的通知悬置;probe 在装则 watcher 5s 节拍
- *  必然送达或 TTL 放弃(2h 上界=run 蒸发极端形,与 CC 等本地 bg 任务的无界形同族)。 */
 export declare function outstandingDeliverableWorkflowCount(): number;
 export declare function subscribeOutstandingWorkflows(listener: () => void): () => void;
-/**
- * 🔴 已**停止等待**的 outstanding 条目数(workflow + bg 合计,process-lifetime 只增)。
- * 消费方(footer / headless 退出前的收尾行)据此把「N 个后台任务已停止等待」与「都送达了」
- * 分开渲——H1:排队与放弃对消费方必须可分辨。additive:既有计数口的语义一字节不变。
- */
 export declare function outstandingAbandonedCount(): number;
-/**
- * 观测口:被**静默 return 掉**的投递次数(notif-02)。去重与丢失在行为上都是「不入队」,
- * 不记账就在观测上等价 —— 分成两个键是因为它们的正当性完全不同:
- *   · `bgDedupDropped` = 同 (taskId,seq,status) 键重复,**正当**(at-least-once 双投自免),恒可 >0;
- *   · `bgCrossChannelDropped` = 首周期已由别的通道送达而被压制,**正当但需可查**(seq 透传一旦
- *     回归,复活周期会伪装成首周期落进这一格 —— 这个数异常增长就是 seq 又丢了的信号);
- *   · `stuckTickResets` = 在飞 tick 超过 STUCK_TICK_RESET_MS 被强制复位的次数,**恒应为 0**;
- *     >0 = 有 probe 连 PROBE_TIMEOUT_MS 都没能截断它。
- *
- * 🔴 [2393] F-1 补两格 —— 上面三格全是 **enqueue 内部**的记账,而 watcher 收摊臂在到达 enqueue
- * **之前**就把台账条目删掉了:「复活周期被秒删」这条路径对上面三格 100% 不可见(立案时被点名当
- * 信号的 `bgCrossChannelDropped` 正是这样对它零判别力的)。删除动作要挣得,也要看得见:
- *   · `bgWatchRevivalPromoted` = 收摊臂靠 probe 实证「任务又在跑」把条目升到新周期的次数
- *     —— 正是修前被静默秒删的那一类;>0 说明 wire 的 seq 没到货,壳在自己补周期号;
- *   · `bgWatchCollectedUnprobed` = probe 未装(mock/离线)时按裸 id 黑名单**盲摘**的次数,
- *     这是唯一保留的无证据删除;>0 = 有完成周期在这类宿主上恒不可观察。
- */
 export interface NotificationDropCounters {
     bgDedupDropped: number;
     bgCrossChannelDropped: number;
-    /** 🔴 [2393] notif-F1:workflow 侧「已通知过」而被静默吞掉的投递次数(第三处漏网拼法)。
-     *  与 bg 两格同理:去重与误吞在行为上都是「不入队」,不记账就在观测上等价。恒可 >0(推送帧与
-     *  probe 链双投自免是正当的);**异常增长** = runId 铸法变了或两条链 id 不同域,真完成在被吞。 */
     workflowDedupDropped: number;
     stuckTickResets: number;
     bgWatchRevivalPromoted: number;
     bgWatchCollectedUnprobed: number;
 }
 export declare function notificationDropCounters(): NotificationDropCounters;
-/** liveClient 在构造会话 client 时注册(带正确 baseUrl/token/principal 的 workflows.get)。 */
 export declare function installWorkflowStatusProbe(probe: WorkflowStatusProbe): void;
 type BgTaskStatusProbe = (taskId: string) => Promise<{
     terminal: boolean;
     status: string;
 } | null>;
-/** 委派 prompt 取件口(行消费端建行/详情页兜底用)。未登记 ⇒ undefined(诚实缺席)。 */
 export declare function outstandingBgTaskPrompt(taskId: string): string | undefined;
 export declare function installBgTaskStatusProbe(probe: BgTaskStatusProbe): void;
-/**
- * bridge 在 Agent async_launched 回执(structured type:'agent')经过时登记。按 (taskId,seq) 幂等。
- *
- * 🔴 notif-02(两账分离):登记闸**不再查 `notifiedRunIds`**。那个集合是「模型通知去重」账
- * (哪次完成已经喂给模型了),不是「是否还要观察」账;两账混用的后果是 seq≥2 的复活周期
- * 永远登记不进来(`notifiedRunIds` 全文无 delete 站点,首周期一通知就是终身黑名单)。
- * 首周期若确已送达,由 watcher 的收摊臂在下一拍摘除(见 `tickWatchInner` bg 半场),
- * 代价是一次 no-op 遍历,而不是一整个完成周期的结构性缺席。
- *
- * 🔴 [2393] F-1:`seq` 缺席时这里仍然**按首周期解释,不在登记口猜周期号** —— 猜出来的周期号会
- * 把「已终局任务的回执重放」也升成新周期,方向相反地造出重复通知。周期号只在 watcher 那侧、
- * 拿到 probe 的「它又在跑」这个证据之后才前进(见 `tickWatchInner` 的收摊臂三档)。
- *
- * @param seq bg 子代生命周期号;wire 未带 ⇒ 按首周期(BG_FIRST_SEQ)解释,复活周期由 watcher 补。
- */
 export declare function registerOutstandingBgTask(taskId: string, description: string, prompt?: string, seq?: number): void;
 export declare function isOwnWorkflowRun(runId: string): boolean;
-/** 本壳亲手启动过的 workflow run 列表(Set 插入序 = 启动序;/workflows 命令的目标 run 选择用,
- *  cmd-workflows.tsx——fleet source 无行可选时的兜底 id 源)。 */
 export declare function listOwnWorkflowRuns(): string[];
-/**
- * CC-37(0.72.2,cli [7468] ②):只登 own 台账、不动 outstanding —— 给 adapter 的 workflow lane 门用:带 `workflowRunId`
- * 的 `task_progress` 帧**且**其父指向本会话见过的 Workflow 工具卡(own-run 正向证明)时,在为其铸行的那一拍就登记,
- * 不再等 run_workflow 回执;此前 fleet 行已渲 13 s 而 `listOwnWorkflowRuns()` 仍空。幂等;别的会话的 workflow 帧
- * (无本会话卡为父)**不登**。
- */
 export declare function noteOwnWorkflowRun(runId: string): void;
-/** bridge 在 run_workflow 回执(structured type:'workflow-run')经过时登记。幂等;已通知的不再登记。 */
 export declare function registerOutstandingWorkflowRun(runId: string): void;
 export interface EngineWorkflowCompletion {
     runId: string;
@@ -257,54 +99,22 @@ export interface EngineWorkflowCompletion {
 export declare function enqueueBgChildNotification(n: {
     taskId: string;
     status: string;
-    /** bg 子代生命周期号(SendMessage 复活即 +1;service seq 字段)。去重键必须含 seq——
-     *  revive 周期(seq≥2)与首周期同 (taskId,status),不带 seq 会被首周期键吞掉
-     *  =「续派后完成通知永不上屏」(clay 图2 案根因,core1.355 复验帧实锤 2026-07-20)。 */
     seq?: number;
     summary?: string;
 }): void;
 export declare function enqueueEngineWorkflowNotification(c: EngineWorkflowCompletion): void;
-/** 测试钩(B2 新增,壳侧原文件没有):清空全部通知台账 + probe 槽 + watcher。
- *  🔴 生产绝不调用 —— 台账是 process-lifetime 去重的唯一凭据,清了就会双投。 */
 export declare function _resetEngineTaskNotificationForTest(): void;
-/**
- * 测试钩:**驱动一拍** watcher(生产由 setInterval 驱动,外部无入口 ⇒ 护栏/TTL/deadline
- * 三条链在门里全不可达,notif-01/-02/-03 才会一路活到今天)。
- * @param nowMs TTL 判据的时钟注入(WATCH_TTL_MS 是 2h,不注入时钟就只能真等两小时)。
- * 🔴 生产绝不调用。
- */
 export declare function _tickWatchOnceForTest(nowMs?: number): Promise<void>;
-/**
- * 测试钩:覆写 watcher 时序常量(默认是 10s/60s 量级,门里等不起)。传 null 恢复生产值。
- * 🔴 生产绝不调用;覆写只影响 deadline 与强制复位门,不动 WATCH_INTERVAL_MS/WATCH_TTL_MS。
- */
 export declare function _setWatcherTimingForTest(o: {
     probeTimeoutMs?: number;
     stuckTickResetMs?: number;
 } | null): void;
-/** 该 objective 是否为 task-notification 自动提交 turn 的注入 XML(整体即通知,非提及)。 */
 export declare function isTaskNotificationObjective(objective: unknown): boolean;
-/**
- * 通知 turn → supplement 文案(非通知 turn → undefined,判别不扩散)。措辞英文、CC 报错语气
- * (事实 + 出路,不惊悚)。status 从 XML `<status>` 读:completed 用定稿句;其余终态如实带
- * status(通知可能报 failed/killed —— 谎称 completed 比不加更糟)。
- */
 export declare function taskNotificationDeliverySupplement(objective: unknown): string | undefined;
-/**
- * API-error 行文拆分(渲染层消费):尾部的 supplement 行(若在)分离出来渲 dim,main 保留原始
- * error 字面渲红。无 supplement 的行原样返回 —— 既有 API-error 渲染路径零改变。
- */
 export declare function splitApiErrorSupplement(text: string): {
     main: string;
     supplement?: string;
 };
-/** SSE 平铺 wire 形(server 1.280.0 http/server.js:6347-6355 直证;ownerScope/ownerSessionId 上 wire 前剥掉)。
- *  🔴 平铺形在 7.48.0 仍逐字成立:`dist/http/routes/fleet.js:146` =
- *     `send("hook_notice", { type:"hook_notice", ...hookNoticeWire(hn), ts })`(spread,不是 `notice:` 嵌套)。
- *  🔴 本形是**第一族**(`hook_decision_unavailable`)的平铺视图,**刻意不为第二族加宽**:
- *     两族只共用 `type`/`kind`/`event`/`ts`,而 `reason` 的**值域各自闭集**(同名不同义)。
- *     第二族的专有键走本文件内部视图 `HookFailureWireView`(不出包边界)—— 把两族的键混进同一个
- *     导出形,等于对外承诺一个「哪一族都不完全对」的形,消费端读哪一位都得再猜一次 kind。 */
 export interface HookNoticeWire {
     type?: unknown;
     kind?: unknown;
@@ -314,13 +124,11 @@ export interface HookNoticeWire {
     ts?: unknown;
 }
 export type HookNoticeReason = 'no_content' | 'unparsed' | 'skipped';
-/** ActiveGoal.lastNotice 的形(壳 state/AppStateStore.ts 同步声明)。 */
 export interface GoalHookNotice {
     reason: HookNoticeReason;
     detail?: string;
     at: number;
 }
-/** 判定结果:ok=true 才交给宿主写 store;drop 原因供宿主打 SEMA_DEBUG 档(壳侧文案不变)。 */
 export type HookNoticeVerdict = {
     ok: true;
     notice: GoalHookNotice;
@@ -332,53 +140,27 @@ export type HookNoticeVerdict = {
     event?: string;
     reason?: HookNoticeReason;
 };
-/**
- * hook_notice 帧的判定本体(壳 ingestHookNoticeFrame 的判定半场逐字等价)。
- * 🔴 归属镜像在**这里**做而不是在 fleetClient 里做 —— #105 变异普查(F3)定谳过:分发条件留在
- * fleetClient 时,离线门只能 grep 源码,而 grep 对「把 'hook_notice' 改成 'hook_noticeZZZ'」
- * 这类变异因注释碰撞+子串命中恒绿。提到这里后离线门直接**行为测本函数**。
- */
 export declare function classifyHookNoticeFrame(frame: unknown, opts: {
     sessionScoped: boolean;
     now?: number;
 }): HookNoticeVerdict;
-/** 判别口:是不是 hook_notice 帧(宿主 fleet applyFrame 的分发条件;不是则继续走别的臂)。 */
 export declare function isHookNoticeFrame(frame: unknown): boolean;
-/**
- * 「Last check」行的诚实文案([1790] 措辞纪律:「本轮未能评估,已放行」方向;detail 是 server
- * 结构化日志同源的机器话,dim 展示原文比意译更可追责)。
- */
 export declare function hookNoticeLastCheckText(n: GoalHookNotice): string;
-/** footer 通知条文案前缀(测试锁字面;宿主拼 ` (${reason})`)。 */
 export declare const HOOK_NOTICE_WARN_PREFIX = "Goal check: couldn't evaluate this turn \u2014 proceeded";
-/** 机器可判的故障形(dist 逐字闭集)。 */
 export type HookFailureReason = 'exit_nonzero' | 'timeout' | 'spawn_failed' | 'bad_json';
-/** 条目类型 —— 没有它,`hookName` 是命令还是 URL 还是提示词全靠猜(dist 逐字闭集)。 */
 export type HookEntryType = 'command' | 'http' | 'prompt' | 'agent';
-/** 宿主写 store / 渲横幅的形(与 {@link GoalHookNotice} 平级,但**不是**同一件事)。 */
 export interface HookFailureNotice {
-    /** 哪个 hook 事件(`PreToolUse` / `Stop` / …)。开集:server 不闭这一位。 */
     event: string;
     reason: HookFailureReason;
-    /** hook 身份(server 侧 `statusMessage` 优先,否则 command / url / prompt),已脱敏 + 有界。 */
     hookName: string;
     entryType: HookEntryType;
-    /** 🔴 **超时 / spawn 失败没有退出码 ⇒ 缺席**(绝不铸 0 那种看着合法的假读数)。 */
     exitCode?: number;
-    /** 工具事件才有(PreToolUse/PostToolUse/PostToolUseFailure);非工具事件缺席。 */
     toolName?: string;
-    /** hook 的 stderr 摘要(server 已脱敏 + 截断;本包边界再兜底一次)。空 ⇒ 缺席。 */
     stderr?: string;
     detail?: string;
     at: number;
 }
-/**
- * 观测帧自由文本上限 —— 与 server `MAX_HOOK_NOTICE_TEXT_CHARS`(`fleet/fleet-bus.d.ts`)同值。
- * 🔴 server 已截过一遍(那一遍拿得到原文,是**承重**的);本包这一遍是**边界兜底**,挡住忘了截断的
- *    未来生产者把一条无界流灌进单行横幅。幂等:输出恒 ≤ 上限。
- */
 export declare const MAX_HOOK_NOTICE_TEXT_CHARS = 512;
-/** 第二族的判定结果。drop 原因供宿主打 SEMA_DEBUG 档。 */
 export type HookFailureVerdict = {
     ok: true;
     failure: HookFailureNotice;
@@ -387,21 +169,6 @@ export type HookFailureVerdict = {
     drop: 'not-hook-notice' | 'unknown-kind' | 'not-session-scoped' | 'unknown-reason' | 'unknown-entry-type' | 'no-hook-name';
     kind?: string;
 };
-/**
- * `hook_non_blocking_failure` 帧的判定本体(#281 的客户端半场)。
- *
- * 🔴 **与 {@link classifyHookNoticeFrame} 是两个口,不是一个口的两条臂**:两族的载荷形不同
- * (那族出 {@link GoalHookNotice},本族出 {@link HookFailureNotice}),把它们塞进同一个返回联合会
- * **破坏既有消费端**(现在 `v.ok` 之后直接读 `v.notice` 的写法要全部改窄化)。分口 ⇒ 姊妹口的行为
- * **逐字节不变**(它对本族仍报 `unknown-kind`,常驻套对这一格有钉),宿主按 `kind` 分派一次即可。
- *
- * 🔴 **闭集位一律「不认就丢」,绝不折成某一档**:与姊妹族「表外 reason 归一到 `skipped`」刻意不同 ——
- * 那一族的 `skipped` 有真兜底语义(「跳过了」),本族**没有**「兜底故障形」这种东西,把一个没见过的
- * 词折成 `exit_nonzero` 就是替引擎编一个它没说过的故障。
- *
- * 🔴 `hookName` 缺席即丢:一条「某个 hook 坏了、但不知道是哪个」的横幅,用户拿它什么都做不了,
- * 只会制造焦虑 —— 而 server 侧这一位是**必填**,缺席意味着这不是一帧合规的本族帧。
- */
 export declare function classifyHookFailureFrame(frame: unknown, opts: {
     sessionScoped: boolean;
     now?: number;