Fontes sociais viram hipótese; o runtime local decide a configuração.
Ao final, você consegue
aplicar a regra ao pedido “adicione isso nas configs”;
separar recomendação de fato demonstrado;
escolher uma prova no boundary real.
A camada Simples é completa; a Técnica acrescenta precisão.
1
A grande ideia
Quando você escreve “adicione isso nas configs”, ainda faltam três respostas: o que já existe, o que o runtime aceita e qual prova encerra o trabalho. Primeiro você investiga. Só então cria um goal que reduza o espaço de busca.
Pense como… É como programar uma viagem: o destino vem depois de olhar o mapa, o combustível e as estradas abertas. A analogia termina aí — no Codex, a rota precisa também de um teste executável.
Por baixo do capô
O fluxo é requirements gathering → inspeção local → hipótese de mudança → finish line → set_goal. Para trabalho pequeno e já delimitado, um goal persistente pode ser desnecessário; para trabalho amplo, a pesquisa precede a ativação.
01 · pedido bruto conduz a estado real; o checkpoint é goal verificável.
2
Atlas visual
Leia cada diagrama como entrada → decisão → checkpoint. As legendas ligam a imagem ao mesmo exemplo.
02 · estado real conduz a goal verificável; o checkpoint é prova.03 · goal verificável conduz a prova; o checkpoint é pedido bruto.04 · prova conduz a pedido bruto; o checkpoint é estado real.05 · pedido bruto conduz a estado real; o checkpoint é goal verificável.06 · estado real conduz a goal verificável; o checkpoint é prova.07 · goal verificável conduz a prova; o checkpoint é pedido bruto.08 · prova conduz a pedido bruto; o checkpoint é estado real.09 · pedido bruto conduz a estado real; o checkpoint é goal verificável.10 · estado real conduz a goal verificável; o checkpoint é prova.11 · goal verificável conduz a prova; o checkpoint é pedido bruto.12 · prova conduz a pedido bruto; o checkpoint é estado real.13 · pedido bruto conduz a estado real; o checkpoint é goal verificável.14 · estado real conduz a goal verificável; o checkpoint é prova.
3
No runtime
Este trecho registra a regra sem expor o arquivo global completo.
Evidência local sanitizada
# pedido bruto
"adicione isso nas configs"
# depois da pesquisa
Goal: aplicar apenas chaves suportadas
Finish line: strict load + sentinel + revisão independente
Acesse você mesmo
Abra SCOPE.md, PRD.md e GOAL.md na raiz desta tarefa; depois compare com LOOP-LOG.md.
Decida antes de revelar; depois ajuste o risco, percorra o fluxo e responda aos quizzes.
Predição
Qual deve ser a primeira ação diante de “adicione isso nas configs”?
Ler o estado real e separar configuração suportada de conselho social.
Flashcards de recuperação
Pergunta
Qual é o exemplo contínuo?
Clique para virar
Resposta
adicione isso nas configs
Pergunta
Qual é a regra de prova?
Clique para virar
Resposta
Boundary real, não alegação.
Pergunta
Qual é o limite?
Clique para virar
Resposta
prova
Escolha a opção operacionalmente correta:
A resposta correta segue o runtime e a finish line; as outras antecipam uma conclusão.
Ajuste de risco
4/10
Revisão focada + teste real.
Fluxo por etapas
Etapa 1 de 4: pedido bruto.
Apresentação da lição
Quadro 1/4
pedido bruto
Quando você escreve “adicione isso nas configs”, ainda faltam três respostas: o que já existe, o que o runtime aceita e qual prova encerra o trabalho. Primeiro você investiga. Só então cria um goal que reduza o espaço de busca.
Quadro 2/4
estado real
O fluxo é requirements gathering → inspeção local → hipótese de mudança → finish line → set_goal. Para trabalho pequeno e já delimitado, um goal persistente pode ser desnecessário; para trabalho amplo, a pesquisa precede a ativação.
Quadro 3/4
goal verificável
Ler o estado real e separar configuração suportada de conselho social.
Quadro 4/4
prova
Leve a regra para o playbook final.
Revisão espaçada
Qual evidência fecha melhor esta lição?
O boundary correto mede o comportamento afirmado; aparência e confiança não substituem execução.
Acertos: 0/1
Pergunte ao seu agente-professor quando um boundary estiver ambíguo. Próxima etapa: Escreva o contrato do trabalho.