Entrega (Handover)

Handover (Entrega)

Empacote uma alteração concluída de forma que seus revisores nunca precisem reconstruir a intenção a partir do diff. Escreva para um revisor que possui apenas o diff — sem documentos de planejamento, sessão ou qualquer conhecimento de que eles existem.

Resolva a tarefa

A entrada é qualquer referência parcial — ID de ticket, slug, caminho de um artefato de planejamento — ou nada, significando a tarefa da sessão; em uma sessão nova, infira a partir do nome da branch e dos commits recentes. Resolva-a para o lar de planejamento da tarefa: seu diretório <id>-<slug>/ no diretório de planejamento do projeto, ou seus arquivos planos <id>-<slug>.* em um diretório familiar compartilhado. Uma correspondência clara → prossiga, informando o lar e os artefatos encontrados. Inferido, ou vários candidatos (-vN, …) → confirme primeiro. Uma referência explícita que não corresponde a nada local → pare e pergunte; nunca adivinhe.

Reúna

Leia estes itens, pulando o que não existe:

1. Artefatos da tarefa — todo <id>-<slug>*.md no lar de planejamento: ticket, requisitos, plano, registro de decisões, rodadas anteriores de revisão e entrega, e qualquer outra coisa que corresponda.
2. Tickets relacionados — apenas um salto: pai (subindo apenas além de contêineres finos), predecessores/sucessores diretos, relações explícitas, irmãos do diretório familiar; nunca expanda suas próprias relações. Primeiro, os .TICKET.md locais; busque no rastreador apenas quando uma relação não tem arquivo local e parece relevante para um porquê — em dúvida se deve buscar, pergunte.
3. A sessão, quando ela produziu a alteração: decisões, pivôs, restrições.
4. O diff contra o destino, mais os assuntos dos commits.

Cada fonte uma vez, sem aprofundar além do que o artefato precisa: leia o diff por cima, leia profundamente apenas os arquivos que você nomeará no Guia de revisão, e nunca reconstrua o histórico commit por commit — qual commit mudou o que é trabalho do diff, não seu.

Em seguida, compare os passos do plano e os critérios de aceitação com o diff em ambos os sentidos — planejado mas ausente, presente mas não planejado. Concluído quando cada fonte é lida ou confirmada ausente e cada item planejado é correspondido.

Nunca invente justificativas

Afirme um "porquê" apenas quando uma fonte o fornece. Um desvio que nada explica é perguntado ao autor uma vez; sem resposta ou impossível de perguntar, ele é enviado sinalizado em palavras simples ("nada registra por que — vale confirmar"), pois pode ser uma lacuna não intencional em vez de uma decisão. A fonte é seu portal, não a leitura do revisor: ela decide o que você pode escrever, e nunca aparece no texto. Quando não tiver certeza, sempre pergunte. Nunca adivinhe.

O artefato

<slug>.HANDOVER.md no lar de planejamento; já existente → <slug>.HANDOVER-2.md, -3, … — nunca sobrescreva. Sem lar de planejamento → apresente o conteúdo e pergunte onde salvá-lo. Seu corpo é pronto para colar como descrição do PR, e é autossuficiente:

• Mencione apenas o que o revisor pode abrir — uma URL do rastreador, ou um arquivo que você verificou estar commitado na branch. Todo o resto — documentos de planejamento, registro de decisões, sessão, hashes de commit — não é vinculado nem nomeado: escreva o que ele diz ("isto foi feito para …"), nunca onde ele diz.
• Tickets relacionados não são mencionados a menos que um porquê dependa de um ("construído assim para preparar para ") — então cite a URL do rastreador.
• Em uma tela, ~400 palavras; os limites abaixo são limites, não metas.
• Linguagem simples voltada ao revisor, nunca o vocabulário desta skill. Antes de redigir, invoque use-conversational-language — recitar suas regras de memória não conta.

Seções, puladas apenas quando realmente vazias:

1. O que e por quê — 2–3 linhas.
2. Decisões que vale a pena conhecer — no máximo 5 linhas, cada uma: o que foi escolhido ou o que se desvia do plano, seu porquê ou a bandeira de porquê ausente, e onde no código vê-lo.
3. Guia de revisão — os poucos arquivos onde o julgamento importa e por quê; o restante nomeado como mecânico.
4. Lacunas conhecidas — no máximo 3: deficiências, suposições, perguntas em aberto.

Concluído quando cada seção está preenchida ou conscientemente pulada, nada lê como verificado que não foi, e nada no texto aponta para algo que o revisor não pode abrir.

Limites

• Não modifique nenhum arquivo fonte; o documento de entrega é o único arquivo escrito.
• Nunca faça push ou abra/comente em um PR — a publicação é uma ação explícita do usuário.