MÓDULO 2.1 / 4 DE 9

Claude → Codex: separe o cérebro do modelo

Explicar por que o lock-in mora no runtime e como o método Auditar → Adaptar → Provar → Handoff leva o conhecimento do projeto para um núcleo portátil.

Página da área: eventos.inema.pro/claude-codex/ · no menu: “migre ou fique agnóstico”

0% 0 de 0
01 / CLAUDE-CODEXA tese: separe o cérebro do modelo02 / CLAUDE-CODEXO lock-in está no runtime03 / CLAUDE-CODEXO método: auditar antes de mudar04 / CLAUDE-CODEXO núcleo portátil, arquivo por arquivo05 / CLAUDE-CODEXMigrar ou ficar agnóstico06 / CLAUDE-CODEXCurso, kit e o primeiro passo
Os 6 tópicos deste módulo. No fim, você preenche a ficha da área.
6 tópicos
~20 min leitura e prática
1 ficha da área
1 prompt pronto

1A tese: separe o cérebro do modelo

O que é

A área Claude → Codex parte de uma frase: "Não migre o seu cérebro. Separe o cérebro do modelo." O "cérebro" é tudo o que você acumulou num projeto: contexto, regras, decisões, tarefas, skills, handoffs e memória. Segundo a página, só CLAUDE.md e AGENTS.md estão presos ao provedor; todo o resto é Markdown portátil, texto simples que qualquer agente consegue ler. Quando esse material vive numa camada portátil dentro do projeto, Claude Code, Codex CLI, Gemini ou um modelo local em container viram apenas executores, isto é, programas que fazem o trabalho a partir desses arquivos. Trocar de modelo passa a ser trocar uma borda, não o centro. A área junta a tese, o método, um curso de 3 trilhas, um kit de scripts e mega-prompts que fazem isso na prática.

Por que aprender

Modelos mudam com frequência, por preço, acesso ou qualidade. Se o conhecimento do projeto estiver no lugar certo, cada troca custa pouco em vez de exigir reconstrução.

Conceitos-chave

cérebro = contexto, regras, decisões, tarefas, skills, handoffs e memória; Markdown portátil; executor; trocar a borda, não o centro

Na prática

Uma analista usa um assistente de código há meses e o time decide testar outro. Como as regras e decisões do projeto estão em arquivos Markdown no repositório, o novo executor lê os mesmos arquivos e continua o trabalho.

✓ Faça

Liste três coisas que o seu agente "sabe" hoje sobre um projeto e anote onde cada uma está gravada.

✗ Evite

Julgar a área pelo nome: leia a tese na página antes de decidir se ela é para você.

2O lock-in está no runtime

O que é

Lock-in é ficar preso a um fornecedor porque sair dele custa caro. A página afirma: "O lock-in não está no modelo. Está no que você deixou dentro do runtime." Runtime é o programa que roda o agente, como o Claude Code ou o Codex CLI. Quem usa um assistente de código há alguns meses acumulou instruções, memória, skills, hooks e milhares de sessões num formato que só aquele runtime lê. A página descreve três mudanças: o lock-in é invisível até o dia da troca; o mesmo conhecimento pode servir a qualquer modelo; e você passa a ter menos dependência e mais controle. O conteúdo é durável, o formato é descartável, e misturar os dois é o que trava a migração.

Por que aprender

A área é para quem usa Claude Code ou Codex em projetos reais e teme a troca de modelo. Entender onde está a dependência mostra o que precisa sair do runtime antes que a troca seja obrigatória.

Conceitos-chave

lock-in; runtime; CLAUDE.md, memória nativa e sessões JSONL são armazenamento do trabalho, não o trabalho; conteúdo durável, formato descartável

Na prática

Um desenvolvedor descobre que as decisões mais importantes do projeto estão só no histórico de sessões do assistente. Ao trocar de ferramenta, ninguém sabe por que certas escolhas foram feitas, porque nada foi anotado fora do runtime.

Lock-ininvisível até a trocaMesmo saberqualquer modeloMais controlemodelo reversível
As três mudanças da página: o problema só aparece na troca, o conhecimento pode servir a qualquer modelo e o controle volta para você.

3O método: auditar antes de mudar

O que é

O método tem quatro passos, nessa ordem: Auditar, Adaptar, Provar e Handoff, "nunca implementando antes de auditar". Auditar é fazer um inventário somente leitura dos dois runtimes: skills, comandos, subagentes, hooks e MCP; cada skill vira reutilizável, adaptador, nativo ou não resolvido. Adaptar é dividir o CLAUDE.md: regras portáteis vão para o AGENTS.md, e o que depende de plugin, hook ou menu do Claude fica no arquivo específico, que apenas importa o portátil. Provar é abrir uma sessão nova e fazer cinco perguntas de continuidade: objetivo e critério de pronto, uma regra com o arquivo de origem, a última decisão, a próxima ação e conflitos. Handoff é gravar decisões, pendências, próximos passos e caminhos num Markdown que a próxima sessão lê antes de agir.

Por que aprender

A ordem evita o erro mais caro: mudar arquivos antes de saber o que existe. E a regra de prova impede que você confunda arquivo criado com conhecimento realmente usado.

Conceitos-chave

Auditar → Adaptar → Provar → Handoff; MODE: audit; portátil × resíduo; cinco perguntas de continuidade; arquivo existir não é prova

Na prática

Uma equipe quer levar um projeto para o Codex. Primeiro roda a auditoria, que só lê e classifica; depois separa o CLAUDE.md; por fim abre uma sessão nova e confere se o agente responde a próxima ação citando o arquivo certo.

Sequência para experimentar

  1. Abra a página da área ao lado desta aula.
  2. Escreva as cinco perguntas de continuidade num arquivo e responda cada uma apontando o arquivo de origem.
  3. Anote em uma frase o que mudou no seu entendimento.
AuditarAdaptarProvarHandoff
A ordem importa: primeiro só ler e classificar, depois adaptar, provar em sessão nova e registrar o handoff.

4O núcleo portátil, arquivo por arquivo

O que é

O núcleo portátil são sete lugares, cada um com um dono e uma regra de atualização. AGENTS.md guarda regras estáveis e ordem de leitura; context/overview.md, fatos verificados com fonte e data; context/current-state.md, o que funciona e o que está pendente; context/sources.md, de onde vem cada informação. context/decisions/ tem uma decisão aceita por arquivo; tasks/current.md traz objetivo, dono, critério de pronto e próxima ação; handoffs/latest.md é a continuação para a próxima sessão. A página avisa que esses nomes são convenção: nenhum runtime carrega essas pastas sozinho, quem manda ler é a ordem de leitura no topo do AGENTS.md. Cada informação tem um tipo: fato, preferência, hipótese ou decisão, e "provenance vence timestamp", ou seja, a origem pesa mais que a data e nada se apaga, usa-se superseded_by.

Por que aprender

Misturar fato com hipótese, ou decisão com preferência, faz o agente repetir erro antigo e contradizer o que já foi resolvido. Dono e data permitem promover uma informação para contexto aprovado, sempre com a sua aprovação.

Conceitos-chave

AGENTS.md; context/; decisions/; tasks/current.md; handoffs/latest.md; fato, preferência, hipótese, decisão; provenance vence timestamp; segredos fora do repositório

Na prática

Num projeto com decisões antigas em conflito, cada decisão aceita vira um arquivo em context/decisions/. Quando uma é substituída, ela não é apagada: ganha a marca superseded_by e o agente para de seguir a regra velha.

✓ Faça

Crie num projeto de teste o arquivo tasks/current.md com objetivo, dono, critério de pronto e próxima ação.

✗ Evite

Pular para a ferramenta ou o curso sem entender o problema que a área resolve.

AGENTS.mdcontext/overview.mdcurrent-state.mdsources.mddecisions/tasks/current.mdhandoffs/latest.md
Os sete lugares do núcleo portátil: nenhum runtime lê isso sozinho, é a ordem de leitura no AGENTS.md que manda.

5Migrar ou ficar agnóstico

O que é

A página separa a decisão em três níveis de esforço, não em opiniões. Nível 1 é importar no app, com um clique: rápido, mas limitado ao que o outro lado aceita, e o CLI do Codex, por exemplo, não tem import nativo. Nível 2 é migrar com o kit, com um comando: rodar os scripts do agente-claude-codex para auditar, adaptar, instalar o núcleo, portar skills e provar. Nível 3 é a camada pessoal portátil, duradoura: o conhecimento vive no projeto e o runtime fica intercambiável. Ficar agnóstico, isto é, não depender de nenhum modelo específico, é o nível 3, e segundo a página é o único que sobrevive à próxima troca. Agnóstico não é abandonar o Claude: você continua escolhendo o executor por tarefa.

Por que aprender

Nem todo mundo precisa do nível 3 agora. A página lista quando migrar já, por custo, acesso ou política, e quando vale ficar agnóstico, como ao usar dois executores ou ter trabalho de cliente.

Conceitos-chave

Nível 1 importar; Nível 2 migrar com o kit; Nível 3 camada pessoal portátil; migrar agora × ficar agnóstico; custo de não fazer nada

Na prática

Um consultor precisa usar o Codex nesta semana por política de um cliente e tem poucas skills, quase todas em Markdown puro: é caso de migrar agora. Outro já trocou de ferramenta uma vez e não quer refazer: é caso de ficar agnóstico.

Nível 1importar no appNível 2migrar com o kitNível 3camada portátil
Cada nível custa mais esforço uma vez, e só o terceiro sobrevive à próxima troca de modelo.

6Curso, kit e o primeiro passo

O que é

O curso Claude → Codex: migre ou fique agnóstico é aberto, em português, com versões em inglês e espanhol; segundo o currículo, são 3 trilhas, 18 módulos e 108 tópicos. A Trilha 1 cobre fundamentos e vocabulário, a Trilha 2 é o kit comando por comando e a Trilha 3 traz seis projetos sobre um sistema real. O kit agente-claude-codex é bash mais Markdown, em três formas de uso: scripts, mega-prompts e o template do núcleo portátil. O doctor.sh responde "meu ambiente está pronto?" e o audit.sh grava um relatório somente leitura; há ainda adapt-instructions.sh, init-core.sh, sync-skills.sh com polyskill, readback-test.sh, drift-report.sh e promover-memoria.sh. A página resume: "O melhor primeiro passo é um projeto seu, em modo audit."

Por que aprender

O curso explica o porquê e o kit faz o trabalho sem apagar nada: nada em ~/.claude ou ~/.codex é copiado em massa ou apagado, e instalar skill faz backup ao lado. Começar pela auditoria mostra em uma sessão o que é portátil e o que depende de hook.

Conceitos-chave

curso de 3 trilhas; kit agente-claude-codex; doctor.sh; audit.sh; mega-prompts A e B; Mapa do tema; área irmã Codex + Claude

Na prática

Uma gestora de TI quer avaliar a troca de ferramenta sem risco. Ela clona o kit, roda o doctor.sh, lê a auditoria e só depois decide qual nível de migração vale a pena para o time.

Critérios para revisar sua ficha

Use esta rubrica depois do laboratório. Cada linha pede uma evidência; marcar leitura não significa que a ficha foi feita.

Critério Evidência esperada Se não passou
Tese A área cabe em uma frase sua, fiel à página. Releia o topo da página e o tópico 1.
Público Você sabe dizer para quem a área é e para quem não é. Volte ao tópico 2 e escreva um exemplo do seu trabalho.
Blocos Você nomeia as partes centrais da área. Use o diagrama do módulo como roteiro.
Primeiro passo Você escolheu um passo concreto e pequeno. Copie o primeiro passo que a própria página recomenda.
Porta de entrada Você sabe qual curso, kit ou projeto abrir primeiro. Consulte o tópico 6 e a faixa de acesso da página.
Fonte Cada afirmação da ficha tem origem na página. Troque o que você supôs pelo que a página diz.

MÃO NA MASSA / ~10 MIN

Sua primeira auditoria em modo audit

Deixe a página da área aberta: https://eventos.inema.pro/claude-codex/. Use um exemplo do seu trabalho, sem dados pessoais ou de clientes.

Prompt: auditoria somente leitura do seu projeto

Cole no Claude, no ChatGPT ou no Codex. Troque o que estiver entre < e > pela sua situação.

MODE: audit
Leia https://eventos.inema.pro/claude-codex/ para entender o método Auditar → Adaptar → Provar → Handoff.
Depois, sem alterar nenhum arquivo, faça um inventário deste projeto: <caminho da pasta do seu projeto>.
1. Liste instruções (CLAUDE.md, AGENTS.md), skills, comandos, hooks e MCP que você encontrar.
2. Classifique cada skill como reutilizável, adaptador, nativo ou não resolvido.
3. Separe o CLAUDE.md em linhas portáteis (vão para o AGENTS.md) e resíduo específico do Claude.
4. Diga quais das cinco perguntas de continuidade (objetivo e critério de pronto, uma regra com arquivo de origem, última decisão, próxima ação, conflitos) os arquivos atuais já respondem.
Devolva só o relatório e um plano. Não implemente nada.

Critério de pronto

Explicar por que o lock-in mora no runtime e como o método Auditar → Adaptar → Provar → Handoff leva o conhecimento do projeto para um núcleo portátil. Guarde a ficha com a tese, o público, o primeiro passo e a porta de entrada.

Abrir a página da área ↗

Confira o que ficou

Um colega diz que migrar do Claude para o Codex é só copiar o CLAUDE.md para outro lugar. O que falta nessa ideia?

Ver resposta comentada

Falta separar o que é portátil do que é resíduo e provar em sessão nova. Como diz a página, arquivo existir não é prova; o agente ter lido e usado é.

Se sua resposta foi diferente, volte ao tópico correspondente e escreva a diferença em uma frase. A checagem não bloqueia seu estudo.

Resumo do módulo

  • cérebro = contexto, regras, decisões, tarefas, skills, handoffs e memória; Markdown portátil; executor; trocar a borda, não o centro
  • lock-in; runtime; CLAUDE.md, memória nativa e sessões JSONL são armazenamento do trabalho, não o trabalho; conteúdo durável, formato descartável
  • Auditar → Adaptar → Provar → Handoff; MODE: audit; portátil × resíduo; cinco perguntas de continuidade; arquivo existir não é prova
  • AGENTS.md; context/; decisions/; tasks/current.md; handoffs/latest.md; fato, preferência, hipótese, decisão; provenance vence timestamp; segredos fora do repositório
  • Nível 1 importar; Nível 2 migrar com o kit; Nível 3 camada pessoal portátil; migrar agora × ficar agnóstico; custo de não fazer nada
  • curso de 3 trilhas; kit agente-claude-codex; doctor.sh; audit.sh; mega-prompts A e B; Mapa do tema; área irmã Codex + Claude

Consulte a fonte

Páginas lidas em 28/09/2026. O conteúdo das áreas muda; a página oficial vale mais que este resumo.

Módulo completo