5.3 Trilha 5 ~45 min

📦 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

PATCH 1.2.1 bugfix — sem quebra MINOR 1.3.0 nova feature — compatível MAJOR 2.0.0 breaking change

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.

comandos git para versionamento
# 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.md — formato recomendado
# 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

1

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
2

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
3

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.

fluxo de refatoração segura
# 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.

tests/aggregate.test.ts — exemplo com Vitest
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 com contexto — formato recomendado
// 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

✅ Você aprendeu
  • • 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
🚀 Próximos passos
  • • Configure semver no seu projeto
  • • Crie o CHANGELOG.md inicial
  • • Adicione Vitest ao projeto
  • • Audite os TODOs existentes