# 执行

> 队列、Auto-Run、独立审查、评分、查根因、卡片、推送与定时

## 队列

*要做的事都进项目的 Bug / Feature 队列，上面记着每件事是谁提的、排在第几、做到了哪一步。*

| 来源 | 怎么进队列 |
| --- | --- |
| 对话 | 只在你明确要求时加：对话席先查有没有同一件事，再用 `queue_items` 的 create 加一条。它不会从聊天里自己识别需求入队 |
| 会议 | 录音 → 分说话人的转写 → Dev 模型提炼事项 → 你分两轮勾选 → 走同一条去重路径入队 |
| 定时任务 | 任务指令里写明要立案时，用同一个 `queue_items` create，同样去重 |
| 手动 | 在界面上直接添加，不做去重 |

### 去重

先按标题精确比对（去掉首尾空白、不分大小写）正在排队或运行的条目；再请一个判别模型做语义比对，置信度 ≥ 0.85 才算重复，每条限时 4 秒。判别模型不可用时照常入队，因为多一条重复总比丢一条需求好。拦下重复时，聊天里会说明「没有入队：X 和 Y 是同一件事」。

### 顺序与状态

每条有一个序号：新条目排队尾，可以拖动重排，Auto-Run 按这个顺序做。状态有 pending / running / done / failed / cancelled / archived；通过席位工具归档或删除，每一条都要在确认卡片上点头。

### 开跑

在队列面板上按 **Build Features** 或 **Fix Bugs**；对话席起不了运行。一次运行拿走同一类型的全部待办，跑的过程中新进来的条目也会接着做。多于一条时，先提议分组，再由另一轮对抗性地检查分组，站不住的退回一条一组。

## Auto-Run

*一键跑完一整批条目。Feature：实现 → 审查 → 评分；Bug：查根因 → 修复 → 审查 → 评分。*

### Feature

1. **implement**: Dev 席实现，补测试，在 PLAN.md 加任务块
2. **review**: 宿主起独立审查，发现回到 Dev 席
3. **grade**: 只在信号命中时起全新的评分器

### Bug

1. **bugfind**: 复现并定位根因，写进 AUDIT.md
2. **fix**: 修根因，补修前失败、修后通过的测试
3. **review**: 同上
4. **grade**: 同上

验收标准就是条目自己的标题和详情。实现 / 修复要拿出客观证据：先复现问题，加上修前失败、修后通过的测试，并在 PLAN.md 加一个带 `Item:` 和 `Verify:` 的任务块。会改变范围的决定，动手之前用一张卡片问提交人。实现、修复和所有的修补轮都在项目的 Dev 席里做；审查者和评分器是宿主另起的进程。

### 宿主 Verify

每一轮审查 / 评分开始时，以及每次修补之后，宿主亲自运行 `Verify:` 行点名的脚本（只跑它允许的脚本，每个限时 10 分钟）。脚本红了，不管模型怎么报告，这一关至少记 1 个未解决问题。结果按项目文件的指纹缓存，只改 AUDIT.md 或勾选框不会触发重跑。

### 提交

实现和修复提交但不推送；查根因和审查只提交 AUDIT.md，提交信息形如 `audit @ <sha> (#N): <结论>`。

### 中断与恢复

| 情况 | 怎么办 |
| --- | --- |
| 额度用完 | 条目回到待办，保留所在阶段。同一家还有别的账号有余量，就切过去，暂停等你点继续；没有的话，停到额度恢复的时刻自己接着跑（不知道恢复时间就等你点继续） |
| 临时错误 | 5xx、网络、引擎崩溃：30 秒、2 分钟、5 分钟三次重试，从同一阶段接着做 |
| 连续两条失败 | 整个运行暂停 |
| 暂停 / 停止 | 暂停：做完当前这条再停；停止：立即打断 |
| 服务重启 | 运行中的条目回到待办，从第一阶段重新开始（引擎的对话上下文还在）。更新、Restart services 这类正常重启之后自动接着跑；服务崩溃之后要再按一次开跑 |

> 关卡证据（基线提交、审查结论、Verify 结果、评分理由）记在运行日志里，恢复后的关卡接着用。

## 独立审查

*写代码的和查代码的不是同一个会话，默认也不是同一家的模型。*

- **谁来审**: 宿主起的审查进程，用项目设置里的 Review 模型（默认是 Codex 系模型，也可以选 Claude），限时 45 分钟
- **权限**: 只读：Codex 跑在只读沙箱里，Claude 审查只有 Read / Glob / Grep
- **审什么**: 这个条目开始以来的提交（`<base>..HEAD`），加上整个未提交的工作区
- **五个视角**: 设计对齐、横向影响、架构边界、任务真实性、代码质量
- **严重度**: critical / major / minor / nit
- **会话**: 一次运行里第一轮是全新会话，之后的轮次接着同一个审查会话

### 一轮审查之后

1. 如果没有发现，而且审查成功、覆盖完整、宿主 Verify 是绿的，这一关直接关闭，不用 Dev 席再跑；宿主在 AUDIT.md 记一行全绿并提交。
2. 如果有发现，Dev 席对照真实代码逐条核实（接受、存疑 / 推翻、审查漏掉而自己补上的），修掉必须修的和它们的同类，提交，更新 AUDIT.md，报告 `REVIEW_REQUIRED: <n>`。
3. `n` 只数这一轮结束时仍未解决的问题；大于 0 就再审一轮。
4. 两轮还没收敛，给你一张卡：继续 / 换思路 / 接受。最多四轮，之后记下现状，这一条进入下一阶段。评分关也是这两个上限。

## 评分

*评分默认跳过。信号命中时才起一个全新的评分器，它拿条目原文当验收标准，逐条找反例。*

| 信号 | 什么时候命中 |
| --- | --- |
| ① 审查 | 审查报了 critical / major，或留下未解决的必须项 |
| ② Verify | 宿主 Verify 红了 |
| ③ 敏感路径 | 改动碰到协议、schema、迁移、鉴权、token、数据库、存储一类的路径（脚本、测试、文档除外） |
| ④ 严格 | 条目标题或详情里写了 `[strict]` / `[严格]` |

评分器每次都是全新的只读 Codex 会话：拿到条目的标题、详情和命中的信号，自己拆出验收项 A1..An，再用具体反例去推翻每一项。它只做静态推理，不跑测试；提交说明和作者的解释都不给它看。

每一项给出 pass / fail、理由和反例，并归为「产品缺陷」或「防护薄弱」。产品缺陷的 fail 为 0 就关闭；大于 0，Dev 席修一轮，再重新评分。跳过时，运行日志写明原因。

## 查根因

*从症状一路追到根因，中间是一条「为什么」链，每一环都带能跑的验证命令。*

这是 Bug 的第一阶段。报告里已经写清症状和复现路径时，就在范围内复现、定位；报告含糊时，起一个独立的只读 Codex 做完整追查：多个候选原因逐个验证，防止表面归因，分清治标和治本，每一环给出验证命令。

默认还会起一个全新的反驳者专门攻击这个结论，给出 CONFIRMED / PLAUSIBLE / REFUTED。主席位把验证命令跑一遍、重新判断，把结论写进 AUDIT.md 并提交。这一步只定位，不改代码。

## 卡片、推送与定时

*需要你时它发卡片；你不在时推到手机；到点的事它自己起来做。*

| 工具 | 做什么 |
| --- | --- |
| `ask_user` | 一个问题或一组问题，带选项按钮，也可以直接打字回答；没有超时。一个聊天窗口一次只显示一张卡，其余按先来后到排队，显示「还有 N 张」 |
| `phase_gate` | 阶段门禁卡：批准 / 要求修改。只有引擎席能发 |
| `genki-push` | 给主人或项目里看得见的成员发推送（iOS + 浏览器），或约一个一次性提醒。提醒由服务器到点投递，重启不丢，也不需要谁的会话还开着 |
| `genki-cron` | 周期任务：每天、每周或每隔 N 小时。每次开一轮全新、隔离的对话（用 Dev 模型）；上一次还没跑完，这一次跳过而不排队；结果发进任务房 |

卡片弹出时会推送给该回答的人；静音了的成员不打扰。