Correção — tratar o parecer da revisão

gm-ship abre a PR e o workflow de revisão publica o parecer. Esta skill fecha o que fica entre os dois: nenhum achado morre por silêncio. Cada um sai daqui corrigido, refutado com evidência, ou promovido a card — e dito na PR.

Um achado é hipótese, não veredito. A revisão declara a própria confiança e erra: corrigir um falso positivo é pior que ignorá-lo, porque entra no diff com ar de correção. Verifique antes.

Como perguntar e como aprovar

This section is stamped from _comum/convencoes.md — the folder beside this skill's; in the claude-brain repo, skills/_comum/convencoes.md — into every gm-* skill that has an interaction point. Never edit this copy: edit the source there and run node scripts/skills-comum.mjs in that repo (its --check catches a copy that drifted). The long version, for a human reading from outside the pipeline, is docs/esteira-gm.md of the claude-brain repo, section ## Como as skills perguntam.

1. Context before jargon. Open with what is at stake and what changes down each path, in pt-BR. Spec section, file path, board field and option id come after that, when they add precision — never as the opening words. Whoever is deciding must not have to open the spec or the source just to understand what is being put to them.
2. Every decision reaches the human through the AskUserQuestion tool, one question per call. No batching, no multiSelect. Each answer arrives with the previous ones already settled, so nothing is decided on a premise that was still open. Five decisions is five calls, in order.
3. Two standard sets, chosen by what is at stake.
   • Artefato (spec, card body, PR body) → Aprovar · Ajustar · Rejeitar. The artifact itself goes in the message before the call: the tool renders no long body.
   • Ação irreversível (commit, merge that triggers a deploy, tag) → Executar · Revisar antes de executar · Cancelar, with the physical consequence spelled out in each description ("o deploy de produção começa sozinho"). "Ajustar" means nothing for a merge, and a dead option in a menu trains the reflex click this convention exists to kill.
4. A list longer than four never becomes a silently truncated menu. The tool takes 2–4 options. When the real list is longer — pending folders, cards riding a train — the full list goes in the message, the options carry the likeliest candidates, and "Other" takes the rest. Never drop a candidate without saying that it was dropped.
5. Silence is never a yes. "Other" is always available, so free text is never taken away. Do not argue one option into being the obvious one. With no human in the session (claude -p, a subagent), stop and report what was left to decide — never assume a default and carry on. The one exception is ## Modo despachado below.

Tool limits, so a question is never rejected or silently cut: 2–4 options per question, header up to 12 characters, label 1–5 words, "Other" appended automatically (never write it yourself). Instructions in this file stay in English; everything the human reads — the question, the labels and every description — is written in pt-BR.

Ambiente na entrada

Before the first test, build or commit — a broken environment found halfway costs the minutes already spent. Read the item Ambiente of the workspace CLAUDE.md, wherever it sits (by convention under ## Convenções da esteira), and check, in this order; stop at the first failure with the reason and the output that proves it (no human → PARADA: ambiente — <o que falta>):

1. Disk. Free space where the working tree lives (df -Pk ., column Available) is at least the minimum the item declares — 2 GB when it declares none.
2. Dependencies. Every package the diff touches that has a lockfile next to its package.json has its node_modules/ (a folder or a junction). Missing → do what the item declares for providing them; nothing declared → stop. Never install by default: installing is what fills the disk.
3. Services. Each service the item declares, by the command it gives to prove it is up. None declared → nothing to check.

No Ambiente item at all → checks 1 and 2 with the defaults, and one line saying the workspace declares none. Applies to gm-correcao only on the Corrige path, the one that needs a checkout.

Preconditions

1. Resolver PR e repo — o workspace tem cinco repos (modulo-processos, shd-rpa, processos-criticas, processos-core, criticas-report), então repo nunca é implícito:
   • owner/repo#123 → explícito, use;
   • pasta de feature → leia planning/<pasta>/spec.md → ## Execution (repo, branch) e ache a PR da branch: gh pr list --repo <owner>/<repo> --head <branch>;

   • só o número → resolva pelo repo do diretório corrente (gh repo view --json nameWithOwner) e confirme antes de agir, porque o mesmo número existe nos cinco repos e tratar parecer na PR errada escreve resposta pública no lugar errado. Título, branch e autor vão na mensagem, e a confirmação vem por uma chamada AskUserQuestion — header PR alvo, pergunta e opções em pt-BR:

     Você passou só o número, e o mesmo número existe nos cinco repos do workspace — tratar o parecer na PR errada publica resposta pública no lugar errado, e ela fica lá. Pelo diretório atual, o <n> é esta: «<título>», branch <branch>, em <owner>/<repo>, aberta por <autor>.

     • É esta — sigo com ela: leio o parecer, verifico cada achado, corrijo ou refuto, e cada inline recebe resposta pública nesta PR.
     • Escolher outra — não toco nesta; mostro as PRs abertas com parecer publicado e você aponta.

   • nada → a lista inteira vai na mensagem — uma linha por PR aberta com comentário <!-- gm:revisao-status -->: número, título, repo e quantos achados o parecer trouxe — e a escolha vem por uma chamada AskUserQuestion, header Qual PR, opções em pt-BR nomeando cada candidata pelo que ela é, nunca só pelo número:

     Estas PRs têm parecer publicado esperando tratamento; esta sessão trata uma.

     • #<n> <duas ou três palavras do título> — «<título completo>», <repo>, <k> achados inline, parecer de <data>.
     • … (as demais na mesma forma)

     Mais de quatro PRs → as opções levam as de parecer mais recente, a lista inteira continua na mensagem, e a mensagem diz em voz alta que as demais chegam por "Other". PR omitida em silêncio é parecer que ninguém trata. Todo comando gh daqui em diante leva --repo <owner>/<repo> explícito.

2. Existe parecer? Ler o comentário <!-- gm:revisao-status -->. Só o estado "Revisada" produz parecer. Qualquer outro (Não revisei — …) significa que não há o que corrigir — pare e diga qual estado foi:
   • "não é idêntico ao da main" → a trava da action compara com a branch default, não com a base. Diagnostique: git diff origin/main origin/<head> -- .github/workflows/revisao-claude.yml. Enquanto main e dev divergirem, nenhuma PR é revisada. Aponte e pare.
   • "revisão foi interrompida" → estado C. O teto é vars.REVISAO_TIMEOUT_MINUTOS, ajustável sem PR. Aponte e pare.
3. Ler o parecer e responder inline não pede checkout nenhum — é tudo gh. Quem pede árvore é o balde Corrige, e a árvore dele é uma worktree recriada no ## Corrigir, não o checkout principal: o /gm-ship removeu a do card quando abriu a PR. Responder inline exige escopo de escrita no gh; 403 → ! gh auth refresh -s repo.

Coletar

• Parecer em prosa: o comentário do autor claude — a revisão é única por PR. Identifique pelo autor, não pelo texto: ele não tem marcador HTML (só o gm:revisao-status, que é do autor github-actions, tem). Traz conformidade · divergências · bugs e riscos · sugestões.
• Inline: gh api "repos/<owner>/<repo>/pulls/<n>/comments" — cada um tem id, path, line. Filtre pelos do autor claude: humanos também comentam inline, e o parecer deles não é seu.
• A linhagem do card, o mesmo insumo que a revisão usou: gm:spec (épico: gm:spec-ref no card em voo + gm:spec no pai), gm:tasks, e os gm:decisao. Achado só é "procede" à luz da spec — sem ela você julga código no vácuo, que é exatamente o que o G4 existe para evitar.

Triar

Verifique cada achado até file:line antes de classificar. Depois, quatro baldes — os três últimos são os protocolos do gm-implement, não invente outros; a emenda pós-tasks, quarta seção de lá, é anterior à PR e não se aplica aqui:

Escopo extra é o que a revisão foi construída para pegar — não o reintroduza corrigindo. "Já que estou aqui" no tratamento do parecer é o mesmo defeito, uma estação depois.

Uma sugestão (não-bug) só vira commit se fechar critério de aceite; senão responda por que não.

Corrigir

0. A worktree primeiro, antes de tocar em arquivo. O /gm-ship apagou a worktree do card ao abrir a PR, e o checkout principal não é lugar de card — corrigir ali fura a mesma regra que o gm-implement aplica. Recrie-a pela convenção, com <n> vindo do **Card:** #<n> da primeira linha da PR e <slug> do nome da branch:

   git fetch origin
   git worktree list                                          # já existe? entre nela e siga
   git worktree add <workspace>/<repo>-<n>-<slug> <branch-da-pr>

   Daqui até o fim do tratamento todo git roda de dentro dela, e todo gh continua com --repo <owner>/<repo> explícito. Card anterior à regra, ainda no checkout principal → siga onde ele está, sem mover: card em voo não se muda de chão.

1. Um commit por achado, mensagem dizendo qual achado fecha e por quê — não "corrige review".
2. Rodar o portão de teste do workspace — o item Portão de teste do CLAUDE.md, como na precondição 4 do gm-ship: a parte local sempre; a suíte inteira aqui quando o portão é local ou quando o item não existe. Vermelho → parar e mostrar.
3. Push na mesma branch. Não alternar draft→ready: isso redispara a revisão inteira e queima cota. A regra é uma revisão por PR e um /gm-correcao: não peça re-revisão (nem mencionando @claude).

Responder na PR

Todo inline recebe resposta — é o que fecha o laço para quem revisar depois:

gh api -X POST "repos/<owner>/<repo>/pulls/<n>/comments/<comment-id>/replies" -f body="..."

• corrigido → o commit (<sha>) e o que mudou, em uma linha;
• refutado → a evidência (arquivo:linha) que mostra por que não procede;
• virou card → #<n>, e por que não cabia aqui.

E um comentário-resumo, sticky por <!-- gm:correcao --> (create-or-update pelo marcador, como o gm:revisao-status), em pt-BR:

<!-- gm:correcao -->
## 🔧 Parecer da revisão tratado

| # | Achado | Decisão | Onde |
|---|---|---|---|
| 1 | <resumo> | corrigido | `<sha>` |
| 2 | <resumo> | não procede | `arquivo:linha` refuta |
| 3 | <resumo> | card #<n> | fora do escopo desta PR |

<uma linha por achado refutado explicando o porquê — é a parte que o revisor humano confere>

Board e registro

• O card não muda de estação: segue em 👀 Revisão (project-id <project-id>, Status <field:Status>). Tratar parecer é parte da revisão, não uma volta para Implementação.
• Achado que virou card entra em 📥 Triagem (<opt:Status=Triagem>).
• Emenda à spec (balde Desvio) vai para spec.md e para o comentário gm:spec do card, com nota datada — a spec nunca pode virar ficção histórica.
• Grave com mcp__brain__lembrar na hora todo achado refutado e todo desvio: por que não procedia, ou o que a spec passou a dizer. Achado refutado sem registro volta na próxima revisão.
• A worktree sai como entrou. Commits empurrados e inlines respondidos, saia dela e rode git worktree remove <workspace>/<repo>-<n>-<slug> mais git worktree prune. Recusa por arquivo não commitado é para ser lida, nunca vencida com --force — é correção que não subiu.

Report

Tabela dos achados com a decisão de cada um, os commits, o resultado da suíte, e os cards abertos.

Depois diga o que falta: PR pronta para a validação humana → merge em dev → o card vai para 🧪 Validação em Dev, onde uma pessoa nomeada roda o checklist da PR (SLA 7 dias). Validado em dev → este Report não fecha o card, porque nada roda no momento da validação: quem recebe o "validado" da pessoa fecha (gh issue close <n> --repo <owner>/<repo> --reason completed). O card fica em 🧪 Validação em Dev (não espera 🚂 Release, ✅ Produção nem /gm-release), mas o workflow Item closed do board, se ligado, pode movê-lo ao fechar: releia o Status depois e, se mudou, devolva com updateProjectV2ItemFieldValue (id da opção Status no CLAUDE.md do workspace). Se algum achado virou desvio e a spec mudou, diga que o checklist de validação mudou junto.

Convenções de saída

This section is stamped from the same _comum/convencoes.md as ## Como perguntar e como aprovar, into every gm-* skill that has a closing point. Edit the source in the claude-brain repo and run node scripts/skills-comum.mjs there — never this copy.

1. The last line of the final answer is machine-readable, so a dispatcher (a script, another session) can chain the pipeline without reading prose. Exactly one of:

   • PROXIMO: /gm-<skill> <argumento> — the pipeline continues; name the next skill and its argument.
   • PARADA: <motivo em uma frase> — the pipeline does not continue; one sentence, in pt-BR, saying what is waiting and on whom.

   Nothing follows that line. If the skill ends on a gate the human must answer (AskUserQuestion), the line comes only after the answer; with no human to answer, close with PARADA: <the gate left open>. Under ## Modo despachado, a gate in its decide rows is answered, not left open.

2. File content never travels inside a command argument. New file → Write. Existing file → Edit. A heredoc only when short: if your workspace has a context-cost hook, it may deny one above 1500 characters. A long body (issue comment, PR body, commit message) goes to a file first, then --body-file (gh) or -F (git commit).
3. A rule that belongs to one workspace never enters a skill. Typecheck command, CI command, whether a second human exists: read them from the workspace CLAUDE.md, and stop to ask when it does not declare them — with no human in the session, that stop is PARADA: <what the CLAUDE.md must declare>.
4. With no human in the session (claude -p, a dispatcher), do not wait for CI and do not schedule a wake-up (ScheduleWakeup, /loop), and do nothing in the background: report what was done and close with PROXIMO or PARADA.

Modo despachado

This section is stamped from the same _comum/convencoes.md as the two above. Edit the source in the claude-brain repo and run node scripts/skills-comum.mjs there — never this copy.

When it applies: no human in the session (claude -p, a subagent) and the argument hands over the front in words ("você decide sozinho o G2, o G3, o commit e o ship"). Both, or it does not apply: no human and no handover → item 5 of ## Como perguntar e como aprovar (stop and report). A human in the session → never, whatever the argument says. When it applies, it replaces item 5 for the rows marked decide; the rest of the skill runs as written. The argument may add stops; it never turns a para into a decide — except the one row below that says so, and only by naming it.

Every decide is recorded on the spot: the decision tool of the workspace (mcp__brain__lembrar where the brain MCP runs) with what, why and what was discarded, and one comment on the card per stage, with the prefix the argument gives.

What the argument still carries — only what belongs to the card: card and repo; where to work (worktree, branch, PR base when stacked); the recorded decisions that bind it; stops beyond this table; environment facts the workspace CLAUDE.md does not declare. What this table says is not repeated there.