rch

RCH — リモートコンパイルのスペシャリスト

RCH は、明示されたコンパイルコマンドを 1 つオフロードするか、リモートコンパイラの経路を調査します。このスキルは何が起きたかを報告します。再試行や修復を制御するものではありません。

段階的な診断が有効なのは、オフロードパイプラインが順番に失敗するためです。可用性、設定、フック、分類、同期、リモートコンパイル、ワーカーの負荷という順に進むため、最初に失敗した段階から障害箇所を特定でき、それ以降の段階はその段階を通過するまでノイズになります。不可逆性の低い順に対処します。読み取り専用の確認と設定の調査を先に行い、デーモンの再起動はその後、クリーンアップはさらにその後に行います。破壊的なクリーンアップやワーカーの変更は、呼び出し元から明示的な権限が与えられた場合に限ります。

名前付きの失敗モード — green-local blindness：[RCH] local (...) と表示されたビルドが成功すると、オフロードも成功したと思い込むことです。ローカルへのフォールバックによって、リモート実行の主張が実証されていないことが隠されます。

アンチパターン：フォールバックの理由が消えることを期待してビルドを再実行することです。 修正方法：記録されたフォールバックの理由を確認し、その段階を修正します。パイプラインは気まぐれにではなく、決定的に失敗します。

手順

1. 変更を加える前に、rch check、rch doctor --json、ワーカーのステータス、および該当する [RCH] のサマリーを記録します。
2. 診断では、最初に失敗した段階を特定します。可用性、設定、フック、分類、同期、リモートコンパイル、またはワーカーの負荷です。
3. 呼び出し元から許可されたコマンド、または文書化された安全な診断のみを 1 回実行します。
4. 正確なコマンド、判明している場合はワーカー、終了コード、ローカルへのフォールバック理由、および実行後のステータスを記録します。
5. そこで停止し、証拠を返します。

[RCH] local (...) は、ローカルビルドが成功していても、要求されたリモートオフロードの主張が実証されていないことを意味します。破壊的なクリーンアップ、ワーカーのデプロイ、デーモンの設定、およびリモートの変更には、呼び出し元からの明示的な権限が必要です。

rch check の終了ステータスで準備状況を判定します（0 = 準備完了、0 以外 = オフロードの準備未完了）。rch doctor --json の success: true を準備完了と解釈しないでください。診断レポートが正常に完了しても、デーモンが停止していたり、ワーカーに到達できなかったりする場合があります。判定には rch check を使い、その理由の確認には doctor を使います。

出力

ステータス（remote、local_fallback、failed、または not_proven）、コマンドと終了コード、ワーカー、サマリー行、および確認済み／未確認の対象範囲を含む、事実に基づいた情報を返します。次のアクションは含めないでください。ここでの not_proven は実行時の診断ステータスであり、AgentOps の判定ではありません。判定上の重みはなく、verdict.v2 の代わりになることもありません。

参考資料

上記の SKILL.md に定める権限境界は、以下のすべての参考資料に適用されます。参考資料に対処方法が記載されている場合、読み取り専用の診断は自律的に実行できますが、リモート操作、特権操作、または不可逆な操作（リモート／sudo による変更、デーモンの起動／再起動／再設定、ワーカーまたはフリートのデプロイ、ツールチェーンの同期、破壊的なクリーンアップ）には、必ず事前に呼び出し元から明示的な許可を得る必要があります。参考資料によって、カーネルが付与する自律性の範囲が広がることはありません。

• フェイルオープンの理由
• エラーカタログ
• トラブルシューティング
• 復旧プレイブック
• ワーカー操作
• 設定
• 機械可読な情報の取得先