Prompt-Motion/ReaReverse

Atualização do changelog REA

Use isto para preparação de notas de release e atribuição de contribuidores. Leia docs/releasing.md da raiz do repositório para autoridade de publicação e as verificações de checkpoint existentes. Esta skill prepara notas; ela não autoriza merge, tagging ou publicação.

Inventário antes da prosa

Busque o histórico completo e as tags. Selecione a tag de base publicada a partir de .release-please-manifest.json no branch base do PR de release, e fixe o SHA exato desse branch como alvo editorial. As tags REA são rea-agents-VERSION. Use a versão proposta, incluindo seu sufixo de pré-lançamento; não altere a estratégia always-bump-minor para imitar as versões de calendário do OpenClaw.

node scripts/release-notes.mjs inventory \
  --repository morluto/rea --base rea-agents-PREVIOUS \
  --target FULL_BASE_BRANCH_SHA --version VERSION \
  --manifest /tmp/rea-VERSION.contributions.json
node scripts/release-notes.mjs record \
  --manifest /tmp/rea-VERSION.contributions.json \
  --summary \
  --output /tmp/rea-VERSION.record.md

Leia o inventário, não apenas o rascunho do bot existente. Ele inclui commits de branch lateral, PRs associados ao GitHub cujos commits de merge estão no intervalo, autores/co-autores de commits, e issues de fechamento confirmadas com seus relatadores. As conexões do GitHub são paginadas. Erros de rede interrompem a geração; execute novamente em um novo arquivo de saída após a recuperação. Arquivos de saída existentes nunca são sobrescritos.

Identidades de commit não resolvidas são retidas como nomes/emails com user: null; nunca adivinhe um handle ou agradeça ao merger como substituto. O relatório preserva desconhecidos. Esta é uma captura de metadados revisada, não uma prova independente de que um humano escreveu um patch. Para identidades não atribuídas, estratégias de merge incomuns, backports, reversões ou referências que o GitHub não associou, inspecione os PRs e diffs de origem e relate a limitação. O coletor atual usa relações confirmadas de fechamento de PR para crédito do relator de issue; menções de issue não relacionadas não são creditadas automaticamente. Não afirme que o trabalho meramente inventariado ainda é enviado após uma reversão.

Escreva para usuários e retenha crédito

Reescreva apenas a seção mais nova ## [VERSION] no CHANGELOG.md, preservando seu cabeçalho de versão/data/link. Use itens de lista Markdown de linha única sob:

• ### Destaques: alguns resultados de usuário que definem a release; sem cota para releases pequenas.
• ### Mudanças: capacidades e mudanças de comportamento significativas.
• ### Correções: correções de confiabilidade, correção, compatibilidade e segurança.
• ### ⚠ MUDANÇAS QUEBRADAS: mantenha quando aplicável, com migrações e referências originais de PR/commit exigidas pelo validador de checkpoint existente.

Agrupe trabalhos relacionados por fluxo de trabalho do analista ou impacto no usuário. Explique o comportamento resultante em entradas curtas e concretas. Destaques resumem a release; evite repetir suas descrições completas em Mudanças. Limpeza interna, testes, CI e documentação de rotina geralmente pertencem apenas ao arquivo de proveniência. Leia PRs/diffs ambíguos antes de fazer afirmações. Distinga verificações de provedor simulado de verificação de provedor real.

Credite cada contribuição representada uma vez nas notas públicas com seu link e Thanks @... para seu autor humano verificado, co-autores conhecidos e relatores de issue de fechamento confirmados. Agrupar preserva todos esses créditos em uma linha. Quando Destaques, entradas detalhadas ou migrações referenciam o mesmo trabalho, coloque seu agradecimento em uma dessas entradas, não em todas. Inclua links de issue. Marcadores de commit direto carregam o link do commit e crédito humano conhecido. Exclua bots do GitHub e contas de agente conhecidas. Os trailers de co-autor observados da REA do Anthropic, Cursor e Codex resolvem para @claude, @cursoragent e @codex com tipo GitHub User; a política de crédito os exclui enquanto retém seus metadados. A pedido do mantenedor da REA, omita auto-agradecimentos a @morluto enquanto preserva a autoria no inventário. Outros contribuidores humanos permanecem elegíveis. Use links explícitos do GitHub para referências entre repositórios para evitar números #NNN ambíguos. Handles desconhecidos permanecem desconhecidos; eles não são crédito fabricado.

Anexe o link de proveniência record --summary gerado, verbatim, no final desta release. O inventário vinculado contabiliza cada PR descoberto no intervalo e contribuição direta, incluindo trabalho interno omitido da prosa. Não cole a saída completa de record nas notas públicas: ela duplica agradecimentos e obscurece as mudanças voltadas ao usuário. Registros completos permanecem disponíveis para revisão. Não edite manualmente créditos gerados para fazer a validação passar. Atualize o inventário quando o histórico do produto mudar; uma correção apenas de prosa pode reutilizar a captura.

Finalize com o Release Please

Antes de alterar o PR de release ativo, tenha autorização para essa atualização de PR. A preparação e validação local podem prosseguir de forma independente.

1. Adicione rea:release-notes-finalized ao PR de release aberto selecionado antes de editar seu branch/corpo. As pushes de proposta principal respeitam este label. Esta é nossa proteção de fluxo de trabalho, não o mecanismo autorelease: snooze do Release Please. Uma proposta já em execução deve terminar antes de editar. Não dispare preparação manual sobre notas finalizadas.

2. Nesse branch de release, salve o inventário revisado como docs/releases/VERSION.contributions.json. Esta é uma proveniência de release pública durável, não um arquivo de planejamento temporário. Não adicione credenciais ou dumps de ambiente local. Mantenha os artefatos de versão existentes alinhados.

3. Execute o validador de checkpoint existente e o novo verificador:

   node scripts/release-notes.mjs check \
     --manifest docs/releases/VERSION.contributions.json
   node scripts/release-notes.mjs render \
     --manifest docs/releases/VERSION.contributions.json \
     --output /tmp/rea-VERSION.notes.md
   

   O verificador suporta corpos de PR inline, incluindo seus metadados circundantes, até o limite de 65.536 caracteres do GitHub. Ele falha em notas maiores em vez de truncar crédito; os corpos de link de overflow do Release Please não são integrados.

4. Atualize o corpo do PR de release com a seção renderizada, preservando seu cabeçalho/rodapé do Release Please e estrutura de componente/versão. Use um arquivo de corpo para gh pr edit --body-file; alterar apenas CHANGELOG.md não altera o corpo de release do Release Please. Faça push apenas de alterações autorizadas.

5. Busque o corpo do PR recentemente para um arquivo e execute check --pr-body FILE. Revise o diff completo e aguarde pelo CI atual. A publicação verifica o corpo novamente antes da criação da release. Evite mais edições no corpo durante a publicação.

O label de finalização congela as atualizações do bot, não a main. Novas mudanças de produto após o alvo do inventário exigem atualizar as notas antes da publicação. O fluxo de trabalho verifica a ancestralidade do alvo e permite apenas caminhos de metadados de release após esse alvo. Ele também exige que o alvo do inventário seja igual ao primeiro pai do merge revisado, portanto, commits intermediários na main exigem um novo inventário. Revise diffs dentro dos caminhos de metadados de release permitidos também: a proteção de caminho não prova que edições de script de dependência/package são apenas mudanças de versão. Para retomar propostas automáticas, remova o label de finalização e deixe o bot regenerar; espere que edições editoriais sejam substituídas.

Releases existentes sem um inventário de contribuições mantêm seu caminho de publicação atual. Nunca refaça a tag ou republique um pacote para corrigir a prosa de release.