Os 5 passos do ciclo: Rascunho → Avaliar → Revisar → Repetir → Pronto
📝 Rascunho — Claude escreve PLAN.md
O ciclo começa com você invocando /claudex plan e
descrevendo o que quer construir. Claude lê seu pedido (e arquivos de escopo, se passados)
e gera a primeira versão do PLAN.md.
📄 Como o PLAN.md inicial se parece
# PLAN.md (rascunho — antes da revisão) ## Objetivo Adicionar expiração para links curtos. ## Abordagem - Adicionar coluna expires_at na tabela links - Endpoint GET /links/:id retorna 404 se expirado - Job diário marca expirados ## Etapas 1. Migration (1h) 2. Atualizar handler (2h) 3. Job de limpeza (1h) 4. Testes (2h) ## Riscos - Nenhum identificado.
É um rascunho. Funcional, mas vago. Sem rollback, sem observabilidade, sem critério de aceite mensurável. É exatamente isso que o ciclo vai endurecer.
💡 O que importa nesta fase
O rascunho NÃO precisa ser perfeito. Ele só precisa ser:
- •Completo o suficiente pra Codex conseguir criticar — sem buracos óbvios
- •Específico no objetivo — vago aqui = vago em todas as rodadas
- •Honesto sobre o que sabe — se não sabe, escreve "a investigar"
🔬 Avaliação — Codex critica
Codex recebe o PLAN.md e uma persona específica (engenheiro sênior, segurança, ou Ops/SRE). Lê o plano com olho cético e gera achados classificados por severidade. Não escreve código, não altera o plano — só lista problemas.
📋 findings-round-1.md (Engenheiro Sênior)
# Rodada 1 — Engenheiro Sênior # Foco: design, premissas, decisões técnicas ## Alto - O plano não trata links já criados antes da feature. Backfill obrigatório: que expires_at esses links recebem? NULL? Padrão de 30d? Permanente? - 404 vs 410: link expirado e link inexistente devem dar status diferentes para suporte conseguir distinguir. ## Médio - Cache de CDN não mencionado. TTL típico de 24h significa link expirado vai continuar respondendo da CDN por 1 dia inteiro depois de expirar. - Estimativa "Job de limpeza (1h)" é otimista. Job que mexe em produção precisa de batch + lock + métrica = 4h mínimo. ## Baixo - Considerar adicionar expired_at (timestamp de quando foi marcado expirado) para auditoria. - Migration sem rollback descrito.
3 críticas reais que economizariam dias de retrabalho. E isso é só a Rodada 1 — ainda vão entrar Segurança e Ops/SRE.
🛠️ Revisão — Claude integra os achados
Claude lê o findings-round-1.md, decide o que
integrar, o que descartar (com justificativa) e reescreve
o PLAN.md. O plano sai mais grosso, mais específico, mais defensável.
📈 PLAN.md depois da Rodada 1
# PLAN.md (após rodada 1) ## Objetivo Adicionar expiração para links curtos com: - distinção entre "expirado" e "não existe" - compatibilidade com cache de CDN ## Decisões - Links existentes recebem expires_at = NULL (permanentes) - Status 410 (Gone) para expirados; 404 para inexistentes - TTL da CDN reduzido para 5min na rota de redirect ## Etapas 1. Migration: adicionar expires_at, expired_at; default NULL (1h) 2. Migration de rollback testada em staging (30min) 3. Atualizar handler para 410 vs 404 (2h) 4. Reduzir TTL da rota de redirect (1h) 5. Job de limpeza com batch de 1000 + lock (4h) 6. Métrica "links_expirados_servidos_cache" (1h) 7. Testes incluindo backfill (2h) ## Riscos - CDN com TTL alto pode servir conteúdo expirado (mitigado: TTL reduzido) - Job mal configurado pode varrer demais (mitigado: batch + lock)
Note: o plano cresceu — mas cresceu onde precisava. Cada parágrafo novo veio de um achado real do Codex.
🔁 Repetição — N rodadas
O ciclo se repete. Cada rodada usa uma persona diferente — o mesmo plano é lido por 3 pares de olhos com critérios distintos. É isso que torna o resultado robusto.
👴 Engenheiro Sênior
Foco: design, premissas, decisões técnicas, dependências mal explicadas.
🔐 Segurança
Foco: autenticação, condições de corrida, perda de dados, vazamento.
⚙️ Ops / SRE
Foco: rollback, observabilidade, métricas, deploy, recuperação.
💡 Por que rotacionar
A mesma persona em 3 rodadas encontra os mesmos tipos de problema. Personas diferentes encontram problemas diferentes.
Engenheiro pega design fraco. Segurança pega corrida. Ops/SRE pega deploy. Sem rotação, você cobre 1/3 do espectro.
🔒 Plano travado — pronto pra execução
Atingidas as N rodadas (padrão 3), o ciclo encerra. O plano fica travado — daí o Claude pode usar pra implementar com confiança. A fase de sumarização mostra o que aconteceu.
📊 Output da sumarização final
# Sumário do ciclo Claudex Plano: "adicionar expiração para links curtos" Rodadas: 3 de 3 concluídas Tempo total: 8min 42s Achados por rodada: Rodada 1 (Engenheiro): 2 alto, 2 médio, 2 baixo Rodada 2 (Segurança): 1 alto, 3 médio, 1 baixo Rodada 3 (Ops/SRE): 1 alto, 2 médio, 0 baixo Total: 14 achados — 13 integrados, 1 descartado com nota PLAN.md: Versão inicial: 22 linhas, 4 seções Versão final: 58 linhas, 7 seções Crescimento útil: rollback, observabilidade, mitigação CDN Status: ✅ PLANO TRAVADO — pronto para execução
Sem isso, o ciclo terminaria em silêncio e você não saberia se foi útil ou não. A sumarização dá clareza e confiança.
🖼️ Visualizando o ciclo completo
Tendo visto cada passo isoladamente, agora monte a imagem mental completa. É essa figura que você vai carregar pra sempre quando ouvir a palavra "Claudex".
🧠 Como descrever em uma frase
"Claude rascunha, Codex critica, Claude revisa, ciclo repete por 3 rodadas com personas diferentes, e o plano sai travado pra execução."
Decore. Use ela quando alguém te perguntar como Claudex funciona — em 30 segundos você mostrou o ciclo todo, com personas, encerramento e propósito.
💡 Dica prática
Se você ainda não conseguiu desenhar o ciclo numa folha de papel, volta nos tópicos 1 a 5. O ciclo é tão central no Claudex que entender por completo aqui economiza horas nos próximos módulos e nas trilhas seguintes.
📌 Resumo do Módulo
Próximo Módulo:
1.4 — ⚖️ Por que Claude + Codex juntos