@sema-agent/client-core 0.40.0 → 0.42.0

package/dist/attachmentsWireCaps.js

@@ -29,7 +29,7 @@
  *     false」—— 对这一族,发 `false` 是违约(核心根本没有「显式关」这个语义位),所以本模块对
  *     它们**永不产出 false**:OFF ⇒ 键不出现。
  *
- *  ② **explicit-false 族**(2 员:agentListing / skillsListing):
+ *  ② **explicit-false 族**(3 员:agentListing / skillsListing / **backgroundTasks**):
  *     它们在 core 里是 **DEFAULT-ON**,SDK 头注写死「`agentListing`/`skillsListing` 是 core
  *     DEFAULT-ON —— **explicit false 才关**(1.254 起 false 真透传;更老 server 静默丢)」。
  *     于是「删键」在这一族上的含义是**保持开着**,而不是关掉。旧的 `AttachmentsSpec` 把全部键
@@ -37,6 +37,29 @@
  *     路径可以关闭**(不是「难关」,是类型层封死)。本批把这两键的类型放宽成 `boolean` 并给出
  *     产出 `false` 的路径。
  *
+ * ══ 🔴 [4982] 候选①(P0-KPI,0.42.0)—— **第三员漏族:`backgroundTasks`** ════════════════════
+ *
+ * core **5.12.0 (BREAKING)** 把 `attachments.backgroundTasks` 与 `agentListing`/`skillsListing`
+ * **同批**翻成 DEFAULT-ON(core `types.d.ts` 逐字:「Post-compact background-task restatement —
+ * DEFAULT ON since 5.12.0 (**boolean, not `true`**: explicit `false` is the opt-out; **same contract
+ * as the listing family below**)」)。三兄弟同批翻转,本模块**跟修了后两个、漏了第一个** ——
+ * `backgroundTasks` 一直留在 ① 族(off = 删键,永不发 false)。
+ * 后果是这个旋钮上最坏的一种失效:`SEMA_ATTACHMENTS=off`(文件自称「真·全关」)对这一位与
+ * **什么都不配**逐字节同效(两条路都不发这个键 = 都是「开」),**且零报错** —— 用户以为关掉了,
+ * 附件照进上下文,没有任何一处会说出来。与 ② 族当初那个洞是同一个病形的第三例。
+ *
+ * ── 修法:把「能不能显式打开」与「能不能显式关掉」拆成**两条正交的轴** ────────────────────────
+ * `backgroundTasks` 同时住两族,这不是分类含糊,这**就是**它的契约:
+ *   · **轴 A(可显式开)** = `full` 会全开的那 7 员 —— `backgroundTasks` 在内,**membership 不动**;
+ *   · **轴 B(可显式关)** = core DEFAULT-ON 的 3 员 —— `backgroundTasks` 新入。
+ * 只把它整个搬进 ② 族(= 从轴 A 里删掉)是**错的修法**,两条理由都是硬的:
+ *   ① `full` / `default` / `+backgroundTasks` 三条既有路会当场少发一个 `backgroundTasks: true`
+ *      —— 对 core ≥5.12.0 行为等价(默认就是开),但对**更老引擎**那是真的从「开」变成「关」,
+ *      而本模块手里没有 server 版本这个量(见下面 §能力边界),没资格替用户做那个降级;
+ *   ② 空 env 的默认产出 `{backgroundTasks: true, toolsDelta: true}` 是 [487]② CC-parity 那一对的
+ *      字面承诺,删掉它就是把「默认逐字节不变」这条本模块的立身纪律自己破了。
+ * ⇒ 本批**只加一条出路**(`off` 与 `-backgroundTasks` 产出 `false`),其余取值逐字节不变。
+ *
  * ── env 面(`SEMA_ATTACHMENTS`)的取值语法,以及为什么选这一种 ────────────────────────────────
  * 目标是「**默认行为逐字节不变** + 有路可关 DEFAULT-ON 两键」,所以选了**在既有值上加逗号 token
  * 列表**,而不是新开一个 env:
@@ -45,8 +68,9 @@
  *   · 逗号 token 列表对**存量取值零影响**:`unset` / `full` / `all` / off 拼法四种老写法解析结果
  *     逐字节不变(FIX7 段 ⑤ 有正面钉),新语法只在用户真写了逗号 token 时才被触发。
  * 语法(逗号分隔,大小写不敏感,允许空白):
- *   · `off|0|false|no|none`(整值)     ⇒ **真·全关**:literal-true 族一个不发(那一族的 off 就是
- *                                        删键)+ DEFAULT-ON 两键发 `false`。
+ *   · `off|0|false|no|none`(整值)     ⇒ **真·全关**:只可显式开的那一族一个不发(它们的 off 就是
+ *                                        删键)+ DEFAULT-ON **三键**(agentListing / skillsListing /
+ *                                        backgroundTasks)发 `false`。
  *     🔴 对抗复审 [medium](2026-08-07)判的真病:这一支此前直接 `return undefined`(不发字段),
  *     而「不发字段」对 DEFAULT-ON 两键的含义**恰恰是保持开着** —— 一个叫 off 的总开关关不掉十件里
  *     的两件,且用户没有任何办法察觉。旧行为在 <1.254 的 server 上与新行为**逐字节等价**(那些
@@ -60,8 +84,9 @@
  *   · `full` / `all`                   ⇒ literal-true 族 7 员全开(**不含** DEFAULT-ON 两键 ——
  *                                        不发 = 保持 core 默认开,壳不替 core 做那个决定)
  *   · `default`                        ⇒ CC-parity 那一对(显式写出「默认」这个意思)
- *   · `<key>` / `+<key>`               ⇒ 单点打开一个 literal-true 族成员
- *   · `-agentListing` / `-skillsListing` ⇒ 产出 **`false`**(explicit-false 族唯一的关法)
+ *   · `<key>` / `+<key>`               ⇒ 单点打开一个「可显式开」族成员(轴 A 的 7 员)
+ *   · `-agentListing` / `-skillsListing` / `-backgroundTasks` ⇒ 产出 **`false`**(DEFAULT-ON 三键
+ *                                        唯一的关法;`-backgroundTasks` 是 [4982] 候选① 补的那条)
  *   · `todoReminderMode=baseline|off`  ⇒ 取值型键
  * 🔴 未登记 token / 对 literal-true 族用 `-` / todoReminderMode 取闭集外的值 ⇒ **fail-loud 抛错**。
  *    静默忽略是这条链上最坏的失效形:用户以为自己关掉了 agentListing,而请求照发、附件照进上下文,
@@ -88,10 +113,20 @@ export const ATTACHMENTS_SPEC_KEYS = [
     'agentListing',
     'skillsListing',
 ];
-/** ② 族(core DEFAULT-ON,explicit false 才关)。 */
-export const ATTACHMENTS_DEFAULT_ON_KEYS = ['agentListing', 'skillsListing'];
-/** ① 族里 `full` 会全开的那 7 员(`todoReminderMode` 是取值型,不搭 full 的车)。 */
-const LITERAL_TRUE_KEYS = [
+/**
+ * **轴 B —— 可显式关**(core DEFAULT-ON,`false` 才是关;`-<key>` 与总开关 `off` 的作用面)。
+ * 🔴 [4982] 候选①(0.42.0):`backgroundTasks` 补入 —— core 5.12.0 与另两员**同批**翻 DEFAULT-ON,
+ *    本模块当时只跟修了两员。这张表**不是** ① 族的补集(`backgroundTasks` 两族兼属,见 AttachmentsSpec
+ *    上的键注与文件头注的「两条正交的轴」段)。
+ */
+export const ATTACHMENTS_DEFAULT_ON_KEYS = ['agentListing', 'skillsListing', 'backgroundTasks'];
+/**
+ * **轴 A —— 可显式开**:`full` 会全开的那 7 员(`todoReminderMode` 是取值型,不搭 full 的车)。
+ * 🔴 `backgroundTasks` **留在本表**([4982] 候选① 的取舍,理由见文件头注):把它从这里删掉会让
+ *    `full`/`default`/`+backgroundTasks` 三条既有路少发一个 `true`,对 core <5.12.0 是真的从
+ *    「开」变成「关」,而本模块手里没有 server 版本这个量。
+ */
+const OPT_IN_KEYS = [
     'todoReminder',
     'changedFiles',
     'planModeReminder',
@@ -100,9 +135,15 @@ const LITERAL_TRUE_KEYS = [
     'toolsDelta',
     'mcpInstructions',
 ];
+/**
+ * **只可显式关、不可显式开**的那两员(轴 B ∖ 轴 A)。`+agentListing` 这类写法的 fail-loud 判据
+ * 锚在**本表**而不是整个轴 B —— 锚轴 B 会把 `+backgroundTasks` / `full` 一起误拒([4982] 候选①
+ * 修复批的判别力所在:两条轴各判各的,不许拿一条去代另一条)。
+ */
+const DEFAULT_ON_ONLY_KEYS = ['agentListing', 'skillsListing'];
 /** CC-parity 默认对(TOC live 路径,[487]②)。 */
 const DEFAULT_PAIR = ['backgroundTasks', 'toolsDelta'];
-const _attachmentsKeyPins = [true, true, true, true];
+const _attachmentsKeyPins = [true, true, true, true, true, true];
 void _attachmentsKeyPins;
 const TODO_REMINDER_MODES = ['baseline', 'off'];
 /** fail-loud 的统一措辞:说清**哪个 token 坏了**、以及合法形是什么(判词要指得出下一步)。 */
@@ -156,7 +197,7 @@ export function attachmentsForRequest(env = hostEnv()) {
             if (!isDefaultOnKey(key)) {
                 refuse(token, `"${key}" belongs to the literal-true family whose OFF is "delete the key", not "send false" ` +
                     '(core wire contract, board [479] ask-2) — simply do not turn it on. ' +
-                    'Only the core DEFAULT-ON keys (agentListing / skillsListing) accept an explicit false');
+                    `Only the core DEFAULT-ON keys (${ATTACHMENTS_DEFAULT_ON_KEYS.join(' / ')}) accept an explicit false`);
             }
             spec[key] = false;
             continue;
@@ -174,7 +215,10 @@ export function attachmentsForRequest(env = hostEnv()) {
         const key = canonicalKey(lhs.startsWith('+') ? lhs.slice(1) : lhs);
         if (key === undefined)
             refuse(token, 'unknown attachments key');
-        if (isDefaultOnKey(key)) {
+        // 🔴 判据锚 `DEFAULT_ON_ONLY_KEYS`(轴 B ∖ 轴 A),**不是**整个轴 B:0.42.0 起
+        //    `backgroundTasks` 两族兼属,拿轴 B 判会把 `+backgroundTasks` 一起误拒(而它在
+        //    `full` 里本来就开得出来,拒它等于同一件事有两个答案)。
+        if (isDefaultOnOnlyKey(key)) {
             refuse(token, `"${key}" is core DEFAULT-ON — turning it "on" is a no-op that would send a redundant true; ` +
                 `use "-${key}" to turn it OFF`);
         }
@@ -184,7 +228,8 @@ export function attachmentsForRequest(env = hostEnv()) {
     }
     return spec;
 }
-/** 总开关 off 的产出:literal-true 族一个不发(删键即关)+ DEFAULT-ON 两键显式 `false`。 */
+/** 总开关 off 的产出:只可显式开的那族一个不发(删键即关)+ DEFAULT-ON **三键**显式 `false`
+ *  ([4982] 候选①:`backgroundTasks` 从 0.42.0 起真的在这条路上被关掉)。 */
 function allDefaultOnOff() {
     const out = {};
     for (const k of ATTACHMENTS_DEFAULT_ON_KEYS)
@@ -193,7 +238,7 @@ function allDefaultOnOff() {
 }
 function allLiteralTrue() {
     const out = {};
-    for (const k of LITERAL_TRUE_KEYS)
+    for (const k of OPT_IN_KEYS)
         out[k] = true;
     return out;
 }
@@ -206,9 +251,14 @@ function splitAssign(token) {
 function canonicalKey(lower) {
     return ATTACHMENTS_SPEC_KEYS.find(k => k.toLowerCase() === lower);
 }
+/** 轴 B:可显式关(`-<key>` 的合法作用面)。 */
 function isDefaultOnKey(k) {
     return ATTACHMENTS_DEFAULT_ON_KEYS.includes(k);
 }
+/** 轴 B ∖ 轴 A:只可关不可开(`+<key>` 的 fail-loud 作用面)。 */
+function isDefaultOnOnlyKey(k) {
+    return DEFAULT_ON_ONLY_KEYS.includes(k);
+}
 /** 单 token 形的历史回落判据(见 `attachmentsForRequest` 里那段注释)。 */
 function isKnownToken(token) {
     if (token === 'full' || token === 'all' || token === 'default')

package/dist/classifierVerdictWire.d.ts

@@ -7,31 +7,6 @@
  * 执行半场、判定走本包,是安全的拆缝(B6 T35/T36/T44 同款「判定半场搬入」姿势)。
  * 逐字纪律:CLASSIFIER_DENY_SIGNATURE / NOTICE_REASON_MAX(80)/ 通知行三段格式一字节不改。
  */
-/**
- * src/sema/classifierVerdictWire.ts — auto-mode 分类器裁决帧的壳侧消费(分类器批3 壳半场,[907])。
- *
- * WIRE 形状(gap-check 2026-07-16 实勘,core 1.279 dist 亲核):
- *   引擎侧分类器 block(core hooks.js runToolGate)→ decision = deny + decisionReason:"classifier",
- *   permissionDenied 钩子收 source:"classifier"(server 1.209 只作 metrics 计量,不出独立 deny 帧)——
- *   壳能看见的唯一 wire 事实 = `tool_end` 帧:
- *     { type:'tool_end', isError:true, output: [{type:'text', text:'<system-reminder>\n
- *       auto-mode classifier blocked this call[: <reason>|: [<category>]]\n</system-reminder>'}] }
- *   (core hooks.js L138 deny message 逐字 + formatHookFeedback 包 system-reminder;
- *    agent-loop createErrorToolResult 落 content 数组;runtask toolOutputFrom 原样上 wire。)
- *   ⇒ 消费面按此签名结构性识别,等价于「deny 帧带 source:'classifier'」的判定(签名字符串是
- *   core 的机器产文面,非模型作文——模型 echo 不会以该签名做 tool_end 错误体开头)。
- *
- * 🔴 fail-soft 铁律:识别不中一律静默走原路,绝不伤害事件流。
- * 🔴 UNTRUSTED:reason 为分类器(模型)产文,只渲染绝不回喂;通知行截断 ≤80(207 同款)。
- */
-/**
- * 🟢 B8 ALLOW 清单登记(REF-CC-域词表-05,属主=client-core 规范重构轮,到期复议=core 改这句
- * deny message 文案时或 2026-Q4 复审以先到者为准):文本匹配 + 非文本结构性合取前置
- * (`ev.type==='tool_end' && ev.isError===true`,见 `classifierDenyFromToolEnd`)。同批同表的
- * 另两处:`detachWire.ts` `DETACH_DURABLE_OFF_400_ANCHOR`(server 契约话)、
- * `subagent/engineTaskHandleWire.ts` `STOP_CONFLICT_CODES`(SDK typed 缺席回落)——三处互指,
- * 理由逐条写在各自站点。
- */
 /** core hooks.js 分类器 deny message 的机器签名(逐字锚;lockstep:core 改文案这里必须跟)。 */
 export declare const CLASSIFIER_DENY_SIGNATURE = "auto-mode classifier blocked this call";
 export interface ClassifierDenyVerdict {

package/dist/classifierVerdictWire.js

@@ -32,6 +32,7 @@
  * `subagent/engineTaskHandleWire.ts` `STOP_CONFLICT_CODES`(SDK typed 缺席回落)——三处互指,
  * 理由逐条写在各自站点。
  */
+import { unwrapSystemReminder } from './systemReminderTag.js';
 /** core hooks.js 分类器 deny message 的机器签名(逐字锚;lockstep:core 改文案这里必须跟)。 */
 export const CLASSIFIER_DENY_SIGNATURE = 'auto-mode classifier blocked this call';
 /** 通知 reason 段截断(CC 207 L696763 同款 80 → 79+…)。 */
@@ -52,11 +53,22 @@ function textFromWireOutput(output) {
         .filter((t) => t !== undefined);
     return texts.length > 0 ? texts.join('\n') : undefined;
 }
-/** 去 <system-reminder> 包裹(formatHookFeedback 逆变换;不包裹则原样)。 */
-function unwrapSystemReminder(text) {
-    const m = /^\s*<system-reminder>\s*\n?([\s\S]*?)\n?\s*<\/system-reminder>\s*$/.exec(text);
-    return m ? m[1] : text;
-}
+/**
+ * core 分类器 deny 的**三个**铸点(core 5.52.0 dist 逐字枚举,候选③ [4974]):
+ *   ① `core/hooks.js:606`                    —— 基础形;
+ *   ② `core/runner/prepare-task.js:3103/3192` —— 继承自祖先层形;
+ *   ③ `core/runner/prepare-task.js:3023`      —— 「批准过的编辑」在祖先层被拦形。
+ * 三者尾巴同形:`: ${reason}` 或 `: [${category}]`(都没有时整条到此为止)。
+ *
+ * 🔴 **顺序即语义**:① 是 ② 的**前缀**,短的排在后面 —— 反过来的话 ② 会被 ① 蒙对,而 `tail` 变成
+ * ` at an inherited ancestor layer: …`,不以 `': '` 开头 ⇒ **reason 整条丢失**(修前实况)。
+ * 🔴 逐字锚,不做模糊匹配(B8 ALLOW 登记的既有纪律):core 改文案这里必须跟车。
+ */
+const CLASSIFIER_DENY_FORMS = [
+    'auto-mode classifier blocked the approved edit at an inherited ancestor layer',
+    'auto-mode classifier blocked this call at an inherited ancestor layer',
+    CLASSIFIER_DENY_SIGNATURE,
+];
 /**
  * 结构性识别一张 tool_end 帧是否为分类器 deny 裁决帧。
  * 判定 = isError:true ∧ 错误体(去包裹后)以 core 机器签名开头。识别不中 ⇒ undefined(原路)。
@@ -67,10 +79,18 @@ export function classifierDenyFromToolEnd(ev) {
     const raw = textFromWireOutput(ev.output);
     if (raw === undefined)
         return undefined;
+    // 件⑥([4974]):剥壳走**单一闸口** —— core ≥5.46 的开标签恒带 `mark="…"`,而这里原来锚的是
+    // 裸开标签 ⇒ 恒剥不掉 ⇒ 下面的 startsWith 恒不成立 ⇒ 整条 auto-deny 呈现面静默失效。
+    // 口径与另一座位(`subagent/engineDelegatedPrompt`)共用一份,见该模块头注。
     const message = unwrapSystemReminder(raw).trim();
-    if (!message.startsWith(CLASSIFIER_DENY_SIGNATURE))
+    // 🔴 前缀**不是**语法(七审 finding③):命中之后还要看**边界**。core 的铸点尾巴只有两种形 ——
+    //    到此为止,或紧跟 `': '`(reason / `[category]` 都走这一个分隔)。少了这条,
+    //    `…ancestor layerX` 这类近似串也会被判成分类器裁决,而那条路径会 `markEnded` + 摘 HOLD +
+    //    写 Recent Denials + 用裁决原文覆盖渲染 —— 任何能产出工具错误正文的工具都能伪造。
+    const form = CLASSIFIER_DENY_FORMS.find((f) => message.startsWith(f) && (message.length === f.length || message.startsWith(': ', f.length)));
+    if (form === undefined)
         return undefined;
-    const tail = message.slice(CLASSIFIER_DENY_SIGNATURE.length);
+    const tail = message.slice(form.length);
     const reason = tail.startsWith(': ') ? tail.slice(2).trim() : undefined;
     return { message, ...(reason !== undefined && reason.length > 0 ? { reason } : {}) };
 }

package/dist/engineAgentPanelStore.js

@@ -62,26 +62,115 @@ export function publishEngineAgentPanelEvent(ev) {
         }
         return;
     }
-    // Buffered (panel not mounted yet / temporarily unmounted). Ticks COALESCE per taskId (only the
-    // latest rollup matters — usage is cumulative), so lifecycle events ('end'/'sweep') are never the
-    // ones squeezed out by a long unmount (adversarial review w0zwpa251 #4: dropping a buffered 'end'
-    // left a row running forever).
-    if (ev.kind === 'tick') {
-        const i = buffer.findIndex(b => b.kind === 'tick' && b.taskId === ev.taskId);
+    // Buffered (panel not mounted yet / temporarily unmounted).
+    //
+    // Two event CLASSES, and every buffering rule below keys off the class (not off one kind):
+    //   · PROGRESS ('tick' / 'fleet-row') — cumulative rollups off the two live lanes. Only the latest
+    //     one per taskId carries information, so they COALESCE per (kind, taskId) and they are the ones
+    //     that yield when the buffer is full.
+    //   · LIFECYCLE ('end' / 'sweep') — each one is a distinct fact that settles a row. They are never
+    //     the ones squeezed out by a long unmount (adversarial review w0zwpa251 #4: dropping a buffered
+    //     'end' left a row running forever).
+    //
+    // 🔴 [F4957-2] (0.41.0) the full-buffer arm used to look ONLY for a 'tick' to evict and then pushed
+    // UNCONDITIONALLY even when it found none — so a stream carrying no ticks at all (the 'fleet-row'
+    // lane is exactly that: background subagents never reach the panel through 'task_progress', see the
+    // fleet-row arm's own header) grew the buffer without bound. MAX_BUFFER is a memory bound on
+    // UNTRUSTED wire volume; it has to hold for every kind mix, not just the one the first version had
+    // in mind.
+    // Adjacent 'sweep' dedup. A sweep settles every row the consumer still has running and its own doc
+    // calls it idempotent, so a sweep whose immediate predecessor is a sweep is a strict no-op — nothing
+    // happened in between that it could settle differently. Dropping it is not a micro-optimisation: a
+    // long unmount publishes one sweep per turn, and 200 of them fill the buffer with pure lifecycle
+    // events, after which every post-barrier progress event has to yield (that is the other half of the
+    // bounded policy) — a subagent that starts at that point would replay as "still settled", forever.
+    if (ev.kind === 'sweep' && buffer.length > 0 && buffer[buffer.length - 1]?.kind === 'sweep')
+        return;
+    const progress = ev.kind === 'tick' || ev.kind === 'fleet-row';
+    if (progress) {
+        const kind = ev.kind;
+        const taskId = ev.taskId;
+        // Search BACKWARDS for a merge target and STOP at the first barrier. The bar for the whole buffer
+        // is "replaying it leaves the consumer in the same state as if the panel had been mounted all
+        // along", and each barrier below is a place where the consumer's state machine changes what a
+        // later event means — so an event on the far side of one cannot be folded into an event on this
+        // side (0.41.0 adversarial review #5 and #6):
+        //   · 'sweep' (global) and 'end' for this taskId — they SETTLE the row, and the consumer ignores
+        //     progress for a settled row. Live: `tick(v1) → sweep → tick(v2)` builds the row, settles it,
+        //     then drops v2 → the row ends settled. Folded into `sweep → tick(v2)` the replay sweeps an
+        //     empty table and then v2 BUILDS a running row — a ghost that live delivery never produces.
+        //   · the OTHER progress lane for this taskId — the fleet-row arm's own header states that a
+        //     'tick' makes the fleet lane hand the row over PERMANENTLY, so what the fleet lane said
+        //     BEFORE the handover (transcriptId / startedAt, often carried by exactly one frame) would
+        //     land after it and never be applied.
+        // Barriers cost buffer slots, and that is the right trade: the bound is still enforced by the
+        // eviction policy below, while a wrong fold is silently wrong forever.
+        let i = -1;
+        for (let at = buffer.length - 1; at >= 0; at--) {
+            const b = buffer[at];
+            if (b === undefined)
+                continue;
+            if (b.kind === 'sweep')
+                break;
+            if (b.kind === 'end') {
+                if (b.taskId === taskId)
+                    break;
+                continue;
+            }
+            if (b.taskId !== taskId)
+                continue; // another task's progress — irrelevant to this row
+            if (b.kind === kind)
+                i = at;
+            break; // same lane ⇒ merge target; other lane ⇒ barrier
+        }
         if (i >= 0) {
-            buffer[i] = ev;
+            // 🔴 Coalescing must not DROP sticky keys either (0.41.0 adversarial review #4). Both progress
+            // lanes are published as PARTIAL frames — the projection emits `...(toolUses !== undefined ?
+            // { toolUses } : {})` and friends, and an absent key means "this frame didn't say, keep what the
+            // row already has" (the three-state rule on the fleet-row arm above). A mounted panel therefore
+            // still shows the `toolUses` that arrived on v1 after a v2 that only moved `totalTokens`; a
+            // replay that kept only v2 would lose it for good. So the surviving copy is a per-key merge
+            // (later frame wins per key, keys it omits are inherited), not a wholesale replacement.
+            const merged = { ...buffer[i], ...ev };
+            // 🔴 Coalescing must not REORDER across a lifecycle barrier (0.41.0 adversarial review #2).
+            // Overwriting in place rewrites `progress(A,v1) → end(A) → progress(A,v2)` into
+            // `progress(A,v2) → end(A)` — the post-settle rollup is moved BEFORE the settle, so a row that
+            // was revived (the fleet projection explicitly allows a settled row to run again) gets settled
+            // by the replay again, with the revived progress applied to the dead cycle. The bar for a
+            // buffered replay is "same result as if the panel had been mounted the whole time", so the
+            // surviving copy has to keep the LATEST event's arrival position: drop the old one, append.
+            buffer.splice(i, 1);
+            buffer.push(merged);
             return;
         }
     }
-    if (buffer.length < MAX_BUFFER)
+    if (buffer.length < MAX_BUFFER) {
         buffer.push(ev);
-    else if (ev.kind !== 'tick') {
-        // Lifecycle events must survive a full buffer: evict the oldest tick to make room.
-        const i = buffer.findIndex(b => b.kind === 'tick');
-        if (i >= 0)
-            buffer.splice(i, 1);
+        return;
+    }
+    // Full: the oldest PROGRESS event yields (its taskId's next rollup supersedes it anyway).
+    const evictAt = buffer.findIndex(b => b.kind === 'tick' || b.kind === 'fleet-row');
+    if (evictAt >= 0) {
+        buffer.splice(evictAt, 1);
         buffer.push(ev);
+        return;
     }
+    // Nothing but lifecycle events in a full buffer (MAX_BUFFER rows settled while the panel stayed
+    // unmounted — 200 distinct 'end's is the realistic way there, the adjacent-sweep dedup above having
+    // removed the cheap one). At a finite bound something must give, and the rule is NEWEST-WINS for
+    // every kind: the oldest event yields, whatever it is.
+    //
+    // 🔴 Why not "progress yields here too" (which is what this arm used to do — adversarial review
+    // round 7, finding #4): a progress event arriving at this point is the ONLY word the panel will
+    // ever get about a row that was created or revived after the barrier — `projectFleetAgentRows`
+    // emits on CHANGE, so a row that then goes quiet never speaks again. Dropping it makes that row
+    // permanently invisible after a remount, which is a strictly worse loss than dropping the OLDEST
+    // lifecycle event: that one settles a row that finished ~MAX_BUFFER events ago, and the sweep that
+    // every turn publishes (newest ⇒ always survives) settles whatever is still running anyway.
+    // The residual — an old 'end' can be dropped, taking its `report`/`isError` with it — is the honest
+    // price of a bounded buffer and is registered in CHANGELOG 0.41.0 "已知局限".
+    buffer.shift();
+    buffer.push(ev);
 }
 /** Single consumer (the panel hook). Replays any buffered events, returns an unsubscribe. */
 export function subscribeEngineAgentPanel(fn) {

package/dist/hitl/approvalsFeed.d.ts

@@ -6,7 +6,7 @@
  * ## 先纠一个事实(census G20 的措辞会误导下一棒)
  *
  * G20 原话是「`hitlBridge.ts:197` 等三处今天靠 `approvals.list` 轮询」。**实测不是轮询** ——
- * 那三处(`hitlBridge.findPending` / `askGateWire.surfaceGateAndDecide` /
+ * 那三处(`hitlBridge.pendingForDecide` / `askGateWire.surfaceGateAndDecide` /
  * `toolApprovalWire.surfaceFsApprovalAndDecide`)都是**按需单次取件**:流上已经来了 park 信号,
  * 才去取那一行。真正缺的不是「把轮询换成推送」,而是**根本没有推送通道**:
  *   · 别的客户端(web/桌面/另一个 TUI)解掉了一条 pending —— 本端不知道;
@@ -17,7 +17,7 @@
  *
  * ## 🔴 它**不替换** D-1 的取件(这条是安全边界,别"顺手优化"掉)
  *
- * D-1 两元组必须取自**人看见的那一行**。让 `findPending` 去读一个可能陈旧的快照 =
+ * D-1 两元组必须取自**人看见的那一行**。让取件去读一个可能陈旧的快照 =
  * 用一个过期的 `boundInputHash` 去 decide ⇒ server fail-closed 409 ⇒ 一个合法审批被拒
  * (或者更坏:快照比服务端新旧关系不确定时,人看到的和绑定的不是同一件事)。
  * 所以那三处**继续走权威 `list()`**,本 feed 只做「有变化了」的通知面与快照面。

package/dist/hitl/approvalsFeed.js

@@ -40,6 +40,16 @@ export function startApprovalsFeed(client, onSnapshot, opts) {
     let retryTimer;
     /** [2393] hitl-F5:连续「回调体抛出」的次数(一次跑完就归零)——见 `schedulePoll` 的 catch 臂。 */
     let consecutivePollEscapes = 0;
+    /** [F4957-1] 轮询腿的**代际**:push 腿每重连一次 +1。在途的旧拍完成时凭它认出自己已经过期 ——
+     *  它的成败属于上一条腿,不该改现在这条腿的连续计数,也不该由它来续排(见 `schedulePoll`)。 */
+    let pollLeg = 0;
+    /**
+     * [F4957-1 三审] 取件的**单调发号**与「已观察到的最新一号」。乱序回滚是**取件面的通病**,不是
+     * 轮询腿的私事:`refresh()`(端上的显式刷新)与 push 腿的重取同样可能后发先至。所以提交面的闸
+     * 从「代际」升成请求序号 —— 一次响应只有在「没有更晚发起的请求先落过地」时才允许改视图。
+     */
+    let takeSeq = 0;
+    let lastObservedSeq = 0;
     const stats = {
         pushEvents: 0, heartbeats: 0, polls: 0, listErrors: 0, streamFailures: 0, snapshots: 0,
     };
@@ -73,9 +83,12 @@ export function startApprovalsFeed(client, onSnapshot, opts) {
         }
         return verdict;
     }
-    async function take(via) {
+    async function take(via, 
+    /** [F4957-1 二审] 发起这次取件时的轮询代际(只有轮询腿传;push/refresh 不受代际管)。 */
+    leg) {
         if (stopped)
             return;
+        const seq = ++takeSeq;
         let rows;
         try {
             rows = (await client.approvals.list({ signal: ac.signal })).pending;
@@ -88,6 +101,23 @@ export function startApprovalsFeed(client, onSnapshot, opts) {
         if (stopped)
             return;
         const d = digestOf(rows);
+        // 🔴 [F4957-1 二审 finding②] 代际闸必须排在**提交之前**:下面四行(lastDigest / revision /
+        // last / onSnapshot)一落,视图就已经被改了 —— 守卫排在 take() 之外只挡得住计数与续排,挡不住
+        // 回滚。乱序是真的会发生的:旧 poll 在途 → push 重连并发布新快照 → 旧 poll 才带着**更老**的
+        // 结果返回 ⇒ 端拿到一张 revision 更高、内容更旧的 `mode:'poll'` 快照(刚出现的待审批被抹掉,
+        // 或刚解决的又冒回来)。过期的结论一个字节都不提交。
+        if (leg !== undefined && leg !== pollLeg) {
+            hostLog('debug', `approvalsFeed: dropping stale poll snapshot from leg ${leg} (current ${pollLeg})`);
+            return;
+        }
+        // 🔴 [F4957-1 三审 finding②] 乱序闸(三条取件路径共用):比「已观察到的最新一号」更早发起的
+        // 响应,其结论已经被后发者的结论取代 —— 一个字节都不提交。`refresh()` 不带代际,单靠上面那道
+        // 闸盖不住它(端上「用户点了刷新」正是最容易与 push 重取撞车的那一发)。
+        if (seq < lastObservedSeq) {
+            hostLog('debug', `approvalsFeed: dropping out-of-order take #${seq} (newest observed #${lastObservedSeq})`);
+            return;
+        }
+        lastObservedSeq = seq;
         if (d === lastDigest)
             return; // 内容没变 ⇒ 不打扰订阅者
         lastDigest = d;
@@ -118,6 +148,11 @@ export function startApprovalsFeed(client, onSnapshot, opts) {
             return;
         pollTimer = arm(setTimeout(() => {
             pollTimer = undefined;
+            // 🔴 [F4957-1 二审] 这一拍属于**哪一代**轮询腿。`take('poll')` 是可以挂很久的(慢 list /
+            // 挂死读面),期间 push 腿完全可能重连成功并把连续计数清零 —— 那一拍的结论此时已经是
+            // **上一条腿**的历史,回写到新计数里就等于把「被健康 push 窗隔开的失败」又算回连续
+            // (回落之后只需 4 拍就转 idle),而这正是本批要修掉的那条语义。代际在重连处 +1。
+            const leg = pollLeg;
             // [C77]② 跳拍:消费方说这一拍不用查 ⇒ 不取件、不计 `stats.polls`(没取件却计数 = 谎报流量)、
             // **不动** `consecutivePollEscapes`(跳拍不是失败,连着跳一万拍也不该被 F5 判成腿挂了),
             // 但下一拍照排 —— 这是「腿活着但闲着」,不是停摆。
@@ -128,7 +163,11 @@ export function startApprovalsFeed(client, onSnapshot, opts) {
             }
             void (async () => {
                 stats.polls++;
-                await take('poll');
+                await take('poll', leg); // 代际随取件一路带进去(提交面的闸在 take 内,见其头注)
+                // 代际已翻篇 ⇒ 这一拍的成败都不属于现在这条腿:既不清零(会掩盖新腿真正的连续失败),
+                // 也不续排(当代那条链由 degradeToPoll 自己排,这里再排一次纯属两条腿并行的种子)。
+                if (leg !== pollLeg)
+                    return;
                 consecutivePollEscapes = 0; // 跑完一整拍 ⇒ 之前的逃逸不再连续
                 if (mode === 'poll')
                     schedulePoll();
@@ -149,6 +188,11 @@ export function startApprovalsFeed(client, onSnapshot, opts) {
                 // ② **连续失败上限转 idle** —— 一直抛就是真的挂了,那时 `mode` 必须说真话,让端的自检
                 // 看得见([honest-absence-not-fabricated-zero]:诚实缺席优先于一个还在报活的假象)。
                 hostLog('debug', `approvalsFeed: poll leg threw unexpectedly (take() should have self-caught): ${String(e)}`);
+                // 🔴 [F4957-1 二审] 同上:上一代的逃逸不喂现在这条腿的连续计数,也不由它来续排。
+                if (leg !== pollLeg) {
+                    hostLog('debug', `approvalsFeed: stale poll completion from leg ${leg} (current ${pollLeg}) — not counted as a consecutive escape`);
+                    return;
+                }
                 consecutivePollEscapes++;
                 if (consecutivePollEscapes >= MAX_CONSECUTIVE_POLL_ESCAPES) {
                     mode = 'idle';
@@ -216,6 +260,17 @@ export function startApprovalsFeed(client, onSnapshot, opts) {
                         clearTimeout(pollTimer);
                         pollTimer = undefined;
                     }
+                    // 🔴 [F4957-1](0.41.0):**同批清零 F5 的连续逃逸计数**。这一拍与 `schedulePoll` 里
+                    // 「跑完一整拍 ⇒ 之前的逃逸不再连续」是同等强度的健康证据 —— 端真的从服务端收到了一个
+                    // 事件。不清零的后果不是多算几次:被一整段健康 push 窗**隔开**的两批逃逸会被当成连续
+                    // 累加(3 次 → 重连 → 再 2 次 = 5),于是刚从 push 回落的轮询腿才逃逸两拍就撞上限,
+                    // `mode()` 谎报 idle —— 而文件头 38-42 卖的正是「mode 不是 idle」这条端自检,
+                    // 它会指着一条刚活过来的腿说它停摆了([honest-absence-not-fabricated-zero] 的反面:
+                    // 把「活着」渲成「死了」同样是撒谎)。计数的语义是**连续**,那就只能被真正连续的失败喂大。
+                    consecutivePollEscapes = 0;
+                    // 与清零**同一拍**翻代际:清零只管已经落地的计数,代际管的是那些还挂在 `take()` 里、
+                    // 稍后才回写的在途拍(二审 finding③ —— 少了这一半,清零会被一个旧拍当场推回 1)。
+                    pollLeg++;
                     hostLog('debug', 'approvalsFeed: push leg re-established — polling leg stopped');
                 }
                 if (ev?.type === 'heartbeat') {

package/dist/hitl/askGateWire.d.ts

@@ -52,8 +52,10 @@
  *      从 `GET /v1/approvals` 拿 pending 行(input=questions + boundCallId/boundInputHash 绑定)、
  *      合成 QuestionFrame 借既有 AskUserQuestion overlay(planReviewWire 同款 local-responder 姿势,
  *      CC 原生对话框,零新 UI)、等用户作答。
- *   3. 决断走 T23 HitlBridge(答案 ride `ApprovalDecision.answer`,D-1 绑定 verbatim 回显;拒答=
- *      cancel-by-deny,contract/04 §2.4)。decide 是 SYNC 驱动的:引擎跑到下一个 park 或终态才返
+ *   3. 决断走 T23 HitlBridge(答案 ride `ApprovalDecision.answer`,D-1 绑定 verbatim 回显;拒答 =
+ *      一次 **TOOL 级 deny** 应答,把这只 ask 结算掉 —— server `ASSISTANT-WIRE-CONTRACT.md` §4a。
+ *      🔴 **0.42.0 撤稿**:原文写的是「拒答=cancel-by-deny,contract/04 §2.4」;§4a 逐字反对把
+ *      deny 读成 run kill,逐条撤稿见 `hitlBridge.decideTool` 头注)。decide 是 SYNC 驱动的:引擎跑到下一个 park 或终态才返
  *      (实测 4-5s+),返回体 `{status}` 即下一状态。
  *   4. 续流:attach `GET /v1/runs/:taskId/events`(durable leg;实证 durable log 从 park 点才开始,
  *      无挂起前重放)。重放的 tool_start/tool_end 按 toolCallId 去重;被 gate 的 call 在重放里带来

package/dist/hitl/askGateWire.js

@@ -76,6 +76,8 @@ export async function* bridgeAskUserQuestionGates(source, deps, opts) {
             park = {
                 gate: action.gate,
                 ...(action.pendingDone !== undefined ? { pendingDone: action.pendingDone } : {}),
+                // [4914] 请托①到货件:park 的待批 call 身份(server ≥7.41.0)——缺席是常态,见 GatePark 头注。
+                ...(action.gatedCallId !== undefined ? { gatedCallId: action.gatedCallId } : {}),
             };
             break;
         }