no-mistakes

no-mistakes

no-mistakes は、コードの変更が設定済みのプッシュ先に届く前に、パイプライン（intent、rebase、review、test、document、lint、push、PR、CI）を通じて検証するローカルゲートです。no-mistakes axi コマンドファミリーを通じて操作します。このコマンドは、機械可読な TOON を標準出力に、進行状況を標準エラー出力に表示します。

アクティブな検証ステップの境界

no-mistakes の検証ステップエージェントは、すでにアクティブな外側の実行内にあります。割り当てられたフェーズだけを調査、修正し、その結果を返す必要があります。no-mistakes のパイプラインを初期化、開始、再接続、再実行、応答、同期、中止、切り離し、または直接プッシュしてはなりません。ユーザーの意図に含まれる納品要件は受け入れ条件として扱いますが、その他の検証、プッシュ、PR、CI の各フェーズを実行するのは、外側の実行プロセスだけです。

NO_MISTAKES_GATE は迅速な診断情報であり、それ自体が認可を示すものではありません。ランタイムは、管理対象の Git ID と認証済みのプロセスの系譜を組み合わせて判定します。パイプライン制御コマンドが 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 を実行してください。

呼び出し方法は 2 通り

/no-mistakes は、ユーザーがコマンドとともにタスクを提示するかどうかに応じて、2 つのモードで動作します。

• 検証のみ - 単独の /no-mistakes（「lint ステップをスキップする」のようなフラグ形式のリクエストを伴う場合もあります）。ユーザーのコード変更はすでにコミット済みです。変更を検証し、結果を報告してください。
• タスク優先 - /no-mistakes <task>。例：/no-mistakes add a --json flag to the status command。まず自分でタスクを実行し、その後、パイプラインを通じて結果を検証してください。
  1. スコープを確認します。 変更やコミットを行う前に git status を調べます。既存の無関係な未コミット変更はそのまま保持し、コミットする際はユーザーのタスクに属する変更だけをコミットしてください。
  2. 作業を行います。 タスクの説明どおりに変更し、その後、フィーチャーブランチにコミットします。ユーザーがリポジトリのデフォルトブランチにいる場合は、まずフィーチャーブランチを作成してください。ゲートはデフォルト以外のブランチにあるコミット済みの履歴を検証するため、実行前に作業をそのブランチに反映させる必要があります。
  3. その後、検証します。 ユーザーのタスクを明示的な意図として渡してください。タスクのテキストは、ユーザーが自分の言葉で達成しようとした内容そのものなので、それ自体が意図となります。制約、除外事項、受け入れ条件、後からの決定など、ユーザーが直接示した要件を維持してください。差分の要約にまとめたり、実装の説明を加える際に要件を省いたりしてはなりません。作業中に行った決定やトレードオフを補足してください（Intent is required を参照）。

テスト品質ルール

実装のソースコードを開く、読み取る、grep する、解析する、またはスナップショットを取得するだけで、特定の文字列、トークン、行、コマンド、関数名、プロンプトの表現、正規表現の一致、AST の構造、あるいは付随的なスナップショットが見つかるかどうかを根拠とするテストは、決して追加しないでください。これでは動作を証明できません。一致したテキストが実行されないコードやコメント内にある可能性があり、動作を変えないリファクタリングでも変わる可能性があるからです。

代わりに、公開インターフェースまたは実行可能なインターフェースを実行し、観測可能な動作、状態、出力、副作用、失敗モードを検証してください。ワークフロー YAML、JSON、ポリシー、.gitignore、生成された設定など、機械によって利用される宣言的な成果物については、可能であれば実際の利用側を呼び出すか、型付きまたは正規化された意味モデルに解析して、意味を検証してください。ファイルに対する単純な部分文字列検索や正規表現は、依然としてアンチパターンです。

ファイルを読み取ることが正当なのは、そのファイル自体が生成された公開出力、シリアライズされたプロトコル、永続化された状態、意図的なスナップショット、または明示的に管理されているその他のテキストやバイト列の契約である場合です。その契約を明示し、その内容を、無関係なコードが動作することの代わりの根拠として使わないでください。自然言語のプロンプトや指示は、そのソースに文が含まれているからといって、効果が証明されるものではありません。決定論的な CI では、エージェントに渡される最終的な生成済みプロンプトを、意図された生成インターフェースとしてテストできます。モデルによる解釈の評価は、稼働中の LLM を使った CI ではなく、開発専用の評価に含めてください。

独立したオラクルを使用してください。期待される結果は、仕様、具体的な例、公開定数、外部契約、独立した根拠に基づく性質など、テスト対象のコード以外から導き出される必要があります。公開される動作、そのオラクルの情報源、そしてテストで排除できるもっともらしい誤動作を明示してください。自分で用意したモックだけを検証したり、結果をそれ自体と比較したり、実装と同じ期待値の規則をそのまま写したりしないでください。同じ誤りを共有していると、どちらもテストを通過してしまう可能性があります。外部境界のモック、定数、スナップショット、計算による期待値も、独立した契約を検証するものであれば、引き続き正当です。

回帰テストでは、可能であれば報告された不具合を再現してください。修正前にはテストが失敗し、修正後には成功する必要があります。

以下の内容すべて、つまり前提条件、意図、検証して判断するループは、作業がフィーチャーブランチにコミットされた後も同じように適用されます。

開始する前に

• 検証したい作業は、ブランチにコミットされている必要があります。ゲートが検証するのはコミット済みの履歴であり、未コミットの作業ツリーではありません。
• リポジトリのデフォルトブランチではなく、フィーチャーブランチにいる必要があります。
• リポジトリは、no-mistakes init で初期化済みである必要があります。
• デーモンには、実行可能な設定済みのパイプラインエージェントが必要です。対応するネイティブエージェントバイナリ、agent: cursor または agent: devin の ACP エイリアス、あるいは acpx 経由の明示的な acp:<target> を使用できます。あなたは AXI のドライバーであり、暗黙的なパイプラインエージェントのバックエンドではありません。いずれも利用できない場合、実行は最初のステップの前に失敗し、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 まで）のいずれかちょうど1つを使って、明示的なインテントを指定する必要があります。つまり、ユーザーが達成しようとしていたこと、この作業の背景にある目標や依頼を、ユーザー自身の言葉で記述します。これは差分や変更したファイルの説明ではなく、その変更が実現しようとしている目的です。会話から把握できるので、そのまま渡してください。no-mistakes は、ローカルのエージェントのトランスクリプトから推測する代わりに、指定されたインテントを使用します。空、または空白文字だけの入力は拒否され、推測されることはありません。 入力の処理、空白の保持、再接続の動作については、CLI インテント入力リファレンスを参照してください。

簡潔さよりも、漏れのない記述を心がけてください。レビューのステップでは、明示的なインテントを使って意図的な判断とミスを区別します。そのため、簡素な一行の要約では、ユーザーがすでに選択した事項まで指摘される可能性があります。細かなニュアンスも記録してください。ユーザーの目標、その過程で選んだ具体的な判断とトレードオフ、採用または除外した制約やアプローチ、差分だけを読むレビュー担当者には意外に見える可能性がある、ユーザーから明示的に依頼された事項などです。数文から短い段落程度が一般的です。差分だけを見るレビュー担当者には分からない、会話から把握した内容を記録してください。

検証して判断する

パイプラインを実行し、見つかった内容が提示されたらその都度判断してください：

1. 実行を開始します。最初の判断ポイントまたは終了までブロックされます：

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

   axi run とすべての axi respond は同期的にブロックされます。レビュー、テスト、CI の各ステップには数分かかることがあるため、1 回の呼び出しがしばらく戻ってこない場合があります。これは正常です。遅く感じても、コマンドをキャンセルしたり再実行したりしないでください。どちらのコマンドも既定で --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_for、現在のラウンドの round_active_for、last_activity、サブプロセスのエージェント実行中にはネイティブの agent_pid、および round 1、auto-fix 1/3、fix 2 などの現在のラウンドが含まれることがあります。last_activity に quiet が付いている場合、step_quiet_warning で指定された時間を超えて、ステップのログもネイティブエージェントのライフサイクルに関するアクティビティも届いていません。これは稼働状況を判断する手掛かりであり、キャンセル、再実行、または自分で作業ツリーを編集してよいという意味ではありません。

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
   

   --action fix を指定すると、却下は明示的に行われます。ゲートに表示された各指摘事項は、--findings または --ignore に列挙する必要があります。いずれかを省略した応答は拒否され、不足している ID が示され、ゲートは保留されたままになります。このステップの前のラウンドですでに判断した指摘事項は、その判断を維持するために省略できます。省略しても却下したことにはなりません。また、前のラウンドで修正すると決めた指摘事項を、後の応答で却下することはできません。適用済みの修正を元に戻すことはゲート応答の範囲外なので、再度修正するには --findings に列挙し、そのまま維持するには省略してください。成功した fix 応答は、記録した内容を recorded: オブジェクト（fixed、ignored、kept）で返します。実際に行った判断を確認するため、必ず内容を確認してください。 実行が進行中の間は、自分でコードを編集して指摘事項を修正しないでください。指摘事項と修正はどちらもパイプラインが管理します。ゲートでの役割は、判断して応答することです。--action fix を指定すると、パイプラインが修正を適用し、その結果を再レビューします。同じ理由から、実行が進行中の間は、指摘事項を自分で修正するために abort や rerun を実行しないでください。自分のコードに実際のバグがあっても同様です。実行するとパイプラインの処理中の作業が破棄され、完全な再検証が必要になります。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 例外を記録します。 これは承認権限を付与するものではありません。ask-user の findings は従来どおりエスカレーションしてください。 reason がない場合、Test の承認は引き続き有効です。失敗したコマンド、no-go、または inconclusive の判定を越えた承認は、operator reason が指定されていない例外として報告されます。
   • --add-finding '<json>'（--action fix とともに）は、あなた自身が 気づいた finding — パイプラインが表面化しなかったもの — を、JSON の finding オブジェクトとして fix ラウンドに組み込みます。ゲート自身の findings テーブルにない、あなたが気づいた問題に使用します。
   • --ignore <id1,id2>（--action fix とともに）は、指定した findings を辞退します。 ゲートの findings テーブル内のすべての finding は --findings または --ignore に現れる必要があります。省略されたものは拒否され、 id が示されるため、省略が辞退として記録されることは決してありません。このステップの 以前のラウンドで既に fix を選択した finding はここにリストできません: 適用済みの fix を revert することはゲート応答の範囲外です。
   • --step <name> は、現在承認待ちのステップではなく、特定のステップに応答します。 これが必要になることはほとんどありません。アクティブなゲートに応答するには省略してください。

3. 出力に gate: ではなく outcome: が含まれるまで、ステップ 2 を繰り返します。outcome は 次のとおりです:

   • checks-passed - 変更が検証され、CI がグリーンです（または 信頼されたデフォルトブランチ設定が no_ci: true を宣言し、チェックが 登録されていない場合 — 該当する場合、help 行がその宣言を明示します）が、 PR はまだマージされていません。あなたのパイプラインの推進は完了です。 マージを 待たないでください: PR の準備ができたことをユーザーに伝え、レビューと マージを依頼してください（PR リンクは help 行にあります）。その宣言なしの 一般的な空の forge チェックリストは準備完了ではありません。no-mistakes は マージ、クローズ、または設定されたアイドルタイムアウトの経過まで、バックグラウンドで PR の監視を続けるため、人間は TUI でそれを確認できます。
   • passed - 要求されたステップの下で、明示的な実行ごとのスキップを含め、 パイプラインが完了しました。これだけでは PR がマージされた証拠にはなりません。
   • passed-with-override - 明示的に承認された Test 例外または CI 失敗とともに パイプラインが完了しました。 クリーンな pass ではなく、例外を報告してください。 Test の証拠は run.test_override_reason にあり、CI readiness が checks-passed を 返す場合も含みます。サマリーから省略しないでください。
   • passed-with-skips - 公開または CI 検証が自動的にスキップされました。 欠落している証拠とその原因を run.automatic_skips から報告し、 完全な run.head_sha に紐づけてください。これは CI readiness でも 失敗するコード判定でもありません。明示的な実行ごとのスキップは既存の動作を維持します。
   • failed または cancelled - 完了しませんでした。出力を読み、対処してください。 出力が指し示すもの（失敗したテスト、lint エラー、スキップした finding）を修正する前に、 以下の custody ガイダンスに従ってください。修正は同じフィーチャーブランチにコミットし、 no-mistakes axi run --intent "..." で送信してください。新規の run または rerun は 実行間 のアクションであり、このような終端の outcome の後でのみ正しく — ゲートを回避するために実行中に行っては決してなりません。ユーザーを failed の outcome に置き去りにして、リトライもせず、何が妨げているかの説明もないままにしないでください。 no-mistakes rerun は既存のヘッド選択を維持します。ゲートヘッド、または受け渡しが未完了の間は、最新の終端実行における検証済みの未公開の保持ヘッドを選択します。既知のクリーンな呼び出し元の HEAD が選択されたヘッドと異なる場合、実行を開始または置き換える前に拒否し、両方の完全な SHA を報告します。呼び出し元のヘッドを代わりに使用したり、両者を一致させるためにどちらかのブランチを移動したりすることはありません。拒否された場合は、no-mistakes axi status を確認し、以下の受け渡しに関するガイダンスに従ってください。ダーティな呼び出し元、およびクリーンなヘッドの証拠がない呼び出し元では、既存の選択動作が維持されます。 パイプライン後のローカルコミットを行う前、または新たに実行を開始する前に、AXI のホーム、ステータス、またはドライブの結果が返す構造化された branch_sync オブジェクトを確認してください。 その next_action.code が sync の場合に限り、まず no-mistakes axi sync を実行してください。 このガード付き同期では、厳密なファストフォワード、または同期前の HEAD をアンカーしてからリセットのセマンティクスでブランチを移動する、内容が同等の分岐先への進行が行われる場合があります。実際の分岐がある場合は引き続きブロックされ、ブランチ参照を移動しない git checkout --detach <pushed-sha> が示されます。 next_action.code が continue_active_run の場合、ブランチはまだパイプラインが管理しています。報告されたコマンドを実行し、アクティブな実行を引き続き進め、ローカルで後続コミットを作成しないでください。 next_action.code が recover_custody の場合は、コマンドを再構成せず、正確な next_action.command を実行してください。これは、まだ利用可能な、保持されたパイプライン HEAD を引き継ぐ no-mistakes axi sync --recover、または次の 2 つの「ローカルを保持」するケースでの no-mistakes axi sync --recover --keep-local です。1 つ目は、アクセス可能なゲートで検証済みの保持 HEAD がないことが確認され、未公開のコミットを明示的に破棄する場合です。2 つ目は、紐付けられたアーカイブによって、復旧時にブランチを報告された正確な必須 HEAD に保ち、アーカイブを選択、マージ、または再適用せずに、分岐後の作業が保持されていることが証明される場合です。報告された「ローカルを保持」するアクションを、通常の --recover や rerun に置き換えないでください。no-mistakes rerun は、上記のクリーン HEAD チェックを条件として、まだ利用可能な通常の保持 HEAD の検証を再開できます。 通常の復旧では、その HEAD へのファストフォワードを行うか、復旧前の HEAD を refs/no-mistakes/recover-local/<run> の下にアンカーしたうえで、分岐した保持 HEAD がすべてのローカル変更を含むと証明できる場合にそれを採用します。後者は、パイプラインがコミットをより新しいベースにリベースした場合の通常の結果です。 通常の封じ込めの証明範囲は意図的に限定されています。そのため、修正ラウンドによって自分の行も書き換えられたリベースは、採用されずに拒否されます。パイプラインによる意図的な修正と、変更の欠落を区別する方法がない場合は、判断をあなたに委ねます。 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 を使うと、保持されたコミットは refs/no-mistakes/recover/<run> の下にアンカーされたまま、現在の HEAD が保持されます。同じフラグは、アクセス可能なゲートで検証済みの保持 HEAD がないことが確認され、復旧参照に問題がない場合の復旧方法でもあります。その場合は、対象オブジェクトがなくても、現在のローカル HEAD で管理権限が戻ります。 同期がブロックされた場合は、リセット、スタッシュ、マージ、リベース、強制操作、ブランチの置き換えを独自に行わず、構造化された状態に従って処理してください。 同期後、後続の変更をその上にコミットし、元のユーザーの意図を使って no-mistakes axi run --intent "..." を再実行してください。 これにより、設定された件名にかかわらず、以前のゲート修正コミットがすべて保持されます。 CI ステップは、チェックに合格した後も PR の監視を意図的に継続します。そのため、チェックがすべてグリーンになった時点（または、チェックがゼロのリポジトリを信頼できる no_ci: true の宣言がカバーしている場合）で axi run は checks-passed を返し、人によるマージを待ってブロックすることはありません。自分でマージを待ってポーリングしたり、再実行したりしないでください。「CI チェックが報告されていない」ことだけをグリーンと見なしてはいけません。

この監視は継続して実行されるため、チェック合格後に PR がデフォルトブランチより遅れたり、マージコンフリクトが発生したりしても（通常は別の PR が先にマージされたことが原因です）、あなたがコマンドを実行する必要はありません。手動でリベースしないでください。CI モニターが実際のコンフリクトを検知すると、ベースブランチにリベースして解決し、リベースではレビュー済みのヘッドとの継続性を証明できないため Review から再検証し、Push を通じてブランチを再プッシュします。単に遅れているだけでクリーンな PR も、プラットフォームがマージするため対応は不要です。例外は、そのモニターが実行されていない場合です。PR がクローズされた、実行が中止または置き換えられた、アイドルタイムアウトになった、自動修正の試行回数を使い切った場合は、前述のクリーンヘッドの確認を条件として、no-mistakes rerun で復旧してください。受け付けられた再実行は古いモニターをキャンセルし、決定論的なリベースステップを含むパイプライン全体を再実行します。まだアクティブな PR を更新するために no-mistakes axi run を使わないでください。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 の指摘について確認を求めずに自動で解決します。

実行全体を自動的に進めることについて明確な同意がある場合は、axi run または axi respond に --yes を渡してください。対象となるゲートでは、対応可能な指摘（auto-fix と ask-user の両方）を修正への同意として扱い、現在の指摘をすべて選択して一度の修正ラウンドに含め、修正後のレビューを受け入れ、no-op の指摘しかないゲートを承認します。ユーザーから、確認を求めずに実行全体を進めるよう依頼された場合に限り使用してください。

protected-path-refusal ゲートでは、--yes を指定していてもオペレーターによる明示的な応答が必要です。パスとルールを伝え、自動で修正、承認、スキップしないでください。承認は拒否されます。オペレーターに報告された編集を確認して解決してもらってから、未完了のステップを再試行するために --action fix を送信してください。保護対象パスのリファレンスで、ステージングガードの適用範囲と制限を確認できます。

未解決の question-<id> の指摘があるゲートも対象外です。質問は判定ではなく axi answer によって確定されるため、この場合 --yes は処理を進めません。また、質問の履歴を最初から最後まで読み取れない場合も同様に、処理を保留して人の対応を求めます。

test-agent-unvalidated-work の指摘は、タイムアウトした Test エージェントがコミットまたは変更を残したものの、Test のターンで検証されていないことを示します。承認は拒否されるため、--yes を指定していても、このゲートで応答せず停止します。指摘に記載された内容を伝え、その作業が公開されてしまうため Test をスキップしないでください。オペレーターに、--action fix でエージェントの予算を追加して作業を検証するか、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> で指定した、別のブランチに属する実行です。そのステータスや結果を自分の作業のものとして扱わないでください。現在のブランチが不明な場合（detached HEAD またはブランチの取得失敗）に run: の下に表示される明示的な --run <id> は、ブランチとの関係を示しません。ステータスの応答が正常に返り、run オブジェクト自体がない場合は、直近の実行テーブルの内容にかかわらず、このブランチにはまだ実行がありません。error: の応答は実行の所有関係について何も証明しないため、ブランチがアイドル状態だと判断せず、エラーに対処してください。
• 終了状態に達していない run オブジェクトには、status の直後に awaiting_agent: parked <duration> が含まれる場合があります。これは、run がゲートで停止していることを意味します。暗黙的に解決された現在のブランチのゲートに限り、引数なしの axi respond を使用できます。明示的な --run <id> を指定したステータス確認は、そのブランチに属する場合でも確認専用です。ブランチには、より新しいアクティブな run が存在する可能性があるためです。この場合、応答コマンドとして axi respond --run <id> が示されます。応答の help に従ってください。
• running または fixing のステップを含む run オブジェクトには、active_steps テーブルが含まれる場合があります。active_for は、そのテーブルを含むステップの経過時間です。round_active_for は、表示されている実行ラウンドまたは修正ラウンドの経過時間で、修正ラウンドではリセットされます。ラウンドの時間情報がない古い run では、round_active_for は空欄です。
• ほとんどの応答の末尾にある help リストには、次に実行するコマンドが示されます。
• エラーは stdout に error: ... として出力され、help リストも表示されます。提示された内容に従って対処してください。
• 終了コード：0 は成功、変更なし、または通常の判断ゲート、1 は最終結果が失敗またはキャンセル、2 は使い方の誤りです。

あなたの対応を待つ gate: は、おおよそ次のように表示されます。ステップ名を示す gate: の行、note などの任意のステップ固有フィールド、各指摘を1行ずつ示す 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（ユーザーへの確認）は、応答する前に停止してユーザーに確認してください。最終状態では、findings テーブルは表示されず、代わりに outcome: <checks-passed|passed|passed-with-override|passed-with-skips|failed|cancelled> が表示されます。フィールド名や正確な列はステップやバージョンによって異なる場合があるため、この形式を決めつけず、実際の findings ヘッダーを確認してください。