FFS — Atrito → Correção → Salvaguarda

O que FFS — Atrito → Correção → Salvaguarda faz?

Use o atrito da sessão para melhorar o harness. Na segunda vez que o usuário precisa repetir uma correção, é evidência de que o texto falhou e uma salvaguarda mecânica pode ser justificada.

Arquitetura

Não construa outro gerador de regras. Use as camadas existentes:

1. Extrair — um minerador determinístico sobre as transcrições de sessão do agente encontra correções repetidas de usuários e emparelha cada uma com a ação do assistente antes dela e a ação corrigida depois dela. (Para configurações baseadas em AgentsView, um extrator como avmine.py rules faz isso; qualquer armazenamento de transcrições JSONL pode ser minerado da mesma forma).
2. Classificar — decida se o fracasso é mecanicamente detectável.
3. Gerar e validar — passe um pacote de evidências para o caminho de geração de regras existente do harness (por exemplo, um comando do tipo /omfg), em vez de reimplementá-lo.
4. Aplicar — salve a saída aceita como uma regra de projeto (.omp/rules/<nome>.md) ou uma regra global (~/.omp/agent/rules/<nome>.md).
5. Verificar — teste exemplos positivos e negativos no motor de regras; depois, re-minere as transcrições para confirmar que a correção parou de recorrer.

Quando um atrito se torna uma regra

Crie uma regra apenas quando todos forem verdadeiros:

• O usuário corrigiu o mesmo comportamento pelo menos duas vezes, ou uma vez com uma consequência explícita de segurança.
• A ação ofensiva é mecanicamente reconhecível no texto do assistente ou nos argumentos da ferramenta.
• Uma substituição segura pode ser declarada sem adivinhar o contexto.
• Nenhuma regra existente já cobre o padrão.

Caso contrário, direcione para outro lugar:

Fracasso	Destino
Comando, caminho, flag ou frase de saída detectável	Regra
Fluxo de trabalho de múltiplas etapas exigindo julgamento	Skill
Preferência ou princípio estável	AGENTS.md
Fato ou procedimento de ferramenta	Notas / conhecimento do projeto
Correção histórica única	Diário / registro de origem

Procedimento de mineração

Execute o extrator determinístico primeiro. Se ele não estiver disponível, pesquise transcrições brutas por frases de correção e inspecione as respostas do assistente ao redor; não infira a ação ofensiva apenas a partir da correção.

Para cada candidato, retenha:

• correção exata do usuário e carimbo de data/hora
• projeto e ID de sessão estável
• comando/texto do assistente imediatamente antes
• comando/texto corrigido imediatamente depois
• contagem de recorrência em sessões lógicas distintas
• escopo recomendado: projeto ou global
• teste positivo (deve acionar)
• teste negativo (não deve acionar)

Não use resumos de sessão gerados automaticamente como evidência. Eles parafraseiam e duplicam. Use mensagens de transcrição bruta e chamadas de ferramentas.

Entrega de geração de regras

Entregue a reclamação mais o par concreto antes/depois ao gerador de regras existente, que já:

• gera um candidato a regra
• valida sua condição contra o histórico do assistente
• oferece escopo de projeto vs. global
• permite emenda antes de salvar

Não duplique essa maquinaria no extrator ou neste skill.

Verificação

Para cada regra aceita, execute ambos um caso negativo e um positivo através do motor de regras (com OMP's TTSR, por exemplo):

omp ttsr test --rule <caminho-absoluto-da-regra> --source tool --tool <ferramenta> '<entrada ruim>' -v
omp ttsr test --rule <caminho-absoluto-da-regra> --source tool --tool <ferramenta> '<entrada boa>' -v

O primeiro deve acionar; o segundo não deve. Uma regra que bloqueia o caminho seguro é pior do que nenhuma regra.

Após uma semana, minere a mesma correção novamente. Zero recorrências é evidência de que a regra funcionou. Uma recorrência significa que a condição perdeu a forma real; corrija com base em evidências, não ampliando cegamente.

Exemplo de referência: "puttys pls"

As transcrições mostraram a mesma correção em dois dias consecutivos. Antes dela, as sessões executavam comandos SSH/exec opacos de uma linha contra hosts remotos de bancada de teste sem terminal visível. Depois dela, lançavam sessões de terminal visíveis através de scripts wrapper nomeados putty-*.

A regra de projeto resultante (<projeto>/.omp/rules/visible-putty-operations.md) captura os caminhos de comando opacos, permite os wrappers visíveis e é respaldada pelos eventos de correção histórica — três rodadas de evidência, não um palpite.