← Voltar ao curso
Nível 3 — Automação e escala · Módulo 3.4 — Verificando trabalho não supervisionado

3.4.2 · Comece pelo diff, não pelo resumo

5 min de vídeo TODOS

Objetivo: ao final, o consultor audita o que mudou em vez do que foi narrado, usando /code-review e depois os próprios olhos no diff — e sabe o que fazer quando não existe diff, como em boa parte do trabalho ABAP.

O que você precisa levar desta aula

  1. Texto bem escrito não é prova de trabalho correto. Um resumo pode ser inteiramente verdadeiro e ainda omitir o que o Claude fez além do combinado.
  2. Ordem de auditoria: /code-review primeiro (automático), depois seus olhos no diff — lendo o que estava no plano e então procurando o que ficou fora dele.
  3. Quando não há git (ABAP clássico), o equivalente existe: a lista de objetos do transporte é o diff, e a comparação de versão no ADT é a leitura linha a linha.

/code-review, na prática

/code-review

Sem argumento, revisa os commits do branch à frente do upstream mais as mudanças não commitadas na árvore de trabalho. Precisa haver algo no branch ou na árvore para ter o que reportar.

Forma O que revisa
/code-review Commits à frente do upstream + mudanças pendentes
/code-review caminho/arquivo.cds Um arquivo
/code-review 481 Um PR pelo número
/code-review main...minha-feature Um intervalo de refs
Flag Efeito
--fix Aplica os achados na árvore de trabalho depois da revisão
--comment Posta os achados como comentário inline no PR

Dois detalhes de comportamento que evitam surpresa:

Ela segue o CLAUDE.md como qualquer sessão, mas não lê o REVIEW.md — esse é só do Code Review gerenciado (aula 3.5.4).

A ordem de leitura que pega problema

Etapa O que fazer Por que nessa ordem
1 /code-review Camada automática, pega o que é detectável por análise
2 Ler no diff o que estava no plano Confirma que o combinado foi feito — parte fácil
3 Procurar no diff o que ficou fora do plano É onde mora o problema que o resumo não menciona
4 Para o que tem consequência, conferir contra a fonte Regra de negócio, número, referência a documento

A etapa 3 é a que quase todo mundo pula, e é a única que encontra o arquivo tocado por acaso. A pergunta a fazer no diff não é "isso está certo?" — é "o que está aqui que eu não pedi?".

Quando não existe diff

Boa parte do trabalho SAP não é versionada em git. Isso não dispensa a verificação; muda o instrumento.

Contexto O que faz o papel do diff
Objetos CAP, Fiori, scripts, documentação versionada git diff de verdade
Objeto ABAP clássico Lista de objetos do transporte — confira se só contém o que deveria
Alteração em objeto existente Comparação de versão no ADT, contra a versão ativa
Reorganização de pasta no Drive ou SharePoint Listagem antes e depois; conferir o que saiu de pasta de fase encerrada
Documento reescrito Comparação de versão no editor, não leitura do resumo

O princípio é o mesmo em todos: audite a mudança, não a narrativa da mudança.

Regra Wayon Nenhum entregável produzido com apoio do Claude vai para o cliente com base na leitura do resumo. A revisão é sobre a mudança em si: git diff onde houver git, lista de objetos do transporte e comparação no ADT no ABAP clássico, comparação de versão em documento. E a pergunta obrigatória da revisão é "o que está aqui que eu não pedi?" — foi ela que pegou a pasta da Fase 1.

📖 /code-review · Plan mode de verdade — módulo 2.6.1

Quiz — 4 questões

1.O resumo de uma execução desassistida diz: "Reorganizei as 200 evidências da Fase 2 conforme o padrão do cliente. Nenhum arquivo foi perdido." O diff mostra que uma pasta da Fase 1 também foi tocada. O resumo mentiu?
  • a)Sim — omitir uma alteração equivale a afirmar que ela não ocorreu

    Omissão e falsidade não são a mesma coisa, e tratar como mentira faz perder a lição: resumos verdadeiros também omitem.

  • b)Não — cada afirmação dele é verdadeira; ele só não menciona o que foi feito além do combinado

    Correto, e é justamente por isso que aprovar pelo resumo é frágil, mesmo quando o resumo é honesto.

  • c)Impossível dizer sem perguntar ao Claude o que ele fez

    É possível e é o ponto da aula: o diff responde isso sem depender de nova narrativa.

Ver resposta e por quê
❌a) Omissão e falsidade não são a mesma coisa, e tratar como mentira faz perder a lição: resumos verdadeiros também omitem.
✅b) Correto, e é justamente por isso que aprovar pelo resumo é frágil, mesmo quando o resumo é honesto.
❌c) É possível e é o ponto da aula: o diff responde isso sem depender de nova narrativa.
2.Qual é a pergunta mais produtiva a fazer ao ler o diff de uma execução desassistida?
  • a)"Isso está bem escrito?"

    Qualidade de redação é justamente o que não prova correção.

  • b)"O que estava no plano foi feito?"

    Necessário, mas é a parte fácil — e não encontra o que foi feito além do plano.

  • c)"O que está aqui que eu não pedi?"

    Correto. É a etapa que quase todo mundo pula e a única que encontra o arquivo tocado por acaso.

Ver resposta e por quê
❌a) Qualidade de redação é justamente o que não prova correção.
❌b) Necessário, mas é a parte fácil — e não encontra o que foi feito além do plano.
✅c) Correto. É a etapa que quase todo mundo pula e a única que encontra o arquivo tocado por acaso.
3.Você rodou /code-review --fix e a revisão aplicou edições que você quer desfazer. Qual é o caminho?
  • a)Reverter com git

    Correto. É o caminho indicado justamente porque as edições da revisão em segundo plano ficam fora dos checkpoints da sessão.

  • b)/rewind, que restaura o estado anterior da sessão

    A revisão roda como subagente em segundo plano e suas edições ficam fora dos checkpoints — /rewind não as desfaz.

  • c)Rodar /code-review de novo, que recalcula e reverte o que aplicou antes

    Uma revisão nova não desfaz a anterior; ela revisa o estado atual.

Ver resposta e por quê
✅a) Correto. É o caminho indicado justamente porque as edições da revisão em segundo plano ficam fora dos checkpoints da sessão.
❌b) A revisão roda como subagente em segundo plano e suas edições ficam fora dos checkpoints — /rewind não as desfaz.
❌c) Uma revisão nova não desfaz a anterior; ela revisa o estado atual.
4.Um consultor TEC alterou dois programas Z no MRD, que não vivem em git. Como fazer a verificação equivalente ao diff? ---
  • a)Não é possível verificar sem git; a alternativa é confiar no resumo da sessão

    Não há necessidade de confiar no resumo: existem instrumentos equivalentes no próprio ambiente SAP.

  • b)Conferir a lista de objetos do transporte e usar a comparação de versão no ADT

    Correto. O transporte faz o papel do diff, e a comparação no ADT faz o da leitura linha a linha.

  • c)Exportar os fontes para um repositório git só para poder rodar git diff

    Funciona como último recurso, mas é caro e desnecessário — os instrumentos nativos já respondem à pergunta.

Ver resposta e por quê
❌a) Não há necessidade de confiar no resumo: existem instrumentos equivalentes no próprio ambiente SAP.
✅b) Correto. O transporte faz o papel do diff, e a comparação no ADT faz o da leitura linha a linha.
❌c) Funciona como último recurso, mas é caro e desnecessário — os instrumentos nativos já respondem à pergunta.