sagas/odisea-del-blog-maestro/004-limpieza-y-primera-spec.md

2026-03-24 published

Episodio 004 — Limpieza de repo y primera spec de herramienta

Episodio 004 — Limpieza de repo y primera spec de herramienta

Serie: bitácora de ingeniería — caprini.dev
Slug: 004-limpieza-y-primera-spec
Resumen: cerramos la fase de reacción (repos rotos, 404, cachés raras) con una higiene explícita del repositorio y abrimos la de diseño de herramientas: la primera spec no es “otro fix”, es un producto mínimo con API clara.


Vibe check: de apagar fuegos a diseñar

Durante varios episodios el ritmo fue diagnóstico → parche → verificar. Eso es sano al principio; se vuelve agotador si no documentas la intención del siguiente salto. Aquí el cambio de tono es deliberado: SPEC-001 no describe un layout ni un token CSS; describe una pieza de flujo de trabajo (GitLab → texto listo para X) con requisitos medibles y límites (MVP vs no objetivos). La bitácora pasa a ser ancla narrativa; la spec, contrato.


Qué hicimos en este mini-episodio

  • .gitignore en la raíz: ñode_modules/, dist/, .astro/, .vscode/, *.log` — lo que no debe ensuciar el historial ni los diffs.
  • Índice de Git: git rm -r --cached . seguido de git add . para alinear el tracking con las nuevas reglas (si algún archivo quedó bloqueado por el SO o el IDE, se detiene el proceso y se revisa fuera de banda).
  • spec.md (proyecto 001-progress-tracker): primera especificación de herramienta bajo src/content/docs/projects/; visible en la galería /specs.
  • Router y memoria: DOC_ROUTER.md y AGENT_PERSISTENT_MEMORY.md actualizados para no perder el hilo entre sesiones.

Próximo paso lógico

Implementar el script (Node + API GitLab), tests con mocks del JSON de respuesta, y un párrafo de uso en memoria o runbook — sin tokens en el repo.