FFS — Reibung → Korrektur → Absicherung
Nutzen Sie Sitzungs-Reibung, um das Harness zu verbessern. Wenn der Nutzer eine Korrektur zum zweiten Mal wiederholen muss, ist das ein Beweis dafür, dass Prosa versagt hat und eine mechanische Absicherung gerechtfertigt sein könnte.
Architektur
Bauen Sie keinen weiteren Regelgenerator. Nutzen Sie die vorhandenen Schichten:
- Extrahieren – Ein deterministischer Miner über die Sitzungstranskripte des Agenten findet wiederholte Nutzerkorrekturen und paart jede mit der Assistentenaktion davor und der korrigierten Aktion danach. (Bei AgentsView-basierten Setups erledigt dies ein Extrahierer wie
avmine.py rules; jeder JSONL-Transkriptspeicher kann auf die gleiche Weise geminnt werden.) - Klassifizieren – Entscheiden, ob der Fehler mechanisch erkennbar ist.
- Generieren und validieren – Übergeben Sie ein Beweisbündel an den vorhandenen Regelgenerierungspfad des Harness (z. B. einen
/omfg-artigen Befehl), anstatt ihn neu zu implementieren. - Durchsetzen – Speichern Sie die akzeptierte Ausgabe als Projektregel (
.omp/rules/<name>.md) oder eine globale Regel (~/.omp/agent/rules/<name>.md). - Verifizieren – Testen Sie positive und negative Beispiele gegen die Regel-Engine; minen Sie später die Transkripte erneut, um zu bestätigen, dass die Korrektur nicht mehr auftritt.
Wann eine Reibung zu einer Regel wird
Erstellen Sie eine Regel nur, wenn alles zutrifft:
- Der Nutzer hat dasselbe Verhalten mindestens zweimal korrigiert, oder einmal mit einer expliziten Sicherheitsfolge.
- Die anstößige Aktion ist mechanisch im Assistententext oder in Tool-Argumenten erkennbar.
- Ein sicherer Ersatz kann angegeben werden, ohne den Kontext zu erraten.
- Keine vorhandene Regel deckt das Muster bereits ab.
Leiten Sie es andernfalls woanders hin:
| Fehler | Ziel |
|---|---|
| Erkennbarer Befehl, Pfad, Flag oder Ausgabetext | Regel |
| Mehrschrittiger Arbeitsablauf mit Urteilsvermögen | Skill |
| Stabile Präferenz oder Prinzip | AGENTS.md |
| Tool-Fakt oder Verfahren | Notizen / Projektwissen |
| Einmalige historische Korrektur | Journal / Quellenaufzeichnung |
Mining-Verfahren
Führen Sie zuerst den deterministischen Extrahierer aus. Wenn dieser nicht verfügbar ist, durchsuchen Sie die Roh-Transkripte nach Korrekturphrasen und untersuchen Sie die umgebenden Assistenten-Turns; leiten Sie die anstößige Aktion nicht allein aus der Korrektur ab.
Für jeden Kandidaten behalten Sie:
- exakte Nutzerkorrektur und Zeitstempel
- Projekt und stabile Sitzungs-ID
- Assistentenbefehl/-text unmittelbar davor
- korrigierter Befehl/Text unmittelbar danach
- Wiederholungsanzahl über verschiedene logische Sitzungen hinweg
- empfohlener Geltungsbereich: Projekt oder global
- positiver Test (muss auslösen)
- negativer Test (darf nicht auslösen)
Verwenden Sie keine automatisch generierten Sitzungszusammenfassungen als Beweise. Sie paraphrasieren und duplizieren. Verwenden Sie Roh-Transkriptnachrichten und Tool-Aufrufe.
Regelgenerierungs-Übergabe
Übergeben Sie die Beschwerde zusammen mit dem konkreten Vorher/Nachher-Paar an den vorhandenen Regelgenerator, der bereits:
- einen Regelkandidaten generiert
- seine Bedingung anhand der Assistentenhistorie validiert
- Projekt- vs. globalen Geltungsbereich anbietet
- Änderungen vor dem Speichern erlaubt
Duplizieren Sie diese Maschinerie nicht im Extrahierer oder in dieser Fähigkeit.
Verifikation
Führen Sie für jede akzeptierte Regel sowohl einen negativen als auch einen positiven Fall durch die Regel-Engine aus (z. B. mit OMPs TTSR):
omp ttsr test --rule <absoluter-regel-pfad> --source tool --tool <tool> '<schlechte-eingabe>' -v
omp ttsr test --rule <absoluter-regel-pfad> --source tool --tool <tool> '<gute-eingabe>' -v
Der erste muss auslösen; der zweite darf nicht. Eine Regel, die den sicheren Pfad blockiert, ist schlimmer als keine Regel.
Nach einer Woche minen Sie dieselbe Korrektur erneut. Null Wiederholungen sind ein Beweis dafür, dass die Regel funktioniert hat. Eine Wiederholung bedeutet, dass die Bedingung die tatsächliche Form verfehlt hat; korrigieren Sie anhand von Beweisen, nicht durch blindes Verbreitern.
Referenzbeispiel: „puttys pls“
Transkripte zeigten dieselbe Korrektur an zwei aufeinanderfolgenden Tagen. Davor führten Sitzungen undurchsichtige Einzeiler-SSH/Exec-Befehle gegen entfernte Testbed-Hosts ohne sichtbares Terminal aus. Danach starteten sie sichtbare Terminalsitzungen durch benannte putty-* Wrapper-Skripte.
Die resultierende Projektregel (<projekt>/.omp/rules/visible-putty-operations.md) fängt die undurchsichtigen Befehlspfade ab, erlaubt die sichtbaren Wrapper und wird durch die historischen Korrekturereignisse gestützt – drei Runden von Beweisen, nicht eine Vermutung.