komilovsg/f-mode

Modo F — modo de filtro primeiro

Princípio: dados brutos nunca entram no contexto; apenas o resultado entra. Mova a lógica para os dados (um pipeline shell, um script curto, um subagente) e traga de volta um resumo compacto. Cada token de um despejo de log que você lê é um token que você não pode gastar em raciocínio — e contexto longo e ruidoso piora o raciocínio, não apenas o torna mais caro.

1. Filtrar e agregar antes de ler

Em vez de	Faça
cat app.log	`grep -c ERROR app.log; grep -E 'ERROR
ler um JSON de 5 MB	jq '.items | length', jq -r '.items[] | [.id,.status] | @tsv' | sort | uniq -c
SELECT * FROM orders	SELECT status, count(*) FROM orders GROUP BY 1
git log	git log --oneline -20, git log --format=%s origin/main..HEAD
rolar um arquivo	grep -n 'def handle' file.py, depois leia com deslocamento/limite

2. Filtrar nunca deve esconder falhas

Uma visão truncada que parece verde é pior do que nenhuma visão.

• Mantenha o código de saída: set -o pipefail, ou cmd > out.txt 2>&1; echo "exit=$?"; tail -20 out.txt. Canalizar diretamente para tail perde o código de saída do comando.
• Grepe marcadores de falha além de tail: grep -cE 'FAIL|ERROR|Traceback|panic' out.txt.
• Imprima contagens com denominadores: passou 41/42, nunca apenas "OK".

pytest -q --tb=short > /tmp/t.out 2>&1; echo "exit=$?"
grep -cE 'FAILED|ERROR' /tmp/t.out; tail -15 /tmp/t.out

3. Muitas verificações semelhantes → um script, uma tabela

Dez endpoints, vinte arquivos, trinta linhas para validar: escreva um script que itere e imprima uma tabela compacta (nome | status | detalhe) mais totais. Não dez chamadas de ferramenta com dez saídas completas.

for u in / /api/health /api/items; do
  printf "%-14s %s\n" "$u" "$(curl -s -o /dev/null -w '%{http_code}' "localhost:8000$u")"
done

4. Verifique o resumo quanto ao significado, não apenas à forma

Uma saída de aparência válida ainda pode estar errada. Compare com um valor esperado ou um total de sanidade: as contagens somam ao tamanho da entrada, uma linha conhecida está presente, o número de arquivos corresponde a ls | wc -l. Se um resumo não puder ser verificado, diga isso.

5. Testes

Modo silencioso, tracebacks curtos, final da seção de falhas:

• pytest -q --tb=short
• vitest run --reporter=dot, jest --silent
• go test ./... 2>&1 | grep -E '^(FAIL|ok|---)'
• cargo test -q

6. Verificações no navegador

Avalie um script que retorne JSON compacto ({title, errors: n, buttons: n, overflowX: bool}) em vez de snapshots completos do DOM. Tire um snapshot apenas quando a própria estrutura do DOM for a questão. Capturas de tela para verificações visuais, não para ler texto.

7. Investigação ampla → subagente

Buscas grandes, análise forense de logs, despejos de banco de dados: delegue a um subagente que retorne conclusões com referências arquivo:linha. Seu resultado ainda é uma afirmação — verifique os pontos-chave antes de agir com base neles.

8. Segredos e dados pessoais

Nunca imprima segredos ou PII real em resumos ou diagnósticos. Masque (postgres://***) ou conte-os (emails encontrados: 12). Masque strings de conexão e chaves também dentro de mensagens de exceção capturadas.

9. Leitura de arquivos

• grep -n primeiro, depois leia apenas o intervalo relevante com deslocamento/limite.
• Código-fonte que você está prestes a editar é lido por completo — leituras parciais causam edições quebradas.
• Não releia um arquivo imediatamente após editá-lo para "verificar"; a ferramenta de edição já erra em caso de falha.

10. Regra de parada

A mesma correção falhou duas vezes → pare. Encontre a causa raiz a partir da linha exata do erro, ou pergunte. Sem terceira tentativa cega.

11. Higiene do contexto

• Limpe o contexto entre tarefas não relacionadas; compacte sessões longas.
• Desabilite plugins, skills e servidores MCP que você não usa neste projeto: cada um custa tokens de prompt em toda requisição.
• Julgue a economia por números reais de uso (ex.: /cost), não por porcentagens divulgadas.