卡不等于分支：我用 TRAE 宝配合 Hive 跑三张任务卡的一天
一、场景：一张卡就是一个任务
项目组有一套自建的 Hive，用来做任务发放与流转，网页端就能看板。它的基本单位是"卡"：一张卡就是一个任务，卡上写死执行契约------允许修改哪些 paths、verify 命令是什么、租约多久、失败策略怎么走。
Hive 通过 MCP 接进了本机的 TraeCode。我这边用 TRAE 宝（TraeCode 里的 AI 助手）当"派活 + 汇总"的角色：看契约、开独立会话、收结果、做判断。真正干活的是被派出去的独立会话，每张卡一个会话、一个 worktree，互不干扰。
11 月 2 日这天，同时发了三张卡：light 仓的 CI、light 的 smoke 脚本、lightmem 的 smoke 脚本。下面按卡讲，重点放在踩的坑。
二、T-0234：让 CI 真跑起来，然后它真的红了
这张卡的契约很窄：只允许改 .github/workflows/ci.yml，verify 是 test -f .github/workflows/ci.yml，60 分钟内没完成就放弃。
执行会话在 .hive\wt\trae-win\T-0234（分支 task/T-0234）里重写了 workflow。改动都落在同一个文件里：补 permissions: contents: read、加 concurrency、用 PYTEST_ADDOPTS 让 PR 跳过 slow、把计时起点挪到 setup-python 之后（干净 runner 上原来第一步就红）、修正 R125 分仓后失效的 lightpub 测试路径、补三道 G9 度量门禁、把预算从 600/1200s 放宽到 1800/3000s。actionlint 校验通过，GitHub 上确实产生了真实 run。
然后 CI 红了：unit 层 12 failed + 7 errors。拆开看是两层：一层是仓库态测试本身的失败，一层是 sibling 仓 lightharness 不在环境里。两者都不在本卡允许的 paths 内，按契约不能越界去修。
提交也不顺。hive_submit 时 git push 被仓库的 pre-push 门禁拦下：假绿断言基线告警、sibling 缺失、worktree 里没有 .venv。这里没有用 --no-verify 绕------绕过去只是把问题推给下一个看日志的人。
所以这张卡最后没有硬报 done，而是回写了 blocked，把两层根因写清楚，另外开了一张治理卡 T-0241 去治这个真红。
真正麻烦的是交付：169c7599 这个 commit 只存在本地，不在任何远端，主控拿不到。执行方于是把 ci.yml 全文逐字贴出来，附上字节数、行数、sha256 和 git blob（a1395f8cf4daa4263edd19b162c6b95dedf45bf9），由主控原样落库。这是这天最有价值的一条经验：推不上去的时候，"我改好了"等于零交付，全文加指纹才是可验证的交付物。
三、T-0235：52 行脚本，和一个 165 秒的钩子
契约同样只允许一个文件：scripts/smoke.sh，verify 是 test -x scripts/smoke.sh。
产物是 52 行 POSIX sh，一条命令回答"装好了没有"：版本 + Hello World 两条判据，成功和失败两路都有明确输出和退出码。commit 23b7556，推 task/T-0235，hive_submit 成功、状态 done。随后 git merge --no-ff 合入 main 并推送（4be264311..15c5f3d60），pre-push 钩子原样跑过、没有冲突。
坑在出口。Windows 上 pre-push 门禁里的 pytest --collect-only 要跑约 165 秒，超过 MCP 的 120 秒网络超时，push 反复超时；Windows cmd 也不认 test -x。处理方式不复杂：先把钩子里的门禁逐条手工跑一遍，确认没问题，再用本地垫片完成这次推送，事后清理干净。钩子是拿来过的，不是拿来关的。
四、T-0236：卡死在 claim 这一步
这张卡和 T-0235 契约一样，但备注里特意提醒：Windows 上 head/grep/awk 和 !/$() 不可用，POSIX 判据会 exit 255 造成假失败，别先怀疑产物；跑不了就换一台内网 FreeBSD 15.1 机器走 ssh，密码从 .env 取，尾部带空格要先 strip。
结果这张卡根本没领到。hive_claim 直接报：agent trae-win 没有配置仓库 'lightmem' 的本地路径。查下来，这个 agent 只登记了 hive / lightharness / light 三个仓。"不动 agents 配置"是明令禁止项，所以停在这里，没有自作主张去改。卡仍然是 ready、owner 为空------把阻塞原样交回给人。
五、踩坑与经验
1. 卡不等于分支。 分支推上去了、代码写完了，都不等于任务完成。done 的唯一依据是 verify 真过。判据在本环境下不可达时，正确动作是回写 blocked 并写清根因，而不是把"文件存在"凑成"任务完成"。T-0234 的 verify 其实只检查文件存在，真要硬凑太容易了，但这张卡的意义就没了。
2. agent 配置的仓库登记是隐性前置条件。 缺一行 "lightmem": "..."，整张卡就卡在 claim 一步，连执行的机会都没有。这类阻塞要快报：试一次、看到明确报错、停手，别反复重试。
3. 跨平台审查会让 POSIX 判据假失败。 Windows 上 test -x、test -f 的语义并不存在，exit 255 往往是环境问题而不是产物问题。正确做法是先证明脚本本身 POSIX 兼容，再上真 POSIX 机器验；最差也要在交付说明里标注"未在真 POSIX 验过"，不许伪装成通过。
4. 出口门禁会拦住"看似成功"的提交。 假绿断言、缺 sibling、缺 venv 都可能被 pre-push 拦下。不要用 --no-verify 绕，先人工把门禁跑一遍，确认到底是哪一条在响。
5. commit 只在本地，等于主控拿不到成果。 远端推不上去时，交付方式是贴全文 + 给指纹（字节数 / 行数 / sha256 / blob），让对方原样落库。只给一句"我改好了"，价值为零。
6. 失败归因别一顶帽子扣到底。 把"仓库态失败"拆成真回归、环境缺件放大、跨仓漂移、未定四类，各自给依据。同一批用例在缺 sibling、缺 venv 的环境里会从 19 条放大到 40 条------环境口径本身就在放大失败面，不拆开就永远归错因。
7. 并行调度要"一卡一会话"。 三张卡各开独立会话、独立 worktree，互不干扰。同一件事的后续（比如"合并 0235"）回到原会话，不重复开新会话重新摸索------上下文本身就是成本。
8. 人的位置。 AI 负责执行与汇报；判据不可达时的取舍------挂 blocked 还是继续硬推、要不要动配置------留给人一句话决定。这天 T-0236 就是靠这条停住的。
六、可复用的工作流
| 阶段 | 要做的事 | 判断点 |
|---|---|---|
| 派卡 | 读契约：paths、verify、租约、失败策略 | 目标是否在本环境可达 |
| 领卡 | 确认 agent 是否登记了对应仓库 | claim 报错即停，不重试 |
| 执行 | 独立会话 + 独立 worktree，只改允许的 paths | 越界即停，先报再问 |
| 出口 | 手工跑一遍 verify 与 pre-push 门禁 | 不用 --no-verify |
| 交付 | verify 过则 done；不过则 blocked + 根因 | 推不上去就贴全文 + 指纹 |
| 合并 | 回原会话做 merge --no-ff 并再推一次 |
钩子原样跑过才算完 |
七、收尾
一整天下来，三张卡里只有一张真正 done，一张 blocked，一张连领都没领到。按"完成率"看不太好看，但三张卡的状态都是诚实的：没有假绿，没有硬凑的 done，也没有绕过门禁的提交。
对我来说，这套配合真正有价值的地方不是"AI 能改代码"，而是它把每一步的判断都落到了可查的证据上------verify 的输出、门禁的报错、commit 的指纹、卡上的 blocked 理由。人需要做的，是在这些证据面前做那一次取舍。
本文记录的是 2026-11-02 的真实流水，数字与 commit 均来自当天的任务卡和终端输出；文中未包含任何密码、token 或具体内网地址。