FFS — 摩擦 → 修正 → 防御
セッションの摩擦を活用してハーネスを改善します。ユーザーが修正を繰り返さなければならない2回目は、説明では不十分で機械的な防御策が必要である証拠です。
アーキテクチャ
別のルールジェネレーターを構築しないでください。既存のレイヤーを使用します：
- 抽出 — エージェントのセッションログに対する決定論的マイナーが、繰り返されるユーザーの修正を見つけ、それぞれをその前のアシスタントのアクションと修正後のアクションとペアにします。（AgentsView対応のセットアップでは、
avmine.py rulesのような抽出ツールがこれを実行します。JSONLトランスクリプトストアであれば同じ方法でマイニングできます。） - 分類 — 失敗が機械的に検出可能かどうかを判断します。
- 生成と検証 — 1つの証拠バンドルをハーネスの既存のルール生成パス（例：
/omfgスタイルのコマンド）に渡します。再実装はしません。 - 強制 — 承認された出力をプロジェクトルール（
.omp/rules/<name>.md）またはグローバルルール（~/.omp/agent/rules/<name>.md）として保存します。 - 検証 — 陽性例と陰性例をルールエンジンに対してテストします。その後、トランスクリプトを再マイニングして修正の再発が止まったことを確認します。
摩擦がルールになる条件
以下のすべてが真の場合にのみルールを作成します：
- ユーザーが同じ動作を少なくとも2回修正した、または1回で明示的な安全上の結果があった。
- 問題のある動作がアシスタントのテキストまたはツール引数で機械的に認識可能である。
- 文脈を推測せずに安全な代替案を述べることができる。
- 既存のルールがそのパターンをカバーしていない。
それ以外の場合は、他の適切な場所に振り分けます：
| 失敗の種類 | 格納先 |
|---|---|
| 検出可能なコマンド、パス、フラグ、または出力フレーズ | ルール |
| 判断が必要なマルチステップワークフロー | スキル |
| 安定した好みや原則 | AGENTS.md |
| ツールの事実や手順 | ノート / プロジェクト知識 |
| 一度限りの過去の修正 | ジャーナル / ソース記録 |
マイニング手順
最初に決定論的抽出ツールを実行します。それが利用できない場合は、生のトランスクリプトから修正フレーズを検索し、周囲のアシスタントのやり取りを調査します。修正だけで問題のある動作を推測しないでください。
各候補について以下を保持します：
- 正確なユーザーの修正とタイムスタンプ
- プロジェクトと安定したセッションID
- その直前のアシスタントのコマンド/テキスト
- その直後の修正されたコマンド/テキスト
- 異なる論理セッションにわたる再発回数
- 推奨スコープ：プロジェクトまたはグローバル
- 陽性テスト（トリガーされる必要あり）
- 陰性テスト（トリガーされてはならない）
自動生成されたセッション要約を証拠として使用しないでください。それらは言い換えや重複を含みます。生のトランスクリプトメッセージとツール呼び出しを使用してください。
ルール生成の引き継ぎ
不満と具体的なbefore/afterペアを既存のルールジェネレーターに渡します。既存のジェネレーターはすでに以下を実行します：
- ルール候補を生成する
- その条件をアシスタントの履歴に対して検証する
- プロジェクトスコープとグローバルスコープを提供する
- 保存前に修正を許可する
抽出ツールやこのスキルにそのメカニズムを複製しないでください。
検証
受け入れられたすべてのルールについて、ルールエンジン（OMPのTTSRを使用する場合など）で陰性ケースと陽性ケースの両方を実行します：
omp ttsr test --rule <absolute-rule-path> --source tool --tool <tool> '<bad input>' -v
omp ttsr test --rule <absolute-rule-path> --source tool --tool <tool> '<good input>' -v
最初のコマンドはトリガーされなければならず、2番目はトリガーされてはなりません。安全なパスをブロックするルールは、ルールがないことより悪いです。
1週間後、同じ修正を再度マイニングします。再発ゼロはルールが機能した証拠です。再発がある場合は、条件が実際の形式を見逃していたことを意味します。証拠に基づいて修正し、盲目的に広げないでください。
参考例：「puttys pls」
トランスクリプトは、2日連続で同じ修正を示していました。修正前は、セッションはリモートテストベッドホストに対して不透明なワンライナーSSH/execコマンドを実行し、表示可能な端末がありませんでした。修正後は、名前付きの putty-* ラッパースクリプトを通じて表示可能な端末セッションを起動しました。
結果として得られたプロジェクトルール（<project>/.omp/rules/visible-putty-operations.md）は、不透明なコマンドパスをキャッチし、表示可能なラッパーを許可します。このルールは、過去の修正イベント（推測ではなく3回の証拠ラウンド）に基づいています。