Passo 6 · Coordenação·Coordenação · Separe autor, revisor e tiers
Codex com objetivo e prova — do prompt ao runtime · Lição 6/8

Separe autor, revisor e tiers

O risco da mudança define quanto revisar; o autor nunca é o único juiz.

Demonstrações debatidas: 3 code-review-pr · 17 pr-writeup · 18 editor-triage-board · apresentação universal

Leia primeiro · fonte local
RESOURCES.md + evidence/proof-results.txt

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


Mudanças de baixo impacto podem usar testes e uma revisão leve. Mudanças com usuários, dinheiro, dados ou segurança pedem intenção registrada, revisão independente e atenção humana nos gates.

Pense como… É a conferência de uma transferência: quem digita não é a única pessoa que confirma um valor alto. Em software, o tier varia com blast radius, vida útil e número de pessoas afetadas.

Por baixo do capô

A revisão deve inspecionar primeiro alterações em testes, comparar código com intenção e procurar enfraquecimento de gates determinísticos. Um revisor diferente reduz blind spots correlacionados; o humano continua dono de merge e ações externas de alto impacto.

intenção → autor → revisor
01 · intenção conduz a autor; o checkpoint é revisor.
2

Atlas visual


Leia cada diagrama como entrada → decisão → checkpoint. As legendas ligam a imagem ao mesmo exemplo.

autor → revisor → humano no gate
02 · autor conduz a revisor; o checkpoint é humano no gate.
revisor → humano no gate → intenção
03 · revisor conduz a humano no gate; o checkpoint é intenção.
humano no gate → intenção → autor
04 · humano no gate conduz a intenção; o checkpoint é autor.
intenção → autor → revisor
05 · intenção conduz a autor; o checkpoint é revisor.
autor → revisor → humano no gate
06 · autor conduz a revisor; o checkpoint é humano no gate.
revisor → humano no gate → intenção
07 · revisor conduz a humano no gate; o checkpoint é intenção.
humano no gate → intenção → autor
08 · humano no gate conduz a intenção; o checkpoint é autor.
intenção → autor → revisor
09 · intenção conduz a autor; o checkpoint é revisor.
autor → revisor → humano no gate
10 · autor conduz a revisor; o checkpoint é humano no gate.
revisor → humano no gate → intenção
11 · revisor conduz a humano no gate; o checkpoint é intenção.
humano no gate → intenção → autor
12 · humano no gate conduz a intenção; o checkpoint é autor.
intenção → autor → revisor
13 · intenção conduz a autor; o checkpoint é revisor.
autor → revisor → humano no gate
14 · autor conduz a revisor; o checkpoint é humano no gate.
3

No runtime


Este trecho registra a regra sem expor o arquivo global completo.

Evidência local sanitizada
Tier 1: tests + focused review
Tier 2: intent + independent review
Tier 3: independent review + real boundary + human gate

Invariant: reviewer != author

Acesse você mesmo

Use o PRD.md#requisitos-funcionais e a síntese da fonte “review como gargalo” em RESOURCES.md.

4

Comparativos


TierEvidência
baixo riscoteste real e revisão focada
alto riscoreview distinto + boundary + gate
AgentePapel
autorproduz a unidade
revisortenta quebrar a alegação
5

Experimente


Decida antes de revelar; depois ajuste o risco, percorra o fluxo e responda aos quizzes.

Predição

Quem deve aprovar o próprio trabalho como única evidência?

Ninguém. O revisor precisa ser distinto do autor.

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
humano no gate
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: intenção.

Apresentação da lição

Quadro 1/4

intenção

Mudanças de baixo impacto podem usar testes e uma revisão leve. Mudanças com usuários, dinheiro, dados ou segurança pedem intenção registrada, revisão independente e atenção humana nos gates.

Quadro 2/4

autor

A revisão deve inspecionar primeiro alterações em testes, comparar código com intenção e procurar enfraquecimento de gates determinísticos. Um revisor diferente reduz blind spots correlacionados; o humano continua dono de merge e ações externas de alto impacto.

Quadro 3/4

revisor

Ninguém. O revisor precisa ser distinto do autor.

Quadro 4/4

humano no gate

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: Atravesse o Proof Gate real.