🧭 Projeto 6: a mentalidade
Tudo isso é iterativo. O módulo de fechamento não instala nada: ele te entrega o hábito que faz os cinco projetos anteriores sobreviverem à próxima troca de modelo — acompanhar o que cada provedor exige, registrar cada falha em uma linha, e parar de administrar prompts.
🎯 O projeto em uma tela
Transformar o que você montou em hábito: uma rotina de manutenção que absorve mudança de modelo, de provedor e de harness sem refazer tudo.
Um FALHAS.md na raiz do projeto com pelo menos uma linha real, um handoff de encerramento escrito, e o checklist dos 7 itens para amanhã.
Você consegue dizer, olhando o FALHAS.md, quantas falhas foram de prompt e quantas de infra — e qual foi a menor correção de cada uma.
♻️ Cada mudança melhora um modelo e quebra outro
O cenário continua mudando, e essa não é uma ressalva educada no fim do texto: é a condição permanente de trabalho. Cada alteração que você faz numa skill, num AGENTS.md, num hook, pode melhorar essa skill para um modelo e quebrar a mesma skill para outro. Você aperta a instrução para o modelo que estava divagando e, na mesma linha, tira o espaço de que o outro precisava.
Por isso o certo não é congelar o workspace depois de montado — é acompanhar constantemente o que cada modelo realmente precisa. O workspace agnóstico não elimina a manutenção; ele torna a manutenção pequena e localizada, em vez de uma migração inteira a cada troca.
O ciclo gira para sempre; o que não gira é o núcleo. Quando uma mudança quebra um executor, o conserto acontece na borda daquele executor — nunca reescrevendo o contexto que os três compartilham.
✓ Manutenção pequena
- ✓A mudança entra no núcleo; o adaptador de cada executor é regerado.
- ✓O readback roda nos runtimes que você usa, não só no favorito.
- ✓Quebrou num só? Conserta a borda daquele, e o resto não é tocado.
- ✓O que quebrou vira uma linha no changelog de falhas.
✗ Manutenção por reescrita
- ✗"Quebrou no Codex" vira "vou refazer minhas instruções do zero".
- ✗Duas versões da skill, uma por modelo, divergindo a cada semana.
- ✗Testar só no modelo que você mais gosta e descobrir o resto em produção.
- ✗Nenhum registro: seis meses depois você repete o mesmo erro.
Conceitos-chave
O cenário muda; o workspace acompanha, não congela.
A mesma mudança tem sinais opostos em modelos diferentes.
Adaptador do executor, nunca o núcleo compartilhado.
Readback em cada runtime que você realmente usa.
🔌 Acompanhar o que cada provedor exige
"Model-agnostic" nunca quis dizer "provider-agnostic sem esforço". A camada de conhecimento é portátil; as bordas continuam sendo do provedor, e elas mudam sem avisar você. As diferenças que o curso inteiro mostrou não são bugs: são o preço de usar mais de um executor.
📋 O que o kit já descobriu sobre as bordas
- •O Codex CLI não tem import: não existe o
@arquivo.mddo Claude. O que precisa ser lido tem que ser dito em texto — "leiacontext/overview.mdantes de responder" — ou o conteúdo entra inline. - •O Codex não lê um
AGENTS.mdglobal do jeito que o Claude lê oCLAUDE.mdglobal: o que vale é o do projeto (e o de~/.codexquando configurado). Não assuma herança; prove com readback. - •Hooks são diferentes em cada harness: nome, evento, formato e momento de disparo não coincidem. Um hook é sempre código de borda — trate como adaptador, não como parte do núcleo.
- •Sandbox e permissão variam por máquina: neste host, forçar
-s read-onlynocodex execquebrou por AppArmor. A correção foi respeitar osandbox_modedoconfig.toml, não reescrever o script. - •O que é comum a quase todos: Markdown.
agents.mdé entendido por vários; oclaude.mdé a exceção específica do Claude. Praticamente todo o resto é portátil.
💡 A rotina de drift, semanal
Uma vez por semana, rode o mesmo readback nos runtimes que você usa e compare com a semana anterior. Não é paranoia: é como você descobre que uma atualização mudou o carregamento de instruções antes de um cliente descobrir. Quinze minutos por semana contra uma migração de emergência.
Conceitos-chave
Import, arquivo global, hooks, sandbox: tudo específico.
Mande ler em texto; não conte com @arquivo.
A diferença que aparece sozinha entre duas semanas.
O denominador comum que sobrevive a todos eles.
🔮 Modelos fechados podem não precisar de skills; locais sim
Uma possibilidade real para o futuro: modelos fechados podem, em algum momento, não precisar mais de skills. Se forem treinados com base nas conversas e absorverem essas capacidades, boa parte do que hoje é skill vira comportamento padrão. Enquanto isso, modelos locais talvez continuem dependendo delas — e dependem hoje.
A conclusão prática não é escolher um lado. É a frase que fecha o texto-fonte: construa sua estrutura de forma independente de modelo, mas acompanhe o que cada provedor exige ao longo do tempo. Skill que virou desnecessária no modelo fechado continua sendo a muleta que faz o modelo local funcionar — e é o que te dá a opção de sair.
✓ O que sobrevive à troca
- ✓Contexto, conhecimento e decisões em Markdown.
- ✓Processos, handoffs e critérios de validação.
- ✓Skills canônicas, com adaptadores gerados por executor.
- ✓Memória curada com fonte e data.
✗ O que você perde na troca
- ✗Prompts afinados para um modelo específico.
- ✗Memória nativa do runtime, que não sai de lá.
- ✗Hooks e configurações de harness escritos à mão.
- ✗Hábitos de interface — e nada disso era o seu trabalho.
💡 Sobre construir um "super-harness"
Para Claude e Codex não vale a pena: os harnesses deles já são bem otimizados, e os fornecedores fazem o trabalho de adaptá-los a cada modelo novo. Onde vale construir o seu é onde ninguém faz por você — modelos locais e pipelines próprios. Aí o harness é seu produto, não uma reimplementação do que já existe pronto.
Conceitos-chave
Capacidade que o modelo passa a ter sem precisar de arquivo.
Modelos locais seguem precisando das skills explícitas.
Construa independente, mas siga o que cada provedor exige.
O valor real de ser agnóstico: poder trocar sem refazer.
🗂️ Você deixa de administrar prompts
Esta é a mudança de mentalidade que dá nome ao módulo, e ela cabe numa frase: você deixa de administrar prompts e passa a administrar contexto, estado, ferramentas, processos e critérios de validação.
Administrar prompt é otimizar a frase. Rende ganho rápido e evapora na próxima versão do modelo. Administrar contexto é responder quem é dono de cada informação, qual é o estado atual da tarefa, quais ferramentas o agente pode usar, qual é o processo e como se prova que ficou pronto — e isso continua valendo quando o modelo muda.
À esquerda, o trabalho que some com a versão do modelo. À direita, os cinco blocos que você administra e que atravessam qualquer troca — o último, validação, é o que impede os outros quatro de virarem ficção.
Como isso muda seu dia: quando algo dá errado, a primeira pergunta deixa de ser "como eu reescrevo esse prompt?" e passa a ser "qual dos cinco falhou?". Faltou contexto? O estado estava velho? A ferramenta não existia na sessão? O processo pulou o handoff? Ou simplesmente ninguém validou? Quatro dessas cinco respostas são consertos de arquivo, não de frase.
Conceitos-chave
Fatos com dono, fonte e data.
tasks/current.md: o que se faz agora e o critério de pronto.
Handoff, prime, drift: o ciclo que você repete.
Readback e canário; "o arquivo existe" não é prova.
📓 O changelog de falhas: uma linha por falha
A ferramenta de manutenção mais barata do curso é um arquivo FALHAS.md na raiz do projeto, com uma linha por falha: data, o que quebrou, a menor correção possível, e se era problema de prompt ou de infra. Sem narrativa. Mais recente no topo.
Depois de umas dez linhas o padrão fica óbvio — e você para de reconstruir coisas que só precisavam de uma proteção. Essa é a tese do arquivo inteiro: se a resposta foi reescrever ou reconstruir, provavelmente faltava só uma proteção — um teto, um retry, um guard, uma validação. Registrar isso na linha é o que impede a próxima reconstrução.
Code box 1 — o FALHAS.md real do kit
Objetivo: ver o formato em uso, com as duas falhas verdadeiras registradas durante a construção deste material. Copie o cabeçalho para o seu projeto.
# Falhas (mais recente no topo)
| data | o que quebrou | menor correção | prompt \| infra |
|---|---|---|---|
| 2026-09-13 | readback-test.sh forçava `-s read-only` no codex exec; bwrap falha por AppArmor neste host | remover o flag, respeitar sandbox_mode do config.toml | prompt \| infra |
| 2026-09-13 | resumo do audit.sh contava linhas da seção 3 (73+17+4=94 ≠ 89) | restringir grep à seção 2.1 | prompt |
Como verificar: wc -l FALHAS.md cresce de uma linha por falha corrigida, e grep -c 'infra' FALHAS.md te diz quantas foram de ambiente. Se uma linha virou parágrafo, ela está no arquivo errado — o detalhe longo vira arquivo separado e é linkado.
✓ Linha útil
- ✓Escrita ao terminar de corrigir, antes da próxima tarefa.
- ✓A menor correção possível, não a que você fez com raiva.
- ✓Marcada como prompt, infra, ou os dois quando for os dois.
- ✓Uma linha. O detalhe longo vira arquivo à parte, linkado.
✗ Linha inútil
- ✗"Deu erro no script, arrumei." — sem o quê nem como.
- ✗Escrita no fim da semana, quando você já esqueceu a causa.
- ✗"Reescrevi o módulo" como correção — isso é o sintoma, não o conserto.
- ✗Três parágrafos de narrativa que ninguém relê.
💡 Prompt ou infra?
Prompt = você pediu de um jeito que induziu o erro, ou o modelo entendeu errado. Infra = máquina, memória, rede, serviço fora do ar, chave errada, processo sem supervisão. Quando for os dois, marque os dois — como a primeira linha do kit, que era um script mal escrito e um AppArmor do host. Falha que atravessa vários projetos vai no FALHAS.md do hub, não no do projeto onde ela apareceu por acaso.
Conceitos-chave
Data, o que quebrou, menor correção, classificação.
O ponto do exercício: o mínimo que resolveu.
Teto, retry, guard, validação — quase sempre era isso.
O arquivo começa a te dizer onde você sempre tropeça.
🏁 Em uma frase — e o que fazer amanhã
Se você fechar esta página e guardar uma frase só, que seja esta:
"Não migre seu cérebro de Claude para Codex; separe o cérebro do modelo."
O que precisa sobreviver à troca não é o Claude, nem o Codex, nem o Gemini. É a sua camada de contexto, conhecimento, Markdown, processos, handoffs, memória e ferramentas.
O que fazer amanhã — 7 itens
1. Rodar o doctor
Veja o que está instalado, em que versão, e o que está quebrado hoje. Quinze minutos antes de qualquer decisão.
2. Rodar o audit (MODE: audit)
Nada é escrito. Você sai com a árvore proposta, as regras de propriedade e os checks de aceite — e com a lista do que não foi possível inspecionar.
3. Escrever o AGENTS.md global
Suas regras genéricas, sem nome de cliente, sem segredo. O CLAUDE.md global aponta pra ele.
4. Escolher UM piloto
Um projeto real, com uma tarefa representativa. Não cinco. O template só é template depois que um passou.
5. Fazer o handoff hoje mesmo
No fim da primeira sessão, antes de fechar. O ciclo começa a valer quando a segunda sessão abre pelo prime.
6. Marcar o drift semanal
Um lembrete recorrente: mesmo readback, mesmos runtimes, comparado com a semana anterior.
7. Criar o FALHAS.md
Vazio, com o cabeçalho pronto. A primeira linha aparece mais cedo do que você imagina — e escrevê-la ali é o que evita a primeira reconstrução.
Code box 2 — handoff de encerramento (exemplo)
Objetivo: fechar o curso do jeito que você vai fechar toda sessão daqui pra frente. Salve como handoffs/latest.md no seu projeto piloto e adapte as linhas.
# Handoff — 2026-09-14 — fim do curso Claude → Codex
## Projeto e escopo
<meu-projeto-piloto>: workspace agnóstico. Escopo: aplicar os 6 projetos da trilha 3.
## Objetivo atual
Rodar uma semana inteira com handoff + prime antes de migrar o segundo projeto.
## Estado aceito
- AGENTS.md global escrito; CLAUDE.md global aponta para ele.
- context/{overview,current-state,sources}.md e tasks/current.md preenchidos.
- 3 fatos promovidos da memória bruta, com fonte e duas datas.
- FALHAS.md criado (1 linha: sandbox do codex exec — infra).
## Checks rodados e resultado
- readback no Claude: passou (citou AGENTS.md e tasks/current.md).
- readback no Codex: passou (citou AGENTS.md; sem import, leitura explícita).
- canário sintético entre clientes: NÃO RODADO (ainda sem workspace de cliente).
## Perguntas abertas
- Vale montar o terceiro executor local agora ou depois do segundo projeto?
- Quais skills viram canônicas primeiro?
## Próxima ação exata
`scripts/drift.sh` na segunda-feira e comparar com o relatório desta semana.
Como verificar: abra uma sessão nova, mande ler só este arquivo, e pergunte "qual é a próxima ação exata?". Se a resposta for a linha final, o handoff está bom. Se a sessão precisar de você para entender, falta contexto no arquivo — não no modelo.
Último lembrete: nada aqui exige que você abandone o Claude, ou o Codex, ou qualquer runtime. Exige só que a sua parte — contexto, estado, ferramentas, processos e validação — esteja em arquivos que você consegue abrir, copiar e levar embora. Os modelos podem mudar. A sua estrutura de trabalho deve continuar funcionando.
Conceitos-chave
A frase que resume o curso inteiro.
O template nasce de um projeto que funcionou.
O ciclo só existe quando a segunda sessão abre pelo prime.
Drift semanal + FALHAS.md: manutenção barata e contínua.
Auto-checagem (opcional): um script seu falhou porque o modelo devolveu uma resposta enorme e estourou o tempo. Você reescreveu o script inteiro. O que vai na linha do FALHAS.md?
🎯 Resumo do projeto
Fim da Trilha 3:
Você percorreu os seis projetos. Amanhã: doctor, audit, AGENTS.md global, um piloto, handoff hoje, drift semanal e o FALHAS.md criado.