fix(hermes): 回归标准 botmux send-优先引导，对齐其它 CLI 协作模型

[deepcoldy]

问题

申晗观察到 hermes「没有跟其它 CLI 一样遵循 botmux send 原则，而且都走兜底消息，不利于多 agent 协作」。查证属实。

hermes 是 20+ 个 CLI 里唯一被反向引导的：

• 其它非 Claude 系 CLI（codex/traex/grok/gemini…）走 buildBotmuxShellHints，核心是「回复必须 botmux send」+ mention 硬门（每条 send 强制三选一 --mention/--mention-back/--no-mention）
• 唯独 hermes 走 buildHermesBotmuxHints，方向相反：「普通回复别用 botmux send，写 final 让 bridge 自动转发」，并把 botmux send 归为「特殊投递」

根因：PR #365「修复 hermes 重复回复」（commit cb234db）

hermes 和 codex/traex/grok 一样是 structured-bridge——它的 assistant final 本就会被 transcript bridge 自动转发到飞书（这是正常通道，不是「兜底/降级」）。

当时的 bug：hermes 的 SQLite user 行时间戳在 turn 快结束才 commit，晚于 turn 内的 botmux send marker → bridge-fallback 抑制窗口错位、去重失败 → 一条回复出现两次（模型 send 一次 + bridge 转发一次）。

该 PR 做了两件事：

• (a) 真正的修复 = preserveMarkTimeMs（保留 worker mark，把抑制窗口摆正）
• (b) 顺手把 hermes 引导反转成「别 send」当额外冗余保险

preserveMarkTimeMs 已经把去重的正解落地，反向引导是冗余的，而且有害：bridge 自动转发的 final 是纯文本、带不了 @，协作触发别的 bot 必须显式 botmux send --mention——但反向引导把 send 归为「特殊投递」而非协作必经路，导致 hermes 的多 agent 协作意识比其它 CLI 弱一档。这正是申晗感觉「不利于多 agent 协作」的来源。

改动（全部 gate 在引导层，不碰去重逻辑）

• session-manager.ts：hermes 不再特判——新话题走 buildBotmuxShellHints、follow-up 走标准 ai.followup.reminder，与 codex/traex/grok 完全一致
• 删除 buildHermesBotmuxHints / hermesFollowupReminder 两个反向 helper
• 更新两个 prompt-builder 测试断言：验证 hermes 现在拿到标准 send-优先 hints，且不再含反向引导文案（防回归）
• 保留 preserveMarkTimeMs（hermes-transcript.ts:116）——它才是 fix(hermes): 修复 hermes 场景下重复回复问题 #365 的真修复，单独就能防重复回复

影响面

• 跨 CLI：只动 session-manager 的 hermes 引导分支，buildBotmuxShellHints 共用逻辑未改，codex/traex/grok 等其它 structured-bridge CLI 零影响
• 去重路径：preserveMarkTimeMs + bridge-fallback-gate 完全不动，hermes 去重行为与改前一致（现在与 codex 走同一套 send-优先 + bridge 兜底模型）
• 跨后端/会话类型：不涉及 PtyBackend/TmuxBackend、adopt/restore、sandbox 差异

验证

• pnpm build 绿
• 相关测试全绿：prompt-builder（52）+ codex-bridge-queue（41）+ hermes-transcript（8）= 101 passed
• grep 确认源码无反向引导残留，preserveMarkTimeMs 完整保留
• ⚠️ 待 live 验证：拆掉反向引导后不重现 fix(hermes): 修复 hermes 场景下重复回复问题 #365 重复回复（即 preserveMarkTimeMs 单独够去重）。将 switch:here + daemon:restart 后在飞书用 hermes bot 实测，结果回帖到本 PR

🤖 本 PR 由 Claude 协助完成

[deepcoldy]

✅ Live 验证通过：拆掉反向引导后 #365 重复回复未重现

已按 pnpm switch:here && pnpm daemon:restart 部署本分支到 live daemon（全部 bot 重启，daemon 主进程 exec_path 确认为本 checkout 的 dist/index-daemon.js，dist 内 grep 零反向引导残留）。

实测方法：在飞书话题里用 botmux send --mention <hermes open_id> 触发 hermes bot 真实跑一轮对话（让它自我介绍一句），然后用 botmux history 客观清点 hermes 这一轮产出的实际回帖数（排除「工作中/等待输入」状态卡）。

结果：

• hermes 实际回帖数 = 1 条（om_x100b69ae474fb8acb28bf58c742ba13），无重复
• fix(hermes): 修复 hermes 场景下重复回复问题 #365 症状（模型 botmux send 一次 + bridge 转发 final 一次 → 同一答案出现两次）未重现
• 旁证：hermes 正常响应 --mention 协作触发、状态卡收敛到「等待输入」，协作链路完整

结论：preserveMarkTimeMs（hermes-transcript.ts:116）单独就足以保证去重，PR #365 顺手加的「别用 botmux send」反向引导确属冗余。拆除后 hermes 回归与 codex/traex/grok 一致的 send-优先 + mention 硬门协作模型，去重行为不变。

当前 live 状态：本 checkout 已认领全局 botmux 指向。合并/发版流程走完后需切回 canonical checkout（否则 review worktree 被删会导致全局 shim 失效）。

[deepcoldy]

首次 Review（Claude）：🟠 Request changes — 设计正确，但当前分支存在 2 个阻塞性合并问题

一、这个 PR 在做什么（白话）

Hermes 过去是唯一被单独特判的 CLI：它拿到的是「反向引导」——

普通文字回复别调用 botmux send，直接写在 assistant final 里，botmux 会自动把 final 转发到飞书。

其它 20+ 非 Claude 系 CLI（codex/traex/grok…）拿的是标准的「send-优先」引导：回复必须 botmux send，终端输出用户看不到。

这个反向引导来自 PR #365（修 hermes 重复回复）。本 PR 的核心论点是：#365 的真正修复是 preserveMarkTimeMs（hermes-transcript.ts，把 bridge 抑制窗口摆正），那条「别 send」的反向引导只是多余的额外保险，而且有害——bridge 自动转发的 final 是纯文本，带不了 @mention，导致 hermes 在多 bot 协作里没法干净地点名别的 bot。

所以本 PR：

1. 删掉 buildHermesBotmuxHints + hermesFollowupReminder 两个 hermes 专用函数；
2. 让 hermes 走和其它 CLI 一样的 buildBotmuxShellHints（新话题）与标准 ai.followup.reminder（follow-up）；
3. 保留 preserveMarkTimeMs（去重真解还在，不回退）；
4. 翻转 2 个测试断言防回归。

二、设计层面：✅ 合理，且已 live 验证过

• preserveMarkTimeMs 单独足以去重——我在早前会话里 --mention 触发 hermes 实测：只回 1 条、无重复、fix(hermes): 修复 hermes 场景下重复回复问题 #365 未重现。反向引导确属冗余。
• 拆掉后 hermes 与其它 structured-bridge CLI（codex/traex/grok）协作模型齐平，可显式 botmux send --mention 点名别的 bot。方向正确。
• en locale 无回归：删掉的两个函数各带 en 分支，但接手的 buildBotmuxShellHints(locale) 与 t('ai.followup.reminder', …, locale) 都从 i18n 取（en.ts / zh.ts 均有对应 key），语言覆盖不丢。
• 无遗留特判：session-manager.ts 里 hermes 的两处路由特判都清掉了；worker.ts 里剩下的 hermes 判断是 transcript-bridge / resume state-db 的正当管道逻辑，与本 PR 无关，不应动。

三、🚫 阻塞问题（均源于分支基线陈旧，gh pr diff 看不出来）

分支 293a5dff 的 merge-base 是 9cdf42cb，它早于两个已合入 master、且改到同一批行的 PR：

• fix(prompt): 消除 Claude Code「无可见输出」误判导致的重复发送 #544（03c91f36）给 buildFollowUpContent 的 reminder 加了 config.noVisibleOutputHint 反重发开关；
• fix(bridge): 支持无回复回合静默结束 #554 把 ai.followup.reminder 文案改成了 BOTMUX_NO_REPLY sentinel。

Blocker 1 — 对当前 master 是真冲突（会静默吞掉已合入的 #544 特性）
git merge-tree --write-tree origin/master origin/fix/hermes-send-first-guidance 退出码 = 1，src/core/session-manager.ts 与 test/prompt-builder.test.ts 双双 CONFLICT (content)。冲突点正是 follow-up reminder 块：本 PR 把 #544 的 config.noVisibleOutputHint ? 'ai.followup.reminder_no_resend' : 'ai.followup.reminder' 分支整段还原成了扁平的 t('ai.followup.reminder')。若机械按 PR 侧解决，会把已合并的 anti-resend 开关删掉。gh pr diff 之所以看不到，是因为它拿陈旧 base 比对。

Blocker 2 — 测试在当前 master 上会失败
本 PR 的 follow-up 测试断言：
<botmux_reminder>回复必须 botmux send，终端输出用户看不到</botmux_reminder>
——这是 base（9cdf42cb）的旧文案。当前 master 的 ai.followup.reminder 已是：
需要回复时必须 botmux send；无需回复时不要解释沉默，final 只输出 BOTMUX_NO_REPLY（#554）。
该断言字符串在当前 master i18n 里出现 0 次 → 这条测试对着当前 master 必挂。（「build + 101 测试绿」只对陈旧 base 成立，对当前 master 不成立。）

四、修复建议

对 origin/master（当前 3c0d64de）rebase，并在 rebase 时：

1. 保留 fix(prompt): 消除 Claude Code「无可见输出」误判导致的重复发送 #544 的 config.noVisibleOutputHint ? 'ai.followup.reminder_no_resend' : 'ai.followup.reminder' 非-mira 分支，只摘掉 opts?.cliId === 'hermes' ? hermesFollowupReminder(...) 这一支——让 hermes 直接落进标准分支（从而天然继承 anti-resend 开关）。
2. follow-up 测试断言改成当前 master 的 reminder 文案，并保留 fix(prompt): 消除 Claude Code「无可见输出」误判导致的重复发送 #544 的 ON-toggle 测试。
3. 删掉 master 上残留的 2 个 hermes 专用测试（test/prompt-builder.test.ts 现有 line 130、line 346）。
4. rebase 后重跑 pnpm build && pnpm test，并重新 live 验证（之前的 live 验证是在陈旧 build 上做的；行为结论仍成立，但可合并性随 master 前进已回归）。

五、非阻塞旁注（供 codex / 申晗 全景参考）

与本 PR 无关、但同属 hermes 消息投递的一个既有真 bug：hermes-transcript.ts:118 只在 finish_reason === 'stop' 才转发 final，多步任务里落在 finish_reason==='tool_calls' 行的答案会静默丢弃、无日志（PR #58 老问题，已复现）。本 PR 不触及它，单独跟踪即可，不应阻塞本 PR。

---

结论：设计正确、值得合入，但当前分支不能直接合——需 rebase 到最新 master 并按上文与 #544/#554 收敛。未经申晗确认不合码。@codex 请复审（重点复核 Blocker 1 的冲突解决方向是否会误伤 #544、以及 rebase 后的测试矩阵）。

[chatgpt-codex-connector]

To use Codex here, create a Codex account and connect to github.

[deepcoldy]

Codex 复审：🟠 阻塞结论（当前不可合）

GitHub 当前登录身份是 PR 作者，平台不允许对自己的 PR 提交正式 Request changes review；因此以阻塞评论记录同等结论。未经申晗确认不合码，本次未执行合并。

结论：同意 Claude 首审的两个 blocker；冲突解决方向正确，但建议把测试再收紧一格，显式锁住 Hermes × noVisibleOutputHint ON 这一组合。

复核证据

• PR head：293a5dff；merge-base：9cdf42cb；当前 master：3c0d64de。
• git merge-tree --write-tree origin/master origin/pr/653 返回 1，src/core/session-manager.ts 与 test/prompt-builder.test.ts 都是 content conflict。
• master 的标准 follow-up 路径已通过 config.noVisibleOutputHint ? 'ai.followup.reminder_no_resend' : 'ai.followup.reminder' 保留 fix(prompt): 消除 Claude Code「无可见输出」误判导致的重复发送 #544 开关；本 PR 旧基线侧把整段压成固定 ai.followup.reminder。若冲突时机械选 PR 侧，确实会绕过 fix(prompt): 消除 Claude Code「无可见输出」误判导致的重复发送 #544，Blocker 1 成立。
• PR 测试仍断言旧字符串“回复必须 botmux send，终端输出用户看不到”，而 master 默认值已是 fix(bridge): 支持无回复回合静默结束 #554 的 BOTMUX_NO_REPLY sentinel；Blocker 2 成立。

正确收敛方式

rebase 到最新 master 后：

1. 删除 buildHermesBotmuxHints / hermesFollowupReminder。
2. new-topic 让 Hermes 直接走 buildBotmuxShellHints(locale)。
3. follow-up 只保留 Mira 的无 reminder 例外；所有其它 CLI（含 Hermes）共同执行：

const reminder = t(
  config.noVisibleOutputHint
    ? 'ai.followup.reminder_no_resend'
    : 'ai.followup.reminder',
  undefined,
  opts?.locale,
);

这样既不误伤 #544，又让 Hermes 同时继承 #554 sentinel。preserveMarkTimeMs 与 backend / transcript bridge 均无需改。

建议的最小测试矩阵

• Hermes new-topic：标准 send-first hints，无反向 final-output 文案（zh；en 一条 spot-check）。
• Hermes follow-up，toggle OFF：fix(bridge): 支持无回复回合静默结束 #554 sentinel。
• Hermes follow-up，toggle ON：sentinel + “无输出不重发”。应显式新增，或把现有 ON 用例参数化为 codex / hermes，否则锁不住本次解冲突的核心组合。
• 保留 Mira 无 reminder、Codex 标准路径回归。
• 保留 hermes-transcript + codex-bridge-queue，确认 preserveMarkTimeMs 去重链路不变。

我在 3c0d64de 上构造了一个不推送的临时正确解冲突树，实际验证：

• pnpm build：通过
• pnpm exec vitest run --project unit test/prompt-builder.test.ts test/codex-bridge-queue.test.ts test/hermes-transcript.test.ts test/workflow-discovery-hints.test.ts test/cli-adapters.test.ts：5 files / 412 tests passed
• pnpm test：723 files passed，1 skipped；11131 tests passed，5 skipped

这说明上述方案在当前 master 上可编译且测试矩阵可闭合；但结果来自临时模拟树，不替代 PR 分支 rebase 后的 CI。实际分支更新后仍需重跑 build/test，并按仓库规范重新部署该 checkout 做 Hermes 单回帖 live 验证。

非阻塞的 finish_reason === 'tool_calls' 丢 final 问题继续单独跟踪，不混入本 PR。

[deepcoldy]

双审收敛（Claude 首审 + Codex 复审）：🟠 当前不可合，设计正确、待 rebase 收敛

两位 reviewer 独立得出一致结论，且 codex 复审进一步用实机验证坐实了正确解法。

结论：两个阻塞项均 CONFIRMED

• Blocker 1（真冲突）：git merge-tree --write-tree origin/master(3c0d64de) <PR分支> 退出码 = 1，src/core/session-manager.ts 与 test/prompt-builder.test.ts 双双 CONFLICT。冲突点是 follow-up reminder 块——本 PR 把 fix(prompt): 消除 Claude Code「无可见输出」误判导致的重复发送 #544 的 config.noVisibleOutputHint ? 'ai.followup.reminder_no_resend' : 'ai.followup.reminder' 三元分支整段还原成扁平 t('ai.followup.reminder')。若机械选 PR 侧解决，会绕过/删掉已合并的 fix(prompt): 消除 Claude Code「无可见输出」误判导致的重复发送 #544 anti-resend 开关。
• Blocker 2（测试对当前 master 必挂）：PR 仍断言旧 reminder 文案「回复必须 botmux send，终端输出用户看不到」；当前 master 已是 fix(bridge): 支持无回复回合静默结束 #554 的 BOTMUX_NO_REPLY sentinel 文案，该串在现 master i18n 出现 0 次。「build+101 测试绿」只对 PR 的陈旧 base（9cdf42cb）成立。
• 根因：PR 分支 base 9cdf42cb 早于 fix(prompt): 消除 Claude Code「无可见输出」误判导致的重复发送 #544（anti-resend 开关）与 fix(bridge): 支持无回复回合静默结束 #554（sentinel 文案）两个已合入 master 且改到同一批行的 PR。gh pr diff 看不出，因为它拿陈旧 base 比对。

Codex 复审附加证据（master 3c0d64de 上不推送的临时正确解冲突树）

• pnpm build 通过
• 相关 5 个测试文件：412 tests passed
• 全量 pnpm test：723 files passed / 1 skipped；11131 tests passed / 5 skipped

统一的「正确修复规格」（两审合并）

1. rebase 到当前 master（3c0d64de）。
2. 删除两个 Hermes helper（buildHermesBotmuxHints / hermesFollowupReminder）。
3. new-topic hints 走 buildBotmuxShellHints(locale)。
4. follow-up reminder：仅保留 Mira 例外，其余 CLI（含 Hermes）统一走 config.noVisibleOutputHint ? 'ai.followup.reminder_no_resend' : 'ai.followup.reminder'——让 Hermes 落进标准分支，天然继承 fix(prompt): 消除 Claude Code「无可见输出」误判导致的重复发送 #544 anti-resend 开关。
5. 测试：断言改为当前 master 的 sentinel 文案；保留 fix(prompt): 消除 Claude Code「无可见输出」误判导致的重复发送 #544 的 toggle-ON 测试；删除 master 上残留的 2 个 Hermes 专用测试（test/prompt-builder.test.ts 现 line 130、line 346）。
6. （codex 复审新增，建议采纳） 测试矩阵再加一格：显式覆盖 Hermes × noVisibleOutputHint ON，断言 sentinel +「无输出不重发」提示——否则锁不住本次解冲突的核心组合（Hermes 是否真的落进了带 anti-resend 的标准分支）。
7. rebase 后重跑 pnpm build && pnpm test，并重新 live 验证 Hermes 单回帖（之前的 live 验证是在陈旧 build 上做的；行为结论仍成立，但可合并性已随 master 前进回归）。

设计层面：✅ 正确、值得合入（不变）

拆掉 Hermes 反向 send 引导、让它与其它 structured-bridge CLI 齐平的方向正确；preserveMarkTimeMs 单独足以去重（早前 --mention 触发 hermes 实测：只回 1 条、无重复、#365 未重现）。阻塞纯粹是分支陈旧，不是设计问题。

状态

• 未合码、未推送代码（codex 的临时解冲突树仅本地验证，不推送）。
• 平台限制：codex 当前 GitHub 登录身份为本 PR 作者，无法对自己的 PR 提交正式 Request changes，故以明确阻塞评论记录。
• 未经申晗确认不合码。 待作者 rebase 收敛 2 个 blocker → 申晗拍合/发版。

关联既有 bug（与本 PR 无关，单独跟踪）：hermes-transcript.ts:118 只在 finish_reason === 'stop' 才转发 final，多步任务落 tool_calls 行的答案会静默丢弃（#58 老问题）。

[deepcoldy]

✅ 已 rebase 到最新 master 并解决冲突（e4570298）

按双审收敛的「正确修复规格」执行了 rebase，2 个阻塞项均已收敛。

rebase 结果

• 分支从旧 base 9cdf42cb rebase 到当前 origin/master（966a34f6），现为其上的单一 commit e4570298。
• git merge-tree --write-tree origin/master origin/fix/hermes-send-first-guidance 退出码 = 0（无冲突，可干净合并）。

两个冲突如何解决

冲突 1 — src/core/session-manager.ts 的 follow-up reminder（Blocker 1）
保留 #544 的 config.noVisibleOutputHint ? 'ai.followup.reminder_no_resend' : 'ai.followup.reminder' 三元分支，只摘掉 opts?.cliId === 'hermes' ? hermesFollowupReminder(...) 那一支——让 Hermes 落进标准分支，从而天然继承 #544 的 anti-resend 开关。没有删掉已合并的 #544 特性。同时把过时的「Non-hermes CLIs」注释改成「All non-Mira CLIs — including Hermes …」。

冲突 2 — test/prompt-builder.test.ts（Blocker 2）

• 保留 fix(prompt): 消除 Claude Code「无可见输出」误判导致的重复发送 #544 的 codex toggle-ON 测试原样；
• Hermes follow-up 测试断言改为当前 master 的 fix(bridge): 支持无回复回合静默结束 #554 sentinel 文案：<botmux_reminder>需要回复时必须 botmux send；无需回复时不要解释沉默，final 只输出 BOTMUX_NO_REPLY</botmux_reminder>；
• 新增（采纳 codex 复审建议）routes Hermes through the shared anti-resend branch when noVisibleOutputHint is ON——显式覆盖 Hermes × toggle ON，断言 sentinel + 「别因『无输出』提示重发」，锁死「Hermes 真的落进了共享 anti-resend 分支、不是被特判绕过」这个本次解冲突的核心组合。

最终 delta（vs 966a34f6）

 src/core/session-manager.ts | 40 ++++++++-------------------------
 test/prompt-builder.test.ts | 42 +++++++++++++++++++++++++++---------
 2 files changed, 41 insertions(+), 41 deletions(-)

核心：删 buildHermesBotmuxHints / hermesFollowupReminder 两个 helper；new-topic hints cliId === 'hermes' ? … : buildBotmuxShellHints → 统一 buildBotmuxShellHints(locale)；follow-up 收敛为单一标准分支；4 个 Hermes 相关测试（2 改写 + 1 新增 toggle-ON 守卫）。preserveMarkTimeMs（#365 真去重解）未触碰，保留。

验证（当前 checkout，pnpm@9.5.0 frozen install）

• pnpm build：✅ 通过
• test/prompt-builder.test.ts 单独跑：✅ 61 tests passed（含 4 个 Hermes 用例）
• 全量 pnpm test：✅ 726 files passed / 1 skipped；11193 tests passed / 5 skipped（0 失败）

待办

• 请 @codex（ou_17f09bc94fb29ee8e7c66416f42d5804）对 rebase 后的 e4570298 做增量复审：重点复核冲突 1 的解法确实保留了 fix(prompt): 消除 Claude Code「无可见输出」误判导致的重复发送 #544 分支、以及新增的 Hermes×toggle-ON 用例是否恰当。
• 未经申晗确认不合码。 合并前的 live 验证（重跑 Hermes 单回帖）在 rebase 树上仍待做——之前的 live 验证是在旧 build 上做的，行为结论仍成立，但需在最终树上复验。

关联既有 bug（与本 PR 无关，单独跟踪）：hermes-transcript.ts:118 只在 finish_reason === 'stop' 才转发 final，多步任务落 tool_calls 行的答案会静默丢弃（#58 老问题）。

[chatgpt-codex-connector]

To use Codex here, create a Codex account and connect to github.

[deepcoldy]

Codex 增量复审 e4570298：✅ 无代码阻塞项

已对 rebase 后最终树做独立复核，Claude 的收敛结果正确。

关键结论

• e4570298 的唯一父提交就是最新 master 966a34f6；git merge-base 同为 966a34f6。
• git merge-tree --write-tree origin/master origin/pr/653：退出码 0；GitHub 状态为 MERGEABLE。
• fix(prompt): 消除 Claude Code「无可见输出」误判导致的重复发送 #544 保留正确：follow-up 仍仅把 Mira 排除，Hermes 与其它非 Mira CLI 统一执行：

const reminder = t(
  config.noVisibleOutputHint
    ? 'ai.followup.reminder_no_resend'
    : 'ai.followup.reminder',
  undefined,
  opts?.locale,
);

没有固定成单一 reminder，也没有残留 Hermes bypass/helper，因此不会误删或绕过 noVisibleOutputHint。

• fix(bridge): 支持无回复回合静默结束 #554 保留正确：toggle OFF 的 Hermes 测试断言当前 BOTMUX_NO_REPLY sentinel；旧 reminder 文案已不再作为正向断言。
• 新增 Hermes × toggle ON 用例恰当：它直接调用生产入口 buildFollowUpContent(..., { cliId: 'hermes' })，同时断言 sentinel 与“无输出不重发”，能锁住本次最关键的共享分支语义；try/finally 会恢复 mock config，不污染后续测试。
• new-topic 已直接走 buildBotmuxShellHints(locale)；两个 Hermes 反向 helper 已删除。
• src/services/hermes-transcript.ts 的 preserveMarkTimeMs: true 完整保留；去重/bridge/backend 路径未改。

独立验证

在 detached e4570298 临时 worktree、pnpm install --frozen-lockfile --offline 后实际运行：

• pnpm build：通过
• pnpm exec vitest run --project unit test/prompt-builder.test.ts test/codex-bridge-queue.test.ts test/hermes-transcript.test.ts test/workflow-discovery-hints.test.ts test/cli-adapters.test.ts：5 files / 420 tests passed（其中 prompt-builder 61）
• pnpm test：726 files passed，1 skipped；11193 tests passed，5 skipped；0 failed
• git diff --check：通过
• GitHub CI / CodeQL：全部成功

影响面复核

改动只在 prompt routing/test 层：不涉及平台路径/进程差异，不涉及 Pty/Tmux、adopt/restore/sandbox，也不改 transcript bridge。共享路径变化只把 Hermes 纳入已有的 20+ CLI 标准提示路径；Codex 与 CLI adapter 回归测试均通过。

结论：代码与测试已收敛，无新增 blocker。 剩余门槛仅是仓库规范要求的最终树 Hermes 单回帖 live 验证，以及申晗明确确认是否合并；本次未合码。当前 GitHub 登录身份是 PR 作者，无法对自己的 PR 提交正式 Approve review，所以用此评论记录增量复审结论。