FFS — 마찰 → 수정 → 보호은(는) 무엇을 하나요?
세션 마찰을 활용하여 하네스를 개선합니다. 사용자가 수정을 반복해야 하는 두 번째 시점은, 글로 설명이 실패했으며 기계적 보호가 필요할 수 있음을 증명하는 증거입니다.
아키텍처
또 다른 규칙 생성기를 구축하지 마십시오. 기존 계층을 활용하십시오:
- 추출 — 에이전트 세션 기록에서 결정론적 마이너가 반복되는 사용자 수정을 찾아내고, 각 수정을 그 이전의 어시스턴트 동작 및 수정된 이후의 동작과 쌍을 이룹니다. (AgentsView 기반 설정의 경우
avmine.py rules와 같은 추출기가 이를 수행합니다. 모든 JSONL 기록 저장소도 동일한 방식으로 채굴할 수 있습니다.) - 분류 — 실패가 기계적으로 탐지 가능한지 결정합니다.
- 생성 및 검증 — 하나의 증거 묶음을 하네스의 기존 규칙 생성 경로(예:
/omfg스타일 명령어)로 전달하여 재구현하지 않습니다. - 적용 — 수락된 출력을 프로젝트 규칙(
.omp/rules/<name>.md) 또는 전역 규칙(~/.omp/agent/rules/<name>.md)으로 저장합니다. - 확인 — 긍정 및 부정 예제를 규칙 엔진에 대해 테스트합니다. 나중에 기록을 다시 채굴하여 수정이 더 이상 반복되지 않는지 확인합니다.
마찰이 규칙이 되는 경우
다음 조건이 모두 참인 경우에만 규칙을 생성하십시오:
- 사용자가 동일한 동작을 최소 두 번 수정했거나, 명시적인 안전 결과와 함께 한 번 수정했습니다.
- 문제가 되는 동작이 어시스턴트 텍스트나 도구 인수에서 기계적으로 인식 가능합니다.
- 안전한 대체 동작을 컨텍스트 없이 명시할 수 있습니다.
- 기존 규칙이 이미 해당 패턴을 다루고 있지 않습니다.
그렇지 않으면 다른 곳으로 라우팅하십시오:
| 실패 유형 | 저장소 |
|---|---|
| 탐지 가능한 명령어, 경로, 플래그 또는 출력 문구 | 규칙 |
| 판단이 필요한 다단계 워크플로 | 스킬 |
| 안정적인 선호도 또는 원칙 | AGENTS.md |
| 도구 팩트 또는 절차 | 노트 / 프로젝트 지식 |
| 일회성 역사적 수정 | 저널 / 소스 기록 |
채굴 절차
먼저 결정론적 추출기를 실행하십시오. 사용할 수 없는 경우 원시 기록에서 수정 문구를 검색하고 주변 어시스턴트 응답을 검사하십시오. 수정 자체만으로 문제가 되는 동작을 추론하지 마십시오.
각 후보에 대해 다음을 유지하십시오:
- 정확한 사용자 수정 및 타임스탬프
- 프로젝트 및 안정적인 세션 ID
- 바로 앞의 어시스턴트 명령어/텍스트
- 바로 뒤의 수정된 명령어/텍스트
- 서로 다른 논리적 세션 간 반복 횟수
- 권장 범위: 프로젝트 또는 전역
- 긍정 테스트 (반드시 트리거되어야 함)
- 부정 테스트 (반드시 트리거되지 않아야 함)
자동 생성된 세션 요약을 증거로 사용하지 마십시오. 이들은 의역하고 중복됩니다. 원시 기록 메시지와 도구 호출을 사용하십시오.
규칙 생성 핸드오프
불만 사항과 구체적인 before/after 쌍을 기존 규칙 생성기에 전달하십시오. 이 생성기는 이미 다음을 수행합니다:
- 규칙 후보를 생성합니다.
- 조건을 어시스턴트 기록에 대해 검증합니다.
- 프로젝트 vs 전역 범위를 제공합니다.
- 저장 전 수정을 허용합니다.
추출기나 이 스킬에서 해당 메커니즘을 중복 구현하지 마십시오.
확인
수락된 모든 규칙에 대해, 규칙 엔진(예: OMP의 TTSR 사용)을 통해 부정 및 긍정 케이스를 각각 실행하십시오:
omp ttsr test --rule <절대-규칙-경로> --source tool --tool <도구> '<잘못된 입력>' -v
omp ttsr test --rule <절대-규칙-경로> --source tool --tool <도구> '<올바른 입력>' -v
첫 번째는 반드시 트리거되어야 하고, 두 번째는 트리거되지 않아야 합니다. 안전한 경로를 차단하는 규칙은 규칙이 없는 것보다 나쁩니다.
일주일 후, 동일한 수정을 다시 채굴하십시오. 반복이 0회이면 규칙이 효과가 있었음을 증명합니다. 반복이 발생하면 조건이 실제 형태를 놓친 것입니다. 증거에 기반하여 수정하고, 맹목적으로 확장하지 마십시오.
참고 예제: "puttys pls"
기록에서 이틀 연속으로 동일한 수정이 나타났습니다. 수정 전에는 원격 테스트베드 호스트에 대해 불투명한 한 줄짜리 SSH/exec 명령어가 실행되었으며, 눈에 보이는 터미널이 없었습니다. 수정 후에는 이름이 지정된 putty-* 래퍼 스크립트를 통해 보이는 터미널 세션이 실행되었습니다.
결과 프로젝트 규칙(<project>/.omp/rules/visible-putty-operations.md)은 불투명한 명령어 경로를 포착하고, 보이는 래퍼를 허용합니다. 이 규칙은 세 번의 증거를 통해 뒷받침됩니다. 추측이 아닌 실제 수정 이벤트에 기반합니다.