PTENES
5.3 Ruta 5 ~45 min

📦 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

PATCH 1.2.1 bugfix — sin cambios incompatibles MINOR 1.3.0 nueva feature — compatible MAJOR 2.0.0 breaking change

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.

comandos git para el control de versiones
# 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.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

  • • 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

1

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
2

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
3

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.

flujo de refactorización 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 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.

tests/aggregate.test.ts — ejemplo con 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$/)
    })
  })
})

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 con 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...
}
💡

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

✅ Aprendiste
  • • 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
🚀 Próximos pasos
  • • Configura semver en tu proyecto
  • • Crea el CHANGELOG.md inicial
  • • Agrega Vitest al proyecto
  • • Audita los TODO existentes