CI: rascunho de post por release, co-criado com a comunidade (#27)

[juansilvadesign]

Descrição da mudança

Materializa a automação proposta na #27: a cada release, a seção daquela versão no CHANGELOG.md vira um rascunho de post e um PR em social/drafts/ — sempre rascunho + revisão humana, nunca publicação direta (o workflow não tem acesso a nenhuma rede social, de propósito).

• scripts/social-draft.mjs (zero dependências, como os demais scripts do repo; node scripts/social-draft.mjs [versão]): extrai a seção do changelog e escreve social/drafts/vX.Y.Z.md com frontmatter de status. Com o segredo ANTHROPIC_API_KEY configurado, o texto é escrito por IA limitada ao que o changelog diz (2 variantes: X/Twitter e Instagram, pt-BR, sem hype); sem o segredo, sai um template honesto montado dos bullets — o fluxo funciona com zero segredos.
• .github/workflows/social-draft.yml: dispara em release publicada (ou manualmente com versão), abre o PR com label social/content.
• social/README.md: o guia de co-criação da comunidade — como propor posts (issue com label ou PR direto em drafts/), regras editoriais (changelog é o limite do factual; privacidade como argumento; crédito a quem contribuiu, no espírito do CONTRIBUTORS.md).

O rascunho de exemplo social/drafts/v1.4.0.md está commitado — foi gerado pelo caminho template contra o changelog real da 1.4.0 (com o crédito ao @leandroohsr preservado no bullet), para servir de modelo do formato.

Tipo de mudança

• Correção de bug (não quebra nada existente)
• Novo recurso (não quebra nada existente)
• Mudança que quebra compatibilidade (comportamento existente muda)
• Documentação / tooling (sem alteração no código da extensão)

Impacto em storage

• Não mexe em chaves de storage
• Adiciona uma chave nova (não renomeia nem remove as existentes)
• Atenção: renomeia/remove uma chave existente (explique a migração abaixo)

Testes

• Rodei npm run lint sem erros
• Rodei npm test sem falhas
• Testei manualmente em uma live real do YouTube — N/A (tooling de repositório; nada muda na extensão)
  • Navegador testado: —

O script foi executado de ponta a ponta contra o changelog real (caminho template; o rascunho commitado é a saída literal). O caminho IA degrada para o template em qualquer erro de API.

Screenshots

N/A — tooling.

Checklist final

• O código segue o estilo do projeto (ESLint passa)
• Atualizei a documentação relevante (README, CHANGELOG, etc.) quando aplicável
• Estou de acordo com a licença GPL-3.0-or-later do projeto

🤖 Generated with Claude Code

https://claude.ai/code/session_01AiLQznJ15KbuK73b9YxAjS

[leandroohsr]

Ótima proposta @juansilvadesign, mas não consigo ver o conteúdo em https://claude.ai/code/session_01AiLQznJ15KbuK73b9YxAjS

[juansilvadesign]

Ótima proposta @juansilvadesign, mas não consigo ver o conteúdo em https://claude.ai/code/session_01AiLQznJ15KbuK73b9YxAjS

O conteúdo ali da sessão é só um resumo geral:

● Todos os seis pull requests estão agora abertos no repositório joaogfc/ZeroDelay:

PR	Feature	Branch
#43	Copiar diagnóstico + resumo da sessão	feat/copy-diagnostics
#44	Latência no ícone da extensão (opt-in)	feat/latency-badge
#45	Aviso de novidades após atualização	feat/whats-new-chip
#46	Configurações via storage.sync	feat/settings-sync
#47	CI: canário noturno do player	ci/nightly-canary
#48	CI: rascunho de post por release (#27)	ci/social-drafts

Alguns detalhes sobre como eles foram preparados, já que isso afeta a forma como o mantenedor os visualizará:

Cada PR é independente. Em vez de apontar todos para a branch de suíte, reconstruí cada funcionalidade em sua própria branch a partir da main do upstream, realizando cherry-picks e resolvendo manualmente as sobreposições — assim, o changelog e o README de cada PR contêm apenas a sua própria entrada, e a integração (merge) de qualquer subconjunto funciona corretamente. Há uma exceção intencional: o #47 (canary) está empilhado sobre o #43 (diagnostics), pois a sonda (probe) utiliza a ponte de diagnóstico para verificar se o engine está ativo; a descrição instrui o mantenedor a integrar o #43 primeiro, momento em que o #47 pode ser reduzido a um único commit. Cada branch foi revalidada de forma independente após a resolução de conflitos — ESLint, a suíte de testes (49 a 58 testes, dependendo do conteúdo da branch), verificador de locales, ambas as compilações para lojas (store builds) e o web-ext.
Realizou-se a verificação de lint (0 erros / 0 avisos) nas quatro branches de código da extensão. Disso resultaram duas pequenas limpezas independentes: a branch de sincronização (sync) continha um comentário e um teste referenciando a chave lastSeenVersion, que
só existe na #45 (removida de lá), e a branch canary estava sem sua entrada no changelog, que havia sido incluída inadvertidamente no commit relacionado a redes sociais (adicionada).

O corpo das Pull Requests (PRs) segue o modelo do repositório — o impacto no armazenamento é declarado em cada PR (as #44 e #45 adicionam uma nova chave cada; a #46 marca a caixa de "atenção" com a explicação completa da migração), e a
caixa de seleção de testes manuais reflete os testes realizados localmente. A #46 é a que provavelmente gerará mais perguntas, por ser a mais invasiva; caso o mantenedor solicite alterações em qualquer uma delas, o fluxo é: corrigir
na branch da funcionalidade (feature branch) e, em seguida, espelhar a alteração para a feat/community-suite, que permanece como sua referência integrada no fork.

[joaogfc]

@
Fechando junto com a #27, como combinado. Esta automação de rascunho de post por release foi construída para alimentar a presença nas redes sociais proposta na #27, e como decidi não seguir com rede social, o workflow perde o propósito.

Obrigado pelo trabalho, Juan, o script estava limpo e bem isolado. Só não é um caminho que quero manter agora.
@