feat(lark): 支持 TraeX 统一初始化 Forge

[kin-dep]

概述

为 TraeX 机器人新增首轮统一初始化卡：用户发送首条普通消息后，在启动 worker 前一次性选择工作目录、普通 TraeX / Forge Pipeline / Forge Pilot，并可编辑初始提示词。

链接

• 技术方案：https://www.feishu.cn/docx/RMYUdYXFooX1R3xzuAfcLjEYnEc

改动

• TraeX 真人首轮消息进入 pending 初始化态，确认前不创建 worker；Bot、监听器、替身、显式 $forge-* 入口保持原直达路径。
• 单张飞书卡统一承载目标目录（已有仓库 / 新建 worktree）、手动目录、初始提示词和三种运行方式。
• Forge 模式分别编译为 $forge-pipeline\n<提示词> 和 $forge-pilot\n<提示词>，复用现有 buildNewTopicCliInput → commitRepoSelection → forkWorker 事务。
• 增加 owner、nonce、活动卡片、重复提交和输入长度校验；取消时关闭占位会话。
• 同时覆盖标准新话题和话题回复安全网两条人工首轮入口；其它 CLI、定时任务、监听器、adopt/resume 不受影响。

测试

• pnpm vitest run --project unit test/traex-initialization.test.ts test/traex-initialization-card.test.ts test/card-handler-repo-select.test.ts test/daemon-rename-route.test.ts test/card-builder.test.ts test/initial-user-turn-opening.test.ts
  • 结果：238/238 通过
• pnpm build
  • 结果：通过（domain audit、TypeScript、Dashboard bundle、dist audit）
• pnpm test
  • 结果：12221 通过；构建后复跑所有 dist 前置失败项均通过
  • 已知环境项：test/v3-distillation-runner.test.ts 的 PID namespace 辅助进程时序用例在本机稳定失败，与本次改动无依赖

覆盖场景

• ✅ TraeX 首条普通消息只返回初始化卡，不提前 fork worker
• ✅ 工作目录、运行方式、编辑后的提示词一次提交
• ✅ 普通 TraeX、Forge Pipeline、Forge Pilot 三种启动方式
• ✅ 已有仓库、新建 worktree、手动目录
• ✅ 非发起人、空提示词、过长提示词、旧卡和重复提交拒绝
• ✅ 普通新话题与话题回复安全网
• ✅ 非 TraeX 和自动化入口行为不变

影响范围

• 公共层：daemon.ts、Lark card handler、DaemonSession 运行态。
• CLI：只对 cliId=traex 的真人首轮普通消息生效；其它 20+ CLI 不进入新分支。
• 后端：最终仍走统一 worker/后端链路，不新增 PTY/Tmux/Herdr/ZMX 特殊逻辑。
• 会话：仅初始化前增加内存态；未确认提示词不持久化，daemon 重启后旧卡自然失效。

QA 回归建议

• 在有默认目录和需要选仓两种配置下，分别验证普通 TraeX / Pipeline / Pilot。
• 验证卡片一次提交后只创建一个 worker，旧卡和重复点击不重复启动。
• 验证其它 CLI 机器人、定时任务、监听器、Bot 协作消息仍按原路径直接运行。

[deepcoldy]

Codex 复审结论：Request changes

本轮重点复核了 TraeX 安全网入口、commitRepoSelection 复用，以及 worktree 两条异步分支。owner / nonce / 活动卡 / 并发门整体成立，但发现 1 个阻塞问题和 1 个窄路径问题。

🔴 P1：项目多时初始化卡超过飞书 100 KB 上限，TraeX 首轮无法启动

buildTraexInitializationCard 把全部项目先映射成目录选项，再为所有主仓库追加 worktree 选项，没有数量或字节预算。当前 checkout 的实际扫描结果已经能稳定触发：

• scanMultipleProjects(['/root', '/tmp'], 3, repoPickerScanOptions())：639 个项目，其中 81 个主仓库
• 下拉选项：720 个
• 卡片原始大小：111,956 bytes
• 经 stampBotmuxCallbackMarkers 后实际发送内容：112,004 bytes

飞书官方接口明确限制卡片内容不超过 100 KB；超过会返回 100000。这里 sessionReply 会失败，worker 又按设计尚未 fork，因此这类环境的 TraeX 真人首轮会直接卡死。现有测试 mock 了发送接口，所以 639-project 用例仍显示通过，没覆盖这个运行时失败。

建议在卡片 builder 里按最终 wire bytes做硬预算（同时给 option 数量设上限），保留当前目录/常用项目并提示可用手动目录兜底；补一个大项目列表测试，断言加 marker 后仍低于 100 KB。

官方限制：https://open.feishu.cn/document/ukTMukTMukTM/uMDO1YjLzgTN24yM4UjN

🟠 P2：thread safety-net 漏掉 !threadGrill

handleNewTopic 的 TraeX guard 有 && !workflowGrillPrompt，但无活跃会话时的 thread safety-net 没有 && !threadGrill。因此老话题里 /workflow new X 会误弹初始化卡。

展开后的 workflow prompt 并非丢失：它进入 promptPrefix；确认时又拼上输入框默认的字面 /workflow new X，Forge 模式还会夹入 $forge-*。最终是“展开后的 workflow skill prompt + 原始 workflow 命令”的语义混合。建议补 && !threadGrill 并加回归测试。

已确认无问题

• TraeX 提交先经过通用 sensitive owner 例外，再经过 operator === pending.owner === session.owner、nonce、活动卡校验。
• worktree 递归 re-dispatch 与 auto-worktree 两支都会在首次 await 前同步设置 ds.worktreeCreating = true；重复点击、普通切仓及并发 commit 会被 worktreeCreating / pendingRepoCommitInFlight 挡住。
• message listener 正常固定用当前 messageId 作新 anchor，并路由到 handleNewTopic，已有 !messageListener；它只有在注册输掉后 re-dispatch、且赢家又恰好消失的极窄竞态才可能落到 safety-net。为对称和防御性，安全网可顺手加 && !ctx.messageListener。bot 自动化则由 isForeignBot 排除。

实际验证

• pnpm build ✅
• 相关 7 个测试文件：373/373 ✅
• git diff --check 4bc7d4e8f..7a3d20ea7 ✅
• PR 当前无 CI checks

未合码，等待作者修复及申晗确认。