FFS — Fricción → Arreglo → Salvaguarda

¿Qué hace FFS — Fricción → Arreglo → Salvaguarda?

Usa la fricción de la sesión para mejorar el arnés. La segunda vez que el usuario debe repetir una corrección es evidencia de que la prosa falló y puede justificarse una salvaguarda mecánica.

Arquitectura

No construyas otro generador de reglas. Usa las capas existentes:

1. Extraer — un minero determinista sobre las transcripciones de sesión del agente encuentra correcciones repetidas del usuario y empareja cada una con la acción del asistente anterior y la acción corregida posterior. (Para configuraciones basadas en AgentsView, un extractor como avmine.py rules hace esto; cualquier almacén de transcripciones JSONL puede minarse de la misma manera).
2. Clasificar — decide si el fallo es mecánicamente detectable.
3. Generar y validar — pasa un paquete de evidencia a la ruta de generación de reglas existente del arnés (por ejemplo, un comando estilo /omfg), en lugar de reimplementarlo.
4. Aplicar — guarda la salida aceptada como una regla de proyecto (.omp/rules/<nombre>.md) o una regla global (~/.omp/agent/rules/<nombre>.md).
5. Verificar — prueba ejemplos positivos y negativos contra el motor de reglas; luego vuelve a minar las transcripciones para confirmar que la corrección dejó de repetirse.

Cuándo una fricción se convierte en regla

Crea una regla solo cuando todo lo siguiente sea verdad:

• El usuario corrigió el mismo comportamiento al menos dos veces, o una vez con una consecuencia explícita de seguridad.
• La acción ofensiva es mecánicamente reconocible en el texto del asistente o en los argumentos de la herramienta.
• Se puede indicar un reemplazo seguro sin adivinar el contexto.
• Ninguna regla existente cubre ya el patrón.

De lo contrario, enrútalo a otro lugar:

Fallo	Destino
Comando, ruta, indicador o frase de salida detectable	Regla
Flujo de trabajo de varios pasos que requiere criterio	Habilidad
Preferencia o principio estable	AGENTS.md
Hecho o procedimiento de herramienta	Notas / conocimiento del proyecto
Corrección histórica única	Diario / registro fuente

Procedimiento de minería

Ejecuta primero el extractor determinista. Si no está disponible, busca en las transcripciones sin procesar frases de corrección e inspecciona los turnos del asistente circundantes; no infieras la acción ofensiva solo a partir de la corrección.

Para cada candidato conserva:

• corrección exacta del usuario y marca de tiempo
• proyecto e id de sesión estable
• comando/texto del asistente inmediatamente anterior
• comando/texto corregido inmediatamente posterior
• conteo de recurrencia en sesiones lógicas distintas
• ámbito recomendado: proyecto o global
• prueba positiva (debe activarse)
• prueba negativa (no debe activarse)

No uses resúmenes de sesión generados automáticamente como evidencia. Parafrasean y duplican. Usa mensajes de transcripción sin procesar y llamadas a herramientas.

Transferencia de generación de reglas

Pasa la queja más el par concreto antes/después al generador de reglas existente, que ya:

• genera un candidato a regla
• valida su condición contra el historial del asistente
• ofrece ámbito de proyecto vs global
• permite modificaciones antes de guardar

No dupliques esa maquinaria en el extractor ni en esta habilidad.

Verificación

Para cada regla aceptada, ejecuta tanto un caso negativo como uno positivo a través del motor de reglas (con el TTSR de OMP, por ejemplo):

omp ttsr test --rule <ruta-absoluta-de-regla> --source tool --tool <herramienta> '<entrada-mala>' -v
omp ttsr test --rule <ruta-absoluta-de-regla> --source tool --tool <herramienta> '<entrada-buena>' -v

La primera debe activarse; la segunda no. Una regla que bloquea la ruta segura es peor que ninguna regla.

Después de una semana, mina la misma corrección de nuevo. Cero recurrencias es evidencia de que la regla funcionó. Una recurrencia significa que la condición no captó la forma real; corrige basándote en la evidencia, no ampliando a ciegas.

Ejemplo de referencia: "puttys pls"

Las transcripciones mostraron la misma corrección en dos días consecutivos. Antes de ella, las sesiones ejecutaban comandos SSH/exec opacos de una línea contra hosts remotos de banco de pruebas sin terminal visible. Después, lanzaban sesiones de terminal visibles a través de scripts contenedores llamados putty-*.

La regla de proyecto resultante (<proyecto>/.omp/rules/visible-putty-operations.md) captura las rutas de comando opacas, permite los contenedores visibles y está respaldada por los eventos de corrección histórica — tres rondas de evidencia, no una suposición.