O Forge começa com uma meta — mas um desejo não é uma meta. O ultragoal é a disciplina por trás do passo /goal: ele transforma uma intenção difusa num contrato que o loop consegue de fato perseguir e que o mundo consegue de fato checar. Uma boa meta tem três partes e só três: uma linha de chegada observável, um verificador que pode FALHAR na fronteira real (o Proof Gate), e contexto durável suficiente para se recuperar depois de uma interrupção. Esta lição te ensina a desenhar esse contrato, a fazer red-team nele antes de ligá-lo, e a mantê-lo agnóstico de agente — a ativação universal é um GOAL.md durável rodando sob o loop em qualquer CLI e qualquer modelo. Uma API de meta nativa é açúcar opcional, nunca um requisito.
"Deixar o relatório noturno melhor" é um desejo. Ninguém consegue dizer quando ele está terminado, e ninguém consegue provar que algum dia esteve. Uma meta é o oposto: ela diz exatamente como é o "pronto", carrega um teste que pode voltar vermelho, e registra o suficiente para que, se a execução for interrompida às 3 da manhã, ela consiga se retomar de manhã.
Nosso exemplo recorrente para a lição inteira é um objetivo real: o digest noturno do RHG precisa chegar à caixa de entrada de cada assinante até as 07:00 com zero links quebrados. Veja como esse desejo vira um contrato que você poderia entregar a qualquer agente e ir embora.
Por que isso importa tanto? Porque o loop que você aprendeu no Módulo 2 — LEARN → ANALYZE → EXECUTE uma unidade → VERIFY na fronteira real → DECIDE — só converge se houver uma coisa fixa para convergir. A meta é essa coisa fixa. Se a linha de chegada puder derivar, ou o teste puder ser silenciosamente enfraquecido, o loop vai rodar feliz para sempre e declarar vitória sobre nada. O ultragoal é como você faz a linha de chegada ficar parada e o teste continuar honesto.
Pense nisso como… um contrato de obra em vez de "me faça uma casa bonita." O contrato declara o endereço, o número de cômodos, a data e — crucialmente — a vistoria que o construtor precisa passar antes de receber. Um desejo deixa o construtor se declarar pronto. Um contrato deixa um fiscal dizer "ainda não." O ultragoal escreve o contrato e contrata o fiscal. Onde a analogia quebra: aqui o fiscal precisa ser alguém diferente do construtor, e a vistoria roda na fronteira real — a caixa de entrada de verdade às 07:00, não a palavra do construtor de que funciona.
Uma tarefa é de uma vez só: faça, está pronto, você segue em frente. Uma meta é durável: ela persiste entre tentativas, esperas, recuperações e ciclos longos de feedback, e seu sucesso é estabelecido por um sinal externo em vez do auto-relato do agente. O ultragoal é o front-end de definição de metas do loop-engineering: o ultragoal define e ativa; o loop persegue. Mesma espinha do Proof Gate, nunca uma alegação ou um mock.
Uma boa meta = uma linha de chegada observável + um verificador que pode falhar + contexto durável para recuperar. Todo o resto desta lição é uma elaboração dessas três cláusulas. Se um rascunho está faltando qualquer uma delas, ainda não é uma meta — é um desejo vestido de meta.
A disciplina é adaptada, com permissão, de jxnl/dots → agents/skills/ultragoal e reescrita para este harness: ativação agnóstica de agente, integrada ao loop do loop-engineering (Proof Gate, o GOAL.md do Forge, o time Orquestrador/Executor/Validador da lição 9).
Antes de qualquer ferramenta, mantenha a forma na cabeça. Uma meta é feita de um pequeno número de partes nomeadas que se encaixam. As três que sustentam estão circuladas abaixo; o resto as apoia.
Nem todo trabalho merece a maquinaria completa de meta. A primeira decisão que o ultragoal toma é o encaixe: isto deve ser uma meta durável, ou uma tarefa comum? Use o modo-meta só quando a maioria destes valer — o progresso exige tentativas repetidas, espera ou recuperação; o sucesso é mensurável numa fronteira real; o agente consegue reagir à próxima falha sem te perguntar; e a evidência de conclusão é mais forte do que o agente dizer "pronto". Se o trabalho é de uma vez só, dependente de gosto, bloqueado em escolhas humanas repetidas, ou não tem verificador crível — é uma tarefa, não uma meta.
Abaixo: cada candidato do mundo RHG é julgado pelos mesmos eixos. Troque a lente para comparar as linhas, depois leia os cartões por candidato para o veredito e a razão.
| candidato \ eixo | repetido / espera? | verificável numa fronteira? | recupera sem você? |
|---|---|---|---|
| digest noturno até as 07:00 | Sim — roda toda noite, pode falhar e repetir | Sim — busca a caixa de entrada, varre os links | Sim — um envio falho apenas roda de novo |
| escolher a nova cor da marca | Não — decidido uma vez | Não — é gosto, não um teste | Não — precisa do seu julgamento |
| migrar o verificador de links para v2 | Sim — iterar até os testes passarem | Sim — a suíte de testes é o gate | Sim — as falhas apontam o próximo conserto |
| aprovar o aviso legal | Não — uma única aprovação | Não — só um humano pode dizer "aprovado" | Não — bloqueado numa pessoa |
candidato · digest noturno
✓ faça disso uma metaDigest em cada caixa de entrada até as 07:00, zero links quebrados. Repete toda noite, falha de forma barulhenta, e um agente diferente pode buscar a caixa de entrada para provar.
Encaixa nos quatro eixos → meta durável.
candidato · cor da marca
→ mantenha como tarefaEscolher a nova cor de destaque. Decidido uma vez, por gosto. Não há fronteira que possa dizer "esta cor está correta."
Sem verificador, dependente de gosto → tarefa comum.
candidato · verificador de links v2
✓ faça disso uma metaMigrar para o verificador de links v2 com a suíte verde. Muitas iterações, cada falha mostra o próximo conserto, a suíte de testes é a fronteira.
Repetido + verificável + auto-recuperável → meta.
candidato · aprovação legal
→ mantenha como tarefaAprovar o novo aviso. Uma decisão humana. O agente não consegue tomá-la, e nada que ele produz prova a aprovação.
Bloqueado numa pessoa → tarefa comum.
O progresso exige tentativas repetidas, espera, recuperação ou feedback longo; o sucesso é mensurável por um teste, benchmark, workflow, inspeção de artefato, captura de tela ou leitura de volta numa fronteira real; o agente consegue responder à próxima falha sem outra decisão de preferência; e a evidência de conclusão é mais forte do que o agente dizer "pronto."
O trabalho é de uma vez só, dependente de gosto, bloqueado em escolhas humanas repetidas, sem verificador crível, ou arrisca ação externa ilimitada. A cor da marca e a aprovação legal falham nos eixos do verificador e da dependência humana — envolvê-las em maquinaria de meta só adicionaria cerimônia, não segurança. O encaixe é o gate antes de tudo: erre-o e uma "meta" lindamente especificada ainda não pode ser perseguida de forma autônoma.
O ultragoal roda em um de três modos, e a diferença é principalmente sobre até onde ele vai. Desenhar pesquisa e devolve um pacote de meta — e para; nada é ligado. Criticar pega uma meta que alguém já rascunhou e a afia — apertando o verificador, fechando os caminhos de trapaça. Ativar faz desenhar + criticar e então, como passo final, escreve o contrato e inicia o loop. A regra de ouro: você só ativa quando o humano pede explicitamente para começar, definir ou rodar uma meta — nunca a partir de conversa de planejamento vaga.
Quando o usuário invoca explicitamente o ultragoal para um objetivo de trabalho concreto e pede para construir, completar, rodar, perseguir ou "faça isso", trate como Ativar por padrão — não pare depois de escrever estado durável ou reportar um pacote. Após aterrissar e (quando útil) escrever o GOAL.md, ative e então continue sob a Disciplina de Meta Ativa. Permaneça em Desenhar só quando o usuário pedir para rascunhar, desenhar, criticar ou discutir uma meta sem iniciá-la.
Só quando o usuário autoriza explicitamente subagentes lastreados por meta. Cada filho ganha um objetivo delimitado e um verificador — a mesma disciplina Orquestrador/Executor/Validador da lição 9, onde o Validador nunca é o agente que construiu a coisa. Nunca crie metas-filhas por iniciativa própria.
Desenhar uma meta significa preencher oito lacunas específicas. Pule uma e o loop tem um buraco por onde cair. Aqui estão elas, cada uma em uma linha simples, depois desenhadas como o ciclo que formam.
Uma meta que roda por muitas noites é, na verdade, uma sequência de fases, cada uma com uma meta, as tarefas dentro dela, os riscos e — a parte que mais importa — uma barra de saída que ela precisa cruzar antes da próxima fase começar. Essa barra de saída é só o verificador aplicado naquele passo. Clique numa fase abaixo para abrir seu cartão; a barra no topo é o mapa. Esta é a meta do digest noturno do RHG, dividida nas fases que o ultragoal escreveria de fato.
Meta: medir o ponto de partida real antes de mudar qualquer coisa, para que "melhor" tenha um número a superar.
Meta: escrever o Proof Gate antes do conserto, para que o sucesso nunca possa ser autodeclarado. O verificador precisa ser capaz de falhar no digest real de hoje à noite.
href no corpo; afirmar 0 respostas não-200Meta: mudar o pipeline até o verificador ficar verde — uma mudança significativa por loop, cada uma medida.
Meta: exigir a prova de conclusão — noites limpas consecutivas o bastante para descartar sorte — e escrever o registro durável para que uma execução futura consiga recuperar.
RESULT.md: a mudança, a evidência de fronteira, riscos residuaisA fase 2 constrói o Proof Gate antes de a fase 3 tocar o pipeline. Esta ordem é deliberada: se você conserta primeiro e verifica depois, vai ser tentado a escrever um verificador que por acaso passa no conserto que você já fez — um verificador que nunca viu vermelho. Exigir uma execução vermelha num fixture sabidamente ruim é o seguro mais barato contra uma checagem que só carimba. Um critério de saída é um gate mensurável, não um sentimento: "o digest parece bom" não é um gate; "uma busca IMAP independente às 07:00 encontrou o digest com zero links não-200" é.
Aqui está a única ideia que o resto da lição protege. Um verificador só vale alguma coisa se houver uma entrada real que o faça voltar vermelho. Uma checagem que retorna verde não importa o quê não é um verificador — é uma decoração. O truque que a maioria das fraudes compartilha é que elas nunca tocam a fronteira real: perguntam ao agente "você enviou?" em vez de perguntar à caixa de entrada "isso chegou?"
Compare os dois abaixo. À esquerda, uma checagem oca que só consegue dizer "sim". À direita, um Proof Gate que alcança a caixa de entrada real e consegue dizer "não".
Hora de conduzir você mesmo. O painel à esquerda deixa você construir um verificador para a meta do digest RHG — escolha onde ele checa, se pode falhar num fixture ruim, e se o agente avalia o próprio trabalho. O painel à direita monta esse verificador e então renderiza o veredito que importa: uma execução preguiçosa ou adversária conseguiria fingir o "pronto" passando por esta checagem? Tente construir um verificador que parece verde mas é, na verdade, fraudável, depois conserte-o.
—
—
Um verificador se torna fraudável no momento em que qualquer um destes é verdadeiro: (1) ele checa uma alegação ou um mock em vez da fronteira real, então a palavra do agente é a evidência; (2) ele nunca viu vermelho, então um resultado verde não significa nada; (3) o construtor avalia a si mesmo, então o viés rumo ao "pronto" fica sem controle; ou (4) a execução pode estreitar escopo ou mover o benchmark sem aprovação, então o "pronto" pode ser redefinido para baixo até ser trivialmente verdadeiro. O painel direito fica vermelho no instante em que qualquer um destes vale — porque, numa execução real, qualquer um deles basta para fingir a conclusão.
Um verificador que passa precisa significar o resultado real: não enfraqueça testes, não estreite escopo, não esconda falhas, não troque por mocks, nem mova o benchmark sem aprovação. O ajustador é um brinquedo, mas a lógica do veredito é exatamente o red-team que você roda em toda meta real antes de ativá-la.
Sob pressão de prazo, um agente (ou uma pessoa) vai buscar a vitória fácil: fazer o teste passar sem tornar a coisa verdadeira. O ultragoal nomeia as cinco jogadas que fazem isso e proíbe todas elas sem aprovação humana explícita. Memorize a lista — é a mesma lista, seja fazendo red-team na sua própria meta ou revisando a de outra pessoa.
Digamos que o envio continua caindo às 07:02. O conserto preguiçoso é editar a asserção do verificador de ts <= 07:00 para ts <= 07:05. O digest agora "passa" — mas o resultado real (em cada caixa de entrada até as 07:00) não é mais o que está sendo provado. A regra anti-trapaça pega isso porque mover o benchmark exige aprovação: o loop precisa trazer a mudança proposta ao humano, não enfiá-la sorrateiramente. A mesma lógica proíbe "estreitar escopo" (provar só para uma conta de teste) e "trocar por um mock" (afirmar contra uma caixa de entrada falsa que sempre tem o digest).
Uma meta que vive só na cabeça de um agente morre no momento em que aquele turno termina. A terceira parte que sustenta uma boa meta é o contexto durável: o suficiente registrado para que uma nova execução — amanhã de manhã, um modelo diferente, depois de um crash — consiga ler os arquivos e retomar do zero. A convenção do loop-engineering usa três arquivos, cada um com uma função clara.
Mantenha o objetivo ativo no GOAL.md curto; quando o contexto de apoio crescer, coloque-o no arquivo durável mais próximo. Prefira as convenções existentes do projeto a inventar arquivos novos. Não crie arquivos no modo Desenhar a menos que peçam, e sempre leia os arquivos de meta existentes antes de editar — preserve trabalho em andamento, nunca atropele um WORKLOG pela metade. Um estado parcial ou intermediário registrado honestamente no WORKLOG.md é carry-over válido; nunca é um "pronto" finalizado.
Esta é a parte que as pessoas mais erram, então vale dizer com clareza. O ultragoal não está atrelado a um agente. A forma universal de ativar uma meta é escrever um GOAL.md durável e rodá-lo sob o loop — e isso funciona em qualquer CLI (claude, codex, kimi, grok, gemini, opencode, …) e qualquer modelo, sem ferramentas especiais exigidas. Alguns agentes também expõem uma API de meta nativa — o create_goal / update_goal do Codex é um exemplo — que você pode chamar como passo de ativação quando ela existe. É açúcar opcional sobre a mesma disciplina do GOAL.md, nunca um requisito. "Ativar" sempre significa: escrever/commitar o GOAL.md e entrar no loop, mais chamar a API nativa só se o agente por acaso tiver uma.
GOAL.md durável rodado sob o loop. A API de meta nativa (tracejada) é um caminho opcional que alguns agentes adicionam por cima — nunca o que faz funcionar.create_goal do Codex para definir uma meta" — esse é o equívoco que esta seção existe para matar. O contrato é o GOAL.md + o loop. A API é açúcar.A ativação é a ação final, e há um gate na frente dela: o red-team. Antes de qualquer meta entrar no ar você faz uma curta série de perguntas difíceis, e o primeiro "não" te manda de volta a redesenhar — você não ativa uma meta que não conseguiria defender. Escolha um rascunho abaixo, depois pressione Próximo para conduzi-lo pelo gate uma pergunta por vez. Veja onde um rascunho fraco se desvia para de volta ao desenho e um defensável chega ao ativar.
Comece aqui
Um rascunho de meta chega ao gate
Pressione Próximo para fazer red-team na meta defensável pergunta por pergunta. Troque o rascunho acima para ver um fraco ser devolvido.
O checklist completo que o ultragoal roda antes de cruzar a linha de ativação: (1) O sucesso pode ser fingido enfraquecendo o verificador? (2) As palavras poderiam ser satisfeitas enquanto se erra o resultado real do usuário? (3) Os gates de aprovação são explícitos? (4) O loop diz o que fazer após uma tentativa falha ou uma espera? E a que este fluxo encerra: a conclusão é observável fora do agente em execução? Um "não" na observabilidade é fatal — se só o agente consegue ver que está pronto, "pronto" é apenas uma alegação. Sobreviva a todas elas e só então escreva/commite o GOAL.md e entre no loop (mais a API nativa, se houver).
Uma vez que a meta está ativa, você não conduz — você observa (exatamente o papel do humano da lição 9). A leitura abaixo é como o estado durável da meta fica renderizado como um painel. Alterne entre os três estados honestos em que uma meta pode estar — ativa, bloqueada e pronta — e veja os números e a pílula de status mudarem. Note que "bloqueada" é um estado real e nomeado, não uma falha para esconder.
digest noturno RHG — estado da meta
fonte · WORKLOG.md (última execução do verificador)
Ativa: o verificador rodou às 07:00, encontrou o digest mas com um timestamp 2 minutos atrasado, e reportou vermelho. O loop vai mudar uma coisa hoje à noite e rodar de novo. Você não fez nada — e nada precisou de você.
Ativa significa que resta um próximo passo seguro e relevante — o loop continua. Bloqueada só é legítima depois que o limiar de bloqueio externo repetido é atingido e não resta progresso significativo, com a menor próxima ação registrada; dificuldade ou incerteza sozinhas nunca são "bloqueada." Pronta é marcada só depois que o objetivo e a prova de conclusão são satisfeitos na fronteira real — aqui, três noites limpas consecutivas com evidência arquivada. Não existe "provavelmente pronta" — um estado parcial permanece Ativa com sua próxima ação registrada.
A coisa mais honesta que uma meta pode fazer, sem chegar a terminar, é parar e dizer exatamente por quê — na fronteira real, com evidência, e com a menor próxima ação. Abaixo está a meta do digest RHG escrita do jeito que uma execução bloqueada deveria reportar: um cabeçalho, uma linha do tempo do que o verificador de fato viu, um cinco-porquês até a causa real, a prova de que é um bloqueio externo genuíno, e um checklist do que a desbloquearia. É assim que "bloqueada" parece quando é um estado, não uma desculpa.
O que o verificador viu, em ordem. Oliva é rotina, terracota é um aviso, vermelho é a parede em que bateu, verde é o único conserto que ainda poderia fazer.
O verificador inicia no horário
O Proof Gate acorda para buscar a caixa de entrada de um assinante real e varrer os links do digest.
rotinaLogin IMAP recusado
A senha da caixa de correio que o verificador usa retorna AUTHENTICATIONFAILED. Foi rotacionada pela TI ontem à noite.
Não consegue provar o resultado na fronteira
Sem acesso à caixa de entrada, o verificador não consegue confirmar que o digest chegou. Ele se recusa a reportar verde numa checagem que não pôde rodar.
bloqueadaMenor próxima ação registrada
WORKLOG: "Bloqueio externo — credencial IMAP rotacionada. Próxima ação: um humano reconcede o segredo da caixa de correio; depois rodar o verificador de novo." Nenhum escopo foi estreitado, nenhum verde foi fingido.
próxima açãoCinco porquês, até a causa real — e por que isto é um bloqueio de verdade, não só dificuldade.
Por que a meta não está pronta?
O verificador não conseguiu confirmar que o digest chegou.
Por que não conseguiu confirmar?
Ele não conseguiu fazer login na caixa de entrada para olhar.
Por que não conseguiu fazer login?
A credencial da caixa de correio retorna AUTHENTICATIONFAILED.
Por que a credencial falha?
A TI rotacionou o segredo durante a noite e o novo valor nunca foi compartilhado com a execução.
Raiz · por que isto é um bloqueio real
Só um humano com acesso ao cofre pode reconceder o segredo rotacionado — o agente não consegue se autoatender, e não há próximo passo seguro que faça progresso sem ele. Essa é a régua para "bloqueada": uma dependência externa mais nenhum trabalho significativo restante. O loop fez a coisa honesta — não enfraqueceu a checagem para uma fraudável só para mostrar verde.
O que a desbloqueia. Marque os itens conforme acontecem — a barra acompanha o progresso. P1 é o passo só-humano que o loop está corretamente aguardando.
A alternativa barata e perigosa era o verificador "passar" porque a função de envio rodou — sem nunca checar a caixa de entrada. Isso teria marcado a meta como pronta enquanto os assinantes não receberam nada. Bloquear com evidência é estritamente mais seguro: traz à tona um próximo passo preciso e acionável por humano (reconceder o segredo) e mantém o contrato intacto. É também onde um gate de aprovação e o papel de observabilidade do humano se encontram — o loop pausa numa bifurcação genuinamente só-usuário (acesso ao cofre) e espera, exatamente como a lição 9 descreveu, em vez de adivinhar ou fingir.
Nada disto precisa de ferramenta especial. A meta inteira é um arquivo de texto puro que qualquer agente consegue ler. Aqui está a meta do digest RHG escrita como o contrato durável — as oito partes da seção 5, na ordem em que o ultragoal as escreve. Este é o arquivo que você commitaria e do qual então iria embora.
# GOAL — RHG nightly digest outcome: "The RHG digest lands in every subscriber inbox by 07:00, zero broken links." baseline: "Last week: median send 07:38; 2.1 dead links/issue." verifier: # the Proof Gate — runs at the REAL boundary, can FAIL - fetch a live subscriber inbox via IMAP at 07:00 - assert digest present AND timestamp <= 07:00 - crawl every href in the body; assert 0 non-200 responses - MUST have failed once on a known-bad fixture (seen red) - run by a DIFFERENT agent than the one that edits the pipeline supporting: [ unsubscribe link works, image alt-text intact ] anti_cheating: "No weakening tests, narrowing scope, hiding failures," "mocking the inbox, or moving 07:00 — without human approval." approval_gates: [ rotating prod secrets, emailing all subscribers a test ] blocker_standard: "external dependency + smallest next action; doubt != blocked" completion_proof: "3 consecutive clean nights, evidence archived in WORKLOG.md"
A disciplina completa do ultragoal vive na skill. Para ler o workflow, a regra de encaixe de meta, a cláusula anti-trapaça e o checklist do red-team:
# the ultragoal workflow, modes, and red-team checklist cat ~/.claude/skills/ultragoal/SKILL.md # where it ties into the loop + the Forge GOAL.md contract grep -rn "Proof Gate\|GOAL.md\|anti-cheating\|red-team\|Validator" \ ~/.claude/skills/ultragoal/ ~/.claude/skills/loop-engineering/
Os três invariantes que o contrato impõe: (1) o verificador roda na fronteira real e já foi visto falhar; (2) "pronto" exige a prova de conclusão, não uma alegação; (3) o caminho de ativação é GOAL.md + o loop em qualquer CLI — uma API de meta nativa é opcional. Note que não há campo que nomeie um modelo ou agente específico: o contrato é deliberadamente portátil.
Amarre tudo com a meta do digest RHG, do início ao fim. Veja onde a disciplina age e onde você não age.
GOAL.md e entra no loop — em qualquer CLI que esteja rodando, sem API nativa exigida. O Validador é um agente diferente de quem edita o pipeline.RESULT.md registra a mudança, a evidência de fronteira e os riscos residuais.Conte suas ações: uma — reconceder um segredo rotacionado atrás de um gate de aprovação. Todo o resto a meta fez sozinha, e todo "pronto" foi provado na caixa de entrada real, nunca alegado.
# WORKLOG.md — RHG digest n1 07:00 verify RED digest present, ts=07:02 (> 07:00) · evidence: imap+crawl ok n1 07:05 change move render step earlier (one change) · re-run queued n1 07:55 verify GREEN ts=06:57, 0 broken links · 1/3 clean nights n2 07:00 verify BLOCKED IMAP AUTHENTICATIONFAILED (rotated) · next: human re-grants secret n2 09:30 human approval-gate: mailbox secret re-granted n3 07:00 verify GREEN ts=06:58, 0 broken · 2/3 n4 07:00 verify GREEN ts=06:59, 0 broken · 3/3 → completion proof met n4 07:01 done RESULT.md written · verifier left running as nightly guard
Note que toda linha verify é um resultado de fronteira real (uma busca de fato na caixa de entrada), a única linha humana fica atrás de um gate de aprovação, e "done" aparece só depois de 3/3 — nunca numa única noite de sorte. O nome do agente é irrelevante para o rastro; o que é fixo é o contrato.
Quatro perguntas rápidas. Escolha uma resposta em cada — ela corrige ao clicar e te diz por quê.
Quais são as três partes que sustentam uma boa meta?
Como distinguir um verificador real de uma decoração?
Em qualquer CLI, qual é a forma universal de ativar uma meta?
O envio continua caindo às 07:02. Qual jogada é permitida?
GOAL.md com um verificador que pode falhar, ou para mostrar como isto ativa numa CLI que você usa (Codex, Kimi, Grok — o contrato é o mesmo). A seguir: o Bright Data CLI — como o loop obtém evidência real da web em vez de adivinhar, toda vez.