⚙️ Disposição × garantia dura
Um guia de comportamento — por mais bem escrito — é intenção. O modelo pode esquecer, despriorizar, ou não disparar a regra no turno certo. Disposição é best-effort por natureza. Este módulo é sobre a outra metade: as alavancas mecânicas que o harness força de fato — o effortLevel e os hooks. Escreva a disposição e arme as travas. Sozinho, nenhum dos dois basta.
Conteúdo detalhado
Por que um guia de comportamento é só "melhor esforço"
A reflexão mais sóbria de todo o material-fonte cabe numa frase: disposição é intenção, não garantia. Você pode escrever o guia de comportamento mais lúcido do mundo, apontar a sessão para ele, e mesmo assim o modelo pode esquecer, despriorizar, ou simplesmente não disparar a regra no turno em que ela importava. Não porque o guia é ruim — porque um guia, por natureza, é best-effort. Ele depende de o modelo lembrar.
⚙️ A ideia em uma frase
Um guia de comportamento é a camada de disposição: ela molda o que o modelo tende a fazer, e a prosa fecha parte real da lacuna. Mas "tende a" não é "vai". Quem confia só no prompt confia no melhor-esforço de um sistema que tem dias ruins.
A medida disso está nos números: mesmo o modelo-fonte, com a disciplina mais alta observada, roda o teste real depois de editar em apenas 23% dos turnos. A intenção estava lá. A execução vazou. É exatamente esse vazamento que uma trava dura fecha — e este módulo é sobre instalá-las.
O que é
A camada de disposição é tudo que vive em prosa: o Fable_Mindset, as regras do seu CLAUDE.md, os "sempre faça X / nunca faça Y". Ela é probabilística: aumenta a chance de o comportamento aparecer, mas nunca a leva a 100%. A garantia dura é o oposto — é o que o harness executa independentemente de o modelo cooperar.
Por que aprender
Porque a tentação do operador iniciante é resolver tudo escrevendo mais regra. Quando o agente "às vezes não roda os testes", a reação instintiva é adicionar mais um "SEMPRE rode os testes!!!" ao prompt — em caps, com exclamações. Isso eleva a probabilidade um pouco e a garantia nada. O operador avançado reconhece quando um problema é de disposição (resolve com prosa) e quando é de mecânica (só uma trava resolve).
✓ O que a disposição faz bem
- ✓Molda o tom, o estilo e a postura padrão
- ✓Eleva a probabilidade de bons hábitos aparecerem
- ✓Cobre os casos que nenhuma trava previu
- ✓Dá o porquê — a trava só dá o quê
✗ O que a disposição NÃO garante
- ✗Que a regra dispare no turno em que importava
- ✗Que o modelo não a despriorize sob pressão
- ✗Que o teste rode toda vez após uma edição
- ✗Repetibilidade — hoje funciona, amanhã pode falhar
A pergunta que classifica o problema
Antes de adicionar mais uma linha ao prompt, pergunte: "isto é uma questão de o modelo querer, ou de ele poder esquecer?" Se for de querer — tom, postura, julgamento — a prosa é o lugar certo. Se for de esquecer — um passo que precisa acontecer toda vez — nenhuma prosa basta; você precisa de uma trava. Escrever regra para um problema mecânico é tratar uma fratura com conselho.
Densidade de raciocínio = effortLevel, não o token budget antigo
A primeira trava dura é a densidade de raciocínio. O Fable_Mindset insiste que raciocinar não é overhead, é o trabalho — mas a prosa só pede; ela não aloca mais raciocínio. Quem aloca é o harness, e a alavanca correta no Opus 4.8 é o effortLevel. Aqui mora a armadilha que pega quase todo operador vindo de modelos anteriores.
🧠 A alavanca certa — e a que não faz nada
- ✓ Use o effortLevel. No Opus 4.8 a densidade de raciocínio é controlada por effortLevel em xhigh ou max, mantendo alwaysThinkingEnabled ligado. É o harness decidindo quanto o modelo pensa — não um pedido em prosa.
- ✗ Esqueça o MAX_THINKING_TOKENS. A variável de ambiente antiga não faz absolutamente nada em modelos de thinking adaptativo. O modelo decide sozinho quando e quanto pensar; um teto fixo de tokens é ignorado. Confiar nela é configurar uma alavanca desconectada.
# eleva a densidade de raciocínio só nesta sessão
/effort max
Use /effort max quando o trabalho da sessão genuinamente pede mais cadência de raciocínio. Para fixar permanentemente, prefira effortLevel: "max" no settings. Lição: a prosa do guia fecha parte da lacuna de raciocínio; o effortLevel fecha o resto.
✗ Configurar a alavanca morta
- ✗Setar MAX_THINKING_TOKENS e achar que algo mudou
- ✗Esperar que um teto fixo controle thinking adaptativo
- ✗Pedir "pense mais" em prosa e parar por aí
- ✗Debugar raciocínio raso mexendo na variável errada
✓ Puxar a alavanca viva
- ✓effortLevel: "xhigh" ou "max" no settings
- ✓alwaysThinkingEnabled: true ligado junto
- ✓/effort max para a sessão pontual
- ✓Effort + as regras de raciocínio do guia, juntos
Quando nem o effort basta
A densidade de raciocínio do modelo-fonte é em parte intrínseca — não se reproduz 100% só por instrução nem só por effort. Para o trabalho que genuinamente exige aquela cadência, a alavanca final é trocar de modelo direto com /model fable. Effort eleva o que o modelo atual pode dar; ele não inventa raciocínio que não está nos pesos.
Hábito determinístico = o hook PostToolUse
Esta é a trava mais poderosa do arsenal, porque transforma um hábito probabilístico num evento determinístico. "Após uma edição, rode os testes" é a regra que o modelo-fonte mais falha — 23% dos turnos. A solução não é gritar a regra mais alto; é tirá-la das mãos do modelo. Um hook PostToolUse casado em Edit|Write|MultiEdit roda o teste quer o agente lembre ou não.
{ "hooksEnabled": true, "hooks": { "PostToolUse": [ { "matcher": "Edit|Write|MultiEdit", "hooks": [ { "type": "command", "command": "npm test" } ] } ] } }
O matcher casa qualquer ferramenta de edição; o command é o teste real do projeto. Sem "hooksEnabled": true nada dispara — essa flag é o interruptor geral. Lição: o que precisa acontecer toda vez não pode depender da memória do agente; precisa de um gatilho do harness.
✗ Confiar na intenção
- ✗"Lembre de rodar os testes após editar" no prompt
- ✗Dispara quando o modelo lembra — 23% dos turnos
- ✗Sob carga ou conversa longa, a regra evapora
- ✗Você descobre o erro só depois, sem o teste ter rodado
✓ Armar o hook
- ✓O harness roda o teste após cada edição, sempre
- ✓Dispara quer o agente lembre ou não — 100%
- ✓Imune à carga, ao contexto longo, ao mau dia do modelo
- ✓O resultado do teste volta antes do agente seguir
Nem todo hábito vira hook — e está tudo bem
O hook é perfeito para o que se reduz a "após o evento X, rode o comando Y". Mas regras que pedem julgamento — como "prefira caminhos absolutos a cd" — não se reescrevem de forma confiável por hook, porque exigem contexto que um casamento de padrão não tem. Essas continuam como regra de disposição. Use a trava onde ela cabe; deixe a prosa cobrir o resto.
Onde a regra mora: CLAUDE.md vs auto-memory
Uma regra de disposição certa, no lugar errado, deixa de garantir. O effortLevel e os hooks são as travas duras; o guia de comportamento é a camada mole — mas onde você guarda essa camada decide se ela carrega de forma confiável ou se desaparece em turnos inteiros. E o detalhe que engana é que auto-memory parece o lugar óbvio, e não é.
CLAUDE.md
Regras de disposição vivem bem aqui. O CLAUDE.md é injetado toda sessão, de forma determinística — a regra está sempre no contexto, todo turno, sem depender de o modelo "lembrar de buscar".
É o lar correto do guia de comportamento e das regras de postura.
auto-memory
Não é o lugar de uma regra de comportamento. O recall é relevance-gated: a memória só sobe se o turno atual a julgar relevante. Uma regra de disposição pode não disparar no turno em que importava.
Ótima para fatos pontuais; arriscada para regras que precisam valer sempre.
📌 Determinístico bate relevante para regras de comportamento
A diferença é a forma de carregamento. CLAUDE.md é carregamento garantido: presente em todo turno por construção. Auto-memory é carregamento condicional: presente se o gate de relevância deixar passar. Para um fato ("o deploy é na Vercel"), condicional basta — ele só importa quando o assunto surge. Para uma regra de comportamento ("sempre verifique o que mudou"), condicional é uma falha esperando acontecer: ela precisa valer justo nos turnos em que o gate pode não a julgar relevante.
Por isso a heurística é direta: regra que precisa valer sempre vai no CLAUDE.md; fato que só importa às vezes pode ir para a memória.
O teste do "turno ruim"
Para decidir onde uma regra mora, imagine o pior turno: o contexto está cheio, o assunto é outro, o modelo está sob carga. A regra ainda precisa estar ali? Se sim, ela exige carregamento determinístico — CLAUDE.md, não auto-memory. A memória brilha justamente quando o turno traz o assunto à tona; ela falha quando a regra precisava estar lá apesar do turno.
Output styles são para tom e papel — não para disciplina agêntica
Existe um terceiro mecanismo que tenta a todo operador como veículo de comportamento, e é o veículo errado: os output styles. Eles existem, são úteis — mas para o que foram feitos: tom e papel. Carregar disciplina agêntica num output style é usar a ferramenta certa para o problema errado, e o comportamento que você queria garantir continua best-effort, só que num lugar mais escondido.
🎭 Cada veículo tem o seu cargo
Há três veículos diferentes, e confundi-los é a fonte mais comum de configuração frágil. Cada um carrega um tipo de instrução — e só um deles é uma garantia dura:
✓ Output style — para o que serve
- ✓"Responda como um revisor sênior, conciso"
- ✓O papel que o modelo encarna na resposta
- ✓O registro: formal, didático, telegráfico
- ✓A persona e a voz da saída
✗ Output style — o que NÃO carrega
- ✗"Sempre rode os testes após editar" → vai no hook
- ✗"Raciocine antes de agir" → effort + CLAUDE.md
- ✗"Verifique antes de declarar pronto" → disposição
- ✗Qualquer disciplina de processo, não de voz
A pergunta que separa tom de disciplina
Antes de colocar algo num output style, pergunte: "isto descreve como a resposta soa, ou o que o agente faz?" Se for como soa — voz, papel, registro — o output style é o veículo certo. Se for o que faz — um passo de processo, um hábito de verificação — está no lugar errado; vá para a disposição (CLAUDE.md) ou, melhor, para a trava (hook/effort). Estilo é roupa; disciplina é músculo.
Juntar os dois: disposição (mole) + travas duras = garantia
Aqui tudo converge. O guia de comportamento é a camada de disposição; o effortLevel e os hooks são as garantias duras. A tese do material-fonte é uma só: use os dois. Sozinho, nenhum basta. A prosa fecha parte da lacuna; a trava fecha o resto. Escreva a disposição e arme as travas — essa conjunção é a montagem operacional inteira.
Escreva a disposição no CLAUDE.md
Aponte a sessão para o guia de comportamento e ponha as regras de postura no CLAUDE.md — carrega toda sessão, determinístico. É a camada mole, e é onde ela pertence. Não em auto-memory, não em output style.
Arme a densidade de raciocínio
Configure effortLevel: "xhigh" ou "max" com alwaysThinkingEnabled ligado (ou /effort max na sessão). Ignore MAX_THINKING_TOKENS — alavanca morta em thinking adaptativo.
Trave o hábito que precisa ser determinístico
Instale o hook PostToolUse em Edit|Write|MultiEdit que roda o teste real, com hooksEnabled: true. O passo que precisa ocorrer toda vez sai das mãos do modelo e vira evento do harness.
Deixe a prosa cobrir o que a trava não alcança
O que pede julgamento — caminhos absolutos vs cd, quando consolidar, como narrar — continua na disposição. A trava pega o repetível e determinístico; a prosa cobre o contextual. Juntas, fecham a lacuna inteira.
✗ Disposição sozinha
- ✗Best-effort: funciona no melhor dia, falha no pior
- ✗O teste roda quando o modelo lembra (23%)
- ✗Não-repetível: o mesmo prompt, resultados diferentes
- ✗Você confia no melhor-esforço de um sistema com dias ruins
✓ Disposição + travas duras
- ✓A prosa eleva a probabilidade; a trava garante o piso
- ✓O teste roda toda vez, lembre o agente ou não
- ✓Repetível: o comportamento garantido não depende do dia
- ✓Disposição e mecânica — a montagem completa
⚙️ A ponte que mais importa
Trate o guia como a camada de mindset: aponte as sessões para ele deliberadamente. E fie o hook de teste e o effortLevel separadamente, como as garantias duras. A disposição diz ao modelo o que querer; a trava remove a dependência de ele querer. Um sem o outro deixa um buraco — a prosa sem trava vaza nos turnos ruins, a trava sem prosa não sabe lidar com o caso que ninguém previu.
É a mesma lógica que atravessa a trilha inteira: você herda o método sem herdar a mente. A disposição é o método em prosa; a trava é o método em mecânica. Escreva a disposição e arme as travas — e o comportamento deixa de ser uma esperança para virar uma propriedade do sistema.
A regra de bolso do operador
Para cada comportamento que você quer, pergunte duas coisas em ordem: "isto precisa acontecer sempre?" e "isto se reduz a um gatilho determinístico?". Sim e sim → vira hook ou config. Sim, mas pede julgamento → vira regra no CLAUDE.md. Só às vezes → pode ser fato na memória. Nunca confie a um veículo mole o que precisa ser duro.
📝 Resumo do Módulo
- ✓Um guia de comportamento é best-effort: o modelo pode esquecer, despriorizar ou não disparar a regra no turno certo
- ✓Densidade de raciocínio = effortLevel (xhigh/max, ou /effort max) — não o MAX_THINKING_TOKENS, que não faz nada em thinking adaptativo
- ✓Hábito determinístico = hook PostToolUse em Edit|Write|MultiEdit que roda o teste, lembre o agente ou não (hooksEnabled: true)
- ✓A regra mora no CLAUDE.md (carrega toda sessão); auto-memory é relevance-gated e pode não disparar
- ✓Output styles são para tom e papel — não para disciplina agêntica
- ✓Junte os dois: disposição (mole) + travas duras = comportamento garantido. Sozinho, nenhum basta
➡️ Próximo Módulo
3.7 — 🏁 Projeto final. Você já tem a análise, a consolidação e as travas. Agora é hora de juntar tudo num projeto que aplica o método ponta a ponta: ler a evolução, destilar o guia, e armar as garantias duras num sistema que se sustenta sozinho.