📦 Manutenção, versionamento e CHANGELOG
Semver, CHANGELOG estruturado, rollback seguro, refatoração com confiança e como controlar dívida técnica em projetos que vivem por meses.
1 🏷️ Semver — versões que comunicam intenção
Cada número do semver comunica o impacto da mudança
Semantic Versioning (semver) não é burocracia — é comunicação. Cada número tem significado preciso que permite a qualquer pessoa (e ao Claude) entender o impacto de uma atualização.
# Criar tag de versão
git tag -a v1.2.3 -m "Release 1.2.3 — Documents Gallery"
# Listar tags
git tag --list
# Push tags para remote
git push origin --tags
# Ver diff entre versões
git diff v1.2.0..v1.3.0
# Voltar para versão específica (checkout)
git checkout v1.2.0 -- src/components/Gallery.tsx
PATCH x.y.Z
Bugfix. API inalterada. Seguro atualizar sem ler changelog.
MINOR x.Y.z
Nova feature. Retrocompatível. Leia o changelog para novidades.
MAJOR X.y.z
Breaking change. Pode quebrar código existente. Leia o guia de migração.
2 📋 CHANGELOG bem estruturado
O CHANGELOG é o diário do projeto. Segue o formato "Keep a Changelog" — estruturado por versão com seções Added, Changed, Fixed e Removed.
# Changelog
## [Unreleased]
### Added
- Suporte a dark mode no painel principal
## [2.3.0] — 2026-05-31
### Added
- Documents Gallery: visualização de docs Obsidian no dashboard
- Filtro por vault na sidebar
### Changed
- Script aggregate.ts agora processa docs em paralelo (3x mais rápido)
### Fixed
- Bug em live-data.json quando Pinecone retorna 0 resultados
## [2.2.0] — 2026-04-15
### Added
- Skill /personas: panteão de personas YAML locais
- Painel de personas no dashboard
### Changed
- Deploy migrado de Vercel para Cloudflare Pages
## [2.1.0] — 2026-03-01
### Added
- Skill /dream: auditoria de 24h em 8 buckets de sinal
✓ CHANGELOG eficaz
- • Uma entrada por versão com data
- • Seções semânticas (Added/Changed/Fixed)
- • Seção [Unreleased] para próxima versão
- • Frases curtas focadas no impacto
- • Atualizado a cada PR mergeado
✗ CHANGELOG inútil
- • "Vários bugs corrigidos"
- • Sem datas ou versões
- • Última entrada tem 6 meses
- • Copia-e-cola de commit messages
- • Mistura de breaking e bugfixes
Claude como assistente de CHANGELOG
Ao final de uma sessão produtiva: "Baseado nas mudanças que fizemos, adicione entradas na seção [Unreleased] do CHANGELOG.md seguindo o formato Keep a Changelog."
3 ⏪ Rollback seguro
Com o Claude gerando código rapidamente, erros acontecem. Saber fazer rollback sem drama é a habilidade mais subestimada em projetos de longo prazo.
Estratégias de rollback por cenário
Commit recente ruim — git revert
Cria um novo commit que desfaz as mudanças. Histórico preservado. Safe para branches compartilhadas.
git revert HEAD~1
Arquivo específico corrompido — git checkout
Restaura um arquivo para a versão de um commit anterior sem afetar o resto.
git checkout v2.2.0 -- src/components/Gallery.tsx
Deploy revertido — versão anterior em produção
No Cloudflare: dashboard → Deployments → selecionar versão anterior → "Rollback". Instantâneo, sem código.
✓ Preparado para rollback
- • Tags de versão em cada release
- • Commits atômicos e pequenos
- • Feature flags para features novas
- • Deploy automatizado (não manual)
- • Testes que detectam regressões
✗ Rollback impossível
- • Sem tags — não sabe qual versão reverter
- • Commits gigantes com 50 arquivos
- • Migrações de banco sem downgrade
- • Deploy manual sem histórico
- • Sem testes para detectar break
4 🔧 Refatorar com segurança
Refatoração com o Claude é rápida — e por isso perigosa. Sem testes, você não sabe se a "limpeza" quebrou algo. Ritual: testes primeiro, refatoração depois.
# 1. Garantir que testes passam ANTES de refatorar
bun test
# 2. Criar branch para a refatoração
git checkout -b refactor/aggregate-pipeline
# 3. Refatorar em passos pequenos, testar após cada passo
bun test --watch
# 4. Commit atômico por mudança semântica
git add src/lib/aggregate.ts
git commit -m "refactor: extract parseObsidianVault to separate function"
# 5. Confirmar que tudo ainda passa
bun test
# 6. Merge via PR (revisão antes de merge)
git push origin refactor/aggregate-pipeline
Prompt de refatoração segura
Diga ao Claude: "Antes de refatorar, mostre quais testes cobrem este código. Depois refatore em passos pequenos e execute os testes após cada passo."
✓ Refatoração segura
- • Testes passando antes de começar
- • Branch dedicada
- • Passos pequenos com commits
- • Rodar testes após cada passo
- • PR para revisão final
✗ Refatoração arriscada
- • Refatorar diretamente na main
- • Mudar 10 arquivos no mesmo commit
- • Sem testes para validar comportamento
- • Só rodar testes no final
- • "O Claude disse que está certo"
5 🧪 Testes como documentação viva
Testes bem escritos são a spec mais confiável: precisam passar para existir. Ao contrário de comentários e README que ficam obsoletos silenciosamente.
import { describe, it, expect } from 'vitest'
import { parseObsidianVault } from '../src/lib/aggregate'
describe('parseObsidianVault', () => {
it('retorna array vazio quando vault não existe', async () => {
const result = await parseObsidianVault('/nonexistent/path')
expect(result).toEqual([])
})
it('extrai notas com frontmatter válido', async () => {
const result = await parseObsidianVault('./fixtures/vault')
expect(result.length).toBeGreaterThan(0)
expect(result[0]).toHaveProperty('title')
expect(result[0]).toHaveProperty('tags')
})
it('ignora arquivos sem extensão .md', async () => {
const result = await parseObsidianVault('./fixtures/vault')
result.forEach(note => {
expect(note.path).toMatch(/\.md$/)
})
})
})
Estratégia de testes por projeto
Unit tests
Funções puras, parsers, transformações. Rápidos, sem I/O. 80% da cobertura.
Integration tests
Módulos trabalhando juntos. Scripts com fixtures. 15% da cobertura.
E2E tests
Fluxos críticos completos. Lentos, rodam no CI. 5% mas os mais importantes.
6 💳 Dívida técnica controlada
Dívida técnica não é sempre ruim — às vezes é a decisão correta no momento. O problema é quando ela acumula sem ser rastreada. Com Claude, a dívida acumula muito mais rápido que o normal.
✓ Dívida rastreada
- • TODO/FIXME com contexto e data
- • Issue no GitHub para cada dívida
- • Sprint de cleanup mensal
- • Métrica de TODO count no CI
- • Decisão explícita de "pagar depois"
✗ Dívida invisível
- • TODO sem autor nem data
- • Código duplicado "por enquanto"
- • Tipos any espalhados pelo TS
- • Dependências desatualizadas ignoradas
- • "A gente refatora depois"
// TODO(nei, 2026-05-15): Este parser é O(n²) para vaults grandes.
// Aceitável para agora (<500 notas) mas precisa de índice quando
// o projeto escalar. Ver ADR-003 para contexto da decisão.
// Issue: github.com/user/project/issues/42
function parseAllNotes(vault: string) {
// ...implementação atual...
}
Auditoria de dívida com Claude
Mensalmente: "Liste todos os TODO/FIXME do projeto com contexto e estime o impacto de cada um. Priorize por risco × esforço."
📋 Resumo do módulo
- • Semver: MAJOR.MINOR.PATCH com semântica
- • CHANGELOG no formato Keep a Changelog
- • Estratégias de rollback por cenário
- • Refatoração em passos com testes
- • Testes como documentação viva
- • Rastreamento de dívida técnica
- • Configure semver no seu projeto
- • Crie o CHANGELOG.md inicial
- • Adicione Vitest ao projeto
- • Audite os TODOs existentes