📦 Mantenimiento, versionado y CHANGELOG
Semver, CHANGELOG estructurado, rollback seguro, refactorización con confianza y cómo controlar la deuda técnica en proyectos que duran meses.
1 🏷️ Semver — versiones que comunican intención
Cada número del semver comunica el impacto del cambio
Semantic Versioning (semver) no es burocracia: es comunicación. Cada número tiene un significado preciso que permite a cualquier persona (y a Claude) entender el impacto de una actualización.
# 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 sin cambios. Puedes actualizar sin leer el changelog.
MINOR x.Y.z
Nueva feature. Compatible con versiones anteriores. Lee el changelog para ver las novedades.
MAJOR X.y.z
Breaking change. Puede romper el código existente. Lee la guía de migración.
2 📋 CHANGELOG bien estructurado
El CHANGELOG es el diario del proyecto. Sigue el formato "Keep a Changelog" — organizado por versión con las secciones Added, Changed, Fixed y 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
- • Una entrada por versión con fecha
- • Secciones semánticas (Added/Changed/Fixed)
- • Sección [Unreleased] para la próxima versión
- • Frases cortas centradas en el impacto
- • Actualizado con cada PR fusionado
✗ CHANGELOG inútil
- • "Se corrigieron varios bugs"
- • Sin fechas ni versiones
- • La última entrada tiene 6 meses
- • Copiar y pegar mensajes de commit
- • Mezcla de breaking y bugfixes
Claude como asistente de CHANGELOG
Al final de una sesión productiva: "Baseado nas mudanças que fizemos, adicione entradas na seção [Unreleased] do CHANGELOG.md seguindo o formato Keep a Changelog."
3 ⏪ Reversión segura
Con Claude generando código rápidamente, ocurren errores. Saber hacer rollback sin drama es la habilidad más subestimada en los proyectos a largo plazo.
Estrategias de rollback según el escenario
Commit reciente incorrecto — git revert
Crea un nuevo commit que deshace los cambios. El historial se conserva. Es seguro para branches compartidas.
git revert HEAD~1
Archivo específico corrupto — git checkout
Restaura un archivo a la versión de un commit anterior sin afectar el resto.
git checkout v2.2.0 -- src/components/Gallery.tsx
Deploy revertido — versión anterior en producción
En Cloudflare: dashboard → Deployments → seleccionar una versión anterior → "Rollback". Instantáneo, sin código.
✓ Preparado para revertir cambios
- • Tags de versión en cada release
- • Commits atómicos y pequeños
- • Feature flags para nuevas features
- • Deploy automatizado (no manual)
- • Pruebas que detectan regresiones
✗ Rollback imposible
- • Sin tags: no sabes a qué versión volver
- • Commits gigantes con 50 archivos
- • Migraciones de base de datos sin downgrade
- • Deploy manual sin historial
- • Sin pruebas para detectar break
4 🔧 Refactorizar con seguridad
Refactorizar con Claude es rápido — y por eso, peligroso. Sin pruebas, no sabes si la "limpieza" rompió algo. Ritual: primero las pruebas, después la refactorización.
# 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 para una refactorización segura
Dile a Claude: "Antes de refatorar, mostre quais testes cobrem este código. Depois refatore em passos pequenos e execute os testes após cada passo."
✓ Refactorización segura
- • Pruebas pasando antes de empezar
- • Branch dedicada
- • Pasos pequeños con commits
- • Ejecutar pruebas después de cada paso
- • PR para la revisión final
✗ Refactorización riesgosa
- • Refactorizar directamente en main
- • Cambiar 10 archivos en el mismo commit
- • Sin pruebas para validar el comportamiento
- • Ejecutar pruebas solo al final
- • "Claude dijo que está bien"
5 🧪 Pruebas como documentación viva
Las pruebas bien escritas son la especificación más confiable: deben pasar para existir. A diferencia de los comentarios y el README, no quedan obsoletas en silencio.
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$/)
})
})
})
Estrategia de pruebas por proyecto
Pruebas unitarias
Funciones puras, parsers, transformaciones. Rápidos, sin I/O. 80% de la cobertura.
Integration tests
Módulos trabajando juntos. Scripts con fixtures. 15% de cobertura.
Pruebas E2E
Flujos críticos completos. Lentos, se ejecutan en CI. Son el 5%, pero los más importantes.
6 💳 Deuda técnica controlada
La deuda técnica no siempre es mala: a veces es la decisión correcta en el momento. El problema surge cuando se acumula sin llevar un registro. Con Claude, la deuda se acumula mucho más rápido de lo normal.
✓ Deuda registrada
- • TODO/FIXME con contexto y fecha
- • Una issue en GitHub por cada deuda
- • Sprint de limpieza mensual
- • Métrica de TODO count en el CI
- • Decisión explícita de «pagar después»
✗ Deuda invisible
- • TODO sin autor ni fecha
- • Código duplicado «por ahora»
- • Tipos any dispersos por TS
- • Dependencias desactualizadas ignoradas
- • "Refactorizamos después"
// 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...
}
Auditoría de deuda con Claude
Mensualmente: "Liste todos os TODO/FIXME do projeto com contexto e estime o impacto de cada um. Priorize por risco × esforço."
📋 Resumen del módulo
- • Semver: MAJOR.MINOR.PATCH con semántica
- • CHANGELOG en el formato Keep a Changelog
- • Estrategias de rollback por escenario
- • Refactorización en pasos con pruebas
- • Pruebas como documentación viva
- • Seguimiento de la deuda técnica
- • Configura semver en tu proyecto
- • Crea el CHANGELOG.md inicial
- • Agrega Vitest al proyecto
- • Audita los TODO existentes