no-mistakes

no-mistakes

no-mistakes 是一个本地门禁，会通过一条流水线（意图、变基、审查、测试、文档、Lint、推送、PR、CI）验证代码更改，然后才将其推送到已配置的目标。你可以通过 no-mistakes axi 命令系列来驱动它：该系列会将机器可读的 TOON 输出到 stdout，并将进度输出到 stderr。

活跃验证步骤边界

no-mistakes 验证步骤 Agent 已处于一个活跃的外层运行中。它必须仅检查、修复并返回分配给自己的阶段。它绝不能初始化、启动、重新连接、重新运行、响应、同步、中止、退出或直接推送 no-mistakes 流水线。用户意图中的交付要求仍是验收背景，但其他验证、推送、PR 和 CI 阶段仅由外层执行器处理。

NO_MISTAKES_GATE 是快速诊断证据，本身并不构成授权。运行时会结合受管 Git 身份与经过认证的进程祖先关系。如果流水线控制命令返回 error.code: nested_gate_context，请立即停止并将控制权交还给外层执行器。仍可通过 no-mistakes axi status、no-mistakes axi logs、帮助信息和 no-mistakes doctor 安全地进行检查。

当用户调用 /no-mistakes 时，请在最后报告结果。如果用户提出了具体要求，请自行将该要求转换为对应的 axi run 标志——例如，“跳过 lint 步骤”转换为 --skip=lint。运行 no-mistakes axi run --help 查看可用标志。

两种调用方式

/no-mistakes 有两种模式，具体取决于用户是否随命令一并提供了任务：

• 仅验证 - 单独使用 /no-mistakes（可附带“跳过 lint 步骤”之类的标志式请求）。用户的代码更改已经提交；验证这些更改并报告结果。
• 先完成任务 - /no-mistakes <task>，例如 /no-mistakes add a --json flag to the status command。先自行完成任务，然后通过流水线验证结果：
  1. 检查范围。 在更改或提交任何内容之前，检查 git status。 保留无关的既有未提交更改；提交时只提交属于用户任务的更改。
  2. 完成工作。 按任务描述进行更改，然后在功能分支上提交。如果用户当前位于仓库的默认分支，先创建功能分支——门禁会在非默认分支上验证已提交的历史，因此必须先将工作提交到该分支，再运行门禁。
  3. 然后进行验证，并将用户的任务作为明确意图传入。任务文本就是用户想要完成的内容，因此它就是意图——保留用户直接提出的要求，包括限制、排除项、验收标准以及后续决定；不要将其缩减为差异摘要，也不要在补充实现背景时删去这些内容。再补充你在完成工作时做出的决定和权衡（参见 必须提供意图）。

测试质量规则

绝不要添加这类测试：它唯一的证据是打开、读取、grep、解析或快照实现源代码，并查找或排除特定字符串、标记、行、命令、函数名、提示词短语、正则匹配、AST 结构或偶然的快照。这并不能证明行为：匹配到的文本可能是无效代码或注释，而保持行为不变的重构也可能改变这些文本。

应改为执行公共接口或可执行接口，并断言可观察到的行为、状态、输出、副作用和失败模式。对于工作流 YAML、JSON、策略、.gitignore 或生成的配置等由机器读取的声明式制品，应尽可能调用实际使用它的工具，或将其解析为有类型或规范化的语义模型，并断言其含义。对文件执行原始子字符串或正则匹配，仍然是反模式。

如果文件本身是生成的公共输出、序列化协议、持久化状态、有意保留的快照，或其他明确归属的文本或字节契约，那么读取该文件是合理的。应说明该契约，不要用其内容作为无关代码正常工作的替代证据。不能因为自然语言提示词或指令的源代码中包含某句话，就证明它有效。确定性的 CI 可以测试最终交付给 Agent 的提示词，将其视为有意生成的接口；对模型理解能力的评估应属于仅用于开发的评估，而不是实时 LLM CI。

使用独立的判定依据：预期结果必须来自被测代码以外的来源，例如规范、示例、已发布的常量、外部契约或经过独立论证的属性。明确说明公共行为、判定依据的来源，以及测试可能拦截的一种合理错误行为。不要只检查自己的模拟对象、将结果与自身比较，或照搬实现中的预期值规则：两边共享同一错误时，测试可能仍会通过。只要检查的是独立契约，外部边界模拟、常量、快照和计算得出的预期值仍然合理。

对于回归问题，在可行时重现已报告的故障：测试应在修复前失败，在修复后通过。

以下所有内容——前置条件、意图、验证与决策循环——在工作提交到功能分支后同样适用。

开始之前

• 你希望验证的工作必须已在某个分支上提交。验证门检查的是已提交的历史记录，而不是未提交的工作区。
• 你必须位于功能分支上，而不是仓库的默认分支上。
• 仓库必须已通过 no-mistakes init 初始化。
• 守护进程必须配置了可运行的流水线 Agent：受支持的原生 Agent 二进制文件、agent: cursor 或 agent: devin ACP 别名，或通过 acpx 指定的 acp:<target>。你是 AXI 驱动程序，而不是隐式的流水线 Agent 后端。如果没有可用的 Agent，运行会在第一步之前失败；no-mistakes doctor 会报告配置问题。

如果未满足上述任一条件，axi run 会返回一条包含具体修复命令的 error:——请阅读并按提示处理（提交你的工作，或创建分支）。如果仓库尚未初始化，请先运行 no-mistakes init；如果 no-mistakes 命令本身缺失或运行异常，no-mistakes doctor 会报告问题所在。 开始之前，运行 no-mistakes axi（主页视图）。 如果显示当前分支上有正在运行的任务，请使用 no-mistakes axi status 检查。 如果任务停在某个验证门，请使用 no-mistakes axi respond 推进。 如果运行中的任务仍与当前 HEAD 匹配（无论它是已提交的头部，还是当前流水线头部），请重新运行 no-mistakes axi run 以重新接入。 只有当你打算在重新开始前丢弃该任务时，才运行 no-mistakes axi abort；中止是两次运行之间的操作，绝不能在任务仍在进行时用于接管或绕过验证门（参见验证并做出决定）。 如果显示另一个分支上有正在运行的任务，请不要处理它，并使用 no-mistakes axi run --intent "..." 为当前分支启动验证。

必须提供意图

启动新任务时，必须通过 --intent TEXT、--intent-file PATH 或 --intent -（从标准输入读取至 EOF）中的一种明确提供意图：用户着手要实现的目标，也就是这项工作的目标或需求，应使用用户自己的表述。这不是对差异内容或所改文件的描述，而是这项更改旨在实现的目标。你可以从对话中了解这一点，因此请直接传入；no-mistakes 会使用你提供的意图，而不是从本地 Agent 转录记录中推断。空输入或仅含空白字符的输入会被拒绝，不会进行推断。有关输入处理、空白字符保留和重新接入语义，请参阅CLI 意图输入参考。

宁可完整，不要过于简短。审查步骤会使用明确的意图区分有意做出的决定与错误，因此过于简略的一行摘要可能会让它将用户已作出的选择标记出来。请充分体现细节：用户的目标、过程中作出的具体决定和权衡、明确纳入或排除的约束或方案，以及用户明确提出但在差异中可能显得意外的要求。通常应写几句话到一小段，记录你从对话中了解到、而只看差异的审查者无法得知的信息。

验证并做出决定

运行流水线，并在发现问题时逐一决定如何处理：

1. 启动运行。它会一直阻塞，直到到达第一个决策点或运行结束：

   no-mistakes axi run --intent "<what the user set out to accomplish>"
   

   axi run 和每次 axi respond 都会同步阻塞——审查、测试和 CI 步骤各自可能需要几分钟，因此单次调用可能需要一段时间才会返回。这是正常现象；不要因为看起来很慢就取消或重新执行命令。这两个命令默认使用 --wait 8m，因此在工具调用时限为 10 分钟的执行环境中，它们会返回结构化结果，而不是无限期挂起。如果命令因等待时间耗尽而返回，这不代表运行失败，也不代表守护进程已停止：请使用 no-mistakes axi status 检查状态，然后重新运行 axi run 或 axi respond 以重新连接。经过健康检查后，运行缓慢但仍存活的守护进程会重试，而不会被视为 I/O 故障。若要在不干扰运行的情况下检查进度，请通过单独的调用执行 no-mistakes axi status。 长时间运行的调用仍在工作，并非卡住——如果执行环境有需要，可以将其放到后台，但运行绝不会自行越过关卡。请阅读每次返回的内容；遇到 gate: 时就作出响应；持续循环，直到出现 outcome:。切勿空等运行自行推进。 如果状态输出中显示该运行的 awaiting_agent: parked <duration>，则表示运行停在审批或修复审查关卡，正在等待你发送 axi respond。该字段仅用于观测：它不会改变关卡的处理方式，不会自动恢复运行，也不会将 --yes 设为默认值。 如果某个步骤正在 running 或 fixing，axi status 可能会显示 active_steps，其中包含步骤级别的 active_for、当前轮次的 round_active_for、last_activity、子进程 Agent 运行时的原生 agent_pid，以及当前轮次信息，例如 round 1、auto-fix 1/3 或 fix 2。如果 last_activity 以 quiet 开头，表示已有超过 step_quiet_warning 的时间没有步骤日志或原生 Agent 生命周期活动。请将其视为运行状态的线索，而不是取消、重新运行或自行编辑工作树的许可。

2. 如果输出包含 gate: 对象，说明流水线正在等待你处理。 请阅读其中的 findings 表。每条发现都包含 id、severity、 file、description 和 action，用于说明流水线如何分类该发现：

   • auto-fix——机械性且风险较低；你可以自行判断并通过 --action fix 授权修复。
   • no-op——仅供参考；无需处理。
   • ask-user——该发现质疑用户有意为之的决定或涉及产品行为。只有用户能作出此决定——请参阅下文的升级处理 ask-user 发现。

   审查阶段默认禁用自动修复（auto_fix.review: 0；设置仓库级或全局的 auto_fix.review > 0 可重新启用），因此，阻塞性审查发现和 ask-user 审查发现会暂停并等待你作出决定，而不会被静默地自动修复。（测试和 lint 等其他步骤可能会在流水线中自动修复问题，并在触发关卡前重新运行。） 选择一种响应：

   # accept the step as-is and continue
   no-mistakes axi respond --action approve
   
   # have the pipeline fix specific findings, then continue
   no-mistakes axi respond --action fix --findings <id1,id2> --instructions "<optional guidance>"
   
   # fix some findings and explicitly decline the rest
   no-mistakes axi respond --action fix --findings <id1,id2> --ignore <id3>
   
   # skip this step
   no-mistakes axi respond --action skip
   
   # continue static review when coverage is incomplete and findings are empty
   no-mistakes axi respond --step review --action complete-coverage
   
   # reject this gate (only when the user has decided it must fail)
   no-mistakes axi respond --action abort --reason "<why the gate is rejected>"
   

   complete-coverage 会对仅包含缺失路径的内容重新运行审查。 它只会在运行、步骤、轮次、头提交、基准提交和受信任范围完全相同的情况下复用已存储的覆盖结果。 来源信息缺失或无效时，Review 会继续保持门控状态。回合期间源代码发生变更时，也会继续保持门控状态。 它绝不会批准不完整的覆盖结果、运行代码修复器或回答问题。 如果存在未处理的发现、发现项覆盖或 --yes，它会拒绝执行。 使用 --action fix 时，拒绝操作必须明确：门控显示的每项发现都必须列在 --findings 或 --ignore 中；如果响应遗漏某项，就会被拒绝并指出缺少的 ID，同时门控会继续保持暂停。 如果当前步骤的较早轮次已经对某项发现作出决定，可以省略该项以保留此前的决定——省略该项并不表示拒绝它；而如果某项发现已在较早轮次选择修复，后续响应就不能再拒绝它：回滚已应用的修复不属于门控响应的范围，因此请将其列在 --findings 中以再次修复，或将其省略以保留修复。每次成功的 fix 响应都会通过 recorded: 对象回显记录的内容（fixed、ignored、kept），因此请查看它以确认实际作出的决定。 运行处于活动状态时，切勿自行编辑代码来修复发现项——发现项和修复工作都由流水线负责。你在门控处的任务是作出决定并响应；使用 --action fix 时，流水线会应用修复并重新审查结果。出于同样的原因，运行处于活动状态时，不要自行 abort 或 rerun 来修复发现项——即便是你自己代码中的真实 Bug 也不行——因为这会丢弃流水线正在进行的工作，并迫使其重新完成全部验证。abort 和 rerun 仅适用于运行之间（即出现 failed 或 cancelled 结果后），绝不可用来绕过门控。

   每次 respond 都会阻塞，直到出现下一个 gate:、checks-passed 决策点或最终结果；阻塞时遵循相同的默认等待时间 --wait 8m。

   如果审查门控中的发现是 question-<id> 行，则它在等待你回答审查者的问题，而不是等待你作出裁决：请使用 no-mistakes axi answer --question <id> --answer "<one of its options>" 逐一回答，而不是批准或修复。关闭最后一个未解问题的回答会像 respond 一样阻塞，并返回下一个 gate: 或结果；其他回答则会立即返回。 respond 的额外标志：

   • --wait 设置等待时长上限（默认为 8m）。
   • --reason "the operator's explanation" 会通过 --step test --action approve 记录一个经明确授权的 Test 例外。 这不会授予审批权限；对于要求询问用户的发现，仍须像之前一样升级处理。 未提供原因时，Test 审批仍然有效；如果在命令失败、no-go 或 inconclusive 判定后审批，会报告为未提供操作员原因的例外。
   • --action abort --reason "<why>" 会记录用户决定该暂停的关卡未通过。必须提供原因。 该轮会记录为已拒绝，不会开始修复轮次，不会审批、推送或合并任何内容，运行会以 failed 结束，原因会记录在步骤错误和运行错误中。已保存的提交、发现和证据仍可用，但运行的工作树会被移除，其中未提交的编辑将丢失。 按照输出中的 branch_sync.next_action 恢复分支。这由用户决定，绝不是由你决定：不要通过发送该操作来绕过某项发现；而且这也不是会取消运行的 axi abort。
   • 对于包含反引号、引号或换行符的文本，优先使用 --instructions-file PATH 和 --add-finding-file PATH。将准确文本写入文件并传入其路径，不要使用 shell 替换。或者，使用 --instructions - 或 --add-finding - 从标准输入读取，直到遇到 EOF、取消或 --wait 超时（每次响应只能输入一次标准输入）。每个文件标志都不能与对应的内联标志同时使用；空文件或仅含空白字符的文件／标准输入会被拒绝。
   • --add-finding '<json>'（与 --action fix 一起使用）会将你自己发现的、流水线未发现的问题作为 JSON 发现对象，纳入修复轮次。用于处理你注意到但未出现在关卡自身 findings 表中的问题。
   • --ignore <id1,id2>（与 --action fix 一起使用）会拒绝指定的发现。关卡 findings 表中的每项发现都必须出现在 --findings 或 --ignore 中；遗漏任何项都会导致请求被拒绝并列出其 ID，因此不会将遗漏记录为拒绝。此步骤较早轮次中已决定修复的发现不能在此列出：撤销已应用的修复不属于关卡响应的范围。
   • --step <name> 会响应指定步骤，而不是当前正在等待审批的步骤。通常不需要此标志；省略它即可响应当前活动关卡。

3. 重复步骤 2，直到输出中出现 outcome: 而不是 gate:。结果包括：

   • checks-passed - 变更已通过验证，且 CI 状态为绿色（或者受信任的默认分支配置声明了 no_ci: true，且未注册任何检查；适用时，帮助行会注明此声明），但 PR 尚未合并。流水线操作到此结束。 不要等待合并：告知用户 PR 已准备就绪，并请他们审查和合并（PR 链接位于 help 行）。如果没有该声明，仅有通用的空代码托管平台检查列表，并不表示已准备就绪。no-mistakes 会在后台持续监控 PR，直到其合并、关闭或达到配置的空闲超时时间，因此人工可以在 TUI 中查看。 如果启用了可选配置 ci.release_after_checks_pass，运行会在判定后结束：run.status 为 checks_passed，运行已释放其工作树，也不会继续监控 PR。 后续若需更新，应在更新后的 head 上重新运行 no-mistakes axi run；此运行不会对其执行变基或重新推送。
   • passed - 流水线已按请求的步骤完成，包括任何明确指定的单次运行跳过项。但这本身并不能证明 PR 已合并。
   • passed-with-override - 流水线已完成，其中包含明确批准的 Test 例外或 CI 失败。 应报告例外，而不是宣称全部通过。 Test 证据位于 run.test_override_reason 中，包括 CI 就绪状态返回 checks-passed 的情况；摘要中不得省略。
   • passed-with-skips - 发布或 CI 验证被自动跳过。 报告缺失的证据及其原因，信息来自 run.automatic_skips，并与完整的 run.head_sha 绑定。这既不表示 CI 已就绪，也不表示代码判定失败。明确指定的单次运行跳过项仍按原有方式处理。
   • failed 或 cancelled - 流水线未通过；请阅读输出并处理。修复输出指出的问题（测试失败、lint 错误、被跳过的发现）之前，先遵循下方的保管指导。在同一个功能分支上提交修复，然后使用 no-mistakes axi run --intent "..." 提交。重新运行或 rerun 属于运行之间的操作，只有在这种终态结果之后才适用；绝不能在运行过程中用它来绕过关卡。若结果为 failed，不要不加说明地让用户就此打住：要么重试，要么解释阻碍原因。 no-mistakes rerun 保持现有的头提交选择逻辑：选择门禁头提交，或者在托管责任仍未解除时，选择最新终态运行中已验证且尚未发布的保留头提交。如果已知干净调用方 HEAD 与所选头提交不同，它会在启动或替代任何运行之前拒绝操作，并报告两者的完整 SHA。它绝不会用调用方头提交替代所选提交，也不会移动任一分支来使两者匹配。被拒绝时，请检查 no-mistakes axi status，并遵循下方的托管责任指引。对于工作区不干净的调用方，以及无法证明头提交干净的调用方，仍沿用现有选择逻辑。

如果 failed 结果是由 Agent 调用本身导致的——例如提供方处理错误、用量或配额限制、传输失败，或 Agent 进程退出——发生在 Test 或更早的步骤中，且运行从未推送，那么 no-mistakes axi retry --run <id> 会继续该运行，而不是重做整个运行：新运行从保留的头提交开始，保留失败步骤之前的步骤，并从头重新执行失败的步骤。因此，失败的 Review 会在 Test 之前完整审查由此产生的头提交。首先使用报告中的 no-mistakes axi sync --recover 采纳保留的头提交，确保干净的 HEAD 与该提交完全一致。如果无法确证继续操作安全（例如失败涉及更改本身、分支已移动或处于脏状态、存在其他运行，或自已携带的 Review 运行以来配置发生变化，包括仓库设置、Agent 或其模型），Retry 会拒绝操作、不做任何更改，并指出失败的证明；此时请改用 rerun 或处理该失败。与 respond 一样，它会阻塞，直到出现下一个 gate: 或结果。 在进行任何流水线后的本地提交或重新运行之前，请先读取 AXI home、status 或 drive 结果返回的结构化 branch_sync 对象。 只有当其 next_action.code 为 sync 时，才先运行 no-mistakes axi sync。 此受保护的同步可能是严格的快进，也可能是内容等效的分叉推进：后者会在使用 reset 语义移动分支前，为同步前的 HEAD 创建锚点；真正的分叉会继续被阻止，并提示运行 git checkout --detach <pushed-sha>，该命令不会移动任何分支引用。 如果报告的 next_action.code 为 continue_active_run，则流水线仍拥有该分支：运行报告的命令，继续推进活动运行，不要进行本地后续提交。 当 next_action.code 为 recover_custody 时，请运行其确切的 next_action.command，不要自行拼凑命令。这可能是 no-mistakes axi sync --recover，用于接管仍可用的、由流水线保留的 HEAD；也可能是在两种保留本地更改的情况下运行 no-mistakes axi sync --recover --keep-local：一种是可访问的门控确认已验证的保留 HEAD 缺失，且你明确要丢弃这些未发布的提交；另一种是绑定的归档证明有分叉的后续工作仍被保留，而恢复操作会让分支停留在报告的确切必需 HEAD 上，绝不选择、合并或重放该归档。对于报告的保留本地更改操作，不要改用普通的 --recover 或 rerun。在满足上述干净 HEAD 检查的前提下，no-mistakes rerun 可以恢复验证仍可用的普通保留 HEAD。 普通恢复会通过快进接管该 HEAD；或者，在有证据证明分叉的保留 HEAD 包含所有本地更改时，通过采用该 HEAD 来恢复——这通常是流水线将你的提交变基到较新基线后的结果。恢复前的 HEAD 会锚定在 refs/no-mistakes/recover-local/<run> 下。 普通恢复的遏制证明刻意设得很严格，因此，如果变基时的修复轮次也改写了你自己的代码行，就会拒绝采用；当没有任何依据能区分流水线的有意修复与被丢弃的更改时，由你决定。 如果某次运行在 Test 之后的步骤中失败，且代码未被触及（例如 Document 或 Lint 获取错误），并且记录的 HEAD 从未经过验证，那么只要你的干净检出恰好位于该 HEAD 上，且门控证明该 HEAD 是已审阅的结果加上流水线在实时门控分支上后续提交所形成的结果，恢复仍会在该 HEAD 上归还控制权。恢复绝不会将落后的工作树移动到未经验证的 HEAD，因此请先检出该确切 HEAD。 当 next_action.code 为 recover_remote_rewritten 时，配置的推送目标在终态运行之后被流水线之外的操作强制改写：请运行确切的命令 no-mistakes axi sync --recover。该命令会重新验证实时目标，将已被取代的流水线 HEAD 锚定在 refs/no-mistakes/recover-rewritten/<run>/<generation> 下，并且只将记录的推送绑定重新绑定到已验证的实时 HEAD；它绝不会移动你的分支、门控分支或远程分支。如果指定 --keep-local，实时 HEAD 或目标在恢复期间发生变化，无法为 HEAD 创建锚点，或者 PR 已合并或关闭，则会拒绝执行。之后请遵循它报告的普通 next_action。 当 next_action.code 为 adopt_published 时，归还控制权后的分支在其门控通道停止移动后发生了变基：请运行 no-mistakes axi sync --adopt-published。该命令会验证配置的推送目标是否已有确切的变基后本地 HEAD，保留旧通道 HEAD，并且只更新过时的门控通道。如果目标不同或在验证期间发生变化，则会拒绝执行，且不会替换该通道。 branch_sync.state 为 user_owned 表示运行在更改已提交的 HEAD 之前就进入终态，且取消操作已释放该分支：确切的分支和 HEAD 归你所有，可立即用于任何获准的交付方式；无需执行同步操作，重复运行 --recover 也只是无害的空操作。 如果工作树不干净，或无法证明分叉已被遏制，恢复将拒绝执行并给出明确选项；--keep-local 会保留你当前的 HEAD，同时将保留的提交锚定在 refs/no-mistakes/recover/<run> 下。如果可访问的门控确认已验证的保留 HEAD 缺失，且恢复引用兼容，那么同一标志也可用于恢复：它会在不要求该对象存在的情况下，于当前本地 HEAD 归还控制权。 如果同步被阻止，请处理该结构化状态，不要自行尝试 reset、stash、merge、rebase、force 或替换分支。 同步后，在其基础上提交后续更改，并使用原始用户意图重新运行 no-mistakes axi run --intent "..."。 无论配置的主题是什么，这都能保留此前所有门控修复提交。 CI 步骤会有意在检查通过后继续监控 PR，因此 axi run 会在检查变绿的那一刻（或受信任的 no_ci: true 声明覆盖无检查项的仓库时）返回 checks-passed，而不会一直等待人工合并。切勿自行轮询或重新运行来等待合并。默认情况下，该监控会持续运行；只有选择启用 ci.release_after_checks_pass，才会在得出判定后结束运行。切勿仅凭“未报告 CI 检查项”就将其视为通过。

由于该监控默认会持续运行，PR 在检查通过后落后于默认分支或遇到合并冲突——通常是因为另一个 PR 先合并了——不需要你执行任何命令：切勿手动变基。当 CI 监控发现实际冲突时，会基于目标分支进行变基、解决冲突、从 Review 阶段重新验证（因为变基无法证明与已审查的提交保持连续），然后通过 Push 阶段重新推送分支。在 GitHub 上，如果干净的 PR 所依赖的目标分支要求分支保持最新（mergeStateStatus: BEHIND），它仍会报告 checks-passed，并等待人工更新分支；只有当仓库启用了 ci.rebase_behind，且检查已通过、目标分支连续一次轮询保持不变后，监控才会对其执行同样的变基。若 PR 只是落后于目标分支，但没有此规则，则无需处理，因为平台会合并它。唯一的例外是监控不再运行时——PR 已关闭、运行已中止或被取代、因空闲超时，或自动修复尝试已耗尽——此时可使用 no-mistakes rerun 恢复，但仍须满足上述干净提交检查。被接受的重新运行会取消过时的监控，并重新运行完整流水线，其中包括确定性的变基步骤。不要使用 no-mistakes axi run 来刷新仍在运行的 PR：使用默认监控时，在 checks-passed 之后，它会重新连接到正在运行的监控（HEAD 未变），并返回其输出，而不会进行变基。

成功完成后（结果为 checks-passed 或 passed），请与用户进行闭环沟通：以简洁易读的格式总结流水线期间发生的情况——验证了什么，以及发现了什么。如果输出包含 fixes 表格，说明流水线修复了你最初的改动遗漏的问题：请承认这些遗漏，并明确列出每项修复，方便用户审阅。

升级处理 ask-user 发现

如果某个关卡的所有发现都标记为 auto-fix 或 no-op，你可以自行判断并安全地推进：酌情使用 --action fix 或 --action approve 进行响应。但标记为 ask-user 的发现属于用户的决定，而不是你的决定——流水线将其标出，是因为它质疑用户有意为之的意图，或会改变产品行为。不要擅自批准、修复或跳过。相反，在作出响应前暂停并告知用户：

• 将每条 ask-user 发现按流水线写出的内容转达给用户——包括其 id、file 和完整的 description，逐字照录。不要改述、删减细节或预先判断答案。
• 询问用户希望如何处理，然后将其决定转换为相应的 respond 调用：--action fix（通过 --instructions 传递用户的指导）、--action approve 或 --action skip。

例外情况是 --yes（见下文）：这是用户给予的持续授权，允许你在无人值守的情况下推进符合条件的关卡，因此使用 --yes 时，你应自动处理普通的 ask-user 发现，而不是停下来询问。

如果你已获得明确授权，可以自动推进整个运行，请将 --yes 传递给 axi run 或 axi respond。对于符合条件的关卡，它会将可操作的发现——无论是 auto-fix 还是 ask-user——都视为修复授权，选择所有当前发现进行一轮修复，接受修复审核结果，并批准仅包含 no-op 发现的关卡。只有当用户要求你在整个运行过程中无需再次确认时，才使用此选项。

即使使用 --yes，protected-path-refusal 关卡仍需要操作员明确响应。转达其路径和规则；不要自动修复、批准或跳过。批准会被拒绝。请操作员检查并解决报告的编辑，然后发送 --action fix，以重试未完成的步骤。 受保护路径参考规定了暂存防护的范围和限制。

存在未关闭的 question-<id> 发现的关卡也不符合条件：问题必须通过 axi answer 解决，不能通过裁决解决，因此此时 --yes 不会介入——如果无法完整读取问题历史记录，也会采取同样的处理方式，将其交由人工处理。

test-agent-unvalidated-work 发现表示某个超时的 Test agent 留下了提交或更改，但没有任何 Test 轮次对其进行验证。批准会被拒绝，因此 --yes 会在该关卡停止，不作响应。转达该发现所指出的内容，不要跳过 Test，因为这会发布相关工作。请操作员作出选择： --action fix 会消耗额外的 Agent 预算来验证这些工作，而 no-mistakes axi abort 会停止运行。

检查状态

no-mistakes axi               # home view: current branch, active runs, next steps
no-mistakes axi status        # full detail plus cached branch_sync when relevant
no-mistakes axi sync --check  # freshly verify an offered synchronization plan
no-mistakes axi sync          # apply only an offered guarded synchronization
no-mistakes axi sync --recover  # return custody after a terminal run left unpublished pipeline commits
no-mistakes axi sync --adopt-published  # adopt an exactly published rebased head into its stale gate lane
no-mistakes axi logs --step <name> --full   # one step's recorded findings, complete summary, and full log
no-mistakes axi abort         # cancel the current-branch active run
no-mistakes axi abort --run <id>   # cancel a specific run by id (works outside its worktree)
no-mistakes axi respond --run <id> --action approve   # answer a specific run's parked gate by id (works outside its worktree)

阅读输出

• 输出格式为 TOON：key: value 键值对、name[N]{cols}: 表格，以及 help[N]: 提示。
• 省略 --run 时，axi status 的范围限定为当前分支：如果当前分支已知，隐式解析出的 run: 就属于此分支。other_branch_run: 下的运行是你通过 --run <id> 指定、但属于其他分支的运行——切勿将其状态或结果视为自己的工作。如果当前分支未知（处于分离的 HEAD 状态或分支查询失败），在 run: 下显示的显式 --run <id> 不表示任何分支关系。在成功的状态响应中，完全没有运行对象表示此分支尚无运行，无论最近运行表中列出了什么；error: 响应无法证明运行归属，因此应处理错误，而不是断定此分支处于空闲状态。
• 非终态运行对象可能在 status 后紧接着包含 awaiting_agent: parked <duration>；这表示运行暂停在一个关卡。只有隐式解析出的当前分支关卡才支持直接使用 axi respond；即使分支匹配，显式 --run <id> 状态也仅供检查，因为该分支可能已有更新的活动运行，并会将 axi respond --run <id> 列为响应命令。请遵循响应中的 help。
• 带有 running 或 fixing 步骤的运行对象可能包含 active_steps 表。active_for 表示所属步骤的持续时间；round_active_for 表示显示的执行或修复轮次持续时间，并会在修复轮次开始时重置。较早的运行没有轮次计时信息，因此 round_active_for 为空。
• 大多数响应底部的 help 列表会告知你接下来要运行的命令。
• 错误会以 error: ... 的形式输出到 stdout，并附有 help 列表；请按建议处理。
• 退出码：0 表示成功、无操作或正常决策关卡；1 表示最终结果失败或已取消；2 表示用法错误。

等待你处理的 gate: 大致如下：一行 gate:，其中列出步骤名称，可选包含 note 等步骤专属字段，接着是 findings[N]{...}: 表格，每项发现占一行，以及列出后续命令的 help[N]: 列表：

gate: review
note: Review auto-fix is disabled by default (auto_fix.review: 0; a repo or global auto_fix.review > 0 override re-enables it), so blocking and ask-user review findings park for your decision rather than being silently self-fixed.
findings[2]{id,severity,file,line,action,description}:
  r1,warning,internal/pipeline/executor.go,,auto-fix,Error from os.Remove is ignored
  r2,error,cmd/no-mistakes/main.go,,ask-user,New --force flag bypasses the confirm prompt
help[6]:
  Run `no-mistakes axi respond --action approve` to accept this step and continue
  Run `no-mistakes axi respond --action fix --findings <ids> [--ignore <ids>]` to have the pipeline fix the selected findings (do not edit files yourself); list every finding below in `--findings` or `--ignore`, unless an earlier round of this step already decided it, and a finding that round chose to fix cannot be declined by a later response
  Run `no-mistakes axi respond --action skip` to skip this step
  Run `no-mistakes axi logs --step review --full` to read the complete step summary and log
  A long-running call is working, not stalled - background it if your harness needs to, but the run never advances past a gate on its own. Read every return; on a `gate:`, respond; loop until an `outcome:`.
  Commit post-pipeline follow-up work on top of the existing branch so every pipeline fix commit remains present. Never abort-and-restart, reset, or replace the branch in a way that drops prior gate-fix commits.

逐行阅读 action 列：根据自己的判断决定是否对 r1（自动修复）执行 respond --action fix --findings r1，将其交给流水线修复；但如果遇到 r2（询问用户），请先停止并向用户升级处理，再作出响应。最终状态则会显示 outcome: <checks-passed|passed|passed-with-override|passed-with-skips|failed|cancelled>，且不含 findings 表格。字段名称和具体列可能因步骤和版本而异，因此请阅读实际的 findings 表头，不要假定其布局固定。