FFS — Friction → Fix → Safeguard

Que fait FFS — Friction → Fix → Safeguard ?

Exploitez les frictions des sessions pour améliorer le harnais. La deuxième fois que l'utilisateur doit répéter une correction est la preuve que le texte a échoué et qu'une sauvegarde mécanique peut être justifiée.

Architecture

Ne construisez pas un autre générateur de règles. Utilisez les couches existantes :

1. Extraire — un mineur déterministe sur les transcriptions de sessions de l'agent trouve les corrections utilisateur répétées et les associe à l'action de l'assistant avant et à l'action corrigée après. (Pour les configurations AgentsView, un extracteur comme avmine.py rules fait cela ; n'importe quel magasin de transcriptions JSONL peut être miné de la même manière.)
2. Classifier — décider si l'échec est mécaniquement détectable.
3. Générer et valider — passer un lot de preuves au chemin de génération de règles existant du harnais (par ex. une commande de style /omfg), plutôt que de le réimplémenter.
4. Appliquer — sauvegarder la sortie acceptée en tant que règle de projet (.omp/rules/<nom>.md) ou une règle globale (~/.omp/agent/rules/<nom>.md).
5. Vérifier — tester les exemples positifs et négatifs par rapport au moteur de règles ; plus tard, reminer les transcriptions pour confirmer que la correction a cessé de se répéter.

Quand une friction devient une règle

Créez une règle uniquement lorsque toutes les conditions suivantes sont vraies :

• L'utilisateur a corrigé le même comportement au moins deux fois, ou une fois avec une conséquence explicite de sécurité.
• L'action incriminée est mécaniquement reconnaissable dans le texte de l'assistant ou les arguments de l'outil.
• Un remplacement sûr peut être énoncé sans deviner le contexte.
• Aucune règle existante ne couvre déjà le modèle.

Sinon, redirigez-le ailleurs :

Échec	Destination
Commande, chemin, drapeau ou phrase de sortie détectable	Règle
Workflow multi-étapes nécessitant un jugement	Compétence
Préférence ou principe stable	AGENTS.md
Fait ou procédure d'outil	Notes / connaissance du projet
Correction historique ponctuelle	Journal / enregistrement source

Procédure d'extraction

Exécutez d'abord l'extracteur déterministe. S'il n'est pas disponible, recherchez dans les transcriptions brutes les phrases de correction et inspectez les tours d'assistant environnants ; ne déduisez pas l'action incriminée uniquement de la correction.

Pour chaque candidat, conservez :

• correction exacte de l'utilisateur et horodatage
• projet et identifiant de session stable
• commande/texte de l'assistant immédiatement avant
• commande/texte corrigé immédiatement après
• nombre de récurrences sur des sessions logiques distinctes
• portée recommandée : projet ou global
• test positif (doit déclencher)
• test négatif (ne doit pas déclencher)

N'utilisez pas les résumés de session générés automatiquement comme preuve. Ils paraphrasent et dupliquent. Utilisez les messages de transcription bruts et les appels d'outils.

Transfert de génération de règle

Transmettez la plainte ainsi que la paire avant/après concrète au générateur de règles existant, qui fait déjà :

• génère un candidat de règle
• valide sa condition par rapport à l'historique de l'assistant
• propose une portée projet ou globale
• permet un amendement avant la sauvegarde

Ne dupliquez pas ce mécanisme dans l'extracteur ou cette compétence.

Vérification

Pour chaque règle acceptée, exécutez à la fois un cas négatif et un cas positif via le moteur de règles (avec OMP TTSR, par exemple) :

omp ttsr test --rule <chemin-absolu-de-la-règle> --source tool --tool <outil> '<mauvaise-entrée>' -v
omp ttsr test --rule <chemin-absolu-de-la-règle> --source tool --tool <outil> '<bonne-entrée>' -v

Le premier doit déclencher ; le second ne doit pas. Une règle qui bloque le chemin sûr est pire que pas de règle du tout.

Après une semaine, minez la même correction à nouveau. Zéro récurrence est la preuve que la règle a fonctionné. Une récurrence signifie que la condition a manqué la forme réelle ; amendez à partir des preuves, pas en élargissant aveuglément.

Exemple de référence : "puttys pls"

Les transcriptions ont montré la même correction deux jours consécutifs. Avant elle, les sessions exécutaient des commandes SSH/exec opaques d'une seule ligne contre des hôtes de banc d'essai distants sans terminal visible. Après elle, elles lançaient des sessions terminal visibles via des scripts wrapper nommés putty-*.

La règle de projet résultante (<projet>/.omp/rules/visible-putty-operations.md) attrape les chemins de commandes opaques, autorise les wrappers visibles, et est soutenue par les événements de correction historiques — trois tours de preuves, pas une supposition.