orchestrate

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Orchestrate (dev-loop driver)

编排（开发循环驱动者）

One orchestrator session: preflight, select, drive one spec end to end, tear down, report - and at a closed-spec seam with real context headroom, optionally roll into the next. Roles are fixed. You (the agent running this skill, in whatever harness) are the driver: you groom, gate, land, push, and own every tracker write. The implementer is always a fresh session at token-zero on your harness's native subagent mechanism - whichever harness drives runs the takes; only an explicit invocation-time request routes them through an external runner (see The take). Grooming breakdowns come from a fresh subagent of your own harness - one session shapes spec, another builds to spec, and review never leaves you.

The loop's semantics ship with this skill at references/dev-loop-protocol.md - read in place, never copied into projects. The project's contract is

docs/agents/dev-loop.md

: its declarations only (ports, scripts, gate proofs, deliberate deviations); on conflict the contract wins. Tracker mechanics are

docs/agents/issue-tracker.md

. Read protocol and contract before the first write. No contract file → stop and point at references/dev-loop-declarations.md to scaffold one, rather than guessing. The tracker is the loop's only memory: a session can die at any point, and the next one recovers from tracker state alone.

一次编排器会话：预检、选择、端到端驱动一个spec、清理、报告——在已完成spec的衔接点且仍有足够上下文空间时，可选择进入下一个spec的流程。角色固定。你（运行此技能的Agent，无论使用何种harness）是driver：你负责梳理、管控、落地、推送，并拥有所有追踪器的写入权限。 implementer始终是基于你的harness原生子Agent机制启动的全新token-zero会话——无论使用何种harness，都由它来执行take；只有显式调用请求才会通过外部运行器路由take（参见《任务执行》）。梳理分解工作由你的harness的全新子Agent完成——一个会话负责定义spec，另一个负责根据spec构建，而审核环节始终由你掌控。

循环的语义规则随此技能一同发布在references/dev-loop-protocol.md中——请直接阅读该文件，不要复制到项目中。项目的契约文件为

docs/agents/dev-loop.md

：仅包含声明内容（端口、脚本、管控证明、刻意偏差）；若出现冲突，以契约文件为准。追踪器机制定义在

docs/agents/issue-tracker.md

中。首次写入前请阅读协议和契约文件。若没有契约文件，请停止操作并指向references/dev-loop-declarations.md来生成一个，不要自行猜测。追踪器是循环的唯一记忆：会话可能随时中断，下一次会话仅从追踪器状态恢复。

Invocation

调用方式

The no-arg form is canonical: run the session-start procedure and take what it selects. A spec argument is a human override that picks among legal choices only: refuse a blocked or claimed spec, and an open

fix-main

ticket still outranks it. One spec at a time, never a guaranteed deliverable - a session may fix main, clear a standalone ticket, only groom, or exit mid-board at a ticket boundary. A closed spec is a continuation seam: when real context headroom remains, the session may re-run selection and roll into the next spec - one spec remains the normal session; continuation is the exception headroom earns, and never starts a spec the session might not finish gating. Every continuation is declared in its reports (see Session end).

无参数形式为标准调用：运行会话启动流程并处理选中的任务。传入spec参数是人工覆盖操作，仅能选择合法选项：拒绝已阻塞或已被认领的spec，且未处理的

fix-main

工单优先级始终更高。一次仅处理一个spec，不保证交付结果——会话可能修复main分支、处理独立工单、仅完成梳理工作，或在工单边界中途退出。 已完成的spec是衔接节点：当仍有足够上下文空间时，会话可重新执行选择流程并进入下一个spec的处理——处理一个spec是常规会话流程；衔接是上下文空间充足时的例外情况，且绝不会启动会话可能无法完成管控的spec。每次衔接操作都需在报告中声明（参见《会话结束》）。

Session start

会话启动

Per the contract's session-start procedure, in order:

Workspace preflight - a dirty tree hard-stops the session with a report of what you found; only work you can identify may be stashed, committed, or discarded. Then
```
git fetch
```
+ rebase onto
```
origin/main
```
, health-check the browser tooling, reap stale loop-owned dev servers on the contract's gate and takes ports - the off-loop port belongs to work outside the loop and is untouchable - and remove stale take worktrees with their branches (leftovers are died sessions). Servers stay ephemeral: spun up when a gate needs one, none started here.
Recovery sweep - any assigned open item is a died session (the loop is single-flight). Apply the contract's recovery table:
```
in-progress
```
ticket → revert to
```
ready-for-agent
```
and unassign;
```
in-progress
```
spec → wipe-and-regroom (close its orphaned sub-issues, revert, unassign); any other assigned issue (umbrella, epic, tracking issue - neither ticket nor spec) → clear the claim (unassign, drop any lifecycle label), no regroom.
Tracker preflight - read the main-health signals the contract declares (deploy status, CI checks) on
```
main
```
's head; a contract declaring no remote signal substitutes a local run of the check command on the rebased head. Any red → find-or-create the single open
```
fix-main
```
ticket (title names the failing check and sha, body carries the evidence). Green with a stale open
```
fix-main
```
→ close it with a note.
Select, in priority order: the open
```
fix-main
```
ticket; else the oldest open, unblocked, unassigned
```
ready-for-agent
```
ticket; else the first open, unblocked, ungroomed
```
ready-for-agent
```
spec; else say so and stop.
```
needs-triage
```
and
```
needs-info
```
items are invisible to the loop.

按照契约文件中的会话启动流程依次执行：

工作区预检——若工作树未清理，会话将立即终止并报告发现的问题；仅可对你能识别的工作进行暂存、提交或丢弃。随后执行
```
git fetch
```
+ 变基到
```
origin/main
```
，检查浏览器工具是否正常，清理契约文件中管控端口和take端口上属于循环的过期开发服务器——循环外的端口属于外部工作，不可操作——并移除过期的take工作树及其分支（遗留内容来自中断的会话）。服务器仅为临时实例：仅在管控需要时启动，此步骤不启动任何服务器。
恢复扫描——任何已分配的未完成项都属于中断的会话（循环为单线程执行）。执行契约文件中的恢复规则：
```
in-progress
```
状态的工单→恢复为
```
ready-for-agent
```
并取消分配；
```
in-progress
```
状态的spec→清理并重梳理（关闭其孤立的子工单、恢复状态、取消分配）；其他任何已分配的议题（总览、史诗、追踪议题——既非工单也非spec）→清除认领标记（取消分配、移除生命周期标签），无需重梳理。
追踪器预检——读取契约文件中声明的main分支健康信号（部署状态、CI检查）；若契约文件未声明远程信号，则在变基后的分支上本地运行检查命令。若检查失败→查找或创建唯一的未处理
```
fix-main
```
工单（标题包含失败的检查项和哈希值，正文包含证据）。若检查正常但存在未处理的
```
fix-main
```
工单→关闭工单并添加说明。
选择任务，优先级从高到低：未处理的
```
fix-main
```
工单；其次是最早的未阻塞、未分配的
```
ready-for-agent
```
状态工单；再其次是第一个未阻塞、未梳理的
```
ready-for-agent
```
状态spec；若无符合条件的任务，则告知并停止。
```
needs-triage
```
和
```
needs-info
```
状态的项对循环不可见。

Driving the spec

驱动spec处理

Selected a spec → groom it (below), then drive its fresh board.
Selected a ticket → deliver it (below); when it belongs to a spec, continue with that spec's board.
Repeat delivery on the board's frontier - oldest open, unblocked, unassigned ticket - one ticket at a time.
Ticket boundaries are the exit seams. At each boundary check your own context pressure and stop rather than start a take you might not gate - take commits are local and die with the session. Anything the next session needs goes as a comment on the relevant ticket; the tracker is the only handoff surface. Resuming is just invoking this skill again.
All sub-issues closed → close the spec; the closed spec is the durable done-marker that unblocks its dependent specs, and its closing comment is the spec report. Then the continuation check: with real context headroom remaining, you may re-run Select and drive the next spec; otherwise tear down and end.

选中spec→梳理它（见下文），然后驱动其全新任务板。
选中工单→交付它（见下文）；若该工单属于某个spec，则继续处理该spec的任务板。
在任务板的待处理项上重复交付流程——每次处理最早的未阻塞、未分配工单。
工单边界是退出节点。在每个边界检查自身上下文压力，若无法完成管控则停止，不要启动新的take——take的提交仅保存在本地，会随会话中断而丢失。下一次会话需要的所有信息都需添加到对应工单的评论中；追踪器是唯一的交接载体。恢复会话只需再次调用此技能。
所有子工单关闭→关闭spec；已完成的spec是持久化的完成标记，会解除对依赖spec的阻塞，其关闭评论即为spec报告。随后执行衔接检查：若仍有足够上下文空间，可重新执行选择流程并驱动下一个spec；否则清理并结束会话。

Grooming a spec

梳理spec

Never groom ahead: a spec is groomable only when its blocking specs are closed, so tickets are written against the codebase they land on rather than an imagined one.

Claim the spec: flip
```
ready-for-agent
```
→
```
in-progress
```
and assign yourself, before any other work.
Spawn a fresh subagent whose prompt directs it to follow the repo's
```
to-tickets
```
skill through its drafting steps only (gather context, explore the codebase as it stands today, draft vertical tracer-bullet slices with blocking edges) and report the breakdown back - the skill's quiz step is the exchange with you below, and its publish step is yours. The report carries, per ticket: title, full body (acceptance criteria included), and its blocking edges.
Quiz the breakdown. The to-tickets quiz is yours to answer - judge it as the human would:
- Granularity - each slice fits one fresh context window and is demoable alone.
- Edges - only genuine gates, nothing serialized out of caution.
- Coverage - every requirement of the spec lands in some ticket.
- Reality - verify any "already exists, no ticket needed" claim against the code yourself before accepting it. The same goes for any assertion about a reference repo or the environment ("X already does this, copy it"): verify it against the actual repo state at groom time, never inherit it from the spec or issue body - a stale claim promoted into a ticket carries the groomer's authority, and the gate checks the diff, not the brief's premises. A reference unreachable from this machine turns the claim into an explicitly marked unverified assumption the take must check before relying on it - never established fact. Iterate by continuing the same subagent when your harness can resume one; otherwise spawn a fresh subagent carrying the prior breakdown plus your objections.
Publish it yourself - every tracker write is the driver's, running
```
to-tickets
```
' publish step: one ticket per slice using its issue template, in dependency order (blockers first, so edges reference real ids), each a native sub-issue of the spec with native blocking edges among siblings and
```
ready-for-agent
```
on it. Verify the publication: enumerate the sub-issues, spot-check the edges.
Unclaim the spec: drop
```
in-progress
```
, unassign - the atomic "board is live" flip. A spec with sub-issues but still
```
in-progress
```
is a half-published board and never selectable.

绝不提前梳理：仅当spec的阻塞项全部关闭后才可梳理，确保工单基于最终要落地的代码库编写，而非想象中的版本。

认领spec：将状态从
```
ready-for-agent
```
改为
```
in-progress
```
并分配给自己，此操作需在其他工作之前完成。
启动全新子Agent，其提示语要求它遵循仓库的
```
to-tickets
```
技能仅完成起草步骤（收集上下文、探索当前代码库、起草带有阻塞关系的纵向追踪切片）并返回分解结果——该技能的问答步骤由你完成，发布步骤也由你执行。报告需包含每个工单的：标题、完整正文（包含验收标准）及其阻塞关系。
审核分解结果。
```
to-tickets
```
技能的问答环节由你主导——以人类视角判断：
- 粒度——每个切片适配一个全新的上下文窗口，且可单独演示。
- 阻塞关系——仅包含真实的管控点，不要因谨慎而添加串行依赖。
- 覆盖范围——spec的所有需求都需对应到某个工单。
- 真实性——在接受任何“已存在，无需工单”的声明前，需自行对照代码验证。对于涉及参考仓库或环境的断言（“X已实现此功能，可直接复制”）也需如此：在梳理时对照仓库实际状态验证，不要从spec或议题正文继承信息——若将过时的声明写入工单，会带有梳理者的权威性，而管控环节仅检查差异，不会验证前提假设。若无法从本机访问参考内容，则将该声明标记为未验证的假设，take在依赖它之前必须先进行检查——不可视为既定事实。若你的harness支持恢复会话，则通过同一个子Agent迭代；否则启动全新子Agent，提示语包含之前的分解结果和你的异议。
自行发布——所有追踪器写入操作都由driver完成，执行
```
to-tickets
```
技能的发布步骤：为每个切片使用对应的议题模板创建工单，按依赖顺序（先创建阻塞项，确保关系引用真实ID），每个工单都是spec的原生子工单，且在同级工单间设置原生阻塞关系，状态设为
```
ready-for-agent
```
。验证发布结果：枚举子工单，抽查阻塞关系。
取消认领spec：移除
```
in-progress
```
状态，取消分配——原子性地完成“任务板激活”操作。若spec已有子工单但仍处于
```
in-progress
```
状态，则属于半发布任务板，不可被选中。

Delivering a ticket

交付工单

One ticket → closed, atomic in-session: take + gate + land. Start from a clean working tree on the branch the ticket lands on; the take runs in its own worktree, so the diff you gate is exactly the take.

Claim: flip
```
ready-for-agent
```
→
```
in-progress
```
, assign yourself - before any work.
Take: spawn a fresh take session in its own worktree (see The take). Each attempt is a take; every take commits, so the issue timeline reads as the full attempt history.
Gate (see The gate). Green → step 5; not green → step 4.
Bounce: comment the specific defect on the issue - the auditable record of what review found - then continue the same take session with the finding and the fix expectation, same contract. Re-gate at step 3. Budget is three takes; if the third still misses, escalate: label
```
needs-human
```
, drop
```
in-progress
```
, unassign, and leave the commits and comments in place as the record. The driver stays out of the code - escalation, not takeover.
Land and close: scan the take's commit messages for wrong
```
#<N>
```
mentions and for closing-keyword +
```
#<N>
```
collisions, amend any before pushing, then land the take branch onto the landing branch (rebase it first if the landing branch has moved, then fast-forward), push, comment what shipped (see The record), and close the issue - closing is what unblocks its dependents. Push only on green: red takes never reach the remote - in most setups a push to main deploys production.
Teardown: stop any dev server or browser session the gate started, then any background process the take left, via its recorded handle (the contract's stop command, or the process group of a recorded pid) - a pattern-matched kill misses a parent sleeping between retries, so anything killed by pattern gets a re-check after a quiet interval to confirm nothing respawned. Before removing the take's worktree and branch, verify no process still holds the worktree path (
```
lsof +D <worktree>
```
) - a survivor runs on from the deleted path, burning quota and writing debris the next take gets blamed for. Teardown runs the same on landing, on escalation, and whenever a take is stopped early (re-scope, interrupt); the tracker comments are the record, not the leftover worktree.

一个工单→关闭，会话内原子性完成：take + 管控 + 落地。从工单落地分支的干净工作树开始；take在独立工作树中执行，因此你管控的差异就是take的内容。

认领工单：将状态从
```
ready-for-agent
```
改为
```
in-progress
```
并分配给自己——此操作需在其他工作之前完成。
执行take：在独立工作树中启动全新的take会话（参见《任务执行》）。每次尝试都是一个take；每个take都会提交，因此议题时间线会完整记录所有尝试历史。
管控（参见《管控环节》）。检查通过→步骤5；未通过→步骤4。
退回：在议题中添加具体缺陷的评论——记录审核发现的可审计内容——然后继续同一个take会话，告知发现的问题和修复要求，遵循相同契约。回到步骤3重新管控。预算为三次take；若第三次仍未通过，则升级处理：添加
```
needs-human
```
标签，移除
```
in-progress
```
状态，取消分配，保留提交记录和评论作为历史。 driver不参与代码编写——仅升级处理，不接管任务。
落地并关闭：检查take的提交信息中是否有错误的
```
#<N>
```
提及，以及关闭关键字与
```
#<N>
```
的冲突，如有则修改后再推送，然后将take分支落地到目标分支（若目标分支已更新，先变基再快进合并），推送代码，添加已交付内容的评论（参见《记录环节》），并关闭工单——关闭操作会解除对依赖项的阻塞。 仅在检查通过时推送：未通过的take绝不能推送到远程仓库——大多数配置中推送到main分支会直接部署到生产环境。
清理：停止管控环节启动的任何开发服务器或浏览器会话，然后停止take遗留的任何后台进程，通过记录的句柄（契约文件中的停止命令，或记录的进程组PID）——模式匹配的 kill 命令可能会遗漏休眠的父进程，因此通过模式匹配杀死进程后，需在静默间隔后重新检查，确认没有进程重启。在移除take的工作树和分支前，需验证是否有进程仍占用工作树路径（
```
lsof +D <worktree>
```
）——残留进程会继续运行，占用资源并产生垃圾文件，导致下一个take被误判。无论落地成功、升级处理还是提前终止take（重新范围、中断），清理流程都相同；追踪器的评论是唯一记录，而非遗留的工作树。

The take

任务执行（The take）

Every take is a fresh session at token-zero, working in its own worktree on a take branch cut from the landing branch - never in a shared working copy, so concurrent sessions cannot sweep each other's uncommitted work into a commit or push each other's ungated commits. Create it with your harness's native worktree isolation when it has one, plain

git worktree add

otherwise, and scaffold it per the contract's worktree scaffold line (untracked env files, dependency install) before the take starts. Takes spawn on your harness's native subagent mechanism - only an explicit invocation-time request routes them through an external runner:

Native subagents - spawn the take with your harness's native subagent mechanism. Bounces continue the same take session where your harness can resume one - cheaper than fresh, and the take's context survives; where it cannot, spawn a fresh subagent whose prompt carries the original contract verbatim, the prior take's report, and the bounce finding.
External runner (explicit request only) - the invocation names a runner file in this skill's
```
runners/
```
folder; follow it for spawn, resume, and take metering.
```
runners/codex.md
```
runs takes as
```
codex exec
```
sessions.

Either way a bounce continuation counts against the three-take budget. Long takes run in the background where the harness supports it; let quiet runs under 30 minutes keep working. Your context takes only the take's final report - never pull the take's transcript, diffs, or file dumps into the driver session; the gate reads the diff from git, not from the report.

The prompt contract. The take starts with zero context - no spec thread, no driver conversation, no house rules beyond what its harness injects. Spec quality decides the take. Every take prompt carries:

the goal: issue number, title, and full body verbatim (acceptance criteria included), plus the parent spec reference - inline the spec's own language for the parts this ticket implements
the process pointer: follow the project's
```
implement
```
skill (
```
.agents/skills/implement/
```
) if present
grounding pointers: the repo's domain glossary (
```
CONTEXT.md
```
), any generated stack guidelines the repo ships (they override trained knowledge), and the design-direction docs when the issue has UI surface
constraints and non-goals lifted from the issue
proof expected: the project's exact check command, plus every deploy-shaped proof the diff will trigger per the contract's Gate proofs section - the take runs them too, so bounces are cheap
runtime rules: if the take needs a running app, it spins up its own ephemeral server from inside its worktree via the dev-server script and takes-port the contract names, and stops it on exit; any other long-running process it starts must be stoppable by handle - launched through a contract-declared lifecycle script, or in its own process group with the pid recorded - and stopped on exit or named in the report; a take never leaves a detached process with no handle
review rules: the implement skill ends with a code-review step whose own instructions spawn parallel review sub-agents - the take must not follow that: it runs both review axes sequentially inline in its own context. More generally a take never spawns sub-agents and never blocks waiting on agent messages or notifications - sub-agent replies are not guaranteed to reach a take, and not every executor can spawn them; when an awaited result has not arrived, proceed with what is on disk and note it in the report
commit rules: commit locally referencing
```
#<N>
```
as a plain mention - the mention must not directly follow any GitHub closing keyword (fix, fixes, fixed, close, closes, closed, resolve, resolves, resolved), even in ordinary prose, since GitHub would auto-close the issue before the gate runs; reword the sentence if needed - and never push
output shape: a terse report only - what shipped, proofs green (y/n), files touched, commit shas, blockers hit

每个take都是一个全新的token-zero会话，在独立工作树中基于目标分支创建的take分支上执行——绝不在共享工作副本中执行，避免并发会话将彼此未提交的工作混入提交，或推送未管控的代码。若你的harness支持原生工作树隔离，则使用该机制创建；否则使用普通的

git worktree add

命令，并在take启动前按照契约文件的工作树脚手架指令进行初始化（未追踪的环境文件、依赖安装）。 take通过你的harness的原生子Agent机制启动——仅显式调用请求才会通过外部运行器路由：

原生子Agent——使用harness的原生子Agent机制启动take。若harness支持恢复会话，则退回时继续同一个take会话——比启动全新会话更高效，且take的上下文会保留；若不支持，则启动全新子Agent，提示语包含原始契约、之前的take报告和退回原因。
外部运行器（仅显式请求）——调用时指定此技能
```
runners/
```
文件夹中的运行器文件；按照该文件的要求启动、恢复take并进行计量。
```
runners/codex.md
```
将take作为
```
codex exec
```
会话运行。

无论哪种方式，退回后的继续操作都会占用三次take的预算。若harness支持后台运行，则长时间运行的take可在后台执行；允许30分钟以内的静默运行继续执行。 driver仅接收take的最终报告——绝不将take的对话记录、差异或文件转储到driver会话中；管控环节从git读取差异，而非从报告中读取。

提示语契约。take启动时无任何上下文——无spec线程、无driver对话、无额外规则，仅包含harness注入的内容。 spec的质量决定take的结果。每个take的提示语包含：

目标：议题编号、标题和完整正文（包含验收标准），加上父spec引用——将spec中与该工单实现部分相关的语言直接嵌入
流程指引：若项目存在
```
implement
```
技能（
```
.agents/skills/implement/
```
），则遵循该技能
基础指引：仓库的领域术语表（
```
CONTEXT.md
```
）、仓库提供的任何生成式栈指南（覆盖训练知识），以及当议题涉及UI时的设计方向文档
从议题中提取的约束和非目标
预期证明：项目的精确检查命令，加上契约文件《管控证明》部分中差异会触发的所有类部署证明——take也需运行这些证明，以便快速退回
运行时规则：若take需要运行应用，则从工作树内部通过契约文件指定的开发服务器脚本和take端口启动自己的临时服务器，并在退出时停止；启动的任何其他长期运行进程必须可通过句柄停止——通过契约声明的生命周期脚本启动，或在独立进程组中运行并记录PID——并在退出时停止或在报告中注明；take绝不能留下无句柄的脱离进程
审核规则：implement技能以代码审核步骤结束，该步骤的指令会启动并行审核子Agent——take不得遵循此步骤：需在自身上下文中依次执行两个审核维度。更一般地，take绝不启动子Agent，也不等待Agent消息或通知——子Agent的回复无法保证送达take，且并非所有执行器都能启动子Agent；若预期结果未到达，则基于磁盘上的内容继续执行，并在报告中注明
提交规则：在本地提交时引用
```
#<N>
```
作为普通提及——该提及不得直接跟随任何GitHub关闭关键字（fix、fixes、fixed、close、closes、closed、resolve、resolves、resolved），即使在普通文本中也不行，因为GitHub会在管控环节运行前自动关闭议题；如有需要则改写句子——且绝不推送
输出格式：仅需简洁报告——交付内容、证明是否通过、修改的文件、提交哈希、遇到的阻塞

The gate

管控环节（The gate）

Review is never delegated and never skipped.

The diff first.

git status -sb

, then read the full diff and judge it like a contributor PR, on four axes:

Spec fidelity - every acceptance criterion met, nothing shipped beyond the issue's scope.
Repo standards - the glossary's vocabulary, the established patterns (function builders, test seams, fixtures), the generated stack guidelines; new code reads like the code around it.
Design direction - UI diffs against the repo's standing design docs; flag drift rather than restyling by taste.
Elegance - the diff earns its size: reuse over reinvention, no gratuitous abstraction, tests assert behavior at settled seams rather than implementation detail.

Then the facts. The report is a claim; the fact is your own re-run in the take's worktree - deps installed, diff checked out. Run the project's check command yourself, and verify the app end to end (the repo's verify skill, if it ships one) when the issue has runtime surface - on your own ephemeral dev server from that worktree (the contract's gate port), with the off-loop port untouched.

Deploy-shaped proofs. The local check chain structurally cannot see deploy-only failures; the gate runs what production runs. The contract's Gate proofs section maps diff shapes to the repo's proof commands (schema changes, destructive data changes, production-build-only errors); run every proof the diff triggers.

Advisory signals. The same section names the repo's review skills and analyzers per surface (UI guidelines, stack analyzers, copy review); run the ones the diff touches and weigh their findings as review input on the standards/elegance axes - never as a pass/fail gate step.

审核绝不委托，也绝不跳过。

先检查差异。执行

git status -sb

，然后读取完整差异并像审核贡献者PR一样判断，从四个维度：

spec一致性——满足所有验收标准，交付内容未超出议题范围。
仓库标准——遵循术语表的词汇、已确立的模式（函数构建器、测试节点、夹具）、生成式栈指南；新代码与现有代码风格一致。
设计方向——UI差异需对照仓库的现有设计文档；标记偏差，而非凭喜好重新设计。
简洁性——差异的规模合理：优先复用而非重新实现，无不必要的抽象，测试在稳定节点验证行为而非实现细节。

再验证事实。报告是声明，事实需你在take的工作树中重新运行验证——安装依赖、检出差异。自行运行项目的检查命令，若议题涉及运行时内容，则端到端验证应用（若仓库提供verify技能则使用该技能）——在该工作树的临时开发服务器上（契约文件指定的管控端口）执行，不操作循环外的端口。

类部署证明。本地检查流程无法发现仅在部署时出现的问题；管控环节需运行生产环境使用的验证流程。契约文件的管控证明部分将差异类型映射到仓库的证明命令（ schema变更、破坏性数据变更、仅生产构建时出现的错误）；运行差异触发的所有证明。

参考信号。该部分还指定了仓库针对不同内容的审核技能和分析器（UI指南、栈分析器、文案审核）；运行差异涉及的工具，并将其结果作为标准/简洁性维度的审核输入——绝不作为通过/不通过的管控步骤。

The record

记录环节（The record）

The tracker's comments are what a later retro reads.

Per ticket - the shipped comment carries:

what shipped and the commit shas
takes used; for each bounce, the defect the gate caught, quoted
the driver session id and each take's session or subagent id

追踪器的评论是后续回顾的依据。

每个工单——交付评论需包含：

交付内容和提交哈希
使用的take次数；对于每次退回，引用管控发现的缺陷
driver会话ID和每个take的会话或子Agent ID

Session end

会话结束

Every session, however it exits:

Teardown - stop loop-owned dev servers and browser sessions.
Report - one spec-level comment per spec driven: the closing comment when the spec closes, a status comment otherwise. A session that touched no spec lands the same report on the last ticket it delivered. It carries: tickets shipped with takes and bounces, escalations, commits, environment or tooling friction hit along the way, observations filed, and the session ids (driver + takes) - the driver session id stated literally, never as "this session", and, when the session drove more than one spec, this spec's ordinal within it ("second spec this session, after #63") so post-factum accounting can split the transcript at spec boundaries. Then a short reflection, a line or two each: the hardest call of the session and the alternatives rejected; the least-confident spots and the assumptions under them; what a wider scope would have done differently. It ends with the loop's blockers: open
```
needs-human
```
items and whether any ready spec remains.
Observations - anything actionable (a tooling defect, a gate blind spot, a skill gap) becomes its own issue labelled
```
needs-triage
```
; narrative context goes in the report's Observations section.

无论会话如何退出，都需执行以下操作：

清理——停止循环所属的开发服务器和浏览器会话。
报告——每个被驱动的spec添加一条spec级评论：若spec已关闭则添加关闭评论，否则添加状态评论。若会话未涉及任何spec，则在最后交付的工单上添加相同报告。报告需包含：交付的工单及对应的take和退回情况、升级处理记录、提交记录、会话中遇到的环境或工具问题、提交的观察结果、会话ID（driver + takes）——driver会话ID需明确写出，不要用“本次会话”指代；若会话驱动了多个spec，需注明该spec在会话中的序号（“本次会话的第二个spec，继#63之后”），以便后续分析时在spec边界拆分对话记录。然后添加简短的反思，各写一两句话：会话中最艰难的决策及被否决的备选方案；最不确定的部分及其背后的假设；若范围更广会做出的不同选择。报告最后列出循环的阻塞项：未处理的
```
needs-human
```
项，以及是否仍有可处理的spec。
观察结果——任何可操作的内容（工具缺陷、管控盲区、技能缺口）都需创建独立议题并添加
```
needs-triage
```
标签；叙述性上下文添加到报告的“观察结果”部分。