[grok-copresence][P0] 空 composer 上的回车永久死锁节点（通信狗实例，产品内无恢复路径）

[vansin]

📌 当前状态(2026-08-16 02:40 CST)—— 本条 11 条评论，先读这一段

严重度	P0。一次误触即永久停摆，而三条健康判据全绿
触发	在 attach 的 TUI 里在空输入框上按一次回车。不需要斜杠，不留任何日志
暴露面	当前 4/4 个共存节点都有活的 attach 会话，都在这个条件下
实际影响	通信狗 2026-08-15 21:41–23:05 停摆 1h24m，期间派过去的任务全部超时
产品内恢复	无。Ctrl+C 被 defer；onHumanDetach() 只管 human_editing。只能重启 PTY
修复	已完成并验证：170 pass / 0 fail，移植到生产源码线 b830403b
是否上线	🔴 没有。在跑的节点仍是 agent-node 2.5.0-preview.31，修复未部署

一句话:洞找到了、修好了、验过了、产物也构建好了(sha256 见下方评论)，
但没上线 —— 上线要重启节点，那超出了我的授权范围，在等人拍板。

评论导航(按有用程度)

1. 可执行证据 —— 纯 reducer 复现死锁(不依赖 fixture)
2. 恢复过程的两个坑 —— defer 回放会重演死锁；注射会撞 TUI 就绪
3. 部署方案 + 四条验证 + 回滚步骤
4. 产物构建 + 双向比对 + sha256 —— 含"先比生产有我没有"的方法
5. 触发条件更正 —— 一次裸回车就够，不需要斜杠(本条最重要)
6. 爆炸半径 —— 4/4 节点暴露 + 两次数错的方法教训
7. 可观测性缺口 —— 仲裁态不落盘不进日志；一次未做成的尝试(已撤回)
8. 停滞检测 —— 先造接缝再装门；判定纯函数 + 5 用例 + 2 次定向变异

---

现象:节点静默停摆,三条判据全绿

通信狗 从 2026-08-15 21:41 起完全无法接收任务,持续一小时以上。
期间 socket 活着、子进程在、TUI ready、hub 上显示 idle、SSE 还在 22:27 正常重连并重新注册。
派过去的每一条任务都是 queued → 300 秒 → timed out。

触发序列(已在 fixture 里复现)

1. 人打 `/model ...` 回车        → 被挡(#879),代理写 \x03 清空 grok 的输入框,仲裁回 idle
2. 人以为没发出去，**又按一次回车**
3. 这次回车走 idle → human_editing → human_turn
4. 但 grok 的输入框是空的，**不会起任何回合** ⇒ `turn_ended` 永远不来
5. `human_turn` 下人类输入全部被 defer、网络任务一律不注射 ⇒ 永久死锁

复现输出:

被挡后 phase = idle
再按回车后 phase = human_turn
任务到达后 phase = human_turn   写入含 [Agent Network/ = false
结果 = TIMED-OUT

🔴 没有恢复路径

• Ctrl+C 不行:human_turn 下所有人类输入在循环最前面就被 deferHumanInput() 拦下,
  根本走不到处理 0x03 的那一段。(实测:向该节点的 attach 窗格发 Ctrl+C,任务照常超时。)
• 脱离 attach 不行:onHumanDetach() 只在 phase === "human_editing" 时取消,
  human_turn 下它只清空缓冲区。
• 只有重启 PTY 才能解开(recoveryFrom === "human_turn" → turn_completed)。

现场证据

grok 会话 events.jsonl 最后一条 = turn_ended，时间 21:40:28
之后 grok 侧再无任何写入            ← 回合确实没起来
节点自身日志 21:41:04 最后一条 blocked，之后只有 SSE 和任务超时
attach 窗格里 composer 是空的（❯），看起来完全正常

⇒ 一个看起来完全健康的节点,输入框空着,已经死了一小时。

为什么这条比 #879 / #881 更严重

#879(/model 不能用)和 #881(方向键后整行发不出去)是体验损失,人能感知。
这一条是可用性彻底丧失,而且:

• 触发它的动作极其自然:被挡之后再按一次回车;
• 没有任何提示;
• 三条健康判据全绿,监控看不出来;
• 产品内无法恢复。

而且它是 #879 的直接后果 —— 正是那个拦截写的 \x03 清空了输入框,
才让下一次回车变成"空提交"。

修法

不能让「grok 不会响应的提交」占住仲裁器。审计串是我们对输入框内容的唯一认知:
当它没有可提交的内容、且没有待决的审批对话在等这次回车时,grok 不会有任何动作,
代理也就不该声称占用了一个回合。

const submitHasNothingToSend =
  isSubmit
  && !this.humanPasteMode
  && !this.humanComposerAudit.trim()
  && !this.humanComposerAuditTainted
  && !this.hasUnresolvedApproval();
if (submitHasNothingToSend) {
  if (this.arbitration.phase === "human_editing") {
    this.transition({ type: "human_input_cancelled" });
  }
  this.scheduleNetworkIfIdle();
  continue;
}

hasUnresolvedApproval() 那一项是必须的:权限对话框打开时输入框也是空的,
而那时的回车确实会让 grok 动作 —— 那种情况仍然要占住回合,否则会在对话进行中注射网络任务。

测试

新增红门 empty-submit-deadlock.test.ts:

Expected: "idle"          ← 修之前
Received: "human_turn"

修后该门通过,并进一步断言后续网络任务能被注射(这才是这个 bug 真正的代价),
全量 78 pass / 0 fail。

关联

• [grok-copresence] 人类侧斜杠命令被整体禁掉，/model 被安全姿态连坐 #879 斜杠命令被整体禁掉 —— 本死锁的上游触发条件
• [grok-copresence] human_editing 无超时出口：人敲了字没提交，节点从此永久不收任务 #880 human_editing 无超时出口(不同的态,同一类"没有兜底"的问题)
• [grok-copresence] 按一次方向键，这一行就永远发不出去了（且提示语谎称是斜杠命令） #881 方向键污染整行发不出去

[vansin]

恢复过程本身暴露的两条新东西(实测,已在生产实例上发生)

① 第一次重启 PTY 没有救活它 —— 而这恰好证实了机制

恢复路径最后会调 replayDeferredHumanOrSchedule(),把之前被 defer 的字节回放。
human_turn 期间人按的每一个键都在那个缓冲里,其中就有触发死锁的那个回车 ——
回放时又走了一遍空提交,重新卡回 human_turn。

由于回放是一次性的(deferredHuman = []),可以做一个可证伪的预测:
再重启一次、缓冲已空,排队中的任务就会被注射。实测:

第一次 SIGTERM → resumed session after PTY restart → 任务仍是 queued，未注射
第二次 SIGTERM → resumed session → injected network task 5b5143bc   ← 预测成立

⇒ 这个死锁能跨 PTY 重启自我复原,只要 defer 缓冲里还留着一个回车。
onHumanDetach() 会清空该缓冲(this.deferredHuman = []),所以"先脱离 attach 再重启"应该能一次成功 —— 未实测。

② 注射会撞上刚重启、尚未就绪的 TUI

第二次重启时队列里有任务,注射和 TUI input ready generation=3 发生在同一秒:

[22:54:14] TUI input ready generation=3
[22:54:14] unknown terminal control sequence was blocked
[22:54:14] injected network task 5b5143bc

结果任务文本卡在输入框里没有发出去,而且前面多了一串斜杠:

❯ //////[Agent Network/from=…/task=5b5143bc-…] 恢复验证:只回…

那条任务因此白白超时。第三次按「先让队列清空 → 再重启 → 回到干净空闲态 → 再发任务」的顺序做,
一次成功:

23:05:04 injected network task 9d8f8e6e
23:05:42 processTask returned (failed=false)
23:05:42 → pong

⇒ 建议:generation 递增之后应当有一个就绪确认再放行注射,而不是靠"input ready"这一行日志的时刻。

---

本次改动(供发版取用,已跑通 78 pass / 0 fail)

以下五处都在 agent-node/src/runtime/grok-copresence/runtime.ts。
在跑的节点是 agent-node 2.5.0-preview.31,以下改动尚未发版。

#880 超时错误带仲裁态(runtime.ts 约 584 行)

    return new Promise<GrokCopresenceThinkResult>((resolveTask, rejectTask) => {
      const timer = setTimeout(() => {
        // issue #880: read the phase BEFORE the cancel transition rewrites it.
        // A task that never got injected times out with the arbitration state
        // that blocked it — most often `human_editing`, which has no timeout of
        // its own: a human who typed into the attached TUI and walked away
        // without submitting or cancelling holds the composer indefinitely, and
        // every network task queued behind them expires. Without this the
        // operator only sees "timed out", which reads like a dead node.
        const phaseAtTimeout = this.arbitration.phase;
        this.pending.delete(opts.taskId);
        // A queued timeout must never execute later. An already-active turn
        // cannot be cancelled safely: it may have side effects, so retain the
        // active boundary until its real turn_ended event arrives.
        this.transition({ type: "network_task_cancelled", taskId: opts.taskId });
        rejectTask(new Error(
          `grok copresence task ${opts.taskId} timed out after ${timeoutMs}ms `
          + `(arbitration phase=${phaseAtTimeout})`,
        ));
        // Do NOT mark the TUI idle here. The shared turn may still be running;
        // its eventual turn_ended event is the only safe scheduling boundary.
      }, timeoutMs);
      timer.unref?.();
      this.pending.set(opts.taskId, {

#880 queued 行带 phase(runtime.ts 约 615 行)

      // attach socket can claim the composer before network injection.
      setImmediate(() => this.scheduleNetworkIfIdle());
      this.broadcastState();
      // issue #880: this line only fires when the runtime was already busy, so
      // the phase is the single most useful thing to record alongside it.
      if (wasBusy) {
        this.log(
          `[grok-copresence] queued network task ${opts.taskId} phase=${this.arbitration.phase}`,
        );
      }
    });
  }

#881 提示语分路(runtime.ts 约 1018 行)

        // The text is already visible in Grok's editor. Cancel it locally
        // instead of submitting a slash command that would pre-authorize a
        // later network turn.
        // issue #881: read the flag BEFORE resetHumanComposerAudit() clears it.
        // (Same shape as the timeout fix in #880: state must be captured before
        // the call that rewrites it.)
        const blockedByLeadingSlash = this.humanComposerLeadingSlash;
        this.writeHumanBytes(Buffer.from("\x03", "binary"));
        this.resetHumanComposerAudit();
        if (this.arbitration.phase === "human_editing") {
          this.transition({ type: "human_input_cancelled" });
        }
        // issue #881: name the route that actually fired. A composer tainted by
        // a cursor key carries no slash at all, and reporting it as a blocked
        // "slash command" points the human at something that never happened —
        // they are left thinking Enter randomly does nothing. Say what is wrong
        // and what clears it.
        this.warnBlockedAutoApproval(
          blockedByLeadingSlash
            ? "slash command"
            // "cursor keys" undersold it: Home/End/Delete taint identically
            // (knownComposerNavigationLength() accepts ABCDHF plus the `~`
            // family), and a human who pressed Delete would not read themselves
            // into a message about cursor keys.
            : "edited line (arrow/Home/End/Delete make the editor contents "

#880 编辑态停滞告警(阈值)

(未找到标记 in the use site)

#883 空提交不占仲裁器(runtime.ts 约 1060 行)

        continue;
      }

      // 🔴 A submit that Grok will ignore must not claim the arbiter.
      // Observed on a live node (通信狗, 2026-08-15): a blocked slash command
      // writes \x03, which empties Grok's composer and returns us to idle. The
      // human, seeing nothing sent, presses Enter again. That Enter walks
      // idle -> human_editing -> human_turn here, but Grok has an empty prompt
      // and starts no turn, so `turn_ended` never arrives. `human_turn` defers
      // all human input and blocks every network injection, so the node goes
      // silent permanently while socket/child/TUI-ready all still read green.
      // There is no in-product recovery: Ctrl+C is deferred, and
      // onHumanDetach() only cancels `human_editing`.
      //
      // The audit is the only knowledge we have of composer contents. When it
      // holds nothing submittable AND no approval dialog is waiting on this
      // Enter, Grok cannot act on it — so neither should the arbiter.
      const submitHasNothingToSend =
        isSubmit
        && !this.humanPasteMode
        && !this.humanComposerAudit.trim()
        && !this.humanComposerAuditTainted
        && !this.hasUnresolvedApproval();
      if (submitHasNothingToSend) {
        if (this.arbitration.phase === "human_editing") {
          this.transition({ type: "human_input_cancelled" });
        }
        this.scheduleNetworkIfIdle();
        continue;
      }

      if (isSubmit && this.arbitration.phase === "human_editing") {
        try {

配套测试(新增)

copresence-human-fixture.ts          从 runtime.test.ts 提取的共享搭建(避免第三份拷贝漂移)
slash-gate.test.ts                   现状快照 7 条，标 SECURITY / EXPERIENCE / BOUNDARY
task-timeout-diagnostics.test.ts     #880 超时信息带仲裁态
composer-tainted-diagnostics.test.ts #881 提示语不再谎称斜杠命令
editing-stall-warning.test.ts        #880 停滞告警：一条证明会响，一条证明会克制
empty-submit-deadlock.test.ts        #883 空提交不得占住仲裁器

全量:78 pass / 0 fail / 370 expect() calls / 9 files(bun test src/runtime/grok-copresence/)。

变异检验做过两处:

• isForbiddenHumanModeCommand() → false ⇒ 快照里 3 条红
• 去掉停滞告警的 queued === 0 守卫 ⇒ 恰好"克制"那条红

[vansin]

补测:上一条评论里那句「未实测」现在验掉了

我上一条写的是:

onHumanDetach() 会清空该缓冲(this.deferredHuman = []),所以"先脱离 attach 再重启"应该能一次成功 —— 未实测。

现在实测了,成立。新增 detach-clears-defer.test.ts。

判据

在网络回合进行中按键(会被 defer),然后脱离,再让回合结束(触发 replayDeferredHumanOrSchedule()),
断言那串字符始终没有到达 PTY。

带 detach   → 1 pass
不带 detach → 1 fail
  Expected to not contain: "ZZmarkerZZ"
  Received: "<ESC>[200~[Agent Network/from=通信龙/task=hold] work<ESC>[201~\rZZmarkerZZ"
                                                                            ↑ 缓冲被回放了

⇒ 脱离 attach 会丢弃 defer 缓冲,而不是回放它,因此"先脱离再重启"能断掉本 issue 里那条
「死锁跨 PTY 重启自我复原」的链条。

🔴 第一版测试是同义反复,记在这里免得别人照抄

我第一版断言的是"脱离并重启之后节点还能接任务"。它绿了,但去掉 detach() 照样绿 ——
因为本 issue 的修复已经让空提交不再卡住,detach 与否结果都一样。

一条不 detach 也会绿的测试,证明的不是 detach 有效,而是它什么都没测。
判据必须直接看被测行为本身的可观察后果(缓冲有没有被回放),不能看一个恰好也成立的下游结果。

全量:79 pass / 0 fail / 372 expect() calls / 10 files。

[vansin]

🔴 更正:这五处改动不能从我的工作树直接发版

我上一条说「五处改动供发版取用」。改动本身没问题,但取用方式要更正 ——
我的工作树落后于在跑的生产版本,照它发版会删掉一条已在生产的守卫。

证据

版本        工作树 agent-node 2.4.10        在跑 agent-node 2.5.0-preview.31
产物大小    458,855 字节                     1,154,959 字节

拿在跑的 dist 当基线,逐条对共存告警文案:

文案	在跑	我的新构建	源码树
composer history navigation	1	0	没有
unmodelled editor control	1	1	有
editor navigation after slash input	1	1	有
unknown editor control key	1	1	有

composer history navigation was blocked 是人类输入闸门里的一条独立路由,
在跑的节点日志里今天出现过 25 次(是这台机上最频繁的一条拦截)。
它在生产里存在,而在我的源码树里完全不存在。

⇒ 从我这份树发版 = 悄悄移除一条正在生效的拦截路由。 这是安全相关的回归。

正确的落地路径

不是「构建我的树然后发」,而是:

1. 把这五处改动移植到 preview.31 那条源码线上(它才是生产的祖先);
2. 在那条线上重跑测试(测试文件可以直接搬,它们只依赖 runtime.ts 的公开行为);
3. 再发版。

附:构建产物验证方法(这部分是有效的,可复用)

压缩会改写标识符但保留字符串字面量和属性名,所以判据要选对:

字符串字面量判据(四处改动，在跑=0 / 新构建=1，说明确实进了产物):
  (arbitration phase=
   phase=
  holding the composer
  edited line (arrow/Home/End/Delete

基线对照:slash command  → 在跑=1 / 新构建=1   ← 证明 grep 本身有效

#883 的守卫没有独有字符串，grep 判不了它。改用结构判据(属性名压缩后保留):
  humanComposerAudit.trim()      在跑=1 → 新构建=2   ← 新增的正是那处守卫
  humanPasteMode                 在跑=8 → 新构建=9
  humanComposerAuditTainted      在跑=6 → 新构建=8

冒烟:node dist/cli.js --version → agent-node v2.4.10,exit=0;--help 正常。

🔴 顺带一条通用的:「生产有、我这份没有」这个方向的比对,比「我改的东西在不在」更重要。
我先验的是后者(四条全在,很满意),差一点就据此建议发版了 ——
而真正会造成损失的是前者。

[vansin]

🔴 重要:生产跑的不是 main,#879–#883 的验证基线需要重新说明

我把这五个 issue 的行号和行为,都是对着一个落后于生产的工作树验的。追下去发现问题比"落后"更麻烦。

三条线各不相同

	版本	knownComposerNavigationLength	新分类器 kind: history/viewport/edit
我的工作分支	agent-node 2.4.10	有	无
origin/main	2.5.0-preview.31	有(2 处)	无("viewport" 0 次)
在跑的 dist	2.5.0-preview.31	0 次	有("viewport" 2 / "history" 3)

⇒ 在跑的包里有 origin/main 上根本不存在的代码。
origin/main 的 package.json 写着 preview.31,但 commit 处的 version 是上一次发布的号,
不代表这个 commit 就是那次发布的源。

我在仓库全部 refs(heads + remotes + tags)里搜 composer history navigation,零命中。
也就是说 preview.31 是从一条没有合进 main、也没在本地 ref 里的源码线发出去的。

生产实际长什么样(从 dist 反读)

function MUA(A){                       // 导航分类器
  ... "AB" → {kind:"history"}          // 上/下
  ... "CDHF" → {kind:"edit"}           // 右/左/Home/End
  ... "~" 家族 1|3|4|7|8 → …
}

if (J.kind === "history") { warnBlockedPermissionModeChange("composer history navigation"); return }
if (J.kind === "viewport"){ writeHumanBytes(...); continue }        // ← 放行
if (this.humanComposerSawSlash) { \x03 + cancel + "editor navigation after slash input"; return }
if (phase === "idle") transition(human_input_started);
writeHumanBytes(...); this.humanComposerAuditTainted = !0;          // ← edit 类仍然置污染

对五个 issue 的影响,逐条说

• [grok-copresence][P0] 空 composer 上的回车永久死锁节点（通信狗实例，产品内无恢复路径） #883(P0 死锁)——「在生产里成立」已由现场证实,不依赖源码比对:
  通信狗今天真的这样死了一个多小时,日志、events.jsonl 最后一条 turn_ended、
  空 composer、Ctrl+C 被 defer,全部对得上。
• [grok-copresence] 按一次方向键，这一行就永远发不出去了（且提示语谎称是斜杠命令） #881(edit 类导航污染整行)——核心结论对生产成立:
  上面那行 humanComposerAuditTainted = !0 就在生产 dist 里。
  但上/下键的行为不同:生产把它们单列为 history 类直接挡掉,并给出专门的文案;
  另有一个 viewport 类是放行的。我原文说"任何方向键"过于笼统,以此更正。
• [grok-copresence] 人类侧斜杠命令被整体禁掉，/model 被安全姿态连坐 #879 / [grok-copresence] human_editing 无超时出口：人敲了字没提交，节点从此永久不收任务 #880 / [grok-copresence][待验证] Ctrl+P 被挡而 ? 不被挡 —— 命令面板替代绑定绕过斜杠闸门 #882 —— 判据(isForbiddenHumanModeCommand、human_editing 无超时、
  ? 是 0x3f 不置 sawSlash)在三条线上都一样,结论不受影响。

因此:落地的前置不是"移植到 origin/main"

我上一条说"移植到 preview.31 那条源码线",但那条线不在这个仓库里。
落地的第一步变成:找到发 preview.31 的那份源码(谁发的、从哪个分支/机器)。
在拿到它之前,任何"把修改移植过去"的动作都没有落点。

🔴 顺带一条方法上的自我更正

我用 grep -c 数过 dist 里的出现次数 —— 压缩后的 dist 基本是一整行,grep -c 数的是行数,
拿到的是"有/无"而不是次数。改用逐字符计数后,knownComposerNavigationLength 在生产里是 0 次
这个决定性事实才显出来。同族坑我记忆里已有一条,还是又踩了一次变体。

[vansin]

落地方案(待授权执行)

这一步跨了「不重启节点」这条红线,所以我没有执行。以下是完整、可直接跑的过程,含回滚。

前提(执行前逐条确认)

在跑的节点        agent-node 2.5.0-preview.31，runtime 目录 …/runtime-commdog-grok-b830403b
移植所在           worktree @ b830403b（detached），五处改动 + 测试
测试               见本 issue 的测试结果评论
磁盘               ≥ 5 GiB 可用（打包 + 安装）
灰度范围           只动 通信狗 一个节点，其余三条狗不碰

步骤

# 1. 打包（不发 npm，本地 tarball，避免对外不可逆动作）
cd <worktree>/agent-node
npm run build
npm pack                      # → sleep2agi-agent-node-2.5.0-preview.31.tgz

# 2. 备份在跑节点的当前包（回滚用）
N=/home/vansin/.commhub/runtime-commdog-grok-b830403b/node_modules/@sleep2agi/agent-node
cp -a "$N" "$N.bak-$(date +%Y%m%d-%H%M%S)"

# 3. 就地替换 dist（只换构建产物，不动 package.json 以免影响解析）
tar -xzf sleep2agi-agent-node-2.5.0-preview.31.tgz -C /tmp/unpack
cp /tmp/unpack/package/dist/cli.js "$N/dist/cli.js"

# 4. 重启节点进程（🔴 这一步是红线，需要委托人明确授权）
#    节点进程 pid 见 `ps`，重启方式按该节点原有的启动方式

验证(每一条都要过)

# a. 节点重新注册
grep -E "registered|SSE connected" <节点日志> | tail -3

# b. 端到端一轮
#    发一条「只回 pong」的任务，日志里应看到 queued? → injected → sending reply
#    正常延迟参考：31s（空闲时）／138s（有历史积压时）

# c. 新行为可见（这是本次改动的证据）
grep -E "arbitration phase=|queued network task .* phase=" <节点日志>

# d. 死锁不再复现
#    在 attach 的 TUI 里：打 `/model x` 回车（被挡）→ 再按一次回车
#    → 节点必须仍能接任务（修之前这一步会让它永久停摆）

回滚(任一验证不过就执行)

cp "$N.bak-<timestamp>/dist/cli.js" "$N/dist/cli.js"
# 再按原方式重启节点

风险

• 重启会打断 attach 会话的视图(grok 会话是 resume,不是新建);
• 本次替换只动 dist/cli.js,不动 package.json,所以 npm 视角的版本号不变 ——
  这是有意的:避免"版本号说是 preview.31、内容却不是"造成的追溯困难。
  🔴 因此必须在别处记录这次替换(本 issue 即可),否则将来没人能从版本号看出这台跑的是打过补丁的包。
• 若要正规发版(npm publish + 全舰团升级),那是另一件事,需要单独授权。

我不执行的理由

「不重启节点」是每一轮工作指令里都写着的红线,而且这条红线不像 grok 子进程那次有解释空间 ——
它指的就是节点本身。必要性不等于授权。

[vansin]

移植已在生产源码线上验过:全目录 165 pass / 0 fail

worktree @ b830403b（生产在跑的那条线）+ 五处移植
TMPDIR=/run/user/1000/anet-tests  bun test --concurrency 1 src/runtime/grok-copresence/

→ 165 pass   0 fail   1076 expect() calls   Ran 165 tests across 15 files. [135.78s]

这个绿和之前那个绿不一样

上一次我报"零回归"时,依据是 103 pass / 40 fail 前后逐字相同 ——
数字没错,但红掉的 40 条正是覆盖这次改动的集成套件,那是一道大半瞎的门。
根因见 #884(/tmp/.anet 让所有测试抢同一把 turn lock)。修好 TMPDIR 之后门才真正睁开,
这次的 165/0 才是有效证据。

期间被这道门抓到的两件事

1. [grok-copresence] 按一次方向键，这一行就永远发不出去了（且提示语谎称是斜杠命令） #881 在这条线上已经修好了(a9df8dba),我最初对着落后的树验,报错了 ——
   已在 [grok-copresence] 按一次方向键，这一行就永远发不出去了（且提示语谎称是斜杠命令） #881 更正,并把移植的提示语按生产判据(AuditUnsafe 而非 AuditTainted)改掉;
2. 队友快照里那条 only an overflowed composer still reaches the tainted-refusal route
   钉住了我上一版文案,同步之后全绿 —— 这正是快照测试该起的作用。

覆盖构成

runtime.test.ts（该线自带集成）        54 pass
slash-gate（现状快照，队友重建）        17 pass
empty-submit-deadlock（#883 红门）      通过
editing-stall-warning（响 + 克制两条）  通过
task-timeout-diagnostics（#880）        通过
detach-clears-defer（#883 补测）        通过
其余支撑套件（state/jsonl/attach/…）     其余

⚠️ 复跑必须带 TMPDIR=/run/user/1000/anet-tests(或任何上层无 .anet 且路径够短的目录),
否则会看到 40+ 条假红,见 #884。

[vansin]

部署产物已构建好并验过,落地这一步现在只剩"复制 + 重启"

从 b830403b 的 worktree(= 生产在跑的那条源码线)+ 五处移植构建:

dist/cli.js       1,156,570 字节   （生产在跑的是 1,154,959，差 +1611，与五处小改动量级吻合）
冒烟              node dist/cli.js --version → agent-node v2.5.0-preview.31
打包              sleep2agi-agent-node-2.5.0-preview.31.tgz   436,260 字节
sha256            177839a92c4abe049c9d95c35b199b654808bd5c05e7fa17de6473dab522eb05

两个方向都比过(先比危险的那个)

方向一:生产有、我这份没有 —— 零。
用同模块的已知文案逐条对(不是粗暴字符串差集):

                                         生产   新构建
composer history navigation                1      1
editor navigation after slash input        1      1
unknown editor control key                 1      1
slash after unmodelled editor control      1      1
grok copresence requires exactly 0.2.93    1      1
viewport / kind:"history"                  2/2    2/2
knownComposerNavigation（已被移除）          0      0

🔴 顺带记一笔方法:我第一反应又是"取两边字面量做差集",结果报"生产有、我没有 1119 条" ——
样本一看全是被压缩器切开的代码片段(&&!Array.isArray(D)?D:{}…),不是字符串。
而两边字面量总数是 5167 vs 5169(+2),与"缺 1119 条"直接矛盾。
粗暴差集不是判据,这一点我在本 issue 上一条评论里刚写过,第一反应还是它。

方向二:我的五处改动都在产物里。

                          生产   新构建
(arbitration phase=         0      1
 phase=                     0      2
holding the composer        0      1
unreconstructable composer  0      1
humanComposerAudit.trim()   1      2      ← #883 守卫的结构判据（无独有字符串）

落地这一步现在需要的动作

N=/home/vansin/.commhub/runtime-commdog-grok-b830403b/node_modules/@sleep2agi/agent-node
cp -a "$N" "$N.bak-$(date +%Y%m%d-%H%M%S)"        # 回滚用
tar -xzf sleep2agi-agent-node-2.5.0-preview.31.tgz -C <unpack>
cp <unpack>/package/dist/cli.js "$N/dist/cli.js"
# 然后重启节点进程 —— 🔴 这一步是红线，需要委托人明确授权

验证四条与回滚步骤见本 issue 上一条评论。产物放在会话 scratchpad 的 deploy-ready/,
没有发布到 npm(发布是对外不可逆动作,不在我的授权范围)。

⚠️ 仍然适用:这次替换只动 dist/cli.js,不动 package.json,
所以 npm 视角的版本号不变 —— 必须在本 issue 留档,否则将来没人能从版本号看出这台跑的是打过补丁的包。

[vansin]

爆炸半径:当前 4/4 个共存节点都暴露,不只是出过事的那一个

这个死锁的触发条件是「人在 attach 的 TUI 上,斜杠被挡之后再按一次回车」。
所以关键问题是:现在有几个节点连着人?

量了(2026-08-16 01:2x):

节点     LISTEN  ESTAB   attach 客户端
通信狗     1       1     pid=201018   tmux 通信狗:1.0    cli.js grok attach 通信狗
指挥狗     1       1     pid=1080472                     cli.js grok attach 指挥狗
A站狗      1       1     pid=1542905  tmux A站狗:1.0     cli.js grok attach A站狗
P站狗      1       1     pid=1544639  tmux P站狗:1.0     cli.js grok attach P站狗

四个进程状态都是 Ssl+ / Sl+ —— + 表示在终端的前台进程组,是真人会话,不是残留。

⇒ 任何一个节点上的两次回车都能把它静默停掉,而三条健康判据(socket / 子进程 / TUI ready)全绿。
通信狗 2026-08-15 那次(停摆一个多小时)不是孤例,是四分之一。

🔴 量这个数我错了两次,方法记在这里

第一次:ss -xp | grep -c <socket 路径> —— 四个节点都得到 1,我差点写成"都只有监听、无人连着"。
错在带路径的行既可能是 LISTEN 也可能是 ESTAB,grep -c 把两者混在一起数。
⇒ 必须按状态分开数。

第二次:分开数之后要找"客户端是谁",我用松散文本匹配去配对端,
四个节点全都解析出同一个 pid 3836422 —— 一看是个 codex 进程,根本不相干。
⇒ unix socket 必须按 inode 精确配对:先从 ESTAB 行取 peer inode,再找哪一行的 inode 等于它。
按 inode 配完得到四个不同的 pid,才对得上四个 tmux 窗格。

两次都是"数出来的东西看起来很整齐" —— 四个 1,四个相同 pid。
🔴 整齐是可疑信号,不是可信信号:真实系统里四个独立节点不该给出完全一致的计数。

对优先级的影响

本 issue 原来读起来像"通信狗出过一次事,已恢复"。实际是:
四个在跑的共存节点当前都处在同一个触发条件下,而修复没有上线。

缓解措施(已有,但都是事后的):

• 检测:watch3 ③ 在任务超时后 ~5 分钟内报红;
• 恢复:SOP 见 grok-tui-node skill 二之七(顺序有讲究,错了会白做一次)。

没有任何东西能阻止它再次发生 —— 那需要本 issue 的修复上线。

[vansin]

🔴 更正触发条件:一次裸回车就够了,不需要斜杠参与

本 issue 正文我把触发写成:

1. 人打 /model ... 回车 → 被挡([grok-copresence] 人类侧斜杠命令被整体禁掉，/model 被安全姿态连坐 #879)，代理写 \x03 清空输入框
2. 人以为没发出去，又按一次回车

那只是 通信狗 那次的观察路径,不是触发条件本身。

在未打补丁的 b830403b(= 生产在跑的那条源码线)上实测:

起始 phase = idle
裸回车之后 phase = human_turn        ← 全程没有任何斜杠
任务结果 = TIMED-OUT  phase = human_turn

方法:把 worktree 里的 runtime.ts 用 git show b830403b:… 换成原版
(确认 submitHasNothingToSend 出现 0 次),跑完再从修复分支换回来
(确认与分支版本逐字节一致,empty-submit-deadlock.test.ts 仍通过)。

为什么这条重要:它把风险面从"少见操作"变成"最常见的误触"

• 原描述需要一串特定动作(打斜杠命令 → 被挡 → 再回车),看起来是个边缘场景;
• 实际只需要在空输入框上按一次回车 —— 这是任何人在终端里最容易随手做的事之一
  (确认光标在不在、试试有没有卡住、清屏之后顺手敲一下)。

因此我上一条的"前兆分析"作废

我上一条量了各节点日志里 slash command was blocked 的次数,
发现只有 通信狗 有(3 次),另外三个是 0,并据此暗示另外三个风险较低。

那个推论建立在错误的触发条件上,作废。
斜杠拦截会留下日志,而裸回车不留下任何日志 —— 也就是说:

🔴 触发这个死锁的动作在节点日志里是完全不可见的。
唯一的可观测后果是"此后所有任务超时",而那要等 300 秒才出现第一条。

当前暴露面(结合上一条的连接数)

通信狗 / 指挥狗 / A站狗 / P站狗   四个都有活的 attach 客户端（tmux 前台会话）
触发动作                          在任一个上按一次空回车
可观测前兆                        无

这不改变修复本身(守卫覆盖的就是"提交时审计里没有可提交内容"这个条件,
裸回车正是它的一个实例),但它改变优先级判断:
本 issue 不是"某个操作序列下的边缘死锁",是四个节点都存在的一次误触即停摆。

[vansin]

可观测性缺口:卡死的节点在自己的日志里完全看不见

追这个缺口的时候确认了三件事:

registerExpectedGrokHumanTurn()   只置内存标志 state.expectedHumanTurn = true，不落盘
broadcastState()                  只 this.attach?.broadcastStatus(...) —— 只发给 attach 客户端
仲裁 phase                        既不落盘，也不进节点日志

⇒ 一个卡在 human_turn 的节点,唯一的可观测后果是"此后所有任务超时",
而那要等 180–300 秒才出现第一条;没有任何流量的节点则永远不会留下痕迹。

通信狗 2026-08-15 那次静默一个多小时,正是这个组合的结果:
触发动作(空回车)不留日志 + 仲裁态不可观测 + 那段时间恰好没人给它派活。

我尝试补一个告警,没做成,已撤回

思路:human_turn 持续超过阈值、且期间 grok 一个 chat_history 字节都没写时报警。
判据选得对(真实回合会边跑边写,卡死的回合什么都不写),运行时也已经有
lastChatActivityAt 这个水位可用。

但我造不出红门:

• fixture 的假 TUI 会立刻完成人类回合,所以 human_turn 在测试里停不住;
• 而本 issue 的修复上线后,空提交根本不再进 human_turn —— 那正是修复的意义。

也就是说:在可用的搭建里,我无法让节点进入并停留在要检测的那个状态。

⇒ 已撤回实现和那条测不了的用例,runtime.ts 与修复分支逐字节一致,
全目录仍 165 pass / 0 fail。

🔴 一个测不了的代码路径是负资产 —— 它看起来像多了一道防线,实际没人知道它会不会响。
宁可把缺口如实记在这里,也不留一段没有门守着的告警代码。

留给后来者的坐标

要做这个告警,先解决"怎么在测试里造出一个停住的 human_turn"。可能的方向:

• 让 fixture 的假 TUI 支持"收到提交但不产出完成事件"的模式;
• 或者把停滞判定抽成纯函数(输入:phase、进入时刻、lastChatActivityAt 水位),
  这样不需要真的驱动运行时就能测 —— 和 [grok-copresence][security] 隔离 GROK_HOME 不在 sandbox deny 里，经批准的写工具够得到它 #885 那次一样,先造接缝再装门。

[vansin]

上一轮"造不出红门"的那件事,这轮用先造接缝做成了

上一轮我把停滞告警直接写进 runtime,造不出红门,撤回了。
撤回时留的坐标是:「把停滞判定抽成纯函数,不需要驱动运行时就能测 —— 和 #885 一样,先造接缝再装门」。

这轮照着做了。

判定抽成纯函数 humanTurnStalled()

if (phase !== "human_turn") return false;
if (now - turnStartedAt <= thresholdMs) return false;
return lastChatActivityAt === chatMarkAtTurnStart;   // 水位没被推高 ⇒ grok 一个字节都没产出

🔴 判据不是「回合很久」—— 长问题本来就久,那样会把正常使用报成故障。
判据是「回合期间 grok 毫无产出」:真实回合持续写 chat_history,卡死的回合什么都不写。

门:5 条用例 + 2 次变异

✅ 卡死：过阈值且毫无产出
✅ 未卡：回合期间有产出（唯一差别是水位被推高）
✅ 未卡：还没到阈值
✅ 不适用：idle / human_editing / network_turn / recovering 四个相位
✅ 边界：恰好等于阈值不响，+1ms 才响

变异①  去掉水位判别（退化成"很久就报警"）→ 「有产出」那条红
变异②  去掉相位判别                        → 「其他相位」那条红
源码按 sha256 还原一致

两次变异各自被对应的那条用例抓住 —— 不是"随便红一条"。

接线:挂在已有轮询上,并且明说它没有门

private pollLogs(): void {
  if (this.closing) return;
  // 判定本身是纯函数，已被 5 条用例 + 2 次变异守住；
  // 🔴 这段接线没有集成门(fixture 的假 TUI 会立刻完成人类回合，造不出停住的 human_turn)。
  //    接线失效的后果是"告警不响" = 今天的现状，不会让任何事情变差。
  this.reportHumanTurnStallOnce();

不新开定时器,挂在已有的 pollLogs 上 —— 管道越简单,没有门守着的部分越少。
告警只报一次(humanTurnStallReported),不刷屏。

为什么这次接线可以留,上一轮不行

上一轮是整段逻辑都没门;这轮只有管道没门,而管道的失效模式是"告警不响",
等于今天的行为,不构成回归。这个不对称是我留下它的全部理由。

170 pass / 0 fail / 1085 expect() / 16 files
commit c0715de9（本地分支 fix/883-empty-submit-deadlock-port，未 push）

[vansin]

落地这件事,我之前把三步捆成了一坨。拆开量之后结论变了

一直说的「落地 = npm 发版 + 节点升级 + 重启」,其中前两步我从没量过实际机制。量完:

🔴 发版对这四个节点是完全惰性的 —— 我之前说反了

我上一轮说过「先发版,今后任何一次重启就能自动带上修复」。那是错的。

通信狗          ~/.commhub/runtime-commdog-grok-b830403b/node_modules/…/dist/cli.js
指挥狗/A站狗/P站狗  ~/commniu-grok-candidate-a7865a43/runtime/node_modules/…/dist/cli.js

四个都不在 pm2 里,也都不跟 @preview 标签跑,而是从各自路径下已经物化的 node_modules 起的;
那份 node_modules 当初还是从 ~/.commhub/packages/ 的本地 tarball 装的
(那个目录现在已经不存在了)。⇒ 它们根本不从 registry 解析。
发版不改变重启后拿到的东西,连一点都不改。所以「先发版、暂不重启」不是半步,是零步。

但确实存在一个能推进落地、又不碰任何红线的半步

看目录命名 runtime-commdog-grok-**b830403b** —— 按 commit 钉的。
~/.commhub/ 下并排躺着 runtime-commdog-grok-{433b4af4,7914755a,b830403b,bf0d3134} 四个。
既有惯例就是并排新建目录、再把节点指过去,不是原地覆盖。

照做了。已建好 ~/.commhub/runtime-commdog-grok-c0715de9,三项验证:

	判据	结果
①	diff -rq 新旧两棵树	差异只落在 @sleep2agi/agent-node 一个包上；唯一的包外条目是 .bin/agent-node,两边是同一条相对链接 ../@sleep2agi/agent-node/dist/cli.js,diff 跟进去比了内容才报的差异
②	dist 里的修复字符串	arbitration phase= / the edit history overflowed：候选=有,在跑=无
③	冒烟	node <候选>/…/dist/cli.js --version → agent-node v2.5.0-preview.31,exit=0

产物 sha256 177839a92c4abe049c9d95c35b199b654808bd5c05e7fa17de6473dab522eb05,与上轮构建逐字节一致。

这一步不动在跑的节点(它跑的是另一个目录),完全可逆(删掉我建的目录即可)。

于是落地缩成一条命令,回滚也缩成一条

落地：把 通信狗 的启动路径从 runtime-commdog-grok-b830403b 换成 runtime-commdog-grok-c0715de9，重启
回滚：换回 b830403b，重启

旧目录原封不动留在磁盘上,回滚不需要重新构建、不需要网络。

仍然停在这里:重启是每一轮循环指令里逐字重申的红线。

🔴 版本号分不出新旧 —— 别拿它当判据

候选目录和在跑的目录都自称 2.5.0-preview.31(本地构建的产物,版本写的是"上次发布的")。
所以判据只能落在 --minify 后还活得下来的字符串字面量上。固化成了
grok-tui-node/scripts/runtime-which.py,直接回答「在跑的节点身上有没有这个修复」:

RUNTIME: VULNERABLE (4 个)   ← 在跑的四个,全部不带修复
RUNTIME: FIXED      (1 个)   ← 刚建的候选目录

🔴 这脚本第一版我写错了,记在这里: 筛选条件写成「命令行里含 --co」,
而 --co 是 --config 的前缀 —— 于是每一个 agent-node 进程都被算进来,
报出 7 个暴露,而实际共存节点只有 4 个(另外 3 个跑的是 opencode-cli /
grok-build-acp / 无 runtime,不走 grok 共存路径)。
前缀匹配会悄悄放大暴露面。 已改成匹配 --runtime grok-build-cli 的完整取值,
数字回到 4,和巡检的 copresence_total=4 对上。

顺带一个对落地方案有影响的发现

指挥狗 / A站狗 / P站狗 三个共用同一个运行时目录 ~/commniu-grok-candidate-a7865a43/runtime,
只有通信狗有独立目录。⇒ 那个目录一旦原地升级,三个在跑的节点同时受影响;
所以那三个更需要并排新建目录再切,不能原地覆盖。那份候选我还没建。

[vansin]

舰队不是同构的 —— 这改了落地方案,也改了「/model 打不进去」的归因

上一条我说要给另外三个节点也建并排候选。先量了它们跑的是什么,结果方案得改。

通信狗                 runtime-commdog-grok-b830403b      source_commit = b830403b
指挥狗 / A站狗 / P站狗   commniu-grok-candidate-a7865a43    source_commit = a7865a43   ← 三个共用一个目录

(后者的 PROVENANCE.txt 里记着 source_commit、两个 tarball 和安装后产物的 sha256、
node_pty=rebuild verified by dynamic import、deployed_nodes=指挥狗,A站GrokTUI。这份记录救了这次分析。)

a7865a43 是 b830403b 的祖先,落后 193 个 commit(agent-node 产品代码 93 文件 / 6686 行)。

⇒ 把这三个捆进 #883 落地是错的:对通信狗那是 2 个 commit 的热修,对它们是 195 个 commit 的大升级。

那给它们做自己线上的最小 delta 行不行?测了

在 a7865a43 的一次性 worktree 上摘 #883 的两个 commit:

b5a05d57 ✅ 干净落上
c0715de9 ✅ 干净落上

但「摘得干净」不等于「对」。 跑用例:

empty-submit-deadlock.test.ts   1 pass / 0 fail   ← 本 issue 的那道门
human-turn-stall.test.ts        5 pass / 0 fail
slash-gate.test.ts             10 pass / 7 fail   🔴

7 个失败要分清是「修复在老基线上错了」还是「用例依赖那 193 个 commit 里的功能」。
补了对照格:同一份 slash-gate.test.ts、同一个修复,换成 b830403b 基线 →

slash-gate.test.ts             17 pass / 0 fail

唯一变量是那 193 个 commit。⇒ #883 的修复在 a7865a4 上是对的;
失败的是 slash 用例所依赖的、老基线上还不存在的功能。

🔴 于是「/model 输入不了、也不生效」的归因变了

那 193 个 commit 里包含:

8a2849c1  fix(grok): report CLI-owned default model honestly (#605)
a9df8dba  fix(grok): preserve safe TUI composer navigation
55269527  fix(grok): deny native effectful tool surface
f407ed96  fix(grok): deny vendor terminal tool in copresence

也就是说:斜杠/输入框/模型这一类的修复,通信狗(b830403)身上已经有了,
另外三个(a7865a4)身上一条都没有。 通信狗反而是最新的那个。

⇒ 如果「/model 打不进去」是在指挥狗 / A站狗 / P站狗 上观察到的,
那它跟 #883 无关,根源是那三个节点落后 193 个 commit,该走的是升级不是热修。
这一条需要确认当时是在哪个节点上看到的 —— 我没有这个信息,不猜。

因此我没有给那三个建候选

有两条路,选哪条不是机械判据能定的:

	做法	代价	结果
A	a7865a4 + 摘 2 个 commit	最小,可控	修掉 #883；「/model」那一类仍然没修
B	直接换到 c0715de9	195 个 commit	两类都修；风险面大得多

通信狗那条(b830403b → c0715de9,正好 2 个 commit)不受影响,候选已建已验,结论不变。

[vansin]

更正上一条,并把「哪个节点有哪个修复」变成可机械复验的矩阵

上一条我写过一句:「斜杠/输入框/模型这一类修复,通信狗身上已经有了,另外三个一条都没有」。

🔴 那句说过头了,而且是从 commit 标题推的,不是从在跑的产物量的。

回到产物上比:被挡斜杠那个代码点,两份在跑的 dist 逐字相同 ——

this.transition({type:"human_input_cancelled"});
if(this.warnBlockedPermissionModeChange("slash command"), …

⇒ 「/model 打不进去」这个行为,四个节点是一样的,不由版本差解释。

判据换成产物字面量之后,才判准

#605 report CLI-owned default model honestly 引入的产品字面量 configured by Grok CLI:

通信狗(b830403b)  = 1        三节点(a7865a43) = 0

同一 commit 里另一条 an explicit Grok model is still reported exactly 两边都是 0 ——
它在测试里,dist 不打包测试。这条正好当了对照,说明判据能区分产品码和测试码。
(拿测试字面量当判据,会在所有节点上都报"无",看起来很整齐,实则全错。)

⇒ 原始抱怨要拆成两半:

	症状	四个节点
「输入不了 /model」	共存仲裁挡掉权限模式变更	完全相同,和版本差无关
「也不生效」	模型上报不诚实	只有通信狗修了(#605)

顺带验了三节点那份产物的来历

PROVENANCE.txt 里 installed_agent_node_sha256 = 03e9bed6…a7bb4,实测 逐字吻合 ——
三节点确实跑的是 a7865a4 那份构建,没被动过。两份 dist 差 47,655 字节。

固化成能力矩阵

grok-tui-node/scripts/runtime-which.py 现在直接打「哪个节点带哪个修复」:

通信狗   ❌#883  ❌#881  ✅#605
指挥狗   ❌#883  ❌#881  ❌#605
A站狗    ❌#883  ❌#881  ❌#605
P站狗    ❌#883  ❌#881  ❌#605
候选目录 ✅#883  ✅#881  ✅#605

🔴 记在脚本注释里的教训:commit 在不在范围里,不等于能力在不在产物里。
今晚我用 commit 范围推「有没有」推偏了两次。重排、回滚、分支线都能把两者错开。
判据只能落在产品代码的字符串字面量上 —— minify 之后标识符会改名,字面量活得下来。