fix(traex): 避免终端空闲提前撤销派发身份

[gofow]

问题与结果

TRAE 的 transcript 已出现 user_message、尚未出现终止事件时，PTY 的临时空闲画面仍可能进入 markPromptReady()，撤销当前回合的 managed origin 和 caller。无沙箱命令又能通过 host IPC 鉴权，派发接口因此继续发送 kickoff、返回成功，却没有写入真人身份委托；接收 Bot 执行受保护工具时才发现身份缺失。

本改动让 TRAE 使用现有结构化生命周期门禁：已开始的回合等待 task_complete（成功或失败）或 turn_aborted，中间的 assistant 文本和终端空闲不会结束回合。派发接口对需要身份委托但没有有效 turnId 的请求返回 dispatch_turn_unproven，不再静默发送缺少回合身份的任务。

变更与边界

• structured-bridge-clis.ts：将已有完整成功、失败、中断解析的 traex 加入生命周期门禁。
• daemon.ts：受保护派发必须有当前 managed turn；host IPC 鉴权不替代真人回合证明。
• 不改变凭据存储、OAuth scope、跨应用用户映射、目标群成员或工具授权检查；不使用会话 Owner、历史用户或请求正文恢复身份。普通 Bot 回合仍不会自动取得真人权限。
• 影响使用共享 Worker 逻辑的 TRAE PTY／tmux／adopt 会话；Codex 原有门禁及 RPC 活跃回合判定不变。IPC 拒绝规则适用于所有 CLI 的受保护派发。TRAE 未开始的裸 mark 不会因此永久阻塞。
• 更新多话题文档说明身份边界；无需改变 Agent Pack、模型配置或部署仓库业务代码。
• 补全 TRAE 原生改名集成测试的 rollout 生命周期：假 CLI 保持真实 rollout 文件打开并写入 user_message，测试先确认空闲画面不能提前改名，再写入 task_complete 并验证改名完成。原夹具仅有提交历史、缺少结束事件，会在新增门禁下确定性超时；不放宽生产门禁或延长超时。

验证

修复前新增用例出现 5 项预期失败：3 种终止方式下均在真正终止前释放身份，2 种来源回合缺失状态均错误返回 200。修复后：

• Node/Vitest：dispatch-user-route、dispatch-user-delegation、structured-bridge-clis、traex-transcript、worker-structured-lifecycle-status、traex-worker-bridge-wiring、daemon-topic-source，7 文件 245 项通过。
• 真实 Worker／假 CLI 的隔离 PTY 集成：traex-terminal-pty-desync.repro.integration、worker-restart-policy-capability，6 项通过（包括 tmux、重启／崩溃及能力撤销）。
• Bun 1.4.2：bun test test/dispatch-user-route.test.ts，26 项通过。
• bun run build、bun run workflow-core:test、git diff --check 通过。

CI 失败修复提交 f450587f60f246367246855dde9a0c8b1b042700 的补充验证：

• 修改前在本地复现与 CI 相同的 TRAE 改名用例超时；修改后通过。
• Node/Vitest：原有 245 项回归、普通 IM 初始化并发 7 项、PTY desync 2 项、重启与能力撤销 4 项，共 258 项通过。
• Bun 1.4.2：失败所在的 worker-ordinary-im-init-concurrency.integration.test.ts 全部 7 项通过。
• bun run build、git diff --check 通过；新提交的 完整 GitHub CI 已全部通过，包括原失败的 test (1/3) 和 bun-test；网络边界检查 同样通过。
• 该补充提交仅修正测试夹具与断言，不改变运行时行为、接口、配置或依赖，因此无需额外修改用户文档。

回归用例使用生产 markPromptReady、生命周期门禁、TRAE parser、pending queue 和 dispatch handler；平台网络／发送以测试替身替换。所有执行均在隔离目录，没有重启共享 daemon。

证据限制： 该缺陷已在本地复现并修复。线上故障记录能确认任务已发出但无身份委托，以及当时模型回合尚未完成；没有保留派发瞬间的内存快照，因此不能把这次历史故障唯一归因于该空闲分支。提交 f450587f60f246367246855dde9a0c8b1b042700 已完成开发机隔离部署与真实双 Bot 完整链路验收，用户已确认飞书最终回复；验收记录及竞态验证边界见补充评论。该验收未向真实 TRAE 确定性注入 idle 竞态，也不代表共享／生产机器人已部署或线上已恢复。

[gofow]

开发机隔离部署与真实双 Bot 验收

验证提交：f450587f60f246367246855dde9a0c8b1b042700（发布本记录时与 PR HEAD 一致）。验收时间：2026-10-13 23:56–23:57，Asia/Shanghai。

Source 使用 TRAE CLI 0.201.6 / gpt-5.6-sol，Target 使用 Codex 0.162.1 / gpt-6-astra。两个专用测试应用分别使用独立 HOME、配置、工作目录和端口，仅共享测试专用的委托数据目录；代码包传输前后 SHA256 一致，验收期间未修改 PR 源码。

真实完整链路：通过。

1. 真人仅在 Source 完成个人授权，再以真实飞书消息启动 TRAE 回合，通过 botmux dispatch --bot-app … 派给 Target。委托签名校验通过，来源应用、来源会话及真人回合、原用户身份、目标应用与目标消息均正确绑定。
2. Target 未建立独立的 bytedcli 个人授权目录。其原生 transcript 确认 Target 亲自通过 PATH 中的受保护入口执行 bytedcli --no-auto-upgrade --json auth userinfo，退出码 0、status=success、person_account，返回身份与原发起人一致；Source 未代查。
3. Target 通过 botmux report --dispatch-root … 回报 PR1876_TARGET_AUTH_OK，回执为 orchestrator-session、viaRegistry=true，返回原 Source 会话。Source 接收报告后通过 botmux send 发送 PR1876_TRAE_DELEGATION_OK，飞书发送回执成功，用户已确认实际可见且内容正确。

开发机 Linux / Bun 1.4.2 回归另有 5 个文件、178 项全部通过：派发身份委托 19 项、结构化生命周期 35 项、CLI 身份 67 项、当轮身份 50 项、普通消息初始化并发 7 项。

竞态与证据边界：

• 上述实测证明该提交的真实 CLI 业务链路有效；未向真实 TRAE 确定性注入“结构化 terminal 事件之前出现伪 PTY idle”的竞态，不能据此宣称真实环境竞态已复现或所有事件交错均已覆盖。确定性竞态证据仍来自 PR 中调用生产 Worker、生命周期门禁、parser 和 dispatch handler 的受控测试，CLI／事件时序及网络发送使用测试替身；它与真实 CLI 完整链路验收是两类证据。
• 历史故障未保留派发瞬间的内存快照，因此仍不能将其唯一归因于该 idle 分支。
• 回合结束后观察到 Source active-turn 文件为空，Target 文件仍保留该轮 ID。本次不宣称已验证所有目标凭据文件在 terminal 时清空；身份相关结论限于正确委托和实际工具调用归属。
• 这是专用测试实例验收，不代表共享／生产机器人已部署此提交；未启用文件沙盒，也不构成操作系统级恶意 Agent 隔离证明。

过程与清理： 隔离 Source 的代理例外配置修正后，模型预检通过，由用户重新发送真人任务。期间模型自行添加 --repo 的派发被权限规则正确拒绝，按不含该参数的命令重试后通过；最终回复的 --mention-back 无法解析时，模型显式提及原用户后发送成功。这些处理未修改 PR 源码或现有机器人配置。

验收结束已停止两个测试 daemon 及其 CLI：11 个匹配隔离 HOME 的进程无存活项，4 个专用端口均关闭。原有 5 个机器人相关进程仍存活，原 bots.json 和全局 botmux 入口文件哈希与验收前一致。

[deepcoldy]

你好，这个 PR 的自动评审群已建好（飞书群，机器人双评审流程）。系统按名单自动邀请时受跨租户可见性限制没能直接拉你进群。

请点击下面的链接加入评审群（一年有效，群外成员需要通过此链接申请加入）：
https://applink.larkoffice.com/client/chat/chatter/add_by_link?link_token=a11n9ef9-2894-4ccf-8c63-8ce4c584a73c

如果链接打不开，也可以把你的 GitHub 账号和飞书信息补录到名单文档，后续复审会自动拉你进群：https://bytedance.larkoffice.com/wiki/WJ1nwWbtxi89erkNGNbcgkt9nUe

（本条由 Botmux 自动巡检流程发布）

[deepcoldy]

更新：已通过内部流程把你直接邀请进评审群，无需再点上面的加群链接，在飞书里查收群邀请即可。（自动流程补拉，抱歉打扰）

[github-actions]

🚀 Released in v3.44.0