🚀 Projetos

O diagnóstico achou 55 projetos marcados como trusted no Codex; 13 deles têm CLAUDE.md mas nenhum AGENTS.md (wifi, portal, inemapro-mono, timesmkt2, timesmkt3, inemacert, promoavatar2, skool-roast, imkt4, iccmonit, ATIA, claude-session-kit, agentes-fronteiros). Nesses, cada sessão do Codex começa do zero.

O piloto certo é pequeno, usado toda semana e com CLAUDE.md próprio — assim o readback mede algo real, não um exemplo de brinquedo.

Trusted no Codex, projeto "cego", ordem por uso, tarefa representativa.

A Fase 0: rodar adapt-instructions.sh ~/.claude, revisar as 71 linhas portáteis, gravar ~/.codex/AGENTS.md e deixar o CLAUDE.md global começando com @AGENTS.md mais as 7 linhas de resíduo.

Sem base global, regras como autor do commit e onde ficam as keys não chegam ao Codex em nenhum projeto.

Instrução global vs por projeto, @AGENTS.md, resíduo Claude, .proposto.md.

Arquivos como o CLAUDE.md do ruflo (1.391 linhas) ou do timesmkt2 (427) viram ruído em qualquer runtime. Regras estáveis ficam no AGENTS.md; decisões, fontes e runbooks vão para context/.

Migrar cru só transporta ruído. A faxina é o passo que o texto-fonte chama de "Marie Kondo para as suas pastas".

Arquivar por padrão, trazer de volta só quando preciso, instrução curta e contexto separado.

A sequência do kit aplicada ao piloto: diagnóstico, inventário, adaptação das instruções, núcleo portátil sem sobrescrever nada e a skill session-handoff portada via polyskill.

Cada script é reversível e produz evidência; pular um deles é exatamente onde a migração vira "achismo".

Ordem fixa, saída em relatorios/, backup ao lado, drift zero.

readback-test.sh <projeto> both abre sessão nova no Claude e no Codex e pergunta objetivo, regra com fonte, última decisão, próxima ação e conflitos. A resposta bruta fica em relatorios/.

É a única prova de que o agente encontrou, leu, entendeu e usou o contexto — arquivo existir não conta.

Sessão nova, cita AGENTS.md / tasks / handoffs, passou / falhou / não rodado.

Critérios do plano: readback aprovado nos dois runtimes, drift zero, clone isolado passa o check.sh, setup Claude intacto. Tudo registrado em tasks/current.md e handoffs/latest.md.

O handoff é o que permite a próxima sessão — em qualquer runtime — continuar do ponto certo sem reler JSONL.

Critério de pronto verificável, handoff com checks rodados, próxima ação exata.

O ~/.claude.json tem magnific e metricool globais, mais klingai (wifi) e cerebro-vip (2cerebrox) por projeto. O config.toml do Codex não tem nenhum bloco [mcp_servers].

MCP dá acesso a ferramenta e dado; não migra histórico nem resolve memória. Saber exatamente o que cada runtime enxerga evita esperar do Codex algo que ele não tem.

MCP global vs por projeto, .mcp.json, config.toml, escopo de conta.

Registrar o servidor no Codex apontando para a mesma key que já vive em ~/projetos/openpcbotv2/.env, carregada em runtime — nunca colada no config nem no repo.

O Prompt A é explícito: traduzir MCP retendo escopo de conta e referência de credencial, sem copiar o valor.

Referência vs valor, carregar em runtime, segredos fora do portátil.

As 15 skills classificadas como "adaptador" (avatar-heygen-nei, heygen-cli, heygen-mcp, espiona-ads, ugc-seedance25, website-intelligence, comfy-relay e as 8 printing-press) só funcionam no Codex depois do MCP correspondente estar registrado.

O bloqueio real da portabilidade é MCP, não o formato do SKILL.md — 72 das 89 skills migram sem tocar em nada.

Reutilizável vs adaptador, dependência de ferramenta, portar depois do MCP.

O Claude dispara 2 hooks em SessionStart (context-mode, fable-mindset). O ~/.codex/hooks.json conhece PostToolUse e Stop (usados pelo impeccable), mas não tem evento de início de sessão.

Nunca assuma que hooks com nome parecido têm a mesma semântica. A lógica reutilizável vai para um script comum; cada evento nativo é validado separado.

Evento, payload, trust hash, script comum + gatilho nativo.

O hook que injeta a "regra de ritmo" no Claude não tem equivalente no Codex; a solução portátil é transformar o playbook numa seção do AGENTS.md global, lida por instrução.

Quando o mecanismo nativo não existe, o conteúdo ainda pode viajar — como Markdown comum. O mesmo vale para silver-platter.

Nativo → texto, instrução em vez de injeção, resíduo Claude.

Os 7 subagentes do Claude (conselho, advogado-do-diabo, analista-neutro, diretor-ecossistema…) não têm equivalente 1:1 no Codex. Cada papel vira uma skill com prompt próprio — o mesmo desenho que o openpcbotv3 usa em agents/ e personalidades/.

Papel é conteúdo; orquestração é mecanismo. O conteúdo é portátil, o mecanismo fica fora do núcleo durável.

Skill de papel, prompt de persona, orquestração fora do núcleo.

Os arquivos em ~/.claude/projects/*/memory foram escritos pelo modelo, sem revisão humana, e nenhum outro runtime os enxerga. Copiá-los em massa transporta erro junto com acerto.

O plano é claro: promover fato a fato, deliberadamente, quando o projeto for tocado — nunca cópia em massa.

Memória nativa vs fonte, promoção deliberada, evidência bruta separada.

Em ~/vault/, o bot v3 mantém MEMORY.md e USER.md curados: ele propõe entradas e você aprova pelo Telegram. USER.md entra em todo prompt do bot.

É o único lugar da máquina com fatos pessoais aprovados por humano — exatamente o que o Prompt B chama de "promover fatos verificados".

Vault curado, overview global, fato verificado com aprovação.

O agente classifica a frase (semântica ou episódica), propõe a entrada, e só /memoria aprovar <id> grava no vault. Perguntas nunca viram fato.

Separa fato de preferência, hipótese e decisão na entrada — o problema que a Trilha 1 chamou de "qual das versões é a correta?".

Proposta, aprovação humana, semântico vs episódico, dedupe.

A consolidação noturna do v3 detecta contradições por data e marca a entrada antiga com superseded_by. A antiga sai do contexto, mas continua no banco.

É a regra de conflito do plano na prática: provenance e decisão aceita vencem timestamp, e nada se perde por engano.

Contradição por data, esconder vs apagar, backup antes da rodada.

O v3 já injeta USER.md em todo prompt. Claude e Codex fazem o mesmo por instrução de leitura no AGENTS.md global; o dsh, via skill de prime. Um fato pessoal, uma fonte, três executores.

Critério de aceite do sistema: em sessão nova, cada runtime cita USER.md como fonte de um fato pessoal.

Fonte única, leitura por instrução, sem auto-load, readback com fonte.

6.859 sessões do Claude (2,3 GB) e 209 do Codex (601 MB) são histórico, não fonte. Com handoff/prime rodando, sessões com mais de 90 dias podem ser arquivadas.

Só depois do ciclo estar de pé: o handoff substitui a dependência dos JSONL, não o contrário.

Histórico vs fonte, arquivar por padrão, ordem de operações.

@deepseek-ai/dsh em Docker, painel em 127.0.0.1:9080. ./dsh local monta ~/projetos e usa só Ollama; remoto usa OpenRouter sem projetos; remoto-projetos exige digitar CONFIRMO.

É um terceiro runtime real, com harness mais fraco — o caso em que o texto-fonte diz que vale a pena cuidar do próprio harness.

Container, provedor trocável, montagem amarrada ao provedor, modelo local.

formato-curso-v2, formato-curso-v5 e capa-inema foram copiadas para ~/projetos/dsh-skills. Quando o original em formato-curso-inema muda, a cópia não acompanha.

Com quatro consumidores de skills (Claude 117, Codex 27, dsh 3, openpcbotv3 16), sem fonte canônica cada um diverge sozinho.

Drift, fonte canônica, quatro consumidores, cópia gerada vs manual.

O dsh aceita o mesmo SKILL.md do Claude, então o destino novo copia dist/claude/<skill> para ~/projetos/dsh-skills/<skill> e o drift check passa a cobrir os 4 destinos (claude, codex, dsh, v3).

As 3 cópias manuais de hoje passam a ser geradas — o critério de aceite é drift sem DRIFT em todos os destinos.

Adaptador de destino, mesmo formato, drift em 4 lugares.

O dsh escaneia $DSH_HOME/skills, mas não lê AGENTS.md sozinho. Uma skill de prime instrui a ler AGENTS.md, context/ e handoffs/latest.md do projeto montado no modo local.

Nomes de arquivo são convenção; nenhum runtime auto-carrega. Quem não tem mecanismo nativo ganha a leitura por skill.

Prime como skill, pontes de caminho em work/, leitura explícita.

~/projetos tem 269 arquivos de segredo (inclui wifi/.env e openpcbotv2/.env). Montar isso com provedor remoto mandaria tudo para fora; por isso montagem e provedor são amarrados e o dsh recusa expor a rede.

Segurança do plano: readback no dsh só em modo local. Pasta é organização; permissão, montagem e credencial é o que impõe acesso.

Modos exclusivos, network_mode host, versão congelada, túnel SSH.

Readback no dsh pelo painel, com as mesmas 5 perguntas. O critério é citar AGENTS.md, tasks e handoffs — não a qualidade da redação. Modelo local rende menos; isso é limite do modelo, não da portabilidade.

Comparar no modo remoto antes de concluir que a estrutura falhou. Skills escritas para o Claude podem ficar aquém num modelo pequeno.

Critério de aceite ajustado, limite do modelo vs limite da estrutura, comparação controlada.

Descubra o que os dois clientes têm em comum (padrões de entrega, skills, processos), centralize essa parte, e mantenha pastas específicas só para o que é exclusivo de cada um.

Quanto maior a área do meio, mais reutilizável o sistema — e menos você reescreve por cliente.

Compartilhado vs exclusivo, template genérico, área comum grande.

Cada projeto de cliente ganha seu repositório privado (ou fronteira equivalente) e começa com um snapshot aprovado de contexto que registra ID do cliente, fonte, data e regra de refresh. Fontes de outro cliente são rejeitadas.

Uma pasta chamada "harbor" descreve organização; só permissão de repo, montagem e credencial impõem acesso.

Fronteira imposta, snapshot datado, client ID, refresh deliberado.

Fatos, credenciais, registros e logs de cliente nunca entram no CLAUDE.md/AGENTS.md global nem no vault pessoal. Trabalho misto roda em pilotos separados, com raízes separadas.

Memória universal vaza contexto de um cliente para outro sem que ninguém perceba — é o erro mais caro do modelo agnóstico.

Escopo global vs de cliente, raízes separadas, pilotos separados.

O bloco "Client workspace" que se acrescenta ao Prompt B: um cliente nomeado, um piloto, padrões genéricos reutilizados, verificação de acesso a repo, montagens, conectores, permissões de retrieval e backups.

Começa em MODE: audit, como tudo: o agente devolve árvore, donos e testes antes de tocar em qualquer arquivo.

CLIENT_SCOPE, audit primeiro, verificação de acesso, um cliente por vez.

Plante um dado falso e único no cliente A; peça-o em sessão do cliente B. Se aparece, o backend vazou. Se o modelo "recusa educadamente", isso não prova nada sobre o backend.

Sem canário você só tem a palavra do modelo. Enforcement não verificado deve ser rotulado como tal.

Canário, dado sintético, prova de backend, rótulo "não verificado".

O template só vai para o segundo cliente quando o primeiro passou em standalone, readback e canário. Para vários clientes, o add-on é repetido com um ID específico a cada vez.

Um dono e um worktree por mudança concorrente; pasta compartilhada não é lock e worktree não impõe isolamento de cliente.

Piloto passou, um ID por rodada, worktree ≠ isolamento.

Uma edição numa skill pode deixá-la melhor para o Claude e pior para o Codex ou para um modelo local. Não existe versão final; existe a versão testada hoje.

Sem readback e drift por runtime, você não descobre a regressão até o dia em que precisa dela.

Iteração, regressão cruzada, teste por runtime.

Caminhos de descoberta, formatos de config, eventos de hook e permissões mudam de versão para versão. Os prompts mandam verificar o comportamento instalado com --help e a documentação oficial, nunca inventar comando de import.

O Codex CLI 0.154 não tem import; o app tem. Esse tipo de detalhe só aparece quando você olha.

Verificar antes de converter, doc oficial, versão instalada.

Se os modelos fechados forem treinados com as suas conversas e absorverem as capacidades, muitas skills viram desnecessárias. Modelos locais provavelmente continuam dependendo delas.

Construir agnóstico não é apostar contra ninguém: é manter a estrutura funcionando enquanto o que cada provedor exige muda.

Capacidade absorvida, skill como muleta temporária, estrutura que sobrevive.

A mudança de trabalho: em vez de colecionar prompts, você mantém contexto, estado atual, ferramentas registradas, processos escritos e critérios de validação. O prompt vira consequência.

É o que o segundo texto-fonte chama de passar da filosofia para o processo: AUDITAR → ORGANIZAR → FONTE DA VERDADE → ADAPTAR → TESTAR → HANDOFF.

Gestão de agentes, seis verbos do processo, prompt como derivado.

FALHAS.md: data, o que quebrou, a menor correção possível, e se foi problema de prompt ou de infra. O kit já tem duas linhas reais: o sandbox bwrap forçado e a contagem errada do audit.

Depois de umas dez linhas o padrão aparece — e você para de reconstruir coisas que só precisavam de uma proteção.

Menor correção, prompt vs infra, padrão em dez linhas.

O resumo do curso em uma frase e a próxima ação concreta: Fase 0 com adapt-instructions.sh ~/.claude, gravar o AGENTS.md global e rodar o primeiro readback num projeto real.

Um curso que termina sem próxima ação exata vira teoria. O handoff vale para você também.

Executores sobre camada portátil, próxima ação exata, o menor passo restante.