Goal
Define onde chegar e qual evidência encerra. Sem condição de parada, a meta vira pedido aberto.
DESTINODoD
Goal não é 'trabalhe sem parar'
Goal é o destino verificável. Loop é o motor que repete executar, validar e corrigir. Plan Mode é análise sem editar. Rider é o trilho que impede o agente de parecer produtivo enquanto sai do caminho.
3peças: goal, loop, rider
4níveis de autonomia
2features nativas: goal e plan
Mapa da aula
Use este mapa para entender a sequência da aula antes de entrar nos detalhes.
Legenda de coresO que cada cor sinaliza nesta aula
Destinoestado final verificável, escrito antes do loop começar
Motorciclo de executar, validar, corrigir e repetir
TrilhoSPEC, AGENTS, rider, gates e rubrica contra drift
Loop sem freioautonomia que trabalha muito e não prova fechamento
Como ler esta aula
1. DestinoGoal descreve o estado final que precisa existir.
2. MotorLoop repete execução, validação e correção até passar gate.
3. TrilhoRider/spec carrega contexto, skills, rubrica e anti-drift.
4. ProvaA tarefa só acaba quando evidência e validators fecham.
Frase da aulaSe o goal não diz quando parar, ele não é goal, é ansiedade terceirizada para a IA.
A diferença que destrava tudo
O erro comum é misturar feature nativa, motor de repetição e convenção de prompt engineering.
Loop
Executa ciclos enquanto houver falha objetiva. Loop bom muda a hipótese depois de cada validação.
MOTORvalidate
Rider
Carrega escopo, fontes, skills, stop rules e gates. É a peça que impede autonomia de virar deriva.
TRILHOanti-drift
Goal
Contrato de chegada. Diz qual resultado precisa existir e como saber que terminou.
Loop
Contrato de repetição. Diz como o agente deve tentar, validar, corrigir e tentar de novo.
Plan Mode
Contrato de análise sem edição. O agente lê, pesquisa e planeja sem editar até existir direção aprovada.
Rider
Contrato de condução. Diz contexto, skills, fontes, restrições, critérios e gates.
Template da comunidade
GOAL/CONTEXT/CONSTRAINTS é uma convenção útil dentro do prompt; não é sintaxe nativa obrigatória.
Prompt solto
Pedido sem destino verificável. Pode gerar trabalho bonito, mas não garante fechamento.
Confusão comum
- Goal = pedir para trabalhar mais.
- Loop = deixar a IA decidir tudo.
- Plan Mode = /goal mais cuidadoso.
- Rider = documento bonito para ninguém ler.
- GOAL/CONTEXT = sintaxe oficial.
- Validação = rodar teste só no final.
Leitura correta
- Goal = Definition of Done em linguagem operacional.
- Loop = repetir enquanto houver falha objetiva.
- Plan Mode = pesquisar e planejar sem alterar nada.
- Rider = memória operacional para evitar drift.
- GOAL/CONTEXT = técnica de estruturação, não comando nativo.
- Validação = portão em cada ciclo, não ritual final.
Três coisas que parecem iguais, mas não são
A pesquisa separa o que é feature nativa, o que é modo de trabalho e o que é engenharia de prompt.
/goal
O que éFeature nativa
Quando usartrabalho com estado final verificável
Erro comumachar que ele entende 'melhorar' sem prova
Plan Mode
O que éModo read-only
Quando usarinvestigar e planejar antes de editar
Erro comumconfundir plano com execução autônoma
Ralph Loop
O que éPadrão manual
Quando usarexperimento ou controle fino do ciclo
Erro comummontar loop infinito sem stop rule
GOAL/CONTEXT
O que éTemplate de comunidade
Quando usartarefa crítica que precisa de contexto rico
Erro comumvender como sintaxe oficial
Correção importanteA sintaxe nativa real é curta: `/goal <condição verificável>`. O template GOAL/CONTEXT/CONSTRAINTS/DONE WHEN/VERIFY/STOP RULES é uma camada opcional para escrever uma condição melhor.
Qual modo usar?
Antes de acionar autonomia, escolha o tamanho do contrato.
A tarefa tem mais de uma etapa e precisa de prova?
Quanto mais longa e ambígua, mais contrato ela precisa.
Não
É pequena, reversível e fácil de conferir.
signal
Ainda não
Você sabe que é importante, mas ainda não sabe o caminho nem o aceite.
bench
↓ ↓ ↓
Talvez
Tem 2-4 passos, mas pouca incerteza.
insight
Sim
Tem validator, teste, lint, review ou qualidade objetiva.
action
Sim, longo
Vai durar muitos ciclos e precisa manter direção.
bench_plus_action
↓ ↓ ↓
Você consegue escrever o estado final em uma frase verificável?
Se não consegue, ainda não é hora de /goal.
Use prompt simples.Renomear texto, ajustar copy, explicar um trecho.
Use Plan Mode ou peça um plano read-only antes de executar.Refactor arriscado, nova aula grande, migração com muitas dependências.
Use prompt com checklist.Ajustar um componente e conferir responsivo.
Use loop.Corrigir aula até `quality:lessons` passar.
Use /goal + rider.Levar todas as aulas ao padrão Método S2S.
Rota 01
Prompt simples
Uma ação, pouca incerteza, conferência manual rápida.
- 1pedir
- 2conferir
- 3encerrar
Rota 02
Loop operacional
Executar, validar, corrigir e repetir enquanto o gate falhar.
- 1executar
- 2validar
- 3corrigir
- 4repetir
Rota 03
/goal + rider
Autonomia longa com contexto, skills, DoD e anti-drift explícitos.
- 1contrato
- 2ciclos
- 3evidência
- 4fechamento
Rota 04
Plan → Goal
Investigar sem editar, extrair critérios de aceite e só então ligar autonomia.
- 1investigar
- 2planejar
- 3aprovar
- 4executar
A anatomia de um goal forte
Goal bom é curto, mas não é raso. O detalhe pesado fica no rider.
Goal curto + rider longo + validators
1
Goal
Estado final mensurável.
2
Contexto
Arquivos, fontes de verdade e restrições.
3
Skills
Especialistas por fase: didática, UX, DS, QA.
4
Gates
Comandos e critérios que provam avanço.
5
Stop
Quando encerrar ou quando pedir ajuda.
O que cada parte responde
Se uma célula fica vazia, o agente vai inventar.
Resultado
O que precisa estar verdadeiro no final?
Escopo
Onde pode mexer e onde não pode?
Régua
Qual benchmark define qualidade?
Skills
Quem ajuda em cada fase?
Gates
Que comandos ou inspeções provam que passou?
Parada
Quando encerrar sem fingir progresso?
O que aparece nos bons exemplos reais
Os melhores exemplos de Claude Code e Codex não vendem mágica. Eles repetem a mesma engenharia: outcome claro, arquivos persistentes, stop rules e prova.
DONE WHEN
PerguntaComo o avaliador sabe que acabou?
Saudáveltests/lint/rota/artefato explícito
Riscomake it good
SPEC.md
PerguntaOnde mora o detalhe?
Saudávelcritério versionado no repo
Riscodetalhe perdido no chat
AGENTS.md
PerguntaQuais regras não mudam?
Saudávelpolítica, linguagem, git, validators
Riscocada sessão reinventa padrão
Rider
PerguntaComo não sair do trilho?
Saudávelfases, skills, scorecard e anti-drift
Riscoautonomia vira deriva
STOP RULES
PerguntaQuando parar?
Saudávelambiguidade, credencial, destrutivo, escopo
Riscoloop caro e infinito
A pilha que mais se repete nos workflows bons
1
SPEC
Define o que será construído ou ensinado.
2
AGENTS
Mantém regras estáveis entre Codex e Claude Code.
3
Rider
Detalha fases, skills, gates e riscos.
4
/goal
Dispara o trabalho autônomo com done-when verificável.
5
Evaluator
Confere o transcript e exige nova iteração se não fechou.
A sacada práticaGoal curto sozinho é frágil. Goal curto apontando para SPEC, AGENTS e rider vira sistema.
Template de goal production-ready
Use esta estrutura quando a tarefa for importante o suficiente para não caber em um pedido solto. Ela é convenção de prompt engineering, não sintaxe obrigatória do comando.
Forma nativa mínima
Use quando o resultado cabe em uma condição clara e provável no transcript.
/goal→estado final→evidência→limite/goal— Ativa o modo de meta com uma condição verificável.Estado final— O que precisa estar verdadeiro para encerrar.Evidência— Qual comando, artefato ou contagem prova que terminou.Limite— Quando parar por turnos, tempo, bloqueio ou ambiguidade.
Camada estruturada da comunidade
Use para coding, curso, módulo, refactor ou qualquer trabalho com risco de drift.
GOAL→CONTEXT→CONSTRAINTS→PRIORITY→PLAN→DONE WHEN→VERIFY→OUTPUT→STOP RULESGOAL— Uma frase com resultado mensurável.CONTEXT— Repo, arquivos, estado atual e fontes de verdade.CONSTRAINTS— O que não pode mudar, onde não pode mexer e quais padrões preservar.PRIORITY— Ordem de decisão quando houver conflito.PLAN— Entender primeiro, restatar, fazer mudanças mínimas e validar.DONE WHEN— Critérios objetivos que qualquer avaliador consegue conferir.VERIFY— Testes, lint, build, rota, screenshot ou rollback plan.OUTPUT— Resumo, arquivos alterados, riscos e validações.STOP RULES— Ambiguidade real, credencial faltante, destrutivo, escopo proibido ou limite de ciclos.
Meta-trick: peça a IA para escrever o goal
Use quando você sabe o que quer, mas ainda não sabe formular a missão com precisão.
ler sessão→ler repo→inferir intenção→perguntar lacunas→gerar /goalLeia— Analise esta conversa, o repo e os arquivos relevantes.Extraia— Identifique intenção, restrições, risco, Definition of Done e validators.Scorecard— Defina métrica, threshold, regression check e o menor teste representativo antes de rodar.Pergunte— Faça perguntas só se a ambiguidade impedir um goal seguro.Escreva— Gere um /goal curto e um rider ou SPEC separado.Revise— Critique o goal como avaliador antes de rodar.
Fraco
- /goal deixe o app melhor
- /goal melhore as aulas até ficarem premium
- /goal resolva tudo que encontrar
- /goal siga todos os critérios pedagógicos e pare quando estiver ótimo
Forte
- /goal A página X está pronta quando build, lint e teste visual passam, preservando Y.
- /goal Eleve as aulas ao padrão S2S seguindo o rider versionado e validators.
- /goal Resolva os issues do SonarQube por classe, com prova final e sem mudar arquivos fora do escopo.
- /goal Produza o rascunho verificável e deixe tom/pedagogia para revisão adversarial separada.
Antes e depois do /goal
O ganho não é escrever menos. É tirar o humano do microgerenciamento quando o critério de chegada é verificável.
O velho fluxo de trabalho parecia controle: pedir uma mudança, esperar, revisar, pedir outra correção, esperar de novo, lembrar o agente do que já tinha sido combinado. O novo fluxo troca conversa por contrato: a pessoa define o estado final, os limites, os gates e a regra de parada. O agente itera sozinho enquanto houver falha objetiva.
De 20 prompts para 1 contrato
Quando o resultado é mensurável, o humano não precisa aprovar cada microcorreção.
Começou comoVárias mensagens pequenas: corrige isso, agora roda teste, agora ajusta lint, agora me mostra.
VirouUm goal com DONE WHEN: todos os testes passam, lint limpo, arquivos alterados listados e riscos reportados.
ProvaO loop continua até a evidência fechar, não até o agente parecer confiante.
LiçãoA autonomia só funciona quando a Definition of Done é observável.
1AntesHumano dirige cada curva.
2ContratoGoal define destino, restrições e gates.
3DepoisAgente itera até prova objetiva.
- O loop continua até a evidência fechar, não até o agente parecer confiante.
- A autonomia só funciona quando a Definition of Done é observável.
- Menos prompts não significa menos critério. Significa critério melhor escrito.
- Antes: Humano dirige cada curva.
- Contrato: Goal define destino, restrições e gates.
- Depois: Agente itera até prova objetiva.
Workflow antigo
- 20 mensagens para lembrar contexto.
- Correções em sequência, sem portão claro.
- Humano decide a cada tentativa se está bom.
- Fim baseado em cansaço ou aparência.
Workflow com goal
- 1 goal com done-when verificável.
- Loop autônomo enquanto teste/lint/review falhar.
- Evaluator ou gate confere a evidência.
- Fim baseado em prova.
A mudança real: de conversa para contrato
1
Escrever contrato
Goal, contexto, constraints, done-when e stop rules.
2
Rodar loop
Implementar, validar, corrigir, repetir.
3
Avaliar transcript
O avaliador confere se a evidência prometida apareceu.
4
Encerrar
Resumo final, arquivos alterados, riscos e próximos passos.
SPEC, AGENTS e Rider: quem faz o quê
Em runs longas, o chat não deve ser a memória principal. A memória precisa morar no repo.
Arquivos persistentes
A pergunta não é qual arquivo é mais bonito. É qual ambiguidade cada um remove.
SPEC.md
Define o produto, módulo ou aula: objetivo, estrutura, entregáveis e aceite.
AGENTS.md
Define regras permanentes: linguagem, git, segurança, estilo, validators.
Rider.md
Define a missão longa: fases, skills, scorecard, anti-drift e stop rules.
Ledger
Registra progresso e decisões quando a execução dura muitos ciclos.
Uso 01
SPEC primeiro
Quando ainda não está claro o que construir ou ensinar.
- 1objetivo
- 2estrutura
- 3aceite
Uso 02
AGENTS sempre
Quando você quer consistência entre sessões, IDEs e modelos.
- 1regras
- 2políticas
- 3validators
Uso 03
Rider para long-run
Quando o trabalho é grande demais para caber em uma conversa.
- 1fases
- 2skills
- 3gates
- 4parada
SPEC para curso: o que precisa existir
Para AIOX Courses, SPEC não é documento corporativo. É um molde para o agente saber exatamente que aula ou módulo precisa nascer.
[ a ] 1. Objetivo
- Primary Goal — resultado mensurável do módulo ou aula.
- Why — por que isso existe para o aluno e para o curso.
[ b ] 2. Estrutura
- Lessons — sequência, duração e mudança por aula.
- Deliverables — scripts, quizzes, labs, diagramas, export ou artefatos.
[ c ] 3. Aceite
- DONE WHEN — critérios que qualquer agente consegue verificar.
- Validation — quality:lessons, typecheck, lint, rota e revisão didática.
[ d ] 4. Limites
- Constraints — o que não mexer, o que não assumir, o que preservar.
- Stop — quando parar por ambiguidade, credencial, custo ou escopo.
SPEC mínimo para uma aula AIOX
Use antes de gerar uma aula nova, especialmente se ela virar material canônico.
Overview→Audience→Objectives→Structure→Done when→Guidelines→Validation→Change logOverview— Uma frase com o resultado de aprendizagem.Audience— Quem é o aluno, o que ele já sabe e onde costuma confundir.Objectives— 2-4 objetivos com verbo observável.Structure— Seções, exemplos, prática, portão e artefatos visuais esperados.Done when— Lista verificável de aceite didático, visual e técnico.Guidelines— Tom, linguagem, acessibilidade, marca e densidade de texto.Validation— Comandos, inspeção visual, revisão adversarial e score mínimo.Change log— Registro curto do que mudou para o documento ser vivo.
O avaliador automático não substitui julgamento humano
A pesquisa deixou uma regra clara: o avaliador de /goal só consegue fechar aquilo que aparece como evidência no transcript.
Máquina-checável
- Teste sai com exit code 0.
- Lint não tem erro.
- Arquivo existe no path esperado.
- Rota responde 200.
- Score `quality:lessons` passou.
Humano-checável
- Tom está adequado para aluno comum.
- A explicação está didática de verdade.
- O visual reduz carga cognitiva.
- O exemplo convence e fixa.
- A aula parece melhor que Método S2S.
Regra para AIOX CoursesUse /goal para produzir o rascunho verificável. Use revisão adversarial humana, course-creator ou UX para julgar pedagogia, clareza e gosto visual.
Typecheck
Vai no /goal?Sim
Vai no review?comando prova
Por quêbinário
Rota 200
Vai no /goal?Sim
Vai no review?curl/probe prova
Por quêbinário
Tom didático
Vai no /goal?Não
Vai no review?review pedagógico
Por quêsubjetivo
Hierarquia visual
Vai no /goal?Não sozinho
Vai no review?screenshot + olhar UX
Por quêavaliador pode aceitar relato
Aula memorável
Vai no /goal?Não
Vai no review?humano ou adversarial review
Por quêjulgamento qualitativo
Codex vs Claude Code na prática
A diferença não é religiosa. É operacional: avaliador, persistência, custo, Plan Mode e recuperação mudam o melhor uso de cada ferramenta.
/goal
CodexGA/default em versões recentes; estado em SQLite
Claude CodeGA, mas session-scoped
Leitura AIOXuse quando houver DONE WHEN verificável
Evaluator
Codexsem modelo separado público; usa templates/continuação e evidência no transcript
Claude CodeHaiku separado julga transcript em binário
Leitura AIOXnenhum dos dois prova o que não apareceu como evidência
Persistência
Codexgoal DB + pause/resume/clear; melhor para runs longas
Claude Codesessão + compaction; bom, mas mais frágil em multi-dia
Leitura AIOXSPEC/AGENTS/Rider continuam obrigatórios
Memória
CodexMemories MCP com busca, paginação e leitura por offsets
Claude Codesem equivalente funcional direto
Leitura AIOXnão confundir memória da ferramenta com fonte de verdade
Custo
Codexbenchmarks independentes indicam 3-4x menos tokens
Claude Codemaior consumo em relatos comparativos
Leitura AIOXsempre usar limite de turns/tempo/budget
Plan Mode
Codexnudges/TUI; não é o mesmo read-only
Claude Coderead-only explícito por toggle/comando
Leitura AIOXClaude é melhor para análise sem edição
Guardrails
Codextoken_budget, hooks e recuperação por SQLite
Claude Codehooks granulares; cap duro menos claro
Leitura AIOXhooks ajudam, mas não substituem STOP RULES
Híbrido
Codexbom para executar longo
Claude Codebom para planejar e revisar com contexto amplo
Leitura AIOXportabilidade vem dos arquivos, não da ferramenta
Regra AIOXCodex é a escolha padrão para execução longa e retomável. Claude é forte para leitura, planejamento e revisão. O sistema confiável usa os dois, mas deixa a verdade em SPEC, AGENTS e rider.
Cuidado com versão e hypeEste recorte é de maio de 2026. Se a aula for usada depois, confira changelog, versão local e flags antes de prometer comportamento específico.
Gaps técnicos que mudam a decisão
O aluno não precisa decorar versão. Ele precisa entender que cada diferença muda uma decisão prática.
Avaliador
Claude expõe um avaliador Haiku transcript-only. Codex não documenta um validador separado com nome; por isso a evidência precisa estar ainda mais explícita no transcript.
Persistência
Codex guarda estado de goal em SQLite e pode retomar melhor depois de crash, reboot ou TUI fechado. Claude depende mais da sessão, compaction e arquivos manuais.
Custo
Benchmarks comunitários comparáveis apontam Codex consumindo 3-4x menos tokens em tarefas longas. Ainda assim, custo real varia por plano e precisa de budget rule.
Plan Mode
Claude vence quando você quer análise read-only clara. Codex tem nudges e TUI, mas não é a mesma garantia operacional.
Guardrails
Codex tem `token_budget`, hooks e estado retomável. Claude tem hooks granulares. Em ambos, STOP RULES continuam obrigatórias.
Claude Haiku evaluator
ConfiançaAlta
O que ensinarjulga transcript, não filesystem
O que não prometernão dizer que ele roda ferramentas
Codex sem modelo avaliador nomeado
ConfiançaMédia
O que ensinarnão há modelo separado público
O que não prometernão inventar arquitetura interna
Codex SQLite + resume
ConfiançaAlta
O que ensinarmelhor para long-running
O que não prometernão substituir checkpoints no repo
Token efficiency 3-4x
ConfiançaAlta para benchmark, média para custo final
O que ensinarusar como tendência
O que não prometernão prometer preço fixo
Plan Mode parity
ConfiançaAlta
O que ensinarClaude tem read-only mais claro
O que não prometernão vender Codex como equivalente exato
Depreciação
ConfiançaMédia
O que ensinarsem sinal atual de remoção
O que não prometerferramenta muda rápido
Como falar para aluno comumPense assim: Claude é melhor para pensar sem mexer; Codex é melhor para trabalhar por muito tempo com freios. Os dois precisam de prova escrita, porque nenhum avaliador enxerga qualidade que não aparece no registro.
Fontes, confiança e incerteza
A parte madura da aula é mostrar que nem toda afirmação tem o mesmo peso.
OpenAI Codex changelog/docs
TipoOficial
Uso na aulaversão, GA/default, goals, hooks
Pesoalto
Technical teardown
TipoSecundária técnica
Uso na aulaarquitetura comparada e falhas
Pesomédio/alto
Benchmarks comunitários
TipoIndependente
Uso na auladireção de consumo de tokens
Pesomédio
Relatos de runs longas
TipoFirsthand
Uso na aulaexemplos reais, não garantia universal
Pesomédio
Posts soltos
TipoComunidade
Uso na aulapadrões e nomes
Pesobaixo/médio
Não ensinar assim
- Codex sempre é mais barato.
- Claude é pior para goal.
- O avaliador do Codex funciona igual ao do Claude.
- Plan Mode é igual nas duas ferramentas.
Ensinar assim
- Em benchmarks comparáveis, Codex consumiu menos tokens.
- Claude tem vantagem clara em planejamento read-only.
- Codex não expõe modelo avaliador separado nas fontes públicas.
- A decisão depende de duração, risco, custo e necessidade de análise sem edição.
/goal vs Ralph Loop
A diferença prática é simples: /goal é o modo nativo com avaliação entre turnos; Ralph Loop é o padrão manual de executar, verificar, criticar e repetir.
/goal
Você define uma condição de conclusão verificável. A ferramenta continua entre turnos até a condição aparecer como evidência suficiente.
Ralph Loop
Você monta manualmente o ciclo: agente trabalha, verifica contra o goal, critica a própria saída e roda outra iteração.
O que eles têm em comum
Os dois tentam resolver o mesmo problema: manter a IA trabalhando até existir prova de conclusão.
O que mudou
/goal transformou um padrão manual da comunidade em interface nativa, com pause, resume, clear e estado visível.
Onde mora o risco
Sem stop rules, turn limit e evidência objetiva, qualquer loop vira consumo de token com aparência de progresso.
Facilidade
/goal nativoQuem monta o ciclo?
Ralph Loop manuala ferramenta cuida do próximo turno
Leitura AIOXvocê cria prompt/script/hook
Parada
/goal nativoQuem decide o fim?
Ralph Loop manualavaliador checa condição
Leitura AIOXscript, prompt ou humano decide
Controle
/goal nativoQuem controla cada iteração?
Ralph Loop manualmenos controle fino
Leitura AIOXmais customizável
Custo
/goal nativoComo evita loop infinito?
Ralph Loop manualcondição + limite de turnos/tempo
Leitura AIOXprecisa guardrail próprio
Uso ideal
/goal nativoQuando escolher?
Ralph Loop manual90% das tarefas longas com DoD claro
Leitura AIOXexperimentos, multi-agente ou controle avançado
Use /goal quando
- Existe DONE WHEN claro.
- O agente pode provar conclusão no transcript.
- Você quer autonomia sem babysitting.
- A tarefa é longa, mas tem validator ou evidência objetiva.
Use Ralph Loop quando
- Você precisa controlar a crítica a cada ciclo.
- Há vários agentes ou ferramentas alternando.
- O loop precisa de script, ledger ou heurística própria.
- Você está testando uma metodologia nova.
Regra de decisãoPara AIOX Courses, comece com /goal + SPEC/AGENTS/Rider. Só use Ralph Loop quando o controle adicional justificar o risco extra.
O padrão híbrido: pro model cria o goal
O fluxo mais forte não começa rodando o goal. Começa pedindo a um modelo mais forte para escrever o contrato certo.
Goal engineering loop
1
Analisar
Modelo forte lê sessão, repo, SPEC e intenção.
2
Forjar
Ele escreve /goal, constraints, done-when, verify e stop rules.
3
Rodar
Codex ou Claude executa o goal com arquivos persistentes.
4
Criticar
Outro olhar revisa output, riscos e evidência.
5
Iterar
Se a crítica é objetiva, volta para o loop.
Híbrido para AIOX Courses
Use quando a tarefa é grande demais para confiar no primeiro goal escrito à mão.
criar SPEC→forjar /goal→executar→review adversarial→corrigirSPEC.md— Define aula, módulo, objetivos, entregáveis e critérios.Goal forge— Modelo forte converte SPEC + contexto em /goal curto e rider claro.Execução— Agente roda em loop até validators e DoD passarem.Review— Segundo agente ou humano revisa didática, visual, técnica e risco.Fechamento— Só encerra com prova, não com relato otimista.
Três exemplos que o aluno consegue copiar
A ideia fica mais fácil quando vira caso real, com frase fraca, frase forte e evidência esperada.
Caso 1: testes de autenticação
Quando o escopo é pequeno, o goal precisa proteger arquivos fora do alvo.
Começou comoArruma os testes de auth.
VirouFaça todos os testes em `test/auth` passarem sem modificar outros arquivos de teste. Pare após 20 ciclos ou reporte bloqueio.
ProvaEvidência: comando de teste passando, arquivos alterados listados e nenhum teste fora do escopo modificado.
LiçãoScope constraint evita uma correção que passa por quebrar outro lugar.
- Evidência: comando de teste passando, arquivos alterados listados e nenhum teste fora do escopo modificado.
- Scope constraint evita uma correção que passa por quebrar outro lugar.
Caso 2: issues de qualidade
Quando há muitos problemas parecidos, agrupe por classe de remediação.
Começou comoResolva todos os problemas do SonarQube.
VirouResolva os issues do SonarQube por classe, em blocos separados, com artefato final provando o que foi corrigido.
ProvaEvidência: relatório antes/depois, classes de issue, comandos executados e riscos remanescentes.
LiçãoAgrupar por classe impede que o agente trate 80 sintomas como 80 decisões diferentes.
- Evidência: relatório antes/depois, classes de issue, comandos executados e riscos remanescentes.
- Agrupar por classe impede que o agente trate 80 sintomas como 80 decisões diferentes.
Caso 3: módulo de curso
Quando a entrega é educacional, teste verde não basta.
Começou comoCrie um módulo sobre goals.
VirouImplemente o módulo conforme SPEC.md, com objetivos, exemplos, prática, portão, visual S2S+, validators e revisão didática.
ProvaEvidência: aula renderizada, quality score, rota 200, revisão visual e checklist pedagógico.
LiçãoCurso precisa de gate técnico e gate de aprendizagem.
- Evidência: aula renderizada, quality score, rota 200, revisão visual e checklist pedagógico.
- Curso precisa de gate técnico e gate de aprendizagem.
01Testes de autenticaçãoescopo pequeno, arquivos protegidos02Issues de qualidadeproblemas agrupados por classe03Módulo de cursogate técnico + gate de aprendizagem
Como ler os exemplos
O padrão é sempre converter intenção vaga em prova concreta.
Frase fraca
O que o aluno escreveria no impulso.
Frase forte
O mesmo pedido com escopo, critério e parada.
Evidência
O que precisa aparecer no final para acreditar.
Lição
A regra reutilizável para o próximo goal.
Exemplos verificados que viram padrão
Use para mostrar ao aluno a diferença entre frase curta e contrato suficiente.
migração→eval→teste/lint→coverageMigração— `/goal Finish the migration and keep tests green.` Curto, mas tem estado final: migração concluída e testes verdes.Eval— Melhorar prompt até accuracy 85% ou parar após 20 iterações. Tem métrica e freio.Teste/lint— Todos os testes em `test/auth` passam e lint está limpo. É o exemplo clássico de done-when binário.Coverage— Cobertura de `src/billing/` chega a 85% e lint passa. Número objetivo reduz interpretação.
Sequência operacional com AIOX
O aluno não precisa decorar nomes. Ele precisa entender quando cada skill entra.
Melhorar aulas em autonomia longa
Use quando o trabalho tem muitas aulas, design, dados estruturados e validação.
ler rider→diagnosticar aula→melhorar conteúdo→melhorar UI→validar→repetirAIOX:course-creator— Diagnostica didática, objetivos, exemplos, prática e Portão da aula.AIOX:aiox-ux-designer— Ajusta hierarquia, sidebar, hero, espaçamento e leitura.AIOX:design-system— Garante wrappers finos e uso de Brandbook antes de criar componente local.AIOX:visual-knowledge-chief— Converte conceitos abstratos em diagramas, matrizes e fluxos.AIOX:aiox-dev— Implementa YAML, TS, TSX e CSS local sem quebrar rotas.AIOX:aiox-qa— Roda typecheck, lint, quality:lessons, YAML changed e doctor.
Protocolo anti-loop antes de dormir
Use antes de qualquer /goal longo, caro ou com múltiplas aulas.
SPEC→scorecard→baseline→monitorar→controleSPEC/Rider— Coloque DoD, constraints, non-goals, skills e gates em arquivo persistente antes do goal.Scorecard— Defina threshold, regression check e o teste rápido que prova avanço em cada ciclo.Baseline— Rode os validadores principais antes para não culpar o goal por falha antiga.3-5 turns— Monitore as primeiras iterações. Se ele entendeu errado no começo, a autonomia só amplifica o erro.pause/resume/clear— Use `/goal pause` para congelar, `/goal resume` para continuar e `/goal clear` para matar um loop ruim.
SOP mínimo de um ciclo
Uma aula por ciclo, conteúdo antes do visual, validação antes de avançar.
Fase 1 · EscolherSelecionar a aula mais fraca ou mais quebrada.
Fase 2 · CompararMedir contra Método S2S: clareza, profundidade, visual, prática, prova.
Fase 3 · EditarMelhorar o menor conjunto de arquivos que resolve o gap.
Fase 4 · ValidarRodar gates e abrir rota quando houver mudança visual.
Fase 5 · RepetirSó passar para a próxima aula depois do portão fechar.
Segundo olhar antes de fechar
Use quando o avaliador automático pode passar algo tecnicamente correto, mas didaticamente fraco.
gerar→validar→revisar contra→corrigir→fecharAIOX:aiox-qa— Confere validadores e riscos técnicos.AIOX:course-creator— Confere clareza, objetivo, exemplo, prática e Portão da aula.AIOX:aiox-ux-designer— Confere se a aula está legível, com ritmo e sem ruído visual.Critério— Se o segundo olhar encontrar risco real, volta para o loop.
Como evitar goal death loop
Um goal seguro não depende de fé no agente. Ele tem freio, evidência e regra para parar quando o loop não aprende.
Não confundaDONE WHEN vago
Melhorar até ficar excelente.
Esclareça: Troque por critério verificável: arquivos, rotas, score, testes e revisão.
Não confundaContradição
Não mude nada, mas reformule tudo.
Esclareça: Priorize: o que pode mudar, o que não pode e quem vence em conflito.
Não confundaSem limite
Continue até terminar.
Esclareça: Use limite de turnos, tempo ou erro repetido para impedir queimar crédito.
Não confundaInput humano
Precisa de aprovação, credencial ou decisão externa.
Esclareça: O agente deve pedir uma vez e pausar, não repetir o mesmo pedido em loop.
Não confundaSub-agente quebrado
Um orquestrador continua chamando uma peça que falha.
Esclareça: Depois de 3 falhas iguais, pare e reporte o elo quebrado.
DoD
SinalNão existe prova objetiva
Freio corretoDONE WHEN + VERIFY
Sem freio viratrabalho infinito
Turnos
SinalO goal pode rodar sem fim
Freio correto25 turns ou 4h
Sem freio viracredit burn
Erro igual
SinalFalhou 3 vezes do mesmo jeito
Freio corretopausar e explicar bloqueio
Sem freio viratentativa cega
Permissão
SinalPrecisa de input do usuário
Freio corretoperguntar uma vez
Sem freio viraretry loop
Escopo
SinalQuer expandir requisitos
Freio corretonon-goals explícitos
Sem freio viradrift caro
Workflow seguro para AIOX Courses
Use quando for revisar uma aula ou módulo inteiro com /goal.
SPEC→goal→turnos iniciais→pausar se desviar→fechar com prova1. SPEC primeiro— Revise objetivo, deliverables, constraints, non-goals e acceptance criteria.2. Goal gerado por modelo forte— Peça para converter intenção em /goal com DONE WHEN, VERIFY e STOP RULES.3. Primeiras 3-5 turns— Observe se o agente entendeu o caminho. Se começou errado, pause cedo.4. Controle manual— `/goal pause` congela, `/goal resume` continua, `/goal clear` encerra.5. Prova final— O final precisa mostrar outputs de validação, arquivos alterados e riscos residuais.
01STOP RULES:02- Halt immediately after 25 turns maximum or 4 hours of wall time.03- If any condition is ambiguous or contradictory, report the exact conflict and pause.04- Never invent requirements or expand scope.05- If user input, credential or permission is needed, ask once and pause.06- If the same error repeats 3 times, stop and summarize what is blocked.07- Do not delete tests, shrink content or remove acceptance criteria just to pass validation.
Caso real: AIOX Courses
A diferença entre uma meta fraca e um goal operacional apareceu neste próprio app.
A meta inicial parecia correta: melhorar as aulas até ficarem superiores ao Método S2S. Mas isso ainda deixava espaço demais para progresso falso. O agente poderia melhorar uma aula, mexer em layout, rodar algum comando e parecer produtivo sem fechar o sistema inteiro. O rider transformou a intenção em contrato: quais aulas, qual régua, quais skills, quais gates, onde pode mexer e quando parar.
De desejo para contrato
A frase 'melhorar aulas' virou uma rotina verificável de melhoria aula por aula.
Começou comoMelhorar as aulas visualmente e didaticamente até ficarem melhores que Método S2S.
VirouRider com escopo, fontes de verdade, skills por fase, scorecard, validators e Definition of Done.
ProvaO arquivo `docs/goals/aiox-courses-s2s-rider.md` define o que fazer, como validar e quando parar.
LiçãoGoal bom não aumenta autonomia por coragem. Aumenta autonomia porque reduz ambiguidade.
SituaçãoHavia muitas aulas, várias rotas e risco de drift visual contra o Brandbook.
DecisãoSeparar goal curto de rider longo, mantendo a execução em ciclos pequenos.
EvidênciaO rider exige `quality:lessons`, typecheck, lint, YAML changed, doctor e inspeção visual quando necessário.
Mensagem ao alunoQuando a tarefa parece grande demais, não escreva um prompt maior. Escreva um contrato melhor.
ContextoAIOX Courses já tinha Método S2S como benchmark e várias aulas precisavam chegar nesse nível.
Percepção-chaveA comparação com S2S só funciona se virar scorecard e gates, não gosto pessoal.
DecisãoCriar o rider antes de criar novas aulas ou continuar melhorias.
1Meta fracaMelhorar até ficar muito bom.
2BenchmarkMétodo S2S como referência concreta.
3RiderEscopo, skills, fontes, gates e anti-drift.
4LoopAula por aula, validar, corrigir, repetir.
1rider canônico
8skills roteadas
5gates finais
Meta fraca
- Melhore as aulas até ficarem melhores.
- Use bom senso.
- Continue trabalhando.
- Me avise quando terminar.
Goal operacional
- Todas as aulas disponíveis passam na régua S2S.
- Siga rider com skills e fontes de verdade.
- Rode validators e corrija em loop.
- Pare só com Definition of Done satisfeita.
Armadilhas que parecem produtividade
O agente pode trabalhar muito e ainda assim não avançar no resultado.
Não confundaAutonomia
Deixar o agente decidir qualquer coisa.
Esclareça: Autonomia boa é liberdade dentro de contrato.
Não confundaLoop
Repetir comandos sem mudar a hipótese.
Esclareça: Loop bom diagnostica a falha antes de tentar de novo.
Não confundaValidação
Rodar um comando verde e ignorar a experiência.
Esclareça: Aula precisa passar em código, conteúdo e leitura visual.
Não confundaRider
Documento longo para parecer elaborado.
Esclareça: Rider bom reduz decisão futura e acelera execução.
Não confundaEvaluator
Modelo avaliador que nunca erra.
Esclareça: Evaluator ajuda no loop, mas curso ainda precisa de revisão humana ou adversarial.
Não confundaSet and forget
Ligar o goal e nunca mais olhar.
Esclareça: Funciona para gates objetivos; conteúdo educacional alto nível ainda pede inspeção final.
Não confundaBudget
Achar que a ferramenta sempre vai parar antes de gastar demais.
Esclareça: Não conte com cap de gasto nativo. Coloque limite de turnos, tempo e condição de bloqueio.
Não confundaTranscript
Achar que o avaliador vê o filesystem sozinho.
Esclareça: A evidência precisa aparecer na conversa: comando rodado, output mostrado, artefato citado.
Goal
PerguntaTem estado final?
SaudávelDoD explícita
Riscotrabalhar sem parar
Loop
PerguntaTem gate objetivo?
Saudávelfalhou → corrige → reroda
Riscotentativa aleatória
Rider
PerguntaTem fontes e skills?
Saudávelcontexto estável
Riscodrift de contexto
Fechamento
PerguntaTem evidência?
Saudávelvalidators + rota
Riscorelato sem prova
Custo
PerguntaTem limite de ciclos?
Saudávelstop rule ou budget
Riscocredit burn
Compaction
PerguntaO contexto crítico está no repo?
SaudávelSPEC/AGENTS/Rider
Riscomemória perdida no resumo
Baseline
PerguntaVocê sabe o estado inicial?
Saudávelteste/lint antes do goal
Riscoloop tentando consertar falha antiga
Escape hatch
PerguntaO agente pode burlar?
Saudávelnão reduzir contagem de testes/arquivos
Riscodeletar teste para passar
Permissão
PerguntaPrecisa de você?
Saudávelpergunta uma vez e pausa
Riscopede aprovação em loop
Erro repetido
PerguntaA mesma falha apareceu 3 vezes?
Saudávelpara e diagnostica
Riscogoal death loop
Prática: converta uma meta fraca em goal
Pegue uma tarefa que você pediria de forma vaga e converta em contrato de execução.
Template prático
Use antes de qualquer tarefa longa em Codex ou Claude Code.
Goal→Contexto→Skills→Gates→StopGoal— O resultado final é...Contexto— As fontes de verdade são...Skills— Use estas skills por fase...Gates— Está pronto quando estes validadores e inspeções passarem...Stop— Pare e peça ajuda somente se...
Prompt final para AIOX Courses
Use como base quando for abrir um goal real para melhorar cursos e aulas.
/goal→seguir rider→uma aula por ciclo→validar→reportar prova/goal— Levar as aulas disponíveis do AIOX Advanced ao padrão Método S2S+.Rider— Seguir `docs/goals/aiox-courses-s2s-rider.md` como contrato operacional.Skills— Usar course-creator para didática, UX para layout, design-system para componentes, QA para gates.Done when— Cada aula tem objetivos, exemplo real, visual, prática, Portão da aula, rota 200 e score aprovado.Verify— `quality:lessons`, typecheck, lint, YAML changed, doctor e inspeção visual quando houver mudança de UI.Stop— Parar por ambiguidade real, credencial, operação destrutiva, escopo proibido, input humano, limite de turns ou erro repetido 3 vezes.
Exemplo preenchido: meta fraca virando contrato
Meta fracaMelhore as aulas do AIOX Advanced.
GoalTodas as aulas disponíveis passam pela régua S2S+: objetivo claro, exemplo real, prática, portão da aula e rota 200.
ContextoUsar content.yaml como fonte de verdade, preservar voz Alan e comparar com Método S2S.
GatesSchema zod, typecheck, qualidade de lição, renderização 200 e inspeção visual quando houver bloco novo.
StopPausar por ambiguidade real, credencial, operação destrutiva, escopo proibido ou erro repetido.
Portão da aulaVocê entendeu Goal vs Loop quando consegue escrever um goal que não depende de confiança no agente, e sim de prova: escopo, SPEC/AGENTS/Rider, skills, gates, stop rules e Definition of Done.
- Escreva a versão fraca da meta em uma frase, sem tentar embelezar.
- Defina o estado final verificável: o que precisa existir para dizer que terminou?
- Liste fontes de verdade, arquivos, skills e restrições.
- Escolha os gates: quais comandos, inspeções ou provas precisam passar?
- Decida se precisa de SPEC.md, AGENTS.md, rider.md ou só prompt com checklist.
- Escreva o stop condition: quando parar, quando pedir ajuda e qual limite de ciclos usar.
- Defina controle manual: quando usar `/goal pause`, `/goal resume` e `/goal clear`.
Funcionou se
- Você separou destino (goal) de motor (loop).
- Você escreveu pelo menos três gates objetivos.
- Você escolheu skills por fase, não como enfeite.
- Você decidiu que memória precisa ir para SPEC, AGENTS ou Rider.
- Você definiu quando parar.
Recap
A autonomia fica segura quando o agente não precisa adivinhar o que é bom.
Goal
Destino verificável. Define o que precisa existir no final.
Loop
Motor de repetição. Executa, valida, corrige e tenta de novo.
Rider
Contrato de condução. Carrega contexto, skills, fontes, gates e anti-drift.
SPEC.md
Documento que descreve o módulo, entregáveis e critérios de aceite.
AGENTS.md
Documento de regras permanentes para manter consistência entre sessões e ferramentas.
Evaluator
Modelo ou gate que verifica se o transcript provou a Definition of Done.
Stop rule
Regra que impede loop infinito, custo sem controle ou decisão fora do escopo.
Ralph Loop
Padrão manual de autoavaliação: trabalhar, verificar, criticar e repetir até o goal ser atingido.
Hyper loop
Fluxo híbrido em que um modelo forte escreve o goal, outro executa e outro revisa criticamente.
Gate
Prova de passagem. Sem gate, o agente só relata progresso.
A regra simplesPrompt simples para tarefa simples. Loop para tarefa com gate. /goal + rider para trabalho longo com risco de drift.
Bloco de código: um /goal com rider e stop rule
A anatomia de um goal verificável, para o aluno converter meta fraca em contrato.
01# Goal fraco (o agente relata progresso mas nunca termina):02/goal "melhorar as aulas"0304# Antes do goal, se ainda houver incerteza:05/plan "Leia a aula, o rider e os materiais de pesquisa.06Proponha acceptance criteria maquina-checaveis e gaps humanos.07Nao edite arquivos ainda."0809# Goal contrato (Definition of Done + gate + stop rule):10/goal "Levar todas as aulas disponiveis ao padrao S2S+.11DoD maquina-checavel:12- quality:lessons PASS13- typecheck PASS14- lint sem erro15- YAML changed PASS16- doctor sem erro bloqueante17Constraints:18- nao criar componente local se o brandbook ja tiver equivalente19- nao reduzir profundidade didatica para passar score20Stop rules:21- pare apos 25 turnos22- pare se precisar de credencial ou operacao destrutiva23- se precisar de input humano, pergunte uma vez e pause24- se o mesmo erro repetir 3 vezes, reporte bloqueio e evidencias25- nunca delete testes, reduza conteudo ou remova criterio para passar validacao."