让几个 AI 编码工具分工认领、评审和合入任务
Viz Platform 的开发任务是按这个流程在跑的。几个 AI 编码工具各领一个角色，认领任务、写代码、评审、合入都按任务合同来，额度用完了或者进程断了，也能从检查点接着做。
需求和验收标准我来想清楚，开会话、派任务、催评审、接中断这些事，让流程自己去跑。
PROJECT EXAMPLES
照着项目文档重新画的，评审不通过会退回去重做，合入主分支的只有一个 Integrator。
项目讲解材料里的流程图，任务合同 → Worker 实现 → Reviewer 评审 → Integrator 合入，出了异常由 Inspector 发现，再找人处理。
01 / Context
一开始都是我手动开会话、派任务、催评审，中断了还得自己去接。几个工具同时改一个仓库，还得提前分好各自能改哪些文件，不然就会互相覆盖。另外模型说做完了、进程退出码也是 0，不代表验收真的过了，额度用完的时候任务停在一半，下一个会话也不知道从哪里接。
做成了什么
目前在一台 Mac 上跑，执行池会按能认领的任务自动增减 Worker，评审和合入各有常驻的角色，总控不在线也能把正常流程走完。9 月中到 10 月中的改动整理成了 0.1 到 0.6 几个版本(只是归档编号，还没正式发布过)。跨项目、跨机器的管理，还有通用的工作流引擎，都还没做。
02 / System
每个任务的依赖、能改哪些文件、怎么验收，都写在任务合同里。排程状态只有一份 JSON，加文件锁做原子修改，每次执行都有自己的 worktree、租约和检查点。
总控只管排优先级和处理例外。Worker 认领任务，做完提交一个固定的 commit，然后 Reviewer 去评这个 commit，评过了，Integrator 在副本里合并、重新跑一遍验收，再快进到主分支。Inspector 负责巡检，处理不了的就列成待办，等人来看。
每个槽位有一个 launchd 托管的 Supervisor 看着，能认领的任务多了就加 Worker，少了就减。每个任务配了一串按优先级排好的模型，某个账号额度用完或者被限流，就先暂停这个账号，换下一个模型接着跑。
03 / Decisions
Worker 提交的那个固定 commit，Reviewer 评的就是这个 commit，作者自己不能给自己写评审通过。
不管开了几个 Worker，合入主分支的只有一个 Integrator，先在独立副本里合并、重新跑验收，过了才快进。
模型说做完了、进程正常退出，都不算。得有一份验收回执，绑定了提交和命令的执行时间，而且任务集成之后才算 done。
额度用完或者进程挂了，先确认相关的进程都停了，现场留着别动，再按恢复预算从检查点接着做。说不清有没有副作用的情况，就留给人来判断。
04 / Our work
角色：这个流程是我搞的，角色合同、状态工具、执行池和模型路由都放在 Viz Platform 的仓库里。打算先在这一个项目上跑通，再看要不要做成通用的。
