FFS — 摩擦 → 修正 → 防護
利用會話摩擦來改善限制條件。當使用者必須重複某項修正時，這就證明口頭說明已經失敗，可能需要機械式的防護措施。
架構
不要建立另一個規則產生器。請使用現有層級：
- 提取 — 一個確定性挖掘器，從代理的會話記錄中找出重複的使用者修正，並將每個修正與其前後的助理動作配對。（對於基於 AgentsView 的設定，可以使用像
avmine.py rules這樣的提取器；任何 JSONL 記錄儲存庫都可以用相同方式挖掘。） - 分類 — 判斷失敗是否可機械檢測。
- 生成與驗證 — 將一個證據包傳遞給限制條件現有的規則生成路徑（例如
/omfg風格的指令），而不是重新實作。 - 強制執行 — 將接受的輸出儲存為專案規則（
.omp/rules/<name>.md）或全域規則（~/.omp/agent/rules/<name>.md）。 - 驗證 — 對規則引擎測試正向與負向案例；稍後重新挖掘記錄，確認修正不再重複發生。
何時將摩擦轉化為規則
僅在以下所有條件成立時才建立規則：
- 使用者至少修正了同一行為兩次，或一次且有明確的安全後果。
- 違規行為在助理文字或工具參數中可機械識別。
- 可以在不猜測上下文的情況下陳述安全的替代方案。
- 沒有現有規則已涵蓋該模式。
否則將其導向其他位置：
| 失敗類型 | 歸屬 |
|---|---|
| 可檢測的命令、路徑、旗標或輸出短語 | 規則 |
| 需要判斷的多步驟工作流程 | 技能 |
| 穩定的偏好或原則 | AGENTS.md |
| 工具事實或程序 | 筆記 / 專案知識 |
| 一次性歷史修正 | 日誌 / 來源記錄 |
挖掘程序
先執行確定性提取器。如果無法使用，則搜尋原始記錄中的修正短語，並檢查周圍的助理回合；不要僅從修正本身推斷違規行為。
對每個候選項目保留：
- 確切的使用者修正與時間戳記
- 專案與穩定的會話 ID
- 緊接在修正前的助理指令/文字
- 緊接在修正後的指令/文字
- 跨不同邏輯會話的重複次數
- 建議範圍：專案或全域
- 正向測試（必須觸發）
- 負向測試（不得觸發）
不要使用自動生成的會話摘要作為證據。它們會改寫和重複。請使用原始記錄訊息和工具呼叫。
規則生成移交
將投訴以及具體的配對（前/後）交給現有的規則生成器，該生成器已經：
- 生成規則候選項
- 根據助理歷史記錄驗證其條件
- 提供專案與全域範圍的選項
- 允許在儲存前進行修正
不要在提取器或此技能中重複該機制。
驗證
對每個接受的規則，透過規則引擎執行正向與負向案例（例如使用 OMP 的 TTSR）：
omp ttsr test --rule <絕對規則路徑> --source tool --tool <工具> '<不良輸入>' -v
omp ttsr test --rule <絕對規則路徑> --source tool --tool <工具> '<良好輸入>' -v
第一個必須觸發；第二個不得觸發。一個會封鎖安全路徑的規則比沒有規則更糟。
一週後，再次挖掘相同的修正。零重複表示規則有效。出現重複表示條件遺漏了實際形式；應根據證據進行修正，而不是盲目擴大範圍。
參考範例：「puttys pls」
記錄顯示連續兩天出現相同的修正。在此之前，會話對遠端測試機台執行不透明的單行 SSH/exec 指令，沒有可見的終端機。之後，它們透過命名的 putty-* 包裝腳本啟動可見的終端機會話。
產生的專案規則（<project>/.omp/rules/visible-putty-operations.md）會攔截不透明的指令路徑，允許可見的包裝腳本，並以歷史修正事件為依據——三輪證據，而非猜測。