refit

リフィット

リフィットでは、エージェントが作業した環境を調査します。エージェントが生成したコード（そのレビューと検証は別の役割です）や、1 回のローンチ実行で得た教訓（それはセディメントパスの役割です）は対象ではありません。どのような作業にも、何らかの摩擦が残ります。同じチェックで何度もつまずくラルフループ、シグナルを待って停止したオートパイロットの実行、決定的な出力がどこにも記録されなかったデバッグセッションなどです。OMC はそのすべてを計測します。リフィットは計測結果を読み取り、記録された摩擦を環境の変更に変えることで、次の実行がより良い環境から始められるようにします。

まず証拠を確認する

調査はチェックリストではなく、OMC の計測結果から始めます。ユーザーに何か尋ねる前に、次を読みます。

• trace_timeline／trace_summary — ターンが停止した箇所、繰り返された箇所、無駄に分岐した箇所
• omc session friction report — セッション自身が記録した摩擦
• .omc/logs/ とセッション状態 — エラー、再試行、握りつぶされた失敗
• プランのメモ帳 .omc/notepads/*/issues.md と problems.md — プラン全体を通じて積み重なった問題
• リポジトリ独自のチェック環境（package.json のスクリプト、CI ワークフロー）— 新たなチェックを提案する前に確認します。既存のチェックが接続されていない、または気づかれないまま壊れていること自体が調査結果であり、再発明する対象ではないためです。

調査結果はデータが示す内容から導きます。調査結果がないことも妥当な結果であり、その旨を明確に伝えます。調査結果の捏造は、調査を省略するのと同じ違反です。接続された自動チェックがないリポジトリは、中立的な初期状態ではなく、それ自体が調査結果です。

修正を担う 4 つの領域

各調査結果では、その修正を担う領域を明示します。どの領域にも当てはまらない調査結果は、その理由を明記して採用しません。

1. 決定論的チェック — 固定された構文パターン、禁止 API、インポート形式、ファイル配置ルールなど、機械的な要因による失敗です。修正には、リポジトリの既存のガードレールを踏まえて最も低コストなものとして、リンタールール、フック、または CI ジョブを導入します。ルールを書くより、チェックを構築することを優先します。
2. 指針の領域 — どのガードレールでも代替できない判断、たとえばファイル間の一貫性や周囲のスタイルとの整合性に関する失敗です。修正は該当する docs/standards/ のドキュメント、またはローンチのセディメントパスで定める簡潔なエントリーポイントの予算内で CLAUDE.md／AGENTS.md に反映します。説明文より、参照先へのポインターを優先します。
3. ツールの領域 — 高コスト、またはトークン効率の悪い MCP 呼び出し、自動化の不足、必要なタイミングで実行できないほど遅いチェックなど、ツール自体が作業の妨げになった場合です。修正は .mcp.json、scripts/、フック、または OMC の設定に反映します。
4. 情報の領域 — 開発サーバーのログ、サービスの状態、サードパーティの読み取り専用アクセスなど、エージェントが必要なシグナルにアクセスできなかった場合です。ログへの出力、状態の公開、またはアクセス方法の文書化によって修正します。

この区分は、どこに強制力が働くかに基づいています。実装のコンテキストには、その強制力の大半があります（調査、執筆、デバッグをすべて同時に行うためです）。レビューのコンテキストに届くのは、そうした強制力が働かない差分です。そのため、標準は実装者に読み込ませる指示を増やすのではなく、レビュアーとチェックに向けたものにします。

提案と反映

1. 調査結果を重要度順に並べ、それぞれを 調査結果 → 領域 → 予定する変更 の形式で提示し、計測結果の証拠（どの計測器が何を示したか）を 1 行添えます。
2. ユーザーの承認を待ちます。各項目は個別に承認または却下できます。
3. 承認された調査結果を各領域に反映します。指針となる文章を書く前に、Skill ツールを呼び出して agent-doc-discipline を指定し、その検証チェックリストを通過させます。新しく導入した決定論的チェックは、反映済みと見なす前に実際に機能することを証明する必要があります。まずクリーンな状態で実行し、次に意図的に違反を導入して失敗することを示し、最後にその違反を元に戻します。失敗を示せないチェックは提案に戻します。発動するところを誰も見たことのないガードレールは、保護ではなく飾りです。
4. 各調査結果の反映先を 1 行につき 1 つのファイルパスで記録します。次のリフィットが記憶ではなく記録から始められるようにするためです。ローンチ実行のセッションでリフィットを行う場合は、その実行のセディメントリストから始めます。ローンチ実行では、教訓の名前を挙げることで、後のリフィットまでその反映を保留できます。

ヘッドレスリファクト（無人実行）

リファクトはユーザーが実行しますが、調査の実行にユーザーがキーボードの前にいる必要はなく、必要なのは承認時だけです。ホストのスケジューラー（cron、CI タイマー、自動化ツール）によって、ヘッドレスエージェントセッションを開始し、このスキルを呼び出せます。調査は同じ契約に従い、所定の境界まで実行されます。

• 調査では同じ手段を読み取りますが、どこにも適用しません。ヘッドレスリファクトが出力するのは提案リストのみです。各項目は finding → surface → intended change の形式で、根拠となる手段の証拠を1行添えます。これは .omc/refit/pending-proposals.md に書き込まれ、通知チャネルが設定されている場合（configure-notifications）、そこにも要約が送信されるため、ユーザーは調査結果の確認が待っていることを知ることができます。
• 対話型リファクトと同様に、ユーザーの承認なしに提案が適用されることはありません。提案は順位付きで保留され、それぞれ個別に却下できます。次回の対話型リファクトでは、調査を再実行せず、保留中のリストから開始します。
• 調査結果がない場合は、「検出事項なし」と明記し、内容を水増ししません。検出事項の捏造は、調査の省略と同じ違反です。

出力

• 重大度順に並べた検出事項。各項目に根拠、適用先、意図する変更を含め、各行を個別に判断できます
• 承認後：適用された内容と適用先
• 却下された検出事項とその理由